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 最容易翻车的地方。

坑三：两种 backend 怎么选？ Triton 提供两种打包方式：Python backend（vLLM 作为 Python 包在 Triton 进程内运行）和 vLLM backend（专用 backend，模型与前端解耦）。Netflix 选了 vLLM backend，因为模型与前端能"更独立地演进"——模型升级不用带动前端代码改动，前端改 schema 也不用重新打包模型。

坑四：统一接口没消除底层差异。 Triton 暴露了 OpenAI 兼容 API 和 KServe 的 HTTP/gRPC 前端，应用团队写代码可以"看哪个顺眼用哪个"。但 Netflix 在集成时撞到了某些功能处理上的差异——同一段约束解码逻辑，在不同接口下的行为细节不一致。

双引擎的隐性成本，是把"框架间的脏活"从应用层挪到了平台层。 应用团队省心了，平台团队多了一倍的工作。

行业对照：优步的做法

Netflix 不是孤例。优步的生成式 AI 网关在外部托管模型和内部管理模型之间提供 OpenAI 兼容接口，集中处理认证、缓存、可观测性、路由这些横切关注点。

两家做法不同——Netflix 把推理能力托管在内网，优步在外部托管和内管之间切换——但两家都在做同一件事：把应用集成和底层模型、运行时、托管环境分离。

大厂共识：应用团队只需要一个稳定的接口面，模型怎么换、引擎怎么升级，那都是平台团队的活。

真正的胜负手：在哪？

看到这里，可能会问：Triton 和 vLLM 谁会吃掉谁？

短期看不会。两者职责本就不同——Triton 解决"调度 + 多框架"，vLLM 解决"显存 + 推理效率"。开源项目经常被合并，但生产场景的边界感比代码库的边界感更强。

长期看，更值得追问的是：当模型厂商自己也开始做平台层（Anthropic、Google、OpenAI 都在推自家 serving stack），大厂的"自建平台"还能守住多少价值？

Netflix 给出的答案是：守住**"接得住几家厂商同时换引擎"**的工程能力。当 OpenAI 推新模型、Anthropic 推新约束、Google 推新芯片，平台能在不打扰应用团队的前提下完成切换——这才是真正的胜负手。

大厂的 LLM 基建竞赛，已经从"模型层"下沉到"推理运行时"。

行动清单（给平台团队的）

1. 把你的 Triton+vLLM 版本矩阵画出来，每一组"已验证组合"打成内部 release，没有矩阵就别升级任一方
2. 给约束解码场景加状态快照，vLLM 暂停/恢复时的状态漂移是已知问题，靠检测+回滚兜底比等官方修复快
3. 把 backend 选择和"模型-前端耦合度"绑在一起评估，Python backend 灵活但耦合，vLLM backend 解耦但新版本要等 Triton 同步发布

平台层的胜负，从来不是"用了哪个框架"，是"哪个团队的运维活做得最干净"。

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