Netflix 把 LLM 推理拆成两层：Triton 站台、vLLM 上灶

2026 年 8 月，Netflix 在工程博客里详述了内部 LLM 服务平台的搭建过程。一个意外细节是：他们没有把所有鸡蛋放在一个篮子里——选了 Triton 做"前台调度"，选 vLLM 做"后厨推理"。两家引擎版本不对齐，模型部署直接失败。

这不是技术洁癖，是被生产环境逼出来的工程选择。

为什么不是单一引擎

市面上的 LLM 推理框架不少。vLLM 凭 PagedAttention 把显存利用率拉满，Triton 在多模型、多框架调度上稳坐头把交椅，SGLang 走 radix attention 路线，TensorRT-LLM 把 NVIDIA 生态焊死。

选一个用，听起来最省事。Netflix 没这么干。

生产环境的真实复杂度是"几十种模型给几百种调用方"。 推荐系统、内容标记、搜索、A/B 测试分流，每个场景要的模型规模、延迟、吞吐、合规约束都不一样。统一的"单引擎"听起来优雅，遇到自定义架构、长上下文、约束解码这些硬骨头就塌。

Netflix 的解法是分层：Triton 负责"模型怎么上架、谁来访问、流量怎么切"，vLLM 负责"token 怎么算、显存怎么分、KV cache 怎么复用"。前者是调度问题，后者是计算问题。这两件事不该被一个框架绑死。

单一推理框架撑不住"几百种模型 × 几万种调用方"的真实生产负载。 双引擎不是过度工程，是基础设施复杂度的必然结果。

架构怎么落：CPU 一条线、GPU 一条线

Netflix 平台的整体架构有两条平行的路径。

CPU 路径跑轻量模型（小于 10 亿参数），直接在 JVM 进程内做推理，零网络开销、零调度损耗。这条路径吃掉了平台大部分小模型调用——比如简单分类、特征提取这类对延迟极敏感的场景。

GPU 路径跑重型模型，应用调用进入 JVM 服务层后，Netflix 把请求委托给 MSS（Model Serving Service），由 Triton 负责模型加载、动态批处理、GPU 调度和多框架服务，最后由 vLLM 执行推理。

这种"双路径"设计有个隐藏好处：小模型和大模型各自走自己最合适的硬件，避免把 GPU 浪费在简单任务上。 大厂 GPU 资源是按分钟计费的浪费，让每个 H100 都跑在它该跑的负载上，比"统一上 GPU"省钱得多。

四个坑：双引擎的真实代价

听起来很美，做起来全是坑。Netflix 自己爆出来的有四个。

坑一：版本必须一起钉死。 Triton 和 vLLM 是两个独立开源项目，发布节奏不同步。Netflix 报告"不匹配的 Triton 与 vLLM 版本可能导致部署无法加载"——这意味着每次任一方升级，另一方也得跟着验证一遍。他们现在把"经过验证的版本组合"作为内部 release 单元固定下来。双引擎架构的成本，第一笔就花在"版本对齐矩阵"的维护上。

坑二：约束解码的状态会丢。 当应用要求模型输出合法 JSON、SQL 或结构化数据时，推理引擎需要在每一步过滤可能的 token 集合。这个"合法 token 集合"依赖前面所有已生成的 token，是一个会随推理过程演化的状态机。vLLM 为了管理 GPU 资源会把请求暂停、释放显存去处理别的请求，恢复时——状态可能已经漂移。Netflix 加了一段检测逻辑，发现漂移就重建状态机或回滚到最近一致点。约束解码是 vLLM 的卖点，也是 vLLM 最容易翻车的地方。

<!-- OSS URLs will replace placeholders before publish -->