背景
Ollama 是本地大模型推理的事实标准框架，支持一键拉取运行 Gemma、Kimi、DeepSeek、Qwen 等数十种开源模型。2026 年 4 月 28 日，Ollama 发布 v0.22.1 小版本，核心变化集中在 Gemma 4 的 renderer 改进——specifically targeting thinking（思考链）和 tool calling（工具调用）两大能力的精度与稳定性。这是自 v0.21.x 以来 Gemma 4 相关改动最集中的一次 release，对在本地部署基于 Gemma 4 的 AI Agent 开发者有直接价值。
本文聚焦：这次 renderer 改进具体改了什么地方？对实际推理输出有什么可观测的影响？开发者如何利用新特性？
一、Gemma 4 的 thinking 与 tool calling 挑战
1.1 什么是 thinking mode
Gemma 4 支持 extended thinking，即模型在生成最终回答之前，先输出一段内部推理过程（think block）。这个机制借鉴自 Claude 的思考模式，让模型在复杂推理任务上表现更好。但 thinking 输出是模型自行生成的结构化文本块，需要专门的 parser 来识别和提取。
老版本 renderer 在解析 think block 时存在边界判断问题：当 tool call 嵌套在 thinking 内部时，两者的边界容易混淆，导致 thinking 内容被错误截断或 tool call 参数解析失败。
1.2 Tool calling 的精度问题
Tool calling 是 Agent 系统的核心能力——模型生成结构化调用指令（通常是 JSON 格式），Agent 框架解析后执行对应工具。Gemma 4 的 tool calling 在 v0.21.x 系列中存在两类典型问题：
| 问题类型 | 现象 | 根因 |
|---|---|---|
| think–tool 边界混淆 | thinking 内容输出到一半突然出现 tool call，解析器无法正确归类 | renderer 在嵌套场景下缺少状态机 |
| tool call 参数乱序 | JSON 参数顺序与 schema 定义不一致，框架校验失败 | Gemma 4 输出 token 时序与预期不符 |
| thinking 内容截断 | 长 thinking 链在中间被截断，后续推理丢失 | renderer 对 think_end 标记识别不完整 |
二、v0.22.1 的核心修复解析
2.1 Renderer 状态机重构
本次 commit 最关键的是 Parth Sareen 的两条 PR：
renderers: update gemma4 renderer (#15886)— 更新了 Gemma 4 的 renderer 实现launch: use vram bytes for model recommendations (#15885)— 改用 VRAM 字节数来计算模型推荐，替代旧的启发式估算
先看 renderer 重构。旧版 renderer 对 Gemma 4 的 thinking block 解析依赖简单的正则匹配，无法处理嵌套场景。新版 renderer 引入了显式状态机，在 token 级别追踪当前所处层级（thinking / tool_call / tool_result / output）：
# 新版 renderer 解析逻辑（概念模型）
state = "idle"
think_depth = 0
for token in model.stream():
if token.type == "think_start":
state = "thinking"
think_depth = 1
elif token.type == "think_end" and think_depth == 1:
state = "idle"
think_depth = 0
elif token.type == "tool_call_start":
# 即使在 thinking 内部，也能正确识别 tool call 边界
state = "tool_call"
elif token.type == "tool_call_end":
state = "idle"
# 根据 state 决定如何处理 token
这个状态机的关键改进是：thinking 嵌套内的 tool call 不再被当作 thinking 内容处理，而是被正确路由到 tool call 解析路径。反映在实际输出上，API 返回的 thinking 字段和 tool_calls 字段不再互相污染。
2.2 Tool calling 参数顺序修复
v0.21.3-rc0 中有一个关键 commit api: accept "max" as a think value by @ParthSareen（#15787），解决了 thinking token 值的 API 层面兼容性问题。配合这次 renderer 更新，Gemma 4 的 tool call 参数现在会严格按 schema 顺序输出。
测试方法：使用 ollama run 调用 Gemma 4 并启用 tool calling：
# 启动 Ollama server
ollama serve
# 测试 tool call 输出（启用 verbose）
ollama run gemma4:latest \
"List the files in /tmp and tell me which ones are larger than 100 bytes" \
--verbose
# 观察 tool_calls JSON 是否按 schema 顺序输出参数
旧版 Gemma 4 在这种多步 Agent 场景下，tool call 参数顺序随机导致 JSON schema 校验失败。新版 renderer 保证了输出顺序确定性。
2.3 Model Recommendations VRAM 计算改进
这是 launch 层面的改进，commit launch: use vram bytes for model recommendations (#15885)。旧版 Ollama launch 界面推荐模型时，使用的估算逻辑是基于模型文件大小的启发式方法，不够精确。
新逻辑直接查询系统可用 VRAM 字节数，再根据各模型实际运行时显存占用推荐，避免了在显存受限机器上推荐了跑不动的模型：
# 查看可用 VRAM
# Linux
nvidia-smi --query-gpu=memory.free --format=csv,noheader
# macOS Metal
# 通过 Ollama API
curl http://localhost:11434/api/ps
# launch 界面现在会根据实际 VRAM 推荐合适的模型
# 而不是仅凭参数量（如 7B / 13B / 70B）估算
三、实测验证：thinking + tool calling 协同效果
3.1 测试场景设计
设计一个需要 thinking + tool calling 协同的复合任务：让 Gemma 4 先思考分解步骤，再调用工具执行，最后汇总。
import ollama
response = ollama.chat(
model='gemma4:latest',
messages=[{
'role': 'user',
'content': (
"I have three files: /tmp/a.txt (50 bytes), /tmp/b.txt (150 bytes), "
"and /tmp/c.txt (80 bytes). First think about which ones are > 100 bytes, "
"then list the results."
)
}],
tools=[{
'type': 'function',
'function': {
'name': 'filter_files',
'description': 'Returns the input list filtered to items larger than threshold',
'parameters': {
'type': 'object',
'properties': {
'files': {
'type': 'array',
'items': {
'type': 'object',
'properties': {
'name': {'type': 'string'},
'size': {'type': 'integer'}
}
}
},
'threshold': {'type': 'integer'}
},
'required': ['files', 'threshold']
}
}
}],
options={
'num_predict': 1024,
'think': True # 启用 thinking
}
)
print("Thinking:", response.message.thinking)
print("Tool calls:", response.message.tool_calls)
print("Output:", response.message.content)
3.2 预期改进效果
在新版 renderer 下，这个场景的预期改善：
| 指标 | v0.21.x（问题状态） | v0.22.1（修复后） |
|---|---|---|
| thinking 内容完整性 | 长链常在中途被截断 | 完整输出直到 think_end |
| tool call 参数顺序 | 随机，与 schema 要求不符 | 严格按 schema 顺序 |
| thinking 内嵌 tool call | 解析器混淆，无法正确路由 | 状态机正确识别嵌套 |
| 模型推荐准确性 | 启发式估算，不考虑实际 VRAM | 基于 vram bytes 计算 |
3.3 升级步骤
# 升级 Ollama 到 v0.22.1
ollama upgrade
# 验证版本
ollama --version
# Expected: 0.22.1
# 重新拉取/更新 Gemma 4（确保使用新版模型文件）
ollama pull gemma4:latest
# 重启 Ollama 服务
sudo systemctl restart ollama
# 或 macOS:
# brew services restart ollama
四、v0.22.1 其他值得关注的变更
4.1 新模型加入：Nemotron 3 Omni 与 Laguna XS.2
v0.22.0 还同步引入了两个新模型：
- NVIDIA Nemotron 3 Omni — NVIDIA 自家的大模型，通过 Ollama 直接调用
- Poolside Laguna XS.2 — 首个开源权重的编程专用模型，面向代码生成优化
Laguna XS.2 的出现意味着 Ollama 生态中又多了一个强力编程模型选择，结合 Gemma 4 的 tool calling 能力，可以在本地构建完整的 AI coding agent。
4.2 Kimi CLI 深度集成
v0.21.1 引入的 Kimi CLI 现已稳定。通过 Ollama launch 可以直接启动 Kimi CLI 并连接到云端 Kimi K2.6 模型：
ollama launch kimi --model kimi-k2.6:cloud
Kimi K2.6 在长程 Agent 任务上表现突出，适合复杂的多步骤推理场景。
总结
Ollama v0.22.1 是一次目标明确的补丁版本，核心价值在于修复了 Gemma 4 的 thinking + tool calling 串联场景下的 renderer 解析问题。对已经在使用（或计划使用）Gemma 4 构建本地 AI Agent 的开发者，这次升级直接提升了 tool call 的可用性和输出稳定性。
配合 VRAM 感知模型推荐、Kimi CLI 集成以及后续 Laguna XS.2 编程模型的支持，Ollama 正在从「本地模型运行工具」向「本地 Agent 开发平台」演进。如果你关注开源 LLM 的本地部署和 Agent 化，Ollama 仍然是最值得跟踪的项目之一。
建议行动：如果你的环境跑的是 Ollama v0.21.x 且使用 Gemma 4，优先升级到 v0.22.1；如果从零开始，推荐从 ollama run gemma4:latest 搭配新 renderer 体验 thinking + tool calling 的完整协同。
评论区