Skip to main content

Descripción general

El streaming entrega la salida de forma incremental. Usa Responses streaming cuando el modelo anuncia un contrato Responses nativo y existe una ruta upstream del mismo protocolo; en caso contrario, usa Chat Completions o el protocolo nativo que publique el modelo.

Recomendado: Responses Streaming

Límites de streaming de Responses y Gemini

En Responses SSE, TokenLab conserva los nombres, el orden y los campos de los eventos upstream y lee usage y el estado terminal fuera de banda, sin cambiar el wire. Después del primer evento entregado no prueba otro canal ni otra credencial. Responses WebSocket acepta solo eventos oficiales response.create. Stream es implícito; background y response.cancel no se ofrecen en este transporte, y background funciona solo por HTTP. Cada conexión es serial, no admite multiplexing y tiene un límite de 60 minutos. Gemini SSE conserva fragmentos nativos. Son válidos los eventos solo de metadatos, los fragmentos intermedios sin finishReason y el EOF natural; TokenLab no añade un marcador Chat [DONE].

Streaming de Chat Completions

Si tu framework aún espera fragmentos SSE de /v1/chat/completions, eso también funciona:

Condiciones de finalización del stream

Condiciones típicas de finalización:
  • response.completed para streams de Responses API
  • finish_reason: "stop" para streams de Chat Completions
  • finish_reason: "length" cuando se alcanza un límite de token
  • eventos de llamada a tool/function cuando el modelo quiere usar herramientas

Patrón para aplicaciones web

Mejores prácticas

Usa /v1/responses si tu SDK o aplicación ya lo admite. Mantén el streaming de /v1/chat/completions para integraciones impulsadas por compatibilidad.
Agrega fragmentos delta a la UI o al terminal a medida que llegan en lugar de esperar la respuesta completa.
Trata las caídas de red y las desconexiones del upstream como modos de fallo normales y vuelve a conectar con cuidado en sesiones de larga duración.