Quantas decisões cabem numa requisição do Jev? Como montar um orçamento de latência

Quase todo mundo erra a conta de latência de IA no mesmo ponto: soma decisão por decisão, como se toda pergunta tivesse que esperar a anterior responder

E aí a rota que "cabia" em 300ms vira 2 segundos em produção 😅

O Jev é um modelo de decisão tipada da TypeSafe AI: em vez de cuspir texto, ele responde perguntas do tipo Noul (sim/não com probabilidade), Choice e Score, e devolve probabilidades calibradas. A TypeSafe informa latência ponta a ponta entre 70ms e 500ms, medida a partir da Costa Oeste dos EUA, que é onde o serviço hospedado dela roda hoje, em região única (o modelo também aparece em outras plataformas, e a gente volta nisso no fim do post)

É um número bonito, só que sozinho ele não te diz nada sobre a SUA rota

Então bora fazer a conta direito: neste post a gente monta um orçamento de latência ponta a ponta, decisão por decisão, pra saber quantas decisões cabem de verdade numa requisição e quais delas dá pra rodar em paralelo

O que você precisa antes de montar o orçamento

Nada de PC da Nasa aqui, o setup é simples

SDK oficial, em Python ou em TypeScript/JavaScript:

# Python (requer Python 3.10+)
pip install typesafe-sdk

# TypeScript / JavaScript (requer Node.js 20 ou superior)
npm i @typesafe-ai/sdk

No SDK Python tu tens os clientes TypeSafeClient e AsyncTypeSafeClient, e o método client.system_one()

No SDK JS a chave vai na variável de ambiente TYPESAFE_API_KEY

O endpoint, que não é o de chat que tu já conhece:

POST https://api.typesafe.ai/v1/systemone

Se você já integrou API de LLM antes, repare na diferença: aqui não é /chat/completions, é um endpoint próprio de avaliação, que recebe um estado (o documento) e uma lista de perguntas

Noção de onde a sua aplicação roda. Chamando a API oficial da TypeSafe, o Jev é serviço hospedado em região única, na Costa Oeste dos EUA, então toda chamada faz round-trip até lá. Se o teu servidor está em São Paulo, esse tempo de rede entra no orçamento e ele não está incluído naquela faixa de 70ms a 500ms

Esse orçamento todo que a gente monta aqui assume a API oficial. Se tu chama o Jev por outro caminho documentado (Cloudflare AI, AI Gateway da Vercel), a parte de rede da conta muda e tu precisa medir na tua própria rota

E o alvo de latência da rota. Esse é o item que mais falta, sério. Antes de somar qualquer coisa, tu precisa do número que a rota pode gastar: 200ms? 800ms? 2s de job em background? Sem esse teto, orçamento vira achismo

Como montar o orçamento de latência da sua rota, passo a passo

A lógica é a mesma de orçamento de dinheiro: define o teto, lista os gastos, corta o que é desperdício e confere se sobra

1. Defina o teto da rota, em milissegundos. Escreve o número antes de olhar código. Se o produto diz que a resposta do endpoint precisa sair em 400ms, teu teto é 400ms e tudo que vem abaixo disputa esse espaço

O erro comum deste passo: definir o teto DEPOIS de medir, pra justificar o que já está lá

2. Liste todas as decisões da rota e marque a dependência real entre elas. Pergunta única pra cada par: a resposta de uma alimenta a próxima? Se a resposta é não, elas são independentes, mesmo que no teu código estejam em fila

É aqui que quase todo mundo descobre que 6 das 7 decisões nunca dependeram uma da outra, era só hábito de escrever linha embaixo de linha

O erro comum deste passo: confundir ordem de escrita com dependência de dados

3. Agrupe tudo que é independente numa única requisição. Dentro de uma requisição, as perguntas são avaliadas de forma independente e em paralelo: a resposta de uma nunca vira contexto da outra. E acrescentar uma quarta (ou uma décima quarta) pergunta quase não muda o tempo de resposta, custando apenas os tokens da própria pergunta

