Netflix 揭秘自研 LLM 推理平台：从 TensorRT-LLM 转向 vLLM

Netflix 人工智能平台的模型运行时与推理团队日前发布了一篇技术博客，详细介绍了其内部大语言模型推理服务的架构选型与落地经验。与多数依赖托管 API 的公司不同，Netflix 选择在自有生产环境中完整自建从模型部署到推理的全栈能力，并在实践中总结出一系列值得参考的工程权衡。

整体服务架构

Netflix 的会员级机器学习服务由一套统一的 JVM 服务框架支撑，负责路由、A/B 测试、候选生成、特征获取、推理与日志记录等端到端流程，同时支持实时与缓存批处理两条调用路径。下游调用方可以通过 gRPC 接入该服务系统，新一代 LLM 驱动的应用也可以走直接的 HTTP 通道。

推理的具体执行位置取决于模型规模：小型 CPU 模型在进程内运行以避免远程调用开销；规模较大的模型需要 GPU 资源，此时前置服务本地完成预/后处理，将推理请求转发到统一的 Model Scoring Service（MSS） 共享推理后端。MSS 在接口层统一封装了 XGBoost、TensorFlow、PyTorch 与 LLM 等多种模型，底层由 NVIDIA Triton Inference Server 负责模型加载、批处理与 GPU 调度。Triton 之上由一套 Java 控制面负责部署、版本管理、健康检查、自动扩缩容与多区域灰度发布。

引擎选型：从 TensorRT-LLM 转向 vLLM

平台最初基于 TensorRT-LLM 构建推理引擎，它在彼时性能领先，且已与作为 MSS 计算底座的 Triton 完成集成。但到 2025 年夏，Netflix 的工作负载结构发生了变化——除了自回归解码，还纳入了 embedding 生成、用于排序与检索的 prefill-only 推理，以及带有复杂单步约束逻辑的自定义模型。

针对这一新负载组合，团队重新做了基准测试，最终选定 vLLM 作为主推引擎，主要基于以下运营适配性考虑：

• 可直接加载自定义模型架构，无需多步编译流水线，加快非标模型的迭代节奏。
• 提供扩展点以接入自定义解码逻辑，为后续受限解码工作提供基础。
• 调试体验优于已编译的 TensorRT-LLM，便于排查失败与中间状态。
• 大量研究阶段的算法工程师已在使用 vLLM，缩短了研究到生产的交接成本。

vLLM 与 Triton 集成的两种方式

引擎选定后，下一步是决定如何在 Triton 中打包模型。Triton 提供两种后端选择，权衡点集中在模型工件与前端升级之间的耦合度：

• Python 后端：模型作者在打包时显式声明输入/输出张量规格，这些规格被冻结在工件中，必须与第三方前端的请求构造器严格一致；任何涉及 I/O 规格的前端升级都需要协调修改打包代码，否则会在运行时失败。
• vLLM 后端：工件仅为一个指向模型权重与分词器的 JSON 配置，Triton 的 vLLM 后端在部署时动态生成 I/O 张量规格，模型与前端可独立演进。

Netflix 将 vLLM 后端视为架构上正确的默认选择，但在生产中遇到两类典型问题：

• Triton 与 vLLM 版本错配：Triton 的 vLLM 后端针对特定版本的 vLLM API 编译，两者一旦漂移便会整体加载失败。例如 Triton 25.09 引入了 vLLM 0.11.2 已移除的 vllm.engine.metrics 模块。平台需要在烘焙服务镜像时固定兼容版本，并禁止模型作者在打包时覆盖 vLLM 版本。
• 自定义模型逻辑：vLLM 后端默认要求标准的 HuggingFace 兼容模型并接管完整推理生命周期；需要自定义预处理、后处理或非常规执行流程（如集成流水线、自定义分词）的模型，仍需回退到 Python 后端以获得对 execute() 的完整控制权。

面向生态兼容的 HTTP 前端

在引擎与打包方案确定之后，团队进一步统一了调用接口。核心设计原则是 LLM 模型不应被视为特殊对象：无论是 XGBoost 集成模型还是大规模 LLM，都通过同一套 gRPC 调用打分，复用既有客户端库、健康检查与部署管线。考虑到 OpenAI 兼容 API 已成为 LLM 生态的事实标准——推理引擎、编排框架、评估工具与客户端库均已支持，团队在此基础上 将 OpenAI 兼容 API 作为额外的前端形式与 gRPC 并行暴露，以降低从实验到生产的迁移成本。