ollama v0.32.4 发布：Laguna 登陆 Apple GPU，Qwen3 MoE 解码修复与 Agent 技能权限全面升级

福大大架构师每日一题

499人浏览 · 2026-07-27 01:00:00

福大大架构师每日一题 · 2026-07-27 01:00:00 发布

在这里插入图片描述

ollama v0.32.4 已正式发布。本次版本围绕 Apple GPU 推理支持、投机解码草稿模型量化、Qwen3 MoE 解码兼容性和性能优化，以及 Agent 技能加载的权限控制展开更新。

从本次变更规模来看，版本共包含 10 次提交、34 个文件变更、3 位贡献者参与，累计新增 2,407 行代码，删除 451 行代码。其中，面向 Apple GPU 的 MLX 引擎能力扩展、不同量化格式专家模型的解码修复、打包 gate/up 投影优化，以及 Agent Skill 权限机制调整，是最值得关注的核心内容。

一、版本核心更新速览

ollama v0.32.4 的官方变更摘要可以归纳为三项重点。

通过 MLX 引擎支持在 Apple GPU 上运行 Laguna。
创建投机解码草稿模型时，按照请求的类型量化草稿模型输出头。
修复 Qwen3 MoE 在不同量化专家配置下的解码问题，并优化打包 gate/up 投影性能，在 M5 Max 上可获得约 4% 到 9% 的提升。

除此之外，提交记录还显示，本次版本包含 Agent 技能权限加载、终端界面中的 Agent 系统提示命令、MLX 已加载模型内存驻留、调度器 loaded map 数据竞争修复，以及更新器和传输单元测试强化等内容。

从功能定位来看，v0.32.4 并不是单一方向的小修复版本，而是同时覆盖了模型推理、模型创建、硬件后端、Agent 运行机制、服务端稳定性与测试可靠性。

二、Laguna 通过 MLX 引擎支持 Apple GPU

本次版本最直观的更新之一，是为 Laguna 增加 MLX 支持，从而使其能够运行在 Apple GPU 上。

更新说明明确指出：

Support Laguna on Apple GPUs via the MLX engine

这项更新意味着，Laguna 的运行支持被接入到 MLX 引擎路径中。此次对应的提交内容为模型层新增 Laguna MLX 支持。

从版本信息能够确认的是，Laguna 与 Apple GPU 的结合依赖 MLX 引擎实现。MLX 是本次改动中的关键运行路径，相关提交还包含一项“保持已加载模型内存驻留”的调整。这两项改动同时出现在本次版本中，说明 MLX 相关能力不仅新增了模型支持，也针对模型加载后的内存状态进行了处理。

需要注意的是，已公布内容仅明确说明支持 Laguna 在 Apple GPU 上通过 MLX 引擎运行，并未给出具体支持范围、模型规格、命令参数、显存或内存占用数据。因此，在本次更新中可以确认的结论是：Laguna 已进入 MLX 支持范围，并可面向 Apple GPU 运行。

对于使用 Apple 平台设备进行本地推理的用户而言，这是一项重要的兼容性扩展。它将 Laguna 纳入 MLX 引擎所覆盖的模型支持范围，使 Apple GPU 路径获得新增模型能力。

三、MLX 改进：保持已加载模型的内存驻留

除 Laguna 的 MLX 支持之外，本次提交列表中还包含一项 MLX 调整：

保持已加载模型的内存驻留。

这一变更与 Apple GPU 及 MLX 引擎相关，但已提供信息中并未展示具体代码差异和实现细节。因此，不能进一步推导其内部缓存策略、释放时机或内存管理机制。

不过，从提交名称可以直接确认：该改动针对的是“已加载模型”的内存驻留状态。它属于 MLX 相关运行时处理的一部分，与新增 Laguna MLX 支持共同构成本次 Apple 平台模型运行能力的更新内容。

在 v0.32.4 中，MLX 相关改动可以归纳为以下两个层面：

模型支持层面：新增 Laguna 的 MLX 支持，使其可以通过 MLX 在 Apple GPU 上运行。
模型运行状态层面：让已加载模型保持内存驻留。

两项更新分别覆盖“能否运行”和“加载后状态处理”两个方向。

四、投机解码草稿模型：输出头按请求类型量化

本次版本对投机解码草稿模型的创建逻辑进行了两项相关调整。

更新摘要中明确提到：

Quantize draft-model output heads at the requested type when creating speculative-decoding drafts.

对应的提交记录包括：

在所请求的量化家族中，将 lm_head 量化为 8 位。
将草稿模型的输出头按照请求类型进行量化。

