LLMのPrefillとDecodeを分離量子化するDQ、速度と精度を両立

LLMの推論は一続きの処理に見えますが、PrefillとDecodeではハードウェア上の性質が大きく異なります。Prefillは入力プロンプトの多数のトークンをまとめて処理するため、演算スループットが重要です。一方、Decodeは1トークンずつ生成するため、重みの読み出しやメモリ帯域が大きな制約になります。

論文「Disaggregated Quantization: Specializing LLM Prefill and Decode」は、この違いを量子化設計に反映する「Disaggregated Quantization（DQ）」を提案しています。単一の量子化チェックポイントを両方の段階で使うのではなく、計算形式、重みの精度、保存場所をフェーズごとに最適化する考え方です。

DQの主な仕組み

• Prefillは演算効率を重視。 長いプロンプトを処理する際に低精度演算を活用しやすい、計算向けのPrefill重みを別途学習します。
• Decodeはメモリ効率を重視。 生成時にはコンパクトな低ビット重みを使い、トークンごとの重み転送量を抑えます。
• 活性値量子化を一律に適用しない。 Qwen 3とGemma 3では、Decodeだけ活性値量子化を外すことで、推論コストを増やさずDecode主体のタスクの精度が改善しました。
• 既存の量子化モデルにも接続できる。 共有重み形式の分離や、ポストトレーニング量子化を通じた検証も行われています。

実験では、別に学習したPrefill重みが、weight-only推論よりもプロンプト処理を高速化しながら、2〜3 bitのDecode設定で同等以上の精度を示しました。Qwen3.8-27B向けに公開されたNVFP4 Prefillerは、Decodeチェックポイントを変更せず、MMLU-ProとMMMU-Proの低ビット設定で性能を改善しています。重要なのは、ビット数を下げることだけではなく、各フェーズのメモリアクセスと演算特性に合う表現を選ぶことです。

単一デバイスへの実装

Prefill用の追加チェックポイントを用意すると、GPUメモリやストレージ容量の負担が増えます。そこで提案されたのが、Offloaded Disaggregated Prefill（ODP）です。Prefill重みをSSDに置き、長いプロンプトを処理しながらストリーミングすることで、読み込みコストを入力長に応じて償却します。

llama.cppで同じ27Bモデルを評価した結果、8Kのプロンプト長では、ODPがweight-onlyのベースラインに対してtime-to-first-tokenを1.78倍改善しました。ただし、効果はプロンプト長、SSDの速度、スケジューリング、モデル構造に依存します。短い入力では、追加の読み込みがメリットを打ち消す可能性もあります。

意義と課題

DQは量子化をモデル全体で固定する設定から、推論システム全体の設計課題へと捉え直します。Prefillでは演算資源を、Decodeではメモリ転送を優先することで、長文入力やDecode主体のサービスに新たな選択肢を提供します。

一方で、複数の重みを管理し、vLLMやllama.cppなどの実行基盤で読み込みと切り替えを制御する必要があります。実運用では、利用するGPU、入力長の分布、ストレージ性能、サービスのスケジューリングを含めた検証が欠かせません。

出典：Hugging Face Daily Papers