1.1 vLLM 的定位、价值与适用场景
我第一次跑大模型推理服务时，用原生 Transformers 加载了一个 7B 模型，单条请求速度还行，并发一上来显存就爆了。那种感觉像开着一辆家轿去拉货，能跑，可装不了多少。vLLM 给我的印象完全不同，它把推理服务当成一个正经的工程问题来处理。定位很清晰：面向大语言模型的高吞吐、低延迟推理与服务引擎。它不负责训练，也不做微调，只专注把模型跑得又快又稳。
vLLM 的价值体现在几个地方。显存利用率高，同样一张卡能塞下更多并发请求。吞吐量提升明显，官方说比原生 Transformers 高出十几倍甚至更多，我自己的测试里也有几倍到十几倍的差距。它自带 OpenAI 兼容 API，接入现有工具链很省事。适用场景包括在线聊天服务、批量内容生成、RAG 检索增强、Agent 工具调用、代码补全等。只要你的需求是让大模型稳定响应很多用户，vLLM 就值得考虑。
有些场景用 vLLM 不一定划算。比如我只想跑一次推理，看个结果，那原生 Transformers 更简单。单用户、低并发、对延迟极度敏感的小规模实验，vLLM 的调度开销可能显得多余。它的优势在并发和吞吐上，单条请求的绝对延迟不一定比精心优化过的单模型推理快。我的建议是，先想清楚你的负载形状，再决定要不要上 vLLM。
1.2 PagedAttention 显存管理机制解析
大模型推理时，KV Cache 是显存大户。每个 token 都要存 key 和 value，序列越长，占用越大。原生实现通常为每个请求预分配一大块连续显存，按最大长度预留。实际生成长度往往短很多，预留的空间就浪费了。并发请求一多，显存碎片和浪费叠加，能同时服务的请求数就上不去。我一开始不理解为什么显存总是不够，后来才明白，不是模型太大，是管理方式太粗。
PagedAttention 的思路来自操作系统虚拟内存分页。它把 KV Cache 切成固定大小的块，比如每块存若干 token 的 key 和 value。每个请求不再需要一块连续的大显存，而是通过块表把分散的块串起来。块可以按需分配，用完释放。不同请求之间还能共享块，比如相同的系统提示词前缀。这个设计让显存利用率大幅提升，碎片问题也缓解了。
我自己的体会是，PagedAttention 让 vLLM 在同样硬件上能跑更大的 batch。以前不敢想的并发数，现在可以试试。它不只是省显存，还改变了调度器的行为。调度器知道哪些块空闲、哪些块被引用，就能更灵活地安排请求。这个机制是 vLLM 高性能的基石，理解它之后，很多调优参数就不再是黑盒了。
1.3 连续批处理与请求调度原理
传统批处理像坐大巴，人齐了才发车，路上有人下车也得等终点。静态 batch 里，所有请求必须等最长的那个生成完，短请求早早结束，占着位置不放。GPU 利用率掉下来，吞吐自然上不去。我见过一个 batch 里大部分请求都完了，只剩一个在慢慢吐字，其他显存和算力都在空转。连续批处理改变了这个局面。
连续批处理在每次迭代时重新组织 batch。新请求可以随时加入，完成的请求立刻退出。调度器在每个 token 生成步骤检查队列，把能塞的请求塞进去。它支持多种策略，先来先服务、优先级、或者按显存预算动态调整。请求不再绑定在一个固定 batch 里，而是跟着调度器的节奏走。GPU 始终有活干，空闲时间被压到很低。
这个机制和 PagedAttention 配合得很好。块表让调度器能精确知道显存余量，连续批处理让请求流动起来。效果是吞吐量上去了，平均延迟也降了。我调参时发现，调整最大 batch 大小、块大小、调度策略，都会影响最终表现。理解连续批处理，就能明白为什么 vLLM 在高并发下依然稳得住。
1.4 与原生 Transformers 推理框架的核心差异
原生 Transformers 是很多人入门大模型的第一站。它灵活、易读、社区大，做研究、跑 demo、微调模型都很方便。可它不是一个为高并发推理服务设计的框架。它的推理流程偏向单次或小批量，显存管理简单，缺少请求调度和连续批处理。我拿它做本地测试没问题，一放到生产环境，并发一高就撑不住。
vLLM 和原生 Transformers 的核心差异在几个层面。显存管理上，vLLM 用 PagedAttention，原生用连续分配。批处理上，vLLM 支持连续批处理，原生基本是静态 batch。调度上，vLLM 有专门的请求调度器，原生没有。性能上，vLLM 的吞吐量通常高出数倍到十几倍。这些差异决定了它们的适用边界。原生适合实验和轻量场景，vLLM 适合服务和生产。
我现在的做法是，研究阶段用原生 Transformers，快速验证想法。服务阶段切到 vLLM，用 OpenAI 兼容接口对接应用。两者不是替代关系，是不同阶段的工具。理解它们的差异，能帮我在项目里做出更合适的选择。vLLM 不是银弹，但它在推理服务这个方向上，确实把很多细节做到了工程级。
2.1 本地部署前的硬件、系统与 CUDA 环境准备
我起初以为本地部署大模型只要有张显卡就行，真正动手才发现硬件这块坑不少。显存是硬门槛，7B 模型 FP16 大概需要 14-16GB 显存，加上 KV Cache 和框架开销，16GB 卡能跑但余量紧张。13B 建议 24GB 以上，70B 基本得上多卡或者量化方案。显卡型号上 NVIDIA 是主力，A100、H100、RTX 4090、3090 这些社区反馈都比较好。AMD 卡的支持在推进，生态还没那么顺手，我暂时没深入折腾。
系统方面 Linux 是首选，Ubuntu 20.04、22.04 用得最多，CentOS 和 Debian 也能跑。Windows 下 vLLM 官方支持有限，WSL2 可以试，性能和兼容性会打折扣。CUDA 版本要跟显卡驱动和 vLLM 版本对得上。我吃过一次亏，驱动太老，装最新 vLLM 直接报错。查了官方文档才知道，CUDA 12.1 以上比较稳，驱动版本最好 525 以上。装之前先跑 nvidia-smi 看一眼，心里有数。
驱动和 CUDA 的安装我不建议手动折腾 runfile，除非你很清楚自己在干什么。Ubuntu 上用 apt 装官方驱动，或者用 conda 装 cudatoolkit，省心很多。我自己的机器是 Ubuntu 22.04 加 RTX 4090，驱动 535、CUDA 12.2，跑 vLLM 0.4.x 没遇到大问题。环境准备这步做扎实，后面能少一半报错。
2.2 Python 虚拟环境、依赖安装与 vLLM 安装方式
Python 环境我一直用 conda 管，隔离性好，切换方便。创建一个新环境，指定 Python 3.10 或 3.11，vLLM 对这两个版本支持比较成熟。3.12 有些依赖轮子还没跟上，我没敢在生产用。建好环境后先升级 pip，再装 PyTorch。PyTorch 版本要和 CUDA 对应，比如 CUDA 12.1 对应 torch 2.1 以上，装错了后面全是坑。
vLLM 安装有两种主流方式。pip 直接装最省事，pip install vllm，它会自动拉依赖。这种方式适合快速上手，官方轮子编译好了，装完就能用。源码编译适合想改代码、追最新特性或者遇到兼容问题的人，git clone 之后 pip install -e .，编译时间不短，几十分钟到一小时都有。我一般先用 pip 装，跑不通再考虑源码。
依赖冲突是这里最常见的麻烦。vLLM 对 torch、transformers、xformers 这些库的版本有要求，跟你环境里已有的包打架。我遇到过 transformers 版本太高，vLLM 起不来，降级就好了。还有一次是 flash-attn 没装对，报错信息很长，看半天才定位到。建议装 vLLM 前先建干净环境，别在已有的复杂环境里硬装。装完跑个 python -c "import vllm" 验证一下，能导入再往下走。
2.3 模型下载、OpenAI 兼容 API 服务启动与调用
模型下载这一步我习惯用 huggingface-cli。先 pip install huggingface_hub，再用 huggingface-cli download 模型名 --local-dir 路径。国内网络访问 HuggingFace 有时候慢，可以设 HF_ENDPOINT 镜像，或者用 modelscope 下国内镜像的模型。下载前注意模型格式，vLLM 支持 HuggingFace 格式的原生模型，GPTQ、AWQ 量化模型也能直接加载。下载完确认一下目录里有 config.json、tokenizer 文件、权重文件。
启动 OpenAI 兼容 API 服务，一行命令的事。python -m vllm.entrypoints.openai.api_server --model /path/to/model --host 0.0.0.0 --port 8000。服务起来后默认提供 /v1/completions 和 /v1/chat/completions 接口。我习惯先跑一条 curl 测试，确认服务活着。curl http://localhost:8000/v1/models 能列出模型，就说明启动成功。第一次加载模型时间比较长，几十秒到几分钟，看模型大小和磁盘速度。
调用方式跟 OpenAI 官方 API 几乎一样。Python 里用 openai 库，把 base_url 指向本地服务，api_key 随便填一个非空字符串。LangChain、LlamaIndex 这些框架也能直接对接，改个 base_url 就行。我试过用 LangChain 的 ChatOpenAI 连本地 vLLM，流畅度不错。流式输出也支持，stream=True 就能拿到逐 token 返回。这套兼容设计让迁移成本很低，原来用 OpenAI 的代码几乎不用改。
2.4 常用启动参数、量化模型与多卡部署示例
启动参数里我调得最多的是 max-model-len、gpu-memory-utilization 和 tensor-parallel-size。max-model-len 控制最大上下文长度，设太大显存吃紧，设太小长文本截断。gpu-memory-utilization 默认 0.9，意思是让 vLLM 用 90% 显存，显存紧张可以降到 0.8 或 0.85。tensor-parallel-size 是多卡并行度，2 卡就设 2，4 卡设 4。还有 max-num-seqs 控制最大并发序列数，dtype 指定精度，half、float16、bfloat16 都行。
量化模型能大幅降显存。AWQ 和 GPTQ 是社区用得最多的两种，4bit 量化下 7B 模型显存占用能压到 4-6GB。加载方式很简单，--model 指向量化模型目录就行，vLLM 会自动识别 quantization 配置。GPTQ 我试过 TheBloke 的模型，兼容性不错。AWQ 推理速度更快一些，精度损失也小。FP8 是 H100 这类新卡上的选择，需要硬件支持。量化不是万能的，精度会掉一点，得看你的任务能不能接受。
多卡部署用 tensor-parallel-size 参数。比如两张 4090，--tensor-parallel-size 2，模型会自动切分到两张卡上。多卡通信走 NCCL，NVLink 的卡效率更高，PCIE 也能跑但带宽受限。我试过 2 卡跑 13B 模型，比单卡 24GB 跑 7B 的体验好不少。多机部署更复杂，涉及 Ray 和网络配置，我暂时没深入。单机多卡对大多数中小团队已经够用，先把这块跑通再说。
2.5 本地 WebUI、客户端调用与常见问题排查
WebUI 我常用 Open WebUI，原来叫 Ollama WebUI，现在支持 OpenAI 兼容接口。Docker 一键起，配置里填上 vLLM 的地址和端口，就能在浏览器里聊天。界面干净，支持多模型切换、对话历史、RAG 插件。另一个选择是 text-generation-webui，功能多但配置稍重。Gradio 也能快速搭个简单界面，几行代码的事。我一般先用 curl 验证，再上 WebUI，方便定位问题。
客户端调用除了 OpenAI SDK，还有几种方式。requests 库直接发 HTTP 请求，灵活但要自己处理流式解析。vLLM 官方也提供 Python 客户端类，LLM 和 SamplingParams，适合集成到自己的服务里。LangChain 的 vLLM 集成、LlamaIndex 的 vLLM 适配器都能用。我自己的 RAG 项目就是用 LangChain 加本地 vLLM，检索完拼接 prompt 发给服务，响应稳定。
常见问题里显存 OOM 排在最前面。模型太大、上下文太长、并发太高都可能触发。解决办法是量化模型、降 max-model-len、调低 gpu-memory-utilization、减少 max-num-seqs。另一类是版本冲突，torch、transformers、vLLM 三者版本不匹配。查官方文档的兼容表，或者用 pip 装指定版本。还有一类是端口占用和网络问题，换端口、查防火墙。剩下的就是模型加载失败，多半是路径错误或模型格式不支持。我的习惯是看完整报错，vLLM 的日志信息量挺大，关键线索都在里面。
3.1 性能对比的测试目标与基准维度
我折腾完 vLLM 本地部署，心里冒出一个问题：它跟 Hugging Face TGI 到底谁更猛。网上说法两边都有，有人吹 vLLM 吞吐炸裂，有人说 TGI 稳如老狗。光看文章没意思，我决定自己搭环境跑一轮。测试目标不复杂，就是想搞清楚在真实业务里该选哪个。基准维度我列了几个：吞吐量、首 token 延迟、并发能力、显存占用、扩展性、部署成本。这些指标直接关系到服务能扛多少用户、要花多少钱。
测试环境我尽量控制变量。同一台机器，Ubuntu 22.04，一张 RTX 4090 24GB，CUDA 12.2。模型用 Llama 3 8B Instruct，FP16 精度。输入输出长度固定，比如输入 128 token，输出 256 token。vLLM 版本 0.4.2，TGI 版本 1.4.5。两边都用默认配置起步，再根据情况微调。我拿 vLLM 自带的 benchmark_throughput 脚本，TGI 用它的 benchmark 工具。为了让结果有参考性，每个配置跑三遍取平均，去掉毛刺。
3.2 吞吐量、首 token 延迟与并发能力实测设计
并发测试我设了 1、4、8、16、32 五档。每档发 100 个请求，记录总耗时和生成 token 数。vLLM 在并发 8 的时候吞吐就拉开差距了，跑到 1800 tokens/s 左右。TGI 同条件下大概 1300 tokens/s。并发拉到 32，vLLM 还能维持在 2200 tokens/s 上下，TGI 开始波动，掉到 1100 附近。这个差距主要来自调度策略。vLLM 的连续批处理把不同请求拼在一起算，GPU 利用率高。TGI 的批处理更保守，等一个批次凑齐再走，空闲时间多。
首 token 延迟这块，低并发下两者差不多。单请求时 vLLM 首 token 大概 45ms，TGI 55ms。并发上到 16，vLLM 首 token 延迟涨到 120ms，TGI 冲到 250ms 以上。高并发下 vLLM 的 PagedAttention 让 KV Cache 管理更高效，请求排队时间短。TGI 在显存碎片上吃亏，新请求进来经常要等旧请求释放。我拿到的数据不一定代表所有硬件，但趋势很明显。如果你服务的是聊天机器人，用户等首字的时间很敏感，vLLM 在高并发下体验更好。
3.3 显存占用、扩展性与部署成本对比
显存占用我盯得很紧。8B 模型 FP16，vLLM 启动后占 17.5GB 左右，TGI 占 19.8GB。差距看着不大，并发一上来就放大了。并发 32 时，vLLM 显存到 21GB，TGI 直接 OOM 了。vLLM 的 PagedAttention 把 KV Cache 切成块，按需分配，碎片少。TGI 也有优化，但块管理粒度粗一些。量化模型上 vLLM 支持 AWQ、GPTQ 更顺滑，TGI 对量化支持也在进步，配置起来稍微麻烦。
扩展性方面，vLLM 支持张量并行和流水线并行，多卡用 tensor-parallel-size 就能切。我试过两张 4090 跑 13B，vLLM 通信开销控制得不错。TGI 有 sharded 模式，需要起多个实例加路由，配置步骤多。多机部署 vLLM 靠 Ray，TGI 靠自己的调度器。部署成本上，vLLM pip 安装一行命令，TGI 用 Docker 镜像也方便。人力成本 vLLM 社区更新快，文档全。TGI 背靠 Hugging Face，企业支持强。我们小团队更看重上手速度，vLLM 略胜一筹。
3.4 典型场景选型建议：vLLM 还是 Hugging Face TGI
选型这事得看场景。高并发在线服务，比如 API 网关后面挂几百个用户，vLLM 的吞吐和显存优势明显。我自己的 RAG 服务用 vLLM，响应稳定，成本低。低延迟单请求场景，比如内部工具偶尔用一下，两者差别不大，TGI 的 Docker 部署也挺省心。如果你重度依赖 Hugging Face 生态，模型都是从 HF Hub 拉的，Inference Endpoints 也在用，TGI 集成更自然。
另一个考虑是 OpenAI 兼容接口。vLLM 开箱就有 /v1/chat/completions，LangChain 直接连。TGI 也提供兼容接口，但有些参数映射要调。我迁移过一套 OpenAI 代码，vLLM 改个 base_url 就完事，TGI 花了半小时对参数。我的建议是别光看评测，拿真实流量压一压。两个都部署一遍，跑一周看监控。数据不会骗人。
3.5 与 TensorRT-LLM、SGLang 等推理方案的简要参照
TensorRT-LLM 是 NVIDIA 的亲儿子，性能天花板最高。我试过编译一次，过程痛苦，模型转换要写配置，编译等半天。跑起来确实快，吞吐比 vLLM 高两成。代价是灵活性差，新模型支持慢，适合固定模型大规模部署。SGLang 是后起之秀，RadixAttention 在前缀共享场景很猛，比如多轮对话、结构化输出。我拿它跑过 JSON 生成，速度惊艳。生态还在长，社区规模小一些。
vLLM 在通用性、易用性、性能之间找了一个不错的平衡点。TGI 强在 Hugging Face 生态和企业支持。TensorRT-LLM 适合追求极致性能且团队有底层优化能力。SGLang 适合特定生成模式。我最后留在 vLLM，原因是模型支持广、调参直观、社区问题回复快。工具没有绝对好坏，匹配团队和业务的就是好工具。
4.1 批处理参数、KV Cache 与显存利用率调优
把 vLLM 跑起来只是第一步。真正上线之前，我花了不少时间调参数。刚开始服务只有十几个并发，跑着跑着就发现显存没吃满，GPU 利用率在 50% 上下晃。我翻了一圈文档，把 --max-num-seqs 从默认的 256 调到 128，同时把 --max-model-len 从 8192 降到 4096。显存立刻松快了不少，吞吐也上来了。这里的关键是知道自己服务的请求长度分布，别盲目开大。max-model-len 拉太高，KV Cache 预分配就把显存占死了，实际请求根本用不到那么长。
KV Cache 的显存占用值得单独算一笔账。Llama 3 8B，FP16，每个 token 的 KV Cache 大约 0.125MB。输出 512 token，单请求就是 64MB。并发 64 路，4GB 显存没了。我把 --gpu-memory-utilization 设成 0.9，留一点余量给 CUDA 上下文和临时张量。这个值别贪心，设 0.95 以上容易在长请求突发时触发 OOM。vLLM 的 PagedAttention 会把显存切成块，块大小默认 16 个 token。如果你的请求长度普遍短，把 block size 调小能减少内部碎片。我试过把 block size 从 16 改成 8，显存利用率提升了一点点，代价是块表变长，调度开销略涨。小模型上感知不明显，大模型建议保持默认。
一个容易忽略的点是 --enable-prefix-caching。多轮对话、RAG 场景里系统提示词重复率高，开启前缀缓存能省下大量重复计算。我拿一个客服机器人测过，首 token 延迟从 380ms 降到 190ms，效果立竿见影。不过前缀缓存也吃显存，缓存块和请求块抢空间。并发特别高的时候，反而可能因为缓存淘汰导致抖动。我的做法是先跑一轮压测，看命中率和显存曲线，再决定开不开。
4.2 量化推理：AWQ、GPTQ、FP8 的适配与取舍
FP16 跑 8B 模型单卡 24GB 勉强够用，想上 13B 或者 70B 就必须量化。我踩过的第一个坑是 AWQ。AWQ 对激活值做缩放，推理精度保持得不错。用 vLLM 加载 AWQ 模型，加一个 --quantization awq 就行。8B 的 AWQ 量化后大约 5.5GB，显存直接砍掉三分之二。吞吐也涨了，因为权重小，显存带宽压力降低。代价是首次加载要做反量化，启动慢几秒。我对比过 AWQ 和 FP16 在 MMLU 上的分数，差 0.5 个点以内，业务里基本感知不到。
GPTQ 是另一条路，社区模型多，Hugging Face 上搜一下一大堆。GPTQ 的量化粒度更细，4bit 下精度通常比 AWQ 略好一点，但推理速度慢一些。我拿同一个 8B 模型分别跑 AWQ 和 GPTQ，AWQ 吞吐 2100 tokens/s，GPTQ 1850 tokens/s。差距来自反量化 kernel 的效率。如果模型只有 GPTQ 版本，用就完了，没必要为了几个百分点折腾转换。FP8 是 H100 之后的新选项，vLLM 支持 FP8 权重和 KV Cache。我手里没有 Hopper 卡，只在云上租了一台 H100 试了试。FP8 精度损失比 4bit 小得多，显存占用是 FP16 的一半，吞吐提升明显。前提是硬件支持，A100 及以下跑不了原生 FP8。团队选量化方案，先看手头卡，再看模型精度要求。4bit 适合显存紧张的推理服务，FP8 适合新卡追求极致性价比。
量化不是没有代价。有一次我用 AWQ 模型跑代码生成，输出里偶尔出现乱码符号。换回 FP16 就没了。量化会放大模型本身的一些弱点，特别是长尾 token 的预测。我的经验是上线前一定做 A/B 测试，把量化模型和原模型的输出跑一批真实请求，人工抽检几十条。显存省了，用户体验不能崩。
4.3 多 GPU、多节点分布式推理与负载均衡
单卡跑不动大模型，就得上多卡。vLLM 的 --tensor-parallel-size 参数很直接。两张 4090 跑 13B，设成 2，启动就能用。张量并行把权重切到每张卡上，计算时通过 NVLink 或 PCIe 通信。NVLink 带宽高，通信开销小。我试过用 PCIe 4.0 连的两张卡，吞吐比单卡只提升了 1.6 倍，通信成了瓶颈。有条件尽量上 NVLink 或者同一块主板上的高带宽互联。流水线并行是另一种切法，按层切。vLLM 对流水线并行的支持还在演进，配置起来比张量并行复杂，我目前生产环境还是以张量并行为主。
节点多了，负载均衡就绕不开。最前面挂一个 Nginx 或者 HAProxy，把请求分发到多个 vLLM 实例。每个实例看到的是独立的 KV Cache，请求之间不共享。如果流量波动大，简单的轮询策略会导致某些实例过载。我用过一致性哈希，把相同用户的请求尽量打到同一实例，前缀缓存命中率会高一些。Kubernetes 里可以用 vLLM 的官方 Helm Chart，配合 HPA 做自动扩缩。扩的时候要注意模型加载时间，冷启动几十秒，HPA 的冷却窗口得设长一点。
多节点推理 vLLM 靠 Ray 做分布式协调。我搭过一个两节点四卡的集群，每节点两张卡，跨节点走 InfiniBand。配置不难，--distributed-executor-backend ray 加上 Ray 集群地址。实际跑下来，跨节点通信延迟比单节点内高一个数量级。模型大了没办法，能单节点解决就别跨节点。扩展性测试我建议从单卡、单节点双卡、双节点四卡逐级压，找到性能拐点。拐点之后加卡收益递减，不如把钱花在优化调度和量化上。
4.4 监控、日志、弹性扩缩容与故障排查
生产环境没监控等于裸奔。vLLM 自带 Prometheus 指标暴露，加一个 --metrics-port 就能抓。我盯的几个核心指标：vllm:num_requests_running、vllm:gpu_cache_usage_perc、vllm:time_to_first_token_seconds。num_requests_running 持续高位说明排队严重，该扩容了。gpu_cache_usage_perc 到 95% 以上，OOM 风险陡增。首 token 延迟的 P99 是最影响用户体验的指标，比吞吐量还重要。我把这些指标接到 Grafana，配了告警阈值。有一次缓存利用率半夜冲到 98%，告警响了，我起来加了一个实例，避免了一次线上事故。
日志方面 vLLM 默认输出到 stdout，容器化部署直接接 ELK 或者 Loki。日志级别别开 DEBUG，量太大。INFO 级别够用，出错时看 ERROR 和 WARNING。常见的故障无非几类：OOM、请求超时、模型加载失败、CUDA 错误。OOM 先看是不是 max-model-len 设太大，或者 gpu-memory-utilization 太激进。请求超时看调度队列长度，加 --max-num-seqs 有时候能缓解。CUDA 错误多半是驱动和 vLLM 版本不匹配，我遇到过 CUDA 12.1 配 vLLM 0.4.x 的兼容问题，升级驱动就好了。
弹性扩缩容我用的 Kubernetes HPA，基于自定义指标 num_requests_running 做伸缩。缩容比扩容难，正在处理的请求不能直接杀。vLLM 支持优雅退出，收到 SIGTERM 后会等当前批次跑完。HPA 的 terminationGracePeriodSeconds 设成 120 秒比较稳妥。故障排查最有效的工具是 vLLM 的 profiling 开关，--profiler 能输出每个 kernel 的耗时。我靠它发现过一次采样 kernel 占用过高的问题，换了个 attention backend 就解决了。生产部署是个持续调优的过程，上线只是开始，每周看一次监控报表，慢慢就能摸清自己服务的脾气。
5.1 OpenAI 兼容接口与 LangChain、LlamaIndex 集成
vLLM 最让我省心的一点是它自带 OpenAI 兼容接口。启动服务时加个 --api-key 就能当 OpenAI 用。我头一回把 LangChain 的 ChatOpenAI 指向本地 vLLM，只改了 base_url 和 api_key 两个参数，整条链就跑通了。LlamaIndex 也类似，用 OpenAI 类指定 api_base 就行。已有的工具、记忆模块、输出解析器都不用动。数据全程在内网，合规部门看了也放心。
集成时踩过几个小坑。vLLM 的接口对 tools 参数支持是逐步完善的，早期版本跑 Agent 会报错。我后来升到 0.5.x 才稳定。LlamaIndex 的流式输出兼容得不错，但 token 计数偶尔和 OpenAI 对不上。我的处理方式是关掉框架自带的 token 统计，直接用 vLLM 返回的 usage 字段。另外要注意模型名称，LangChain 里填的 model_name 得和 vLLM 启动时加载的模型一致，不然会报找不到模型。
5.2 RAG、Agent、代码助手与多模态推理场景
RAG 是我用 vLLM 最多的场景。企业文档切片后存进 Milvus，检索出相关段落拼进 prompt，再调 vLLM 生成答案。连续批处理让几十路并发检索加生成变得很轻松。Agent 场景更费脑，我拿 vLLM 做 LLM 后端，配合 LangGraph 做多步推理。Agent 的 prompt 通常很长，一定得开 --enable-prefix-caching，不然首 token 延迟会拖垮体验。代码助手对延迟特别敏感，我用 CodeLlama 加 vLLM 的 FIM 模式，补全速度能到每秒几十个 token。多模态方面 vLLM 还在追赶，我试过用 LLaVA 跑图文问答，图像编码后交给 LLM，效果能接受，吞吐比纯文本差不少。
实际落地时，RAG 的瓶颈往往在检索，不在生成。我见过检索出一堆不相关文档，vLLM 再快也白搭。Agent 容易陷入死循环，得设最大步数，还要加超时。代码助手要处理长上下文，max-model-len 得调到 8K 以上。多模态场景显存吃紧，量化要格外小心，图像 token 会挤占 KV Cache。我的习惯是用小模型先跑通全流程，再换成大模型压测。vLLM 社区迭代快，新模型的支持通常几天就跟上。
5.3 私有化知识库与企业大模型落地
我给一家金融客户做过私有化知识库，他们要求数据绝对不出内网。方案是 vLLM 离线部署 Qwen 72B，AWQ 量化到 4bit，跑在四张 A100 上。知识库有几十万份文档，检索用 BGE 模型，生成走 vLLM 的 OpenAI 接口。整个系统架在内网 K8s 里，外面套一层 VPN。前端直接用 Open WebUI，对接 vLLM 的 API 地址就行。落地难点不在 vLLM 本身，在数据清洗、权限映射和日常运维。vLLM 的量化支持让单卡跑 13B 成为可能，小团队也能玩得起。
企业场景对稳定性要求高。我给他们配了双实例热备，前面挂 Nginx 做健康检查。监控用 Prometheus 抓 vLLM 的指标，Grafana 出图。日志走 ELK，出问题能追溯。版本升级我坚持现在测试环境跑一周，再上生产。成本方面，自建 GPU 服务器比调 API 便宜，但得算上运维人力。中小公司可以选云上 GPU 实例，按需启停。vLLM 的生态让私有化部署门槛降了不少，以前要写一堆胶水代码，现在改个 base_url 就能用。
5.4 权限、安全、合规与成本治理
vLLM 自身不带用户认证，权限得在前端或网关做。我用过 Nginx 加 JWT 校验，也试过 Keycloak 做统一登录。API Key 是最简单的，但适合内部服务。合规方面，生成内容要过滤敏感词，我在 vLLM 后面加了一个轻量审核模型，输出前过一遍。RAG 场景要防 prompt 注入，检索回来的文档可能藏了恶意指令。我的做法是清洗检索结果，只保留纯文本，并且限制模型只能引用给定上下文。审计日志要记录谁在什么时候问了什么，我把 vLLM 的请求日志接入 ELK，保留六个月。
成本治理的核心是盯住 GPU 利用率。vLLM 暴露的 gpu_cache_usage_perc 和 num_requests_running 是我最常看的两个指标。闲时缩容，忙时扩容，K8s HPA 基于自定义指标做伸缩。量化能省显存，AWQ 4bit 比 FP16 省一半显存，吞吐还高，整体成本能降四成。有些合规场景不允许量化，那就只能堆卡。安全、合规、成本三者经常打架，我的经验是先把安全底线划清楚，再在合规框架里找性价比最高的方案。vLLM 的灵活性让这种平衡变得可能。
6.1 vLLM 从入门到进阶的学习路径与资源
我刚开始接触 vLLM 那会儿，翻了好几遍官方文档。说实话，文档写得不算特别友好，但够用。我的做法是先跑通一个最小示例，装好 vLLM，拿个小模型比如 Qwen2.5-1.5B 起个 API 服务，用 curl 发一条请求看能不能出结果。这一步走通了，心里就有底了。接着去啃 PagedAttention 的论文，配合官方博客里的架构图看。论文不用逐字读，抓重点，理解 KV Cache 分页和块表映射这两个概念就行。源码可以慢慢看，vllm/attention 和 vllm/core 这两个目录是核心。
跑通基础之后，我会去做压力测试。用 vLLM 自带的 benchmark 脚本，换不同的并发数、不同的输入输出长度，观察吞吐和延迟的变化。这一轮下来，对连续批处理的感知会深很多。调参的时候从 max-num-seqs、gpu-memory-utilization 这两块入手，每次只改一个变量。社区资源我常逛 GitHub Discussions 和 vLLM 的 Slack 频道，里面有不少实战踩坑记录。中文资料可以看知乎和公众号上几位做推理优化的博主，但要以官方文档为准，社区版本更新太快，二手信息容易过时。
进阶阶段我建议直接读源码里的调度器实现。Scheduler 类怎么挑请求、怎么管理 block，看一遍比看十篇博客有用。有能力的话，尝试给 vLLM 提个 issue 或 PR，哪怕只是改文档错别字。参与进去，学习速度完全不一样。我自己的习惯是每学一个模块就写一篇笔记，把踩过的坑记下来。过两个月回头翻，收获比当时大得多。
6.2 本地部署与性能对比中的常见误区
本地部署最容易踩的坑是显存估算。很多人以为模型权重占多少显存，就只需要多少显存。实际 vLLM 启动时 KV Cache 要占一大块，gpu-memory-utilization 默认 0.9，意思是把 90% 的显存都预留下来。我第一次部署 7B 模型，按 14GB 权重准备了一张 24GB 卡，结果 OOM 了。后来把 max-model-len 从默认的 8192 降到 4096，KV Cache 占用才降下来。显存估算公式大致是：权重 + 激活 + KV Cache + 框架开销。留 20% 余量比较稳妥。
性能对比的误区更隐蔽。我见过不少人拿 vLLM 和 TGI 比，只测单条请求的延迟就下结论。单条请求 vLLM 不一定比 TGI 快，它的优势在高并发。得测不同并发下的吞吐曲线，看拐点在哪。还有的人测吞吐只算输出 token，不算输入 token。长 prompt 场景下输入 token 占大头，漏算会把结论带偏。我自己的测试模板固定几个维度：并发数从 1 到 256，输入长度分短中长三档，输出固定 256 token，记录首 token 延迟、每 token 延迟、总吞吐。对比才公平。
另一个误区是迷信 benchmark 榜单。不同硬件、不同模型、不同参数配置，跑出来的数字没有可比性。网上流传的“vLLM 比 TGI 快 10 倍”这类说法，仔细看条件往往很特殊。我的态度是自己动手测，用自己业务场景的真实请求分布来压。量化版本也要单独测，AWQ 和 FP16 的吞吐差异很大，不能混着比。还有人忽略了冷启动，vLLM 加载模型和编译 CUDA 图要时间，第一次请求延迟特别高。生产环境得做预热。
6.3 社区版本演进、硬件生态与未来趋势
vLLM 的版本迭代速度快得有点吓人。我印象里 0.4 到 0.5 那段时间，几乎每周都有小版本。新模型支持通常几天就跟上，Llama 3 发布后第一周 vLLM 就能跑。这种节奏对开发者是好事，但也带来兼容性烦恼。我吃过一次亏，升级到新版本后原来的启动脚本参数变了，--tensor-parallel-size 的行为调整过。我的经验是生产环境锁版本，测试环境跟最新，升级前先看 release notes 里的 breaking changes。
硬件生态这块，vLLM 最早绑死 NVIDIA，现在 AMD ROCm、Intel Gaudi、Google TPU 都陆续支持了。我试过在 AMD MI300X 上跑 vLLM，性能能达到 A100 的七八成，成本优势明显。国产卡像昇腾、寒武纪也有社区适配，成熟度还差些。Apple Silicon 通过 MLX 后端在摸索中，跑小模型可以。硬件多元化对行业是好事，不会被一家卡脖子。vLLM 的插件式架构让新硬件接入成本在降低，以后可能会有更多选择。
未来趋势我个人看好几个方向。一是更激进的量化，FP8 在 H100 上已经可用，4bit 甚至 2bit 的研究在推进。二是分离式架构，prefill 和 decode 拆到不同实例，vLLM 已经在做这块的实验。三是多模态原生支持，现在还是外挂编码器，以后可能会内建。四是与训练框架的融合，RLHF 场景下推理和训练打通。这些变化会让 vLLM 从单纯的推理引擎，慢慢变成大模型服务的基础设施。
6.4 面向生产落地的选型与实施清单
选型这件事，我踩过坑才知道要看什么。先明确场景，是离线批量推理还是在线低延迟服务，是内部工具还是对外产品。离线场景吞吐优先，vLLM 是大杀器。在线场景延迟敏感，得在 vLLM 和 TGI、TensorRT-LLM 之间权衡。模型大小也关键，7B 以下单卡随便跑，70B 以上要考虑多卡甚至多节点。量化需求、硬件预算、团队运维能力，都得纳入评估。我一般列个表，每个维度打分，最后看总分。
实施清单我总结了一套流程。硬件上，确认 GPU 型号、显存、卡间互联带宽，NVLink 和 PCIe 性能差很多。软件上，CUDA 版本、驱动版本、Python 版本要匹配，vLLM 对 CUDA 12.x 支持最好。部署方式选 Docker 还是裸机，生产我推荐 Docker 或 K8s，环境隔离和版本管理方便。模型准备阶段要做量化评估、显存估算、并发压测。上线前必须做预热、健康检查、监控告警、灰度发布。回滚方案要提前想好，新版本出问题能快速切回。
运维阶段我盯几个核心指标。gpu_cache_usage_perc 反映 KV Cache 压力，持续高于 90% 就该扩容。num_requests_waiting 排队请求数，高了说明吞吐不够。time_to_first_token 和 time_per_output_token 是用户体验的直接体现。日志集中收集，出问题能追溯。成本上定期算 GPU 利用率和单位 token 成本，闲时缩容节省开支。版本升级走测试、灰度、全量三步。这套流程跑顺了，vLLM 在生产环境能稳得住。
