ollama v0.32.6 正式发布：Apple GPU 推理加速、流式接口对齐、云端模型调用优化与 TUI 体验修复

2026年8月6日，ollama v0.32.6 正式发布。本次更新聚焦于推理性能、接口兼容性、云端模型调用、终端交互体验以及底层推理引擎更新等多个方面。

从更新内容来看，v0.32.6 并不是一次单纯新增功能的版本，而是围绕现有能力进行优化和修复：在 Apple GPU 场景下，MLX 引擎能够自动使用模型的 MTP head 进行推测解码；/v1/chat/completions流式输出进一步对齐 OpenAI 的 wire format；没有默认标签的云端模型可以通过新的云端标签正常调用；TUI 中多个影响使用体验的问题得到修复。

同时，需要特别注意的是，实验性图像生成功能在 v0.32.6 中被暂时移除。如果仍然需要使用图像生成能力，需要继续使用 v0.32.5。

一、版本信息概览

本次发布版本为：

• 版本号：v0.32.6

• 发布时间：2026年8月6日

• 项目地址：github.com/ollama/ollama

本次更新涉及以下内容：

• Apple GPU 上的模型推理速度优化

• MLX 引擎自动使用模型的 MTP head 进行推测解码

•/v1/chat/completions流式输出格式对齐 OpenAI wire format

• 截断响应的finish_reason返回值调整

• 云端模型标签调用方式优化

• TUI 中表格渲染、文件补全、提示词滚动等问题修复

• 实验性图像生成功能暂时移除

• MLX 与 llama.cpp 引擎更新

从这些内容可以看出，v0.32.6 的重点主要集中在推理链路、接口返回行为、命令行交互细节和引擎维护上。

二、Apple GPU 推理速度提升：MLX 自动使用 MTP head 进行推测解码

本次更新中最值得关注的一项内容，是 Apple GPU 场景下的推理性能优化。

更新说明明确指出：

Qwen3.5 在 Apple GPU 上运行更快，MLX 引擎现在会自动使用模型的 MTP head 进行推测解码。

这意味着，在使用 MLX 引擎并运行 Qwen3.5 时，系统将自动启用模型的 MTP head 来进行 speculative decoding，也就是推测解码。

对于用户而言，这项变化的重要特点是“自动”。

此前，用户在关注模型推理性能时，通常需要留意模型结构、推理引擎能力以及特定优化是否被启用。而在 v0.32.6 中，MLX 引擎会自动利用模型自身提供的 MTP head 能力进行推测解码，不需要用户额外在更新说明中提到的范围内进行手动配置。

这项改动直接对应的是 Apple GPU 上的运行速度表现。也就是说，在满足相关模型和推理引擎条件的情况下，Qwen3.5 在 Apple GPU 环境中的推理速度将得到提升。

这里有几个关键点值得关注：

• 优化对象是 Apple GPU 场景

• 涉及的推理引擎是 MLX

• 更新说明中明确提到的模型是 Qwen3.5

• 优化方式是自动使用模型的 MTP head

• 采用的技术路径是 speculative decoding，即推测解码

• 用户无需额外手动开启这一能力

从版本说明的表述可以看出，这并不是单纯升级模型本身，而是 MLX 引擎针对模型能力进行了更进一步的自动利用。模型拥有 MTP head，而 MLX 引擎在 v0.32.6 中能够自动将其用于推测解码，从而带来更快的推理体验。

对于在 Apple GPU 设备上使用 MLX 引擎运行 Qwen3.5 的用户来说，这是一项直接影响日常生成速度的重要更新。

三、/v1/chat/completions流式输出格式对齐 OpenAI wire format

除了推理性能优化外，v0.32.6 还对接口兼容性进行了调整。

本次更新中，/v1/chat/completions的流式输出行为进一步匹配 OpenAI 的 wire format。

更新说明中提到：

/v1/chat/completions streaming now matches OpenAI’s wire format: role only on the first chunk, finish_reason on its own chunk, and usage in a separate chunk with stream_options.include_usage.

