16GB 外接顯卡跑 125B 本地 AI：配置、128K 驗收與效能上限

我想知道，一台已經在使用的 MiniPC，搭配 16GB 外接顯卡，能把本地語言模型做到什麼程度。需求很具體：繁體中文、程式與證據判讀，要有 128K 上下文，而且能接進日常工作流程。

這輪最後留下的基準是：Qwen3.8-Flash-Next GSQ-RCO IQ3_S，在 Strata 上完成 124,002-token 輸入的長文生成；另一組受控測速的暖機 decode 中位數是 27.75 tok/s。但長文算術與混合證據判讀仍有失敗。容量、速度、品質，是三份需要分開交付的結果。

本文是這台主機在 2026 年 10 月 10–12 日的實作紀錄，由我與 AI 工具協作部署、分析與核對。不是目前最佳模型排行，也不代表其他硬體能複製同樣速度。

硬體配置：80GB RAM，加上一條受限的 GPU 通道

記憶體由 32＋8GB 升級成 32＋48GB。新增的 Crucial 48GB RAM 購入價為 NT$20,999（2026-10-13 補充確認）。這是單條新增記憶體的實際購入價，不是整套 80GB 的價格，也不是目前市場報價；這輪沒有長時間記憶體壓力測試。

模型配置：權重、快取與上下文分開放

選用的是 Qwen3.8-Flash-Next 125B MoE。MoE 會選擇部分專家參與每步運算，但完整專家權重仍要有地方存放。這套配置保留完整專家，透過 Strata 管理 RAM、VRAM 與 SSD 的分工。

IQ3 模型 revision 為 ed59f92082b1e93c0e96d60a8b11aab089b52f09，兩分片已核對 SHA-256。IQ4 revision 為 38bb39ee97821de2c9009abb7e93950eec396e66，三分片共 93,682,584,224 bytes，同樣完成雜湊核對。

當時引擎文件記載，IQ3_S 下載約 83.6GB，其中專家約 50GB，另有約 28.8GB 查表資料留在 SSD，MTP 附加檔另計。這解釋了為什麼不能拿下載大小直接和 16GB VRAM 比較：GPU 快取部分專家，未命中時再搬入。下載容量、RAM 常駐量與 VRAM 使用量是不同數字。

部署時，原配置一度只剩約 176MiB 顯存餘裕；將保留量提高到 1,536MiB 後，重載觀察到約 1,022MiB 可用。這是當次狀態，不能當成所有請求都保有的固定餘裕。

128K 驗收：長文放得進去，還要檢查答案

以下三題，IQ3 與 IQ4 的保存請求 JSON 已逐一比對一致。每個版本、每題各一次，沒有挑選重跑成功的答案。不同量化發布者與隨機採樣都可能影響結果，不能把單題差異全歸因於位元數。

IQ3 Python 總時間在比較筆記另有 48.63 秒的記載；此表沿用部署原始摘要的 48.62 秒，不以這 0.01 秒差異做推論。

長文實際輸入 124,002 tokens，IQ3 輸出 82、IQ4 輸出 89 tokens。這是 131,072 窗口內的測試，不是塞滿 128K 輸入後再額外生成。IQ3 約等了 4 分 16 秒才出首字，長上下文的可運行性與互動體驗有很大距離。

取樣未必捕捉瞬間峰值。程式題也只做有限案例，沒有覆蓋混合時區等完整情境。因此，這輪證明了部署可行，尚不足以把模型升為可靠主力。

品質出錯後，我做了 18 次跨引擎診斷

容量題失敗後，沿用同份 IQ4 權重做 16 次原題，加 2 次獨立控制題。每組 temperature 0.7 與 0 各兩次、seed 11，維持非思考模式。下表只計容量欄位，並非整份回答得分。

另兩題把條件明確分列，無 MTP 的 Strata 分別在 4.53 秒答出「實體 80GB／顯示 79.3GB」，在 4.88 秒算出 160。原題的混合證據失敗仍成立，但也不能因此概括模型完全不會算數。

llama.cpp 首次以 42 層 MoE 專家置 CPU，在建立 131,072 窗口的 compute buffer 時顯存不足；調成 46 層才成功。這輪只做短題，沒有重新驗收 llama.cpp 長文。Strata 與 llama.cpp 的快取條件不同，也沒有拿它們的耗時做公平引擎排名。

我能排除的是「換個引擎或關掉 MTP 就穩定修復這題」。尚不能區分原始模型能力與量化損失，也沒有證據支持為了這個短題錯誤購買更多 RAM 或 GPU。

為什麼 GPU 顯示 99%，仍只有約 28 tok/s？

瓶頸診斷另取了一段 629 tokens、27 秒的生成遙測。它和後面的受控基準是不同測試，不混成同一組速度。

