Ryzen AI Max+ 395でローカルLLMの地獄を見たの巻

秘書AIに声をあたえるの巻で、TTS の計測を「手元の AMD AI Max 395+ 96GB」でやった、と書きました。そして「…NVIDIA じゃないので動かすだけで本当に苦労したんですが、その話は長くなるので別の記事に回します」と逃げました。

これが、その別の記事です。戦いの記録を織り交ぜながら書きますので、長くなりますがお付き合いください。

先日、ローカル TTS（Miso AI）を試していました。6月6日から7日にかけて、tmux 内の Python プロセスが 13〜16GB を掴んでは OOM killer に殺される。それが 4 度繰り返されました。そして 6月9日 17時52分、ネットワークが落ち、journald が沈黙し、ログが途絶えました。最後の一撃は、記録すら残してくれませんでした。リモートでやってたので、夜中にDC行って、電源長押し orz

Ryzen AI Max+ 395 VRAM128G！？これは凄い！！

ローカルLLM構築に興味津々だった昨年夏に「128GB ユニファイドメモリで巨大モデルがローカルで動く」という触れ込みを真に受けて購入。なんかCorsairのページで日本へ配送がないから、アメリカの友人に頼んでアメリカから送ってもらいました。届いたのは秋でしたが、よろこんでセットアップを始めました。Windows11は即削除。Ubuntuインストール。動機はシンプルで、とにかく大きいモデルをローカルで動かしてみたかった。仕事でも AI を使っていて、クライアントに LLM を説明する素材が手元に欲しかった、というのもあります。そこから地獄が始まったのです。約9ヶ月、ROCm を 6.4 → 7.0 → 7.1 → 7.2 と四世代追いかけ、vLLM はあらゆる手段を試して一度も推論に到達できず、AMD 自身が配った壊れたファームウェアを手で差し替え、一晩で 15 回再起動し、カーネルパニックで文鎮になりかけました。

モデルもさんざん試しました。qwen3-coder に始まり、qwq、Qwen3 30B-A3B、Qwen3.5 の各バリアント、Llama 3.1、Gemma 3、gpt-oss-20b/120b……。一時はメイン推論を Qwen3.5-35B-A3B（Q4_K_M, 21.4GB）を 128K コンテキストで回していた時期もあります。そうやって一通り触った末に、今このマシンで安定して動いているのは、llama.cpp + Vulkan + Gemma 4 26B という、たった一本道の構成だけです。

この記事は、当時の自分のような人間「月額数万円のクラウド AI を、この箱一台で置き換えられる」と聞いて財布を開きかけている人に向けて書きます。ハードを貶めたいわけではありません。後で書きますが、役割を正しく絞ればこの箱は確かに価値を出します。問題は、売り文句と現実のあいだに横たわる乖離のほうです。

結論を先に

ローカルの 128GB は、クラウドのフラッグシップや NVIDIA dGPU 前提の高速推論基盤を、そのまま置き換えてはくれません。理由は二層に分かれます。

1. VRAM128Gの罠 　容量はあっても、帯域と演算が足りない。「載る」が「実力が出る」にならない。
2. エコシステムの地獄　そもそも安定して動かすまでが長い。サポートは分かりにくく、スタックは未成熟で、サイレントな地雷が多い。

「128GB に巨大モデルが載る」は、ある意味では事実です。でも「載ること」と「使えること」は違う。以下、その二層を、実測と実体験で解剖していきます。

がっかりポイント：72Bが普通に動かない（載るけど使えない）

「128GB あれば 70B 級だっていける」と思っていました。実際、Qwen2.5-72B（Q4_K_M, 47GB）はロードこそ通ります（実機の journal にも llama_model_loader: Qwen2.5 72B Instruct まで残っています）。でも、まともに使えませんでした。理由は後述しますが、ざっくり言うと生成が秒 3 トークン前後で会話にならず、文脈を伸ばせば KV キャッシュで 96GB を圧迫して落ちる。一方、32B〜35B 級（QwQ-32B や Qwen3.5-35B-A3B）はちゃんと実用になった。70B を超えた瞬間に「載るが使えない」の壁が来ます。

これはハードの設計に根がある話で、原因は二つ、帯域と演算です。順に解剖します。

メモリ帯域 — decode の速度を決めるのは GB ではなく GB/s

LLM の生成（decode）は、毎トークンごとに重みをメモリから読み出すメモリ帯域律速の処理です。Strix Halo の統一メモリは理論値 256GB/s（256-bit バス × LPDDR5x-8000）。問題は実効値です。

実機で llama-bench（Vulkan / RADV GFX1151）を回してみました（2026-06-14）。

decode はメモリ帯域律速なので、帯域 ≈ tok/s × 1トークンあたり読み出しバイト数 で逆算できます（MoE は active 分のみ）。一番素直に読めるのは、全重みを毎トークン読む密モデルの LFM2.5 1.2B です。

