AI-LECTURER 速報課|2026-10-02|約 25 分鐘

47B 的模型只花 3.2B 的力氣:Olmo-core 3 如何讓「專家團隊」大到兆級還跑得快

📍 真實場景
阿哲,大學實驗室的碩士生,實驗室只有 8 張 GPU 的小叢集

他想訓練一個比現有模型更聰明的語言模型,老師建議改用「混合專家」架構,因為聽說參數多、卻不用每次全部計算

😖 卡住的地方:他讀到的說法是「專家越多越強」,但也聽學長說專家一多,GPU 之間搬資料搬到比算還久,最後反而更慢。他不知道這兩個說法哪個才對,也不知道自己該不該相信「用得起的開源工具」真的能做到
💡 這課用 Ai2 公布的真實數字,帶你算出「專家從 8 個變 128 個,為什麼速度只掉不到 5%」,並用一支能在你電腦直接跑的小程式親手驗證這個算術

🧭 這到底是什麼(白話版)

Ai2 這次釋出的 Olmo-core 3,是一套用來訓練大型語言模型的開源框架,也就是一套 訓練框架把『怎麼把一個超大模型切開、分給很多張顯示卡一起學習』這件事寫好的工具箱。這一版的重點,是重新設計了訓練 混合專家模型簡稱 MoE,模型裡有很多個各有專長的小腦袋,每次只叫出其中幾個來工作 的系統。

MoE 的好處是:模型可以放很多 參數模型學到的知識所存放的數字,越多通常代表能記住越多東西,但每處理一個 token語言模型一次處理的最小文字單位,大約是一個字或半個單字,只會用到其中一小部分。素材裡的實測是:把專家從 8 個增加到 128 個,每個 token 仍然只挑 4 個專家,平均啟用的參數大約固定在 3.2B,總參數卻從 4.6B 長到 47B,訓練速度(throughput)只掉不到 5%。同一套基礎架構也已經測過超過一兆(1T)總參數。

但 MoE 有隱藏成本:整個模型仍然要放在 GPU 記憶體顯示卡上的專用記憶體,模型、資料都得先放進去才能算 裡,而且要把每個 token 送到正確的專家那裡,在叢集中會產生大量通訊與協調成本。專家越多,這些成本越可能吃掉「只用一部分」所省下的運算。Olmo-core 3 就是為了縮小這個落差而設計的。

具體做法是換掉舊的資料切分方式:舊版用 FSDP完全分片資料平行,把模型權重切碎存在各張卡上,要用時再臨時湊起來,用完再拆開,而且是每一小批訓練資料就湊一次、拆一次權重;新版改成以 DDP分散式資料平行,每張卡各自拿一份模型、各吃不同資料,彼此同步結果 為基礎的系統,讓專家常駐在 GPU 上,改成把『資料』送去找專家,避免反覆搬權重。在 8 張 NVIDIA B300 的初步測試中,47B 的 MoE 每張卡每秒處理 52,000 個 token,舊實作是 19,400 個,約 2.7 倍。

🎯 為什麼值得你花時間

把「大模型」從財力問題變成工程問題素材明說:訓練大模型耗費大量算力、成本與能源,讓學術研究者與小型實驗室很難進場。MoE 加上一套開源、高效率的訓練系統,目標是讓更多團隊有機會做大模型,而不是只有資金雄厚的公司。
「總容量」與「每次花費」被拆開了實測中總參數從 4.6B 長到 47B(約 10 倍),每個 token 啟用的參數維持約 3.2B,速度只掉不到 5%。這代表你可以買到更大的知識容量,卻不必付等比例的計算費用,前提是訓練系統不被通訊成本拖垮。
開源的是『訓練基礎設施』,不只是成品模型Ai2 的承諾是公開每一代新模型背後的工具與訓練基礎設施。對學習者而言,這等於能看到一個真實大型模型是怎麼被訓練出來的,而不是只拿到一個權重檔。

⚙️ 它是怎麼運作的

