要想让 AI 跑得更快，可以给大模型找个替身队友？这是上海交通大学教授戚正伟团队的最新成果。你有没有玩过这样的游戏：一个团队里每个人都有自己的特长，但有时候某个队员临时来不了，如果找个技能相似的替补队员顶上，整个团队也能顺利完成任务。现在，AI 大模型也遇到了类似情况。

想象一下，AI 大模型就像一个由成千上万个小专家组成的超级团队。每个小专家都擅长处理不同类型的问题，有的擅长数学、有的擅长写作、有的擅长编程。

但神奇的是，每当你问 AI 一个问题，它并不需要请出所有专家来回答。就像你问 AI 一道数学题的时候，只需要请出来数学专家工作就可以，不需要惊动写作专家和绘画专家。这种设计让 AI 能够保持较高效率，同时其还拥有海量的知识。

不过问题来了：虽然每次只用到少数专家，但是所有专家都必须随时待命准备被召唤。为了解决这个“太胖装不下”的问题，人们想了一个办法：把不常用的专家搬到电脑的普通内存里待命，就像把不常用的物品放到仓库一样。当需要某个专家的时候，再临时把它从仓库请回来。

但是这个方法存在一个大问题：从仓库搬东西太慢了，把一位专家从普通内存请到显卡上工作，需要花费 10 毫秒左右的搬运时间。而专家在显卡上的工作时间却只需要不到 1 毫秒。也就是说，搬运时间比工作时间长了 10 倍。

戚正伟团队在仔细观察这些 AI 专家之后发现，很多专家其实长得特别像，功能也差不多。比如，在处理“苹果”这个词语的时候，可能同时有好几个专家都能理解它，有的专家将苹果理解为水果，有的专家将苹果理解为苹果公司，但它们在某些情况之下可以互相替代。为此，他和团队通过绘制专家关系热力图，厘清了哪些专家经常一起工作、哪些专家的能力很相似。

基于此，戚正伟团队提出一款名为 BuddyMoE 的智能系统（Buddy 就是好朋友的意思）。这个系统的核心思想很简单：当需要某个专家但它又不在显卡上的时候，不是急着去仓库搬运，而是立即找一个已经在显卡上的、能力相似的伙伴专家来临时顶替。

BuddyMoE 的专家预取流程。当 GPU 正在处理第 i 层的计算时，CPU 会提前预测并预加载第 i+1 层所需的专家（Prefetch），将数据的搬运与计算并行进行，从而降低延迟。

（https://arxiv.org/pdf/2511.10054）

但这个替换并不是随便进行的，BuddyMoE 系统遵循以下三个判断规则：

第一，看问题本身挑剔不挑剔。有些问题对于专家的要求很高，必须指定专家才能回答好。

第二，看需要替换的专家多不多。如果要替换的专家太多，说明系统出了状况，这时就不太适合大量使用替身，而是应该采用更加稳妥的方法。第三，要选择合适的替身。

在所有可用的伙伴专家中，系统会选择能力最接近、配合最默契的来顶替。经过大量测试，这个替身队友系统的表现非常好，在保证回答质量基本不变的前提下，准确度仅下降不到 2%，推理速度最高能提升 10%。

在内存特别紧张的情况下，效果更加明显。这项技术不仅能用于单个 AI 模型，也能在云服务中让多个 AI 模型共享彼此的专家。就像不同班级的学霸组成了一个超级学霸团，能够为全校同学答疑解惑。

大模型的大小（红线）相比于显卡内存的容量（蓝线）增长得更快，这更加凸显了 CPU 与 GPU 协同工作（异构计算）的需求。

（https://arxiv.org/pdf/2511.10054）

已在 llama.cpp 中进行原型实现和实验验证。

戚正伟告诉 DeepTech，BuddyMoE 的基本思路是：当预测失败、所需专家不在 GPU 时，不再执着于从 CPU 获取该专家，而是转而寻找一个已经在 GPU 显存中、且功能相似的伙伴专家来替代它执行计算。

这就好比一项工作原本的负责人无法到场，请另一位能力相仿的同事代为处理。通过这种方式，避免了耗时的高速/低速内存间数据传输或缓慢的 CPU 计算，所有计算均在高速的 GPU 内完成，从而极大地提升了推理速度。

