NVIDIA 发布了 Nemotron-3.5-Bolt-E4B 4GB，这是一款给本地助手、互动角色和机器人使用的小模型，重点是自然地接话，并调用工具完成任务。模型基于 Google Gemma-4-E4B-it 构建，经过强化学习后训练，量化后在目标负载下的运行显存约为 4GB。主要功能特点包括：

• 多轮工具调用与动作决策：支持在连续对话中调用应用接口，读取执行结果，再决定下一步动作。
• 对话模式一键切换：在模板中提供开关，启用后自动加入精简指令并减少排版符号，输出适合语音播报的口语短句。
• 可调节思考机制：支持运行时开启或关闭显式思考过程，并支持设置思考 Token 预算上限以控制响应时延。
• 64K 上下文窗口：容纳系统设定、多轮历史对话、工具定义、环境状态与检索知识。
• 端侧多设备运行：面向 GeForce RTX 显卡、Jetson 嵌入式计算板、RTX Spark 与边缘设备。

说是 4GB 模型，到底需要多大显存和内存？

在讨论端侧部署时，“8B”、“4B”、“4GB”与“6GB”常被混淆。理解 Nemotron-3.5-Bolt-E4B 的资源需求，首先要分清参数规模、权重文件与运行时内存的具体指向。

模型的总参数量为 8B，有效参数量（Effective Parameters）为 4B。这继承自底座 Gemma-4-E4B 的分层嵌入（PLE）设计：模型让每层按 token 查找各自的专属嵌入表，表虽然体积大，但主要用于快速查表，不像常规计算层每次都要进行密集运算；因此，它的总参数有 8B，有效计算规模则按约 4B 命名。查找表仍然需要存储，不能据此把权重占用减半。（B 表示十亿：8B 是 80 亿参数，4B 是 40 亿。参数描述模型规模，GB 描述存储或内存容量。）

量化是降低权重数字的保存精度，以减少模型体积与运行资源需求；不同方案对体积和能力的取舍也不同。在实际存储与运行时，权重文件、显存占用与整机内存各不相同：

• 权重文件大小：BF16 全精度权重约为 15GB。官方采用重要性矩阵（imatrix）校准后的 Q4_K_M 4 位量化 GGUF 文件约为 6.18GB；而 Unsloth 发布的 UD-Q4_K_XL 量化文件约为 4.76GB。下载时要认准各自的量化规格。
• 运行时显存占用（VRAM）：在典型的单会话业务负载下（如 3,000 Token 输入、50 Token 输出），RTX 5070 上的显存开销约为 3.5GB；在 32K 缓存的多轮长会话中约为 4.3GB；在配备 8GB 统一内存的 Jetson Orin Nano 上，整套推理运行时占用约为 4.2GB 至 4.9GB。这也是命名中“4GB”的由来——将目标负载下的显存开销控制在 4GB 左右。这里 6.18GB 统计的是整份磁盘权重，而 3.5GB 仅计算 GPU 显存占用，运行还需要配合系统内存。4GB 是目标负载下的显存指标，不是整机只需 4GB 内存。
• 整机运行内存（RAM）：Unsloth 给出的运行参考是约 6GB RAM。实际占用还会随量化版本、上下文长度与运行软件变化；看到“6GB”后，仍要为系统和其他应用留出空间。

小模型少占一些内存，语音识别、语音合成、感知模型和应用就更有机会在同一台设备共存。不过，Jetson 的 8GB 是共享内存；除了 Bolt 的占用，还要计算操作系统和其他程序的开销。

为什么它能做到少说废话，专注于执行任务？

小模型充当本地助手时，冗长回答会造成两种麻烦：一是陷入冗长的内心独白，输出大段分析却迟迟不调用工具；二是输出充满复杂排版、长篇大论的书面说明，导致语音播报时延极高且听感生硬。

