vLLMコミュニティがSM120で推測デコードの異常を報告、GLMのドラフトトークン受理率がゼロに

vLLMコミュニティは10月2日、推測デコードの異常を報告した。8基のRTX PRO 6000、FP8版GLM-5.3-Flash、8-wayテンソル並列の構成で、当日のナイトリービルドはMTPドラフトトークンを継続的に生成したものの、受理率はゼロだった。報告されたテストの1回では、822個のドラフトが生成されたが、受理されたものは一つもなかった。デコード速度は毎秒約80トークンだった。問題報告

MTPはモデルのマルチトークン予測能力を利用して候補を提示し、検証処理で受理するトークンを決めることで、逐次デコードのコストを削減する。vLLMの公式ドキュメントでは、推測デコードはリクエスト量が中程度から少ない、メモリ帯域幅がボトルネックとなるワークロードで、トークン間レイテンシを下げる機能として位置づけられている。また、その効果はモデル、ハードウェア、トラフィック、サンプリング設定によって異なると説明している。そのため、サービスが正常にテキストを生成できているだけでは、加速経路が有効だとは確認できない。公式ドキュメント

報告者は、デフォルトのCUDA Graph、eager実行の強制、ドラフト数を3から1への削減をそれぞれ試したが、受理率は依然としてゼロだった。これらの結果で調査範囲は絞られたものの、実行モードやドラフト処理の影響を完全に排除するには至っていない。ログによると、システムは自動的にFLASHINFER_MLA_SPARSE_SM120を選択し、旧式のAttentionバックエンド用環境変数を未知の設定として扱っていた。報告者は、ドラフト推論経路に異常がある可能性を指摘している。テストとログ

同じハードウェアとモデルを使ったコミュニティ提供のイメージでは、バックポートされたSM90 Sparse MLA経路で、ドラフトの受理率は約60％、速度は毎秒163～190トークンと報告された。ただし、この比較ではvLLMのビルドとFlashInferのバージョンも同時に変更されている。そのため、速度差をSM120カーネルに直接帰属させることはできず、すべてのデプロイ環境で同程度の性能低下が起きるとも言えない。比較構成

ナイトリービルドを採用するエンジニアリングチームにとって、この事例は、アップグレードの受け入れ検証でドラフトの受理率、実際に使われているAttentionバックエンド、トークン間レイテンシを併せて確認し、推測デコードを無効にした場合の基準値も記録しておく必要性を示している。次の段階では、依存関係のバージョンを固定した状態で上流が問題を再現し、ドラフト出力と検証処理を確認したうえで、修正と正式リリースへの影響範囲を判断する必要がある。確認時点では、issueはオープンのままで、ページに関連する修正は記載されていない。