Ollama/vLLM/llama.cpp实测

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、工具 1Ollama — 深受喜爱的初学者工具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.6GBCPU 使用率在正常条件下保持在 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、工具 2vLLM — 生产级主力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_urlhttp://localhost:8000/v1, api_keytoken-here) response client.chat.completions.create( modelmeta-llama/Llama-4-Scout-17B-Instruct, messages[{role: user, content: Explain PagedAttention in 2 sentences.}] )50 个并发用户时的性能数据每秒 920 个总 tokenp95 延迟 2.1 秒p99 延迟 2.8 秒。在 128 个并发连接下vLLM 保持了 100% 的请求成功率。在相同的负载下Ollama 的队列已经崩溃。缺点确实存在vLLM 需要具有 CUDA 计算能力 7.0 或更高的 NVIDIA GPUV100、T4、A10、A100、H100。不支持 Mac。不支持纯 CPU 部署。大多数模型也不支持开箱即用的 ROCm。设置更加复杂——需要 Python 3.12、CUDA 工具包、适当的环境配置。在单张 H100 80GB 上以 BF16 运行 Llama 3.1 8BvLLM 能提供大约每秒 12,500 个 token。这完全是另一个级别的性能。谁在信任 vLLMAmazon Rufus服务 2.5 亿客户、LinkedIn、Roblox每周 40 亿 token、Mistral AI 和 Stripe。当 Hugging Face 在 2025 年 12 月弃用 TGIText Generation Inference时他们官方推荐 vLLM 作为继任者。vLLM 结论在 NVIDIA 硬件上进行生产级多用户服务的唯一真正选择。5、工具 3llama.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_METALON -DGGML_NATIVEON 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 endpoint2026 年新功能llama.cpp 添加了 MCP 客户端支持通过 Model Context Protocol 直接在 llama-server 中调用工具、通过基于 RPC 的分布式推理实现多 GPU以及自动处理新模型结构化输出的自动解析器。2026 年 3 月版本还实现了跨 GPU 上下文的并行模型加载。其局限性与 Ollama 使用它的原因相同GGUF 量化牺牲了一些精度以换取可移植性。Q5_K_M5 位量化非常出色但它不是 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_M4 位通常用于对话是可以的但在精确数值推理和编码方面会明显退化。对于生产使用Q5_K_M 或 Q8_0 值得多占用一些 VRAM。在 vLLM 中运行全精度模型与在 llama.cpp 中运行量化模型不是一个公平的比较——你是在用精度换取可移植性。Ollama 不会消失。它的路线图包括改进并发处理团队也已经承认了生产环境的局限。对于 95% 的用例——单用户或低并发的个人工具——它仍然是从想法到运行模型的最快路径。10、结束语经过三周的测试这是我得到的结论你开始的工具不应该就是你上线的工具。Ollama 在开发者体验上无可争议地获胜。用它来构建、测试和迭代。当有超过五个人同时使用你的应用时切换到 vLLM。性能差距不是理论上的——在 50 个并发用户下这是 2 秒响应和 18 秒响应之间的差别。llama.cpp 是无名英雄Ollama 构建于其上的运行时60% 量化模型使用的格式让本地 AI 变得实用的项目。如果你使用的是 Apple Silicon 或需要在 CPU 上运行从这里开始而不是把它当作高级选项。我个人的设置在 MacBook 上使用带 Metal 的 llama.cpp 进行实验在云 GPU 上的 Docker 中运行 vLLM 用于有实际用户的场景。切换只花了一个下午。原文链接Ollama/vLLM/llama.cpp实测 - 汇智网