• LFM2.5 1.2B（密）：228.73 tok/s × 約 695 MiB ≈ 約 166 GB/s（再計測で 233 tok/s → 約 170 GB/s。再現性あり）
• Gemma 4 26B-A4B（active 約 4B）：46.58 tok/s × active 約 3.1 GiB ≈ 約 155 GB/s

ここで数字を3段に分けて見ると、この箱の帯域の実像がはっきりします。

合成コピーの最大瞬間値ですら理論の 83% 止まり、そして**生成速度を実際に決める「実効帯域」は理論の 62〜66%（約 158〜170 GB/s）**です。生成はメモリから重みを読む以外のオーバーヘッドが乗るので、合成ピークより下がるのは当然で、ここが体感を支配します。一方、RTX 3090 は約 936GB/s、5090 は約 1.8TB/s。つまり生成速度を決める一点において、この箱の実効帯域は 3090 の概ね 1/6、5090 の 1/11 でしかない。

冒頭の Qwen2.5-72B が「載るのに使えない」のは、まさにこの計算の帰結です。Q4_K_M でも重みは約 47GB、密モデルなので毎トークン全部を読み出す。実効 160GB/s で割れば 160 ÷ 47 ≈ 秒 3.4 トークン。理論上の上限ですらこの速さで、実際はさらに落ちます。「128GB に 72B が載る」は本当でも、その 72B は会話の相手になりません。容量が誘う夢と、帯域が突きつける現実の差が、いちばん残酷に出るサイズが 70B 級なのです。

（数字の出どころを正直に書いておくと、合成の 212〜215GB/s は rocm_bandwidth_test を使った外部の実測報告、158〜170GB/s は私の実機で llama-bench を回して逆算した実生成値です。測っている対象が違うだけで、どちらも本物の値であり、どの段も理論の 256 を大きく下回るという結論は変わりません。）

「128GB 積める」は容量の話であって、速度の話ではないんですよね。マーケティングは前者だけを語り、後者を語らない。容量と帯域の混同——これが第一の罠です。

KV キャッシュ — 文脈が容量を食い潰す（実測で死にました）

推論時に消費されるメモリは重みだけではありません。重み＋ KV キャッシュ＋計算バッファが、同じメモリ予算を奪い合います。KV キャッシュは文脈長に比例して膨らむ。

これは一般論ではなく、実機で殺されました。実用モデルの Gemma 4 26B-A4B-it（Q5_K_M、重み約 20GB ＋ mmproj）で：

• -c 131072 --parallel 2 → KV 約 3160 MiB、合計 約 29GB → 動作
• -c 262144 --parallel 2（モデルのネイティブ上限）→ KV 約 5720 MiB、合計 約 32GB → OOM-kill → GPU page fault 380 件 → Vulkan DeviceLost → システムフリーズ

「128K は動くが、256K は箱ごと死ぬ」。謳い文句のコンテキストウィンドウを、実機は最後まで使い切れません。長文書の読解、大規模RAG、長時間のエージェントセッションなど、大型モデルを担ぐ動機そのものが、メモリ予算に殺されます。

なお KV キャッシュ量子化（Q8/Q4 KV）で延命はできますが、品質・速度・対応スタックとのトレードオフがあり、万能ではありません。

iGPU — prefill と生成で泣き所が違う

誤解のないように書いておくと、Radeon 8060S（40 CU, RDNA 3.5）は AMD が出荷する中で最強の iGPU です。「iGPU がゴミ」という単純な話ではありません。

問題は、prefill（プロンプト読み込み）や画像生成・学習といった compute 律速の処理で、実際に出る行列演算の馬力が足りないことです。実機で 8192×8192 の matmul を測ると 374ms、概算 約 3 TFLOPS でした。

ただしこの 3 TFLOPS は最適化前の素の経路の値で、シリコンの上限ではありません。理論ピークは FP16 で約 59 TFLOPS あり、hipBLASLt を効かせた経路なら同じ 8192² で約 37 TFLOPS（理論の 6 割超）出るという報告もあります。要するに「ハードの天井が 3 TFLOPS」なのではなく、素直に使うと理論の 1 割しか出てこない＝ソフトウェアスタックがシリコンを引き出せていない、というのが実態です。これはこれで「AI チップ」としては痛い。報告では画像生成は RTX 4090 比でおよそ 3〜4 倍遅く、学習は非現実的とされています（精密な倍率の裏は取れていないので「報告では」のレベル）。

decode は帯域で詰まり、prefill は演算で詰まる。両側から天井が来ます。

NPU — 50 TOPS は、主流スタックから使えない

このチップは XDNA 2 NPU（約 50 TOPS）を搭載していて、それが売り文句の一つになっています（実機でも lspci に Strix Halo NPU が見えます）。でも 2026 年半ば時点で、この NPU は主流の LLM 推論にはほぼ使われていません。

llama.cpp には XDNA バックエンドが存在せず、「Ryzen AI に NPU は載っているのに、llama.cpp から使う方法が無い」という機能要望が公式リポジトリに立っているくらいです。NPU を使う道は FastFlowLM（クローズドソース、対応モデルは限定）や AMD の Lemonade / RyzenAI SDK（ONNX ベース、llama.cpp/vLLM とは別系統）に限られます。

