AI热榜 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 增加了检测变化并在继续生成前重建状态的逻辑。
🔗 原始来源
如果你要核对细节，可以再看原文： InfoQ AI原文链接