ollama/ollama v0.40.17-rc0：集成显卡加载，MLX 并发生成

1. 分别应对加载失败与生成等待

2026年11月10日发布的 v0.40.17-rc0 分别调整了模型加载阶段和请求处理阶段的瓶颈，即拖慢处理的关键环节。这些改动针对共享内存显卡的加载问题，以及多个请求重叠时的等待时间。

集成显卡方面，改动减少了模型数据重复占用同一内存预算，即设备可用内存额度的问题。MLX 方面，不再让后续请求一直等到前一个请求结束，而是让多个请求共享计算资源。

2. Vulkan 集成显卡通过内存映射读取

原有加载方式将留在 CPU 端的模型数据放入 Vulkan 的主机缓冲区。Ollama 的变更提案解释，这个空间与权重，即模型学到的数值信息，共用同一设备内存预算，因此集成显卡的内存占用可能约为两倍，并导致加载失败。报告的症状包括内存固定分配失败和 Windows AMD 环境中的错误。

Ollama 现在会在检测到 Vulkan 集成显卡时自动选择 mmap，以内存映射方式读取。直接 I/O，即不经过操作系统缓存的读取方式，也无法避开主机缓冲区，因此此次改变了加载路径本身。适用对象是与 CPU 共享内存的集成显卡。

以下是修改后函数的部分原文。

// appendLoadModeArgs selects llama-server's single model loading mode. Integrated
// GPUs share memory with the CPU: Linux CUDA/ROCm use direct I/O to skip the page
// cache, while Vulkan uses mmap because non-mmap loads place CPU-resident tensors
// in a host buffer drawn from the same device budget as the weights.
func appendLoadModeArgs(params []string, opts api.Options, gpus []ml.DeviceInfo) []string {
	for _, g := range gpus {
		if !g.Integrated {
			continue
		}
		if strings.EqualFold(g.Library, "Vulkan") {

3. MLX 同时处理多个生成请求

MLX 模型可通过 OLLAMA_NUM_PARALLEL 设置同时处理的生成请求数。默认处理一个请求，提高该值后，每个活跃请求都需要额外内存。设为 2 时，如果两个请求同时到达，原本需要排队的请求也能更早开始接收 token。

多个请求会将可共同计算的部分合并处理，但各自的缓存，即临时存放可复用数据的空间，以及响应流仍保持独立。系统不再处理完一个请求的全部输入才转向下一个，而是将提示词，即输入模型的指令和上下文，按每段 2048 个 token 拆分，与响应生成交替处理。用户配置示例如下。

OLLAMA_NUM_PARALLEL=2

据公司公布的性能测量，测试在 Apple M5 Max 上运行采用 NVFP4 量化，即通过缩减模型数值来节省内存的转换模型，数值为以秒计的中位数。两个客户端同时提交请求，基线采用顺序处理，修改版交错处理请求。下表列出等待请求开始接收响应的时间，以及两个请求全部完成的时间。

表：并发请求的响应开始与全部完成时间

条件：NVFP4，p4096/g256，Apple M5 Max；OLLAMA_NUM_PARALLEL=2；两个客户端同时提交；基线为 main 的顺序处理，修改版为交错处理

单位：秒（中位数）

在这些条件下，三个模型中等待请求的响应开始时间均有所提前。两个请求的全部完成时间在 Gemma 和 Qwen 上增加，Nemotron 则相近。变更提案称，单个请求的性能接近基线。

4. 响应等待与处理成本的权衡

并发处理让等待中的请求更早获得响应，代价是共享原本由第一个请求使用的显卡计算资源。通过预先猜测生成内容来提速的技术，在多个请求运行期间也会暂停。运营者获得的是更短的等待时间，付出的是每个请求更多的内存，以及部分模型更长的全部完成时间。

各请求独立保留的缓存，即使在请求空闲时也仍占用内存，而且输入的公共前缀会被重复存储。开发团队计划后续改进，让缓存共享保留预算、回收空闲内存并复用公共输入。

此次发布为预览版，测量结果仅对应表中列出的模型、配置和硬件条件。

v0.40.17-rc0 减轻了共享内存环境下的加载负担，并让 MLX 的等待请求能够更早获得响应，但采用并发生成时，仍需一并权衡内存和全部完成时间的成本。