vLLMコミュニティ、再起動後の出力不一致を報告　カーネルの自動チューニングが再現性に影響する可能性

vLLMコミュニティは9月27日、乱数シードを固定して温度を0に設定しても、プロセスを再起動すると出力が変わる場合があると報告した。事例ではvLLM 0.30.0、PyTorch 2.13.0、Qwen3-8B、RTX 6000 Adaを使用。異なるカーネル構成が選ばれたプロセスでは、8組のプロンプトのうち3組で異なるトークン列が生成された。[問題報告](https://github.com/vllm-project/vllm/issues/58899)

報告者は、Q/K正規化とRotary Position Embedding（RoPE）を融合したTritonカーネルが原因だと指摘している。コンパイラは実測速度に基づき、リダクションブロックが64または128の構成を選択する。両者では加算順序が異なり、浮動小数点の最下位ビットの差が貪欲デコードの結果を変える可能性がある。候補となる構成を固定すると、それぞれに対応する出力を再現できた。また、`VLLM_BATCH_INVARIANT=1`を有効にしても、プロセス間の出力差が確認された。[再現手順](https://github.com/vllm-project/vllm/issues/58899)

公式ドキュメントはもともと、デフォルト設定での再現性を保証しておらず、オンラインサービングで一貫した結果を得る方法としてバッチ不変性を挙げている。ただし、同一のハードウェアとvLLMバージョンを使用することが前提となる。この事例が示すように、固定シードで制御できるのは乱数の供給源であり、基盤となる数値計算経路が異なる場合、サンプリングパラメーターを保存するだけでは信頼できる比較基準を確立できない。[再現性に関するドキュメント](https://docs.vllm.ai/en/latest/usage/reproducibility/)

関連する別の問題として、PyTorchではDynamoのトレース終了後にグローバル状態を復元する際、Inductorの決定論的設定まで上書きされる可能性がある。9月25日に提出された修正案は、基盤となるグローバルフラグを直接復元し、コンパイラ側の独立した設定を保持するものだ。提案にはCPUテンソルとeagerバックエンドを使った回帰テストが含まれており、状態復元の問題を切り分けやすくしている。ただし、GPUサービング環境での挙動は別途検証が必要だ。確認時点でこの提案はまだマージされておらず、前述のvLLM事例が解決済みと見なすことはできない。[修正提案](https://github.com/pytorch/pytorch/pull/198572)

バッチ不変性は現在もテスト段階にある。最新のドキュメントには、一部のCUDA構成では`torch.compile`を回避できることも記載されている。これは実際の実行経路が設定によって異なることを示しており、単一バージョンでの報告をすべてのデプロイ環境に当てはめることはできない。[機能の制限と実装](https://docs.vllm.ai/en/latest/features/batch_invariance/)

エンジニアリングの観点では、評価や回帰テストでプロセスの完全な再起動を対象にし、モデルのリビジョン、パッケージのバージョン、コンパイル設定を保存したうえで、トークン列と対数確率を比較する必要がある。調査では、単一プロセス内の安定性と、再起動をまたいだ一貫性を区別し、インフラの違いをプロンプトや重みの変更による影響と誤認しないことも重要だ。今後は、メンテナーによる確認、修正のマージ、ハードウェアをまたいだ再現性を追跡する必要がある。現時点の根拠は主に報告者の検証に限られており、広く発生しているか、モデル品質に影響するかを推定するには不十分だ。