2026 Qwen3.8-27B 下載驗收：Mac 上線前清單

截至 2026 年 8 月 14 日，第三方整理的前代 27B 模型資料顯示，BF16 權重總量約 55.6GB，而「約 17GB 可執行」的說法其實接近 5-bit 量化的權重級別，尚未包含上下文快取與執行器開銷。相關資料與計算方式 因此，我們本週的建議很明確：先做 Qwen3.8-27B 下載驗收，再決定是否讓它進入本機 Agent；只要來源、模板、工具呼叫或持續運行其中一項不合格，就更換構建版本、回退成熟模型，或轉到臨時雲端 Mac。

這篇文章適合三類讀者：準備把模型接入本地編碼助手或 AI Agent 的開發者；需要形成可複核模型選型結論的技術負責人；以及沒有空閒高記憶體 Mac、需要判斷是否值得申請臨時雲端環境的測試人員。

最後更新於 2026 年 8 月 14 日；發布狀態、模型檔案與授權需以 Qwen 官方模型頁面、ModelScope、Hugging Face 及執行器最新文件為準。

先分清「成功啟動」與「驗收通過」

最容易誤判的案例，是終端機已經出現模型回覆，普通問答也能正常產生文字，但接入 Agent 後，模型把工具參數寫成不符合 JSON schema 的自然語言，或在工具回傳一次結果後直接中斷。這不是單純的「Mac 不夠快」，而可能是模型模板、量化構建、執行器解析或工具呼叫能力沒有對齊。

公開的 MLX Swift 問題記錄曾出現「模型似乎載入，但權重結構或參數鍵不正確」的情況，維護者指出，載入流程若未完整驗證，可能把缺少的權重誤當成正常模型結構。MLX Swift 公開問題記錄 這正是我們需要把驗收拆成五層的原因：

1. 來源層：是否為官方權重，或只是社群轉換包。
2. 檔案層：分片、設定、tokenizer 與模板是否完整。
3. 執行層：MLX 或 Ollama 是否真正辨識模型架構。
4. 任務層：輸出品質、格式、工具參數是否符合業務要求。
5. 穩定性層：連續任務、上下文增長及異常恢復是否可接受。

只通過第一層或第二層，仍不能把模型標記為「可上線」。

下載前先鎖定來源、版本與責任邊界

Qwen3.8-Max 的官方公告在 2026 年 8 月 3 日提到，Qwen3.8-Max 將開放權重，並表示 Qwen3.8-27B 也會開放權重；公告同時列出 Max 為 2.4T 參數、95B active，但這些資料不能直接套用到 27B。Alibaba Cloud 官方公告

下載 Qwen3.8-27B 前，我們會先建立一張版本紀錄表，而不是直接複製社群指令：

截至本文更新時，27B 是否已完整提供權重、模型卡、LICENSE、量化版本與原生執行器說明，必須以官方頁面當日實際可見內容核對。ModelScope 的官方模型頁面可作為檔案樹與提交紀錄的檢查入口；若頁面暫時只有模型名稱、倒數或不完整檔案，不能把第三方「即將可下載」的文章當成發布證明。ModelScope 模型頁面

第三方文章提到的「17GB」只能當作待驗證線索，不能變成 Mac 記憶體採購結論。因為精度、上下文長度、KV cache、執行器及並發請求都會改變實際佔用。

下載後按檔案清單逐項驗收

下載完成後，不要先執行聊天指令。我們建議先把原始權重與轉換版本分開存放，再檢查以下項目：

• 權重分片數量是否與模型卡或檔案樹一致。
• 每個分片是否完成下載，沒有零位元或明顯異常的小檔案。
• config.json 的模型類型、層數、詞彙表及上下文設定，是否與模型卡一致。
• tokenizer.json、tokenizer_config.json 或同類 tokenizer 檔案是否齊全。
• chat_template 是否存在，或是否由執行器自行套用模板。
• generation_config 的停止詞、採樣預設值是否與測試紀錄一致。
• LICENSE、README、轉換腳本與量化說明是否可以追溯。
• 檔案雜湊值是否已保存，方便後續更新後比對。

