1. 从一条标题里拆出来的三层信息

第一次看到“指令级拆解”“撬动降价”“锁单”这几个词凑在一起，我脑子里冒出来的第一个判断是：这不是一条普通的硬件发布新闻，而是一条把芯片架构、推理成本、商业订单三件事串起来的产业链信号。标题里信息密度很高，但每一层都需要拆开看，否则很容易被“75%”“锁单”这类数字带着走，最后只记住情绪，记不住逻辑。

我先把标题拆成三层。第一层是指令级拆解，指向的是芯片底层指令集与算子映射层面的分析，而不是停留在“算力多少T、带宽多少G”这种参数对比。第二层是撬动降价，指向的是推理侧单位token成本的下降，这背后是硬件利用率、显存带宽、互联效率共同作用的结果。第三层是锁单，指向的是下游大模型厂商对算力资源的长期预定，本质是对“单位成本可预期”的投票。

这三层其实是一条因果链：底层指令与架构设计决定了算子执行效率，算子效率决定了推理吞吐与单位成本，单位成本又决定了商业侧敢不敢下长单。很多讨论只盯着最后一环的“降价”和“锁单”，忽略了前面两环，结果就是看热闹。这篇内容我想做的，是把这条链从头到尾捋一遍，讲清楚一个从业者在做这类分析时，到底该看哪些指标、怎么算、哪些数字能信、哪些数字要打问号。

适合谁看？如果你是大模型推理侧的工程同学，关心的是“同样的卡，为什么别人跑出来的吞吐比我高”；如果你是做算力采购或成本测算的，关心的是“单位token成本到底怎么估”；如果你只是对国产算力进展感兴趣，想看懂这类标题背后的门道，那这篇也能给你一套可复用的拆解框架。下面所有涉及具体型号、具体订单的描述，我都按公开讨论中常见的分析口径来讲，涉及未公开细节的部分，我会明确标注这是基于常见工程实践的合理推演，不作为事实断言。

2. 指令级拆解到底在拆什么

2.1 为什么“指令级”比“参数级”更有信息量

大部分人看芯片，第一反应是看参数表：算力多少、显存多大、带宽多高。参数表有用，但它回答不了“实际跑一个Transformer层要多少个周期”。指令级拆解的价值就在这里——它把“一颗芯片”拆成“一条条指令怎么被调度、怎么被发射、怎么和访存重叠”，从而解释为什么两颗参数接近的芯片，实测吞吐能差出一大截。

打个生活化的比方。参数表就像一辆车的马力、油箱、轴距，而指令级拆解相当于去看发动机的燃烧过程、变速箱的换挡逻辑、底盘的力传导路径。马力相同的两辆车，开起来感受完全不同，差别就在这些“过程”里。芯片也一样，标称算力是理论峰值，真正决定推理成本的是有效算力利用率，而利用率恰恰是被指令调度、数据搬运、算子融合这些“过程性”因素决定的。

所以当我看到“指令级拆解”这个词，我预期看到的不是一张参数对比表，而是对矩阵乘、注意力、归一化、激活这几类核心算子在目标硬件上的映射方式分析，包括数据在片上缓存和片外显存之间怎么流动、计算单元的空转率大概在什么水平、有没有针对低精度做专门的指令通路。这些才是能解释“降价从哪来”的东西。

2.2 推理场景下真正吃紧的三个环节

做推理成本分析，我习惯把一个大模型的前向过程拆成三个吃紧环节来看，这三个环节基本决定了单位token成本的大头。

第一个是矩阵乘的吞吐。Transformer里绝大部分FLOPs都在线性层上，矩阵乘的效率直接决定算力利用率。这里的关键不是峰值算力，而是在给定batch和序列长度下，计算单元能不能被喂饱。小batch时容易受限于访存，大batch时容易受限于显存容量，中间那段“甜点区”才是吞吐最高的地方。

第二个是注意力的访存开销。注意力机制在长序列下会显著放大KV缓存的读写量，这部分开销往往不是算力瓶颈，而是带宽瓶颈。指令级拆解里如果能看到KV缓存的组织方式、有没有做分块、有没有减少重复读写，那对成本判断就很有价值。

第三个是算子之间的数据搬运。一个层里往往有多个小算子串联，如果每个算子都要把中间结果写回显存再读出来，搬运开销会吃掉大量时间。算子融合、片上缓存复用这些手段，本质上就是在减少这部分“无效搬运”。

