摘要

一条此前停留在论文里的路线开始进入工程视野：把 Transformer 的不同部分放到不同的硬件上执行——注意力部分交给 GPU，前馈网络部分交给类脑或存算一体芯片，两者协同完成一次推理。近期国内有团队公布了这类异构混合推理系统的实践，让这件事从概念走向可讨论。它的吸引力在于，模型各部分的算术强度与访存特征本就不同，理论上可以让每种硬件做自己擅长的事；但它的代价也很直接——跨设备同步、数据搬运与调度复杂度会吃掉一部分收益。本文拆开看这套方案为什么现在才可行、切分点该怎么选、以及工程上必须满足的前提。2026 奇点智能技术大会（11 月 20-21 日 · 北京万达文华酒店）将讨论异构算力调度这一方向。

一、为什么是现在

异构计算不是新概念，但过去在大模型推理上难以落地，原因有三。

其一，模型结构过于统一。 早期 Transformer 的各层计算形态高度一致，切分收益有限。稀疏化与混合架构普及后，模型内部出现了明显的计算形态差异——有的部分密集矩阵运算为主，有的部分稀疏、事件驱动特征更强，这才让"分硬件执行"有了依据。

其二，替代算力终于有了足够规模。 类脑芯片与存算一体架构过去多为实验室原型，算力规模与软件栈都不足以承担生产负载。近两年单芯片规模与集群互联能力都有实质进展。

其三，功耗约束变成了硬约束。 数据中心的电力与散热不再是"扩容就能解决"的问题，单位功耗下的有效吞吐开始成为首要指标，而这恰好是专用架构的优势区间。

驱动因素：模型结构分化 + 专用算力成熟 + 功耗约束变硬
                    ↓
        让不同硬件各做擅长的事，第一次变得划算

二、切分点该怎么选

把一个模型拆到两套硬件上，第一问题是：在哪里切。

切分粒度	切分对象	优点	主要代价
模块级	Attention 走 A 硬件，FFN 走 B 硬件	语义清晰，改动集中	每层都要跨设备传两次张量
层级	前 N 层走 A，后 M 层走 B	跨设备次数少	难匹配各部分算力比例
请求级	不同请求分发到不同硬件	调度简单，无层间同步	无法利用单次请求内的互补性
算子级	单个算子内部按形状路由	灵活度最高	调度与编译复杂度极高

从工程可行性看，模块级切分是最常见的起点，它的改动集中在模型定义层，推理框架侧只需支持跨设备张量传递。代价也最明显：每层的 Attention 与 FFN 之间都要跨一次设备边界，通信次数等于层数乘以二。

这个代价可以用两个办法缓解：一是把连续多层打包，减少往返次数；二是让两套硬件共享高带宽互联，把单次传递成本压到足够低。如果两个办法都做不到，模块级切分的收益会被通信吃掉大半。

三、收益从哪里来，又漏到哪里去

异构方案的收益来自三个地方：专用硬件在特定算子上的能效优势、GPU 侧负载减轻后批处理效率提升、以及整体功耗下降。

但收益会漏掉的地方同样明确。

第一处漏洞是同步等待。 两套硬件的执行节奏不同步时，快的那一侧会空转等待。在逐层切分的方案里，这种等待会逐层累加，形成类似流水线气泡的损耗。

第二处漏洞是数据布局转换。 不同硬件对张量布局、精度格式、内存对齐的要求往往不同，转换本身要花时间，还可能需要额外显存。在长上下文场景下，这笔开销会随序列长度线性增长。

第三处漏洞是调度复杂度。 请求到达模式不均匀时，两侧硬件的利用率很难同时维持高位。一个侧满载而另一个侧闲置的情况，在实际流量下比纸面测算更常见。

def estimate_speedup(t_a_gpu, t_b_gpu, t_a_alt, t_b_alt, sync_cost):
    """粗估异构收益：分别算两部分在新硬件上的耗时，再扣掉同步开销。
    t_*_gpu: 原方案耗时；t_*_alt: 异构方案耗时；sync_cost: 每层的同步与搬运。"""
    baseline = t_a_gpu + t_b_gpu
    hetero = t_a_alt + t_b_alt + sync_cost
    return baseline / hetero

这个公式的价值在于它显式地把同步开销放进了分母。很多异构方案的乐观估计，问题就出在把 sync_cost 算成了零。

四、工程落地的前提条件

要让这套方案真正跑通，至少要满足四个前提。

一是互联带宽足够。 这是硬门槛。如果两套硬件之间走的是通用网络而非高带宽互联，跨设备传递的延迟会直接决定方案是否可行。

二是编译与运行时支持跨设备图切分。 需要框架能自动识别算子归属、插入传输节点、并在执行时管理两侧的内存生命周期。手工实现这些逻辑可以验证概念，但无法支撑生产。

三是数值一致性可验证。 不同硬件的数值行为（尤其是低精度格式下的舍入与累加顺序）存在差异，必须有机制验证两侧结果在可接受误差内一致，否则长序列生成会出现累积漂移。

