山村商店

【CUDA 16GB向け】llama.cppの最新修正：16GB GPU向けMMQ最適化、VRAM節約、MTPバグ回避

目次
  1. 今回の要点
  2. CUDA MMQ量子化最適化とMoEメモリ管理の改善
  3. VRAM管理改善とプレフィル高速化・バグ修正
  4. Blackwell/RTX 5090向けバグ修正と最適化
  5. MTP/スペキュレーション推論の既知バグと対策
  6. 16GB環境向け新GGUFモデルの追加
  7. 出典

この記事はAIによって編集・作成されています。

llama.cppは、ggml-orgがC/C++で開発するLLM推論エンジン。GGUF形式の量子化モデルをCPUやGPUで動作させる。今回の更新では、16GB VRAMのGPUユーザーにとって特に重要な最適化とバグ修正が含まれている。

今回の要点

  • MMQ量子化最適化：Q2_K/Q8_1の高速化とMoEメモリ管理の改善で、16GB環境での推論コスト低減が期待される。
  • VRAM管理とEmbedding高速化：不要なメモリ確保の回避やEmbeddingモデルのCUDA高速化により、実用性が向上。
  • 次世代GPU対応：RTX 5090 (Blackwell) での動作安定化と、vLLM/SGLangの最適化。
  • MTP/スペキュレーション推論の注意点：Qwen3.8でのメモリリークや生成バグが報告されており、運用時の注意が必要。
  • 新モデル追加：16GB GPUで余裕を持って動作するZime AI Dwight 4BやQwen3.5 9B/4BのGGUFモデルが公開。

CUDA MMQ量子化最適化とMoEメモリ管理の改善

前提

MMQ (Multi-Query Quantization) は、量子化された行列積を高速化するための手法。MoE (Mixture of Experts) は、モデルの重みを複数の「専門家」に分け、入力に応じて必要な部分のみをGPUにロードするアーキテクチャ。

何が変わったか

今回の更新では、CUDA環境におけるMMQ量子化の最適化と、MoEモデルのメモリ管理が強化された。具体的には、int2 (Q2_K量子化) のMMQ積算がベクトル化され、GLU活性化関数のMMQ (Q8_1) 量子化に対応した。これにより、16GB GPUでのMMQ Q2_K推論速度の改善や、Q8_1 GLUによるメモリ削減が期待される。また、MoEモデルにおけるduplicate expert IDsの修正や、CPU-resident MOE重みのpinned memory確保上限を4GBに制限する修正が行われた。これにより、Windows環境でのOOMエラー対策や、16GBカードにおけるMOEエクスパートのストリーミング効率向上が図られた。さらに、スペキュレーション推論のための`llama-fit-params`が引数を受け付けるようになり、DSV4 graph MTPにおけるトークンアサートのバグ修正も含まれている。

なぜ重要か

16GB GPUユーザーにとって、MoEモデルはVRAM不足で動作が困難なケースが多い。今回の修正により、エクスパートのストリーミング効率が向上し、メモリ圧力が軽減される。また、MMQ量子化の最適化は、量子化モデルの推論速度向上に直結する。

根拠のリンク

利用者の報告

janhq/jan#9163 において、jamesdam は、Jan v0.8.5-rc3 (llama.cpp engine 0.5.0) で、ビルド時にCUDA Graphsが無効化されているため、NVIDIA GPU上でのトークン生成速度が0.8.4比で約4倍遅くなっていると報告している。これはWindows x64、Linux x64、Windows arm64のCUDAバンドルに影響する重大なバグとされている。原因は、`build_ggml()` がラッパープロジェクトを通じてggmlを構成し、llama.cppのトップレベル`CMakeLists.txt`をスキップしているため、ggmlのデフォルト設定が有効化されていないことにある。

