Brasileiro faz em casa um concorrente aberto do Jev (TypeSafe) que também entende imagem: números, créditos e o que errei
Transparência antes de qualquer coisa: quem escreve é quem fez. Não é matéria, não é assessoria, não tem empresa atrás. Sou um brasileiro que trabalha como CTO de dia e, à noite, montei isso no servidor de casa, em duas RTX 3090 usadas, sem contar para ninguém. Escolhi publicar aqui porque o TabNews é o lugar onde eu quero ser cobrado com exatidão sobre cada número abaixo.
O que é o Jev, em um parágrafo
A TypeSafe lançou na semana passada o Jev, um modelo que eles chamam de "System One". Em vez de gerar texto token por token, ele recebe um estado (texto, JSON, logs) e perguntas tipadas: sim/não, uma entre N opções, um nível numa escala. Devolve uma distribuição de probabilidade para cada pergunta, em milissegundos. Não alucina no sentido usual porque não escreve nada, só escolhe entre opções que você definiu. Para roteamento, classificação, triagem e verificação, é outra categoria de ferramenta. Só que é fechado, hospedado, e tem lista de espera.
O que eu construí
Chamei de Open-RLCD. É uma API com o mesmo contrato do Jev (o SDK oficial da TypeSafe funciona apontando o base_url para a minha máquina), rodando em cima de um modelo aberto desmontado: ele nunca gera. Faz uma passada forward, lê os logits só dos rótulos de resposta, e o cache do estado é compartilhado entre todas as perguntas. As três primitivas: Noul (sim/não), Choice (uma entre N, com distribuição e confiança) e Score (níveis ordenados, valor esperado ponderado). Comecei cinco dias depois do lançamento do Jev.
Números medidos no meu hardware, não estimados:
Texto 57 ms por requisição, uma RTX 3090
Imagem cerca de 285 ms por foto
Concordância com o jev-1.13 234 de 255 perguntas (92%) numa bateria de 126 casos que eu mesmo montei; 94% na suíte menor
Imagens 32 de 33
VRAM mínima 8 GB para o modelo de texto, 12 GB para o de visão
Duas ressalvas que eu prefiro escrever antes que alguém escreva por mim. A bateria é minha, então mede o que eu escolhi medir. E a diferença de latência para o Jev é, na maior parte, a ida e volta até o servidor deles. Não é "meu modelo é mais rápido que o deles", é "o meu está na minha rede".
A parte que eu não achei em lugar nenhum: imagem
O Jev é só texto. O modelo de visão do Open-RLCD aceita fotos no estado e responde às mesmas perguntas tipadas sobre elas: é qual aparelho, tem dano, qual a gravidade. 285 ms por foto numa GPU. As fotos entram uma vez no estado compartilhado e todas as perguntas são avaliadas em cima, sem reprocessar a imagem.
Até onde consegui verificar (a documentação do Jev, o código da versão em llama.cpp que saiu esta semana e os repositórios com "RLCD" no nome no Hugging Face), é o único motor aberto nesse estilo que faz isso. Se você conhece outro, me corrija nos comentários. Prefiro saber.
Quem veio antes, e onde o meu se encaixa
Harsha (harshatheg/Qwen-2.5-1B-RLCD) provou a ideia em aberto no dia 16, horas depois do lançamento. Foi a primeira prova pública de que dava para fazer.
Codacus colocou a mesma ideia dentro do llama-server (endpoint /v1/decision, branch parallel-decision) no dia 21. Roda qualquer GGUF na placa que você já tem. Se você só precisa de texto, é o caminho de menor atrito, e eu digo isso sem dor.
O Open-RLCD é o único dos três com imagem, o único compatível com o SDK oficial do Jev, e o único com concordância medida contra o próprio Jev: 92% em 255 perguntas. Os outros dois compararam com geração de JSON, não com o Jev. Em velocidade bruta ainda não fiz a comparação de igual para igual (mesmo modelo, mesma placa, mesma bateria). Quando fizer, publico o resultado aqui, ganhe ou perca.
A TypeSafe teve a ideia e documentou bem o bastante para ser reproduzida. "Jev", "System One" e "TypeSafe" são nomes deles; uso só para descrever compatibilidade.
Os pesos que eu desmontei vêm de modelos abertos com licença permissiva. Quais são, eu mostro no vídeo. Não é mistério por marketing: é a parte do trabalho que eu ainda quero contar do meu jeito, com a tela aberta.
Três coisas que errei
Medi 54 ms no modelo de visão e quase publiquei. O cronômetro começava depois de decodificar a imagem. O número real é cerca de 285 ms. Se o número parece bom demais, procure onde o timer começa.
Treinei uma cabeça de calibração (objetivo Brier) que melhorou tudo nos dados de treino, ECE de 0,16 para 0,04, e derrubou a concordância fora do domínio de 94% para 81%. O servidor hoje roda zero-shot. Calibrar no seu dataset é fácil; generalizar não é.
Rótulos por letra (A, B, C) têm viés de posição. Fiz permutação de ordem para compensar e ela piorou a primitiva Score: numa escala de estrelas, 3,87 virou 3,24 contra 3,9 do Jev. Ficou desligada por padrão e restrita a Choice.
Duas partes já estão abertas
Não é tudo promessa. Dois pedaços do ecossistema já estão no meu GitHub, os dois Apache-2.0.
MonkeyLLM (github.com/JimmyWesley/MonkeyLLM, site em monkeyllm.com) é um motor de conhecimento para agentes. Seus arquivos viram um grafo de markdown versionado em git que o agente navega por MCP: resumos curados, arestas tipadas, respostas citadas, SQL sobre as planilhas, nada picado em chunks anônimos, nenhum banco vetorial. O número que me fez escrever aquilo: num benchmark em que toda pergunta precisa de 3 ou mais saltos entre documentos, o mesmo modelo local de 12B acerta 0 de 11 como RAG top-k e 11 de 11 como navegador, a 0,66× o custo em tokens por resposta certa, numa única RTX 3060. Busca de entrada em 1,3 ms, sem embedder. pip install monkeyllm; o paper e os scripts de cada número estão no repositório.
RLCD Gateway (github.com/JimmyWesley/rlcd-gateway, aberto hoje) é a ferramenta para quem quer usar modelos de decisão de verdade, e não só testar. É um gateway em Go para agentes de código (Claude Code, Codex, OpenCode) e para qualquer app com SDK da OpenAI ou da Anthropic: você aponta o base URL para ele e pronto, sem proxy de sistema, sem certificado. Ele faz três coisas. Intercepta cada chamada e roteia para o provedor que você escolher, com o app segurando uma chave do gateway em vez da chave do provedor. Reduz consumo de tokens: antes de encaminhar, poda os blocos antigos do contexto que o objetivo atual não precisa mais, trocando cada um por um marcador que o modelo pode restaurar se precisar; quem decide "manter?" por bloco é um modelo System One, o Open-RLCD ou o próprio Jev, sem reescrever texto nenhum. E permite governar as decisões: regras de decisão configuráveis no fluxo, a partir de templates, com teste ao vivo antes de ativar; fallback quando o backend falha; e cada decisão registrada para auditoria, com estatísticas por pergunta. A poda começa em modo sombra, mostrando quanto teria economizado em cada turno sem tocar na requisição, até você confiar nas decisões. Não vou dar um percentual de economia porque ainda não tenho um medido de verdade; o painel calcula por turno, com o cache de prompt na conta.
O lado que eu não queria escrever
Sou tímido e nunca quis aparecer. Fiz tudo calado, esperando ficar bom o bastante antes de alguém ver. O que me tirou do anonimato foi assistir, em uma semana, várias pessoas publicarem a mesma ideia, e nenhuma com imagem. Gravei o primeiro vídeo da minha vida e coloquei meu rosto nele. E como benchmark de tabela cansa, no vídeo eu coloco os dois modelos para trocar porrada em jogos: Tetris e Street Fighter II Turbo, decidindo cada movimento em tempo real. No Street Fighter, o lado do Open-RLCD joga olhando a tela, com o modelo de visão, sem nenhuma leitura de memória do jogo. Quem ganha, eu deixo para lá: https://youtu.be/544l_1_iBsk
Onde está e o que eu prometo
O site https://open-rlcd.com tem as capturas reais do playground e da bateria, a tabela de requisito mínimo e o comparativo com modelos de chat. O motor está privado, e explico sem rodeio: quero viver de código aberto, e a única moeda que me permite isso é gente acompanhando o trabalho. Quando o canal chegar a 5 milhões de inscritos, o repositório abre inteiro: motor de texto, de visão, playground e bateria. Sei que é uma meta enorme e sei que muita gente vai achar a mecânica errada. Aceito a crítica, e prefiro ela aqui do que em silêncio. O gateway e o MonkeyLLM já estão abertos; se quiser saber como eu trabalho antes de decidir se acompanha, está tudo lá.
Se você trabalha com classificação, triagem ou roteamento e tem uma GPU parada, me conta nos comentários qual seria o primeiro uso. Respondo qualquer pergunta técnica que couber aqui.
Fonte: https://open-rlcd.com