LLMストリーミング(エルエルエムストリーミング)
LLMが生成したトークンを全文完成を待たずに逐次クライアントへ送信する出力方式。ユーザーの体感待ち時間を大幅に短縮し、ChatGPTやClaudeなどの対話型AIサービスで標準的に採用されている。
LLMストリーミングとは
LLMストリーミングは、大規模言語モデル(LLM)が生成したテキストをトークン単位でリアルタイムにクライアントへ送信する技術です。従来の「全文生成完了後に一括返却」方式では、1,000トークンの回答生成に3〜10秒の待ち時間が発生しますが、ストリーミングでは最初のトークンが生成された時点(通常100〜500ms)で表示が始まるため、ユーザーの体感応答時間を劇的に改善します。
ストリーミングの仕組み
トークン生成とAutoregressive デコーディング
LLMはautoregressive(自己回帰的)にテキストを生成します。つまり、1トークンずつ順番に生成し、各トークンの生成には直前までのすべてのトークンが入力として必要です。この特性がストリーミングを自然に可能にしています。
| 処理段階 | 所要時間(目安) | 説明 |
|---|---|---|
| プリフィル(Prefill) | 50〜500ms | 入力プロンプト全体を並列処理しKVキャッシュを構築 |
| 最初のトークン生成 | 10〜50ms | プリフィル完了後、最初の出力トークンを生成 |
| 後続トークン生成 | 10〜30ms/token | 1トークンずつ逐次生成(Inter-Token Latency) |
| 全文完成 | 1〜30秒 | トークン数×ITLの合計時間 |
TTFT と ITL
ストリーミング性能を測る2つの主要メトリクスがあります。
- TTFT(Time To First Token): プロンプト送信から最初のトークンが返るまでの時間。ユーザーの「応答が始まった」という体感に直結し、500ms以下が理想
- ITL(Inter-Token Latency): トークン間の生成間隔。人間の読速度(約250ms/単語)より短ければ、テキストが滑らかに流れるように見える
GPT-4oのTTFTは約200〜400ms、Claude 3.5 Sonnetは約300〜600ms、Gemini 1.5 Proは約200〜500msが典型的な値です。
通信プロトコル
Server-Sent Events(SSE)
ストリーミングの標準的な通信手段はSSE(Server-Sent Events)です。HTTPの単方向ストリームで、サーバーからクライアントへテキストイベントを連続送信します。OpenAI、Anthropic、Google(Gemini)の各APIはすべてSSEをサポートしています。
WebSocket
双方向通信が必要な場合(例: ユーザーが生成途中でプロンプトを追加する)にはWebSocketが使われます。Realtimeオーディオ対話(OpenAI Realtime API)やマルチモーダルストリーミング(Gemini Live)で採用されています。SSEより実装が複雑ですが、中断・再開・双方向制御が可能です。
gRPC ストリーミング
高性能な推論サーバー(NVIDIA Triton Inference Server、vLLM)ではgRPCのサーバーストリーミングRPCが使われます。Protocol BuffersによるバイナリシリアライゼーションでSSEより低オーバーヘッドですが、ブラウザからの直接接続には対応していないため、バックエンド間通信に限定されます。
主要APIのストリーミング実装
OpenAI API
stream: true パラメータでストリーミングを有効化します。レスポンスはSSE形式で、各イベントの data フィールドに ChatCompletionChunk オブジェクトが含まれます。最終チャンクには finish_reason が設定され、その後 data: [DONE] が送信されます。
Anthropic Messages API
stream: true でストリーミングが有効になり、message_start、content_block_start、content_block_delta、content_block_stop、message_stop の5種類のイベントが送信されます。content_block_delta の delta.text フィールドにトークンテキストが含まれます。
Google Gemini API
generateContent の代わりに streamGenerateContent エンドポイントを使用します。各チャンクに candidates[0].content.parts[0].text でテキストが格納されます。
ストリーミングの課題
トークン数のカウント
ストリーミング中はトークンが逐次送信されるため、合計トークン数の正確な把握が困難です。多くのAPIでは最終チャンクまたはストリーム完了後に usage オブジェクトで正確なトークン数を返します。
エラーハンドリング
ストリーム途中でサーバーエラーが発生した場合、部分的なレスポンスだけがクライアントに届きます。リトライ戦略として、受信済みテキストをプレフィックスとして再送し、続きから生成させる手法が一般的です。
構造化出力との両立
JSON Schema に準拠した構造化出力をストリーミングする場合、部分的なJSONが逐次送信されるため、クライアント側でパーシャルパースが必要です。OpenAIとAnthropicの最新APIでは、構造化出力モードでもストリーミングが可能です。
FAQ
Q1: ストリーミングと非ストリーミングで生成結果は変わる?
A1: 生成結果は同一です。ストリーミングは出力の送信方式を変えるだけで、モデルの推論処理自体は変わりません。ただし、ストリーミングではHTTPコネクションの維持時間が長くなるため、プロキシやロードバランサーのタイムアウト設定に注意が必要です。
Q2: ストリーミングのほうがコストが高い?
A2: トークン課金は同一です。ただし、SSEコネクションの維持にサーバーリソースを消費するため、大量の同時接続がある場合はインフラコストが増加します。vLLMやTGIなどの推論サーバーは、Continuous Batching技術でこの問題を軽減しています。
Q3: ストリーミングを中断したら課金はどうなる?
A3: API提供者によって異なりますが、一般的には中断時点までに生成されたトークン分のみ課金されます。OpenAI APIでは途中中断しても生成済みトークンに対して出力トークン料金が発生します。