中科大团队破解AI大模型推理难题：让专家系统像乐队一样分工协作

这项由中国科学技术大学深圳校区的张哲祥、王烨团队，联合中国电信人工智能研究院、深圳环大湾区研究院等多家机构共同完成的研究，发表于2025年12月的arXiv预印本平台（论文编号：arXiv:2512.13525v2）。有兴趣深入了解的读者可以通过该编号查询完整论文。

当我们提到人工智能的发展，很多人会自然地想到那些能够回答各种问题的聊天机器人。但是，支撑这些智能系统运行的底层技术——大型语言模型，正面临着一个非常现实的挑战：如何在保证响应速度的同时，高效地利用计算资源。特别是那些被称为"专家混合模型"（Mixture-of-Experts，简称MoE）的先进架构，就像一个拥有众多专业技能的超级团队，虽然能力强大，但管理起来却异常复杂。

研究团队敏锐地观察到，现有的AI模型推理系统就像一个管理混乱的大公司，所有部门都被强制使用相同的资源配置，无论是负责"理解"的注意力机制部门，还是负责"专业处理"的专家网络部门。这种一刀切的管理方式导致了严重的资源浪费，就好比让搬运工和工程师使用完全相同的工具和工作空间一样不合理。

为了解决这个问题，研究团队开发了一个名为JANUS的创新系统。JANUS这个名字来源于古罗马神话中双面神雅努斯，象征着这个系统能够同时面向两个不同的处理任务——注意力计算和专家网络计算，并为它们提供最适合的资源配置。

一、专家混合模型的运行挑战

要理解JANUS系统的创新之处，我们首先需要了解专家混合模型的工作原理。想象一个大型咨询公司，公司里有数百名不同领域的专家，比如金融专家、法律专家、技术专家等等。当客户提出一个复杂问题时，公司不需要让所有专家都参与，而是选择最相关的几位专家来处理。

专家混合模型就是按照这个思路设计的。以目前最先进的DeepSeek-V3模型为例，它拥有256个专家，每处理一个词语时，只需要激活其中最相关的几个专家。这种设计的巧妙之处在于，模型的总容量非常庞大，但每次实际工作的部分相对较小，就像一个拥有众多专家的咨询公司，虽然专家库很大，但每个项目只需要动用部分专家。

然而，这种设计带来了三个主要挑战。首先是内存压力巨大。就像咨询公司需要为所有专家准备办公室一样，即使某个专家暂时不工作，他的办公空间也不能被其他人占用。研究数据显示，在DeepSeek-V3这样的模型中，专家参数占据了整个模型内存的93.7%，需要至少16块H100 GPU才能完整加载。

其次是工作负载的动态变化。在真实的应用场景中，用户的请求就像潮水一样起伏不定，有时是高峰期，有时是低谷期，而且每个请求的复杂程度也不相同。现有系统很难灵活应对这种变化，往往只能按照最高负载需求来配置资源，导致在低负载时期出现大量资源闲置。

第三个挑战是注意力计算和专家网络计算的需求完全不同。注意力机制就像是企业的总经理，需要统览全局，协调各部门的工作，它的计算特点是需要处理大量相互关联的信息。而专家网络更像是专业技术人员，每个专家专注于自己的领域，计算特点是内存密集型的。把这两类完全不同的工作放在相同的环境下，就像让总经理和技术工程师共用一间办公室，效率自然不高。

研究团队通过深入的性能分析发现了一个重要规律：在目前的在线推理场景中，专家网络的执行时间几乎完全取决于同时激活的专家数量，而不是具体激活了哪些专家或者处理多少数据量。这个发现就像发现了生产线的关键瓶颈，为后续的优化指明了方向。

二、JANUS系统的分工协作架构

基于对问题的深入理解，研究团队设计了JANUS系统的核心理念：让注意力计算和专家网络计算各自在最适合的环境中工作，就像让不同类型的员工在最适合他们的办公环境中发挥最大效能。

JANUS系统采用了分离式架构设计，将整个GPU集群分为两个专门的子集群。注意力子集群专门负责处理注意力计算和管理用户对话的历史记录，就像公司的管理部门，需要保持对全局信息的掌控。专家子集群则专门运行各种专业的专家网络，就像公司的技术部门，每个GPU负责托管多个专家。

这种分离带来了显著的灵活性提升。过去，系统只能以整个模型为单位进行扩缩容，就像只能整体搬迁整个公司。现在，系统可以根据实际需求独立调整两个子集群的规模。当用户请求增多但问题相对简单时，可以主要扩展注意力子集群；当请求涉及复杂专业问题时，可以重点扩展专家子集群。这种精细化的资源管理使得系统的资源利用率大大提升。

