大语言模型推理部署实战：从vLLM到TensorRT-LLM

引言

随着大语言模型（LLM）从实验室走向生产环境，推理部署成为工程师必须掌握的核心能力。训练一个大模型可能需要数百万美元，但将一个已有价值的模型以低延迟、高吞吐的方式提供给用户，同样充满挑战。本文将深入拆解 LLM 推理部署的全链路技术栈，从底层原理到主流框架实战，帮助你构建生产级推理服务。

一、LLM 推理的核心挑战

与传统的机器学习模型推理不同，LLM 推理面临几个独特的困难：

内存墙问题。一个 7B 参数的 FP16 模型至少需要 14GB 显存仅用于加载权重。70B 模型则超过 140GB，这意味着需要多卡甚至多节点才能运行。

计算强度与 IO 瓶颈。自回归生成的每一步都需要将整个模型权重从 HBM（高带宽内存）加载到计算单元。对于大模型，这种 IO 操作成为性能瓶颈，而非计算本身。

序列长度动态变化。用户输入和输出长度不可预知，导致 batch 内的序列长度差异巨大，传统静态 batching 效率极低。

二、推理优化关键技术

2.1 KV Cache 与内存管理

Transformer 解码过程中，每一层的 Key 和 Value 张量只需计算一次，之后在生成后续 token 时可以复用，这就是 KV Cache。以 Llama-2-70B 为例，单个请求在 4096 token 的序列长度下，KV Cache 约为 800MB。

内存碎片是 KV Cache 管理的主要挑战。不同请求的填充和释放会导致显存中出现不连续的碎片。PagedAttention（源自操作系统虚拟内存的分页思想）将 KV Cache 切分为固定大小的 block，通过 block table 映射逻辑块到物理块，将内存利用率从约 20-40% 提升到接近 100%。

2.2 Continuous Batching

传统 Static Batching 中，batch 中最长的序列决定了所有序列的等待时间。Continuous Batching（又称 Iteration-Level Batching）在每个 decode 步骤动态地将新请求加入 batch、将已完成请求移出，使 GPU 始终处于忙碌状态。

实验数据表明，在并发请求数为 32 时，Continuous Batching 相比 Static Batching 可将吞吐量提升 2-3 倍，P99 延迟降低 40-60%。

2.3 量化技术

量化是减少模型内存占用、加速推理的有效手段：

• GPTQ：训练后量化方法，将权重压缩至 4-bit 甚至 3-bit，可减少 4 倍内存占用，精度损失通常在 1-2% 以内。
• AWQ（Activation-aware Weight Quantization）：根据激活分布选择性地保护重要权重通道，在 4-bit 量化下保持更好的精度。
• GGUF/GGML：专为 CPU 推理设计的量化格式，提供从 2-bit 到 8-bit 的多种量化等级（Q4_K_M、Q5_K_M、Q8_0 等），适用于边缘设备和 Mac 平台。
• FP8/FP4：利用 Hopper 架构（H100）的原生 FP8 支持，在几乎不损失精度的前提下实现 2 倍内存节省。

2.4 Speculative Decoding（投机解码）

投机解码利用小模型（Draft Model）快速生成候选 token 序列，然后大模型（Target Model）并行验证。验证时，大模型可以在一次 forward pass 中对多个 token 进行并行因果计算，因为每个位置的注意力 mask 可以并行生成。

当小模型准确率为 70% 时，理论加速比约为 1.5-2 倍。DeepMind 的研究表明，即使使用不同架构的小模型，只要蒸馏得当，依然能获得显著的加速效果。

三、主流推理框架对比

3.1 vLLM

由加州大学伯克利分校开发的 vLLM 是目前最流行的开源 LLM 推理框架。其核心技术 PagedAttention 借鉴了操作系统的虚拟内存分页机制，解决了 KV Cache 的内存碎片问题。

vLLM 支持多 GPU 推理（Tensor Parallelism）、分布式推理（Distributed Inference）、OpenAI 兼容的 API 服务器。2024 年以来的发展重点是多机推理优化和对新模型的快速适配。

适合场景：单机多卡或小型集群部署，需要高吞吐服务和 OpenAI 兼容 API 的场景。

3.2 TensorRT-LLM

NVIDIA 官方推出的 TensorRT-LLM 深度整合了 CUDA 生态，提供了极致的底层优化：自定义 attention kernel、融合算子、FP8/INT4 量化、KV Cache 的多种管理策略。

其优势在于 H100/H200 硬件上的性能领先，缺点是模型转换流程较为复杂，新模型适配需要手动编写部分 CUDA kernel。

适合场景：追求极致性能的 NVIDIA GPU 部署环境。

3.3 TGI（Text Generation Inference）

Hugging Face 推出的 TGI 框架使用 Rust 编写，主打易用性和快速部署。内置 Continuous Batching、Token Streaming、Flash Attention 支持，并提供了标准化的 Docker 镜像。

TGI 对新 Hugging Face 模型的适配速度最快，但性能在极端负载下通常低于 TensorRT-LLM。

适合场景：快速迭代、模型频繁更新的开发环境。

3.4 llama.cpp

