メインコンテンツにスキップ

ShadowPrefill：モデルを切り替えるエージェントで、切替先のKVキャッシュを先に温めておく

技術
解説
KVキャッシュ
AIエージェント
要点 ShadowPrefillは、エージェントが1ステップごとにLLMを切り替えると失われるプレフィックスキャッシュを、切り替える前に切替先モデルの遊休GPU能力で作っておく仕組みである。Microsoft Azure Researc…
作者

obelos

公開

2026年11月14日

更新日

2026年11月14日

要点

ShadowPrefillは、エージェントが1ステップごとにLLMを切り替えると失われるプレフィックスキャッシュを、切り替える前に切替先モデルの遊休GPU能力で作っておく仕組みである。Microsoft Azure Researchの論文「ShadowPrefill: Keeping Your Next Model Warm for Per-Step Model Routing in Agentic LLM Serving」（arXiv:2611.13176、2026年11月）で提案された。

  • 24のモデルペア・5種類のエージェント系ワークロードで、モデル切替直後の呼び出しのレイテンシを8.5〜21.4%、最初のトークンまでの時間（TTFT）を約44〜47%短縮する
  • キャッシュ済み入力の割引が効くようになり、ルーティング後のトークン費用を22.5〜46.1%削減する
  • GPUは追加しない。通常トラフィックのSLOは維持され、リクエストあたりの消費エネルギー増加は0.4%にとどまる

実装はvLLM上のプロトタイプ（vLLM本体は無改造、約840行）と、推論シミュレータVidurの拡張（約2,700行）の2つで評価されている。

ShadowPrefillは、③の灰色の部分を切替が決まる前に、切替先モデルの空き能力で計算しておく。

前提知識

この論文は、LLM推論サーバーの6つの仕組みを組み合わせている。先にそれぞれを整理する。

プリフィルとデコード

LLMの推論は2段階で進む。プリフィルは、プロンプトの全トークンをまとめて処理し、各層のAttentionが使うKeyとValueを計算する段階である。行列演算が中心で、計算能力がボトルネックになる。

デコードは、1トークンずつ出力を生成する段階である。1トークンごとに重みと過去のKey/ValueをGPUメモリから読むため、メモリ帯域がボトルネックになる。デコード中のGPUは、計算能力に余裕がある。

KVキャッシュ

デコードで毎回過去の全トークンを計算し直さないよう、計算済みのKey/ValueをGPUのHBMに保持する。これがKVキャッシュである。サイズは、層数×KVヘッド数×ヘッド次元×2（KとV）×数値精度に比例し、トークン数とともに増える。

論文の例では、全ヘッドが個別のKVを持つMulti-Head AttentionのGemma-7Bで1トークン458KBを使う。10万トークンのコーディングエージェントの文脈だけで、H100 1枚のKV領域の大半が埋まる。

プレフィックスキャッシュ

リクエストが終わった後もKVキャッシュを残し、次のプロンプトの先頭部分（プレフィックス）が一致したら再利用する仕組みである。一致した部分はプリフィル不要になり、差分だけを計算すればよい。vLLMのAutomatic Prefix Caching、SGLangのRadixAttentionが代表例である。

エージェントは、毎回「それまでの履歴＋新しいツール出力」を送る。前回のプロンプトが今回のプレフィックスになるので、この仕組みとの相性が非常によい。API事業者はキャッシュ済み入力を通常の約1/10の価格で課金しており、論文もこの料金体系を前提に費用を計算している。

KVキャッシュはモデルごとに別物

Key/Valueはそのモデルの重みから計算される。そのため、モデルAが作ったKVキャッシュをモデルBは使えない。同じ文脈でも、モデルを切り替えた瞬間にキャッシュは使えなくなる。この論文が扱う問題の出発点はここにある。

Continuous batchingとchunked prefill

現在の推論エンジンは、「イテレーション」と呼ぶ短い単位でGPUを動かす。1回のイテレーションで、実行中の全リクエストのデコード1トークン分と、新しいリクエストのプリフィルの一部を同じバッチで処理する。長いプリフィルを一定トークン数の断片に分けて混ぜるのがchunked prefill（Sarathi-Serve）である。

プリフィルの断片を足すと、そのイテレーションに乗っている全デコードがその分だけ遅れる。ShadowPrefillは、この「足してもよい量」を精密に管理する。

