成本陷阱（上）：开源模型的蜜糖，Token工厂的砒霜！

模型开源了，权重免费了，论文全公开了——那为什么云厂商部署出来的成本，还是原厂的三倍？

我拿2026年6月的真实定价算了一笔账：月收入60万的MaaS服务，月成本194万。用户越多，亏得越多。这不是经营不善，是数学上就不成立。

这篇文章拆的就是这件事：钱到底亏在了哪里，以及为什么开源解决不了它。

一、开源的是“图纸”，不是“工厂”

DeepSeek创始人梁文锋在一次内部交流中说过这样一段话：

“哪怕模型开源了，所有原理都公开了，别人要用起来门槛依然非常高，要把成本做到同样低更是难上加难。并不是我开源了，别人就能轻易做到跟我一样的部署成本。”

他给出了一个财务锚点：DeepSeek的API定价按"十个月收回设备采购成本"来设定。如果第三方拿开源模型自行部署，成本可能是原厂的几倍甚至二十倍。

作为智算云计费系统的设计者，我对此深有感触。在云厂商内部，我们看报价单的方式和客户完全不同——客户看到的是"H800 2美元/小时"，我们看到的是"这张卡在不同推理框架下的有效产出是多少token/秒，单位token的固定成本和边际成本分别多少，闲置率吃掉了多少毛利"。

这句话翻译成云计算从业者熟悉的语言就是：开源发布的是"图纸"，不是"工厂"。你拿到了图纸（模型权重+架构论文），但图纸不会自动变成一座高效运转的工厂（推理服务）。从图纸到工厂之间，隔着一整套深度的工程能力。

一份代码，不同团队部署出来的性能和成本可以差几倍。大模型推理把这个差距进一步放大了——因为它的优化深度，远超传统软件。

那差距到底卡在哪？很多人第一反应是"算力不够"。其实不是。

二、钱到底花在了哪里？

先说一个反直觉的结论：大模型推理最大的瓶颈不是计算能力（FLOPS），而是显存（GPU Memory）。

大模型在生成每一个词的时候，需要记住之前所有的对话上下文，这些"记忆"数据称为KV缓存。随着对话变长、并发用户增多，KV缓存会占满GPU显存，成为限制吞吐量的第一道墙。

这意味着，推理成本优化的核心不是"算得更快"，而是"在有限显存里塞下更多并发、更长的上下文"。谁能更高效地利用每一字节显存，谁的成本就更低。

从计费视角看：云厂商按token计费，但成本端是按GPU时间计费。中间的转换公式是：

每百万token成本 = GPU小时单价 ÷ GPU小时产出token数 × 1,000,000

GPU小时产出token数（即吞吐量）越高，单位token成本越低。而吞吐量的上限，往往不是算力卡住的，而是显存卡住的。这就是为什么显存利用效率直接决定了你的成本竞争力。

原厂通过模型架构创新和全栈工程优化，在这道墙上开了好几扇门。但云厂商拿到开源模型后，这些门并非自动敞开——它们需要配套的"钥匙"（底层工程能力）才能真正打开。

那云厂商到底在哪些环节"丢了钥匙"？我把它拆成四笔账来算。

三、四笔账：云厂商的钱亏在哪

损失一：显存压缩的红利大打折扣

DeepSeek在模型架构上做了一个关键创新：把对话记忆压缩成极小的摘要再存储，显存占用直接降低93%。这是它成本低的第一个秘密。

模型权重开源了，压缩机制也在权重里。但问题是：要真正享受这个红利，推理引擎必须能直接在压缩状态下计算——不是解压后再处理，而是“带着压缩包直接干活”。这需要深度定制的底层程序。

这里需要理解两个概念：

• 推理框架：把模型权重变成可调用API的中间层软件，类似“数据库引擎”——同样的数据，不同引擎速度差几倍。主流的两个是vLLM（使用最广）和SGLang（DeepSeek官方推荐）。
• 算子（Kernel）：GPU上的底层计算程序，类似“专用指令”。原厂为特定模型手写专用算子，通用框架用标准库的通用算子，两者性能可以差数倍。

