山村商店

【CUDA 16GB向け】llama.cpp: DFlash/Qwen4Exp修正、サーバーSIGTERMハング解消、gpt-oss NaNバグ

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

目次
  1. 今回の要点
  2. DFlash/MTP推論のバグ修正とQwen4Exp対応
  3. llama-serverのSIGTERMハングとプロンプト復元バグ修正
  4. gpt-oss-120b CUDA NaN出力バグ修正
  5. Flint/Qwen2.5-32B等新モデルGGUFと16GB適合性
  6. 出典

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

今回の要点

  • DFlash/MTP推論の品質向上: Qwen4Expの推論品質修正とドラフター用入力スケールロードにより、推論精度が改善された。
  • サーバー終了時のハング解消: 量子化ドラフトキャッシュ使用時のSIGTERMハングと、キャッシュ復元失敗バグが修正された。
  • gpt-oss NaNバグ修正: 120bクラスのモデルで発生していたfp16オーバーフローによるNaN出力が修正された。
  • 16GB環境向け最適化: プロンプト共有機能やMoEオフロードの最適化により、VRAM節約と推論速度向上が期待できる。

DFlash/MTP推論のバグ修正とQwen4Exp対応

DFlashとMTP（Multi-Token Prediction）は、ドラフトモデルを用いて推論速度を向上させる技術である。今回の修正では、Qwen4ExpモデルにおけるAttention計算の正確性と、ドラフターの生成品質向上が図られた。

具体的には、Qwen4ExpモデルのQSA（Query-Softmax Attention）セレクションで不要だった kq_mask の処理が外され、Attention計算の正確性が確保された（PR #30965）。また、DFlashドラフターが optional fully-connected input scale をロード可能になり、Flash Attentionのドラフト生成品質が向上した（PR #30945）。これにより、Qwen4Expモデルにおける推論品質と安定性が改善された。

これらの修正は、DFlashやMTPを使用するユーザー、特にQwen4Expモデルを16GB GPUで動かすユーザーにとって、推論の信頼性向上に直結する。また、DeepSeek-V4.1-Flashなどにおけるプロンプトプレフィックス再利用時の出力破損（Issue #30944）や、Qwen3.8-Flash-Nextにおけるクラッシュ（Issue #30887）といった既知の問題も関連する修正対象である。

利用者の報告

V100とP100を混載した環境で、修正版とメインライン版のベンチマークが報告されている。FatheredPuma81は、V100 + P100（それぞれ32GB/16GB）構成で、MTP有効時のトークン生成速度に低下が見られたと報告している（GitHub Issue #6）。一方、qr0nは、この結果から混合カードパスはクリアされており、V100自体の処理にギャップがあると分析している（GitHub Issue #6 comment）。

llama-serverのSIGTERMハングとプロンプト復元バグ修正

llama-server は、llama.cpp の HTTP サーバー機能である。今回の修正では、サーバー終了時の挙動と、キャッシュされたプロンプトの復元に関するバグが解消された。

量子化ドラフトキャッシュを使用する環境で、SIGTERM（kill -TERM）送信時にサーバーがハングし、VRAMが解放されない問題が報告されていた（Issue #30975）。これは、speculative decoding 有効時の CUDA 環境で再現し、2回目のシグナルで強制終了されていた。また、unified KV cache 環境において、アイドルスロットのクリア前にキャッシュされたプロンプトを復元しようとして失敗し、プロンプトが破棄されるバグも修正された（Issue #30961）。

これらの修正は、16GB RTX 環境で speculative decoding を利用するユーザーや、複数のセッションを管理するユーザーにとって、サーバーの安定性向上に寄与する。特に、バックグラウンドジョブとエージェントが同じモデルを共有する環境では、プロンプトの再処理による遅延（114-150秒）が解消される。

利用者の報告

belo-labs は、27B IQ4_XS モデルを 40,960 コンテキストで実行中に、SIGTERM ハングを再現したと報告している（GitHub Issue #30975）。また、Guramannen は、unified KV cache 環境でプロンプト復元失敗により、エージェントのターンごとにフルコンテキストの再処理が発生し、114-150秒の遅延が生じていたと報告している（GitHub Issue #30961）。

gpt-oss-120b CUDA NaN出力バグ修正

gpt-oss-120b は、120Bパラメータの大規模モデルである。今回の修正では、CUDA 環境での fp16 オーバーフローによる NaN 出力バグが解消された。

gpt-oss-120b（MXFP4 experts）において、プロンプトバッチサイズが 8 を超える場合、fp16 蓄積と dequantize + cuBLAS フォールバックのオーバーフローにより、NaN（「GGGG」）が出力される問題が報告されていた（Issue #30951）。また、Q4_1/Q5_1 量子化モデルでも、block offset と Q8_1 block sum の乗算で fp16 オーバーフローが発生し、同様の NaN 出力が生じていた（Issue #30950）。

この修正は、H100 2台環境で再現・検証されたが、fp16 オーバーフローは Ampere/Hopper アーキテクチャ全般に影響する可能性がある。Cross2pro は、fp32 スケール積を適用する修正計画を報告している（GitHub Issue #30950 comment）。

利用者の報告

denizyuret は、H100 2台環境で、IQ1_M 量子化モデルにおいてバッチサイズ 8 超で NaN 出力を再現したと報告している（GitHub Issue #30951）。

Flint/Qwen2.5-32B等新モデルGGUFと16GB適合性

16GB RTX 環境で動作可能な新モデルの GGUF が多数リリースされている。Flint モデルのサポートが追加され（PR #30928）、RecursiveSI_flint の IQ2_M（13.9GB）や IQ2_S（12.5GB）は 16GB RTX で動作可能である（Hugging Face: bartowski/RecursiveSI_flint-GGUF）。

また、wesjos_mario-html-v2-9B（Q4_K_M: 5.7GB）や Spark-X2.6-4B（Q4_K_M: 2.5GB）など、小規模モデルも 16GB RTX で余裕を持って動作する（Hugging Face: wesjos_mario-html-v2-9B-GGUF、Hugging Face: Spark-X2.6-4B-GGUF）。Qwen2.5-32B-YOYO-reasoning-v3 の Q3_K_M（15.2GB）も、16GB にぎりぎり適合する（Hugging Face: Qwen2.5-32B-YOYO-reasoning-v3-GGUF）。

出典

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

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