为了让两个子集群能够高效协作，JANUS设计了一套巧妙的通信机制。传统的做法就像每个部门的每个员工都要和其他部门的所有人直接沟通，这会造成信息传递的混乱。JANUS采用了"两阶段通信"的方法，先让同一个节点内的多个实例进行内部整合，然后再进行跨节点的批量传输。这就像先在部门内部开会统一意见，然后派代表参加跨部门会议，大大减少了沟通成本和时间延迟。

更巧妙的是，JANUS会根据实际的通信需求自适应地选择不同的传输策略。当目标节点较少时，采用直接传输；当需要大量数据交换时，则采用中转传输。这种自适应机制确保了在各种工作负载下都能保持最优的通信效率。

三、智能负载均衡调度算法

JANUS系统面临的一个关键挑战是如何在微秒级的时间内做出最优的专家调度决策。这就像是一个超级繁忙的调度中心，需要在极短时间内决定哪些专家处理哪些任务，既要保证工作质量，又要避免某些专家过度劳累而其他专家闲置。

系统采用了一种名为"激活专家均衡调度"的算法。这个算法的核心思想是尽可能让每个GPU上同时运行的专家数量保持均衡，从而避免出现某个GPU因为专家过多而成为整个系统的瓶颈。

调度过程就像一个高效的任务分配流水线。首先，系统会快速扫描一批待处理的数据，识别出需要哪些专家参与。然后，对于那些只有一个副本的专家，系统会直接分配给对应的GPU，没有选择余地。对于有多个副本的专家，系统会选择当前负载最轻的GPU来处理，这样可以保持整体负载的均衡。

最后，系统会将原本的逻辑专家请求转换为具体的物理专家分配，并将任务分发给相应的GPU进行并行处理。整个过程就像一个经验丰富的项目经理在短时间内完成了任务分解、资源评估和人员分配的全过程。

为了达到微秒级的调度速度，JANUS做了两个重要的设计决策。第一是将调度算法实现为GPU内核程序，这样可以避免CPU和GPU之间的数据传输延迟，就像把决策权直接下放到现场，避免了层层汇报的时间消耗。第二是采用完全分布式的调度方式，每个GPU都独立运行相同的调度算法，由于算法是确定性的，所有GPU会得出相同的调度结果，这样既避免了跨GPU的通信协调开销，又保证了调度的一致性。

研究团队的测试结果表明，即使在处理512个并发请求的高负载情况下，JANUS的调度开销仍然保持在100微秒以下，相比于专家网络几百微秒的执行时间，这个开销几乎可以忽略不计。

四、动态专家管理和资源优化

除了实时的负载调度，JANUS还实现了一套长期的专家管理策略，就像一个智能的人力资源管理系统，能够根据业务需求的变化来调整专家团队的配置。

系统会持续监控每个专家的使用频率，发现一些专家经常被需要，而另一些专家很少被调用。基于这个观察，JANUS会为热门专家创建更多副本，就像为受欢迎的医生安排更多坐诊时间。同时，对于那些经常同时被需要的专家组合，系统会尽量将它们分散到不同的GPU上，避免某个GPU因为承担过多相关专家而成为瓶颈。

这种动态调整不仅考虑了专家的受欢迎程度，还考虑了专家之间的协作模式。比如，如果金融专家和法律专家经常需要为同一个项目协作，系统就会确保不要把它们都放在同一个GPU上，这样可以提高整体的并行处理能力。

在资源扩缩容方面，JANUS实现了真正的细粒度管理。传统系统只能以完整模型为单位进行扩缩容，就像只能整栋楼一起租或退租。JANUS可以独立调整注意力子集群和专家子集群的规模，甚至可以在实例级别进行调整，就像可以独立调整办公室的数量而不影响整栋楼的运营。

这种灵活性的价值在实际应用中非常明显。研究团队通过模拟真实工作负载发现，相比于传统的整体扩缩容方式，JANUS的细粒度资源管理可以节省25%的GPU使用量，同时保持相同的服务质量。

五、性能评估和实际效果

为了验证JANUS系统的实际效果，研究团队进行了大量的实验测试。他们使用了包括DeepSeek-V2在内的多个主流专家混合模型，在不同规模的GPU集群上进行了对比测试。

测试结果令人印象深刻。在保证相同服务质量的前提下，JANUS系统相比传统的SGLang系统实现了最高3.9倍的单GPU吞吐量提升。这个提升主要来自于两个方面：一是更高效的资源利用，二是更智能的负载均衡。

