AI服务器入门 · 第4篇大模型推理服务器部署 vLLM vs TensorRT-LLM选型实战显存计算 + 框架横评 + 生产部署经验
前三篇聊了硬件架构和散热，这篇开始进入"软件层"。大模型训练是少数巨头的游戏，但推理部署是每个AI团队都要面对的工程问题。vLLM、TensorRT-LLM、SGLang到底怎么选？我用实测数据告诉你。
开篇：推理部署的三座大山
大模型训练完成后，把它变成一个"线上服务"要翻三座山：
第一座：显存墙。70B模型FP16权重就要140GB，单卡放不下。就算放下了，高并发请求时的KV Cache会吃掉剩余显存。
第二座：吞吐墙。推理是访存密集型任务，GPU算力往往不是瓶颈，HBM带宽才是。同样的模型，不同推理框架的吞吐可以差3-5倍。
第三座：延迟墙。用户问一句话，3秒内不回答就是"慢"。但高吞吐和低延迟往往矛盾——batch size大了吞吐高但延迟也高。
这篇就围绕这三座山，讲清楚推理框架怎么选、显存怎么算、性能怎么调。
一、显存计算：先算清楚再买卡
这是最基本也是最容易踩坑的环节。很多团队买了服务器才开始研究"能不能跑"，结果发现显存不够。
推理显存的5个组成部分
总显存 = 模型权重 + KV Cache + 激活值 + 临时缓冲 + CUDA上下文
1. 模型权重
取决于模型参数量和精度：
| 精度 | 每参数字节 | 70B模型显存 | 7B模型显存 |
|---|---|---|---|
| FP32 | 4 bytes | 280 GB | 28 GB |
| FP16/BF16 | 2 bytes | 140 GB | 14 GB |
| INT8 | 1 byte | 70 GB | 7 GB |
| INT4 (AWQ/GPTQ) | 0.5 byte | 35 GB | 3.5 GB |
2. KV Cache（大头！）
这是最容易被低估的部分。Transformer推理时，每个token的Key和Value都要缓存，供后续token的Attention计算使用。
KV Cache = 2 × num_layers × hidden_size × kv_heads × head_dim
× batch_size × seq_len × precision_bytes
以Llama2-70B为例（80层, hidden_size=8192, 64头, head_dim=128, FP16）：
| 序列长度 | 单请求KV Cache | 32并发KV Cache |
|---|---|---|
| 512 tokens | ~0.5 GB | ~16 GB |
| 2048 tokens | ~2 GB | ~64 GB |
| 4096 tokens | ~4 GB | 128 GB |
| 8192 tokens | ~8 GB | 256 GB |
看到没有？4096序列长度、32并发，KV Cache就要128GB——比模型权重还大。
3. 激活值 + 临时缓冲 + CUDA上下文
这三部分通常占总显存的5-10%，规划时预留即可。
实战计算：70B模型在8卡H100上能跑多少并发？
总显存：8 × 80GB = 640GB 模型权重（FP16）：140GB CUDA上下文+临时缓冲：约40GB 可用于KV Cache：640 - 140 - 40 = 460GB 单请求KV Cache（4096序列长度）：4GB 最大并发请求数：460 / 4 ≈ 115
所以8卡H100跑70B模型（FP16, 4096序列），理论上能支持约115路并发。实际运行中由于显存碎片化和框架开销，打80-90折，约90-100路并发。
💡 从业者视角：这就是为什么量化技术对推理这么重要。把70B从FP16量化到INT4，模型权重从140GB降到35GB，多出来的105GB全给KV Cache，并发量直接翻倍。这也是为什么AWQ和GPTQ量化方案在2024年成为推理部署标配——精度损失可控（<2%），显存收益巨大。
二、三大推理框架横向对比
目前主流的推理框架有三个：vLLM、TensorRT-LLM、SGLang。选型之前先搞清楚各自的定位。
1. vLLM社区之王
vLLM是加州大学伯克利分校开源的推理框架，2023年发布后迅速成为社区最流行的选择。
核心创新：PagedAttention
传统推理框架为每个请求预分配一段连续显存存放KV Cache，长度按最大序列长度预留。这导致严重的显存碎片——请求实际只用了2K tokens，但预留了4K空间，浪费一半。vLLM借鉴操作系统的虚拟内存管理，把KV Cache切成固定大小的"页"（block），按需分配。显存利用率从~60%提升到~96%。
优点：易用性极好，pip install即可用；社区活跃，模型支持最广；PagedAttention显存效率高；支持连续批处理
缺点：纯Python实现，部分算子未经深度优化；峰值性能不及TensorRT-LLM（差10-30%）；对NVIDIA以外的硬件支持有限
2. TensorRT-LLM性能怪兽
TensorRT-LLM是NVIDIA官方推出的推理框架，基于TensorRT引擎做深度优化。
核心优势：内核级优化
NVIDIA把Transformer的每一层算子都做了手写CUDA kernel优化。还支持FP8推理、INT4 AWQ量化等NVIDIA硬件特有加速。
优点：性能最强，尤其在NVIDIA硬件上；支持FP8/INT4等低精度推理；深度优化的Kernel；与Triton Inference Server集成，生产级服务化
缺点：编译流程复杂（需先build engine，耗时10-30分钟）；模型支持有限；学习曲线陡峭；和NVIDIA硬件强绑定
3. SGLang后起之秀
SGLang同样来自伯克利，设计理念比vLLM更激进——不只是优化推理引擎，还优化了"如何使用推理引擎"。
核心创新：RadixAttention + 结构化生成
SGLang引入了前缀树（Radix Tree）来管理KV Cache，自动识别和复用不同请求之间的公共前缀。对于多轮对话、few-shot等场景，前缀复用可以大幅减少重复计算。
优点：多轮对话/few-shot场景性能突出；结构化输出（JSON mode）性能优秀；前缀缓存自动化
缺点：生态成熟度不及vLLM；通用场景性能优势不明显；文档和社区规模较小
横向对比总结
| 维度 | vLLM | TensorRT-LLM | SGLang |
|---|---|---|---|
| 易用性 | ★★★★★ | ★★☆ | ★★★☆ |
| 峰值性能 | ★★★★ | ★★★★★ | ★★★★ |
| 模型支持 | ★★★★★ | ★★★☆ | ★★★☆ |
| 生产成熟度 | ★★★★ | ★★★★★ | ★★★☆ |
| 低精度支持 | INT8/INT4 | FP8/INT4 | INT8/INT4 |
| 多轮对话优化 | 基础 | 基础 | RadixAttention |
| 硬件绑定 | NVIDIA为主 | NVIDIA专用 | NVIDIA为主 |
| 社区活跃度 | 最高 | 中 | 增长最快 |
💡 从业者视角：选型没有"最好"只有"最合适"。我的建议：快速原型验证选vLLM，极致性能优化选TensorRT-LLM，多轮对话/Agent场景选SGLang。很多团队的实际做法是：开发阶段用vLLM快速迭代，上线后迁移到TensorRT-LLM榨干性能。
三、Benchmark实测：Llama2-7B推理性能对比
光说理论不够，放一组实测数据。测试环境：单卡H100 SXM5, Llama2-7B, FP16精度, vLLM 0.6.0 vs TensorRT-LLM 0.10.0。
吞吐量对比（tokens/s）
| 并发数 | vLLM | TensorRT-LLM | 差距 |
|---|---|---|---|
| 1 | 85 | 112 | +32% |
| 8 | 520 | 680 | +31% |
| 32 | 1450 | 1820 | +26% |
| 64 | 2100 | 2650 | +26% |
| 128 | 2350 | 2980 | +27% |
INT4量化后对比（AWQ, 7B模型）
| 指标 | vLLM (FP16) | vLLM (INT4) | TRT-LLM (INT4) |
|---|---|---|---|
| 显存占用 | 14.2GB | 4.8GB | 4.6GB |
| 吞吐(32并发) | 1450 t/s | 2100 t/s | 3200 t/s |
| 精度损失 | 基准 | ~1.5% | ~1.5% |
💡 从业者视角：几个关键发现——1) TensorRT-LLM在所有场景下吞吐都比vLLM高25-30%，代价是工程复杂度；2) INT4量化后吞吐提升45-50%，显存节省65%以上，精度损失不到2%，性价比极高；3) 高并发时vLLM的PagedAttention优势显现，差距从32%缩小到26%，因为显存利用率高允许更大batch。
四、连续批处理：吞吐量翻倍的关键
传统推理的批处理方式是静态批处理：等一批请求凑齐，一起推理，一起返回。问题是：请求长度不一，短的要等长的跑完才能返回，GPU在等待中空转。
连续批处理（Continuous Batching）的思路是：请求随时来随时加入batch，完成了随时返回。GPU永远不空转。
时间步1: [Req A token 1] [Req B token 1] [Req C token 1] 时间步2: [Req A token 2] [Req B token 2] [Req C token 2] 时间步3: [Req A token 3] [Req B ✅完成] [Req C token 3] [Req D token 1] 时间步4: [Req A token 4] [Req C token 4] [Req D token 2] [Req E token 1]
Req B在第3步就完成了，立即返回结果。空出来的位置立刻给新请求Req D。GPU始终满载运行。
| 批处理方式 | 吞吐量 (32并发) | 平均延迟 |
|---|---|---|
| 静态批处理 | 680 t/s | 380ms |
| 连续批处理 | 1450 t/s | 145ms |
吞吐量翻倍，延迟降低60%。这就是为什么vLLM和TensorRT-LLM都把连续批处理作为核心特性。
💡 从业者视角：连续批处理的前提是显存够用——因为batch中各请求的序列长度不同，需要灵活管理KV Cache。这又回到第一节的显存计算——显存规划做得好，连续批处理才能跑大batch，吞吐才能上去。PagedAttention（vLLM）和RadixAttention（SGLang）本质上都是在优化KV Cache的管理效率，让连续批处理跑得更狠。
五、生产部署的工程细节
理论讲够了，最后分享几个线上部署的血泪经验。
1. 模型加载优化
70B模型FP16权重140GB，从磁盘加载到显存需要3-5分钟。如果是冷启动（容器首次拉起），用户等待时间不可接受。
方案：使用safetensors格式替代pytorch_model.bin，加载速度提升2-3倍；预热机制（服务启动时先跑dummy request编译CUDA kernel）；模型常驻（容器不销毁，只做health check和流量切换）
2. 显存碎片化
长时间运行后，PagedAttention的显存页会产生碎片，导致新请求分配失败。
方案：设置--gpu-memory-utilization 0.9留10%缓冲；配合K8s liveness probe，OOM频率超阈值时自动重启容器
3. 流量调度
推理服务的流量有明显波峰波谷。
方案：基于GPU利用率的HPA；预测性扩容（提前15分钟）；分级SLA（VIP专用GPU池 + 普通用户共享池）
4. 模型版本管理
灰度发布新模型时，需要新旧版本同时在线。
方案：双模型并行加载（按比例分流）；A/B测试框架（按用户ID hash分流）；快速回滚（旧模型权重保持在内存中，秒级切回）
💡 从业者视角：推理服务上线容易、稳定运行难。最常见的事故不是框架bug，而是显存OOM——某个用户发了一个超长prompt，KV Cache暴涨，把整个节点的显存吃光，所有请求超时。防御措施：1) 限制单请求最大序列长度；2) 请求级别显存预检查；3) 设置请求超时，超时直接返回错误而非无限等待。
小结：推理框架选型速查表
| 你的场景 | 推荐框架 | 量化方案 | 关键优化点 |
|---|---|---|---|
| 快速原型/开发 | vLLM | FP16或INT8 | PagedAttention + 连续批处理 |
| 生产部署/极致性能 | TensorRT-LLM | INT4 AWQ | FP8 + Kernel融合 |
| 多轮对话/Agent | SGLang | INT4 AWQ | RadixAttention前缀复用 |
| 显存极度受限 | vLLM | INT4 GPTQ | 减小max_seq_len |
| 多模型混合部署 | vLLM + Triton | 按模型选 | GPU共享 + 时间片调度 |
一句话总结：推理部署的核心不是"选哪个框架"，而是"显存够不够、吞吐高不高、延迟低不低"的三角平衡。 先算显存，再选框架，最后调性能——这个顺序不能反。
📋 系列预告
最后一篇，我们聊聊AI服务器的未来——超节点、液冷2.0与国产替代。这是趋势判断篇，我会从从业者角度谈谈这条赛道接下来2-3年往哪走。
关注本号，终篇见 🚀
作者注：文中benchmark数据基于笔者在H100 SXM5环境下的实测，使用Llama2-7B-chat模型。不同硬件、模型、版本下数值可能有差异，仅供参考。vLLM和TensorRT-LLM版本迭代很快，建议以最新版本实测为准。