概要
Streaming は出力を段階的に配信します。モデルがネイティブ Responses 契約を公開し、同一プロトコルの upstream ルートがある場合に Responses streaming を使用してください。それ以外は Chat Completions またはモデルが公開するネイティブプロトコルを使用します。推奨: Responses Streaming
Responses と Gemini の streaming 境界
Responses SSE では upstream イベントの名前、順序、フィールドを保持し、wire を変えずに usage と終端状態を帯域外で読み取ります。最初のイベントを配信した後は、別の channel や credential を試しません。 Responses WebSocket が受け付けるのは公式のresponse.create イベントだけです。stream は暗黙で、この transport では background と response.cancel を提供しません。background は HTTP のみです。接続は直列で multiplexing を行わず、上限は 60 分です。
Gemini SSE はネイティブ chunk を保持します。metadata のみのイベント、finishReason のない中間 chunk、自然な EOF は有効で、Chat の [DONE] を追加しません。
Chat Completions ストリーミング
フレームワークが依然として/v1/chat/completions からの SSE チャンクを想定している場合でも、これも動作します。
ストリーム終了条件
一般的な完了条件:- Responses API ストリームでは
response.completed - Chat Completions ストリームでは
finish_reason: "stop" - token 制限に達した場合は
finish_reason: "length" - モデルがツールを使用したい場合の tool/function call イベント
Web アプリのパターン
ベストプラクティス
新規構築では Responses streaming を優先する
新規構築では Responses streaming を優先する
SDK またはアプリがすでに
/v1/responses をサポートしている場合は、それを使用してください。/v1/chat/completions のストリーミングは、互換性を重視した統合向けに維持してください。出力を段階的に flush する
出力を段階的に flush する
完全な応答を待つのではなく、到着した delta チャンクを UI またはターミナルに追加してください。
切断と再試行を処理する
切断と再試行を処理する
ネットワーク切断や上流側の切断は通常の障害モードとして扱い、長時間実行されるセッションでは慎重に再接続してください。