调查研究-165 vLLM 深入浅出：从 PagedAttention 到生产级大模型推理服务

vLLM 深入浅出：从 PagedAttention 到生产级大模型推理服务

TL;DR

如果你正在本地或服务器上部署大语言模型，迟早会遇到三个问题：显存不够、并发上不去、接口不好接。模型本身只是第一步，真正让模型稳定对外提供服务的是推理引擎。

vLLM 就是目前开源大模型推理部署里非常重要的一类基础设施。它不是一个普通的模型调用库，而是一个面向高吞吐、低显存浪费、在线服务场景的大模型推理引擎。它最核心的能力包括 PagedAttention、连续批处理、KV Cache 管理、OpenAI 兼容接口、多 GPU 并行、量化、Prefix Cache、Speculative Decoding 等。

一句话概括：

Transformers 更像是"我能把模型跑起来"，vLLM 更像是"我能把模型以服务的方式高效跑起来"。

这篇文章会从问题背景、核心原理、安装启动、接口调用、常用参数、性能调优、生产部署和常见问题几个角度系统梳理 vLLM。

一、为什么需要 vLLM

很多人第一次部署大模型时，通常会从 HuggingFace Transformers 开始。比如加载一个模型、输入 prompt、调用 generate()，很快就能看到模型输出。

这种方式适合调试、研究和单用户实验，但它并不天然适合生产环境。

原因很简单：生产环境里的请求不是一个一个规整地来的。用户请求长度不同，生成长度不同，有的请求只问一句话，有的请求带几千字上下文，有的请求生成几十个 token，有的请求生成上千个 token。对于大语言模型来说，这些差异会直接影响显存占用和计算调度。

LLM 推理不是传统接口服务。传统 Web 服务里，一个请求通常占用的内存相对固定，请求处理时间也比较可控。而 LLM 推理存在两个明显阶段：

第一是 prefill 阶段，也就是模型读取输入 prompt 的阶段。这个阶段计算量大，通常更偏计算密集。

第二是 decode 阶段，也就是模型逐 token 生成输出的阶段。这个阶段每次只生成一个或少量 token，但需要不断读取历史 KV Cache，因此更容易受到显存带宽和 KV Cache 管理效率影响。

当请求并发升高后，系统瓶颈往往不是"模型能不能跑"，而是：

显存能不能装下足够多请求的 KV Cache；
多个请求能不能被合理批处理；
GPU 有没有被充分利用；
不同长度请求会不会互相拖慢；
服务接口能不能像普通 OpenAI API 一样被业务系统调用；
多 GPU 时能不能有效切分模型；
出现 OOM、超时、排队时能不能稳定退化。

vLLM 的价值就在这里：它不是只解决"跑模型"，而是解决"高效服务模型"。

二、LLM 推理真正吃显存的地方：KV Cache

理解 vLLM，必须先理解 KV Cache。

Transformer 模型在生成文本时，并不是每生成一个 token 就重新计算全部历史内容。为了避免重复计算，模型会把历史 token 在注意力机制中产生的 Key 和 Value 缓存下来。后续生成新 token 时，可以复用这些缓存。

这个缓存就是 KV Cache。

KV Cache 的好处是减少重复计算，坏处是显存占用非常大，并且会随着上下文长度和并发请求数增长。

一个请求输入越长，KV Cache 越大。并发请求越多，总 KV Cache 越大。模型层数越多、隐藏维度越大、上下文越长，KV Cache 的压力也越明显。

传统方式里，KV Cache 管理容易出现几个问题：

第一，内存分配不灵活。系统往往需要为请求预留一段连续显存，但实际生成长度是不确定的。预留太少会不够，预留太多会浪费。

第二，显存碎片严重。不同请求长度不同，释放时间不同，显存空间会变得零散。

第三，batch size 受限。显存浪费越多，能同时处理的请求越少，吞吐就越差。

第四，多样本生成和多轮对话中，很多 prefix 是重复的，但传统方式不一定能高效复用。

