Jev (Typesafe AI) x LLM: quando decisão tipada compensa

Quando um sistema precisa decidir algo a partir de texto não estruturado (classificar um chamado, rotear um pedido, pontuar um risco), o caminho padrão hoje é um LLM. Só que, em decisões repetidas em alto volume, o LLM traz três custos recorrentes: preço por chamada, latência de segundos e saídas que mudam de uma execução para outra. Em setembro de 2026, a Typesafe AI apresentou uma alternativa: uma nova classe de modelos, a System One, cujo primeiro representante é o Jev, em early access. Também foi noticiada a Laya, apresentada como alternativa open source ao Jev.

Este texto compara as duas abordagens do ponto de vista de decisão de negócio: quando cada uma faz sentido, quanto dos números divulgados pode ser levado a sério e o que validar antes de qualquer adoção.

A pergunta que decide a escolha

Antes de comparar tecnologias, responda uma pergunta: a decisão tem um conjunto fechado de respostas (categoria, sim ou não, faixa de risco, prioridade) ou exige escrever ou conversar com alguém?

• Se exige texto livre (redigir uma resposta, conduzir um diálogo, gerar um resumo), o caso é de LLM. A proposta do Jev não cobre isso.
• Se a resposta é um conjunto fechado e a decisão se repete milhares de vezes por dia, a comparação abaixo importa.

O que a Typesafe AI propõe

Segundo a empresa, o Jev é "uma função de chamada de inteligência de fronteira": recebe estado não estruturado e devolve decisões tipadas e probabilísticas. Três diferenças em relação a um LLM:

• Saída tipada. Os resultados possíveis são definidos antes da chamada, então o sistema que consome a resposta não precisa fazer parsing de texto livre.
• Probabilidades calibradas. Cada resultado vem com uma probabilidade e um nível de confiança, que a empresa afirma serem consistentes, em vez de uma resposta apresentada com a mesma segurança independentemente do acerto.
• Geração paralela. Todas as saídas são produzidas em uma única consulta, e não token a token, o que é a base do ganho de latência divulgado.

A empresa ainda descreve o modelo com uma arquitetura nova e um método de treino próprio, chamado RLCD (Reinforcement Learning for Calibrated Decisions), que otimiza decisões com probabilidades calibradas. Sem acesso à documentação técnica completa, esses detalhes devem ser tratados como afirmações da fornecedora.

Os números divulgados, com as ressalvas da própria empresa

A página inicial do fornecedor cita ganhos de 193,6x em velocidade e 444,6x em custo. A própria empresa reconhece limitações nas comparações:

• os benchmarks foram rodados pela equipe do fornecedor, a partir de laptops na Costa Oeste dos EUA;
• a referência de comparação favorece modelos da OpenAI e da Anthropic, o que pode subestimar concorrentes;
• os wrappers usados para os LLMs tendem a ser mais lentos e caros do que uma integração otimizada;
• a empresa diz não poder provar que o preço atual não é subsidiado.

Por isso, trate esses números como hipótese a validar com a sua carga de trabalho, e não como fato para orçamento.

Onde faz sentido

A própria fornecedora cita os seguintes casos:

• Roteamento, classificação, pontuação e extração dentro de fluxos de IA, onde a lógica manual é frágil.
• Processamento de grandes volumes em padrão map-reduce.
• Aplicações em tempo real, em que uma latência de cerca de 100 ms faz diferença na experiência.
• Verificação de saídas de LLM, como guardrails e detecção de tentativas de manipulação.

Onde não faz sentido

Pelo mesmo critério, o modelo não serve para chat, copiloto ou agente que precisa produzir linguagem natural. A empresa afirma isso de forma explícita. Também não é a ferramenta certa quando a decisão precisa ser explicada em texto para o usuário final.

Riscos a considerar antes de adotar

• Disponibilidade e preço. O Jev está em early access, e o acesso às demonstrações é restrito a quem tem acesso antecipado. Preço e condições podem mudar.
• Dependência de fornecedor. É uma classe de modelo nova, com pouca base comparável. A Laya, por ser open source, pode reduzir essa dependência, mas exige avaliar maturidade, licença e custo de operação por conta própria.
• Calibração não é garantia. Probabilidades bem calibradas no benchmark do fornecedor podem não se repetir com os seus dados. É preciso medir isso com um conjunto de casos reais e rotulados.

Exemplo ilustrativo: triagem de chamados de suporte

Para tornar a comparação concreta, considere uma situação comum: uma organização recebe 2 milhões de chamados por mês de suporte interno e precisa classificar cada um em uma categoria (acesso, incidente, financeiro, dúvida) e em uma prioridade (crítica, alta, normal). Esse é o tipo de decisão que o Jev descreve: entrada em texto livre, saída fechada, repetida milhares de vezes por dia.

Importante: os números a seguir são uma estimativa com premissas declaradas, não resultados medidos em um cliente real. Eles servem para mostrar como fazer a conta. Os valores de preço usados são os divulgados pela própria fornecedora ou uma referência de mercado, e o volume e o tamanho dos chamados são hipotéticos. Substitua pelos seus números antes de decidir.