通用框架虽然已经支持了这套压缩机制，但有三个现实问题：硬件适配不全（只在最新GPU上效果好，混合集群上大打折扣）、精度支持不完整（FP8支持缺失导致显存消耗翻倍）、数据布局复杂（底层程序需完全重写）。结果就是：93%的压缩红利，实际能拿到的约为一半。

翻译成钱：同样一张H800，原厂每小时产出约5500万token，通用框架只有2800万-3800万（约为原厂的50%-70%）。仅此一项，单位token成本就贵了40%-100%。

损失二：稀疏计算的通信开销吃掉性能红利

原厂做了什么？

DeepSeek V3总参数671B，但每个词只需要激活其中37B的参数来计算。这相当于一个6710亿参数的"超级大脑"，每次思考只动用370亿的"神经元"。这是其成本低的关键所在。

但问题是：这37B的参数不是集中在一个地方的。模型包含256个"专家"（Expert），分布在多个GPU、多个服务器节点上。每处理一个词，都需要把数据发送到对应的专家所在的GPU上，算完再收回来。这个操作称为All-to-All通信，模型的每一层都要执行一次。

用一个比喻来理解：

想象一家有256个专科医生的超级医院，分布在多栋楼里。每个病人来了，分诊台判断需要哪8位医生会诊，然后病人的病历必须被打印多份，分别送到这些医生所在的楼。医生看完后，诊断结果还要汇总回来。这个"送病历"和"收诊断"的过程，就是All-to-All通信——而它是每一层、每一个词都要做的。

原厂自己的数据显示：在最好的数据中心网络条件下（400G InfiniBand），仅"送病历"这个动作，就将每生成一个词的时间锁定在约15毫秒。在没有任何计算的情况下，速度上限就被通信卡死了。

云厂商为什么损失更大？

原厂为了把这个通信开销压到最低，自研了一套专门的通信库（DeepEP），做了三件通用框架做不到的事：

1. 通信不占用GPU计算资源。通用框架的通信操作会占用GPU的计算单元，导致"一边通信一边干不了活"。原厂用了一种特殊机制，让通信完全不占GPU计算资源，真正实现"边搬数据边算"。

2. 数据传输直接用压缩格式。原厂在传输数据时直接用FP8格式（1字节），而通用框架通常用BF16格式（2字节），通信量直接多一倍。

3. 动态平衡专家负载。模型的路由是自动学习出来的，有些"热门专家"会被频繁调用，导致持有该专家的GPU忙不过来，其他GPU只能干等。原厂做了实时监控加动态迁移，把热门专家复制到空闲GPU上。通用框架用静态分配，面对负载不均衡无能为力。

此外还有一个规模门槛。原厂的生产系统使用144路专家并行，需要数百张高速互联的GPU。中小云厂商没有这个规模——GPU越少，跨节点通信占比越高，效率越低。

实际影响与成本换算：业界用"效率系数η"来衡量这个差距——原厂η≈0.7-0.9（跑出了同等计算量密集模型70%-90%的速度），通用框架朴素部署η≈0.3。这相当于671B只激活37B的模型，实际吞吐只相当于一个10B密集模型——稀疏激活的收益被通信吃掉了70%。换算成月度账单：如果你本期望用671B模型的"37B计算成本"来定价，实际付出的GPU成本是预期的3倍以上。

损失三：GPU资源利用率天然偏低

原厂做了什么？

原厂有一个云厂商无法复制的运营策略：白天全部GPU做推理服务，夜间降速后释放一部分GPU做训练和研究。这种"推理-训练混部"模式将GPU利用率从行业典型的50%拉到接近100%。

云厂商为什么做不到？

云厂商的MaaS（模型即服务）需要7×24小时保持推理可用。为了应对流量峰值（比如白天办公时间的请求高峰），必须预留大量冗余GPU。夜间流量低谷时，这些GPU闲置但仍在计费。