提示：看任何一份“指令级拆解”，先找这三个环节的分析。如果通篇只有峰值算力和显存容量，没有算子映射和访存路径，那它大概率只是参数表的另一种写法，参考价值有限。

2.3 低精度通路是降本的关键杠杆

推理降本最直接的杠杆之一，是低精度计算。从FP16到BF16再到FP8甚至更低，每一步精度下降都意味着单位时间能处理更多数据、显存占用更小、带宽压力更低。但低精度不是简单“换个数据类型”就完事，它需要硬件在指令层面有对应的通路支持，否则要么退化成高精度计算，要么精度损失大到不可接受。

这里的关键判断点是：低精度是不是原生支持的。如果硬件在指令层面就支持低精度矩阵乘，并且有配套的累加精度保障，那推理侧就能放心地把大部分线性层切到低精度，只在少数敏感层保留高精度。这种“混合精度”策略在实际部署里非常常见，也是很多推理成本优化方案的核心。

我在做成本测算时，一般会把低精度带来的收益拆成两块：一块是吞吐提升，单位时间处理的token变多；另一块是显存节省，同样的卡能装下更大的模型或更长的上下文。两块收益叠加，才是低精度对单位成本的完整影响。只算吞吐不算显存，容易低估；只算显存不算吞吐，容易高估。

3. 从指令效率到单位token成本的推算路径

3.1 单位token成本的三段式估算模型

“降价75%”这种数字，如果不给推算路径，基本没法验证。我习惯用一个三段式模型来估算单位token成本，虽然粗糙，但能把逻辑讲清楚。

第一段是硬件折旧成本：一台推理服务器按三年折旧，算出每小时的成本。第二段是有效吞吐：在目标模型、目标精度、目标batch下，这台服务器每小时能稳定产出多少token。第三段是利用率修正：实际业务不可能满负荷，要乘一个合理的利用率系数。三段一除，就是单位token的硬件成本。

用公式表达大概是：单位token成本 = 每小时硬件成本 ÷（每小时有效token数 × 利用率系数）。这个模型里，硬件成本相对固定，真正能撬动降价的变量是有效token数，而有效token数又直接由指令效率、算子融合、低精度通路这些底层因素决定。所以“指令级拆解”和“降价”之间不是修辞上的关联，而是这条公式里的分子分母关系。

3.2 一个可复现的算例演示

为了让你能自己动手算，我给一组假设参数做个演示。注意，以下数字是为了说明计算方法而设定的示例值，不代表任何真实产品的实测数据。

假设一台推理服务器整机成本按折旧摊到每小时是40元。在某个目标模型上，优化前每小时有效产出是20万token，利用率系数取0.6，那么单位token成本约为 40 ÷（200000 × 0.6）≈0.00033元/token，也就是每百万token约333元。

现在假设通过指令级优化——包括更好的算子融合、低精度通路启用、KV缓存访存优化——有效吞吐提升到每小时60万token，利用率系数因为延迟更稳定提升到0.7，那么单位成本变成 40 ÷（600000 × 0.7）≈0.000095元/token，每百万token约95元。对比之下，降幅约71%，和标题里“75%”的量级是能对上的。

这个算例想说明的是：75%这个量级的降幅，在吞吐提升两到三倍、利用率小幅改善的情况下是可能出现的，并不需要什么魔法。关键在于吞吐提升是不是真的能落地，而这就要回到指令级拆解去看——算子融合省了多少搬运、低精度通路覆盖了多少计算、访存瓶颈缓解了多少。这三项每一项都有明确的收益上限，加起来能不能撑起两三倍吞吐，是可以逐项估算的。

3.3 为什么“降价”必须绑定“可预期”

单次跑分跑出高吞吐不难，难的是长期稳定可预期。商业侧敢锁单，看的不是峰值数字，而是“在我这个业务负载下，单位成本能不能稳定在这个水平”。这就把话题从纯硬件拉到了工程落地层面。

稳定性来自几个方面：一是散热与功耗墙，长时间高负载下会不会降频；二是软件栈成熟度，算子库、编译器、推理框架的适配是不是到位，否则硬件潜力发挥不出来；三是多卡互联效率，大模型推理往往要多卡协同，互联带宽和延迟直接影响到实际吞吐。这三点里任何一点不稳，单位成本就会波动，锁单的基础就不牢。

所以我在看“锁单”这类信息时，关注点不是订单数字本身，而是订单背后的成本承诺是怎么算出来的。如果对方能给出在特定模型、特定精度、特定并发下的稳定吞吐区间，那这个锁单才有工程意义。否则就只是意向层面的东西。