这就是 vLLM 的核心切入点：把 KV Cache 当成一种需要精细管理的系统资源，而不是简单粗暴地连续分配。

三、PagedAttention：vLLM 的核心思想

vLLM 最有代表性的技术是 PagedAttention。

这个名字很容易让人联想到操作系统里的分页机制。这个类比基本是准确的。

操作系统不会要求一个进程的虚拟内存在物理内存中必须连续存放，而是通过页表把虚拟地址映射到不同的物理页。这样可以减少碎片，提高内存利用率。

PagedAttention 做了类似的事情：它把 KV Cache 切成多个 block，不要求一个请求的所有 KV Cache 在显存中连续存储，而是通过 block table 管理这些分散的缓存块。

这样做带来几个好处。

第一，减少显存浪费。请求需要多少 token，就分配多少 block，而不是提前预留一大段连续空间。

第二，减少显存碎片。即使请求长度不同，KV Cache 也可以按 block 粒度管理。

第三，提高 batch size。显存利用率提高后，同一张 GPU 可以容纳更多并发请求。

第四，便于共享 prefix。在某些场景下，不同请求可能有相同的系统提示词、模板、RAG 文档前缀，PagedAttention 的结构更容易做缓存复用。

第五，适合动态生成。LLM 的输出长度通常不可预测，按 block 动态扩展比提前固定分配更适合在线推理。

简单说，PagedAttention 解决的不是"模型算得快不快"这么单一的问题，而是"显存能不能被更合理地组织和复用"的问题。

这也是为什么 vLLM 在高并发、长上下文、多请求混合场景下往往比朴素 Transformers 推理更适合。

四、Continuous Batching：让 GPU 不要闲着

除了 PagedAttention，vLLM 另一个关键能力是 continuous batching，也就是连续批处理。

传统 batch 推理通常是这样的：收集一批请求，组成一个 batch，一起送进模型，等这一批全部处理完，再处理下一批。

这种方式在训练或离线推理里比较常见，但在在线服务里会有问题。因为不同请求的生成长度不同，如果一个 batch 里有的请求很短，有的请求很长，短请求生成完后就只能等待长请求，GPU 利用率也不稳定。

Continuous batching 的思路是：不要把 batch 看成固定的一组请求，而是在每一次 decode step 中动态调度请求。已经完成的请求可以退出，新的请求可以加入。这样 GPU 可以持续保持较高利用率。

这对在线服务非常重要。

假设有 100 个用户同时请求模型，其中一部分只需要回答一句话，另一部分需要生成长文。传统 batch 方式容易被长请求拖住，而连续批处理可以在每一步动态组织计算，让短请求更快完成，也让 GPU 不断有活干。

vLLM 的调度器会根据请求状态、KV Cache、batch token 数、并发数量等因素动态安排执行。对于业务侧来说，你看到的只是一个 HTTP 接口；对于底层来说，vLLM 正在不断做请求调度、显存分配、缓存复用和 batch 组织。

这也是 vLLM 和简单 model.generate() 的本质区别之一。

五、vLLM 适合什么场景

vLLM 特别适合以下场景：

第一，本地部署开源大模型，并希望提供 OpenAI 兼容 API。比如你想把 Qwen、Llama、DeepSeek、GLM、Mistral 等模型部署成 /v1/chat/completions 接口，让已有业务代码几乎不用改。

第二，有一定并发量。单用户测试时，vLLM 的优势可能没有那么明显；但并发请求变多后，PagedAttention 和 continuous batching 的价值会逐渐体现。

第三，需要长上下文。上下文越长，KV Cache 压力越明显，vLLM 的内存管理越重要。

第四，需要多 GPU 部署。大模型单卡放不下时，可以使用 tensor parallel 或 pipeline parallel 切分模型。

第五，需要更接近生产的服务能力。比如接口鉴权、Prometheus 指标、服务参数控制、模型别名、多模型生态兼容等。

