vLLM
Apache-2.0 开源高吞吐推理引擎——PagedAttention 显存分页 + 连续批处理，一行命令起 OpenAI 兼容服务，吃满 GPU
要把开源权重变成「能扛流量的 API 服务」，vLLM 是当前默认答案。配合 LiteLLM 做统一网关 / 配合 Ollama 做本地轻量推理是最常见组合；想要零运维的托管推理走云厂商，想要单卡本机跑小模型走 Ollama。
TL;DR
vLLM 是当前开源生态吞吐量最高的 LLM 推理引擎——它不是「模型」，而是「跑模型的运行时」：你给它模型权重，它给你一个能扛并发的 API。最早由 UC Berkeley 团队提出，现归属 PyTorch Foundation，核心创新 PagedAttention 把 KV cache 当虚拟内存管，配合连续批处理（continuous batching）把 GPU 利用率从传统推理的 30-40% 拉到 70-80%+。Apache-2.0 协议，纯 Python + CUDA，部署在 Linux + NVIDIA GPU。
适合：需要对外提供 LLM API 服务、多用户并发、追求最大吞吐和最低延迟的工程团队，以及跑大规模 batch 离线推理的研究场景。不适合：单用户本地原型（用 Ollama 更轻量）、Mac M 系列（vLLM 对 Metal 支持有限）、没有 NVIDIA GPU 的环境、不想碰 Linux + CUDA 驱动的小团队。
核心能力
- PagedAttention：借鉴操作系统虚拟内存的分页机制管理 KV cache，消除碎片化，显存利用率提升 2-4 倍
- 连续批处理（Continuous Batching）：请求动态插入 / 弹出，不需要等整批完成，GPU 闲置接近为零
- 高吞吐：官方基准口径最高比 Hugging Face Transformers 高 24 倍（倍数随模型 / 硬件 / 批大小浮动，不给单一数字以免误导）
- 多接口兼容 Server：
vllm serve <model>一行起服务，原生兼容 OpenAI（/v1/chat/completions、/v1/responses、/v1/embeddings）、Anthropic（/v1/messages）与 Cohere（/v2/embed、/rerank）三套 API，客户端几乎不用改代码 - 多硬件后端：NVIDIA CUDA、AMD ROCm、Intel Gaudi、Google TPU、AWS Neuron、华为昇腾、寒武纪——一套引擎多硬件跑
- 量化支持：AWQ、GPTQ、FP8（H100/Ada）、INT8 KV cache，显存减半吞吐不掉
- 张量并行（Tensor Parallelism）：
--tensor-parallel-size N多卡切分，支持多 GPU 推理大模型 - 分布式部署：Ray 集群多节点推理，支持 pipeline parallelism
- LoRA 多租户：同时加载多个 LoRA adapter，单服务多模型，按请求路由
价格
| 档位 | 价格 | 说明 |
|---|---|---|
| Open Source | $0（Apache-2.0） | 引擎免费、商用无限制，成本只来自你自己的 GPU / 算力 |
| 托管推理 | 按云厂商计费 | 用云厂商的 vLLM 托管服务则走对方账单 |
引擎本身免费，真实成本在 GPU 时长与运维。一张 A100 80GB 云端按需约 $2-4/小时，跑 FP16 的 70B 模型需 2-4 张；自建机房摊薄后更便宜。价格为 2026-09 查询口径，可能变动。
体验与评测（资料整理）
说明：本节基于官方文档与公开评测整理，非本站独立实测环境，具体数据请以官方为准。 环境（撰写时参考）：4× A100 80GB + Llama-3-70B-Instruct（FP16），vLLM 0.29.x 系列（2026-09 最新为 v0.29.0，最新稳定版请以 vllm.ai 为准）。
亮点：
vllm serve meta-llama/Meta-Llama-3-70B-Instruct --tensor-parallel-size 4一行拉起，4 卡自动切分- 并发 64 用户，平均延迟 1.2s，吞吐稳定在 3200 tok/s，GPU 利用率 75-85%
- 同样硬件跑 HF Transformers + 默认 batching，吞吐仅 ~200 tok/s，差距 16 倍
- AWQ 量化版 70B 单卡 A100 即可跑，吞吐只掉 15-20%，显存从 140GB 降到 40GB
- OpenAI 兼容端点接 Cursor / Dify / FastGPT 零改动
- 连续批处理下短请求和长请求混合调度公平，没有长尾饿死
踩坑：
- 第一次启动要编译 CUDA kernel，冷启动 3-5 分钟，加
--enforce-eager可跳过但掉速 20% - KV cache 默认占 90% 显存，跑长上下文（32K+）要手动调
--gpu-memory-utilization 0.85留余量 - 旧版本对 Qwen2.5-VL 等多模态模型支持不稳定，偶发 OOM，建议查阅官方 issue 选择适配版本
- 国内 HuggingFace 下载模型慢，配
HF_ENDPOINT=https://hf-mirror.com或预下载到本地 --max-model-len必须设，否则默认按模型最大上下文分配，32B 模型 128K 上下文会直接 OOM
上手
- 环境准备：Linux + NVIDIA GPU（compute capability ≥ 7.0）+ CUDA 12.1+，推荐
uv pip install vllm --torch-backend auto（或pip install vllm） - 拉起服务：
vllm serve meta-llama/Meta-Llama-3-8B-Instruct --port 8000 - 测试调用：
curl http://localhost:8000/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"meta-llama/Meta-Llama-3-8B-Instruct","messages":[{"role":"user","content":"hi"}]}' - 多卡并行：加
--tensor-parallel-size 4（卡数） - 量化部署：
vllm serve TheBloke/Llama-2-13B-AWQ --quantization awq - 接入应用：任何 OpenAI SDK 改
base_url=http://localhost:8000/v1即用；Anthropic SDK 指向/v1/messages同样可跑
对比
| 维度 | vLLM | Ollama | TGI (HF) | TensorRT-LLM |
|---|---|---|---|---|
| 吞吐（A100 8B） | ~800-12500 tok/s | ~40 tok/s | ~500 tok/s | ~10000 tok/s |
| 上手门槛 | 中 | 极低 | 中 | 高 |
| PagedAttention | (v0.7+) | |||
| 连续批处理 | ||||
| OpenAI 兼容 | 需封装 | |||
| 多模态 | 部分 | 部分 | ||
| Mac 支持 | 有限 | MLX | ||
| 开源协议 | Apache 2.0 | MIT | HFOIL | Apache 2.0 |
国内使用注意事项
- vLLM 原生支持**华为昇腾（Ascend）/ 寒武纪（MLU）**等国产 NPU，是信创 / 国产算力自托管推理的常用底座。
- 中文模型权重（Qwen / Kimi / GLM / DeepSeek）都在官方支持列表，国内拉权重注意用镜像源加速。
- 文档以英文为主，中文社区资料丰富但需自行甄别版本。
避坑
- 冷启动慢不是 bug：首次编译 CUDA kernel 需要几分钟，生产环境用 Docker 镜像预编译或加
--enforce-eager（牺牲 15-20% 性能换即时启动） --max-model-len必设：不设会按模型最大上下文预分配 KV cache，小显存直接 OOM- 量化模型要匹配版本：AWQ 模型必须用
--quantization awq，GPTQ 用--quantization gptq，混用会报错或精度崩 - 别用
:latest上生产：发版快、偶有破坏性变更，固定到带版本号的 release（如 v0.29.x） - 不要在 Mac 上用 vLLM 跑生产：Metal 后端是实验性的，性能远不如 CPU，Mac 本地推理用 Ollama / MLX
- 监控 GPU 显存碎片：长跑后偶发显存碎片导致新请求 OOM，加
--gpu-memory-utilization 0.85留 buffer 或定期重启 - 多模态模型看版本：不同版本对 VLM 支持差异较大，新模型先查官方 issue 选适配版本
适合 / 不适合
- 生产级 LLM API 服务（多用户并发、高吞吐）
- 大规模离线 batch 推理（数据标注、合成数据生成）
- 需要最低成本跑大模型（量化 + 单卡部署 70B）
- 有 NVIDIA GPU + Linux 运维能力的工程团队
- 单用户本地原型 / 个人开发（用 Ollama，0 配置）
- Mac M 系列用户（Metal 支持有限，用 Ollama + MLX）
- 没有 GPU 的环境（vLLM 的 CPU 后端性能极差）
- 多模态 / 语音模型生产部署（支持不稳定，看具体版本）
FAQ
Q: vLLM 和 Ollama 怎么选？ A: Ollama 是 Daemon + CLI，单用户原型极简；vLLM 是推理服务器，多用户并发吞吐高 16-20 倍。个人用 Ollama，对外提供服务用 vLLM。
Q: 单卡能跑 70B 吗？ A: 可以。用 AWQ/GPTQ 4-bit 量化，70B 约需 35-40GB 显存，A100 80GB 或 2×A100 40GB 张量并行。FP16 则需 140GB（2×A100 80GB）。
Q: 和 TensorRT-LLM 比谁快？ A: TensorRT-LLM 在极致优化下略快（5-15%），但需要编译 engine、调试周期长、模型适配少。vLLM 灵活性和生态好得多，综合性价比更高。
Q: 支持 AMD GPU 吗？ A: 部分支持。0.5+ 起 ROCm 后端可用，但稳定性、性能、生态都远不如 NVIDIA CUDA。生产环境仍建议 NVIDIA。
相关阅读
- 本地轻量推理：Ollama
- 统一多厂商网关：LiteLLM
- 开源模型底座：DeepSeek-V4 / Qwen3 / Kimi K2.7 Code
- 架构科普：MoE（混合专家） / RAG
- 协议层：MCP
Long-tail quick picks
长尾检索速查：下面三项对应「vLLM 开源版 / 免费版 / 国内可用」等搜索意图，方便直接跳转。
Open-source alternatives
Free tier
China availability
相关替代品：
来源
本文的价格、版本号与性能数据均参考以下官方渠道整理，可能随时间变动，请以官方实时信息为准。
- · 需要对外提供 LLM API 服务、多用户并发的团队
- · 追求最大吞吐和最低延迟的工程团队
- · 跑大规模 batch 离线推理的研究场景
- · 多硬件（昇腾 / 天垓 / TPU / ROCm）自托管推理
- · 单用户本地原型 / 个人开发（用 Ollama 更轻量）
- · Mac M 系列用户（vLLM 对 Metal 支持有限，用 Ollama + MLX）
- · 没有 NVIDIA GPU、或不想碰 Linux + CUDA 驱动的小团队
不适合只想「本机跑个本地模型聊天」的纯交互用户——那条路用 Ollama 更省心
- 纯 CLI / Server，没有图形界面，新人要先理解引擎参数（tensor-parallel、gpu-memory-utilization）
- 大模型和长上下文对显存敏感，OOM 时调参门槛不低
- 发版快、偶有破坏性变更，生产务必固定版本号（如 v0.29.x）而非 :latest
可接入 / 兼容以下大模型 API（在设置中配置 key 即可切换底座）：