AI 工具 10 min read

MoE 省記憶體?錯了:Dense 與 MoE 最反直覺的差別

Dense 模型每個字都用上全部參數,誠實但耗算力;MoE(Mixture of Experts)靠一個「領班」每個字只派一小撮專家上工,帳面參數很大但實際算力很省。最反直覺的一點:MoE 省的是算力跟速度,不是記憶體——所有專家還是得全部載進 VRAM。VRAM 不夠時該砍的是「總參數量」,不是無腦選 Dense。這篇從我在單機 dev 機換本地 LLM 卡到的真實問題出發,用餐廳出餐比喻講透 router 怎麼運作,再拿 Mixtral 8x7B(46.7B/13B)、DeepSeek-V3(671B/37B)、Gemma 4 12B(純 Dense)三顆真模型把數字釘死,最後給出 VRAM 受限時該怎麼選的決策表。

#MoE #Dense #Mixture of Experts +6 tags
MoE 省記憶體?錯了:Dense 與 MoE 最反直覺的差別
本文目錄 · 9

# MoE 省記憶體?錯了:Dense 與 MoE 最反直覺的差別

TL;DR:Dense 模型每個字都用上全部參數,誠實但耗算力;MoE(Mixture of Experts)靠一個「領班」每個字只派一小撮專家上工,帳面參數很大但實際算力很省。最反直覺的一點:MoE 省的是算力跟速度,不是記憶體——所有專家還是得全部載進 VRAM。VRAM 不夠時該砍的是「總參數量」,不是無腦選 Dense。

📌 目錄

⭐ 我為什麼想搞懂這兩個詞

起因很實際。我在一台單機 dev 機上跑本地 LLM,VRAM 就那麼多,要在 gemma4-e4b(太小、推理不穩)跟 gemma-4-12B(大一點、推理穩)之間換。換完我順手 curl 了一下 vLLM 的模型清單:

curl -s http://<dev-host>:8000/v1/models | python3 -m json.tool

吐出來 root 是 /models/gemma-4-12B-it-AWQ-INT4。我那時順口說「12B 應該是 Dense 吧」,話一出口就卡住——我憑什麼這樣斷言? 同一代的 Gemma 4 還有一顆 26B 是 MoE。Dense 跟 MoE 到底差在哪、為什麼有些尺寸做成 Dense 有些做成 MoE、跟我 VRAM 不夠又有什麼關係,我其實講不清楚。這篇就是把這條我自己卡過的問題,從頭講明白。

🧠 一句話講完 Dense 跟 MoE

就一句:MoE 每個 token 只用一部分參數,Dense 每個 token 用全部參數。

  • Dense(密集):模型有多少參數,每處理一個字就全部過一遍。沒有挑選、沒有分流。
  • MoE(Mixture of Experts,專家混合):模型內部切成很多組「專家」,外加一個 router(路由/領班)。每個字進來,router 決定「這個字交給最對口的那幾組專家就好」,其他專家這一輪不出力。
差別的核心就在那個 router。Dense 沒有它,MoE 靠它省力。

⚖️ 餐廳出餐:最好懂的比喻

把模型想成一間餐廳,參數就是廚師,處理一個 token 就是出一道菜。

Dense 餐廳:店裡 12 個廚師,每道菜 12 個全上。不管你點炒飯還是牛排,全部人一起做。出菜穩、品質一致,但每道菜都吃滿全部人力。

MoE 餐廳:店裡養了 64 個廚師,但門口站了一個領班(router)。每道菜進來,領班看一眼就喊「這道叫 8 個最對口的去做」,其他 56 個在旁邊待命不動。所以你帳面上養了 64 個廚師(總參數),但每道菜實際出力的只有 8 個(active 參數)。

