Netflix 自建 LLM 推理平台：从 TensorRT-LLM 转向 vLLM 的生产实践
Netflix AI Platform 团队分享其在生产环境中自建 LLM 推理服务的架构、引擎选型、模型打包与 API…
Netflix 的 AI Platform 团队近日发布了一篇工程博客，详细介绍了其内部 LLM 推理平台的设计思路与生产经验。与多数直接调用托管 API 的企业不同，Netflix 选择在已有的生产环境中自建完整链路，涵盖模型部署、推理调度以及输出约束等环节。这篇文章聚焦于那些经过严肃评估的关键决策——引擎选型、模型打包、API 暴露方式、部署策略以及输出约束执行——并分享了设计阶段未能预见、生产环境才暴露的教训。
整体架构
Netflix 的会员级 ML 服务前端是一个统一的、基于 JVM 的推理系统，负责路由、A/B 实验逻辑、候选生成、特征获取、推理、后处理和日志记录等端到端流程，同时支持实时与缓存批量两条路径。调用方目前可通过两种方式触达推理：一是经过该推理系统的 gRPC 路径，二是较新的 LLM 驱动应用所用的直连 HTTP 路径。
具体的推理执行位置取决于模型规模。小型 CPU 模型直接在进程内运行，避免远程调用开销；较大的模型则需要 GPU，推理系统在本机完成前后处理，将推理委托给远程服务 Model Scoring Service (MSS)。MSS 是一个共享推理后端，在统一接口下支持 XGBoost、TensorFlow、PyTorch 以及 LLM，底层使用 NVIDIA Triton Inference Server 管理模型加载、批处理与 GPU 调度。在 Triton 之上，Netflix 搭建了一个 Java 控制平面，负责部署、版本管理、健康检查、自动扩缩容以及多区域灰度发布。
引擎选型：从 TensorRT-LLM 转向 vLLM
平台最初基于 TensorRT-LLM 构建——当时它是性能领先的推理引擎，且已与 Triton 集成。到 2025 年夏天，两件事发生了改变：开源引擎在性能上已大幅缩小与专用栈的差距；同时 Netflix 的工作负载也变得更加多样，包括 embedding 生成、为排序与检索服务的 prefill-only 推理、自回归解码，以及带复杂逐步约束逻辑的自定义模型。
基于这一混合负载的重新基准测试后，团队选择了 vLLM 作为「铺装路径」（paved-path）引擎，理由包括：
- 无需多步编译流水线即可加载自定义模型架构，加快非标模型的迭代速度；
- 提供自定义解码逻辑的扩展点，便于后续的约束解码工作；
- 调试性优于编译型引擎，便于检查失败与中间状态；
- 团队对 vLLM 已有较高熟悉度，降低了从研究到生产的交接成本。
模型打包：Triton 的 Python 后端 vs vLLM 后端
确定引擎后，下一个决策是如何打包模型以供 vLLM 使用。Triton 提供两种方式，各有显著的维护性影响：
- Python 后端：作者在打包时显式定义输入输出张量规范，并冻结在产物中。每次前端升级触及 I/O 规范时，都需要协调修改打包代码，否则请求会在运行时失败。
- vLLM 后端：产物仅为一个指向模型权重与 tokenizer 的 JSON 配置。Triton 的 vLLM 后端在部署时动态读取该配置并生成 I/O 张量规范，模型与前端可独立演进。
从架构上看，vLLM 后端是默认正确选择。但生产环境中也暴露了两个问题：
- Triton 与 vLLM 版本不匹配：Triton 的 vLLM 后端针对特定 vLLM API 表面编译。例如 Triton 25.09 引入了
vllm.engine.metrics模块，而该模块在 vLLM 0.11.2 中已被移除，导致后端完全无法加载。平台必须在烘焙服务镜像时锁定兼容版本，并阻止模型作者在打包时覆盖 vLLM 版本。 - 自定义模型逻辑：vLLM 后端默认期望标准的 HuggingFace 兼容模型并处理完整推理生命周期。对于需要自定义前后处理或非标准执行流程（如集成流水线、自定义分词）的模型，仍需使用 Python 后端以获得对
execute()的完全控制。这一逃生通道在可预见的未来仍将是必要的。
对外接口：兼容 OpenAI 的 HTTP 前端
在引擎与打包方案确定后，团队面临的核心问题是如何向调用方暴露能力。系统的关键设计目标是不让 LLM 模型成为特殊例外——无论是 XGBoost 集成模型还是大规模 LLM，都通过相同的 gRPC 调用评分，复用同一套客户端库、健康检查与部署流水线。考虑到 OpenAI 兼容 API 已成为 LLM 生态的事实标准接口（推理引擎、编排框架、评估工具、客户端库均已支持），平台在 gRPC 之外额外暴露了 OpenAI 兼容 API 作为前端。该设计显著简化了从实验到生产的迁移路径。
小结
Netflix 的案例展示了一家大规模生产环境在自建 LLM 推理栈时的核心权衡：性能不是唯一指标，运营契合度、可调试性、生态兼容性以及版本治理同样关键。引擎、打包、接口三个层面的选择彼此约束，构成了一个相互依赖的设计序列。这些来自真实负载的经验，对正在评估或搭建自建 LLM 服务的基础设施团队具有直接参考意义。