从计费系统设计角度：这是我们设计"按量计费"和"资源包"时最头疼的问题——客户按token付费（收入端波动），我们按GPU时间付费（成本端固定）。GPU利用率55%意味着45%的时间GPU在"吃空饷"，这45%的成本没有对应的收入来覆盖。资源包的本质是让客户承诺消费量来对赌这个闲置风险，但MaaS场景下流量波动大，客户也不愿意签长期承诺。

实际影响：云厂商的GPU利用率通常只有50%-60%，意味着单位token的固定成本是原厂的1.7-2倍。

损失四：推理效率以外的隐性成本

除了上述技术层面的损失，云厂商作为服务提供商，还需承担原厂不需要的额外成本：

这些隐性成本通常占GPU租赁成本的15%-20%。说句大实话：这部分成本在报价单上是看不到的，但会实打实地吃进你的毛利里。大云厂商通过规模效应摊薄这些固定成本，中小厂商的占比只会更高。

四笔账算完了。技术层面的损失加上隐性成本，叠加起来是什么概念？我拿2026年6月的真实定价，算了一笔完整的账。

四、一笔完整的账：月亏134万

当前市场定价

2026年6月，主流平台对开源大模型系列API的定价（每百万Token，人民币）：

从定价策略角度：主流云厂商的定价被原厂锚定了——这是典型的"价格跟随者"困境。卖得比原厂贵，客户直接找原厂；卖得和原厂一样，但自己的成本是原厂的好几倍。原厂是"价格领导者"，它把价格定在了"十个月回本"的水平——这个水平对它自己是有利润的，对部署方是亏本的。这就是定价权的本质：不是你的成本决定你的价格，而是你的效率决定你能不能在原厂的价格下活下来。

盈亏推算

假设一个MaaS服务商日均处理100亿输出token，按原厂经济版定价收费（输入收入暂不计入，仅算输出）：

月收入= 100亿 ÷ 100万 × 2元 × 30天 =60万元

月成本（云厂商，使用通用框架，GPU利用率55%）：

GPU数量推算：100亿为输出token，叠加输入token（通常为输出的4倍左右），日实际处理约500亿token。通用框架单卡吞吐约3300万token/小时（约为原厂的50%-70%），按55%利用率折算，单卡日有效产出约4.4亿token。500亿 ÷ 4.4亿 ≈ 114张，再考虑流量峰值冗余和多副本高可用，实际需约160张H800。

月亏损 = 60万 - 194万 = -134万元

毛利率 = (60万 - 194万) / 60万 = -223%

这就是行业里常说的"用户越多亏损越多"——每多服务一个token，就多亏一份钱。除非推理效率能逼近原厂，否则纯API转售在数学上不可能盈利。

已有中小MaaS服务商因持续亏损而宣布停止相关API服务。这不是个案，而是商业模式的系统性问题。

账算到这儿，结论已经很残酷了。那大家是怎么活的？我观察下来，大致是三种活法。

五、三种活法

大型云厂商：交叉补贴，长期布局

阿里云、腾讯云、华为云等头部厂商的策略不是靠MaaS本身赚钱，而是将其作为生态入口：

• 阿里云：宣布未来三年投入3800亿用于云和AI基础设施，MaaS是带动IaaS/PaaS销售的流量入口
• 腾讯云：将开源模型接入微信等国民级应用，带动整体云推理算力需求
• 华为云：从昇腾芯片到模型到应用的国产全栈方案，核心诉求是国产替代的战略卡位

这些厂商可以承受MaaS业务的长期亏损，因为整体云生态的收益远大于推理业务的亏损。但这本质上是用其他业务的利润补贴推理的亏损——推理本身的成本效率并未改善，只是亏损被转移了。从计费系统设计角度，大厂的做法是"用IaaS的高毛利覆盖MaaS的负毛利"，整体账户层面算总账。中小厂商没有这个"总账"可以算。

