本番環境における LLM の遅延と推論コストを削減する 12 の方法

# イントロダクション

大規模言語モデル（LLM）を扱うアプリは、予想以上にすぐに遅くなり、コストも膨らんでしまいます。プロトタイプ段階では問題なさそうに見えても、実際の運用環境では話は別です。

ユーザー数が少なく、1 回の呼び出しで短いプロンプトしか使わない場合、応答速度に疑問を抱くことはほとんどないでしょう。しかし、本番環境ではトラフィックの急増によりリクエストがキューに殺到します。会話の長さが伸びれば、それだけ処理時間がかかります。さらに、検索拡張生成（RAG）パイプラインを導入すると、プロンプトごとに大量のコンテキストが追加され、処理負荷が増大します。エージェントが複数のツールを呼び出すようになれば、その分だけコストも跳ね上がります。初期に設定した出力制限の幅広さも、気づかないうちに遅延とコストを増加させる要因となっています。

驚くべきことに、解決策は必ずしも高性能なモデルや追加の GPU 導入ではありません。最も効果的な改善点は、「最初から行う必要のない作業を減らす」ことです。トークン数を削減し、呼び出し回数を減らし、簡単なタスクには小規模なモデルを使い、キャッシュを適切に再利用し、キューで待たされる時間を最小限に抑えること。本ガイドでは、本番環境における LLM の遅延と推論コストを削減するための 12 の実践的な方法を紹介します。

# 1. まず適切な遅延指標を測定する

最適化を行う前に、まず時間がどこで消費されているかを把握する必要があります。

エンドツーエンドの遅延（レイテンシ）は参考になりますが、それだけでは応答が遅い原因を特定することはできません。本番環境の LLM システムでは、少なくとも以下の指標を追跡すべきです：

• キュー待ち時間：リクエストが処理を開始するまでの待機時間
• 初回トークン到達時間（TTFT）：ユーザーがストリーミングされた最初の応答トークンを表示されるまでの所要時間
• トークン間レイテンシ：モデルが次のトークンを生成する速度
• エンドツーエンドのレイテンシ：リクエストから完了した応答に至るまでの総所要時間
• 入力・出力トークン数：推論コストを決定する主要な要因
• キャッシュヒット率：プロンプト、検索、または応答キャッシュが重複作業を防ぐ頻度
• ツールおよび検索のレイテンシ：モデル自体の外側で消費される時間
• P50、P95、P99 レイテンシ：平均値よりも、遅延する極端なケース（テイル）の方が重要になることが多い

例えば、TTFT が高い場合、プロンプトが長すぎるか、検索が遅いか、キュー待ちが発生している可能性があります。トークン間レイテンシが遅い場合は、モデルが大きすぎたり、GPU が過負荷だったり、バッチ処理の設定が悪い、あるいはメモリ圧力がかかっていることが考えられます。

これらの測定を行わないままでは、チームは往々にしてボトルネックを誤って最適化してしまいます。

# 2. 出力トークンを積極的に削減する

生成された出力トークンは、レイテンシとコストの両方において最も明確な要因となるケースが多いです。

モデルは完了用のトークンを順次生成する必要があります。応答が倍の長さになれば、生成にかかる時間も概ね倍になり、コストも大幅に増加します。

まずは以下の対策から始めましょう：

• max_tokens や最大完了制限など、現実的な上限を設定する
• ユーザーが長い説明を必要としない場合は、簡潔な回答を求める
• 適切な箇所で停止シーケンス（stop sequences）を活用する
• モデルにユーザーの質問を繰り返させるよう依頼しない
• JSON スキーマはコンパクトにし、フィールド名も短くする
• 出力から不要な要約、免責事項、重複したコンテキストを削除する
• プロダクト UI で「簡易回答」と「詳細解説」のモードを分ける

例えば、社内サポートアシスタントでは、3 つのポイントと出典リンクがあれば十分で、デフォルトで 700 文字もの説明が必要ないケースが多いです。

シンプルなルールとして、「ユーザーが読まないトークンにお金を払わない」ことを心がけましょう。

# 3. 要件を満たす最小のモデルへリクエストをルーティングする

すべてのタスクに、最大規模で最も高価なモデルが必要とは限りません。

多くのプロダクションワークロードは反復的で構造化されています。具体的には以下のようなケースです：