这项变化包含三个非常明确的调整。

3.1 role 仅在第一个流式数据块中返回

在 v0.32.6 中，流式响应中的 role 只会出现在第一个 chunk，也就是第一个数据块中。

换句话说，当通过/v1/chat/completions接口进行流式调用时，响应不再在每一个后续数据块中重复返回 role，而是在第一个 chunk 中给出 role 信息。

这一变化使流式输出的结构与 OpenAI 的 wire format 保持一致。

对于需要处理流式响应的客户端、服务端转发层或接口适配层来说，返回格式的一致性很重要。客户端在解析流式内容时，可以按照更统一的行为处理 role：

• 首个 chunk 用于获取 role

• 后续 chunk 主要用于接收持续生成的内容

• 不需要将 role 视为每个数据块都会重复出现的字段

此次调整的重点在于“role only on the first chunk”，即 role 只出现在首个数据块。

3.2 finish_reason 独立放在自己的 chunk 中

在流式输出结束阶段，finish_reason将放在独立的 chunk 中返回。

更新说明中使用的表述是：

finish_reason on its own chunk

也就是说，finish_reason不再与普通内容数据混合在同一个数据块中，而是拥有单独的流式 chunk。

这意味着流式响应的结束信号在结构上更加清晰。

当模型生成完成后，客户端可以通过专门承载finish_reason的数据块识别生成结束原因。对于需要严格处理流式输出生命周期的调用方来说，这种结构能够让结束状态与内容增量更加明确地区分开。

从接口行为上看，可以将流式数据理解为包含不同职责的数据块：

• 第一个 chunk：包含 role

• 中间的 chunk：承载持续输出的内容

• 专门的结束 chunk：承载finish_reason

• 使用量相关 chunk：在启用对应选项后独立返回 usage

这种划分使每类信息都有更清晰的位置。

3.3 usage 通过stream_options.include_usage独立返回

在 v0.32.6 中，usage 信息也会以单独的 chunk 返回，但这一行为与stream_options.include_usage选项相关。

更新说明明确指出：

usage in a separate chunk with stream_options.include_usage

这意味着，当调用方使用stream_options.include_usage时，usage 将在一个独立的数据块中返回。

因此，在流式调用中，如果需要使用量信息，就需要关注stream_options.include_usage。启用这一选项后，usage 不会与正常内容流混合，而是作为独立 chunk 提供。

此次调整与 role、finish_reason的变更共同构成了更明确的流式返回结构：

返回内容

v0.32.6 中的流式位置

role

仅第一个 chunk

内容增量

持续输出的内容 chunk

finish_reason

独立 chunk

usage

启用stream_options.include_usage后独立 chunk

需要注意的是，这里的重点不是新增一个普通字段，而是流式输出中不同类型信息的组织方式发生了调整，并且整体行为对齐 OpenAI wire format。

对于已经基于/v1/chat/completions实现流式解析的开发者而言，应关注以下变化：

• 不应假定每个 chunk 都会包含 role

• 应单独处理包含finish_reason的结束 chunk

• 如果使用stream_options.include_usage，应准备接收独立的 usage chunk

• 流式解析逻辑需要按照新的 wire format 行为进行适配

四、被截断的 OpenAI 响应将返回finish_reason: "length"

在接口返回行为方面，v0.32.6 还修正了一个与截断响应有关的状态标记问题。

更新说明指出：

Truncated OpenAI responses now report finish_reason: “length” instead of “tool_calls”.

也就是说，当 OpenAI 响应发生截断时，finish_reason现在会返回：

"length"

而不再返回：

"tool_calls"

这是一次语义更加准确的调整。

“截断”对应的是长度限制相关的结束情况，因此 v0.32.6 将截断响应的结束原因调整为"length"。此前该情况会返回"tool_calls"，而现在不再如此。

对于依赖finish_reason判断请求结束状态的调用方，这一变化需要重点关注。

在 v0.32.6 中，可以理解为：