四是有可回退路径。 任何一侧硬件故障时，能否降级为单硬件执行，决定了这套系统能否上生产。没有回退路径的异构方案，只适合做验证，不适合承载业务。

五、这件事对国内产业的特殊意义

在先进制程受限的条件下，通过架构组合而非单芯片性能来提升系统级效率，是一条现实且合理的路径。它把竞争从"谁能做出更强的单卡"转向"谁能把不同算力组织得更有效"。

这个转向对软件能力的要求显著高于硬件。系统级的收益藏在调度、切分、通信与容错里，这些恰恰是软件工程可以发挥的地方。也正因如此，这类创新更可能诞生在同时掌握硬件与系统软件的团队手里。

需要冷静的是，异构不是万能解法。它增加了系统的复杂度与运维负担，只有当能效收益足够覆盖这份复杂度时才值得做。判断标准很简单：如果你的瓶颈在显存带宽或互联，异构未必有帮助；如果瓶颈在功耗与特定算子的能效，它才值得评估。

六、如何验证异构方案是否真的划算

异构方案最容易出问题的地方，是收益验证方法本身。以下四步是必要的。

第一步：分别测量两侧耗时。 不能只测端到端时间，要把模型分成两部分，分别测它们在各自硬件上的执行时间，与全 GPU 方案对比。只测端到端，无法判断收益来自哪里，也就无法继续优化。

第二步：单独测量同步开销。 在两侧之间插入计时点，统计每层的传输与等待时间。这个数字必须单独列出来——它是决定方案可行性的关键变量，也是最容易在汇报中被合并进"其他"的那一项。

第三步：用真实负载分布测试。 请求长度分布、并发量、批大小都会影响结论。用均匀长度的请求集测试会得到过于乐观的结果，因为真实负载里的长尾请求恰恰是异构方案表现最差的地方。

第四步：做对照实验而非前后对比。 同一时间段内，一半流量走原方案、一半走异构方案，比较单位成本与 P99 延迟。前后对比会混入流量波动与代码改动的影响，结论不可靠。

验证项	常见错误做法	正确做法
耗时测量	只测端到端	分段计时
同步开销	混入其他项	单独统计
测试负载	均匀构造请求	采样真实分布
对比方式	上线前后对比	同期对照

一个必须提前设好的判断标准是：在多大的收益以上才值得引入这套复杂度。 如果方案只带来 10% 的成本下降，却让系统多了一整套跨设备调试流程，通常不划算。复杂度的账要算进去，而不是只看性能收益。

七、读者问答

问：异构方案会不会让系统变得不可维护？ 会显著增加复杂度。因此建议只在收益明确且稳定的场景下使用，并且必须保留单硬件的回退路径。如果业务规模不足以支撑专门的维护投入，不建议引入。

问：Attention 与 FFN 的切分比例是固定的吗？ 不固定，取决于模型结构与两侧硬件的能力比。实践中需要按模型调参，甚至按层动态调整——不同层的计算形态差异可能很大。

问：这类方案适合训练还是推理？ 目前更适合推理。训练对数值一致性与通信模式的要求更高，异构带来的复杂度在训练场景下更难控制。

八、几个延伸问题

问：异构方案对编译工具链的要求是什么？ 核心是跨设备的图切分与内存生命周期管理。编译器需要识别算子归属、自动插入传输节点、并管理两侧的内存分配与释放。如果这些靠手工实现，可以验证概念但无法支撑生产。

问：数据传输会成为瓶颈吗？ 在逐层切分的方案里一定会。这也是为什么连续多层打包与高带宽互联是这类方案的前提条件。如果两者都做不到，收益会被传输吃掉。

问：如何判断收益是否来自异构本身？ 做对照实验：同样的负载，一半走异构、一半走原方案，比较单位成本与尾延迟。同时分段计时，确认收益确实来自专用硬件而非调度变化。

问：这套方案的未来演进方向是什么？ 短期看是更细粒度的切分与更高效的互联；长期看，如果编译与运行时能自动完成切分决策，异构才会真正普及，否则只有少数大团队用得起。

九、衔接大会专题

11 月 20-21 日，北京万达文华酒店，2026 奇点智能技术大会的 AI 基础设施专题将讨论异构算力的调度与协同，包括跨架构编译、混合部署与集群稳定性等议题。同期 C++ 及系统软件技术大会则从运行时、通信库与性能剖析的角度给出更底层视角。

建议带着"我的负载里，哪些部分的计算形态最适合被分出去"这个问题去听，会比关注峰值算力数字更有收获。

---

大会信息
2026 奇点智能技术大会 + C++ 及系统软件技术大会
时间：2026 年 11 月 20-21 日
地点：中国·北京万达文华酒店
大会免费资料：点击领取大会PPT资料

立即报名，锁定 Lukasz Kaiser Keynote 与 70+ 场演讲完整资料！