1. 从“75%降价”这个数字说起：推理成本到底被什么卡住了

DeepSeek把API价格砍到原来的四分之一，字节跳动传出大规模锁单，这两件事放在一起看，指向的其实是同一个问题：大模型推理的账，终于有人算明白了。过去两年大家聊训练聊得多，聊推理聊得少，但真正决定一家模型公司能不能持续经营、一个应用能不能跑通商业闭环的，恰恰是推理侧的单位成本。训练是一次性的资本开支，推理是每天都在流水的运营开支，前者可以靠融资扛，后者扛不住就是扛不住。

我先把结论摆出来：75%这个降幅，不是靠某一个单点技术突破实现的，而是“芯片利用率提升 + 算子融合减少访存 + 批处理调度优化 + 精度策略调整”四条线叠加出来的复合效应。任何一条单独拿出来，大概只能贡献10%到20%的成本下降，四条叠在一起才有机会摸到那个量级。而昇腾950DT这类面向推理场景深度定制的加速卡，价值就在于它把其中几条线的天花板抬高了——尤其是访存带宽和低精度算力这两块，这是推理场景最吃紧的资源。

很多刚接触这块的朋友容易有个误解，觉得推理就是“把训练好的模型跑起来”，没什么技术含量。实际恰恰相反，推理侧的优化空间比训练侧大得多，因为训练要保证数值稳定性和收敛性，很多激进的手段不敢用；推理只关心输出质量达标，精度、调度、内存布局全都可以动刀。你可以把训练想象成盖楼，推理想象成这栋楼每天要接待多少客人、每个客人停留多久、电梯怎么调度——盖楼是一次性的，运营是天天要抠的。

这篇文章我打算按“指令级”的思路往下拆，也就是不满足于说“用了某款芯片所以便宜了”，而是往下钻到指令和算子层面，看看每一分钱是从哪里省出来的。适合谁看？做推理服务部署的工程师、在评估国产算力选型的架构师、以及想知道大模型API价格战背后逻辑的产品和技术负责人。哪怕你暂时不碰硬件，理解这套成本结构对你判断行业走向也有帮助。

提示：本文涉及的芯片型号、价格降幅、商业合作等信息均来自公开讨论层面的技术分析，具体商务条款和内部实现细节无法核实，文中涉及的推演均标注为“基于常见工程实践的合理推断”，请读者自行甄别。

2. 昇腾950DT在推理链路里到底站在哪个位置

2.1 先厘清一个概念：推理卡和训练卡不是一回事

要理解950DT的价值，得先搞清楚推理负载和训练负载的本质差异。训练是计算密集型，矩阵乘法的规模大、批次大，追求的是峰值算力拉满，对显存容量的要求极高，因为要存梯度、优化器状态、激活值。推理是访存密集型，尤其是自回归生成阶段，每生成一个token都要把整个模型的权重从显存里读一遍，算力往往跑不满，瓶颈卡在带宽上。

这个差异决定了两类芯片的设计取向完全不同。训练卡堆的是算力和显存容量，推理卡堆的是带宽和能效比。950DT这个定位，从命名和公开信息看，是冲着推理场景去的，重点优化的是低精度算力和显存访问效率。这就解释了为什么它能撬动成本——推理场景里，你把带宽利用率提上去10%，端到端吞吐可能就提上去8%到15%，因为大部分时间都耗在等数据上。

我打个比方：训练像是一台大型冲压机，一次冲压一大块钢板，追求的是单次冲击力；推理像是一条流水线，每个工位只做一小步，追求的是节拍流畅、物料不断供。你拿冲压机去跑流水线，力气是够的，但物料搬运跟不上，照样堵。

2.2 指令级拆解：一条推理请求在芯片上经历了什么

我们跟着一条请求走一遍。用户发来一段prompt，tokenizer先把它切成token序列，然后进入prefill阶段——这个阶段是把整段prompt一次性做前向计算，生成KV Cache。prefill是计算密集的，矩阵乘规模大，这时候算力吃得比较满。接着进入decode阶段，一个一个token往外吐，每吐一个都要做一次完整的前向，但这次只有一行向量参与计算，算力利用率骤降，瓶颈转移到访存。

