一張既有 GPU 自建本地 AI，關鍵在模型分工與核查

圖片：Wikimedia Commons／Pang Ka Kit（CC BY 2.5）

TechLab 編輯部（譯）·2026-10-28

XDA Developers 作者分享其以一張已有的 16GB RTX 4070 Ti Super 及 Ryzen 5 7600X，自行託管多個 AI 模型的做法：把網頁研究、寫程式與圖片生成分派給不同模型，而非要求一個模型包辦全部工作。這對已有合適 GPU、重視資料留在本機的用戶有參考價值。

不過，這是作者個人的設定與測試，未經獨立驗證；「零訂閱費」亦不等於零成本，因為硬件購入、耗電、儲存空間和設定時間都沒有計入。更重要的是，即使用模型接上搜尋引擎，輸出仍可能帶有無法追溯的資料。

三類工作，各用不同模型

作者把工作流分成三部分：

研究：BigBang-v1 為 Qwen3.6-35B-A3B 的微調版本。作者透過 MCP 將 llama.cpp 的網頁介面接到 Exa 搜尋引擎，並以免費 API key 搜尋資料。
程式編寫：Qwen3.8-27B 用於寫程式。作者指它的生成速度較慢，但其個人使用感受較佳。
圖片生成及編輯：FLUX 3 Image Klein 配合一個 9B Qwen3.5 prompt 擴寫模型及一個 4B Qwen3-VL 文字編碼模型，經 ComfyUI 運行。

這個配置反映本地 AI 的一項實際取捨：與其追求「萬用模型」，不如按任務挑選模型。好處是可把既有 GPU 的效能用在最合適的工作；代價則是要管理多個模型、檔案、介面及授權條款，入門門檻不低。

16GB VRAM 仍要借用系統 RAM

作者使用的研究模型量化檔約 19.3GB，大於顯示卡的 16GB VRAM。他以 llama.cpp 的 --n-cpu-moe 參數，將約 7GB 模型專家權重移至系統 RAM；其個人測得在 128K context window 下可達每秒 68 至 78 個 token。

程式模型的量化檔約 14.3GB，理論上可放入 VRAM，但 32K context window 的快取再需約 2GB。因此執行環境會把 64 層中的 6 層移至系統 RAM；作者稱生成速度約為每秒 15 至 17 個 token。

這說明 VRAM 容量不能只按模型權重計算。context window、KV cache，以及模型是否屬於 mixture-of-experts（MoE）架構，都會改變 RAM 與 VRAM 的分配。把部分資料移到系統 RAM 可以令模型「跑得起」，但未必代表能維持同樣速度；實際表現亦取決於 RAM、CPU、儲存裝置和使用情境。

搜尋可補足時效，不能取代來源核查

作者以一條關於 Windows 11 26H2 已知問題的近期問題測試 BigBang-v1，稱模型以五次搜尋找出 Microsoft 當時確認的問題、日期及 KB 編號。不過，他同時發現模型加入了一個自己無法回溯至 Microsoft 的 KB 編號和修正方法。

這正是把本地模型接入搜尋工具時最需要留意的限制：搜尋可讓模型取得訓練資料截止日後的資訊，但模型仍可能把檢索所得內容與推論混合，甚至補上看似合理但沒有依據的細節。涉及更新狀態、漏洞、產品規格或操作指引時，應直接打開原始來源核對，不宜只看模型的摘要。

圖片工作流省去額度，換來操作複雜度

作者指其 FLUX 3 Image Klein 工作流以 INT8 版本運行，ComfyUI 會在各階段把相應模型載入 VRAM；在其硬件上，五次 1024×1024 圖片生成平均約 16 秒，其中採樣約 4 秒，其餘時間大多用於擴寫 prompt。

本地生成的吸引力在於沒有雲端用量上限和輸出水印，但並非按下按鈕便完成。作者亦承認，ComfyUI 對初次使用者並不容易掌握。此外，FLUX 3 Image Klein 採用 FLUX Kommunity License，原文所述條款容許非商業使用，並在附帶條件下容許年收入低於 500 萬美元者作商業使用；使用前仍應自行閱讀適用條款。

對已有 GPU 的人而言，這個案例較適合作為容量規劃和工作流分工的參考，而非硬件或模型推薦。接下來值得觀察的是，本地工具能否把模型下載、記憶體調配、搜尋來源展示及圖片工作流整合得更易用；在此之前，來源核查仍應留在使用流程之中。