Ollama v0.40.12 聚焦提示处理速度与小图细节
Ollama 已发布 Ollama v0.40.12 候选版本，包含四项改动，聚焦本地模型性能、图像处理及底层软件依赖。这一区分很重要：其提示处理改进与生成改进来自不同变更，各自也有不同限制。
核心问题在于，支持某个模型与高效运行该模型之间仍有距离。模型或许能够成功加载，却可能以低效方式处理文档，或丢失有用的图像细节。此次发布针对的正是这类差距中的具体案例，而非宣布推出新的模型系列。
这一比较也不止涉及 Ollama 本身。Apple 的机器学习数组框架 MLX，为围绕其底层运算开展开发的研究者提供了更直接的路径。Ollama 的角色是将这些能力整合进模型运行时，即负责执行模型的软件。对于应用开发者而言，这种整合决定了哪些上游改进真正能惠及其工作负载。
Ollama v0.40.12 实际带来了哪些变化
这是一次有针对性的运行时更新，已发布的构建仍为候选版本。
该候选版本的标签为 v0.40.12-rc0，尽管其显示标题为 v0.40.12。GitHub 将其标记为预发布版本，发布日期为 2026 年 10 月 27 日。其比较基线为 v0.40.11。
这一命名差异值得关注，因为仅凭显示标题无法证明稳定版本已经发布。评估升级的读者应区分已发布的候选版本与之后可能出现的稳定构建。关于此构建的结论应保留其完整标签。
列出的变更涵盖紧凑型 Gemma 4 图像处理、MLX 依赖更新、DFlash2 支持以及 llama.cpp 依赖更新。四项条目均署名贡献者 dhiltgen。它们共同描述的是跨多条执行路径的维护，而不是一项普遍适用的加速功能。
因此，此版本对不同群体的意义各不相同。使用受影响图像模型的开发者面临的是正确性问题；等待提示处理完成的开发者面临的是响应速度问题；测试受支持生成加速功能的开发者则面对另一类性能问题。
解读这项公告时，应将这些问题区分开来。更快的文档处理并不自动意味着更快的答案生成。保留图像细节也不代表在所有视觉任务中都有更高准确性。更新依赖项也并未说明对每一种受支持设备的具体收益。
因此，更有价值的分析框架应面向具体工作负载：哪项操作发生了变化、哪个模型会使用它，以及应用程序的哪一部分依赖该操作？相比将每条更新日志都视为本地 AI 普遍提速的证据，这些问题能带来更具可操作性的理解。
对于文档助手，最相关的改进可能发生在答案出现之前。对于截图助手，关键可能在于从输入中保留的信息。对于生成较长回复的应用，生成路径则可能更值得深入考察。
这些是分析性示例，并非已报道的客户部署案例。它们说明，即使使用相同接口，同一版本也可能以不同方式影响各类应用。可见的产品体验可能保持熟悉，但底层执行的工作已经改变。
此次更新也促使应用维护者重新审视旧有假设。先前的比较可能反映的是较早的执行路径，而非模型长期固有的限制。反过来，新的基准测试也不应在未经再次比较的情况下，抹去生产工作负载中的既有证据。
这正是此类维护版本的实际意义。它为重新评估既有行为提供了具体理由，同时并未解决有关模型质量和部署适用性的更广泛问题。
小图像揭示了“能加载”与“能看见”之间的差距
图像相关变更解决的是模型生成答案之前的信息损失问题。
这项紧凑型视觉修复涉及 Gemma 4 的紧凑型视觉塔，即将图像转换为模型输入的组件。根据该拉取请求，动态尺寸调整可能会将最小图像网格向下取整，低于预期的 70-token 预算。
这里的 token 是用于表示图像信息、供模型处理的单位。该变更会将紧凑型视觉塔的网格向上取整，同时将其限制在下一个受支持预算内。维护者表示，显式预算以及较大和统一型视觉塔的现有尺寸调整方式均保持不变。
这是一项范围有限的修正，但具有明确含义。当输入在准备阶段丢失细节时，后续推理无法可靠地恢复缺失的信息。即使模型能力很强，仍取决于运行时实际传递给它的内容。
设想一个应用需要回答有关小尺寸截图的问题，截图中包含一个状态标签。如果准备阶段移除了相关细节，修改提问措辞可能无法解决根本问题。应用需要确保视觉证据能保留足够久，以供模型解释。
这也说明图像处理为何属于性能讨论的一部分。用户评价的是完整任务，包括系统是否正确读取输入。回复即使很快抵达，却遗漏了相关标签，仍会造成额外工作。
不过，这项修复不应被解读为紧凑型模型如今可以准确处理所有小图像。来源指出的是一种尺寸调整行为及有限范围的修正，并未证明其对截图、扫描文档、图表或照片具有普遍效果。
图像尺寸也无法完整描述任务难度。包含醒目符号的小图，与包含密集文字的小图，面临的是不同挑战。评估应反映真实应用希望提取的信息。
最清晰的比较方式是，在不同构建之间保留原始图像和问题不变。在评估过程中以不同方式调整图像尺寸，会为答案变化引入另一种解释。目标是隔离正在考察的运行时行为。
对维护者而言，这改变了调查故障的方式。错误的视觉回答不一定源于模型学习能力本身。输入准备也是一个可能的环节，而该补丁提供了一个具体实例。
它也改变了对早期负面结果的解读。如果受影响的配置丢弃了有用信息，旧测试可能低估了该配置在修正后能够达到的表现。这种可能性值得重新测试，而不是将此前结果改写为无效。
更广泛的启示在于模型比较的边界。模型名称本身并不能描述被评估的完整系统。图像准备、执行软件和应用行为，都会共同决定最终传递给用户的答案。
Ollama MLX 性能提升发生在答案生成之前
提示处理速度变更加快了请求读取过程，而维护者明确表示解码速度保持不变。
这项提示处理更新更新了 MLX 及其 C 语言接口 MLX-C。它采用原生滑动窗口注意力机制，将相关注意力运算限制在模型输入的移动窗口内。
维护者报告了在 Apple M5 Max 上的预填充改进。预填充是处理输入、生成新输出之前的阶段。对于 2,048-token 提示，Gemma、Flint 和 Laguna 的报告吞吐量分别提升 9.2%、14.5% 和 24.1%。
对于 6,144-token 提示，对应的报告增幅分别为 7.5%、14.3% 和 27.0%。这些是维护者针对指定模型配置的测量结果。该拉取请求指出，解码速度，即输出生成速率，保持不变。
这一限定明确了 Ollama MLX 性能主张的范围。等待长文档被读取的用户，与等待长答案生成的用户，面临的是不同瓶颈。前者得到改善，并不能证明后者也得到改善。
当请求包含大量支撑材料、却只要求简短回复时，这一点尤其相关。在这种假设性工作负载中，处理输入可能是体验的重要部分。即使后续输出以相同速率抵达，更快的准备过程仍可能带来实际价值。
反过来的情况则需要不同解读。一个请求很短、但生成输出很长的应用，可能在提示处理上花费相对较少的时间。不能仅凭预填充吞吐量来预测其整体体验。
这些百分比描述的也是吞吐量，而不是等待时间的普遍缩短。端到端延迟，即完成整个请求所需的时间，包含的不只是被测处理阶段。加载、应用开销及其他工作都会使直接换算变得复杂。
这种区分能够避免一种常见的报道错误：将单一组件的改进表述为完整任务等比例的改进。基准测试可以准确描述该组件，同时仍让应用层结果保持开放。
此次发布为开发者提供了更具体的理由，去研究长输入工作负载。但它并不要求开发者在未进行测量前，就得出应用已经变快的结论。这是两种不同的证据标准。
对于组装文档上下文的团队而言，其影响也延伸至评估设计。重复利用已计算结果的缓存输入，应与全新输入区分开来。否则，重复请求可能掩盖此更新所影响的处理工作。
因此，可信的应用比较应说明用户提交了什么，以及系统复用了什么。缺少这种区分时，看似很小的差异可能隐藏着改进；看似很大的差异也可能另有原因。
将 Ollama MLX 性能视为一项精确的工程主张最有价值。受影响阶段、模型配置、硬件和输入长度，为读者提供了可测试的内容。去除这些边界会让主张更宽泛，却也更缺乏信息量。
Ollama DFlash2 支持针对的是另一类瓶颈
DFlash2 涉及答案生成，因此其结果应与提示处理改进分开看待。
这项DFlash2 实现加入了一种推测式生成方法，即由目标模型检查提出的输出。维护者描述了一种候选选择器，它会根据先前选择来决定后续选择。
根据实现说明，一个会话每轮起草七个 token，并通过现有回滚机制进行验证。贡献者表示，验证过程会保留目标输出分布。这是一项实现层面的主张，而非本文呈现的独立验证。
该拉取请求将 DFlash2 与内置多 token 预测头进行比较，后者是一种能够提出多个未来 token 的机制。对于 qwen3.8:27b，在列出的低精度配置下，维护者报告称其在 M5 Max、M5 Pro 和 M2 Ultra 系统上均实现了生成性能提升。
在 M5 Max 上，使用较短的测试提示词时，报告的生成吞吐量从每秒 57.0 个 token 提升至 71.0 个 token。该比较使用的是同一构建版本，而非将上一版本与此候选版本进行测量对比。
最后这一区别很重要。这些结果比较的是同一构建内的生成方法。不应将其表述为所有从上一版本升级的用户都能获得的实测性能提升。
因此，Ollama DFlash2 支持新增了一条评估路径，而非提供笼统的速度承诺。受支持的配置创造了比较行为表现的机会，但并不能告诉每个应用哪种生成方法会带来最佳结果。
推测式生成的基本取舍很直接：当足够多的提案具有价值，足以证明生成和检查它们所付出的工作是合理的，提案才会有所帮助。若只评估提案阶段，就会忽略验证成本。
对于应用开发者而言，完成的输出比内部提出了多少候选 token 更重要。一种激进起草的方法仍需高效地产出被接受的输出。相关结果是在应用实际条件下实现有用的生成。
除速度外，输出行为也值得审视。使用结构化响应的团队应检查应用是否仍能收到预期格式。评估事实性回答的团队，在引入另一条执行路径时应保留现有的正确性检查。
这些是评估重点，并非证明该实现会导致格式或质量问题。来源描述了旨在保持行为一致性的保障措施。独立的应用测试，才是团队判断自身要求是否持续得到满足的方式。
支持与默认行为之间还存在报告层面的区别。发布说明宣布一项功能，本身并不能证明每个已安装模型都会使用它。读者需要确认任何观察结果背后的实际配置。
这一点将该功能与本次发布的其他内容联系起来。运行时改进要通过一连串兼容性和集成决策才能发挥作用。用户看到的是回答，但所选模型和执行方法决定了哪些变化真正作出了贡献。
对于长回答工作负载，生成机制本身值得单独关注。将其报告的收益与无关的提示词处理百分比结合，会产生缺乏依据的估算。每项改进都需要与之匹配的工作负载，才能支撑应用层面的结论。
依赖项更新让比较保持有据可依
较新的依赖项表明底层基础发生了变化，但并不能证明存在普遍适用的性能结果。
llama.cpp 更新 将 Ollama 的依赖项从构建版本 b11845 升级至 b11901。llama.cpp 是一个推理引擎，即执行已训练模型以生成输出的软件。该 pull request 于 10 月 26 日合并。
可见的 pull request 链接了上游比较，但未提供对应的应用基准测试。这足以支持对版本变动的报道，却不足以将某项特定速度或质量改进归因于使用该路径的每一种工作负载。
这一点很重要，因为依赖项更新很容易被过度解读。较新的构建编号描述的是软件谱系，并不能说明某个特定应用中哪些操作发生了变化，也不能证明其原有瓶颈是否发生转移。
与直接使用框架的比较有助于厘清 Ollama 的定位。MLX framework 向开发者直接提供编程接口和机器学习操作。Ollama 则将底层能力整合进模型运行环境。
这两种方式满足的需求有所重叠，但承担的责任层级不同。直接使用框架操作的研究人员可以细致考察实现选择。使用集成运行时的应用团队则依赖运行时提供的受支持执行路径。
没有任何一种方式天然赢得所有比较。直接访问提供控制力，而集成可以减少运行受支持模型所需的工作。公平的评估应当询问：应用团队希望自行承担哪些责任？
该候选版本也说明了为何上游和下游结果应保持区分。框架能力需要恰当集成后，应用才能受益。反过来，集成层改进也不应归功于新模型，若模型本身并未改变。
这一差异会影响竞争性表述。来自某一模型、设备和执行路径的结果，并不能证明 Ollama 在整体上快于其他运行时。它证明的是被测试系统的结果，且包含该系统的边界条件。
现有证据主要来自项目维护者。它支持这些变化的存在及其报告的测量结果，但并未形成关于生产环境采用、可靠性或不同部署方案优劣的独立共识。
没有必要为了让这些证据显得有意义而制造公众争议。尚未解决的问题是实际的：这些变化是否能在维护者测量之外的应用中带来有用收益。即使没有虚构支持者或批评者，这个问题也足够重要。
对于企业采购方，恰当的审查重点应放在证据质量上。对本地 AI 的广泛演示，不如与目标任务相匹配的结果有用。采购决策需要模型、硬件、工作负载和运营要求彼此对齐。
开发者同样能从保留比较背景中受益。记录评估的团队可以使用可搜索的知识库，将发现与配置和示例一同保存。有价值的记录不仅包括最快的一次运行，也包括失败情况和局限性。
三项信号将显示该候选版本的重要程度
下一批有意义的证据依次是发布进展、可复现的耗时数据，以及经过验证的任务行为。
首先，关注已发布候选版本后续如何发展。稳定工件、后续候选版本或修正性发布，都将澄清可供更广泛采用的软件。这些事件不会自动证明应用质量，但会解答部分发布状态问题。
最有参考价值的进展将保留标签与变更之间的清晰关联。这将使开发者能够判断后续结果是关于该候选版本，还是经过修改的构建。缺少这种连续性时，讨论可能会将不同软件的发现混为同一简称版本下的结果。
后续修正并不一定会否定此处描述的工作。其意义取决于受影响的行为。读者应寻找任何报告问题、其影响范围及其所用配置之间的具体关联。
其次，关注能够将输入处理与输出生成区分开的、可复现的应用耗时数据。这将检验所报告的组件改进是否能在原始测量条件之外仍然成立。结果应明确实际模型配置和硬件。
来自匹配工作负载的证据，将加强采用相关变更的理由。若比较显示端到端收益很小，则会缩小这一理由，但不一定与组件基准相矛盾。应用可能只是将时间花在了其他地方。
当耗时报告同时描述全新输入和复用输入时，信息价值会更高。它们还应区分已加载的模型与必须加载模型的请求。这些条件回答的是日常使用中不同的问题。
第三，关注图像处理和加速生成的任务级检查。图像修正需要能够测试保留视觉信息的示例。生成路径除了耗时外还需要输出检查，尤其是在应用依赖可预测结构的场景中。
有价值的报告应包括原始输入、预期行为，以及每个比较配置的结果。这样其他人便可检验相关主张，而非只依赖“某个回答看起来更好”的说法。
对于图像任务，简单示例上的正确回答对困难输入只能提供有限证据。对于生成任务，快速响应对应用兼容性也只能提供有限证据。任何结果的力度都取决于它实际测试了什么。
这些信号应结合阅读，但不应被压缩成单一评分。发布进展关注工件，耗时关注执行，任务检查关注应用是否正确完成有用工作。
未来几个月，最有价值的后续证据将连接这些层面。与特定发布版本和代表性任务绑定的可复现结果，将强化实际应用价值。缺乏依据的泛化只会增加关注度，而无法解决部署问题。
对于评估 Ollama v0.40.12 的读者，请先从你已关心的工作负载开始。在比较构建版本前，保留其输入、模型配置和预期输出。将处理请求所花费的时间与生成回答所花费的时间分别记录。如果图像很重要，请保留原始文件，并检查应用所需的细节。如果加速生成很重要，请在检查速度的同时检查完整响应。将候选版本的完整标签与发现一同保存，以便后续比较仍可解读。随后围绕一个具体结果作出升级决定：变更后的执行路径是否在应用实际面对的条件下，改善了用户实际执行的任务？
