4. 模型加载与推理：支持模型格式、加载方式、推理参数调优

4.1 核心原理：vLLM 的模型加载链路

vLLM 之所以能在生产环境中实现高吞吐推理，其模型加载链路的设计是关键。与 Hugging Face Transformers 的“按需实例化”不同，vLLM 在加载阶段就完成了权重分片、KV Cache 预留、CUDA 图捕获三大动作。整个链路可以概括为：权重读取 → 张量并行切分 → 内存规划 → 图编译 → 服务就绪。

vLLM 默认使用 safetensors 格式加载权重，因为它支持内存映射（mmap）和零拷贝读取，避免了 pickle 反序列化的安全风险。加载时，vLLM 会依据 tensor_parallel_size 将每个权重矩阵按行或列切分到多张 GPU 上，同时为每层预分配固定大小的 KV Cache 块。这一过程与推理时的 PagedAttention 机制紧密配合——KV Cache 不是动态增长的，而是在加载阶段就按最大序列长度预算锁定。

关键点：vLLM 的加载并非“读入内存即可”，而是“加载即规划”。如果显存不足，加载阶段就会报错，而不是等到推理中途 OOM。
vLLM 模型加载与推理链路 ① 权重读取 safetensors / bin mmap 零拷贝 校验 SHA256 ② 张量并行切分 TP=2/4/8 按行/列切分权重 NCCL 通信组建立 ③ 内存规划 KV Cache 预分配 gpu_memory_utilization 块表初始化 ④ 图编译 CUDA Graph 算子融合 预热 ⑤ 推理服务就绪 /v1/chat/completions → PagedAttention 调度 → 流式输出 max_num_seqs 控制并发窗口，KV Cache 块按需分配 关键加载参数 • --tensor-parallel-size：多卡切分维度，决定权重切分方式 • --gpu-memory-utilization：KV Cache 可用显存比例，默认 0.9 • --max-model-len：单序列最大长度，影响 KV Cache 块数 • --dtype：半精度加载，bfloat16 优先

4.2 支持模型格式与加载方式

vLLM 对模型格式的兼容性经历了从“单一 HF 格式”到“多格式并存”的演进。当前生产环境主要涉及以下三种格式：

格式 加载方式 适用场景 注意事项
Hugging Face（safetensors） 自动下载 + 本地缓存 开发调试、中小模型 需联网或提前下载；首次加载慢
GGUF（llama.cpp 量化） 通过 --quantization gguf 指定 CPU/混合部署、低显存环境 仅支持部分架构；量化精度损失需评估
AWQ / GPTQ（4bit 量化） 加载时自动识别量化配置 高并发低延迟生产 需安装对应 kernels；与 TP 配合需谨慎

加载方式上，vLLM 提供了两种路径：直接加载与预转换加载。直接加载适用于 HF 格式，vLLM 会调用 from_pretrained 读取权重；预转换加载则针对 GGUF 或 AWQ，需要先通过 AutoAWQ 或 llama.cpp 工具链完成格式转换，再交给 vLLM 的 LLMEngine 消费。

生产建议：对于超过 13B 的模型，优先使用 safetensors + bfloat16 加载，并配合 --enforce-eager 关闭 CUDA Graph 以降低显存峰值（代价是吞吐下降约 15%）。若显存紧张，再考虑 AWQ 4bit 量化。

4.3 推理参数调优：从吞吐到延迟的平衡

推理参数调优是 vLLM 生产部署中最具实操价值的部分。核心参数分为服务级参数（启动时指定）与请求级参数（API 调用时指定）。

4.3.1 服务级参数（启动命令）

python -m vllm.entrypoints.openai.api_server \
    --model /data/models/Qwen2.5-14B-Instruct \
    --tensor-parallel-size 2 \
    --gpu-memory-utilization 0.92 \
    --max-model-len 8192 \
    --max-num-seqs 64 \
    --max-num-batched-tokens 8192 \
    --swap-space 4 \
    --disable-log-requests \
    --port 8000

其中 --max-num-seqs 决定了并发序列上限，--max-num-batched-tokens 控制单次前向传播的 token 总量。两者共同影响吞吐与显存占用。经验法则：max-num-seqs 每增加 16，KV Cache 显存约增加 1GB（7B 模型）。

4.3.2 请求级参数（OpenAI 兼容接口）

curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Qwen2.5-14B-Instruct",
    "messages": [{"role": "user", "content": "解释什么是 PagedAttention"}],
    "max_tokens": 512,
    "temperature": 0.7,
    "top_p": 0.9,
    "frequency_penalty": 0.2,
    "presence_penalty": 0.1,
    "stream": true
  }'

调优时需注意 temperature 与 top_p 的配合：两者都控制随机性，但作用机制不同。生产环境中建议固定 temperature=0.2~0.7，top_p=0.9，避免两者同时极端调整导致输出质量不稳定。

4.4 案例：Qwen2.5-14B 生产部署调优实录

某金融客服系统需要部署 Qwen2.5-14B-Instruct，要求单卡 A100-80G 上达到 每秒 40 次请求（输入 200 token，输出 150 token）。初始配置如下：

初始配置：--tensor-parallel-size 1 --gpu-memory-utilization 0.9 --max-num-seqs 32
实测吞吐：28 req/s，P95 延迟 1.8s，显存峰值 72GB。

调优过程分三步：

  1. 提升并发窗口：将 --max-num-seqs 从 32 提升至 48，同时将 --max-num-batched-tokens 从 4096 提升至 6144。吞吐升至 36 req/s，但显存达到 78GB。
  2. 启用 Prefix Caching：在启动参数中加入 --enable-prefix-caching，利用客服系统高频重复的系统提示词（约 800 token），命中率约 40%，吞吐提升至 42 req/s。
  3. 调整请求级参数：将 frequency_penalty 从 0 调至 0.3，减少重复输出导致的 token 浪费，实际输出 token 数下降 12%，P95 延迟降至 1.2s。

最终配置：--max-num-seqs 48 --max-num-batched-tokens 6144 --enable-prefix-caching，吞吐 42 req/s，满足业务要求。

4.5 常见误区与复盘

误区一：盲目调大 max-num-seqs 提升吞吐。 当并发序列超过显存承载能力时，vLLM 会触发 swap 到 CPU 内存，导致延迟急剧恶化。复盘发现，某团队将 max-num-seqs 从 64 调至 128 后，吞吐反而下降 30%，因为 swap 开销超过了并行收益。
误区二：忽略 dtype 对加载速度的影响。 使用 fp32 加载 70B 模型需要 280GB 显存，而 bfloat16 仅需 140GB。若误用 fp32，加载阶段就会 OOM。建议始终显式指定 --dtype bfloat16。
误区三：量化模型直接上生产不验证。 AWQ 4bit 模型在数学推理任务上可能损失 5~8% 的准确率。某案例中，代码生成模型量化后 BLEU 分数下降 12%，最终回退到 bfloat16。量化前必须用业务测试集做回归验证。

复盘要点：模型加载与推理调优是一个“显存预算 → 并发窗口 → 缓存策略 → 请求参数”的联动过程。任何单一参数的调整都会影响其他环节。建议每次变更只改一个参数，并用 vllm.engine.arg_utils 导出的配置快照做对比记录，避免“调优后不知道哪个参数生效”的困境。

← 上一章 📖 返回目录 下一章 →