如何部署并提升大语言模型的 Token 生成速度

很多团队在将大语言模型（LLM）从商业 API 转向私有化部署时，都会经历一个“幻灭”时刻：当并发请求增加时，响应延迟呈指数级飙升，而监控面板上的 GPU 利用率却徘徊在 40% 左右。直觉告诉我们“加显卡”就能解决问题，但增加一张显卡往往只会让你得到两张半闲置的 GPU，延迟依然没有改善。问题的核心不在于算力容量，而在于推理引擎的底层调度与内存管理。本文将深入剖析大模型推理的性能瓶颈，并提供从底层原理到工程实践的 Token 生成速度提升指南。

透视推理瓶颈：为什么你的 GPU 在“摸鱼”？

要提升 Token 生成速度，首先必须理解大模型推理的两个截然不同的计算阶段：预填充（Prefill）和解码（Decode）。

预填充阶段负责处理用户输入的 Prompt（提示词）。这是一个计算密集型（Compute-bound）任务，GPU 的矩阵乘法单元被充分调用，计算效率极高。 解码阶段则是逐字生成 Token 的过程。每生成一个新 Token，模型都需要将所有的权重和上下文缓存从显存中读取一遍。这是一个典型的内存带宽密集型（Memory-bound）任务。

在实际生产中，解码阶段占据了绝大部分时间。由于每次生成 Token 都需要搬运庞大的数据，GPU 的算力往往在等待显存数据搬运的过程中处于闲置状态。这就是为什么在并发不高时，GPU 利用率依然很低的根本原因——Transformer 推理的瓶颈在于“内存墙”，而非“计算墙”。

此外，传统的显存分配方式极其低效。模型权重、KV Cache（键值缓存）、激活值和通信缓冲区都在抢占显存。如果不加干预，60% 到 80% 的 VRAM（视频随机存取存储器）会因为内存碎片和 Padding（填充）被默默浪费。

打破内存墙：KV Cache 优化与模型量化

既然瓶颈在于内存，那么优化的核心就是提高显存利用率和降低内存带宽压力。

PagedAttention 与显存碎片化治理

KV Cache 是解码阶段的“隐形杀手”。随着上下文长度的增加，KV Cache 的体积甚至会超过模型权重本身。传统的连续内存分配会导致严重的显存碎片化。

PagedAttention 技术（由 vLLM 框架发扬光大）借鉴了操作系统虚拟内存的分页思想，将 KV Cache 切分为固定大小的块（Block）。这些块不需要在物理显存中连续存放，从而彻底消除了内存碎片和内部填充浪费。这使得系统能够在相同的硬件上支持更大的 Batch Size（批处理大小），直接成倍提升吞吐量。

量化技术（Quantization）的权衡

将模型从 FP16（半精度浮点数）量化为 INT8、FP8 甚至 INT4，是降低显存占用的最直接手段。例如，一个 70B（700亿）参数的模型从 FP16 量化到 INT8，其显存占用直接减半。

量化不仅减少了模型权重的体积，更重要的是降低了内存带宽压力。在 Decode 阶段，GPU 需要读取的数据量减少，意味着在相同的带宽下可以处理更多的请求。虽然量化会带来微小的精度损失，但在 AWQ（激活感知量化）或 GPTQ 等现代量化算法的加持下，这种损失在绝大多数业务场景中几乎可以忽略不计。

榨干 GPU 算力：高级调度与并行策略

解决了内存问题后，我们需要通过高级调度策略来填补 GPU 在等待数据时的算力空白。

连续批处理（Continuous Batching）

传统的静态批处理（Static Batching）要求一个 Batch 内的所有请求必须同时开始、同时结束。如果某个请求提前生成完毕，GPU 只能闲置等待其他请求，导致算力浪费。

连续批处理（也称 Inflight Batching）打破了这一限制。它允许在 Decode 阶段的每一步动态插入新请求或移除已完成的请求。只要 GPU 有空闲的显存槽位，新的请求就会立即被调度进去。这种“见缝插针”的调度方式，能将 GPU 的利用率从 40% 强行拉升到 90% 以上。

投机解码（Speculative Decoding）

