Laya vs Jev: a IA de decisão de US$ 40 milhões contra a de graça que roda no seu notebook

Seis dias de vida, US$ 40 milhões de seed, e o Jev já tem um concorrente Apache-2.0 que roda offline e é 7x mais rápido no P50.

A pergunta não é qual é melhor.

É por que ninguém tinha percebido que esse trabalho não precisava de um LLM.

Este post compara Laya vs Jev com os números que cada lado publicou, e registra a briga de anterioridade que estourou no Hacker News dois dias depois do lançamento. Separando o que dá pra conferir do que ainda é acusação.

TL;DR

• O que é: comparativo cabeça a cabeça entre o Jev (TypeSafe AI, API fechada, US$ 40M de seed) e o Laya, a primeira alternativa open source ao Jev com pesos publicados (Convai Innovations, Apache 2.0, 421M de parâmetros, roda local).
• Stack/Modelos: Jev via API REST; Laya via transformers (Python) ou ONNX Runtime (@receptron/laya, Node/TypeScript).
• Custo/Acesso: Jev em early access por waitlist, US$ 0,042 por milhão de tokens de entrada, saída grátis. Laya com pesos abertos, custo de inferência zero e custo de GPU seu.
• Links úteis: anúncio oficial do Jev | model card do Laya no Hugging Face
• Status: post vivo. A disputa de anterioridade ainda está aberta; o registro de atualizações fica no fim.

O contexto mínimo: o que é um modelo System One

Um modelo System One não escreve texto. Ele recebe estado de programa e devolve uma decisão tipada com probabilidade: qual fila, qual label, escala ou não escala. Sem token por token, sem parser de JSON torto, sem retry porque o modelo resolveu filosofar.

Se você ainda não viu a ideia, o fundamento está destrinchado em Jev: o modelo de IA que não escreve nada. Aqui o assunto é outro: a comparação e a briga.

E é uma briga que interessa a quem constrói produto, não a quem coleciona notícia. Escolher entre API paga e peso aberto pra uma decisão que roda milhões de vezes por dia é decisão de arquitetura, e decisão de arquitetura mal tomada vira dívida técnica em seis meses. Esse tipo de conversa é o que rola toda semana no Clã Beer and Code: é pago, é assinatura, e é onde a escolha é discutida antes de entrar no código em vez de depois do incidente.

A thread do Hacker News: o que o autor do Laya publicou em março de 2025

Dia 15 de setembro de 2026 a TypeSafe AI saiu do stealth com o Jev e US$ 40 milhões de seed liderados pela DCVC. Dia 17, Nandakishor M, fundador da Convai Innovations, abriu uma thread no Hacker News dizendo que tinha publicado a mesma ideia em março de 2025, com paper, pesos e dataset abertos, e que agora ela estava sendo anunciada como descoberta nova.

O que dá pra conferir sozinho:

• VERIFICADO. O paper existe e tem data. arXiv:2503.23303, SalesRLAgent: A Reinforcement Learning Approach for Real-Time Sales Conversion Prediction and Optimization, Nandakishor M, submetido em 30 de março de 2025. A técnica é PPO sobre embeddings de sequência devolvendo trajetória de conversão turno a turno, de 0.0 a 1.0, em vez de gerar texto.
• VERIFICADO. Existe um segundo paper, arXiv:2510.01237, Confidence-Aware Routing for Large Language Model Reliability Enhancement, de 23 de setembro de 2025, sobre roteamento por confiança antes da geração.
• EM DISPUTA. Que esse trabalho seja a mesma arquitetura do Jev.

O contraponto apareceu na própria thread do HN. Num outro fio, um comentarista resumiu a acusação e levou resposta direta: "the paper does not describe a model architecture, it describes a system built on embeddings, rag, and orchestrators, they don't seem very similar to me."

E tem um detalhe que o próprio Nandakishor admite: o modelo dele foi treinado pra uma tarefa (previsão de conversão em conversa de vendas), enquanto o Jev está sendo creditado por fazer isso zero-shot pra qualquer conjunto de escolhas. Escopo diferente.

Tem ainda a coincidência de sigla. A TypeSafe chama o método de treino do Jev de RLCD, Reinforcement Learning for Calibrated Decisions. O model card do Laya também descreve o treino como RLCD, e o site do projeto diz que o paper de setembro de 2025 formalizou esse framework. Fui conferir: o paper de setembro não usa o termo RLCD em nenhum momento. Fica registrado dos dois jeitos, porque é exatamente o tipo de detalhe que vai decidir a discussão.

Até o fechamento deste post eu não localizei resposta pública da TypeSafe à acusação. Ninguém mostrou reuso de código. O que está na mesa é anterioridade não creditada, não cópia.

