Lo streaming non rende il tuo modello più veloce. Rende l'attesa più breve percepita. Il tempo totale per generare una risposta è quasi identico che tu la trasmetta in streaming o no. Ciò che lo streaming cambia è quando l'utente vede il primo token, e quel singolo numero, il time to first token, guida l'intera percezione di velocità. Tratta lo streaming come una decisione UX, perché è esattamente quello che è, e farai scelte migliori su quando usarlo e quando invece danneggia attivamente.

Il riflesso è ricorrere a InvokeModelWithResponseStream o ConverseStream perché lo streaming sembra la scelta performante. Ma il modello produce gli stessi token nello stesso tempo totale in entrambi i casi. Non stai ottimizzando il throughput. Stai decidendo se un essere umano fissa uno schermo vuoto per sei secondi o guarda il testo apparire dopo trecento millisecondi.

Perché il time to first token è il numero che conta

Una risposta non in streaming ha una sola latenza che l'utente percepisce: l'intera generazione, dall'inizio alla fine. Chiedi tre paragrafi e l'utente aspetta tutto prima che appaia qualcosa. Quell'attesa si legge come sistema lento, anche quando il tempo totale va bene.

Lo streaming divide questo in due numeri. Il time to first token è quanto tempo passa prima che appaia qualcosa. Poi i token arrivano continuamente, e poiché le persone leggono più lentamente di quanto un modello generi, il testo tende a rimanere avanti rispetto al lettore. L'esperienza percepita è "istantanea e fluida" anche se il tempo totale di generazione non è cambiato. Questa è la stessa psicologia di una barra di avanzamento: il movimento si legge come progresso, e uno schermo vuoto si legge come un blocco. Per qualsiasi cosa conversazionale, dove una persona legge l'output come prosa, lo streaming è quasi obbligatorio solo per questo motivo.

Dove lo streaming peggiora silenziosamente le cose

Lo streaming è un default, non una legge. Diversi casi comuni sono serviti meglio aspettando la risposta completa.

Output strutturato che il client deve analizzare

Se la risposta è JSON che il tuo frontend deserializza, uno stream parziale è inutile o dannoso. Non puoi analizzare metà di un oggetto JSON, e mostrare all'utente una struttura mezza costruita è peggio che mostrargli uno spinner. Quando il consumatore dell'output è codice, non un lettore, aspetta il tutto e analizzalo una volta sola. Lo streaming non ti porta nulla e aggiunge il rischio di renderizzare uno stato parziale malformato.

Uso di tool dentro un agente

Quando un modello trasmette in streaming una decisione di chiamare un tool, non c'è nulla da leggere per l'utente: l'"output" è un'invocazione di tool, non prosa. Trasmettere in streaming i token di una chiamata di funzione all'interfaccia mostra all'utente meccanismi interni che non ha chiesto di vedere. Il pattern giusto è trasmettere in streaming la risposta finale rivolta all'utente e tenere il ragionamento intermedio sulla chiamata di tool fuori dallo schermo, o rappresentarlo come uno stato tipo "sto controllando il tuo ordine", non come token grezzi in streaming.

Risposte brevi

Se la risposta è una frase, lo streaming aggiunge complessità di protocollo senza guadagno percepibile. Tutto arriva in poche centinaia di millisecondi in entrambi i casi. Riserva l'infrastruttura di streaming a risposte abbastanza lunghe da far percepire l'attesa altrimenti.

Il costo a cui ti iscrivi quando fai streaming

Lo streaming non è ingegneria gratuita. Mantieni una connessione aperta per la durata, il che cambia il modo in cui pensi a timeout, retry e load balancing. La gestione degli errori diventa più difficile: un fallimento a metà di uno stream lascia l'utente con una risposta troncata che devi rilevare e da cui devi recuperare, contro un fallimento pulito e netto su una chiamata bufferizzata. E non puoi eseguire un controllo di output Guardrails o una validazione JSON su una risposta che hai già mostrato all'utente token per token. Se la validazione conta, o bufferizzi, o validi mentre trasmetti in streaming e sei pronto a ritrattare, il che è lavoro vero. Pesa questo contro il guadagno UX invece di assumere che lo streaming sia sempre strettamente migliore.

A volte, abbassa il numero invece

Se il problema è genuinamente che il primo token impiega troppo, lo streaming lo nasconde ma non lo risolve. Il prompt caching sì: mettere in cache il prefisso stabile di un prompt lungo taglia il tempo prima che inizi la generazione, il che abbassa direttamente il time to first token. Su un agente pesantemente promptato, tagliare e mettere in cache il prompt può fare più per la velocità percepita di quanto faccia lo streaming, e aiuta anche i casi non in streaming e strutturati.

Il punto chiave

Lo streaming non cambia quanto velocemente gira il tuo modello. Cambia il time to first token, il che cambia quanto veloce sembra il sistema, quindi è una decisione UX. Trasmetti in streaming la prosa conversazionale dove un umano sta leggendo. Non trasmettere in streaming output strutturato che un client deve analizzare, ragionamento grezzo sulla chiamata di tool, o risposte di una riga. E quando la latenza del primo token è la vera lamentela, metti in cache il prompt per abbassare il numero invece di trasmettere in streaming per mascherarlo.

Leggi questo dopo

Per l'infrastruttura dietro le connessioni a lunga durata e la latenza ai bordi della rete, le field notes cloud sono su ercan.cloud, e l'hub è su ercanermis.com.