Ollama 的定位一直很清楚：一个把模型下载、加载、推理服务打包在一起的本地运行时。它解决的是"把模型跑起来并暴露一个能调的接口"，不解决训练、微调、向量库、agent 编排这些事——后者要靠别的组件补。认清这条边界，再看 v0.40.9 的四条变化，才知道哪些对你有用。
这次 release notes 给了四条：
- Flint 模型现在支持 Linux 和 Windows，此前只有 macOS
- 流式 OpenAI Responses 与 Anthropic Messages 请求在生成失败时会报错，而不是输出一部分后静默结束
ollama launch会把云端模型的上下文长度和能力传给编码工具，修正了工具里错误的上下文与压缩设置- Anthropic 兼容的 web search，后续请求会改用模型所支持的 thinking 设置
四条里没有一条是性能数字，全是"把原本会咬人的地方补上"。这类更新对已经在用的人价值更高。
Flint 的平台覆盖
Flint 进 ollama.com/library 之后一直只批了 macOS，Linux 和 Windows 用户拉下来会失败。0.40.9 把这两个平台补齐，意味着团队里不同系统的人可以用同一个模型名对齐实验，不用各自找替代模型。
# 拉取并运行 Flint：0.40.9 起 Linux / Windows 可用，此前仅 macOS
ollama pull flint
ollama run flint
# 服务端、云端模型下发与状态查看
ollama serve
ollama launch # 把云端模型的上下文长度与能力传给编码工具
ollama show # 查看模型参数，确认下发的上下文长度
ollama ps # 看当前加载了哪些模型、占用多少显存
ollama run 适合交互式试模型，真要接进应用还是走 ollama serve 之后的 HTTP 接口：默认监听 127.0.0.1:11434，OpenAI 兼容端点是 /v1。
需要注意的是"支持某个平台"不等于"在你的机器上跑得动"。Flint 的显存和内存占用取决于模型规格与量化方式，机器不够时 Ollama 会把层卸载到 CPU，速度会明显下降，这不是版本能修的问题。
流式失败的错误上报
这条是四条里最实用的一条。在此之前，走 OpenAI Responses 或 Anthropic Messages 兼容接口的流式请求，如果生成中途失败，可能表现为输出了一段就正常结束——客户端收不到任何错误，把不完整的内容当成完整结果往下传。0.40.9 之后这类失败会带上错误。
客户端最好顺手把错误分支写全，别只处理 delta：
import json
import os
import requests
BASE = os.getenv("OPENAI_BASE_URL", "http://127.0.0.1:11434/v1")
messages = [{"role": "user", "content": "把这周的订单异常列一下"}]
with requests.post(
f"{BASE}/chat/completions",
json={"model": "flint", "messages": messages, "stream": True},
stream=True,
) as resp:
for raw in resp.iter_lines():
if not raw or not raw.startswith(b"data:"):
continue
chunk = json.loads(raw[5:])
if "error" in chunk:
# 0.40.9 起生成失败会带错误对象，而不是输出一半后静默结束
raise RuntimeError(chunk["error"].get("message", "generation failed"))
print(chunk["choices"][0]["delta"].get("content", ""), end="", flush=True)
服务端报错只是让错误"可达"，客户端还要真的去看。如果上层把流式响应直接拼接后就落库，建议加一个结束标记检查：正常流会收到结束信号，收到错误对象或连接提前断开时应当标记这条结果为不完整。
launch 下发的上下文与能力
第三条对用编码工具的人影响最直接。云端模型通过 ollama launch 接进本地端点时，编码工具此前拿不到准确的上下文长度和能力描述，只能靠内置猜一个，于是压缩（compaction）阈值设错——要么过早压缩丢掉上下文，要么撑爆窗口后才触发。0.40.9 让 launch 把这两项一并传给工具，工具按实际值设置。
对使用方来说，配置上要做的是把写死的那些值删掉：
# 让编码工具走本地 OpenAI 兼容端点，上下文与能力由 launch 下发
export OPENAI_BASE_URL=http://127.0.0.1:11434/v1
export OLLAMA_HOST=127.0.0.1:11434
ollama launch
如果之前的配置里写死了上下文长度或压缩阈值，这次升级后应当删掉，让工具用下发值。写死的值与模型实际能力不一致，正是这次要修的那类问题。
第四条是 Anthropic 兼容路径上的 web search：后续请求改用模型本身支持的 thinking 设置，避免因为传了不支持的设置而失败。这条只在走 Anthropic 兼容接口且开了 web search 时才碰得到，属于把边缘路径的报错率压下去。
与 LM Studio、llama.cpp 的对比
三者是本地运行时最常见的三个选项，定位差别明显：
| 维度 | Ollama | LM Studio | llama.cpp |
|---|---|---|---|
| 形态 | 命令行 + 后台服务 | 桌面应用（带图形界面） | 推理引擎与命令行工具 |
| 上手成本 | 一条命令拉模型，接口即用 | 装客户端，界面里点选模型 | 需自行编译或找构建产物，参数要自己调 |
| 模型管理 | 官方模型库，按名字拉取 | 内置模型检索与下载 | 自己准备权重文件（GGUF 等） |
| API 兼容 | 本地 REST + OpenAI 兼容端点 | 提供本地服务与兼容端点 | 自带 HTTP 服务，兼容能力需自行确认 |
| 资源占用 | 常驻服务，模型按需加载 | 客户端常驻，占用偏高 | 最精简，无额外常驻开销 |
| 适合谁 | 要把本地模型接进脚本和应用 | 想可视化试模型、调参数 | 要抠性能、做嵌入式或自定义集成 |
表里没有填具体数字，因为这类数字随版本和模型变，抄一个当下值反而误导。选型时按形态和团队习惯判断更稳。
选型建议
如果目标是让应用代码调一个和 OpenAI 接口同构的本地端点，Ollama 是三者里最省事的：ollama serve 起来就有 /v1，客户端改一个 base_url 就能切。团队里多人要用同一个模型，也只需要在各自机器上 ollama pull 同一个名字。
如果目标是评估模型效果、调 sampling 参数、看不同量化版本差异，LM Studio 的图形界面效率更高，不用来回改命令。
如果目标是把推理嵌进自己的产品、或者要在受限环境里抠内存和算力，llama.cpp 更合适——它是最靠近底层的一层，代价是参数和环境都得自己管。
三者并不互斥：常见组合是本地用 Ollama 起服务做开发，生产环境换 llama.cpp 或自建推理服务，接口层保持一致。
不适合谁
不打算在本地跑模型、只调云端 API 的团队，装 Ollama 只是多一个要维护的进程。
需要微调或训练的场景，Ollama 不提供这条路径，它只负责推理与分发。
需要多机分布式推理、高并发服务的场景，Ollama 的单机服务模型撑不起来，应该直接看专门的推理服务框架。
对模型规格极其敏感、需要精细控制批处理、线程数、KV cache 等参数的人，Ollama 把这些封装掉了，llama.cpp 层面的调参自由度更高。
最后一条：如果团队里没人愿意维护本地模型缓存和显存分配，那么本地运行时的收益会被运维成本吃掉，直接用云端 API 更划算。