RSI-Jev vs Jev 1.13: Um Você Baixa, o Outro Você Chama

Coloque RSI-Jev v6.1-VL 4B e Jev 1.13lado a lado e a primeira coisa que um chamador percebe é que eles são a mesma requisição. Entregue a qualquer um deles um estado e um conjunto de perguntas tipadas — um sim/não, uma escolha de uma entre k, uma avaliação em uma rubrica — e ambos retornam uma probabilidade calibrada para cada opção, em uma única passagem direta, sem texto gerado para analisar. Isso não é coincidência: o RSI-Jev foi construído de propósito para falar o formato de transmissão do Jev, então um cliente escrito para a API da TypeSafe funciona com ele apenas mudando uma URL base. O que não é igual é tudo ao redor da chamada. O Jev 1.13 é o modelo comercial fechado da TypeSafe, servido a partir de um endpoint cujo uso é medido; o RSI-Jev v6.1-VL é um checkpoint de 4,69 bilhões de parâmetros sob pesos Apache-2.0 que você baixa e serve no seu próprio hardware. Nenhum dos dois é uma reformulação de marca do outro, nenhum fornecedor endossa o outro, e quase todos os números desta comparação vêm da parte que a produziu.

A data sobre o assunto importa, porque este projeto lança uma versão quase todos os dias. RSI-Jev v6.1-VL 4B foi publicado em 2026-10-07 por Shanghua-Gao/RSI-Jev, um projeto de terceiros — um ciclo de pesquisa autoaperfeiçoável que treina modelos de decisão no estilo Jev e publica todos os braços que falharam junto com os que venceram. É a oitava versão em treze dias nessa linha, e é uma média ponderada da versão anterior com um segundo ajuste fino do mesmo Qwen3.5-4B-Base. O Jev 1.13 é o modelo da TypeSafe AI, lançado em 2026-09-15 e presente no nosso próprio catálogo desde 2026-09-24. Ambas as datas importam abaixo, porque uma comparação com um projeto que se move diariamente tem prazo de validade medido em dias.

O que os dois realmente são, em uma linha cada

Jev 1.13 é um modelo de decisão hospedado por trás de um endpoint dedicado — POST /v1/systemone, sem streaming, com um orçamento de entrada de aproximadamente 64.000 tokens somando o estado e todas as suas perguntas juntas, com preço de $0,042 por milhão de tokens de entrada e saída cobrada a zero, porque não há tokens de saída. Sua arquitetura, contagem de parâmetros e compute de treinamento não são divulgados; a TypeSafe disse que os detalhes estão sendo mantidos em sigilo e que um artigo pode ser publicado em seguida. Você não o executa. Você o chama, e cada chamada é uma requisição de rede medida.

O RSI-Jev v6.1-VL é a outra configuração na íntegra. É uma torre Qwen3.5-4B-Base ajustada de ponta a ponta, com cabeças de decisão nas camadas 16, 20 e 32, servida a partir de um checkpoint autocontido de 9,7 GB em bf16. O número de parâmetros é 4,69B e vale a pena saber como se distribuem: 3,57B nas 32 camadas do descodificador, 0,64B nos embeddings de tokens, 0,33B na torre de visão, 0,05B na cabeça de decisão principal e 0,10B nas duas cabeças de saída antecipada. Não há mistura de especialistas nem um segundo modelo. Instala-o com um comando pip a partir do repositório, executas o respetivo servidor e, a partir daí, a decisão nunca sai da tua infraestrutura.

• Quem o executa — um endpoint hospedado com medição que você não controla vs um checkpoint de 9,7 GB na sua própria GPU, Apple Silicon ou CPU.

• Estrutura de preços — $0,042 por milhão de tokens de entrada, saída gratuita, pago por chamada vs zero na margem, mais o custo da máquina e das operações.

• Orçamento de entrada — cerca de 64.000 tokens por solicitação no modelo hospedado, contra 32.768 tokens de texto mais um orçamento de imagem no checkpoint, com qualquer coisa mais longa sendo recusada em vez de truncada.

• Pesos e licença — fechado, tamanho não divulgado vs pesos Apache-2.0, código MIT, 4,69B parâmetros.

• Modalidade — texto para o contrato do Jev vs. texto mais até quatro imagens por requisição nas versões de visão do RSI-Jev.

• Propriedade — O modelo comercial da TypeSafe AI versus um projeto de pesquisa de terceiros que declara, na sua própria linha de licença, que "não é afiliado à TypeSafe AI".