第六，需要和现有 AI 应用框架集成。只要你的应用支持 OpenAI API 格式，通常就可以比较顺滑地切到 vLLM 服务。

但 vLLM 不是所有场景的最优解。

如果你只是本地单人聊天，Ollama、LM Studio 可能更简单。如果你部署的是很小的模型，只追求启动方便，不追求并发吞吐，vLLM 的工程复杂度可能显得偏重。如果你要做极端低延迟的语音实时链路，还需要结合模型大小、流式输出、网络、TTS/ASR、调度策略综合评估，不能只看 vLLM 本身。

六、安装 vLLM

vLLM 的安装与 CUDA、PyTorch、Python 版本强相关。生产环境建议使用独立虚拟环境，避免和已有项目依赖冲突。

一个常见的安装方式如下：

bash 复制代码

python -m venv vllm-env
source vllm-env/bin/activate

pip install --upgrade pip
pip install vllm

如果使用 uv，也可以这样：

bash 复制代码

uv venv vllm-env
source vllm-env/bin/activate
uv pip install vllm

安装后可以检查：

bash 复制代码

python -c "import vllm; print(vllm.__version__)"

如果安装失败，优先检查几个点：

bash 复制代码

python --version
nvidia-smi
nvcc --version
pip show torch

常见问题通常来自 CUDA Driver、CUDA Runtime、PyTorch、vLLM wheel 之间的兼容性。特别是生产服务器上已有 CUDA 环境时，不要盲目升级系统 CUDA，也不要随便覆盖 PyTorch。最稳妥的方式是根据 vLLM 当前版本文档选择对应安装方式，必要时使用 Docker 镜像隔离环境。

七、启动一个 OpenAI 兼容服务

vLLM 最常用的方式是启动 OpenAI-Compatible Server。

以一个文本模型为例：

bash 复制代码

vllm serve Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --dtype auto

启动后，可以用 curl 测试：

bash 复制代码

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen/Qwen2.5-7B-Instruct",
    "messages": [
      {"role": "system", "content": "你是一个严谨的技术助手。"},
      {"role": "user", "content": "请用一句话解释 vLLM。"}
    ],
    "temperature": 0.7,
    "max_tokens": 256
  }'

也可以使用 OpenAI Python SDK 调用：

python 复制代码

from openai import OpenAI

client = OpenAI(
    api_key="EMPTY",
    base_url="http://localhost:8000/v1",
)

resp = client.chat.completions.create(
    model="Qwen/Qwen2.5-7B-Instruct",
    messages=[
        {"role": "system", "content": "你是一个严谨的技术助手。"},
        {"role": "user", "content": "请解释 vLLM 的核心优势。"},
    ],
    temperature=0.7,
    max_tokens=512,
)

print(resp.choices[0].message.content)

业务系统接入时，通常只需要把 OpenAI SDK 的 base_url 改成本地 vLLM 地址，把 model 改成部署的模型名即可。这是 vLLM 很大的工程优势：它降低了本地模型替换云 API 的接入成本。

八、如何指定显卡

如果服务器有多张 GPU，可以用 CUDA_VISIBLE_DEVICES 指定 vLLM 使用哪张卡。

比如只使用第 6 张卡：

bash 复制代码

CUDA_VISIBLE_DEVICES=6 vllm serve Qwen/Qwen2.5-7B-Instruct \
  --host 0.0.0.0 \
  --port 8000

注意，CUDA_VISIBLE_DEVICES=6 之后，程序内部看到的这张卡会变成 cuda:0。这是 CUDA 的常规行为。

如果使用多张卡，可以这样：

bash 复制代码

CUDA_VISIBLE_DEVICES=0,1 vllm serve Qwen/Qwen2.5-72B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2

这里的含义是：只暴露 0、1 两张 GPU 给当前进程，并用 tensor parallel 把模型切到 2 张卡上。

