Ollama 发布了一个候选版本,加快了 Apple 芯片上的模型回答生成和长输入处理,并能保留部分小图像的更多细节。自行运行模型的开发者可以根据任务耗时主要在读取输入还是生成回答,评估改进效果。

1. 先生成草稿,加速回答生成

10月27日发布的 0.40.12-rc0 加入了 DFlash2 支持。该方式先生成多个词元的草稿,再由模型验证,以加速回答生成。

此次支持加入了 MLX 执行路径,MLX 是 Apple 芯片上模型运算的基础。每轮生成 7 个词元的草稿,并通过现有的状态恢复路径进行验证。

该拉取请求的作者使用 qwen3.8:27b 模型的 NVFP4 格式测量了性能,这是一种以 4 位浮点数表示数值的格式。两种方式在相同构建和会话中运行。

作为对照的 MTP 是模型内置的预测功能。下表展示了 M5 Max 上 16 次 2K 输入请求的中位数,分别列出作者公布的输入吞吐量和生成吞吐量。

表:M5 Max 上不同草稿生成方式的吞吐量

条件:M5 Max、qwen3.8:27b (NVFP4)、2K 输入、16 次请求的中位数、temperature 1、top_p 0.95、top_k 20、thinking on、相同构建与会话

单位:词元/秒

先生成草稿,加速回答生成
方式输入吞吐量生成吞吐量
内置 MTP76757.0
DFlash279071.0

在这些条件下,生成吞吐量的变化比输入吞吐量更明显。同一模型和设备在 32K 输入测量中的生成吞吐量也从 54.0 提高到了 63.2。该结果是其余设置相同、请求数为 12 次的测量中位数。

2. 改善读取长输入的阶段

更新 MLX 及其连接层的变更针对模型先读取输入的预填充阶段。通过利用指定一次处理的输入范围的运算功能,提高了 Gemma 4、Flint 和 Laguna 系列模型的吞吐量。

拉取请求作者公布的 Apple M5 Max 测量中,Laguna 模型在 2048 词元输入下的吞吐量变化如下。提升幅度也采用原文给出的数值。

表:Laguna 模型在 2048 词元输入下的吞吐量变化

条件:Apple M5 Max、laguna-xs.2:nvfp4、2048 词元输入、MLX 与 MLX-C 更新前后的预填充吞吐量

改善读取长输入的阶段
项目更新前更新后提升幅度(%)
吞吐量(词元/秒)4668579524.1

同一设备和模型在 6144 词元输入下,吞吐量从每秒 4289 词元增至 5448 词元,作者给出的提升幅度为 27.0%。这对读取输入耗时较长的任务具有参考价值,而该变更的测量中,生成回答的解码速度保持不变。

3. 保留小图像细节,但增加词元用量

Gemma 4 中用于处理图像的小型组件——紧凑型视觉塔也进行了修正。自动调整图像尺寸时,若将最小网格向下取整,分配的词元可能少于预期的 70 词元预算,导致小图像细节丢失。

此次变更将该网格向上取整,但不超过下一个受支持的预算档位。将图像划分为供模型读取的小格子时,略微增加格子数量,以减少细节丢失。

保留细节的收益伴随着图像输入词元用量可能增加的代价。明确指定预算的输入、更大的视觉塔以及统一塔仍沿用现有的尺寸调整方式。

4. 用测试模型确认生成路径

DFlash2 拉取请求的作者以自己的名字发布了测试模型。原文给出的下载命令如下。

ollama pull dhiltgen/qwen3.8:27b-dflash2-nvfp4

此次 Ollama 候选版本分别改进了回答生成、长输入读取和小图像细节保留,值得根据任务瓶颈评估其效果。