文 | 金锐点

编辑 | 金锐点

现在企业做智能化升级，千亿参数模型用起来，不少团队都犯怵，要么是GPU突然出故障，整个推理服务直接停摆。

要么是资源调不动，明明流量降了，GPU还得整组租着，白浪费钱，最近中国团队研发的EaaS框架，正好解决了这些麻烦，也打破了国外同类框架的局限。

哪怕有GPU损坏，千亿参数模型的推理照样能跑，效率只降不到2%，还能比国外主流框架省37.5%的GPU资源。

同样是跑大模型推理，为啥国外框架总显得娇贵，一遇问题就卡壳？EaaS又是怎么做到让模型抗造又省钱的？

其实大模型参数越做越大，从百亿冲到千亿甚至万亿，推理时的计算开销也跟着指数级涨，怎么在保性能的同时降成本，成了行业里的大问题。

MoE架构本来是个好办法，把模型拆成大量“专家”子模型，每个输入数据只激活少数专家干活，不用让所有“专家”都启动。

这样一来，模型参数能提上去，推理计算量却不用同步增加，刚好能支撑千亿参数的规模。

但国外主流的MoE推理框架，在实际用的时候却有不少局限，具体来看，扩展性就是个大问题。

这些框架大多要把几十块甚至上百块GPU绑成大规模同步通信组才能用，有点像租办公室只能整层租，哪怕只用一半空间，也得付整层的钱。

这种方式根本没法跟着用户流量灵活调资源，流量高峰想加GPU，得整组加，不能单块加。

流量低谷想减资源，也得整组减，剩下的GPU只能空转，资源浪费特别明显，容错性更让人头疼。

国外框架靠All-to-All这类集体通信让GPU协同工作，就像一群人拔河攥着同一根绳，只要一个人松手，整队都没法继续，随便一块GPU节点出故障，整个服务集群都得重启，推理业务直接中断。

之前有实验对比过，用国外的SGLang+DeepEP、vLLM+DeepEP这些框架，只要有一块GPU故障，整个集群就没法继续推理，服务只能停着等修复。

还有负载不均的问题，MoE里的专家被哪个输入激活是动态的，全看数据内容，有时候某几个专家会被频繁调用，对应的GPU忙到过载，计算延迟越来越高。

有时候另一些专家很少被激活，对应的GPU长期闲置，资源利用效率低得厉害。

但国外框架的专家和GPU是固定绑定的，没法跟着负载变化调整，只能看着忙的忙死、闲的闲死，没什么好办法。

为啥国外框架始终跳不出这些局限？说到底，是对“专家”层的认知没到位，其实“专家”层本质是无状态的。

它只根据输入数据做纯函数计算，不依赖之前的处理记录，就像计算器，算完一次不会记住上一次的数字。

但国外框架却把它当成有状态的整体来管理，非要把所有专家、Attention层绑在一个紧密的系统里。

后来也有研究想把Attention层和专家层拆开部署，可还是没跳出整体化的思路，扩展性、容错性的问题还是没解决。

中国团队的EaaS框架，没沿着国外的老路走，而是从专家层无状态这个特性切入，把整个推理系统的形态都改了。

不再是一个紧耦合的大应用，而是多个独立的无状态服务，就像把原来的大工厂拆成一个个小车间，每个车间独立干活，互不影响。

这种专家即服务的设计，正好戳中了国外框架的局限，从根上解决了问题。

把每个专家都被拆成了独立的服务模块，不用再依赖全局同步通信组，Attention层通过gating机制，需要哪个专家就调用哪个，想用多少块GPU启动专家服务都灵活。

初始部署时16块GPU就能起步，后续流量涨了，加一块GPU也行，流量降了，减一块GPU也没问题，完全能跟实际负载精准匹配。

Attention层和专家层被彻底解耦，也不再挤在同一组计算节点里，两者通过专门的通信机制衔接，Attention层不用等专家层算完结果再处理下一批数据，反而能异步等待，同时着手处理新的数据。

为了让这种解耦架构跑得顺畅，EaaS还做了两个关键技术支撑，一个是基于InfiniBand GPUDirect Async的通信库。

能让GPU直接通过网卡收发数据，完全不用经过CPU协调，相当于快递员直接跟客户对接，不用经过中介，通信速度快了不少。

再结合CUDAGraph技术减少内核启动开销，通信和计算能同步进行，不会拖慢整体速度。

另一个是动态负载均衡机制，系统有个中央监控组件，实时盯着每个“专家”的调用频率。

要是某个专家成了热专家，调用太频繁，就自动加几个实例帮它分摊，要是某个专家成了冷专家，就减几个实例省资源，彻底解决了忙闲不均的问题。

在容错性上，EaaS更是直接避开了国外框架的短板，因为是客户端-服务端的松耦合模式，不用依赖集体通信。

某块GPU上的专家服务出故障了，中央监控会马上通知Attention客户端，切换到这个专家的其他备用实例，不用重建整个通信组，服务一点都不耽误。

扩展能力上，当GPU节点从32块增加到64块时，EaaS的总吞吐量几乎跟着翻倍，完全线性增长。

对比下来，同样的推理性能，EaaS能比国外静态架构省37.5%的GPU资源，对企业来说，这就是实实在在的成本节省。

更关键的是，EaaS在吞吐和延迟的平衡上，也没输给国外最优框架，它既能保持跟国外框架相当的推理吞吐量。

每个token的平均生成延迟还能维持在低水平，不会出现要么快但延迟高，要么稳但吞吐量低的情况，刚好满足企业对效率和体验的双重需求。

对整个行业来说，EaaS的价值不只是解决了当下的痛点，更在于它打破了国外框架的局限，让千亿参数模型真的摆脱了娇贵标签。

对云服务商而言，能根据实时负载灵活调配GPU资源，不用再让算力闲置，对用大模型的企业来说，故障时服务不中断，资源成本还能降，可靠性和经济性都有了保障。

而且这种专家服务化的架构，还特别适合云端大模型推理和模型即服务场景，专家服务可以独立升级维护，比如更新某个专家的算法，不用重启整个系统。

通信调度组件也能慢慢优化，不用像国外框架那样，改一点就得动全局，EaaS的突破，不是靠简单的技术叠加，而是从架构设计上找对了方向。

这种思路不仅让千亿参数模型变得抗造又省钱，也为中国大模型产业提供了一条更灵活的路径，不用再被国外框架的设计局限牵着走。