MattWolfgang は、MoEエクスパートのストリーミングに関する興味深い動きとして、Janas (pure-C, GPL engine) がNVMeドライブから直接エクスパートをストリーミングし、32GB RAMのIntelラップトップでQwen3-Next-80B (48GBモデル) を24 tok/s (draftありで37 tok/s) で動作させたと報告している。一方、llama.cppはGPU使用時にOOMで失敗し、CPUのみで2.8 tok/sであった。ただし、これは実験的な実装であり、discrete GPUでのテストは行われていない。

ak12kpoot は、公式の測定詳細を補足し、NVMe上の重みに対してO_DIRECT+io_uringでエクスパートを按需にロードし、熱エクスパートキャッシュ約19GBで、draftなしで24 tok/s、MTP draftで37 tok/s、1024トークンのプロンプト読み込みで62 (llama.cppは16) と報告している。llama.cppは通常GPUを開くとOOMするため、`GGML_CPU_REPACK=OFF` と `–no-host 1 -lm mmap` を使用する必要がある。GPL-3.0で、作者は「実験的」としており、Linux x86-64のみでAPIが頻繁に変更されると警告している。

VRAM管理改善とプレフィル高速化・バグ修正

前提

VRAM管理は、16GB GPUのような限られたメモリ環境では、モデルのロードや推論時のメモリ確保効率を左右する。Embeddingモデルは、テキストの埋め込み表現を生成するモデルで、RAG (Retrieval-Augmented Generation) などで利用される。

何が変わったか

llama.cppでは、外部範囲をバックエンドバッファにマップしない修正や、不要な時にdraft contextを保存しない修正が行われた。また、causal maskレイアウトでのk-pool選択の構築により、KVプールが最適化された。さらに、attentionにKVキャッシュを使用しないEmbedding/encoderモデルにおいて、K/V次元を256の倍数にパディングする修正が行われた。これにより、CUDA flash attentionカーネルでの silent CPU fallback が修正され、EmbeddingGemma 2 (head size 512) などで3841トークンの処理時間が363msから58msに短縮された。また、`llama-fit-params` が spec-decoding パラメータを受け付けるようになり、スペキュレーション推論時のメモリ推定が正確になった。

なぜ重要か

Embeddingモデルの高速化は、RAGアプリケーションのレスポンス時間改善に直結する。また、VRAM管理の改善は、16GB GPUで複数のモデルや長いコンテキストを扱う際の安定性向上に寄与する。

根拠のリンク

利用者の報告

janhq/jan#9163 において、jamesdam は、前述のCUDA Graphs無効化による速度低下を報告している。これはv0.8.5のリリースブロッカーと位置づけられている。

EamonMcKiernan5 は、新しいランタイム「SonicBoom」について報告している。これはネイティブC++/CUDAで、Pythonなし。RTX 3050搭載ラップトップで、Gemma 4 E4B Q3_K_M (同じGGUF) を使用し、51.7 tok/s (llama.cppは45.2 tok/s) を達成した。これは、fused opsやactivationsの量子化再利用、1ステップあたりの1つのCUDA Graphによる14%の改善。ただし、v0.0.1ではprefillはllama.cppの半分、モデルは1つ、greedyのみという制約がある。

Blackwell/RTX 5090向けバグ修正と最適化

前提

Blackwellアーキテクチャ (RTX 5090等) は、NVIDIAの最新GPU。llama.cppやvLLM、SGLangなどの推論エンジンでの動作安定化と性能最適化が進められている。

何が変わったか

llama.cppでは、RTX 5090でcohere2moeモデルのMUL_MAT時にillegal memory accessが発生するバグが報告されている (FA offは動作)。vLLMでは、Flash Attention 4 sparse MQA decodeがBlackwell (Hopper/Blackwell) で有効化された。また、8-bit量子化における要素ごとの除算を逆数乗算に置き換えるパフォーマンス最適化や、DeepGEMM MegaMoEカーネルのウォームアップにより、最初のリクエストレイテンシが削減された。SGLangでは、pi05 modeloptのためのFP8 CUDAテストや、NVIDIA Hopper/BlackwellアーキテクチャにおけるNVFP4形式の圧縮テンソルの修正が行われた。

