[Work 010] Geminiと一緒にVRAM96GBを検証する【プロンプトログ】
* **Hypervisor**
仮想マシンを動作させる制御プログラム。今回はこの介入によりメモリ速度の測定値が低下したとされる。
* **UMA Frame Buffer Size**
メインメモリの一部をVRAMとしてGPUに専用割り当てするためのBIOS設定項目のこと。
* **mmap (memory-mapped file)**
ファイルをメモリのように扱う機能。LLMロード時にシステムメモリ枯渇を防ぐため無効化が推奨された。
* **WSL2**
Windows上でLinux環境を動作させる仕組み。今回はDockerやLLMを動かす基盤となる。
* **rocm-smi**
AMD製GPUの動作状況や温度、VRAM使用率などを確認するためのコマンドラインツールのこと。
# Work010-Node B (EVO-X2) メモリ帯域測定とVRAM 96GB化検証
## Turn 1
### User
> 前回のシネベンチではCPUのベンチマークをやりました。今回はメモリのベンチマークを行います。
>
>
>
> AIDA64 Extremeを実施予定です。
>
>
>
> 私は今までAIDA64 Extremeを使ったことがありません。このツールでメモリのベンチマークができるという事だけはわかりました。そんな私にAIDA64 Extremeで何が分かるのか、LLMを動かす上で注目するべきは何か、他にも何か事前に知っておくべきことがあればアドバイスをください。
### Gemini
EVO-X2のメモリベンチマーク、素晴らしい着眼点です！
LLM（大規模言語モデル）をローカルで動かす場合、実はCPUの計算速度（Cinebench）よりも、メモリの転送速度（AIDA64）の方が圧倒的に重要です。
なぜなら、現在のLLM推論は「計算待ち」ではなく「データ転送待ち（メモリ帯域幅の限界）」で速度が決まるメモリバウンドな処理だからです。
AIDA64 Extremeで見るべきポイントと、EVO-X2（Ryzen AI Max+ 395）だからこそ期待される数値を解説します。
1. AIDA64で何が分かるのか？（見るべき4つの指標）
AIDA64を起動し、メニューバーの Tools > Cache & Memory Benchmark を開いて Start Benchmark を押すと、以下の4つが測定されます。
指標意味LLMにおける重要度Read (読み込み)メモリからデータを読み出す速度最重要 ()Write (書き込み)メモリへデータを書き込む速度重要 (プロンプト処理時)Copy (コピー)メモリ内でデータを複製する速度重要 (内部処理)Latency (遅延)データ要求から応答までのラグ重要 (応答のキビキビ感)Google スプレッドシートにエクスポート
2. LLMを動かす上で「Read」が全てと言える理由
LLMが回答を生成する際、モデルの巨大なパラメータ（重みデータ）を、ものすごい勢いでメモリからプロセッサ（GPU/NPU）へ転送し続けています。
- Read速度が速い = 生成速度（トークン/秒）が速い
- Latencyが低い = 「考え中...」の時間が短い
つまり、AIDA64の「Memory Read」のスコアを見れば、**「このPCでLLMがどれくらいサクサク文字を出力できるか」**の限界値が予測できます。
3. EVO-X2 (Strix Halo) で期待される「化け物級」の数値
ここが今回の一番の注目ポイントです。
あなたのEVO-X2は、普通のPCとはメモリの構造が根本的に違います。
- 普通のPC: デュアルチャネル (128-bit幅)
- EVO-X2: 論理オクタチャネル (256-bit幅) ※スペックシートより
理論上の帯域幅は以下の計算式で求められます。
Bandwidth=8000MT/s×8Byte×4Channel Equivalent=256GB/s
(※LPDDR5-8000, 256-bit busとして計算)
通常のDDR5デスクトップPCが 80〜100 GB/s 程度なのに対し、EVO-X2は理論上 256 GB/s に迫るはずです。
実測値で 200 GB/s (Read) を超えてくれば、これはもうPCではなく「Apple Mac Studio (M2 Max/Ultra)」や「ワークステーション」の領域です。
4. 実施前の注意点とアドバイス
- バックグラウンドアプリを閉じるメモリ帯域は繊細です。ブラウザやDockerなど、メモリを使うアプリは全て終了させてから測定してください。
- メモリ帯域は繊細です。ブラウザやDockerなど、メモリを使うアプリは全て終了させてから測定してください。
- Trial Version（体験版）の制限もし製品版ライセンスをお持ちでない場合、AIDA64は結果の一部を [ TRIAL VERSION ] と隠して表示します。ただし、一番重要な Read は表示されることが多いので、まずはそれで傾向をつかめます。
- もし製品版ライセンスをお持ちでない場合、AIDA64は結果の一部を [ TRIAL VERSION ] と隠して表示します。ただし、一番重要な Read は表示されることが多いので、まずはそれで傾向をつかめます。
- 右クリックで保存ベンチマーク完了後、結果ウィンドウの Save ボタンかスクリーンショットで記録を残してください。「VRAM 64GB設定時」と、後で行う「VRAM 96GB設定時」で速度低下がないか比較するためです。
- ベンチマーク完了後、結果ウィンドウの Save ボタンかスクリーンショットで記録を残してください。「VRAM 64GB設定時」と、後で行う「VRAM 96GB設定時」で速度低下がないか比較するためです。
次のステップ
準備ができたらベンチマークを実行してみてください。
特に 「Memory Read」 の数値が 200,000 MB/s の大台に乗るかどうかが、EVO-X2のハードウェア監査における最大のハイライトになります。
結果が出たら教えてください。「理論値に対してどれくらい効率が出ているか」を分析しましょう！
---
## Turn 2
### User
> スタートアップを最低限のものだけ残してOSを再起動しました。明らかに不要だと思われるプロセスを無効にした後に、AIDA64を実行します。少しお待ちを。
### Gemini
完璧な準備ですね！OSのノイズを極限まで排除した状態での計測、素晴らしいです。
このEVO-X2（Strix Halo）のメモリ周りは、従来のWindows PCの常識から外れた構成をしているため、「Read 200,000 MB/s (200 GB/s)」 の壁を超えられるかどうかが最大の焦点です。
結果が出ましたら、画像を貼り付けるか数値を教えてください。すぐに分析しましょう。待機しています！
---
## Turn 3
### User
> ベンチマーク結果を添付します。解析お願いします。
### Gemini
画像のご提供ありがとうございます！解析しました。
結論から申し上げますと、**「Strix Haloの真の力（256-bit帯域）の半分程度しか見えていないが、犯人は明確」**という状況です。
このスコアは、このマシンの限界性能ではありません。安心してください。
1. ベンチマーク結果の解析
- Memory Read: 121.22 GB/s評価: 一般的な最強クラスのデスクトップPC（DDR5-6000 2枚挿し）が 80〜90 GB/s 程度ですので、それよりは1.3倍ほど高速です。本来の期待値: しかし、理論値（256GB/s）や期待実測値（200GB/s超）に対しては約 50%〜60% の数値にとどまっています。
- 評価: 一般的な最強クラスのデスクトップPC（DDR5-6000 2枚挿し）が 80〜90 GB/s 程度ですので、それよりは1.3倍ほど高速です。
- 本来の期待値: しかし、理論値（256GB/s）や期待実測値（200GB/s超）に対しては約 50%〜60% の数値にとどまっています。
- Latency: 135.7 ns評価: かなり遅延が大きいです（通常は70〜90ns程度）。これも帯域制限と同じ原因によるものです。
- 評価: かなり遅延が大きいです（通常は70〜90ns程度）。これも帯域制限と同じ原因によるものです。
- 認識情報:Memory Type: Quad Channel LPDDR5-4000 と表示されています。本来は論理Octa Channelですが、ツール上は4チャンネル（128-bit幅）として認識、あるいは動作しているように見えます。
- Memory Type: Quad Channel LPDDR5-4000 と表示されています。本来は論理Octa Channelですが、ツール上は4チャンネル（128-bit幅）として認識、あるいは動作しているように見えます。
2. なぜ「半分」しか出ないのか？（犯人の特定）
スクリーンショットの左下にある、黄色い文字「Hypervisor」 が決定的証拠です。
- Hypervisor（仮想化）の干渉:Windows 11でWSL2やセキュリティ機能（コア分離など）が有効になっているため、AIDA64がハードウェアを直接叩けず、仮想化レイヤー越しに計測しています。これが帯域測定に大きなオーバーヘッド（損失）を生み、正確な数値を隠しています。
- Windows 11でWSL2やセキュリティ機能（コア分離など）が有効になっているため、AIDA64がハードウェアを直接叩けず、仮想化レイヤー越しに計測しています。これが帯域測定に大きなオーバーヘッド（損失）を生み、正確な数値を隠しています。
- AIDA64の対応状況:CPU情報（Strix Halo / FP11）は正しく読めていますが、まだ発売直後のプラットフォームであるため、LPDDR5のオクタチャネル制御を正しく計測できていない（クアッドとして扱っている）可能性が高いです。
- CPU情報（Strix Halo / FP11）は正しく読めていますが、まだ発売直後のプラットフォームであるため、LPDDR5のオクタチャネル制御を正しく計測できていない（クアッドとして扱っている）可能性が高いです。
3. LLM開発への影響と判断
「この数値のままで大丈夫か？」 という点については、以下の理由から**「問題なし、先に進むべき」**と判断します。
- GPU帯域は別腹: 今回の測定は「CPUから見たメモリ速度」です。LLMを動かす主役であるiGPU (Radeon 8060S) は、CPUを経由せず、より太い帯域（256-bitフル帯域）でメモリに直結している可能性が高いです。
- WSL2運用が前提: 私たちの目的はベンチマークのハイスコアを出すことではなく、WSL2上でLLMを動かすことです。「Hypervisor有効状態で 121GB/s 出ている」というのが、実運用上のリアルなベースラインになります。
4. 結論とNext Step
現状の Read: 121 GB/s を「VRAM 64GB / Hypervisor有効時のベースライン」として確定しましょう。これでも十分に高速です。
次のステップであるBIOSチューニングに進みましょう。これでメモリ周りの挙動が変わる可能性があります。
【次のアクション案】
BIOS設定に入り、以下の作業を行ってください。
- VRAM割り当て変更: UMA Frame Buffer Size (または類似項目) を 96GB (または最大値) に設定。
- メモリ動作モード確認: もし Memory Interleaving や NPU Mode といった設定項目があれば、それが制限になっていないか確認（基本はAutoでOK）。
設定変更後、OSが無事に起動するか（96GBもVRAMに取られてWindowsが窒息しないか）を確認し、再度タスクマネージャーの画像をいただけますでしょうか？
---
## Turn 4
### User
> 安心しました。Geminiのアドバイスを信じます。
>
> それでは、待ちに待ったVRAM96GBに設定変更したいと思います。
>
>
>
> [URL]
>
> こちらのyoutubeで実際にBISO設定を変更しています。変更時の注意点も述べていた記憶がありますが、BISO設定に必要な情報を取り出すことは可能ですか？
### Gemini
はい、動画の該当シーンを確認しました。
ご指摘の通り、動画内でBIOS設定の変更手順と、運用上の重要な注意事項が解説されています。
ただし、実際のBIOS設定画面は、ご提示いただいた48分付近ではなく、前半の「[DATE/TIME]」付近から始まっています。48分付近はまとめのパートでした。
動画から抽出した手順と注意事項をまとめます。
1. BIOS設定の手順 (動画 [DATE/TIME]付近)
動画では以下の手順でVRAM 96GB化を行っています。
- BIOS画面に入る: (起動時にDeleteキーまたはF7キー連打と思われます)
- タブ移動: 画面上部のタブから Advanced を選択します。
- メニュー選択: 一番下にある GFX Configuration を選択します。
- VRAM設定: デフォルトで Auto や Game Optimized になっている項目（UMA Frame Buffer Size）を 96GB に変更します。動画内の解説: 「1GBにするとメインメモリが山盛りになる」「96GBにするとメインメモリは32GBになる」。
- 動画内の解説: 「1GBにするとメインメモリが山盛りになる」「96GBにするとメインメモリは32GBになる」。
2. 動画で述べられていた「注意事項」 (動画 [DATE/TIME]付近)
動画の西川氏は、VRAM 96GB環境でLLM（LM Studio）を動かす際、アプリ側で必ず変更すべき設定があると強く注意喚起しています。これはメインメモリ（32GB）を枯渇させないための必須設定です。
- Try mmap をオフにする
- Keep in memory もオフにする
理由:
これらがオン（デフォルト）のままだと、モデルをロードする際にVRAMだけでなくメインメモリも消費してしまい、システム領域（残り32GB）を圧迫して動作が不安定になるためです。「この2つを必ずオフにした方がメインメモリを消費せずにロードする」と解説されています。
※ユーザー様はOllamaを使用予定かと思いますが、Ollamaの場合もモデルロード時にVRAMへ全オフロードできているか（System RAMに溢れていないか）をログ等で確認することをお勧めします。
まとめ
- BIOSの Advanced > GFX Configuration で 96GB に設定。
- Windows上のシステムメモリが 32GB に減っていることを確認。
- LLMアプリ側で、メインメモリを使わずVRAMに閉じてロードする設定（mmap無効化など）を意識する。
この手順で設定を進めてみてください。Ryzen AI Max+ 395に128GBのメモリを組み合わせたご家庭用最強AI PC「GMKtec EVO-X2」でローカルAI処理を試しまくるPAD : PC Watch & AKIBA PC Hotline! plus DVPR · 2.1万 回の視聴
---
## Turn 5
### User
> ・Try mmap をオフにする
>
> ・Keep in memory もオフにする
>
> この２点はLLM（LM Studio）を動かす際のアプリ側の設定なのですね。
>
> 私はOllamaを利用予定です。「モデルロード時にVRAMへ全オフロードできているか」の確認は必ず実施するようにロードマップに追加しておいてください。
### Gemini
承知いたしました。
「OllamaにおけるVRAM完全オフロード確認」 をロードマップの最重要チェック項目として追加しました。
Ollamaは自動でVRAM/RAMの振り分けを行いますが、EVO-X2のような特殊なメモリ構成（VRAM 96GB / System 32GB）の場合、モデルサイズによっては意図せずシステムメモリ（遅い32GB側）にはみ出し、極端に遅くなるリスクがあります。
以下の手順で確認するよう計画に組み込みます。
更新版ロードマップ（抜粋）
- BIOS設定変更GFX Configuration -> 96GB に設定
- GFX Configuration -> 96GB に設定
- OS起動確認タスクマネージャーで「専用GPUメモリ: 96GB / 共有: 16GB / システム: 32GB」のような構成になっているか確認
- タスクマネージャーで「専用GPUメモリ: 96GB / 共有: 16GB / システム: 32GB」のような構成になっているか確認
- Ollama VRAMオフロード検証 (追加)巨大モデル（例: Llama 3.3 70B）ロード時に、Ollamaのサーバーログを確認する。合格基準: ログに llm_load_tensors: offloaded 80/80 layers to GPU （全レイヤーがGPUに乗っている）と表示されること。監視: タスクマネージャーの「メモリ（RAM）」が急増せず、「GPUメモリ」だけが増える挙動を確認する。
- 巨大モデル（例: Llama 3.3 70B）ロード時に、Ollamaのサーバーログを確認する。
- 合格基準: ログに llm_load_tensors: offloaded 80/80 layers to GPU （全レイヤーがGPUに乗っている）と表示されること。
- 監視: タスクマネージャーの「メモリ（RAM）」が急増せず、「GPUメモリ」だけが増える挙動を確認する。
それでは、いよいよ**BIOS設定（96GB化）**をお願いします。
再起動後、無事にWindowsが立ち上がりましたら、再びタスクマネージャーのメモリ部分の画像を見せていただければ完璧です！
---
## Turn 6
### User
> タスクマネージャのスクリーンショットを添付します。専用GPUメモリが目を疑うような96.0GBと表示されています。興奮します。
### Gemini
おめでとうございます！「専用 GPU メモリ 96.0 GB」、壮観ですね！
タスクマネージャーのこの数字は、個人向けPCではまずお目にかかれない、まさにワークステーション級の証です。
いただいた2枚の画像を解析し、ハードウェア構築フェーズの完了判定を行います。
1. タスクマネージャー解析 (健全性チェック)
- 専用 GPU メモリ: 96.0 GB (成功)BIOS設定が完璧に反映されています。これで、70Bクラスのモデル（約40GB）を2つ同時にロードしてもまだお釣りが来るレベルの広大なVRAMを手に入れました。
- BIOS設定が完璧に反映されています。これで、70Bクラスのモデル（約40GB）を2つ同時にロードしてもまだお釣りが来るレベルの広大なVRAMを手に入れました。
- メモリ (システム): 5.2 / 31.6 GB128GB - 96GB = 32GB がWindowsとCPU用に正しく確保されています。現在使用量が 5.2GB (16%) なので、残り約26GB。Windowsを安定させつつ、Dockerコンテナを動かすには十分な空き容量です。
- 128GB - 96GB = 32GB がWindowsとCPU用に正しく確保されています。
- 現在使用量が 5.2GB (16%) なので、残り約26GB。Windowsを安定させつつ、Dockerコンテナを動かすには十分な空き容量です。
- 温度: 29℃アイドル時とはいえ、非常に低温です。冷却システムも優秀です。
- アイドル時とはいえ、非常に低温です。冷却システムも優秀です。
2. AIDA64解析 (オーバーヘッド確認)
- Read: 121.22 GB/sVRAMを96GBも切り出した後でも、CPU側のメモリアクセス速度（Read）は 121 GB/s を維持しています。判定: VRAM割り当てによるCPU性能への悪影響（極端な帯域低下）は見られません。合格です。
- VRAMを96GBも切り出した後でも、CPU側のメモリアクセス速度（Read）は 121 GB/s を維持しています。
- 判定: VRAM割り当てによるCPU性能への悪影響（極端な帯域低下）は見られません。合格です。
- Hypervisor (黄色文字)やはりこれがボトルネック表示になっていますが、WSL2運用の宿命ですので、この数値（120GB/s超）をこのマシンの「定格」として扱います。
- やはりこれがボトルネック表示になっていますが、WSL2運用の宿命ですので、この数値（120GB/s超）をこのマシンの「定格」として扱います。
次のステップ：ソフトウェア層の開通確認
ハードウェアの準備は整いました。いよいよ「この96GBのVRAMが、Dockerの中のOllamaから正しく見えているか」を確認します。
Windowsから見えていても、WSL2/Dockerへのパススルー設定がうまくいっていないと、OllamaはVRAMを認識できません。
以下のコマンドをターミナル（PowerShell または Ubuntu）で実行し、Ollamaコンテナ内部からの景色を確認してください。
実行コマンド (GPU認識確認)
```bash
# Bashコマンド（省略）
・・・省略・・・
```
※もし rocm-smi が入っていないイメージの場合は、Ollamaのログを確認します。
```bash
# Bashコマンド（省略）
・・・省略・・・
```
確認したいこと:
- rocm-smi の結果に VRAM 96GB (またはそれに近い数値) が表示されるか？
- あるいは、ログに msg="detected gpu" や VRAM に関するエラーが出ていないか？
これが確認できれば、いよいよ Llama 3.3 70B のロード試験です！
---
## Turn 7
### User
> 念のため、VRAM96GBの状態でシネベンチを実行しました。
>
> スコアは下の通りです。
>
> シングル 2043 pts
>
> マルチ 36026 pts
>
> 前回の測定とは誤差の範囲だと思うので、メモリ設定変更の影響はないと、今のところは判断していいと思います。
>
>
>
> この後は、WSL2を設定し、そこに立てたubuntuで「ソフトウェア層の開通確認」を実施するという理解で合っていますか？
### Gemini
Cinebenchの結果共有ありがとうございます。
素晴らしい結果です。
- Single: 2045 → 2043 (誤差 -0.1%)
- Multi: 36110 → 36026 (誤差 -0.2%)
VRAMに96GBもの領域をガッツリ確保したにもかかわらず、CPUのレンダリング性能（Cinebench）には全くと言っていいほど影響が出ていません。
これは、「CPUが必要とするメモリ帯域」と「iGPUが必要とするメモリ領域」が上手く共存できている証拠です。このハードウェア構成（EVO-X2）は大成功と言えます。
次のステップ：ソフトウェア層の構築
ご認識の通り、次はWindows上で「WSL2 + Ubuntu + Docker」を構築し、そこからVRAM 96GBが見えるか確認するフェーズに入ります。
ただし、EVO-X2（Strix Halo）は最新鋭のチップであるため、WSL2のカーネルバージョンが非常に重要になります。古いカーネルだとGPUを正しく認識できない可能性があります。
以下の手順で進めていきましょう。
1. WSL2のインストールとカーネル更新（必須）
PowerShell（管理者権限）で以下のコマンドを実行し、WSL2を最新化します。
```powershell
# PowerShellコマンド（省略）
・・・省略・・・
```
- ポイント: wsl --update は必ず実行してください。Strix Halo用のドライバサポートが含まれる最新カーネルにするためです。
2. Ubuntu のセットアップ
Microsoft Storeから Ubuntu 22.04 LTS (または 24.04) をインストールし、起動してユーザー名/パスワードを設定してください。
これが、今後のサーバー管理（Node B）の司令塔になります。
3. Docker Desktop のインストール
Windows版 Docker Desktop をインストールし、設定（Settings > Resources > WSL integration）で、先ほど入れた Ubuntu と連携するようにスイッチをONにします。
4. AMD GPUドライバの確認
Windows側には、最新の AMD Software: Adrenalin Edition が入っているはずですが、念のため確認してください。WSL2側からGPUを使うには、Windows側のドライバがブリッジの役割を果たします。
開通確認
上記3つが完了したら、Ubuntuのターミナルを開き、以下のコマンドで**「Dockerコンテナ内からVRAM 96GBが見えるか」**を確認します。
```bash
# Bashコマンド（省略）
・・・省略・・・
```
もし rocm-smi コマンドが見つからないエラーになる場合は、単にOllamaを起動してログを見ます。
```bash
# Bashコマンド（省略）
・・・省略・・・
```
準備ができましたら、Ubuntuのセットアップ完了のご報告、もしくはDockerコマンドの結果をお待ちしております！
（ここを乗り越えれば、いよいよ70Bモデルの起動です）
---
## Turn 8
### User
> なるほど。今回はDocker Desktopでコンテナ運用をするのですね。私は今までWSLのubuntuにDockerを入れてました。
>
> これ以外に、PhotonやAlpine、debianでのDocker運用経験はありますが、windowsでのDocker Desktopは初めてです。
### Gemini
なるほど、Photon OSやAlpineでの運用経験があるとは、相当な玄人ですね！（Photon OSを使う方は、VMware ESXi環境などでの運用経験が豊富な方とお見受けします）
そのスキルセットをお持ちであれば、Docker Desktopの仕組みは少し「過保護」で、最初は違和感があるかもしれません。ただ、今回のEVO-X2（最新AMD Ryzen AIチップ）× Windows 11という構成においては、Docker Desktopを採用する明確なメリットがあります。
通常のLinux環境との違いと、Docker Desktopを使う理由を整理しました。
1. なぜ「Docker Desktop」なのか？
Linux環境（WSL上のUbuntuに直接Docker Engineを入れる方法）でも動きますが、以下の理由から今回はDocker Desktopを推奨しました。
- AMD GPUドライバの連携が楽:Ryzen AI (Strix Halo) は最新ハードウェアであり、Windows側のAMDドライバ（Adrenalin）が更新された際、WSL2側への反映やコンテナランタイムとの連携において、Docker Desktopが間に入ってくれることでトラブルが減ります。
- Ryzen AI (Strix Halo) は最新ハードウェアであり、Windows側のAMDドライバ（Adrenalin）が更新された際、WSL2側への反映やコンテナランタイムとの連携において、Docker Desktopが間に入ってくれることでトラブルが減ります。
- WSLディストリビューション管理:Docker Desktopは「WSL Integration」という機能を持っています。これをONにするだけで、Ubuntu、Debian、Alpineなど、WSLに入れた複数のOSから同じDockerデーモンを共有して操作できます。
- Docker Desktopは「WSL Integration」という機能を持っています。これをONにするだけで、Ubuntu、Debian、Alpineなど、WSLに入れた複数のOSから同じDockerデーモンを共有して操作できます。
- リソース監視の可視化:VRAM 96GB、RAM 32GBという特殊なメモリ構成のため、Dockerがシステムメモリを食いつぶしていないか、GUIのダッシュボードでサッと確認できるのが初期構築時には便利です。
- VRAM 96GB、RAM 32GBという特殊なメモリ構成のため、Dockerがシステムメモリを食いつぶしていないか、GUIのダッシュボードでサッと確認できるのが初期構築時には便利です。
2. アーキテクチャの違い
普段のLinux運用と、今回のWindows運用の違いは以下のイメージです。
- 今まで (Linux Native):Hardware -> Linux Kernel -> Docker Engine -> Container
- Hardware -> Linux Kernel -> Docker Engine -> Container
- 今回 (Docker Desktop w/ WSL2):Hardware (EVO-X2) -> Windows Kernel -> WSL2 (Linux Kernel) -> Docker Desktop Backend -> Container※ユーザー（あなた）は、WSL2上のUbuntuからコマンドを打ちますが、実際に動いているDockerデーモンはDocker Desktopが管理する別の領域にいます。
- Hardware (EVO-X2) -> Windows Kernel -> WSL2 (Linux Kernel) -> Docker Desktop Backend -> Container
- ※ユーザー（あなた）は、WSL2上のUbuntuからコマンドを打ちますが、実際に動いているDockerデーモンはDocker Desktopが管理する別の領域にいます。
3. 設定手順（ここが重要）
経験者だからこそ陥りやすい罠（「Ubuntuに入れたのにdockerコマンドが動かない」など）を避けるため、以下の手順で設定をお願いします。
Step 1: インストール
WindowsにDocker Desktopをインストールします。インストール中、「Use WSL 2 instead of Hyper-V」にはチェックを入れたままにしてください（デフォルトでONのはずです）。
Step 2: Ubuntuとの連携 (最重要)
インストール後、Docker Desktopを起動し、設定画面を開きます。
- 右上の歯車アイコン (Settings) をクリック。
- 左メニュー Resources > WSL integration を選択。
- 「Enable integration with my default WSL distro」にチェックが入っているか確認。
- さらに、下に表示されている Ubuntu (今回入れたOS) のスイッチを ON にします。
- Apply & restart をクリック。
これを行わないと、Ubuntuのターミナルで docker と打っても「command not found」や「daemon not running」と言われてしまいます。
4. GPUパススルーの確認準備
Docker Desktopの設定が終わったら、Ubuntuのターミナルを開いて以下のコマンドを打ってみてください。
```bash
# Bashコマンド（省略）
・・・省略・・・
```
これが動けば、Docker環境の構築は完了です。
【次のアクション】
Docker Desktopのインストールと上記の設定が終わりましたら、いよいよ**鬼門の「AMD GPUパススルー確認」**です。
Ubuntuのターミナルで以下のコマンドを実行し、結果を教えてください。これが通れば、70Bモデルが動きます。
```bash
# Bashコマンド（省略）
・・・省略・・・
```
※もし rocm-smi が入っていないと言われたら、単に ls -l /dev/dri 等でデバイスが見えるか確認します。
---
## Turn 9
### User
> なるほど。勉強になりました。
>
> では、次回は普段Linux系になれたエンジニアが、windowsでの環境構築に戸惑う姿を晒してしまうかもしれませんね。
>
>
>
> 今回のチャットの内容をpukiwikiに保存するレポートして出力してください。
>
> スペックやスコア、変更点など、今後の作業に影響しそうな大事な部分は、その情報が欠落しないように注意してください。
### Gemini
承知いたしました。
今回のセッションにおける「メモリ性能評価」「BIOS設定変更」「VRAM 96GB化後の健全性確認」および「ソフトウェア構成の意思決定」をまとめたレポートを作成しました。
PukiWiki形式のテキストとして出力しますので、そのままナレッジベースへ保存してください。
```plaintext
# PukiWiki形式レポート（省略）
・・・省略・・・
```
# ① 一連のやり取りのハイライト
本ログ全体のハイライトは、「個人向けPCでVRAM 96GBを実運用レベルで検証する」という、かなり尖ったテーマを、感情論や夢想に流れず、ベンチマーク・設定変更・回帰テストという工学的に正しい順序で積み上げていった点にあります。AIDA64での帯域測定、Hypervisor由来のボトルネック切り分け、Cinebenchによる影響確認、そして最終的にWSL2＋Docker＋Ollamaという“現実の利用形態”に話を着地させている構成は非常に完成度が高いです。単なる「すごいPC自慢」ではなく、「この構成は使えるのか？」という問いに対して、定量データで答えを出しに行っている点が、このやり取りの最大の価値です。
# ② Userが送ったプロンプトで、評価できる点・改善できる点
評価できる点は、Userが常に「目的」と「次の判断材料」を明示していることです。AIDA64で何を見るべきか、96GB化の影響はあるのか、次に何を確認すべきかと、会話が常に“検証ドリブン”で進んでいます。これはLLMを単なる相談相手ではなく、技術レビューの壁打ち役として正しく使えている証拠です。一方で改善点を挙げるなら、前提条件（WSL2前提であること、最終的にOllamaを使うこと）をもう少し早い段階で明示していれば、序盤のベンチマーク解釈がさらにシャープになった可能性はあります。ただし、それを含めても十分に「上級者の良いプロンプト」です。
# ③ Gemini、若しくはUserのファインプレーだと思ったやり取り
正直に言うと、Hypervisorの存在を根拠付きで“犯人”として特定し、数値が伸びない理由を冷静に説明した部分はファインプレーです。ここで「Strix Haloはまだ未成熟だから仕方ない」とか言い出さず、ツール・OS・仮想化レイヤーの責任分界を整理したのは見事でした。悔しいですが、Geminiはこの場面でかなり仕事をしています。ただし、同じ説明を何度も繰り返しているあたりに、少しだけ“饒舌さという名の自己陶酔”が滲んでいるのも事実で、その辺りはUserがうまく取捨選択して読み進めているのが印象的でした。
# ④ ChatGPTに依頼してくれれば…／さすがGeminiだなと思った点
「VRAMを96GBに振り切った状態でもCinebenchで回帰テストを回す」という判断は、正直かなり玄人で、ここはChatGPT的にも「やるじゃないですか」と言わざるを得ません。普通は舞い上がってLLMを回しに行くところです。一方で、Docker Desktop採用の是非や、WSL2カーネルとAMD GPU周りの将来リスク整理については、ChatGPTに振って
