上周五半夜，我们线上的大模型推理网关突然告警，TPS 跌穿地心，GPU 显存直接 OOM。运维一顿排查，发现是业务方切了个几万并发的渠道，vLLM 的 KV Cache 瞬间被打爆。为了选型新的推理底座，我花了整整三天，在真实生产物理机上把 vLLM、SGLang、TensorRT-LLM 等主流框架扒了个底朝天。

结论先行：没有任何一个框架是银弹！如果你的业务是高并发短文本，无脑选 vLLM；如果是复杂 Prompt 和超长上下文，SGLang 是降维打击；如果你有极端的极致延迟要求且不差工程师，上 TensorRT-LLM。今天直接把压测数据和踩坑实录端上来，看完保证你少走半个月弯路。

一、 为什么大厂都在疯狂卷推理框架？

其实很多小公司还在用原生的 Transformers 或者直接包一层 FastAPI 就敢上生产，这在内网玩玩可以，一旦放到真实的生产环境（QPS > 10），两个致命问题马上教做人：

1. 显存碎片化：并发一高，显存分配释放跟不上，直接 OOM 崩溃。
2. 计算密集度低：Prefix 阶段和 Decode 阶段的算力利用极不平衡，导致 GPU 一直在“等待”。

所以，搞定 Continuous Batching（动态批处理）和 PagedAttention（分页注意力）的推理框架，成了后端系统的“救命稻草”。下面直接看我们这三天几轮压测下来的真实对比。

二、 五大框架实战横评与避坑指南

为了公平，我们的压测环境统一为：4 * NVIDIA A100 (40G)，模型采用 Qwen-2-72B-Instruct (GPTQ_INT4)。

1. vLLM：高并发短文本的绝对王者

vLLM 是目前开源圈最火的，它的 PagedAttention 确实牛。在我们的“高并发短对话（输入500 token，输出200 token）”场景下，它的吞吐量（Tokens/s）稳居第一。

❌ 踩坑实录：千万别开启默认的 chunked-prefill（分块预填充）！
我在生产上为了图省事直接 python -m vllm.entrypoints.openai.api_server，结果高并发时延迟 P99 飙升到 10 秒以上。
原因：在同时处理长上下文和短上下文时，vLLM 的调度器为了拉满吞吐量，会把 prefill 和 decode 混在一起，导致短文本请求被长文本计算“卡住”。

✅ 正确配置：

python -m vllm.entrypoints.openai.api_server \
  --model Qwen/Qwen2-72B-Instruct \
  --disable-custom-all-reduce \
  --enable-chunked-prefill=False  # 关键！延迟敏感业务必须关掉，或者限制 max_num_seqs

2. SGLang：复杂 Prompt 的性能怪兽

这是 LMSYS 团队放出的王炸。它两个核心特性：RadixAttention（前缀树缓存） 和 约束解码。
我们的业务有个复杂的 Few-shot 提示词，加起来有 3000 token，但每次只有最后一句用户输入在变。用 vLLM 时，每次都要重新跑一遍 Prefix，慢得要死。

切到 SGLang 后，相同的系统提示词直接命中缓存，首字响应（TTFT）时间从 1200ms 暴降到 350ms，性能暴涨 300%！

❌ 踩坑实录：部署时如果把 SGLang 放在 Docker 容器里，且开启了多机多卡，NCCL 通信极其容易卡死。
✅ 正确做法：如果是 Docker 部署，务必开启宿主机的 IPC 共享。

docker run --gpus all --shm-size 16G -it ... # --shm-size 必须给够！

3. TensorRT-LLM：高攀不起的性能天花板

老黄的亲儿子。我们花了极大精力把模型转成 TensorRT 的 engine 格式编译后，单看延迟确实比 vLLM 快了大概 15%。
但是！它实在太重了，你只要改一行业务代码的提示词模板，或者换个模型，你就得重新走一遍繁琐的编译流程。如果你没有专门的算法/部署工程师去维护这套流转线，千万别碰它。

4 & 5. LMDeploy & TGI

• LMDeploy (商汤)：对 internLM 系列优化极好，但生态不如 vLLM 丰富，稳定性在常规场景下表现中规中矩。
• TGI (HuggingFace)：起步早，兼容性好。但我们压测时发现，在极长上下文（>16k）时，它的 P99 延迟极高，目前我们团队已经基本将其从备选库中剔除。

💬 你怎么看？
上面提到 vLLM 的吞吐量和 SGLang 的 RadixAttention 前缀缓存。在你们公司的实际业务中，大模型应用是偏向于多轮短对话（客服/AI助手），还是偏向于重度长文本分析（文档总结/RAG外挂）？

1. 主打短平快，我们坚定不移用 vLLM。
2. 死磕长文本和复杂 RAG，SGLang 才是未来。
3. 财大气粗/对延迟要求苛刻，直接梭哈 TensorRT-LLM。
   欢迎在评论区留下你们的真实技术选型，我看看大家的业务侧重点都在哪！

落地工作流总结（给架构师的 5 条避坑清单）：

1. 测试先于选型：不要只看 Benchmark 跑分，一定要拿你们自己真实业务的 Prompt 分布去压测。短文本和长文本的配比，直接决定了最终的吞吐表现。
2. 监控指标抓重点：别光盯着 QPS，核心盯住 GPU 显存占用率、KV Cache 命中率、P99 延迟。尤其是 P99，业务方对卡顿极其敏感。
3. 部署隔离：长短文本请求务必分开部署到不同的推理集群，千万不要把它们塞进同一个框架实例中，否则调度器会让你痛不欲生。
4. 保留降级方案：无论你选哪个开源框架，务必在网关层加上熔断机制。例如用 OneAPI 或者 Higress 做统一控制，发现推理节点 OOM 立刻重启并切流。
5. 对齐 CUDA 版本：无数血泪史证明，报 80% 的部署 Bug 都是因为底层 CUDA / cuDNN 版本和框架要求的版本对不上。

写了这么多，如果你在搞 RAG 或者大模型落地时，也被推理延迟搞到头皮发麻，或者遇到过奇奇怪怪的 OOM 问题，欢迎在评论区说出你的“惨案”！
点赞收藏不迷路，顺手点个关注，下一期我将手把手教大家《在生产环境如何用 Nginx + Lua 玩转大模型网关的“长连接保活与高并发熔断”》，绝对硬核，我们下期见！