1
1. 路由:每個 token 挑 4 位專家模型裡有一個負責分派的『路由器』,對每個 token 從專家池裡選出 4 個專家來處理。專家池從 8 擴到 128 時,每個 token 仍只選 4 個,所以每個 token 的計算量大致不變。
▼
2
2. 專家常駐在 GPU 上新版系統不再每處理一小批資料就把權重收集起來又拆掉,而是讓專家一直待在各張 GPU 裡,省下反覆搬權重的流量。
▼
3
3. 把資料送去找專家被選中的專家可能在另一張卡上,所以系統把對應的 token 資料傳過去,算完再收回來。搬的是相對輕的資料,不是沉重的整份權重。
▼
4
4. 其餘部分用資料平行同步整體架構以 DDP 為底:各卡各自處理不同的資料,再同步學習結果。這是從舊版 FSDP 路線換過來的核心設計。
▼
5
5. 用吞吐量檢驗設計是否成功判斷標準是 throughput,也就是每張卡每秒能處理多少 token。8 張 B300 上,47B 模型新版 52,000、舊版 19,400,約 2.7 倍。
Olmo 系列三代訓練設計的差異(資料來自素材)
系列架構備註
OlmoEMoE,64 個路由專家Ai2 稀疏模型的起點
Olmo 3密集(dense)架構,幾乎整個模型每個 token 都啟用訓練系統是圍繞密集設計打造的
Olmo-core 3為更大的 MoE 重新設計:DDP 為基礎、專家常駐 GPU已測到超過 1T 總參數;47B MoE 比舊 FSDP 版約快 2.7 倍

🔍 程式碼漫遊(點有 ● 的行看白話講解)

素材給了兩組總參數量(8 專家=4.6B、128 專家=47B)與每個 token 啟用約 3.2B。這段程式用這兩個數字反推『每位專家多大、共用部分多大』,再驗證啟用參數是否真的約 3.2B。注意:這是我們依素材數字做的簡化估算(假設總參數=共用部分+專家數×單一專家大小),不是 Ai2 公布的內部結構。

●TOTAL_8, TOTAL_128 = 4.6, 47.0
💬 素材公布的兩個總參數量,單位是十億(B)。
●TOP_K = 4
💬 每個 token 只挑 4 位專家,這個數字不隨專家池變大而變。
●expert_size = (TOTAL_128 - TOTAL_8) / (128 - 8)
💬 兩組數字相減:多出的 120 個專家貢獻了 42.4B,所以平均每位專家約 0.353B。
●shared = TOTAL_8 - 8 * expert_size
💬 把 8 位專家的份量從 4.6B 扣掉,剩下約 1.77B 是所有 token 都會用到的共用部分。
●active = shared + TOP_K * expert_size
💬 重點行:每個 token 實際用到的參數=共用部分+4 位專家,算出約 3.19B,和素材的 3.2B 吻合,代表這個簡化模型合理。
●def route(num_tokens, num_experts, top_k, seed=0):
💬 第二部分:模擬路由,看專家變多時每位專家分到多少 token。
● for e in rng.sample(range(num_experts), top_k):
💬 這裡用隨機挑專家,只是教學簡化;真實的路由器是學出來的,目標是把 token 送給最適合的專家。
● load[e] += 1
💬 記錄每位專家被分到幾個 token,也就是它的工作量(load)。

🛠️ 動手做:用 40 行 Python 驗證「專家變 16 倍,每次花費卻幾乎不變」

這是一個真實小專案:下載(或複製)檔案,照步驟在你電腦上跑起來。

📄 moe_sim.py ⬇ 下載
import random

# 素材公布的兩組總參數量(單位:十億 B)與每個 token 挑選的專家數
TOTAL_8, TOTAL_128 = 4.6, 47.0
TOP_K = 4

# 假設 總參數 = 共用部分 + 專家數 x 單一專家大小,用兩組數字反推
expert_size = (TOTAL_128 - TOTAL_8) / (128 - 8)
shared = TOTAL_8 - 8 * expert_size
print('單一專家約 %.3fB,共用部分約 %.2fB' % (expert_size, shared))

for n in (8, 32, 128):
    total = shared + n * expert_size
    active = shared + TOP_K * expert_size
    print('專家數 %3d | 總參數 %5.1fB | 每個 token 啟用 %.2fB' % (n, total, active))


def route(num_tokens, num_experts, top_k, seed=0):
    # 教學簡化:隨機挑專家。真實路由器是學出來的,不會是隨機
    rng = random.Random(seed)
    load = [0] * num_experts
    for _ in range(num_tokens):
        for e in rng.sample(range(num_experts), top_k):
            load[e] += 1
    return load


print()
for n in (8, 128):
    load = route(10000, n, TOP_K)
    avg = sum(load) / n
    print('專家數 %3d | 平均每位專家 %.0f 個 token | 最忙 %d | 最閒 %d' % (n, avg, max(load), min(load)))