当然，使用替代专家可能会带来微小的精度损失。但经过其测试，在专家替换比例低于 20% 的情况下，精度损失通常可以控制在 0.5% 到 1.5% 之间，某些情况下可能会稍高，但一般不会超过 5%。

这个代价相对于其带来的显著性能提升而言是可以接受的。也就是说，本次工作受到专家间存在相似性这一现象的启发，将这种相似性转化为应对预测失败的有效备选方案，最终实现在基本不损失模型精度的前提下，有效提升了推理速度。

该团队通过大量实际测试验证了本次方法的有效性。在大部分数据集上，使用伙伴专家进行替换会带来一定的精度损失，这是可以理解的，毕竟替代者并非原定的专家，可以看作是一个“功能相近的替补”。因此，很自然地会有人质疑这种方法的实用性，认为随便找个专家替代必然导致精度下降。

针对这些疑问，该团队进行了非常详尽的量化分析。他们设计了一套完整的机制来刻画和控制这种影响，其引入了专家选择的敏感度评估，并设定了一个全局的“专家替换比例”作为关键参数。

如果这个比例设置得过高，即替换的专家过多，确实会累积导致精度显著降低；反之，如果将这个比例调低，减少替换发生的次数，就能将精度损失控制在更小的范围内。

这套机制使得系统在工程实践上非常灵活和完备，主要体现在两个方面：

第一，精度与速度是可调和的。系统允许根据实际需求进行权衡，如果应用场景可以容忍例如 2% 的精度损失以换取更高的吞吐量，那么就可以采用更激进的替换策略。

如果对精度要求极为严苛，那么系统会减少替换，代价是响应延迟会相应增加。而这本质上是一个面向用户需求的、可配置的权衡。

保留了完整的后备方案。如果系统监测到某次替换可能导致无法接受的精度下降，或者用户明确要求零精度损失，可以立即回退到传统处理方式：要么等待将该专家从 CPU 重新加载到 GPU 进行计算，要么直接在 CPU 上执行。

这两种后备方案都能确保模型的输出精度与原始情况完全一致，只是需要承担相应的性能延迟。目前，该团队已经在 llama.cpp 项目中进行了原型实现和实验验证。

稀疏激活的 MoE 模型（下方）与标准 Transformer 模块（上方）的对比，它通过门控机制（Gate）只激活部分专家（Experts）进行计算，以保持高效和海量知识。

（https://arxiv.org/pdf/2511.10054）

异构计算的一种良好实践

戚正伟表示，这项技术本质上是异构计算的一种实践，在与业界的合作中，业界伙伴也特别关注如何不将计算任务完全绑定在单一硬件（如 GPU 或 XPU）上。从这一点来看，本次方案具有良好的可迁移性，完全能够适配国产硬件生态，因为其核心设计框架与底层硬件架构是解耦的。

图 | 戚正伟（戚正伟）

在本次方案的设计中，CPU 和 GPU 是协同工作的，并非只依赖其中一方。该团队采用了异构融合的计算模式，让两者都参与到推理任务中来。实验数据表明，这种协同带来了整体系统效率的提升。

具体而言，CPU 在这个过程中承担了关键的后勤与调度工作，包括执行专家预取预测、管理伙伴专家列表，以及在替换失败时启动回退方案等，从而能够显著提高 CPU 的利用率。

与此同时，GPU 的利用率也得到了提升。在传统方案中，一旦预取失败，GPU 必须停止计算，等待从 CPU 加载所需专家，从而产生空闲和延迟。

而在本次方案中，GPU 在遇到这种情况时可以直接找到一个替代专家并继续全速进行计算，避免了因等待 I/O 而产生的性能停顿。因此，通过这种 CPU 与 GPU 的协同分工与负载优化，整个系统实现了更高的吞吐率和更低的推理延迟。

后续，该团队将在华为昇腾等具备强大算力的“超级节点”国产硬件上进行更大规模的实验。这样的环境将使其能够验证 BuddyMoE 在复杂多租户场景下的应用潜力。

例如，探索不同模型之间的专家是否也能建立伙伴关系并实现共享，这对于提升整个数据中心集群的资源利用率和推理效率具有重大意义。

参考资料：

相关论文 https://arxiv.org/pdf/2511.10054

运营/排版：何晨龙