Nemotron 3.5 Bolt 24GB vs Nemotron 3.5 Bolt 74B: Um Modelo, Dois Artefatos

Isto é uma comparação entre um modelo e ele mesmo. N​VIDIA N​emotron 3.5 Bolt 74B-A9B 24GB e N​VIDIA N​emotron 3.5 Bolt 74B-A9B BF16 são a mesma arquitetura com a mesma contagem de parâmetros, produzidos na mesma semana, do mesmo pai — e a própria documentação da N​VIDIA diz claramente que um é para executar e o outro é para alterar. Tratá-los como rivais é um erro de categoria; tratá-los como intercambiáveis é um erro caro. Aqui está a diferença, medida em bytes e em pontos de benchmark.

O que os dois artefatos realmente são

Os nomes descrevem o pipeline, não dois designs. A N​VIDIA pegou o N​emotron 3.5 Super VL 120B-A12B, executou uma busca de arquitetura guiada por roteador chamada Star Elastic contra um orçamento de memória e produziu um modelo de 74 bilhões de parâmetros com 9 bilhões de parâmetros ativos. Esse resultado existe em duas formas publicadas: os pesos BF16 como saíram do pós-treinamento, e os mesmos pesos com as camadas de especialistas quantizadas para 2,0625 bits por elemento e reparadas com destilação ciente de quantização.

Ambos estão datados de 15 de outubro de 2026 em seus cartões de modelo. Ambos trazem a mesma licença OpenMDW-1.1, a mesma janela de contexto de 256.000 tokens, o mesmo backbone híbrido Mamba-2 LatentMoE e o mesmo codificador de visão C-RADIO v4-H. Os metadados do repositório tornam a relação explícita em um único campo: o cartão do checkpoint de 24 GB lista base_model_relation: quantized em relação à versão BF16.

O que difere é para que serve cada uma. A placa de 24 GB define seu caso de uso como harnesses de agentes locais — chamada de ferramentas, navegação, trabalho no terminal — e sua implantação como vLLM em Ampere, Hopper ou Blackwell. A placa BF16 define seu caso de uso como pós-treinamento com NeMo RL e NeMo Gym, adaptação de domínio, destilação e produção de suas próprias variantes quantizadas, e avisa, no mesmo parágrafo, que para inferência otimizada para latência e vazão você deve usar a versão de 24 GB em vez dela. Quando um fornecedor diz para você não executar um checkpoint que acabou de baixar, vale a pena ler ao pé da letra.

A diferença de tamanho, lida na listagem de arquivos

• BF16 — 149,8 GB no total em 63 shards safetensors, maior shard 3,71 GB, mais uma torre de visão de 228 MB.

• safetensors de 24 GB — 24,12 GB distribuídos em 90 shards na versão pronta para vLLM, o que é marginalmente superior ao número no nome do modelo.

• 24GB GGUF — 22,02GB em um único arquivo, além de um projetor de visão separado de 1,73GB, totalizando 23,75GB.

• Razão — aproximadamente seis para um em bytes, de especialistas de 16 bits para especialistas de 2 bits, além de tratamento em precisão mista para todo o restante.

Sessenta e três shards contra noventa também é uma diferença de forma, não apenas de tamanho. A versão BF16 foi criada para ser carregada por um framework de treinamento, seja qual for o layout paralelo que você tiver; a versão de 24GB foi criada para ser carregada por uma única GPU, ou pelo llama.cpp em uma única máquina, e a contagem de shards reflete o trabalho diferente.

Vale a pena entender três gigabytes da diferença de 24 GB antes de planejar o armazenamento. O projetor de visão é um arquivo separado na build do GGUF porque é assim que o llama.cpp lida com entrada multimodal, e quem baixa apenas os pesos e depois se pergunta por que as imagens não funcionam deixou-o de fora. Na build do safetensors, a torre de visão fica dentro dos shards e o total ultrapassa a linha dos 24 GB.

Quanto custou a quantização, segundo os próprios números da N​VIDIA

A ficha do BF16 publica ambas as colunas lado a lado, o que é incomumente revelador: a mesma tabela de benchmarks traz os números do IQ2 24 GB e os números do BF16 para as mesmas treze avaliações. Divulgados pelo fornecedor, não reproduzidos, e ainda assim a evidência mais direta disponível sobre quanto custam dois bits por especialista.

• Terminal-Bench 2.1 — 50,98 em IQ2 contra 53,93 em BF16, uma perda de 2,95 pontos.

• BrowseComp — 66,75 contra 70,00, uma perda de 3,25.

• GPQA Diamond — 86,43 contra 88,83, uma perda de 2,40.

• Raciocínio de contexto longo AA-LCR — 64,06 contra 67,38, uma perda de 3,32.

• HLE sem ferramentas — 25,30 contra 28,73, uma perda de 3,43.

• Precisão do AA-Omniscience — 16,90 contra 21,80, uma perda de 4,90, a maior da tabela.

• PinchBench — 87,82 contra 90,35, uma perda de 2,53.

• GDPVal-AA-V2 — 28,47 contra 31,13, uma perda de 2,66.

Duas linhas quebram o padrão, e são as interessantes. Na métrica de não alucinação do AA-Omniscience, o modelo quantizado obtém pontuação mais alta, 61,27 contra 56,14 — comprimir os especialistas tornou o modelo menos propenso a responder com confiança quando não sabe, que é o tipo de descoberta que torna uma tabela digna de ser publicada na íntegra. No WebArena vision, os dois estão no mesmo nível, 50,86 contra 50,25, sugerindo que o caminho de visão sobreviveu à compressão mais ou menos intacto, e o retreinamento do adaptador de visão descrito no cartão do modelo é, presumivelmente, o motivo.