底座模型 Gemma-4-E4B-it 本身已经具备指令微调（IT）基础。NVIDIA 在本次 Nemotron-3.5-Bolt-E4B 的后训练阶段跳过了额外的监督微调（SFT），全程直接采用强化学习。研发团队曾尝试使用多样化的教师模型数据进行 SFT，实验表明 SFT 虽然能拉高工具调用的表现，但也让对话质量下降、回答变得冗长。因此最终版本选择先检查动作做得对不对（如利用规则直接验证工具调用参数与执行结果的正确性）、回答是否自然，以这些反馈继续训练，将基于可检查结果的奖励（RLVR）与基于偏好的反馈奖励（RLHF）结合起来。（训练在 NeMo-RL 与 NeMo-Gym 框架下开展。）

为了让小模型在交互中更敏捷，训练中落实了三项机制：

1. 非思考与思考样本 2:1 配比：训练集里的每一条样本，都会分别在开启思考（enable_thinking=true）和关闭思考（enable_thinking=false）两种模式下生成与评估奖励。训练批次中维持 2 份非思考样本比 1 份思考样本的比例，使模型在无需显式中间推演链条时，也能准确理解指令并输出正确动作。
2. 动态调整长度惩罚：随着强化学习进行，模型往往倾向于拉长推演过程来规避错误。团队在生成奖励模型（GenRM）环境中对过长的思考和回答扣分，并通过循环调节扣分力度（放宽与收紧惩罚），让准确率与简洁度一起改善。官方在输出长度对照中给出的结果是：在 BF16 的 21 项基准综合评估中（多数任务开启思考，EQ-Bench、RoleBench 与 RULER 关闭），Bolt 均分为 63.9 分、平均输出 672 tokens；底座 Gemma-4-E4B-it 均分为 58.1 分、输出 782 tokens；而同规模的 Qwen3.5-4B 均分为 57.8 分，输出却达到 3,604 tokens。Bolt 的平均输出比这里的 Qwen 少约 81%，比 Gemma 少约 14%。所以“最多少约 80%”取决于比较对象；长度惩罚是训练中的一项选择，这组对比衡量的是整个模型的结果。
3. 先说话后动作的模板排布：在聊天模板中，当助手的回复同时包含自然语言和工具调用时，模板将解释性文字置于工具调用之前。这使得智能体在触发耗时工具前，能先向用户口头说明（例如“正在为您查询今天的天气…”），再发出调用指令，让对话中的确认和实际动作衔接起来。

官方还测试了游戏里的铁匠商人 NPC：玩家提出想要一把金斧，NPC 要求收取两颗钻石；玩家先交付一颗后，NPC 明确要求补足第二颗，待两颗钻石收齐后，再自主调用工具查询合成配方、取用材料、制作金斧并交付给玩家。在这条执行链中，模型负责输出工具调用请求，外部宿主应用在本地执行对应的真实 API，并将执行结果与新状态回传给模型，模型再基于最新依据推进下一步动作与对话，保持完整的请求与执行闭环。

本地部署跑得有多快？首字延迟与生成速度表现

评估本地助手的响应速度，必须将首字延迟（TTFT，Time to First Token）与生成吞吐率（TPS，Tokens Per Second）分开分析。前者主要受读取输入的“预填充”阶段影响，后者衡量逐步生成内容的“解码”阶段。

首字延迟是指从用户请求进入模型到吐出第一个 Token 的时间，它主要受预填充阶段的计算影响，但并不等同于语音交互中“用户说完到音箱开始发声”的端到端整体延迟（端到端还包含语音识别与音频传输等环节）。生成吞吐率则代表进入解码阶段后，模型每秒能生成多少个 Token。在硬件测试中，32K 缓存指已经缓存的上下文，2K 为本轮新输入，256 为本轮输出；两组负载测试的多项条件不同，不能把两组差值全部归因于缓存长度。

以官方在 Q4_K_M 量化下的基准数据为例：

• 在桌面级独立显卡 RTX 5070（12GB） 上，面对 3,000 Token 的标准输入，TTFT 为 548 毫秒，TPS 达到 133.4 tok/s。
• 但在算力受限的嵌入式边缘设备 Jetson Orin Nano（8GB） 上，处理相同的 3,000 Token 输入，首字延迟升至 5,785 毫秒（近 5.8 秒），解码速率为 15.5 tok/s。