# client criado conforme a doc do SDK Python
client = TypeSafeClient()

resultado = client.system_one(
    state=documento,          # o estado vai UMA vez por requisição
    questions=perguntas,      # todas as decisões independentes juntas aqui
)

Por que isso muda tanto a conta? Porque o estado domina o custo. N chamadas de uma pergunta pagam o estado N vezes, em N round trips; a chamada em lote paga uma vez

O cookbook oficial de perguntas paralelas mostra isso com 13 perguntas (8 Noul, 2 Choice e 3 Score) sobre o artigo da Wikipédia do GDPR: numa única requisição, saiu 12,2x mais barato e 10,0x mais rápido do que 13 chamadas separadas, sem mudança nas respostas

Mesmas perguntas, mesmas respostas, um décimo do tempo. Massa demais

O erro comum deste passo: manter o loop for que dispara uma chamada por pergunta porque "funciona"

4. Conte as requisições encadeadas que sobraram e multiplique pelo PIOR caso. Depois do agrupamento, o que sobra é uma cadeia: requisição 1, que alimenta a requisição 2, que alimenta a 3. Essa cadeia é o que você soma

Use 500ms por elo, não a média. A faixa informada pela TypeSafe é de 70ms a 500ms, e o teto é o que protege o teu p99. Só pra referência de métrica viva: o Jev 1.13 aparece no OpenRouter com P50 de 0,28s no melhor provedor, em janela móvel da última semana, todas as localizações. P50 é mediana, ou seja, metade das chamadas ficou acima disso

O erro comum deste passo: orçar pela mediana e descobrir na Black Friday que a cauda existe

5. Some rede e banco. Round-trip da tua infra até a API nos EUA, mais as queries que montam o estado, mais o que você faz com a resposta. Não chute esse pedaço: meça da tua própria máquina de produção, porque a distância muda tudo e esse tempo não está dentro da faixa do modelo

O erro comum deste passo: orçar só o modelo e esquecer que buscar o documento no banco também custa

6. Confira a janela de contexto. O Jev trabalha com cerca de 64k tokens por requisição, compartilhados entre estado e TODAS as perguntas, com estado + a pergunta mais longa em torno de 32k. Se o teu documento é gordo, é ele que vai limitar quantas perguntas cabem no mesmo pacote, não a latência

O erro comum deste passo: assumir que o limite é de quantidade de perguntas. O teto documentado é de tokens

7. Valide contra os limites de taxa. A TypeSafe publica 250.000 tokens por segundo e 1.200 requisições por minuto, ajustados dinamicamente durante o early access. Pega o pico de requisições por minuto da tua rota, multiplica pelo tamanho médio do estado e vê se cabe

Repara no efeito colateral bonito do agrupamento: juntar 13 decisões em 1 requisição derruba o teu consumo de req/min por um fator grande, sem mexer em nada mais

O erro comum deste passo: validar tokens/s e esquecer req/min, ou o contrário

Sobre custo, só pra fechar a planilha: tokens de entrada saem por US$ 0,042 por 1 milhão, e tokens de saída são US$ 0,00. Ou seja, o que você paga é o estado + as perguntas, o que reforça exatamente a mesma regra: manda o estado uma vez só

Três rotas típicas e o orçamento de cada uma

Bora ver o raciocínio aplicado em três formatos que aparecem sempre

Rota 1: moderação e triagem de conteúdo

Tu recebe um comentário e precisa saber: tem spam? tem discurso de ódio? é off-topic? qual a categoria? qual a nota de qualidade?

Nenhuma dessas decisões depende da outra. Todas olham o mesmo estado

Então é UMA requisição, com Noul pros sim/não, Choice pra categoria e Score pra nota. O orçamento é: rede + banco + um único bloco de até 500ms no pior caso. Adicionar a sexta pergunta amanhã custa os tokens dela e quase nada de tempo

Rota 2: fluxo com decisão dependente

Aqui a segunda pergunta só existe se a primeira disser sim. Exemplo clássico: "este documento é um contrato?" e, se for, "qual o tipo de cláusula de rescisão?"

