← 概念辨析に戻る

Concept Contrast Fable

プリフィルとデコード段階、バッチ入力は一気に飲み込み、一文字ずつ吐き出す

先に結論:プリフィルは推論の最初の段階で、すべての入力トークンを一度に並列処理する。デコード段階がそれに続き、出力トークンを一つずつ自己回帰的に生成する。議論の中でプリフィルを推論の「入力処理」と略す人がいるが、ユーザーが見る結果を実際に生み出しているのはデコードであり、二つの段階のエンジニアリング特性はまったく異なる。

プリフィルは推論の最初の段階で、すべての入力トークンを一度に並列処理する。デコード段階がそれに続き、出力トークンを一つずつ自己回帰的に生成する。議論の中でプリフィルを推論の「入力処理」と略す人がいるが、ユーザーが見る結果を実際に生み出しているのはデコードであり、二つの段階のエンジニアリング特性はまったく異なる。

寓話

一つの竈に二つの鍋、一つは強火で一気に炒める、一つは弱火でゆっくり煮て一匙ずつ盛る

町に官宴専門の酒楼があり、厨房の主灶は兄弟二人が握っていた。兄は炒め鍋を担当:食材を一緒に鍋に入れ、強火で素早く返し、二三分で皿に盛る——下ごしらえは揃っていなければならず、一つ欠けても火をつけない。弟はスープ鍋を担当:スープの出汁は朝に煮込み、客が注文すると長いお玉で一杯ずつ椀に注ぐ。一杯ごとにスープ表面の油の花と椀底の具を確認し、急いではならない。

酒楼の効率はすべて厨房の連携にかかっている。中華鍋が速く炒めるときは、次々と鍋を送り出し、十卓分の料理が同時に仕上がる。しかしスープ鍋は遅い——一杯ごとに個別に盛り、個別に見て、個別に味を加える。中華鍋とスープ鍋の間には配膳台があり、炒め終わった料理がそこで待つ。毎回詰まるのはスープ鍋の側である。

しばらくの間、酒楼は多くの大型寿宴を引き受けた——一枚のテーブルの料理量が極端に多い。炒鍋の材料量は一人前からテーブル全体分へ跳ね上がり、鍋は同じ鍋、火力も変わらないが、一鍋を返す時間は三倍近くになった。湯鍋の一杯あたりの速度は変わらず、全体の待ち時間は長くなった。厨房主管が料理待ちの苦情を一つずつ調べると、七割の苦情は提供が遅いからではなく、「料理とスープの間隔が大きすぎる」ことだった——炒め物が来て、スープはまだずっと待たされる。

主管は二つのことを行った。一つ目は炒め鍋の仕込み基準の強化——料理の量がどれほど多くても、仕込みは2分以内に揃え、鍋が火にかかっているのに材料が一品欠けて待つという空費を出さないこと。二つ目はスープ鍋に保温分装台を追加したこと——スープ鍋のメインスープをまず保温台で十杯に予め注いでおき、客の注文ごとに最後の味付けと盛り付けだけを行い、最も遅い部分を高速化した。

修正後、寿宴の悪評は消えた。厨房の主管は新入りの学徒に語った。中華鍋は入力全体を一度に並列処理する——計算密度を食い、菜量が増えるほど、すべての材料が鍋の中にいる時間差への要求が厳しくなる。スープ鍋は一つずつ出力する——単段の流暢さを食い、速度を上げる方法は単段間の準備時間を減らすことだ。一つの厨房に二つの鍋があるが、中華鍋に新鮮な菜を入れるときもスープ鍋は動き続けており、互いに止まらない。

料理長はこの経験を厨房マニュアルに書き込んだ。中華鍋は下ごしらえを一度で済ませ、強火で一気に炒めることが肝心で、スープ鍋は各お玉の間で途切れないことが肝心だ。中華鍋が遅いときは下ごしらえと火力を、スープ鍋が遅いときは盛り付け台と配膳のリズムを疑う。二つの鍋が詰まる場所は違い、直し方も違う。

後に誰かが主管に、中華鍋とスープ鍋を一つの鍋に統合できないかと尋ねた。主管はしばらく考えて言った。中華鍋は強火短時間、スープ鍋は弱火長時間——同じ媒体に置けば両方ともうまくいかなくなるだけだ。あなたにできるのは、中華鍋で炒め終わった熱い料理をそのままスープ鍋の隣の配膳溝に滑り込ませ、途中で冷まして盛り直さないことだ。境界は動かさず、流れは通す。

プリフィル

推論の第一段階。入力シーケンス全体の token を一度に並列処理し、すべての token の注意力を計算して、最初の token の生成状態を出力する。スループット志向で、計算集約型。

デコード段階

推論の第二段階。出力トークンを一つずつ自己回帰的に生成し、各ステップで新トークンの履歴への注意を計算する。レイテンシに敏感で、メモリアクセス集約型。

物語の対応

  • 中華鍋(強火の爆炒):prefill——全入力tokenの並列注意計算
  • スープ鍋(弱火でゆっくり煮込み、お玉で一杯ずつ):decode——トークンごとに自己回帰生成
  • 配膳台の詰まり:prefill は速いが decode が遅く、ユーザー体感の遅延を引き起こす
  • 大規模な寿宴で中華鍋が三倍の時間に:長い入力の prefill 遅延増加
  • 中華鍋の下ごしらえ標準の強化:prefill最適化の鍵は準備時間差を減らすこと
  • スープ鍋保温盛り付け台:decode 最適化は単一ステップ間の待ち時間を減らすことにかかっている
  • 二つの鍋を統合する議論:prefill と decode の計算特性を一つのコアに混ぜてはならない
  • KV キャッシュ再利用:prefill が出力した中間状態をそのまま decode に渡し、コールドスタートしない

推論サービスのレイテンシ分析に落とし込む

ユーザーが「モデルの反応が遅い」と感じたら、まず二つの指標に分けて見る:初回トークン遅延と後続トークン間隔。初回トークン遅延が高い場合はprefillがボトルネック——入力が長すぎるかバッチが大きすぎるため、prefillの並列戦略を最適化する必要がある。後続トークン間隔が大きい場合はdecodeがボトルネック——単ステップのメモリアクセスが遅く、KVキャッシュの読み書きを最適化するか投機的デコーディングを試す必要がある。サービス監視パネルではTTFT(初回トークン時間)とTPS(毎秒生成トークン数)を別々のパネルに設定する。これらは二つの異なる最適化経路に対応する。prefillだけを最適化して遅延に満足すると、リリース後に長い出力の場面でdecodeの隠れた弱点が露呈する。

京ICP备2026014272号