VkingAI
返回博客
·开源生态

vLLM、Ollama、LM Studio 横评：自托管 LLM 到底该选谁？

试了一圈主流自托管方案，从吞吐实测到踩坑复盘，帮你找到最适合你场景的 LLM 部署方式。

#vLLM#Ollama#LM Studio#LLM部署#开源模型

# vLLM、Ollama、LM Studio 横评：自托管 LLM 到底该选谁？

自托管 LLM 这两年热度爆表。我试了一圈主流方案，今天来聊聊真实体验。

先说结论，再展开

  • 追求吞吐和生产环境 → vLLM
  • 追求开箱即用和易用性 → Ollama
  • 开发调试、桌面端用 → LM Studio
  • 边缘设备、本地部署 → llama.cpp

    • 这个排序不是拍脑袋，是我跑了三个项目之后得出的。

    vLLM：性能怪兽，但门槛不低

    vLLM 的核心优势是 PagedAttention。它把 KV Cache 按 page 管理，解决了显存碎片问题，吞吐量比 naive 实现高 2-4 倍。

    **实测数据（A100 80GB，Llama-3-8B-Instruct）：**

    | 配置 | 吞吐量 (tokens/s) | 延迟 (ms/token) |

    |------|------------------|-----------------|

    | vLLM (TP=1) | ~180 | ~5.5 |

    | vLLM (TP=2) | ~320 | ~3.1 |

    | HuggingFace Transformers | ~60 | ~16 |

    | Text Generation Inference | ~120 | ~8 |

    数字很直观。但 vLLM 不是人人都能用：

  • **必须 CUDA**——不支持 MPS，苹果芯片只能看

    • 2. **需要 Docker 或者 GPU 服务器**——本地 Mac 开发基本告别

    3. **部署复杂度**——需要配路由、负载均衡、监控，不是 pip install 就完事

    我上次用 vLLM 是因为要跑一个 RAG 服务，并发要求 50+。Ollama 直接扛不住，LM Studio 更别提。vLLM 在 Docker 里跑起来后，QPS 稳定在 40+，延迟 20ms 以内，问题解决。

    但部署那套东西花了我两天——从 docker-compose 到 prometheus 到 Grafana，全是体力活。

    Ollama：最省心的方案

    Ollama 的安装体验是我用过所有方案里最好的：

    # macOS

    curl -fsSL https://ollama.com/install.sh | sh

    ollama run llama3.2

    # 或者直接 API 调用

    curl http://localhost:11434/api/generate -d '{"model":"llama3.2","prompt":"你好"}'

    完事儿。没有 Docker，没有配置，没有 CUDA 驱动安装。

    **优点：**

  • 零配置，开箱即用
  • 支持量化模型（GGUF 格式），8GB 显存也能跑 Llama-3-8B
  • API 兼容 OpenAI 格式，直接替换端点就行
  • 有 Modelfile 可以自定义模型参数
  • Apple Silicon 原生支持（MPS）

    • **缺点：**

  • 并发性能有限。单请求没问题，多请求就降速
  • 模型库选得少，虽然够用但不够丰富
  • 没有生产级的监控、日志、扩展性

    • 我用 Ollama 做了两个项目：一个是内部知识问答工具（QPS<5），一个是给同事演示用。都很合适。但一旦并发上来，Ollama 就捉襟见肘了。

    LM Studio：开发者的调试神器

    LM Studio 本质是个带 UI 的 llama.cpp。它的目标用户不是生产环境，而是开发者和研究者。

    **优点：**

  • 图形界面，模型浏览、下载、配置一体化
  • 实时显示 token 生成速度、上下文长度、GPU 利用率
  • API 服务器内嵌，切换模型不需要改代码
  • 支持 GGUF 量化模型，对硬件要求低

    • **缺点：**

  • 本质还是单进程，并发能力弱
  • 没有生产部署能力
  • UI 偶尔卡死，体验一般

    • LM Studio 适合的场景：本地调试、模型选型对比、给非技术人员演示。我写代码的时候用它做本地 API 服务，调试完再迁移到 vLLM。

    llama.cpp：被低估的底层引擎

    llama.cpp 不是一个产品，是一个引擎。Ollama 和 LM Studio 底层都在用它。

    它的真正价值在于：

  • **极致轻量化**——CPU 推理也能跑，不需要 GPU

    • 2. **GGML/GGUF 格式**——量化模型行业标准，从 INT4 到 Q8，精度和速度都能选

    3. **嵌入式部署**——可以在树莓派、手机、WebAssembly 上跑

    // llama.cpp 最小推理示例

    llama_model_params mparams = llama_model_default_params();

    mparams.n_gpu_layers = 35; // 限制 GPU 层数，节省显存

    llama_model *model = llama_load_model_from_file("llama-3-8b.Q4_K_M.gguf", mparams);

    llama_context *ctx = llama_new_context_with_model(model, llama_context_params_default());

    // 推理...

    我用 llama.cpp 做过一个项目：在树莓派 4 上跑 Phi-3-mini（INT4 量化），虽然只有 4GB 内存，但响应还能接受。当然，这不是生产级别的，但在某些场景下，能跑比什么都强。

    选型决策树

    你的场景是什么？

    ├── 生产环境，高并发 → vLLM（有 GPU 服务器）/ Ollama（轻量生产）

    ├── 本地开发调试 → LM Studio / Ollama

    ├── Apple Silicon → Ollama / LM Studio（MPS 支持）

    ├── 没有 GPU → llama.cpp / Ollama（CPU 量化模型）

    └── 嵌入式/边缘设备 → llama.cpp

    一个实际踩过的坑

    去年我接了一个客户，要用 Ollama 跑 RAG 服务。他本地只有一台 Mac mini M1，要求支持 10 并发。

    我部署完后发现，Ollama 默认单进程处理请求，并发请求会排队。第 5 个请求开始，响应时间从 200ms 飙升到 5 秒。

    解决方案是上 vLLM，但客户没有 GPU 服务器。最后折中方案：用 Ollama + nginx 做简单的负载均衡，配合请求限流，把并发控制在 Ollama 能扛的范围以内。

    总结

    没有最好的方案，只有最适合场景的方案。

  • 生产高吞吐 → vLLM，做好部署准备
  • 快速启动、本地开发 → Ollama，别犹豫
  • 调试和演示 → LM Studio，UI 方便
  • 极致轻量、边缘部署 → llama.cpp，底层引擎

    • 选之前想清楚你的场景，否则很容易踩坑。我就是踩过之后才写这篇的。

    *有具体问题可以留言。下一篇打算聊聊 quantization 的选型——INT4 vs INT8 vs FP8，实测数据对比。*