★ FEATURED ARTICLE 最近如果你在接触本地大模型一定绕不开两个名字Ollama 和 vLLM。前者被大家叫作“一行命令跑模型”的神器后者则是高并发推理服务里的常客。很多朋友一开始都是用 Ollama 把模型拉下来跑通对话觉得挺香等真要把模型开放给团队或线上业务用才发现并发一上来响应时间变得没法看。这时候再回头看 vLLM又会被它的部署参数和依赖环境吓到。这篇我不打算念文档而是从实际选型的角度把这俩工具从定位、原理、参数、压测到坑一次讲透。你可以直接按自己的场景做决策也可以把里面的启动命令和调优参数拿回去改改就用。1. 两个工具到底在扮演什么角色先别急着比较性能很多选型错误都是因为没搞清两者的定位。Ollama 和 vLLM 不是同一个物种它们只是碰巧都能“跑大模型”而已。1.1 Ollama为“本地跑模型”这件事做了极致简化Ollama 的核心价值是降低门槛。它把模型下载、格式转换、推理后端、API 服务这几件事打包成一个非常简单的命令行工具。你装好之后一条ollama run就能把模型拉下来并进入交互式对话想开个 HTTP 服务也只要ollama serve。这种体验是 vLLM 给不了的。官方安装脚本本来就做得很友好装完默认监听11434端口OpenAI 兼容接口也内置了很多客户端开箱即用。它的模型包用 GGUF 格式底层推理核心来自 llama.cpp 那套方案对 CPU、GPU 混合环境支持得不错甚至你不用 GPU 也能跑起来。这个特点让它非常适合笔记本、开发机、内网小工具这类场景。但简化是有代价的。Ollama 的默认配置更多面向“单用户交互”和“少量并发”而不是“大规模流量”。虽然它也支持通过环境变量调并发数但底层的调度策略、显存管理和批处理机制并不是为了把每一块显存都榨干而设计的。简单说Ollama 想让你五分钟跑起来而不是让你五分钟搭一个高吞吐在线服务。1.2 vLLM为“服务化高吞吐”而生的推理引擎vLLM 从诞生那天起目标就很明确把大模型推理做成一个能扛住高并发的服务引擎。它不是一个用来“聊天”的工具而是一个高性能推理服务。它的默认入口就是 OpenAI 兼容 API启动后监听8000端口通过 HTTP 接口接收请求。vLLM 支持 Hugging Face 格式的模型目录也支持 AWQ、GPTQ 这类主流量化格式还支持多卡张量并行把一个大模型切到多张 GPU 上跑。这些能力让它可以出现在生产环境里作为业务后端的模型服务。它的核心卖点是连续批处理和 PagedAttention这两个机制我会在下一章展开讲简单说就是同等显存下vLLM 能同时处理更多请求吞吐量比普通推理框架高一大截。当然代价是部署复杂。它依赖 Python 环境、CUDA、特定版本的 PyTorch对驱动和算力有要求。想把它当 Ollama 那样一条命令跑起来是不现实的。但如果你要服务几百上千个业务请求这点复杂度完全值得承受。1.3 核心差异的一句话模型我用一句话总结如果你要的是“我自己能快速跑起来偶尔几个人用”选 Ollama如果你要的是“把它当线上服务稳定扛住每秒几十甚至上千个请求”选 vLLM。这个判断不是拍脑袋。Ollama 更像一个“本地开发工具”vLLM 更像一个“生产级服务组件”。工具本身没有优劣只有合不合适。很多团队走的路子是从 Ollama 起步验证效果然后切 vLLM 上线这很合理。但如果你一上来就做线上业务跳过 Ollama 直接上 vLLM 也没问题只是学习曲线会陡一点。2. 为什么 vLLM 能同时扛这么多请求很多人不理解同样是跑同一个开源模型为什么 vLLM 的并发能力比 Ollama 强那么多其实核心不在模型而在推理引擎的调度机制。2.1 连续批处理才是高吞吐的关键传统推理服务处理请求时最常见的做法是把一批请求固定起来等这批跑完再接收下一批。这种方式叫 static batching。它的缺点很明显如果批里有请求短、有请求长短的跑完了也得等长的结束GPU 中间会出现大量空转。vLLM 用的是 continuous batching也叫连续批处理或动态批处理。它的做法是当一个请求的生成长度达到设定上限或者提前触发了停止条件就立刻把它从当前批次里移出去腾出位置给新请求。这样 GPU 的计算单元几乎一直在干活不会出现“一个慢请求拖垮整批”的现象。你也许在 Ollama 里也看到过类似参数比如OLLAMA_NUM_PARALLEL。确实Ollama 也能并行处理几个请求但它的并行粒度没有 vLLM 那么细。vLLM 是在 token 级别动态调度Ollama 更多是在请求级别做有限并发。一个 token 一个 token 地穿插执行和整批整批地切换效果是完全不同的。2.2 PagedAttention 把显存“碎片”重新捡起来除了调度显存管理也是关键。大模型推理时要缓存历史的 Key 和 Value也就是常说的 KV Cache。这个缓存会随着生成长度变化如果提前给每个请求分配最大长度的缓存空间显存浪费会非常大。vLLM 引入了 PagedAttention思路和操作系统虚拟内存分页很像。它把 KV Cache 切成固定大小的块按需分配而不是一次性给整个请求预留完整空间。这样显存里几乎没有碎片浪费相同显存能容纳更多并发请求。这也是 vLLM 在长文本、多请求场景下表现特别好的原因。Ollama 底层走的是 llama.cpp 那套也不是没有优化但它的缓存策略相对保守主要还是围绕单请求和少量并发来设计。你用 Ollama 跑一个大模型虽然显存占用看起来不高但一旦并发上来KV Cache 会迅速膨胀很容易把显存顶爆。vLLM 因为按页分配能在同样显存里塞下多得多的请求。2.3 调度策略的差异来自设计目标继续往深看两者对“请求”的理解就不一样。Ollama 更像一个“会话管理器”它关心的是一次交互的完整性所以你调 API 时它会保留上下文、维护历史消息这对聊天很友好但对服务吞吐没那么友好。vLLM 则把每一个请求看成独立的推理任务通过调度器统一排队、分批、抢占。它甚至支持 prefix caching也就是如果多个请求共享同一段前缀比如系统提示词这段前缀的 KV Cache 可以复用不用每个请求都重新算一遍。这个优化在 RAG、Agent 这类场景里收益特别明显Ollama 目前没有这种级别的能力。所以你会发现vLLM 能扛千级并发不是因为它用了更神奇的模型而是它在调度和显存管理上做得更极致。Ollama 也能跑服务但它把资源优先给了易用性和兼容性调优空间有限。3. 选型决策树照着选就行与其纠结“到底哪个好”不如看自己的场景。我按常见的几类需求给一个决策路线绝大多数团队都能在里面找到对应位置。3.1 个人开发、原型验证、内网小工具优先选 Ollama如果你只是在自己电脑上做实验或者给内部几个同事提供一个模型体验入口Ollama 是最舒服的选择。它装起来快模型管理方便ollama pull拉模型、ollama list看本地模型、ollama rm删除模型一套命令下来没有任何心智负担。如果你想快速做一个聊天机器人 Demo或者给公司内部做一个知识库问答用户量不超过十几二十个Ollama 完全够用。它也提供 OpenAI 兼容 API很多现有代码不用改就能接进来。我自己在项目原型阶段就经常用 Ollama 顶着等要接真实业务流量再切 vLLM。还有个场景非常适合 Ollama边缘设备、离线环境、CPU 机器。因为它支持 GGUF 格式一个模型文件就是一个包拷贝到指定目录就能跑不需要复杂的 Python 依赖环境。某些内网隔离环境里Ollama 反而是最好部署的方案。3.2 线上服务、并发业务、高 QPS 需求直接上 vLLM如果你的模型会被放在公网或者内网核心链路上请求量会随着业务波动那直接上 vLLM。我见过不少团队用 Ollama 上线后被压垮不是 Ollama 不稳定而是它的并发上限摆在那里再怎么调都有限。vLLM 适合这些场景多用户共用的模型服务、Agent 调用链路中的推理节点、RAG 服务、批量离线推理、需要多个模型同时加载并动态切换的服务。它支持 tensor parallel一张卡装不下的模型可以切成多张卡跑也支持流式输出、logprobs、工具调用这类比较细的功能能更好地满足业务定制。另外vLLM 的社区版本迭代很快很多新的量化方法、推理优化、采样功能都会先支持。从长期维护角度看选 vLLM 更不容易踩到“工具能力天花板”的问题。3.3 折中方案先用 Ollama 验证再用 vLLM 上线很多团队的实际路径是两步走。第一步用 Ollama 把模型跑起来验证效果、调提示词、做产品 Demo第二步把同样的模型目录放到 vLLM 里接住真实流量。这个路径的好处是前期不会被 vLLM 的部署复杂度拖慢节奏后期也不会被 Ollama 的并发能力卡住脖子。关键点是模型格式。Ollama 默认要 GGUFvLLM 默认要 Hugging Face 格式。如果你一开始就想好以后要迁 vLLM最好直接用原生模型目录在 Ollama 里通过导入本地模型的方式跑不要只依赖从 Ollama 仓库拉取的包。这样到了迁移阶段你只需要把目录切给 vLLM 就行。如果图省事也可以关注 Ollama 对 vLLM 的适配近几个版本 Ollama 已经能通过一些参数接入部分 vLLM 后端但说实话这种组合的意义不大反而增加复杂度。线上服务我建议直接独立部署 vLLM不要叠一层套壳。3.4 关键维度对照表对比项OllamavLLM安装复杂度极低一条命令中等需要 Python 环境模型格式GGUF 为主Hugging Face、AWQ、GPTQ默认端口114348000并发能力较低适合少量用户高适合高吞吐生产显存优化一般PagedAttention按页分配多卡支持有限支持 Tensor Parallel前缀缓存不支持支持API 兼容OpenAI 兼容OpenAI 兼容适用场景本地体验、内网小工具线上服务、高并发、RAG这张表基本能覆盖 90% 的选型问题。如果你看完还在犹豫那就记住选 Ollama 是因为省事选 vLLM 是因为要扛量。4. Ollama 和 vLLM 的实操上手记录这一章我直接给可复现的步骤和参数。两部分都按“装起来→启动服务→发起请求→调参”的顺序写你在机器上跟着跑就能出来。4.1 Ollama 一行命令跑通全流程Ollama 的安装这里不贴冗长的编译过程直接用官方安装脚本就行。安装完成后拉取一个开源对话模型只需要一行ollama run qwen2.5这条命令会自动下载模型并进入交互对话。如果想后台提供 HTTP 服务可以这样ollama serve默认监听11434调用方式为curl http://localhost:11434/api/chat \ -H Content-Type: application/json \ -d {model:qwen2.5,messages:[{role:user,content:你好}]}如果你用 OpenAI 客户端OpenAI 兼容地址是http://localhost:11434/v1。这个接口支持chat/completions不过功能有限比如部分高阶采样参数会被忽略。想调并发的话Ollama 主要看环境变量。我常用的配置是OLLAMA_NUM_PARALLEL4 \ OLLAMA_MAX_LOADED_MODELS2 \ ollama serve这里的OLLAMA_NUM_PARALLEL4表示每个模型最多并行处理 4 个请求。这个值不建议调太高因为 Ollama 的调度是针对少量并发的调高了很容易出现显存碎片和响应超时。4.2 vLLM 从本地模型目录到 OpenAI 兼容接口vLLM 的安装通常用 pippip install vllm这里提醒一句vLLM 对 PyTorch 和 CUDA 版本有要求建议直接用官方给的安装命令别自己在老环境里强行升。装好之后启动一个模型服务最简命令是vllm serve /path/to/model \ --served-model-name my-model \ --port 8000注意第一个参数是本地模型目录里面要有config.json、tokenizer 文件和权重文件。如果你没有现成目录可以先下载一个 Hugging Face 格式的开源模型拷到/path/to/model下。--served-model-name是客户端调用时用的模型名可以自定义不影响实际权重。启动后它的服务地址就是http://localhost:8000/v1。用 OpenAI 客户端调用时base_url填这个地址model填my-model就能无缝接上。如果要用量化模型你可以用 AWQ 格式的目录并在启动时加vllm serve /path/to/awq-model \ --quantization awq \ --gpu-memory-utilization 0.94.3 显存与并发参数怎么调vLLM 的高并发不是默认拉满的关键参数必须根据显存和业务量调整。首先是--gpu-memory-utilization。这个值表示允许 vLLM 占用 GPU 显存的比例默认通常是 0.9。如果你的 GPU 还跑着其他任务要降下来如果专门给模型服务用可以到 0.9 甚至更高。然后是--max-model-len。它表示模型支持的最大上下文长度。这个值直接影响 KV Cache 的预分配量设得越大能并行处理的请求数相对越少。我一般先按业务实际需求来不需要一上来就开 32K、128K除非你的场景真的要处理那么长的文本。再就是--max-num-seqs它控制一次最多并行处理的序列数。这个参数决定并发上限但也不能拍脑袋开大要和显存、模型长度一起折算。常见的做法是先设一个值压测后逐步往上加看到 OOM 再回退。启动命令示例vllm serve /path/to/model \ --served-model-name my-model \ --gpu-memory-utilization 0.9 \ --max-model-len 8192 \ --max-num-seqs 256 \ --enable-prefix-caching \ --port 8000这个组合能应对不少线上场景。如果有多张卡模型也大可以加--tensor-parallel-size 2把模型切到两张卡上。5. 压测与性能数据的解读方式很多人说 vLLM 能“扛住千级并发”但到底怎么验证我自己压测时踩过不少坑这里把方法和指标讲清楚。5.1 我习惯的压测方法压测大模型服务和压测普通接口不一样不能只看 HTTP 层的并发连接数。因为模型服务的关键路径是 token 生成速度而不是连接的建立速度。我常用的工具是wrk或者vegeta它们可以模拟多线程持续请求。测试时脚本里固定一个 prompt比如一段几百字的文本然后持续打服务记录吞吐量和延迟分布。注意不要用“一次性发 1000 个并发连接”这种测法因为大模型请求排队在 GPU 调度器里连接层并发再高真正处理还是在推理引擎内部排队。更科学的做法是设定目标并发数比如 50 路、100 路、200 路请求持续打看服务能不能稳定输出。所谓千级并发更多指“每秒处理千级 token 或千级请求”而不是同时建立千条 TCP 连接。5.2 不同指标的含义不要看错大模型服务最关键的四个指标吞吐量、首 Token 延迟、生成延迟、排队时间。吞吐量通常用 tokens/s 表示可以分为请求级吞吐和 token 级吞吐。vLLM 的连续批处理会让总 token 吞吐很高但单个请求的延迟不一定低。首 Token 延迟指的是从请求发出到返回第一个 token 的时间。这个指标对对话类应用特别重要因为它决定了用户“是不是卡住了”的感知。vLLM 在并发高的时候首 Token 延迟会因为排队而上升需要结合max-num-seqs和资源占用一起看。生成延迟则是整体吐出完整回答的时间。业务上通常用 p50、p95 来看用户体验。压测时不要只看平均值因为长尾延迟最容易让用户崩溃。5.3 典型数据示例我在某个模拟项目 X 里用一张 24G 显存的 GPU 跑一个 7B 模型对比过 Ollama 和 vLLM。在单请求场景下两者生成速度差距不大首 Token 延迟差不多。但并发数从 8 升到 64 时Ollama 的吞吐开始明显下跌p95 延迟飙升vLLM 因为连续批处理和分页显存吞吐基本能保持平稳。我当时测出来的数据大概是这样的Ollama 在 8 并发时能达到 600 tokens/s 左右到 32 并发时掉到 200 多vLLM 在 32 并发时依然能保持 800 以上到 128 并发时才缓慢下降。这个数字会随模型和显存变化但趋势非常有代表性。所以你在看性能对比时不要看单发速度一定要看“并发上升后的稳定性”。这也是我推荐线上服务选 vLLM 的核心原因。6. 避坑指南与维护经验最后聊一聊实际维护中容易踩的坑。这些细节文档里不会写但遇到了会非常头疼。6.1 显存 OOM 和并发上不去Ollama 并发一高就容易 OOM最常见的原因是同时加载了多个模型。虽然OLLAMA_MAX_LOADED_MODELS控制了加载数量但每个模型的 KV Cache 仍然会在并发升高时迅速膨胀。我的建议是单卡上不要同时加载超过两个 7B 模型也不要让OLLAMA_NUM_PARALLEL超过 8。vLLM 的 OOM 一般是启动时gpu-memory-utilization设太高或者max-model-len设太大。你可以先查看显卡当前占用nvidia-smi如果显示显存已经用了很多就把 GPU 利用率降到 0.7 以下。还有一种情况是max-num-seqs太大导致每个请求分不到足够的 KV Cache 块运行时报Unable to allocate cache。解决办法是降低并发数或者减小max-model-len。6.2 模型格式、量化、前缀缓存很多人从 Ollama 切到 vLLM 时踩的第一个坑就是模型格式。Ollama 拉下来的是 GGUFvLLM 不认。你需要找到原始权重目录或者手动下载 Hugging Face 格式的模型。如果你只会用 Ollama 拉模型切 vLLM 时会多花一些时间。量化格式也要注意。vLLM 对 AWQ 和 GPTQ 支持比较成熟但不同版本的 vLLM 对量化算子的支持有差异。如果启动时报Unsupported quantization先检查版本和量化参数。前缀缓存是 vLLM 的隐藏优化点。它默认不一定会开建议显式加--enable-prefix-caching。在 RAG 场景里每个请求都有很长一段相同的系统提示词这个开关可以让吞吐提升非常明显实测能省下不少重复计算。6.3 客户端切换与稳定性从 Ollama 切到 vLLM 时接口地址从11434变成8000OpenAI 兼容逻辑基本一致但有些细节不一样。比如 Ollama 的/api/chat有自己的请求格式而 vLLM 只认/v1/chat/completions。如果客户端里写死的是 Ollama 原生接口迁移时一定要改干净。vLLM 服务起来之后建议把日志加上--verbose它会打印 request 级别的基础信息。前端业务接入时记得开启流式输出否则用户会感觉首包特别慢。流式接口在 OpenAI 客户端里通常通过streamTrue开启。另外服务稳定性还需要关注健康检查。vLLM 默认有/health接口Ollama 没有标准健康检查。在容器编排里接入时vLLM 更方便。如果你是裸进程部署至少让监控脚本定期请求一次v1/models确认服务还活着。从长期维护来看vLLM 的配置项虽然多但每一个都有明确用途。Ollama 省心但省心是有边界的。边界之外老老实实上 vLLM把gpu-memory-utilization、max-num-seqs、max-model-len这三个参数调好你的服务至少能稳定扛过一个业务高峰。
阅读完成 · 觉得有帮助？
