Gemma 4 助手模型加速草稿 Token
Gemma 4 的 E2B 與 E4B 助手模型用 centroid masking，把草稿 token 的 lm_head 計算量砍到約 45 倍，且品質損失很小。
Gemma 4 助手模型用 centroid masking，讓草稿 token 生成更快，vLLM 也能直接吃到這個優化。
Google 的 Gemma 4 助手模型，這次不是在比參數量。重點是它把 speculative decoding 的草稿路徑，切得更省算力。
原本要掃大約 26.2 萬個詞彙。現在先縮到約 4,000 個 centroid。講白了，就是少做很多 dot product。
| 項目 | 數值 | 意義 |
|---|---|---|
| 完整詞彙表 | 約 262,000 | 原本 lm_head 的基礎成本 |
| Centroid 候選集 | 約 4,000 | 草稿 token 先看的小集合 |
| 計算量下降 | 約 45x | lm_head 少做很多工作 |
| 最大上下文 | 8,192 | vLLM 範例的 context window |
| 每步草稿 token | 4 | speculative decoding 的預測數量 |
Centroid masking 到底改了什麼
訂閱 AI 趨勢週報
每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。
不會寄垃圾信，隨時可取消。
先講白話版。一般 LLM 在選下一個 token 時，會對整個詞彙表打分。詞彙表越大，lm_head 越吃算力。
Gemma 4 的 E2B 與 E4B assistant checkpoints，用的是 centroid masking。它不是完全不算，而是先把候選範圍縮小，再去做選擇。
這招很適合 speculative decoding。因為草稿模型要夠快，才有意義。草稿如果自己就很慢，主模型還沒驗證，時間就先燒掉了。
- 完整詞彙表約 262K
- 候選集縮到約 4K
- vLLM 回報
lm_head計算量約降 45x - 有 ordered embeddings 時會自動啟用
為什麼跑 vLLM 的人會在意
對 vLLM 使用者來說，這種優化最討喜的地方是不用手動魔改。只要 checkpoint 帶有 centroid weights，設定裡的 use_ordered_embeddings: true 就能啟動。
這比很多 inference 技巧好用。很多方案要改 kernel、改環境變數，或是找特定 fork。說真的，工程師最煩的就是這種「看起來很美，實作很醜」的東西。
Gemma 4 這次比較務實。你如果已經在跑 speculative decoding，這個草稿路徑優化就能直接吃到。
“Speculative decoding can significantly accelerate generation when the draft model is much cheaper than the target model.” — Yaniv Leviathan、Matan Kalman、Yossi Matias
這句話很直白。草稿模型便宜，整體才會快。草稿模型如果不便宜，所有優化都只是紙上談兵。
數字怎麼看，和一般草稿模型差在哪
先看數字。262K 變 4K，差了 65.5 倍的候選範圍縮減。vLLM 的說法是，lm_head 計算量大約少 45 倍。
但別直接把 45x 當成端到端速度。因為主模型還要驗證草稿 token。真正的總體加速，還要看拒絕率、batch size、GPU 型號，和上下文長度。
不過，這個優化還是很實在。它砍掉的是 speculative decoding 裡最常見的浪費之一，也就是草稿階段的詞彙打分成本。
- 普通草稿模型：每步仍要掃大詞彙表
- Gemma 4 助手模型：先用 centroid 篩候選
- 結果：草稿路徑更省算力
- 影響：更容易把 speculative decoding 放進 production
跟其他推理做法比，差在哪
很多人一聽到加速，就想到量化、KV cache、flash attention。那些都重要，但它們處理的是不同瓶頸。
centroid masking 處理的是草稿 token 的選擇成本。它不是把模型變小，也不是把精度硬壓下去。它是把不必要的候選先擋掉。
這種作法比較像工程上的省錢術。不是喊口號，而是直接少算一大段。對伺服器成本敏感的團隊，這種東西很有感。
- 量化：主要省記憶體與部分算力
- KV cache：主要省長上下文推理成本
- speculative decoding：靠草稿模型先猜 token
- centroid masking：再把草稿模型的候選集縮小
這個做法放在產業裡怎麼看
LLM 服務現在很現實。大家不只看 benchmark，也看每秒 token、每張 GPU 的吞吐量，還有延遲抖動。
Gemma 4 這種做法，對雲端推理很有意義。因為草稿路徑越便宜，越容易把 speculative decoding 變成預設選項，而不是實驗室裡的 demo。
另一個重點是可部署性。這次不是叫你重寫整個 serving stack，而是讓 checkpoint 自帶 centroid weights。這點很務實。
如果你在看開源模型，還是可以把它跟 Hugging Face 上其他 checkpoint 一起比較。重點不是誰名氣大，而是誰在 production 比較省錢。
接下來該看什麼
我覺得下一步要觀察兩件事。第一，這種 ordered embeddings 會不會變成更多模型的標配。第二，vLLM 之外的 serving 框架會不會跟進。
如果更多 assistant checkpoints 都內建 centroid weights，speculative decoding 會更容易落地。反過來說，如果只有少數模型有這個設計，它就還是特定場景的加速技巧。
對開發者來說，現在最實際的動作很簡單。你如果在跑 Gemma 4，去確認自己是不是用了 assistant checkpoint。沒用對版本，等於白白浪費一大段草稿效率。