展示 HN：為 5090 找到的最佳本地 LLM 設定（llama.cpp 分支 + turboquant）

本文詳細介紹瞭如何在單張 32GB VRAM 的 NVIDIA RTX 5090 顯示卡上，透過 llama.cpp 的 TurboQuant 分支和 YaRN 縮放技術，執行 Qwen 3.6 35B MoE 模型，並實現高達 450,000 token 的上下文視窗。該方案已在 Windows 上完整實現並執行，但核心引數同樣適用於 Linux 系統。

模型選擇與量化權衡

選用的模型為 Qwen3.6-35B-A3B-Q6_K.gguf（28.5GB）。該模型採用混合專家（MoE）架構，每 token 僅啟用約 3B 引數，兼顧速度與推理能力。量化級別選擇 Q6_K 而非更低的 Q4 或 Q5，以保留超過 99% 的原始 BF16 困惑度，確保複雜程式碼生成的邏輯準確性和語法結構。

記憶體預算與上下文校準

在 32GB 物理視訊記憶體中，模型權重佔用 28.5GB，靜態開銷約 0.8GB，剩餘約 2.7GB 用於上下文。標準 FP16 KV 快取僅支援約 32K token。為實現 450K 上下文，採用兩項關鍵技術：

1. KV 快取量化（TurboQuant）：使用 --cache-type-k turbo3 和 --cache-type-v turbo3 將 KV 快取壓縮至 3 位，減少約 80% 的快取佔用，使 450K 上下文適應剩餘視訊記憶體。該功能基於社群分支 TheTom/llama-cpp-turboquant。

1. RoPE 縮放（YaRN）：模型的原始上下文長度為 262,144 token，透過 --rope-scaling yarn 和 --rope-scale 1.72 擴充套件至 450K。需注意，超出原生範圍會導致檢索準確率和推理能力顯著下降，困惑度隨上下文長度增加而上升。

多模態設定

模型支援影像輸入，需下載對應的視覺投影器 Qwen3.6-35B-A3B-mmproj-F16.gguf，並透過 --mmproj 引數載入。注意，llama.cpp 的影像解碼器基於 stb_image 庫，僅支援 PNG 和 JPEG，不支援 WebP 格式。

技術複製指南

提供了完整的模型下載指令碼和伺服器啟動引數。推薦使用 --no-mmap 強制模型權重連續載入到視訊記憶體，--flash-attn 開啟快閃記憶體注意力機制，-ngl 99 將所有層和輸出張量解除安裝至 GPU。另外，為管理近乎佔滿視訊記憶體的後臺程序，實現了基於 Go 的按需生命週期管理，透過 Web 儀表板控制伺服器的啟停，確保釋放視訊記憶體供其他應用使用。

效能評估與程式碼生成

測試中，模型成功生成了一個包含 Three.js 的互動式 3D 場景，程式碼一次性編譯執行，展示了其處理大型程式碼庫的能力。透過配置 OpenCode 客戶端的 modalities 塊，可解鎖影像拖放支援，實現多模態開發輔助。

結論

在消費級硬體上執行 35B MoE 模型並實現 450K 上下文，體現了本地推理最佳化的進步。但該方案處於 32GB 視訊記憶體的物理極限，幾乎無動態分配餘量，且擴充套件上下文會犧牲檢索忠實度和邏輯推理準確性。對於關鍵任務，建議保持上下文在原生範圍內；450K 限制更適合探索性搜尋和廣泛總結任務。