Cómo transmitir respuestas de LLM con SSE y fragmentos de uso
Traducción automática
Este artículo se tradujo automáticamente a partir de la versión original en inglés.
Para transmitir una respuesta de LLM de forma incremental, analiza el protocolo de eventos del servidor, ensambla los deltas de contenido y actualiza la pantalla a medida que llega texto utilizable. Muchas APIs usan Server-Sent Events, o SSE. Una lectura HTTP puede contener parte de un evento o varios eventos. Un evento puede contener varios tokens del modelo.
Las implementaciones del cliente necesitan almacenamiento temporal y gestión de la finalización, además de una primera actualización rápida.
Analiza los eventos antes que los datos del modelo
El formato SSE usa líneas como data: y termina cada evento con una línea en blanco. Las lecturas de red pueden dividir esas líneas o combinar varios eventos. Almacena temporalmente el texto incompleto, identifica los eventos completos y después analiza los datos específicos de la API. Varias líneas data: pertenecen a un mismo evento.
En OpenAI Chat Completions, el contenido llega en forma de deltas que el cliente ensambla en un mensaje. Procesa los deltas de tool calls o los deltas estructurados según sus campos, en lugar de tratar cada evento como prosa. El marcador [DONE] es una convención de la API, no un requisito general de SSE.
Un orden útil de procesamiento en el cliente es:
- Decodifica los bytes entrantes sin perder un carácter UTF-8 dividido entre lecturas.
- Almacena los datos temporalmente hasta disponer de un evento SSE completo.
- Interpreta ese evento con el esquema de la API seleccionada.
- Añade el contenido o los campos estructurados a la respuesta ensamblada.
- Actualiza la pantalla al alcanzar un límite adecuado del búfer.
Separa la representación, la finalización y el uso
Muestra la prosa cuanto antes cuando sea posible. Almacena temporalmente las construcciones Markdown o las líneas de código incompletas si darles formato de inmediato provoca cambios repetidos en la disposición. Registra el inicio de la solicitud y el primer contenido generado por separado del momento de apertura de la conexión o de un evento que solo contiene metadatos.
En la API de chat de OpenAI, stream_options: {"include_usage": true} solicita un fragmento final de uso antes de [DONE]. Ese fragmento tiene un array de opciones vacío. Las transmisiones interrumpidas o canceladas pueden no entregarlo nunca, por lo que la ausencia de datos de uso no puede interpretarse como cero tokens.
Los servidores compatibles con OpenAI pueden implementar otros formatos de datos o comportamientos de finalización. Prueba eventos fragmentados, varios eventos por lectura, deltas vacíos, cancelaciones, errores del servidor y la ausencia de datos finales de uso con la implementación cuya versión has fijado. Conserva el texto ya recibido y distingue una respuesta incompleta de una finalización correcta.
Guía de ingeniería: transmisión incremental en la práctica relaciona el comportamiento del cliente con TTFT, TPOT y la planificación del prefill.