Open Models Change The Economics of AI

Ollama CEO Jeffrey Morgan：企业80-90%的token将流向开源模型，但预算只占10-20%；AT&T已把40% token消费转移到开源模型。

开放模型越便宜，越值钱的是编排

Jeffrey Morgan 是 Ollama 联合创始人兼 CEO，早年曾在 Docker 参与打造 Docker Desktop。今天的 Ollama 已被 900 万开发者使用，拥有 17.8 万 GitHub stars，并进入 85% 的《财富》500 强企业。它既看到开发者在本地跑什么，也看到企业在云端为哪些模型付费。Morgan 给出的判断很直接：模型正在变成越来越便宜的原料；真正难、也真正值钱的，是把模型接进真实工作流的那层工程。

这期回答了 8 个问题：

1. 为什么企业未来会把 80%—90% 的 token 交给开放模型，却只花很小一部分预算？
2. 当 token 变得充足且廉价后，AI 产品真正稀缺的能力是什么？
3. 一个新模型发布当天，为什么往往比训练模型本身更像一场工程火灾演练？
4. 本地模型和云端模型会如何按任务难度重新分工？
5. 做传统基础设施的人，为什么必须放弃“系统必须完全确定”的执念？
6. Ollama 花了两年找方向后，为什么只用两周就完成了关键转向？
7. 企业使用中国来源模型时，究竟更在乎模型产地，还是模型运行的位置？
8. 为什么一个免费、无需审批的开发者工具，能从爱好者迅速进入大企业？

被问到企业采用开放模型是否只是为了降本时，Morgan 先给了一个看似矛盾的比例。token 是模型读取和生成文本时的基本计量单位，可以粗略理解为 AI 完成一次工作所消耗的“字词燃料”。他的判断是，企业内部最终有 80%—90% 的 token 会由开放模型处理，但开放模型只会占总成本的 10%—20%。"The super majority of tokens and this is our take it will be open models within a business. Call it 80 90%."（我们判断，一家企业里的绝大多数 token 都将来自开放模型。大概是 80% 到 90%。）

这不是说企业突然不再需要最强的闭源模型。相反，最难的问题仍会留给聚集顶尖研究者的前沿实验室。但一家公司里的 AI 任务并不全是“最难的问题”。大量编程辅助、资料整理、客服支持、销售和财务流程，单次推理不一定需要最高智力密度，却可能有极高调用量。Morgan 援引《The Information》的报道说，AT&T 已将 40% 的 token 消费迁移至开放模型，同时也在评估中国模型。

这意味着企业关心的不只是把每一次调用压到多便宜，而是能否放心地把更多工作交出去。开放模型先解决最痛的成本问题，随后带来控制权：企业可以按自己的场景部署、调整和定制。预算大头仍可能花在少量昂贵的云端复杂任务上，但日常工作流的默认算力层，会逐渐由便宜且可控的开放模型承担。

被问到开放模型生态会拆出哪些独立公司和服务时，Morgan 的答案没有停在“再做一个模型平台”。他认为，开放模型 token 的供给正在迅速充足，已经有数十家提供商能供应它们。真正变稀缺的，不是再多拿一点模型输出，而是把这些输出组织成能做事的系统。"The new scarcity the problems now are what's above the tokens right?"（新的稀缺性，恰恰是 token 之上的那些问题。）

他引用 Anthropic 平台团队对这一层的划分：第一是知识，如何把企业内部数据和上下文连到模型；第二是协调，一个请求可能拆成多个子代理，有的在本地跑，有的在云端跑，谁先做、谁接手、何时停止，都要有人调度；第三是执行，代理越来越多地在云端完成任务，需要隔离环境和计算资源。这里的“代理”不是聊天窗口，而是能调用工具、查找资料、执行多步流程的软件角色。

更棘手的是状态。状态指系统必须持续记住的东西，例如历史上下文、数据存储、登录凭证和安全规则。模型训练完成后，权重就固定了，不能把最新客户记录、权限变化或密码管理直接“塞回模型”。这意味着竞争会往控制平面上移：保存什么、允许谁访问、如何派发任务、怎样验证执行结果，都会成为产品核心。单个开发者不可能独自造齐这些层，开放生态也因此会出现更多专门处理记忆、权限、协调和执行的服务。