なぜ重要か

RTX 5090などの最新GPUを使用するユーザーにとって、動作の安定性と性能の最大化は重要。特にMoEモデルやFP8推論の利用が増える中で、これらの修正は必須。

根拠のリンク

利用者の報告

janhq/jan#9163 において、jamesdam は、CUDA Graphs無効化による速度低下を報告している。これはRTX 5090を含むNVIDIA GPUに影響する。

niklaslenz_ai は、RTX 5090上でStrataとllama.cppを比較し、Qwen3.8-Flash-Nextモデル (32GBに収まらないため一部がシステムRAM) で、Strataは28.8秒 (204 tok/s)、llama.cppは104.2秒 (68 tok/s) で完了したと報告している。両方とも15の品質チェックをパスしたが、Strataは2回目に同じ質問をしてもほぼ同じテキストが返ってこず (27回中1回一致)、llama.cppは27回中27回一致した。これは、Strataが実験的な実装であることを示唆している。

MTP/スペキュレーション推論の既知バグと対策

前提

MTP (Multi-Token Prediction) は、複数のトークンを同時に予測するスペキュレーション推論の一種。Qwen3.6/3.8などのモデルで利用されるが、メモリ使用量や生成品質に課題がある。

何が変わったか

Qwen3.8 27BでMTP (`–spec-type draft-mtp`) を使用すると、コンテキストチェックポイントがトークンごとに4 KiBずつ成長し、262kコンテキストで32チェックポイント使用時に37 GiBのホストRAMを必要とするというバグが報告された。また、Qwen3.6でツール呼び出しがコンテンツに漏れ出す問題や、Qwen3.6 27BでMTP使用時に長いセッション後に `////` が繰り返される問題、MTP有効時にpresence_penalty > 0でスループットが大幅に低下する問題が報告されている。さらに、`ggml_mul_mat_id` がduplicate IDsをサポートしていないことが明記され、関連テストが無効化された。

なぜ重要か

16GB GPUユーザーがMTPを活用する場合、メモリ不足や生成品質の低下に直面する可能性がある。これらのバグを認識し、適切な設定や回避策を講じる必要がある。

根拠のリンク

利用者の報告

ggml-org/llama.cpp#30502 において、sanmai は、RTX 5090、Qwen3.8 27B Q6_K、Linux環境で、MTP有効時にコンテキストチェックポイントがトークンごとに4 KiB成長し、262kコンテキストで32チェックポイント使用時に37 GiBのホストRAMを必要ると報告している。これは、16GB GPUユーザーにとって深刻なメモリ不足の原因となる。

ggml-org/llama.cpp#30501 において、ggerganov は、`ggml_mul_mat_id` がduplicate IDsをサポートしていないことを明記し、関連テストを無効化したと報告している。

janhq/jan#9163 において、jamesdam は、CUDA Graphs無効化による速度低下を報告している。

ggml-org/llama.cpp#30407 において、alosslessdev は、Intel oneapi toolkitがSYCL依存をすべて含むことを明記したと報告している。

16GB環境向け新GGUFモデルの追加

前提

GGUF形式は、llama.cppで利用されるモデルファイル形式。量子化されたモデルは、VRAMの少ないGPUでも動作可能。

何が変わったか

bartowskiがZime AI Dwight 4BのGGUF変換を公開。oscarwest1がQwen3.5 9B Q6_KのGGUFを公開。GrizzillaAIがQwen3.5 4B Q4_K_MのGGUFを公開。

なぜ重要か

4Bモデルは16GB GPUで余裕を持って動作し、長いコンテキストも可能。9B Q6_Kは約6-7GBで、16GB GPUに余裕がある。4B Q4_K_Mは3GB未満で、約13GBをKVキャッシュに使用可能。

根拠のリンク

出典

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

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