场景

返回的finish_reason

OpenAI 响应被截断

"length"

这项修改尤其关系到调用方对结果完整性的判断。

如果应用需要根据finish_reason执行后续处理，例如判断内容是否因长度原因停止、是否需要继续请求、是否需要提示用户内容未完整返回，那么应将被截断场景识别为"length"。

此次调整也与前文提到的流式输出规范化相呼应。v0.32.6 不仅调整了finish_reason在流中的位置，使其独立放置在自己的 chunk 中，同时也调整了截断场景下的具体值，使其从"tool_calls"变为"length"。

五、云端模型调用优化：ollama run kimi-k3可提供kimi-k3:cloud

本次更新还改善了云端模型的调用体验。

更新说明指出：

ollama run kimi-k3 now offers kimi-k3:cloud for cloud-only models that publish no default tag, instead of failing.

这一变化针对的是没有发布默认标签的 cloud-only 模型。

在此前的情况下，当执行：

ollama run kimi-k3

如果该模型属于 cloud-only 模型，并且没有发布默认 tag，那么该命令可能会失败。

而在 v0.32.6 中，面对这种没有默认标签的 cloud-only 模型，系统会提供：

kimi-k3:cloud

而不是直接失败。

这项改动的核心是：为没有默认标签的云端模型提供可用的云端标签路径。

从更新说明中的信息可以梳理出以下逻辑：

• 用户执行ollama run kimi-k3

• 目标模型为 cloud-only 模型

• 该模型没有发布默认 tag

• 在 v0.32.6 中，不再直接失败

• 系统提供kimi-k3:cloud

这使得云端模型的标签调用行为更加明确。

对于用户而言，最直接的变化是，当模型没有默认标签时，不再只得到失败结果，而是可以使用对应的:cloud标签。

在本次更新中，明确给出的示例是：

kimi-k3:cloud

这一变化避免了 cloud-only 模型因为缺少默认 tag 而无法通过原始模型名直接处理的情况。

需要强调的是，更新说明只明确描述了这一云端标签提供行为，并没有给出更多模型标签规则。因此，在使用时应以kimi-k3:cloud这一明确提供的形式为准。

六、TUI 体验修复：文本渲染、文件补全与提示词滚动均得到改善

v0.32.6 对 TUI 进行了多项修复。

TUI 是终端用户界面，在日常通过终端与模型交互时，文本显示、输入补全和命令滚动等细节都会直接影响使用体验。

本次修复包含三个方面：

• 使用竖线分隔的普通文本不再被错误渲染成表格

• 按下 Enter 键可以接受当前高亮的@文件补全项

•/prompt滚动不再卡顿

下面分别展开说明。

6.1 竖线分隔的普通文本不再被渲染为表格

更新说明中提到：

pipe-delimited prose no longer renders as a table

也就是说，使用竖线分隔的普通文本不再被渲染成表格。

在 Markdown 或终端文本渲染场景中，竖线通常可能与表格语法产生关联。但并不是所有包含竖线的内容都是表格。

当一段普通文本只是使用竖线来分隔内容时，如果被错误识别为表格，就会导致显示形式与原始表达意图不一致。

v0.32.6 修复后，pipe-delimited prose，即使用竖线分隔的普通叙述性文本，将不再被当作表格渲染。

例如，以下类似的内容应当被视为普通文本，而不是表格：

选项A | 选项B | 选项C

此次修复解决的不是表格本身的显示问题，而是避免普通文本被误判为表格。

对于经常在 TUI 中输入或查看带有竖线分隔内容的用户来说，这一修复能够使文本呈现更符合原本的输入形式。

6.2 Enter 键可接受当前高亮的@文件补全项

第二项 TUI 修复与文件补全有关。

更新说明中指出：

Enter accepts the highlighted @ file completion

在 v0.32.6 中，按下 Enter 键可以接受当前被高亮的@文件补全项。

