文 | 金銳點
編輯 | 金銳點
現在企業做智能化升級，千億參數模型用起來，不少團隊都犯怵，要麼是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的突破，不是靠簡單的技術疊加，而是從架構設計上找對了方向。
這種思路不僅讓千億參數模型變得抗造又省錢，也為中國大模型產業提供了一條更靈活的路徑，不用再被國外框架的設計局限牽著走。
