vLLMコミュニティ、CPUサンプリングの偏りを報告　固定乱数テーブルにより一部のトークンが選ばれない可能性

vLLMコミュニティは10月2日、CPU推論の正確性に関する報告を提出した。V1サンプラーが固定乱数テーブルを使用するため、生成結果がモデル出力の確率分布から逸脱する可能性があるという。報告にはコア層とエンジン層の再現コードが添付され、Linux x86_64とApple M1 Proでテストされている。現時点の証拠はメインブランチの特定コミットに基づくもので、すべての正式リリース版が影響を受けると断定することはできない。問題報告

報告者によると、fused_gumbel_argmaxは2²⁰個の要素を含む固定Gumbelテーブルから摂動値を取得する。呼び出しごとにシードで開始位置を決め、トークンのインデックスに沿って連続した値を使う。このため、語彙全体に割り当てられる乱数の組み合わせは、同じテーブル内の限られた範囲に制約される。報告者は、語彙数151,936、手動で設定したZipf分布のもとですべての範囲を列挙し、理論上は非ゼロの確率を持つトークンのうち79,078個が一度も勝者にならないことを確認した。これらのトークンが占める確率質量は、元の分布の約3.75%に相当する。テスト方法と結果

エンジン層のテストでは、ランダムな重みを持つ小型Llamaを使い、カスタムlogitsプロセッサで各ステップの分布を固定したうえで、単一トークンのリクエストを2万回送信した。V1では上記のトークンが選ばれなかった一方、Model Runner V2では768回選ばれ、理論上の期待値749回に近かった。これはサンプリングの挙動を切り分けるための人工的な実験であり、実際のモデルで語彙の半分が恒久的に使えなくなることや、生成品質が一定の幅で低下することを示すものではない。エンドツーエンド比較

公式設計ドキュメントは、2つの経路の違いを説明している。Model Runner V2はTriton Gumbelカーネルを使い、シードに基づいてカーネル内でステートレスな乱数を生成する。また、完全なsoftmaxを明示的に構築することも避ける。公式の設定コードではV2の利用にTritonが必須とされているため、デプロイ担当者はプラットフォームの対応状況と実際に使われる実行経路を確認する必要がある。V2への切り替えを汎用的な解決策とみなすことはできない。設計ドキュメント、設定の検証

エンジニアリングチームにとって、この報告は、サンプリングテストでは出力が自然かどうかだけでなく、実際の語彙規模と長い裾を持つ確率分布も対象にすべきだという示唆になる。報告者によると、既存のカイ二乗検定は語彙数を100に制限しており、このケースを捉えられなかった。今後は、大規模語彙での統計テストが上流に追加されるか、乱数生成方式がどう変更されるか、また各CPUプラットフォームで修正の正確性と性能がどうなるかを確認する必要がある。現時点では、影響範囲全体についてメンテナーの確認が待たれる。テストの盲点と修正の方向性