llama.cpp、Ollama、LM Studio、vLLM

定位

llama.cpp 是底層 C/C++ LLM 推論引擎。
它的核心價值是可攜、輕量、可控，特別適合在 CPU、Apple Silicon、消費級 GPU、邊緣設備或內網伺服器上執行 GGUF 模型。

優點

• 控制力最高，可細調 GPU offload、context、batch、threads、KV cache 等參數。

• 支援 GGUF 與多種量化格式，適合在有限 VRAM/RAM 下跑模型。

• 可透過 llama-server 開 HTTP API，支援 OpenAI-compatible API。

• 適合離線部署、內網部署、資安可控環境。

• C/C++ 實作，部署相對輕量，不一定需要完整 Python/MLOps stack。

缺點

• 使用門檻較高。

• 模型下載、量化、路徑、參數、效能調校多半要自己處理。

• 對大量併發與高吞吐 GPU serving，不是最省事的選擇。

適合情境

• 單機或小型內網 LLM 服務。

• CPU/消費級 GPU 環境。

• 對部署可控性、離線性、可稽核性要求較高。

• 想直接掌控 GGUF 模型與推論參數。

定位

Ollama 是開發者友善的本地模型管理與 API 服務。
它把模型下載、執行、服務化包裝起來，讓開發者用很少指令就能在本機跑 LLM。

常見用法：

優點

• 上手最快，CLI 很直覺。

• 內建本地 API，適合程式串接。

• 可用 Modelfile 自訂 system prompt、template、參數、adapter。

• 適合 VS Code、RAG demo、agent、LangChain、內部工具快速整合。

• 對工程師而言，比直接操作 llama.cpp 省很多時間。

缺點

• 抽象層較高，底層參數可控性不如 llama.cpp。

• 大量併發、高吞吐、多 GPU serving 不是主要強項。

• 模型與 runtime 管理由 Ollama 包起來，企業正式部署時需額外規劃版本、模型來源、cache 路徑與權限。

適合情境

• 工程師本機開發。

• 快速建立本地 OpenAI-like API endpoint。

• 小型內部工具、PoC、RAG demo。

• 想快速測模型，而不想管理底層推論細節。

定位

LM Studio 是圖形化本地 LLM 工作站。
它的核心價值是使用體驗：模型搜尋、下載、聊天、調參、文件聊天、本地 API server 都能透過 GUI 完成。

優點

• GUI 體驗最好。

• 適合非工程使用者直接試用模型。

• 可搜尋與下載 Hugging Face 模型。

• 支援本地聊天、文件聊天、prompt/config 管理。

• 可啟用本地 API server，供其他程式呼叫。

• 適合 PoC、demo、模型比較、內部展示。

缺點

• Desktop app 不是像 llama.cpp / Ollama / vLLM 那樣完整開源的基礎設施元件。

• 不建議當正式多人服務後端核心。

• 企業資安稽核時，要特別確認授權、版本更新、runtime 下載、模型下載來源、local logs 與資料保存位置。

適合情境

• 主管、PM、客服、內部使用者試用本地模型。

• 模型挑選、prompt 測試、文件聊天 demo。

• 不想先寫程式，只想先確認模型效果。

定位

vLLM 是高吞吐 LLM serving engine。
它跟 llama.cpp 一樣屬於推論/serving 後端，但設計目標不同：vLLM 的重點是 GPU server 上的多人併發、高 throughput、OpenAI-compatible API、KV cache 管理與 serving 效率。

核心價值

vLLM 的代表性技術是 PagedAttention。
PagedAttention 的目的，是改善 LLM serving 時 KV cache 動態成長、記憶體碎片、batch size 受限等問題，讓 GPU 在多請求併發時可以更有效率地被使用。

優點

• 適合正式 API serving。

• 適合多人併發、高吞吐場景。

• 支援 OpenAI-compatible HTTP server。

• 適合 RAG backend、內部 Copilot、客服助理、agent gateway。

