當各大 AI 公司競相推出數百億參數的模型、雲端 API 費用居高不下的時候，一個有趣的問題浮現了：家裡那些還躺在舊電腦裡的老顯卡，到底還能做什麼？能做的事可能比你想像的多！最近有位國外神人將一張 8 年前的 NVIDIA GTX 1060 6GB：2026 年連文書機都嫌過時的規格，搭配一顆 i3-8100 處理器和 24GB DDR4 記憶體跑 35B 參數的 Qwen 3.6 混合專家模型（MoE），竟然能以每秒 17 個 token 的速度、256K token 的超長上下文穩定運行，只有搭配五個 llama.cpp 的啟動參數。
Qwen 3.6 35B A3B：為低 VRAM 場景設計的 MoE 模型
先來認識主角，Qwen 3.6 35B A3B 是阿里巴巴 Qwen 團隊在 2026 年 4 月發表的開放權重模型。雖然總參數高達 350 億，但它採用混合專家（Mixture of Experts, MoE）架構：256 個小型專家網路中，每次處理一個 token 時只啟動 8 個，因此實際運算量僅約 30 億參數。這意味著，大部分的模型權重其實是「睡著的」。
影片作者選了一台「最慘的測試機」：8 年前的 GTX 1060 6GB（PCIe Gen 3）、8 年前的 i3-8100（4 核無超執行緒）、24GB DDR4 記憶體。如果是你的設備比這台好，而絕大多數情況都是你的速度只會更快。
預設值：ngl 20，每秒 3 個 token
傳統的作法很直覺：把模型切一半，上半層放 GPU、下半層放 CPU（透過 `–ngl` 參數控制層數）。結果是每秒約 3 個 token，一句話要等 20-30 秒才出現——開發者稱之為「衛星電話體驗」。
關鍵洞見：MoE 模型不能這樣分
問題出在 dense 模型的思維：當一個層被分配到 CPU 時，該層包含的所有專家權重也一併留在 CPU，每個 token 都需要透過 PCIe 匯流排傳輸大量資料。但 MoE 模型的特性是專家區塊佔了大部分權重，而且每次只啟動少數專家。正確的做法是：把永遠活躍的小型層留在 GPU，把大部分時間休眠的大型專家推到 CPU。
第一參數：–n-cpu-moe 41，速度暴漲 230%
llama.cpp 有一個專為 MoE 設計的參數：--n-cpu-moe。設定為 41，意思是每一層的專家全部釘在 CPU 上，其餘部分送進 GPU。
同一台機器、同一個模型、只改一個參數，速度從 3 tok/s 直接躍升到 10 tok/s，提升 230%。
第二參數：不要讓 OS 自作聰明（no-mmap）
預設情況下，llama.cpp 會用記憶體映射（mmap），假裝整個模型檔案在 RAM 裡，實際上還在磁碟上，由作業系統按需分頁載入。聽起來聰明，但每隔幾個 token，模型會要一個還沒載入的專家：磁碟讀取、等待、token 延遲。--no-mmap 這個參數指示 llama.cpp 在啟動時把整個 20GB 模型一口氣讀進 RAM。一旦載入完成，所有專家隨時可用，推理過程中不再有磁碟存取。速度從 10 tok/s 提升到 13.5 tok/s，再拉升 35%。
第三參數：調整 n-cpu-moe 到 35，突破 17 tok/s
這時候 GPU 還沒吃滿，還有 2GB VRAM 閒置。把 --n-cpu-moe 從 41 降到 35，把 6 層的專家從 CPU 拉回 GPU，更多工作在 GPU 上完成，更少資料穿越 PCIe。VRAM 使用從 4GB 增加到 5.5GB，速度從 13.5 跳到 17 tok/s。但這有個取捨：GPU 佔用越多，留給 context window 的空間就越少。上下文從 100K token 縮水到約 64K token。對一般對話足夠，但要餵入整個程式碼庫就不太夠了。
第四、五參數：Turbo Quant 壓縮，無痛拿回 256K 上下文
Context window 之所以耗費 VRAM，是因為模型需要為每個 token 儲存兩組數字（Key 和 Value），這個 KV cache 隨上下文線性成長。開發者原本已經使用 Q8 量化（近乎無損），但再往下壓到 Q4、Q3 時，回答品質就會明顯下降。
解決方案來自 Google DeepMind 今年稍早發表的論文 Turbo Quant，：隨機旋轉（random rotation）搭配激進量化——Key 用 4 bit、Value 用 3 bit，但品質幾乎與 Q8 無異。 bash --cache-type-k q4_0 --cache-type-v q3_0 這兩個參數的成果是驚人的：Context 從 64K 拉回 128K，VRAM 僅 5.3GB，沒有 OOM。再進一步推到 256K，把一片專家層調回 CPU（n-cpu-moe=36）精準卡在 5.9GB/6GB 的邊緣，速度維持 17 tok/s 不變。256K token 是什麼概念？等於同時餵入一本小型書的內容，模型不會在讀到第 50 頁時忘了第 1 頁的內容（目前主流模型 Context 也是 200K左右）。
第六參數（生產環境版）：–mlock，鎖定記憶體
這是最容易被忽略但攸關長期穩定的關鍵。當伺服器運行一段時間後，記憶體壓力或系統閒置可能導致部份專家被 page out 到磁碟，下次推理時就會觸發 page fault，出現隨機的卡頓。 解法涉及三個層級：LXC 容器需要權限、Docker 需要 IPC lock capability、llama.cpp 需要 --mlock 參數。三者缺一不可，否則會無聲無息地退化。三管齊下後，mlocked 達到 16GB，每個專家都被黏在記憶體中。運作一週也不降速，這是生產環境等級的穩定性。
為什麼 speculative decoding 在 MoE 上失敗？
影片作者還誠實地分享了失敗嘗試：speculative decoding。概念很漂亮：用小模型猜測下 8 個 token，大模型一次性驗證。然而在 Qwen 3.6 35B 上，速度從 17 tok/s 降到 11 tok/s。
原因有二：第一，MoE 模型每個 token 各自挑選不同的專家，8 個 token 的批次可能觸及 64 個不同的專家，變成記憶體風暴而非批次；第二，該模型使用 state space layer（40 層中有 30 層是 SSM），每一步依賴前一步的狀態，無法平行化驗證。
五個參數，一個 Docker 指令
總結整個配置：
--n-cpu-moe 41 → 35：MoE 專家分流，3 → 10 → 17 tok/s--no-mmap：預先載入模型至 RAM，10 → 13.5 tok/s--n-cpu-moe 36：微調 GPU 佔用，拿回 256K context--cache-type-k q4_0 --cache-type-v q3_0：Turbo Quant 壓縮，64K → 256K 上下文--mlock：鎖定記憶體防置換，長期穩定不降速
這段影片傳達的核心訊息是：硬體不再是瓶頸，預設值才是。一張 8 年前的 GTX 1060、8 年前的 i3、普通的 DDR4，透過五個參數調整，就能以閱讀速度流暢運行 35B 參數的模型，且上下文長達 256K token。任何人只要擁有這十年內的任何硬體、較新的顯卡、更快的 RAM 的話，數字只會更好看，這也突顯了在使用 AI 模型時依照適合的軟體，搭配正確的「調教」可能比傻傻堆硬體配置重要的多，不過老實說這對一般入門者也有一定的門檻，想嘗試的人建議多爬文、多請教大神，你也可以在有限的資源裡玩出最大化的效果。
有興趣的朋友可以觀看這部影片自己實作看看：