4. 商业侧“锁单”背后的成本账怎么算

4.1 大模型厂商为什么愿意提前锁定算力

站在大模型厂商的角度，推理成本是运营成本里最刚性的一块。用户量涨、上下文变长、模型变大，三个方向都在推高推理开销。提前锁定算力，本质是用确定性换价格——牺牲一部分灵活性，换取单位成本的稳定和可预期。

这个逻辑和很多制造业的长期协议是一样的。你提前锁定产能，供应商给你更低的单价，你承担的是“万一需求没起来”的风险，换来的是“需求起来时不会被临时涨价”。对推理业务来说，只要用户增长曲线大致可预期，这个交换就是划算的。

但这里有个前提：锁的是“有效算力”而不是“标称算力”。如果软件栈不成熟，标称算力发挥不出来，那锁单锁到的可能是一堆跑不满的卡，成本反而更高。所以锁单决策背后，一定有一轮扎实的实测验证，而实测验证的核心指标就是前面说的有效吞吐。

4.2 成本对比不能只看单价

做算力成本对比，最容易犯的错是只比“每卡每小时单价”。这个比法忽略了三件事：实际利用率、模型适配度、迁移成本。

实际利用率前面说过了，同样单价，利用率高的方案实际成本更低。模型适配度指的是目标硬件对你要跑的模型结构是不是友好，比如某些算子有没有专门优化、注意力实现是不是高效。迁移成本则包括软件栈适配、团队学习曲线、现有工具链改造，这些都是一次性但不可忽略的投入。

我一般会做一个总拥有成本的粗算：把硬件成本、迁移成本、运维成本加总，再除以预期产出的token总量。这样比出来的结果才接近真实。单看单价，很容易得出一个漂亮但错误的结论。

4.3 锁单信号对产业链意味着什么

从产业链视角看，锁单是一个需求侧确认信号。它说明下游已经完成了从“观望测试”到“批量采用”的跨越。这个信号的价值不在于数字大小，而在于它验证了“单位成本可预期”这件事在工程上成立了。

对上游来说，锁单意味着产能规划有了依据，可以更放心地投入扩产和迭代。对中间层的软件生态来说，锁单意味着有更多真实负载跑在平台上，算子库和编译器能在真实场景里打磨，这会反过来提升硬件利用率。对下游其他厂商来说，头部厂商的锁单行为会形成一个参考锚点，降低它们的评估成本。

这条链一旦转起来，就是一个正循环：真实负载多→软件栈成熟→利用率提升→单位成本下降→更多厂商愿意采用。所以我看这类信息，更关注的是这个循环有没有启动，而不是单笔订单的绝对数字。

5. 实操：自己动手做一次推理成本拆解

5.1 准备阶段：明确模型、精度与并发

自己动手拆解之前，先把三个变量定死：跑什么模型、用什么精度、目标并发是多少。这三个变量不定，后面所有数字都没有可比性。

模型方面，选一个有代表性的结构，比如标准的decoder-only架构，层数、隐藏维度、注意力头数都记录下来。精度方面，明确是纯FP16还是混合精度，混合精度的话哪些层保留高精度。并发方面，明确是单请求低延迟场景还是批量高吞吐场景，这两个场景的最优batch完全不同。

我建议先用一个小规模配置跑通流程，比如把层数减半、序列长度设短，确认工具链没问题，再上完整配置。这样能避免一上来就卡在环境问题上，浪费大量时间。

5.2 采集阶段：记录关键指标而非只看总耗时

跑起来之后，别只记一个总耗时。要拆开记：每个算子的耗时占比、计算单元利用率、显存带宽利用率、KV缓存读写量。这几个指标能告诉你瓶颈在哪。

如果矩阵乘耗时占比高但计算单元利用率低，说明是访存受限，要考虑增大batch或优化数据布局。如果注意力部分耗时随序列长度增长得特别快，说明KV缓存访存是瓶颈，要考虑分块或缓存压缩。如果算子之间有明显空隙，说明调度或数据依赖有问题，要考虑算子融合。

采集工具方面，硬件厂商一般会提供性能分析工具，推理框架本身也有profiling能力。两者结合看，能定位到比较细的粒度。我习惯把一次完整前向的算子耗时按顺序列出来，画成一条时间线，空隙和热点一目了然。

5.3 分析阶段：把耗时映射回成本

