Netflix详述其基于Triton与vLLM的内部LLM服务平台

Netflix 在其文章中介绍了将 LLM 推理纳入内部服务平台的生产经验，讨论了支持不同模型规模、硬件要求以及快速演进的推理引擎所遇到的问题。

文章涵盖了在 CPU 与 GPU 上运行实时与批处理工作负载时的架构选择与运维工作，涉及从模型打包与部署到约束解码与版本兼容性等方面。

该平台基于 Netflix 现有的 JVM 服务层构建，该服务层继续负责路由、特征获取、候选生成、后处理（post-processing）和日志记录。较小的模型可以在 CPU 进程内运行，而较大的请求则委托到 MSS，由 Triton 负责模型加载、批处理、GPU 调度和多框架服务。即便推理在本地与远程硬件之间切换，这种设计也能保持外围生产工作流的一致性。

在 GPU 路径中，Netflix 选择了 vLLM 以满足其运营适配性与可扩展性，同时保留了 Triton 的模型管理与调度职责。Triton 负责模型周边的服务环境，而 vLLM 负责执行推理并提供用于自定义行为的扩展点。Netflix 报告称，不匹配的 Triton 与 vLLM 版本可能导致部署无法加载，因此需要一起测试并固定兼容的发布版本。

自定义模型带来了额外的集成挑战。vLLM 对 Hugging Face 的兼容性对部分 Netflix 模型尚有不足，因而公司使用 vLLM 的扩展点为自定义架构与解码行为提供支持。

Netflix 还比较了两种 Triton 打包方式：Triton 的 Python backend 与 vLLM backend。该公司表示，vLLM-backend 方法使得模型与前端可以比 Python-backend 更独立地演进。该选择影响模型与其服务环境的耦合强度，而非决定由哪个引擎执行推理。

通用的服务接口并未消除底层引擎之间的差异。尽管 Triton 同时暴露了兼容 OpenAI 的 API 以及 KServe 的 HTTP 和 gRPC 前端，Netflix 仍在这些集成中遇到了某些功能处理上的差异。

受约束的解码是其中的一个示例。它允许 Netflix 在每一步过滤模型时通过可能生成的 token 来强制模型响应符合诸如合法 JSON 之类的格式。由于这些规则依赖于已生成的所有内容，解码器必须在整个请求过程中维护状态。当 vLLM 为管理 GPU 资源而暂停后，在后续恢复请求时，该状态可能与 token 历史不同步，因此 Netflix 增加了检测变化并在继续生成前重建状态的逻辑。

兼容性也影响着部署流程。Netflix 将经过测试的 Triton 与 vLLM 版本一起固定，以防止后端加载失败，而 Red-Black 和 Versioned 部署策略用于在模型级别处理变更。Versioned 部署会保留旧版与新版修订并行可用，使消费者在适配不兼容的输入或输出 schema 后可逐步迁移。

优步在应用边界处描述了相关的做法。他们的生成式 AI 网关在外部托管与内部管理的模型之间提供兼容 OpenAI 的接口，同时集中处理认证、缓存、可观测性与路由等关注点。实现方式与 Netflix 的服务平台不同，但两者都将应用集成与后端的模型、运行时和托管环境进行了分离。

Netflix 的经验展示了通用服务接口如何位于若干不同的层之上。这类架构旨在为应用团队提供稳定的集成面，同时允许模型提供商与服务运行时继续演进。但是，这种抽象并没有消除底层的工作，也就是打包、兼容性控制、受约束解码与部署隔离仍需在每一层进行工程实现。

查看英文原文：Netflix Details Its In-House LLM Serving Platform with Triton and vLLM