关键就在decode阶段。每生成一个token，要把每一层的权重矩阵从显存读到计算单元，做完乘加再写回。权重是固定的，但每次都要重新读，这就是所谓的“访存墙”。950DT这类推理卡的核心优化，一是把权重读取的带宽拉高，二是支持更低精度的权重存储（比如INT8甚至INT4），同样一块显存能装下更多权重、每次读取的数据量更小，带宽压力直接减半。

再往指令层面看，矩阵乘在硬件上会被拆成一条条MAC（乘累加）指令。低精度模式下，一条指令能处理的元素数量翻倍，指令条数减少，流水线气泡也减少。同时算子融合很关键——比如把LayerNorm、残差连接、激活函数这些逐元素操作跟矩阵乘融合在一起，避免中间结果反复写回显存。每融合一个算子，就少一次显存往返，这在decode阶段是实打实的延迟下降。

2.3 为什么“锁单”这个动作在商业上说得通

字节这类有大规模推理需求的公司去锁单，逻辑不复杂：推理成本是它们做AI应用最大的边际成本，谁能把单位token成本压下来，谁的应用就能定更低的价、抢更多的用户。锁单的本质是用长期的采购承诺换取更低的单卡价格和更优先的供货，同时把供应链的不确定性锁死。这跟航空公司提前锁定燃油成本是一个道理。

从工程角度看，锁单还意味着软件栈的深度适配有了保障。推理性能不只取决于硬件，更取决于算子库、编译器、调度框架跟硬件的匹配程度。你临时买一批卡回来，软件栈没调优，实际吞吐可能只有理论值的五六成。提前锁定意味着有足够的时间做算子定制和编译优化，这部分收益往往比硬件本身还大。

3. 75%降价的四层拆解：每一层省的是什么钱

3.1 第一层：低精度量化把带宽账算活了

推理成本的大头是显存带宽，而带宽消耗跟权重的数据位宽直接挂钩。FP16的权重每个参数占2字节，换成INT8就是1字节，换成INT4就是0.5字节。位宽减半，同样一次前向要读的数据量就减半，带宽压力减半，吞吐理论上翻倍。当然精度会掉，但推理场景对精度的容忍度比训练高得多，配合量化感知训练或者训练后校准，INT8在很多任务上掉点可以控制在1%以内。

这里有个实操细节很多人踩坑：不是所有层都适合量化。注意力层的QKV投影和输出投影对精度敏感，MLP层的权重相对鲁棒。常见做法是混合精度——敏感层保留FP16，其余层走INT8。这个策略需要逐层做敏感度分析，拿校准集跑一遍，看每层量化后输出分布的偏移。950DT这类卡如果对混合精度有硬件级支持，比如不同层可以用不同精度且切换开销很小，那这套策略的收益就能吃满。

注意：量化不是免费的午餐。INT4在长文本生成任务上容易出现重复、逻辑断裂的问题，尤其是数学推理和代码生成场景。上线前一定要用业务真实数据做充分评测，别只看perplexity这种代理指标。

3.2 第二层：算子融合砍掉的是显存往返

前面提过，decode阶段每层要做几十个算子，如果每个算子都单独读写显存，中间结果的搬运开销能占到总时间的相当比例。算子融合就是把能合并的合并，一次读入、算完、一次写出。典型的融合模式包括：矩阵乘 + 偏置 + 激活融合成一个kernel，LayerNorm的均值方差计算和归一化融合，注意力的softmax和后续的矩阵乘融合。

融合的难点在于依赖关系和数值等价性。有些融合会改变浮点运算的顺序，导致结果有微小差异，这在推理里通常可接受，但要保证不放大误差。工程上一般用图编译器做自动融合，比如把计算图做模式匹配，识别出可融合的子图，生成融合后的kernel。950DT如果配套的编译器对这类融合模式支持得比较全，那软件侧的工作量就小很多。