如果使用 MLX 版本，必須確認它的基礎倉庫、轉換日期、量化位元數及是否修改 tokenizer 或模板。MLX LM 官方文件指出，它可以載入 Hugging Face 上符合 MLX 格式的模型，也支援模型轉換與量化；但「MLX 可載入」不等於任何社群模型都具有相同的任務品質。MLX LM 官方文件

如果使用 GGUF，則應查看 GGUF 來源、轉換工具、量化方法及模板設定。不要因為檔名包含 Q4、Q5 或 Q8 就自行推測檔案大小、品質或上下文能力。

提醒： 原始 Safetensors、MLX 轉換包及 GGUF 不應混在同一個資料夾中測試，否則日後很難判斷問題來自模型本身、轉換流程，還是執行器。

首次載入先驗證執行器，而不是直接跑完整 Agent

MLX 路徑

Apple Silicon Mac 上使用 MLX 時，先確認 macOS、MLX 及 mlx-lm 版本，再查看載入輸出是否包含正確的模型類型、tokenizer 與量化資訊。對大型模型，MLX LM 官方說明指出，較新的 macOS 版本可透過 wired memory 相關設定改善大型模型運行，但模型相對於整機記憶體過大時仍可能變慢。大型模型與記憶體說明

第一輪只做最小文字請求，接著依序檢查：

1. 模型是否完成載入，沒有 missing key、shape mismatch 或 tokenizer 錯誤。
2. 是否能產生完整文字，而不是只輸出半句便停止。
3. 串流輸出是否連續，停止詞是否在預期位置生效。
4. 同一個問題重複兩次時，採樣設定是否一致。
5. 第二輪對話能否引用第一輪已提供的關鍵資訊。

Ollama 路徑

Ollama 官方文件支援以 Modelfile 的 FROM 指向 GGUF 檔案，也支援部分 Safetensors 模型匯入；但支援的架構與格式需要逐項核對，不能把其他 Qwen 版本的指令直接套用到 Qwen3.8-27B。Ollama 匯入模型文件

基礎流程可寫成：

FROM /absolute/path/to/model.gguf

然後使用：

ollama create qwen38-27b-check -f Modelfile
ollama show qwen38-27b-check
ollama run qwen38-27b-check

這些指令只代表匯入流程，不代表模型已通過 Agent 驗收。Ollama 官方建議可用 ollama show 查看模型 capabilities；若要接工具，還要確認 tools 能力是否存在，並用實際 schema 測試，而不是只看模型能否回答一般問題。Ollama GGUF 與工具呼叫說明

第一小時完成目標任務驗收

第一小時不應花在問模型常識題，而要使用準備上線的真實任務。對編碼助手，我們會準備一個小型程式修改、測試失敗修復及差異摘要；對 AI Agent，則加入工具呼叫、錯誤回傳、檔案讀取及中斷後恢復。

建議固定以下測試條件：

• 相同系統提示與 chat template。
• 相同 temperature、top-p、最大輸出長度與停止詞。
• 相同工具 schema、工具名稱及參數描述。
• 相同測試資料、檔案內容與上下文順序。
• 每次測試保存輸入、完整輸出、工具請求及錯誤訊息。

工具呼叫要觀察四件事：是否選對工具、工具名稱是否完全一致、參數是否符合 JSON schema，以及工具回傳後能否繼續完成原任務。長上下文則要逐步增加資料量，檢查模型是否遺忘中段內容、錯誤引用早先資料，或在尚未完成任務時自行停止。

目前不能把多模態能力寫進 Qwen3.8-27B 的驗收結論，除非官方模型卡明確列出圖像或影片輸入，以及對應執行器的支援方式。Qwen3.8-Max 的官方公告與 27B 的開放權重計畫是不同層級的資訊，不能互相代替。

