標準型 AI 電腦
日常 AI 工作與創作的均衡主力，在速度、模型尺寸、圖像工具及 RAG 工作流之間取得更完整的平衡。
這個方案是為誰而設？
標準型方案適合已經確定會長期使用本地 AI 的用家。與入門級相比，這個級別的重點是提高 VRAM、RAM 及整體系統餘量，讓 8B–14B 級量化模型、RAG、Embedding、AI Coding 及部分視覺工作可以在同一部機上並行進行。
支援的 AI 模型與工具方向
以下列出的模型及工具是「適用方向」而非代表任何一個固定配置可以無限制高速運行所有項目。實際可用性取決於模型版本、量化格式、VRAM、Context、解析度及工作流。
模型 / 平台
- Llama 3.1 / 3.3 8B
- Qwen3 8B / 14B
- Gemma 3 12B
- Mistral 系列
- RAG / Embedding Models
常見工作
- 企業文件 RAG
- AI Coding / IDE 輔助
- 多輪長 Context 對話
- 本地知識庫
- 輕至中度 AI 圖像工作流
- 多模型切換與測試
適合人群
需要把 AI 真正融入日常工作的專業人士、程式員、內容創作者、小型企業及本地資料處理用家。
建議硬件方向
如果主要使用 8B 模型，12GB VRAM 已有相當實用的空間；若希望更舒服地使用 14B 級量化模型、RAG、較長 Context 或同時運行其他 AI 程式，16GB VRAM 會更有彈性。RAM 建議 32GB 起，重度工作則考慮 64GB。
配置邏輯
Ollama / LM Studio → Open WebUI → Embedding + Vector DB → RAG → Local Coding Assistant。使用 Gemma 3 12B、Qwen3 14B 等模型時，實際速度與可用 Context 應按量化格式及系統 VRAM 測試，而不是只看模型名稱。
模型容量與 VRAM：不要只看「幾 B」
模型大小 ≠ 實際所需顯存
模型參數量只是第一個指標。推理時還要考慮權重精度、量化格式、KV Cache、Context 長度、Batch Size、Framework 及其他 runtime 開銷。因此「14B / 32B / 70B」不能直接等同於一個固定 VRAM 數字。
量化與 Offload
4-bit、8-bit 等量化可以降低權重記憶體需求；CPU RAM Offload 則可以把部分資料放到系統記憶體，但通常會犧牲速度。多 GPU 亦需要從主機板 PCIe、電源及散熱整體規劃。
適合的實際工作流
| 工作流 | 建議方向 | 注意事項 |
|---|---|---|
| Local Chat | Ollama / LM Studio + 量化 LLM | VRAM 決定可載入模型的彈性；Context 越長，額外記憶體需求越高。 |
| RAG | Embedding + Vector DB + LLM | 資料庫規模、Embedding 模型及同時運行服務會增加 RAM / SSD 需求。 |
| AI Agent | LLM + Tool Calling + Browser / Files | 需要穩定長時間運行；Agent 工具本身未必是本地模型。 |
| 圖像 / 影片 | ComfyUI / Diffusion / Video Workflow | 解析度、模型、ControlNet、LoRA、幀數及 Upscale 都會影響 VRAM。 |
實際配機時，我們會看什麼？
① 先確認模型
先列出你真正會使用的模型、版本及量化格式，再估算權重、KV Cache、Context 與其他 Runtime 所需資源。這樣可以避免只按「8B、14B、32B」等參數量作錯誤判斷。
② 再確認工作流
同一張 GPU 用於 Local LLM、ComfyUI、AI Video、RAG 或 Agent，瓶頸可能完全不同。工作流會直接影響 VRAM、RAM、CPU、SSD、散熱及電源的比例。
③ 最後規劃升級
如果預計未來增加模型尺寸、加入 AI 圖像／影片、Fine-tuning 或 Agent，首次配置應預留 RAM、SSD、電源、機箱及 PCIe 擴充空間，避免短期內重新砌機。
直接告訴我們你想跑甚麼。
模型名稱 + 用途 + 預算，已經足夠作為第一次配機討論的起點。