概念地圖・專家混合路由
作者 山姆（謝冠生）・喵喵書評創辦人
發布
分類：創新
這一頁不只是把一個概念解釋一遍——一張自己畫的結構圖，加上拿台灣情境從頭走一次的實例演練、這個框架什麼時候會騙你，以及它接回 P.A.I.N. 之後長什麼樣。一頁必須交付的三層 →
專家混合路由：讓每個輸入選路合流
手術衣代工廠整理多語客戶詢問時，工程師把一段輸入的路由記錄打開，四個專家編號裡只有兩個亮起。這是下面教育演練的起點。專家混合路由讓可訓練的閘控網路，替進入某一層的 token 表示選出少數子網路，再把輸出加權合流。模型可以容納更多參數，每次只動用其中一部分——省下的運算很誘人，分支有沒有塞車、整段回覆有沒有變快，也得一起看。
一個輸入怎麼選路、再合流
稀疏閘控 MoE 論文對專家子網路與加權輸出的說明，給了這張圖的基本結構：閘控網路可訓練、專家各有參數、輸出依閘控權重相加。以下採用一種 top-2 的簡化教學設定，實際模型的選取與正規化方式要另查。
| 圖上的位置 | 這一步做什麼 | 讀記錄時留意 |
|---|---|---|
| 單一 token 表示 | 送入該層的是一個位置的向量表示。 | 一個中文字與一個 token 沒有固定的一對一關係。 |
| 路由器 | 根據輸入計算路由分數，選取兩個分支。 | 相鄰 token、不同層，選擇都可能改變。 |
| E2、E4 | 兩個可訓練子網路各自處理同一個輸入表示。 | 編號只標示參數分支，語意專長需額外驗證。 |
| 加權合併 | 本例將選中權重重正規化為 60% 與 40%，再合成輸出。 | 這兩個比例不代表答案正確率或可信度。 |
| 下一層表示 | 合流結果繼續送往後續運算。 | 整個模型還包含其他層與部件，圖中只畫局部。 |
「混合」發生在向量輸出上。四個專家也各自是一段神經網路，無須替它們冠上人類學科名稱。圖中留下灰框，是提醒你模型持有的參數容量仍然存在——某一筆輸入只動用其中幾組。
驗路由時需要的觀察紀錄
一、先確認路由粒度。工廠的教育工作坊把客戶詢問送進斷詞器後，應保留 token 序列、位置及所在層。若工程師只截一張亮燈圖，業務容易以為整封信都交給同兩個分支。把記錄往下一個位置翻，才能看見選擇有沒有改變——鏡頭要對準一筆可追蹤的運算。自問：我記錄的選擇，對應哪個輸入單位與哪一層？
二、拆開總量與啟用量。代工廠比較內部助理的部署方案時，可以在同一張筆記上分欄記總參數、每個 token 啟用的參數，以及機器要容納的權重。計算少了一部分，權重仍需要存放與調度；規格書上只有一個漂亮的大數字，採購就少了一半視野——先讓供應方補齊口徑。自問：總參數與單次啟用量，各自採什麼計算範圍？
三、留下負載分布。拿廠內常見的多語詢問做測試，按一批輸入統計每個分支接到多少 token，並記容量限制及超量時的處理方式。少數專家若長期擠滿，平均利用率看起來平穩，也可能藏著局部等待——需要查看忙碌分支的時間線。單次的 60% 與 40% 是合流權重，負載則要跨多個 token 累計。自問：輸入集中在哪些分支，超過容量時會怎麼處理？
四、量完使用者的等待。替業務測詢問草稿時，把從送出到完整回覆的時間留下，連同輸入長度、輸出長度、同時進來的工作量一起記。若專家分散在不同裝置，資料搬運也會進入等待。把這些條件固定後再比較——桌面上那圈轉動的小圖示，才是同事每天會感受到的延遲。自問：相同工作條件下，端到端延遲與回覆品質如何變化？
手術衣代工廠讀一份推論記錄
底下這家台灣中部的手術衣代工廠，是為了把這個結構講清楚而編出來的示意情境，沒有指涉任何真實公司。接回開頭的路由記錄，工程師在內部 AI 教育工作坊拿出一份已斷詞的假想輸入片段。投影幕上新增的是分數、權重與兩維向量，所有數字都供課堂演算；輸出沒有醫療或產品合規判決效力。
- 先把一個位置停住：在四個專家的某一層，這個 token 的路由分數依序是 E1＝0.10、E2＝0.42、E3＝0.20、E4＝0.28。此處分數視為選取前已正規化的非負權重，總和為 1。挑出最大的兩個，就得到 E2 與 E4。先固定層與位置，大家才在讀同一筆記錄。
- 把留下的權重重新分配：選中者總和為 0.42＋0.28＝0.70。E2 的新權重是 0.42÷0.70＝0.60，E4 則是 0.28÷0.70＝0.40。它們加起來為 1，對上圖中的 60% 與 40%。權重較大，只代表這次合流占比較大。
- 手算一次向量合流：假想 E2 輸出為（2，7），E4 輸出為（9，1）。第一維是 2×0.6＋9×0.4＝4.8；第二維是 7×0.6＋1×0.4＝4.6，合成向量為（4.8，4.6）。兩維只是可算的教具，沒有直接對應交期、品質或客戶意圖。每個維度各自加權，再送往後續層。
- 把鏡頭拉回整段：假設片段共有 6 個 token，且每個都選 2 個專家，這一層共有 6×2＝12 次專家指派；在同樣條件下，四個全算則是 6×4＝24 次。這裡計的是指派次數，各分支可以在硬體上批次處理。12 次與 24 次的差值，不能直接換成總耗時或整體成本減半。
這場工作坊最該留下的，是每個數字都能往前追到一個運算位置。0.42 要追到選取前分數，0.60 要追到重正規化，4.8 要追到第一維的加權和；最後才輪到完整回覆花了多久。工程師可以把這張手算紙貼在測試記錄旁，讓同事提問時知道自己正在問分數、向量還是等待時間——名稱一混在一起，供應方的效能宣稱就很難核對。接下來的測試應另用真實輸入與業務可接受的回覆標準。以上為說明結構用的示意情境，僅供理解框架之用。
稀疏分流什麼時候會騙你
- 替專家編號取名太早。E2 常被某種句型叫到，可以成為研究線索；要宣稱它懂某類業務，還需要測試資料與穩定表現。尤其同一個請求會經過多層路由，光看一層亮燈，很難把整段錯答歸給某個編號——把名稱留作索引，先查相似輸入在不同條件下的結果。
- 把稀疏程度當成秒數折扣。熱門分支可能集中排隊，跨裝置還要搬送向量。論文也討論了分批計算與通信造成的效能限制。實際部署要把負載、容量及分派耗時一起記——少跑幾組參數後，剩下的等待可能挪到另一個地方。
- 以為未啟用的權重消失了。模型仍需要存放全部專家的權重，或設計相應的載入與分派機制；選兩個分支只描述這次運算。若硬體記憶體吃緊，載入策略與裝置配置都會牽動速度——評估部署時，把記憶體需求、通信量與單次啟用量各自列出，才有可以核對的代價。
忙碌的分支要有人查
少算一次，也就少走了一組參數。
把運算稀疏化，會替每筆輸入決定可走的路徑。這個選擇值得工程師追，也值得業務用失敗情境回問。《痛點》的 P.A.I.N. 追問先落在現場：同事為哪種回覆重打了一段話，客戶因哪次錯解多等一輪確認。這張圖畫得出分支與合流，畫不出一段錯答讓客戶多忙了多久。若某批詢問反覆卡住，把錯誤類型、路由分布與排隊時間放在同一筆記錄裡，再查看是否只是同時出現；路由集中本身還不足以證明錯答原因。一次只調整可比較的條件——今晚先挑一段已去識別的詢問，請工程師與業務一起標出最早偏離需求的那一句，存下當時的測試版本。
專家混合，常見問題
MoE 的專家真的各懂一個領域嗎？
專家指可訓練的子網路，名稱來自模型結構。訓練後可能出現某些分工傾向，是否對應人類熟悉的知識領域，需要另做分析。拿工廠詢問來說，看到某分支持續啟用，先記下語言、句型與位置，再用不同樣本測它——替分支起一個很有說服力的名字，無法取代品質驗證。
top-2 代表每次只用兩個模型回答嗎？
本頁的 top-2 表示一個 token 在這個 MoE 層選兩個專家子網路，兩者輸出加權後還會繼續運算。它們屬於同一模型內的分支。整段輸入包含多個 token，後面也可能經過其他 MoE 層——請先問清楚供應方說的「兩個」是在哪一層、以什麼單位計數，才有共同討論的範圍。
啟用參數少，推論一定更快、更便宜嗎？
少啟用一些參數，提供了節省部分計算的空間；使用者實際等多久，還受硬體、負載分布、資料搬運及其他模型部件影響。測試時固定請求長度與工作量，同時記完整延遲和答案品質。成本比較也應納入部署需求——把一次回覆的帳算完，再判斷這種結構適不適合你的使用情境。
評估部署方案時，請供應方把權重存放、跨裝置傳輸與尖峰等待分開列出。接著可用關注位置與資訊加權辨認圖外的注意力運算，再沿著使用資料帶來的學習回饋，檢查這些測試紀錄如何回到下一輪改善。
喜歡這篇文章嗎？
每週幫你拆二本好書，把判斷力、好書金句、好問題，直送你的信箱。
不適合你可隨時退訂 · 每週兩封，陪你把書讀進生活。
送出即表示同意我們依隱私權政策使用你的 email。