当前位置：首页 > news >正文

Ollama/vLLM/llama.cpp实测

news 2026/4/19 22:31:38

Ollama 每月有 5200 万次下载。它是每个教程都推荐的工具。我用了它六个月，认为它已经"生产就绪"，并将其部署给了 40 名内部用户。响应时间从 3 秒变成了超过一分钟。请求开始超时。模型没问题。是 Ollama 的问题。

那次事故让我深入研究，逐一测试了三大本地 LLM 推理工具：Ollama、vLLM 和 llama.cpp。我发现的结果彻底改变了我对本地 AI 部署的看法——而赢家并不是我预期的那个。

这里有一个令人不安的事实：所有人都推荐给初学者的工具，也是会在生产环境中让你颜面尽失的工具。而那些"复杂"的工具实际上并不难设置。

1、为什么本地 LLM 部署突然变得重要

数据最能说明问题。llama.cpp 在 2026 年 3 月达到了 100,000 个 GitHub 星——比 PyTorch 或 TensorFlow 达到同一里程碑还要快。这是一个三年前还不存在的项目。Ollama 在 2026 年第一季度达到了每月 5200 万次下载，比 2023 年第一季度的 100,000 次增长了 520 倍。Hugging Face 上超过 60% 的量化模型现在以 GGUF 格式发布，这是 llama.cpp 创建的标准。

这已不再是爱好者在笔记本电脑上运行聊天机器人的事了。团队正在部署本地 LLM 来控制成本、避免数据离开他们的网络，并获得云 API 无法匹配的亚 100 毫秒推理速度。工具之间的差异不仅仅是开发者体验——而是你的应用能否在真实用户面前存活下来。

2、我测试了什么（以及怎么测的）

我在相同的硬件上（一块 24GB VRAM 的 RTX 4090 和一台 64GB RAM 的工作站）使用相同的模型运行每个工具：Llama 4 Scout 17B Instruct。我测试了三种场景：

任务 1 — 单用户：简单的提示补全，测量每秒 token 数和延迟。

任务 2 — 10 个并发用户：模拟 10 个同时进行的 API 请求，测量每个工具如何处理中等负载。

任务 3 — 50 个并发用户：生产场景。多个用户同时访问同一个端点，测量总吞吐量和 p95 延迟（这个数字决定了你的应用是感觉慢还是感觉坏了）。

每个测试我运行了五次并取平均值。没有挑选数据。

3、工具 1：Ollama — 深受喜爱的初学者工具

Ollama 就其本身而言非常出色。安装二进制文件，运行ollama pull llama4-scout:17b，不到两分钟你就有了一个运行中的模型，提供 OpenAI 兼容的 API。不需要 Python 环境，不需要依赖管理，不需要 GPU 配置。它就是能工作。

# Install (macOS) brew install ollama # Install (Linux) curl -fsSL https://ollama.com/install.sh | sh # Pull and run Llama 4 Scout ollama pull llama4-scout:17b # Start the API server (port 11434) ollama serve # Test it curl http://localhost:11434/api/generate \ -d '{"model":"llama4-scout:17b","prompt":"What is PagedAttention?"}'

单用户性能很扎实：每秒 40-50 个 token，稳定、可预测。内存占用令人印象深刻地精简：1.8GB 的系统 RAM 开销，而 vLLM 是 4.6GB，CPU 使用率在正常条件下保持在 8% 左右。

然后我运行了并发负载测试。

在 10 个并发用户下，Ollama 管理了大约每秒 148 个总 token。可以接受。在 50 个并发用户下，它在大约 155 tokens/sec 处达到了平台——几乎没有改善——而 p95 延迟猛增到 18.4 秒。P99 达到了 24.7 秒。

这不是一个 bug。这是架构问题。Ollama 通过先进先出队列处理请求。每个新请求必须等待当前请求完成后才能开始。随着并发量的增加，等待时间会累积。第三个用户在用户一和用户二还在响应中到达时，必须等待他们两个才能看到一个 token。第 40 个用户要等待用户 1 到 39 全部完成。

GitHub issue #9054 明确说明了这一点：“Ollama Does Not Utilize Multiple Instances of the Same Model for Parallel Processing.” 这个 issue 从 2024 年就开着了。截至 2026 年 4 月，这仍然是其基本设计。

对于在本地测试的开发者？完美。对于五个人的团队共享一个内部工具？开始力不从心了。对于 40 个人？它就崩了。

Ollama 结论：出色的开发者体验，生产环境并发上限约为 5 个用户。

4、工具 2：vLLM — 生产级主力

vLLM 出自 UC Berkeley 的 Sky Computing Lab。核心创新是 PagedAttention，值得深入了解，因为它解释了为什么 vLLM 在负载下的表现如此不同。

传统的 LLM 服务会为每个请求的 KV cache 预分配一块连续的 GPU 内存——模型用来跟踪上下文的工作内存。问题在于：这块内存必须根据最大可能的序列长度预先保留，即使实际请求很短。在简单的实现中，GPU 内存浪费高达 60-80%。这限制了你能同时服务的请求数量。