Jev por dentro: RLCD, 70 a 500 ms, US$ 0,042/MTok e até 255 opções

Tudo abaixo é VERIFICADO no sentido de "publicado pela TypeSafe". Nem tudo é medido por terceiro, e eu marco onde não é.

Duas ressalvas honestas sobre essa tabela.

A primeira: o "0% de alucinação" é uma garantia de tipo, não uma medição de acerto. O modelo não consegue devolver algo fora do schema. Isso não quer dizer que ele escolha a opção certa. São coisas diferentes e vale ler com esse filtro.

A segunda: a TypeSafe não publicou tabela de benchmark pública no anúncio. Os números de acurácia do Jev que circulam hoje vieram, em boa parte, da medição feita pela concorrente. Que é o próximo bloco.

Laya por dentro: 421M no ModernBERT-large, 32,8 ms no P50 e ECE 3x melhor

O Laya é o primeiro modelo System One open source com pesos, dataset e paper publicados. Por baixo, um encoder bidirecional com cabeça de decisão. Sem geração autorregressiva, uma passada pra frente só.

• Backbone: ModernBERT-large, 395M de parâmetros, fine-tune completo.
• Cabeça de decisão: 2 camadas transformer, um scorer por marcador de opção e uma cabeça act/escalate.
• Total: 421M no checkpoint em inglês, 512 tokens de contexto, orçamento de 192 tokens pras opções.
• Variante multilíngue: mmBERT-base, 322M, 1024 tokens de contexto, 100+ idiomas.
• Licença: Apache 2.0, três checkpoints, o de inglês com cerca de 808 MB de pesos.

Os números de latência, medidos numa Tesla T4 (uma GPU de 2018, não um H100):

Em lote, o custo marginal cai pra cerca de 7,2 ms por pergunta. É outra ordem de grandeza de problema.

Rodar é uma linha em Python:

from laya import Router

router = Router(preload=True)
res = router.predict(ticket, questions)

print(res["answers"]["queue"]["choice"])

E existe wrapper Node/TypeScript por cima de ONNX Runtime, sem PyTorch e sem Python em runtime, publicado sob MIT (@receptron/laya):

import { Laya } from "@receptron/laya";

const laya = await Laya.load();

const result = await laya.systemOne(
  { subject: "Refund not received", body: "..." },
  {
    department: {
      type: "choice",
      instructions: "Which team should handle this?",
      criteria: { billing: "refunds", support: "bugs", sales: "purchases" },
    },
  },
);

result.answers.department.choice; // "billing"

Se o seu backend é PHP ou Go, o caminho é o mesmo de sempre: sobe o Laya como serviço HTTP interno e chama por dentro da VPC. A parte cara não é a linguagem, é a GPU.

Laya vs Jev: a tabela dos números publicados

Aqui é onde o duelo Laya TypeSafe fica desconfortável, porque quem mediu o Jev foi a Convai, a autora do Laya. Não existe, até agora, uma medição neutra dos dois. Leia com isso na cabeça.

O ECE é o número que eu acho mais interessante e o que menos gente vai olhar. Expected Calibration Error mede se a probabilidade que o modelo devolve corresponde à frequência real de acerto. Se ele diz 0.9 e acerta 90% das vezes, o ECE é baixo. 0,081 contra 0,246 é três vezes melhor, e é isso que decide se você pode escrever if confidence > 0.85: auto_resolve() sem virar incidente.

Sobre os 7,8x de latência, uma correção que ninguém faz: 32,8 ms é inferência local numa T4. Os 236 a 276 ms do Jev são chamada de API, com rede, fila e TLS no meio. Comparar os dois é comparar coisas diferentes. A diferença continua enorme, mas parte dela é geografia, não arquitetura.

Onde o Laya apanha: mais de 20 opções, fine-tuning e calibração por domínio

Essa seção existe porque o próprio model card é honesto, e a maioria dos posts sobre o Laya ignorou.

Cardinalidade alta destrói o modelo. No Banking77, com 77 labels, o Laya faz 0,425 contra 0,870 do Jev. Motivo mecânico: o orçamento de 192 tokens pras opções vira 3 a 4 tokens por label. Não cabe descrição, não cabe critério, sobra o nome espremido. Na prática, acima de umas 20 opções você está no território onde o Jev ganha limpo.

Zero-shot ele não serve. O checkpoint base faz 0,362 no typed-decisions. Chutar a classe mais comum faz 0,461. Ou seja: pior que a heurística burra. O model card não disfarça: "Laya is a fast base to specialise, not a zero-shot decision engine."

Calibração não vem de graça. Aquele ECE de 0,081 é depois de ajustar temperatura por domínio. O checkpoint cru sai em 0,213 (0,285 no multilíngue). Se você não refitar temperatura pro seu tipo de pergunta, a probabilidade que ele devolve não vale como gatilho de automação.