Dependência real significa cadeia real: duas requisições, orçamento dobra

No pior caso, 1s só de modelo, mais rede e banco. Se o teto da rota é 800ms, você tem duas saídas: ou agrupa a segunda leva de perguntas na primeira requisição (perguntando as duas coisas de uma vez e descartando o que não se aplica), ou tira a segunda decisão do caminho crítico. É exatamente o tipo de decisão que aparece quando você vai encadear decisões do Jev em código dentro de um fluxo maior

Rota 3: job em lote, fora do caminho crítico

Reprocessar 50 mil documentos de madrugada. Ninguém está esperando na frente da tela

Aqui a latência por chamada deixa de ser o gargalo e o limite vira taxa: 250.000 tokens por segundo e 1.200 requisições por minuto. O orçamento muda de pergunta: não é mais "cabe em 400ms?", é "em quanto tempo a fila inteira passa sem tomar 429?"

Quando o orçamento estoura: sintomas, causas e o que fazer

Tome cuidado com esses quatro, são os que mais derrubam orçamento bem feito

Sintoma: 429 Too Many Requests (ou 529 Overloaded). A causa é estourar tokens por segundo ou requisições por minuto. A orientação da doc é repetir com backoff exponencial, e os SDKs oficiais já repetem com backoff por padrão, respeitando o header retry-after

O detalhe cruel: retry consome exatamente o tempo que você reservou no orçamento. Uma rota de 400ms com três tentativas não é mais uma rota de 400ms

Sintoma: latência acima da faixa esperada. Causa provável é distância. O serviço hospedado da TypeSafe roda em região única na Costa Oeste dos EUA e toda chamada até a API oficial faz round-trip até lá. Isso não se resolve com retry, se resolve tirando a decisão do caminho crítico, aceitando o custo de rede no orçamento ou medindo os outros caminhos documentados (Cloudflare AI e AI Gateway da Vercel) pra ver o que muda na tua rota

Sintoma: requisição rejeitada por contexto. Estado + todas as perguntas passaram dos ~64k tokens, ou estado + a pergunta mais longa passou dos ~32k. Solução: cortar o estado (mandar o trecho relevante, não o documento inteiro) antes de cortar perguntas, já que é o estado que domina

E a política de retry, que é configurável. No SDK Python dá pra amarrar o comportamento ao teu teto:

client = TypeSafeClient(
    retry=RetryPolicy(max_retries=3, backoff_max=0.2, timeout=1.0)
)

Lê esses três números como parte do orçamento, não como config solta: max_retries multiplica o pior caso, backoff_max limita a espera entre tentativas e timeout é a linha que você desenha pra não deixar a rota inteira pendurada

Prevenção, em uma linha: agrupe o que é independente, orce pelo pior caso, e configure retry sabendo quanto tempo ele pode gastar do seu teto

E já que o papo é encurtar ciclo, esse vídeo do canal mostra como acelerar o fluxo de desenvolvimento com o Claude Code:

O próximo passo

A regra central cabe em duas frases

Tudo que é independente vai na MESMA requisição, porque as perguntas são avaliadas em paralelo e a pergunta extra custa só os próprios tokens

O que você soma no orçamento é o número de requisições ENCADEADAS, sempre pelo pior caso de 500ms, mais rede e banco

O próximo passo prático é bem direto: pega uma rota real, lista as decisões dela numa planilha, marca a dependência de cada uma, agrupa o que dá e valida com uma chamada ao POST https://api.typesafe.ai/v1/systemone

E se o teu stack não é Python nem Node direto, ou se a distância até a API dos EUA está pesando no teu orçamento, os caminhos alternativos existem: o Jev está documentado na Cloudflare AI com o identificador typesafe/jev, chamado assim:

const resultado = await env.AI.run('typesafe/jev', { state, questions })

E a API da TypeSafe também é acessível pelo AI Gateway da Vercel

Faça o teste com a rota mais lenta que você tem aí, aposto que tem umas 4 decisões em fila que nunca precisaram estar em fila 😀

até o próximo post!