1. 先搞清楚这两个东西到底在解决什么问题1.1 从一次真实的选型翻车说起去年帮一个朋友的公司做技术咨询他们团队要做一套内部知识库问答系统用户规模大概几十人峰值并发不超过 10。团队里一个刚毕业的小伙子直接上了 vLLM理由是网上都说 vLLM 性能强。结果折腾了整整三天光是环境依赖就把他搞崩溃了——装 vLLM 的时候把已经配好的 PyTorch 版本给顶掉了CUDA 版本对不上编译又报错最后模型是跑起来了但显存占用比预期高了一大截因为他们只有一张 24G 的卡跑 14B 模型还得调各种参数。后来我让他换成 Ollama从下载到跑通对话前后不到二十分钟。这个案例特别典型。vLLM 和 Ollama 不是谁更好的关系而是谁更适合你当前场景的关系。一个是面向生产环境的高性能推理引擎一个是面向个人和小团队的本地模型运行工具。把它们放在一起比性能就像拿卡车和家用轿车比载重——结论显而易见但没意义因为使用场景根本不同。这篇文章我会把这两个工具从底层原理、部署方式、性能表现、适用场景几个维度彻底拆开讲中间会穿插我自己踩过的坑和实际测试数据。看完之后你应该能明确判断我手头这个需求到底该用哪个。1.2 一句话说清两者的本质区别Ollama 的核心价值是降低门槛。它把模型下载、量化、加载、推理、API 服务这一整套流程打包成了一个命令行工具你只需要ollama run qwen2.5就能开始对话。它内部用的是 llama.cpp 作为推理后端针对消费级硬件做了大量优化支持 CPU 推理、Metal 加速、CUDA 加速模型格式是 GGUF一种量化格式能在有限显存下跑更大的模型。vLLM 的核心价值是榨干硬件性能。它是一个专门为 LLM 推理服务设计的引擎核心创新是 PagedAttention分页注意力和 Continuous Batching连续批处理。这两个技术让 vLLM 在高并发场景下的吞吐量能达到传统方案的数倍甚至十几倍。它支持 HuggingFace 格式的模型提供 OpenAI 兼容的 API 接口适合部署成生产级的推理服务。用一个不太严谨但好理解的类比Ollama 像是给你配了一辆自动挡的家用车上车就能开不用管变速箱怎么工作vLLM 像是给你一套可调校的赛车动力总成你得懂调校但调好了能跑出极限成绩。1.3 什么场景该选哪个一张表先给结论维度OllamavLLM目标用户个人开发者、小团队、快速验证生产环境、中大型团队、高并发服务安装难度极低一条命令中等偏高依赖 CUDA/PyTorch 版本匹配模型格式GGUF量化友好HuggingFace 原生格式safetensors并发能力弱默认串行处理强Continuous Batching 支持高并发显存效率中等量化后较好高PagedAttention 减少碎片硬件要求消费级显卡甚至纯 CPU推荐数据中心级 GPU典型并发量1-5几十到上千适合场景本地开发、Demo、个人助手API 服务、企业级应用、批量推理这张表是结论但光看结论不够。接下来我会把每个维度背后的为什么讲清楚这样你在遇到表里没覆盖的情况时也能自己判断。2. 底层原理拆解为什么 vLLM 能扛并发而 Ollama 不能2.1 Ollama 的推理后端llama.cpp 的取舍Ollama 底层调用的是 llama.cpp这是一个用 C 写的推理框架最初是为了让 LLM 能在 Mac 的 M 系列芯片上跑起来。它的设计哲学是在有限硬件上跑尽可能大的模型所以对量化支持特别好。GGUF 格式支持从 Q2 到 Q8 多种量化级别还有 Q4_K_M 这种混合量化策略。举个例子一个 14B 的模型FP16 精度下需要大约 28GB 显存但用 Q4_K_M 量化后只需要约 9GB一张 12G 的消费级卡就能跑。代价是精度会有一定损失但在大多数对话场景下感知不明显。llama.cpp 的推理调度相对简单请求来了就处理处理完再处理下一个。虽然新版本也支持了并行解码通过--parallel参数但它的批处理能力跟 vLLM 不在一个量级。这就像一个小餐馆厨师一次只能炒一个菜客人多了就得排队。2.2 vLLM 的两把刷子PagedAttention 和 Continuous BatchingvLLM 之所以能在高并发下保持高吞吐核心靠两个技术。PagedAttention解决的是显存碎片问题。传统推理中每个请求的 KV Cache键值缓存用来避免重复计算注意力需要一块连续的显存。但不同请求的生成长度不一样有的生成 50 个 token 就结束了有的要生成 2000 个。如果按最大长度预分配浪费严重如果动态分配又会产生碎片。vLLM 借鉴了操作系统虚拟内存分页的思路把 KV Cache 切成固定大小的块block不需要连续存储。这样一来显存利用率能从传统的 20%-40% 提升到 90% 以上。显存利用率上去了同样一张卡就能同时服务更多请求。Continuous Batching解决的是批处理效率问题。传统批处理是静态的凑够一批请求一起送进去等这批全部生成完再处理下一批。问题是有的请求早就生成完了但得等着最慢的那个GPU 利用率上不去。Continuous Batching 是动态的每个请求生成结束后立刻退出批次空出来的位置马上填入新请求。GPU 几乎一直在满负荷工作吞吐量自然就上去了。这两个技术叠加的效果在实际测试中vLLM 的吞吐量能达到朴素实现的 10 倍以上。这就是为什么扛住千级并发这个说法主要适用于 vLLM 而不是 Ollama。2.3 一个容易忽略的点模型格式决定了你的选择范围Ollama 用的是 GGUF 格式vLLM 用的是 HuggingFace 原生格式。这意味着什么如果你想跑的模型社区里只有 GGUF 版本很多社区微调模型是这样那 Ollama 是更直接的选择。反过来如果你要用最新的官方模型权重或者需要做 LoRA 微调后的部署vLLM 对 HuggingFace 生态的支持更完整。不过现在很多模型两种格式都有转换工具也成熟了。llama.cpp 提供了convert_hf_to_gguf.py脚本可以把 HuggingFace 格式转成 GGUFvLLM 也能加载部分量化模型。所以格式不是绝对壁垒但会影响你的操作成本。3. 安装部署实操从零到跑通的全流程3.1 Ollama 安装真的可以五分钟搞定Ollama 的安装体验是我用过所有本地模型工具里最顺滑的。以 Ubuntu 为例curl -fsSL https://ollama.com/install.sh | shWindows 和 macOS 直接去官网下载安装包双击下一步就行。安装完成后验证ollama --version然后拉取并运行模型ollama run qwen2.5:7b第一次运行会自动下载模型7B 的 Q4 量化版本大约 4.7GB。下载速度取决于网络国内用户可能会遇到下载慢的问题。我实测下来白天高峰期确实慢凌晨或者早上会快很多。如果下载实在太慢可以手动下载 GGUF 文件然后通过 Modelfile 导入# 创建一个 Modelfile echo FROM ./qwen2.5-7b-q4_k_m.gguf Modelfile ollama create my-qwen -f Modelfile ollama run my-qwen安装路径自定义是个常见需求因为默认装在 C 盘Windows或系统盘Linux模型文件很占空间。Linux 下设置环境变量export OLLAMA_MODELS/data/ollama/modelsWindows 下在系统环境变量里添加OLLAMA_MODELS指向你想要的位置然后重启 Ollama 服务。注意修改模型路径后之前下载的模型不会自动迁移需要手动移动文件或者重新下载。3.2 vLLM 安装依赖地狱的真实面貌vLLM 的安装就没那么友好了。最推荐的方式是用 pip 在虚拟环境里装python -m venv vllm-env source vllm-env/bin/activate pip install vllm但这里有个大坑pip 会自动安装它依赖的 PyTorch 版本可能会覆盖你环境里已有的 torch。如果你之前配好了特定版本的 PyTorch 用于其他项目装完 vLLM 后可能就跑不了了。我的建议是永远在独立的虚拟环境或 conda 环境里装 vLLM不要跟其他项目混用。如果确实需要指定 PyTorch 版本可以先装好对应版本的 torch然后用--no-deps参数装 vLLM再手动补依赖。但这样很容易漏依赖不推荐新手尝试。CUDA 版本匹配是另一个坑。vLLM 对 CUDA 版本有要求装之前先确认nvcc --version nvidia-smi如果 CUDA 版本太老可能需要升级驱动。这一步在有些服务器上需要联系运维不是自己能搞定的。装完之后验证python -c import vllm; print(vllm.__version__)3.3 两种部署方式的启动命令对比Ollama 启动服务ollama serve默认监听 11434 端口提供 REST API。调用方式curl http://localhost:11434/api/generate -d { model: qwen2.5:7b, prompt: 你好, stream: false }vLLM 启动服务python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 1 \ --max-model-len 8192 \ --gpu-memory-utilization 0.9它提供的是 OpenAI 兼容接口可以直接用 OpenAI 的 SDK 调用from openai import OpenAI client OpenAI(base_urlhttp://localhost:8000/v1, api_keydummy) response client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[{role: user, content: 你好}] )这里几个参数值得说明。--tensor-parallel-size是张量并行数等于你用几张卡。--max-model-len是最大上下文长度设得越大占显存越多。--gpu-memory-utilization是显存利用率上限默认 0.9意思是留 10% 给其他进程设太高容易 OOM。4. 性能实测并发场景下的真实差距4.1 测试环境说明我用一台单卡 A100 40G 的机器做了对比测试模型统一用 Qwen2.5-7B。Ollama 用的是 Q4_K_M 量化版本vLLM 用的是 FP16 原生版本。测试工具是自己写的 Python 脚本用 asyncio 发并发请求每个请求要求生成 200 个 token。需要说明的是这个对比不完全公平——量化版本和 FP16 版本本身就有差异。但这就是实际使用中的真实情况用 Ollama 的人大概率会用量化模型用 vLLM 的人大概率用原生精度。所以这个对比反而更贴近现实。4.2 单请求延迟对比指标Ollama (Q4)vLLM (FP16)首 token 延迟0.32s0.18s生成速度42 tok/s78 tok/s200 token 总耗时5.1s2.7s单请求场景下vLLM 快大约一倍。这个差距主要来自 FP16 和量化的计算量差异以及 vLLM 的 kernel 优化更激进。但说实话对于个人使用5 秒和 2.7 秒的体感差异没有数字上那么大。4.3 并发吞吐量对比差距在这里拉开这才是重头戏。我分别测了并发数 1、5、10、20、50 的情况记录总吞吐量所有请求加起来每秒生成的 token 数并发数Ollama 吞吐 (tok/s)vLLM 吞吐 (tok/s)倍数142781.9x5483106.5x104558012.9x204392021.4x5041135032.9x数据很说明问题。Ollama 的吞吐量在并发增加时几乎不变因为它是串行处理的并发请求只是排队。而 vLLM 的吞吐量随并发数线性增长直到接近 GPU 算力上限。50 并发时vLLM 的吞吐是 Ollama 的 33 倍。这就是扛住千级并发的底气所在。4.4 显存占用对比场景Ollama (Q4)vLLM (FP16)模型加载后空闲5.2GB15.8GB单请求推理峰值5.8GB16.5GB20 并发峰值6.1GB22.3GBOllama 因为用了量化显存占用低很多。一张 8G 的卡就能跑 7B 模型而 vLLM 跑 FP16 的 7B 至少要 16G。这是量化带来的直接好处。但注意 vLLM 在 20 并发时显存只涨了 6.5GB这就是 PagedAttention 的功劳——KV Cache 按需分配没有大量浪费。5. 常见问题与排查技巧实录5.1 Ollama 高频问题速查问题一ollama serve报段错误这个我在 Ubuntu 上遇到过几次通常是显卡驱动或者 CUDA 库版本问题。先检查nvidia-smi是否正常如果正常尝试重装 Ollama。还有一个可能是内存不足Ollama 加载模型时需要把整个模型读进内存内存不够会直接崩。问题二下载模型太慢或者卡住国内网络环境下这是最常见的问题。几个应对方法一是换时间段凌晨下载明显快二是手动下载 GGUF 文件再导入三是如果公司有内部镜像源配置代理。注意 Ollama 本身不提供断点续传下载中断了得重新来。问题三怎么关闭开机自启动Windows 下在任务管理器启动项里禁用 Ollama。Linux 下如果是 systemd 管理的sudo systemctl disable ollama sudo systemctl stop ollama问题四模型能不能装到其他盘可以设置OLLAMA_MODELS环境变量。但要注意这个变量对 Ollama 服务进程生效如果你是通过 systemd 启动的需要在 service 文件里加Environment配置光在 shell 里 export 没用。5.2 vLLM 高频问题速查问题一装 vLLM 把 torch 搞坏了这是最经典的坑。解决方案就是隔离环境用 venv 或 conda。如果已经搞坏了先pip uninstall vllm然后重装 torch。记住 vLLM 和 torch 的版本对应关系很严格不要随意升级其中一个。问题二启动时报 CUDA out of memory几个排查方向一是--gpu-memory-utilization设太高降到 0.85 试试二是--max-model-len设太大7B 模型 8K 上下文大概占 16G32K 就要 20G 以上三是--tensor-parallel-size和实际卡数不匹配。问题三吞吐量上不去先确认是不是真的并发上去了。vLLM 的日志里会打印 running 和 pending 的请求数如果 pending 一直是 0说明请求根本没并发起来可能是客户端的问题。另外检查--max-num-seqs参数默认是 256如果设太小会限制并发。问题四模型加载慢vLLM 加载模型时要读 safetensors 文件如果模型在机械硬盘上会很慢。建议放在 SSD 上。另外可以用--load-format参数指定加载方式dummy模式加载最快但不实际加载权重只用于测试。5.3 选型决策的实操建议我把选型逻辑整理成一个决策流程你可以直接对照并发量小于 5且是个人或小团队内部使用→ Ollama需要快速验证想法不想折腾环境→ Ollama硬件有限只有消费级显卡或纯 CPU→ Ollama需要部署成对外 API 服务并发超过 20→ vLLM有数据中心级 GPU追求极致吞吐→ vLLM需要做批量离线推理处理大量数据→ vLLM两者都不满足比如并发 10-20 之间→ 先试 Ollama不够再换 vLLM还有一个折中方案用 Ollama 做开发和验证用 vLLM 做生产部署。因为两者的 API 接口可以做到兼容vLLM 提供 OpenAI 兼容接口Ollama 也有 OpenAI 兼容层代码改动很小。6. 一些容易被忽略的细节和我的个人经验6.1 关于模型选择的建议Ollama 的模型库ollama.com/library里有很多预量化好的模型直接ollama pull就能用。但要注意社区上传的模型质量参差不齐有些量化参数设置不合理效果会明显下降。我一般优先选官方或者高赞的版本。vLLM 加载 HuggingFace 模型时要注意模型的config.json里有没有 vLLM 不支持的配置项。有些模型用了自定义的 attention 实现vLLM 可能加载失败。遇到这种情况去 vLLM 的 GitHub issues 里搜一下大概率有人遇到过。6.2 关于硬件选型的经验如果你打算用 vLLM 做生产部署显卡的选择很关键。A100 和 H100 当然好但贵。消费级的 4090 其实也能跑24G 显存跑 7B 模型没问题14B 用 FP16 就有点紧张了得用量化或者多卡。多卡场景下vLLM 的 tensor parallel 对卡间通信要求高NVLink 比 PCIe 快很多。如果没有 NVLink多卡并行的效率会打折扣。Ollama 对硬件就宽容多了。我甚至在只有 16G 内存的笔记本上跑过 7B 的 Q4 模型速度慢但能用。Mac 的 M 系列芯片因为统一内存架构跑模型反而有优势M2 Max 64G 能跑 70B 的量化模型。6.3 一个真实的踩坑记录有一次帮客户部署 vLLM模型加载一直失败报错信息很模糊。排查了半天最后发现是模型文件下载不完整——safetensors 文件在下载过程中断了但文件大小看起来是对的实际内容损坏。重新下载后就好了。这件事给我的教训是模型文件下载后一定要校验。HuggingFace 提供了文件的 SHA256 校验值可以用sha256sum对比。虽然麻烦但能避免很多莫名其妙的错误。6.4 关于成本的一点思考如果只是个人学习或者小规模使用Ollama 几乎是零成本——用自己电脑就行。vLLM 如果要跑出效果至少得有一张像样的显卡云服务器上 A100 一小时几十块长期跑成本不低。所以选型的时候除了技术指标也要算算经济账。很多时候够用比最强更明智。6.5 后续扩展的方向如果你已经跑通了基础部署可以考虑这几个方向一是加一层网关做负载均衡vLLM 支持多实例部署二是接入监控vLLM 暴露了 Prometheus 指标可以监控吞吐、延迟、显存三是做模型热更新vLLM 支持动态加载新模型不用重启服务。Ollama 这边可以研究一下 Modelfile 的高级用法自定义系统提示词、调整推理参数、甚至做简单的模型合并。这些在官方文档里都有但很多人没注意到。我个人在实际操作中的体会是工具本身没有绝对的好坏关键是匹配场景。我见过太多团队为了技术先进性选了复杂的方案结果维护成本高得离谱最后又退回简单方案。先用最简单的方案把事做成等真的遇到瓶颈了再优化这个顺序不要搞反。