• 感情分析
• データ抽出
• コンテンツモデレーション
• クエリ書き換え
• FAQ への回答
• 構造化された JSON の生成
• 基本的な要約

これらのタスクは、品質に許容範囲がある場合、より小型のモデルで実行可能です。その結果、コスト削減とレスポンス速度の向上が期待できます。

有効なパターンとして「モデルルーティング」があります：

• シンプルなリクエストを小型で低コストのモデルへ送信する
• 信頼度、複雑さ、出力品質などを評価する
• 困難なリクエストは必要な場合にのみ、より強力なモデルへエスカレーションする

ルーティングの判断基準としては、プロンプトの長さ、タスクの種類、ユーザーのランク、モデルの信頼度、検索結果の質、あるいは軽量な分類器などが挙げられます。

このアプローチにより、最も高性能なモデルをあらゆるリクエストのデフォルト回答として使用することを防ぎます。

# 4. LLM の呼び出し回数を減らす

生産環境でよく見られる失敗が、モデル呼び出しが多すぎるワークフローを構築してしまうことです。

例えば、エージェントは以下のような処理を行うことがあります：

• ユーザーの要求を分類する
• 要求を書き直す
• ドキュメントを検索する
• 検索したドキュメントを要約する
• 回答を生成する
• 回答を批判的に検証する
• 回答を再構成する

それぞれの呼び出しが、レイテンシの増加、コストの上昇、障害ポイントの発生、そして運用上の複雑さを招きます。

組み合わせ可能なステップを探しましょう。構造化された出力を持つ単一のよく設計されたプロンプトで、2 つや 3 つのモデル呼び出しを置き換えることができます。

また、LLM を必要としないステップも特定してください。以下の処理には決定論的なコードを使用します：

• 日付フォーマット
• フィールドのバリデーション
• 単純なルーティングルール
• 権限チェック
• 計算処理
• UI ラベルの表示
• 既知のテンプレート
• データベース参照

独立したタスクは並列実行しましょう。検索、分類、背景情報の付加などは、互いに待機する必要がないケースがほとんどです。

# 5. プレフィックスキャッシングを考慮したプロンプト設計

プロンプトキャッシングは、繰り返し使用される長いプロンプトのコストと時間を削減する最も効果的な方法の一つです。

多くの LLM システムでは、すべてのリクエストで安定して出現するコンテンツがあります：

• システム指示
• セーフティポリシー
• ツールの定義
• フューショット例（Few-shot examples）
• 製品ドキュメント
• 長い参照資料
• ワークフローの静的コンテキスト

こうした再利用可能なコンテンツは、プロンプトの先頭に配置します。

一方、変化する内容は後方に置きます：

• ユーザーからのリクエスト
• 会話のステータス
• 現在のタイムスタンプ
• 取得したパッセージ（文章）
• ツールの出力結果
• ユーザー固有のデータ
• ダイナミックな ID

この順序が重要なのは、プロンプトの初期部分を変更すると、再利用可能なプレフィックスが無効化されてしまうからです。

適切に構造化されたプロンプトは、繰り返し発生する長いコンテキストを毎回ゼロから処理してコストを払う代わりに、キャッシュヒットとして扱えるようにします。

# 6. キャッシュ層の複数導入

プロンプトキャッシングは有用ですが、システム内で唯一のキャッシュ手段にしてはいけません。

本番環境で稼働する LLM アプリケーションでは、複数のキャッシュ層を設けることで大きな恩恵が得られます：

// 完全一致レスポンスキャッシュ

同一のリクエストに対する回答を保存します。

これは以下のような安定した質問に対して特に効果的です：

• 「料金プランはどのようなものですか？」
• 「パスワードの再設定方法を知りたいです」
• 「返金ポリシーについて教えてください」

古くなった回答が indefinitely（無期限に）提供されないよう、バージョン管理と有効期限（TTL）を設定してください。

// 意味的キャッシュ

新しいリクエストが過去のものと非常に類似している場合、その答えを再利用できるのが意味的キャッシュです。

例えば：

• 「メールアドレスの変更方法を教えてください」
• 「アカウントのメールアドレスを更新できますか？」

言葉遣いは異なりますが、回答内容は同じであるケースが多いでしょう。

この手法はカスタマーサポートや社内ナレッジベース、繰り返し発生する情報問い合わせにおいて有用ですが、厳格な類似度閾値の設定、テナント間の分離（アイソレーション）、コンテンツのバージョン管理、そして評価チェックが不可欠です。

