Streaming não torna seu modelo mais rápido. Ele faz a espera parecer mais curta. O tempo total para gerar uma resposta é praticamente idêntico, com ou sem streaming. O que o streaming muda é quando o usuário vê o primeiro token, e esse único número, time to first token, direciona toda a percepção de velocidade. Trate streaming como uma decisão de UX, porque é isso que é, e você tomará decisões melhores sobre quando usá-lo e quando ele realmente atrapalha.

O reflexo é recorrer a InvokeModelWithResponseStream ou ConverseStream porque streaming parece a escolha performática. Mas o modelo produz os mesmos tokens no mesmo tempo total de qualquer forma. Você não está otimizando throughput. Você está decidindo se um humano encara uma tela em branco por seis segundos ou vê texto aparecer depois de trezentos milissegundos.

Por que time to first token é o número que importa

Uma resposta não transmitida em streaming tem uma latência que o usuário sente: a geração inteira, do início ao fim. Peça três parágrafos e o usuário espera tudo aparecer de uma vez. Essa espera é lida como o sistema sendo lento, mesmo quando o tempo total é razoável.

Streaming divide isso em dois números. Time to first token é quanto tempo até algo aparecer. Depois os tokens chegam continuamente, e como as pessoas leem mais devagar do que um modelo gera, o texto tende a ficar à frente do leitor. A experiência percebida é "instantânea e fluida" mesmo que o tempo total de geração não tenha mudado. É a mesma psicologia de uma barra de progresso: movimento é lido como progresso, e uma tela em branco é lida como travamento. Para qualquer coisa conversacional, onde uma pessoa está lendo o output como prosa, streaming é quase obrigatório só por esse motivo.

Onde o streaming silenciosamente piora as coisas

Streaming é um padrão, não uma lei. Vários casos comuns são melhor atendidos esperando pela resposta completa.

Output estruturado que o cliente precisa fazer parsing

Se a resposta é JSON que seu frontend desserializa, um stream parcial é inútil ou prejudicial. Você não consegue fazer parsing de metade de um objeto JSON, e mostrar ao usuário uma estrutura pela metade é pior do que mostrar um spinner. Quando quem consome o output é código, não um leitor, espere pela coisa inteira e faça o parsing uma vez. Streaming não te traz nada e adiciona o risco de renderizar um estado parcial malformado.

Uso de ferramentas dentro de um agente

Quando um modelo transmite em streaming a decisão de chamar uma ferramenta, não há nada para o usuário ler: o "output" é uma invocação de ferramenta, não prosa. Transmitir em streaming os tokens de uma chamada de função para a UI mostra ao usuário maquinaria que ele não pediu para ver. O padrão certo é transmitir em streaming a resposta final voltada ao usuário e manter o raciocínio intermediário da chamada de ferramenta fora da tela, ou representá-lo como um status tipo "verificando seu pedido", não como tokens brutos transmitidos.

Respostas curtas

Se a resposta é uma frase, streaming adiciona complexidade de protocolo sem ganho perceptível. A coisa inteira chega em algumas centenas de milissegundos de qualquer forma. Guarde o encanamento de streaming para respostas longas o suficiente para que a espera seria de fato sentida.

O custo que você assume ao fazer streaming

Streaming não é engenharia de graça. Você mantém uma conexão aberta durante a duração toda, o que muda como você pensa sobre timeouts, retries e load balancing. O tratamento de erro fica mais difícil: uma falha no meio de um stream deixa o usuário com uma resposta truncada que você precisa detectar e recuperar, versus uma falha limpa e completa em uma chamada bufferizada. E você não consegue rodar uma verificação de output do Guardrails ou uma validação de JSON em uma resposta que você já mostrou ao usuário token por token. Se validação importa, ou você faz buffer, ou valida enquanto transmite e fica pronto para retratar, o que é trabalho de verdade. Pese isso contra o ganho de UX em vez de assumir que streaming é estritamente melhor.

Reduza o número em vez disso, às vezes

Se o problema é genuinamente que o primeiro token demora demais, streaming esconde isso mas não conserta. Prompt caching conserta: fazer cache do prefixo estável de um prompt longo corta o tempo antes da geração começar, o que reduz diretamente o time to first token. Em um agente fortemente prompted, cortar e fazer cache do prompt pode fazer mais pela velocidade percebida do que streaming faz, e ajuda também nos casos não transmitidos e estruturados.

A conclusão

Streaming não muda quão rápido seu modelo roda. Muda o time to first token, o que muda quão rápido o sistema parece, então é uma decisão de UX. Transmita em streaming prosa conversacional onde um humano está lendo. Não transmita em streaming output estruturado que um cliente precisa fazer parsing, raciocínio bruto de chamada de ferramenta, ou respostas de uma linha. E quando a latência do primeiro token é a reclamação real, faça cache do prompt para reduzir o número em vez de usar streaming para disfarçá-lo.

Leia isto a seguir

Para a infraestrutura por trás de conexões de longa duração e latência na borda, as notas de campo de nuvem estão em ercan.cloud, e o hub está em ercanermis.com.