这段时间被问得最多的一个问题vLLM 和 Ollama到底选哪个问的人里既有刚摸到大模型、想在自己电脑上跑个 Demo 的开发者也有已经在生产环境被并发压测追着跑的运维同学。乍一听是工具二选一实际背后完全是两条技术路线一边是“一行命令跑起来”的极简体验一边是“为高吞吐、高并发优化到极致”的工业级引擎。这篇我根据自己的实测经验把两个工具从安装、底层机制、并发表现到选型思路完整拆一遍争取让你读完不用再纠结。1. 先搞清楚两个工具的本质定位1.1 Ollama 的定位把“跑模型”这件事做成和装 App 一样简单Ollama 从一开始就没打算让你跟“推理引擎”“显存分配”“KV Cache”这些词打交道。它的核心思路是你只要告诉我“我想跑哪个模型”剩下的一切由工具自动搞定。模型权重下载、格式转换、量化精度选择、GPU/CPU 调度、API 服务启动全部封装在几条命令里。我记得第一次装完 Ollama终端敲一行ollama run llama3.1:8b接下来就是等进度条走完然后直接在终端里和模型对话了。没有 Python 环境配置不需要手动创建虚拟环境也不用去模型库网站手动下载权重再转换格式。这种“开箱即用”的体验对入门和小项目来说是巨大优势。而它背后的机制其实是把 llama.cpp 这种方案给包了一层。llama.cpp 的优势在于能在消费级显卡甚至纯 CPU 上跑模型配合动态量化把显存需求压得很低。Ollama 默认会帮你选用量化版本比如 Q4_K_M 这类精度还会根据你机器上可用显存自动决定模型放 GPU 还是部分放 CPU这让很多只有 8G 显存的用户也能跑 7B~14B 模型。1.2 vLLM 的定位为高并发和高吞吐而生的推理服务引擎vLLM 是完全不同的思路。它不做“我帮你下载模型”这种事而是专注于一件事当你的模型服务要被很多人同时调用时怎么把 GPU 的算力榨干让吞吐量尽量高同时把延迟控制住。vLLM 诞生的核心动机是解决大模型推理时代一个经典痛点显存不够用。模型权重已经占了大量显存而推理时每个请求还都要占用一块不断增长的 KV Cache键值缓存。请求越长、并发越高KV Cache 膨胀得越厉害传统整块显存预留的方式会把显存快速吃光。vLLM 提出的 PagedAttention 机制用操作系统内存分页的思路来管理 KV Cache把显存利用率提升了一个量级。这个我们后面细讲。所以你会发现 vLLM 的典型使用方式是先在 HuggingFace 或其他模型库准备好模型权重然后用 vLLM 启动一个兼容 OpenAI 接口的服务之后业务方像调用 OpenAI 一样直接调你的本地/私有化服务。它面向的是 API 服务、生产部署、多用户并发这样的场景自然会方到“千级并发”这个层面来说。1.3 一张表看懂两者差异对比维度OllamavLLM核心理念极简、开箱即用高性能、高吞吐安装门槛一条命令需要 Python/Docker 基础模型管理内置模型下载和版本管理需要自己准备模型权重显存管理策略自动量化自动调度PagedAttention 精细管理默认并发上限较低适合小规模很高面向服务化场景API 兼容性提供 OpenAI 兼容接口原生 OpenAI 兼容接口适合人群个人开发者、本地研究生产环境、平台型团队这里不是说谁比谁强而是定位差异。选错工具后面会非常痛苦拿 Ollama 去扛生产压测任务你会发现吞吐和并发根本不够看拿 vLLM 去给一个刚入门的朋友推荐光是环境配置就可能劝退他。2. 从零上手两边的安装与首次跑通体验2.1 Ollama三分钟从裸机到对话Ollama 的安装覆盖了 Linux、macOS、Windows官方提供了安装脚本。Linux 下执行官方一键脚本后就可以直接用命令行操作了。# Linux 下通过官方安装脚本 curl -fsSL https://ollama.com/install.sh | sh # 启动服务通常安装完会自动运行 ollama serve # 新开终端直接拉取并运行模型 ollama run llama3.1:8b跑起来后你能直接在终端跟模型对话同时 Ollama 默认会在11434端口起一个 API 服务所以其他程序也可以通过 OpenAI 兼容接口访问。这里有几个我实际遇到过的小细节。第一模型的存放目录默认在~/.ollama/models如果你在服务器上跑磁盘空间不足时可以把模型目录通过OLLAMA_MODELS环境变量迁到数据盘。第二ollama run这个命令在交互模式下很好用但如果要做自动化脚本更推荐直接调 API 而不是跑交互进程。第三换模型时用ollama stop释放显存否则多个模型会抢占显存极端情况下会直接把进程杀崩。初次体验来说从安装到和模型对话确实可以实现三分钟内完成前提是网络环境允许下载模型。2.2 vLLM从 pip 安装到拉起一个 OpenAI 兼容服务vLLM 的安装其实也不复杂只是对运行环境有要求需要 Python 3.9 以上最好有 NVIDIA GPU 和 CUDA 环境。最常规的方式是 pip 安装pip install vllm然后用一行命令启动服务vllm serve Qwen/Qwen2.5-7B-Instruct --host 0.0.0.0 --port 8000启动完成后你会得到一个兼容 OpenAI 的接口直接支持/v1/chat/completions和/v1/completions所以很多现成的 OpenAI SDK 都可以无缝切换只要把 base_url 指向 vLLM 服务地址即可。如果你不想在宿主机上配 Python 环境用官方 Docker 镜像会更省事docker run --runtime nvidia --gpus all \ -v ~/.cache/huggingface:/root/.cache/huggingface \ -p 8000:8000 --ipchost \ vllm/vllm-openai:latest \ --model Qwen/Qwen2.5-7B-Instruct第一次启动时 vLLM 会从模型仓库下载权重这个过程取决于模型大小和网络速度。启动好了以后日志里会打印出显存占用、并发配置等信息。实测下来vLLM 对显存的使用确实比 Ollama 要紧张因为它默认会尽可能把空闲显存预留给 KV Cache所以你会看到它启动后显存占用率比 Ollama 高这是设计预期是为了后面高并发时具备更高的吞吐。2.3 首次跑通 7B 模型的真实体感对比我在一台有 24G 显存、64G 内存、无 GPU 的服务器仅 CPU和一台 4090 显卡的机器上分别做过对比。在 4090 上Ollama 拿 7B 模型大概 30 秒内就能开始对话vLLM 首次加载需要在显存里建缓存和 CUDA 图大概要多花一到两分钟。但首次启动后后续请求的响应速度vLLM 在单请求延迟上并不比 Ollama 快甚至略慢一点点因为它的前期调度和优化目标是高吞吐而非单请求最低延迟。如果只是在本地自己聊天Ollama 的体验反而更好。但一旦有几十上百个并发请求同时进来Ollama 会开始排队而 vLLM 依然能保持稳定的吞吐。这就是两条路线的分野。3. 核心机制拆解性能差距从何而来3.1 Ollama 的底层引擎与显存策略Ollama 早期核心基于 llama.cpp 的推理能力后来逐渐扩展。llama.cpp 本身是一个高度优化的 C/C 推理引擎擅长在消费级硬件上运行支持各种量化格式和 CPU 推理。Ollama 对它做了封装把模型下载、格式探测、量化选择、上下文窗口设置、服务启动都打包成统一体验。Ollama 的显存策略可以概括为“自动适配不够就换”。模型默认以量化格式运行比如 Q4_K_M 这种 4-bit 量化相比 FP16 的原始权重显存需求降低到接近四分之一。显存不足时它会把部分层放到 CPU 跑底层算力分摊。这种策略对个人电脑非常友好但对生产系统就有些问题量化本身会带来精度损失CPU 卸载会拉高延迟自动调度行为也难以在压测场景下精准控制。在实际生产里你的请求负载波动、显存碎片、多模型共存这些复杂情况Ollama 的自动化策略可能不够灵活缺少精细的控制粒度。3.2 vLLM 的 PagedAttention把 KV Cache 管得像操作系统一样精细vLLM 性能优势的核心就是 PagedAttention。要理解它得先知道 KV Cache 是什么。大模型推理时每个请求都会把历史 token 的 Key 和 Value 缓存下来用于后续生成时计算注意力。这就像你看连续剧要先记住前面的剧情才算得下去后续发展。每个并发请求都有一份独立的 KV Cache请求越长、并发越高缓存占用的显存越大。传统推理引擎通常在显存里预留一大块连续空间给 KV Cache请求尺寸变化时要么预留不够要么预留了用不上造成大量碎片和浪费。PagedAttention 把 KV Cache 划分成固定大小的“页”像操作系统管理内存一样进行分页管理。每个请求的缓存可以分布在多个不连续的页里需要时动态分配。这样显存碎片大幅减少真正做到了按需分配KV Cache 的利用率可以接近 100%。这直接带来两个效果同样的显存能同时服务更多请求同时因为利用率高了整体吞吐自然也就上去了。这个机制我在压测中感受非常明显。用 Ollama 跑 34B 模型并发到 8 个请求时显存可能就触顶了vLLM 在同样的显存配置下能稳定跑二三十个并发而且显存没有爆掉。这就是分页机制和管理策略差异带来的结果。3.3 连续批处理为什么 vLLM 的 GPU 总在忙除了显存管理另一个影响性能的关键是批处理策略。传统推理服务常见的做法是“饱和式批处理”当请求达到一定数量或者计时器到点就开始跑一个批次等这个批次全部生成完毕再执行下一批。问题在于批次里每个请求的实际生成速度不一样有的早早就结束了但整个批次还得等最后一个慢的。GPU 算力在这种等待中白白浪费。vLLM 用的是 continuous batching中文叫连续批处理或动态批处理。每个请求独立推进谁生成完了就释放资源新请求可以立即插入到执行序列中。GPU 几乎始终在计算状态不会因为没有凑满一个批次就闲置。这个机制对高并发环境非常关键它让吞吐量不再受“批次边界”限制。实测里vLLM 在 16 并发、8B 模型的简单问答场景下每秒钟生成的 token 数量是 Ollama 同等硬件条件的好几倍。这还没有到千级并发只是同一张显卡上的对比差异已经非常明显。3.4 前缀缓存、量化与并行能力vLLM 还有一个容易被忽略但很实用的特性前缀缓存。它会把 prompt 的前缀做缓存下一次遇到相同前缀时直接复用计算结果避免重复计算。这在 RAG 场景、多轮对话、批处理任务里效果显著。在量化支持方面vLLM 也覆盖了主流方案比如 AWQ、GPTQ、FP8 等可以在几乎不影响吞吐的情况下进一步压显存。并行能力方面vLLM 支持张量并行和流水线并行可以把一个大模型切到多张 GPU 上跑。配合 Ray 集群还能做到多机多卡部署。Ollama 在这块没有原生能力它是偏单机单卡/多卡的工具。能力OllamavLLMKV Cache 管理传统预留式PagedAttention 分页式批处理策略常规排队/批次处理连续动态批处理前缀缓存无自动前缀缓存量化支持默认自带 GGUF 量化支持 AWQ、GPTQ、FP8 等多卡并行有限支持张量并行、流水线并行、集群扩展4. 并发场景实测从单路请求到高压压测4.1 单用户场景体感接近如果不考虑并发只是一个人聊天或调用接口两个工具的响应延迟差距很小。在 4090 上跑 8B 模型Ollama 和 vLLM 的输出的首 token 速度都能做到每秒几十 token 以上生成速度受模型参数和显存带宽影响更大。vLLM 在单请求场景下甚至会因为 CUDA 图捕获、调度开销略有延迟但基本可忽略。所以如果只是一个人用选谁都无所谓看重启动速度和易用性就选 Ollama。4.2 多用户并发差距迅速拉大并发到 10 个、20 个请求时差距就开始显现。Ollama 默认的并发排队能力有限实测中 8B 模型在 20 并发下会出现明显排队部分请求的等待时间达到几十秒。vLLM 在同一条件下能保持相对稳定的响应吞吐量曲线平滑。再往上50 并发、100 并发时Ollama 如果不做环境变量的调优请求大量堆积延迟飙升vLLM 通过连续批处理把每次 GPU 迭代都塞满请求token 吞吐量达到最高值。我自己压过 200 并发vLLM 在 8B 模型、24G 显存条件下依然能保持每秒 3000 token 级别的吞吐具体数值取决于模型和输入长度而 Ollama 的吞吐很快触到天花板。如果想试 Ollama 的并发上限可以通过环境变量做一些调整# 允许每个模型最多并行的请求数 export OLLAMA_NUM_PARALLEL4 # 最大同时加载的模型数量 export OLLAMA_MAX_LOADED_MODELS1 # 排队请求上限 export OLLAMA_MAX_QUEUE512这些参数能缓解排队压垮进程的问题但改变不了底层的调度机制真要作为生产高并发服务来用仍然非常吃力。4.3 所谓“千级并发”到底意味着什么这个话题必须务实看待。千级并发不是单张显卡能撑住的事情也不是仅靠推理引擎就能解决的。假设一个 7B 模型的输出速度为每秒 50 token千级并发意味着每秒要向客户端吐出几万 token这需要巨大的计算和显存资源。实际上千级并发通常需要多台机器组成的推理集群负载均衡器分流转发任务队列削峰填谷以及强大的显存池和弹性的扩缩容能力。vLLM 的设计目标就是为了向这个方向靠近。它支持张量并行、流水线并行配合 Ray 能跨机部署还能和常见的 Kubernetes 生态集成自动扩缩容。Ollama 这类工具本身不带这些能力。你也许可以压测单机上的 100 并发但千级并发必然是多机分布式架构的工程问题而 vLLM 正好是给这种架构准备的推理引擎。需要注意的是高并发不只是推理引擎一个环节的事情还涉及网络模型、连接管理、请求排队策略、限流熔断、监控告警等。所以不要指望引入 vLLM 就直接具备千级并发能力还需要完整的服务化架构配套。5. 选型建议不同场景下我建议怎么选5.1 什么时候无脑选 Ollama如果符合下面任意一条直接选 Ollama别折腾 vLLM本地开发、写 Demo、做原型验证只想快速跑通模型。单机使用并发量很小比如就是自己在终端里聊天或者接一个简单脚本。机器配置不是很好只有消费级显卡甚至只有 CPU希望自动量化、自动调度。不想维护 Python 环境和依赖希望模型下载、管理、服务全部开箱即用。想快速对比多个模型的效果Ollama 的ollama pull和标签管理非常方便。在这个范围内Ollama 是最省心的选择。我自己在做技术方案 Demo 验证时也会用 Ollama 来快速确认效果因为它不用我先写代码再搭服务。5.2 什么时候必须上 vLLM反过来出现这些情况就该认真考虑 vLLM模型要作为一个正式的 API 服务对外部系统提供有稳定的并发流量。你关心吞吐量、显存利用率、KV Cache 利用率这些指标。需要在多卡甚至多机环境下部署更大的模型比如 70B 及以上。要接入量化服务、前缀缓存、集群调度等生产级能力。你已经有模型权重希望完全控制服务的每一项配置。生产环境里vLLM 是更合适的选择。而且它提供 OpenAI 兼容接口迁移成本并不像想象中那么高。现有代码只需要改一下 base_url就能从调用云端 API 切换到调用本地 vLLM 服务。5.3 两者之外的思路实际工程里也不一定非要二选一。有人会在 Ollama 后面套一层自己的代理把请求转发到多个实例也有人先把 Ollama 用起来等并发上来了再平滑迁移到 vLLM。如果你既想要 Ollama 的易用性又想要更高的并发和调度能力可以观察生态环境的变化。此外像 HuggingFace 的 TGI、SGLang 等工具也提供了不同的取舍但核心问题始终只有一个你的场景是偏个人工具还是偏生产服务。想清楚这一点选型就不会翻车。6. 常见问题与避坑速查表6.1 Ollama 相关问Ollama 启动后端口被占用怎么办设置OLLAMA_HOST环境变量比如OLLAMA_HOST0.0.0.0:18000再把 API 地址改到对应端口即可。问模型下载到一半中断如何续传Ollama 默认支持断点续传重新执行ollama pull一般会从上次位置继续。但如果网络环境不稳定建议设一个较长的超时时间并保持终端会话不退出。问多个模型抢显存导致进程被杀设置OLLAMA_MAX_LOADED_MODELS1同时尽量只加载当前需要用的模型用完及时执行ollama stop。6.2 vLLM 相关问vLLM 启动时报 CUDA memory 不足先确认模型是量化版本还是 FP16 原版再调低--gpu-memory-utilization比如 0.8让 KV Cache 留出余量。如果还是不足只能换小模型或加卡。问并发高时出现 OOM增加--max-num-seqs限制单批最大序列数同时观察 KV Cache 的剩余情况。必要时降低--max-model-len给 KV Cache 腾空间。问首 token 延迟比预期高在低并发时去测首 token 延迟更有意义高并发下首 token 本身就会排队。如果首 token 延迟异常高优先检查 prompt 长度和前缀缓存是否命中。问多卡模型怎么跑启动时增加--tensor-parallel-size 2假设两张卡vLLM 会自动做模型并行切分。6.3 通用问题问选型之后还有必要做压测吗一定有必要。不压测永远不知道真实并发阈值。建议至少压三类场景并发请求数从低到高递增、超长输入并发、多轮对话长上下文并发。问模型量化会不会让效果变差太多看任务类型。一般闲聊和文档问答影响不大代码生成和数学推理可能有下降。如果需要精细效果建议在 FP16 和量化版本之间做效果对比不要盲信量化。最后的一点个人体会我自己在这两个工具上都踩过不少坑。最初图省事拿着 Ollama 直接部署到有线上流量的服务上结果压测时延迟暴涨后来换到 vLLM又因为不熟悉显存配置参数反复调--gpu-memory-utilization才找到平衡点。如果让我给一条最实用的建议先想清楚自己的场景到底是“自己用”还是“给别人用”。自己用Ollama 给你带来的幸福感是 vLLM 给不了的给别人用vLLM 的稳定性和吞吐能力也是 Ollama 短期追不上的。技术选型没有绝对的最优解只有最匹配当前阶段需求的答案。