llama.cpp vs vLLM：本機模型引擎怎麼選

[IND] 2026年6月22日3 分鐘閱讀OraCore 編輯部

這篇比較 llama.cpp 和 vLLM，幫你判斷是要用 CPU 友善、適合單人本機推理的方案，還是適合多使用者、高併發服務的 GPU 推理引擎。

這篇比較 llama.cpp 與 vLLM，幫你判斷本機推理該選低門檻的單機方案，還是高併發的服務型引擎。

llama.cpp 和 vLLM 都能在本地跑開源權重模型，但一個偏向個人電腦與低併發，另一個偏向多使用者與正式部署。這篇是寫給正在選模型引擎、想先把硬體成本與效能風險算清楚的人。

一張表看懂

每週精選模型發布、工具應用與深度分析，直送信箱。不定期，不騷擾。

不會寄垃圾信，隨時可取消。

比較維度	llama.cpp	vLLM
最適合場景	單人使用、低併發本機推理	多使用者服務、正式推論部署
測試模型與環境	Llama 3.1 8B、FP16、1 張 NVIDIA H200、最高 64 名使用者	Llama 3.1 8B、FP16、1 張 NVIDIA H200、最高 64 名使用者
64 人併發吞吐	基準值，約比 vLLM 低 44 倍	約比 llama.cpp 高 44 倍 token 吞吐
64 人 P99 首 token 延遲	超過 180 秒	在負載測試中維持低且穩定
模型封裝	GGUF 單檔格式	Hugging Face 風格載入，加上服務功能
硬體傾向	CPU 優先，可選 GPU 加速	GPU 優先，支援 NVIDIA、AMD、Intel、TPU 等加速器

llama.cpp 的價值，不在於它把效能推到最高，而在於它把「能跑」這件事變得很容易。對很多人來說，真正的門檻不是模型本身，而是硬體門檻；llama.cpp 讓你可以先用筆電、桌機，甚至 VRAM 不大的小主機開始做本機推理。

它最適合的情境，是你主要在意離線工具、個人助理、原型驗證，或是只有少量同時使用者的內部應用。表格裡的 64 人測試已經說明了一件事：一旦併發上來，llama.cpp 的延遲會明顯惡化，所以它不是拿來扛大量請求的首選。

vLLM 的設計重點是「服務」而不是單純「執行」。它的 continuous batching 和 PagedAttention，目的就是讓 GPU 更有效率地吃滿工作量，同時控制 KV cache 壓力，避免請求一多就排隊失速。

這個差異在負載測試裡非常明顯：同樣是 64 名使用者，vLLM 的 token 吞吐量大約是 llama.cpp 的 44 倍，而且首個 token 的 P99 延遲也能維持在較低水準。只要你要做 API、多人共用服務，或是希望延遲在高流量下仍然可預期，vLLM 就更像是正解。

llama.cpp 的優勢，常常不是在跑分，而是在部署自由度。GGUF 單檔格式讓模型搬移、備份、離線分發都很直覺，對沒有完整 MLOps 團隊的人尤其友善。你不用先把一整套服務框架搭起來，先把模型跑起來再說，這是它很實際的價值。

vLLM 的優勢則是把「服務化」做得更完整。當請求數變多，模型載入、批次處理、快取管理、輸出穩定性，這些平常不顯眼的細節會直接變成使用者體感。若你在意的是產品體驗而不是單次啟動成本，vLLM 的工程取向會更合適。

如果你是個人開發者、研究者，或只是想在自己的電腦上安靜地跑模型，先選 llama.cpp。它對硬體要求比較寬容，也比較適合做離線筆記、摘要、問答、Side project，重點是上手快、成本低。

如果你要的是多人共用、API 對外、或公司內部正式服務，請直接看 vLLM。它更適合有 GPU 資源、需要穩定吞吐與延遲控制的團隊，特別是當你已經預期會遇到併發問題時。

如果你現在還拿不定主意，通常先用 llama.cpp 做本機驗證最省事；唯一會改變答案的情境，是你從一開始就知道會有明顯的多人同時使用，那就該直接上 vLLM。

// 相關文章