Ollama v0.40.15：recurrent 与视觉模型的并发限制解除，小米 MiMo V2.6 入库
Ollama v0.40.15 于 2026-11-03 转正：recurrent 与视觉 GGUF 模型首次支持多请求并行，小米 MiMo V2.6 与 AutoTrust 决策模型入库，launch 支持 Kimi Code CLI。
2026-11-07 · Ollama 官方 Release Notes（GitHub Releases API 逐 tag 一手核对，2026-11-07）
发布 2026-11-07核实 2026-11-07要点速览
v0.40.15（tag 时间戳2026-11-03T22:52:31Z，prerelease: false）已转正为 stable，接替同日 01:40 的v0.40.14，生产请改钉v0.40.15。两个 stable 相隔不到 21 小时，延续 10 月以来「一天一版」的节奏。- 本版头号：官方首次明写「recurrent 与视觉 GGUF 模型可以同时服务多个请求」——"Recurrent and vision GGUF models can now serve more than one request at a time."
- 这句话的反向含义是：此前这两类模型在 Ollama 上被限制在单请求。对搭多用户服务、或多 agent 共用一个 daemon 的部署，这是实质解禁。
- 官方未给槽位数、未给显存换算式，也未说明是否受
OLLAMA_NUM_PARALLEL统一控制；本站未实测各模型族的实际并行数，不作推断。
- 🆕 小米 MiMo V2.6 入库：官方说明为 9B、面向代码与 agent 工作流，
ollama run mimo-v2.6即可拉取。参数量之外的规格（上下文、量化档、许可）本版未列。 - 🆕 AutoTrust 决策模型家族：
autotrust-jev，含 9b / 35b / 27b-vl 三档，35b 与 27b-vl 可读图；用法是给一段文本 + 一个--ask问题，返回选项、是/否概率与评分。本版仅 Apple silicon 支持，官方未标注厂商归属。 - 🆕
ollama launch支持 Kimi Code CLI：官方原文称其为 kimi-cli 的后继（"the successor to kimi-cli"），并主动提供迁移现有 kimi-cli 配置的选项。 ollama launch补两处模型清单：自动填充 Pi 的模型列表，使模型可在 Pi 内选择；Claude Desktop 的模型选择器开始显示 Ollama 的实际模型名（此前显示的是通用名）。- Qwen3 与 Qwen3.5 支持长上下文（YaRN）缩放。
- 无参数运行
ollama进入 welcome launcher（此前进的是帮助文本）。
并发这条为什么值得单独看
Ollama 的并发行为一直是本地部署里最容易误判的一项：同一台机器、同一个 daemon，不同模型族的并行能力从根上不同。
- 常规 dense 模型可以靠
OLLAMA_NUM_PARALLEL与OLLAMA_MAX_LOADED_MODELS调，代价是显存按槽位倍增。 - recurrent（线性注意力 / 混合架构）与视觉模型此前被官方钳在单请求，因此无论怎么调环境变量都上不去。这类模型在本地跑 agent 时最难受——一个 daemon 只能服务一个会话，第二个请求排队等。
v0.40.15 解除的正是这一层限制。 但请把三件事分开看：
| 层面 | 本版给的 | 本版没给的 |
|---|---|---|
| 能力 | 可以多请求并行了 | 一个模型最多几个槽位 |
| 控制 | — | 是否统一受 OLLAMA_NUM_PARALLEL 约束，还是各自有独立上限 |
| 成本 | — | 每增加一个槽位，KV cache 占多少显存 |
结论：这是「从 1 到 N」的解禁，不是「N 等于几」的答案。 上生产前请用你自己的模型与上下文长度压一遍，别按「官方说能并发」就直接把 parallelism 压满——本地 OOM 通常表现为请求超时而非显式报错，很难第一时间归因。
决策模型这条的定位
autotrust-jev 与本站 9 月记录的 TypeSafe AI 的 Jev 决策模型是同一条产品思路：不生成文本，直接输出结构化判断。区别在于：
- **Jev（TypeSafe AI）**走的是 API 与云服务，卖点是延迟（端到端 70–500 毫秒）与按 token 计价。
- AutoTrust 走的是本地 Ollama 权重，卖点变成「判断逻辑不出本机」。
两者是否为同一家、是否有授权关系，官方说明里都没写，本站仅记录「同一类产品形态在本地侧出现」，不推断归属。三档规模里 9b 能跑在消费级机器上，35b 与 27b-vl 的实际显存需求官方未给。
Kimi Code CLI 进 launch 的含义
ollama launch <cli> 这条命令的作用是把本地模型接进某个编码 CLI（此前已支持 claude、codex、OpenCode v2、Pi）。本版把 Kimi Code CLI 纳入，并且带迁移逻辑——说明官方把它当作 kimi-cli 的继任者来对待，而不是并列的另一个工具。
这条与本站 Kimi Code 工具卡记录的产品线（2.5.x 主线）方向一致：本地模型 ↔ 编码 CLI 的适配层正在被 Ollama 官方标准化，而不是每个 CLI 各自写文档教用户配环境变量。
AI 之家 观点
一、「并发从 1 到 N」比「又支持了几个新模型」重要一个量级。 本站记录 Ollama 的版本线已经十几轮，绝大多数版本是「某家族入库」；真正会改变部署形态的条目很少，本版这条算一个。 判断标准很简单：模型入库只影响「能不能跑」，并发上限影响「怎么跑」——后者决定你是一人一 daemon，还是一 daemon 服务一个团队。
二、但「能并发」和「该并发」是两件事。 recurrent 架构省的是长上下文的计算量，不省 KV cache 显存；视觉模型多开一个槽位还要多一份图像编码缓冲。在 24GB 显存的机器上，最可能的结局是第二个请求进来就把第一个挤成超时。 建议做法：先固定上下文长度，从 2 槽位起压，用首 token 延迟与超时率而不是「有没有报错」判断是否过载。
三、MiMo V2.6 选 9B 这个尺寸是有讲究的。 官方把它定位成「代码与 agent 工作流」而不是通用对话——9B 是能在笔记本上常驻、同时还能跑得动工具调用的甜点区。但 本版说明里没有上下文长度，而长上下文恰恰是 coding agent 的刚需；在拿到规格前，不要把它当长仓任务的主力。
四、给使用者的四条动作：① 生产改钉 v0.40.15；② 跑 recurrent 或视觉模型的，重新压一遍并发，并用超时率而非报错率判断；③ 在用 kimi-cli 的，走 ollama launch 的迁移选项前先备份原配置；④ Qwen3 / Qwen3.5 长上下文的，复核 YaRN 缩放开启后显存是否还够。
待核实
- recurrent / 视觉模型的实际并发槽位数，以及是否统一受
OLLAMA_NUM_PARALLEL约束——官方只有一句「can now serve more than one request at a time」，本站未实测。 - AutoTrust 的厂商归属与许可——官方说明未标注；
autotrust-jev与 TypeSafe AI 的 Jev 是否相关不作推断。 - MiMo V2.6 的上下文长度、量化档位与许可——本版说明未列。
ollama launch对 Kimi Code CLI 的迁移范围（是否搬模型配置、是否搬 profile）。- Qwen3 / Qwen3.5 的 YaRN 缩放是默认开启还是需要显式参数——官方只写「已支持」。
v0.40.15是否与v0.40.15-rc0/-rc1共用时间戳——本站上轮记录到正式 tag 曾 404、只有 rc 存续；本轮正式 tag 已存在，但命名 tag 的聚合规整性本次未逐条复核。
来源
常见问题
recurrent 模型并发限制解除，具体指什么？
官方原文是一句话：Recurrent and vision GGUF models can now serve more than one request at a time。此前这两类模型在 Ollama 上被钳在单请求，v0.40.15 起可以并行处理多个请求。但每个模型能开几个槽位取决于显存与上下文长度，官方未给具体档位，本站也未实测。
能直接用 ollama run mimo-v2.6 吗？
官方给了这条命令。MiMo V2.6 是小米 MiMo 的 9B 模型，官方定位为代码与 agent 工作流。参数规模、上下文长度与量化档位本版说明里未列出。
AutoTrust 是哪个厂商的？
官方说明只写 AutoTrust decision models，未标注厂商归属。家族含 9b、35b、27b-vl 三档，35b 与 27b-vl 可读图；本版仅 Apple silicon 支持。本站不对其厂商归属作断言。