TTFT・TPOT・SLO

TTFT（Time To First Token）は、リクエスト到着から最初のトークンが返るまでの時間である。主にプリフィルの長さで決まる。TPOT（Time Per Output Token）は、出力1トークンあたりの生成間隔である。SLOは、これらに設ける目標値である。

論文の評価では、TTFTが「1秒」と「単独実行時のプリフィル時間の5倍」の大きい方以下、TPOTが「25ミリ秒」と「バッチ1でのデコード時間の5倍」の大きい方以下をSLOとしている。

PD分離

プリフィル用のインスタンス（P）とデコード用のインスタンス（D）を分け、Pで作ったKVをDへ転送する構成である（Splitwise、Mooncakeなど）。計算律速とメモリ律速の処理を分離して、互いの干渉をなくす。

背景：ステップ単位のルーティングと「切替税」

モデルを切り替えた呼び出しは、同じモデルを続けた呼び出しの1.5〜3.2倍の時間がかかる。論文はこれを「model switch tax（切替税）」と呼ぶ。

ステップ単位ルーティング

エージェントは、計画、ツール呼び出し、結果の読み取り、編集、テストを繰り返す。ステップごとに難易度が大きく違うため、単一モデルでは「難しいステップには力不足、簡単なステップには高すぎる」。そこで、LLM呼び出しごとに使うモデルを選ぶルーターが使われる。論文は、GPT-5が高速モデルと推論モデルをリクエストごとに切り替える例や、コーディングエージェントがサブタスクを小さいモデルに任せる例を挙げている。

評価では、ルーターにLLMRouter（UIUCのオープンソースライブラリ）を使う。各ステップを「コストあたりの正解率」が最も高いモデルへ送るポリシーで、候補は小モデルSと大モデルLの2つに限る。このルーターは、常に大モデルを使う場合より正解率が6.6〜13.6ポイント高い。2つのモデルは正解できる問題が異なるためである。

切替は頻繁に起き、文脈は長い

評価に使われた5種類のワークロードを下に示す。GHCP-codingは、GitHub Copilotのコーディングエージェントの公開トレース1日分からトークン数を取っている。SWE-benchは、SWE-agentの実際の実行履歴（平均57呼び出し）を使う。

ワークロード モデルペア数 切替率 切替回数/セッション プロンプト平均（トークン） 同p99 キャッシュヒット率（全体） 同（切替時）
xRouteBench 5 19% 2.3 19K 113K 80.4% 52%
FusionBench 5 26% 3.1 13K 58K 76.6% 52%
Router-R1 6 33% 4.1 10K 45K 69.2% 46%
GHCP-coding 6 26% 2.0 63K 131K 55.4% 44%
SWE-bench 6 26% 10.9 36K 93K 95.2% 65%

全呼び出しの19〜33%でモデルが切り替わる。同じモデルを続けた呼び出しのキャッシュヒット率は80〜89%だが、切替直後は44〜65%に落ちる。切替先には文脈がないか、あっても「最後にそのモデルを使った時点」で止まっているからである。

切替税は3か所で払われる

  • レイテンシ：失ったプレフィックスをプリフィルし直すまで、最初のトークンが出ない。切替呼び出しはxRouteBenchで3.2倍、GHCP-codingで1.5倍遅く、差の大半がTTFTである。GHCP-codingの切替呼び出しは19.0秒かかる
  • 費用：キャッシュ済み入力の約1/10の割引が消える。ルーターが「常に大モデル」に対して節約できるのは28〜44%にとどまり、その一因がこの割引の喪失である
  • 他の利用者：余分なプリフィルが、同じGPUで動く他のリクエストの計算時間を奪う

切替を避けるように学習したルーターもあるが、その分精度を手放す。ShadowPrefillはルーターの判断を変えず、切替の値段を下げる。

着眼点：本番クラスタには「イテレーション単位の余裕」がある

切替先のモデルは、ほとんどの場合すでにデプロイされ、他の利用者のリクエスト（論文では「通常トラフィック」）を処理している。ShadowPrefillは、そのインスタンスが使い切っていない能力を使う。

ピーク基準の確保で、平常時は余る

推論クラスタは、SLO違反を避けるためピーク時の負荷に合わせてGPUを確保する。Azureの本番LLM推論トレースでは、P95の需要に合わせて確保したGPUプールの利用率は、テキストで50%、マルチモーダルで39%にとどまる。

