Ollama v0.32.10 重置默认设置，但 Alibaba GitHub 模型几乎未受影响

Ollama v0.32.10 修改了一项沿用多年、数值为 1.1 的生成默认设置，但 Alibaba GitHub 模型的情况有一个重要例外。Qwen3、Qwen3.6 和 Qwen3-Coder 均已发布各自的重复惩罚值。因此，这些模型应能避免此次发布中最显著的行为变化。

这一例外体现了本次更新中更大的张力。Ollama 正在撤回一项覆盖整个运行时的调优选择，将更多生成行为控制权交给模型作者。这一转变使 Ollama 与那些将“不使用重复惩罚”视为中性默认值的推理引擎保持一致。

该版本还加速了 Apple MLX 框架上部分 NVFP4 模型的提示词处理。另一项安全修复则弥补了 OCI manifest 中重复摘要所涉及的 blob 验证漏洞。综合来看，v0.32.10 的影响比其简短的发布说明所暗示的更大。

Ollama v0.32.10 关闭了一项隐藏的生成偏置

核心变化是移除了一项许多模型创建者从未要求过的全局干预。

此前，当模型未声明重复惩罚时，Ollama 会将其设为 1.1。重复惩罚会降低近期已在生成文本中出现过的 token 的概率。它可以抑制循环，但也可能惩罚必要的重复。

0.32.10 版本将后备值改为 1.0，即关闭该惩罚。模型仍可通过其发布的参数定义其他值，调用方也可以通过请求选项提供该值。

默认值与显式模型设置之间的区别至关重要。Ollama 会将请求选项叠加在已发布的模型参数和服务器默认值之上。因此，旧服务器值可能会作用于任何未设置该字段的本地模型。

根据发布说明，新行为与其他推理引擎一致，并可改善推测解码。该版本通过 v0.32.10-rc1 标签发布时，仍被标记为预发布版本。

推测解码会先使用更快的草稿过程提出多个 token，再由目标模型进行验证。被接受的提议可减少昂贵的目标模型步骤数量；被拒绝的提议则会抵消其中一部分优势。

隐藏的惩罚可能导致目标模型不同意那些未经同样调整而生成的草稿。这种分歧并不一定说明草稿质量差，也可能是因为运行时悄然改变了目标分布。

提交分析提供了 Ollama 测试中的具体测量数据。据称，在 Muse Glimmer 30B 上，旧默认值使端到端推测吞吐量降低了 13% 至 16%。

同一测试指出，在温度为 0.8 时，加入该惩罚后的文本接受率从 0.44 降至 0.30。在 Qwen3.6-35B 上，平均接受的草稿长度据称从 4.3 个 token 降至 3.5 个 token。

这些结果来自项目测试，而非独立基准测试。硬件、提示词、温度和草稿策略都可能改变结果。不过，其背后的降速机制在技术上很直观。

旧默认值也会影响常规输出。代码、JSON 和较长的推理轨迹常常需要重复标点、标识符、字段名或结构性 token。即使重复是正确的，对这些 token 施加惩罚也会改变行为。

Ollama 现在将 1.0 视为中性状态。受益于重复控制的模型必须直接声明这一点。这将责任从运行时的历史偏好转移到模型特定的配置上。

这种做法会带来兼容性成本。一些较旧的模型在升级后可能更容易重复，因为此前的惩罚掩盖了其行为。Ollama 建议用户在出现这种情况时设置模型级参数。

这一建议比在全局恢复该设置更精确。修正值可以始终附着于受影响的模型，其他 checkpoint 则不再继承无关干预。

因此，这次发布改变的不只是一个数字。它明确了谁控制采样行为，并让缺少模型建议的情况意味着“关闭”。这一原则也对本地推理运行时提出了更广泛的要求。

Alibaba GitHub 的关联只是例外，不是重点

Alibaba GitHub 模型有助于解释这一变化，但领先的 Qwen 系列并非其主要受益者。

给定关键词指向 Alibaba 在 GitHub 上的开放模型工作。实际上，相关联系体现在 Alibaba 的模型家族 Qwen，以及 Ollama 对 Qwen 生成设置的处理方式；这并不意味着此次 Ollama 发布由 Alibaba 主导。

