出力20トークンなら、前置きを省く効果で29.0%短縮できました。
出力4000トークンでは0.2%まで縮みます。出力を作る時間は省けないためです。
同じ前置きなら計算を省けます。ただし省けるのは前置きの分だけで、出力の時間は残ります。
プレフィックスキャッシュは、共通する前置きの計算を省きます。公式は自動プレフィックスキャッシュは、既存の問い合わせのKVキャッシュを保存し、新しい問い合わせが同じ前置きを持っていればそのまま使い回せるので、共通部分の計算を省けると述べています。
省けるのは前置きの分だけです。出力の長さが変わるとどうなるのか実際に計算して数えました。
前置き 2,000トークン。読み込みは1トークン0.09ms、出力は1トークン22ms
前置きを省略できても、出力を作る時間（decoding）はそのまま残る
出力の長さ 前置きの読み込み 出力を作る時間 省略ありの合計 省略なしの合計 短縮率
20 180ms 440ms 440ms 620ms 29.0%
80 180ms 1760ms 1760ms 1940ms 9.3%
300 180ms 6600ms 6600ms 6780ms 2.7%
1000 180ms 22000ms 22000ms 22180ms 0.8%
4000 180ms 88000ms 88000ms 88180ms 0.2%
出力20トークンでは29.0%短縮できます。前置きの180msが、全体620msの3割近くを占めるためです。
出力4000トークンでは0.2%です。出力を作る時間が88,000msに対して、前置きの180msは誤差程度になります。
この形は、公式の前処理の時間（prefilling）だけを減らし、新しいトークンを作る時間（decoding）は減らさないという説明そのままです。
だから効果を見積もるときは、前置きと出力の比率を先に見ます。短い出力を大量にさばく用途で最も効きます。
この区分けは連続バッチングの記事でも扱った、詰める処理と生成する処理の違いと同じ形です。
出力が長くなるほど、前置き省略の効果は薄まる。
Automatic Prefix Caching (APC in short) caches the KV cache of existing queries, so that a new query can directly reuse the KV cache if it shares the same prefix with one of the existing queries, allowing the new query to skip the computation of the shared part.原文vLLM 公式ドキュメント「Automatic Prefix Caching」 この内容の有効期限2027-02-18
長い文書を繰り返し使う用途で効きます。ただし到着の間隔が空くと、使い回す前に消えてしまいます。
プレフィックスキャッシュの典型的な用途は、長い文書への繰り返しの問い合わせです。公式は同じ長い文書に違う問いを繰り返す場合、その文書を何度も処理する代わりに、APCは1度だけ処理させ、以後の要求はKVキャッシュの使い回しで再計算を避けられると述べています。
使い回されるかどうかは、到着の頻度で決まります。実際に流して数えました。
問い合わせ 2000件。前置き 2000トークン・問い 60トークン・出力 150トークン
使い回しは 5分もつものとし、置くとき 1.25倍・読むとき 0.1倍で数える
1分あたりの件数 使い回した回数 置き直した回数 入力の相当量 使わない場合との比
0.2件 1260回 740回 2,222,000 53.9%
1件 1980回 20回 566,000 13.7%
5件 1999回 1回 522,300 12.7%
20件 1999回 1回 522,300 12.7%
60件 1999回 1回 522,300 12.7%
1分5件以上なら、入力の相当量は12.7%まで下がって頭打ちになります。ほとんどの回で使い回せています。
1分0.2件だと53.9%です。5分の保持時間内に次が来ないことが多く、置き直しが740回発生しました。
前置きの長さを変えたとき（1分あたり5件の場合）
前置きの長さ 入力の相当量 使わない場合 比
200トークン 160,230 520,000 30.8%
500トークン 220,575 1,120,000 19.7%
1000トークン 321,150 2,120,000 15.1%
2000トークン 522,300 4,120,000 12.7%
8000トークン 1,729,200 16,120,000 10.7%
8000トークンの前置きでは10.7%まで下がります。長い文書ほど、省ける割合が大きくなります。
つまり長い文書への繰り返し問い合わせという公式の想定は、この2つの条件が両方そろう場面を指しています。
Long document query, where the user repeatedly queries the same long document (e.g. software manual or annual report) with different queries. In this case, instead of processing the long document again and again, APC allows vLLM to process this long document only once, and all future requests can avoid recomputing this long document by reusing its KV cache.原文vLLM 公式ドキュメント「Automatic Prefix Caching」 この内容の有効期限2027-02-18
有効にして損はしません。ただし前処理の段階だけが対象で、生成の段階には手を出しません。
プレフィックスキャッシュは、有効にしても性能を落としません。公式はAPCは一般に、vLLMの性能を下げない。とはいえ、APCが減らすのは問い合わせを処理する時間（前処理の段階）だけで、新しいトークンを作る時間（生成の段階）は減らさないと述べています。
「性能を下げない」と「速くなる」は別のことです。最初の節の表を見直します。
出力4000トークンの行では、短縮率は0.2%でした。下がらないが、ほとんど速くもならないという状態です。
だから「有効にしたのに速くならない」と感じたら、まず出力の長さと前置きの長さの比率を確かめます。設定の問題ではなく、用途の性質によることが多いです。
下がらない性質がある以上、有効にしておいて損はありません。効くかどうかは用途次第、という理解で使うことになります。
2つの計測はいずれも手元で書いた模型で、実際のvLLMを動かしたものではありません。1トークン0.09ms・22ms、保持時間5分、置くとき1.25倍・読むとき0.1倍といった値はすべて置いたものです。実際の速さの比は機材とモデルによって変わります。ここで見せているのは、出力が長くなるほど短縮率が薄まるという点と、到着の頻度が保持時間を下回ると使い回せなくなるという点の2つです。
APC in general does not reduce the performance of vLLM. With that being said, APC only reduces the time of processing the queries (the prefilling phase) and does not reduce the time of generating new tokens (the decoding phase).原文vLLM 公式ドキュメント「Automatic Prefix Caching」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る