El streaming es una decisión de producto, no de rendimiento
El streaming no hace el modelo más rápido. Cambia lo que el usuario hace mientras espera — y ese es todo el punto.
Una respuesta en streaming y una en buffer terminan al mismo tiempo. Los tokens llegan al mismo ritmo en ambos casos. Lo que cambia es que con streaming el usuario empieza a leer en el token uno en vez del token novecientos.
Esa distinción importa más de lo que suena, porque decide dónde inviertes esfuerzo de ingeniería.
Qué te compra realmente el streaming
El usuario puede abandonar temprano. La mitad del valor de una respuesta en streaming es que a las tres frases alguien se da cuenta de que va en la dirección equivocada y la detiene — algo que no puede hacer si lo primero que ve es la salida terminada.
También convierte una espera inexplicada en progreso visible. Un spinner de doce segundos y una respuesta que se escribe sola durante doce segundos se sienten como productos distintos, y solo a uno de los dos lo acusan de estar roto.
Qué cuesta
El streaming complica el manejo de errores de una forma que la mayoría de implementaciones resuelve mal. Una vez que enviaste bytes al cliente no puedes recuperarlos — así que un fallo a mitad de camino no es un request fallido que puedes reintentar, es una respuesta a medio escribir que el usuario ya está leyendo.
Tienes que decidir cómo se ve eso antes de lanzar. Agregar una frase simple al stream suele ser mejor que el silencio, y siempre mejor que un error lanzado que el cliente renderiza como una caja en blanco.
Cuándo no hacer streaming
Si la salida es estructurada y la UI no puede renderizarla parcialmente, el streaming no compra nada y cuesta complejidad. Un payload JSON que solo cobra sentido una vez completo debería ser un request normal — muestra un estado de carga real y ahórrate la maquinaria.
La pregunta no es "¿esto es lento?". Es "¿puede el usuario hacer algo útil con una respuesta parcial?".