@文件补全是终端交互中的一个重要输入辅助能力。当用户输入与文件相关的内容时，系统可能提供候选补全项。此次修复后，如果某个@文件补全候选项处于高亮状态，用户可以通过 Enter 键确认并接受该候选项。

这一改动带来的核心价值在于交互一致性。

在存在高亮候选项的情况下，Enter 键可以直接用于接受当前选项，减少额外操作，使文件补全的确认过程更顺畅。

本次更新明确说明的是：

• 存在@文件补全

• 某个候选项被高亮

• 按下 Enter

• 当前高亮的文件补全项会被接受

对于依赖终端进行文件引用或文件相关操作的用户来说，这是一项实用的交互修复。

6.3/prompt滚动不再卡顿

第三项 TUI 修复涉及/prompt的滚动性能。

更新说明中写道：

/prompt scrolling is no longer laggy

也就是说，/prompt的滚动不再出现卡顿问题。

滚动卡顿会直接影响查看和编辑体验，尤其是在需要浏览较多提示词内容时，响应不够流畅会影响终端交互效率。

在 v0.32.6 中，这一问题已经被修复。/prompt滚动不再 laggy，也就是不再滞后、不再卡顿。

需要注意的是，更新说明没有进一步给出卡顿原因、修复方式或性能数据。因此，对于此次变更，可以确认的信息是：

•/prompt过去存在滚动卡顿问题

• v0.32.6 已对这一问题进行修复

• 修复后的目标是让滚动不再卡顿

这项改进虽然属于交互细节，但对于经常使用 TUI 进行提示词查看和管理的用户来说，实际感受会比较直接。

七、实验性图像生成功能暂时移除

本次更新中有一项需要特别留意的变化：实验性图像生成功能被暂时移除。

更新说明明确指出：

Experimental image generation has been temporarily removed. Continue using 0.32.5 for image generation support.

这意味着，在 ollama v0.32.6 中，实验性图像生成功能暂时不可用。

这里包含两个关键信息。

第一，移除的是实验性图像生成能力。

第二，如果仍然需要图像生成支持，应继续使用 v0.32.5。

因此，对于依赖图像生成能力的用户，在升级前需要明确评估这一变化。

可以直接总结为：

使用需求

建议版本

需要实验性图像生成支持

继续使用 v0.32.5

使用 v0.32.6

实验性图像生成功能暂时移除

“暂时移除”意味着该功能在当前 v0.32.6 版本中不提供，但更新说明没有给出恢复时间，也没有提供替代方案。因此，不应基于本次说明推测后续恢复计划。

对于已经在使用 v0.32.5 图像生成能力的用户而言，最重要的信息就是：如果图像生成是当前工作流中的必要部分，不应仅因为 v0.32.6 带来了其他优化而忽略该功能已经暂时移除的事实。

本次更新说明给出的明确建议是继续使用 0.32.5 以获得图像生成支持。

八、MLX 与 llama.cpp 引擎已更新

除上述具体功能与修复外，v0.32.6 还更新了 MLX 和 llama.cpp 引擎。

更新说明中的原始内容为：

Updated the MLX and llama.cpp engines.

这表明两个底层推理引擎均已在本版本中完成更新：

• MLX 引擎已更新

• llama.cpp 引擎已更新

其中，MLX 引擎的更新与本次 Apple GPU 上 Qwen3.5 的推理速度提升直接相关。MLX 现在能够自动使用模型的 MTP head 进行推测解码，这是本次版本说明中明确列出的 MLX 侧行为变化。

至于 llama.cpp 引擎，更新说明仅确认其已经更新，但没有提供具体的版本号、更新细节或行为变化。因此，在梳理本次版本内容时，只能确认 llama.cpp 引擎已更新，不应额外推断未在发布说明中出现的内容。

这也说明，v0.32.6 不仅包含用户界面层和接口层的变化，同时也对底层推理引擎进行了维护和更新。

九、v0.32.6 更新重点汇总

为了更清晰地查看本次更新，可以将核心内容汇总如下。

更新方向

具体变化

