vLLMコミュニティ、NVFP4キャッシュのレイアウト上の問題を調査　インターリーブ保存でデータとスケール値が重なる可能性

vLLMコミュニティでは10月12日、NVFP4 KVキャッシュの異常が報告され、翌日には別の参加者が独立したカーネルテストを追加した。議論の焦点は、BLNHCのtoken-major物理レイアウトだ。K、V、量子化スケールデータをインターリーブして保存すると、書き込み側と読み取り側でバイト位置の解釈が異なる可能性がある。最初の報告によると、特定のQSAモデルのデプロイではトークンが返されるものの、回答の一貫性が失われるという。コミュニティの報告と再現

KVキャッシュの量子化は、推論中に注意状態を保持するためのメモリーコストを下げ、収容できるトークン数を増やすことを目的とする。この最適化では、数値データとスケール係数の対応関係を正しく保つ必要もある。vLLMのNVFP4ヘルパー関数のドキュメントでは、各K領域またはV領域内で、データとスケール値をそれぞれ連続してパックするよう定めている。呼び出し側は、統合キャッシュから先に両側を切り出す必要がある。そのため、テンソル形状が要件を満たしていても、物理ストレージのレイアウトに互換性があるとは限らない。量子化KVキャッシュのドキュメント、NVFP4 APIドキュメント

10月13日、ある参加者はRTX 5090上でモデルを読み込まずに、NVFP4の書き込み後に読み出すと誤差が生じることを再現した。また、問題は書き込み側のストライド計算だけにとどまらない可能性を指摘した。読み取りヘルパー関数が作成するデータビューとスケールビュー自体が、同じバイトを参照している可能性があるという。つまり、書き込み側だけを調整しても、インターリーブレイアウトを修正できるとは限らない。このテストは演算カーネルとストレージ契約に関する証拠を示すもので、モデルサービス全体の検証は行っていない。テストと制約

影響範囲には、まだ重要な疑問が残っている。参加者によると、関連するQSA NVFP4統合の提案はまだマージされておらず、メインブランチのQSA型リストにもNVFP4のサポートは宣言されていない。エンジニアはまず実際の統合経路を確認し、コンフィギュレーターが生成したレイアウトでテストデータを往復させるべきだ。今後は、メンテナーがサポート契約をどう定義するか、また初期化時に互換性のないレイアウトを拒否するかどうかが注目点となる。現時点の報告だけでは、すべてのNVFP4モデルで生成不具合が起きると一般化できない。サポート範囲に関する議論