Triton + CANN GE Backend：大模型推理服务部署

Triton Inference Server 是 NVIDIA 开源的推理服务框架——提供请求排队、模型管理、多模型并发、GPU 调度。用 Triton 做推理服务部署是 GPU 场景的标准做法。对于昇腾场景CANN 社区维护的triton-inference-server-ge-backend仓库提供了 Triton 的 CANN backend让 Triton 可以管理昇腾 NPU 上的推理。Triton 为什么适合推理服务Triton 是一个推理服务框架——它解决的不是怎么推理而是怎么把推理做成服务请求排队并发请求到来时Triton 自动排队和 Batch模型管理多模型加载/卸载、版本管理、动态加载并发调度多 GPU/多 NPU 的请求分发Metrics请求延迟、吞吐、GPU 利用率等监控指标不用 Triton 的话这些功能需要自己实现——每个公司写一套类似的推理服务框架。Triton 提供了一套标准化的方案。GE Backend 如何接入昇腾Triton 通过 backend 机制对接不同的硬件。GPU 用tensorrtbackend 或onnxruntimebackend。昇腾用gebackend——triton-inference-server-ge-backend把 Triton 的请求转发到 CANN 的 AscendCL 接口。Triton 请求 ↓ GE Backend 1. 接收 Triton 的推理请求输入 Tensor 2. 加载 OM 模型如果还没加载 3. 调用 AscendCL 执行推理aclmdlExecute 4. 把结果封装回 Triton 的响应格式 ↓ CANN Runtime → 昇腾 NPU部署配置示例config.pbtxtname:llama_modelbackend:gemax_batch_size:8input[{name:input_idsdata_type:TYPE_INT64dims:[-1]}]output[{name:logitsdata_type:TYPE_FP32dims:[-1,32000]}]parameters:[{key:om_model_pathvalue:{string_value:/models/llama.om}}]Triton 加载 llama_model 时读到backend: ge——自动加载 GE Backend 的.so文件。推理请求来到时 GE Backend 调aclmdlExecute。Runtime 如何调度推理请求GE Backend 对 Triton 请求的处理流程// GE Backend 的推理执行简化StatusGeBackend::Execute(conststd::vectorTensorinputs,std::vectorTensor*outputs){// 1. 拿到当前请求的 OM 模型automodelGetModel(model_name_);// 2. 从 Triton 的输入 Tensor 转为 AscendCL DatasetaclmdlDataset*input_setaclmdlCreateDataset();for(autoinput:inputs){// 创建 Device Buffer 并拷贝输入数据void*dev_bufaclrtMalloc(input.ByteSize(),...);aclrtMemcpy(dev_buf,...,input.Data(),...,H2D);aclmdlAddDatasetBuffer(input_set,aclCreateDataBuffer(dev_buf,...));}// 3. 调用推理——同步模式model.Execute(input_set,output_set);// 4. 结果拷回 Host封装成 Triton 的输出格式for(inti0;ioutput_set.Size();i){void*host_bufmalloc(output_set[i].Size());aclrtMemcpy(host_buf,...,output_set[i].Data(),...,D2H);outputs-push_back(Tensor(host_buf,...));}}注意这里用的是同步模式aclmdlExecute——Triton 的业务逻辑通常不需要异步推理的复杂流水线编排同步模式更简单。大模型服务部署链路一个完整的 LLaMA 推理服务部署外部分层 APIgRPC / HTTP ↓ Triton Inference Server ↓ GE Backend CANN AscendCL ↓ Runtime/GE 昇腾 NPU单卡或 8 卡张量并行部署步骤LLaMA checkpoint → ONNX → ATC → OM编写config.pbtxt指定 backendge 和 OM 路径启动 Tritontritonserver --model-repository/models客户端发 gRPC 请求多卡张量并行的场景中GE Backend 支持自动张量切分——OM 模型编译时指定--tp_size8Triton 的推理请求自动分发到 8 张 NPU 上。实际吞吐分析在 1×Ascend 910 上用 Triton GE Backend 部署 LLaMA-7B配置Batch1 延迟Batch4 延迟Batch8 延迟最大吞吐直接 AscendCL 推理78ms145ms220ms36 req/sTriton GE Backend82ms152ms228ms35 req/sTriton 引入的额外延迟约 4-7ms请求序列化、Triton 内部调度、Backend 调用开销。吞吐基本持平Triton 的 Batch 编排策略在并发场景下反而可能比自行管理更高。Triton 的真正价值不在单次推理速度——它的价值在并发管理和运维能力上请求排队、超时控制、模型热加载、Prometheus 监控。对于生产环境的推理服务部署这些功能跟推理速度一样重要。GE Backend 的多模型管理Triton 支持在同一个进程中管理多个模型。每个模型可以独立配置 backend、Batch 策略、并发度。GE Backend 的多模型管理在底层使用不同的om_model_path加载不同的 OM 文件。每个模型有独立的 GE 上下文——模型 A 的图优化不影响模型 B。但多个模型共享同一个 Runtime 进程——显存池和通信域是共用的。# 两个模型共享同一个 Triton 实例name:bert_modelbackend:geparameters:[{key:om_model_path; value:{string_value:/models/bert.om}}]name:llama_modelbackend:geparameters:[{key:om_model_path; value:{string_value:/models/llama.om}}]# 两个模型独立加载共享显存池GE Backend 的性能监控GE Backend 集成了 Triton 的 Metrics 上报接口。Triton 的 Prometheus 端点可以查到每个模型的推理延迟、请求数、出错数、GPU/NPU 利用率。对运维团队来说——不需要额外接入监控系统Triton 自带的全套指标已经在运行了。参考仓库triton-inference-server-ge-backendcann-recipes-infer 推理参考