# 素材中的實測吞吐量(8 張 B300、47B MoE)
print()
print('新版/舊版吞吐量倍數:%.2f' % (52000 / 19400))
  1. 在 PowerShell 輸入:mkdir $env:USERPROFILE\moe_lab; cd $env:USERPROFILE\moe_lab
  2. 用記事本建立 moe_sim.py,貼上上面的內容,存檔時編碼選「UTF-8」。(或用 VS Code 存成 UTF-8)
  3. 在同一個 PowerShell 視窗輸入:py moe_sim.py
  4. 觀察第一段:專家數 8、32、128 時,總參數從約 4.6B 長到約 47B,但「每個 token 啟用」都是約 3.19B。
  5. 觀察第二段:專家數從 8 變 128,每位專家平均分到的 token 變少,最忙與最閒的差距在比例上變大,這就是 MoE 需要負載平衡的原因。
  6. 進階挑戰:把檔案中的 TOP_K 改成 2 或 8,再執行一次,看看『每個 token 啟用的參數』如何跟著改變。

🧠 工程思維透鏡(資深工程師看到的是什麼)

🔭 資深工程師看到「總參數 10 倍、速度只掉不到 5%」,第一個會問什麼?
會問:省下來的運算被什麼吃掉了?MoE 把運算量壓在每個 token 啟用的參數上(約 3.2B 不變),但把成本轉移到『記憶體容量』與『跨 GPU 通訊』。這個數字漂亮,代表通訊與協調成本被控制住了,而不是成本消失了。工程上的重點永遠是『成本搬去哪裡、值不值得』。
🔭 為什麼要從 FSDP 換成以 DDP 為基礎的設計?
舊做法是每處理一小批資料,就把需要的權重收集、使用、再拆開;對 MoE 而言,專家數量極多,反覆搬權重的成本很高。新做法讓專家常駐在 GPU,改搬 token 資料。取捨是:每張卡要為常駐專家預留記憶體、也要設計資料送往專家的路徑,換來的是不再重複搬沉重的權重。設計原則是『搬輕的、不搬重的』。
🔭 素材也提到 NVIDIA 的 Megatron-Core 是成熟選項,為何 Ai2 還要自己整合一套?
素材只說明:Olmo-core 3 把整合式的 MoE 訓練堆疊放進 Olmo 所用的框架,並且比自家舊的 FSDP 實作快。我們不能替 Ai2 臆測更多動機,但可以學到一個一般性的工程思考:把關鍵能力整合進自己的主框架,換來的是同一套系統從研究到訓練都一致、也更容易開源與維護,代價是要自己承擔設計與優化的工作量。

📝 隨堂考(點選答案,立即回饋)

Q1. 素材中,專家從 8 個增加到 128 個、每個 token 仍選 4 個,下列哪一項描述最正確?
✅ 選專家的數量固定為 4,所以每個 token 啟用的參數大致不變;專家池變大讓總容量增加。訓練速度只掉不到 5%。
Q2. Olmo-core 3 相對於舊版 MoE 實作,最核心的設計改變是什麼?
✅ 素材明說新版改用以 DDP 為基礎的系統,讓專家常駐 GPU 並把相關資料路由過去,避免反覆收集權重。
Q3. MoE 專家越多,為什麼不一定更快?
✅ 素材指出這兩項成本會隨規模成長,侵蝕『只用部分模型』的運算優勢。Olmo-core 3 就是要縮小這個落差。
Q4. 在 8 張 B300 上、47B 的 MoE,新舊實作的吞吐量比較是?
✅ 素材的初步測試結果:新堆疊每張 GPU 每秒 52,000 個 token,舊實作 19,400,約 2.7 倍。(注意是初步測試。)

🃏 翻牌記憶卡(先想答案,再點開對答)

MoE 的核心取捨是什麼?點我翻面
用大量總參數換取知識容量,但每個 token 只啟用少數專家來控制計算量;代價是記憶體容量與跨 GPU 的通訊協調成本。
Olmo-core 3 的基準數字(8→128 專家)點我翻面
每個 token 仍選 4 個專家,啟用參數約 3.2B;總參數 4.6B→47B;訓練吞吐量下降不到 5%;同基礎架構測過超過 1T 總參數。
FSDP 與 DDP 為基礎的新設計,差別在哪?點我翻面
舊版 FSDP 每小批資料都收集再切開權重;新版以 DDP 為基礎,專家常駐 GPU,改把相關資料路由到專家,避免反覆搬權重。
新舊實作的速度比較點我翻面
8 張 NVIDIA B300、47B MoE:新版 52,000,舊版 19,400 tokens/s/GPU,約 2.7 倍(初步測試)。
Olmo 系列三代的架構演進點我翻面
OlmoE 是 64 個路由專家的 MoE;Olmo 3 是密集架構;Olmo-core 3 擴充訓練系統,專為更大的 MoE 設計。

✅ 離開前自測(全勾=這課真的學會了)

0%