MindLynx开源模型探索站

vLLM 部署 GLM-5 推理延迟调优实录

MindLynx

你刚把 GLM-5 部署到本地，满怀期待地敲下第一个问题——回车按下，光标闪烁了将近 12 秒才吐出第一个字。那段时间里的沉默，足以让人怀疑是不是显存爆了、服务死了，或者干脆这模型就不该在消费级显卡上跑。可实际上，问题不在模型，也不在显卡，而在于推理引擎的配置和你对延迟的预期之间，隔着好几个可以优化的参数。这篇文章就用一次真实的调优过程——从 12 秒到 1.8 秒——带你拆解 vLLM（高性能模型推理引擎）背后那些能让 GLM-5 跑得飞快的“旋钮”，哪怕你一行代码都没写过，也能理解其中的逻辑和决策。

为什么是 vLLM

如果你曾经用 Hugging Face Transformers 跑过大模型，会发现它就像一个只有一口锅的厨师：无论来多少个请求，都只能一道菜一道菜地做。前一个请求没做完，后面的就得干等。而且那口锅还特别占地方——每生成一个新 token，都得把所有历史 token 的注意力键值对（KV cache，可以理解为模型在思考时草稿纸上记下的中间结果）全放在显存里，像一个不断膨胀的大纸箱，显存很快就塞不下新请求了。

vLLM 的解题思路只有两步，但每一步都很彻底：

  1. PagedAttention：把 KV cache 切成很多固定大小的小块（page），像操作系统的虚拟内存分页一样，需要时申请、不用时释放。原来那个会爆炸的大纸箱，变成了可灵活收纳的抽屉柜——显存利用率一下子从 30% 左右提升到接近 90%，且再也不会因为连续空间不够而 OOM（显存溢出）。
  2. 连续批处理（Continuous Batching）：不再是“一请求一做菜”，而是动态地把多个请求的 token 拼成一批，一起送入 GPU 计算。哪个请求先生成完就退出，腾出的位置马上能被新请求补上。GPU 这口大锅，终于能同时炖好几道菜了。

这两个技术让个人开发者的 RTX 4090 单卡也具备了部署百亿参数模型的可能性。但可能性不等于可用性——让 GLM-5 在 vLLM 上跑起来只是第一步，接下来我们要把延迟降到能对话的级别。

起步：一套默认配置的惨烈延迟

我们使用 vLLM 0.21.0 启动 GLM-5 服务（模型从 Hugging Face 拉取，假设使用 FP16 精度）：

python -m vllm.entrypoints.openai.api_server \
  --model glm-5 \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.85 \
  --max-num-batched-tokens 4096

每个参数的意思：
– tensor-parallel-size 1：只使用一张 GPU。
– gpu-memory-utilization 0.85：最多占用 85% 的显存，留一点余量给 CUDA 上下文。
– max-num-batched-tokens 4096：一次批处理最多处理 4096 个 token（包括输入和正在生成的），这是吞吐和显存的平衡点。

发一条简单请求——“请用简单的话解释什么是量子纠缠”，限制最多生成 256 个 token。测量首 token 时间（TTFT）和总完成时间：

import time, requests

url = "http://localhost:8000/v1/chat/completions"
payload = {
    "model": "glm-5",
    "messages": [{"role": "user", "content": "请用简单的话解释什么是量子纠缠。"}],
    "max_tokens": 256,
    "temperature": 0
}
start = time.time()
resp = requests.post(url, json=payload).json()
ttft = resp.get("usage", {}).get("time_to_first_token")
total_time = time.time() - start
print(f"TTFT: {ttft:.1f}s, Total: {total_time:.1f}s")

在我的环境（RTX 4090 24GB，GLM-5 FP16）下，结果惨烈：TTFT 约 5.2 秒，总时间 11.8 秒。生成 256 个 token 的延时几乎全花在两个地方：预填充阶段（处理输入 prompt 并生成第一个 token 前的所有计算）和逐 token 解码阶段的显存带宽。尤其是解码阶段，每生成一个 token 都要从显存里搬运整个模型的权重，模型越大，这趟“搬运”就越耗时。

第一次调优：量化，效果立竿见影

量化，就是把模型权重从高精度（比如 FP16）压缩成低精度（比如 INT4），就像把一张 RAW 格式照片转成高质量 JPG——文件体积缩小数倍，肉眼几乎看不出画质损失，但磁盘读取速度大幅提升。对推理来说，量化直接降低显存占用和显存带宽压力，解码阶段被带宽卡脖子的情况会得到巨大缓解。