Escala ordinal é o ponto fraco. SST-5, que é sentimento em cinco níveis, dá 0,372. Ordenar intensidade não é o forte dele.

Traduzindo pra decisão de projeto: o Laya é uma base rápida pra especializar. Ele custa fine-tuning, dataset rotulado do seu domínio e um passo de calibração. O Jev custa cartão de crédito. Essa é a troca real, e ela não aparece em nenhuma manchete.

API paga vs self-hosted: a conta real por volume de chamadas

Vamos fazer a conta com premissa explícita, que é o único jeito honesto de fazer.

Premissa: uma decisão típica com estado de programa mais opções gasta cerca de 600 tokens de entrada. A US$ 0,042 por milhão, cada decisão sai a US$ 0,0000252. Ou seja, US$ 25,20 por milhão de decisões.

Os dois últimos números vêm do throughput publicado: 103 a 332 perguntas por segundo em lote numa T4, extrapolado pra 30 dias de saturação.

A leitura é simples e provavelmente contraria o que você esperava.

Abaixo de uns 10 milhões de decisões por mês, o Jev é mais barato. US$ 252 não paga nem o custo de alguém configurar, monitorar e ficar de plantão numa GPU. Pagar API aqui é a decisão de engenharia correta.

Acima de algumas centenas de milhões, a conta inverte com folga. Uma T4 custa uma fração de US$ 6.700 por mês em qualquer nuvem, e a mesma GPU absorve o volume inteiro. Nesse regime, self-hosted não é ideologia, é margem.

E tem o eixo que preço nenhum resolve: o Laya roda offline. Se o seu dado não pode sair da VPC por contrato, LGPD ou paranoia justificada de cliente enterprise, a comparação de custo acaba antes de começar. Um lado é elegível, o outro não.

Verificado vs em disputa: o placar honesto

Esse post não arbitra as três últimas linhas. Não dá, com o que é público hoje.

FAQ rápido

Dá pra trocar Jev por Laya sem reescrever o código? A forma da chamada é compatível de propósito: você passa estado mais um mapa de perguntas tipadas e recebe answers[chave].choice com probabilidade. O que não é portável é a qualidade: sem fine-tuning no seu domínio, o Laya cru vai piorar suas métricas.

Preciso de GPU pra rodar o Laya? Os números publicados são todos em GPU (Tesla T4). Não existe benchmark de CPU no model card. Com 421M de parâmetros e uma passada única, CPU é plausível pra volume baixo, mas trate como hipótese a testar, não como fato.

O Laya substitui meu LLM? Não. Nenhum dos dois escreve texto. Eles substituem a chamada de LLM que você usa hoje só pra decidir algo: rotear ticket, classificar intenção, escolher ferramenta, decidir se escala pra humano. A geração continua com o LLM.

Qual eu uso hoje, no dia 21 de setembro de 2026? Poucas opções, volume alto, dado que não pode sair de casa: Laya, com orçamento pra fine-tuning. Muitas opções, volume baixo, time pequeno: Jev. Prototipando: Jev, porque não exige dataset. Nenhuma dessas respostas é permanente e a segunda metade da tabela pode mudar em um mês.

O que fica de pé

Seis dias separaram um modelo de US$ 40 milhões de um concorrente de 808 MB que roda numa GPU de 2018. Isso não é sobre o Jev ser ruim. É sobre a categoria inteira ter sido cara por um motivo que já não vale: a gente estava usando modelo generativo pra tarefa que nunca foi generativa.

A disputa de anterioridade provavelmente não se resolve, e um Jev open source oficial não está no roteiro de ninguém. O que ela expõe é mais útil: decisão tipada calibrada não era um problema aberto esperando um lab com seed de nove dígitos. Era um encoder bidirecional com uma cabeça em cima, e alguém tinha escrito isso num paper de vendas em março de 2025 sem ninguém olhar.

Se quiser o fundamento antes do comparativo, comece por Jev: o modelo de IA que não escreve nada. Se quiser o padrão maior, o de peso aberto alcançando API fechada em semanas, o caso do Qwen 3.8 27B é o mesmo filme com outro elenco.

Registro de atualizações

Este post é vivo e vai ser atualizado conforme a disputa evoluir.

• 21/09/2026 — publicação. Jev em early access desde 15/09; Laya publicado em 19/09; thread de anterioridade aberta no HN em 17/09, com discussão derivada na mesma semana. Sem resposta pública da TypeSafe até aqui. Sem medição neutra dos dois modelos.

Se você rodar um benchmark independente dos dois, manda. Entra aqui com crédito.