2026年8月12日ollama 发布 v0.32.9 版本。本次更新围绕 NVIDIA Nemotron 3.5 Lightning、Nemotron 3 系列架构支持、工具调用解析稳定性、Nemotron 3 Nano 与 Nemotron 3.5 Nano 提示词渲染兼容性等方向展开。本次版本共包含 3 次提交、44 个文件变更、2 位贡献者参与累计新增 4,867 行代码、删除 473 行代码。虽然版本更新说明看起来简洁但从代码变更可以看到这次升级重点解决了始终在线智能体在工具调用、流式输出、思维链标签处理以及复杂提示词布局上的多个边界问题。对于需要运行常驻 AI Agent、使用工具调用、依赖流式推理输出的用户而言v0.32.9 是一次值得重点关注的版本更新。一、NVIDIA Nemotron 3.5 Lightning 正式可用v0.32.9 中最受关注的新增模型之一是 NVIDIA Nemotron 3.5 Lightning。该模型是一个开源的 300 亿参数混合专家模型也就是 MoE 模型但每次推理仅激活约 30 亿参数。它的定位并非单纯追求大模型对话能力而是面向始终在线运行的智能体执行层。这意味着它更适合承担 Agent 的长期运行、任务分发、工具调用、流程执行以及持续响应等工作负载。该模型可以通过以下命令直接运行ollama run nemotron-3.5-lightning从更新信息可以看出Nemotron 3.5 Lightning 的设计目标是服务于常驻型 Agent 场景并面向 OpenClaw、Hermes Agent 一类的智能体运行框架。同时它也与 NVIDIA NemoClaw 开源安全与管理栈形成配合用于支持常驻 AI Agent 的安全运行和管理。在本次更新中ollama 不只是加入了一个新模型名称而是同步补足了 Nemotron 3 系列相关的解析器、渲染器与提示词布局支持。这使得模型在实际工具调用、思考输出和上下文拼接时能够与其预期格式保持更高一致性。二、Nemotron 3 架构支持加入模型适配范围进一步扩大更新说明中明确提到新增 Nemotron 3 架构。这项变更意味着 ollama 对 Nemotron 3 系列模型的支持不再局限于原有实现而是进一步覆盖新的模型结构与提示词格式需求。从解析器注册逻辑的调整可以看到Nemotron 3 Nano 与 Nemotron 3.5 Nano 现在将共用同一套解析器casenemotron-3-nano,nemotron-3.5-nano:returnNemotron3NanoParser{}此前解析器仅匹配nemotron-3-nano。在 v0.32.9 中nemotron-3.5-nano也被加入同一分支。这项修改虽然代码量不大但意义非常明确Nemotron 3.5 Nano 已具备内置解析器识别能力Nemotron 3 Nano 与 Nemotron 3.5 Nano 在输出解析层可以复用工具调用、思维链输出、流式文本等结果能够使用同一套兼容处理逻辑内置解析器测试也同步补充了nemotron-3.5-nano对应的测试中内置解析器可用性检查增加了新模型名称确保该模型名称能够正确找到解析实现。三、重点修复Glimmer 工具调用中的边界 Token 异常本次更新中一个非常关键的修复来自 Glimmer 函数调用解析器。问题的背景是在某些工具调用输出中模型可能会把|message|这样的消息边界 Token 错误地插入到工具名称区域。正常情况下ATEM 工具调用格式会包含工具名称例如atem:invoke nameread但模型在生成时可能出现以下异常情况atem:invoke nameread|message|或者更复杂的情况atem:invoke nameread|message|atem:parameter namepath后一种情况尤其危险因为|message|不只是被插入工具名称中甚至替代了原本应该存在的结束标记。这样会导致原有解析逻辑无法正确找到工具名称结束位置进而令整个函数调用解析失败。v0.32.9 针对这一类“边界 Token 被错误放入工具调用名称区域”的情况新增了专门的恢复逻辑。四、新增 glimmerCutInvokeName从异常工具名中恢复调用结构本次变更新增了glimmerCutInvokeName函数。它的职责是从 ATEM invoke 元素中提取工具名称并识别和恢复|message|被错误插入名称区域的情况。该函数重点处理两种已观察到的异常形态。第一种边界 Token 位于已结束的工具名称中。nameread|message|此时解析器会移除|message|并恢复出正确的工具名称read第二种边界 Token 替代了工具名称的结束符。nameread|message|atem:parameter ...这种情况下解析器会识别到|message|出现在工具名称区域随后继续检查其后的文本。如果边界 Token 后面立刻出现参数标签那么解析器会把此前的内容视为完整工具名称并从参数标签处继续解析。也就是说下面这种异常输出read|message|atem:parameter namepathgo.mod/atem:parameter将被恢复为工具名称read 参数名称path 参数值go.mod这一修复对于 Agent 场景非常重要。因为工具调用一旦解析失败模型即使生成了正确意图Agent 也无法真正执行文件读取、搜索、命令运行或其他工具行为。v0.32.9 通过恢复机制提升了模型在输出格式偶发异常时的可用性。五、工具名称中的边界 Token 会被清理但参数值保持原样本次修复并非简单地在全部内容中删除|message|。代码中特别强调函数名称属于标识符因此边界 Token 出现在函数名称区域时不具备合法性可以被清除但参数值中的|message|必须保留。例如下面的工具名称read|message|应恢复为read但如果某个参数值本身就是keep |message| literal那么该值不能被修改。对应测试明确固定了这一行为当|message|出现在参数值中时解析器必须原样保留该文本。这项细节非常重要因为工具参数可能包含普通文本、代码片段、模板内容、特殊标记或模型生成的原始字符串。如果为了修复工具名称异常而无差别删除边界 Token反而可能损坏真实参数内容。因此v0.32.9 的处理策略是工具名称区域发现异常边界 Token恢复并删除参数区域中的边界 Token不做删除保持原始内容工具名称恢复过程记录警告日志参数解析仍从正确位置继续进行这种处理方式兼顾了容错性与数据保真性。六、Glimmer 解析器新增多个边界测试场景为了验证工具调用恢复能力v0.32.9 为 Glimmer 解析器新增了多个测试场景。其中包括工具名称结束符被|message|替换|message|出现在工具名称中间工具名称中连续出现多个|message|参数值中包含字面量|message|例如工具名称中间被插入边界 Tokenre|message|adatem:parameter namepathgo.mod/atem:parameter应恢复为read连续边界 Token 的情况read|message||message|atem:parameter namepathgo.mod/atem:parameter也应恢复为read这些测试说明 v0.32.9 不只是针对单一异常样本进行修补而是对多种相近格式错误进行了覆盖。对于依赖函数调用的模型使用场景来说这类测试能够减少模型偶发格式抖动所带来的工具执行失败。七、Nemotron 3 Nano 流式思考输出修复空白字符丢失问题本次版本还修复了 Nemotron 3 Nano 解析器在流式输出过程中的一个细节问题部分思维内容中的空白字符可能被错误裁剪。在流式响应中解析器需要判断当前缓冲区末尾是否正在形成不完整标签例如think或者/think以及工具调用相关标签。为了避免把不完整标签过早输出解析器会保留可能与标签重叠的尾部内容。但此前实现中会对可立即输出的内容执行右侧空白裁剪。这可能导致一个问题如果文本末尾的空白是实际推理内容的一部分而后续内容并非真正标签而只是看起来像标签的普通文字那么空白可能被丢失。v0.32.9 调整了这部分处理方式。新的逻辑会先计算重叠位置之前的内容再识别其中尾部连续空白的起始位置。这样可以在保留可能是半截标签内容的同时也保留普通推理文本中原本存在的空格。换句话说更新后的逻辑不再简单地裁剪尾部空白而是更精确地区分真正可能构成标签前缀的内容普通文本中的空白后续被证明只是普通文本的“伪标签”内容八、流式输出新增三类伪标签测试Nemotron 3 Nano 解析器新增的测试重点覆盖了流式推理中的“标签假象”问题。第一类是工具调用标签伪装。分块内容可能是reasoning ending with tool_call fakeout /think Done.这里tool_call起初看起来像工具调用标签开头但后续出现的是普通文本fakeout因此它不是有效工具调用标签。更新后的预期是完整保留推理内容reasoning ending with tool_call fakeout第二类是思维结束标签伪装。例如reasoning ending with /think fakeout /think Done.其中/think起初看起来像思维结束标签但后续内容表明它只是普通文本。更新后应完整保留reasoning ending with /think fakeout第三类是以部分思维标签开头的普通文本。例如th oughts are literal /think Done.这里th看起来可能是think的开头但实际构成的是普通文字thoughts are literal更新后该内容会作为思维内容原样保留。这些测试说明v0.32.9 进一步提升了流式解析对不完整标签和普通文本之间边界的判断能力避免因为过度识别标签而损坏模型原始输出。九、Nemotron 3.5 提示词布局支持正式加入本次更新还对Nemotron3NanoRenderer进行了较大调整用于支持 Nemotron 3.5 的提示词布局。渲染器新增了v35标记typeNemotron3NanoRendererstruct{v35bool}该标记用于区分 Nemotron 3 Nano 与 Nemotron 3.5 对提示词格式的不同要求。虽然两者可以共用大量基础逻辑但在系统消息处理、思考开关、工具消息拼接、推理强度参数、工具参数渲染等方面Nemotron 3.5 有自己的布局规则。因此v0.32.9 通过v35分支实现了兼容处理。十、Nemotron 3.5 支持 medium 推理强度在渲染阶段v0.32.9 增加了对medium推理强度的识别。当满足以下条件时使用 Nemotron 3.5 布局请求中明确传入思考参数思考参数为字符串类型参数值为medium渲染器会将其视为中等推理强度模式。对于最后一条用户消息系统会追加如下内容{reasoning effort: efficient}该提示会附加在用户消息内容之后并通过两个换行与原始用户文本分隔。这一逻辑表明Nemotron 3.5 的提示词模板支持通过请求参数表达不同的推理配置其中medium对应的渲染文本为{reasoning effort: efficient}十一、Nemotron 3.5 中思考开关只由请求控制在 Nemotron 3 Nano 的原有处理逻辑中用户或系统消息内的/think、/no_think可能会影响是否开启思考。但 v0.32.9 对 Nemotron 3.5 的行为进行了区分。对于 Nemotron 3.5是否启用思考仅由请求中的思考参数决定用户消息中的/think被视为普通文本用户消息中的/no_think被视为普通文本系统消息中的这类文本也不会作为开关处理对应代码逻辑明确指出在 v35 模式下/think与/no_think只是提示词中的普通字符。这意味着Nemotron 3.5 的思考控制行为更加依赖 API 请求层参数而不是嵌入在文本中的指令标记。十二、系统消息在 Nemotron 3.5 下保持原样v0.32.9 还调整了系统消息的清洗策略。对于非 v35 模式系统消息中的/think、/no_think会被移除同时会使用临时占位符保护真正的/think标签避免处理/think时误伤结束标签。相关逻辑可以概括为先保护 /think 移除 /think 移除 /no_think 恢复 /think而在 Nemotron 3.5 模式下系统消息不再进行这类清洗而是原样传递。这意味着对于 Nemotron 3.5系统消息中的/think保留系统消息中的/no_think保留系统消息中的/think保留系统提示文本不再被额外修改这一调整与“思考开关只由请求参数控制”的规则保持一致。十三、工具消息拼接逻辑更精确避免无意义 user 块在工具消息处理部分v0.32.9 修复了一个边界问题。此前只要遇到工具消息且前一条不是工具消息渲染器就可能创建一个 user 消息块。更新后增加了位置判断ifi0!prevWasTool{sb.WriteString(|im_start|user\n)}这意味着如果工具消息位于消息列表开头就不会额外创建一个没有内容的 user 块。代码注释明确说明前面没有任何消息的工具消息不应打开 user 块。这一修复能让提示词结构更加准确避免在特殊消息序列下出现不必要的空用户消息段。十四、Nemotron 3.5 的思维内容格式存在差异在构建 assistant 内容时v0.32.9 也区分了 Nemotron 3 Nano 与 Nemotron 3.5 的思维文本格式。当消息包含Thinking内容时非 v35 模式的格式为think 思维内容 /think 正文内容其中思维内容与结束标签、正文内容之间带有额外换行。而 v35 模式的格式为think 思维内容/think正文内容这里没有额外插入相同的换行布局。这说明 Nemotron 3.5 对思维内容与普通正文的拼接格式有独立要求v0.32.9 已针对该布局完成适配。十五、工具参数渲染更贴近模板行为本次更新还改进了工具参数值的格式化逻辑。此前参数值的处理方式主要是map 和数组使用 Python 风格 JSON其他值使用通用格式化输出更新后逻辑被统一为templateValue。新的渲染规则是nil渲染为Nonenull渲染为Nonetrue渲染为Truefalse渲染为False对象与数组使用 Python 风格 JSON其他标量使用普通字符串形式这一调整尤其适用于工具定义中的额外参数字段例如$defs以及items此前这两个字段会直接使用 Python 风格 JSON 输出更新后统一改为调用templateValue。这样做的意义是参数值的显示方式更接近模板的实际行为。对于对象、数组、布尔值、空值等不同类型能够获得更符合预期的文本表示。例如true 变为 True false 变为 False null 变为 None而对象和数组仍会以适合模板使用的结构化形式输出。十六、渲染布局细节同步调整除了上述重点逻辑外Nemotron 3 Nano 渲染器还进行了若干提示词结构调整。包括系统消息前后的换行布局调整系统消息结束标记后的空行数量调整消息循环结束后增加额外换行用户与系统消息内容渲染时根据 v35 状态采取不同文本处理策略图像偏移量仍根据消息图像数量持续更新工具响应仍使用tool_response包装工具调用内容仍通过既有工具调用写入逻辑构建这些调整共同服务于 Nemotron 3.5 提示词布局的兼容同时保持 Nemotron 3 Nano 原有处理方式。十七、v0.32.9 更新重点总结ollama v0.32.9 的核心更新可以归纳为以下几个方面。1. 新增 NVIDIA Nemotron 3.5 Lightning支持运行面向常驻 Agent 执行层设计的开源 MoE 模型可通过以下命令启动ollama run nemotron-3.5-lightning2. 新增 Nemotron 3 架构支持进一步完善 Nemotron 3 系列模型的架构、解析与提示词适配能力。3. Nemotron 3.5 Nano 使用内置解析器nemotron-3.5-nano已加入内置解析器识别范围并复用 Nemotron 3 Nano 解析器。4. 修复 Glimmer 工具调用边界 Token 异常当|message|被模型错误插入工具名称甚至替换工具名称结束符时解析器能够恢复工具名称并继续解析参数。5. 保证参数文本不被误改工具名称中的异常边界 Token 会清理但参数值中的|message|保持原样。6. 改进 Nemotron 3 Nano 流式解析处理不完整标签、伪标签和尾部空白字符时更加精确避免普通思维文本被错误裁剪。7. 支持 Nemotron 3.5 提示词布局新增 v35 渲染分支覆盖思维控制、系统消息传递、消息格式、工具消息结构与参数文本格式等差异。8. 支持 medium 推理强度提示在 Nemotron 3.5 布局下medium思考参数会在最后一条用户消息后附加{reasoning effort: efficient}结语代码地址github.com/ollama/ollamaollama v0.32.9 并不是一次只增加模型名称的常规更新而是围绕 Nemotron 3 系列实际运行需求做了较完整的底层适配。一方面NVIDIA Nemotron 3.5 Lightning 的加入为始终在线的 Agent 执行场景带来了新的模型选择。另一方面围绕工具调用、流式推理、边界 Token、提示词布局和参数渲染的修复也让 Nemotron 3 与 Nemotron 3.5 系列模型在真实运行环境中的表现更加稳定。尤其是 Glimmer 函数调用解析器对|message|异常位置的恢复能力以及 Nemotron 3 Nano 流式输出对伪标签和空白字符的保护都是面向真实模型输出波动的重要改进。对于正在使用 ollama 构建本地工具调用、常驻 Agent、流式推理服务或 Nemotron 系列模型工作流的用户来说v0.32.9 的升级内容值得重点关注。