Ollama

TL;DR

2026-10-17 更新（官方仓库 Releases 逐 tag 核对，一手）：当前 stable 已推进到 v0.40.5（2026-10-14 19:45 UTC 发布），接替 10-11 的 v0.40.3（v0.40.4 于 2026-10-12 19:00 UTC 也曾是 stable）。v0.40.6-rc0（2026-10-16 22:00 UTC）为候选版，生产请钉 v0.40.5。四个版本落在六天内——Ollama 近期的发版节奏明显加快，钉版本时务必写死具体号，不要用浮动范围。 本站未取得 v0.40.4 / v0.40.5 / v0.40.6-rc0 的官方 Release Notes 正文（Releases API 只返回 tag 与时间戳），不对本版改动内容作断言，列入待核实。 又是一个「版本号顺序会骗人」的例子：v0.35.1 的发布时间（2026-09-29 20:14 UTC）晚于 v0.40.0（2026-09-25 03:31 UTC）。旧线维护版本与新主线并行发布是 Ollama 的常态，核对时务必看发布时间戳，不要按数字大小判断新旧。 本卡正文提到「0.19+ 起 Mac M 系列切 MLX」——该结论在 0.40.x 上依然成立（MLX 是 0.19 引入的能力，后续版本沿用），但具体版本号已大幅前进，请以官方 Release Notes 为准。

2026-10-18 更新（官方仓库 Releases 逐 tag 核对 + Release Notes 原文，一手）：v0.40.6 已转正为 stable（2026-10-16 22:00 UTC），接替 10-14 的 v0.40.5。 上一版正文写的「v0.40.6-rc0 为候选版、生产请钉 v0.40.5」已被证伪——本站 10-17 核对时只取了 Releases 列表的 tag 名而未逐条读取 prerelease 标记，v0.40.6 的 prerelease 实为 false。判据修正：判断 stable 不能看 tag 名里有没有 -rc 后缀，必须读 Releases API 的 prerelease 字段（本站此前在 Codex / Gemini CLI 上已用同一判据，此处漏用）。 本版改动（官方 Release Notes 原文，一手）：

改动	说明（官方原句转述）
Windows 防孤儿 runner	win: prevent orphaned runners（PR #18500）——Windows 侧退出后残留 runner 进程的处置
GGUF 新增 q2_0	gguf: add the q2_0 tensor and file types（PR #18967）——新增一种 2-bit 量化张量 / 文件类型
clef 在 Ollama 云端启动	Launch clef in Ollama's cloud（PR #19036）
--ask 模式改用标识符	use identifiers for --ask mode question keys（PR #19041）
官方 Release Notes 只给出 PR 标题，未给出改动细节与影响面，本站未逐 PR 阅读，不作超出标题的断言；clef 在本语境下的具体所指官方未说明，列入待核实。
对使用者的实际含义：① 生产请钉 v0.40.6（不再建议钉 v0.40.5）；② q2_0 是新的量化档位，跑到 2-bit 量化的场景此前没有原生张量类型，现在有了——但质量代价官方未给数据，不要因为「多了个更低比特」就默认可用。

2026-10-19 复核（官方仓库 Releases API 逐 tag 核对，一手）：stable 仍为 v0.40.6，未见新 stable；上游已出现 v0.40.7-rc0（2026-10-18 00:28 UTC，经 Releases API 确认 prerelease = true），属候选版，生产请继续钉 v0.40.6。沿用本站 10-18 修正后的判据：该结论来自 prerelease 字段，不是看 tag 名里的 -rc 后缀。另注：six days 内出了 0.40.3 / 0.40.4 / 0.40.5 / 0.40.6 四个 stable，发版节奏明显加快，钉版本时务必写死具体号，不要用浮动范围。本站未取得 v0.40.7-rc0 的 Release Notes 正文（Releases API 仅返回 tag 与时间戳），不对该版改动内容作任何断言，列入待核实。