具体来说，在处理轻负载任务时，JANUS会选择最小的注意力配置（比如1个注意力实例配6个专家实例），将更多GPU资源集中用于专家处理，从而获得更高的吞吐量。随着负载增加，系统会逐步增加注意力实例的数量，始终保持最优的资源配置比例。

在通信优化方面，JANUS的两阶段通信机制相比直接通信减少了18%的延迟。这个改进在高负载情况下尤为明显，因为此时跨节点的通信量很大，传统的多对多通信会产生严重的网络拥塞。

负载均衡调度的效果也很显著。测试显示，在没有JANUS调度算法的情况下，不同GPU上激活专家数量的差异可能达到8个，而使用JANUS后，这个差异降低到4个左右，有效减少了系统中的性能瓶颈。

更重要的是，JANUS在长期运行中展现出了出色的适应性。研究团队使用真实的工作负载数据进行了为期两天的模拟测试，发现JANUS能够根据负载的日常变化动态调整资源配置，相比固定配置的传统系统节省了25%的GPU资源消耗。

六、技术突破的意义和未来展望

JANUS系统的成功不仅仅是一个技术优化的成果，更重要的是它代表了AI推理系统设计思路的重要转变。从过去的"一刀切"资源管理，转向"因材施教"的精细化管理，这个转变对整个AI产业都有重要意义。

随着AI模型规模的不断增长，如何高效地利用计算资源已经成为制约AI普及和发展的关键因素。JANUS提供的解决方案表明，通过深入理解不同计算模块的特性，并为它们提供量身定制的运行环境，可以显著提升整体系统的效率。

这种设计思路也为未来的AI系统架构提供了新的启发。研究团队指出，JANUS的核心技术可以很容易地扩展到其他类型的AI模型中，比如支持不同的并行策略组合，或者适应异构硬件环境。在异构硬件环境中，注意力计算可以分配给计算能力强的GPU，而专家网络可以分配给内存容量大的GPU，进一步优化资源利用效率。

研究团队还提到了JANUS与其他AI优化技术的兼容性。比如，可以将预处理和解码阶段的分离技术与JANUS结合，在每个阶段内部再进行注意力和专家的分离，形成更加精细的优化策略。同样，微批处理技术也可以很自然地集成到JANUS中，通过流水线方式让注意力和专家模块并行工作在不同的微批次上。

从产业发展的角度来看，JANUS系统解决的问题具有很强的现实意义。当前，训练和部署大型AI模型需要巨大的计算资源投入，这不仅推高了AI服务的成本，也限制了技术的普及范围。JANUS这样的优化技术可以显著降低AI服务的运营成本，使更多的企业和开发者能够负担得起先进的AI能力。

归根结底，JANUS系统的成功证明了一个重要观点：在AI技术快速发展的今天，系统级的优化创新同样重要。通过深入理解AI模型的工作特性，设计出更加智能和高效的运行框架，我们可以在不改变模型本身的情况下获得显著的性能提升。这种"软硬结合"的优化思路，为AI技术的持续发展和普及应用开辟了新的道路。

这项研究的成果已经在开源社区中得到了应用，基于SGLang框架的JANUS实现为其他研究者和开发者提供了实用的工具。随着更多团队对这类技术的关注和改进，我们有理由相信，未来的AI推理系统将变得更加高效、灵活和经济，为AI技术的广泛应用创造更好的条件。

Q&A

Q1：JANUS系统是如何提高AI模型推理效率的？

A：JANUS通过将注意力计算和专家网络分离到不同的GPU子集群来提高效率。就像让不同类型的员工在最适合的环境中工作，注意力部分专门处理全局协调，专家部分专门处理专业任务，避免了传统系统中所有组件必须使用相同资源配置的浪费问题，从而实现最高3.9倍的性能提升。

Q2：JANUS的两阶段通信机制是怎么工作的？

A：JANUS的两阶段通信就像公司内部先开部门会议再开跨部门会议。第一阶段，同一节点内的多个实例先进行内部数据整合，第二阶段再进行跨节点的批量传输。这样可以减少小数据包的传输次数，降低网络延迟18%，特别是在高负载情况下效果更明显。

Q3：为什么JANUS能节省25%的GPU资源？

A：JANUS实现了细粒度的资源管理，可以独立调整注意力和专家模块的资源配置，而不是像传统系统那样必须整体扩缩容。当工作负载变化时，系统可以精确地只增加需要的部分，避免过度配置。通过智能的专家调度和动态资源分配，在保持相同服务质量的前提下显著减少了资源浪费。