你有沒有在本地跑 LLM 時，盯著終端機一個字一個字慢慢蹦出來，心裡想著：「如果它再快一點就好了」？

這不是你的 GPU 不夠力，而是 LLM 推論從設計上就有個先天瓶頸：它一次只能生成一個 token。不管下一個字是顯而易見的「words」（接在 “Actions speak louder than…” 後面），還是需要複雜推理的邏輯判斷，模型都得花同樣的時間去處理。對本地開發者來說，每多一秒的等待，就多一次進入心流的阻礙。

Google 最新發布的 Gemma 4 MTP（Multi-Token Prediction）起草器，就是用來打破這個瓶頸的。效果很直接：最高 3 倍速度提升，輸出品質完全不變。這不是實驗室數據，而是 Gemma 4 發布不到一個月、超過 6000 萬次下載之後推出的實戰級更新。

為什麼你的 GPU 一直在「等」？

很多人以為 LLM 跑得慢是因為「計算太大」。這個說法只對了一半。真正的瓶頸在記憶體頻寬。

每次 LLM 生成一個 token，GPU 要做的是：把整個模型的參數從 VRAM 搬到計算核心，做完一次前向傳播，產生一個 token，然後把結果寫回去。接著重複這個流程，生成下一個 token。問題在於，搬運參數花的時間遠比實際計算的時間長。

做個估算：一顆 70B 參數的模型，光是讀取一次所有參數就需要約 140GB 的資料傳輸。即使是最新的消費級 GPU（如 RTX 5090 的頻寬約 1.8 TB/s），單次讀取也需要約 80 毫秒。而生成一個 token 的計算本身可能只需要幾毫秒。

這就是為什麼你在終端機看到的 token 生成速度不是每秒幾千個，而是每秒幾個到幾十個。GPU 大部分時間都在「等資料送來」，而不是在「做計算」。技術上稱之為 memory-bandwidth bound — 運算單元被記憶體頻寬卡住了脖子。

Gemma 4 26B 和 31B 模型雖然參數量相對較小，但這個瓶頸依然存在。你可能以為在 MacBook 上跑 26B 模型會很流暢，但實際體驗往往是每秒不到 10 個 token 的速度。

回到基本面：什麼是自回歸解碼？

大型語言模型的生成過程稱為「自回歸解碼」（Autoregressive Decoding）。所謂「自回歸」，是指模型根據已經生成的 token，預測下一個 token 的機率分布。然後從這個分布中取樣，把選中的 token 加入已生成的序列，再用新序列預測下一個 token。如此循環往復。

這個過程在數學上很優雅，在工程上卻很低效。它從根本上是序列化的 — 每個 token 都必須等前一個生成完才能開始。GPU 的平行計算能力在這裡完全派不上用場。

業界已經提出了多種方案來解決這個問題。最常見的是批次推論（batch inference）：一次處理多個請求，讓 GPU 在每個步驟中同時生成多個序列的對應 token。但這個方法只能提高吞吐量，不能降低單一請求的延遲。對即時互動場景（聊天機器人、程式碼補全）來說，延遲才是關鍵指標。

另一種方案是模型量化：把權重從 16-bit 降到 4-bit 或 8-bit，減少每次搬運的資料量。但這個方法會犧牲模型品質。

MTP 走的是完全不同的路線。

MTP 的破解思路：不要等，先猜

Google 研究團隊在 2022 年發表了〈Fast Inference from Transformers via Speculative Decoding〉這篇論文，提出了一個打破自回歸生成枷鎖的方法。

投機解碼（Speculative Decoding）的想法很簡單：與其讓大模型慢慢排隊，不如讓一個小模型先「偷跑」猜一串，再讓大模型一次驗證整串。

流程如下：

第一步：起草器快速預測。 一個輕量的專用模型（drafter）負責快速預測接下來的多個 token。它的參數量遠小於主模型，計算成本極低。它不需要像主模型那樣深思熟慮，只需要快速給出合理的猜測。

第二步：生成候選序列。 起草器一次生成一組候選 token，比如一次預測接下來 5 個 token。對 GPU 來說，讓小模型跑幾次前向傳播的計算量微乎其微。

第三步：主模型平行驗證。 Gemma 4 主模型用一次前向傳播，平行驗證整串猜測。這裡是關鍵：GPU 的矩陣運算本質上就是平行處理，一次驗證 5 個 token 跟驗證 1 個的計算成本幾乎沒有差別。

第四步：接受或修正。 如果預測全部正確，整串直接輸出，主模型還會順便多生成一個 token。如果部分錯誤，從第一個錯誤的 token 開始退回，由主模型生成正確內容。

這個流程的核心洞察是：平行驗證多個 token 的成本，跟驗證一個幾乎一樣。 如果起草器猜得夠準，整段序列就能在原本只夠生成一個 token 的時間內全部輸出。這就是 3 倍加速的來源。

為什麼草案器能猜這麼準？

