LLMの回答が遅いとき、どこから改善する？TTFT・出力・キャッシュ・モデル選択

2026年10月27日 · 約9分で読めます

最初の文字は出るのに、使える回答が届かない。問い合わせ対応AIを例に、全体の計測、出力削減、プロンプトキャッシュ、文脈の予算、モデルの振り分けを5件のTipsでつなぎます。

LLMの回答が遅いとき、まず何を測る？

対策は、モデル名を変える前に遅い段階を見つけることです。問い合わせへの返信案を作る架空のAIで、受信から最初の表示、根拠付き返信案の検証完了、利用者が依頼した操作の完了を別に記録します。TTFTは最初のトークンまでですが、開始点や何をトークンとして数えるかは計測仕様を揃えます。

測定	含める範囲	見落としやすい点
最初の表示	待ち行列・検索・モデル開始など、定義した入口からの時間	定型の前置きだけ速くても回答は未完成
利用可能な回答	検索・生成・検証の完了まで	構造化出力の検証や再生成も含める
操作完了	認可・ツール・外部結果の確認まで	受付応答と確定した成功を分ける

1件の要求で振り分け100ms、検索300ms、生成1,200ms、検証400msが直列なら合計2,000msです。独立した処理は並列化の候補ですが、根拠が必要な生成を検索より先に完了させることはできません。段階ごとのp95を足して全体のp95とせず、同じ要求の開始から完了までを測ります。

出力を短くする：効く条件を計算する

入力を読む段階をプリフィル、出力を作る段階をデコードと呼びます。TTFTが0.5秒、生成速度がほぼ毎秒50トークンという独自の仮定なら、完了時間を概算で0.5＋出力数÷50と置けます。800トークンは16.5秒、200トークンは4.5秒です。最初の1トークンの扱いを簡略化した概算で、製品の速度保証ではありません。

仮定のモデル呼び出し完了時間（秒）。検索・検証の時間は含まない

800トークン: 16.5秒
200トークン: 4.5秒

返信案に必要な結論・根拠・次の操作を残し、重複説明を減らします。上限トークン数だけを小さくすると文やJSONが途中で切れるため、指示と形式も短い出力に合わせます。ストリーミングは早く読み始めるために使えますが、表示済みの不適切な内容を後から検証して回収することはできません。

プロンプトキャッシュ：固定部分と可変部分を分ける

プレフィックス型のキャッシュでは、先頭から一致する範囲が重要です。毎回変わる時刻や要求IDを長い共通資料より先に入れると、その後ろの再利用を妨げます。対応するAPIでは、安定したツール定義・指示・共有資料を先へ、利用者ごとの入力を後へ置きます。認可済みの資料を渡す判断は毎回行い、キャッシュで権限検査を置き換えません。

並べ方の概念例。APIの完全な要求形式ではない

stable tools -> stable policy -> authorized shared references
             -> relevant history -> current question and request metadata

最小のキャッシュ可能長、境界、TTL、書き込み料金はAPIとモデルで確認します。キャッシュ済み入力トークン、ミス時の時間、書き込みを含む費用を記録します。入力の再利用が効いても出力の生成を省くものではなく、短い入力や疎な呼び出しでは別の対策が有効なこともあります。

長い履歴とツール結果に予算を付ける

架空の入出力共有32,000トークン枠で、出力8,000、指示など4,000を確保すれば、履歴・検索・ツール結果に残るのは20,000です。これは製品の上限ではありません。実際の入出力・推論用トークンの算入規則に合わせて、検索件数とツールの返却量を制限します。

履歴を要約するときは金額・例外・出典を落としていないか確認します。重要な値は構造化して持ち、原本へ戻れるようにします。枠を超えたら無言で切り捨てず、検索を絞る、段階に分ける、利用者に条件を確認する経路を作ります。短くしても必要な根拠を失えば改善とは呼べません。

小さいモデルへ振り分ける前に、後段の費用も測る

最初から1つのモデルを選ぶルーターと、軽いモデルの結果を見て強いモデルへ回すカスケードは別です。全件で1費用単位、20%でさらに5単位なら平均1＋0.2×5＝2単位。これは架空の呼び出し料金だけの計算で、検証・検索・再試行は含みません。後段へ回す件は両方の時間がかかります。

モデル自身の「自信」を正しさと同一視せず、言語・難易度・入力長ごとに、誤って通す件と不要に後段へ送る件を評価します。平均費用が減っても、難しい件の待ち時間や重大な誤りが増えるなら採用条件を満たしません。Bedrockのルーティングのような製品機能も、独自の段階実行例とは方式を区別します。

改善を確かめる試験：速度と品質を一緒に見る

同じ評価セットで、初回・キャッシュヒット・長い会話・大きいツール結果を比べる。
入力長・出力長・待ち行列・再試行・検証回数をトレースと結び付け、全体のp50・p95を測る。
回答の根拠、構造化出力の完了、業務上の重大な誤りを速度変更の前後で確認する。
全体の期限を超える仕事は受付済み・処理中・失敗・完了を持つ非同期処理も比較する。

参考にした一次資料

以下の公式資料は2026年10月27日に確認しました。数値例とシナリオは独自の仮定です。設定例は説明用で、実サービスでの実行や性能測定は行っていません。