1週間分のトレースを再生すると、1日の中で負荷が3〜10倍変動する。コード系トラフィックを処理するインスタンスは、中央値の時間帯で72%、最も閑散な時間帯で85%の時間が完全にアイドルである。ただしピーク時は8%しかない。会話系トラフィックは負荷が安定していて、インスタンス丸ごとアイドルになる時間はどの時間帯にもない。

ピーク時でも、各イテレーションには余裕がある

切替が最も高くつくのは混雑時であり、まさにそのときインスタンス丸ごとの遊休は消える。そこで論文は、より細かい単位の余裕に目を向ける。

デコード中心のイテレーションはメモリ律速で、TPOTのSLOより十分短い時間で終わる。ピーク時でも、中央値のイテレーションはTPOT SLOの約1/4しか使わず、各イテレーションの時間予算の69〜79%が未使用である。

ここにプリフィルの断片を足すと、そのイテレーションに乗る全デコードが遅れる。ただし、遅れが実行中の各リクエストの余裕の範囲に収まれば、SLOを外すリクエストは出ない。この余裕が、ShadowPrefillが収穫（harvest）する計算能力である。

手法：ShadowPrefillの仕組み

ShadowPrefillは、ルーターが選ばなかった側のモデルで、セッションの文脈を最低優先度の仕事としてプリフィルし続ける。ルーターと推論エンジンの間に入り、ルーティングされた呼び出しごとに、もう一方のモデル上の「シャドウジョブ」を作成・延長する。

通常のデコードは各イテレーションのSLO予算を使い切らない。余った時間にシャドウの断片を詰め、切替の前に文脈のKVを作り終える。

5つの課題と対応する仕組み

課題 内容 仕組み
C1 ピーク時に空きGPUがない 切替が高くつく混雑時ほど、丸ごと空いたインスタンスがない SLO余裕コントローラ
C2 シャドウが本来の呼び出しを遅らせる シャドウの断片とルーティングされた呼び出しが同じイテレーションに乗る ルーティング呼び出しの保護
C3 長い文脈がKV領域に収まらない 10万トークンの文脈は小モデルのKV領域を大きく占め、使う前に追い出される 上限付きのシャドウKVクラス＋ホストメモリ退避
C4 シャドウの多くが無駄になる 切替は呼び出しの26〜33%。ルーターは呼び出しが来た時点で初めて決める 増分・ストリーミング・スティッキー配置、切替確率順の実行
C5 SLOを悪化させない 切替呼び出しはシャドウを待たず、通常トラフィックはSLOを守る 最低優先度・イテレーション単位の実行と、コールド切替へのフォールバック

シャドウジョブ：差分だけを送り続ける

セッションsが呼び出しk+1でモデルAからBへ切り替わるとき、そのプロンプトは「呼び出しkまでの全履歴」＋「新しい入力」である。目標は、呼び出しk+1が届くまでに履歴をBのプレフィックスキャッシュに載せておき、新しい入力だけをプリフィルさせることである。

  • 増分：シャドウジョブは、Bがすでに持っているプレフィックスと、まだ持っていないトークンを記録する。Bが同じ部分を二度プリフィルすることはない。A→B→Aと切り替わっても、処理するのは差分だけである
  • ストリーミング：呼び出しkがAに届いた瞬間にその入力をジョブへ追加し、Aが出力トークンを生成したらそれも順次追加する。シャドウは常に「現在の呼び出しの出力」の分だけ遅れる。その末尾は、切替呼び出し自身がプリフィルする
  • スティッキー配置：各セッションはモデルごとに固定のインスタンスを持ち、シャドウはもう一方のモデルの固定インスタンスで動く。ルーターは、「キャッシュされていないトークンだけを数えたプリフィル完了予測時刻」が最も早いインスタンスへ送る。そのため切替呼び出しは、そのインスタンスが極端に混んでいない限りシャドウを持つインスタンスに届く
  • 切替確率順：待ちのシャドウジョブは、過去のセッションからタスクと現在のモデルごとに推定した切替確率の高い順に実行する

どこに入れるか：イテレーションの最後尾

各イテレーションは、「実行中のデコード」「処理中のプリフィル断片」「待ち行列からの新規受付」の順に組まれる。シャドウの断片はその最後に追加し、待ち行列が空で、メモリ不足で受付できなかったリクエストもないときに限る。

