Transformers、生成モデルのエクスポートを再設計し、プリフィルとデコードで計算グラフを共用

Hugging Face TransformersのプロジェクトメンバーであるIlyasMoutawwakilは11月2日、生成モデルのエクスポートを再設計する提案を提出しました。プロンプトのプリフィルと、その後の逐次デコードを同じデコード計算グラフで処理する構成です。この設計は、実行側が読み込むグラフや接続コードを減らし、2つの段階で同じ重みをそれぞれエクスポートするのを避けることを目指しています。確認時点で、提案はまだマージされていません。提案の内容

具体的な違いは入力形状にあります。動的エクスポートのグラフは、プロンプト全体を一度に受け取った後、新しいトークンを1つずつ処理できます。一方、静的エクスポートではクエリ軸が単一トークンに固定されるため、プロンプトも1トークンずつ入力する必要があります。したがって、計算グラフを共用しても、あらゆるデプロイ方式でプリフィルを一度に実行できるわけではありません。モデルが独立したプリフィル用グラフを必要とする場合、この方式は重みをもう1組出力するのではなく、明示的にエラーを返します。設計と制約

こうした変更は、デプロイ時の成果物に直結します。Optimum Intelの公式ドキュメントによると、OpenVINOのエクスポートでは、トポロジーを記述するXMLと重みを格納するBINが生成されます。また、デフォルトのステートフルモデルではKVキャッシュがモデル内部に隠されます。このことから、グラフの分割方法やキャッシュの境界は、実行側でモデルをどう読み込み、呼び出し、管理するかに影響します。ファイルを正常に変換できたかどうかだけでは判断できません。公式エクスポートドキュメント

提案では、長いプロンプトについて全位置の語彙スコアを生成するのを避けるため、デフォルトで最後の位置のlogitsだけを出力します。補助デコードが必要な場合は、完全な出力を要求できます。量子化のキャリブレーションでは、プリフィルとデコードの両方を対象にします。両者で活性値の範囲が異なるためです。デプロイを担当するエンジニアにとって検証すべき点は、重複する成果物を減らした後も、出力の一貫性と量子化品質を維持できるかどうかです。技術的な詳細

現時点では、統合に向けていくつかのハードルが残っています。このPRはマルチモーダル実行ブランチの上に重ねられており、提案によると、生成ランタイムに接続されるまではruntime()が生成エクスポート成果物を拒否します。今後は、依存する変更がマージされるか、さまざまなモデルでプリフィルとデコードの結果が元の実行結果と一致するか、実際の読み込みコストとレイテンシがどうなるかを確認する必要があります。現段階では、設計上の目標を実現済みの高速化として扱うことはできません。統合状況