Nace.AI torna o Drex 1.5 open source: modelo de decisão de 9B pontua opções em uma única passagem direta e atinge 93,4% em documentos longos de 128K
Segundo o MarkTechPost, em 9 de outubro de 2026, a Nace.AI tornou open source o Drex 1.5, um modelo de decisão denso de 8,95B que lê um estado e uma pergunta tipada e devolve probabilidades para as opções, sem gerar texto. O relato diz que ele obteve 58,08 no Decision Index 0.3.1 e que pode rodar localmente em uma única GPU com bf16 ou em uma versão quantizada de cerca de 9,5 GB.
O que mudou
Segundo o MarkTechPost, em 9 de outubro de 2026, a Nace.AI tornou open source o Drex 1.5, um modelo de decisão denso de 8,95B voltado a agentes e fluxos de trabalho de backend. O modelo não gera texto: o usuário envia um estado (texto ou JSON) e uma pergunta nomeada, e o modelo retorna, em uma única passagem direta, probabilidades para cada opção, com suporte a três tipos de pergunta: choice, noul (sim/não) e ordinal score; como não amostra tokens, temperature e top_p não se aplicam. A fonte afirma que o backbone é o MiMo-V2.6-Distill-Qwen-9B, com 32 camadas e atenção híbrida (cada camada de atenção completa acompanhada de 3 camadas de atenção linear), além de uma cabeça de ponteiro separada, head.pt, que pontua os estados ocultos. A interface é POST /v1/systemone, com formato de requisição idêntico ao do modelo fechado Jev, da TypeSafe; segundo a fonte, clientes Jev existentes podem migrar alterando poucas variáveis de ambiente. O contexto padrão é de 16384 tokens, com máximo de 131072; os pesos foram publicados no Hugging Face, a versão hospedada está no OpenRouter e a fonte afirma que a capacidade computacional é fornecida pela DeepInfra.
Impacto para desenvolvedores
Para os desenvolvedores, a mudança mais direta é que a tarefa de decisão deixa de ser “pedir a um modelo de chat que produza texto estruturado e depois analisá-lo” e passa a ser “obter probabilidades das opções em uma única passagem direta”, o que elimina lógica de análise e nova tentativa e torna a latência da decisão mais previsível. Segundo o relato, documentos longos são o ponto forte do Drex 1.5: de 32K a 128K tokens, 93,4% de acurácia e latência mediana de 2,0 segundos; quando o mesmo lote de requisições é truncado para 8K tokens, a acurácia cai para 76,5% e 78%, o que indica diferença clara entre o desempenho em decisões de contexto longo e de contexto curto — algo relevante para fluxos de trabalho de arbitragem pós-RAG ou de ordenação de múltiplas opções candidatas. Por outro lado, o relato aponta que ele é uma camada de decisão, não um modelo de uso geral: não gera texto, código nem explicações; tarefas intensivas em conhecimento são seu ponto fraco, com GPQA Diamond em 45,4% contra 78,6% do Jev, MMLU-Pro em 58,7% contra 82,7% do Jev; no ACOS, a F1 para análise de sentimento de um único comentário é de apenas 7,4%, contra 29,5% do Jev. O treinamento usou o conjunto oficial do benchmark de indexação, o que lhe dá vantagem em tipos comuns de decisão, mas a fonte também alerta que os resultados podem diferir em novos domínios. No nível de implantação, a rota local exige os forks da Nace do llama.cpp e do Ollama, e não as builds da linha principal upstream; os pesos usam a licença Open RAIL-M, e a fonte alerta explicitamente para verificar os termos antes do uso comercial — é aqui que “pesos abertos” e “licença de código aberto” precisam ser considerados separadamente, pois a disponibilidade dos pesos não equivale a uma licença permissiva.
Integração e avaliação
O que segue são sugestões e análises condicionais baseadas no relato da fonte, não fatos já verificados. Primeira decisão: migrar ou não os pontos de chamada atuais do Jev para o Drex 1.5. O relato afirma que o formato de requisição dos dois é o mesmo e que o custo de mudança está sobretudo nas variáveis de ambiente; portanto, quando a carga de trabalho for predominantemente de pontuação de opções, decisões sim/não e ordenação ordinal, e a equipe quiser tirar o tráfego de decisão de uma API fechada, é mais prudente começar com uma comparação em tráfego-sombra; um critério de aceitação mensurável é enviar o mesmo lote de requisições históricas pelos dois caminhos e medir a taxa de concordância das opções e a proporção de casos em que a probabilidade da opção mais alta fica abaixo do limiar; se a concordância for alta e a proporção de amostras de baixa confiança não subir de forma clara, aumentar gradualmente o volume; se a carga de trabalho incluir geração de explicações ou respostas que exijam processo de raciocínio explícito, não migrar, porque, segundo o relato, o modelo não gera texto. Segunda decisão: em cenários de documentos longos, usar diretamente a faixa de 128K em vez de truncar primeiro. O relato mostra 93,4% de acurácia e latência mediana de 2,0 segundos na faixa de 32K a 128K, enquanto o truncamento para 8K reduz a acurácia para 76,5% e 78%; portanto, quando a entrada for realmente um documento longo e o orçamento de latência comportar o custo de segundos, preservar o contexto longo pode ser a escolha de maior ganho; na avaliação, medir acurácia e latência P95 por faixas de comprimento (até 8K, de 8K a 32K, de 32K a 128K); se a latência da faixa longa ultrapassar o orçamento, considerar o truncamento, aceitando a queda de acurácia. Terceira decisão de implantação: rodar localmente ou usar a versão hospedada. O relato afirma que bf16 ocupa cerca de 18 GB e roda em uma única A10G de 24 GB, que o Q8_0 GGUF ocupa cerca de 9,5 GB e roda em chips Apple e CPU, e que as duas rotas de quantização dão respostas consistentes; portanto, quando os dados não podem sair da rede interna ou for necessária inferência offline, a implantação local é viável, desde que se aceite usar as builds dos forks da Nace e se aceitem as condições da Open RAIL-M. O critério de avaliação é comparar a consistência das respostas entre local e hospedado no mesmo conjunto de avaliação, e verificar se a vazão em uma única GPU atende à demanda de requisições por segundo. Os preços mudam; para custos de hospedagem, consultar as páginas atuais de preços do OpenRouter e do Nace Console.
Limites e pontos a confirmar
É preciso deixar claro que o Drex 1.5 não aparece atualmente entre os modelos do KimiSeek; a disponibilidade de API mencionada no relato aponta para o serviço hospedado do próprio fornecedor e não tem relação com o catálogo deste site. As pontuações de benchmark citadas na fonte (58,08 no Decision Index 0.3.1, 86,2% no JevBench, 122 vitórias, 47 empates e 87 derrotas no OpenSpiel, 93,4% em documentos longos etc.) são resultados reportados pela Nace ou pelos responsáveis pelos rankings, em sua maioria obtidos pela própria fabricante ao rodar as suítes oficiais de avaliação, e este site não os reproduziu de forma independente. O relato também indica que o treinamento do modelo usou o conjunto de treinamento oficial do benchmark de indexação, de modo que o desempenho em novos domínios de decisão pode ficar aquém das pontuações dos rankings; as fraquezas em análise de sentimento do ACOS e em testes de conhecimento já foram apresentadas no relato. Além disso, as rotas do Ollama e do llama.cpp dependem das versões forkadas pela Nace, e a linha principal upstream pode não oferecer suporte sincronizado; os pesos são abertos, mas a licença é a RAIL-M, com restrições de uso, e o uso comercial exige verificação própria dos termos. O bônus de cadastro de 25 dólares e os preços de hospedagem mencionados no relato referem-se ao momento do lançamento e podem ter mudado; consultar as páginas de preços atuais.