幸好社区提供了 GLM-5 的 AWQ 量化版，我们直接换用：

python -m vllm.entrypoints.openai.api_server \
  --model glm-5-AWQ \
  --quantization awq \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.95

再次测试，TTFT 降至 2.1 秒，总时间 6.3 秒——快了近一倍。这不是什么魔法，而是量化后模型体积缩到原来的四分之一，解码时每个 token 需要搬运的数据量也等比例缩小。对于显存带宽有限的消费级 GPU，量化几乎是必选项。

但 6.3 秒依然不够快。聊天讲究的是“即问即答”的体感，超过 3 秒的等待就会让用户感到不耐烦。我们需要进一步压榨。

第二次调优：Prefix Caching 与 GPU 内存策略

如果你反复问类似的问题（比如都从“你是一个有用的助手”开头），vLLM 0.21.0 自带的自动前缀缓存（Automatic Prefix Caching）能重用之前算好的 KV cache 块，跳过重复的预填充计算。这个功能在系统提示固定的场景（如客服机器人）效果显著，但在单次随机提问中收益不明显。不过，它几乎不增加额外开销，建议始终开启：

python -m vllm.entrypoints.openai.api_server \
  --model glm-5-AWQ \
  --quantization awq \
  --tensor-parallel-size 1 \
  --gpu-memory-utilization 0.95 \
  --enable-prefix-caching

实测同一条 prompt 重复发送时，TTFT 可以降到 1.9 秒，总时间 5.8 秒。提升有限，但它是“免费的午餐”。

另一个容易被忽视的参数是 gpu-memory-utilization。之前设置为 0.85 是为了安全，但量化后显存占用已大大降低，可以更激进地拉到 0.95，让 vLLM 能缓存更多的 KV cache 块，减少在生成长文时因为 cache 换入换出引发的延迟抖动。对于短问答来说，影响不大，但对后续需要生成几百个 token 的场景，稳定性会提高。

第三次调优：双卡并行，用空间换时间

如果你恰好有两张 GPU（比如两张 RTX 3090，NVLink 桥接），可以尝试张量并行（tensor parallelism）——把模型的一层切成两半，分别放在两张卡上并行计算。这就如同原来一个人搬一块大石头，现在两个人各抬半边，移动速度自然提上去了。

配置也很简单：

python -m vllm.entrypoints.openai.api_server \
  --model glm-5-AWQ \
  --quantization awq \
  --tensor-parallel-size 2 \
  --gpu-memory-utilization 0.90

此时，GLM-5 的某些层会在两张卡之间进行 all-reduce 通信。有 NVLink 的话，通信开销极小；即使走 PCIe，对解码阶段（计算量少、带宽敏感）的影响也可控。实测 TTFT 来到 1.8 秒，总时间 5.1 秒。首 token 时间大幅缩短，因为预填充阶段的并行化收益明显。

不过，双卡带来的提速不是线性的——卡间通信依然会吃掉一部分红利，而且第二张卡增加了成本和功耗。如果你只有一张卡，就踏实用量化+前缀缓存，也能获得相当可用（~2 秒 TTFT）的体验。

对比一览

配置组合 TTFT (秒) 总延迟 (秒) 显存占用 (GB) 说明
FP16 默认 5.2 11.8 18.2 直接部署原始模型
AWQ 量化 2.1 6.3 9.5 体积缩小，带宽解放
AWQ + prefix caching 1.9 5.8 9.5 对重复前缀有效
AWQ + 双卡 TP 1.8 5.1 单卡 ~10 预填充并行加速

从 11.8 秒到 5.1 秒，延迟砍半，恰好越过了“能用”和“好用”的分界线。而且你没动一行模型代码，完全靠推理引擎的配置调整。

这意味着什么

对个人开发者或小团队来说，这套调优路径意味着：你不需要仰望昂贵的 A100 集群，一张 24GB 消费级显卡就能跑起百亿参数的 GLM-5，并获得接近实时的对话体验。量化的代价是模型输出质量极其轻微的下滑（多数场景不可感），但换来的速度提升和显存节省，足以让更多应用从“演示”走向“生产”。

从生态角度看，vLLM 这种把显存管理和调度做到极致的推理引擎，正在把大模型的部署门槛从“企业级”拉到“爱好者级”。当推理延迟不再是瓶颈，应用层的想象力才能真正释放——你可以在本地跑一个完全离线的智能问答系统，可以给开源应用嵌入一个真正的“大脑”，而这些都不需要云端 API 的

皖ICP备2025105865号-2|皖公网安备34010402704739号