Ollama 的变更说明称，Qwen3 和 Qwen3.6 已将重复惩罚固定为 1.0。Qwen3-Coder 使用 Qwen 推荐的 1.05。这些已发布的值优先于 Ollama 的新后备值。

运行这些系列的用户不应认为 v0.32.10 会改变其重复行为。只有模型和请求均未指定该参数时，服务器默认值才会生效。显式值会保留原有路径。

这一例外很有价值，因为它展示了本次发布的底层模型：运行时提供中性基线，而模型发布者编码由其 checkpoint 合理化的偏离设置。这种分离让升级更易于理解。

Qwen2.5 则暴露了尚未解决的边缘情况。Ollama 的分析称，该系列推荐使用 1.05，但发布时未包含相应的参数层。因此，它将从旧的 1.1 后备值变为新的 1.0 后备值。

两个值都不符合其声明的推荐设置。0.32.10 移除了过于宽泛的默认值，但不会自动补全缺失的模型元数据。这项工作仍属于模型打包流程。

这种对比也避免了对 Alibaba 和 GitHub 关系的误导性结论。这并不是 Ollama 违背 Alibaba 意愿更改 Qwen 设置的竞争。对于主要的当前 Qwen 系列，Ollama 正在遵循已附加于模型的值。

其他系列受到的影响更直接。Ollama 将 Gemma、Muse Glimmer、Laguna、GPT-OSS、DeepSeek、Nemotron、Granite、Mistral、Llama、Phi、GLM、LLaVA 和 Devstral 列为受影响的本地模型。

具体影响会因 checkpoint 而异。很少回访近期 token 的模型，可能几乎不会出现可见差异。结构化输出、编码和长推理可能有更明显的反应，因为合理重复在这些场景中很常见。

根据项目的比较说明，云端模型不经过这条特定的服务器默认值路径。这一区别对于在同一应用中混用本地和托管模型的用户很重要：相同请求仍可能遇到不同的参数归属。

因此，压力落在运行时维护者和模型打包者身上，而不是某一家模型供应商。运行时需要中性且有文档说明的默认值；发布者需要随模型一起提供完整参数。

应用开发者也需要停止将采样设置视为通用常数。一个能抑制某个 checkpoint 循环的值，可能会降低另一个 checkpoint 的保真度。同一个值还可能干扰推测解码期间的草稿接受率。

团队应在将输出变化归因于新权重之前，检查其 Modelfile 和请求载荷。应用可能已覆盖该参数，已发布的模型配置也可能如此。

这一配置层级解释了为何现在提出广泛的基准结论仍为时过早。两名用户可以安装同一 Ollama 版本，却使用不同的有效设置。他们的结果取决于模型包和请求层。

此次发布让这一层级不再那么令人意外，但并未将其消除。实际问题不再是 Ollama 是否使用 1.0，而是哪个层为特定推理请求提供最终值。

对于 Alibaba GitHub 模型用户而言，这就是可执行的要点：在更改任何设置前，先检查 Qwen 变体及其发布参数。不要仅因旧版 Ollama 曾静默携带该值，就添加重复惩罚。

更快的 NVFP4 预填充省去了一次额外的内存往返

这项 MLX 优化将此前需要分别进行 GPU 处理的两项操作融合在一起。

0.32.10 版本加速了使用全局缩放的 NVFP4 MLX 模型的预填充。预填充是模型开始生成答案前，对提示词 token 进行的初始处理。更快的预填充可缩短输出开始前的等待时间。

NVFP4 是一种四位浮点格式，旨在压缩模型权重，同时保留缩放信息。受影响的 ModelOpt checkpoint 会在按组量化后应用 float32 全局缩放。这一额外缩放在 Ollama 早先的执行路径中带来了可避免的开销。

此前，MLX 会将乘法以及转换回激活数据类型作为两个独立的即时操作执行。这种方式需要额外启动一个 kernel，也会在内存中实体化中间结果。

新路径将乘法和类型转换编译为一个 kernel。融合使中间工作保留在单个操作内，既减少启动开销，也避免为每次投影单独实体化一个 tensor。

Ollama 报告称，在 M5 Max 上，Qwen3.6-27B 的预填充吞吐量中位数从每秒 703 个 token 提升至每秒 769 个 token，据称增长 7.9%。