A pontuação no próprio placar da RSI-Jev, e por que isso é apenas metade de uma comparação.

O número com que o projeto se apresenta é a sua pontuação no Decision Index 0.3: 50,98 para o v6.1-VL 4B, acima dos 46,23 da versão anterior. Trata-se de uma execução completa da configuração predefinida — 140 178 pedidos, cobertura 1,0 — e, no quadro público do próprio projeto, datado de 2026-10-06, empata com o melhor modelo 4B desse quadro (50,98 contra os 50,82 do ezjev 4B s2, que o kit considera um empate a 0,25) e ocupa o 27.º lugar entre 113 no geral. No Decision Index 0.2.1 mais antigo, regista 50,74 contra os 46,24 do v6.0-VL. A sua suite de quinze benchmarks, reportada sem a open_jev_ood tarefa que se descobriu sobrepor-se a linhas de treino, é 0,793, e o seu conjunto retido é 0,729.

Todos esses números são do próprio RSI-Jev, medidos na estrutura de avaliação do RSI-Jev. O Decision Index é um painel público de benchmark, mas não há nenhuma medição do Jev 1.13 nele, porque a suíte do projeto foi criada para pontuar checkpoints de decisão abertos e o Jev é um endpoint fechado. Portanto, a tentação de contrapor 50,98 ao 0,727 do Jev no benchmark de decisões tipadas e declarar um vencedor é exatamente o erro a evitar: esses dois números vêm de estruturas de avaliação diferentes, tamanhos de amostra diferentes e dados diferentes, e ninguém executou uma mesma estrutura de avaliação em ambos os modelos.

O único confronto direto que existe é o da Laya, não o da RSI-Jev.

Há uma comparação publicada que de fato coloca um número Jev ao lado de um checkpoint aberto, e não foi realizada por nenhuma das partes aqui. A Convai Innovations, criadora do modelo de decisão Laya, tabulou os números publicados do Jev 1.13.0 do TypeSafe em comparação com os seus próprios e sinalizou ela mesma as limitações: os números do Jev são publicados por terceiros e nunca foram medidos pela Convai, os tamanhos de amostra e os prompts são diferentes, e o fornecedor não lista seus próprios benchmarks para o modelo. Vale a pena ler essa tabela para fins de calibração, não para um veredito — e ela não inclui o RSI-Jev de forma alguma, porque o RSI-Jev não existia quando ela foi publicada.

O que ele mostra é o formato da questão entre hospedado e aberto que um leitor está de fato ponderando. O modelo hospedado lidera onde o espaço de opções é grande e o modelo precisa manter um amplo conjunto de respostas estável; os modelos abertos vencem na latência bruta por chamada porque não há rede no caminho. Nada nesse padrão diz qual desses dois modelos específicos é melhor para a sua tarefa, e a posição honesta é que a resposta ainda não existe publicamente.

O que o checkpoint proporciona que o endpoint não consegue

O argumento mais forte a favor do RSI-Jev não é uma pontuação. É que os pesos ficam no seu disco. Para uma decisão de roteamento tomada com base em um prontuário médico, um documento jurídico ou o histórico da conta de um cliente, "os dados nunca saem do prédio" não é uma preferência que você troca por um ponto de benchmark — é um requisito rígido, e nenhum endpoint hospedado a qualquer preço atende a isso. A mesma propriedade elimina o limite de taxa: a documentação do próprio fornecedor para o modelo hospedado observa que seus limites são ajustados dinamicamente e podem mudar sem aviso prévio, e um checkpoint auto-hospedado não tem esse teto além do seu hardware.

A segunda coisa que o checkpoint oferece é controle de profundidade, e isso é incomum. Como as cabeças de decisão ficam em três profundidades, uma configuração de esforço escolhe quantas camadas uma requisição pode usar: baixo para na camada 16, com mediana de cerca de 23 ms, médio para na camada 20 com 27 ms, alto para na camada 32 com cerca de 40 ms, e automático responde na primeira saída confiante o suficiente, com média de 19,5 de 32 camadas no conjunto de testes do projeto. Essas latências são números do próprio projeto, medidos em uma H200 em bf16, e não devem ser misturadas com qualquer número de serviço hospedado — um forward pass local e uma chamada de API medida não são a mesma medição, e a própria documentação do RSI-Jev é explícita ao afirmar que sua comparação anterior com a latência publicada do Jev opôs trabalho local de GPU a uma ida e volta de rede.

