要问最近哪个模型最火，混合专家模型（MoE，Mixture of Experts）绝对是榜上提名的那一个。
它的巧妙之处，就在于把不同的任务分配给擅长处理的专家网络，让整个系统性能得以提升。
但你知道吗?
正是这个关键的专家网络，也是严重影响系统推理性能的因素之一。
因为在大量任务来临之际（尤其是超大规模时），MoE并不是以“雨露均沾”的方式去分配——专家网络们的负载均衡问题，就会显得尤为突出。
这个问题的根源，是因为某些专家网络总是被频繁调用（热专家），而另一些专家网络则鲜有机会派上用场（冷专家）。
没错，MoE里的“专家们”也是有冷热之分的，而且被调用频率的差距甚至可以达到一个数量级以上!
如此负载不均衡的现象，就会导致整个系统推理的时间被延长，以及还有资源利用率、系统性能受限等问题。
那么此局又该如何破解?
别急，华为团队已经给出了一种有效解法，直接让DeepSeek-V3在理论上的推理延迟可降低约10%、吞吐量可提升约10%。
值得一提的是，团队还将在近期准备把这个解法全面开源了;那么接下来，我们就来深入了解一下。
针对专家们冷热不均的问题，华为优化的刀法，叫做OmniPlacement。
简单来说，它的工作原理是这样的:
通过专家重排、层间冗余部署和近实时动态调度，显著提升MoE模型的推理性能。
具体可以分为三步走:
在这一步中，华为团队通过分析专家的活跃度（激活数据），先是识别出了忙碌的热专家和清闲的冷专家。
然后将提出的一种基于计算均衡的联合优化算法OmniPlacement用了上去。
这个算法会根据专家调用频率和计算需求来优化部署的顺序，这样就会显著降低负载不均的现象。
具体来说，OmniPlacement算法的特点如下:
刚才的步骤是面向冷热专家整体，那么这一步则是剑指热专家。
为了缓解热专家的压力，华为团队还提出了一种层间冗余部署的策略——
通过为高频调用专家分配额外的冗余实例，降低跨节点通信开销，从而提升系统吞吐量。
这个策略的创新点在于:
为了让系统能更灵活地应对各种变化，在实际运行中快速做出反应，研究团队设计了一套类似 “智能管家” 的方案——
近实时调度与动态监控机制。
其具体包含的子模块如下:
这套机制通过两个关键设计大幅提升了系统性能:
首先采用多任务并行处理技术，让系统反应更快、调整更灵活;其次独创性地将监控和调度功能分开运行。
这样既保证了实时监控的准确性，又避免了监控程序拖慢系统速度，使整个系统运行更加稳定可靠。
为了支持上述技术的稳定运行，团队还开发了适用于vLLM的推理优化框架OmniPlacement，其核心特点如下:
OmniPlacement采用模块化设计，把核心算法和推理流程分开处理，就像把汽车的发动机和控制系统分开优化一样。
这样设计有两个突出优势:
一是专门负责任务调度的模块可以独立工作，不会干扰主系统的运行效率;二是整个框架可以根据不同需求灵活调整，为大型AI模型的稳定运行提供了坚实的底层支持。
在了解完华为的“刀法”之后，我们再来看下“疗效”。
华为团队把这套优化方法在DeepSeek-V3上进行了全面验证，实验环境包括多节点GPU集群和高并发推理场景。
得到了如下的测试结果:
进一步的分析表明，OmniPlacement在不同规模的MoE模型和输入数据分布下均表现出良好的适应性。
并且从实际测试证明来看，它不仅能大幅提升运算效率，还能更合理地利用计算资源，同时保持系统稳定运行。
这为今后在实际应用中部署大型MoE模型提供了坚实的技术保障。
最后值得一提的是，华为团队不仅是发布优化方案这么一个动作，更是要将这个方法在近期全面开源。
完整技术报告:
https://gitcode.com/ascend-tribe/ascend-inference-cluster/blob/main/OmniPlacement/OmniPlacement-%E6%98%87%E8%85%BE%E8%B6%85%E5%A4%A7%E8%A7%84%E6%A8%A1MoE%E6%A8%A1%E5%9E%8B%E6%8E%A8%E7%90%86%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E6%8A%80%E6%9C%AF%E6%8A%A5%E5%91%8A.pdf
技术博客:
https://gitcode.com/ascend-tribe/ascend-inference-cluster/blob/main/OmniPlacement/ascend-inference-cluster-omniplacement.md
（举报）
要问最近哪个模型最火，混合专家模型（MoE，Mixture of Experts）绝对是榜上提名的那一个。
它的巧妙之处，就在于把不同的任务分配给擅长处理的专家网络，让整个系统性能得以提升。
但你知道吗?
正是这个关键的专家网络，也是严重影响系统推理性能的因素之一。
因为在大量任务来临之际（尤其是超大规模时），MoE并不是以“雨露均沾”的方式去分配——专家网络们的负载均衡问题，就会显得尤为突出。
这个问题的根源，是因为某些专家网络总是被频繁调用（热专家），而另一些专家网络则鲜有机会派上用场（冷专家）。
没错，MoE里的“专家们”也是有冷热之分的，而且被调用频率的差距甚至可以达到一个数量级以上!
如此负载不均衡的现象，就会导致整个系统推理的时间被延长，以及还有资源利用率、系统性能受限等问题。
那么此局又该如何破解?
别急，华为团队已经给出了一种有效解法，直接让DeepSeek-V3在理论上的推理延迟可降低约10%、吞吐量可提升约10%。
值得一提的是，团队还将在近期准备把这个解法全面开源了;那么接下来，我们就来深入了解一下。
针对专家们冷热不均的问题，华为优化的刀法，叫做OmniPlacement。
简单来说，它的工作原理是这样的:
通过专家重排、层间冗余部署和近实时动态调度，显著提升MoE模型的推理性能。
具体可以分为三步走:
在这一步中，华为团队通过分析专家的活跃度（激活数据），先是识别出了忙碌的热专家和清闲的冷专家。
然后将提出的一种基于计算均衡的联合优化算法OmniPlacement用了上去。
这个算法会根据专家调用频率和计算需求来优化部署的顺序，这样就会显著降低负载不均的现象。
具体来说，OmniPlacement算法的特点如下:
刚才的步骤是面向冷热专家整体，那么这一步则是剑指热专家。
为了缓解热专家的压力，华为团队还提出了一种层间冗余部署的策略——
通过为高频调用专家分配额外的冗余实例，降低跨节点通信开销，从而提升系统吞吐量。
这个策略的创新点在于:
为了让系统能更灵活地应对各种变化，在实际运行中快速做出反应，研究团队设计了一套类似 “智能管家” 的方案——
近实时调度与动态监控机制。
其具体包含的子模块如下:
这套机制通过两个关键设计大幅提升了系统性能:
首先采用多任务并行处理技术，让系统反应更快、调整更灵活;其次独创性地将监控和调度功能分开运行。
这样既保证了实时监控的准确性，又避免了监控程序拖慢系统速度，使整个系统运行更加稳定可靠。
为了支持上述技术的稳定运行，团队还开发了适用于vLLM的推理优化框架OmniPlacement，其核心特点如下:
OmniPlacement采用模块化设计，把核心算法和推理流程分开处理，就像把汽车的发动机和控制系统分开优化一样。
这样设计有两个突出优势:
一是专门负责任务调度的模块可以独立工作，不会干扰主系统的运行效率;二是整个框架可以根据不同需求灵活调整，为大型AI模型的稳定运行提供了坚实的底层支持。
在了解完华为的“刀法”之后，我们再来看下“疗效”。
华为团队把这套优化方法在DeepSeek-V3上进行了全面验证，实验环境包括多节点GPU集群和高并发推理场景。
得到了如下的测试结果:
进一步的分析表明，OmniPlacement在不同规模的MoE模型和输入数据分布下均表现出良好的适应性。
并且从实际测试证明来看，它不仅能大幅提升运算效率，还能更合理地利用计算资源，同时保持系统稳定运行。
这为今后在实际应用中部署大型MoE模型提供了坚实的技术保障。
最后值得一提的是，华为团队不仅是发布优化方案这么一个动作，更是要将这个方法在近期全面开源。
完整技术报告:
https://gitcode.com/ascend-tribe/ascend-inference-cluster/blob/main/OmniPlacement/OmniPlacement-%E6%98%87%E8%85%BE%E8%B6%85%E5%A4%A7%E8%A7%84%E6%A8%A1MoE%E6%A8%A1%E5%9E%8B%E6%8E%A8%E7%90%86%E8%B4%9F%E8%BD%BD%E5%9D%87%E8%A1%A1%E6%8A%80%E6%9C%AF%E6%8A%A5%E5%91%8A.pdf
技术博客:
https://gitcode.com/ascend-tribe/ascend-inference-cluster/blob/main/OmniPlacement/ascend-inference-cluster-omniplacement.md
（举报）
