01：引子
最近一位推理Infra大佬给我爆料：
某大模型厂商推理是弱项，
做得不行，
现在，连算法同学都调去搞推理了，
比起，DeepSeek，Kimi，
该厂商的推理技术水平，差远了。
这则爆料，有个反常识的点：
算法同学一向是镁光下的C位，
怎么现在，把这批最贵的脑力，
成建制地调去做推理？
我还拿到一则爆料：
大模型厂商创始人多次，
亲自面试一位大厂infra大佬，
开出一千万的年薪，是不是很昂贵？
可别说，这位infra大佬一旦去了，
能给他们省下亿元的成本，
这么算，是不是又划算了。
于是，大模型厂商创始人即便是三顾茅庐，
也是分内之事。
有关推理系统的一切，没有秘密，
目的就是降“单位Token成本”。
说到底，推理的成本，
就是"用了多少GPU小时"，
除以"吐了多少token"。
同一套推理系统，可以跑在线推理，
也可以跑离线推理；
区别在于它们追求不同，
最看重的指标不同。
我理解，离线推理像任务侧就分好批了，
不是系统来干，
不过，离线推理难在"规模"，
比如一个搜索公司，
要把几十亿网页，上亿篇文档，
全部重新生成Embedding，
因为模型升级了。
这时候没有用户在等，
但是数据量如此之大，
GPU更要一直保持高利用率。
而且推理还有个特点：
对比上层模型结构，数年争论不休，
工程上的基础技术手段，
争论较少，共识颇多。
而熟悉推理这一层都知道，
这里可不是大放阙词之地，
因为差之毫厘，谬以千金。
DeepSeek那样做，
Kimi这样做，阿里这样做，
其他推理团队肯定也会快速跟上，
又是一个没有魔法，
全靠倾尽心血的故事。
放眼望去，训练的折旧还要数年才能消化，
而推理成本的酣战已经打响。
训练是大赌注，大消耗，大手笔；
而推理是精细战，是巷战，
他们是要在每条马路，
每个路口，每个街角，都打个漂亮仗。
02：DeepSeek掀起了价格战
DeepSeek在2026年7月初，
宣布高峰涨价，
高盛将此解读为，
自2026年4月底以来，
中国AI模型公司部分玩家毛利率为零，
甚至为负的激进定价，
开始正在向更理性阶段过渡的早期信号。
而自研AI推理芯片的计划，甚嚣尘上；
竞争没有退潮，只是换了个维度。
DeepSeek在推理届一哥的地位，
就不用介绍了。
它做了两件事，
把整个市场的定价钉死了。
一是模型效果够用，
在大多数常见任务上，
它已经好到让多数人觉得"够了"，
二是价格极低，
还公开了自己很高的成本利润率，
这等于告诉所有人：
我有能力做到这个价，还赚钱，不赔本。
这两件事合起来，
就在市场上打下一个锚点：
你的模型如果只比DeepSeek强一点点，
用户不愿为那一点点多掏高价的钱，
你就没法定高价，
只能贴着它的低价走。
若想在同一个价位竞争，
你就得跟它的技术能力一样，
在这个价位有手法赚钱。
而这，取决于你的推理成本，
能不能压到和它一样低。
于是，对模型厂商，
活下去要两条腿：
模型效果能压过对手（你得上桌子），
推理成本足够低（在价格战里扛得住）。
对云厂商也一样：
云上挂的那几个模型要领先头部，
推理业务本身要高利润。
无论哪种，都收敛到一句话，
压低推理成本这一件事，
决定了产品竞争力和业务利润。
背后取决于你的技术水平。
既然DeepSeek把全市场的调子，
起得这么高，
那现在推理到底在卷什么呢？
要我说：推理的工作，难啃，又值钱。
在一堆互相牵制的东西之间，反复权衡，
找“最优”，紧贴变化，再找“最优”。
最后还别忘了，
场景不同需求也不同。
真正优秀的推理系统，
不是单纯把某一个指标做到极致，
而是根据业务需求，
比如，延迟低，
意味着这一次决策马上就能做出来。
自动驾驶就是，
驾驶必须立即有结果，
慢吞吞吐出的token再多也没有用，
车都撞了。
百度云Infra大佬给我说了个GDP的比喻，
推理成本降1%，
更像GDP降1%，数字巨大。
你把单位成本优化1%，
乘上全部调用量，是一笔巨款。
在别的生意里，
1%的优化可能淹没看不见，
在推理里，这1%就是赚的。
这样看来，把算法同学调去搞推理，
不是大材小用。
重金招兵买马Infra专家，
也是物有所值。
是把最贵的脑力，最强的经验，
投到利润线上。
另外，大佬们似乎有口皆碑，
Deepseek已经成为，
所有AI infra优化的基准。
03：token成本“告别”传统软件成本
看上去，推理的开销是随调用量滚动，
永不停止的边际成本。
当今年Agent类应用的火爆，
立刻把单位时间的token消耗，
推高一个量级，
这笔成本就从财务上的一个科目，
变成了决定一家公司能不能盈利的结构性变量。
所以，不能只谈技术，不谈钱。
以前，企业大了，吃规模效应。
在很多年以前，
传统软件是个好生意，毛利高，
因为服务多一个客户几乎不多花成本。
在一定的规模内，
多一个人用淘宝买东西，
阿里成本会高吗？
在没有到规模拐点的时候，并不会。
回看当年阿里的技术支持淘宝和天猫，
本质是是技术服务业务。
而今不同，旧玩法失效了：
技术不再是业务背后的支撑，
技术本身就是业务的胜负手。
回想早年微博、淘宝的黄金增长期：
硬件投入翻倍，能换来几十倍几百倍，
甚至上万倍的客户增量。
原来，规模本身就是利润。
然而，世界变了，
推理把这个规律打破了，好事没有了。
多服务一个用户，
就多烧一份GPU。
所以，推理业务的毛利，
不由用户数量决定，
由单位token成本决定。
等等，这个说法也不完全对。
我也犯了互联网惯性思维的错误。
假如我有一个智能体，
我让智能体一秒问100万个问题，
用户数量还是我一个。
上面说法的毛病在哪？
"用户"这个词它衡量不了推理的真实负担。
"用户数量"根本不是那个和成本挂钩的量。
那和什么挂钩？
1个用户在聊天，肯定吃不满这张卡，
100个人同时在聊天，
GPU把这100个请求，
凑成一批（batch）一起算。
搬一次权重服务的越多越好。
所以，从1个用户加到100个用户，
并不需要100倍的时间，
而且，搬运成本被这100个人摊薄了。
整机产出变成了每个用户慢一点。
但是，我们还是用用户的角度来理解，
这样方便对比，
服务一万人要这么多GPU，
服务十万人就要差不多十倍的GPU，
用户翻十倍，
成本大体也翻十倍。
因为每一个token都是实打实的一次计算，
发现难点了吧？
有的成本干不掉，摊不薄。
你没法像传统互联网那样靠规模出利润，
也就是，你能赚多少，
是token成本被压到多少。
于是唯一的活路，靠技术硬生生向下压。
传统互联网APP的故事已经翻篇，
那么token成本的故事是什么？
我们往深聊。
04：回到物理层面
为了找答案，
这就要回到推理最底层的物理事实。
推理其实是两件事，
我建议不用细究这两件事情，
更重要的是，干这两件事所需要的资源，
正好相反。
或者说，推理对付的，
是两种完全不同的工作负载，
却要共用同一套硬件。
一旦一个系统里同时住着两个需求相反的东西，
麻烦就是结构性的，很难彻底干掉。
一个infra的技术小哥哥给我这样吐槽：
“推理糟心事儿很多。
这个调大了，那个变差了；
这里节省了，那里又变差；
前面拆开了，后面又有新麻烦了。”
吐槽很生动，麻烦反应本质，
这不是工程没做好。
有个俗语：按下葫芦浮起瓢。
你为其中一个调优，
几乎必然动到另一个。
既然是前和后（prefill和decode），
两部分组成的。
你想让前面的（prefill）快，
就得给它更多算力，
让它尽情爆发，可它一爆发就占满了卡，
后面那部分（decode）就被挤得吐字卡顿，
像是你满足一个，就得罪另一个。
你把两个拆开想各自解决，
拆开这个动作本身又造出新麻烦。
这正是PD分离的处境：
你为了不让二者互相拖累，
把它们拆到不同的卡上，
这一步确实解开了老矛盾，
但拆开后，
前面算出的东西要跨机器传给后者，
凭空多出一笔传输和一层新的调度。
怎么理解前面那部分（prefill）呢？
它的本质是一次性的算力大爆发，
阿里infra大佬的说法是，
prefill更像训练，对算力要求高。
对付它就把进来的多条请求并行算完，
这一看就是吃算力。
怎么理解后面那部分（decode）呢？
怕等，更怕带宽跟不上。
对了，还有一笔账要记：
decode每一步除了搬权重，
还要搬到目前为止全部的KVcache。
KVCache小的时候，不着急，
但一旦长，就有新麻烦。
后面会介绍搞定这个麻烦的思路，
简而言之，推理这行，
是边发展边长出打法的。
打法总会形成共识，
谁先把东西做出来，
做到最好，谁就最牛。
05：推理是一个多主角的舞台
原本，只需要一个推理引擎层，
请求进来，模型算一遍，吐一个字，
再接回去继续算，再吐一个。
前面的中间结果，
每一圈都在被反复使用。
推理引擎是这个圈的管理者和执行者。
一个引擎内部有它自己的排队和拼批：
请求进来怎么排队？
谁跟谁拼一批？
显存满了怎么取舍？
这些都是这一个引擎内部的事，
它自己有全部信息，也有权决定。
之前能管好，但摊子大到，
要堆很多个引擎副本时，
冒出一类新问题，
而这类问题任何单个的都解决不了。
因为它只看得见自己，看不见别人。
这时候就需要往上增加一层，
也就是集群的调度层。
它和引擎内部那种安排不是一回事：
前者管一个引擎里面，
它管的是一堆引擎之间。
它的本质盯着两边，
一边是不断涌进来的请求，
一边是手里的集群。
把请求和机器做最优匹配，
凑成最划算的搭配。
也就是把请求合理的分配和拼接。
由它决定请求先后顺序，优先级等，
也就是谁先谁后，
谁跟谁拼一批，派给哪台，
是马上处理还是等一等，
都是为了同一个目的：
让机器别闲着也别堵着，尽量满载干活。
好的，其实这章讲了两层，
推理引擎层和集群调度层，
不过还有一层没有讲，
那就是KVcache。
06：KV Cache就是为了“复用”
KVcache这堆东西又贵，
又占地方，又不能不留。
引擎是"用它"，调度是"绕着它安排"。
那它自己凭什么还要单独成一层?
为什么不能就是引擎里的一块内存，
随便存存算了?
答案是：因为这堆东西，
已经足够大，足够复杂，
且要很多方共享，
"随便存存"谈何容易，
必须有一套专门的机制去管它。
它大到装不下，必须跨越好几种存储，
它分层存储，就需要专门一层去管。
而且更重要的是，
KV cache不只服务一个请求，
一个引擎，
共用的东西，
不能单独塞到任何一个引擎里面去，
必须抽出来做成公共底座。
谁都要用它，谁都不能独占它，
那它就只能自己站成一层。
整个KVcache层的目的倒也简单，
说人话，就是"存它"。
虽然KVcache层的逻辑是为了“复用”，
但是，它毕竟是个存储层。
把算过的中间结果存下来，
在有限的地方里，
把这堆KVcache挪来挪去，
尽量放到最划算的位置（存储），
而且当下KVcache显存占用，
动不动就超过模型权重本身。
所以，也有理解是，
在“长上下文，高并发，多轮agentic"，
这个特定场景下，
整个推理系统才围着KVcache转。
写到这里突然想起来Kimi的一篇文章，
在特定场景里，这个金句已经是共识了。
不过，对短输入，prefill重的负载，
KV cache根本不是主角，
或者这么说，KV cache是推理故事中，
一条支线的主角，
但不是整台戏的唯一主角，但戏份够重。
再看看其他的技术观点：
美国Digitalocean云平台，
有位Staff Engineer大佬的观点认为，
推理有个困境，
是吞吐量、延迟和成本之间的三难困境。
提高吞吐量，延迟就会增加；
降低延迟，GPU成本就会飙升；
你试图优化成本，
又不得不在吞吐量和延迟之间做出妥协。
三难困境不存在一劳永逸的解法，
而是一种持续的权衡。
你做出的每一个选择都会改变这三者之间的平衡，
并不存在放之四海的“完美”方案。
也有专家告诉我，
把可调的“推理旋钮”总结为四个：
硬件、模型、数值精度、调度与批量大小；
甚至核心难题也被专家们概括得明明白白：
选哪个模型、用什么精度、配哪种卡、
一次凑多少请求一起算。
凑得多，整机吞吐高、单位成本低，
但用户要和更多请求抢资源，延迟可能变大；
凑得少，响应快、体验好，
但资源利用差、成本高。
归根结底，这就是工程上的权衡。
至于所谓的“Token成本”，
它的本质不是单一指标，
而是一个多维度的复合指标。
07：推理集群对网络的核心诉求是什么？
阿里云基础设施团队的技术大佬，
是这样回答我的：
两方面，跨机EP的流量和KV cache的流量；
还有就是，这两种流量混跑的时候，
会不会互相干扰，
这也是很关键的。
看上去，如果只有两方面，
事情还比较简单；
对于KVCache来说，
如果网络慢到取缓存还不如重算，
复用就失去意义。
EP能跨机铺多大，不是模型说了算，
而是网络说了算。
网络跟得上，EP可以继续扩大，
把成本压得更低；
网络跟不上，GPU就一直等数据，EP越大，
等待越多，最后反而把大规模并行，
省下来的钱又赔了进去。
这里确实有一个很反直觉的地方，
也是AI集群设计最有意思的地方。
正常人的直觉是：
GPU越多，并行规模越大，
成本应该越低。
但现实不是这样。
你得有技术把成本降低。
这事的复杂度还没有结束。
跨机EP的流量和KVcache的流量，
是在同一张网络上跑的，
而它俩性质相反，
EP流量高频琐碎，极其怕延迟，
KVcache流量偶发但单次量大，
一传就占满带宽。
大块的KVcache传输一旦挤上来，
就会堵住那些细碎，
卡在关键路径上的EP通信，
让decode的每一步都被拖慢。
所以从本质上看，并行并不天然省钱，
它只是提供了一个省钱的机会。
只有网络，调度，推理引擎都配合得上，
这个机会才能抓住；
否则，规模越大，浪费反越大。
08：选模型，选芯片
文章前面聊的事情是，
给定一个模型，
给定一批卡，
怎么把它榨到极致。
看上去似乎是给定条件做题，
条件肯定可以改，
也就是，既可以上面换模型，
也可以下面换芯片。
你可以没有配套软件，
但你绝不能没有芯片。
配套软件的目的还是那个，
降单位token成本。
同一批GPU，不同的模型跑上去，
性价比天差地别。
错配就是浪费。
思考一，任务和模型有无错配？
简单任务如果用了最贵的大模型，
就是浪费，
选了模型，往往同步确定量化精度。
思考二，模型和芯片有没有错配？
即使同一批GPU芯片，跑不同模型，
单位Token成本可能相差几倍，
如何让每个模型跑在最合适的硬件上？
仅盯着这个问题研究，那就看上去像篇学生论文。
但是，我们可以由此点讨论，
举个例子，
DeepSeekV3是个超大的MoE模型，
运算量很大，也就是计算强度高，
而H800这块卡本身算力强。
两者的计算强度正好对得上。
V3跑在H800上，
能把这块卡的算力吃得比较满，
所以H800适合V3。
再看Qwen3，
这个模型每做一点运算，就要搬不少数据，
瓶颈卡在带宽上，算力用不满。
这种模型你给它配H800，
那种"算力猛"的卡是浪费，
而H20恰恰是"带宽不错。
所以，Qwen3适合H20。
真正把AI系统跑好的团队，
大家都会用自己挑好的模型，
自己的数据和芯片跑大量测试，
因为只有真实跑一遍，
才能知道哪种组合速度最快，成本最低，
这是最终的答案了吗？
并不是，而是这个模型，
在这个业务流量，这个上下文长度，
这个延迟要求，这个成本目标下，
跑在哪个芯片上最划算。
我也顺道和上海张江那边的，
国产推理芯片厂商的大佬聊了一下，
她的观点是，推理芯片市场收敛缓慢，
不会出现英伟达式的一家独大。
论及原因，有以下几个：
第一，半导体行业容易出现强者恒强，
芯片一旦跑通，
最后会向一两家龙头集中：
它的东西又好、又便宜、功能又全，
客户自然不愿意换。
但推理芯片的市场足够大，
而需求足够碎。
只要你能吃下一个细分场景，
哪怕只有1%的市场，
也可能摊平研发和部署成本。
客户也未必会完全抛弃你，
因为他们关心的是，
这一代模型、这一类业务、这一笔账，
能不能算得过来。
只要你在某个推理场景里不明显落后，
甚至有一点成本优势，
你就有继续存在的理由。
第二，
训练那边，英伟达的护城河是CUDA生态，
但推理不一样，最后看的不是谁的生态最全，
而是谁能在具体场景里token成本做到最低。
于是，有人优化低延迟，有人优化长上下文，
有人优化小模型，有人优化大批量吞吐……
他们追求的最优都可能不一样。
第三，
客户对于推理芯片，胆子也更大。
这样的话，训练更容易向“一个平台”集中，
推理更像“很多专用解法”并存。
而美国SambaNova芯片公司的一位资深研发，
则更详细地告诉我：
因为英伟达GPU现在在低延时的场景下，
吞吐并不高，这是其它芯片的机会。
高速是其它芯片能发挥作用的场所。
因为一个公司不会只有一个模型，
也不会只有一种请求。
09：最后的话
说到底，耗尽心血的推理系统，
并不是永固的护城河，但能卷死竞争对手。
让Token变便宜的这些东西，
不是什么精妙的算法秘密，
而是扎实的系统工程。
那么推理的胜负手，
是在一堆已知的工程问题，
一个一个抠到极致。
跟着业务，做得越细，利润越高。
这也解释了开头那个爆料：
大厂把算法同学调去搞推理，
不是让他们去发明更聪明的模型，
是让他们去把这套系统工程做扎实。
我认为，在推理这件事上，
技术，产品，业务已经变成同一个东西了。
而这件事一旦成立，
像我一直所担心的那样：
每个场景都要单独优化，
每种卡，每个模型都要单独适配优化，
推理就不再是业务的支撑，推理本身就是业务。
这条护城河，不在于别人做不出来,
而在于别人短期追不平。
热门跟贴