2026-10-25 更新（官方仓库 Releases API 逐 tag 核对 + Release Notes 原文，一手）： 上一条「stable 仍为 v0.40.6」已被连续五个版本追上——v0.40.7 / v0.40.8 / v0.40.9 / v0.40.10 / v0.40.11 已全部转正为 stable，当前生产请钉 v0.40.11。

版本	发布时间（UTC）	主角
v0.40.11	2026-10-24 00:30	语音合成走 OpenAI 兼容 /v1/audio/speech；d3 决策模型家族 2B/4B/9B/27B
v0.40.10	2026-10-23 15:03	NVIDIA Nemotron 3.5 Bolt E4B（Gemma 4 VLM，128K，DFlash draft）
v0.40.9	2026-10-22 01:33	Phonon 语音合成（Apple Silicon）；d3 决策模型首发；Flint 扩展到 Linux / Windows
v0.40.8	2026-10-21 16:20	Recursive 的 Flint 编码模型（Apache 2.0、40B MoE / 每 token 约 2.5B 激活、262K，首发仅 macOS）
v0.40.7	2026-10-18 00:28	上一版 stable

三条判据层面的提醒：① 「先发 rc、转正后沿用原时间戳」已连续三轮踩到（v0.40.7 / v0.40.8 / v0.40.11 均有同名 -rc0 tag 与之共用时间戳）→ 按版本号聚合所有同名 tag 后再读 prerelease 字段；② 自 2026-10-12 起，0.40.3 ~ 0.40.11 共九个 stable 落在十二天内——钉版本务必写死具体号，不要用 ^0.40 这类浮动范围；③ v0.40.11 起 /v1/audio/speech 与 OpenAI 兼容，已接 OpenAI TTS 的应用理论上只改 base URL 即可切到本地，但字段级对齐情况官方未给，先小流量验证。

平台与规格限定：语音合成官方写的是 on macOS；Flint 的量化档位与最低硬件要求、Nemotron Bolt E4B 的参数量与许可、d3 各档的准确率与推荐硬件官方均未给，本站不推断。详见 v0.40.11 资讯 与 v0.40.8 / v0.40.9 资讯。

2026-10-29 更新（v0.40.12 转正，官方仓库 Releases API 逐 tag 一手核对 + Release Notes 原文，一手）：Liquid AI 的 LFM3 系列上桌，但本版只支持 Apple 硬件。

版本	发布时间（UTC）	主角
v0.40.12	2026-10-27 00:07	Liquid AI LFM3 家族；d1 决策模型 2B 档；Apple Silicon 提速；ollama launch 支持 OpenCode v2
v0.40.11	2026-10-24 00:30	上一版 stable（/v1/audio/speech）

LFM3 家族四个成员（官方原文 "Liquid AI's new family of small models built for local agents, tool calling, and structured output"）：

模型	定位	规格
lfm3	文本	1.7B，256K 上下文
lfm3-vl	文本 + 图像理解	在 lfm3 基础上加视觉
lfm3-audio	语音识别 / 翻译 / 合成	18 种语言
lfm3-omni	文本 + 图像 + 音频一体	全模态

d1 决策模型新增 2B 档（基于 LFM3）：d1 处理文本与图像的决策任务，d1-omni 再加音频。官方给的用法是 ollama run d1:2b "I was charged twice for order 4417." --ask "Is this a billing issue?"。

平台限制是本版最需要记住的一条：官方原文 "lfm3 and d1 2b are supported on Apple hardware in this release. Support for Linux/Windows coming soon." ——Linux / Windows 用户现在装了也用不了，别按「模型已上架」去写部署文档。

其余变化：Apple silicon 上 Gemma 4 / Flint / Laguna 的 prompt 处理提速；MLX 上的投机解码支持 DFlash2 草稿模型；Gemma 4 小尺寸图像保留更多细节；ollama launch 现在可与 OpenCode v2 配合（与本站 OpenCode 2.2.0 记录 呼应）；修掉 Kimi CLI 的 tool-only assistant turns；更新 MLX 与 llama.cpp。