A terceira coisa são as imagens. O contrato do Jev é texto na entrada, JSON estruturado na saída. As versões de visão do RSI-Jev aceitam de uma a quatro imagens por requisição como URLs de dados em base64, com o estado se referindo a cada uma por um marcador, e o v6.1-VL obtém 0,834 no conjunto de imagens reservado do projeto. Se a sua decisão é “a foto mostra danos visíveis?”, isso é uma capacidade que o contrato hospedado não oferece de modo algum.

Aquilo de que você abre mão também é real, e o projeto o publica. A calibração piorou nesta versão, não melhorou: o erro de calibração esperado final é 0,048 na camada 32 e 0,055 com auto, contra 0,036 e 0,024 da versão anterior. O limiar único padrão de 0,95 é entregue explicitamente como não confirmado — é o fallback de uma regra de seleção cuja própria escolha, 0,85, não atingiu o teto de profundidade do projeto em metade de seus dados de desenvolvimento. As saídas antecipadas leem apenas texto, então qualquer pergunta com uma imagem executa todas as 32 camadas independentemente do esforço. E cinco das fontes de treinamento de imagem são não comerciais ou apenas para pesquisa, com o projeto afirmando claramente que não está definido se pesos treinados com dados não comerciais herdam esses termos.

Onde chamar o hospedado, e onde não

Esta é a parte da comparação na qual temos interesse, por isso vale a pena ser preciso. Atendemos ao modelo comercial da TypeSafe como typesafe/jev-1.13 no endpoint dedicado systemone — um POST para /v1/systemone em vez do formato chat-completions da OpenAI, sem streaming, contra o contexto de 65.536 tokens listado em nosso catálogo. É o mesmo formato de requisição e resposta que o RSI-Jev implementa, do modelo cujo contrato o projeto copia. O próprio RSI-Jev nós não hospedamos; não há id rsi-jev nem id shgao em nosso catálogo, e quem quiser esse modelo o baixa.

A razão pela qual essa distinção importa aqui é específica e concreta. Uma camada de decisão raramente é todo o fluxo de trabalho — normalmente fica ao lado de um modelo generativo que escreve a resposta, o resumo ou o código. Isso historicamente significou dois contratos. Já não precisa de ser assim para a metade hospedada: o Jev 1.13 está na mesma chave que mais de 200 outros modelos a preço de tabela do provedor repassado com 0% de markup, portanto, se a TypeSafe alterar uma tarifa, a alteração fica ativa do nosso lado no mesmo dia, em vez de no próximo ciclo de faturação. A metade auto-hospedada nunca teve esse problema, porque você é o provedor. A forma mais limpa de decidir entre eles é testar o contrato comercial em alguns dos seus próprios casos rotulados primeiro, ver se o comportamento pronto a usar é suficientemente bom para automatizar, e só então avaliar se executar um checkpoint de 4,69B por conta própria vale a pena para as operações.

Qual deles você deveria realmente escolher

Escolha o RSI-Jev v6.1-VL 4B se a decisão precisar ficar dentro do seu perímetro, se você precisar de uma decisão sobre uma imagem, bem como sobre texto, se seus conjuntos de opções chegarem às centenas (o checkpoint admite até 5.120 opções por pergunta) ou se quiser ajustar a profundidade e a latência por solicitação. Avance ciente de que está adotando um projeto que mudou oito vezes em treze dias, de que seu lançamento mais recente trocou a calibração pela precisão e de que sua própria ficha nomeia as partes da política de saída que não conseguiu confirmar.

Escolha o Jev 1.13 se você quer que a decisão funcione sem uma stack de serving, se você valoriza um endpoint que outra pessoa mantém no ar, e se o preço de $0.042 por milhão de tokens de entrada — sem tokens de saída para medir — for barato em relação ao seu volume de chamadas. Vá sabendo que você está chamando um modelo fechado cujo tamanho não é divulgado, cujos limites de taxa podem mudar sem aviso, e cujos benchmarks publicados não são algo que você possa executar de novo.

O que ambos têm em comum é mais útil do que o que os separa, e é a razão pela qual uma comparação como esta vale a pena ser escrita. Nenhum dos modelos gera texto, portanto nenhum introduz a classe de falhas que vem de um modelo que se esquece de fechar uma chave ou inventa um campo. Ambos retornam probabilidades e, nos dois casos, a probabilidade é a parte que você precisa validar nos seus próprios dados rotulados antes de automatizar com base nela — a latência já se tornou uma commodity, e o valor de confiança é o que precisa ser conquistado a cada implementação. Independentemente do lado da linha entre o download e a chamada em que você acabar, teste a calibração primeiro.