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

作者：Ian
發布：2026-10-13
更新：2026-10-13
實作紀錄期間：2026-10-10 至 2026-10-12
正式網址：https://ianinfra.com/knowledge/local-ai-egpu-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 通道

| 項目 | 本次配置與證據範圍 |
| --- | --- |
| 主機 | ASUS NUC 14 系列 MiniPC；既有硬體紀錄為 NUC 14 Pro+／NUC14RVH，未在本輪重核機身標籤 |
| CPU | Intel Core Ultra 5 125H，14 核心、18 執行緒 |
| 記憶體 | Samsung 32GB＋Crucial／Micron 48GB，合計 80GB DDR5 SODIMM，5600 MT/s，容量不對稱 |
| 系統顯示容量 | 79.3GB，硬體保留 699MB；79.3GB 不是安裝容量，也不是當下剩餘量 |
| GPU | GIGABYTE AORUS AI BOX，RTX 5060 Ti 16GB；遙測總量 16,311 MiB |
| 連線 | 外接 eGPU 經 USB4，PCIe 協商 Gen4 x4；卡片回報最大 x8 |
| SSD | ZHITAI TiPlus7100s 2TB NVMe，沿用既有硬體紀錄 |
| 系統 | Windows 11 Home 25H2，沿用既有版本紀錄 |
| 顯示器 | 一台接 NVIDIA 獨顯，一台接 Intel Arc 內顯 |

記憶體由 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 的分工。

| 配置項 | 設定 |
| --- | --- |
| 主測量化 | ISTA-DASLab GSQ-RCO IQ3_S |
| 比較量化 | Unsloth UD-IQ4_XS |
| 引擎 | Strata 0.1.41；部署 commit 為 fb58e0dbc8399662c0e47c76578c6e878b14f6cf |
| 上下文窗口 | 131,072 tokens；輸入與輸出共用 |
| 思考模式 | 非思考，reasoning_effort=none；三題回讀 reasoning_content 均為空 |
| KV cache | INT8；32,768 個位置常駐 VRAM，其餘串流 RAM |
| VRAM 保留 | 1,536 MiB |
| CPU pool workers | 8 |
| 併發範圍 | 單一請求 |
| 品質測試採樣 | temperature 0.7、top_p 0.8、top_k 20、presence_penalty 1.5 |
| 服務範圍 | 僅本機 loopback；本輪沒有建立引擎常駐或開機自啟機制 |

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 已逐一比對一致。每個版本、每題各一次，沒有挑選重跑成功的答案。不同量化發布者與隨機採樣都可能影響結果，不能把單題差異全歸因於位元數。

| 題目／輸入 tokens | IQ3 首字／總時間 | IQ4 首字／總時間 |
| --- | --- | --- |
| 證據與容量判讀／263 | 3.77／14.47 秒 | 8.47／28.03 秒 |
| Python 事件合併／143 | 2.22／48.62 秒 | 4.02／69.22 秒 |
| 長文跨段檢索與計算／124,002 | 256.49／260.03 秒 | 318.11／325.69 秒 |

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

| 題目 | IQ3 結果 | IQ4 結果 |
| --- | --- | --- |
| 容量判讀 | 把安裝 80GB 混成顯示 79.3GB，失敗 | 同樣失敗 |
| Python 事件合併 | 生成案例與額外有限案例實際執行通過 | 有限案例通過，但漏了要求的繁體中文說明 |
| 長文 | 找到前、中、後來源與更新版本；173−29＋16 誤算成 162 | 答出 160，並辨識舊值 47 已被 29 取代 |

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

| 長文資源，每 3 秒取樣 | IQ3 | IQ4 |
| --- | --- | --- |
| 最低可用 RAM | 11.21 GiB | 8.90 GiB |
| 最高觀察 GPU 使用 | 15,044 MiB | 14,960 MiB |
| OOM | 未觀察到 | 未觀察到 |

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

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

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

| 配置 | 容量項正確次數 |
| --- | --- |
| Strata，自動 CPU 分工、MTP 開啟 | 0／4 |
| Strata，CPU share=0、MTP 開啟 | 1／4 |
| Strata，CPU share=0、MTP 移除 | 0／4 |
| llama.cpp b11429，直接讀同份 GGUF、無 MTP | 0／4 |

另兩題把條件明確分列，無 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 秒**的生成遙測。它和後面的受控基準是不同測試，不混成同一組速度。

| 指標 | 觀察值 |
| --- | --- |
| GPU SM 使用率 | 平均 97.1%，中位數 99% |
| GPU 功耗 | 平均 61.2W，上限 180W，約 34% |
| VRAM 頻寬使用率 | 平均 25.7% |
| PCIe 接收 | 平均 2,115 MB/s，取樣峰值 5,338 MB/s |
| 溫度 | 41–52°C，未見降頻事件 |
| 引擎 host-to-device | 另次部署量到約 3.1 GB/s，量測方法不同 |

高 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 數一致。

| 指標 | A：原配置 | B：per-layer |
| --- | --- | --- |
| 中位 decode tok/s | **27.75** | **27.75** |
| 平均 tok/s | 28.31 | 27.56 |
| 範圍 tok/s | 26.50–30.50 | 24.50–30.20 |
| expert 命中率中位數 | 74.8% | 74.5% |
| 兩臂載入 slots | 3,776／3,786 | 3,840／3,840 |

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

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

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

| 項目 | 結果與判斷依據 |
| --- | --- |
| 螢幕全移到內顯 | 未執行，我決定維持配置；模型未載入時桌面佔約 1,061MiB |
| 移走常駐 embedding 模型 | 該次讀到 size_vram=0，已在 CPU，沒有顯存可釋放 |
| INT8 KV 改 k8v4 | 推算只多約 46 slots（1.2%），未採用；不是完成 A/B 後證明無效 |
| KV 常駐降至 20,480 | 實際 prompt 達 22,664，會越過新門檻；評估後撤回 |
| per-layer expert cache | 已做 ABBA；兩組中位數同為 27.75 tok/s，未測得改善 |
| KV prefetch | 開啟已由 log 確認；8K–22K 工作負載低於 32,768 常駐門檻，測試無收益 |
| message-boundary cache | 特定重複前綴測試大幅有效，但未符合兩個實際用途的新增收益條件，未採用 |

小幅增加 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 模型卡](https://huggingface.co/ISTA-DASLab/Qwen3.8-Flash-Next-GSQ-RCO-GGUF)、[Unsloth GGUF](https://huggingface.co/unsloth/Qwen3.8-Flash-Next-GGUF)。引擎分工與配置參考：[Strata 模型文件](https://github.com/Niko1221/Strata/blob/fb58e0dbc8399662c0e47c76578c6e878b14f6cf/docs/MODELS.md)。上游資料與本機實測分開使用。

下一篇：[DSH 接本地 AI：工具能用之後，瓶頸才開始浮現](/knowledge/dsh-local-ai-bottlenecks/)