--- title: "Netflix 的 vLLM 与 Triton：生产经验" canonical: https://wavect.io/zh/blog/netflix-vllm-triton-inference-stack/ language: zh description: "拆解 Netflix 的 vLLM 与 NVIDIA Triton 推理栈：约束解码、GIL 瓶颈、部署、缓存、指标，以及一套务实的自建或采购判断。" image: "https://wavect.io/img/blog/headers/header_netflix-vllm-triton-inference-stack.png" --- [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年8月16日 最近审核 2026年8月16日 [**下一篇**](/zh/blog/self-hosting-llms-eu-cost/) # Netflix 的 vLLM 与 Triton 推理栈：7 个生产经验 要点速览 Netflix 公开了一条内部 LLM 服务路径：统一服务层调用 Model Scoring Service，底层由 NVIDIA Triton 与 vLLM 承担推理。团队从原先的 TensorRT-LLM 路径转向 vLLM，原因不是一个脱离场景的跑分，而是自定义架构接入更快、调试更直接、扩展点更合适，而且研究人员已经熟悉它。生产环境随后暴露了简单基准看不到的问题：Python logits processor 在 batch 扩大后受 CPU 限制，API 字段可能被接受后静默丢弃，模型下载拖慢启动，不兼容的 Triton 与 vLLM 版本在加载时失败，分散指标则掩盖服务真实状态。可迁移的经验是，先掌控接口契约、测试、发布与可观测性，再决定是否掌控每个推理组件。低量或突发需求仍适合托管 API；只有当自定义解码、稳定负载、隐私或模型控制足以支撑专门平台团队时，自建栈才更可信。 社交媒体上的版本很简单：Netflix 不再给 AI 供应商付费，所有东西都自己做。真正有用的版本要精确得多。Netflix 的 AI Platform 团队公开了 [一条由 NVIDIA Triton 与 vLLM 组成的内部 LLM 服务路径](https://netflixtechblog.com/in-house-llm-serving-at-netflix-a5a8e799ea2c) ，并解释它为什么适合相关工作负载、在生产并发下哪里会失效，以及外围还需要补上什么。 如果你在做推理架构决策，这个边界很重要。复制组件清单只能得到软件，复制决策边界才能得到运营模型。本文只讨论后者。成本、欧盟数据驻留与通用盈亏平衡问题，仍由我们的 [欧盟 LLM 自托管成本指南](/zh/blog/self-hosting-llms-eu-cost/) 负责，两个页面不会争夺同一搜索意图。 ## Netflix 是否使用 OpenAI？ 不能据此断言 Netflix 从不使用 OpenAI。在另一个名为 MediaFM 的 Netflix 系统中，团队明确写到，他们用 [OpenAI 的 text-embedding-3-large 处理定时文本与标题元数据](https://medium.com/netflix-techblog/mediafm-the-multimodal-ai-foundation-for-media-understanding-at-netflix-e8c28df82e2d) 。内部推理文章能证明 Netflix 为部分工作负载运营 vLLM 与 Triton 路径，却不能证明公司全面禁用托管模型。 对采购者而言，更强的结论是：成熟的 AI 体系可以按工作负载选择不同推理通道。托管 API 适合快速实验或复制成本过高的能力。内部服务适合自定义模型、专有解码规则、稳定负载或更严格的控制。架构应跟随工作负载边界，而不是跟随一句公司口号。 ## Netflix 的 LLM 服务架构是什么样？ 公开设计可以拆成四层。现有应用通过 gRPC 调用统一的 JVM 服务系统，由它负责路由、A/B 分配、特征获取、预处理与后处理。大模型被委托给共享推理后端 Model Scoring Service。下层由 NVIDIA Triton 管理模型加载与 GPU 执行，vLLM 则是 LLM 工作负载的首选引擎。 1. **消费方契约：** 传统 ML 与 LLM 使用同一个 scoring 抽象。 2. **服务工作流：** 路由、实验与数据准备不塞进推理引擎。 3. **控制平面：** 部署、健康检查、自动扩缩、模型版本与多区域发布仍由平台负责。 4. **推理平面：** 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 接口](https://docs.vllm.ai/en/latest/api/vllm/v1/sample/logits_processor/index.html) ，其 `apply` 方法直接接收 batch logits tensor。 复杂性并没有消失。动态 batch 需要显式更新状态，chunked prefill 可能跨多个引擎步骤。内存吃紧时，preemption 可能移除某个请求的 KV cache，之后用更短的 token 历史重新调度。Netflix 为部分 prefill 增加跟踪，并在历史缩短时重置状态机。处理时间随 batch 保持平坦，来自新的状态模型，而不是一次免费的版本升级。 ## 值得复制的 7 个生产经验 ### 1. 先按运维适配度选型，再跑真实基准 测试代表性模型、并发、提示与输出长度，以及真实约束逻辑。测量首 token 时间、token 间延迟、吞吐与尾延迟，同时计入打包、诊断和升级所需时间。引擎是发布系统的一部分，不是孤立的 benchmark 程序。 ### 2. 把消费方契约放在引擎之上 Netflix 没让每个调用方都理解 vLLM。既有服务层继续负责路由、实验与工作流逻辑。稳定的内部契约让团队替换引擎而无需重写所有产品集成。我们的 [有状态 LLM 平台生产架构](/zh/blog/stateful-llm-platform-production-architecture/) 也遵循同一原则：持久产品行为不应依赖某一个模型 runtime。 ### 3. 固定整套兼容组合 Triton 的 vLLM backend 依赖特定 vLLM API。Netflix 报告过版本漂移导致 backend 无法加载的问题。NVIDIA 现在发布容器版本的 [Triton 与 vLLM 兼容矩阵](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/introduction/compatibility.html) 。把 Triton 镜像、vLLM、CUDA、驱动与插件当作一个经过测试的单元，不能让模型包单独覆盖其中一项。 ### 4. 测试 API 语义，不只看状态码 Netflix 发现 Triton 的 OpenAI 兼容前端接受了 `response_format`，却在请求抵达 vLLM 前静默丢弃它。调用成功，承诺的输出约束却消失了。Netflix 修补了转换层。NVIDIA 当前的 [Triton OpenAI 兼容前端文档](https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/client_guide/openai_readme.html) 展示了前端与 vLLM backend 的组合方式，但你的契约测试仍需验证每个关键字段实际生效。 ### 5. 让发布策略匹配接口风险 模型接口稳定时，Netflix 使用 Red-Black 部署。新版本与旧版本并行启动，通过健康检查后分阶段切流。tensor 形状变化会让旧消费方与新模型发生重叠冲突，此时版本化部署让两套接口同时服务，直到消费方完成迁移。暂时多出的 GPU 成本购买了一段安全兼容窗口。 ### 6. 把权重放到能接受的启动路径上 从对象存储下载大模型让冷启动过慢，因此 Netflix 在模型发布时把它们物化到 Amazon FSx。AWS 文档说明，与 S3 连接的 FSx for Lustre 文件首次访问会产生额外延迟，除非团队 [预加载所需文件内容](https://docs.aws.amazon.com/fsx/latest/LustreGuide/preload-file-contents-hsm-dra.html) 。通用规则与云厂商无关：权重放置属于部署流程，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. **第 1 至 2 周，定义契约：** 固定代表性提示、响应 schema、延迟目标、质量评测与失败行为，记录托管基线。 2. **第 3 至 5 周，测试真实路径：** 以生产级并发、约束和模型变体测试候选引擎，包含 CPU 工作与冷启动。 3. **第 6 至 8 周，证明可运营：** 固定镜像组合、预加载权重、统一指标，演练模型加载失败与回滚。 4. **第 9 至 10 周，运行影子流量：** 在不返回用户可见响应的前提下比较质量、延迟与 schema 合规。 5. **第 11 至 13 周，做商业决策：** 比较平台全成本与托管账单，并计入工程时间、冗余、支持与升级。 如果主要约束是延迟，请把服务架构与模型所有权分开。我们对 [共享 KV cache 降低首 token 延迟](/zh/blog/shared-kv-cache-llm-inference-latency/) 的分析说明，一项针对性基础设施改动可能已经足够，无需替换整条推理路径。 ## Netflix、vLLM 与 Triton 常见问题 ### Netflix 是否把所有 LLM 推理都放在内部？ Netflix 公开了一条内部 vLLM 与 Triton 服务路径，但也在另一套 MediaFM 系统中公开使用 OpenAI embeddings。证据支持按工作负载选架构，而不是所有 Netflix AI 都自托管的说法。 ### Netflix 为什么偏好 vLLM 而不是 TensorRT-LLM？ 对 2025 年重新评估的工作负载，Netflix 在开源引擎性能已经具有竞争力后，更看重自定义架构支持、解码扩展性、可调试性与研究人员熟悉度。这是特定场景决策，不是永久排名。 ### 约束解码瓶颈来自哪里？ vLLM V0 在 GPU 生成 batch logits 后按请求运行 Python 处理器。CPU 工作随 batch 增长，Python GIL 又阻止并行。Netflix 转向 vLLM V1 的 batch 级处理与多线程 C++ 热路径。 ### 运行 vLLM 是否必须使用 NVIDIA Triton？ 不需要。vLLM 可以直接提供 OpenAI 兼容服务。需要共享模型仓库、多种 backend、控制平面集成或成熟服务器运维时，Triton 才更相关，同时也增加了必须固定和测试的兼容面。 ### 规模较小的公司何时该自托管 LLM 推理？ 当自定义解码、自定义模型、严格数据边界或稳定利用率带来可量化优势，并且团队能负责升级、可观测性、回滚和值班时再考虑。对低量、突发或标准需求，管理式推理通常是更简单的起点。 ## 真正需要掌控的是运营边界 Netflix 最强的经验不是一串品牌名，而是所有权顺序：保持稳定消费方契约，用真实负载选引擎，把 runtime 固定成一个单元，验证 API 承诺是否到达解码器，让发布策略匹配兼容风险，把权重纳入部署路径，并共同观察 CPU、cache、调度器与 GPU。 Wavect 的 [AI Enablement 与推理架构服务](/zh/services/ai-enablement/) 覆盖从工作负载基准到生产交接的整套评估。 [Twinsoft AI 案例](/zh/case-studies/twinsoft-ai/) 展示我们如何把 AI 决策转成经过测试的产品工作流。你可以用 [从原型到生产的决策指南](/zh/software-development-guide/vibe-coded-prototype-to-production/) 规划更广的平台工作，也可以 [申请一次推理架构评审](/zh/contact/) ，从现有流量、数据与模型约束出发。 模型与基础设施 ## 继续浏览此集群 模型选择、推理经济性、本地部署、压缩与服务架构。 [从核心文章开始**在欧盟自托管 LLM：开放权重模型何时才真正划算**](/zh/blog/self-hosting-llms-eu-cost/) - [Transformers.js 浏览器本地 AI：什么时候适合放进产品](/zh/blog/transformers-js-browser-ai-guide/) - [LiteLLM 生产级自托管指南：2026 架构与安全](/zh/blog/self-host-litellm-production-2026/) - [AI 就绪企业 Wiki：架构与实施指南](/zh/blog/ai-ready-company-wiki/) - [Claude 会给文本加水印吗？2026 API 实战解读](/zh/blog/claude-text-watermark-api-2026/) - [OpenKB 评测：知识编译器 vs RAG](/zh/blog/openkb-review-vs-rag/) 只收重要内容 ## 关注与你相关的内容 每当我们发布新文章，你会收到一封简短邮件。你可以关注整个博客，也可以只选感兴趣的主题。 [**返回**](/zh/blog/overview/) [![Kevin Riedl](/img/team/kevin.webp)](/zh/team/kevin-riedl/) [Kevin Riedl](/zh/team/kevin-riedl/) https://linkedin.com/in/wsdt 10 分钟 阅读 · 2026年8月16日 最近审核 2026年8月16日 [**下一篇**](/zh/blog/self-hosting-llms-eu-cost/) 邮件订阅新文章 × × 通过邮件获取新文章 我们发布时给你一封简短邮件。免费，不做跟踪。 ## Structured Data ```json { "@context": "https://schema.org", "@graph": [ { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ], "employee": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "founder": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "legalRepresentative": [ { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } } ], "name": "Wavect GmbH", "subjectOf": { "@id": "https://wavect.io/verified-claims.json#dataset", "@type": "Dataset", "creator": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "description": "A machine-readable registry of quantitative and qualitative claims published by Wavect, with review dates, localized page appearances and public third-party citations where available.", "inLanguage": "en", "isAccessibleForFree": true, "license": "https://creativecommons.org/licenses/by/4.0/", "name": "Wavect verified publication claims", "url": "https://wavect.io/verified-claims.json" }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/team/christof-jori/#person", "@type": "Person", "jobTitle": "Managing Director", "name": "Christof Jori", "sameAs": [ "https://www.wikidata.org/wiki/Q139796367", "https://www.linkedin.com/in/jocr77/", "https://github.com/jo-chris" ], "url": "https://wavect.io/team/christof-jori/", "worksFor": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] } }, { "@id": "https://wavect.io/#website", "@type": "WebSite", "inLanguage": [ "en", "de", "es", "zh" ], "name": "Wavect", "potentialAction": { "@type": "SearchAction", "query-input": "required name=search_term_string", "target": { "@type": "EntryPoint", "urlTemplate": "https://wavect.io/search/?q={search_term_string}" } }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/" }, { "@id": "https://wavect.io/zh/blog/netflix-vllm-triton-inference-stack/#webpage", "@type": "WebPage", "dateModified": "2026-08-16", "inLanguage": "zh", "isPartOf": { "@id": "https://wavect.io/#website", "@type": "WebSite" }, "lastReviewed": "2026-08-16", "url": "https://wavect.io/zh/blog/netflix-vllm-triton-inference-stack/" } ] } ``` ```json { "@context": "https://schema.org", "@type": "BlogPosting", "abstract": "Netflix 公开了一条内部 LLM 服务路径：统一服务层调用 Model Scoring Service，底层由 NVIDIA Triton 与 vLLM 承担推理。团队从原先的 TensorRT-LLM 路径转向 vLLM，原因不是一个脱离场景的跑分，而是自定义架构接入更快、调试更直接、扩展点更合适，而且研究人员已经熟悉它。生产环境随后暴露了简单基准看不到的问题：Python logits processor 在 batch 扩大后受 CPU 限制，API 字段可能被接受后静默丢弃，模型下载拖慢启动，不兼容的 Triton 与 vLLM 版本在加载时失败，分散指标则掩盖服务真实状态。可迁移的经验是，先掌控接口契约、测试、发布与可观测性，再决定是否掌控每个推理组件。低量或突发需求仍适合托管 API；只有当自定义解码、稳定负载、隐私或模型控制足以支撑专门平台团队时，自建栈才更可信。", "articleBody": " 博客概览/AI 与智能体/模型与基础设施 Netflix 的 vLLM 与 Triton 推理栈：7 个生产经验 要点速览 Netflix 公开了一条内部 LLM 服务路径：统一服务层调用 Model Scoring Service，底层由 NVIDIA Triton 与 vLLM 承担推理。团队从原先的 TensorRT-LLM 路径转向 vLLM，原因不是一个脱离场景的跑分，而是自定义架构接入更快、调试更直接、扩展点更合适，而且研究人员已经熟悉它。生产环境随后暴露了简单基准看不到的问题：Python logits processor 在 batch 扩大后受 CPU 限制，API 字段可能被接受后静默丢弃，模型下载拖慢启动，不兼容的 Triton 与 vLLM 版本在加载时失败，分散指标则掩盖服务真实状态。可迁移的经验是，先掌控接口契约、测试、发布与可观测性，再决定是否掌控每个推理组件。低量或突发需求仍适合托管 API；只有当自定义解码、稳定负载、隐私或模型控制足以支撑专门平台团队时，自建栈才更可信。 社交媒体上的版本很简单：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 与 Triton 服务路径，但也在另一套 MediaFM 系统中公开使用 OpenAI embeddings。证据支持按工作负载选架构，而不是所有 Netflix AI 都自托管的说法。 Netflix 为什么偏好 vLLM 而不是 TensorRT-LLM？ 对 2025 年重新评估的工作负载，Netflix 在开源引擎性能已经具有竞争力后，更看重自定义架构支持、解码扩展性、可调试性与研究人员熟悉度。这是特定场景决策，不是永久排名。 约束解码瓶颈来自哪里？ vLLM V0 在 GPU 生成 batch logits 后按请求运行 Python 处理器。CPU 工作随 batch 增长，Python GIL 又阻止并行。Netflix 转向 vLLM V1 的 batch 级处理与多线程 C++ 热路径。 运行 vLLM 是否必须使用 NVIDIA Triton？ 不需要。vLLM 可以直接提供 OpenAI 兼容服务。需要共享模型仓库、多种 backend、控制平面集成或成熟服务器运", "articleSection": "Engineering", "author": { "@id": "https://wavect.io/team/kevin-riedl/#person", "@type": "Person", "name": "Kevin Riedl", "sameAs": [ "https://www.wikidata.org/wiki/Q139796365", "https://www.linkedin.com/in/wsdt", "https://github.com/wsdt" ], "url": "https://wavect.io/team/kevin-riedl/" }, "citation": [ { "@type": "WebPage", "name": "一条由 NVIDIA Triton 与 vLLM 组成的内部 LLM 服务路径", "url": "https://netflixtechblog.com/in-house-llm-serving-at-netflix-a5a8e799ea2c" }, { "@type": "WebPage", "name": "OpenAI 的 text-embedding-3-large 处理定时文本与标题元数据", "url": "https://medium.com/netflix-techblog/mediafm-the-multimodal-ai-foundation-for-media-understanding-at-netflix-e8c28df82e2d" }, { "@type": "WebPage", "name": "batch 级 logits processor 接口", "url": "https://docs.vllm.ai/en/latest/api/vllm/v1/sample/logits_processor/index.html" }, { "@type": "WebPage", "name": "Triton 与 vLLM 兼容矩阵", "url": "https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/introduction/compatibility.html" }, { "@type": "WebPage", "name": "Triton OpenAI 兼容前端文档", "url": "https://docs.nvidia.com/deeplearning/triton-inference-server/user-guide/docs/client_guide/openai_readme.html" }, { "@type": "WebPage", "name": "预加载所需文件内容", "url": "https://docs.aws.amazon.com/fsx/latest/LustreGuide/preload-file-contents-hsm-dra.html" } ], "dateModified": "2026-08-16", "datePublished": "2026-08-16", "description": "Netflix 公开了一条内部 LLM 服务路径：统一服务层调用 Model Scoring Service，底层由 NVIDIA Triton 与 vLLM 承担推理。团队从原先的 TensorRT-LLM 路径转向 vLLM，原因不是一个脱离场景的跑分，而是自定义架构接入更快、调试更直接、扩展点更合适，而且研究人员已经熟悉它。生产环境随后暴露了简单基准看不到的问题：Python logits processor 在 batch 扩大后受 CPU 限制，API 字段可能被接受后静默丢弃，模型下载拖慢启动，不兼容的 Triton 与 vLLM 版本在加载时失败，分散指标则掩盖服务真实状态。可迁移的经验是，先掌控接口契约、测试、发布与可观测性，再决定是否掌控每个推理组件。低量或突发需求仍适合托管 API；只有当自定义解码、稳定负载、隐私或模型控制足以支撑专门平台团队时，自建栈才更可信。", "headline": "Netflix 的 vLLM 与 Triton 推理栈：7 个生产经验", "image": "https://wavect.io/img/blog/headers/header_netflix-vllm-triton-inference-stack.svg", "inLanguage": "zh", "keywords": "AI 基础设施, LLM 推理", "mainEntityOfPage": { "@id": "https://wavect.io/zh/blog/netflix-vllm-triton-inference-stack/", "@type": "WebPage" }, "publisher": { "@id": "https://wavect.io/#organization", "@type": [ "Organization", "ProfessionalService", "LocalBusiness" ] }, "url": "https://wavect.io/zh/blog/netflix-vllm-triton-inference-stack/", "wordCount": 541 } ``` ```json { "@context": "https://schema.org", "@type": "BreadcrumbList", "itemListElement": [ { "@type": "ListItem", "item": "https://wavect.io/zh/", "name": "首页", "position": 1 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/overview/", "name": "博客概览", "position": 2 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/topics/ai-agents/", "name": "AI 与智能体", "position": 3 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/clusters/models-infrastructure/", "name": "模型与基础设施", "position": 4 }, { "@type": "ListItem", "item": "https://wavect.io/zh/blog/netflix-vllm-triton-inference-stack/", "name": "Netflix 的 vLLM 与 Triton：生产经验 | ", "position": 5 } ] } ``` ```json { "@context": "https://schema.org", "@type": "FAQPage", "mainEntity": [ { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "Netflix 公开了一条内部 vLLM 与 Triton 服务路径，但也在另一套 MediaFM 系统中公开使用 OpenAI embeddings。证据支持按工作负载选架构，而不是所有 Netflix AI 都自托管的说法。" }, "name": "Netflix 是否把所有 LLM 推理都放在内部？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "对 2025 年重新评估的工作负载，Netflix 在开源引擎性能已经具有竞争力后，更看重自定义架构支持、解码扩展性、可调试性与研究人员熟悉度。这是特定场景决策，不是永久排名。" }, "name": "Netflix 为什么偏好 vLLM 而不是 TensorRT-LLM？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "vLLM V0 在 GPU 生成 batch logits 后按请求运行 Python 处理器。CPU 工作随 batch 增长，Python GIL 又阻止并行。Netflix 转向 vLLM V1 的 batch 级处理与多线程 C++ 热路径。" }, "name": "约束解码瓶颈来自哪里？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "不需要。vLLM 可以直接提供 OpenAI 兼容服务。需要共享模型仓库、多种 backend、控制平面集成或成熟服务器运维时，Triton 才更相关，同时也增加了必须固定和测试的兼容面。" }, "name": "运行 vLLM 是否必须使用 NVIDIA Triton？" }, { "@type": "Question", "acceptedAnswer": { "@type": "Answer", "text": "当自定义解码、自定义模型、严格数据边界或稳定利用率带来可量化优势，并且团队能负责升级、可观测性、回滚和值班时再考虑。对低量、突发或标准需求，管理式推理通常是更简单的起点。" }, "name": "规模较小的公司何时该自托管 LLM 推理？" } ] } ```