高 SM 使用率不能單獨證明算力已耗盡。結合低功耗、記憶體頻寬、快取與搬運量，這輪證據指向 expert 權重搬運是主要限制。PCIe 取樣峰值也不等於 USB4 持續有效吞吐量。

一次引擎載入記錄顯示，expert cache 是 3,875／24,576 slots，約 15.8%，佔 7.40GiB VRAM。slots 是層與專家的配對快取，覆蓋率不等於請求命中率：當次 decode 命中約 65.9%–72.6%，後面的暖機測試更高。依流量與生成量粗估，每 token 搬運約 91MB；這是推算量，不是每個 token 都固定搬這麼多。

KV 則是另一套快取。七次請求的 KV 命中率落在 95.15%–99.95%，長請求曾從 RAM 讀 247.5MiB。不能把最後一筆 99.95% 當作全程固定值，更不能混成 expert 命中率。

受控基準：27.75 tok/s 是怎麼量的

測試採 ABBA：A 是原配置，B 加上 per-layer expert cache。每臂重啟，固定四題暖機並丟棄結果，再跑四題、每題 400 tokens；每種配置合計 n=8。temperature 設為 0，確認這組測試輸出逐字與 token 數一致。

這裡的 slots 與前次載入的 3,875 不同，正是為什麼每次都要記錄資源狀態。臂內波動約 ±7%，本測試估計只能辨識約 5–7% 以上的效果；沒有量到改善，不等於數學上證明效果為零。

另外一次知識庫同題試用，IQ3 完整耗時 75.638 秒、IQ4 97.936 秒，正文速度分別 31.2 與 17.3 tok/s。這是跨日、各一次的觀察，不能替代上面的受控基準。

七項優化，為什麼最後都沒有採用

小幅增加 slots 的收益不能從另一項快取政策直接嚴格推導。per-layer 組多了約 54–64 slots 仍未測得收益，只能支持「在這輪解析度下不值得優先追」，不足以證明所有配置下增加 46 slots 都沒用。

prefetch 的第一個 A 臂是 37.9 秒，後三臂約 33.5 秒，包含第二個 A。若只做 A→B，就會誤認有約 11% 改善；ABBA 揭露了冷機漂移。

embedding 也有啟動順序的例外：Strata 停止期間，它可能先載到 GPU，曾觀察約 635MiB／0.62GiB 的占用，讓 Strata 下一次取得較少 slots。因此「當時在 CPU」不能寫成永久不會搶顯存。

真正影響等待的，還有讀提示時間

一次實際請求有 22,664 個輸入 tokens，prefill 34 秒；生成 524 tokens，19 秒。兩段合計約 53 秒，prefill 佔約 64%。即使假設生成提高至 40 tok/s，簡化估算仍要 34＋524÷40，約 47 秒。這是估算，並非改機後實測。

message-boundary cache 測試更明顯：固定 14,162-token 歷史，只換尾端短訊息，後續輪次從 33.5 秒降到約 0.4 秒，約 84 倍；log 從 0 reused／14,162 read，變成 14,146 reused／16 read。這是特定 prefill 重用的效果，不是整個應用快 84 倍。

這項測試的冷輪約 33.5 與 34.0 秒。原始筆記同時記錄「多 487ms」與 33,978／33,514ms，兩者不一致；依所列數值相減為 464ms，本文只採「約半秒」，不把不一致的精確值當結論。

我的知識庫當時每次送全新單輪請求；DSH 的累加式聊天則已有一般 prompt cache 可重用。因此沒有採用這個新開關。更小量化、改硬體連線或縮短證據，仍是不同方向，但品質代價、成本與實際收益尚未完成比較。

這輪的交付：知道能跑，也知道停在哪裡

對我而言，成果是建立一條可追查的界線：這台 MiniPC 能運行這份模型與長上下文；在固定題目上，暖機 decode 中位數是 27.75 tok/s；USB4 eGPU 的權重搬運限制值得重視；回答品質仍需獨立驗收。

這輪檢查的七個方向沒有留下值得採用的設定，不代表所有未來版本、所有工作負載都沒有優化空間。把已知失敗、樣本數與量測邊界留下來，下一次升級模型或引擎才有基準可比。

資料來源與閱讀範圍

本機數據來自 2026-10-10 的 IQ3／IQ4 部署驗收、18 次跨引擎診斷，以及 2026-10-12 的遙測與 ABBA 紀錄；硬體資料來自升級紀錄。私人日誌與原始題目未公開，本文保留去識別後的測試條件與結果，不宣稱第三方已獨立重現。

模型來源：ISTA-DASLab GSQ-RCO 模型卡、Unsloth GGUF。引擎分工與配置參考：Strata 模型文件。上游資料與本機實測分開使用。

下一篇：DSH 接本地 AI：工具能用之後，瓶頸才開始浮現