行动建议：① 生产改钉 v0.40.12，但只有 Apple 硬件能用上 LFM3 / d1 2B；② Linux / Windows 团队先别把 LFM3 写进部署文档，等官方的 coming soon 落地；③ 跑了 MLX 投机解码的，DFlash2 草稿模型是新支持项，值得单独测一次吞吐。v0.40.13-rc0 的处置已于 2026-10-30 更新：v0.40.13 与 v0.40.13-rc0 共用时间戳 2026-10-28T19:55:04Z，本站 10-29 只取到 rc0 并判定为 prerelease；本次复核确认 v0.40.13 的 prerelease 为 false，已转正为 stable，内容见下方 2026-10-30 一节——这正是本卡上文判据 ① 所述「同名 tag 共用时间戳」陷阱的又一次实例。详见 10-29 版本复核资讯。

2026-10-30 更新（v0.40.13，官方 Release Notes 原文一手核对）：LFM3 走出 Apple Silicon，登陆 Linux 与 Windows。

v0.40.13（2026-10-28T19:55:04Z 发布，prerelease: false）是当前 stable，接替 10-27 的 v0.40.12。 本版官方 Release Notes 只有一条，但方向很清楚——原文标题即为 「LFM3 on Linux and Windows」："Liquid AI's LFM3 models, including text-to-speech in lfm3-audio and lfm3-omni, now run on Linux and Windows as well as Apple silicon."

三点解读： ① LFM3 家族（Liquid AI）此前在 Ollama 上主要落在 Apple silicon，本版把 Linux 与 Windows 补齐——非 Mac 用户终于能在本机跑这条线了； ② lfm3-audio 提供 text-to-speech，也就是说这条线不只是文本生成，本机语音合成也一并可用； ③ lfm3-omni 同批覆盖，多模态侧同样受益。

与上一版对读：v0.40.12 官方原文写的 "Support for Linux/Windows coming soon"，在本版已兑现。上版「Linux / Windows 团队先别把 LFM3 写进部署文档」的建议可以解除。

本站未做安装与实测：未验证 LFM3 各尺寸的显存 / 内存占用、推理速度，也未核对 lfm3-audio 的语种支持与音频格式，这些均列入待核实，不作为选型依据。 官方 Full Changelog 对比基线为 v0.40.12...v0.40.13，除 LFM3 一条外官方未列其他条目；本站不对未列出的改动作断言。

2026-11-04 更新（v0.40.14，官方 Release Notes 原文一手核对）：一个会静默改变输出复现性的默认值被改掉了。

v0.40.14（2026-11-03T01:40:40Z 发布，prerelease: false）是当前 stable，接替 10-28 的 v0.40.13。生产请改钉 v0.40.14。

头条：OpenAI 兼容端点不再覆盖模型自带的采样参数。 官方原文 "OpenAI-compatible endpoints no longer override a model's packaged sampler defaults — clients that send no temperature/top_p get the model's own values instead of 1.0, matching /api/chat"。这是一条默认值语义变更，且方向是「变好」但「会改结果」：此前走 /v1/chat/completions 却不传 temperature / top_p 的客户端，实际拿到的是 1.0 / 1.0；现在拿到的是模型打包时自带的值，与 /api/chat 对齐。含义有三层：① 同一段代码升级前后的输出可能不同，做基准对比 / 回归测试的必须先显式固定采样参数；② 此前「OpenAI 兼容端点和 /api/chat 结果不一致」的困惑有了官方解释——不是模型不同，是采样默认值不同；③ 对依赖 temperature=1.0 默认行为的生成式应用（尤其是创意类），输出风格会明显收敛。

其余六条：

