LocalLLaMA、K=64カーネル修正でBlackwellワークステーションのQwen3.5-397B推論改善を主張

コミュニティが追っていたボトルネック

2026年3月14日に r/LocalLLaMA に投稿された内容は、RTX PRO 6000のようなSM120 BlackwellワークステーションGPUで発生していた具体的な推論ボトルネックを扱っている。投稿者によれば、NVFP4系MoEモデル向けのblock-scaled GEMM経路は、このクラスのGPUでは有効なtile shapeが不足しており、結果として遅いfallback kernelへ落ちていた。つまりQwen3.5-397B-A17B-NVFP4のような大規模モデルが、本来のハードウェア性能を引き出せていなかったという話だ。

投稿でリンクされた FlashInfer PR #2786 は、解決策をかなり具体的に示している。SM120向けにK=64 tile shapeを追加し、K=64時に起きるscale-factor layout mismatchを修正することで、block-scaled MoE GEMMを成立させるというものだ。PR本文では、この修正によってRTX PRO 6000構成でsingle-user decode throughputがおよそ2倍になったと述べている。

数値の読み方

Reddit投稿は改善経路も公開している。WSL2で55 tok/s、native Linuxで119 tok/s、driverと設定最適化で142 tok/s、さらにcustom K=64 kernelで283 tok/sという流れだ。ただし投稿者は、この283 tok/sがshort promptかつthinking mode有効の条件で測定された値であり、Multi-Token Predictionが予測しやすい <think> token を多く受理するため高く見えると明示している。実運用に近い real prompt、thinking off 条件では、およそ130-136 tok/sが妥当だとしている。

つまり重要なのは、「ワークステーションBlackwellが突然すべてのdatacenter benchmarkに並んだ」という話ではなく、カーネル制約による損失をコミュニティ修正でかなり回復できる可能性が出たことだ。

なぜLocalLLaMAで刺さったのか

この話がLocalLLaMA向きなのは、単なる速さ自慢ではなく、shared memory制約、CUTLASS tile設計、upstream可能なパッチという実装レベルの説明が付いているからだ。PR本文も、99KB shared memoryのSM120 GPU向けにK=64 block-scaled MoE GEMM経路を開くことが核だと書いている。これが広く取り込まれれば、ローカルBlackwell環境でQwen3.5-397BやDeepSeek系MoEを回す人に直接効いてくる。

もちろん数値はself-reportedで、PRもまだopenだ。したがって現時点では確定結果というより有力な方向性と見るべきだ。それでも、local AIの性能が今やmodel weightだけでなく、kernel成熟度とsystem integrationに大きく左右されることを示す好例になっている。

原典: FlashInfer PR #2786、CUTLASS issue #3096。コミュニティ議論: r/LocalLLaMA.