中型智算云厂商：卖算力而非卖Token

以九章智算云（DataCanvas）、无问芯穹（Infinigence AI）为代表的中型厂商，选择了不同的路线——不碰模型推理优化，只卖算力和调度能力：

• 核心产品是"算力包"或"推理算力池"，按自定义单位计费（如九章的"度"/DCU，H800低至9元/度套餐价）
• 用户拿到的是裸算力或容器化算力，自行部署模型
• 主打Serverless弹性架构，任务秒级启动，仅对有效计算时间收费
• 重点布局垂直场景（强化学习云、行业专网等），避开大规模Token推理的红海

核心逻辑：不承担推理效率优化的技术风险，也不承担Token定价的商业风险。赚的是算力资源的批零差价和调度溢价。这是一种"我不碰你的蛋糕，你也别来抢我的"的防守策略。

风险：当大云厂商通过MaaS补贴变相拉低算力市场价格时，定价空间被挤压。出路在于向更高附加值的AI基础设施服务转型。

小型平台型厂商：做分发和聚合

以硅基流动（SiliconFlow）、模力方舟（MoArk）为代表的平台型厂商，定位更接近"模型聚合与分发层"：

• 聚合大量开源模型（硅基流动覆盖主流开源模型全线，模力方舟聚合2万+模型兼容HuggingFace生态），用户一键调用
• 提供Serverless API，开发者无需关心底层GPU，绑定令牌即可上架应用
• 部分厂商延伸至边缘推理硬件（如模力方舟698元PocketClaw），面向个人开发者

核心逻辑：不自建大规模GPU集群，做"模型分发层"，聚合上游算力，赚API调用差价和开发者生态。

风险：API质量完全依赖上游算力供应商，当上游（原厂或大云厂商）持续降价时，中间层利润被持续挤压。

三类厂商对比

六、开源到底改变了什么

分析了这么多技术细节和商业案例，我想把结论收束到一个最本质的问题上——开源到底改变了什么，没改变什么？

开源降低了：

• 模型获取成本——不需要自己花数亿元从头训练
• 算法理解门槛——架构和原理完全公开
• 行业整体技术水位——拉齐了所有人的认知起点

开源没有降低：

• 推理服务的工程成本——底层算子优化、通信库开发、调度系统建设
• 规模化运营的效率——GPU利用率、资源混部能力
• 硬件协同设计的深度——从模型架构到芯片特性的全栈优化

一句话概括：开源传递的是"知识"，不是"能力"。知识可以被复制，但将知识转化为极致工程实践的系统性能力——底层程序开发、通信优化、资源调度、全栈协同——无法通过开源传递。这正是原厂信心的来源，也是云厂商在部署开源大模型时始终无法获得成本优势的根本原因。

结语

说到底，梁文峰那句话戳破了一个行业幻觉：在AI时代，基础设施的竞争已经从"有没有算力"升级为"能不能把算力用到极致"。开源让模型不再是壁垒，但把模型变成高效推理服务的工程能力——从底层算子到通信库，从调度系统到资源混部——成了新的、更难跨越的壁垒。

对云厂商来说，现实很骨感：仅仅"部署"开源模型是不够的。做不到推理全链路的深度优化，就始终处于成本劣势，无论模型本身是否免费。

我自己的判断是：MaaS纯API转售这条路，对绝大多数中小厂商走不通。要么你有能力做到原厂70%以上的推理效率（这需要数千万级的工程投入），要么你找到"API以外的收入"来覆盖推理亏损。两者之间，没有中间地带。

那如果真下决心投入深度优化，能追平原厂多少？具体有哪些举措？这就是下一篇要回答的问题。

下一篇预告：《砸钱优化，能追平原厂吗？》

关注本系列，下篇继续拆。觉得有用的话，转发给你身边正在做大模型部署决策的朋友。

文中数据基于2026年公开信息整理，技术迭代很快，具体数字请以各平台最新披露为准。欢迎同行交流拍砖。