Gemma 4 在 Mac 上快了近 90%，但 Ollama 今年才被抓到資安漏洞
Ollama 0.31 靠多標記預測（MTP）讓 Gemma 4 在 Apple Silicon 上的生成速度從 50.2 tok/s 衝到 95.0 tok/s，官方數字、真實 coding benchmark。但同一年，Ollama 才因為資安漏洞跟信任危機被罵到臭頭。這篇拆兩件事：這次加速到底做了什麼，還有為什麼你該連 Ollama 的黑歷史一起看。
目錄+
Ollama 0.31 上線，Gemma 4 在 Mac 上跑 coding agent 的生成速度，從 50.2 tok/s 衝到 95.0 tok/s。快了近 90%，而且是官方自己拿真實 coding benchmark 測出來的數字，不是行銷稿裡的「理論最高值」。
但今年稍早，Ollama 才因為一個 CVSS 9 分以上的資安漏洞、加上開源社群對它「不夠透明」的長期不滿，被罵得很難聽。這篇文章想講的不只是「加速多少」，還有這個加速為什麼發生在一個口碑正在下滑的專案身上。
這次到底加速了什麼
先講技術。這不是把模型裁小、犧牲品質換速度，而是靠一套叫多標記預測（Multi-Token Prediction，簡稱 MTP）的機制。
Gemma 4 現在會搭一個很小的「草稿模型」，跟主模型一起跑。草稿模型負責先猜接下來幾個 token 會是什麼，主模型再一次性驗證這些猜測、留下猜對的部分。因為草稿模型體積只是主模型的一小部分，猜測成本很低。猜對的話，你等於用一次驗證的代價，拿到好幾個 token。
程式碼特別適合這套邏輯。閉合括號、重複的變數名、樣板寫法，這些東西「可預測性」極高，草稿模型猜中的機率也高。這也是為什麼 Ollama 官方部落格特別強調 coding agent 場景，那種要一直呼叫模型讀檔案、跑工具、推進任務的用法，生成速度快一點，體感差很多。
真正難的地方在「該猜幾個 token」這件事上沒有標準答案。猜太少浪費效能，猜太多會讓驗證失敗的成本蓋過省下來的時間，反而比不猜還慢。Ollama 的做法是在跑的當下即時調整草稿長度，追蹤猜中率和每次驗證要花多久，一旦猜測不再有幫助，就自動退回一次一個 token 的正常解碼。
Ollama 團隊還做了一件更底層的事：他們幫 MLX（Apple 那套機器學習框架）貢獻了一個新的運算核心，專門處理驗證階段那種尷尬的批次大小，通常是 2 到 8 個 token。過去矩陣乘法的核心，要嘛為單一 token 優化，要嘛為大批次優化，這種中間尺寸沒人管。在 M5 Max 搭 nvfp4 精度的情況下，這個核心讓 Gemma 4 最大的矩陣運算快了 2 到 2.5 倍，而且不是 Ollama 專屬，其他跑在 MLX 上的模型也能沾光。
要跑起來也不難。更新到 Ollama 0.31 之後，跑 ollama launch claude --model gemma4:12b-mlx 就會用上這個版本；已經下載過 Gemma 4 的人，要重新 ollama pull gemma4:12b-mlx 才拿得到 MTP 版本。
這才是整個工程真正的難點：不是讓模型猜得更準，是讓它準時閉嘴。
這不是 Ollama 一家的事
把時間拉遠一點看，MLX 上的推測解碼（speculative decoding）本來就落後一截。今年 5 月 mlx-lm 0.21 才第一次把生產等級的推測解碼做出來，在那之前 Apple Silicon 用戶只能靠 llama.cpp 那套實驗性的草稿模型支援湊合著用，跟 CUDA 陣營、跟 vLLM 比，是明顯的後段班。
而且就算是同一個 Gemma 4 的 MTP 草稿模型，不同引擎接的進度也不一樣。vLLM 那邊到今年 5 月，官方的 Gemma 4 drafter 整合都還掛著好幾個未合併的 PR，屬於「工程量還沒做完」而不是架構做不到的問題。換句話說，Ollama 這次不是獨門技術突破，而是在一個大家都在追的方向上，先把 Mac 這條線補齊了。
但 Ollama 今年的名聲，沒有這麼風光
如果你只看這則推文，會覺得 Ollama 這家公司很穩。實際上今年對 Ollama 來說是顛簸的一年。
5 月，資安圈揭露一個代號「Bleeding Llama」的漏洞（CVE-2026-7482），CVSS 評分 9 分以上，出在 GGUF 模型載入器上：只要餵一個宣告的張量大小超過檔案實際長度的惡意 GGUF 檔，就能讀到堆疊裡不該讀到的東西，包括 prompt、對話紀錄，甚至環境變數裡的 API key。影響範圍粗估超過 30 萬台部署。
同一段時間，開源社群對 Ollama 的抱怨也沒停過：說明文件很少提到它其實建立在哪些開源專案之上、模型命名方式讓人誤以為跑的是完整版而不是蒸餾版、效能落後 llama.cpp 直跑三到七成。壓力大到讓 Ollama 在 5 月的 0.3.0 RC15 版本裡，乾脆宣布改回直接用 llama.cpp 當底層引擎，理由包括跟不上新模型架構的速度、需要盡快支援 GPT-OSS 這類新模型，還有社群的壓力。
這不代表這次 MTP 加速是假的。數字是真的，benchmark 是真實的 coding 任務，機制也解釋得清楚。但如果你是把 Ollama 當成生產環境或內部工具的信任基礎，這兩件事得放在一起看。技術做得好，不代表資安跟透明度也做得好，這是兩碼子事。
你該做的兩件事
如果你本來就在 Mac 上用 Ollama 跑 Gemma 4 做 coding agent，這次升級幾乎沒有代價。同樣的輸出品質，換來接近一倍的生成速度，值得馬上更新。
但如果你是在評估要不要把 Ollama 導入團隊的生產流程或內部服務，這篇不是叫你別用，而是提醒你把資安更新頻率、GGUF 檔案來源的信任邊界，一併排進評估清單，而不是只看最新一則官方推文的加速數字。
順帶一提，如果你正在把 Mac 桌面環境整理成適合跑本地模型、開發 coding agent 的工作站，桌面開發者裝備組合這類機械鍵盤、USB-C Hub、螢幕掛燈的基本盤，是先把桌面弄順、再談效能優化的合理起點。
Gemma 4 在 Mac 上快了 90%，這數字沒有灌水。但如果你打算把 Ollama 放進團隊的生產環境，先把今年那份資安公告讀完，再決定要不要賭這個信任。