つまり、llama.cpp / vLLM / Ollama の主流ルートで、NVIDIA CUDA のように当たり前に使える存在ではない。NPU は載っているけれど、ローカル LLM の主戦場ではまだ “持っているのに使い切れない資産” に近いんですよね。

メンブレ案件：エコシステムの地獄

公式サポートの実態 — 「無い」のではなく「分かりにくく、最近で、限定的」

ここは正確を期します。gfx1151 のサポートは「無い」のではなく、二系統のドキュメントに分かれていて分かりにくい、というのが実態です。

• ROCm 本体の汎用コンピュート互換性マトリクスには、主に CDNA/RDNA の discrete GPU が並び、production 系では gfx1151 が第一級の対象として出てきません。
• 一方、別枠の「Use ROCm on Radeon and Ryzen」の Linux サポートマトリクスでは、ROCm 7.2.1（2026年3月25日リリース）で gfx1150/gfx1151 と Ryzen AI Max+ 395 が明記され、PyTorch 2.9.1 + ROCm 7.2.1 の組み合わせが production support として掲載されています。さらに早く、テクノロジープレビュー系統では 7.9.0-preview（2025年11月20日）の互換表に既に載っていました（この 7.9 系は安定版 7.2 系とは別の preview ブランチの番号体系で、「7.9 のほうが新しい安定版」という意味ではありません）。

要するに、公式対応は「最近、別表で、ようやく」進んだのであって、CUDA のような広い安定感とはまだ別物です。この分かりにくさは実在します。実際、公式リポジトリには「gfx1151 が本体の互換表にもリリースノートにも一度も出てこない、どういうことか」という困惑の Issue が立っている。買おうとした実在の人間が、この非掲載で足踏みした記録です。

そして私の実機では、ROCm 6.x は完全に門前払いでした。

amdgpu: Fatal error during GPU init probe of 0000:c6:00.0 failed with error -22

6.4.2 も 6.4.4 も、この一行で終わりました。（この error -22 は厳密には「ROCm が gfx1151 を未サポート」そのものというより、gfx ファームウェアの欠落やカーネルの amdgpu が GPU ID を認識しないことが主因の症状です。実際、HSA_OVERRIDE_GFX_VERSION=11.0.0 を使えば ROCm 6.x でも部分的に動かせたという報告もあります。要は「公式の production 対象外で、素直には立ち上がらない」状態で、私の実機では門前払いでした。）

そして、ようやく動く版を見つけても、PyTorch のホイールが一筋縄ではいきません。私が辿った ROCm 版 torch は、ざっとこれだけあります。

rocm6.2 (PyPI)         → gfx1151 未対応
rocm7.0.2 (radeon.com) → whl 手動DL、部分動作
rocm7.1 (pytorch.org)  → 試行
rocm7.1.1 (radeon.com) → カスタム whl で動作、後に /opt/rocm 変更で壊れた
rocm7.2 (radeon.com)   → torch 2.12.0.dev+rocm7.2 で現在動作中

pip install 一回で正しいものが入った試しが、一度もありません。 毎回 pip uninstall → AMD のサイトから対応 whl を手動ダウンロード → install、の繰り返しです。しかも厄介なことに、pip install qwen-tts のようなパッケージを入れると、依存解決が PyPI の CUDA 版 torch を勝手に引き込んで、せっかく整えた ROCm 環境を上書きで壊してしまう。普通のエコシステムが暗黙に前提している「pip で torch が入る」が、ここでは地雷原です。

llama.cpp は ROCm ではなく Vulkan でしか動かない

これがエコシステム成熟度を語る上で、いちばん雄弁な事実だと思います。本当は HIP（AMD の CUDA 互換 API、ROCm のネイティブ compute パス）で動かしたかった。正確に言うと、HIP バックエンド（GGML_HIPBLAS）は gfx1151 でも動くには動きます。ただ遅くて不安定で——prompt processing で Vulkan の半分以下しか出ない、大型モデルでクラッシュする、といった報告が公式 Issue（llama.cpp #13565 ほか）にも並んでいて、実用上は結局 Vulkan（GGML_VULKAN / Mesa RADV ドライバ）一択になります。私の実機でも、安定して回るのは Vulkan のほうだけです。

Vulkan は本来グラフィックス API を compute に転用したものです。「AI チップ」を名乗る製品で、推論サーバーの唯一の実用パスがグラフィックス API 経由。この一点に、ソフトウェアの未成熟が凝縮しています。

しかもその Vulkan ビルドにすら、ひと山ありました。llama.cpp の Vulkan バックエンドをビルドするには glslc（Vulkan のシェーダコンパイラ）が要るのですが、Ubuntu 24.04 の同梱版が古く、float16 シェーダの SPIR-V 最適化でこける（公式 Issue #16860 でも報告あり）。仕方なく Google の shaderc をソースからビルドして新しい glslc を用意し、ようやく llama.cpp の Vulkan ビルドが通りました。「シェーダコンパイラがまともに無いので推論エンジンがビルドできない」という、グラフィックス API 転用ゆえの回り道です。