纯 C/C++ 实现的 CPU 推理引擎，支持 Apple Silicon（Metal）、x86（AVX2/AVX512）、ARM（NEON）架构。通过 GGUF 量化格式，在 Mac 和边缘设备上实现了令人惊讶的性能。

M1/M2 Mac 上，7B 模型 Q4 量化可达 30-40 tokens/s，足以支持交互式使用。

适合场景：本地开发调试、边缘设备部署、非 GPU 环境。

3.5 SGLang

张昊团队（UC Berkeley）开发的新兴推理框架，创新性地将 LLM 推理视为结构化生成问题。通过 RadixAttention 共享 prefix KV Cache，在多轮对话和少样本场景中效率极高。

SGLang 的编译式前端（类似 CUDA 的编程模型）允许用户对推理过程进行更精细的控制。

适合场景：复杂提示词工程、多轮对话应用、结构化输出场景。

四、部署架构设计

4.1 单机部署

对于 7B-13B 模型，单张 A100 40GB 配合 INT8 量化即可运行。70B 模型需要 2 张 A100 或单张 A100 80GB。

单机部署建议采用 vLLM + Nginx（反向代理+负载均衡）的架构。对于高可用场景，可以在同一台机器部署多个 vLLM 实例，由 Nginx 分配请求。

4.2 多机分布式推理

当单卡无法满足需求时，需要考虑多机推理。主要策略包括：

• Tensor Parallelism（TP）：将模型权重切分到多张 GPU 上，每张 GPU 负责部分计算。适合延迟敏感场景（通常 TP 不超过 8）。
• Pipeline Parallelism（PP）：将模型层分配到不同 GPU，形成流水线。适合吞吐优先场景。
• Hybrid Parallelism：TP+PP 组合，如 4 机 x 8 卡场景下使用 TP=4, PP=2 的配置。

多机推理面临的核心瓶颈是 NCCL 通信开销。NVLink（600GB/s）和 InfiniBand（400Gbps）是主流的高速互联方案。

4.3 Gateway 层设计

生产环境需要一个统一的 Gateway 层来管理多模型、多版本、多实例的推理集群：

• 请求路由：根据模型名称和版本将请求转发到对应实例组
• 负载均衡：轮询/最少连接/PP 感知调度
• Rate Limiting：按用户/API Key 进行配额管理
• Fallback：上游实例不可用时自动切换
• Logging and Tracing：请求全链路追踪和成本计入

五、性能调优实战

5.1 Batch Size 与 max_model_len 的黄金组合

吞吐量和延迟往往相互矛盾。以下是在 A100 80GB 上运行 Llama-2-13B（FP16）的实测数据对比：

在 max_model_len=4096 时：batch=8 吞吐 320 tok/s P50 延迟 120ms；batch=16 吞吐 480 tok/s P50 延迟 180ms。

在 max_model_len=1024 时：batch=64 可达 610 tok/s，但 P99 延迟升至 1200ms。

结论：延迟敏感业务建议 batch=8-16，吞吐优先场景建议最大化 batch。

5.2 Quantization Level 选择策略

根据业务对精度的敏感度选择量化等级：

• 对话系统：Q4_K_M（GGUF）或 INT4（GPTQ）
• 代码生成：Q5_K_M 或 INT8
• 数据密集型：FP16 或 FP8（精度优先）
• 边缘设备：Q2_K 或 Q3_K（极度内存受限）

5.3 Prompt Cache 优化

在多轮对话和少样本场景中，系统提示词和示例的 KV Cache 可以被缓存和复用。SGLang 的 RadixAttention 实现了基于前缀树的 Cache 共享机制，将公共前缀的 KV Cache 存储在 Radix Tree 中，减少重复内存和计算。

实测在一个 1000 条对话的数据集上，hintCache 命中率可达 60-80%，相应吞吐量提升约 40%。

六、监控与可观测性

部署后需要关注四个核心指标：

• 吞吐（tokens/s）：集群每秒处理的 token 数
• 延迟分布（TTFT/TPOT）：首次 Token 延迟和每 Token 延迟
• GPU 利用率：是否存在计算空闲或显存溢出
• 请求成功率：受 Rate Limit、超时被丢弃的比例

推荐监控栈：Prometheus + Grafana（资源层）、LangSmith/Phoenix（模型层）、ELK（日志层）。

七、趋势展望

2024-2025 年的推理部署趋势正在向以下几个方向演进：

• Multi-LoRA 服务：单模型底座加多个 LoRA Adapter 的部署模式，同时服务多个微调版本
• Disaggregated Serving：Prefill 和 Decode 阶段分离到不同 GPU 集群，各自独立扩展
• 异构推理：CPU 处理 Prefill，GPU 处理 Decode，充分利用异构硬件
• MoE 推理优化：专家并行和稀疏激活的部署策略
• 超长上下文：100K+ token 上下文的缓存和调度优化

总结

LLM 推理部署是一个系统工程，涵盖硬件选型、框架选择、架构设计、性能调优和运维监控多个环节。没有万能的解决方案，关键在于理解自身业务需求（延迟 vs 吞吐、精度 vs 成本），因地制宜地选择技术栈。建议读者从一个简单的 vLLM 单机部署开始，逐步深入到分布式推理和多模型调度，在实践中积累经验。