改动	官方原句要点
ollama launch claude 应用输出上限	按模型自身的 output token 上限配置 Claude Code，云模型不再撞 128k 默认天花板
云端 web search 解码	/api/chat 上云端 web search 响应正确解码，含压缩响应
/v1/responses 保留可读内容	不再压平输入内容，含此前 assistant 的拒答
Ollama 应用重试 ChatGPT 断连	断连后可重试，不再把连接留在坏状态
ollama launch codex 预检路由	配置前先验证 ChatGPT 路由，不可用时给出明确错误
MLX top-k 采样提速	大词表场景下更快

对使用者的实际含义：① 生产改钉 v0.40.14，但先跑一次输出对比——如果你的应用依赖 OpenAI 兼容端点的 temperature=1.0 默认行为，升级后效果会变；② 接 Claude Code 的，ollama launch claude 现在会按模型真实上限配，长输出任务不再被 128k 卡住；③ 接 Codex 的，路由不可用会在配置阶段就报错，比运行到一半失败好排查。

本站未做安装与实测：未验证采样默认值变更对具体模型输出的影响幅度，也未核对「模型自带的 sampler defaults」在各模型上的具体取值，均列入待核实。官方 Full Changelog 基线为 v0.40.13...v0.40.14，除上表七条外官方未列其他条目，本站不对未列出的改动作断言。

2026-11-07 更新（v0.40.15，官方 Release Notes 原文 + Releases API 逐 tag 一手核对）：recurrent 与视觉模型的并发限制解除了。

v0.40.15（2026-11-03T22:52:31Z 发布，prerelease: false）是当前 stable，接替同日 01:40 的 v0.40.14——两个 stable 相隔不到 21 小时。生产请改钉 v0.40.15。 上轮记录的「正式 tag v0.40.15 404、只有 rc0/rc1」已作废，正式 tag 现已存在。

头条：recurrent 与视觉 GGUF 模型可以同时服务多个请求了。 官方原文 "Recurrent and vision GGUF models can now serve more than one request at a time." 反向含义才是重点：此前这两类模型在 Ollama 上被钳在单请求。 对搭多用户服务、或多 agent 共用一个 daemon 的部署，这是从 1 到 N 的解禁。

但官方没给「N 等于几」：既未给槽位数，也未给显存换算式，也没说明是否统一受 OLLAMA_NUM_PARALLEL 约束。别按「官方说能并发」就把 parallelism 压满——本地 OOM 通常表现为请求超时而非显式报错，最难归因。建议固定上下文长度后从 2 槽位起压，用首 token 延迟与超时率而不是「有没有报错」判断过载。

新增模型与生态：

条目	官方要点
小米 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 的后继，并主动提供迁移现有 kimi-cli 配置的选项
ollama launch 补模型清单	自动填充 Pi 的模型列表；Claude Desktop 的模型选择器开始显示 Ollama 实际模型名
Qwen3 / Qwen3.5 长上下文	支持 YaRN 缩放；是默认开启还是需显式参数，官方未写
无参数启动	直接跑 ollama 进入 welcome launcher（此前是帮助文本）

对使用者的实际含义：① 生产改钉 v0.40.15；② 跑 recurrent（线性注意力 / 混合架构）或视觉模型的，重新压一遍并发——这是本站长期记录「这两类模型怎么调都上不去」的官方解法，但槽位数要自己测；③ 在用 kimi-cli 的，走 ollama launch 迁移前先备份原配置；④ Qwen3 / Qwen3.5 开长上下文的，复核 YaRN 打开后显存是否还够。

与本站另一条记录的关系：autotrust-jev 与 9 月记录的 TypeSafe AI 的 Jev 决策模型 属同一类产品形态在本地侧落地，但是否为同一厂商、有无授权关系，官方说明未写，本站不推断。

本站未做安装与实测：并发槽位数、OLLAMA_NUM_PARALLEL 是否统管、MiMo V2.6 的上下文长度、YaRN 是否默认开启，均列入待核实。详见 v0.40.15 资讯。