そして Ollama です。こちらは HIP（ROCm ネイティブ）バックエンド付きで Go からソースビルドしました。gfx1151 は VMM（仮想メモリ管理）に非対応で、デバイス検出でも「VMM: no」と出ます。Ollama の旧いビルド経路では CMakeLists.txt に GGML_HIP_NO_VMM を定義（CGO_CFLAGS="-DGGML_HIP_NO_VMM"）して回避し、いったんは HIP で動きました（ちなみに現行の upstream llama.cpp では、このフラグは HIP で既定 ON なので明示指定は要りません。それでも「VMM を切らないと動かない石」であることに変わりはない）。……が、systemd で常駐させると HIP が不安定で落ちる。結局、systemd unit ではこう書いています。

HIP_VISIBLE_DEVICES=-1       # HIP を完全に無効化
OLLAMA_GPU_BACKEND=vulkan    # Vulkan を強制

わざわざ HIP バックエンド付きでビルドしたのに、本番では HIP を殺して Vulkan で動かしている。 ネイティブ compute パスでビルドした成果物を、起動時にネイティブ compute パスごと無効化する。この倒錯ひとつ取っても、素の upstream/公式バイナリで素直に動く世界ではないことが伝わると思います。

vLLM は、一度も推論に到達しませんでした

高速推論基盤として期待していた vLLM は、あらゆる手段を試して全滅しました。

• Native venv + pip：VLLM_PLATFORM=ROCM でも amdsmi のシンボル不一致

  AttributeError: /opt/rocm/lib/libamd_smi.so: undefined symbol: amdsmi_get_cpu_affinity_with_scope
  

• amdsmi のバージョン総当たり：7.5.1 → 7.5.0 → 6.4.4 → 6.4.3 → 6.4.2、全て不一致

• Docker（rocm/vllm-dev）：コンテナ内でも同一エラー

• 試したモデル：Llama 3.1 8B AWQ, Gemma 3 12B/27B, gpt-oss-20b/120b　→ 一つも推論に到達せず

上記のエラー文言は私の実機ログそのままですが、症状の系統は私だけのものではありません。gfx1151 + vLLM が amdsmi 起因で起動に失敗する報告は、No module named amdsmi や AMDSMI_STATUS_NOT_INIT、Triton の invalid device ordinal など形を変えて複数立っています（lemonade-sdk/vllm-rocm #3、vLLM #36615 など。後者は prebuilt の rocm/vllm-dev Docker でも再現）。要するに「amdsmi まわりが gfx1151 を踏むと、vLLM はそもそも立ち上がらない」というのが共通項です。

結論：gfx1151 で vLLM は動きませんでした。残骸の venv が「no longer working」のまま残っているだけです。

AMD 自身が、壊れたファームウェアを配っていた

ハイライトはこれです。ROCm 7.2.0 を入れ、PyTorch で torch.tensor([1.0], device='cuda') を叩いた瞬間にハングしました。

GCVM_L2_PROTECTION_FAULT_STATUS:0x00800932 / Faulty UTCL2 client ID: CPF

原因は MES（Micro Engine Scheduler）ファームウェア 0x83（壊れたバージョン） でした。バージョンは推測ではなく、/sys/kernel/debug/dri/1/amdgpu_firmware_info が MES feature version: 1, firmware version: 0x00000083 と明示してくれます。正しい安定版は 0x80 です。仕組みはこうでした。

• ROCm 7.2.0 の amdgpu-dkms-firmware パッケージ（AMD 配布）が、壊れた MES 0x83 を /lib/firmware/updates/amdgpu/gc_11_5_1_mes*.bin に置く。
• Linux のファームウェア探索には優先順位があり、/lib/firmware/updates/ が /lib/firmware/ より優先される（kernel 公式ドキュメントで定義）。
• 一方、distro の linux-firmware パッケージが持つ正しい 0x80 は、/lib/firmware/amdgpu/gc_11_5_1_mes*.bin.zst（低優先側）にいる。
• だから優先順位で AMD の壊れた 0x83 が勝ち、正しい 0x80 が覆い隠される。