• 支援 tensor parallel、pipeline parallel 等 server-side scaling 能力。

• 生態偏向 Hugging Face / MLOps / Kubernetes / Ray / GPU cluster。

缺點

• 部署複雜度高於 Ollama、LM Studio。

• 通常需要較完整的 Python/GPU/MLOps 環境。

• 不適合拿來取代 LM Studio 的 GUI 體驗。

• 也不應把它簡單視為「更快的 GGUF llama.cpp」；vLLM 對 GGUF 的支援不是它的主場。

適合情境

• 一整個部門或多系統共用 LLM API。

• 需要高併發、低延遲、高吞吐。

• 有 NVIDIA/AMD/Intel server GPU。

• 要部署 RAG、內部 Copilot、客服助理、agent backend。

• 要把 LLM 服務納入正式監控、壓測、擴縮容與平台治理。

GGUF 生態

GGUF 是 llama.cpp 生態的主力格式。
以下工具都很常見於 GGUF 場景：

• llama.cpp

• Ollama

• LM Studio

GGUF 的優勢是方便量化、方便本地跑、對 CPU/消費級 GPU 友善。

Hugging Face / safetensors 生態

vLLM 的主場通常是 Hugging Face 模型格式與 serving-oriented quantization，例如：

• safetensors

• AWQ

• GPTQ

• FP8

• INT8 / INT4

這類格式與生態更常見於正式 GPU serving、MLOps、Kubernetes、Ray、模型倉庫與 CI/CD 流程。

不建議的誤解

不要把 vLLM 視為「更快的 Ollama」或「更快的 LM Studio」。
也不要直接把 vLLM 視為「更快的 GGUF llama.cpp」。

比較合理的理解是：

PoC 階段

建議使用：

原因：

• LM Studio 給非工程人員快速試模型、試 prompt、試文件聊天。

• Ollama 給工程師快速串 API、做 RAG demo、測 agent flow。

• 這個階段重點是驗證模型效果，不是追求最終效能。

小型正式服務

建議使用：

適合條件：

• 使用者數量不多。

• 併發量有限。

• 單台工作站或單張消費級 GPU 即可承擔。

• 重視離線、簡單維運、內網部署。

中大型正式服務

建議使用：

適合條件：

• 多人同時使用。

• 多系統共用 LLM API。

• 有 GPU server。

• 需要監控、壓測、擴縮容、服務等級管理。

• 要支援 RAG、客服助理、內部 Copilot、agent gateway。

為什麼需要 LLM Gateway

不建議讓所有系統或所有使用者直接打推論服務。
即使是內網，也應該透過 gateway 控制：

• 誰可以用哪個模型。

• 每個人或每個系統的呼叫量。

• 是否允許上傳文件。

• prompt 與回應是否要留存。

• 是否記錄 token usage。

• 是否允許敏感資料輸入。

• 是否要做內容過濾或遮罩。

1. 本地推論不等於零風險

即使模型在本機或內網跑，仍然可能有以下風險：

• prompt history

• chat log

• model cache

• runtime cache

• API logs

• crash logs

• 使用者上傳文件暫存

• 模型下載來源風險

• plugin / extension / MCP server 風險

2. 模型授權要獨立審查

工具可商用，不代表模型權重可商用。
導入時至少要確認：

• 模型 license。

• 是否允許商業使用。

• 是否允許內部再散布。

• 是否允許 fine-tune。

• 是否要求標註來源。

• 是否有限制用途。

3. 固定版本與模型來源

正式服務建議固定：

• 模型名稱。

• 模型版本。

• quantization 格式。

• runtime 版本。

• container image。

• prompt template。

• context length。

• sampling parameters。

不要讓 production 服務自動抓 latest model 或 latest runtime。

4. 記錄與稽核

至少應規劃：

• API 呼叫者。

• 使用模型。

• token usage。

• 時間戳記。

• 錯誤碼。

• latency。

• 是否保留 prompt 與 completion。

• 敏感資料遮罩規則。