二、大模型部署基础：LLM推理原理、显存占用分析、部署挑战

在深入VLLM框架的优化技巧之前，必须先建立扎实的底层认知。大模型部署并非简单的“加载模型—启动服务”，其背后涉及Transformer解码机制、KV Cache显存动态增长、以及延迟/吞吐/成本三者间的复杂博弈。本章将系统拆解LLM推理的核心原理，量化分析显存占用构成，并明确部署时面临的关键挑战，为后续章节的优化案例提供理论支撑。

LLM推理核心链路与部署挑战全景 ① Prefill（预填充） ② Decode（逐token生成） ③ KV Cache 动态增长 模型权重（FP16/BF16） KV Cache（随并发增长） 激活值（Activation） CUDA Context + 运行时 延迟（TTFT/TPOT） 吞吐（Tokens/s） 成本（GPU/Token） VLLM 优化核心：PagedAttention + Continuous Batching 显存利用率↑ · 调度开销↓ · 吞吐量↑ 计算密集 访存密集 用户感知 系统效率

2.1 LLM推理核心原理：从Prefill到Decode

大语言模型（LLM）基于Transformer架构，其推理过程本质上是自回归式的序列生成。与训练阶段的前向+反向传播不同，推理只执行前向计算，且必须逐token迭代。理解这一过程是分析性能瓶颈的起点。

2.1.1 核心原理：两阶段解码机制

LLM推理可拆分为两个计算特征截然不同的阶段：

  • Prefill（预填充）阶段：处理用户输入的完整Prompt。此阶段将输入序列的所有token并行计算，生成每个token的Key和Value向量，并写入KV Cache。该阶段是计算密集型（Compute-bound），GPU算力利用率高，但耗时与输入长度成正比。
  • Decode（解码）阶段：逐token生成输出。每步仅输入上一步生成的1个token，计算其与历史所有token的注意力。该阶段是访存密集型（Memory-bound），GPU算力利用率低（通常低于5%），主要瓶颈在于读取KV Cache的带宽。
关键量化指标：业界常用TTFT（Time To First Token，首token延迟）衡量Prefill阶段耗时，用TPOT（Time Per Output Token，每输出token耗时）衡量Decode阶段速度。例如，一个7B模型在A100上，Prefill 512 token约需0.3秒，而Decode阶段每生成一个token约需15-30毫秒。

2.1.2 判断方法：识别推理瓶颈

通过nvidia-smi监控GPU利用率（SM占用率）和显存带宽利用率，可快速判断当前处于哪个阶段：

# 观察Prefill阶段：GPU计算利用率应接近90%+
# 观察Decode阶段：GPU计算利用率通常低于10%，但显存带宽利用率接近饱和
nvidia-smi --query-gpu=utilization.gpu,utilization.memory --format=csv -l 1

若Decode阶段GPU利用率持续低于5%，说明模型受限于显存带宽而非算力，此时增加Batch Size或优化KV Cache管理比单纯堆算力更有效。

2.1.3 实战场景：长上下文对话的延迟波动

假设部署一个13B模型服务多轮对话。当用户连续提问时，KV Cache不断累积。第1轮对话（输入200 token）TTFT约80ms，但第10轮对话（历史上下文累积至2000 token）TTFT可能飙升至500ms以上。这是因为Prefill阶段需要并行计算所有历史token的注意力，计算量随上下文长度线性增长。

优化启示：VLLM的PagedAttention通过非连续显存管理，允许KV Cache按需分配，避免预分配导致的碎片化浪费，从而在长上下文场景下维持更稳定的延迟。

常见误区：初学者常误以为“增加GPU数量就能线性降低延迟”。实际上，Decode阶段是串行逐token生成，多卡Tensor Parallel仅能加速单次前向计算，无法消除串行依赖。对于单用户请求，延迟下限受限于模型大小和硬件带宽，而非GPU数量。

2.2 显存占用分析：权重、KV Cache与激活值

显存是LLM部署最稀缺的资源。一个7B模型在FP16精度下，仅权重就需要14GB显存。但实际部署时，显存占用远不止于此。准确估算显存是选择模型、配置Batch Size和判断是否OOM（Out of Memory）的前提。

2.2.1 显存构成四要素

组件 计算公式 示例（7B模型，FP16） 特征
模型权重 参数量 × 字节数 7B × 2B = 14GB 静态，加载后常驻
KV Cache 2 × 层数 × 头数 × 头维度 × 序列长度 × 字节数 × Batch 40层×32头×128维×2048长度×2B×8Batch ≈ 10.7GB 动态，随并发和长度增长
激活值（Activation） Batch × 序列长度 × 隐藏层维度 × 层数 × 字节数 8×2048×4096×40×2B ≈ 5.4GB（峰值） 瞬时，Prefill阶段峰值高
CUDA Context + 运行时 固定开销 约0.5 - 1.5GB 静态，与框架和驱动相关

2.2.2 判断方法：显存估算与监控

在部署前，建议使用以下Python脚本快速估算KV Cache占用：

def estimate_kv_cache_gb(layers, num_heads, head_dim, seq_len, batch_size, dtype_bytes=2):
    # 每个token的KV大小 = 2 (K和V) × layers × num_heads × head_dim × dtype_bytes
    kv_per_token = 2 * layers * num_heads * head_dim * dtype_bytes
    total_tokens = seq_len * batch_size
    return (kv_per_token * total_tokens) / (1024**3)

# 示例：7B模型（40层，32头，128维），序列2048，Batch 8
print(f"KV Cache占用: {estimate_kv_cache_gb(40, 32, 128, 2048, 8):.2f} GB")