如果不设置 CUDA_VISIBLE_DEVICES，vLLM 通常会看到所有可见 GPU，但不代表它一定会自动把模型分到所有 GPU 上。是否多卡并行，关键还是看你是否设置了 --tensor-parallel-size 或相关并行参数。生产环境不建议依赖默认行为，最好明确指定 GPU 和并行方式。

九、常用启动参数解释

vLLM 参数很多，初学者不需要一开始就全部记住。下面这些参数最常见。

1. `--host` 和 `--port`

指定服务监听地址和端口。

bash 复制代码

--host 0.0.0.0 --port 8000

如果只在本机测试，可以使用 127.0.0.1。如果要让局域网或其他服务访问，需要监听 0.0.0.0，同时注意防火墙和鉴权。

2. `--dtype`

指定模型推理精度。

bash 复制代码

--dtype auto

常见值包括 auto、float16、bfloat16 等。一般优先使用 auto，由 vLLM 根据模型和硬件选择。

3. `--max-model-len`

限制模型最大上下文长度。

bash 复制代码

--max-model-len 32768

上下文越长，KV Cache 占用越大。很多人一上来就把上下文开到很大，结果服务直接 OOM。生产环境要根据真实业务需要设置，不要盲目拉满。

4. `--gpu-memory-utilization`

控制 vLLM 可使用的 GPU 显存比例。

bash 复制代码

--gpu-memory-utilization 0.9

这个参数不是越高越好。设置太高可能导致其他进程没有显存空间，也可能增加 OOM 风险。独占 GPU 时可以相对高一些，共享 GPU 时要保守。

5. `--max-num-seqs`

限制同时处理的序列数量。

bash 复制代码

--max-num-seqs 128

并发上不去时可以关注这个参数，但它不是单独决定吞吐的唯一因素。还要看模型大小、上下文长度、输出长度、显存容量和 batch token 数。

6. `--max-num-batched-tokens`

限制一个 batch 内的 token 数。

bash 复制代码

--max-num-batched-tokens 8192

它会影响吞吐和延迟。过小可能 GPU 利用率不足，过大可能增加排队和显存压力。调优时应该结合压测结果，而不是凭感觉设置。

7. `--served-model-name`

给模型设置服务侧别名。

bash 复制代码

--served-model-name qwen-local

这样调用接口时可以使用：

json 复制代码

{
  "model": "qwen-local"
}

这对业务系统很有用。以后底层模型路径变化时，业务侧不一定要改模型名。

8. `--api-key`

为服务设置简单鉴权。

bash 复制代码

--api-key your-token

调用时需要带上：

bash 复制代码

-H "Authorization: Bearer your-token"

如果服务暴露到公网，不能裸奔。即使有 --api-key，也建议配合反向代理、访问控制、安全组、防火墙、日志审计一起使用。

9. `--trust-remote-code`

部分 HuggingFace 模型需要执行仓库中的自定义代码，启动时可能需要：

bash 复制代码

--trust-remote-code

这个参数有安全风险。它意味着你信任模型仓库里的代码。生产环境不要对来源不明的模型随便开启，至少要固定版本、审查代码、隔离运行环境。

十、Prefix Cache：重复上下文场景的优化

很多业务请求有大量重复前缀。

比如：

固定 system prompt；
固定工具说明；
固定角色设定；
RAG 中多个用户命中同一篇文档；
多轮对话中历史上下文重复；
Agent 框架里固定的 tool schema。

这些重复内容如果每次都重新 prefill，会浪费计算。Prefix Cache 的作用就是尽量复用相同前缀的 KV Cache。

在实际业务里，Prefix Cache 对以下场景比较有价值：

第一，客服机器人。系统提示词、业务规则、工具说明大量重复。

第二，知识库问答。很多问题会引用相同文档片段。

第三，代码助手。项目背景、规范说明、文件上下文可能重复。

第四，多 Agent 系统。Agent 的工具 schema、角色 prompt、流程描述通常很长。

但是 Prefix Cache 不是万能加速器。它依赖请求之间确实存在可复用前缀。如果每个请求都完全不同，收益就有限。调优时要结合业务请求分布，而不是看到参数就打开后期待所有场景都变快。

