题记与说明
- 类型：主题研究（多来源精读 + 交叉综合）
- 日期：2026-10-29
- 检索方式：WebSearch 圈定候选 → webReader 全文精读 5 个来源 → 关键论断交叉验证
- 来源清单（精读）：
- llama.cpp vs Ollama vs vLLM: One User vs Many (2026) — insiderllm.com（2026-02 发布，含 2026 年中版本信息，最贴合本主题）
- Ollama vs. vLLM: A deep dive into performance benchmarking — Red Hat Developer（2025-08，唯一有严谨实测数据的来源）
- Ollama vs llama.cpp vs vLLM vs SGLang: Choosing the Right LLM Inference Engine in 2026 — NemesisNet Lab（2026-01，四引擎选型 + Windows/Linux 决策矩阵）
- Unable to use GPU at all on windows · ollama/ollama#9166（2025-02，Windows 特有 GPU 故障一手案例）
- vLLM vs Ollama: Key differences, performance, and how to run them — Northflank（部署/运维视角，技术密度较低，作辅助）
- 检索到但未全文精读、仅采信其可交叉验证的摘要信息：
- vLLM 原生 Windows 安装失败的一手 issue：microsoft/fara#21（2025-11，原文结论「vLLM is only supported via WSL on Windows」）、WSL2 已知 bug #5102、#4140
- llama.cpp Windows 侧性能波动：#18258（RTX 3090 + CUDA 13.1，b7406 后 40 t/s → 20 t/s 回归，2025-12）、#14201（llama-server 比 llama-cli 慢 40%，2025-06）
- Vulkan 后端近况：NVIDIA 论坛实测帖（2026-03）称新版 Vulkan 在部分硬件上可反超 CUDA；早年 #5486（2024-02）FP16 Vulkan 惨败于 CPU 的问题已属历史
- Ollama 封装开销的社区实测：ollama#4437（同负载 Ollama 比 llama.cpp 慢 1.5–2 倍）
一、核心问题（这份主题在解决什么）
在 Windows 本机（个人桌面 / 笔记本，通常单张消费级 GPU 或纯 CPU）上跑开源大模型，三个主流推理栈该怎么选：
- 可行性：谁能在 Windows 上原生安装、开箱即用？谁必须绕道 WSL2/Docker？
- 性能：单用户生成速度（tok/s）、提示词处理速度、多并发吞吐差距有多大？
- 代价：易用性、显存管理、模型管理、API 兼容性各自的 trade-off 是什么？
背景性事实（贯穿所有来源的共识）：Ollama 本质是 llama.cpp 的封装（体验层），llama.cpp 是引擎，vLLM 是面向高并发生产环境的另一个引擎。所以这是「2 个引擎 + 1 个壳」的对比，而不是三个并列同类物。
二、主要主张（各来源的核心论点）
insiderllm（2026，最直接的对比文）
"Single-user, the three are closer than benchmark posts admit. Concurrent, vLLM pulls 10-20x ahead."
- 单用户场景下三者差距比网上流传的基准帖小得多（一个壳的开销约 5–15%，偶尔 30%）；并发上来后 vLLM 领先 10–20 倍。
- PagedAttention 是差距的技术根源：vLLM 把 KV cache 切成固定大小的 block，显存浪费从 60–80% 降到 <4%，同样显存能塞下多得多的并发上下文；配合 continuous batching，请求随到随插，不用等整批完成。
- vLLM 最大的新手陷阱：
gpu_memory_utilization默认 0.90，启动即预分配约 90% 显存，不管当前请求量。桌面上想同时开游戏或浏览器用显存，会被直接 OOM。
Red Hat 官方基准（2025-08，唯一的硬数据）
"vLLM outperforms Ollama in high-performance production deployments, delivering significantly higher throughput and lower latency."
- 在 256 并发下 vLLM 吞吐是 Ollama 的 19 倍；但这是 Linux（OpenShift）上跑的，且 Ollama 官方 FAQ 自己定位「for local machine, not for high throughput」——Red Hat 测的是 vLLM 的主场、Ollama 的客场。
NemesisNet（2026-01，四引擎选型）
- 给出明确的 Windows vs Linux 决策矩阵：Windows 行只有 Ollama（最易用）/ llama.cpp（可控）/ LM Studio（GUI）三个可选项，vLLM 一格的结论是 "use Ollama/llama.cpp instead"，原文直接断言 "you cannot install vLLM on Windows"（指原生安装）。
ollama#9166（Windows 一手故障案例）
- RTX 4060 笔记本（MSI Pulse 17）上，模型权重被加载进 NVIDIA 显存，但实际推理跑在 CPU 上；
CUDA_VISIBLE_DEVICES等环境变量不生效。证明 Ollama 在 Windows 上「检测到 GPU ≠ 用上 GPU」，部署后必须实测验证。
Northflank（辅助）
- 从部署侧确认分工：vLLM 的价值在 Kubernetes/云端多租户高并发（Northflank 自己只在 Linux 上跑 vLLM）；Ollama 的价值是本地开发、原型、单机。
三、方法（各来源怎么论证的）
| 来源 | 方法 | 可信度评估 |
|---|---|---|
| insiderllm | 综合多个基准 + 架构原理解释（PagedAttention/continuous batching）+ 单用户 RTX 4090 实测引用 | 结论与架构解释自洽；具体 tok/s 数字为转述，未给完整测试环境，属于中等可信 |
| Red Hat | 最严谨：GuideLLM 0.2.1 压测，A100-PCIE-40GB 单卡，Llama-3.1-8B（vLLM 用原始权重、Ollama 用 fp16 GGUF），vLLM 0.9.1 vs Ollama 0.9.2，并发 1→256，每档 300 秒，固定数据集，测吞吐/TTFT/TPOT | 官方厂商出品、方法透明（控制变量、报中位数/均值/P99），可信度最高；但硬件是数据中心卡、系统是 Linux，对「Windows 本地部署」外推有限 |
| NemesisNet | 定性对比表 + 选型决策矩阵 | 定性归纳，无新数据，适合当索引用 |
| ollama#9166 | 单用户环境报告（硬件/版本/复现步骤/日志） | 一手但样本为 1，且已关闭，可能是特定驱动环境问题 |
| Northflank | 定性 + 产品营销 | 只取其部署事实，不取性能结论 |
方法论上的关键提醒（读这批材料最大的收获之一）：几乎所有「谁更快」的结论都依赖测试条件——并发数、量化方案（Ollama 常默认 Q4，vLLM 常用 FP16/原始权重）、批大小、是否首 token。Red Hat 那篇 19 倍的数字只在「256 并发 + Linux + A100」下成立，直接搬到「Windows 单人本地用」场景就是误用。
四、数据与证据
1. 并发-吞吐核心数据（insiderllm 汇总）
同一 Llama 3.1 8B 级模型，并发上升时 vLLM 对 Ollama/llama.cpp 的吞吐倍数：
| 并发 | 倍数 | 说明 |
|---|---|---|
| 1 用户 | ~1.1× | 三者几乎打平 |
| 8 用户 | ~2.3×（82 vs 187 tok/s） | vLLM 开始甩开 |
| 50 用户 | ~5.9×（155 vs 920 tok/s） | llama.cpp 系吞吐饱和 |
| 100+ 用户 | 15–20× | llama.cpp 系彻底失守 |
单用户 RTX 4090 / Llama 3.1 8B 参考值：Ollama Q4_K_M ≈ 62 tok/s；llama.cpp 直连 ≈ 65 tok/s；vLLM FP16 ≈ 71 tok/s。
2. Red Hat 官方压测（Llama-3.1-8B @ A100-40GB，Linux）
- 256 并发总吞吐：vLLM 793,185 tok/s vs Ollama 41,198 tok/s（约 19 倍）
- 256 并发平均 TTFT：vLLM 2.06 秒 vs Ollama 25.59 秒
- P99 TTFT：1 并发时 vLLM 好约 2 倍；128 并发时好约 32 倍
- 资源利用率：Ollama GPU/显存利用率 ~100%（满载但低效），vLLM 85–95%（预留空间换调度弹性）
3. Windows 可行性事实链（三重印证）
- NemesisNet 决策矩阵：Windows 原生可用的只有 Ollama、llama.cpp（+LM Studio），vLLM 标注不可装；
- vLLM 官方立场：Linux 优先，Windows 走 WSL2；原生
pip install vllm失败（microsoft/fara#21，2025-11："vLLM is only supported via WSL on Windows"）；2025-12 Docker 官方推广「WSL2 + NVIDIA GPU 一条命令跑 vLLM」，等于官方承认 WSL2 是 Windows 唯一路径； - WSL2 路径并非无坑：API server 挂起（#5102）、多卡张量并行启动失败（#4140）等 issue 长期存在。
4. Windows 特有性能/稳定性风险（一手 issue）
- Ollama Windows：#9166（加载进显存但 CPU 推理）；#12264（装了 CUDA SDK 但 GPU 缺失/禁用时 ollama serve 崩溃）；#12428（0.12 后模型加载变慢）
- llama.cpp Windows：#18258（RTX 3090 + CUDA 13.1，某版本后生成速度 40→20 t/s 的回归）；#14201（llama-server 比 llama-cli 慢 40%——Windows 上部署要实测 server 模式而不是想当然）
- Ollama 封装税：#4437 同负载比 llama.cpp-python 慢 1.5–2×；insiderllm 给出更温和的 5–15%（常至 30%）区间
5. 版本坐标（insiderllm，2026 年中）
llama.cpp b9840+（预编译支持 CUDA/Vulkan/SYCL）、Ollama 0.31.2、vLLM 0.24.0。llama.cpp 的 Vulkan 后端在 2026 年已能覆盖无 CUDA 工具链的 Windows 机器（AMD/Intel 卡的主路径）。
五、结论（综合判断）
一句话：Windows 本地部署的可行域里只有 llama.cpp 和 Ollama 两个真选项；vLLM 的能力边界（高并发生产服务）恰恰是 Windows 个人机器用不上的场景，硬要上只能 WSL2/Docker，得不偿失。
按场景的最终选型（多来源一致的收敛结论）：
| 场景 | 选择 | 理由 |
|---|---|---|
| Windows 个人机，想最快跑起来、做产品原型 | Ollama | 原生安装器、模型管理、OpenAI 兼容 API 开箱即用；代价 5–15%（可至 30%/2×）性能税 + Windows 上偶发 GPU 识别问题（部署后必须 ollama ps + 实测验证） |
| Windows 个人机，追求单用户极限速度/老显卡/AMD-Intel 卡 | llama.cpp | 原生预编译（CUDA/Vulkan），参数全可控，llama-bench 自带基准；代价是要自己管模型文件、编译/选型、启停 |
| Windows + 真的需要高并发服务 | WSL2/Docker + vLLM（或换 Linux） | 唯一路径；注意 90% 显存预分配与 WSL2 已知 bug；更现实的替代是「同机双系统/另一台 Linux 盒子」 |
| 多用户生产服务（任何平台） | vLLM | 并发 8 起甩开，50 并发近 6 倍，100+ 并发 15–20 倍；这是 PagedAttention + continuous batching 的架构优势，不是调参能追平的 |
易被忽略的两个结论：
- 三者差距在单用户时被严重夸大，在多用户时被严重低估——选型错误的方向几乎总是「用 Ollama 扛了本该 vLLM 扛的并发」或「为了 5% 速度忍受 llama.cpp 的手工运维」。
- Windows 本身的工程成熟度是隐藏变量：Ollama 和 llama.cpp 都有「Linux 上没见过的 Windows 特有故障」（GPU 检测假阳性、版本回归），Windows 部署后必须实测，不能信任默认行为。
六、局限
来源层面的局限：
- 没有任何来源做过 Windows 原生环境下的三方同机对照基准。唯一严谨的定量数据（Red Hat）是 Linux + 数据中心 GPU + 两引擎（不含 llama.cpp 直连）的测试，所有 Windows 上的性能结论都是从 Linux 数据 + 单点 issue 外推的。
- insiderllm 的具体 tok/s 数字未给完整测试脚本与环境，属于「方向可信、数值需复核」级别。
- #9166 等一手 issue 样本量 1，且部分已关闭，不代表当前版本状态（测试时版本为 0.5.11，与 2026 年的 0.31.2 差了很多个版本）。
- Vulkan 后端「可反超 CUDA」的说法目前只来自论坛实测帖，未见系统基准。
- 未找到 2026 年针对 Windows 的 vLLM/llama.cpp/Ollama 统一横评（如 llama-benchy 这类工具的 Windows 实测数据）。
判断层面的局限：
- 「WSL2 有 10–20% 性能损耗」这类常见说法在本次来源中未获定量证实，我没有采信具体数字。
- 本机硬件差异（显存大小、是否 RoPE 长上下文、笔记本 iGPU 混合架构）对结论影响很大，本主题结论适用于「典型单卡 8–24GB 显存」档位。
- 未实测：本笔记所有数据均来自网络来源，我自己没有在这台 Windows 机器上运行过任何基准。
七、对我的启发
- 「2 引擎 + 1 壳」的心智模型：看到任何「Ollama vs vLLM」对比先问测的是什么——壳的开销（5–15%）和引擎的架构差距（10–20×）是完全不同的两回事，网上多数争论是拿这两个量级混着吵。
- 选型问题先问并发，再问平台：单用户 → llama.cpp/Ollama 随意（体验优先）；并发 >8 → 必须能跑 vLLM 的环境。这个分界线（约 2.3×@8 并发）比任何笼统的「vLLM 更快」都有用。
- vLLM 的 90% 显存预分配是桌面环境的硬伤：如果未来想在带显卡的 Windows 工作机上跑服务类推理，这是比安装更先卡住的问题——它决定了 vLLM 和「日常使用的桌面」天然互斥。
- Windows 部署必须「部署后验证」：Ollama 假装用 GPU（#9166）、llama.cpp 版本回归腰斩速度（#18258）说明 Windows 是二等公民，任何部署要立刻用 llama-bench / ollama ps / 任务管理器实测验证，而不是信任日志里的 "GPU"。
- 对写作/报告的启发：Red Hat 那篇是「如何报告基准」的好范本——写清硬件、版本、量化方案、并发梯度、每档时长、报告 P99 而不只是均值；反例则是大量不写测试条件的「X 比 Y 快 N 倍」流量文。以后引用任何性能数字前，先检查它有没有交代这些变量。
- 可复用的决策树（insiderllm 版，简化）：单机单人 → Ollama 起步，速度不满意换 llama.cpp；要多用户 API → Linux/WSL2 + vLLM；要 GUI → LM Studio；要分布式集群 → 不在 Windows 上想。
附：来源原文重要引述备查
- insiderllm："Single-user, the three are closer than benchmark posts admit. Concurrent, vLLM pulls 10-20x ahead."；"vLLM's
gpu_memory_utilizationdefaults to 0.90 — it pre-allocates ~90% of VRAM at startup"；Platform 表 Windows 行：vLLM = "WSL2 only — no native Windows build" - NemesisNet：Windows/Linux 决策矩阵中 vLLM 在 Windows 行的建议为 "use Ollama/llama.cpp instead"；正文断言 "you cannot install vLLM on Windows"
- microsoft/fara#21（2025-11）："vLLM is only supported via WSL on Windows."
- Red Hat：256 并发下 vLLM 793,185 tok/s vs Ollama 41,198 tok/s；平均 TTFT 2.06s vs 25.59s；测试框架 GuideLLM，每档并发 300 秒
- ollama#9166（2025-02）："the models seem being loaded in Nvidia memory, BUT inference [runs on CPU]"（RTX 4060 笔记本，Ollama 0.5.11）