Apple GPU 推理性能

Qwen3.5 在 Apple GPU 上运行更快

MLX 推理优化

自动使用模型的 MTP head 进行推测解码

流式接口格式

/v1/chat/completions

流式输出匹配 OpenAI wire format

role 返回位置

role 只在第一个 chunk 中返回

结束原因返回位置

finish_reason

在独立 chunk 中返回

usage 返回位置

使用stream_options.include_usage时，usage 在独立 chunk 中返回

截断响应状态

被截断的 OpenAI 响应返回finish_reason: "length"

云端模型调用

ollama run kimi-k3

可提供kimi-k3:cloud，避免无默认 tag 时失败

TUI 文本渲染

竖线分隔的普通文本不再错误渲染为表格

TUI 文件补全

Enter 可以接受高亮的@文件补全项

TUI 提示词滚动

/prompt

滚动不再卡顿

图像生成

实验性图像生成功能暂时移除

图像生成建议

需要图像生成支持时继续使用 v0.32.5

推理引擎

MLX 与 llama.cpp 引擎已更新

十、升级时需要重点关注的事项

结合本次更新内容，升级到 v0.32.6 时，有几个方面需要特别注意。

第一，Apple GPU 与 MLX 用户可以关注推理速度变化。

如果使用 Apple GPU、MLX 引擎以及 Qwen3.5，v0.32.6 中的自动 MTP head 推测解码是本次版本的重要变化。该能力会自动启用，重点是提升相关场景下的运行速度。

第二，流式接口调用方需要适配新的 chunk 行为。

使用/v1/chat/completions流式接口时，需要关注以下规则：

• role 只在第一个 chunk 中出现

•finish_reason在独立 chunk 中出现

• 使用stream_options.include_usage时，usage 在独立 chunk 中出现

如果调用方此前假设 role 会重复出现，或者假设结束原因与普通内容位于同一数据块中，则需要按照新行为进行处理。

第三，截断响应的结束原因值发生变化。

被截断的 OpenAI 响应现在返回：

finish_reason: "length"

而不是：

finish_reason: "tool_calls"

对于基于结束原因执行后续逻辑的程序，应重点检查这一判断条件。

第四，云端模型标签行为有所改善。

对于没有默认 tag 的 cloud-only 模型，ollama run kimi-k3不再直接失败，而是提供kimi-k3:cloud。

第五，依赖图像生成功能的用户不应升级到 v0.32.6。

实验性图像生成功能已经在 v0.32.6 中暂时移除。需要图像生成支持时，应继续使用 v0.32.5。

十一、总结

ollama v0.32.6 于2026年8月6日发布，本次更新围绕性能、接口、云端模型调用、TUI 交互以及底层引擎更新展开。

在性能方面，MLX 引擎能够自动使用模型的 MTP head 进行推测解码，使 Qwen3.5 在 Apple GPU 上运行更快。

在接口方面，/v1/chat/completions的流式输出行为进一步匹配 OpenAI wire format：role 仅在第一个 chunk 中出现，finish_reason使用独立 chunk 返回，启用stream_options.include_usage后 usage 也会使用独立 chunk 返回。同时，被截断的 OpenAI 响应将以"length"作为finish_reason，不再返回"tool_calls"。

在云端模型调用方面，执行ollama run kimi-k3时，针对没有默认 tag 的 cloud-only 模型，可以提供kimi-k3:cloud，避免直接失败。

在终端交互方面，v0.32.6 修复了竖线分隔文本被误渲染为表格的问题，支持通过 Enter 接受高亮的@文件补全项，并解决了/prompt滚动卡顿的问题。

此外，MLX 与 llama.cpp 引擎均已更新。

我们相信人工智能为普通人提供了一种“增强工具”，并致力于分享全方位的AI知识。在这里，您可以找到最新的AI科普文章、工具评测、提升效率的秘籍以及行业洞察。 欢迎关注“福大大架构师每日一题”，发消息可获得面试资料，让AI助力您的未来发展。