這個比喻能一次解釋三件事:

  • 為什麼 MoE 帳面參數那麼大 — 你真的養了 64 個廚師

  • 為什麼 MoE 算得快 — 每道菜只動 8 個,出菜當然快

  • 為什麼 MoE 還是很佔空間 — 那 56 個待命的廚師,薪水照付、店裡照站(記憶體照佔)

    • 💰 最反直覺的點:MoE 省算力,不省記憶體

    這是最多人卡住的地方,單獨拉一段講。

    很容易誤會成「MoE 每次只用一小部分,所以比較省記憶體」。錯。 MoE 省的是算力(FLOPs)跟推理速度,不是 VRAM。

    原因回到餐廳:那 56 個待命的廚師,雖然這道菜沒叫他們,但下一道菜可能就叫了——所以他們全部都得待在店裡。對應到模型:不管 router 這次選了誰,所有專家的權重都必須事先載進 VRAM,因為你不知道下一個 token 會路由到哪幾個。

    維度DenseMoE
    一個 token 經過的參數全部只有被選中的專家
    有沒有 router沒有有,每個 token 動態挑
    算力 / 推理速度中規中矩快(只算一小撮)
    VRAM(記憶體)載全部參數一樣要載全部參數
    賣點簡單、誠實用小算力跑出大模型品質
    所以 MoE 的真正賣點是「用接近小模型的算力跟速度,跑出接近大模型的品質」,代價是「你得有放得下全部參數的記憶體」。

    📊 三個真實模型對照

    抽象講完,看三顆真模型把數字釘死。

    模型架構總參數每 token active一句話
    Mixtral 8x7BMoE46.7B~13B養 46.7B,跑起來像 13B,曾以 6 倍速度打平 LLaMA-2-70B
    DeepSeek-V3MoE671B37B養 671B 巨無霸,每字只動 37B
    Gemma 4 12BDense12B12B(全活)12B 全程參與,沒有 router
    看出來了嗎?Mixtral 名字裡的「8x7B」不是 8×7=56B,而是 46.7B 總參數、每次只活 ~13B——這就是 MoE「帳面大、實際小」的典型。DeepSeek-V3 更誇張,671B 總參數每字只動 37B。而 Gemma 4 12B 是純 Dense,12B 就是實打實 12B 算力,沒有任何分流。
    補充一個容易搞混的點:Gemma 4 12B 是 Google 官方明說的 dense multimodal model,但它有個特性叫 encoder-free(把影像/音訊 encoder 換成直接線性投影餵進 backbone)。encoder-free 講的是「多模態資料怎麼進來」,Dense 講的是「參數怎麼算」,是兩個獨立維度,別混為一談。同代的 Gemma 4 26B 才是 MoE。

    🎯 空間不夠該選 Dense 還是 MoE

    回到我一開始的實際問題:VRAM 不夠,該選哪個?

    直覺答案是「選 Dense」,但這個直覺理由是錯的。正確的判斷是:

    VRAM 不夠時,該砍的是「總參數量」,不是糾結 Dense 還是 MoE。

    因為前面說過,同樣總參數下,Dense 跟 MoE 載進 VRAM 的量其實差不多(MoE 全部專家都要載)。MoE 為了「帳面夠大、品質夠高」,通常總參數會做得很大——對小 VRAM 反而不友善。所以:

    你的瓶頸該怎麼選
    VRAM 小選總參數量小的。小卡上小 Dense 通常最實際
    VRAM 夠、想要快 / 省算力選 MoE。塞得下全部參數,但每 token 只算一小撮,又快又接近大模型品質
    要最高品質、資源無上限大 MoE 或大 Dense 都行,看預算
    回到我那台 dev 機:選 12B 而不是 26B,真正幫我省 VRAM 的是「12B < 26B 這個總量差」,不是 Dense 這個架構本身。剛好 Gemma 4 把 12B 那級做成 Dense、26B 那級做成 MoE,所以「挑小的」結果就拿到 Dense 了——對的選擇,但理由要校準。

    如果哪天同尺寸有「12B Dense」對上「12B MoE」讓你選,兩者吃的 VRAM 會很接近,那時候 MoE 反而比較划算(一樣記憶體、跑更快)。只是現實上 MoE 幾乎都被做在大尺寸,所以小卡實務就是「挑小 Dense」。

    ❓ 常見問題

    Q1:MoE 比 Dense 厲害嗎?
    不是「厲害」的問題,是「划算」的問題。MoE 用更少的算力換到更大的有效參數,但代價是 VRAM 要塞得下全部專家、訓練也更難調(router 容易負載不均)。資源夠就划算,資源不夠就是負擔。

    Q2:為什麼 Mixtral 叫 8x7B 卻不是 56B?
    因為專家之間共享了一部分參數(像 attention 層),不是 8 個完全獨立的 7B 模型疊起來。實際總參數是 46.7B,每個 token 只啟用 2 個專家、約 13B。

    Q3:MoE 真的完全不省記憶體嗎?
    推理時不省 VRAM(全部專家要載)。但它在「相同算力預算下能塞進更多知識」這件事上是省的——你用 13B 的算力成本,拿到了 46.7B 參數的知識容量。省在算力效率,不在記憶體佔用。

    Q4:怎麼快速判斷一個模型是 Dense 還是 MoE?
    看它的命名跟規格卡。出現「8x7B」「A22B」(active 22B)「total/active 兩個數字」這類寫法,幾乎都是 MoE。只給單一參數量(如 12B、70B)且沒提 active,通常是 Dense。最準的還是去看官方 model card。

    🔗 延伸資源

    author
    陳
    陳彥彤

    AI 工程師 · AI 顧問。Java 後端 8 年、AI 工程師 2 年。AI 內訓 · AI 導入顧問 · 前後端與雲端培訓。

    support

    覺得文章有用可以到 GitHub 給個 star，或是透過信箱聊聊 AI 內訓、AI 導入顧問或前後端 / 雲端培訓。

    email github
    related

    相關文章

    [AI 工具] · 19min
    LLM token 怎麼算才準？5 種計量方案實測比較（中文差 47% 的坑）
    LLM token 計量沒有單一正解，而是一條從輕到重的光譜：啟發式估算（字數÷4）、本機 tokenizer（tiktoken）、provider 官方 count API（Anthropic count_tokens 免費）、跨模型計價庫（liteLLM / tokencost）、線上 observability（Langfuse / Helicone）。關鍵是分清「事前估」還是「事後對帳」——前者用本機 tokenizer，後者直接讀 API response 的 usage。最大的坑是 tokenization 不跨 provider 標準化：我本機實測同一段 66 字中文，GPT-4 的 cl100k_base 算 62 token、GPT-4o 的 o200k_base 只算 42——差 47%。這篇把 5 種方案逐個拆、做成優劣總表與決策流程圖，附本機 tiktoken 實測指令。
    [AI 工具] · 19min
    CodeGraph vs grep：AI 讀 codebase 少 81% 工具呼叫的知識圖譜
    CodeGraph 把整個 codebase 預先建成一張「程式碼知識圖譜」（symbol 節點 + call 邊），讓 Claude Code、Codex、Cursor 這類 AI agent 不用一個一個檔案爬，一次 codegraph_explore 就拿到相關 source、call path 跟改動波及範圍。官方在 7 個真實開源專案實測：VS Code 少 81% tool call、少 64% token，Alamofire 便宜 40%、快 33%。這篇把它是什麼、三層架構（tree-sitter + SQLite + file watcher）、安裝三件套、跟 grep / LSP 的差別、以及我接的時候要注意的點寫一遍。100% 本機跑、MIT、支援 23 種語言、8 個 agent。
    [AI 工具] · 12min
    AI agent 額度爆了不用乾等：ccs 多帳號無縫切換（Claude Code + Codex，同一場對話接得起來）
    額度撞 rate limit 最痛的不是要等刷新，是對話脈絡斷掉。ccs 這套把這個痛點直接做掉——一鍵切到第二個帳號，把同一串對話搬過去用它的額度繼續跑，脈絡完全不斷。核心原理 provider-agnostic：每一場對話其實是一個 .jsonl 檔躺在硬碟上，用 CLAUDE_CONFIG_DIR / CODEX_HOME 環境變數隔離兩個帳號身份，撞 limit 時把那場對話檔複製到第二個帳號目錄、再用它 resume 就好，額度算第二個帳號的、歷史一字不差。支援 Claude Code 與 Codex，連 Codex 斷了用 Claude 接的跨工具接力都涵蓋。安全上用「按需複製單一對話檔」而非 symlink 整個資料夾（後者雙開會 corrupt），token 永遠留在你自己的 Keychain、不被搬移。本文最後一段可以直接複製貼給 Claude Code，它會自己 git clone + 跑 install.sh 幫你裝好——唯一要你自己按的只有第二個帳號的 login。
    ← all posts