【780M向け】llama.cppのVulkan iGPU対策が相次ぐ：load-mode autoで二重メモリ回避、BIOS「Auto」割当がVRAM認識を壊す、ROCmFP4モデルが3款目登場
目次
- llama.cpp: default load-mode autoでiGPU二重メモリを回避（PR#26081）
- CRITICAL: Strix Halo APUでBIOS「Auto」がVRAM認識0を招く（Issue#26089）
- 780M環境でのVulkanモデル読み込みフリーズ確認（Issue#26087）
- Vulkan Strix向けROCmFP4モデルが3款目登場
- HIP: FlashAttentionのrocWMMAカーネルを削除（PR#26046 / Commit fa72ae）
- HIP: VMM不可信頼時はレガシーメモリプールにフォールバック（PR#26054）
- OpenCL: 融合RMS normのmul view offsetを修正（PR#26085）
- vLLM: ROCm関連3件（MoE不整合・GEMMフォールバック・hybrid-Mamba崩壊）
- vLLM: unified-memory GPUでgpu_memory_utilizationを尊重（Issue#49760）
- vLLM: ROCm CIネイティブコンパイルキャッシュをローカルディスクに強制（Issue#49763）
- Unsloth: 企業プロキシ対応・.jsonデータセット修正（PR#7416 / PR#7421）
- まとめ：今日やるべき3つのアクション
この記事はAIによって編集・作成されています。
本日（2026-08-10）のAMD 780M（RADV / Vulkan）向けLLM情報をまとめた。今回の主軸は、iGPUでLLMを動かすユーザーに直結する2つの重大な発見だ。一つはllama.cpp PR#26081で採用されたデフォルトのload-mode auto。これはiGPUでmmapを回避し、デバイスの共有メモリへモデルがコピーされる際の二重メモリ問題を防止する。もう一つはPR#26089で報告された問題。Windows 11上でBIOSのGPUメモリ割当を「Auto」にしていると、VRAM認識が0になる。これは「Fixed」割当にすれば解決するが、BIOS設定が正しいことを確認する必要がある。
またVulkan Strix向けROCmFP4モデルが3款目登場。Laguna-S 2.1・GPT-OSS 120B・Nemotron 3 Nano 30BのいずれもAMD Strix（gfx1151）向けに最適化されたFP4量子化モデルだ。一方vLLMでは、hybrid-MambaモデルがRDNA世代でTriton paged attentionにフォールバックしデコードが崩れる問題が780Mを含むRDNA3で報告された。
llama.cpp: default load-mode autoでiGPU二重メモリを回避（PR#26081）
llama.cpp PR#26081は、iGPUユーザーにとって極めて重要な変更だ。これによりload-modeのデフォルトがautoに設定される。autoモードはiGPUにおいてmmapを回避し、モデルをデバイスの共有メモリに直接ロードする経路を選ぶ。これにより、ホストメモリに一度モデルがコピーされた後にデバイス側にもコピーされるという二重メモリ問題が防止される。この対応はPR#20834およびPR#26023に続くフォローアップであり、特にVRAM制限が厳しい780MのiGPU環境でモデル読み込みが失敗するケースの根本原因への対処となる。
780M（16GB UMA）で20Bパラメータ以上のモデルをVulkanで動かす場合、この変更はモデルの読み込み成功率に直結する可能性がある。まだ適用前のビルドを使っているなら、最新のmainブランチにupdateする必要がある。
情報源: llama.cpp PR#26081 — add default load-mode auto, which avoids mmap on iGPUs
CRITICAL: Strix Halo APUでBIOS「Auto」がVRAM認識0を招く（Issue#26089）
PR#26089は、AMD Strix Halo APU（gfx1151、32GB UMA）を持つユーザーに重要な注意喚起だ。Windows 11上のBosgame M5で、BIOSのGPUメモリ割当を「Auto」に設定していると、VRAMの列挙結果が0になる。つまりllama.cppが「VRAMが0GB」としてモデルをロードしようとして失敗する可能性がある。この問題を回避するには、BIOS設定でGPUメモリ割当を「Fixed」にする必要がある。「Auto」のままVulkanでLLMを実行すると、モデルサイズが大きいほど読み込み直後にフリーズする可能性が高い。
この問題は今後修正される見込みだが、それまでの間、BIOSの設定を確認するのが唯一の回避手段となる。
情報源: llama.cpp Issue#26089 — VRAM enumeration returns 0 on AMD Strix Halo (Windows) BIOS Auto
780M環境でのVulkanモデル読み込みフリーズ確認（Issue#26087）
PR#26087では、Bosgame M5（Ryzen AI Max）でQwen 3.5 122B-A10B-MTPモデルをVulkanでロード中、100% CPUフリーズが発生したと報告されている。これはモデルが非常に巨大なため、共有メモリの割当に失敗し、GPU側ではなくCPU側のループでフリーズしている可能性が高い。780Mで122BクラスのモデルをVulkanで動かそうとした場合、同様のフリーズが発生する可能性がある。実用的なサイズ（7B〜20B程度）で試すよう推奨する。
情報源: llama.cpp Issue#26087 — Qwen 3.5 122B hangs 100% CPU using Vulkan on AI Max
Vulkan Strix向けROCmFP4モデルが3款目登場
AMD Strix（gfx1151）向けに最適化されたROCmFP4量子化モデルが3款目登場した。いずれもサイズは未確認だが、Strix固有の最適化が施されていると期待される。
Laguna-S 2.1 Q4_0 ROCmFP4（公式・Lean版）
1337Heroによる公式Laguna-S 2.1 Q4_0 ROCmFP4モデルと、kingjones777によるStrix Lean版。後者はVRAM節約向けの軽量化版で、Strix HALO / gfx1151向けに特別最適化されている。
情報源: 1337Hero / Laguna-S-2.1-Q4_0-ROCMFP4-GGUF
情報源: kingjones777 / Laguna-S-2.1-Q4_0_ROCMFP4_STRIX_LEAN-GGUF
Chadrock ROCmFP4 StrixKVSpine V4
jcbtcによるChadrock ROCmFP4モデル。StrixKVSpine V4を採用しており、エージェント的コーディング・ツール使用に最適化されている。KVスパインの最適化により、Strix環境での推論効率が向上する可能性がある。
情報源: jcbtc / Laguna-S-2.1-Chadrock-ROCmFP4-StrixKVSpine-V4-GGUF
GPT-OSS 120B・Nemotron 3 Nano 30B A3B（ROCmFP4 Strix Lean）
gsrunionによる大規模MoEモデル2款。GPT-OSS 120B ROCmFP4 Strix Leanと、Nemotron 3 Nano 30B A3B（MoE Mambaハイブリッド）のROCmFP4 Strix Lean版。いずれもサイズ未確認。122Bクラスのモデルを780Mで動かすのは現実的ではないが、Strix向けの最適化が施されたモデルとして注目される。
情報源: gsrunion / gpt-oss-120b-ROCmFP4-STRIX_LEAN-GGUF
情報源: gsrunion / Nemotron-3-Nano-30B-A3B-ROCmFP4-STRIX_LEAN-GGUF
HIP: FlashAttentionのrocWMMAカーネルを削除（PR#26046 / Commit fa72ae）
llama.cpp PR#26046および関連コミット（fa72aeccb239）で、AMD向けのrocWMMA FlashAttentionカーネルが削除された。これにより、全てのAMDハードウェアでより高性能なMMAカーネルが統一して使われるようになった。古いCUDA由来のFlashAttention実装は既にObsoleteであり、AMDユーザーはこの変更でパフォーマンス向上が期待できる。llama.cppの最新ビルドでは自動的に新しいMMAカーネルが採用される。
情報源: llama.cpp PR#26046 — remove rocWMMA FlashAttention kernel
情報源: llama.cpp Commit fa72aeccb239 — Removes obsolete CUDA FlashAttention kernel
HIP: VMM不可信頼時はレガシーメモリプールにフォールバック（PR#26054）
PR#26054により、HIPビルドでVMM（Virtual Memory Management）が信頼できない場合、レガシーメモリプールにフォールバックするようになった。これは共有メモリシステム（iGPUなど）で特に重要だ。VMMが正常に機能しない環境でも、レガシープールの経路でモデルロードが継続される。780Mのような共有メモリ環境では、このフォールバックがモデルロードの成否を分ける可能性がある。
情報源: llama.cpp PR#26054 — fall back to legacy memory pool when VMM not reliable
OpenCL: 融合RMS normのmul view offsetを修正（PR#26085）
PR#26085でOpenCLの融合RMS norm計算におけるmul view offsetのバグが修正された。AMDハードウェアではOpenCLとVulkanを同時に走らせられる可能性があるため、OpenCLバックエンドを使う場合、この修正が含まれているビルドを適用する必要がある。Vulkan単独では直接影響しないが、OpenCL/Vulkanの両方を使う環境では重要だ。
情報源: llama.cpp PR#26085 — fix fused RMS norm mul view offset
vLLM: ROCm関連3件（MoE不整合・GEMMフォールバック・hybrid-Mamba崩壊）
MoE: expert_mapとAITER expert_maskの不整合修正（Issue#49758）
vLLM Issue#49758で、ROCmのMoE（Mixture of Experts）処理におけるexpert_mapとAITER expert_maskの不整合が修正された。非AITERエクスパートがEP（Expert Parallelism）下で正しく動いていたのが、この修正で正常化される。780MでMoEモデルをvLLMで動かす場合、この修正を含むビルドを使う必要がある。
情報源: vLLM Issue#49758 — [ROCm][MoE] Fix expert_map vs AITER expert_mask
RDNA世代でhybrid-MambaモデルがTriton paged attentionにフォールバックしデコードが崩壊（Issue）
vLLMのRDNA性能問題で、hybrid-MambaモデルがRDNA世代（780Mを含むRDNA3を含む）においてTriton paged attentionにフォールバックし、デコードパフォーマンスが崩壊すると報告された。Mambaブロックを持つモデルをvLLMで780M上で動かす場合、このフォールバックにより生成速度が著しく低下する可能性がある。当面の回避策はMambaモデルを避け、標準Transformerモデルを使うこと。
情報源: vLLM Issue — [Performance] On RDNA, hybrid-Mamba models fall back to Triton paged attention
bf16→fp32ルーターGEMMがROCmでstandalone copy kernelにフォールバック（Issue）
vLLMのbf16→fp32ルーターGEMMがROCm環境でstandalone copy kernelにフォールバックする性能問題。780MでvLLMのルーター（multi-agent等）を使う場合、このフォールバックによるオーバーヘッドが影響する可能性がある。
情報源: vLLM Issue — [Performance][ROCm] Fused bf16→fp32 router GEMM falls back on ROCm
vLLM: unified-memory GPUでgpu_memory_utilizationを尊重（Issue#49760）
vLLM Issue#49760で、unified-memory GPU（GB10 / DGX Spark / Jetson）におけるgpu_memory_utilizationのバグ修正。共有メモリ環境ではgpu_memory_utilizationがメモリを予約せず、ホストメモリを圧迫してシステムを硬く楔（かくだ）する可能性があった。この修正により、共有メモリGPUでもgpu_memory_utilizationが適切に機能するようになる。780Mは共有メモリGPUであるため、vLLMを使う場合この修正を含むビルドを適用する必要がある。
情報源: vLLM Issue#49760 — [Bugfix] Respect gpu_memory_utilization on unified-memory GPUs
vLLM: ROCm CIネイティブコンパイルキャッシュをローカルディスクに強制（Issue#49763）
vLLM Issue#49763で、ROCm CIのネイティブコンパイルキャッシュがローカルディスクに強制されるようになった。これはROCmユーザーのパフォーマンスと信頼性向上に直結する修正だ。780MでvLLMをビルド・実行する場合、この変更でコンパイルキャッシュの再ビルド時間が短縮され、信頼性が向上する可能性がある。
情報源: vLLM Issue#49763 — [ROCm][CI] Force native compile caches onto local disk
Unsloth: 企業プロキシ対応・.jsonデータセット修正（PR#7416 / PR#7421）
Unslothの2款PR。PR#7416でhostnameベースの企業プロキシに対応。PR#7421で.jsonデータセットが行ごとのパーシングから単一のJSON文書として解析されるよう修正された。Fine-tuning環境で.jsonファイルを使う場合、この修正が適用されているビルドを使う必要がある。
情報源: Unsloth PR#7416 — support hostname-based enterprise proxies
情報源: Unsloth PR#7421 — Parse .json dataset as one JSON document
まとめ：今日やるべき3つのアクション
llama.cppの最新ビルドをビルド — PR#26081（load-mode auto）とPR#26054（VMMフォールバック）はiGPUユーザーに必須。最新のmainブランチから再ビルドする。
BIOSのGPUメモリ割当を「Fixed」に — PR#26089で報告されたVRAM認識0問題の回避策。Windows 11環境では必ず確認する。
vLLMを使う場合は修正ビルドを確認 — Issue#49758（MoE不整合）とIssue#49760（unified-memory gpu_memory_utilization）を含むビルドを使う。MambaモデルはRDNA3でデコード崩壊する恐れがある。
本日得たROCmFP4 Strixモデルは、いずれもサイズ未確認。正式なVRAM要件・推論性能が確認されるまで、サイズ10B〜20B程度のモデルで780M上でテストすることを推奨する。
SwitchBot公式ページ
クーポン「AF-4903」で5％引き（アフィリエイトクーポンになりますのでご協力お願いします）
割引の詳しい仕組みに関してはこちらのページを参照ください。
製品ごとの特徴・紹介動画は SwitchBot 製品ガイド にまとめています。
その他おすすめリンク
【2026年8月】クーポン・ポイント情報 GMKtec MINISFORUM GEEKOM ACEMAGIC 公式サイト攻略法
当ページの商品リンクは基本アフィリエイト（SwitchBot、Amazon、楽天、アリエクスプレス他）となっております。ご協力いただければ幸いです。