Netflix 的 vLLM 与 Triton 推理栈：7 个生产经验
社交媒体上的版本很简单：Netflix 不再给 AI 供应商付费，所有东西都自己做。真正有用的版本要精确得多。Netflix 的 AI Platform 团队公开了一条由 NVIDIA Triton 与 vLLM 组成的内部 LLM 服务路径，并解释它为什么适合相关工作负载、在生产并发下哪里会失效，以及外围还需要补上什么。
如果你在做推理架构决策，这个边界很重要。复制组件清单只能得到软件，复制决策边界才能得到运营模型。本文只讨论后者。成本、欧盟数据驻留与通用盈亏平衡问题，仍由我们的欧盟 LLM 自托管成本指南负责，两个页面不会争夺同一搜索意图。
Netflix 是否使用 OpenAI？
不能据此断言 Netflix 从不使用 OpenAI。在另一个名为 MediaFM 的 Netflix 系统中，团队明确写到，他们用 OpenAI 的 text-embedding-3-large 处理定时文本与标题元数据。内部推理文章能证明 Netflix 为部分工作负载运营 vLLM 与 Triton 路径，却不能证明公司全面禁用托管模型。
对采购者而言，更强的结论是：成熟的 AI 体系可以按工作负载选择不同推理通道。托管 API 适合快速实验或复制成本过高的能力。内部服务适合自定义模型、专有解码规则、稳定负载或更严格的控制。架构应跟随工作负载边界，而不是跟随一句公司口号。
Netflix 的 LLM 服务架构是什么样？
公开设计可以拆成四层。现有应用通过 gRPC 调用统一的 JVM 服务系统，由它负责路由、A/B 分配、特征获取、预处理与后处理。大模型被委托给共享推理后端 Model Scoring Service。下层由 NVIDIA Triton 管理模型加载与 GPU 执行，vLLM 则是 LLM 工作负载的首选引擎。
- 消费方契约：传统 ML 与 LLM 使用同一个 scoring 抽象。
- 服务工作流：路由、实验与数据准备不塞进推理引擎。
- 控制平面：部署、健康检查、自动扩缩、模型版本与多区域发布仍由平台负责。
- 推理平面：Triton 托管后端，vLLM 负责 LLM 调度、batch 与解码。
较新的 LLM 应用还可以使用兼容 OpenAI 的 HTTP 前端。这是接口选择，不代表请求由 OpenAI 托管模型处理。把协议与供应商分开，调用方可以继续使用熟悉的客户端，平台则能替换后端引擎。
Netflix 为什么选择 vLLM 而不是 TensorRT-LLM？
Netflix 最初使用 TensorRT-LLM。到 2025 年夏季，团队认为开源引擎在自身工作负载上的性能差距已经明显缩小，运维适配度因此成为主导因素。vLLM 无需原先的多步编译流程就能加载自定义架构，提供自定义解码扩展点，更容易检查中间状态，而且研究人员已经熟悉它。
| 决策因素 | 为什么重要 | 你的团队该问什么 |
|---|---|---|
| 架构变化速度 | 自定义模型无需单独编译工件流程即可进入服务 | 模型形状与自定义层多久变化一次？ |
| 可调试性 | 工程师更容易查看引擎状态与失败原因 | 凌晨两点由谁诊断加载失败？ |
| 解码扩展性 | 自定义 logits 处理是 Netflix 约束逻辑的核心 | 标准结构化输出 API 是否足够？ |
| 团队熟悉度 | 研究人员已经使用 vLLM | 模型作者能否在交接前复现生产行为？ |
| 峰值跑分 | 仍然重要，但不能单独决定 | 测试是否覆盖真实模型、batch 与约束？ |
这不是 vLLM 对 TensorRT-LLM 的永久排名，两个项目都在持续变化。可重复的方法是：先用真实负载做基准，再计算研究、部署、调试与回滚之间的完整工程成本。每秒多几个 token，无法弥补一个团队不敢安全修改的平台。
约束解码为什么撞上 Python GIL？
约束解码在生成过程中阻止无效 token，而不是在输出错误后再验证或修复。Netflix 把每项约束建模成状态机，每一步都生成允许 token 的 mask。在 vLLM V0 中，自定义 Python 处理器按请求运行。GPU 先产出整个 batch 的 logits，CPU 再逐请求串行执行约束逻辑。batch 越大，CPU 时间越长，因为 Python Global Interpreter Lock 阻止这条热路径并行化。
vLLM V1 提供 batch 级处理模型。Netflix 把处理器改写为 batch 数据结构，并把热路径迁到多线程 C++。当前 vLLM 文档同样定义了batch 级 logits processor 接口，其 apply 方法直接接收 batch logits tensor。
复杂性并没有消失。动态 batch 需要显式更新状态，chunked prefill 可能跨多个引擎步骤。内存吃紧时，preemption 可能移除某个请求的 KV cache，之后用更短的 token 历史重新调度。Netflix 为部分 prefill 增加跟踪，并在历史缩短时重置状态机。处理时间随 batch 保持平坦，来自新的状态模型，而不是一次免费的版本升级。
值得复制的 7 个生产经验
1. 先按运维适配度选型，再跑真实基准
测试代表性模型、并发、提示与输出长度，以及真实约束逻辑。测量首 token 时间、token 间延迟、吞吐与尾延迟，同时计入打包、诊断和升级所需时间。引擎是发布系统的一部分，不是孤立的 benchmark 程序。
2. 把消费方契约放在引擎之上
Netflix 没让每个调用方都理解 vLLM。既有服务层继续负责路由、实验与工作流逻辑。稳定的内部契约让团队替换引擎而无需重写所有产品集成。我们的有状态 LLM 平台生产架构也遵循同一原则：持久产品行为不应依赖某一个模型 runtime。
3. 固定整套兼容组合
Triton 的 vLLM backend 依赖特定 vLLM API。Netflix 报告过版本漂移导致 backend 无法加载的问题。NVIDIA 现在发布容器版本的 Triton 与 vLLM 兼容矩阵。把 Triton 镜像、vLLM、CUDA、驱动与插件当作一个经过测试的单元，不能让模型包单独覆盖其中一项。
4. 测试 API 语义，不只看状态码
Netflix 发现 Triton 的 OpenAI 兼容前端接受了 response_format，却在请求抵达 vLLM 前静默丢弃它。调用成功，承诺的输出约束却消失了。Netflix 修补了转换层。NVIDIA 当前的 Triton OpenAI 兼容前端文档展示了前端与 vLLM backend 的组合方式，但你的契约测试仍需验证每个关键字段实际生效。
5. 让发布策略匹配接口风险
模型接口稳定时，Netflix 使用 Red-Black 部署。新版本与旧版本并行启动，通过健康检查后分阶段切流。tensor 形状变化会让旧消费方与新模型发生重叠冲突，此时版本化部署让两套接口同时服务，直到消费方完成迁移。暂时多出的 GPU 成本购买了一段安全兼容窗口。
6. 把权重放到能接受的启动路径上
从对象存储下载大模型让冷启动过慢，因此 Netflix 在模型发布时把它们物化到 Amazon FSx。AWS 文档说明，与 S3 连接的 FSx for Lustre 文件首次访问会产生额外延迟，除非团队预加载所需文件内容。通用规则与云厂商无关：权重放置属于部署流程，readiness 前必须验证，并且要在空节点而非热开发机上测冷启动。
7. 合并引擎与服务器可观测性
Triton bridge 只暴露 Netflix 所需 vLLM 指标的一部分。团队把 Triton 指标与 vLLM 的 Prometheus 多进程文件合并到一个 endpoint。最小仪表盘应同时看到请求率、排队时间、首 token 时间、token 间延迟、吞吐、KV cache 利用率、prefix cache 命中、preemption、模型加载状态、错误与 GPU 饱和度。GPU 图表全绿时，CPU logits 路径仍可能已经坏掉。
你的公司该复制 Netflix，还是继续使用托管 API？
| 信号 | 托管或管理式推理 | 内部 vLLM 与 Triton 平台 |
|---|---|---|
| 需求 | 低、不确定或突发 | 足够稳定，可以规划 GPU 容量 |
| 模型需求 | 标准模型与 API 能力 | 自定义架构、插件或解码规则 |
| 变更责任 | 希望供应商管理升级 | 平台团队能固定、测试和回滚 |
| 数据边界 | 合同约束下的外部处理可接受 | 推理必须留在受控基础设施内 |
| 可观测性 | 供应商指标足够 | 需要 token、cache 与调度器证据 |
| 故障预算 | 更偏好供应商故障切换 | 能运营多版本 GPU 发布与值班 |
只有当至少一项差异化需求通过了严肃的管理式服务评估，才应选择内部平台。自定义约束解码、稳定高负载或严格数据边界都可能成立。单纯不喜欢按 token 计费，不是一套架构。
一套 90 天验证计划
- 第 1 至 2 周，定义契约：固定代表性提示、响应 schema、延迟目标、质量评测与失败行为，记录托管基线。
- 第 3 至 5 周，测试真实路径：以生产级并发、约束和模型变体测试候选引擎，包含 CPU 工作与冷启动。
- 第 6 至 8 周，证明可运营：固定镜像组合、预加载权重、统一指标，演练模型加载失败与回滚。
- 第 9 至 10 周，运行影子流量：在不返回用户可见响应的前提下比较质量、延迟与 schema 合规。
- 第 11 至 13 周，做商业决策：比较平台全成本与托管账单，并计入工程时间、冗余、支持与升级。
如果主要约束是延迟，请把服务架构与模型所有权分开。我们对共享 KV cache 降低首 token 延迟的分析说明，一项针对性基础设施改动可能已经足够，无需替换整条推理路径。
Netflix、vLLM 与 Triton 常见问题
Netflix 是否把所有 LLM 推理都放在内部？
Netflix 为什么偏好 vLLM 而不是 TensorRT-LLM？
约束解码瓶颈来自哪里？
运行 vLLM 是否必须使用 NVIDIA Triton？
规模较小的公司何时该自托管 LLM 推理？
真正需要掌控的是运营边界
Netflix 最强的经验不是一串品牌名，而是所有权顺序：保持稳定消费方契约，用真实负载选引擎，把 runtime 固定成一个单元，验证 API 承诺是否到达解码器，让发布策略匹配兼容风险，把权重纳入部署路径，并共同观察 CPU、cache、调度器与 GPU。
Wavect 的 AI Enablement 与推理架构服务覆盖从工作负载基准到生产交接的整套评估。Twinsoft AI 案例展示我们如何把 AI 决策转成经过测试的产品工作流。你可以用从原型到生产的决策指南规划更广的平台工作，也可以申请一次推理架构评审，从现有流量、数据与模型约束出发。