要想讓 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 模型共享彼此的專家。就像不同班級的學霸組成了一個超級學霸團，能夠為全校同學答疑解惑。

大模型的大?。t線）相比于顯卡內存的容量（藍線）增長得更快，這更加凸顯了 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

運營/排版：何晨龍