Premissas

• 2.000.000 de chamados por mês.
• Cerca de 800 tokens de entrada por chamado (texto do chamado mais instruções).
• Cerca de 40 tokens de saída por chamado, no caso de um LLM que devolve a categoria, a prioridade e uma justificativa curta.
• Jev: US$ 0,042 por milhão de tokens de entrada, saída informada como gratuita.
• LLM de referência: US$ 1 por milhão de tokens de entrada e US$ 5 por milhão de saída. É um valor intermediário dentro da faixa que a fornecedora cita para os LLMs.

Exemplo com Jev

O chamado chega assim:

"Desde as 7h não consigo acessar o sistema de folha. Tenho 40 pessoas do financeiro travadas e o fechamento é hoje."

O Jev recebe o estado não estruturado (o texto e o contexto) e devolve uma decisão no formato definido antes da chamada. Um exemplo do tipo de saída, ilustrativo:

categoria: acesso          # acesso | incidente | financeiro | duvida
prioridade: critica        # critica | alta | normal
confianca: 0.93            # probabilidade calibrada da categoria escolhida

O sistema que consome a resposta não precisa interpretar texto: o valor já vem tipado. Se a confiança for baixa, o chamado pode ser roteado para revisão humana sem nenhuma lógica de parsing.

Custo estimado: 1.600 milhões de tokens de entrada × US$ 0,042 por milhão ≈ US$ 67 por mês.

Latência: entre 70 e 500 ms por chamado, segundo a fornecedora. Para triagem, isso significa classificar o lote inteiro em minutos.

Exemplo com LLM tradicional

Com um LLM de propósito geral, o mesmo chamado pode voltar assim:

"Esse chamado parece ser de acesso, com prioridade crítica, porque afeta vários usuários e há prazo de fechamento. Eu classificaria como acesso."

A informação está lá, mas o sistema precisa extrair o valor desse texto. Na prática, isso exige um prompt que force o formato JSON, validação da saída, nova tentativa quando o formato falha e uma regra para o caso em que o modelo muda a classificação entre duas execuções para o mesmo chamado.

Custo estimado: 1.600 milhões de tokens de entrada × US$ 1 ≈ US$ 1.600, mais 80 milhões de tokens de saída × US$ 5 ≈ US$ 400. Total de cerca de US$ 2.000 por mês. Esse valor cai se o provedor oferecer cache de prompt para as instruções repetidas, mas o cálculo precisa ser refeito com o preço real.

Latência: alguns segundos por chamada, e a faixa citada pela fornecedora vai de 3 a 329 segundos. A escolha do modelo e o tamanho da resposta mudam bastante esse número.

Exemplo combinado: Jev primeiro, LLM só quando precisar

Uma arquitetura em cascata usa o Jev para classificar todos os chamados. Quando a confiança fica abaixo de um limiar (por exemplo, 0,80), o chamado vai para um LLM, que recebe o histórico completo e pode lidar com texto ambíguo. Supondo que 15% dos chamados caiam nesse caminho:

• Jev em todos: 2 milhões de chamados, cerca de US$ 67.
• LLM nos 15%: 300 mil chamados, cerca de 240 milhões de tokens de entrada e 12 milhões de saída, aproximadamente US$ 300.
• Total: cerca de US$ 370 por mês, uma redução de cerca de 80% em relação ao LLM sozinho.

O ponto que mais pesa nessa arquitetura é a calibração: o limiar de 0,80 só faz sentido se a probabilidade reportada pelo Jev corresponder de fato à taxa de acerto nos seus dados. Esse é o primeiro teste a fazer.

Cenários e ganhos esperados

O que esperar, e o que medir antes

Os ganhos de custo e de latência são prováveis, mas dependem do seu volume, do preço real e da taxa de chamados escalados. Antes de qualquer decisão:

1. Acurácia: rotule manualmente de 300 a 500 chamados reais e compare Jev, LLM e cascata contra esse gabarito.
2. Calibração: verifique se, para os chamados com confiança de 0,80, a taxa de acerto está perto de 80%.
3. Taxa de escalonamento: meça quantos chamados caem abaixo do limiar. Ela define o custo real da cascata.
4. Custo real: use o preço e o volume contratados, não os de referência usados aqui.

A fornecedora afirma que o Jev não alucina porque a saída segue um schema. Isso garante o formato da resposta, não que a categoria escolhida esteja certa. A acurácia precisa ser medida.

Critério para levar à reunião

Três perguntas resolvem a maior parte da decisão:

1. A decisão tem respostas fechadas?
2. Ela se repete em alto volume?
3. Precisa de latência abaixo de um segundo e de resultado auditável?

Se as três forem sim, vale um piloto com o Jev ou com uma alternativa open source, medindo calibração, latência e custo com dados reais. Se alguma for não, a escolha continua sendo um LLM ou regras explícitas, conforme o caso.

Fontes: Introducing System One Models & Jev (Typesafe AI) · Laya chega como alternativa open source ao Jev da Typesafe AI (iMasters)