【CUDA 16GB向け】RTX 5090の長文推論遅延修正と、16GB GPUでの超大規模MoE推論実測
目次
今回の要点
- バグ修正: RTX 5090等におけるCUDA Flash Attentionの長文prefill遅延（最大40%）が修正された。また、Vulkan環境での文字化けやMTP（多トークン予測）の動作不良も報告されている。
- 16GB GPUでの超大規模推論: Qwen3.8-Flash-Next (125B) が、RTX 5060 Ti 16GB 1枚や、RTX 5070 12GB + 5060 Ti 16GB の2枚構成で動作し、実用的な速度（50-100 tok/s）で推論可能であることが実測されている。
- MoE最適化: llama.cppにおいてMoE推論のキャッシュ機構がSLRU方式に変更され、VRAM不足解消のためのホストRAM expert配置や、推論エンジン（Unsloth等）のメモリ削減技術が強化された。
- 推論エンジンの動向: vLLM 0.32.0でNVFP4 KVキャッシュ対応、SGLang v0.5.21でCUDA 13対応とMTPサポートが強化された。
CUDA/Vulkan/HEXAGONの主要バグ修正とレジション対応
前提
llama.cppは、GGUF形式の量子化モデルをCPUやGPUで高速に推論するためのC/C++エンジンである。CUDAやVulkanなどのバックエンドを通じて、ユーザーのハードウェア環境に合わせた推論が可能だが、新バージョンやハードウェアの登場に伴い、特定の条件下で不具合が発生することがある。
何が変わったか
今回の更新・修正では、主に以下の不具合が対象となっている。
| 不具合内容 | 影響環境 | 修正状況 |
|---|---|---|
| CUDA FA stream-kブロック数不整合 | RTX 5090 (170 SMs) | 修正により速度回復 |
| Vulkan RADV転送キュー文字化け | AMD GPU (Vulkan) | 報告中 |
| MTP (多トークン予測) 動作不良 | SYCL / Intel Arc | 報告中 |
| OpenAI APIツール呼び出しの終了通知欠落 | /v1/responses エンドポイント | 報告中 |
特に重要なのは、RTX 5090におけるFlash Attention (FA) パスの遅延問題だ。長文コンテキスト（65K〜131Kトークン）でのprefill処理が、RTX 4090と比較して10〜13%遅くなる現象が発生していた。修正後は、この遅延が解消され、RTX 4090と比較して約37〜40%の高速化が確認されている。
なぜ重要か
16GBクラスのGPUユーザーにとって、長文コンテキストの処理速度は実用性を左右する。また、RTX 5090のような高性能GPUを使用している場合、ソフトウェア側の不具合により本来の性能が発揮されない可能性がある。今回の修正により、長文処理における推論速度の安定性が確保された。
根拠のリンク
- llama.cpp #30784: CUDA FA stream-k block count not a multiple of ntiles_dst on RTX 5090
- llama.cpp #30782: MTP working broken after update
- llama.cpp #30768: Vulkan RADV slash spam
利用者の報告
RTX 5090における長文prefillの遅延と修正効果 ユーザー @Nebiforever による報告では、RTX 5090 (170 SMs) において、CUDA 13.4.59、ドライバー 595.91.07、llama.cpp b11674 の環境で、Qwen3.5-9B-Q4_K_Mモデルを用いた長文prefill（-d 65536/131072）がRTX 4090より遅いという現象が確認された。 原因は、MMAカーネル（ncols=64, nbatch_fa=32）の実行ブロック数が、stream-kアルゴリズムにおいてRTX 5090のSM数（170）に対して割り切れない値（340ブロック）になっていたことにある。これにより、RTX 4090（128 SMs, 256ブロック）と比較して効率的に処理できなかった。修正後は、この不整合が解消され、短文コンテキストやトークン生成時と同様に、RTX 5090がRTX 4090に対して約20%高速なパフォーマンスを発揮するようになった。 MTP (Multi-Token Prediction) の動作不良 ユーザー @shansen008 は、Ryzen 9 5900XT / Intel Arc Pro B70、SYCLバックエンドの環境で、最新リリースへの更新後、MTP（多トークン予測）が機能しなくなったと報告している。Qwen3.8-27B-UD-Q4_K_XLモデルとmtp-Qwen3.8-27B-Q4_0ドラフトモデルを使用しているが、トークン生成速度が10 tok/s程度に低下し、思考ボックスがガビッジを出力する無限ループに陥る現象が発生した。
Qwen3.8-Flash-Next (125B) の16GB GPU実測と最適化技術
前提
Qwen3.8-Flash-Nextは、125Bパラメータ（アクティブ51B）のMoE（Mixture of Experts）モデルである。通常、このような超大規模モデルは複数のGPUや大量のVRAMを必要とするが、量子化技術や推論エンジンの最適化により、16GBクラスのGPUでも動作可能となってきた。
何が変わったか
コミュニティによる実測では、16GB VRAMのGPU単体、あるいは16GBを含む複数GPU構成で、Qwen3.8-Flash-Nextが実用的な速度で動作している。
| 環境 | 推論エンジン | 量子化 | 速度 (tok/s) |
|---|---|---|---|
| RTX 5060 Ti 16GB (1枚) | Strata | Q3 | 52 |
| RTX 5070 12GB + 5060 Ti 16GB (2枚) | Strata v0.1.45 | IQ3_S | 50-64 (decode) |
| RTX 4090 (1枚) | llama.cpp (UD) | IQ3_XXS | 86.5 (decode) |
| RTX 4090 (1枚) | vLLM | FP4 | 174.8 |
なぜ重要か
16GB GPUを持つユーザーにとって、MoEモデルは「VRAM不足で動かない」というイメージが強かった。しかし、Qwen3.8-Flash-Nextのようなモデルが、単一の16GB GPUや、16GBを含む混合構成で動作することは、ローカルLLMの利用範囲を大幅に広げる。特に、StrataなどのエンジンがNVIDIAとAMDの混合GPU構成をサポートしたことで、既存のGPUを有効活用した推論環境の構築が可能になった。
根拠のリンク
利用者の報告
RTX 5060 Ti 16GB 単体での動作 ユーザー @Indy_triguy は、RTX 5060 Ti 16GB、DDR4 64GBの環境で、Qwen3.8 Flash Next (Q3量子化) を動作させ、52 tok/s の推論速度を記録した。また、Qwen3.8 27BをSpark環境で併用し、複数エージェントによる256Kコンテキストセッションと、Flash Nextを批評役として使用するハイブリッドな運用も可能であると報告している。 RTX 5070 12GB + 5060 Ti 16GB 混合構成での動作 ユーザー @murasametech は、RTX 5070 12GB と RTX 5060 Ti 16GB の2枚構成（VRAM合計28GB）、RAM 64GB（WSL2に56GB）で、Strata v0.1.45 を使用して Qwen3.8-Flash-Next GSQ-RCO IQ3_S (約84GB) を動作させた。GPUに収まらないモデル部分はRAMとSSDに配置している。実測では、Decodeが約50〜64 tok/s、1.4万トークン入力のPrefillが417〜440 tok/s となった。文章が流れていく速度は実用的であり、待たされる感じはないと評価している。 RTX 4090 における高速推論 ユーザー @PotatoLordsLab は、Dell C4130 (3× V100 16GB + 1× Tesla M10) という複数GPU構成で、Qwen3.8-Flash-Next (NVIDIA FP4) をテストし、MTPドラフト有効時に102.4 tok/s、最良のチャット応答で112.7 tok/s、262Kコンテキストで55.1 tok/s を記録した。
MoE推論の高速化：SLRUキャッシュとホストRAM expert配置
前提
MoE（Mixture of Experts）モデルは、入力に応じて複数の「専門家（Expert）」パラメータを動的に選択して推論を行う。この際、頻繁にアクセスされるExpertを高速に保持するキャッシュ機構が重要となる。また、VRAMが不足する場合、ExpertをホストRAM（CPUメモリ）に配置し、GPUとの間でデータ転送を行う手法も検討されている。
何が変わったか
llama.cppにおいて、MoE用の単純なLRU（Least Recently Used）キャッシュが、50/50に分割されたSLRU（Second Chance LRU）キャッシュに置き換えられた。これは、ガーベジコレクションの世代別GCに似た仕組みで、安定した「古い」セットと、変動の大きい「若い」セットを分離することで、単純LRUと比較して1〜5%の性能向上を実現した。 また、ホストRAMにExpertを配置するパイプライン並列化のプルリクエスト（#29963）や、512 ExpertのMTPドナーを256 Expertのアーキテクチャに適応するツール（#30770）も開発されている。
なぜ重要か
16GB GPUユーザーがMoEモデルを扱う際、キャッシュの効率は推論速度に直結する。SLRUキャッシュへの移行により、同じVRAM環境でもより安定した高速推論が可能になる。また、ホストRAMを活用する技術の進展は、VRAM不足による推論失敗を回避する手段として注目される。
根拠のリンク
- llama.cpp #30637: Replace MoE LRU cache with a 50/50 SLRU cache
- ggml : pipeline parallelism with MoE experts in host RAM
vLLM/SGLangのNVFP4対応と最新リリース
前提
vLLMとSGLangは、大規模言語モデルの推論を高速化するための主要な推論エンジンである。NVFP4（NVIDIA FP4）は、4ビット浮動小数点量子化の一種で、メモリ使用量を大幅に削減しつつ、推論速度の向上を目指す技術。
何が変わったか
vLLM 0.32.0（2026年10月17日リリース）では、NVFP4 KVキャッシュが正式にサポートされた。これにより、注意機構のヘッドテンソルを4ビットFP精度で保存し、FP8と比較してKVメモリを約4倍削減。A100環境では約3.75倍長いシーケンスを処理可能となった。また、Model Runner V2の導入により、MoE、ハイブリッド注意機構、MTP、マルチ入力などを統一してサポートするようになった。 SGLang v0.5.21では、CUDA 13とTorch 2.11をベースとし、Qwen3.6 NVFP4やQwen3.8-Flash-Nextなどの新モデルサポート、およびMTP（Multi-Token Prediction）対応が強化された。
なぜ重要か
16GB GPUユーザーにとって、VRAMの効率的な使用は必須である。NVFP4 KVキャッシュの導入により、より長いコンテキストやバッチサイズでの推論が可能になる。また、vLLMとSGLangの両方でMTPサポートが強化されたことで、推論速度のさらなる向上が期待できる。
根拠のリンク
Unslothのメモリ削減技術とStudio新機能
前提
Unslothは、ファインチューニングと推論を高速化するためのライブラリ。特に、VRAM使用量の削減と推論速度の向上に注力しており、16GB GPUでの大規模モデル操作を可能にする技術を提供している。
何が変わったか
Unsloth v2026.10.6（2026年10月15日リリース）では、NVIDIA Nemotron 3.5 Boltが24GBメモリで動作可能となった。また、Meta Muse Spark Open (816B) が256GBメモリで動作するよう最適化された。 LoRAトレーニングにおいては、NVFP4、INT4、MXFP4のチェックポイントに対して、元のパックされた重みから直接トレーニングを行うことで、VRAM使用量を削減しつつ精度を保持する技術が導入された。例えば、Qwen3.8-27B-NVFP4の場合、ピークメモリ使用量が72.9 GBから40.2 GBに約44%削減された。 Unsloth Studioでは、llama.cpp RPCプロトコルを使用したGGUFモデルの分散推論（PR#13726）や、REAP Expert Pruning（PR#14130）などの新機能が追加された。
なぜ重要か
16GB GPUユーザーにとって、LoRAトレーニング時のVRAM不足は大きな障壁であった。パックされた重みからの直接トレーニングにより、より大きなモデルや複雑なファインチューニングが、消費メモリを抑えて実行可能になる。また、分散推論機能により、複数マシンを活用した大規模モデルの推論環境構築が容易になる。
根拠のリンク
出典
SwitchBot公式ページ
クーポン「AF-4903」で5％引き（アフィリエイトクーポンになりますのでご協力お願いします）
割引の詳しい仕組みに関してはこちらのページを参照ください。