被问到 Ollama 如何应对新模型发布时的流量爆发时，Morgan 描述的不是一次轻松的“上架”，而是一套临战拼装。研究实验室发布的是模型权重，但让用户真正用起来，还要先让推理引擎支持它，并确保速度够快、输出准确、行为符合参考实现。这一步有时就要花数周。模型架构、工具调用机制和性能问题都可能不同，一次集成并不能换来永久通用的流程。

Ollama 把首发交付拆成三件事：先准备好 harness 或 SDK，也就是让开发者能以正确方式调用模型的运行外壳；再保证模型本身和云端容量可靠，尤其是首发日通常会迎来最大流量；最后要与硬件和推理提供商一起调优，模型再强，跑得慢也不是好体验。正式发布前，还必须对最终产品做基准测试，而不是只看实验室给出的分数。"A lot of this stuff comes together in the last 24 hours before the model gets released and so it's generally a fire drill."（大量事情都在模型发布前最后 24 小时才拼到一起，所以通常就是一场火灾演练。）

这意味着开放模型分发商越来越像运行时和操作系统提供者。用户感受到的是 API 是否稳定、工具能否调用、速度是否达标；这些体验来自推理、容量、硬件和应用接口的同步，而不只来自权重本身。模型迭代越快，这个“最后 24 小时”的工程能力就越重要。

被问到企业会如何选择本地模型还是云端模型时，Morgan 不认为这是一次站队。他看到的新一代硬件已经很擅长运行 200 亿到 400 亿参数的模型，有时甚至可以运行 1280 亿参数模型。参数量可以理解为模型内部可学习的规模，通常越大，运行所需的硬件资源也越多。现在的问题不是“本地能不能跑”，而是“什么任务值得本地跑”。

他的观察是，编程代理往往还需要大型云端模型，因为它们要理解复杂代码库、写代码、写测试并反复修正，端到端难度高。文档处理则不同：如果流程更标准化，例如提取、分类、归档或按规则整理，本地模型已经很合适。"for easier tasks you could run them locally and with lower latency and of course lower cost when it comes to the per token cost."（对于更简单的任务，你可以在本地运行，获得更低延迟，当然单个 token 的成本也更低。）

因此，企业未来要建设的未必是一套“万能模型”，而是一个路由器。它识别任务难度，把简单、频繁、标准化的请求留在本地硬件上完成；只有遇到真正复杂的推理、编码或规划任务，才转给大型云端模型。这样既降低延迟，也把昂贵调用集中到刀刃上。但本地不是免费午餐：硬件需要预先购买，而高难度编程代理目前仍主要依赖云端大模型。混合执行不是过渡方案，而可能是长期结构。

被问到一支来自 VMware、Docker 和网络公司的团队如何适应 AI 工程时，Morgan 先指出了传统基础设施思维的边界。过去做系统，理想状态是每个组件按设计运行：代码被测试、验证，输入相同就应得到相同结果。这叫确定性。但 LLM 并不是这样的系统。同一句请求换一种表述、上下文多一段信息，输出就可能改变；这不是简单修一个 bug 就能消除的偏差。

Morgan 认为，AI 已经让一些十年前必须靠大量人力处理的问题，不再需要同样规模的团队。"there are just problems that you don't need to staff as heavily whereas you you you did 10 years ago"（有些问题已经不需要像 10 年前那样配备那么多人了。） 但人少了，不代表工程问题消失了。新的难题是：如何运营一种云服务，而没有任何工程师能完整解释系统里所有代码和模型行为为何如此。

这意味着团队的工作重心会变化。过去是靠人力覆盖确定流程；现在更要靠评测确定“什么输出可接受”，靠监控发现偏离，靠权限和约束限制模型能做什么，再通过反馈回路持续修正。工程组织不再承诺每个回答绝对正确，而要定义哪些错误可以容忍、哪些动作必须拦住、什么情况下必须交给人。Morgan 也承认，上一代 DevOps 和基础设施公司的不少经验已不适用，团队仍在重新学习该打破哪些旧规则。

被问到 Ollama 如何从 Kubernetes 和开发者安全方向转向本地大模型时，Morgan 给出的时间线并不光鲜。团队在 YC 2021 后，花了约两年摸索，先尝试 Kubernetes 安全，也尝试过桌面端开发者安全。那段时间最吓人的不是没有新闻，而是不断和客户沟通，却始终无法确认自己是否真的解决了某个强烈需求。

