Netflix LLM推理平台：Triton与vLLM的工程实践

近日，企业级大语言模型推理落地实践迎来了新的行业参考样本，某科技企业分享了将LLM推理集成到内部服务平台的完整生产经验，内容覆盖不同模型规模适配、硬件资源调度，以及应对推理引擎快速迭代带来的各类挑战。

该平台基于企业现有的JVM服务层搭建，原有服务层依然承担路由配置、特征数据获取、候选结果生成、后处理流程以及日志记录等核心职责。针对不同算力需求的模型，平台采用了差异化部署策略：体量较小的模型可直接在CPU进程内运行，而对算力要求更高的大模型请求则会被委托到专门的算力服务集群，由Triton框架负责模型加载、请求批处理、GPU资源调度以及多框架模型的服务托管。这种分层设计即便在推理任务在本地CPU和远程GPU硬件之间切换时，也能保证外围生产工作流的一致性。

在GPU推理的具体实现上，团队选择了vLLM作为推理执行引擎，以满足业务的适配性和扩展性需求，同时保留了Triton在模型管理与调度层面的核心职责。具体来说，Triton负责搭建模型周边的服务环境，而vLLM则专注于推理执行，并提供了用于自定义行为的扩展接口。团队提到，Triton和vLLM的版本不匹配会导致模型部署无法正常加载，因此需要对两个组件进行统一测试，并锁定兼容的发布版本组合。

针对企业自研的自定义模型，集成过程面临了额外的挑战。由于vLLM对Hugging Face生态的兼容性无法覆盖部分自研模型，团队借助vLLM提供的扩展点，为自定义架构和特殊解码行为提供了适配支持。

团队还对比了Triton的两种后端打包方案：Python后端和vLLM后端。他们发现，采用vLLM后端的方式可以让模型和前端服务实现比Python后端更高的演进独立性。这一选择主要影响的是模型与服务环境之间的耦合强度，而非实际执行推理的引擎本身。

即便使用了通用的服务接口，底层不同推理引擎之间的差异依然无法被完全抹平。尽管Triton同时提供了兼容OpenAI的API接口，以及适配KServe的HTTP和gRPC前端，但团队在实际集成过程中依然发现了部分功能处理上的不一致。

约束式解码就是其中一个典型的兼容性问题场景。该功能允许平台在模型生成内容的每一步，通过过滤可能的token来强制输出符合特定格式的结果，比如合法的JSON格式。由于这类规则依赖于已经生成的全部上下文内容，解码器需要在整个请求周期内维护完整的状态。当vLLM为了管理GPU资源而暂停请求处理，后续恢复请求时，维护的状态可能会和token历史出现不一致，因此团队额外增加了状态检测逻辑，在继续生成内容前重新构建完整的状态信息。

版本兼容性同样影响着整体的部署流程。该企业会将经过充分测试的Triton和vLLM版本绑定固定，以避免后端加载失败的问题。在模型层面的变更处理上，他们采用了两种部署策略：Red-Black和Versioned。其中Versioned部署会保留新旧版本的模型修订版并行可用，让业务消费者可以在适配不兼容的输入或输出schema后，逐步完成版本迁移。

另有同行企业在应用边界层也提出了类似的架构思路：他们的生成式AI网关在外部托管和内部管理的模型之间提供了兼容OpenAI的统一接口，同时集中处理认证、缓存、可观测性以及路由等跨服务的关注点。尽管具体实现和该企业的服务平台存在差异，但两者的核心思路一致，都是将应用集成逻辑和后端的模型、运行时以及托管环境进行解耦。

该企业的实践经验证明，通用服务接口可以搭建在多层不同的技术栈之上。这类架构的设计目标是为应用团队提供稳定的集成入口，同时允许模型提供商和服务运行时进行独立演进。但需要明确的是，这种抽象层并没有消除底层的工程工作，模型打包、兼容性管控、约束式解码以及部署隔离等环节，依然需要在每一层进行针对性的工程实现。