研报速递DEEP RESEARCH · 本地大模型运行时
Ollama 深度研究报告
从一条命令，到开放模型的运行时层 ｜ 2026-11-13 口径
发布日期：2026-11-13 ｜ 领域：AI 基础设施 · 本地推理 · 开放模型生态 ｜ 阅读时长：约 22 分钟 ｜ 稳定版口径：v0.40.16（2026-11-09）
摘要
2026 年的 Ollama 已经不是「给 llama.cpp 套了个命令行的外壳」。按官方源核对，它同时是四层东西：一个本地模型运行时（CLI + 桌面 App + 单机调度器）、一个云端推理服务（Ollama Cloud / NCP 托管 / 按 token 计费）、一个三协议兼容网关（Ollama native、OpenAI、Anthropic），以及一个开放模型进入编码 Agent 与桌面工作流的默认入口（`ollama launch`、Claude Desktop、ChatGPT Desktop）。核心判断有三条：① 它的护城河不是推理速度，而是分发与协议适配——`ollama pull` 把模型资产变成可拉取的包，`ollama launch` 把运行时变成 Agent 的插座，双协议兼容把上游生态的迁移成本压到改一个 base URL；② 2026 年真正发生的是两次跃迁——3 月 MLX 引擎让 Ollama 从「llama.cpp 的封装」变成「多引擎运行时」，9 月 Jev 式决策模型让「小模型」从「弱一点的聊天」重新定义为「低成本确定性判别算子」；③ 生产边界必须写清楚：官方 FAQ 的默认并发是 1、默认上下文 4096、本地 HTTP 服务没有内建鉴权、没有 `/metrics` 端点，第三方 H100/A100 基准给出 20–29 倍吞吐差与 13–39% 的超时率。一句话总纲：Ollama 把「跑一个模型」压缩成一条命令，代价是把「服务一群人」留给了别人。本报告按「纵向演进 → 架构解剖 → 能力矩阵 → 云与定价 → 协议兼容 → 横向竞品 → 生产安全 → 商业化 → 趋势」九段展开，全部数字以 2026-11-13 可核实的官方页面为准，第三方估算统一标注口径。
一、术语界定：四个「Ollama」，别混着谈
这个词在中文技术讨论里被用在至少四个不同层级上，混用会让架构评审对象直接错位。先把口径切开。
| ollama（命令 / 二进制） | 127.0.0.1:11434 | |
| Ollama（产品 / 桌面 App） | ||
| Ollama Cloud | ollama.com/api 与 /v1，API key 鉴权，按 token 计费 | |
| Ollama Engine（引擎层） |
还要排除三类常见混淆：Ollama 不是模型（qwen3、gemma4 才是）、不是训练或微调框架（不产出权重，只消费权重）、不是高并发在线推理服务（vLLM / SGLang 才是那一层）。它是把「模型资产 + 单机调度 + 协议」封进一个可安装容器的运行时层。
专家注解（抽象层级的代价）：Ollama 做的是一次典型的抽象层级上移：把模型格式、显存评估、加载调度、多协议适配全部收进一个可安装容器，把复杂性从「使用者」转移到「容器」。收益是使用成本骤降——用户不必知道 GGUF 与 MLX 的区别，也不必自己写 chat template、配 CUDA 环境、处理模型换入换出；代价是容器本身成为新的单点，并发调度与鉴权都集中在这一层，且很难绕过它单独替换其中一环。本报告第七、八章会回到这两处边界。判断这个运行时是否适合你的场景，本质上是在判断「你愿不愿意把这两件事一并交给它」。
口径说明：本报告事实截止 2026-11-13。版本以 GitHub Releases 为准：稳定版 v0.40.16（2026-11-09 发布），另有预览版 v0.40.17-rc0。用户规模与融资采用官方博客 2026-07-09 的 8.9 million developers / $88M；第三方报告中的 GitHub stars、模型库数量、月下载量彼此差距极大（分别出现 5M / 9M、200+ / 1200+ / 4500+、173K / 176K / 180K 等口径），本报告一律不作为核心结论，涉及处标注 [不确定]。
二、纵向演进：从命令行封装到运行时层，六次跃迁
把官方博客与 Releases 按时间轴摊开，能清楚看到产品定位的六次跳变。下表只列改变定位的节点，同一时期的常规模型上架已略去。
| 跃迁① | ||
| 跃迁② | ||
ollama launch | 跃迁③ | |
| 跃迁④ | ||
| 跃迁⑤ | ||
| 跃迁⑥ |
值得注意的是节奏密度：v0.40.8 到 v0.40.17-rc0 集中在 2026-10-21 至 11 月这三周内，几乎每 2–5 天一个版本。这种发布频率在基础设施软件里是罕见的，也解释了为什么第三方基准极容易过期——第七章引用的所有倍率都必须当作快照看。
近五个版本的技术增量，比营销节点更能说明工程重心：
/v1/audio/speech | |
ollama launch 把云模型的上下文与能力正确传给编码工具 | |
/v1/audio/translations | |
/v1/responses 保留可读输入内容 | |
| v0.40.16（11-09，稳定版） | /v1/responses 尊重 truncation 且不再默认静默截断；/v1/models 空模型返回空列表而非 null；CUDA 13.5 / Windows on ARM；llama.cpp 升级 |
读法：把这份 changelog 按主题归类，会看到三条并行主线——① 内存与速度（27 GiB 优化、MTP、DFlash/DFlash2 投机解码、Vulkan mmap、q8_0/q4_0 KV cache）、② 协议正确性（sampler defaults、truncation、models 空列表、流式错误上报）、③ 新品类模型接入（语音、决策、全模态、混合架构）。其中第 ② 类最容易被低估，但它恰恰是「兼容层能否被生产系统信任」的真实成本。
三、架构解剖：一条 ollama run 背后发生了什么
把系统按层拆开，才能看清 Ollama 到底负责什么、不负责什么。以下六层均以官方文档为基础归纳。
| L0 入口 | run / pull / serve / launch / signin / ps / cp / create）、桌面 App、Python / JS 官方库、Quickstart 直连云 | ollama 无参数时打开欢迎启动器（v0.40.15 起） |
| L1 协议 | /api/*/v1/*（OpenAI）、/v1/messages（Anthropic）、Web search API | |
| L2 服务与调度 | 单机资源管理器 | |
| L3 引擎 | ||
| L4 硬件后端 | ||
| L5 模型资产 | ollama.com/library、private models / push / pull |
3.1 调度器：官方 FAQ 里的关键默认值
这部分是判断「能不能上生产」的硬依据，也是中文资料里错得最多的地方。以下全部来自 2026-11-13 可访问的官方 Local FAQ。
OLLAMA_HOST | 127.0.0.1:11434 | 0.0.0.0 才对外暴露 |
OLLAMA_CONTEXT_LENGTH | 4096 tokens | /set parameter num_ctx，API 用 options.num_ctx |
OLLAMA_NUM_PARALLEL | 1 | Required RAM ∝ NUM_PARALLEL × CONTEXT_LENGTH，示例 2K × 4 = 8K context |
OLLAMA_MAX_QUEUE | 512 | 503 overloaded |
OLLAMA_MAX_LOADED_MODELS | ||
OLLAMA_KEEP_ALIVEkeep_alive | -1 常驻、0 立即卸载、ollama stop 手动卸载 | |
OLLAMA_KV_CACHE_TYPE | f16 | q8_0（约半内存，官方标为「不用 f16 时的推荐」）、q4_0（约四分之一内存）；高 GQA 模型精度损失更明显 |
OLLAMA_FLASH_ATTENTION | 10 关；与 KV cache 量化配合显著降低长上下文内存 | |
OLLAMA_NO_CLOUDdisable_ollama_cloud | Ollama cloud disabled: true | |
OLLAMA_ORIGINS | 这是 CORS 白名单，不是鉴权 |
另外三条容易踩的机制：① 多 GPU 分配——模型能完整放进单卡就优先单卡（减少推理时跨 PCI bus 传输），放不下才 spread across all available GPUs；② GPU 并发加载——官方原文「使用 GPU 推理时，新模型必须能完整放入 VRAM 才允许并发模型加载」；③ 队列行为——内存不足时新请求排队，先前模型 idle 后被卸载腾位，排队请求按序处理。模型默认存储路径：macOS ~/.ollama/models、Linux /usr/share/ollama/.ollama/models、Windows C:\Users\%username%\.ollama\models，可用 OLLAMA_MODELS 覆盖。
专家注解：请注意这一层的定位——它是单机资源管理器，不是集群调度器。它做 VRAM 评估、模型换入换出、固定槽位分配；它不做 continuous batching、不做跨请求 KV cache 页式复用、不做多机张量并行。第七章那些「20–29 倍」的差距不是调参没调好，而是这两类调度器的设计目标本来不同。把 OLLAMA_NUM_PARALLEL 调到 32 只会把显存按槽位线性切开，不会凭空长出批处理能力。
四、能力矩阵：2026 年的 Ollama 能做什么
按「首次出现 → 当前状态 → 工程注意」整理。这里刻意把「能力」与「是否适合生产」分开，避免把功能清单误读成 SLA。
| 结构化输出 | /v1/chat/completions 支持 response_format | |
| 工具调用 + 流式 | ||
| Thinking 控制 | /v1 用 reasoning_effort / reasoning.effort，模型自定义名称优先，兼容别名映射 minimal→low、xhigh/ultra→max；GPT-OSS 无法关闭 thinking（none 也落到 low） | |
| 视觉 / 多模态 | content 数组；2026 年 Muse Glimmer 在 MLX 引擎上新增原生图像输入 | |
| Embeddings | /v1/embeddingsdimensions、encoding_format | |
| Web Search | /v1/responses 不支持内置 web search | |
| 图像生成 | ||
| 语音（Speech） | /v1/audio/speech 于 v0.40.8 | wav（不是 mp3），speed 仅支持 1，非法值返回 400 而非忽略 |
| 转录与翻译 | /v1/audio/translations | json / text / verbose_json / srt / vtt 与 SSE 流式增量 |
| 决策模型 | ||
| Responses API | /v1/responsestruncation，不再默认静默截断 | |
| 编码 Agent 集成 | ollama launch | |
| 长上下文 | num_ctx |
4.1 决策模型：2026 年最被低估的品类扩张
2026-09-29 官方博客《Ollama now supports Jev-style decision models》引入基于 TypeSafe Jev API 的决策模型：给它一段文本（或结构化状态、图片），问一个是非题 / 选择题 / 打分题，它返回每个选项的概率，而不是生成一段话。官方描述其「低延迟、可无成本运行」。随后两个多月内密集上架：
- AutoTrust（v0.40.15）
：9b / 35b / 27b-vl，后两者可读图；示例 ollama run autotrust-jev "A customer says their card was charged twice." --ask "Is this a billing issue?" - d1 / d1-omni（Liquid AI，v0.40.12）
：基于 LFM3，2B 起步，d1-omni 加音频； - d3（v0.40.11）
：来自 vLLM Semantic Router 的决策模型，2B / 4B / 9B / 27B，可接受文本、结构化状态或图像，输出分类、是非或带概率的打分； - Clef（Cloudflare，2026-10-19 上云）
：27B 多模态决策模型，可本地也可云端运行。
专家注解（为什么判别层比生成速度更重要）：决策模型的价值不在「更小」，而在它把小模型重新定位成验证器。Agent 系统里有一条朴素的验证层级：形式化校验 > 执行反馈 > 打分 / rubric > 模型自评，越靠近可机械验证的一端，闭环越不容易自欺。决策模型恰好提供了极便宜、极低延迟、可重复调用的判别层——用于路由、审核、guardrail、工具选择与结果验收。对做 Agent Harness 的团队来说，这比「再快 10% 的生成速度」更有架构意义：它把「生成—验证—重试」闭环里的验证成本，从一次大模型调用降到一次分类调用。Ollama 把这类模型做成一行 ollama run 就能拉起、并给出每个选项的概率，等于把验证器变成了随手可取的标准件——这比单纯多上架几个聊天模型更有架构价值。
五、云与定价：本地—云双栈的商业闭环
Ollama Cloud 不是把本地服务搬上云，而是三条访问路径并存：
| 纯本地 | http://localhost:11434 | ollama pull |
| 直接云 API | https://ollama.com/api/v1 | Authorization: Bearer $OLLAMA_API_KEY/api/tags，无需 pull |
| 本地 server 转发云模型 | http://localhost:11434gemma4:cloud | ollama signin；保留本地工具链与统一端点，创建/删除模型仍需本地 server |
托管侧事实：模型权重使用提供方发布的原生权重，在现代 NVIDIA 硬件上可能采用 Blackwell / Vera Rubin 支持的加速格式（如 NVFP4）；算力主要托管在美国，为全球需求可能路由到欧洲扩容；合作方为 NVIDIA Cloud Providers（NCP）。隐私口径是官方明确承诺的 ZDR（zero data retention）：prompt / response 仅瞬时处理，不存储、不记录、不用于训练，仅收集基础账户信息与不含内容的有限 usage metadata；Ollama 要求合作托管方同样执行 no logging / no training / zero data retention；不出售数据，账号可随时删除。
5.1 五档定价（2026-08-31 起 per-token 制）
计费细则：所有档位均可另购 usage credits，扣除顺序为「套餐内额度 → 已购余额」；额度按月重置、不滚存，重置日取订阅起始日（年付亦按月重置）；用量达 90% 邮件提醒；并发上限之外的请求排队，队列满则拒绝；Pay as you go / Pro 为 3 并发，Max / Team 为 10。Off-Peak 定价适用于工作日 12:00–18:00 UTC 之外及周末全天。
代表性模型价格（每百万 token，输入 / 缓存输入 / 输出，单位美元）：
专家注解：2026-08-31 的「transparent pricing」是一次定价单位重构：从旧版 Pro / Max 的 session / weekly 限制，改为 per-token + 月度 credits。官方 FAQ 明确写「切换到新方案后，旧方案的 session 与 weekly 限制不再适用」。这一步把收入与边际成本对齐，同时用 Off-Peak 半价把价格当成负载调度信号——这与数据中心分时电价、云厂商 Spot 实例是同一套思路。另一个信号是「云模型列表本身成了行业快照」：deepseek-v4.1-flash、glm-5.3、kimi-k3.1-pro、mimo-v2.6、minimax-m3.1-flash、mistral-large-4 同期在架，说明 Ollama 的中立分发位已经形成。
六、协议兼容：三套协议，一个底座
这是 Ollama 最容易被低估、也最有商业价值的资产。官方 API introduction 给出的 base URL 矩阵：
https://ollama.com/api | http://localhost:11434/api | |
https://ollama.com/v1 | http://localhost:11434/v1 | |
https://ollama.com | http://localhost:11434 |
Anthropic 客户端会自动在 base URL 后拼 /v1/messages。云请求需要 API key，本地请求不需要；本地 OpenAI 客户端虽要求填一个 api_key 值，但官方明确「required but ignored」。官方库为 Python（ollama-python）与 JavaScript（ollama-js），直连云时把 host 设为 https://ollama.com 并带 Bearer 头。
6.1 端点覆盖
| Ollama native | /api/chat/api/generate | options.num_ctx、keep_alive、预加载空请求 |
/api/show/api/tags、/api/pull、/api/delete、/api/copy | ||
| OpenAI | /v1/chat/completions | n；reasoning_effort、tool_choice、logit_bias |
/v1/completions | prompt | |
/v1/responses | think 为 Ollama 扩展 | |
/v1/models/v1/embeddings、/v1/audio/* | createdowned_by 默认为 library | |
| Anthropic | /v1/messages | anthropic-version: 2023-06-01；2026-01-16 起支撑 Claude Code 用开放模型 |
6.2 兼容性尽调清单：不支持 / 易踩坑的地方
- Responses 是无状态的
：不支持 previous_response_id与conversation，每次请求须自带历史；云 API 还不支持 stateful Responses、/v1/responses内置 web search、自定义 / freeform 工具回放。 - OpenAI 协议无法设置上下文长度
：官方给出的唯一解法是写 Modelfile 的 PARAMETER num_ctx再ollama create出新模型名。 - 默认模型名要造假
：依赖 gpt-3.5-turbo之类硬编码名的旧工具，需用ollama cp llama3.2 gpt-3.5-turbo临时映射。 - 音频默认值与 OpenAI 不同
： /v1/audio/speech默认wav而非mp3，speed仅接受 1，不支持的值返回 400 而不是被忽略。 - sampler 语义在 v0.40.14 改过
：OpenAI 兼容端点不再覆盖模型自带采样默认值；不传 temperature/top_p时使用模型自身值，而非硬编码 1.0，与/api/chat对齐。升级后输出风格可能变化，需重跑评测集。 - API 不严格版本化
：官方承诺稳定与向后兼容，弃用罕见且会在 release notes 公布——这意味着要盯 changelog 而不是盯版本号语义。 - 迁移到 vLLM / SGLang 时的隐蔽差异
：Ollama 的 completions 端点会把原始 prompt 包进 chat template，而其他引擎按原样发送，切换后需核对模型实际收到的内容 [不确定，第三方对比材料]。
专家注解：评估任何「兼容层」都不要看它宣称支持多少字段，要看它在语义边界上做了哪些静默决策。v0.40.16 修的「/v1/responses 不再默认静默截断」、v0.40.14 修的「不再覆盖 sampler defaults」、v0.40.9 修的「流式失败不再静默结束」，三条都属于同一类问题：静默行为。对上层 Agent 而言，静默截断比直接报错危险得多，因为它会产生一个看起来完整、实际被削掉上下文的答案，并把这个答案继续喂给下一轮。这套「静默行为清单」可以直接作为团队选型兼容层的检查表。
七、横向对比：本地运行时与生产服务栈，不是同一场比赛
把常见选项放在一张表里，先按「优化目标」分类，再比参数。
| Ollama | ||||
| vLLM | /metrics | |||
| SGLang | ||||
7.1 三组公开基准（全部为第三方快照）
OLLAMA_NUM_PARALLEL=32 调优后 Ollama 仍明显落后 | ||
口径风险（务必带上）：① 三组数据均为快照，倍率随模型、量化、GPU、版本变化，公开材料给出的倍率跨度从约 2× 到 29×；② Red Hat 测的是 Ollama 0.9.2，其当时默认 4 并行，而当前官方 FAQ 默认为 1，不可直接套用；③ 部分材料引用了 CVE-2025-63389 等第三方漏洞条目与「公网暴露 >2 万个服务」的规模估算，时点与统计方法不一，均标 [不确定]；④ Winder.AI 给出的每百万输出 token 成本对比（同卡满载时 SGLang 约 $0.56 vs Ollama 约 $29.48）属第三方测算，包含 $3.49/小时 H100 租金假设，[不确定]。
决策树：单人 / 笔记本 / Apple Silicon / 数据不出网 / 快速验证模型 → Ollama；8 并发以上 / 用户面在线 API / 共享 GPU 池 / 需要 Prometheus 指标与多机扩展 → vLLM 或 SGLang；中间态的最佳实践是两者都用——Ollama 作为模型评估与迭代 harness（GGUF 一行切换），vLLM 承担生产流量。最需要避免的失败模式是「第一周因为好装选了 Ollama，产品长起来后忘了换」。
7.2 同类产品迁移清单：从 Ollama 换到 vLLM / SGLang 要核对什么
「改个 base URL 就切过去」是这套兼容层最大的错觉。协议相同不等于语义相同，下面六项是实际迁移时最容易出问题的地方。
| 权重格式 | ||
| 上下文与采样 | num_ctx；v0.40.14 起兼容端点沿用模型自带 sampler 默认值 | max_model_len |
| prompt 处理 | /v1/completions | |
| 并发与限流 | max-num-seqs / state cache 与 gpu-memory-utilization，否则可能被静默限流 | |
| 可观测性 | /metrics，指标在反向代理层采集 | /metrics，迁移后监控口径要重接 |
| 部署与鉴权 |
反向也成立：当需求变成「离线演示、端侧隐私、快速试十个量化版本」时，从 vLLM 换回 Ollama 同样是理性选择。真正的选型依据不是谁 benchmark 更高，而是当前负载的并发量、数据是否能出网、以及团队愿意承担多少运维面。三者变了，答案就该跟着变。
专家注解：不要把「20–29 倍」当成产品质量结论。真正的分野在调度器：vLLM 用 continuous batching 让新请求在每个生成步加入运行批次，用 PagedAttention 把 KV cache 当虚拟内存页管理；Ollama 给每个并发槽预分配固定 context buffer。前者是集群调度器，后者是单机资源管理器——两者优化的目标函数分别是「GPU 利用率」与「首 token 延迟 + 安装复杂度」，本来就不在一张记分卡上。更值得决策层关注的是错误率而非倍率：20 倍吞吐差是容量规划输入，39% 的失败率是线上事故。
八、生产落地与安全边界：一次重要的口径纠错
2025 年 Ollama 因本地部署 DeepSeek 浪潮进入监管视野。可核实的事实链条：
- CNVD-2025-04094
：国家信息安全漏洞共享平台收录「Ollama 未授权访问漏洞」，综合评级高危；影响范围表述为「Ollama 所有版本（未设置访问认证的情况下）」。 - 2025-03-03 通报
：国家网络与信息安全信息通报中心依据清华大学网络空间测绘联合研究中心分析发布公告，指出默认配置存在未授权访问与模型窃取隐患；工信部网络安全威胁和漏洞信息共享平台（NVDB）同期发布风险提示。 - 三类风险
：未授权访问（无需认证即可调用模型、操作模型与数据）、数据泄露（例如经 /api/show取得 license 等敏感信息）、算力盗取 / 数据投毒 / 恶意文件上传 / 关键组件删除 / 服务拒绝。 - 历史 CVE
：公告点名 CVE-2024-39719 / 39720 / 39721 / 39722 可与未授权访问组合利用。
8.1 纠错：默认配置其实已经改了，但鉴权仍然缺失
这是全文最需要澄清的一点。2026-11-13 官方 Local FAQ 的原文是「Ollama binds 127.0.0.1 port 11434 by default」。也就是说，当前版本的默认安装并不对外监听，不能笼统写成「Ollama 默认就有公网漏洞」。真实的风险入口是四类显式操作：把 OLLAMA_HOST 改成 0.0.0.0、Docker 的 -p 11434:11434 端口映射、云主机安全组放通、以及 Nginx / ngrok / Cloudflare Tunnel 反代配置错误。漏洞通报描述的是部署态，不是发行态。
但第二个问题至今成立，而且更本质：本地 HTTP server 本身没有内建鉴权。官方 Local FAQ 没有提供本地 HTTP API 的账号 / 密码 / API key 中间件配置；它把账户、API key、隐私、云模型问题全部指向 Cloud FAQ。三个常被混淆的概念必须分开：
| API key | ollama.com/api 的程序 | 不能 |
Ollama Public Keyid_ed25519.pub） | 不能 | |
OLLAMA_ORIGINS | 不能 |
8.2 五层加固清单
| ① 绑定层 | OLLAMA_HOST=127.0.0.1；用 ollama ps 与端口核查验证；容器不要无差别映射 11434 |
| ② 网络层 | |
| ③ 代理鉴权层 | |
| ④ 接口治理层 | /api/pull、/api/push、/api/delete、/api/copy、/api/show；对 chat 限流防 DDoS；对模型资产做完整性校验防投毒 |
| ⑤ 版本与审计层 | ~/.ollama/logs/server.log；敏感环境用 OLLAMA_NO_CLOUD=1 或 disable_ollama_cloud 锁定本地仅模式 |
8.3 运维侧的三个硬缺口
- 无可观测端点
：官方 Local FAQ 未记载 /metrics端点；延迟与错误率需在反向代理层采集。对有 SLO 的系统，这是必须补的一层。 - 无横向扩展设计
：官方只描述单机多 GPU 的分层与 spread，未描述集群调度；规模化只能「多副本 + 负载均衡」，且每个副本有独立队列，容易在尾延迟上叠加。 - 并发与显存强耦合
：提高 OLLAMA_NUM_PARALLEL会按NUM_PARALLEL × CONTEXT_LENGTH放大内存，长上下文 + 高并发极易 OOM；超额请求排队到 512 后返回503 overloaded，属于「排队后拒绝」而非优雅降级。
上线前 10 条检查项：绑定地址 / 安全组 / 反向代理鉴权 / 危险接口禁用 / chat 限流 / 版本锁定与升级流程 / 代理层指标与日志 / num_ctx 显式设定 / NUM_PARALLEL 与显存预算验算 / 模型来源与哈希校验。此外建议把 keep_alive 与预加载（对 /api/generate 发空请求）纳入冷启动预案，并在升级后重跑评测集——第三章提到的 sampler 语义变更就是典型例子。
九、商业化与生态位：中立分发层的价值
2026-07-09 官方博客《Ollama: all aboard open models》披露：服务 8.9 million developers，完成 $88M 融资，投资方为 Benchmark、Theory Ventures、8VC、Y Combinator 及多位天使投资人。这是判断其战略意图的关键锚点，也是本报告唯一采用的规模数字（第三方 stars / 模型数 / 下载量口径分歧过大，标 [不确定]）。
商业模式可归纳为三级漏斗：本地免费（获客、分发、开发者心智）→ 云推理按 token 变现（大模型跑不动本地硬件时的自然溢出）→ Team / Enterprise 治理变现（统一计费、模型访问控制、成本预算、安全问卷）。注意 Enterprise 卖的不是更快，是可控：限定团队可访问的模型、给每个用户与 API key 设成本上限、提供定制安全问卷——这三项恰好对应企业采购最常卡住的三个问题。
更关键的是中立性。从官方博客可核实的合作方横跨几乎所有阵营：
这张表说明 Ollama 不与任何模型厂竞争，它占据的是「开放模型 → 开发者工作流」之间的通道。谁的模型想被本地开发者第一时间用上，谁就需要这个通道；反过来，通道的议价能力来自三协议兼容与 ollama launch 的渠道位，而不是推理性能。
四类结构性风险：① 上游开放权重发布节奏若收紧，分发层的货品供给受影响；② 云推理价格战下，per-token 模式的毛利空间被压缩；③ 三套上游 API 持续演进，兼容层是长期维护负债；④ 商业化后开源社区的信任治理，以及「本地无鉴权」带来的品牌与合规外溢风险——即使默认绑定已修正，只要企业部署事故仍被归因到 Ollama，这项成本就存在。
十、挑战、趋势与专家判断
| 三引擎的维护成本会持续上升 | ||
| 并发是结构性边界，不是调参问题 | ||
| 从「生成运行时」变成「本地多模态算子库」 | ||
| 决策模型会成为 Agent Harness 的标配验证层 | ||
| 协议兼容既是资产也是负债 | ||
| 编码 Agent 入口是最强渠道位 | ollama launch | |
| 端侧软硬协同成为主要性能来源 | ||
| 云—端分工会沿隐私边界细化 | ||
| 安全与合规进入产品功能清单 | ||
| 与同类产品的竞争焦点从「能跑什么」转向「能被谁直接调用」 | ollama launch 与桌面 App 集成、三协议兼容、本地—云同构 API 才是相对 llama.cpp / LM Studio / Docker Model Runner 的差异点；相对 vLLM / SGLang 则始终是分工而非替代 |
十一、总结
一句话总纲
Ollama 把「跑一个模型」压缩成一条命令，代价是把「服务一群人」留给了别人。它优化的是分发效率、跨硬件一致性与协议迁移成本，不是 GPU 利用率。
三条核心判断：
- 定位判断
：2026 年的 Ollama 是「本地运行时 + 云推理 + 三协议网关 + Agent 入口」四层合体，护城河在分发与协议适配，不在推理速度。 - 技术判断
：3 月 MLX 引擎确立多引擎路线，9 月决策模型确立判别算子品类，Q4 的密集版本把重心放在内存优化与协议正确性；默认 1 并发 / 4096 上下文 / 本地无鉴权，决定了它的适用边界。 - 工程判断
：把它用在单人、低并发、隐私、离线、原型与端侧是最优解；把它用在高并发在线服务是用错了工具。第三方基准的 20–29× 吞吐差与 13–39% 超时率应读作「调度器设计目标不同」，但错误率必须当作真实事故风险对待。
分角色行动建议
| 个人开发者 / 研究者 | ollama launch 接入编码 Agent；显式设 num_ctx；对敏感材料开 OLLAMA_NO_CLOUD=1；把决策模型用作本地 guardrail / 路由验证 |
| 企业平台团队 | |
| 安全负责人 | /api/pull 等危险接口；明确 CORS、API key、Public Key 都不是本地鉴权；对照 CNVD-2025-04094 做一次暴露面排查 |
| 战略 / 投资视角 | ollama launch 带来的 Agent 入口份额、以及兼容层补丁占 release 的比例（负债侧的代理变量） |
收尾注解：把 Ollama 放回同类产品的坐标系，位置其实很清晰：往下比 llama.cpp、MLX 多了一层服务化与协议适配，往上比 vLLM、SGLang 少了集群调度与可观测性，往旁边比 LM Studio、Docker Model Runner 多了云—端同构 API 与编码 Agent 入口。它选择的不是「把某一项做到极致」，而是把「从下载模型到被工具调用」这条链路整段变短。工程上真正要做的，不是要求它补齐所有能力，而是清楚知道这条链路在哪个并发量、哪种数据敏感级别上会失效，然后提前把失效的那一层换掉。
附：参考来源与口径说明
官方一手来源（本报告主要依据，均于 2026-11-13 核对）：
GitHub Releases · github.com/ollama/ollama/releases（v0.40.8 → v0.40.17-rc0 全部变更条目）官方博客时间线 · ollama.com/blog（2024-11 至 2026-10 全部条目日期与摘要）Local FAQ · docs.ollama.com/faq（并发默认值、内存公式、绑定地址、KV cache、多 GPU、云功能禁用、模型路径）Cloud FAQ · docs.ollama.com/cloud/faq（ZDR、API key 与 Public Key 区分、公钥路径）API Introduction · docs.ollama.com/api/introduction（三协议 base URL、鉴权、版本策略）OpenAI compatibility · docs.ollama.com/api/openai-compatibility（端点、支持字段、音频规格、Responses 限制）Quickstart · docs.ollama.com/quickstart（CLI、四协议请求示例、本地模型下载规格）Pricing · ollama.com/pricing（五档套餐、模型价格表、Off-Peak、并发与隐私条款）
监管与第三方来源（按需引用，均已标注口径）：国家信息安全漏洞共享平台 CNVD-2025-04094 公告（转载于地方网信通报页面）、国家网络与信息安全信息通报中心 2025-03-03 通报（中新经纬等媒体转述）、工信部 NVDB 风险提示、Red Hat Developer 2025-08 A100 基准、Applied Sciences 16(11):5435（2026）H100 同行评审基准、Winder.AI 2026-09 H100 五引擎对比、Origins AI / Prodinit 2026 企业选型综述。
[不确定] 项汇总：① 图像生成是否已全平台正式支持；② 第三方报告中的 GitHub stars、活跃用户、模型库数量、月下载量与公网暴露服务数量；③ CVE-2025-63389 等第三方漏洞条目的权威性与影响范围；④ 官方未来是否引入 continuous batching 或更高并发调度；⑤ 第三方测算的自托管每百万 token 成本；⑥ Ollama completions 端点与 vLLM 在 chat template 处理上的差异（来自第三方对比材料）；⑦ 各基准所用版本默认值与当前版本默认值不一致带来的可比性。
说明：本报告为技术调研与架构分析，不构成采购、投资或安全合规结论。所有版本号、价格与功能状态以官方页面为准；涉及生产决策请以实际环境复测为准。
DEEP RESEARCH · Ollama 专题 ｜ 2026-11-13