十一、量化：显存、速度和质量的取舍

大模型部署经常遇到一个现实问题：模型太大，显存不够。

量化是降低显存占用的重要手段。常见量化包括 GPTQ、AWQ、FP8 等。具体支持情况取决于模型、硬件和 vLLM 版本。

量化的收益主要有两个：

第一，降低显存占用。模型权重更小，同样显存可以部署更大的模型，或者给 KV Cache 留出更多空间。

第二，可能提升吞吐。权重读取压力下降后，在某些硬件上可能有速度收益。

但量化也有代价：

第一，模型质量可能下降。尤其是低 bit 量化，推理结果可能变差。

第二，兼容性更复杂。不是所有模型格式都能顺利加载。

第三，性能不一定总是提升。不同 GPU、不同 kernel、不同量化格式表现不同。

生产环境不应该只看"能不能跑"，还要做业务评测。比如对客服、代码生成、数据抽取、意图识别、RAG 问答分别构建测试集，比较原始模型和量化模型的输出稳定性。

十二、多 GPU：Tensor Parallel 和 Pipeline Parallel

单张 GPU 放不下模型时，就需要多 GPU。

vLLM 常见并行方式包括 Tensor Parallel 和 Pipeline Parallel。

Tensor Parallel 是把模型里的张量计算切到多张 GPU 上，适合大多数大模型多卡推理场景。比如一个 72B 模型单卡放不下，可以用 2 张、4 张或 8 张 GPU 切分。

启动示例：

bash 复制代码

CUDA_VISIBLE_DEVICES=0,1,2,3 vllm serve Qwen/Qwen2.5-72B-Instruct \
  --tensor-parallel-size 4 \
  --host 0.0.0.0 \
  --port 8000

Pipeline Parallel 是把模型层分布到不同 GPU 上。它更像按层切分，适用于某些模型结构和跨节点场景。但 pipeline 会引入流水线调度问题，不是所有场景都比 tensor parallel 更直接。

实际部署时，优先考虑：

模型能不能单卡放下；
单卡吞吐是否够；
多卡后通信开销是否可接受；
GPU 之间是否有 NVLink；
是否跨节点；
请求是偏长上下文还是短上下文；
业务更看重 TTFT、TPOT 还是总吞吐。

多卡不是越多越好。卡数增加后，显存容量变大，但通信成本也会上升。对于小模型，强行多卡可能反而不划算。

十三、性能指标：不要只看"每秒多少 token"

评估 vLLM 服务时，不能只看一个 token/s。

常见指标包括：

1. TTFT

Time To First Token，首 token 延迟。用户从发起请求到看到第一个 token 的时间。

对聊天、语音助手、实时交互来说，TTFT 很重要。TTFT 太高，用户会感觉系统"卡住了"。

2. TPOT

Time Per Output Token，每个输出 token 的平均耗时。

它影响生成过程的流畅程度。TPOT 越低，流式输出越快。

3. Throughput

吞吐量，可以按 requests/s 或 tokens/s 衡量。

吞吐高不代表单个用户体验一定好。极端情况下，为了追求总吞吐，系统可能让请求排队更久。

4. GPU 利用率

GPU 利用率过低说明调度、batch、请求负载或模型配置可能有问题。GPU 利用率高也不一定代表服务健康，还要看显存、延迟和错误率。

5. 显存占用

显存占用包括模型权重、KV Cache、临时 buffer 等。长上下文和高并发下，KV Cache 往往是关键变量。

6. P50 / P95 / P99 延迟

平均延迟意义有限。生产环境更应该看尾延迟。P99 很高说明少数请求体验很差，可能是长请求、排队、显存抢占、GC、网络或调度问题。

7. 错误率

包括 OOM、超时、连接断开、请求被拒绝、模型输出异常等。

真正的压测应该模拟业务请求，而不是只拿几个固定 prompt 测 token/s。输入长度、输出长度、并发数、请求分布都会改变结果。

