Nvidia lança Nemotron 3.5 Bolt E4B para agentes locais
A Nvidia lançou o modelo Nemotron 3.5 Bolt E4B em 23 de outubro de 2026, disponibilizando pesos abertos pós-treinados para workloads de agentes locais e edge. Derivado do Gemma-4-E4B-it, o modelo possui uma arquitetura de 8B parâmetros totais com 4B parâmetros efetivos e suporta janelas de contexto de até 64K tokens. O lançamento foca na execução de baixa latência para assistentes de voz, personas interativas e interfaces de dispositivos, reduzindo o consumo de recursos do sistema.
O que o modelo faz em dispositivos de borda empresariais
A implantação do Nvidia Nemotron 3.5 em agentes de borda executa tarefas para assistentes de voz locais, personas interativas e interfaces embarcadas. O modelo foca no uso de ferramentas em múltiplas etapas, no seguimento de instruções e na fundamentação de entradas. Ele opera com baixo consumo de memória e baixa latência para o primeiro token, permitindo chamadas rápidas de ferramentas enquanto preserva a capacidade do sistema para outros softwares.
Benchmarks comparados com modelos concorrentes
Em avaliações oficiais no ambiente NeMo Gym da Nvidia, os benchmarks do Nemotron 3.5 Bolt E4B mostram altas pontuações no uso de ferramentas e no seguimento de instruções. No formato quantizado Q4_K_M, o modelo atingiu 71.21 no RoleBench, contra 60.51 do Gemma 4 E4B-it e 52.35 do Qwen 3.5 4B. No RoleMRC, alcançou 79.12 contra 75.24 do Gemma 4 e 62.61 do Qwen 3.5 4B. No InverseIFEval, o modelo Q4_K_M registrou 45.26 contra 39.75 do Gemma 4 e 22.04 do Qwen 3.5 4B.
Desempenho do Nemotron 3.5 Bolt vs Qwen 3.5 4B em testes principais
A comparação entre Nemotron 3.5 Bolt vs Qwen 3.5 4B revela diferenças em raciocínio e no uso de ferramentas. Na precisão Q4_K_M, o modelo da Nvidia atingiu 74.13 no ToolSandbox e 69.29 no RelyToolBench, enquanto o Qwen 3.5 4B marcou 74.51 no ToolSandbox e 38.34 no RelyToolBench. No MultiChallenge, o modelo quantizado da Nvidia registrou 55.60 contra 52.23 do Qwen 3.5 4B.
Como rodar o modelo localmente usando Docker
Desenvolvedores interessados em como rodar Nemotron 3.5 Bolt E4B localmente podem implantá-lo via llama.cpp em contêineres Docker. A implantação exige o download do arquivo GGUF Nemotron-3.5-Bolt-E4B-Q4_K_M.gguf do Hugging Face, junto com o arquivo rascunho opcional Nemotron-3.5-Bolt-E4B-DFlash-BF16.gguf. Executar a imagem ghcr.io/ggml-org/llama.cpp com aceleração por GPU expõe um endpoint HTTP compatível com a OpenAI na porta 8000 para respostas de chat.
Requisitos de memória do sistema e arquitetura
Sobre os requisitos de VRAM do Nemotron 3.5 Bolt E4B, a edição quantizada de 4GB foi projetada para implantações locais com pouca memória. A arquitetura baseia-se no Gemma-4-E4B, com 8B parâmetros totais e 4B parâmetros efetivos. O modelo suporta janelas de contexto de até 64K tokens de entrada e saída. Ele foi pós-treinado via aprendizado por reforço multiambiente com otimização GRPO (Group Relative Policy Optimization) em cenários de instrução e ferramentas.
Licença e regras para uso comercial
O modelo é distribuído sob a licença OpenMDW-1.1, pronto para uso comercial e não comercial. Como foi pós-treinado a partir do Google Gemma-4-E4B-it, o uso do modelo base Gemma 4 é regido pela Apache License, Version 2.0. A data de corte dos dados de pós-treinamento é maio de 2026. Os sistemas operacionais suportados incluem Linux nas microarquiteturas de GPU NVIDIA Ampere A100, Hopper H100-80GB e Blackwell.
Perguntas e respostas
O modelo é licenciado para implantação comercial?
Sim, o modelo está disponível sob a licença OpenMDW-1.1 para uso comercial e não comercial, com o modelo base Gemma 4 regido pela Apache License, Version 2.0.
Como é o desempenho do modelo contra o Qwen 3.5 e Gemma 4?
Nas avaliações do NeMo Gym na quantização Q4_K_M, o modelo obteve 71.21 no RoleBench e 69.29 no RelyToolBench, superando o Gemma 4 E4B-it (60.51 e 67.15) e o Qwen 3.5 4B (52.35 e 38.34).
A visão da MOZGII
Como nós construiríamos
Para implantar um assistente de dispositivo local em hardware edge, combinaríamos um motor embutido como o llama.cpp com um roteamento estrito de funções locais. Carregaríamos os pesos quantizados de quatro gigabytes ao lado de um arquivo rascunho auxiliar para manter a baixa latência no hardware local. Alimentaríamos o modelo com a telemetria do dispositivo local, entradas do usuário e esquemas de ferramentas definidos. Uma camada fina de software local traduziria as chamadas de ferramentas do modelo diretamente em comandos de hardware.
O sistema falha quando o contexto complexo de múltiplos turnos causa limites de memória ou formatação inválida de parâmetros de ferramentas. Para controlar a execução, executaríamos scripts de validação baseados em regras sobre cada chamada de função gerada antes de passá-la para os drivers do dispositivo. Um administrador de sistemas revisaria chamadas de ferramentas com falha e entradas de usuário não tratadas registradas durante a operação. Rastrearíamos o tempo até o primeiro token como nossa métrica principal.
Em seguida, construiríamos uma rota alternativa automatizada para consultas que excedam os limites do agente local. Quando uma entrada exigisse um raciocínio mais profundo ou memória longa além da janela de sessenta e quatro mil tokens, o agente edge rotearia a carga de trabalho para um servidor na nuvem.
Fontes
De onde vêm os fatos desta matéria.