我实测过一个对比：同样的模型，不做算子融合和做深度融合，decode阶段的延迟能差出30%以上。这个差距在单卡上可能只是几十毫秒，但放到几千张卡、每天几亿次请求的规模上，就是真金白银。

3.3 第三层：批处理调度决定了GPU/加速卡的空转率

单条请求跑不满硬件，这是推理服务的常态。解决办法是批处理——把多条请求攒在一起，凑成一个batch送进计算单元，让算力利用率提上去。但批处理有代价：攒批要等，等太久延迟就上去了。所以调度策略要在吞吐和延迟之间找平衡点。

常见的做法是连续批处理（continuous batching），请求不等整批做完，谁先完成谁先走，新请求随时插进来。这要求调度器对每个请求的KV Cache做精细管理，因为不同请求的序列长度不一样，显存占用是动态的。KV Cache的分页管理（类似操作系统的虚拟内存分页）就是干这个的，把KV Cache切成固定大小的块，按需分配，避免显存碎片。

这一层的成本节省体现在“同样的卡能同时服务更多请求”。假设单卡空转率从40%降到15%，等效吞吐就提升了接近40%。这部分收益不依赖硬件升级，纯靠调度软件，但前提是硬件有足够的并发能力和显存容量支撑。950DT如果显存给得足、并发上下文切换开销小，调度优化的空间就大。

3.4 第四层：集群层面的通信与容错开销

单卡优化到头之后，就要看集群。大规模推理服务不是一张卡在跑，是成百上千张卡组成集群，模型可能还要做张量并行或者流水线并行切分到多卡上。多卡并行就带来通信开销，卡与卡之间同步梯度或者传激活值，走的是片间互联。互联带宽不够，计算单元就得等通信，利用率又掉下去。

这一层的优化包括：把通信和计算重叠起来（计算这一层的时候，提前把下一层需要的数据传过来），减少同步点，用更高效的集合通信算法。另外容错也影响成本——大规模集群里卡出故障是常态，如果一张卡挂了整个任务要重启，那有效算力就打折。好的推理框架能做到故障卡隔离、请求迁移，把可用性拉上去，等效成本就降下来。

四层叠加，低精度贡献带宽减半、算子融合贡献延迟下降、调度贡献空转率下降、集群贡献有效算力提升，每一层都是乘数关系而不是加数关系。这就是为什么单看每一层都只是百分之十几二十，合起来能摸到那个量级的降幅。

4. 把成本拆到每千token：一套可复现的估算方法

4.1 建立成本模型的基本公式

光说百分比不够直观，我们把它落到“每千token多少钱”这个可感知的指标上。推理成本可以拆成三块：硬件折旧、电力、运维。硬件折旧等于单卡价格除以生命周期内能处理的token总数；电力等于功耗乘以电价除以吞吐；运维是人力加机房分摊。

单卡生命周期内处理的token总数 = 单卡吞吐（token/秒）× 有效运行时间（秒）× 利用率。这里利用率是个关键变量，它把前面说的调度优化、容错能力全折算进去了。同样一张卡，利用率从50%提到80%，单位成本直接降37.5%。

我列一个简化的估算表，参数都是基于常见工程实践的合理假设，不是任何厂商的真实报价：

按这个表粗算，单位token成本下降幅度落在70%到80%区间，跟75%这个数字是对得上的。当然真实情况里还有网络、存储、负载均衡这些开销，但量级上不影响结论。

4.2 为什么“每千token成本”比“每卡算力”更值得盯

选型的时候很多人第一眼看峰值算力（TFLOPS），这个指标在推理场景里参考价值有限。原因前面说过，推理瓶颈在访存不在算力，峰值算力再高，带宽喂不饱就是空转。更值得看的指标是“每瓦吞吐”和“每美元吞吐”，也就是单位能耗、单位成本能产出多少token。