// 検索キャッシュ

埋め込みベクトル、検索結果、再ランク付けの結果、および文書チャンクを、繰り返し行われるクエリに対してキャッシュします。

// ツール結果キャッシュ

多くのエージェントツールは、決定論的またはゆっくりと変化するデータを生成します。鮮度要件が許す範囲であれば、API の出力やデータベースクエリ、商品検索結果、ウェブ検索結果などの出力をキャッシュしてください。

目指すべきはシンプルです。システムがすでに情報を把握している内容を、モデルに繰り返し処理させるのを避けることです。

# 7. RAG コンテキスト予算の管理

RAG（検索拡張生成）は精度向上に寄与しますが、逆にレイテンシとコストの主要な要因にもなり得ます。

典型的な失敗パターンは以下の通りです。

• 取得するドキュメント数が多すぎる
• リランキングを行わずに完全なパッセージを追加する
• 重複するチャンクを含める
• 会話履歴をすべて保持する
• 生のツール出力や HTML をそのまま追加する
• 「万一のために」と、すべての情報をモデルに送信してしまう

その結果、処理コストが高くつき、生成速度も遅くなる巨大なプロンプトが作成され、さらにモデルが関連性の低い情報の中から検索しなければならないため、精度が低下することさえあります。

代わりに「コンテキスト予算」の概念を導入しましょう。

• 取得するドキュメント数を減らす
• モデルに送信する前にリランキングを行う
• 重複するチャンクを統合・削除する
• ナビゲーションテキストや定型文、HTML を除去する
• 過去の会話については要約を用いる
• 現在の意思決定に必要なツール出力のみを含める
• システム指示、取得コンテキスト、チャット履歴、生成出力に対してそれぞれ独立したトークン予算を設定する

コンテキスト量が多ければ良いというわけではありません。

# 8. 非対話型タスクのバッチ処理への移行

すべての LLM タスクが即時応答を必要とするわけではありません。

データラベリング、評価実行、一括要約、レポート生成、ナレッジベースの処理、夜間ワークフロー、大規模な抽出などといったタスクは、通常非同期で実行すべきです。

バッチ処理を活用すればコストを削減でき、バックグラウンドの負荷が対話型ユーザーのトラフィックに悪影響を与えるのを防げます。リアルタイムシステムは、ユーザーに直接影響するリクエストに集中させるべきです。オフラインジョブは優先度の低いキューやバッチ API、スケジュールされたワーカーへ送ってください。

この分離により、ユーザー体験が向上すると同時に、インフラの利用率も予測可能になります。

# 9. レイテンシ最適化のためのバッチ調整（スループットのみ追求しない）

バッチ処理は GPU が複数のリクエストを効率的に処理するのを助けます。ただし、バッチサイズが大きいほど自動的に良いわけではありません。

過度なバッチ処理はスループットを向上させる一方で、キュー待ち時間を延ばし、TTFT（First Token Time）を悪化させる可能性があります。GPU 利用率の観点からはシステムが効率的に見えても、ユーザーにとっては応答が遅いという結果になりかねません。

バッチ設定は、ユーザー facing のサービスレベル目標に基づいて調整してください：

• 許容される最大キュー待ち時間
• P95 および P99 の TTFT
• トークン間レイテンシ（Inter-token latency）
• 並行リクエスト数
• プロンプトと出力の平均長さ
• 対話型タスクとバックグラウンドワークの優先度

自社ホスト型のモデルでは、完了したリクエストがバッチから離れながら新しいリクエストが入ってくる「連続バッチ処理（Continuous Batching）」や「実行中バッチ処理（In-flight Batching）」が有効なケースが多いです。

目指すべきは GPU 利用率の最大化ではありません。許容範囲のコスト内で、最高のユーザー体験を提供することこそがゴールです。

#10. キーバリューキャッシュとコンテキスト長の慎重な管理

長文コンテキストを扱うワークロードは、GPU メモリをあっという間に消費してしまいます。キーバリュー（KV）キャッシュはトークン生成に必要な情報を保持する領域ですが、コンテキストウィンドウの拡大や並行リクエスト数の増加に伴い、これがインフラ上の大きなボトルネックになります。

具体的には以下のような問題が発生します。

• メモリ圧迫
• リクエストの停止（プリエンプション）
• キャッシュの強制削除（イジェクト）
• 処理速度の低下
• 並行処理能力の減少
• メモリ不足によるエラー