インスタンスが完全に空いているときは、シャドウだけのイテレーションを回す。1回の長さはTPOT SLOのβ倍（β=0.5）までとし、新しいリクエストが待たされる時間に上限を設ける。

SLO余裕コントローラ（C1）

混雑時は、通常のイテレーションにシャドウの断片を相乗りさせる。何トークン足すかは、実行中のリクエストのSLO余裕で決める。使う情報は、本番のスケジューラが知っている到着時刻・最初のトークンの時刻・イテレーション回数だけである。

デコード中のリクエストrが時刻f_rに最初のトークンを出し、k_r回のイテレーションを終えたとする。TPOT SLOをT_r、安全マージンをmとすると、次のイテレーションに許される長さσ_rは次の式である。

\[ \sigma_r = (1-m)\,T_r\,(k_r+1) - (t - f_r) \]

「ここまでに使ってよい時間」から「実際に使った時間」を引いた残りが、そのリクエストが貸せる時間である。プリフィル中のリクエストは、TTFT SLOの残りから残りのプリフィル予測時間を引いた値を余裕とする。

イテレーションの予算は、バッチ内で最小の余裕（上限βT）である。レイテンシモデルが「予算内に収まる」と予測する限りシャドウのトークンを足す。SLOに余裕のあるリクエストが時間を貸し、締切に近いリクエストがいればそのイテレーションでは足さない。

ルーティング呼び出しの保護（C2）

エージェントの呼び出し自体には貸せる余裕がない。そのイテレーションが伸びれば、その分がそのままエージェントの待ち時間になる。そこで、ルーティングされた呼び出しを含むイテレーションでは、小さな「クレジット」だけを使う。

クレジットは、デコードのみのイテレーションの時間のδ倍（δ=0.025）ずつ貯まる。そのため、ルーティングされた呼び出しの長期的な遅延は最大でもδ（2.5%）に抑えられる。通常トラフィックだけのイテレーションでは、余裕を全部使う。

シャドウKVの管理（C3）

  • 上限付き・先に捨てる専用クラス：シャドウのKVは独立したキャッシュクラスとし、KV領域の25%を上限とする。使えるのは空きブロックと5秒以上使われていないキャッシュだけである。追い出しはシャドウを通常のキャッシュより先に行い、各クラス内はLRUである
  • ホストメモリへの退避：HBMから追い出されたKVを、シャドウも通常もホストのDRAMに退避し、必要になったらPCIe経由で戻す。戻す方が再計算よりはるかに安い。長い文脈のコーディングエージェントでは、これがないとシャドウは切替の前に消える

安全性とフォールバック（C5）

シャドウは、ルーティングされた呼び出しも通常リクエストも妨げない。待ちがないときだけ動き、1回あたりの量は予算で制限され、イテレーション単位で中断される。新しいリクエストの待ちは最大でも上限付きイテレーション1回分である。

切替呼び出しがシャドウを待つことはない。シャドウが途中までなら、そこまでを使って残りをプリフィルする。無いか追い出されていれば、ShadowPrefillがない場合とまったく同じ動きになる。予測が外れたときの代償は、使った余剰能力とその分の電力だけである。

PD分離構成への拡張

PD分離では、切替のたびに切替先のPrefillインスタンスでのコールドプリフィルと、Decodeインスタンスへの大きなKV転送が発生する。ShadowPrefillは、もう一方のモデルのPrefillインスタンスで、待ち行列が空かつ他のリクエストにTTFTの余裕があるとき、最大0.1秒のイテレーションでシャドウを作る。

Decodeインスタンスは、受信側のリンクが空いているときに4Kトークン単位でシャドウKVを取り込み、最初に回収される空きメモリへ置く。切替時はPrefillが末尾だけを計算し、Decodeは足りないトークン分だけを受け取る。Prefillインスタンスはプリフィルのピークに合わせて確保され、アイドルになりやすいため、同居構成より多くの能力を使える。

評価結果

全機構（Harvest-SLO+Host）は、追加GPUなしで「切替がタダになる理想状態（Oracle）」の効果の52〜54%を得た。