采集完数据，下一步是把耗时映射回成本。方法很简单：用总耗时反推每小时能跑多少token，再套前面说的三段式模型。但要注意，实验室环境和生产环境有差距，要留出合理的利用率折扣。

分析时重点看两件事：一是优化空间在哪，哪个环节耗时占比最高、有没有明确的优化手段；二是优化收益上限，假设把那个环节优化到理想状态，总耗时能降多少。这两件事想清楚，就能判断“降价”的空间是不是真实存在。

我一般会做一个敏感性分析：把几个关键参数（batch大小、序列长度、精度）各变动一档，看单位成本怎么变。这样能知道成本对哪个变量最敏感，实际部署时就知道该优先调什么。

5.4 验证阶段：小流量灰度再放大

任何成本测算，最后都要用真实流量验证。我的做法是先小流量灰度，把一部分真实请求打到新方案上，对比单位token成本和延迟分布。灰度期间重点看长尾延迟，因为平均值好看但长尾爆炸的方案，在生产环境里是不可用的。

灰度稳定后再逐步放大流量，同时监控资源利用率和错误率。这个过程中如果发现成本和测算偏差较大，回头检查是哪个假设不成立——常见的是利用率系数估高了，或者实际请求的序列长度分布和测试时不一样。

注意：成本测算里的利用率系数是最容易被高估的参数。实验室里可以跑到很高，生产环境里有各种波动和空闲，实际系数往往要打个不小的折扣。做决策时宁可保守一点。

6. 常见误判与排查清单

6.1 把峰值算力当有效算力

这是最常见的误判。峰值算力是理论值，实际能发挥多少取决于模型结构、精度、batch、软件栈。两颗峰值算力相同的芯片，实际推理吞吐可能差一倍以上。看到任何“算力翻倍”的说法，第一反应应该是问“在什么模型、什么精度、什么batch下的有效吞吐是多少”。

排查方法：要求提供目标模型上的实测吞吐，而不是只给峰值算力。如果拿不到实测数据，就自己按前面说的方法跑一遍。

6.2 忽略软件栈成熟度的隐性成本

硬件潜力再大，软件栈跟不上也发挥不出来。算子库覆盖不全、编译器优化不到位、推理框架适配不完整，都会让实际吞吐大打折扣。这部分成本是隐性的，但真实存在。

排查方法：看目标模型里的关键算子有没有专门实现，看编译器对常见融合模式的支持程度，看推理框架的适配是不是官方维护。这几点如果都有明确答案，软件栈成熟度基本可信。

6.3 用单一场景数据外推所有场景

短序列跑得好，不代表长序列也跑得好；小batch延迟低，不代表大batch吞吐高。不同场景的瓶颈完全不同，用单一场景数据外推，很容易得出错误结论。

排查方法：至少测两组场景——一组低延迟小batch，一组高吞吐大batch，再补一组长序列。三组数据放在一起看，才能对成本有一个完整判断。

6.4 把一次性优化当成持续能力

有些优化在特定版本、特定配置下有效，换个模型或升个版本就失效了。把一次性优化当成持续能力，会导致成本预期过于乐观。

排查方法：看优化手段是不是结构性的——比如指令层面的低精度通路、算子融合能力，这些是结构性的，换模型也能受益；而某些针对特定算子的手工调优，就是一次性的，泛化性有限。判断清楚这一点，成本预期才靠谱。

7. 我在做这类拆解时的几个习惯

第一个习惯是先看瓶颈再看数字。任何成本数字，先问瓶颈在哪，瓶颈决定了优化的天花板。不看瓶颈直接看降幅，很容易被数字带偏。

第二个习惯是把测算和实测分开记。测算是纸面推演，实测是真实数据，两者会有偏差。我会把偏差原因记下来，下次测算时修正假设。时间长了，测算的准确度会越来越高。

第三个习惯是对“锁单”类信息保持克制。订单数字本身信息量有限，真正有价值的是订单背后的成本承诺和验证过程。看到锁单，我会去找“他们是怎么验证的”，而不是只看“锁了多少”。

第四个习惯是留出安全边际。成本测算里的每个参数都有不确定性，最后的结果要留出折扣。宁可保守一点，也不要让乐观预期误导决策。

这套拆解框架不复杂，但需要耐心把每个环节的数据都拿到。拿到之后，标题里的那些数字就不再是情绪，而是可以逐项验证的工程结论。这也是我觉得“指令级拆解”这个角度值得认真对待的原因——它把讨论从参数表拉回到了真实的执行过程，而真实的执行过程，才是成本真正的来源。