山村商店

【CUDA 16GB向け】16GB GPU向けMoE最適化、Vulkan不具合修正、推論パラメータ伝播の修正

ローカルLLMCUDA量子化LLM最適化GPU

目次
  1. 今回の要点
  2. 16GB GPU向けMoE最適化とDFlash2推論機能の追加
  3. Vulkan環境のVRAM枯渇とRDNA4不具合報告
  4. 推論パラメータ伝播とlogprobs APIの修正
  5. Nemotron EmbedとQwen系列の最適化対応
  6. サーバーのトークンカウントとSSEイベント修正
  7. 出典

llama.cpp は ggml-org が開発する C/C++ の LLM 推論エンジン。GGUF 形式の量子化モデルを CPU/GPU で動かす。

今回の要点

  • VRAM不足解消と推論速度向上に直結するMoE最適化とDFlash2推論機能が追加された。
  • AMD GPUユーザーの動作安定性に直結するVulkan環境のVRAM枯渇とRDNA4不具合報告がなされている。
  • API互換性確保と推論品質の安定化のため、推論パラメータ伝播とlogprobs APIの修正が行われた。
  • 新モデル利用とメモリ効率改善のため、Nemotron EmbedとQwen系列の最適化対応が行われた。
  • 運用時のメトリクス正確性とクライアント連携のため、サーバーのトークンカウントとSSEイベントの修正が行われた。

16GB GPU向けMoE最適化とDFlash2推論機能の追加

前提

MoE (Mixture of Experts) モデルは、パラメータの一部のみを活性化させることで推論効率を高めるアーキテクチャ。GPUのVRAM容量が限られる環境では、ホストRAMにオフロードされた重みへのアクセスがボトルネックになる。

何が変わったか

GPUに常駐するLRUキャッシュが、ホストRAMに存在するMoEの専門的重みに対して導入された。これにより、ホストRAM帯域幅に縛られていたデコーディング処理が改善される。また、DFlash2というハードウェアアクセラレーションされた推論方法に対して確率的サンプリングが拡張され、speculative decoding における logprobs API のサポートも追加された。さらに、speculative decoding において大きな draft context を使用した場合の KV cache オーバーフローを防ぐため、draft context が n_ctx_train に制限されるようになった。

なぜ重要か

16GBのVRAMを持つGPUユーザーが、CPUオフロードされたMoEモデルを動かす際の速度が大幅に向上する。また、speculative decoding を使用しているCUDAユーザーは、logprobs API が利用可能になり、推論品質の安定化に寄与する。

根拠のリンク

利用者の報告

  • ngxsonは、llama.cppスキーマとAnthropicスキーマ間のパラメータ競合リスクを懸念し、互換性を保つため既存コードを残しつつ新しい`extra_params`フィールドにllama.cpp関連パラメータを格納する案を提示した ngxson
  • ServeurpersoComは、将来のAnthropicキーとの競合を防ぐためnamespacedなフィールドが安全だと同意し、標準Anthropicパラメータはトップレベルに残しllama.cpp固有パラメータのみ`extra_params`オブジェクトに格納するよう変更を提案した ServeurpersoCom

利用者の報告

RTX 4090 + llama.cpp-omni の環境で、M4 iPad Pro (16GB) における SSD 専門的読み込み速度が、ベースラインの 2.97 tok/s から、contiguous weight layout と dspark speculative sampling を有効化することで 17.39 tok/s (5.86倍) になったという報告がある @SympathyLabs。一方、NVIDIA GLM-5.3-Flash-NVFP4 (DFlash2) において、2x H200s と 4x RTX Pro 6000 の比較では、SGLang および vLLM のスループットデータが予想以上に接近していたという報告もある @keennay。また、同じラップトップ、同じモデルでの比較において、vLLM (NVFP4 + DFlash2) は約 50 tok/s、llama.cpp Q4_K_M + MTP (native Windows) は 36.6 tok/s、llama.cpp (WSL) は 30.5 tok/s だったという報告がある @sherlock_comms。

Vulkan環境のVRAM枯渇とRDNA4不具合報告

前提

Vulkan はクロスプラットフォームのグラフィックスAPI。AMD GPU (Radeon) を使用する場合、Windows 環境では WDDM (Windows Display Driver Model) 経由でVRAMとシステムメモリの管理が行われる。ReBAR (Resizable BAR) が無効の場合、VRAMの効率的な利用が制限されることがある。

何が変わったか

ReBAR無効のAMD GPU (RX 6950 XT) 環境において、Vulkanバックエンド使用時に `DEVICE_LOCAL|HOST_VISIBLE` メモリタイプが優先され、VRAMではなくシステムメモリの共有セグメントにバッファが割り当てられる問題が報告された。これにより、プロセスの共有予算を超えて `ErrorOutOfDeviceMemory` が発生し、VRAMは空いているにもかかわらずキュー送信が失敗する。また、RDNA4 (gfx1201) アーキテクチャにおいて、Flash attention 有効時、head_dim 256 のモデルで長文脈プリフィル時に出力が破損し、直ちに EOS (End of Sequence) となる不具合も報告された。この破損は非単調な帯域（〜66.5k および 〜87.5k トークンで発生し、〜76.5k は正常）で見られる。

なぜ重要か

AMD GPUユーザー、特にReBAR無効環境やRDNA4アーキテクチャ（例：Radeon AI R9700）を使用するユーザーにとって、推論の安定性や出力の信頼性に直結する課題。VRAM枯渇エラーや出力破損により、長文脈推論や特定のモデルアーキテクチャでの利用が制限される。

根拠のリンク

利用者の報告