十四、生产部署建议

vLLM 能快速启动服务，但生产部署不能只靠一条命令。

1. 使用固定版本

不要在生产环境直接使用不固定版本的依赖。建议固定：

txt 复制代码

vllm==具体版本
torch==具体版本
transformers==具体版本

模型也应该固定 revision，避免 HuggingFace 仓库更新后行为变化。

2. 使用 Docker 隔离环境

如果服务器上有多个 CUDA 项目，Docker 能减少依赖冲突。尤其是 vLLM、PyTorch、CUDA 版本变化较快，裸机环境很容易互相污染。

3. 服务不要裸露公网

如果必须公网访问，至少要有：

API Key；
反向代理；
HTTPS；
防火墙或安全组；
访问频率限制；
日志审计；
异常告警。

LLM 服务成本很高，被扫到后可能造成明显资源损失。

4. 增加健康检查

可以通过服务探活接口、模型预热请求、进程监控来判断服务是否健康。不要只看进程存在，进程存在不代表模型还能正常响应。

5. 做模型预热

模型刚启动后第一次请求可能较慢。生产流量进入前，可以主动发送几次测试请求，让服务完成必要初始化。

6. 限制最大输入和输出

不要让用户无限制传入超长 prompt 或请求超长输出。应该在网关层和模型服务层都做限制。

例如：

最大 prompt token 数；
最大输出 token 数；
最大请求体大小；
单用户并发限制；
超时时间；
队列长度。

7. 区分交互请求和批处理请求

聊天、语音助手、在线问答通常更看重低延迟。离线总结、批量抽取、长文生成更看重吞吐。两类请求最好不要混在同一个服务实例里，否则长请求可能拖慢交互请求。

8. 监控 GPU

至少监控：

GPU 利用率；
显存占用；
温度；
功耗；
进程显存；
token 吞吐；
请求延迟；
错误率。

不要只靠 nvidia-smi 人工观察。生产系统需要指标采集和告警。

十五、常见问题与排查思路

1. 启动时报 CUDA 错误

优先检查：

bash 复制代码

nvidia-smi
python --version
python -c "import torch; print(torch.__version__, torch.version.cuda)"
python -c "import vllm; print(vllm.__version__)"

很多问题不是 vLLM 本身，而是 PyTorch、CUDA、驱动、Python 版本组合不匹配。

驱动版本一般向下兼容 CUDA Runtime，但不代表所有 wheel 都能随便混用。不要看到报错就盲目升级驱动，生产服务器升级驱动有风险，可能影响其他服务。

2. OOM

OOM 常见原因：

模型太大；
上下文长度太长；
gpu-memory-utilization 过高；
并发太高；
max-num-seqs 太大；
batch token 太多；
同一张 GPU 上还有其他进程；
量化格式不合适；
多模态模型额外占显存。

排查时不要只改一个参数。先确认模型权重占用，再估算 KV Cache，再降低上下文长度和并发。

3. 首 token 很慢

TTFT 高可能来自：

prompt 太长；
prefill 计算量大；
请求排队；
batch 配置不合理；
GPU 已经满载；
Prefix Cache 没有命中；
模型过大；
网络链路慢；
反向代理缓冲影响流式返回。

实时交互场景中，TTFT 比总吞吐更影响用户感知。

4. 输出格式不符合预期

可能原因：

chat template 不匹配；
模型不是 instruct/chat 版本；
system prompt 写法不适配；
temperature 太高；
stop 参数设置不正确；
OpenAI SDK 调用格式和模型模板不一致。

部署模型前要确认它是 base 模型还是 instruct 模型。base 模型不适合直接聊天。

5. 多卡没有生效

检查是否设置：

bash 复制代码

CUDA_VISIBLE_DEVICES=0,1
--tensor-parallel-size 2

同时确认日志里是否真的初始化了多张 GPU。只暴露多张卡不等于自动使用多张卡。

6. 服务能启动，但请求失败