这一同负载对比表明：在算力较低的边缘设备上，面对较长的系统设定与历史上下文，预填充阶段带来的首字延迟会显著拉长用户的等待时间，需要开发者重点控制输入长度。

为了在生成阶段提高解码吞吐，该模型配套发布了基于 DFlash 架构的并行投机采样草稿模型（DFlash Parallel Drafter）。投机采样让小草稿模型先快猜下一串内容、主模型集中检查、采用通过的部分，一次性敲定多个 Token，从而减少了主模型逐个生成的次数。这个草稿模型有 5 层 Transformer，单次前向传播能同时预测 7 个候选 Token，再由主模型并行验证，验证过程严格保持主模型的原始概率分布。

在加速效果上，准确对应的测试基线如下：

• 在 RTX PRO 6000 上运行 BF16 NIM 服务、开启思考且并发为 1 时，配合 DFlash 的单用户解码速率提升至无投机采样基线的 2.74 倍（从 124.7 tok/s 提升至 341.2 tok/s）；
• 在 RTX 5070 上以 batch size 1 测试 SPEED-Bench coding 子集时，两款目标模型均采用 Q4_K_M 量化，Bolt 搭配 BF16 DFlash 草稿模型，其生成吞吐率达到 272.6 tok/s，相比 Gemma-4-E4B-it 官方自带的 MTP 方案（225.9 tok/s）提升了 21%（达到 1.21 倍）。这与前文 133.4 tok/s 属于不同的测试设置，两者不能混淆。

DFlash 加快的是后续生成。在上述 NIM 测试设置中，首字延迟的变化不足 100 毫秒；输入很长时，读取输入的等待仍然需要单独解决。

它能看懂图片、听懂语音吗？多模态与跨语言能力实测

Bolt 继承了 Gemma 4 的看图、听音频能力，但具体能用哪些输入，还取决于部署方式：官方基础 GGUF 模型卡上的输入输出标注为 Text / text，但官方 NIM BF16 微服务原生支持文本、图像与音频输入；在 Unsloth 仓库中，也提供了配套的 mmproj 附加文件供多模态工具加载。看图需要匹配的模型文件与运行工具，加载文本 GGUF 并不等于已经接好了视觉输入。

继承的能力也出现了不同方向的变化：

1. 视觉理解出现了退化：Gemma-4-E4B 底座本身具备多模态能力，但在纯文本强化学习后训练过程中，视觉编码器与语言模型之间出现了对齐漂移。评测表明其视觉指标相比 Gemma-4-E4B-it 出现退化：在开启思考模式下，文档识别基准 OmniDocBench 1.5 指标（越低越好）从 0.21 升至 0.42；多学科视觉理解 MMMU-Pro Vision 从 47.63 降至 42.02，MathVision 从 48.29 降至 46.25。团队尝试单独训练视觉编码器，仍未见明显改善。
2. 音频理解能力有所提升：在开启思考模式下，Bolt-E4B 在单轮语音基准 VoiceBench 上评分为 80.30（高于底座的 78.20）；在多轮语音评测 Audio MultiChallenge 上达到 25.22（高于底座的 19.03）。两款模型均支持最长 30 秒的语音输入，由于 AudioMC 中有超过 50% 的对话包含超出 30 秒的回合，评测成绩受到每轮 30 秒语音输入上限的限制，未覆盖完整未截断的对话。这些分数衡量听懂语音输入；把回答念出来仍需要语音合成。
3. 机器人演示中的感知与动作分工：在官方公布的 Reachy Mini 桌面机器人演示中，实时环境视觉理解由 NVIDIA Cosmos 3 Edge 负责。Bolt-E4B 接收 Cosmos 传来的感知结果，负责组织对话逻辑，并调用机器人既有动画库中的动作脚本驱动身体反应。两个模型在 Jetson Orin Nano 8GB 上本地协作。
4. 跨语言表现的取舍：这次后训练使用英文数据，但 WMT24++ 评测显示其机器翻译质量总体得以保留；而在多语言知识与推理（MMLU-ProX）上出现了小幅但一致的下滑。在开启思考模式下，其中文 MMLU-ProX 得分为 65.17，相比底座 Gemma-4-E4B-it（66.78）低了 1.61 分（非思考模式为 63.32，低 1.12 分）。

