Ollama v0.40.12 聚焦提示詞速度與小型影像細節
Ollama 已發布 Ollama v0.40.12 發行候選版本，當中包含四項改動，針對本地模型效能、影像處理及底層軟件依賴項。這個區別很重要：其提示詞處理改進與生成改進來自不同變更，並各有不同限制。
核心重點在於「支援某個模型」與「讓它高效運行」之間的差距。模型可以成功載入，卻仍可能低效處理文件，或流失有用的影像細節。此版本處理的是這個差距的具體例子，而非宣布推出新的模型系列。
比較亦延伸至 Ollama 本身以外。Apple 的機器學習陣列框架 MLX，為圍繞其底層操作進行開發的研究人員提供更直接的途徑。Ollama 的角色，是將這些能力整合至模型運行時環境，即執行模型的軟件。對應用程式開發者而言，這項整合決定哪些上游改進真正能惠及其工作負載。
Ollama v0.40.12 實際改變了甚麼
這是針對性的運行時更新，而已發布的產物仍是發行候選版本。
這個發行候選版本的標籤為 v0.40.12-rc0，雖然其顯示標題寫作 v0.40.12。GitHub 將其標記為預發布版本，日期為 2026 年 10 月 27 日。其比較基準始於 v0.40.11。
這個命名差異值得注意，因為單憑顯示標題並不能證明穩定版本已經推出。評估升級的讀者應區分已發布的候選版本與任何後續穩定版本。關於此建置版本的發現，應保留其完整標籤。
列出的變更涵蓋精簡 Gemma 4 影像處理、MLX 依賴項更新、DFlash2 支援，以及 llama.cpp 依賴項更新。四項條目均列 dhiltgen 為貢獻者。整體而言，這些變更描述的是多個執行路徑上的維護，而非單一、通用的加速功能。
這個範圍令此版本因不同原因而與不同群體相關。使用受影響影像模型的開發者面對的是正確性問題。等待提示詞處理改善的開發者面對的是回應速度問題。測試已支援生成加速的開發者則面對另一個效能問題。
解讀這項公告時，這些問題應保持區分。更快的文件處理不一定代表更快生成答案。保留影像細節也不代表所有視覺任務的準確度都會提高。更新依賴項並不說明每一部受支援裝置都能獲得甚麼好處。
因此，較有用的框架是按工作負載分析：哪一項操作改變了、哪個模型會使用它，以及應用程式哪一部分依賴該操作？這些問題比起將每一項更新日誌條目都視為本地 AI 普遍提速的證據，能帶來更具可操作性的理解。
對文件助理而言，最相關的改進可能發生在任何答案出現之前。對截圖助理而言，則可能關乎從輸入中保留了多少資訊。對生成較長回應的應用程式而言，生成路徑可能更值得仔細檢視。
這些是分析示例，而非已報道的客戶部署案例。它們說明了即使使用相同介面，同一個版本為何會以不同方式影響不同應用程式。可見的產品可以保持熟悉，但底層執行的工作卻可能改變。
這次更新亦促使應用程式維護者重新檢視舊有假設。先前的比較可能反映的是較早期的執行路徑，而非模型長期存在的限制。反過來說，新的基準測試也不應在未進行另一輪比較前，抹去生產工作負載中的既有證據。
這就是像此類維護版本的實際意義。它提供具體理由重新評估現有行為，同時仍未解答關於模型質素及部署適用性的更廣泛問題。
小型影像揭示載入與看見之間的落差
這項影像變更處理的是模型生成答案前的資訊流失。
這項精簡視覺修正涉及 Gemma 4 的精簡視覺塔，即將影像轉換為模型輸入的元件。根據該 pull request，動態尺寸調整可能將最小影像網格向下取整，低於原定的 70 個 token 預算。
在此，token 是用於表示影像資訊以供模型處理的單位。這項變更會為精簡視覺塔將該網格向上取整，並以上一個受支援預算為上限。維護者表示，明確指定的預算，以及較大型和統一式視覺塔的既有尺寸調整方式，均維持不變。
這是一項範圍狹窄的修正，卻有一項實用含意。當輸入在準備階段流失細節，後續推理便無法可靠地恢復缺失資訊。即使模型能力強大，仍取決於運行時環境傳遞給它的內容。
試想一個應用程式要回答一張含有狀態標籤的小型截圖問題。如果準備過程移除了相關細節，改寫問題措辭未必能解決根本問題。應用程式需要讓視覺證據保留得足夠久，以供解讀。
這個情境解釋了影像處理為何屬於效能討論的一部分。使用者評價的是完成後的任務，包括系統是否正確讀取輸入。快速送達卻錯過相關標籤的回應，會造成額外工作。
不過，這項修正不應被延伸為精簡模型現已能準確處理所有小型影像的說法。來源指出的是一種尺寸調整行為及有限度修正，並未證實截圖、掃描文件、圖表或相片的普遍結果。
影像尺寸亦不足以完整說明難度。一張包含顯眼符號的小圖，與一張包含密集文字的小圖，面對的是不同挑戰。評估應反映實際應用程式預期抽取的資訊。
最清晰的比較方式，是在不同建置版本中保留原始影像及問題不變。若在評估期間以不同方式調整影像尺寸，便會為答案變化引入另一種解釋。目標是隔離正在檢視的運行時行為。
對維護者而言，這改變了調查失敗案例的方式。錯誤的視覺答案不一定源於模型習得的能力。輸入準備是另一個合理的層面，而這項修補提供了具體例子。
它亦改變了對早期負面結果的解讀。若受影響配置丟棄了有用資訊，較舊的測試可能低估該配置在修正後可提供的能力。這種可能性值得重新測試，而非把先前結果改寫為無效。
更廣泛的教訓在於模型比較的邊界。單憑模型名稱並不能描述正在評估的完整系統。影像準備、執行軟件及應用程式行為，都有助決定最終送達使用者的答案。
Ollama MLX 效能在答案開始前已有改善
提示詞速度變更加快讀取請求的過程，而維護者明確表示解碼速度維持不變。
這項提示詞處理更新更新了 MLX 及其 C 語言介面 MLX-C。它採用原生滑動視窗注意力機制，將相關注意力操作限制在模型輸入的移動視窗內。
維護者報告了在 Apple M5 Max 上的預填充改進。預填充是生成新輸出前處理輸入的階段。使用 2,048-token 提示詞時，報告吞吐量對 Gemma 增加 9.2%、Flint 增加 14.5%、Laguna 增加 24.1%。
使用 6,144-token 提示詞時，對應的報告增幅分別為 7.5%、14.3% 及 27.0%。這些是維護者針對指定模型配置的測量結果。該 pull request 表示，解碼速度，即生成輸出的速率，維持不變。
這項限定界定了 Ollama MLX 效能聲稱的範圍。等待長篇文件被讀取的使用者，與等待長篇答案的使用者，面對的是不同瓶頸。改善前者並不能證實後者也有所改善。
當請求包含大量支援材料但只要求簡短回應時，這點尤其相關。在這類假設工作負載中，處理輸入可能是整體體驗的重要部分。即使後續輸出以相同速率送達，更快的準備過程仍然重要。
相反情況則需要不同解讀。包含短請求及大量生成輸出的應用程式，可能只花相對少時間處理提示詞。其整體體驗不應僅從預填充吞吐量推斷。
這些百分比描述的也是吞吐量，而非等待時間的普遍縮減。端到端延遲，即完成整個請求所經過的時間，包含的不止是測量到的處理階段。載入、應用程式額外開銷及其他工作，都令任何直接換算變得複雜。
這個區別可避免常見的報道錯誤：將一個元件的改進，表述為完成任務也有同等改進。基準測試可以準確描述該元件，同時仍不對應用程式結果作出定論。
這個版本給予開發者更具體的理由調查長輸入工作負載，但並不要求他們在測量前就下結論，說其應用程式變得更快。兩者是不同的證據標準。
對組合文件上下文的團隊而言，影響亦延伸至評估設計。重用先前計算工作的快取輸入，應與全新輸入區分。否則，重複請求可能掩蓋這項更新影響的是哪一類處理工作。
因此，可信的應用程式比較應描述使用者提交了甚麼，以及系統重用了甚麼。缺少這個區分，看似微小的差異可能掩蓋改進；看似巨大的差異也可能另有原因。
Ollama MLX 效能最有用之處，在於它是一項精確的工程聲稱。受影響階段、模型配置、硬件及輸入長度，讓讀者有具體內容可供測試。移除這些界限會令聲稱更廣泛，卻更缺乏資訊價值。
Ollama DFlash2 支援針對另一個瓶頸
DFlash2 關乎生成答案，因此其結果應與提示詞處理改進分開看待。
這項DFlash2 實作加入一種推測式生成方法，讓目標模型檢查建議的輸出。維護者描述了一個候選選擇器，讓連續選擇以先前選擇作為條件。
根據實作說明，一個工作階段每輪草擬七個 token，並透過既有的回退機制驗證它們。貢獻者表示，驗證會保留目標輸出分佈。這是實作層面的聲稱，而非本文呈現的獨立驗證。
該 pull request 將 DFlash2 與內建的多 token 預測頭作比較，後者是一種提出多個未來 token 的機制。就 qwen3.8:27b 而言，使用所列的低精度配置，維護者報告在 M5 Max、M5 Pro 及 M2 Ultra 系統上的生成效能均有提升。
在 M5 Max 上，使用較短的測試提示時，據報生成吞吐量由每秒 57.0 個 token 上升至 71.0 個 token。比較採用了相同的 build，而非將上一個版本與此候選版本直接測量比較。
這個最後的區別相當重要。這些結果比較的是同一 build 內的生成方法，不應被報道為每位由上一版本升級的使用者都可量度的效能提升。
因此，Ollama 的 DFlash2 支援增加了一條評估途徑，而非提供一項全面的速度承諾。支援的配置帶來比較行為表現的機會，但並不會告訴每個應用程式哪種生成方法可帶來最佳結果。
推測式生成的一般取捨很直接：當足夠多的提案可用，足以抵銷產生及檢查它們的工作時，提案才有幫助。若只評估提案階段，便會忽略驗證成本。
對應用程式開發者而言，完成的輸出比內部提出了多少候選 token 更重要。即使方法積極地起草內容，仍須有效率地產生獲接納的輸出。關鍵結果是在應用程式實際條件下產生有用內容。
除了速度，輸出行為亦值得仔細檢視。使用結構化回應的團隊應檢查，應用程式是否仍能收到預期格式。評估事實性答案的團隊，在引入另一條執行路徑時，應保留既有的正確性檢查。
這些是評估重點，而非證明此實作會造成格式或品質問題的證據。來源描述了旨在維持行為一致的保障措施。獨立的應用程式測試，才是團隊判斷自身要求是否仍然成立的方法。
支援與預設行為之間亦有報道上的區別。發布說明宣布某項能力，本身並不代表每個已安裝模型都會使用它。讀者須辨識任何觀察結果背後的實際配置。
這一點把此功能與本次發布的其他部分連繫起來。執行期改善須透過一連串兼容性及整合決定才會發揮作用。使用者看到的是答案，但所選模型及執行方法決定了哪些改動有所貢獻。
對於長篇答案工作負載，生成機制本身值得獨立關注。把其報告中的增益與無關的提示處理百分比結合，會構成缺乏支持的估算。每項改善都須配對相應工作負載，才可支持應用程式層面的結論。
依賴項更新令比較保持有據可依
較新的依賴項標示了基礎已改變，但並不能證明普遍的效能結果。
llama.cpp 更新將 Ollama 的依賴項由 build b11845 更新至 b11901。llama.cpp 是一個推理引擎，即執行已訓練模型以產生輸出的軟件。該 pull request 於 10 月 26 日合併。
可見的 pull request 連結至上游比較，但未提供對應的應用程式基準測試。這支持報道版本變動，卻不足以為每個使用該路徑的工作負載指定某項速度或品質改善。
這很重要，因為依賴項更新很容易被過度解讀。較新的 build 編號描述的是軟件沿革，並不指出特定應用程式有哪些操作改變，亦不能確立其既有瓶頸是否已轉移。
與直接使用框架的比較，有助釐清 Ollama 的定位。MLX framework直接向開發者提供程式設計介面及機器學習操作；Ollama 則將底層能力整合至模型運行環境。
兩種方法滿足部分重疊的需要，但承擔的責任層面不同。直接使用框架操作的研究人員可仔細研究實作選擇；使用整合式執行期的應用程式團隊，則依賴該執行期支援的執行路徑。
任何一種方法都不會在每項比較中必然勝出。直接存取提供控制權，而整合則可減少運行受支援模型所需的工作。公平的評估應問：應用程式團隊希望自行承擔哪些責任？
這個候選版本亦說明了為何上游和下游結果應保持區分。框架能力須經適當整合，應用程式才可受惠。反過來說，若模型本身沒有改變，整合式改善不應歸功於新模型。
這個區別影響競爭性主張。來自某一模型、裝置及執行路徑的結果，不能證明 Ollama 普遍地勝過其他執行期。它只證明了受測系統的結果，並包含該系統的界限。
目前可得的證據主要來自專案維護者。它支持這些改動的存在及其報告的量度結果，但未能提供關於生產環境採用、可靠性或不同部署選項優越性的獨立共識。
無須捏造公開爭議，才能令這些證據變得有意義。未解決的是一個實際問題：這些改動能否在維護者量度範圍以外的應用程式中帶來有用增益。即使沒有虛構的支持者或批評者，這個問題已足夠重要。
對企業採購者而言，恰當的審視應落在證據質素。廣泛展示本地 AI 的能力，不及與預定任務相符的結果有用。採購決策需要模型、硬件、工作負載及營運要求互相對應。
開發者亦可從保留比較背後的脈絡中受益。記錄評估的團隊可使用可搜尋知識庫，將結果連同配置及範例保存。有用的紀錄應包括失敗與限制，而不只是最快的一次運行。
三項訊號將顯示此候選版本的重要程度
下一批有意義的證據依次是發布進展、可重現的計時，以及經驗證的任務行為。
第一，留意已發布候選版本的後續發展。穩定版本產物、後續候選版本或修正發布，將釐清可供更廣泛採用的軟件。這些事件不會自動證明應用程式品質，但會解決發布狀態問題的一部分。
最具資訊價值的進展，會保留 tags 與改動之間的清晰關聯。這可讓開發者辨識後續結果涉及的是此候選版本還是經修改的 build。若沒有這種延續性，討論便可能把不同軟件的發現混在同一個簡寫版本名稱之下。
後續修正並不會自動否定本文所述的工作。其重要性取決於受影響的行為。讀者應尋找任何已報告問題、其範圍，以及所用配置三者之間的具體關係。
第二，留意可重現的應用程式計時結果，並將輸入處理與輸出生成分開。這將測試所報告的元件改善能否在原有量度條件以外維持。結果應列明實際模型配置及硬件。
來自相符工作負載的證據，會加強採用相關改動的理據。若比較顯示端到端效益不大，便會收窄這個理據，但未必與元件基準測試矛盾。應用程式可能只是把時間花在其他地方。
若計時報告同時描述全新及重複使用的輸入，便更具參考價值。它們亦應區分已載入的模型與必須載入模型的請求。這些條件回答的是日常使用中不同的問題。
第三，留意圖像處理及加速生成的任務層面檢查。圖像修正需要測試保留視覺資訊的例子。生成路徑除了計時外，也需要輸出檢查，特別是在應用程式依賴可預測結構的情況。
有用的報告會包括原始輸入、預期行為，以及每個比較配置的結果。這讓其他人可檢視該主張，而非依賴「答案看來較好」的說法。
對圖像任務而言，在簡單例子中答對，對困難輸入只提供有限證據。對生成任務而言，快速回應對應用程式兼容性亦只提供有限證據。任何結果的力度取決於它實際測試了甚麼。
這些訊號應一併解讀，但不應壓縮成單一分數。發布進展關乎發布產物；計時關乎執行；任務檢查關乎應用程式能否正確完成有用工作。
未來數月最有價值的後續資料，將會連結這些層面。與特定發布版本及具代表性任務相關的可重現結果，會加強實際採用的理據。缺乏支持的泛化說法只會增加關注，卻無法解決部署問題。
對正在評估 Ollama v0.40.12 的讀者，應先從你已有的重要工作負載開始。在比較 builds 前，保留其輸入、模型配置及預期輸出。分開記錄處理請求所花的時間，以及生成答案所花的時間。若圖像很重要，請保留原始檔案，並檢查你的應用程式所需的細節。若加速生成很重要，請在檢查速度的同時檢查完整回應。把候選版本的完整 tag 與你的發現一併保存，讓日後比較仍可解讀。然後圍繞一個具體結果作出升級決定：在你的應用程式實際面對的條件下，改變後的執行路徑是否改善了你的使用者真正執行的任務？
