先说结论：如果你在IDC里按词元向客户收费，Triton-Proxy是唯一让我半夜不用爬起来改配置的。但如果你是自用或内部研发，vLLM-Gateway的吞吐量能让你省下一半带宽钱。
测试环境与近期背景：就在上周，GitHub上有个issue炸了——某中型IDC用FastChat-Router做多租户推理，结果因为流式响应中词元边界截断错误，单次对话多算了近300个词元，客户直接投诉到工信部。我这次特意用Locust模拟了500并发、平均输入800词元、输出400词元的场景，同时用iftop盯住25G网口的实际流量。
vLLM-Gateway：快，但别拿来收钱。优点很明显——基于PagedAttention的连续批处理让它的词元吞吐达到每秒4200个，比另两家高出27%。配合25G网卡，实际带宽跑到了18.7Gbps。缺点是它的计量模块就是个摆设：流式返回时每个chunk的usage字段都是累计值而不是增量，你得自己写中间件去算差值。我试着在IDC计费场景下用，两小时就出现了6次词元统计偏差超过15%的情况。适用人群：预算充足的自建推理团队，不在乎计费精度。
Triton-Proxy：计费稳如老狗，但带宽吃相难看。它的词元统计是基于每个response的完整tokenize结果再切割，误差控制在0.3%以内。实测中我故意注入10%的乱码输入，它依然能准确扣掉无效词元。但槽点来了：为了实现精确计量，它会把每个流式响应先完整缓存在内存里再转发，导致首词元延迟从vLLM的38ms飙到210ms。更麻烦的是，当并发超过300时，它的内部队列会积压，带宽利用率只有12Gbps左右，大量时间在等内存拷贝。适用人群：IDC服务商、需要向客户出具精确账单的团队。
FastChat-Router：轻量但别碰多租户。它胜在部署简单，一个docker-compose就能跑起来，内存占用不到另两家的三分之一。但在我的压力测试中，当词元输出速率超过每秒2000个时，它的路由表会出现竞态条件，把同一个请求同时发给两个后端worker，导致词元翻倍。而且它的网络软件层没有做TCP_NODELAY调优，小包延迟抖动高达±80ms。适合个人开发者在本机跑着玩，千万别放到IDC生产环境。
最后给个硬建议：如果你的IDC按词元收费，直接上Triton-Proxy并加一块P4网卡做硬件时间戳；如果只是内部推理集群，vLLM-Gateway+自己写的计费sidecar更划算。FastChat？等它把那个竞态bug修了再说吧。
0 留言