AMD Radeon RX 6950 XT (16 GB)、AMD proprietary driver、Windows 11、32 GB RAM、resizable BAR 無効の環境で、stable-diffusion.cpp (ggml fork) を使用し、Vulkanバックエンド時に `ErrorOutOfDeviceMemory` が発生し、`ggml_backend_dev_memory()` がVRAMの大半を空いていると報告してもキュー送信が失敗するという報告がある laurentvv。また、AMD Radeon AI R9700 (gfx1201, RDNA4, 32 GB)、ROCm 10.0、Windows x64 の環境で、Qwen3.8-27B モデル使用時、Flash attention 有効で長文脈プリフィル時に出力が破損し、直ちに EOS となる不具合が確認された konopka。同様のカード (R9700) とモデルで、`/completion` では直ちに EOS となるが、`/v1/chat/completions` では正常に回答するケースも報告されており、ログプロットの閾値や数値の微小な変化が影響している可能性が示唆されている DanoPTT。

推論パラメータ伝播とlogprobs APIの修正

前提

llama.cpp のサーバーは OpenAI 互換の API エンドポイントを提供する。`/v1/messages` は Anthropic 互換のインターフェースとして使用されることがある。推論パラメータ（温度、top_k、top_p、シードなど）は、エンドポイント間で正しく伝播しないと、推論結果や制御が意図しないものになる。

何が変わったか

`/v1/messages` エンドポイントにおいて、それまで `temperature`、`top_k`、`top_p`、`stream`、`chat_template_kwargs` のみが伝播されていたが、`server-schema.cpp` に定義された 24 種類の sampling パラメータがすべて伝播されるようになった。これにより、`seed`、`min_p`、`presence_penalty` などのパラメータが正しく適用される。また、speculative decoding 有効時でも logprobs API が正常に動作するよう修正された。さらに、`/v1/messages` において `id_slot` が伝播されず、スロット選択が自動に戻ってしまう問題が修正された。

なぜ重要か

API互換性を確保し、推論品質の安定化に必要。特に、`/v1/messages` を使用しているユーザーは、推論パラメータが正しく適用されないことで、再現性や制御性が損なわれていた。また、スロットピン機能が正しく動作しないことで、長文脈セッションにおいて再プリフィルが発生し、推論速度が大幅に低下する問題が解消される。

根拠のリンク

利用者の報告

`/v1/messages` に対して `seed: 4242, min_p: 0.33, presence_penalty: 1.5` を送信した場合、修正前は `seed 4294967295, min_p 0.05, presence_penalty 0.0` になっていたが、修正後は `/v1/chat/completions` と同様に正しく伝播されるという報告がある Dgarc359。また、`id_slot` が伝播されないことで、Qwen3-Next クラスのハイブリッドモデルにおいて、間違ったスロットにリクエストが振り分けられ、99k トークンのセッションで単一のツール呼び出しに対して約 16 分間の再プリフィルが発生していた問題が、修正により解消されたという報告がある pcvelz。

Nemotron EmbedとQwen系列の最適化対応

前提

Nemotron Embed は NVIDIA が開発する埋め込みモデル。Qwen 系列は広範なアーキテクチャを持つ大規模言語モデル群。これらのモデルを llama.cpp で効率的に動かすには、対応する GGUF 変換と、アーキテクチャ固有の最適化が必要。

何が変わったか

NVIDIA の Nemotron-3-Embed および Nemotron-3.5-Embed モデルのサポートが追加された。Qwen モデルの出力リシェイプが 3D から 2D テンソルに変更され、互換性が向上し、メモリオーバーヘッドが削減される可能性がある。また、ssm_conv カーネルサイズ 7 のサポートが追加された。

なぜ重要か

新モデルの利用が可能になり、Qwen 系列モデルのメモリ効率が改善される。ssm_conv カーネルサイズ 7 のサポートにより、将来のモデルアーキテクチャへの対応が進む。

根拠のリンク

サーバーのトークンカウントとSSEイベント修正

前提

llama.cpp のサーバーは OpenAI 互換の API を提供し、ストリーミングには SSE (Server-Sent Events) を使用。`n > 1` のリクエストや、並列ツール呼び出しでは、トークンカウントやイベントの整合性が重要になる。

何が変わったか

`n > 1` の OpenAI リクエストにおいて、`completion_tokens` と `total_tokens` が過小評価されていた問題が修正された。すべての選択肢の `completion_tokens` を合計し、`total_tokens` を再計算するようになった。また、OpenAI Responses API のストリーミングイベントに `output_index` が追加され、並列ツール呼び出しにおいて、関数呼び出しの ID が正しく関連付けられるようになった。さらに、クライアントが接続を切断した場合、ルーターが子サーバーへのリクエストを完全に停止するよう修正された。

なぜ重要か

運用時のメトリクス正確性とクライアント連携のため。トークンカウントの誤りは課金や使用量監視に影響し、SSEイベントの整合性問題はクライアント側の処理エラーを引き起こす。また、接続切断時のリソース解放が改善され、サーバーの安定性が向上する。

根拠のリンク

利用者の報告

Qwen3.8 27B 上の llama-server でテストされ、並列ツール呼び出しのリクエストが正しく解析され、整列されたという報告がある Renzishi。また、ルーター経由で生成を開始し、クライアントを切断した場合、子スロットがアイドル状態になることを確認する回帰テストが追加され、ライブ HIP テストでは、アップストリームソケットが閉じてから約 0.4 秒後に子が停止し、スロットを解放したという報告がある Me42019。

出典

【宣伝】SwitchBot 購入はこちらから

SwitchBot公式ページ
クーポン「AF-4903」で5％引き（アフィリエイトクーポンになりますのでご協力お願いします）
割引の詳しい仕組みに関してはこちらのページを参照ください。