評価の設定

  • シミュレーション：Vidurを拡張した離散イベント型のクラスタモデル。各イテレーションの時間は、H100で測った演算子プロファイルから層ごとに算出する。22モデルペア（7B〜141B、denseとMoE、Qwen・Llama・Mistral・Gemma・GPT-OSS・Granite）
  • 通常トラフィック：各モデル4インスタンス。Azureの会話トレースを、ピーク時に90%のリクエストがSLOを満たせる能力の70%（ρ=0.7）で流し、ピーク・中央値・谷の3時間帯を再現する
  • 実機：H100 16枚。vLLM 2インスタンスで、FusionBenchの2ペアとSWE-bench Verifiedの2ペア（SWE-agent-LM-7B×SWE-agent-LM-32B、SWE-agent-LM-7B×Qwen2.5-72B-Instruct）、通常トラフィックはρ=0.3

主な結果（シミュレーション）

指標 ベンチマーク16ペア GHCP-coding 6ペア Oracle（上限）
切替呼び出しのレイテンシ短縮 10.4% 14.3%（19.0秒中3.3秒） 19.3% / 27.4%
切替呼び出しのTTFT短縮 44.1% 47.0% —
全LLM呼び出しの平均レイテンシ短縮 5.0% 9.7% 9.6% / 13.8%
タスクあたりのLLM時間短縮 4.9% 10.0% —
キャッシュヒット率 75.0%→82.1% 55.4%→76.3% 84.4% / 81.3%
トークン費用削減 28.5% 32.0% —

単一ペアでは、切替レイテンシが最大21.4%、トークン費用が最大46.1%下がる。タスクあたりのLLM時間は、Gemma-2-9BとMixtral-8x7Bのペアで最大17.7%短くなる。効果の大半はTTFTから来ている。

機構ごとの寄与

論文は、機構を順に足した構成を比較している。Harvestは固定クレジット（δ=0.1）だけで収穫する構成、Harvest-SLOはそれをSLO余裕コントローラに置き換えた構成、+Hostはホストメモリ退避を加えた全機構である。Predictiveは切替確率0.25以上のセッションだけを温める構成、Dedicatedはシャドウ専用のインスタンスを各モデルに1台足す構成、Oracleは切替時のキャッシュが無償で用意される理想値である。

Predictiveが Harvestより効果が小さいのは、ルーターが呼び出しごとに決めるため、確率で絞ると実際に起きる切替を取りこぼすからである。DedicatedはOracleに近づくが、GPUが25%、エネルギーが11.7%増える。シャドウを通常優先度のリクエストとして流すと（Eager）、逆にLLM呼び出しが7.0%遅くなる。

GHCP-codingではホストメモリ退避の影響が大きい。Harvest-SLOだけでは63Kトークンのシャドウが小モデルのKV領域から追い出され、4.3%にとどまる。退避を加えると14.3%になる。

ルーティングの精度と費用

ShadowPrefillはルーターの判断を変えないので、精度はそのままである。「常に大モデル」に対する費用削減は、28〜44%から49〜56%に広がる。同じ精度で、ルーター自身の請求額が22〜34%下がる。GHCP-codingでは、「常に大モデル」より精度が13.6ポイント高く、費用は54%低い。

オーバーヘッド

  • スループット：シャドウを含むプリフィル総量は3.8%増える。一方、ルーティングされた呼び出しと通常リクエストのプリフィルは2.4%減る。切替呼び出しがキャッシュに当たるためである。デコードのスループットは変わらない
  • エネルギー：SLOを満たしたリクエストあたりの消費エネルギーは+0.4%。もともと電源が入っているGPUの、メモリ律速で余った計算能力を使うためである
  • 通常トラフィック：SLO達成率は下がらず、0.10〜0.40ポイント上がる。切替呼び出しが早く終わり、インスタンスが早く空くためである
  • PD分離：LLM呼び出しのレイテンシが5.2%、切替呼び出しが14.0%短くなる（同居構成は3.7%と7.7%）。ただし、寝ていたPrefill用GPUを起こすため、エネルギーは+11.5%になる

実機での検証

vLLMのプロトタイプでも、切替呼び出しのTTFTは平均61.9%短くなる。タスクあたりのLLM時間は、FusionBenchで12.1%、全ペア平均で7.0%短くなる。トークン費用は平均20.4%下がり、エネルギー増加は1.4%、通常トラフィックのSLO達成率は全ペアでわずかに上がる。