これらの課題に対処するには、以下の項目に対して現実的な制限値を設定する必要があります。

• 最大コンテキスト長
• 最大生成出力長
• 同時実行可能なリクエスト数
• ユーザーごとの会話履歴保存量
• 検索して取得するチャンク数
• ツールからの出力サイズ

ページド KV キャッシュや、キャッシュの量子化（quantization）、メモリ状況に応じたスケジューリングなどの技術は有効な手段となり得ますが、これらが自社の実際のワークロードで効果を発揮するかは、必ず実環境で検証してください。

モデルが巨大なコンテキストウィンドウをサポートしているからといって、無理にそれを全リクエストで使うべきではありません。実際には、すべてのリクエストで最大値を利用する必要がないケースがほとんどです。

#11. 本番トラフィックでのサービング最適化のベンチマーク

セルフホスト型の LLM サービングスタックには、パフォーマンス向上のための多彩な機能が用意されています。

• 量子化（Quantization）
• スペキュラティブ・ディコーディング（Speculative decoding）
• テンソル並列とパイプライン並列
• プレフィックスキャッシュ
• チャンクドプリフィル（Chunked prefill）
• プリフィル/デコードの分離（Disaggregation）
• フラッシュアテンション（Flash attention）と連続バッチ処理

これらの機能はパフォーマンスを向上させる可能性がありますが、すべてのケースで万能に働くわけではありません。

例えば、スペキュレティブ・ディコーディング（推測的デコーディング）は特定のワークロードではスループットを向上させる一方で、別のワークロードではオーバーヘッドを増加させたりキャッシュ効率を低下させたりする可能性があります。テンソル並列処理は大規模モデルを複数の GPU に分散させるのに役立ちますが、通信オーバーヘッドを引き起こす恐れがあります。量子化（Quantization）もメモリ使用量を削減できますが、ハードウェアの種類によって品質や速度への影響は異なります。

変更を加える際は、実際の生産環境のトラフィックを反映したベンチマークで検証してください。

• 実際のプロンプト長
• 実際の出力長
• 実際の並行処理数
• 実際のキャッシュヒット率
• 実際の検索動作
• 実際の P95 および P99 レイテンシ目標

単なる孤立したベンチマークの数値や、トークン/秒という指標だけを頼りにしてはいけません。

# 12. 受付制御と段階的な機能低下の追加

トラフィックの急増は、通常は高速で安価な LLM システムを、遅く高コストなものに変えてしまいます。

本番環境のアプリケーションでは、リソースが限られた場合にどう対処すべきかを明確にしておく必要があります。有効な制御手段としては以下が挙げられます。

• ユーザーごとのレート制限
• リクエストサイズの上限設定
• 最大出力長の制限
• プライオリティキューの実装
• 並行処理数とリトライ回数の制限
• 過負荷時のバックプレッシャー（抑制）
• 小規模モデルへのフォールバック
• レスポンスの詳細度の一時的な低下
• 非クリティカルなリクエストの遅延処理

例えば、高負荷時には以下のような対応が可能です。

• オプションのエージェントステップを無効化する
• 最大出力長を縮小する
• 優先度の低いユーザーを小規模モデルへルーティングする
• バックグラウンドでの情報補完を遅らせる
• 詳細なレポートではなく、簡潔な回答を返す

すべてのリクエストをキューに積み上げてシステム全体が使えなくなる状態にするよりも、段階的に機能を低下させる（グレースフル・デグラデーション）方がはるかに優れています。

結びの言葉

LLM の最適化において最も効果的な戦略とは、単に高速なモデルを使うことでも、GPU を増設することでもありません。重要なのは、モデルが不必要な作業を行わないようにシステムを設計することです。

具体的には、出力トークンの数を減らし、呼び出しの重複を防ぎ、キャッシュされたプレフィックスやレスポンスを再利用し、コンテキストサイズを適切に制御します。また、単純なタスクは小規模なモデルへルーティングし、バッチ処理とユーザー向けのトラフィックを分離しましょう。インフラチューニングにおいては、GPU の利用率だけでなく、P95 や P99 レイテンシ（遅延）の観点から最適化を行うことが不可欠です。

これらの基本が整っていれば、ユーザーが重視する品質を損なうことなく、LLM アプリケーションをより高速かつ低コストで、そして信頼性の高いものへと進化させることができます。