Como funciona o streaming de respostas em agentes de IA

Quem já integrou um modelo de linguagem numa aplicação conhece a cena: o usuário manda o prompt, a tela fica em branco por alguns segundos e, de repente, a resposta inteira aparece de uma vez. Um vídeo publicado em 3 de novembro pelo canal AWS Developers, no YouTube, explica por que a maioria dos apps de IA evita essa espera e mostra, com três demonstrações práticas, como reproduzir o mesmo comportamento num agente próprio.

O modelo não fica mais rápido, só parece

O ponto de partida é uma correção de expectativa: streaming não acelera o modelo. Um LLM já gera a resposta token por token internamente, cada token previsto a partir de tudo que veio antes. O que muda é o momento em que cada pedaço chega até quem está esperando: em vez de guardar a resposta inteira no servidor até o último token sair, cada token é enviado assim que é produzido.

A métrica que essa mudança ataca tem nome: time to first token (TTFT). É o intervalo entre o envio do prompt e a chegada do primeiro pedaço de resposta visível. Sem streaming, o TTFT é praticamente igual ao tempo total de geração. Com streaming, o TTFT cai para a duração de só o primeiro token, e o resto da resposta vai preenchendo a tela enquanto o modelo continua trabalhando.

Em resumo: o usuário não espera menos tempo pela resposta completa, mas passa a ver progresso desde os primeiros milissegundos, e é essa sensação de progresso que reduz a percepção de lentidão.

Por baixo do capô: conexão aberta e SSE

Para tokens chegarem aos poucos, a conexão entre o cliente e o servidor precisa ficar aberta durante toda a geração, em vez de abrir, receber uma resposta e fechar como numa chamada REST tradicional. O servidor empurra cada token pela conexão assim que ele é produzido, normalmente usando HTTP streaming (uma resposta com Transfer-Encoding: chunked) ou Server-Sent Events (SSE), o protocolo baseado em texto que mantém o navegador recebendo eventos do servidor sem precisar de WebSocket.

Isso significa trade-off de infraestrutura: conexões que ficam abertas por segundos ou minutos consomem recursos de forma diferente de requisições curtas, e proxies, load balancers e timeouts precisam estar configurados para não derrubar a conexão no meio da geração. Para quem roda agentes atrás de API Gateway, ALB ou Lambda Function URLs na AWS, essa é a primeira coisa a verificar antes de ativar streaming em produção: o componente de borda precisa suportar resposta em chunks sem buferizar tudo antes de entregar.

Três formas de receber os tokens

O vídeo usa o Strands Agents SDK, o framework open-source da AWS para construir agentes em Python, para mostrar três cenários equivalentes ao mesmo prompt, cada um entregando os tokens de um jeito diferente.

Demo 1: sem streaming, resposta pronta

Com callback_handler=None na criação do agente, o SDK desliga qualquer emissão incremental e devolve a resposta só quando a geração termina:

from strands import Agent

agent = Agent(callback_handler=None)
response = agent("Explique consistência eventual em bancos distribuídos")
print(response)

É o comportamento padrão de quem só quer o resultado final, sem interface alguma acompanhando o progresso, útil em jobs em lote ou chamadas de agente para agente onde ninguém está olhando a tela.

Demo 2: streaming direto no console

Trocando a chamada síncrona por stream_async(), o agente passa a devolver um gerador assíncrono que entrega cada evento assim que o token correspondente é gerado:

async for event in agent.stream_async("Explique consistência eventual"):
    if "data" in event:
        print(event["data"], end="", flush=True)

O efeito no terminal é o texto aparecendo palavra por palavra, o mesmo padrão visual de uma CLI de chat.

Demo 3: streaming para o navegador, com FastAPI

A terceira demonstração liga esse mesmo stream_async() a um endpoint FastAPI, usando StreamingResponse para repassar cada token para o navegador via SSE:

from fastapi import FastAPI
from fastapi.responses import StreamingResponse

app = FastAPI()

@app.get("/chat")
async def chat(prompt: str):
    async def token_stream():
        async for event in agent.stream_async(prompt):
            if "data" in event:
                yield event["data"]
    return StreamingResponse(token_stream(), media_type="text/event-stream")

Esse é o padrão que sustenta a maioria das interfaces de chat baseadas em IA que o leitor já usou, em que a resposta vai sendo preenchida na tela aos poucos, pedaço por pedaço, enquanto o modelo continua gerando o restante.

O preço do streaming: erros e guardrails no meio do caminho

Streaming resolve percepção de latência, mas cria um problema novo: o que fazer quando a geração falha depois que parte da resposta já foi mostrada para o usuário. Sem streaming, um erro de geração pode ser capturado e tratado antes de qualquer coisa chegar à tela. Com streaming, o usuário já viu meia resposta quando o erro acontece, e a aplicação precisa decidir se completa, se avisa ou se apaga o que já foi exibido.

O mesmo vale para guardrails de conteúdo: validações que checam a resposta inteira antes de liberá-la (bloqueio de dados sensíveis, checagem de política de uso) funcionam mal com streaming, porque o texto é liberado em pedaços antes de existir uma resposta completa para validar. Na prática, isso significa escolher entre validar cada chunk isoladamente, aceitar um atraso de buffer para validar em lotes menores, ou aplicar o guardrail só depois, como auditoria.

Quando vale a pena streamar

O vídeo fecha com um critério direto, que separa bem os dois cenários:

• Vale streaming: interfaces de chat, assistentes conversacionais, qualquer lugar onde um humano está olhando a tela em tempo real e a sensação de progresso importa mais do que a velocidade total.
• Não vale streaming: extração de dados estruturados, chamadas de agente para agente, pipelines em lote e qualquer fluxo onde o consumidor da resposta é código, não gente, e precisa da saída completa e validada antes de agir.

Para quem desenvolve agentes com Strands, Bedrock ou qualquer outro runtime de LLM na AWS, essa divisão é o primeiro filtro antes de decidir a arquitetura: streaming melhora a experiência de quem está esperando na tela, mas adiciona complexidade de tratamento de erro e validação que só compensa quando existe, de fato, alguém esperando.

Fonte: YouTube — AWS Developers