返回首頁

GitHub Repo

Ollama 預覽版納入 Qwen3.8 Flash Next 記憶體優化,改為按需載入嵌入表

Ollama 最新預覽版納入 MLX 記憶體優化,維護者回報 Qwen3.8 Flash Next 的鎖定記憶體由 97.6 降至 70.8 GiB。更新以按需搬移嵌入表資料與混合精度量化降低負擔,長提示效能與生成品質仍須實測。

Mattruffoni · CC BY-SA 4.0 · Image source
zh-Hant

Ollama 於 11 月 9 日的發布列表列出 v0.40.16 預覽更新,其中納入 Qwen3.8 Flash Next 的 MLX 記憶體優化。相關程式碼已於 11 月 6 日合併,如今進入預覽發布流程;維護者回報,模型的鎖定記憶體由 97.6 降至 70.8 GiB,目標是改善 128 GiB Mac 的本機推論可行性。這項數字描述特定記憶體指標,不能直接視為整台機器的總用量。發布列表、合併提案

優化針對模型內一張約 26.8 GiB、採 NVFP4 格式儲存的 PLE 嵌入表。每次前向運算只會存取少數經雜湊選出的資料列,原先卻須承擔整張表常駐的成本。新路徑將 safetensors 分片映射至主機位址空間,只把需要的壓縮資料列及尺度參數搬入 MLX 解量化,其他布局仍保留常駐處理方式。載入階段也排除這些張量,避免啟動時先配置整張表再釋放。實作與審查

量化策略同時有所調整。作者指出,全面套用 NVFP4 會損害長篇生成,因此讓敏感的 QSA 投影與非專家 MTP 路徑保留 BF16,其他適合的稠密與控制權重使用 MXFP8,路由專家及嵌入表則維持 NVFP4。這讓記憶體配置與數值精度成為共同設計問題。量化設計

這種處理方式與模型架構有直接關係。Ollama 模型頁列出 125B 總參數、每個 token 啟用 6B 參數,另有大型 N-gram 嵌入表。對工程師而言,稀疏啟用降低運算量,仍須另外處理權重儲存與搬移成本;按存取特性安排資料位置,是這次更新的實際價值。模型架構說明

部署前仍應分別量測提示預填、逐 token 解碼與長對話峰值。維護者表示目標解碼吞吐量未見可量測下降,但討論中也曾出現長提示預填偏慢的回報,缺乏對照測試。模型頁仍列出 105GB 套件大小,下載容量與執行期鎖定記憶體應分開判讀;接下來需觀察正式版收錄,以及相同硬體、提示長度下的可重現結果。效能討論、套件資訊

來源

  1. Ollama 發布列表:v0.40.16 預覽更新
  2. MLX: make Qwen3.8 Flash Next memory efficient #18078
  3. Qwen3.8 Flash Next 模型與架構說明