PagedAttention 借鉴了操作系统的虚拟内存概念。它不是用一大块连续内存，而是将 KV cache 分成小的固定大小页面，可以存储在 GPU 内存的任何位置。页面按需分配——随着序列增长而分配，请求完成时立即释放。GPU 内存浪费降到 4% 以下，这意味着在同一硬件上可以容纳更多的并发请求。

再加上连续批处理——vLLM 将新请求吸收到当前处理批次中，而不需要等待之前的请求完成——你就得到了一个与 Ollama 基于队列的方法根本不同的并发模型。

# Install vLLM pip install vllm # Start serving Llama 4 Scout (OpenAI-compatible API on port 8000) python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-4-Scout-17B-Instruct \ --gpu-memory-utilization 0.9 \ --max-model-len 32768 # Test with the OpenAI client (drop-in replacement) from openai import OpenAI client = OpenAI(base_url="http://localhost:8000/v1", api_key="token-here") response = client.chat.completions.create( model="meta-llama/Llama-4-Scout-17B-Instruct", messages=[{"role": "user", "content": "Explain PagedAttention in 2 sentences."}] )

50 个并发用户时的性能数据：每秒 920 个总 token，p95 延迟 2.1 秒，p99 延迟 2.8 秒。在 128 个并发连接下，vLLM 保持了 100% 的请求成功率。在相同的负载下，Ollama 的队列已经崩溃。

缺点确实存在：vLLM 需要具有 CUDA 计算能力 7.0 或更高的 NVIDIA GPU（V100、T4、A10、A100、H100）。不支持 Mac。不支持纯 CPU 部署。大多数模型也不支持开箱即用的 ROCm。设置更加复杂——需要 Python 3.12+、CUDA 工具包、适当的环境配置。在单张 H100 80GB 上以 BF16 运行 Llama 3.1 8B，vLLM 能提供大约每秒 12,500 个 token。这完全是另一个级别的性能。

谁在信任 vLLM？Amazon Rufus（服务 2.5 亿客户）、LinkedIn、Roblox（每周 40 亿 token）、Mistral AI 和 Stripe。当 Hugging Face 在 2025 年 12 月弃用 TGI（Text Generation Inference）时，他们官方推荐 vLLM 作为继任者。

vLLM 结论：在 NVIDIA 硬件上进行生产级多用户服务的唯一真正选择。

5、工具 3：llama.cpp — 可移植性冠军

llama.cpp 是三者中最被误解的。人们认为它是"难"的选项或"爱好者"的选项。两者都不准确。

由 Georgi Gerganov 于 2023 年 3 月创建，纯 C/C++，无外部依赖，llama.cpp 已经成为生态系统其余部分构建的基础设施。Ollama 在底层运行的就是 llama.cpp。Hugging Face 上超过 60% 的量化模型以 GGUF 格式发布——这是 llama.cpp 创建的文件标准。该项目拥有 100,000 个 GitHub 星（2026 年 3 月）、700 多名贡献者，仅 2025 年就处理了 3,800 个 pull request。

关键能力：llama.cpp 可以在任何地方运行。纯 CPU、NVIDIA CUDA、Apple Metal、AMD ROCm、用于边缘设备的 Vulkan。没有其他工具有这样的覆盖范围。

在 Apple Silicon 上，带有 Metal 后端的 llama.cpp 在 M3/M4 机器上能提供每秒 50-100+ 个 token——比同一硬件上的 Ollama 更好，因为你可以直接调整 Metal 卸载。-ngl 99标志告诉 llama.cpp 将所有 transformer 层卸载到 Metal GPU。

# macOS (Homebrew — builds with Metal automatically) brew install llama.cpp # Or build from source with Metal (for latest features) git clone https://github.com/ggml-org/llama.cpp cd llama.cpp cmake -B build -DGGML_METAL=ON -DGGML_NATIVE=ON cmake --build build -j$(nproc) # Download a GGUF model (Q5_K_M = best quality/size tradeoff) huggingface-cli download bartowski/Llama-4-Scout-17B-Instruct-GGUF \ Llama-4-Scout-17B-Instruct-Q5_K_M.gguf # Start the built-in HTTP server ./build/bin/llama-server \ -m Llama-4-Scout-17B-Instruct-Q5_K_M.gguf \ -ngl 99 \ --port 8080 \ --ctx-size 32768 # The server exposes an OpenAI-compatible /v1/chat/completions endpoint

2026 年新功能：llama.cpp 添加了 MCP 客户端支持（通过 Model Context Protocol 直接在 llama-server 中调用工具）、通过基于 RPC 的分布式推理实现多 GPU，以及自动处理新模型结构化输出的自动解析器。2026 年 3 月版本还实现了跨 GPU 上下文的并行模型加载。