Lidos em conjunto: uma penalização de dois a cinco pontos na maioria das linhas de capacidade, quase nula na fundamentação visual, e uma melhoria numa métrica de calibração. É um resultado favorável para uma compressão de seis para um, e continua a ser uma penalização que se deve contar em vez de ignorar.

Qual deles você pode realmente servir?

O artefato de 24GB tem uma história de runtime e o de BF16 tem uma história de treinamento, e não são a mesma história com uma flag diferente.

O GGUF de 24GB está listado para llama.cpp, e a NVIDIA aponta o mesmo modelo para Ollama, LM Studio e Unsloth. O caminho do vLLM é mais rigoroso do que parece: a receita de referência fixa um contêiner nightly por hash de commit, exige um pacote de kernel separado buscado em tempo de execução, define explicitamente o executor de modelo v2, nomeia b12x para os backends linear e MoE com FlashInfer para atenção e Mamba, fixa o cache KV em fp8 e define max-num-seqs 1. Esse último flag é o que merece atenção — a configuração de serving publicada é uma única sequência concorrente, que é uma configuração em formato de laptop, não uma em formato de serving.

O drafter é um terceiro download. LiLiCorr é um checkpoint complementar de 1,13B cujo card declara com todas as letras que não é um modelo de linguagem autônomo, que propõe tokens de rascunho e que o alvo de 24GB os verifica, e que o alvo produz o texto visível. Os 83,99 tokens por segundo relatados pela N​VIDIA no AIPerf SPEED-Bench-Coding pressupõem que ele esteja anexado, com sete tokens rascunhados por passo e comprimentos médios de aceitação de 4,68 sob decodificação greedy e 4,25 com amostragem na concorrência 64.

A história de serving do checkpoint BF16 é o seu problema para resolver. Ele precisa de aproximadamente seis vezes a memória da versão quantizada antes de qualquer KV cache, o que inviabiliza um único acelerador de 80 GB e faz de multi-GPU ou multi-node o pressuposto padrão. Essa é a escolha certa para pós-treinamento e a escolha errada para inferência, que é exatamente o que o cartão diz.

A decisão, dita claramente

Se você quiser executar um agente hoje em hardware que você possui, baixe a build de 24 GB, aceite o imposto de dois a cinco pontos e inclua no orçamento o drafter e o projector, além dos pesos.

Se quiser mudar o modelo — ajustá-lo com fine-tuning nos seus próprios dados, destilá-lo em algo menor ou comprimi-lo de forma diferente para hardware que a N​VIDIA não otimizou — baixe a versão BF16 e trate o lançamento de 24 GB como documentação de um possível resultado.

O caso intermediário interessante é aquele para o qual o cartão BF16 convida explicitamente: produzir sua própria variante quantizada. Alguém com um acelerador diferente, ou com apetite por pesos de quatro bits, ou com uma carga de trabalho que exige mais concorrência do que a receita de referência permite, pode pegar os pesos de precisão completa e construir o artefato que a NVIDIA não construiu. O imposto de quantização acima é, então, o número a ser batido, e agora é uma meta publicada em vez de um mistério.

Onde um gateway se encaixa em uma pilha local

Nenhum desses checkpoints está hospedado em lugar nenhum, inclusive por nós — o catálogo do OrcaRouter não contém nenhum modelo N​emotron, então não há endpoint nem preço a cotar para nenhum deles. A inferência local também é sempre apenas metade de uma arquitetura de agente: a máquina que executa o Bolt ainda precisa acessar modelos que não consegue baixar, seja um modelo de fronteira para os casos difíceis, um modelo de visão para algo que o Bolt lida mal, ou uma segunda opinião sobre uma decisão que importa.

Essa é a camada que operamos. Uma única chave para mais de 200 modelos hospedados ao preço de tabela do provedor, sem acréscimo; failover automático quando um provedor degrada no meio de uma requisição; uma DSL de roteamento que transforma "tentar o Bolt localmente, escalar para um modelo hospedado quando a tarefa o exceder" em configuração em vez de código. A metade de 24GB da pilha é decidida pelo seu hardware e pela sua tolerância a um contêiner que roda à noite. A metade do outro lado do escalonamento é decidida por quem detém a chave.

O que mudaria esta imagem?

Duas coisas, e ambas são previsíveis.

O primeiro é uma build de quatro bits ou FP4 do Bolt da NVIDIA ou da comunidade, dado que a família de origem já disponibiliza checkpoints NVFP4 e a versão BF16 existe precisamente para que tais variantes possam ser criadas. Um Bolt de quatro bits que recuperasse metade da diferença acima e que, ainda assim, coubesse num envelope de 24 GB tornaria o argumento do imposto de quantização consideravelmente menos interessante.

O segundo é qualquer avaliação independente de qualquer um dos artefatos. O painel Artificial Analysis mediu o modelo de 24GB em 21 no seu Intelligence Index, sem velocidade nem custo publicados, porque não há nada com que medir um preço. Ninguém publicou sequer uma execução reproduzível do checkpoint BF16, o que não surpreende para um download de 150GB destinado ao treinamento. Até que alguém o faça, a diferença entre as duas colunas acima é o relato de um fornecedor sobre a sua própria compressão, e a forma honesta de lê-la é como uma afirmação que, por acaso, é excepcionalmente bem sustentada pela forma das evidências.

Um resultado como este também é um lembrete de que erros de modelo já estão documentados: os incidentes de IA e as falhas de agentes por trás de modelos dessa classe são reunidos no OrcaRouter AI Incident Archive, onde cada entrada traz suas próprias fontes, severidade, grau de confiança e indicador de disputa.