这里的重点在于：投机解码草稿模型的输出头，也就是 lm_head，不再只是处于与请求类型无关的固定量化处理路径，而是会按照创建时请求的量化类型进行量化。

从提交名称可以确认两个细节。

第一，lm_head 被明确纳入量化处理范围。

第二，草稿模型的输出头会使用请求的类型进行量化。

投机解码通常涉及主模型与草稿模型协作，草稿模型的输出头在生成候选输出时处于关键位置。因此，本次改动针对的不是普通模型转换中的单独量化动作，而是投机解码草稿模型创建过程中的输出头量化一致性问题。

在已给出的变更内容中，“requested family”和“requested type”分别出现在两条相关提交中。可以据此准确描述为：创建草稿模型时，lm_head 与草稿模型输出头的量化会遵循所请求的量化家族或类型。

本次内容没有提供更具体的量化格式名称、支持类型列表、命令行示例或不同类型之间的性能对比。因此，文章不对其增加额外推断。

可以确认的是，v0.32.4 将草稿模型输出头的量化处理与用户请求的量化类型进行了对齐。

五、Qwen3 MoE 解码修复：不同量化专家不再按单一格式处理

本次版本另一项核心更新，是 Qwen3 MoE 解码修复。

官方摘要指出：

Fixed Qwen3 MoE decoding for differently-quantized experts

对应提交表述为：

对每个专家张量使用其自身的量化格式进行解码。

这项改动直接指向 Qwen3 MoE 模型中的专家张量处理逻辑。

MoE 模型包含多个专家模块，而在不同专家采用不同量化格式的情况下，如果解码时不能根据各专家自身的量化格式进行处理，就可能造成解码不正确。v0.32.4 的修复方式非常明确：不再以统一的量化格式处理所有专家，而是让每一个专家张量按照它自己的量化格式进行解码。

从更新文本中可以提炼出以下准确结论：

修复对象是 Qwen3 MoE 解码。
问题场景是不同专家具有不同量化格式。
修复方式是逐个专家张量使用其各自的量化格式解码。

这一调整的重要性在于，它提升了不同量化专家组合下的解码兼容性。对于包含不同量化专家张量的 Qwen3 MoE 模型，解码路径将不再假设所有专家采用相同格式。

本次发布内容没有给出错误现象示例、触发条件、模型文件结构或修复前后的输出对比，因此不能将其扩展为更具体的行为描述。但从提交和发布说明来看，这是一项明确的正确性修复，而不仅是性能优化。

六、Qwen3 MoE 性能优化：打包 gate/up 专家合并为一次启动

除了不同量化专家的解码修复，v0.32.4 还对 Qwen3 相关的专家投影执行路径进行了优化。

官方说明中提到：

faster packed gate/up projection

提交记录中则明确写为：

在一次启动中收集打包的 gate_up 专家。

这项改动的重点是将打包的 gate_up 专家收集操作合并到一次启动中完成。

从名称上看，优化对象是 packed gate_up experts，即打包的 gate_up 专家数据。优化方式不是改变模型结构，而是调整执行调度与数据收集路径，使原本可能需要多次处理的工作在一次启动中完成。

官方给出了这项优化的性能数据：

在 M5 Max 上，性能提升约为 4% 到 9%。

这一数字是本次发布说明中明确提供的性能信息，因此可以直接作为版本亮点进行记录。需要严格注意的是，该提升范围对应的是更快的打包 gate/up 投影，测试平台为 M5 Max。发布内容没有声明它适用于所有模型、所有硬件、所有量化格式或所有推理场景。

因此，更准确的表述应当是：

针对 Qwen3 相关的打包 gate/up 投影路径，v0.32.4 通过一次启动收集打包专家，在 M5 Max 上获得约 4% 至 9% 的速度提升。

结合上一节的不同量化专家解码修复，Qwen3 MoE 在此次版本中同时获得了正确性和性能两个层面的调整。

一方面，专家张量根据自身量化格式进行解码，解决不同量化专家之间的兼容性问题。

另一方面，打包 gate/up 专家的收集被合并到一次启动中，提升相关路径的执行效率。

这也是 v0.32.4 最集中、最具针对性的模型推理优化方向之一。

七、Agent 技能加载机制调整：模型主动加载必须经过审批

本次更新中，Agent 技能系统的权限控制改动较为明显，且给出了比较完整的代码差异与测试内容。

首先，技能工具的说明被调整为：

