sglang vs vllm vs tensorrt

手上有一批卡、要跑一个开源模型对外提供服务，同事问你为什么不用另一个引擎，你答不上来——这种情况太常见了。这篇不堆跑分，只给判断顺序：先看你的硬件是不是被锁死、再看你的请求形态是长提示还是长输出、最后看团队能不能扛住编译和版本对齐的维护成本。每一步都告诉你在什么条件下这个结论不成立。

手上有一批卡、要跑一个开源模型对外提供服务，同事问你为什么不用另一个引擎，你答不上来——这种情况太常见了。问题往往不在于谁更快，而在于你没把约束条件排清楚：卡是什么型号、请求是长提示还是长输出、团队有没有人愿意长期跟版本。这三个条件一变，答案就跟着变。

这篇不堆数字，只给判断顺序。每一步都告诉你在什么条件下这个结论不成立，避免把别人的场景直接搬到自己身上。想先有个整体印象，可以到 /inference 看同类开源模型的部署与比价概况，但别拿别人的结论当自己的选型依据。

先看硬件：这一步就能砍掉一个选项

选型第一步不该是比吞吐，而是确认候选引擎能不能在你的卡上稳定跑起来。TensorRT 系推理对显卡世代和驱动版本比较敏感，卡不在它支持的那几代范围内，编译环节就可能直接卡住，这时候不用比吞吐，直接排除。SGLang 和 vLLM 更贴近通用 GPU 生态，但如果你用的是国产卡或非主流加速卡，也要先确认有没有对应分支和算子支持，别默认能跑。

再看请求形态：长提示和长输出，选法不一样

硬件过关之后，下一步不是看总吞吐，而是看你的请求长什么样。前缀复用比例高的情况——比如同一份长文档被反复提问、few-shot 示例固定不变——前缀缓存的收益最明显，这是选型时要重点验证的能力。反过来，输入短、输出长的生成型请求，压力点更多落在解码调度和显存占用上，和前者完全不是一回事。

• 先从线上日志拉出输入长度和输出长度的分布，别用别人的合成数据代替
• 把峰值并发、平均并发、突发时长一起统计，单看均值会误判
• 到 /tools/speed-test 用你自己的请求比例量一遍延迟基线，记录稳定态而不是峰值
• 同一份流量在两个候选引擎上各压一轮，重点看长尾延迟和队列堆积
• 确认前缀缓存的命中条件，比如提示前缀是否严格一致、是否跨会话复用

判断顺序是：先有真实长度分布，再有延迟基线，两者合起来才能判断哪种引擎更贴合。如果你的请求量很小、并发长期是个位数，这一层的差异会被冷启动和排队淹没，不必过度纠结。想对照不同引擎在真实服务里的表现，可以到 /rankings 看当时的横向记录，注意那是别人的流量形态。

部署难度：真正花钱的是维护，不是第一次跑通

启动一个服务、加载权重、暴露一个兼容接口，这三个动作各家都有现成路径，第一次跑通通常不难。难的是换模型版本、换卡、调并发参数的时候还能不能快速复现。第一次跑通花一天，之后每次升级都花一周，这种账要提前算，而不是等线上出问题才发现没人能改。

1. 记录一条可复现路径把镜像、依赖版本、启动参数写成脚本，任何人照着能起一份一样的环境，验证方式是换台机器执行一遍
2. 验证换模型成本同一引擎换一个模型或换量化档位，看要不要重新编译算子、要不要重下缓存，记录耗时和磁盘占用
3. 验证换卡成本把服务从一张卡迁到另一张不同型号的卡，看配置改动量，这一步最容易暴露隐性绑定
4. 评估版本对齐负担算子编译类方案首次构建慢、缓存体积大，团队若没有专人跟版本，升级一次模型可能要重排一轮工期

量化档位和引擎的搭配也是常见的坑：不是所有量化格式在每个引擎里都能吃到加速，有的只是省显存、不提速，甚至因为额外的反量化开销变慢。选之前到 /models/deploy 按模型和量化方式算一遍显存与卡数，再决定用哪一档。如果只是一次性实验、不打算长期维护，首次构建的麻烦可以忍；一旦要对外提供稳定服务，维护成本必须算进选型里。

落地清单：四步走完再拍板

前面三节是排除法，这一节是可执行流程。原则是先用真实约束砍掉不合适的选项，再用同一份流量做对比，最后留一条能换引擎的后路。每一步都有明确的验收动作，不是走形式。

接口层保持 OpenAI 兼容，引擎换了只改后端——选型时给自己留的这条后路，比任何一个跑分都值钱。

拍板前把业务代码和引擎的私有参数解耦，不要把调度参数写进业务逻辑里。如果只有单卡、只服务内部几个人，挑最省事的那条路就行，没必要走完整流程；但一旦要对外提供有承诺的服务，回退路径和监控必须提前准备好，否则换引擎的代价会远高于当初省下的时间。