展示 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 限制更適合探索性搜索和廣泛總結任務。