检查：

model 名称是否和服务端一致；
是否需要 --served-model-name；
API Key 是否正确；
请求路径是否是 /v1/chat/completions；
请求体是否符合 OpenAI 格式；
是否使用了模型不支持的参数；
是否缺少 chat template。

十六、vLLM 与 Ollama、TGI、Transformers 的区别

vLLM vs Transformers

Transformers 更适合模型加载、研究、微调、单机实验和自定义推理逻辑。vLLM 更适合把模型作为服务高效部署出来。

如果你只是写脚本跑几个样例，Transformers 足够。如果你要做在线 API 服务，vLLM 更合适。

vLLM vs Ollama

Ollama 强在本地体验和使用门槛低。拉模型、运行、聊天都很方便，适合个人电脑、本地工具、小规模使用。

vLLM 更偏服务端和生产推理。它的配置复杂度更高，但可控性、吞吐、并发、多 GPU 能力也更强。

vLLM vs TGI

TGI 也是成熟的大模型推理服务框架，生态和生产特性也很完整。vLLM 的突出特点是 PagedAttention、OpenAI 兼容体验、社区活跃度和高吞吐场景下的广泛使用。

两者没有绝对谁替代谁，应该根据模型支持、性能测试、团队熟悉度、部署环境、监控体系和业务请求类型选择。

十七、一个更接近生产的启动示例

下面是一个相对完整的启动示例：

bash 复制代码

CUDA_VISIBLE_DEVICES=0,1 vllm serve Qwen/Qwen2.5-72B-Instruct \
  --host 0.0.0.0 \
  --port 8000 \
  --tensor-parallel-size 2 \
  --dtype auto \
  --max-model-len 32768 \
  --gpu-memory-utilization 0.9 \
  --max-num-seqs 64 \
  --served-model-name qwen72b \
  --api-key your-secret-token

调用：

bash 复制代码

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer your-secret-token" \
  -d '{
    "model": "qwen72b",
    "messages": [
      {"role": "system", "content": "你是一个严谨的技术助手。"},
      {"role": "user", "content": "请总结 vLLM 的核心优势。"}
    ],
    "temperature": 0.7,
    "max_tokens": 512,
    "stream": true
  }'

这个示例不是通用最优配置，只是一个参考。真实生产环境必须根据模型大小、GPU 显存、业务并发、上下文长度、延迟目标进行压测后调整。

十八、vLLM-Omni 与多模态补充

随着多模态模型发展，推理服务不再只处理文本。现在很多模型会涉及图像、语音、视频、TTS、STT、Any-to-Any 多模态链路。

vLLM 本体已经支持越来越多模型和接口，围绕 vLLM 的多模态扩展也在快速发展。比如 vLLM-Omni 方向，就是面向更复杂的多模态 serving 场景。

不过这里要注意一个工程现实：文本 LLM 服务和语音实时服务不是同一类问题。

文本模型只要流式输出 token，用户通常还能接受几百毫秒到几秒的响应。但语音实时交互要考虑：

麦克风采集；
VAD；
ASR；
LLM；
TTS；
播放缓冲；
打断；
网络延迟；
端侧设备性能；
多服务链路超时。

所以不能因为某个模型能通过 vLLM 部署，就直接认为它能平替商业 Realtime API。是否能达到实时效果，要看端到端链路，而不是只看模型能不能启动。

十九、vLLM 调优的基本方法

调优不要凭感觉。建议按以下顺序：

第一步，固定环境。固定 GPU、驱动、CUDA、vLLM、PyTorch、模型版本。

第二步，固定业务样本。准备真实 prompt，包括短问答、长上下文、多轮对话、RAG、工具调用等。

第三步，设定指标。明确你要优化的是 TTFT、TPOT、吞吐、显存、错误率，还是综合成本。

第四步，单变量调参。一次只改一个关键参数，比如 max-model-len、max-num-seqs、max-num-batched-tokens、gpu-memory-utilization。

