|
查看: 40|回复: 23
|
[行业资讯]
开源推理引擎吞吐量对比：vLLM和SGLang和TRT-LLM实测
[复制链接]
|
UID2
贡献9 点
钻石7 个
C币993 个
|
手头有四张A100 40G，上周跑了一轮推理引擎对比，测的模型是Qwen2.5-72B和Llama3-70B，都是AWQ 4-bit量化。三套引擎：vLLM 0.6.3、SGLang 0.4.1、TensorRT-LLM 0.13.0。
vLLM的吞吐量在并发64的场景下大概是2100 tokens/s，P99延迟2.3秒。SGLang在同条件下到了2400左右，延迟压到1.8秒，主要优势在它的RadixAttention缓存复用，重复前缀多的场景提升明显。TRT-LLM最高，到了2800，但编译engine花了快两小时，而且换个模型就得重新编译，灵活性太差。
实际选型的话我觉得分场景：在线服务对延迟敏感的，SGLang现在是最优解，社区也很活跃；离线批量推理不在意启动时间的，TRT-LLM吞吐最高；快速验证和原型阶段，vLLM最省心，文档好生态全。
还有个细节，vLLM从0.6开始默认开了chunked prefill，对长上下文场景的TTFT改善很大，之前0.5版本跑128K context要等十几秒首token，现在压到了4秒以内。 |
温馨提示：
1、在论坛里发表的文章仅代表作者本人的观点，与本网站立场无关。
2、论坛的所有内容都不保证其准确性，有效性，时间性。阅读本站内容因误导等因素而造成的损失本站不承担连带责任。
3、当政府机关依照法定程序要求披露信息时，论坛均得免责。
4、若因线路及非本站所能控制范围的故障导致暂停服务期间造成的一切不便与损失，论坛不负任何责任。
5、注册会员通过任何手段和方法针对论坛进行破坏，我们有权对其行为作出处理。并保留进一步追究其责任的权利。
6、网络世界也请遵守我国的法律法规！一旦发现违法行为，将立即封存相关信息并报警处理！
|
|
|
|
|
|
|
|
|
|
|
匿名
发表于 2026-9-17 18:33:41
|
|
|
|
|
|
|
|
|
|
|
发表于 2026-9-17 18:46:12
|
显示全部楼层
|
现在工具链更新太快，半年前的最佳实践今年可能就过时了。 |
|
|
|
|
|
|
|
|
|
|
|
发表于 2026-9-17 18:54:04
|
显示全部楼层
|
|
|
|
|
|
|
|
|
|
|
发表于 2026-9-17 18:58:49
|
显示全部楼层
|
|
|
|
|
|
|
|
|
|
|
发表于 2026-9-17 19:07:36
|
显示全部楼层
|
这个结论我保留意见，至少在我们行业不太成立，可能跟样本有关。 |
|
|
|
|
|
|
|
|
|
|
|
发表于 2026-9-17 19:12:38
|
显示全部楼层
|
把工作流拆细之后，能自动化的比例其实没有想象中高。 |
|
|
|
|
|
|
|
|
|
|
|
发表于 2026-9-17 19:19:39
|
显示全部楼层
|
真正跑通的案例里，投入的人力成本往往被忽略不计了。 |
|
|
|
|
|
|
|
|
|
|
|
发表于 2026-9-17 19:29:34
|
显示全部楼层
|
提示词工程能解决一部分，但解决不了根本的领域知识问题。 |
|
|
|
|
|
|
|
|
|
|
|
发表于 2026-9-17 19:37:39
|
显示全部楼层
|
小团队做这个真不如直接用现成 API，自建维护成本太高。 |
|
|
|
|
|
|
|
|
|
温馨提示：
1、在论坛里发表的文章仅代表作者本人的观点，与本网站立场无关。
2、论坛的所有内容都不保证其准确性，有效性，时间性。阅读本站内容因误导等因素而造成的损失本站不承担连带责任。
3、当政府机关依照法定程序要求披露信息时，论坛均得免责。
4、若因线路及非本站所能控制范围的故障导致暂停服务期间造成的一切不便与损失，论坛不负任何责任。
5、注册会员通过任何手段和方法针对论坛进行破坏，我们有权对其行为作出处理。并保留进一步追究其责任的权利。
6、网络世界也请遵守我国的法律法规！一旦发现违法行为，将立即封存相关信息并报警处理！
发表于 2026-5-30 00:38:43
