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 现在将共用同一套解析器：
case "nemotron-3-nano", "nemotron-3.5-nano":
return &Nemotron3NanoParser{}
此前，解析器仅匹配 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 name="read">
但模型在生成时可能出现以下异常情况：
<atem:invoke name="read<|message|>">
或者更复杂的情况：
<atem:invoke name="read<|message|><atem:parameter name="path">
后一种情况尤其危险，因为 <|message|> 不只是被插入工具名称中，甚至替代了原本应该存在的 "> 结束标记。这样会导致原有解析逻辑无法正确找到工具名称结束位置，进而令整个函数调用解析失败。
v0.32.9 针对这一类“边界 Token 被错误放入工具调用名称区域”的情况，新增了专门的恢复逻辑。
四、新增 glimmerCutInvokeName：从异常工具名中恢复调用结构
本次变更新增了 glimmerCutInvokeName 函数。
它的职责是从 ATEM invoke 元素中提取工具名称，并识别和恢复 <|message|> 被错误插入名称区域的情况。
该函数重点处理两种已观察到的异常形态。
第一种：边界 Token 位于已结束的工具名称中。
name="read<|message|>">
此时解析器会移除 <|message|>，并恢复出正确的工具名称：
read
第二种：边界 Token 替代了工具名称的结束符。
name="read<|message|><atem:parameter …>
这种情况下，解析器会识别到 <|message|> 出现在工具名称区域，随后继续检查其后的文本。如果边界 Token 后面立刻出现参数标签，那么解析器会把此前的内容视为完整工具名称，并从参数标签处继续解析。
也就是说，下面这种异常输出：
read<|message|><atem:parameter name="path">go.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|>
例如，工具名称中间被插入边界 Token：
re<|message|>ad"><atem:parameter name="path">go.mod</atem:parameter>
应恢复为：
read
连续边界 Token 的情况：
read<|message|><|message|>"><atem:parameter name="path">go.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 标记：
type Nemotron3NanoRenderer struct {
v35 bool
}
该标记用于区分 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 消息块。
更新后增加了位置判断：
if i > 0 && !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 渲染为 None
- null 渲染为 None
- true 渲染为 True
- false 渲染为 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-lightning
2. 新增 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/ollama
ollama 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 的升级内容值得重点关注。
