【CUDA 16GB向け】llama.cpp MVQ→MMQ decode crossoverのランタイム調整、vLLM RMSNormカーネル1.2〜3.1倍高速化、35B A3B MoE GGUF登場 — 8月13日版
目次
この記事はAIによって編集・作成されています。
本日はllama.cppとvLLMのCUDA最適化改善が二本、そして16GB GPU向けの実機載せモデル候補が5本登場しました。llama.cppではバッチサイズ>1時のquantized decode crossoverポイント（mvq→MMQ）がランタイムパラメータで調整可能に。vLLMはRMSNormのuncontiguousパス導入でカーネル性能が最大3.1倍改善されました。モデル面ではQwen3.6 35B-A3B ApexやSarashina2 7B IT（Q4_K_M）など、16GB環境で実際に動かす価値のある候補が複数登録されています。
llama.cpp: CUDA MVQ→MMQ decode crossoverをランタイム調整可能に（PR#26079）
情報源: https://github.com/ggml-org/llama.cpp/pull/26079
llama.cppのCUDAバックエンドで、バッチサイズが2以上の時におけるquantized decodeの遷移ポイント（mvqモードからMMQモードへのcrossover point）が、ランタイムで調整可能になりました。従来はハードコードされた閾値でしたが、PR#26079でランタイムパラメータとして制御できるようになります。
これは特にバッチ推理時のデコードパス選択を状況に合わせて細かく調整できることを意味します。同じモデル・同じバッチサイズでも、GPUのメモリ帯域やシリアル処理の重みのバランスによって最適なパスは変わります。これをユーザー側で調整できるのは、RTX 3080/4080/5060 Ti等の16GBクラスのカードでバッチ推理を動かす場合に恩恵が大きいです。
実際に試せる設定例
# llama.cppビルド後のランタイムパラメータ（環境変数で指定）
export GGML_CUDA_MMVQ_MAX=64
# 使用例：バッチサイズを調整しながらcrossover閾値も同時探索
./main -m model.gguf -b 4 --crossover 64
※パラメータ名はPRマージ後の正式名称と異なる可能性があります。マージ後に公式ドキュメントで確認推奨。
llama.cpp: CUDA CEIL演算で非連続テンソルをサポート（PR#26072）
情報源: https://github.com/ggml-org/llama.cpp/pull/26072
llama.cppのCUDAバックエンドで、CEIL（天井値）演算の非連続テンソル対応が追加されました。これにより、特にattention patternの端っこのケースで、テンソルのメモリ配置が連続でない時にエラーになるような問題が解消されます。
これはモデル自体の精度向上ではなく、動作の安定性を改善する修正です。バッチ推理やattentionのマスクパターンが複雑な場合に、GPU側のカーネルエラーに遭遇していたケースが「動作する」ようになります。
vLLM: RMSNormのuncontiguous対応でカーネル性能1.2〜3.1倍改善（Issue#49750）
情報源: https://github.com/vllm-project/vllm/issues/49750
vLLMのRMSNorm演算でuncontiguousパスのサポートが追加され、カーネル性能が1.2〜3.1倍の改善が見られました。メモリ配置が連続でない場合でも効率的に処理できるようカーネルが最適化された形です。
この改善はモデル層の重み配置やバッチの形状に依存し、同じバッチサイズでもモデルアーキテクチャによって速度差が違ってきます。最大3.1倍という数字はカーネルレベルの改善であり、アプリケーション全体の速度がそのまま3.1倍になるわけではありませんが、特にRMSNormを使うアーキテクチャ（Gemma系など）では全体の推論速度にも効いてくるでしょう。
vLLM環境での確認コマンド
# vLLMのカーネルベンチマーク（uncontiguousパス有効化確認）
python -c "import vllm; print(vllm.__version__)"
# モデル推論（RMSNormを含むアーキテクチャで効果的）
python -m vllm.entrypoints.openai.api.serve --model model_name
vLLM: MoE weight scalesのTP共有（Issue#49764）
情報源: https://github.com/vllm-project/vllm/issues/49764
vLLMで、MoE（Mixture of Experts）モデルのweight scalesをTensor Parallelism（TP）間で共有するRFCが提起されました。TP（テンソル並列化）でモデルを分割して推論する場合、各ラウンドで個別にスケールを計算していました。これを共有することで計算オーバーヘッドを削減する方針です。
これはMoEモデルを複数GPUで動かす場合に特に有用な改善です。RTX 3080/4080のような16GBカードを複数枚使ってMoEモデルを動かす場合に恩恵があります。
16GB GPU向けモデル候補 — 5本のGGUFが新着
Qwen3.6 35B-A3B Apex（35B総パラメータ / 3Bアクティブ）— Myric
情報源: https://huggingface.co/Myric/Qwen3.6-35B-A3B-APEX-GGUF
Qwen3.6のMoEモデル。総パラメータ35Bだがアクティブは3Bのみ。APEX量子化により16GB VRAMに収まりやすい設計。バッチ推理や長いコンテキストでの推論に向く。
※16GBでの推論速度・コンテキスト長は実測待証。要検証。
Qwen3.5 35B-A3B Apex（35B総パラメータ / 3Bアクティブ）— Myric
情報源: https://huggingface.co/Myric/Qwen3.5-35B-A3B-APEX-GGUF
Qwen3.5のMoE版。総パラメータ35B / アクティブ3B。APEX量子化。前世代のQwen3.6 Apex版と比較して、アーキテクチャの違いによる速度差も確認する必要あり。要検証。
Sarashina2 7B IT（日本語指示付き）— RyoSpiralArchitect
情報源: https://huggingface.co/RyoSpiralArchitect/sarashina2-7b-it-GGUF
Sarashina2の7B日本語モデル。Q4_K_M量子化済み。7Bクラスは16GB GPUで余裕を持ちながらバッチ推理も可能なサイズ。日本語の指示追従・会話品質は実測で確認推奨。
# llama.cppでの推論例
./main -m sarashina2-7b-it-Q4_K_M.gguf -p "日本語で説明して：" -n 256 -c 4096 -b 4
Gemma-4 12B I-T QAT（量子化後微調整）— Mer0vin8ian
情報源: https://huggingface.co/Mer0vin8ian/gemma-4-12B-it-qat-GGUF
Gemma-4の12B指示付きモデル。QAT（Quantization-Aware Training）で量子化後微調整済み。12Bクラスは16GB GPUでQ4_K_MやQ8_0量子化時に余裕のあるサイズ。vLLMのRMSNorm高速化（1.2〜3.1倍改善）が効くアーキテクチャでもある。
Qwen3.5 4B MXFP8量子化 — michaelw9999
情報源: https://huggingface.co/michaelw9999/Qwen3.5-4B-MXFP8-GGUF
Qwen3.5の4Bモデル。MXFP8量子化。低リソース環境向けの小型モデルですが、16GB GPUなら非常に高い速度で動作するはずです。バッチサイズを大きく取れるサイズでもあります。
本日まとめ — 推奨アクション
1. vLLMの最新版をビルド・チェック — RMSNormカーネルの1.2〜3.1倍改善がGemma系モデルで効く。ベンチマークで速度差を確認。
2. Qwen3.6 35B-A3B Apexを試す — 3BアクティブのMoEは16GB GPUでバッチ推理も可能。コンテキスト長とデコード速度を実測。
3. Sarashina2 7B Q4_K_Mを日本語用途で評価 — 16GBの空きVRAMが大きいのでバッチサイズ4〜8で日本語応答品質を確認。
SwitchBot公式ページ
クーポン「AF-4903」で5％引き（アフィリエイトクーポンになりますのでご協力お願いします）
割引の詳しい仕組みに関してはこちらのページを参照ください。
製品ごとの特徴・紹介動画は SwitchBot 製品ガイド にまとめています。
その他おすすめリンク
【2026年8月】クーポン・ポイント情報 GMKtec MINISFORUM GEEKOM ACEMAGIC 公式サイト攻略法
当ページの商品リンクは基本アフィリエイト（SwitchBot、Amazon、楽天、アリエクスプレス他）となっております。ご協力いただければ幸いです。