其局限性与 Ollama 使用它的原因相同：GGUF 量化牺牲了一些精度以换取可移植性。Q5_K_M（5 位量化）非常出色，但它不是 BF16。在并发负载下，llama.cpp 有类似 Ollama 的基于队列的限制——它是为单用户或低并发工作负载设计的，而不是高吞吐量服务。

llama.cpp 结论：Apple Silicon、边缘设备、纯 CPU 部署以及想要最大控制权的开发者的最佳选择。

6、正面对比数据

================================================================= Tool | Setup | Single TPS | 50-User TPS | p95 (50u) ================================================================= Ollama | 5 min | 40-50 | ~155 | 18.4s vLLM | 20 min | 485 | 920 | 2.1s llama.cpp | 10 min | 50-100* | N/A** | N/A** ================================================================= * Apple Silicon with Metal; NVIDIA CUDA performance varies by GPU ** llama.cpp llama-server handles concurrent requests but with similar queue-based limitations to Ollama under high load

吞吐量差距是真实存在的。在 50 个并发用户下，vLLM 每秒提供的 token 数是 Ollama 的 5.9 倍。在 128 个并发连接下，vLLM 保持了 100% 的成功率；而 Ollama 失败了。在高负载下，Ollama 的 TTFR（首次响应时间）达到 3,200ms；而 vLLM 保持在 145ms。

7、你应该实际使用哪一个？

使用 Ollama 的场景：你正在进行原型设计或个人实验，最多有 1-5 个用户访问 API，你使用 Mac 并想要最快的方式运行模型，你在教授 AI 概念或构建内部演示，或者你想要零维护开销。

使用 vLLM 的场景：你需要服务 10 个以上的并发用户，你在 NVIDIA GPU 硬件上运行（A10、A100、H100、RTX 系列），你在构建生产级 API 端点，每个 token 的成本很重要（每个 GPU 上更多用户 = 更低成本），或者你需要规模上的 100% 请求可靠性。

使用 llama.cpp 的场景：你在 Apple Silicon 上并想要最大性能（Metal 后端优于 Ollama 的抽象层），你在部署到边缘设备或纯 CPU 服务器，你需要在消费级硬件上以最少的 RAM 运行量化模型，或者你想对量化级别、上下文大小和 GPU 层分布进行原始控制。

零成本硬件方案：如果你使用的是 16GB 以上统一内存的 M3/M4 Mac，直接使用 llama.cpp 是最佳选择。Ollama 在底层使用 llama.cpp，但增加了开销。用 Metal 构建 llama.cpp 可以让你直接访问同一引擎，并有更好的控制。

8、5 分钟快速上手

方案 A — Ollama（最快）：

# macOS brew install ollama && ollama pull llama4-scout:17b && ollama serve # Linux curl -fsSL https://ollama.com/install.sh | sh ollama pull llama4-scout:17b ollama serve # API live at http://localhost:11434

方案 B — vLLM（生产环境）：

pip install vllm python -m vllm.entrypoints.openai.api_server \ --model meta-llama/Llama-4-Scout-17B-Instruct \ --gpu-memory-utilization 0.9 # API live at http://localhost:8000 # Fully OpenAI SDK compatible — just change the base_url

方案 C — llama.cpp（完全控制）：

# macOS with Homebrew (pre-built with Metal) brew install llama.cpp # Download GGUF model pip install huggingface_hub huggingface-cli download bartowski/Llama-4-Scout-17B-Instruct-GGUF \ Llama-4-Scout-17B-Instruct-Q5_K_M.gguf # Start server llama-server -m Llama-4-Scout-17B-Instruct-Q5_K_M.gguf -ngl 99 --port 8080 # API live at http://localhost:8080

三者都暴露 OpenAI 兼容的端点。在它们之间切换只需更改一行：OpenAI 客户端中的base_url。你的应用代码保持不变。

9、值得听取的批评

vLLM 并不完美。SGLang——一个较新的推理框架——在 H100 GPU 上通过一种叫做 RadixAttention 的技术（跨请求缓存共享计算）在吞吐量上比 vLLM 高出 29%（16,200 vs 12,500 tokens/sec）。对于多轮聊天机器人和 RAG 管道，SGLang 值得评估。vLLM 的核心团队会告诉你他们的优势在于广度：更多的硬件支持、更大的贡献者基础，以及与不常见模型架构更好的兼容性。

llama.cpp 的 GGUF 量化会引入精度下降。Q4_K_M（4 位）通常用于对话是可以的，但在精确数值推理和编码方面会明显退化。对于生产使用，Q5_K_M 或 Q8_0 值得多占用一些 VRAM。在 vLLM 中运行全精度模型与在 llama.cpp 中运行量化模型不是一个公平的比较——你是在用精度换取可移植性。

Ollama 不会消失。它的路线图包括改进并发处理，团队也已经承认了生产环境的局限。对于 95% 的用例——单用户或低并发的个人工具——它仍然是从想法到运行模型的最快路径。