Ollama 是本地 LLM 的 Daemon 事实标准——后台跑、暴露 REST API（11434）+ CLI、Modelfile 配置、GGUF 一站式。MIT 开源，跨 Win / Mac / Linux。0.19+ 起 Mac M 系列底层切 MLX 推理。模型库覆盖 Llama / Qwen / DeepSeek / Gemma / Mistral 等主流开源模型，ollama pull 一键拉。

适合：给 Cursor / Cline / Continue / Open WebUI 接本地 OpenAI 兼容 endpoint、个人 / 评估 / 原型、嵌入应用、自动化脚本。不适合：GUI 偏好用户（用 LM Studio）、多用户并发生产服务（用 vLLM）、模型浏览 / 调参界面（用 LM Studio）。

Ollama 核心能力

• 后台 Daemon：开机自启，应用调用零延迟
• CLI：ollama pull / run / list / show / create / serve
• Modelfile：类 Dockerfile 注册任意 GGUF，配 SYSTEM / PARAMETER / TEMPLATE
• OpenAI 兼容 API：http://localhost:11434/v1/chat/completions
• 原生 API：/api/chat、/api/generate、/api/embeddings
• 模型库：官方注册表内置 Llama / Qwen / DeepSeek / Gemma / Mistral / GPT-OSS 等
• MLX 加速（Mac）：0.19+ 起 M 系列自动用 MLX
• 量化：默认 Q4_K_M、支持 Q5 / Q8 / FP16
• 跨平台：Win / Mac / Linux 安装包，Docker 官方镜像

Ollama 价格

完全免费、MIT 开源、商用免费。

Ollama 实测

亮点：

• ollama run qwen3-coder:7b 一行起飞，3 秒进交互
• REST API 配 Cursor / Cline / Continue 几乎全工具开箱即用
• Modelfile 写自定义编码助手（low temperature + system prompt + 16K context）几分钟搞定
• 多模型并存，按需切换，内存占用合理
• Mac M 系列 MLX 后比旧 GGUF 模式快显著

踩坑：

• 默认 num_ctx 偏小（2048），跑长上下文要在 Modelfile 加 PARAMETER num_ctx 16384
• 模型默认走 0.0.0.0:11434 ↔ Docker 容器互访要 --add-host=host.docker.internal:host-gateway
• 国内 ollama.com/library 下载偶有慢，可手动 HF 下 GGUF + Modelfile 自建
• 多用户并发吞吐显著低于 vLLM
• 没有 GUI，模型浏览 / 参数面板要走 LM Studio / Open WebUI 配合

Ollama 上手 5 分钟

1. curl -fsSL https://ollama.ai/install.sh | sh（Mac / Linux）；Windows winget
2. ollama pull qwen3-coder:7b（按需换模型）
3. ollama run qwen3-coder:7b 直接聊
4. 应用接入：baseURL = http://localhost:11434/v1
5. 自定义：写 Modelfile → ollama create my-coder -f Modelfile
6. 进阶：装 Open WebUI 做前端 / 多人共享

Ollama 与同类对比

Ollama 避坑清单

• num_ctx 一定要设：默认 2K 太小，跑代码 / 长文档要 16K+
• Modelfile 模板别漏 TEMPLATE：错的 chat template 会让模型输出乱码 / 不停
• KV cache 爆表 = 速度悬崖：32B 模型 32K 上下文，KV cache 可能 12+ GB，超显存自动 offload 慢 10×
• 不要 0.0.0.0 直接对公网：默认无鉴权，对外暴露走反代 + Bearer / mTLS
• Mac 让它自动用 MLX：升 0.19+；不要手动强制 GGUF + Metal

适合 / 不适合

• 应用 / IDE 接本地模型（Cursor / Cline / Continue）
• 个人 / 评估 / 脚本自动化
• Modelfile 自定义系统 prompt + 参数
• Mac M 系列 MLX 用户
• 多用户并发生产服务（用 vLLM）
• GUI 调参 / 模型浏览（配 LM Studio / Open WebUI）
• 极致单卡吞吐研究（直接 llama.cpp / vLLM）