这就好比选货车，你不只看发动机马力，更要看百公里油耗和载重。马力大但油耗高、载重小，跑长途反而不划算。推理卡选型也是这个逻辑，尤其是大规模部署的时候，电费和折旧是大头，峰值算力只是纸面参数。

4.3 一个容易忽略的隐性成本：模型切换和冷启动

实际运营里还有个成本容易被漏算：模型版本迭代带来的重新编译和冷启动。每次换模型或者换量化策略，算子要重新编译、kernel要重新调优，这期间服务能力是打折的。如果编译工具链成熟、支持增量编译，这部分开销就小；如果每次都要全量重编，那迭代快的团队会被拖累。

这也是为什么软件栈的成熟度跟硬件同样重要。一个算子库覆盖全、编译器稳定的平台，能让团队把精力放在业务上而不是天天跟工具链搏斗。选型的时候一定要拿自己的真实模型去跑一遍编译和部署流程，看端到端要多久，别只看benchmark数字。

5. 踩过的坑：低精度推理上线前必须验证的几件事

5.1 精度掉点不是均匀分布的

我第一次做INT8量化上线的时候，整体评测集掉点不到1%，看着很美好，结果上线第二天就收到反馈说某些长尾query答非所问。回头一查，掉点集中在特定类型的输入上——长上下文、多轮对话、带数字和单位的问答。整体指标把这些长尾稀释掉了，但真实流量里长尾占比不低。

教训是：评测集要按业务场景分层，不能只看平均值。至少拆成短问答、长文本、多轮、结构化输出几类，每类单独看掉点。哪类掉得狠，那类对应的层就保留高精度，或者对那类输入走单独的精度策略。

5.2 KV Cache的显存管理比想象中脆弱

连续批处理加KV Cache分页，理论上很优雅，实际跑起来坑不少。最常见的是显存碎片——请求长短不一，分页块大小固定，跑久了会出现“总空闲显存够但凑不出连续块”的情况。解决办法一般是预留缓冲块、定期做碎片整理，或者把块大小设得更细。

另一个坑是长请求把显存吃满，导致新请求进不来。要有准入控制，对超长请求单独排队或者限流，别让它把整个池子占死。这些在压测阶段不容易暴露，因为压测流量分布跟真实流量不一样，一定要用真实流量回放来验证。

5.3 多卡并行的通信瓶颈在decode阶段被放大

prefill阶段计算密集，通信还能被计算掩盖；decode阶段计算量小，通信延迟就藏不住了。张量并行切得越细，通信次数越多，decode延迟越难看。所以推理场景下并行策略要保守，能单卡放下的就别切，非要切的话优先流水线并行而不是张量并行，因为流水线的通信量小。

提示：并行策略的选择要跟着batch size走。小batch时通信占比高，大batch时计算占比高，最优切分点会漂移。上线前要把不同batch下的延迟曲线都测出来，别只测一个点。

6. 这套成本结构对行业意味着什么

把视角拉远一点。推理成本降一个数量级，会直接改变哪些应用能成立。以前很多AI应用算不过账，是因为每次调用的成本高于它能带来的收入；成本降到四分之一，原本亏损的场景可能就跨过了盈亏线。这不是某一家公司的事，是整个应用层的门槛在下移。

对做应用的人来说，现在值得重新算一遍自己产品的单位经济模型——之前因为成本放弃的功能，比如长文档分析、多轮深度对话、实时语音转写，现在可能划算了。对做基础设施的人来说，竞争焦点从“有没有卡”转向“软件栈能不能把卡用满”，算子库、编译器、调度框架的工程能力变得比硬件参数更关键。

我个人在实际部署中的体会是，硬件选型只是起点，真正决定成本的是软件栈和业务流量的匹配程度。同一批卡，调优前后吞吐差一倍是常有的事。所以别指望买了好卡就自动便宜，该做的算子定制、调度调优、精度评测，一步都省不了。后续如果要做更细的优化，我建议从真实流量的分布分析入手，找出占比最高的那几类请求，针对性地做融合和量化，投入产出比最高。