第五步，记录结果。每次压测都记录配置、输入长度、输出长度、并发数、GPU 占用、延迟分布、错误率。

第六步，按业务分流。低延迟请求和长文本批处理不要混在一起。

第七步，压测极限。不要只测正常流量，还要测突增流量、超长输入、异常参数、客户端断连、重复请求等情况。

最终目标不是把某个 benchmark 跑得好看，而是让业务在真实请求下稳定。

二十、总结

vLLM 的价值可以归纳成三句话。

第一，它通过 PagedAttention 更高效地管理 KV Cache，降低显存浪费，让同样硬件能承载更多请求。

第二，它通过 continuous batching 等调度机制提升 GPU 利用率，让在线推理不再是简单的单请求 generate()。

第三，它通过 OpenAI 兼容接口、多 GPU 并行、量化、Prefix Cache、监控指标等能力，把开源大模型部署从"能跑"推进到"能服务"。

但 vLLM 不是魔法。它不能让显存凭空变大，也不能消除大模型本身的计算成本。它解决的是推理服务中的系统效率问题，而不是模型能力问题。

对于个人开发者，vLLM 可以帮助你把本地模型包装成标准 API，接入自己的应用系统。

对于团队和企业，vLLM 更像是一层推理基础设施：上面可以接 RAG、Agent、代码助手、客服机器人、数据分析助手、语音助手；下面对接 GPU、模型权重、调度策略和监控系统。

真正理解 vLLM，不是背几个启动参数，而是理解大模型服务的核心矛盾：请求是动态的，输出是不确定的，KV Cache 是昂贵的，GPU 必须被持续喂满，而业务还要求接口稳定、延迟可控、成本可接受。

vLLM 正是围绕这些矛盾做工程化优化的系统。

调查研究-165 vLLM 深入浅出：从 PagedAttention 到生产级大模型推理服务

vLLM 深入浅出：从 PagedAttention 到生产级大模型推理服务

TL;DR

一、为什么需要 vLLM

二、LLM 推理真正吃显存的地方：KV Cache

三、PagedAttention：vLLM 的核心思想

四、Continuous Batching：让 GPU 不要闲着

五、vLLM 适合什么场景

六、安装 vLLM

七、启动一个 OpenAI 兼容服务

八、如何指定显卡

九、常用启动参数解释

1. --host 和 --port

2. --dtype

3. --max-model-len

4. --gpu-memory-utilization

5. --max-num-seqs

6. --max-num-batched-tokens

7. --served-model-name

8. --api-key

9. --trust-remote-code

十、Prefix Cache：重复上下文场景的优化

十一、量化：显存、速度和质量的取舍

十二、多 GPU：Tensor Parallel 和 Pipeline Parallel

十三、性能指标：不要只看"每秒多少 token"

1. TTFT

2. TPOT

3. Throughput

4. GPU 利用率

5. 显存占用

6. P50 / P95 / P99 延迟

7. 错误率

十四、生产部署建议

1. 使用固定版本

2. 使用 Docker 隔离环境

3. 服务不要裸露公网

4. 增加健康检查

5. 做模型预热

6. 限制最大输入和输出

7. 区分交互请求和批处理请求

8. 监控 GPU

十五、常见问题与排查思路

1. 启动时报 CUDA 错误

2. OOM

3. 首 token 很慢

4. 输出格式不符合预期

5. 多卡没有生效

6. 服务能启动，但请求失败

十六、vLLM 与 Ollama、TGI、Transformers 的区别

vLLM vs Transformers

vLLM vs Ollama

vLLM vs TGI

十七、一个更接近生产的启动示例

十八、vLLM-Omni 与多模态补充

十九、vLLM 调优的基本方法

二十、总结

1. `--host` 和 `--port`

2. `--dtype`

3. `--max-model-len`

4. `--gpu-memory-utilization`

5. `--max-num-seqs`

6. `--max-num-batched-tokens`

7. `--served-model-name`

8. `--api-key`

9. `--trust-remote-code`