常见误区

误区一：「能跑大模型 = 能省钱。」 省钱的前提是你有闲置算力且电费不计。一张闲置的 4090 跑 7B 模型成本确实低；但如果你为了跑它专门买卡、或者它占用了本来在跑训练的机器，账就不是这么算的。GPU 小时数是唯一诚实的单位。

误区二：「本地 = 隐私安全。」 本地解决的是数据不出内网。但请注意三件事：① 模型权重本身可能有许可与使用限制，不是「下载下来就归你」；② ** Ollama 的 API 默认无鉴权**，0.0.0.0` 直接暴露等于给内网任何人一个推理接口；③ 你拉模型的那条网络路径本身就会泄露你在关注什么。

误区三：「num_ctx 设到最大最好。」 KV cache 随上下文线性增长。32B 模型开 32K 上下文，KV cache 可能就吃掉 12+ GB，一旦超出显存就会 offload 到内存，速度掉一个数量级（不是慢一点，是慢十倍）。原则：按你实际的 p95 输入长度 + 一点余量来设，而不是按最大值设。

误区四：「一个 Modelfile 解决所有事。」 Modelfile 里最容易出错的是 TEMPLATE。它决定对话怎么被拼成 prompt，写错的表现不是报错，而是模型「看起来能说话但一直说不停」或输出乱码。换模型务必重查官方 template。

误区五：「vLLM 只是更快的 Ollama。」 两者优化目标不同：Ollama 优化的是单用户从零到能跑的体验；vLLM 优化的是多用户并发吞吐（PagedAttention + 连续批处理）。把 vLLM 当作「Ollama 的性能升级版」会让你在一个人用的场景下白白付出运维复杂度。

什么时候不该用 Ollama

相关阅读

• LM Studio 评测
• Open WebUI 评测
• Cherry Studio 评测
• RAG Pipeline 搭建 Playbook

Long-tail quick picks

长尾检索速查：下面三项对应「Ollama 开源版 / 免费版 / 国内可用」等搜索意图，方便直接跳转。

Open-source alternatives

• 是否开源：是（支持自托管）
• 想找开源替代？看这几个：Trae · Cline · Aider

Free tier

• 是否有免费档：是
• 价格概要：完全免费 + 开源（MIT）
• 预算敏感用户可先用免费档；进阶需求参考 通义灵码 / CodeGeex（国内免费额度更友好）。

China availability

• 是否国内可用：部分可用（本轮 2026-10-13 更正：原模板误写为「否」）
• 更正理由：Ollama 是 MIT 开源、可完全自托管的本地推理服务，不需要厂商账号、不存在地域封锁。它的国内限制只有一条——官方模型注册表 ollama.com/library 的拉取速度不稳定；而这个问题有明确的绕行路径：从 Hugging Face / 魔搭手动下载 GGUF，再用 Modelfile 注册（写法见上文「Ollama 上手 5 分钟」第 5 步）。把「下载慢」写成「不可用」会误导选型。
• 中文友好度评分：3 / 5（CLI 与文档均为英文；但本地运行不受语言环境影响，实际阻塞远低于「不可用」的判读）

相关替代品：

• lm-studio
• open-webui
• cherry-studio

来源

1. Markaicode — Import GGUF Models into Ollama 2026（2026-05-15）https://markaicode.com/import-gguf-models-ollama-guide
2. ComputingForGeeks — Ollama Models Cheat Sheet 2026 https://computingforgeeks.com/ollama-models-cheat-sheet
3. Codersera — Ollama vs LM Studio vs vLLM vs llama.cpp vs MLX 2026 https://codersera.com/blog/ollama-vs-lm-studio-vs-vllm-vs-llama-cpp-vs-mlx-2026/