Netflix 近日介绍了其内部大语言模型服务平台。该平台没有将 LLM 推理单独建设成一套孤立系统，而是把大模型服务纳入既有的 Model Scoring Service（MSS），与 XGBoost、TensorFlow、PyTorch 等模型共享服务接口、客户端库、健康检查和部署流程。
在推理层，Netflix 选择 vLLM 作为主要推理引擎，并将其集成到 NVIDIA Triton Inference Server 中。Triton 负责模型加载、批处理和 GPU 调度等底层服务能力，上层控制面则处理部署、版本管理、健康检查、自动扩缩容以及多区域发布。平台同时保留既有的 gRPC 调用路径，并增加了兼容 OpenAI API 规范的 HTTP 接口，以降低应用从托管模型迁移到内部模型时的改造成本。
Netflix 表示，选择 vLLM 的考虑并不只包括性能，还包括对自定义模型架构的支持、较短的迭代路径、对自定义解码逻辑的扩展能力，以及调试和研究转生产过程中的便利性。平台需要覆盖多种工作负载，包括嵌入生成、仅预填充推理、自回归解码，以及带有复杂约束逻辑的自定义模型。
在生产集成过程中，Netflix 遇到的一个重要问题是 Triton 与 vLLM 的版本兼容性。部分版本之间的模块变化可能导致 vLLM 后端无法加载，因此平台需要在服务镜像中固定兼容的版本组合，并限制模型打包阶段对 vLLM 版本的覆盖。对于需要非标准预处理、后处理或执行流程的模型，平台仍保留 Triton Python backend 作为扩展路径。
部署方面，平台提供 Red-Black 和 Versioned 两种策略。前者让新旧版本并行运行，在健康检查通过后逐步切换流量，并支持回滚；后者则为不同的模型版本保留独立部署，以应对输入输出结构发生变化的情况。Netflix 的经验是，能够将可变配置直接放进模型内部时，Red-Black 部署更经济；只有在接口变化无法兼容时，才需要采用 Versioned 部署。
Netflix 还重点讨论了约束解码的工程实现。一些生产工作负载要求模型直接生成符合规则的结果，而不是先生成无效内容，再通过重试或后处理进行修复。为此，平台利用 vLLM 的自定义 logits processor 接口，将约束表示为随生成过程更新的状态机，并在每一步生成时计算可用 token 的掩码。
这部分逻辑最初基于 vLLM V0 实现，但在批量请求增加时出现 CPU 侧处理开销随批大小增长、尾延迟上升的问题。迁移到 vLLM V1 后，Netflix 将处理逻辑改造成面向批次的数据结构，并将热点路径改用 C++ 和多线程实现。根据 Netflix 的介绍，迁移后 logits 处理时间能够在批大小增加时保持相对稳定。不过，分块预填充和 KV cache 驱逐等机制也要求约束状态机额外处理请求状态变化。
在模型加载和可观测性方面，Netflix 也进行了定制。为了避免在实例启动时直接从对象存储或模型仓库下载大型模型，平台会在模型发布时将模型物化到 Amazon FSx，以缩短冷启动路径。由于 vLLM 与 Triton 的指标体系并不完全一致，平台还增加了指标聚合层，将两者的数据合并到统一的 /metrics 端点中。
从 Netflix 的实践看，LLM 服务平台的难点并不局限于选择某个推理引擎。版本锁定、模型打包、接口兼容、GPU 部署、约束解码和指标统一，都会影响模型从实验环境进入生产系统的成本。vLLM 与 Triton 的组合提供了较清晰的职责分工，但也意味着平台方需要承担组件集成、版本治理和定制补丁的长期维护工作。