SWE-agent-LM-7B×Qwen2.5-72Bでは、切替が呼び出しの13%しかなく、デコードが実行時間の大半を占める。そのため切替呼び出しのTTFTは65.9%短くなっても、タスクあたりの時間はほぼ変わらない。またSWE-benchでは、エージェント向けに調整された32Bモデルとの組み合わせがタスクの32%を解き、汎用の72Bモデルとの組み合わせは14%にとどまる。モデルが大きいだけではエージェントの精度は上がらない。

効果が大きくなる条件・小さくなる条件

効果を決めるのは、「切替呼び出しのうちプリフィルが占める割合」と「収穫できる余裕の量」の2つである。

条件 結果 理由
文脈が長い 2Kトークン未満で切替レイテンシ0.7%短縮、64K超で20.5%短縮 コールド切替で作り直す量が増える。ホストメモリ退避がないと、32K超でシャドウが追い出され効果が落ちる
切替先が小さい 15B未満で切替レイテンシ12%短縮、15〜50Bで4%、50B超で3% ヒット率はどのサイズでも切替時に24〜28ポイント上がる。ただし大モデルはデコードが支配的で、削れるプリフィルは全体の12〜13%（小モデルは26%）
出力が長い推論モデル DeepSeek-R1（671B）は改善0.2ポイント 平均355トークンの推論出力でインスタンスが常に忙しく、余裕がない
SLOが緩い 既定の半分のSLOでLLM呼び出し2.7%短縮、既定で6.7%、2〜3倍緩めると約8.7% 収穫できる余裕はSLOに比例する
負荷が高い ホスト退避なしはρ=0.2で4.4%、ρ=0.9で0.7%。ホスト退避ありはρ=0.9で15.2% 余裕は減るが、コールド切替の待ちとキャッシュ追い出しが増え、ホスト退避の価値が上がる

シャドウKVの上限25%は、ほとんど使われない。平均でKV領域の1.7%しか占めず、上限を全領域にしても5%にしても結果はほぼ変わらない（5.0%と4.6%）。

効いてくるのは、「何秒使われていないキャッシュならシャドウで上書きしてよいか」という閾値である。0秒では直後に使われるキャッシュまで消し、シャドウの仕事量が2.1倍に膨らんで効果は3.6%に下がる。120秒では空きメモリしか使えず、切替時のヒット率が72%から54%に落ちて2.8%になる。2〜10秒であれば4.8〜5.2%で安定する。

関連研究との違い

既存のKV管理は、すべて「そのKVを作ったモデル自身のキャッシュ」を扱う。ShadowPrefillは、まだそのセッションを処理していないモデルにキャッシュを作る点で異なる。

分野 代表例 ShadowPrefillとの違い
プレフィックスキャッシュ vLLM、SGLang、CachedAttention 同一モデル内での再利用
キャッシュの階層化 Mooncake、Pensieve、LMCache ホストメモリやリモートへの退避。対象は同一モデル
ツール呼び出しをまたぐKV保持 InferCept、KVFlow、Continuum 同一モデルのKVを残す・先読みする
モデル間のKV変換・共有 Cache-to-Cache、ICaRus、PrefillShare 再学習が必要で、変換後のKVは近似。ShadowPrefillは切替先モデル自身が計算するので完全に等価
余剰能力の収穫 Harvest VM、GPU同居、ConServe、Sarathi-Serve 低優先度ジョブやバッチ処理が対象。ShadowPrefillは収穫した能力をエージェントのモデル切替に使う

まとめ

  • ステップ単位のモデルルーティングは精度と費用を両立するが、KVキャッシュがモデル固有であるため、切替のたびにプレフィックスキャッシュを失う。切替呼び出しは1.5〜3.2倍遅く、キャッシュ割引も消える
  • ShadowPrefillは、切替先候補のモデルで文脈を先にプリフィルしておく。使うのは、インスタンスの完全アイドル時間と、各イテレーションのSLO余裕である。余裕を測る単位をインスタンスからイテレーションに細かくしたことで、混雑時にも能力を確保できる
  • 投機的な仕事を最低優先度に置き、間に合わなければ従来どおりのコールド切替に戻る。そのためルーターの判断も通常トラフィックのSLOも変えずに、切替レイテンシを8.5〜21.4%、トークン費用を22.5〜46.1%下げる。効果が最も大きいのは、文脈が長く切替先が小さいコーディングエージェントである

参考文献