vLLMコミュニティがMoE LoRAバックエンドの修正を提案、BlackwellではTritonを指定しても起動に失敗する可能性

vLLMコミュニティは10月12日、量子化されていないMoE LoRAのバックエンド選択に関する不具合を報告した。特定条件下のBlackwell GPUでは、--moe-backend tritonを指定しても、システムがFlashInferのTRT-LLM経路を選ぶ場合がある。さらに--fully-sharded-lorasを有効にすると、サービス起動時の解析段階でアサーションが発生する。報告環境はv0.31.0、SM103 GPU、CUDA 13、BF16のQwen3.5-35B-A3Bで、報告者は開発ブランチにも同じロジックがあると指摘した。不具合報告

報告では、バックエンド選択関数が原因として挙げられている。LoRAの分岐では、ユーザー指定のバックエンドを先に処理せず、TRT-LLMのサポート条件を先に確認していた。選択された実装はadd_inputs=Falseを指定してLoRA演算を呼び出すが、下位のカーネルはこの引数と全シャーディングモードの併用をサポートしていない。そのため、Tritonオプションを追加するだけではエラーを回避できない。報告者によると、選択条件を局所的に変更すると、同じコマンドで起動してサービスを提供できた。再現手順とコード経路

この問題は、デプロイ設定が実際に反映されるかどうかに関わる。公式ドキュメントでは、--moe-backendはMoEエキスパート演算カーネルを選択するためのインターフェースと定義されている。全シャーディングLoRAでは、LoRA計算全体をテンソル並列構成に沿ってシャーディングする。ドキュメントによれば、長いシーケンス、高いランク、大規模な並列構成で効果が見込まれる。これを踏まえると、エンジニアリングチームは性能パラメーターを調整する際、起動ログで実際に使われたバックエンドも確認する必要がある。エンジン引数のドキュメント

10月13日に提出されたPR #61301は、明示的に指定されたTritonを優先し、全シャーディング設定をMoEの互換性チェックに渡す変更を提案している。自動選択時にはTritonへフォールバックできる一方、互換性のないTRT-LLMの組み合わせを明示的に要求した場合は、設定エラーを早期に発生させる。作者は3件のユニットテストが通過したと記載しているが、テスト記録ではCPUホスト上でCUDA／ROCmのマーカーにより2件がスキップされている。したがって、完全なGPU検証が済んだとはいえない。修正提案

確認時点で、この提案は未オープンのままではなくオープン状態で、マージコンフリクトの解消が必要と表示されている。今後は、メンテナーのレビュー、Blackwell実機でのテスト、正式リリースへの取り込み状況を追う必要がある。現時点の証拠から、すべてのMoE LoRAデプロイで失敗すると推定することはできない。提案の状況