技能工具是面向模型的核心 Agent 技能目录适配器。
技能工具只提供指令。
普通工具仍然保留它们各自的文件系统或网络访问审批要求。
模型主动加载技能需要审批，因为技能中的指令可能影响本次运行的其余过程。
用户显式激活技能时，由会话中的合成技能调用处理，并绕过这一适配器。

与此前相比，核心变化是：模型主动发起的技能加载被明确要求审批。

代码层面增加了以下行为：

func (t *Skill) RequiresApproval(map[string]any) bool { return true }

这意味着，当模型调用名为 skill 的工具加载技能时，该工具会被标记为需要审批。

这一设计的原因也被代码注释明确说明：技能内容中的指令可能对本次后续运行产生影响。因此，模型主动加载技能不能被视为普通的无审批读取操作，而需要用户或审批流程确认。

从测试内容可以看到，模型主动加载技能的行为分为三种典型情况。

审批被拒绝。
审批被允许。
无交互审批环境下被拒绝。

在审批被拒绝时，测试中的结果包含“Skill loading denied.”，即技能加载被拒绝。

在审批被允许时，模型会继续进行后续调用，技能内容能够被成功加载。

在无交互审批环境下，结果包含“Tool execution requires approval”，即工具执行需要审批。

这些测试清晰地表明，v0.32.4 对模型主动技能加载建立了明确的审批边界：

有审批提示器时，需要取得审批结果。
审批拒绝时，技能不会继续加载。
审批允许时，技能可以继续执行。
没有审批提示器的无交互环境中，因工具需要审批而不能直接执行。

此次变化并不是禁止技能加载，而是将模型主动加载技能纳入审批流程。

八、用户显式激活技能：无需审批，并通过合成技能调用处理

与“模型主动加载技能必须审批”相对应，v0.32.4 对用户显式激活技能保留了不同的行为。

代码注释明确说明：

Explicit user activation is handled by the session’s synthetic skill call and bypasses this adapter.

也就是说，用户显式激活技能并不走模型主动调用 skill 工具的同一路径，而是由会话中的合成技能调用处理，并绕过该工具适配器。

测试中验证了这一点：

用户显式指定技能名称。
即使存在审批提示器，也不会产生审批请求。
会话会生成合成的技能调用。
合成技能调用中能够包含对应技能的指令内容。

测试明确检查了：显式激活技能时，审批请求数量为零。同时，消息列表中会出现工具名称为 skill 的合成调用，并且其内容包含技能指令。

由此可以得到本次版本中非常清晰的权限逻辑划分。

场景	是否需要审批	处理方式
模型主动请求加载技能	需要	通过技能工具适配器执行
用户显式激活技能	不需要	通过会话合成技能调用处理
无审批提示器的模型主动加载	无法直接执行	返回需要审批的结果

这种区分避免将“用户明确要求启用某项技能”和“模型自行决定加载某项技能”混为一谈。

从已给出的代码注释看，模型主动加载需要审批的直接原因，是技能中的指令会影响后续运行过程；而用户显式激活属于用户已经明确表达的操作，因此由会话的合成调用处理，无需再通过模型主动工具调用的审批适配器。

九、技能名称冲突处理：新增保留名称排除能力

Agent 技能目录还新增了 ExcludeNames 方法，用于排除被调用方保留的技能名称。

代码注释说明：

ExcludeNames removes skills whose names are reserved by a caller. It returns the excluded names in sorted order.

该方法的行为可以概括为以下步骤。

如果技能目录为空，则返回空结果。
遍历传入名称。
对名称进行空白去除。
将名称转换为小写。
去除名称开头的 /。
忽略空名称。
将处理后的名称加入保留名称集合。
遍历当前技能目录。
如果技能名称与保留名称匹配，则从目录中删除。
收集被删除的名称。
对被删除名称按字母顺序排序后返回。

也就是说，技能名称排除具备三个明确特征。

第一，名称匹配不区分大小写。

测试中传入的名称包含大写形式，而目录中对应的小写技能仍然能够被识别和排除。

第二，名称前缀中的 / 会被忽略。

测试中以 /system 形式传入保留名称，最终能够排除名为 system 的技能。

第三，排除结果按排序后的顺序返回。

测试验证的返回结果为 exit,system，显示结果进行了排序。

测试还验证了排除后的实际加载行为：

被排除的 system 技能无法继续加载。
被排除的 exit 技能无法继续加载。
未冲突的 release-notes 技能仍然可以正常加载。

这说明 ExcludeNames 并非只返回冲突名单，而是会直接从技能目录中移除对应技能，使后续 Load 操作无法再加载这些被排除的名称。