Muse Glimmer 30B 的预填充速度据称从每秒 790 个 token 提升至 843 个 token。Ollama 将这一改善计算为 6.7%。发布摘要将整体增益四舍五入为约 7% 至 8%。

该项目称，它针对 main 分支进行了交换执行顺序的 A/B 测试。贪婪输出在这些测试中保持字节级一致。这一细节表明，该优化改变了执行效率，并未有意改变数值输出。

这一改进的适用范围较窄。它仅适用于带有全局缩放的 NVFP4 checkpoint。单缩放 NVFP4、MXFP8 和仿射量化 checkpoint 将继续沿用现有路径。

对于这些模型，推测解码在测量噪声范围内也保持不变。这与直接影响草稿接受率的重复惩罚调整不同。预填充优化处理的是解码开始前的工作。

因此，用户应在长提示词场景下看到最明显的收益。简短聊天消息在预填充上花费的总时间较少，因此节省的时间可能并不显著。大型文档和延长的对话历史则提供了更多待处理的提示词 token。

编码助手就是一个清晰示例。它可能在请求下一个 token 前发送代码库指令、多个源文件、工具结果和对话历史。预填充决定模型吸收这些汇总上下文的速度。

本地研究工作流也会产生类似负载。它可以将笔记、提取段落、引用和一个较长的问题组合为一次请求。构建可搜索知识库的团队，应将首个 token 时间与生成速度分开衡量。

这种指标分离可避免一种常见的基准测试错误。预填充吞吐量衡量提示词摄取，而解码吞吐量衡量生成的 token。第一阶段更快，并不保证持续输出更快。

硬件范围同样重要。Ollama 公布的数据使用的是 M5 Max，而 MLX 面向 Apple 平台。不同的内存带宽、散热条件、提示词长度和模型形态，都会改变实际获得的提升幅度。

因此，这项宣称的收益应被视为项目证据，而非普遍承诺。开发者可以固定模型、提示词、上下文长度和生成设置来验证它。交替测试顺序有助于减少热缓存和温度带来的偏差。

即使存在这些限定条件，其机制依然可信且明确。消除一次启动和中间分配，是一种常见的优化模式。它还聚焦于量化本地模型会反复执行的路径。

更大的意义在于本地推理竞争的走向。模型质量依然备受关注，但运行时效率决定了大上下文是否真正易用。微小的内核改进会在大量投影计算和请求中不断累积。

对 Qwen 用户而言，这项优化比默认惩罚参数的变更更相关。兼容的 Qwen3.6 NVFP4 检查点即使其显式重复设置保持不变，也能获得更快的预填充。一项发布可以在保留输出策略的同时改善提示词处理。

这项低调的 OCI 修复填补了持续存在的验证缺口

这项安全修复确保新下载的 blob 不会因重复摘要碰撞而绕过验证。

Ollama 使用 OCI 风格的清单分发模型工件。一个清单可以通过摘要引用配置对象和一个或多个层。摘要通过内容的加密哈希标识内容。

当清单的配置和层共享同一摘要时，漏洞就会出现。Ollama 使用以该摘要为键的映射来记录是否可跳过验证。同一键的两个条目可能会相互覆盖。

已缓存的配置可能将映射值设为 true，表示可以跳过验证。具有相同摘要但刚下载的层则需要验证。配置的缓存命中状态可能覆盖该层的 false 值。

这种碰撞使新的 blob 在未进行预期哈希检查的情况下写入磁盘。验证修复改变了映射合并状态的方式。只要某个摘要的任一次下载不是缓存命中，验证就仍然是必需的。

该实现会在更新跳过决策时使用逻辑 AND。只有每个相关出现位置都满足缓存条件时，某个摘要才有资格跳过验证。一次新的下载就会强制进行验证。

相关 pull request 描述的威胁模型比意外损坏更严重。它指出，恶意 OCI 注册表可以构造含有重复摘要的清单。随后，该注册表可以将 blob 获取请求重定向到内部端点。

这种模式类似服务端请求伪造，通常简称为 SSRF。攻击者诱使服务器请求攻击者无法直接访问的网络位置。内部服务是常见目标。

根据 pull request 的分析，响应可能会作为 blob 写入磁盘。随后，摘要碰撞可能抑制哈希验证。即使文件与声明的内容标识不匹配，它也可能被保留下来。

