2026 年自架 LLM 真的可行。一張 4090 跑量化過的 70B。一張 H100 跑同一個未量化版。硬體是簡單的部分 — 你挑的軟體 stack 決定自架是好玩、生產力工具、還是全職工作。
Hobby 等級:Ollama
晚上玩跟學習,Ollama 是對的起點。一個指令(ollama run llama3.1)就下載並跑任何熱門模型。GGUF 量化、GPU 偵測、模型儲存、OpenAI 相容 API 全部自動處理。DX 真的好。
什麼時候用 Ollama:在學習、做原型、side project 不需要超出自己機器的 scale、想試多個模型不想 commit。
弱點:不是為高吞吐建的。並發請求會序列化、沒有 batching、OpenAI 相容 API 不完整。不要放在真實用戶前面。
Hobby 等級加 GUI:LM Studio
LM Studio 是 Ollama 的 GUI 表親 — Mac/Windows/Linux 桌面 app,Ollama 能做的它都能做,加上模型搜尋、chat UI、可以給 script 打的 server。對非工程師更好用,工程師會覺得比 Ollama 略不可駭一點。
什麼時候用 LM Studio:想在本地模型上有 chat UI、想下模型不用跟 Hugging Face 角力、想讓朋友或非工程師合作者用本地模型。
Side-project 等級:text-generation-webui、KoboldCpp、llama.cpp 直用
比 Ollama 多控制,沒那麼精緻。text-generation-webui(oobabooga)是雜貨店 — 支援更多模型格式、更細採樣控制、roleplay 優化。KoboldCpp 是著重故事 / RP 的分支。llama.cpp 自己就是這些東西包的核心。
什麼時候用這些:想調採樣參數、把 RP 角色聊天當興趣、特別需要 GGUF 支援、想找專案學習。
Production 等級:vLLM
認真部署都用 vLLM。連續 batching、paged attention、跨多 GPU 的 tensor 並行、FP16 / INT8 / INT4 量化、OpenAI 相容 API。吞吐量比 Ollama 或 text-gen-webui 高很多。
什麼時候用 vLLM:把模型放在真產品後面、有多並發用戶、需要可預期延遲、至少一個能仔細讀文件的工程師。
弱點:不是隨插即用。第一次會跟 GPU 記憶體配置、模型載入、config 角力。回報是一個 server 能輕鬆處理 100+ 並發請求。
Production 等級替代品:TGI、llama.cpp server、Modal
- HuggingFace TGI — vLLM 主要對手,也好。優化選擇略不同。看你用的特定模型誰支援得好就選誰。
- llama.cpp server — CPU only 或中等 GPU 部署。比 vLLM 慢,但能在 vLLM 拒絕的硬體上 work。
- Modal / RunPod / Together — 受管自架。你不跑 GPU,你跑 code,在他們的 GPU 上執行。想要自架靈活但不擁有硬體的中庸選項。
- SGLang — vLLM 較新對手,某些 workload 上有時更快。如果你被吞吐量綁住,值得比較。
硬體:實際該買什麼
2026 年單機配置:
- RTX 4090(24GB) — 跑 70B Q4 量化舒服、13B 未量化、所有 7B 都自由。二手約 $1800。
- RTX 5090(32GB) — 比 4090 好,70B Q5/Q6 量化能跑。零售約 $2500-3000。
- 2× RTX 4090 — 兩張卡用 tensor 並行跑 70B 更高品質。二手約 $3600 + 不錯的 PSU。
- A100 / H100 — 個人用過頭,小團隊有意義。二手 A100 80GB 約 $8-12k。
- Mac Studio M3 Ultra — 因為統一記憶體出乎意料能打。192GB 共享記憶體能跑 70B 未量化。每 token 慢,但沒有其他 2026 桌面消費級硬體能跑這 size 的模型。
雲端 GPU(不買硬體):Lambda Labs、RunPod、Together、Modal 都穩。按小時付費代表你只在用的時候付,但 24/7 server 大概 6 個月後自有硬體比較划算。
量化選擇
GGUF 格式(Q4_K_M、Q5_K_M、Q6_K、Q8_0)用品質換 size。粗略法則:
- Q8_0:幾乎無損、size 減 50%
- Q6_K:極小品質損失、size 減 60%
- Q5_K_M:可察覺但輕微品質損失、減 65%
- Q4_K_M:實質但可接受品質損失、減 70%
- Q4 以下:嚴重退化,只給絕望的資源限制用
Production 自架,Q5_K_M 或 Q6_K 是甜蜜點。AWQ 跟 GPTQ 是 vLLM 支援的替代量化格式 — trade-off 不同但結果類似。
什麼時候不適合自架
每月在 Anthropic API 上花 $300,在考慮自架?不要。硬體 $2000+、電費是真的、你的時間是真的。留在 API。
你有 ops 能力嗎?團隊只有一個工程師同時對產品負責,不要再加自架 GPU server。半夜兩點掛掉的那天,不是學 vLLM 內部的時候。
模型適合你的場景嗎?先在 API 上跑實驗。如果 Claude 或 GPT 在產品上 work,換自架 Llama 代表接受一些品質下降,常常超過你預期。不要把自架當第一個成本優化。
實用配置 recipe
小型 production 部署:
- 硬體:1× H100(租或自有)、64GB 系統 RAM、NVMe SSD
- OS:Ubuntu 22.04 LTS
- 推論:vLLM 加
--enable-prefix-caching跟--max-model-len 16384 - 模型:Llama 3.1 70B Instruct,FP8 量化
- 反向 proxy:Caddy 或 nginx 處理 TLS
- 監控:Prometheus + Grafana 看 token 吞吐跟 GPU 使用率
- 日誌:結構化 JSON 送到你既有的工具
- 認證:簡單 API key 或 OAuth — 不要無認證 expose
這個 stack 在典型聊天 workload 下能輕鬆處理 50-100 並發用戶。
決策樹
- 興趣、單用戶:Ollama 或 LM Studio
- side project、想 tinker:text-gen-webui 或 llama.cpp
- 真產品、真用戶、自有硬體:vLLM + 自有 GPU
- 真產品、沒硬體預算:Modal、Together、RunPod
- 只有 Mac、大模型:Ollama + Mac Studio M3 Ultra
- 只有 CPU:llama.cpp server
下一步
- 讀一下特定量化格式:GGUF Q4 vs Q5 vs Q6
- 看 LoRA 推論,服務基底模型的微調變體
- 讀 vLLM 特定調校:max_num_seqs、gpu_memory_utilization
- 早點設好監控 — 出事前你就會想要它