Latência é o número que mais muda de significado conforme quem mede. Um fabricante mede o tempo do serviço dele; você mede o tempo que o seu usuário espera. Os dois são legítimos e quase nunca são iguais.
Esta página põe os dois lado a lado, com o método de cada um.
O que a TypeSafe declara
O anúncio oficial do Jev apresenta uma faixa de 70 a 500 milissegundos de ponta a ponta, e a compara com 3 a 329 segundos de modelos de fronteira. Junto, a empresa publica ressalvas que este guia repete sempre: ela espera que os números de destaque estejam no extremo superior dos ganhos reais e reconhece viés possível. O exame completo desses números está em 193,6x e 444,6x sob exame.
O que nós medimos
Método: cinco chamadas à API oficial em 18 de setembro de 2026, cada
uma com seis perguntas sobre um texto de atendimento em português do Brasil. O
modelo que respondeu, reportado pela própria API, foi o jev-1.13.0. A média
foi de 955 tokens de entrada por chamada. O tempo foi medido por quem
chamou, do lado de fora, envolvendo a chamada inteira — ou seja, inclui a
rede.
| Medida | Valor |
|---|---|
| Menor ida e volta | 270 ms |
| Mediana | 538 ms |
| Maior ida e volta | 802 ms |
| Tokens de entrada, média | 955 |
Por caso, na ordem em que aparecem no nosso conjunto:
| Caso | Latência |
|---|---|
| Cobrança com menção ao Procon | 270 ms |
| Regionalismo e fala coloquial | 377 ms |
| Ironia | 538 ms |
| Elogio espontâneo | 758 ms |
| Suporte técnico com pressa | 802 ms |
Há uma segunda medição, independente das cinco: uma análise do playground deste site, rodando em produção no nosso servidor, registrou 422 milissegundos com 994 tokens de entrada e custo estimado de R$ 0,00023.
Cinco chamadas não são um benchmark, e não as tratamos como tal. Os textos completos estão em o Jev funciona em português.
Por que os números diferem
Comparar 270–802 ms com 70–500 ms e concluir que alguém está errado seria uma leitura preguiçosa. Eles medem coisas diferentes, e as diferenças são identificáveis.
A rede está no meio. A nossa medição inclui a viagem da requisição do Brasil até os servidores e a volta. Nenhuma faixa publicada por um fornecedor inclui a rede do cliente, porque ela não é dele.
A região importa. Não sabemos em que região os servidores que nos atenderam estavam, e a documentação não publica essa informação. Distância física vira milissegundos.
O ponto de medição é outro. “Ponta a ponta” do lado do fornecedor começa quando a requisição chega e termina quando a resposta sai. Do nosso lado, começa antes da conexão e termina depois do último byte.
A amostra é pequena e não controlada. Cinco chamadas, de um cliente, em um momento. Não isolamos abertura de conexão, não repetimos em horários diferentes e não medimos de mais de um lugar.
Nada disso é crítica ao fornecedor. É a diferença normal entre um número de catálogo e um número de campo — e a nossa medição, apesar de incluir tudo isso, ficou abaixo de um segundo em todas as cinco chamadas.
O que isso permite desenhar
Fluxo síncrono é viável. Abaixo de um segundo cabe em uma requisição web que já faz outras coisas: classificar um ticket antes de responder, decidir um desvio, validar uma entrada. Isso é o que permite os desenhos de roteamento de intenção.
O orçamento de retentativa precisa caber no seu contrato. O padrão do SDK Python é um orçamento total de 30 segundos por chamada, o que é generoso demais para um caminho síncrono. Com a latência que medimos, dois ou três segundos já cobrem uma repetição — o ajuste está em retentativas e tempo limite.
O paralelismo sai da latência. Para sustentar 20 requisições por segundo com meio segundo por chamada, bastam cerca de dez trabalhadores simultâneos. A conta completa está em limites de taxa.
Agrupar perguntas é a maior economia de tempo. As nossas cinco chamadas carregavam seis perguntas cada. Em seis chamadas separadas, o tempo teria sido somado; o cookbook oficial mediu 10,0 vezes mais rápido ao juntar treze perguntas numa chamada em vez de treze chamadas em sequência.
O que ainda não medimos
Vale listar, porque o que falta define o quanto você pode confiar no que está aqui.
- State grande. Todas as nossas chamadas são de textos curtos, com média de 955 tokens. Não sabemos como a latência se comporta perto do teto de 32 mil tokens.
- Variação por horário. Uma única janela de medição.
- Mais de um ponto de origem. Medimos de um lugar, não de várias regiões brasileiras nem de várias operadoras.
- Percentis altos. Cinco amostras não dão p95 nem p99, e é justamente a cauda que quebra um contrato de latência.
Como medir no seu caso
Marque o tempo em volta da chamada, do lado do cliente, e registre junto o
usage.input_tokens e o model da resposta. Em uma semana de tráfego real
você tem a distribuição que interessa — a sua — com os percentis que nenhuma
página consegue dar.
Para montar a primeira chamada e ler esses campos, veja primeiros passos e a API HTTP sem SDK. O índice desta seção está em português.
Perguntas frequentes
Qual a latência do Jev medida do Brasil?
Nas nossas cinco chamadas de 18/09/2026, a ida e volta ficou entre 270 e 802 milissegundos, com mediana de 538. O tempo foi medido por quem chamou, do lado de fora, e portanto inclui a rede. Uma análise do servidor do site em produção registrou 422 milissegundos com 994 tokens de entrada.
Por que os nossos números diferem dos 70 a 500 ms declarados?
Porque medem coisas diferentes. A faixa da TypeSafe é a latência de ponta a ponta do serviço dela; a nossa inclui a viagem de rede entre o Brasil e os servidores, o estabelecimento da conexão e a variação da internet pública. Nenhum dos dois está errado.
Dá para usar o Jev em um fluxo síncrono no Brasil?
Nas condições que medimos, sim: abaixo de um segundo em todas as cinco chamadas. Mas dimensione com o seu caso, porque a latência cresce com o tamanho do state e varia com a rede do seu provedor e com a região onde o seu código roda.
O tamanho do state muda a latência?
Muda, e as nossas cinco chamadas são todas de textos curtos, com média de 955 tokens de entrada. Não medimos documentos grandes, então não temos dado para afirmar como a curva se comporta acima disso.
Como eu meço a latência no meu caso?
Marcando o tempo em volta da chamada no seu código, do lado do cliente, e registrando junto o campo usage.input_tokens e o campo model da resposta. Medir do lado de fora é o que captura a experiência real do seu usuário.