各项基准测试表现：它擅长什么，又不适合什么？

NVIDIA 报告的“比 Nano 4B 平均提升约 40%”，覆盖 21 项基准；推文配图里的 70.2 分，来自其中 6 项任务的 Q4_K_M 平均成绩，图中的首字速度在 RTX 5090 上测量，输入约 3,000 个 token、输出约 50 个。70.2 不能当作手机上的速度或通用能力总分。

成绩由 NVIDIA 在统一的 NeMo-Gym 框架下测得，适合用来观察同条件比较；Brevity Benchmark 和 When2Call-MT 尚未公开。

下图六项测试的思考模式并不完全相同：RULER 在 BF16 与 Q4_K_M 两种精度下均关闭显式思考，其余五项则开启思考。关闭思考能够直接给出答复，但也伴随具体任务上的准确率取舍——例如在 BF16 下，关闭思考后 When2Call-MT 得分由 63.36 降至 51.25，Tau2-Bench 由 55.10 降至 34.34。在全部 21 项基准中，Bolt 的非思考模式仍在同组对手中取得 14 项最高或并列最高分；是否关闭，应结合任务所需的正确率来决定。

1. 突出优势：规则遵守与工具判断

• 系统指令冲突遵守（IHEval BF16 84.79 / Q4_K_M 82.40）：在系统预设与用户指令发生冲突或恶意诱导测试中，Bolt-E4B 对系统规则的遵守表现明显好于底座 Gemma-4-E4B-it（BF16 67.04 / Q4 66.61）与 Qwen3.5-4B（BF16 60.57 / Q4 62.87）。这说明它更能坚持预设规则，但仍会出现遵守失败。
• 跨轮约束与角色身份保持：在连续多轮交互中持续遵循规则并维持角色设定，对本地交互式 Agent 尤为关键。在开启思考模式下，测试多轮上下文指令与约束一致性的 MultiChallenge（BF16）中，Bolt-E4B 达到 53.10 分（底座 Gemma-4-E4B-it 为 42.08）；在角色阅读理解与人设依从基准 RoleMRC（BF16）上，Bolt-E4B 达到 80.63 分（底座为 74.62）。这两项结果说明，相比底座，它更善于记住多轮约束、按给定身份回应；这与能否体察情绪是不同的能力。
• 调用时机把控（When2Call-MT BF16 63.36 / Q4_K_M 60.50）：相比 Qwen3.5-4B（BF16 37.85 / Q4 42.88），Bolt-E4B 能更稳定地判断何时直接作答、何时应触发外部工具、何时向用户反问澄清，与底座 Gemma-4-E4B-it（BF16 62.90 / Q4 61.12）表现相当。
• 回答精简度（Brevity Benchmark BF16 82.52 / Q4_K_M 82.84）：在保留核心回答信息的前提下，其表达比底座 Gemma-4-E4B-it（BF16 79.99 / Q4 78.49）与 Qwen3.5-4B（BF16 75.35 / Q4 75.17）更为简练。
• 工具防带偏能力（RelyToolBench BF16 63.16 / Q4_K_M 69.29）：当调用的外部 API 返回虚假或错误字段时，模型抗干扰并纠正执行的能力明显强于 Qwen3.5-4B（BF16 43.35 / Q4 38.34）。
• 资料检索依据与事实选择：从检索资料中提取有据事实不同于工具异常时的抗干扰。比如本地助手在读取设备手册或本地知识库后，需要准确基于提供的内容作答，避免脱离材料编造。在开启思考模式下，衡量依凭检索材料生成事实的 GaRAGe（BF16）中，Bolt-E4B 达到 42.61 分，高于底座 Gemma-4-E4B-it 的 34.73 分；而在辨别无依据陈述的 RAGTruth（BF16）上，Bolt-E4B（77.59）相比底座（76.97）改善幅度较小，回答仍可能出现缺少依据的说法。

2. 明显短板：复杂多步任务与长文检索