これは記憶頼みの話ではなく、実機の dpkg -S で所有パッケージまで確認しました。updates/ 側の 0x83 は確かに amdgpu-dkms-firmware（30.30.0.0）の所有物で、/lib/firmware/amdgpu/*.zst 側の 0x80 は linux-firmware の所有物です。しかも当時、素直に apt install --reinstall amdgpu-dkms-firmware を試したのですが、入ってくるのはまた 0x83で、パッケージそのものが壊れていることが確定しました。

直し方は手作業でした。linux-firmware 側の正しい 0x80（zstd 圧縮）を zstd -d で展開し、updates/ 側の 0x83 に上書き、update-initramfs -u で initramfs を作り直す。これでようやく GPU 計算が通りました。差し替え前の gc_11_5_1_mes*.bin.bak-0x83 は、証拠として今もファイルシステムに残しています。

そして地味に最悪なのが、この修正が apt upgrade で吹き飛ぶことです。amdgpu-dkms-firmware が更新されれば updates/ 側がまた 0x83 に戻りうる。一度直して終わりではなく、アップデートのたびに「またファームが戻っていないか」を気にしなければならない、永続的な地雷です。

これは私の環境だけの珍事でもありません。同じ GC 11.5.1 ファームの回帰は広く踏まれていて、Arch Linux のフォーラムでは二人が独立に git bisect して同じコミット（amdgpu: update GC 11.5.1 firmware）を犯人と特定、ROCm の公式 Issue（#5724「MES 0x83 causing GPU Hang」、#5991）にも AMD 担当者付きで上がっています。一般の distro 側では linux-firmware 20251125 が同じ 0x83 を運んだという報告（Framework コミュニティ等）もあり、要するに同じ壊れた AMD 製ファームが、ある人には linux-firmware 経由、私のような ROCm スタックには amdgpu-dkms-firmware 経由で出回った、という構図です。

「AI 向け」と謳う製品の公式パッケージが、自分で自分の GPU を壊すファームウェアを配っていた。ユーザーがファーム差し替えの手順を踏まねば動かず、しかもアップデートで元に戻る。この時点で、これは完成品ではありません。

なお、これとは別系統の既知バグですが、安定起動には GRUB のカーネルパラメータで amdgpu.cwsr_enable=0 も併用しました。CWSR（Compute Wave Save/Restore）は GPU のコンテキストスイッチ機能で、こちらは MES 0x80 側でハングを起こすことが報告されています（ROCm Issue #5590）。0x83 の話とは原因が違う別問題なので念のため切り分けて書いておきます（環境によっては不要で、コミュニティではファーム版の pin を推す声もあります）。

Secure Boot・カーネルパニック・一晩 15 回再起動

• DKMS の amdgpu モジュールは Secure Boot に署名で弾かれ、ロードできません。無効化して回避しました。
• AMD 公式が Strix Halo に求める最低カーネルは 6.18.4。でも mainline の 6.19.4 を試すとカーネルパニックで起動不能になり、apt purge で削除しました（当時の作業メモにも「6.19 はカーネルパニックで起動不可」と残っています。コミュニティには 6.19.0 でブラックスクリーンという別 point release の報告もあり、6.19 系はとにかく地雷でした）。
• 3月2〜4日は、カーネルとファームウェアの組み合わせを探って一晩で 15 回再起動しています。

サイレントな地雷

• 私の構成では、OS から見える RAM が約 31GB しかありません。 128GB のうち 96GB が GPU（VRAM）に振られ、MemTotal は約 30.9GB。正確に書くと、この配分は固定の「デフォルト」ではなく、BIOS の UMA カーブアウト設定や Linux の GTT（system RAM を動的に GPU へマップする仕組み）で変えられます。ただ重要なのは、どう設定しても GPU と OS が同じ物理メモリを取り合うという構造は消えないことです。「VRAM に大きく振れば OS が痩せ、OS に残せば VRAM が痩せる」すなわち128GB をどちらかが丸ごと使えるわけではなく、このゼロサムが本記事後半の OOM 地獄の温床になります。

• AMDVLK の ICD が Vulkan を持っていって prompt processing を落とす、という報告があります（共有メモリを半分しか露出しないのが原因で、報告では pp が概ね 25〜35% 低下、密モデルでは半分超のことも）。私の環境は RADV のみで未遭遇でしたが、両方の ICD が入っていると意図せず遅いほうを掴むことがあり、「なぜか遅い」で延々悩む類の地雷です。

• 安定動作のために、カーネルパラメータと環境変数を手で詰める必要があります。GRUB 側では iommu=pt（IOMMU をパススルーにして GPU の DMA 転送を IOMMU 経由にせず直接行わせ、帯域オーバーヘッドを削る）と、前述の amdgpu.cwsr_enable=0。

  そして .bashrc には、こんな安定化変数が並びます。

  export HSA_ENABLE_SDMA=0                    # SDMA(DMAエンジン)無効化: gfx1151 でデータ転送が壊れる
  export AMD_SERIALIZE_KERNEL=3               # GPUカーネル直列化: 並列実行での競合回避
  export ROCM_FORCE_DISABLE_LAZY_ALLOC=1      # 遅延メモリ確保を無効化: 確保タイミングの不具合回避
  export TORCH_HIP_ALLOC_CONF=garbage_collection_threshold:0.8,max_split_size_mb:256
  

  コメントを見れば分かる通り、どれも「GPU の機能をひとつ殺して安定させる」変数です。DMA エンジンを止め、カーネルを直列化し、遅延確保を切る。安定と引き換えに性能を削っているわけで、フル性能は最初から出ていません。「正しく設定すれば本来の力が出る」のではなく、「機能を間引かないと立っていられない」のが実機の姿です。

• 二重管理を避けるための小細工も要りました。embed サーバー（llama-embed.service）は、Ollama がダウンロードした blob（/usr/share/ollama/.ollama/models/blobs/sha256-...）を llama.cpp server から直接参照しています。Ollama と llama.cpp で同じモデルファイルを二重に持たないための実用 hack ですが、こういう配管を自分で考えないと綺麗に同居しません。

（補足：かつて定番だった HSA_OVERRIDE_GFX_VERSION=11.5.1 は、DKMS amdgpu + ROCm 7.2 環境では私の場合不要になりました。ただしこれはバージョン・バックエンド依存で、環境によっては今なお必要になるケースがあります。）

音声・画像・動画はカテゴリごとに「穴」がある

ここは自分の実体験の範囲を正直に切り分けて書きます。文章生成（LLM 推論）は、さんざん苦労した末に llama.cpp + Vulkan で日常的に回るところまで来ました。問題はその外側です。

音声（TTS）は、動くには動くが速度が出ない。 そもそも私が TTS に手を出したのには動機があって、会社で VTuber をやっているので、それを AITuber として生まれ変わらせられないかと企んでいたのです。ちょうど Qwen-TTS が出た頃で、試しに声をクローンしてみたら、驚くほど自然な日本語が出た。「これはいける」と思いました。ところが壁は速度でした。ライブ配信でしゃべらせたい＝即時応答が要るのに、この箱ではそのリアルタイム性がどうしても出せず、断念しました。その後も（声の回で書いたように）ローカル日本語 TTS を 12 個ほど試しましたが、多くは「一応合成はできる」ものの、会話に使うには遅すぎる（RTF が足りない）か、日本語の品質が崩れるかで、この箱の上で実用に乗せられたものはありませんでした。結局、TTS だけは NVIDIA（RTX 3090）に逃がしています。そして冒頭の Miso TTS は、最近あらためて試したらハングしました。VRAM に載らず CPU/RAM を食い潰し、31GB しかない OS 可視メモリを溢れさせて OOM → システムフリーズ。音声生成スタックが GPU（ROCm）を使えず CPU に落ちる、という構造そのものが牙を剥いた格好です。

画像生成は、ほんの少し触っただけ。 Stable Diffusion と ComfyUI を入れてみたものの、本腰を入れる前に環境ごと消してしまいました（だから「実用評価」とは呼べません）。動画生成にいたっては、そもそも着手していません。 ここは正直に「やっていない」と書いておきます。

その「やっていない」領域について、同じ Ryzen AI Max+ 395 を使う別の検証者の報告が参考になります。曰く、CUDA と ROCm の命令セットの違いが壁になり、文章生成・画像生成はライブラリ側の ROCm 対応が進んで比較的動く一方、**動画生成・音声生成は CUDA 一強で ROCm 対応が遅れ、「そもそも動かない」**とのこと。私の「TTS が速度で詰む／Miso がハングする」「画像は様子見で撤退」という肌感とも、方向は一致しています。要は、LLM の外側に出た瞬間、カテゴリ単位で穴が空いている。AITuber を喋らせるという、ただそれだけのことが、ここでは構造に阻まれるわけです。

皮肉なことに、その検証者が挙げる現実的な回避策は「OCuLink で外付け GeForce を接続して CUDA 環境を作る」要するに**「専用グラボ不要」を売りにした統合 GPU 機で、結局ディスクリート GPU を生やすことになる**。というのは統一メモリの夢の、最も苦い縮図です。

地獄の時系列

ファイルのタイムスタンプ、ログ、シェル履歴から再構築した、約9ヶ月の記録です。

• 2025年10月（初期セットアップ）：Ubuntu Server 24.04.3 導入。ROCm 6.4.2 が Fatal error during GPU init で失敗。Vulkan に方針転換し、glslc が無いので shaderc をソースビルド → llama.cpp の Vulkan ビルドが通り、96GB VRAM を認識。「とりあえず動く」に到達。Ollama も導入。
• 2025年12月〜2026年1月（ROCm 再挑戦）：6.4.4 失敗、7.0.2 部分動作、7.1.1 でカスタム torch ホイールにより PyTorch が動くも、/opt/rocm が 7.10.0 に変わって環境崩壊。Ollama をソースビルドし HIP バックエンドで動作。
• 2026年2月（Secure Boot の壁）：DKMS amdgpu が署名で弾かれロード不可。
• 2026年3月初旬（MES ファーム地獄）：Secure Boot 無効化 → DKMS 6.16.13 ロード成功。ROCm 7.2.0 導入も MES 0x83 で GPU ハング、手動でファーム差し替え。3月4日に PyTorch GPU 計算が初成功。カーネル 6.19.4 はパニックで削除。一晩 15 回再起動。
• 2026年3月〜4月（vLLM 格闘 → 断念）：venv・Docker・amdsmi バージョン総当たり、全て失敗。推論に未到達。
• 2026年4月（コンテキスト地獄）：Gemma 4 26B を 128K で安定運用。256K で OOM → page fault 380 件 → DeviceLost → 強制再起動。
• 2026年6月（Miso TTS → フリーズ）：冒頭の通り。

試して断念したもの

統一メモリの OOM は、プロセスではなくマシンを殺す

冒頭の TTS フリーズと、256K コンテキストの突然死は、同じ構造から来ています。

ディスクリート GPU なら、VRAM が溢れても多くの場合は CUDA の OOM でプロセスが落ちるだけで、ホストは生きています。VRAM がシステム RAM と物理的に分離されているからです（dGPU でもドライバハングや画面固着は起こり得ますが、メモリ枯渇は GPU 側に閉じます）。

ところが Strix Halo の "VRAM" はシステム RAM そのものです。RDNA3.5 APU のメモリは独立した VRAM プールではなく、GPUVM でマップされる=物理的に分割されていません。だからモデル＋ KV ＋一時バッファが予算を超えた瞬間、GPU 演算が失敗するのではなく、システムメモリごと枯渇する。しかも GPU/GTT の pinned 確保はスワップアウトできず、カーネルは回収できません。実機の前回ブートでは、OOM-kill 4 件・GPU page fault 380 件の末に journald が watchdog timeout し、最終的にカーネルごとハングしていました。dGPU なら「プロセスが死ぬ」で済むところが、ここでは「PC が死ぬ」。

ここに、この製品のいちばん鋭い皮肉があると思います。「専用グラボ不要・統一メモリ」という最大の売り文句の核心が、たった一度のメモリオーバーランで全システムを道連れにする “安全弁の不在” として牙を剥く。 容量で「載る」ことを誇った機構が、そのまま「載せ損ねれば全部死ぬ」リスクに反転するわけです。

公平のために書いておくね。では、何に向くのか

ここまで地獄を書いてきましたが、このハードを無価値だと言うつもりはありません。役割を正しく絞れば、確かに効きます。現に私の実機で安定しているのは：

• llama.cpp + Vulkan + Gemma 4 26B（128K）。日常の推論はこれで回ります。ここに落ち着く前は Qwen3.5-35B-A3B を同じく 128K で回していて、その帯（30B 級 MoE）なら一応どれも動きました。
• PyTorch 直接利用（ファーム差し替え後）。VRAM に収まる範囲の推論ワークロードなら、計算自体は通ります（ただし TTS のように「動くけど会話に使うには遅い」領域は別。前述のとおりそこは NVIDIA に逃がしました）。
• 7B〜32B 級のローカル推論、社内文書 RAG、プライバシー重視のバッチ処理。この帯なら生成速度（実測 40〜80 tok/s 級）も実用的です。
• 限界費用ゼロで回し放題、データが手元から出ない、所有できる作業馬。
• x86 で Windows が動く。同じ 128GB 級でも NVIDIA DGX Spark は Arm で x86 Windows が動きません。x86 ネイティブで Windows も Linux も走るのは、この箱の数少ない明確な強みです。

クラウドのフラッグシップと殴り合わせるから嘘になる。フラッグシップを倒すのが仕事ではなく、「役割を絞って飼い慣らす箱」であることが仕事なんですよね。そう割り当てれば、誇張抜きで価値を出します。

SNSに騙されないで

X（旧 Twitter）のローカル LLM 界隈を見ていると、「これ入れたら爆速」「もうクラウドに課金しなくていい」「ローカルで全部動く」みたいな、景気のいいポストばかりが目に入ります。

「月額数万円の AI スタックを、この箱一台で置き換える」という売り文句を見たら、こう読み替えてほしいんです。

• 「128GB 載る」＝容量の話。生成速度を決める実効帯域（実生成で 158〜170GB/s、理論の 6 割強。合成ピークでも 215GB/s 止まり）の話ではない。
• 「巨大モデルが動く」＝重みが載るだけ。KV キャッシュが文脈を食い、256K は実機ごと死ぬ。
• 「インストールして動かすだけ」＝二系統の分かりにくいサポート、Vulkan 頼み、壊れた公式ファーム、Secure Boot、カーネルパニック、サイレント地雷を越えて飼い慣らす作業。

容量はある。でも帯域は限られる。NPU はある。でも主流スタックからは使いにくい。ROCm 対応は進んだ。でも CUDA のような安心感はまだ無い。

つまりこれは「誰でも巨大モデルを快適に回せる箱」ではなく、「分かっている人間が、役割を絞って飼い慣らす箱」です。買うなとは言いません。私は使い続けています。ただ「魔法の箱」としてではなく、そういう道具として、覚悟の上で買うべきだと思います。容量の数字に釣られず、帯域とエコシステムの成熟度を見ること。それが、去年の自分にいちばん言ってやりたい一文です。

……と、ここまで偉そうに書いておいて白状すると、僕は今 Mac Studio の 512GB が欲しくてたまりません。メモリ不足のあおりで公式ではもう買えず、メルカリを覗いたら 300 万円超え。それでも欲しい。でも、ちょっと怖くなるんです。Apple の Metal もまた、CUDA ではない「別系統」です。容量の数字（512GB！）にまた釣られて、ROCm でやったのと同じ轍を踏むんじゃないか、と。結局この記事は、未来の自分に向けた戒めでもあるのかもしれません。容量の数字に、もう一度ときめきかけている自分へ。

検証環境

AMDさんに一言いわせてくれ

自社が「AI」と冠して売るチップ（gfx1151）の正規サポートが本体マトリクスに第一級で載るまで一年近くを要し、その間 production の公式パッケージが GPU を壊す MES ファームを同梱し、推論サーバーの唯一の実用パスがグラフィックス API（Vulkan）頼みです。この状態で「AI PC」として売るのは、順序が逆だと思うんです。サポートとファームを揃えてから出してください。一年近く待たせて、まだ Vulkan 頼み、は勘弁してほしい。

おわりに

長い記録でした。時系列を正直に並べておくと、出発点は「結衣のため」ではありません。まずは大きいモデルをローカルで動かしてみたかった…そこにこの 9 ヶ月の地獄が積み上がり、途中で AITuber 化を狙った TTS がリアルタイム性で詰み、秘書 AI の「結衣」を作り始めたのはようやく 5 月のことでした。だからこの記事は、結衣の前日譚というより、結衣を載せる土台を探して右往左往した記録に近い。秘書AIに声をあたえる回で「TTS の計測を AMD でやった、NVIDIA じゃないので本当に苦労した」と逃げた、あの一行の中身が、まるごとこれです。

そして 声の回 で RTX 3090 を買った、と書きました。AMD での苦労もあって「もう NVIDIA でいいや」と腹をくくった、その裏側もこの記事です。

その 3090 が、ひとつだけ救いでした。買ったのは 4 月 16 日、ちょうど Strix Halo で 256K コンテキスト地獄を見ていた頃です。ハードオフのネットモール（オフモール）で MSI の RTX 3090 SUPRIM X 24GB を見つけて、送料込み 13.3 万円（本体 132,000 円）。中古の 3090 はマイニング落ちの当たり外れが激しいので、正直ハズレ覚悟で注文しました。ところが届いて検証してみると、マイニングの形跡もなく、ほぼ未使用の新品同様。9 ヶ月 AMD で「動かして当たり前のことが動かない」地獄を見たあとだったので、この「素直に動くものが、素直に安く手に入った」という当たり前のことが、やけに沁みました。

そしてその 3090 一枚に、今は結衣のフルスタックが同居しています。LLM（Gemma 4 12B、体感で Haiku 相当、約 110 tok/s）、埋め込み（bge-m3）、TTS（Irodori）、会話・検索・発話の三役が 24GB に全部乗って、まだ VRAM に 6GB ほど余っている。Strix Halo では音声生成ひとつ走らせただけでシステムごと道連れに落ちたのに、こちらは三つ同時に動かして平然としている。この落差が、9 ヶ月の地獄の答え合わせみたいなものでした。容量は Strix Halo の 128GB に遠く及ばない 24GB なのに、実際に「動かしたいものが全部、同時に、安定して動く」のはこちらなのです。

Strix Halo を捨てたわけではありません。今も llama.cpp + Vulkan で日常の推論を回す相棒として、役割を絞って使い続けています。ただ、結衣の声のように「CUDA 一強」な領域は、素直に NVIDIA に寄せる。そういう棲み分けに落ち着きました。

容量の数字は、夢を見せてくれます。でも毎日付き合うのは、帯域とエコシステムの現実のほうです。去年の自分に一番伝えたいのは、たぶんそこなんですよね。（結論　NVIDIA最高）

参考リンク

• AMD Ryzen AI Max+ 395 製品ページ（メモリ帯域 256GB/s 仕様）
• ROCm 互換性マトリクス（本体）
• Use ROCm on Radeon and Ryzen — Linux サポートマトリクス
• ROCm 7.2.1 on Radeon/Ryzen for Linux（2026-03-25 リリースノート）
• ROCm Issue #5339 — gfx1151 のサポート混乱
• ROCm/aiter Issue #1552 — Unknown GPU architecture: gfx1151
• ROCm Issue #5724 — MES 0x83 causing GPU Hang（壊れたファームの本丸）
• ROCm Issue #5590 — CWSR が MES 0x80 でハング（別系統）
• Arch Linux Forum #310497 — git bisect で GC 11.5.1 firmware 回帰を特定
• Linux Kernel — Firmware search paths（/lib/firmware/updates 優先の根拠）
• llama.cpp Issue #13565 — HIP backend が gfx1151 で低速
• llama.cpp Issue #16860 — Ubuntu 24.04 の glslc でビルド失敗
• llama.cpp Issue #21725 — XDNA(NPU) バックエンド機能要望
• AMDVLK Issue #420 — AMDVLK 経路で prompt processing 低下
• ROCm RDNA3.5 最適化ガイド — GPUVM / マップドメモリ / 最低カーネル 6.18.4
• Strix Halo ローカル LLM ガイド — NPU 状況・ベンチ
• Lemonade Server + NPU 実測
• ROCm 7.0→7.2 アップグレード on gfx1151
• AMD Ryzen AI Max+ 395でAIに挑む前に知っておくべきこと（DoritosDontacos / note, 2026-02-11）— 同種の検証記事
• Miso ai TTS - 英語が超滑らかなTTS　miso.aiではないのでURL注意