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 "