发布说明使用了更狭窄的措辞，称在共享摘要条件下跳过了 blob 验证。用户不应将这句话视为已知遭到利用的证据。公开材料描述的是一条可信的攻击路径和一个代码缺陷。

所审阅的发布材料没有证据表明该漏洞已在野外被利用。材料也未量化第三方注册表产生此类清单的频率。这些不确定性在评估运营风险时很重要。

谨慎的应对措施依然直接明了。从不受信任或私有运营的注册表拉取模型的用户，应优先更新。运营人员也应在可行情况下限制模型服务基础设施的网络可达范围。

验证和网络控制解决的是不同问题。摘要检查可发现与清单不匹配的内容。出站限制则减少被操纵的获取请求可访问的内部目标。

受信任的注册表并不会让这个代码缺陷变得无关紧要。注册表凭据、重定向行为、镜像、代理或遭入侵的基础设施，都可能扩大实际的信任边界。内容验证本应能够经受这些故障。

该修复也说明，模型分发值得像软件包分发一样受到审视。在每种工作流中，模型都不是一个静态文件。它可能以清单、配置对象、层、模板和运行时元数据的形式到达。

每个阶段都会对身份和缓存形成假设。一个重复键就可能将安全的本地优化变成验证绕过。这一弱点并不要求哈希算法本身失效。

贡献者 vigneshakaviki 通过 pull request 15504 提交了修复，Patrick Devine 被列为共同作者。v0.32.10 的说明将 vigneshakaviki 标识为首次贡献者。这项贡献成为该版本三项重点变更之一。

对企业采用者而言，这项修复的重要性可能超过性能工作。百分比提升影响的是延迟；被跳过的完整性检查影响的是进入推理环境的工件可信度。

团队应在部署日志中记录注册表来源、清单摘要、已解析的 blob 以及 Ollama 版本。这些信息有助于事件复盘和可复现性。它也能将模型行为调查与供应链调查区分开来。

此次更新并未消除所有注册表风险。它修正了验证状态中的一次碰撞。运营人员仍需要访问控制、受信任端点、受限网络，以及为模型工件制定成文的晋级流程。

新默认值以兼容性换取模型保真度

Ollama 更简洁的默认值是合理的，但它可能暴露用户此前从未看到过的重复现象。

关闭惩罚并不保证文本会更好。它只是移除了一项运行时干预。底层模型、提示词、上下文、采样器和已发布参数仍然决定输出。

较旧或较小的检查点在生成变得不稳定时可能重复短语。旧的 1.1 值或许掩盖了其中一部分行为。因此，直接从 v0.32.8 升级的用户即使不修改应用代码，也可能注意到循环输出。

这种结果不一定意味着模型权重发生了变化。它完全可能由新的回退值导致。在提交模型质量 bug 前，对比实际生效的请求选项至关重要。

补救措施应保持模型特定性。用户在确认回归后，可以通过 Modelfile 或请求选项添加重复惩罚。将 1.1 应用于每个模型，会重新制造本次发布试图解决的兼容性问题。

开发者至少应测试三类输出。自然文本能揭示短语循环；代码和 JSON 则能揭示惩罚是否损害了必要的结构性重复。

长推理轨迹值得单独测试。其重复的变量名、标签和中间结构可能以不同方式与惩罚相互作用。单一的短聊天基准无法捕捉这种行为。

推测解码增加了另一层测量需求。团队应记录接受的草稿长度、接受率和端到端吞吐量。原始目标模型的 token 速度无法揭示控制器是否停止了推测。

发布中关于 Muse Glimmer 的数据说明了这一点的重要性。一个看似只是微小文本质量调整的参数，据称带来了两位数的吞吐成本。采样策略因此成为系统性能问题。

不过，来自两款指定模型的基准结果无法对每个检查点下定论。草稿方法各不相同，接受情况取决于草稿与目标分布之间的对齐程度。温度参数同样会改变比较结果。

正确的解读应是有条件的。移除未请求的惩罚，消除了草稿不一致的一个已知来源。实际加速取决于受影响模型是否使用推测解码，以及其草稿路径与目标路径的匹配程度。

MLX 的结果也有类似限制。Qwen3.6-27B 和 Muse Glimmer 30B 在 M5 Max 上显示出更快的预填充。其他芯片和全球规模的检查点需要直接测试。