转折发生在多伦多的一次团队讨论。大家决定把旧想法全部放下，从头问一个问题：这支由前 VMware 和 Docker 人员组成的团队，究竟最擅长什么？答案不是安全销售，而是让复杂系统真正跑起来，并做出开发者愿意使用的体验。于是他们给自己设了一个极短期限："let's give ourselves two weeks to launch the first version of Llama"（让我们给自己两周时间，发布第一个 Llama 版本。） 两周期限将到时，Llama 2 正好发布，团队立即上线。Morgan 说，这次发布带来的用户数超过此前所有项目。

这意味着好的转向不是追着“AI”这个热词换赛道，而是把新技术机会和团队已有能力对齐，再用短周期验证用户会不会真正在乎。两周不是靠冲动取代判断，而是把“是否值得继续想”变成“能否拿到真实使用”。反面也很明确：Morgan 承认，他们本可以更早做这次自我审视；此前两年相当大一部分时间，是在过度思考客户和产品，却没有足够快地交付。

被问到中国来源开放模型的地缘政治风险时，Morgan 没有给出一个简单的“可以”或“不可以”。他接触到两类企业：一类主要关心模型运行在哪里、数据是否处于安全环境；另一类则明确在意模型训练来源、数据来源和模型表达方式。对前者来说，把模型放在受控环境里运行是第一优先级；对后者而言，模型来自哪里本身就是采购条件。

关键任务会把这个区别放大。Morgan 提到一个案例：有帖子称，Llama 被用于芬兰一座发电厂的分析系统，检测电涌并帮助维持供电。若模型参与这类任务，企业会更严肃地追问模型来源和供应链。大型企业其实早就在处理类似风险：一个普通应用可能有数千个开源依赖，任何一个依赖出问题，都可能引发重大安全事件。模型则更棘手，因为代码能逐行审阅，模型内部行为却更不透明。

当被追问是否存在已知模型被植入潜伏后门的案例时，Morgan 的回答是："I think not that I can think of off the top of my head. I haven't heard."（我一时想不到这样的案例，也没听说过。） 这不等于风险被证明不存在。它意味着企业不能只贴国别标签，也不能只看部署地点，而要把部署环境、模型筛查和供应链治理一起纳入决策。安全检查或许能筛掉大部分问题，但没人能给出彻底排除潜伏后门的办法。

被问到 Ollama 为什么能从本地模型爱好者迅速进入大量《财富》500 强企业时，Morgan 讲出了一个常被企业软件忽略的入口：一开始，开放模型的用户确实是自己搭环境、在家里折腾硬件的爱好者。但他们喜欢的特点——免费起步、可以在任意位置运行、马上能动手试——恰好也是企业 IT 开发团队最需要的特点。

传统企业软件通常先经过采购、预算、信息安全和许可审批，开发者想验证一个想法，往往先要跨过一连串流程。开放模型把这个顺序倒了过来。团队成员可以先在自己的环境中试用，确认模型能处理某类文档、某段代码或某个内部流程，再把实际需求带回组织。"they don't have to ask for permission to use it."（他们不必先申请许可，就可以使用它。）

LLM 的无状态特性也让这种迁移更容易。所谓无状态，是指一次调用不必天然绑定一套长期保存的用户数据；开发者可以先从相对轻的试验开始，而不一定先迁走整套核心系统。于是，原本服务爱好者的开发者体验，迅速变成企业内部扩散的通道。后续当然仍要补上云端容量、成本、安全和正式采购，但采用惯性已经形成。企业增长不一定先从销售合同开始，也可能先从一个开发者觉得“这个工具不用求人就能跑起来”开始。

“企业会把多数 token 交给开放模型，却未必把多数预算交出去”，和“Token 会变成廉价原料，状态、协调与执行才是新瓶颈”，说的其实是同一件事：模型本身会越来越像电力或带宽，消耗量很大，却不必是利润最厚的那一层。真正困难的是让这些 token 知道该读什么数据、能调用什么工具、何时切换模型、出了错由谁接管。

“本地与云端不会二选一，路由器将按任务难度分工”进一步说明，企业不会靠采购某个最强模型解决一切。它需要的是任务分流能力；而“模型首发的胜负不在权重，而在发布当天能否跑成产品”说明，即便模型能力到了，运行时、容量、硬件和接口没有接好，用户也得不到能力。

如果你正在做 AI 产品，真正该盘点的未必是“还能接入哪个新模型”，而是自己的工作流里哪些环节需要记忆，哪些环节需要权限，哪些任务可留在本地，哪些失败必须被拦截。模型会持续变化，价格会继续下降；留在你手里的，是把这些不断变化的模型可靠接入真实工作的能力。