对于对延迟极度敏感的场景，投机解码是一项“黑科技”。它的原理是使用一个参数量较小的“草稿模型”（Draft Model）快速自回归地生成多个候选 Token，然后利用大参数量的“目标模型”在一次前向传播中并行验证这些 Token。如果草稿模型猜对了，大模型就直接采纳；如果猜错了，则从错误点重新生成。由于大模型的验证过程是并行的，这能大幅降低首字延迟（TTFT）和整体生成延迟。

张量并行（Tensor Parallelism）

当单个 GPU 的显存无法装下整个模型时，我们需要将模型切分到多张 GPU 上。张量并行将 Transformer 的每一层（如 Attention 和 MLP 层）的权重矩阵横向或纵向切分。需要注意的是，张量并行会引入 GPU 间的通信开销（如 All-Reduce 操作）。因此，在工程实践中，必须确保多卡之间通过 NVLink 等高速互联技术连接，否则通信延迟会抵消并行带来的收益。

工程实践：基于 vLLM 的高性能部署指南

理论需要落地。目前，vLLM 是工业界部署 LLM 的首选框架之一，它原生集成了 PagedAttention、连续批处理和多种量化加速。以下是一个基于 vLLM 部署 Qwen-72B 模型的生产级代码示例：

from vllm import LLM, SamplingParams

# 1. 定义采样参数
sampling_params = SamplingParams(
    temperature=0.7,
    top_p=0.9,
    max_tokens=512
)

# 2. 初始化 vLLM 推理引擎，配置核心优化参数
llm = LLM(
    model="Qwen/Qwen-72B-Chat",
    tensor_parallel_size=4,          # 张量并行：将模型切分到 4 张 GPU (如 4xA100)
    gpu_memory_utilization=0.92,     # 显存利用率：允许 vLLM 使用 92% 的显存用于 KV Cache
    max_model_len=8192,              # 限制最大上下文长度，防止 OOM (内存溢出)
    enable_prefix_caching=True,      # 开启前缀缓存，复用共享 System Prompt 的计算
    quantization="awq",              # 启用 AWQ 4-bit 量化，大幅降低显存占用并提升带宽
    enforce_eager=True,              # 禁用 CUDA Graph 以节省显存（适用于显存极度紧张时）
)

# 3. 准备输入 Prompt
prompts = [
    "请详细解释量子计算中的量子纠缠现象。",
    "编写一个 Python 函数，实现快速排序算法。",
    # ... 可以动态传入成百上千个请求
]

# 4. 执行推理（vLLM 会自动应用连续批处理）
outputs = llm.generate(prompts, sampling_params)

# 5. 处理输出
for output in outputs:
    prompt = output.prompt
    generated_text = output.outputs[0].text
    print(f"Prompt: {prompt!r}\nGenerated: {generated_text!r}\n")

在上述代码中，gpu_memory_utilization 和 enable_prefix_caching 是提升吞吐量的关键。前者最大化了 KV Cache 的可用空间，允许更大的并发 Batch Size；后者则让具有相同系统提示词（System Prompt）的请求能够共享 Prefill 阶段的计算结果，节省大量算力。

总结与展望

提升大语言模型的 Token 生成速度并非简单的“堆硬件”，而是一项涉及内存管理、计算调度和硬件拓扑的系统工程。从理解 Prefill/Decode 的本质差异，到利用 PagedAttention 治理显存碎片，再到通过连续批处理和量化技术榨干 GPU 的每一滴算力，每一步优化都能带来数量级的性能提升。

展望未来，随着硬件层面 CXL（计算快速链接）内存池化技术的成熟，以及软件层面更高效的 MoE（混合专家模型）架构和原生 FP8 训练的普及，LLM 的推理成本将进一步呈指数级下降。对于 AI 工程师而言，深入理解这些底层原理，将是在大模型时代构建高性能、低成本 AI 基础设施的核心竞争力。

参考来源：

RunPod Team. LLM Inference from First Principles: Tokenization, KV Cache, and Serving at Scale. RunPod Articles.
某技术博主. 百亿参数级大模型部署性能瓶颈全景解析与工程优化路径. CSDN 博客.
RamosAI. How to Deploy Llama 3.3 70B with vLLM + Batch Processing on a $8/Month DigitalOcean GPU Droplet. DEV Community.
shashank ms. Optimizing LLM Inference Time with GPU Support. DEV Community.
Google Cloud. Prácticas recomendadas para optimizar la inferencia de modelos de lenguaje grandes con GPUs en Google Kubernetes Engine (GKE). Google Cloud Documentation.

编程手札