用户还应区分发布标签。GitHub 将引用的工件发布为 v0.32.10-rc1，并标记为预发布版本。生产团队可能需要稳定版本或内部验证后，才能广泛部署。

安全暴露情况可能改变这一权衡。使用不受信任注册表的团队可能会优先处理验证修复。完全隔离、且使用受信任工件的开发者笔记本电脑则可以接受更缓慢的推进。

这些并非相互矛盾的决定。版本采用结合了行为兼容性、性能和安全态势。不同环境会为这些维度赋予不同权重。

因此，本次发布中的主要对立面并不是 Ollama 对阵 Alibaba、MLX 或另一种运行时。它是运行时范围的历史默认值与模型作者配置之间的对立。0.32.10 选择了后者。

这一选择使本地推理与更广泛的互操作性目标保持一致。当引擎从中性的采样设置开始时，模型的行为会更加一致。显式元数据随后可以记录有意设置的差异。

当软件包缺少推荐值时，一致性仍然不完整。Qwen2.5 展示了这一缺口。中性的服务器默认值无法替代准确的模型打包。

长期考验在于发布者是否会补充完整的生成元数据，以及运行时是否会清晰展示实际生效的配置。缺乏可见性时，用户将继续通过输出变化来诊断不可见的参数层。

Ollama 的更新改善了基线，但可观测性是下一步。请求追踪应让最终的重复惩罚值易于识别。用户不应需要考古式地翻查仓库，才能知道是哪一层提供了它。

开发者在 v0.32.10 之后应关注什么

三个信号将决定本次发布会成为持久修正，还是又一个临时调优周期。

第一个信号是此前继承 1.1 的模型在真实世界中出现的重复报告。报告应注明模型摘要、提示词、实际生效的选项、上下文长度和采样器设置。没有这些细节，比较将始终不可靠。

一批可复现的回归将削弱将 1.0 本身视为充分方案的理由。但这并不意味着应恢复通用惩罚。它会表明受影响的模型软件包需要显式参数。

第二个信号是更多模型和硬件上的推测解码遥测数据。Ollama 报告的 Muse Glimmer 和 Qwen3.6 数据确立了一个机制和两个测试案例。更广泛的结果必须证明，这些收益是否能在不同草稿、提示词和温度设置下保持。

在输出稳定的同时获得更高接受率，将强化本次发布的性能论据。若在已公布设置之外变化很小，则会缩小该主张的适用范围。无论哪种结果，都能帮助团队根据证据选择设置。

第三个信号是在部署和衍生软件包中采用 OCI 验证修复的情况。运营人员应确认其分发渠道中的哪个版本包含补丁。他们还应审查模型注册表是否能够将下载重定向到敏感的内部网络。

若公开披露遭到利用，更新的紧迫性将急剧上升。持续缺乏此类证据并不意味着该缺陷无害。它只会使评估继续聚焦于预防性加固，而非事件响应。

NVFP4 优化值得在同一评估周期内持续观察。应在受支持的 Apple 硬件上，使用较长且固定的提示词测量首个 token 的生成时间。请将解码速度单独统计，避免将预填充阶段的收益误报为全面加速。

Alibaba GitHub 模型用户应尤其关注配置来源。Qwen3、Qwen3.6 和 Qwen3-Coder 已经定义了惩罚参数，因此不必要的覆盖可能会抹去模型作者设定带来的优势。Qwen2.5 则需要更仔细地检查，因为其推荐配置与打包的后备配置可能并不一致。

升级前，请记录一套小型基准测试。应涵盖自然语言文本、结构化输出、代码、长提示词，以及生产环境中使用的任何推测模式。记录模型摘要值及每一项显式选项。

升级后，在比较文本质量之前，先比较实际生效的设置。随后检查预填充延迟、解码吞吐量、草稿接受率和重复生成行为。这个顺序能避免某个默认值的变化被模糊地归因于模型质量问题。

归根结底，Ollama v0.32.10 是一个关于边界的版本。模型发布者负责检查点特定的生成建议；运行时则负责中立执行、高效内核和经过验证的工件处理。

下一步应在你自己的技术栈中检验这些边界。你的模型包是否定义了预期的惩罚参数？日志能否证明实际运行的是哪个值？如果不能，请在下一次升级前记录该配置，并将证据与模型工件一同保留。