运行时，使用nvidia-smi --query-gpu=memory.used,memory.total --format=csv -l 1监控实际显存增长曲线。若显存随请求数线性增长且接近上限，说明KV Cache是主要瓶颈。

2.2.3 案例拆解：为什么8张A100（80GB）跑不动70B模型？

70B模型FP16权重需140GB，8张A100共640GB显存看似充裕。但实际部署时，若Batch Size设为64，序列长度4096，KV Cache计算如下：

  • 70B模型典型配置：80层，64头，128维
  • KV Cache = 2 × 80 × 64 × 128 × 4096 × 64 × 2B ≈ 343GB
  • 加上权重140GB和激活值峰值约30GB，总需求超510GB

此时显存虽未溢出，但Tensor Parallelism（张量并行）带来的通信开销会显著拖慢Decode速度。实际测试中，70B模型在8卡A100上，Batch 64时TPOT可能超过100ms，远高于单用户可接受的50ms阈值。

复盘经验：显存充足不等于性能达标。部署前应同时评估显存容量和计算/带宽资源。VLLM的PagedAttention通过将KV Cache分页管理，可将显存利用率提升至95%以上（传统方案仅60-70%），从而在相同硬件上支持更大Batch或更长上下文。

经验提醒：对于7B-13B模型，建议预留20%的显存余量给CUDA Context、临时缓冲和推理框架开销。不要将显存计算到100%满负荷，否则在高并发下极易触发OOM或显存碎片化。

2.3 部署挑战：延迟、吞吐与成本的三角博弈

生产环境部署LLM，本质是在延迟、吞吐和成本之间寻找平衡点。三者相互制约：追求低延迟会牺牲吞吐，提升吞吐往往增加延迟，而两者都优化则推高硬件成本。

2.3.1 三大挑战的量化定义

挑战维度 核心指标 业务影响 典型瓶颈
延迟（Latency） TTFT < 500ms，TPOT < 50ms 用户交互体验，实时性要求 Prefill计算量、Decode串行速度
吞吐（Throughput） Tokens/s（每秒生成token数） 系统并发能力，单位时间处理请求数 显存容量限制Batch Size、调度开销
成本（Cost） $/1M Tokens 或 $/GPU/小时 运营利润，规模化可行性 GPU利用率低、显存浪费

2.3.2 判断方法：性能基准测试流程

部署前必须建立基准数据，否则无法评估优化效果。推荐以下测试流程：

  1. 单请求延迟测试：固定输入长度（如512 token），测量TTFT和TPOT。
  2. 并发吞吐测试：使用工具（如wrk或locust）模拟不同并发数（1/8/16/32），记录吞吐量和P99延迟。
  3. 长稳测试：持续运行30分钟以上，监控显存增长趋势和是否出现OOM。
# 使用vllm自带的benchmark脚本
python -m vllm.benchmark.benchmark_throughput \
  --model meta-llama/Llama-2-7b-hf \
  --input-len 512 --output-len 256 \
  --num-prompts 1000 --max-num-seqs 32

2.3.3 实战场景：在线聊天机器人的SLA保障

某在线客服机器人要求：TTFT < 800ms，TPOT < 80ms，单GPU支持至少20路并发。使用传统vLLM（无PagedAttention）部署7B模型时，实测数据如下：

  • Batch Size = 1时：TTFT 350ms，TPOT 45ms，但吞吐仅22 tokens/s
  • Batch Size = 16时：TTFT 900ms（超标），TPOT 120ms（超标），吞吐提升至180 tokens/s

分析：传统方案中，KV Cache预分配导致显存浪费，Batch 16时显存已占用85%，但实际有效利用率仅65%。增大Batch虽提升吞吐，却因显存带宽争抢导致延迟恶化。

优化动作：引入VLLM的PagedAttention后，KV Cache按需分配，显存利用率提升至92%。在相同硬件上，Batch Size可提升至24，且TTFT稳定在600ms，TPOT 70ms，吞吐达到260 tokens/s。同时，Continuous Batching（连续批处理）机制允许GPU在请求间隙立即处理新请求，进一步将整体吞吐提升30%。

风险提示：盲目追求高吞吐可能导致长尾延迟（Long-tail Latency）恶化。在金融、医疗等对延迟敏感的领域，应设置严格的P99延迟SLO（Service Level Objective），而非仅关注平均延迟。建议在部署时配置--max-num-seqs限制最大并发数，为延迟预留缓冲。

2.3.4 总结复盘：部署优化的核心原则

  • 先诊断，后优化：通过监控区分是计算瓶颈、显存瓶颈还是调度瓶颈。
  • 显存是硬约束：KV Cache的浪费是最大的隐性成本，PagedAttention是当前最有效的解决方案。
  • 延迟与吞吐需平衡：通过Continuous Batching和动态Batch调整，在满足SLO的前提下最大化吞吐。
  • 成本考量：量化模型（如INT8/INT4）可降低显存和带宽需求，但需评估精度损失。VLLM支持AWQ/GPTQ量化格式，可在部署时直接加载。
本章核心结论：LLM推理的Prefill/Decode两阶段特性决定了其性能瓶颈在显存带宽而非算力。显存占用中，KV Cache是唯一随并发和上下文动态增长的部分，也是优化的主战场。部署挑战的根源在于传统静态批处理和显存预分配机制无法适应LLM的动态特性。VLLM通过PagedAttention和Continuous Batching，从系统层面解决了显存碎片化和调度低效问题，为后续章节的调优案例奠定了技术基础。
← 上一章 📖 返回目录 下一章 →