LocalLLaMAが見たQwen 3.5 27Bの110万 tok/s、主役はB200よりvLLM tuning

設定を見直させるほど大きなthroughput数字

2026年3月26日、r/LocalLLaMAではGoogle Cloud communityの記事が共有された。内容は、Qwen 3.5 27BをvLLMでserveし、12 node、96基のNVIDIA B200 GPUで合計1,103,941 tokens per secondを達成したというものだ。Reddit反応はクロール時点で205 points、52 comments。headlineの数字も十分大きいが、さらに価値があるのは、この文章が結果を当然視せず、失敗経路とtuning過程をそのまま残している点だ。

著者によれば、モデル選定自体が意図的だった。Qwen 3.5 27BはMoE siblingではなくdense variantで、すべてのtokenで全parameterが有効になる。sparseな代替より加速は難しいが、heavy output workloadで品質を重視する運用者にはそのほうが意味がある。記事はさらに、このモデルのhybrid GDN plus grouped-query-attention構造、262K native context window、Apache 2.0 licenseにも触れている。

なぜserving strategyが結果を変えたのか

記事によると、最初の選択はnodeごとに8 GPUを束ねるtensor parallelismだった。しかしこれはおよそ9,500 tok/sから22,300 tok/s程度までしか伸びず、原因はsynchronization overheadだった。その後、各GPUが約29GBのモデル全体コピーを独立して持つdata parallelismへ切り替えると、throughputは即座に約74,848 tok/sへ跳ねた。そこからは多くのチームが軽視しがちなcontext-window tuningが効いてくる。最大長を131Kから数千tokenへ縮めることでKV-cache容量が解放され、性能がさらに上がった。

本当の突破点は、vLLM 0.18.0でFP8 KV cacheとMTP-1 speculative decodingを有効にした後に来た。記事の測定では、MTPを外すとthroughputは約3分の1落ち、GPU computeもほぼゼロへ戻る。一方、最適化されたsingle-node setupはmulti-node scaling前で約96,000 tok/sに達した。Reddit postはさらに二つの上位結果を加えている。8 nodeで約97.1%、12 nodeで96.5%のscaling efficiency、そしてKV-aware routing付きInference Gatewayを使うと、より単純なClusterIP round-robinより約35%のoverheadがあったという点だ。

なぜLocalLLaMAが注目したのか

この投稿が広がった理由は、派手なinfrastructure benchmarkを実運用playbookへ落とし込んだからだ。主な教訓はB200が速いという事実そのものではない。それは誰もが予想していた。より重要なのは、TPかDPか、speculative decoding、KV-cache dtype、実際のworkloadに合ったcontext sizeといったserving stackの判断が、raw accelerator specより重要になりうることだ。これはopen model deploymentにとって特に重要で、追加hardwareを買う前にinference configurationを直すべき場面があることを示している。

著者は自分がGoogle Cloudで働いていると明かしている。したがって数値は中立的baselineではなく、vendor-affiliated環境で最適化された結果として読むべきだ。それでもengineering detailは十分に具体的で、GitHub configへの導線もあるため、典型的なmarketing benchmarkよりはるかに再現可能性が高い。

原典: Google Cloud community write-up。コミュニティ議論: r/LocalLLaMA。