• 复杂多步骤客服任务（Tau2-Bench BF16 55.10 / Q4_K_M 52.32）：在包含用户状态迁移与退改签等复杂多步骤客服任务中，Bolt-E4B 虽高于底座 Gemma-4-E4B-it（BF16 38.50 / Q4 38.72），但明显落后于 Qwen3.5-4B（BF16 75.06 / Q4 61.74），在多步规划任务上显得吃力。
• 超长文本检索（RULER 64K BF16 86.99 / Q4_K_M 85.76）：在 64K 满上下文的精确信息定位中，得分与底座 Gemma-4-E4B-it（BF16 86.55 / Q4 86.14）接近，但低于 Qwen3.5-4B（BF16 95.15 / Q4 95.37），也落后于前代 Nano 4B（BF16 91.51 / Q4 91.31）。面对长文档的密集检索并不是它的强项。
• 情绪理解与共情（EQ-Bench v3 BF16 39.40 / Q4_K_M 38.15）：该项评估在关闭思考模式下进行，得分略低于底座 Gemma-4-E4B-it（BF16 41.17 / Q4 39.77），但高于 Qwen3.5-4B（BF16 32.92 / Q4 32.07）。

如何上手体验与调用模型？

在下载或配置模型时，需注意认准 E4B 规格，避免误下载同系列中体积大得多的 74B 规格（如 74B-A9B 权重超过 20GB，需要完全不同的硬件配置）。

1. 图形化试用（Unsloth Desktop）

适合希望在 Mac、Windows 或 Linux 上直接进行本地对话体验的用户：

• 打开 Unsloth Desktop 应用，进入 Model Hub。
• 搜索 Nemotron 3.5 Bolt，在列表中明确选择 E4B 规格（如 NVIDIA-Nemotron-3.5-Bolt-E4B-UD-Q4_K_XL.gguf）。
• 初次体验时，可将上下文长度设置为 4,096 或 8,192 Token 作为短上下文的尝试起点，根据实际硬件显存表现再逐步调整，而非所有设备都能直接满足长上下文运行。

2. 开发者部署参考

具备 NVIDIA GPU 的 Linux 开发者，可直接参考官方 Hugging Face 模型卡（nvidia/NVIDIA-Nemotron-3.5-Bolt-E4B-4GB）与 NIM 指南获取容器部署方法。在启动服务时，应根据实际显存合理设置上下文窗口大小，避免因直接设置 64K 上下文而造成内存耗尽。

3. 核心调用参数与模式控制

通过 API 客户端调用时，需注意官方推荐的设置与特有参数：

• 采样参数：官方推荐在开启和关闭思考模式下，均保持 temperature=1.0 与 top_p=0.95。
• 对话模式（conversational_mode）：在调用中传递 chat_template_kwargs={"conversational_mode": True}，模板会在系统提示中加入简短、少用复杂排版格式的口语化指令，而非强制剔除所有格式；该开关与思考模式相互独立，可自由组合搭配。
• 思考模式控制（enable_thinking）：通过 chat_template_kwargs={"enable_thinking": False} 可关闭显式思考过程直接输出回答，但这只代表不输出思考链条，并不意味着底层完全不做推理；若需设置思考 Token 预算上限，--reasoning-budget 仅为 llama.cpp 的 llama-server 启动选项，NIM 则通过请求级的 thinking_token_budget 参数控制。硬性上限会直接截断思考过程，需要结合具体任务进行验证，语音识别、工具执行等其他环节的延迟仍需另外处理。
• 开源协议说明：模型权重遵循 OpenMDW-1.1 协议，官方模型卡注明可用于商用或非商用场景；底座 Gemma-4 虽然采用 Apache 2.0 协议，但本次后训练权重需遵守 OpenMDW-1.1 条款，使用本次权重时应按其标注协议处理。

Nemotron-3.5-Bolt-E4B 4GB 将重心放在了端侧有限资源下的本地助手与受控交互场景。它在精简回答长度、执行多轮工具操作和遵守系统指令层级上表现突出，适合需要快速反应的桌面伴侣、车载语音或机器人动作调度任务；而在超长文本检索与复杂多步业务规划上仍有明显短板。在实际落地时，开发者仍需根据自身设备的延迟承受力与具体任务需求，进行实际的测试与选择。