最近做技术方案咨询时被问得最多的一个问题就是vLLM 和 Ollama 到底怎么选问的人背景差别很大有刚接触大模型、想在自己电脑上把模型跑起来试试的初学者也有做产品要上线、需要给几十上百个用户提供稳定推理服务的开发者。这两个名字经常同时出现中文社区里也都有大量教程乍一看好像都能“把模型跑起来”但细看会发现它们解决的根本不是同一个问题。这篇我用实际使用中积累的经验把两者的定位、原理、性能差距和选型逻辑一次讲透顺便把在这两个框架上踩过的坑也列出来方便你直接照着做决策。1. 先把定位搞清楚一个解决“跑起来”一个解决“扛得住”1.1 Ollama把大模型变成“一键可用”的本地工具Ollama 的目标非常明确——让一个没有深度机器学习背景的人也能在两三分钟内把开源大模型跑起来。装完就是一行命令ollama run qwen2.5:7b模型自动下载、量化格式自动匹配、API 自动暴露。它底层基于 llama.cpp 生态主打 GGUF 这种量化友好的模型格式对 CPU、内存和消费级显卡的适配做得非常到位。我在 Mac、普通 Windows 笔记本、甚至一些低配显卡机器上都跑过基本就是“下载即用”的体验。这个定位决定了很多设计细节模型库集中管理、默认 5 分钟的 keep-alive 策略、通过环境变量控制并行度、支持 Modelfile 自定义推理参数。你不需要理解 KV Cache 是什么不需要关心 CUDA 版本配对不需要研究吞吐量怎么调优。它更像一个“模型管理工具 简易推理服务”的结合体适合个人开发验证、本地离线使用、教学演示。用一个容易理解的比喻Ollama 就是家用咖啡机按键出咖啡咖啡豆和研磨参数都封装好了你不用也不该去拆开它。1.2 vLLM为了高吞吐和稳定服务而生的推理引擎vLLM 的定位完全站在另一个方向。它不是一个“一行命令跑模型”的工具而是一个高性能推理服务引擎核心目标是在有限的 GPU 资源下用尽可能高的吞吐量处理尽可能多的并发请求。它直接对接 Hugging Face 生态的模型权重支持主流开源架构内置了 PagedAttention、连续批处理、前缀缓存、投机采样、张量并行等一系列面向生产环境的优化手段。在 vLLM 上启动模型服务虽然也只是一条 Python 命令但背后的行为完全不同启动时会预分配显存、构建 CUDA graph、初始化调度器你可以用一堆参数精细控制显存利用率、最大序列长度、并发序列上限、量化方式、并行卡数。它也许不是最适合快速体验的工具但一旦你需要在多用户、高 QPS、长对话、多卡分布式这类真实生产场景里提供 APIvLLM 几乎是绕不开的选择。继续用咖啡机的比喻vLLM 更像是商用咖啡机上手有门槛需要理解水压、研磨度、维护周期但出品稳定、出杯量大。很多人问“vLLM 是不是比 Ollama 更快”这个问法本身就容易误导因为两者的设计目标根本不在一个维度上。1.3 核心区别不是性能高低而是“解决问题层次”不同更准确的理解是Ollama 在“把模型快速可靠地跑起来”这个层次上做得极其出色vLLM 在“把模型作为生产级服务稳定地、高并发地跑起来”这个层次上是长期投入优化的主流选择。由于默认行为差异太大直接比较一个数字意义不大。我把两者的主要差异列成一张表后面再针对关键技术点逐个展开。对比项OllamavLLM安装难度极低脚本或客户端即可中等需要 Python/CUDA 环境模型格式GGUF 为主Hugging Face 权重为主启动时间快按需加载相对慢启动时预分配显存并发能力低到中可通过环境变量调节高连续批处理调度显存管理按需加载多模型切换PagedAttention 显存分块分布式不支持张量并行/流水并行适用偏向本地个人使用、原型验证产品服务、高并发在线推理上手难度很低需要理解调度参数这张表只是宏观印象下面来看原理层面为什么会有这些差异。2. 从原理看差距为什么一个像“家用工具”一个像“调度系统”2.1 底层引擎的不同llama.cpp 生态 vs 独立推理引擎Ollama 选择拥抱 llama.cpp 生态这是它易用性占巨大优势的根本原因。llama.cpp 用 C/C 实现核心思路是“尽量在普通硬件上把大模型跑起来”通过 GGUF 格式和多种量化方案q4_K_M、q5_K_M、q8_0 等大幅降低模型体积和显存需求。这种设计对个人用户是福音。在 Ollama 里运行一个 7B 模型默认选好量化等级内存和显存压力远小于跑原版权重。vLLM 则是一个从零构建的独立推理引擎更多考量的不是“最弱的硬件能不能跑”而是“GPU 是不是每一刻都被高效利用”。它默认使用 Hugging Face 格式的权重因为这样可以和训练、微调工具链无缝衔接。虽然也能通过 AWQ、GPTQ、FP8 等量化方式获得显存优化但这些方案通常需要额外的校准和转换成本不像 GGUF 那样“下载即量化好”。这也是为什么同一个模型你在 Ollama 和 vLLM 里跑的体验会明显不同——它们背后的技术路线就不同。2.2 PagedAttention显存管理的分页思路大模型推理时会为每一条请求维护一份 KV Cache用来缓存已经算过的那部分注意力键值历史 token 越长KV Cache 占用越大而且这个内存是动态变化的。传统推理框架一般有两种做法要么给每条请求预分配最大长度的显存浪费严重显存可能只有三到四成被真正利用要么请求结束前死死占住不释放并发一高就 OOM。vLLM 引入的 PagedAttention借鉴了操作系统虚拟内存分页的思路把 KV Cache 切成固定大小的物理块通过块表把逻辑上连续的序列映射到物理上不连续的显存块按需分配、按需释放。这带来的直接收益是显存利用率大幅提升同等显存下可以容纳更多并发序列。你可以把它理解成图书馆不再为每本书预留一整排书架而是按页分配书架格子书页之间虽然不连续但有索引卡片把它们串起来反而让书架的每一格都可能被用到。Ollama 底层沿用 llama.cpp 的显存管理方式模型切换策略和 KV 处理相对保守更多依赖“量化模型体积小 keep_alive 管理”来缓解压力。在单机单卡的个人场景下这不构成问题但并发请求一多显存碎片和预分配浪费就会让可承载的并发量明显下降。2.3 连续批处理 vs 静态排队吞吐量的分水岭再说批处理。很多新手没意识到GPU 推理要想把吞吐打上去靠的是“同一时刻算多个请求”而不是“一个请求算完再算下一个”。早期框架的做法是静态批处理凑满 N 个请求组成一个 batch算完一批再算下一批如果中途有的请求短、有的请求长短请求算完也只能等长请求一起结束GPU 白白空转。vLLM 的连续批处理把调度粒度从“请求”降到“迭代步”。每一步前向传播调度器都会重新决定这个 step 里要算哪些序列新请求来了有空位就插进去某个序列生成了结束符下一个迭代就把它移除输入阶段和生成阶段的序列也可以在同一步混编。这样 GPU 每一轮都在算“当前最该算的内容”空闲很少。这也是 vLLM 在高并发下总吞吐特别稳的核心原因。Ollama 也支持一定的批量推理llama.cpp 本身有 batch 机制Ollama 也提供了并行度相关环境变量。但从调度粒度和动态性来讲它的设计目标毕竟不是“把每一毫秒 GPU 时间榨干”。在 Ollama 里开 10 个并发请求会发现请求要么排队、要么整体变慢同样的压力放到 vLLM 上每个请求的延迟可能有波动但整体吞吐通常要稳得多。这里也要诚实地说标题里提到的“千级并发”不是指单张显卡上的一个 vLLM 进程就能做到而是指 vLLM 作为推理服务引擎可以通过多实例、多卡并行、前缀缓存等手段为千级并发提供一个可扩展的底座。Ollama 的定位里基本没有这条路线。2.4 前缀缓存、投机采样和分布式生产场景的加分项如果只是并发高vLLM 还有几项能力让它在生产场景里更实用。第一是前缀缓存多轮对话和带固定 system prompt 的请求会共享一段前缀vLLM 可以复用这些前缀的 KV Cache省掉大量重复计算。第二是投机采样用一个更小的草稿模型先预测多个 token再让目标模型一次性验证生成速度有明显提升。第三是张量并行和流水并行多张卡时能把一个模型切到多卡上或者把不同层的计算分到不同卡上为超大模型打开了空间。这些特性在 Ollama 的个人使用场景里几乎用不上也不是它应该补的方向。换句话说vLLM 的“强”不只是表面上的性能数字而是它把调度、显存、批处理、前缀、并行这些决定服务水平的东西都做了系统性的优化。拿它和 Ollama 比相当于拿调度系统跟家用自动化工具比——两者都是好东西但服务层次不同。3. 实操记录把两个框架都跑一遍3.1 Ollama 快速上手从安装到 API 调用我仍然建议所有想入门的朋友先从 Ollama 开始不是因为它最强而是因为你不能在 10 分钟内看到一个模型真的跑起来后面再强大的技术都跟你没关系。以 Linux 环境为例一条脚本指令就能装完Windows 和 macOS 有原生客户端体验更简单。装完后执行ollama run qwen2.5:7b第一次会下载模型之后本地启动直接进入交互式对话。交互式对话背后其实是一个常驻服务进程默认监听 11434 端口。你甚至不用进入交互界面直接用 API 就能调用curl http://localhost:11434/api/generate \ -H Content-Type: application/json \ -d {model: qwen2.5:7b, prompt: 用一句话介绍什么是大模型}更常见的做法是走 OpenAI 兼容接口curl http://localhost:11434/v1/chat/completions \ -H Content-Type: application/json \ -d {model: qwen2.5:7b, messages: [{role: user, content: 你好}]}如果你只需要在代码里调用本地模型这个接口基本可以无缝替换原来的 SDK 调用方式。我平时做原型验证的时候甚至不需要改任何业务代码只把 base_url 换成http://localhost:11434/v1就行。Ollama 还有几个命令值得记住ollama list查看本地模型ollama ps查看当前加载的模型和显存占用ollama cp复制模型做修改ollama show查看模型信息。要自定义推理参数可以写一个 Modelfile比如设置 temperature 和上下文长度然后用ollama create生成一个新的本地模型。这一步对只想微调行为、不想改动权重的人来说非常实用。3.2 vLLM 部署把显存当作需要规划的预算vLLM 的安装多数人直接用 pip 装即可但建议先确认 Python 版本和 CUDA 驱动满足要求Linux 环境最顺Windows 用户要折腾 WSL。装好之后启动一个 OpenAI 兼容服务的方式大致如下python -m vllm.entrypoints.openai.api_server \ --model /data/models/qwen2.5-7b-instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9 \ --port 8000这段命令背后发生的动作很值得理解。--model指向一个 Hugging Face 格式的模型目录--max-model-len决定你允许的最大上下文长度直接影响 KV Cache 的容量预算--gpu-memory-utilization 0.9表示让 vLLM 预占约 90% 的显存用于模型权重和 KV Cache剩下 10% 留给 CUDA graph 以及其他零碎开销。启动后同样可以用 curl 测试curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d {model: /data/models/qwen2.5-7b-instruct, messages: [{role: user, content: 你好}]}vLLM 冷启动一般比 Ollama 慢因为要做模型加载、显存分配、CUDA graph 构建。7B 模型在一张普通显卡上大概 10 到 30 秒内可以就绪大模型或者多卡时间更长。第一次启动如果看到 CUDA graph 相关报错可以先加--enforce-eager关掉相关优化把问题定位清楚再决定。启动后还有自带的/metrics端点可以接入 Prometheus 看吞吐、排队时长等指标这一点对生产很有用。3.3 性能测试不要凭感觉对比我在帮别人做选型时最反对直接拿一个 prompt 在两套环境里敲一遍看谁打字快就下结论。性能对比必须控制变量并明确场景。同样的模型、同样的输入输出长度、同样的并发数才有一点可比性。简单测试可以用脚本并发打请求。一个最小思路是准备几十个并发请求每个请求带固定输入文本统计所有请求完成所需的总时间和平均每个 token 的输出速度。可以直接用 Python 写也可以直接用 hey、wrk、k6 这类压测工具。vLLM 的/metrics里有requests_total、generation_tokens_total、time_to_first_token等指标我一般用这些做更长周期的观测。以我手头常见环境单张消费级显卡、7B 模型、中等输入长度的经验来看Ollama 单请求体验很好首字延迟和生成速度都挺体面一旦并发数拉到 8 到 16请求排队和总完成时间就会明显变差整体吞吐上不去。vLLM 在同样的并发压力下单请求首字延迟略有增加但整体吞吐可以稳定在数倍于前者的水平随着并发继续拉高优势会更明显。注意这是经验值不是 benchmark 结论不同模型、不同上下文长度下差距会变化但方向基本一致。3.4 我的参数调优心得Ollama 侧真正值得调的参数不多但几个环境变量要记住OLLAMA_NUM_PARALLEL控制一个模型最多同时处理的请求数OLLAMA_MAX_LOADED_MODELS控制最多同时驻留几个模型OLLAMA_KEEP_ALIVE控制模型在内存和显存里的保活时长默认 5 分钟对反复测试可能不够长任务前可以设大一点。如果并发上去了发现 Ollama 响应变慢先看是不是这几个环境变量没设。vLLM 侧优先调三个参数。一是--max-model-len它决定 KV Cache 预算设太大浪费显存、设太小长对话直接报错二是--gpu-memory-utilization一般 0.85 到 0.95 比较稳妥不要顶到 1.0三是--max-num-seqs限制单 batch 内最多序列数量避免极端并发下单请求延迟过高。有条件还可以开--enable-prefix-caching固定 system prompt 或多轮对话场景收益明显。至于量化参数我建议先跑 fp16 或默认精度确认功能正常后再尝试 AWQ、GPTQ省得混在一起排查问题。4. 选型决策到底怎么选4.1 先回答六个问题我总结了一个自查清单帮你在五分钟内锁定方向。使用者是只有你还是一组人给自己玩优先 Ollama给别人提供 API老实考虑 vLLM。预期并发是多大并发个位数且不强调稳定Ollama 完全够要扛几十上百甚至更高并发选 vLLM。模型文件是什么格式GGUF 拿来就跑选 OllamaHugging Face 权重、要做精细控制选 vLLM。你的硬件是什么层次消费级单卡、Mac、CPU 环境Ollama 更省心有多卡、要跑大模型vLLM 的分布式能力是刚需。你打算投入多少运维精力不想管环境、希望 10 分钟出结果选 Ollama愿意学习调度参数、做监控调优选 vLLM。后续会不会接到生产服务里哪怕今天只是 Demo如果明天就要接 API直接从 vLLM 起步可能更划算。这个清单不是教条而是一个提醒选型失败往往不是因为工具不好而是因为对场景的预判和工具定位不匹配。4.2 场景对照表为了决策更直观我把常见场景列成一张表。场景推荐原因本地学习、实验、写代码辅助Ollama上手快资源占用可控离线环境单机推理Ollama不需要复杂依赖快速做原型 DemoOllama10 分钟出效果团队成员共享一个推理服务vLLM并发吞吐更重要对外提供 API有稳定压力vLLM调度、监控、高并发支持完整多卡部署大模型vLLM张量并行/流水并行主要在 Windows/Mac 本地跑Ollama官方客户端体验完善需要和微调、评测工具链集成vLLM与主流模型生态原生打通看完这张表你会发现一个规律以“我”为中心的工具Ollama 赢面大以“系统”为边界的产品化服务vLLM 赢面大。这不是性能高低决定的而是工具的使命决定的。4.3 有一种更聪明的用法混合方案很多团队最后实际跑通的方案并不是二选一而是两套都留。开发工程师本地用 Ollama 跑一个小模型负责验证 Prompt 逻辑和业务代码测试环境和生产环境用 vLLM 部署正式模型承担真实并发。两者都暴露兼容接口所以业务代码只需要切换 base_url迁移成本很低。需要注意两个细节。第一是模型格式本地 Ollama 用的 GGUF 可能转不回 vLLM 需要的权重格式转换后要在目标环境重新验证输出质量第二是参数差异两边对 temperature、top_p 等采样参数的解释基本一致但 API 返回结构里有些字段不完全一致业务尽量只依赖choices里的核心字段。另外如果你只有一个后端服务但希望同时负载本地实验和生产流量也可以用一个路由层做分流。不过我不建议把问题搞复杂绝大多数场景下开发环境 Ollama、生产环境 vLLM已经是很平衡的架构。5. 常见问题与避坑实录5.1 我实际踩过的坑第一vLLM 启动没多久就显存溢出。最常见原因是--max-model-len设得过大或者--gpu-memory-utilization顶到 1.0导致没有给 CUDA graph 留余量。我的习惯是先按 0.9 设再用实际业务里最长的上下文需求反推max-model-len别图省事拉满。第二Ollama 某次调用模型很慢以为是坏了其实是默认 keep-alive 把之前模型卸载了重新加载要花时间。后来在自动任务里显式把keep_alive参数调大问题就消失了。遇到“第一次请求明显变慢、后续变快”的情况十有八九是保活机制在作祟。第三模型格式混用导致的困惑。我在本地用 GGUF 测得好好的换到 vLLM 才发现不能直接加载要么转格式要么重新下载对应权重。现在我的习惯是涉及可能要上生产的模型从一开始就下载对应权重纯粹本地玩的模型才用 GGUF。第四量化模型的精度陷阱。AWQ、GPTQ、GGUF 的 q4 量化确实能显著省显存但在代码生成、数学推理这类高精度任务上量化常常导致输出质量肉眼可见地下降。建议先用未量化的版本跑一遍正确性测试再决定要不要为省显存接受精度损失不要一上来就压到最低精度。5.2 常见问题速查表问题原因解决办法Ollama 并发一高就排队默认并行度低设置 OLLAMA_NUM_PARALLELOllama 隔一段时间响应慢模型被保活机制卸载调大 OLLAMA_KEEP_ALIVE 或 API 传 keep_alivevLLM 启动即 OOMmax-model-len 或显存利用率过高调小 max-model-lengpu-memory-utilization 设 0.9 以下vLLM CUDA graph 报错驱动或显卡兼容问题加 --enforce-eager 先跑通请求上下文超长被拒max-model-len 不够增大该值或业务侧做截断量化后输出质量下降明显量化精度过低或方法不匹配提升量化位宽先用未量化权重验证本地 Ollama 和线上 vLLM 输出不同格式、量化、采样参数不一致固定相同采样参数同权重复测这个表可以说是我自己排查问题时的最小备忘遇到类似现象的时候直接照着方向查能省不少时间。5.3 几个容易被忽视的小技巧还想在这里补几个平时教程里不太会讲的细节。Ollama 如果跑在服务器上建议不要把默认端口直接暴露到公网加一层鉴权或者只在内网使用因为它的默认 API 没有身份校验。vLLM 也类似生产环境前面通常要放一个网关负责限流、鉴权和负载均衡vLLM 本身并不负责这些事。另一个技巧是如果你在 vLLM 里要频繁跑长 prompt 的批量评测强烈建议开前缀缓存并且把评测数据的公共提示词统一到最早的位置这样缓存命中率会非常高。Ollama 侧没有对应的显式开关但可以通过固定 system prompt 和尽量复用相同上下文来获得类似收益。还有一个习惯问题无论选哪个框架模型文件本身都建议单独挂载在独立磁盘上不要跟系统盘混在一起。大模型文件动辄几十 GB系统盘空间被撑爆导致服务崩溃的案例我见过不止一次。我自己现在的工作流基本就是一个混合架构桌上电脑里跑着 Ollama用来日常调试、检验 prompt 效果生产环境跑着 vLLM由监控和压测数据来驱动参数调整。这两个工具放在各自的位置上都很好用。非要逼我用一句话总结那就是如果你还不知道模型怎么跑选 Ollama如果你的模型要跑给别人看选 vLLM。至于更具体的数字和调参还是要回到你自己的硬件和业务场景里去实测别人的经验只能帮你少走弯路不能替你踩坑。