第一次看到”一边在造原子弹，一边在造蒸汽机”这个说法时，我把它当修辞。后来对着几件具体的事想了想，发现它确实能解释一些东西——为什么两边的架构选择不一样，为什么定价差那么多，为什么同一句”支持长上下文”在两边含义不同。
但它也有解释不了的地方，而且那部分恰好是最容易被讲成口号的部分。
这个比喻成立的部分
原子弹的特点是：固定投入极高，成功只需要一次，收益是威慑。蒸汽机的特点是：单台不稀奇，价值在于铺开，收益是渗透率。
对应到模型上，一条路是把能力推到前沿，然后靠”只有我有”收租；另一条路是把能力做便宜，然后靠”到处都有”收租。前者的护城河是时间差，后者的护城河是成本和渠道。
我更在意的是另一个差别：原子弹只需要成功一次，蒸汽机必须可靠运行十年。后者的难点不在突破，在维护。落到 AI 上，这个差别对应的不是”能不能刷榜”，是”能不能稳定交付”。一个模型在评测里赢两分，和一个模型在半年里不出事故，是两种完全不同的能力，而后者更难被写进新闻。
发布讲的是突破，工程讲的是不出事。两边的语言不一样，所以经常互相听不懂。
不过我不同意把这个比喻推到”零和”上。原子弹是零和的，你有我就没有；模型能力的扩散不是严格零和。用军备竞赛的框架去看，会系统性地高估对抗、低估应用层的空间。我这几年看到的实际变化，大部分发生在应用层，而不是在榜单上。
组织方式也不一样，这一点比技术差异更根本。一个是项目制：集中资源、明确目标、一个截止日期。一个是产业制：无数小团队各自试错，靠市场筛选。项目制擅长攻克单点，产业制擅长把成本压下来。两种组织在同一条赛道上竞争，短期的结果和长期的趋势往往相反，这也是各种预测互相对不上的原因之一。
对我来说，这个框架真正有用的地方不是判断谁赢，而是提醒我”哪些结论是从哪条路推出来的”。前沿能力的数据通常来自封闭评测，成本数据通常来自公开定价，两者不在同一个尺度上。把一组榜单分数和一列价格放在同一张表里比较，看着整齐，实际上是把两套语言混用了。
被算力逼出来的工程能力
算力受限会塑造工程，这一点我有切身体会。
拿不到足够多的卡，就只能从架构上找空间：稀疏激活、注意力机制的压缩、预填充和解码拆开跑、KV 缓存池化复用、按流量潮汐调度。这些做法单个看都是省钱的技巧，合起来是一套系统能力。
关键在于，这套能力是可以迁移的。模型会换代，参数会重训，但”怎么在有限显存里把吞吐榨出来”这件事的经验不会过期。我甚至觉得，它比某一次模型突破更值钱，因为它决定了未来所有模型的单位成本。
我自己的项目里有过类似的经验。显存不够的时候，我第一反应不再是换卡，而是看 batch 怎么排、缓存命中了多少、有没有重复计算。这个思维一旦形成，会一直用下去，而且换个场景也成立。约束会让人变聪明，也会让人变偏执——我现在有时候会花两小时优化一个本来只需要跑一次的脚本，这就是偏执的那一面。
代价要说清楚。走这条路意味着：部署更复杂，调优周期更长，文档更少，踩坑时没人陪着。开源生态的好处是有对照、可以自己改；坏处是没有人为你的故障负责。出了问题，在 issue 区翻半天，最后发现是某个版本的依赖不兼容。
还有一个很现实的麻烦：异构。手上有什么卡就得用什么卡，版本、驱动、通信库各不相同，一套配置在 A 机房能跑，到 B 机房就要重调。这种工作在文章里不出现，但它占掉了工程团队很大一块时间。相比之下，”买最先进的卡，用统一的集群”是一种奢侈——它不只是贵，是省掉了整整一类问题。
还有一个反直觉的点。稀疏架构让小硬件也能跑大模型，但它同时让”这一次激活了哪些专家”变得不可预测。同一个输入，两次运行的路径可能不同，出了问题很难复现。省下来的算力，有一部分又还给了调试时间。这笔账很少有人算。
端侧是这条路的延伸，也是我最愿意花时间的方向。把模型量化、跑到笔记本上，这件事的价值不在性能，在可用性：不联网、不按次付费、数据不出机器。代价是能力打折，而且打折的位置不可控——有些任务几乎无损，有些任务明显退化，靠试才知道。我做过一个本地文档问答的小工具，量化之后速度可接受，但它在需要跨段落推理的问题上错得很稳定，那种错不是随机噪声，是有规律的偏差，反而更难处理。
价格差是结果，不是策略
同一档能力，两边的单价能差一到两个数量级。这个差距不是单纯的补贴，是架构、规模、竞争三件事共同作用的结果。把它理解成”烧钱换市场”，会得出一个错误结论：补贴停了价格就会回去。实际上架构带来的成本优势是结构性的，不会因为补贴退出而消失。
但价格对商业模型的影响是不对称的。
对话型产品对单价不敏感。一个人一天问二十个问题，差价可以忽略。agent 型产品是按流量烧 token 的：一个常驻流程每天跑几千次调用，单价直接决定这个生意成不成立。所以同一份价目表，在两种产品里的意义完全不同。这也是为什么”便宜”这件事在 agent 时代突然变得重要——不是因为大家变穷了，是因为用法变了。
我不喜欢”十分之一的价格等于十分之一的能力”这种换算。真实分布更像是：大部分任务两边都够用，少数任务只有贵的那个能过。如果这个分布成立，那么理性的做法不是选边，是分级——把能过的任务交给便宜的，把过不去的留给贵的。
混合路由听起来很聪明，但它有自己的成本：两套供应商、两套评测、两套合规、两套限流和重试策略。小团队养不起这个复杂度。我见过为了省 token 反而多搭了一套基础设施的例子，最后总成本更高，还多了一个会出故障的环节。
还有一层不太被提：低价会改变使用习惯。当单价低到可以忽略，人的默认策略会变成”先跑一遍看看”，成本意识被推迟到账单来了才有。这在探索阶段是好事，在生产阶段是隐患。我自己就吃过这个亏，一个每天跑几十次的小任务，一个月下来比我预期高了一个数量级。
站在做产品的人这边，价格差的另一个影响是定价锚。如果我按贵的那个成本定售价，利润空间很薄；换成便宜的，同样的售价就有了余量。但一旦我按便宜的定价，以后想换回贵的那条路，就得涨价，而涨价比一开始定价贵更难。所以这个选择看起来是技术选型，实际是商业承诺。我现在的做法是把模型调用包在接口后面，对外只说能力和延迟，不说用的是谁——保留将来换的可能，代价是要多写一层适配。
成本落在谁头上
这是我认为最值得想的一层。
闭源高价的模式，成本落在调用方。好处是责任也在供应商：模型出问题、服务中断、合规要求变化，都有人兜。坏处是长尾场景做不起来，因为对那些场景来说，调用成本超过了它能创造的利润。
开源低价的模式，成本转移到部署方和维护方。模型权重是免费的，但推理质量、安全加固、合规评估、版本升级，全都归自己。这笔钱不出现在价目表上，它出现在工程团队的人天里。
开源不是把成本消灭了，是把成本从账单挪到了工资单。
我倾向后者，因为我愿意用工程时间换确定性，而且我恰好有这个能力。但这是一个偏好，不是一个普适建议。对一个没有工程团队的公司，开源自部署的总成本大概率高于直接买 API，尤其是把故障时间算进去之后。这一点在讨论里经常被忽略，因为”免费”是一个太好传播的词。
合规是这笔账里最容易被低估的一项。数据放在哪个司法辖区、日志保留多久、模型会不会把输入用于训练，这些问题在买 API 的时候由供应商回答，自部署的时候由自己回答。回答它们不需要写代码，但需要时间和判断，而且答错了代价很大。我见过团队把开源模型直接接上用户数据，跑了几个月才想起来问一句”我们的隐私政策允许这样吗”。
对个人开发者来说，可选的生态位其实很清楚：不做预训练，做路由、做端侧、做具体场景。把几个模型拼起来解决一个真实问题，比训练一个模型现实得多。这不是退而求其次，这是分工。
具体到选型，我现在只看三个变量：单次任务成本、失败时的可诊断性、以及换供应商要花多久。第一个决定能不能跑量，第二个决定我半夜会不会被叫起来，第三个决定我明年还能不能谈价格。能力排在第四，因为在前三个都过关之后，能力的差距通常已经不是瓶颈了。
我不认为这两条路会有一方赢。它们会在”够用”这条线上相遇，而”够用”的位置每年都在上移。我在看两个东西：单位 token 的成本曲线，以及长上下文下检索质量的衰减速度。前者决定应用能铺多宽，后者决定应用能做多深。
这两个数我都没有把握。可能明年这个时候，我的判断会被推翻一半。到时候我更愿意承认自己算错了，而不是把新的事实解释进旧框架里——这是我写这类东西时唯一给自己定的规矩。
比喻只是脚手架，拆掉之后留下的应该是对具体机制的判断，而不是一句更顺口的结论。
评论