从功能目的看，这一机制用于处理调用方保留名称与技能名称之间的冲突。方法名称和注释已经明确指出，被排除的是“被调用方保留的技能名称”。

本次给出的测试示例涉及三个技能名称：

release-notes
system
exit

其中，system 与 exit 被视为传入的保留名称而被排除，release-notes 则作为非冲突技能继续保留。

十、技能加载测试强化：审批与显式激活路径得到覆盖

本次改动不仅新增权限逻辑，也同步补充了测试覆盖。

技能工具测试中，原有的“无需审批”测试被调整为“需要审批”。新的测试验证：模型发起技能加载时，ToolRequiresApproval 会返回真值。

同时，测试直接执行技能工具后，仍可确认技能内容被正常返回。测试内容中使用的技能指令包含“Use concise bullets.”，以此验证技能目录和技能工具的加载结果。

更完整的会话测试覆盖了以下链路：

模型请求调用 skill 工具。
调用参数中携带要加载的技能名称。
系统根据工具审批要求发起审批。
审批器可以拒绝或允许。
拒绝时工具结果返回拒绝信息。
允许时会话继续推进。
无审批器时，工具结果返回需要审批的信息。
用户显式指定技能时，不产生审批请求。
显式技能激活通过合成技能调用进入消息序列。

这些测试共同保证了 v0.32.4 中技能权限语义的一致性：模型自主加载与用户显式启用采用不同路径，并具有不同审批行为。

十一、终端界面新增 Agent 系统提示命令

本次提交列表中还包括一项终端界面更新：

在命令行终端界面中增加 Agent 系统提示命令。

提交名称表明，该功能位于 cmd/tui 相关部分，目标是 Agent system prompt command。

已提供信息没有展示该提交的具体代码差异，因此无法确认命令名称、命令格式、具体交互方式、可配置内容或最终显示效果。

可以确认的只有一点：v0.32.4 的终端界面中增加了与 Agent 系统提示相关的命令能力。

这一更新与 Agent 技能权限控制同属 Agent 使用体验与运行控制方向的改动，但两者对应不同层面：

技能权限控制关注模型加载技能时的审批边界。
终端界面系统提示命令关注 TUI 中的 Agent 系统提示操作。

十二、服务端修复：调度器 loaded map 数据竞争问题

提交记录中包含一项服务端修复：

修复调度器 loaded map 的 ps 数据竞争问题。

该更新位于 server 相关部分，标题明确指出问题涉及 ps 数据和 scheduler loaded map 之间的数据竞争。

从已公开的提交说明可以确认：

修复对象在服务端。
问题涉及调度器中的 loaded map。
问题类型是数据竞争。
关联场景涉及 ps 数据。

由于没有提供具体差异代码，不能进一步描述锁机制、并发控制方式、状态读取逻辑或受影响请求路径。

不过，这项修复表明 v0.32.4 在模型推理功能更新之外，也处理了服务端并发访问稳定性问题。

十三、测试稳定性：强化更新器与传输单元测试

本次提交列表还包括：

强化不稳定的更新器与传输单元测试。

提交描述使用了“harden flaky updater and transfer unit tests”，说明改动的目标是提升更新器和传输相关单元测试的可靠性，处理测试不稳定问题。

测试不稳定通常会影响持续集成和版本验证，但本次已提供内容没有展示具体测试文件、失败条件或修复方式。因此，只能基于提交名称确认：

涉及 updater 与 transfer 两类单元测试。
改动目标是强化不稳定测试。

这项更新属于工程质量和测试可靠性方向，与模型支持、推理性能和 Agent 权限功能共同组成了本次版本的完整改动范围。

十四、v0.32.4 的 10 项提交内容汇总

根据发布页面列出的提交记录，v0.32.4 包含以下 10 项更新。

日期	提交内容
7月24日	在请求的量化家族中将 lm_head 量化为 8 位
7月25日	强化更新器与传输单元测试，降低测试不稳定性
7月25日	修复调度器 loaded map 的 ps 数据竞争问题
7月25日	对 Qwen3 MoE 的每个专家张量使用自身量化格式解码
7月25日	在一次启动中收集打包 gate_up 专家
7月25日	增加 Agent 技能权限加载相关能力
7月25日	在终端界面加入 Agent 系统提示命令
7月25日	保持 MLX 已加载模型的内存驻留
7月25日	创建草稿模型时，按请求类型量化输出头
7月25日	新增 Laguna 的 MLX 支持