Qwen3.8-27B 下載驗收 FAQ

FAQ 放在完成檔案與首次載入檢查後，原因是許多問題必須先分清官方原始權重、MLX 轉換包與 GGUF 構建，否則很容易把格式問題誤判成硬體問題。

上線前用勾選清單形成可複核結論

下載與來源

• [ ] 已保存官方模型頁面、下載日期與 revision。
• [ ] 已確認模型卡、LICENSE、config 及檔案樹可見。
• [ ] 已分開保存官方原始權重與社群轉換版本。
• [ ] 已記錄構建者、轉換工具與量化方法。
• [ ] 已保存檔案大小及可取得的雜湊值。

檔案與執行器

• [ ] 所有權重分片均已完成下載。
• [ ] tokenizer、chat template 與 generation config 能互相對應。
• [ ] MLX 載入沒有 missing key、shape mismatch 或模板錯誤。
• [ ] Ollama 匯入後能以 ollama show 查看模型資訊。
• [ ] 最小文字請求、串流輸出、停止詞及多輪對話均正常。

Agent 任務

• [ ] 一般程式修改任務能完成並產生可檢查的差異。
• [ ] 結構化輸出符合固定 schema。
• [ ] 工具名稱與參數格式完全正確。
• [ ] 工具回傳錯誤後，模型能按預期修正或回報。
• [ ] 上下文增加後，模型仍能引用關鍵資料。
• [ ] 任務中斷後，模型能從保存狀態繼續，而不是重新胡亂規劃。

穩定性與回退

• [ ] 已完成連續任務測試，而不是只成功跑一次。
• [ ] 已記錄記憶體峰值、首字延遲、生成速度與異常退出。
• [ ] 已在目標並發量下測試，而不是只測單一請求。
• [ ] 已寫明本機可長期運行、需要更大環境復測，或目前構建不應上線。
• [ ] 已準備成熟模型、舊版構建或雲端 Mac 作為回退路徑。

我們會用三檔評分取代「這台 Mac 能不能跑」的二元判斷：

穩定性結果決定本機、升級環境或雲端回退

完成第一小時任務後，仍要做連續運行測試。至少應記錄首字延遲、生成速度、記憶體峰值、上下文增長後的變化、異常退出次數及恢復時間。這些數值必須來自同一台 Apple Silicon Mac、同一版本執行器與同一組提示，否則比較沒有意義。

需要特別留意三項隱性成本：

• 記憶體被上下文與其他程式分食：權重能放入記憶體，不代表長上下文仍有足夠空間。
• 模板與執行器責任不清：模型可以輸出文字，但工具呼叫格式可能由模板或中介層破壞。
• 版本更新造成結果不可重現：社群轉換包、Ollama、MLX 或模型 revision 任一更新，都可能改變輸出與載入行為。

如果團隊準備把結果寫入模型選型文件，建議保存以下資料：模型來源、revision、構建類型、量化方式、Mac 型號與記憶體配置、執行器版本、測試集、完整日誌、評分結果及回退方案。未來官方補上 LICENSE、模型卡或原生執行器支援時，才能在同一條件下重做比較。

若目前的 Windows、Linux 或自建伺服器方案已經能跑文字生成，仍可能存在三個實際缺點：硬體環境不在團隊手邊、Apple Silicon 路徑與本地工具鏈不一致，以及長時間測試時需要自行處理遠端連線、權限與維運。若正在比較本地設備與臨時環境，可先參考我們整理的 Mac 本地大模型硬體選擇思路；當本機沒有足夠空閒記憶體完成連續任務時，使用 JexMac 的臨時雲端 Mac 進行同一套驗收，通常比直接購買一台尚未確定用途的設備更容易控制成本與回退風險。需要查看可用方案時，再到 JexMac 方案頁面 核對配置與租用條件。

常見問題