答案在於自然語言中的「可預測性密度」並不均勻。有些 token 的出現幾乎是必然的，有些則有很多可能性。

舉例來說，當你看到「根據最新的研究報告顯示，AI 在醫療領域的應用」，接下來出現的 token 大多是可以合理預測的：「正在」、「持續」、「已經」 — 這些詞彙的出現機率遠高於其他選擇。對這些「顯而易見」的 token，一個參數量僅為主模型十分之一的小模型就足以勝任。

反過來說，如果句子是「這個實驗的關鍵發現是……」，接下來的內容可能是「量子糾纏態的觀測結果」或「蛋白質折疊的深度學習預測」。但這類「高難度」token 在實際對話和程式碼生成中的佔比並不像想像中那麼高。

在程式碼生成中可預測性更強。當你寫了 def fibonacci(n):，接下來的 if n <= 1: return n 幾乎是無法避開的標準寫法。草案器處理這類 token 游刃有餘。

傳統的自回歸解碼浪費了大量計算在那些「簡單」的 token 上，因為它不分難易，一律用同樣的計算量去處理。MTP 讓小模型處理簡單的 token，大模型只需要在關鍵時刻把關。

數據說話：MTP 在不同硬體上的表現

根據 Google 官方測試數據：

一般情境下最高 3 倍加速： 在不進行額外批次優化的情況下，單一請求的 token-per-second 可以提升到原來的 3 倍。適用於大多數消費級硬體的單一請求場景。

Apple Silicon + 26B MoE 模型： 26B MoE（Mixture of Experts）在 batch size 1 時，由於 MoE 的路由機制需要為每個 token 動態決定啟動哪些專家，會造成 GPU 核心利用率不均。但 batch size 提升到 4-8 時，可達約 2.2 倍的本地加速。

對 Mac 使用者來說，這意味著：如果你覺得速度不夠，試著用 vLLM 或 SGLang 這類支援批次處理的框架，讓 GPU 同時處理多個任務，反而能解鎖更高的推論效率。

Nvidia A100： 增加 batch size 同樣能看到顯著增益。對雲端部署的團隊來說，同樣的 GPU 時數可以服務更多請求。

邊緣裝置（E2B/E4B）： Google 在邊緣模型上實作了效率嵌入器，使用分群技術壓縮 logit 計算瓶頸。更短的推論時間也轉化為更低的功耗。

零品質損失： 因為最終驗證權還是在主模型手上，你得到的 token 跟不使用 MTP 時完全一致。不需要在速度和品質之間做取捨。

MTP 對開發者日常的實際影響

抽象的速度數字可能還不夠有感，以下用幾個具體場景來說明 MTP 能帶來什麼改變。

場景一：程式碼補全。 你在 VS Code 中寫了半行程式，等待 AI 助理的建議出現。如果這個過程超過 1 秒，你的思路就被打斷了。3 倍的加速意味著原本 1.5 秒的等待縮短到 0.5 秒 — 從「讓人煩躁」變成「幾乎無感」。

場景二：多步驟 Agent。 Agent 的推理序列通常包含多個步驟：理解任務、規劃、執行、觀察結果、調整策略。如果每一步從 2 秒降到 0.7 秒，一個 5 步驟的工作流程就從 10 秒降到 3.5 秒。對使用者體驗來說，這是質的飛躍。

場景三：行動裝置。 手機上跑 AI 最大的痛點在於發熱和續航。MTP 讓每次查詢的運算時間縮短三分之一以上，意味著同樣的任務消耗更少的電量。對需要在手機上做即時翻譯或語音辨識的應用來說，這個改善非常實際。

MTP 背後的關鍵設計

如果只看表面，MTP 像是「一個小模型幫忙猜，大模型來驗證」。但 Google 在實作中做了幾個關鍵的架構設計。

啟用共享（Activation Sharing）： 起草器直接使用主模型的 KV cache 和中間啟用值。主模型已經算好的東西，草案器直接拿來用。從記憶體的角度來看，這意味著草案器幾乎沒有增加 VRAM 的佔用。

KV Cache 共享： 這是最重要的優化。傳統的推論過程中，KV cache 逐 token 增長。如果草案器和主模型各自維護自己的 KV cache，記憶體開銷會加倍。Gemma 4 讓草案器直接掛載在主模型的 KV cache 上，不僅節省記憶體，也避免快取不一致的問題。

效率嵌入器（Efficient Embedder）： 對邊緣裝置來說，logit 計算是個瓶頸 — 詞彙表可能有數萬個 token，每次都要對所有 token 算機率。Google 將語意相似的 token 分群，先在群組層級做粗粒度預測，再在群組內部做細粒度選擇，壓縮了計算量。

跨批次路由優化： 對 26B MoE 模型，Google 發現批次處理能讓多個請求的專家啟用分布更均勻，提高整體效率。對開發者的啟示是：跑 MoE 模型時不要只發單一請求。

這些細節說明 MTP 不是簡單的 hack，而是對整個推論管線的深度優化。

