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{returntrue}这意味着当模型调用名为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-notessystemexit其中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 支持这 10 项提交与版本摘要形成了完整对应关系。模型与推理方向Laguna 支持通过 MLX 运行于 Apple GPU。草稿模型 lm_head 与输出头按请求量化类型处理。Qwen3 MoE 支持按每个专家自身量化格式解码。打包 gate/up 专家路径获得性能优化。Agent 方向模型主动加载技能需要审批。用户显式激活技能不需要审批走合成技能调用。增加技能保留名称排除能力。终端界面增加 Agent 系统提示命令。运行时、服务端与工程质量方向MLX 已加载模型保持内存驻留。修复调度器 loaded map 的 ps 数据竞争。强化更新器与传输单元测试。十五、版本总结代码地址github.com/ollama/ollamaollama v0.32.4 的更新重点可以概括为“扩展、修复、提速、收紧权限、强化稳定性”。在硬件与模型支持层面Laguna 通过 MLX 引擎获得 Apple GPU 支持同时 MLX 已加载模型的内存驻留行为也得到调整。在投机解码与模型创建层面草稿模型的输出头会按照请求的类型进行量化lm_head 也被纳入请求量化家族中的处理路径。在 Qwen3 MoE 推理层面v0.32.4 解决了不同量化专家张量不能统一处理的问题改为每个专家按自己的量化格式解码与此同时打包 gate/up 专家的收集被优化为一次启动完成并在 M5 Max 上取得约 4% 到 9% 的性能提升。在 Agent 层面本次版本明确建立了模型主动技能加载的审批机制。模型自行请求加载技能时必须经过审批因为技能指令可能影响后续运行而用户明确激活技能时则由会话以合成技能调用方式处理无需重复审批。技能目录还加入了保留名称排除机制可对冲突名称进行规范化匹配、删除和排序返回。此外终端界面增加 Agent 系统提示命令服务端修复调度器 loaded map 相关的数据竞争问题更新器与传输单元测试也获得稳定性强化。整体来看ollama v0.32.4 同时推进了 Apple GPU 模型支持、MoE 推理兼容性、关键路径性能、Agent 安全边界、服务端并发稳定性与测试可靠性。