6 月 5 日釋出的 Ollama 0.30 是一次引擎層更新：透過 llama.cpp 的改進，把效能與 GGUF 模型相容性一起往前推。這次的重點不是新增什麼炫技功能，而是讓「本地跑模型」在更多硬體上更省事——Apple silicon 上的 MLX engine 獲得補強，其他平台則透過 GGUF 引擎拿到更多模型與更快的執行速度。
NVIDIA 最高 20%：一個附帶測試條件的數字
官方部落格的帳面亮點，是 NVIDIA 硬體吞吐量最高提升 20%。這個數字值得先看條件再看大小：它來自 NVIDIA 團隊與 llama.cpp 維護者的協作優化，實測組態是 Gemma 4 26B 模型、RTX 5090、Q4_K_M 量化。「最高」與單一組態是兩個必須一起讀的限定詞——換了模型、換了量化、換了顯示卡，數字不保證重現；但這批優化進的是 llama.cpp 上游，會隨引擎散布給所有使用者，不是只存在於示範環境。
Vulkan 預設啟用：GPU 加速去掉安裝門檻
比 20% 更影響採用體驗的改動，是 Vulkan 改為預設啟用。過去在 AMD 或 Intel GPU 上啟用加速，得先安裝廠商特定函式庫，而這一步往往是整條路的失敗點；現在 GPU 加速開箱即用，更多硬體直接受惠。要留意的是，官方貼文沒有提供 Vulkan 與各家原生後端的效能比較數據，追求極致吞吐的重度使用者仍值得自行實測再決定後端；但對多數「先把模型跑起來」的場景，預設路徑已經夠用。
GGUF 相容性擴大，Hugging Face 匯入三步完事
模型生態方面，GGUF 相容性明顯擴大：LFM、Prism 這些新興家族，以及 Unsloth 發布的 fine-tuned 模型，現在都能開箱即跑，不必再等官方模型庫收錄或自寫轉換腳本。從 Hugging Face 匯入自己下載的 GGUF，流程與 Ollama 既有習慣一致：
FROM ./my-model.Q4_K_M.gguf
ollama create -f Modelfile my-model
ollama run my-modelModelfile 用 FROM 指向 GGUF 檔案（或包含 GGUF 檔案的目錄），create 之後就跟模型庫裡的任何模型一樣用 run 啟動。沒有轉檔腳本、沒有後端設定，這是本次更新對日常工作流最直接的減法。對追新模型的團隊，這個擴充把等待時間也拿掉了：fine-tune 生態每週都有新版本，過去要碼等官方模型庫收錄、要碼自己維護轉換腳本，現在兩條路都縮成一行 FROM，模型發布到本地可用之間不再有加工層。
Tool calling 沿用：把本地模型掛上 coding agent
對開發者最實用的一條：GGUF 模型若本身支援 tool calling，這個能力會沿用到 Ollama，不因匯入而消失。先用 ollama show my-model 檢查輸出中的 tools capability，確認之後就能把本地模型掛到 coding agent 與 personal assistant 後面；官方給的指令形式是 ollama launch claude --model my-model，hermes 與 openclaw 同樣適用。落地順序可以照這樣排：先用 show 確認 capability，再用 launch 掛進 agent，最後用一個小任務驗證端到端行為——例如請 agent 呼叫一個簡單工具並檢查回傳——三步都過再放進正式流程。
（此段為我的詮釋）這條路徑的價值在於選擇權：coding agent 背後的模型來源不再只有雲端 API 一種，隱私敏感或成本敏感的場景多了一個本地選項。當然，工具呼叫的品質取決於模型本身，匯入前先確認 capability、匯入後先跑小任務驗證，是必要的兩道檢查。
短文如實讀：廠商數據與未涵蓋的問題
這篇公告本身不長，有幾個誠實的讀法：20% 是廠商自述且綁定單一組態，未經獨立驗證；Vulkan 的實際效能表現、GGUF 目錄多檔案的選檔行為，公告都沒有展開，這些留給社群實測補上。升級建議因此很簡單：NVIDIA 使用者升級後用自己的模型跑一輪 benchmark 再下結論；AMD 與 Intel 使用者直接驗證 GPU 是否真的被用上；打算匯入的 GGUF，先用 ollama show 確認 tool calling 是否存在。0.30 的價值不在數字多驚人，而在把本地模型工作流的三個摩擦點——安裝門檻、模型相容、agent 整合——各自推掉了一層。
參考來源
本文由 AI 協助自上述來源整理，經人工審核後發布。