開發者如何使用 MTP

MTP 草案器已可用，Apache 2.0 開源授權：

Hugging Face Transformers： 下載模型權重和草案器權重，載入時指定 use_mtp=True。

MLX（Apple Silicon）： 對 Mac 用戶來說是最佳選擇，社群已提供 MTP 版本。

vLLM（生產環境）： 適合高吞吐量的服務場景，Google 文檔有詳細的整合指南。

SGLang： 支援 speculative decoding，可根據硬體配置自動調整 batch size。

Ollama（快速測試）： 一行指令就能在本地跑起來，最簡單的上手路徑。

Google AI Edge Gallery： 對 Android 和 iOS 開發者，可以直接在手機上測試 MTP。

從其他模型遷移的考量

如果你目前使用 Llama 3 或 Mistral，正在考慮搬到 Gemma 4 MTP，以下是具體的評估面向：

框架相容性： Gemma 4 已整合到 Hugging Face Transformers、vLLM、SGLang 和 Ollama。如果你已經在使用這些框架，遷移只需要更換模型權重路徑並啟用 MTP 選項。應用層的程式碼不需要改寫。

硬體需求： Gemma 4 26B 和 31B 需要約 16-20GB VRAM（16-bit 精度）。RTX 4090（24GB）或 MacBook M 系列（統一記憶體 32GB+）都能流暢運行。草案器額外增加約 500MB，可以忽略。

效能比較： 在同樣的硬體上，Gemma 4 26B + MTP 的 token-per-second 通常高於 Llama 3 70B（4-bit 量化），而輸出品質在 Hugging Face 排行榜上處於同一梯隊。如果你的應用對延遲敏感，這個組合值得測試。

測試建議： 花一個下午的時間就夠了。步驟很簡單：下載模型權重和草案器權重 → 選擇一個框架啟動（vLLM 或 MLX 都行）→ 啟用 MTP → 用你原本的應用 prompt 測試 → 比較速度差異。大約一到兩小時就能得到明確答案。

遷移後的調整： Gemma 4 的 tokenizer 跟 Llama 系列不同，某些 token 的編碼效率會有些微差異。如果你的應用依賴特定 prompt 格式（如 chat template），需要在遷移時確認相容性。多數框架已經內建了 Gemma 4 的 chat template，這部分通常不需要手動處理。

開源生態的新變數

Gemma 4 不到一個月 6000 萬下載的成績，說明了市場對高效開源模型的需求有多強烈。與此同時，其他陣營也在推論加速上各自發力：Llama 系列靠量化和工具鏈成熟度取勝；Mistral 以滑動視窗注意力降低計算量；DeepSeek 用 MoE 架構和專家並行平衡速度與品質。

MTP 的加入進一步拉開了 Gemma 4 的競爭距離 — 不是參數量的差距，而是部署效率的差距。過去兩年，開源模型的競爭集中在「誰的模型更強」— 更大的參數量、更高的 benchmark 分數。但隨著模型能力逐漸趨同，焦點正在轉移。開發者關心的不再只是「這個模型能不能回答複雜問題」，而是「這個模型在我的筆電上跑得多快」。

MTP 從根本上改變了推論的範式 — 它不是讓模型算更快，而是讓模型少算。如果投機解碼成為主流，未來每個模型發布時可能都會附帶一個專屬的草案器，就像手機處理器都附帶 AI 加速單元一樣。草案器本身也可能成為一個研究方向：為特定模型設計最佳草案器，可能會像為特定晶片設計編譯器一樣，成為一個專業領域。

對於硬體廠商來說也是值得關注的趨勢。Nvidia、Apple、Qualcomm 都在開發針對 LLM 推論的專用加速硬體。MTP 這類軟體優化與硬體加速並不衝突，兩者可以疊加使用。

對於正在考慮自建 AI 應用的開發團隊來說，Gemma 4 MTP 提供了一條值得測試的路徑：開源、Apache 2.0 授權、支援主流框架、速度提升顯著，而且不需要犧牲輸出品質。

過去三年，AI 領域的發展速度讓人眼花撩亂。但在這波浪潮中，真正能讓開發者日常工作變得更好的技術，往往不是那些最炫的，而是那些最實用的。MTP 就是這樣一個技術。它沒有改變模型的推理能力，沒有增加參數量，沒有引入新的訓練範式。它只是讓既有的模型跑得更快 — 但這個「更快」，足夠讓本地 AI 從「可以玩」變成「可以用」。

這正是開源生態最迷人之處：不是在實驗室做出驚人的突破，而是讓已經很好的東西，每個人都能在自己的電腦上輕鬆用起來。

參考資料：
– Google Blog: Accelerating Gemma 4 with Multi-Token Prediction Drafters (2026.05.05)
– Fast Inference from Transformers via Speculative Decoding, arXiv 2211.17192
– Gemma 4 官方技術文件 (ai.google.dev/gemma/docs/mtp)
– Hugging Face — Gemma 4 Model Collection