2. GPU推理部署基础
在GPU模型部署验证与回归测试工程中，最先需要厘清的不是“用哪个框架跑得快”，而是每一层软件栈各自负责什么、部署形态长什么样、验证时应该从哪里切入。同一个模型，可能以PyTorch权重、ONNX文件、TensorRT引擎或Triton模型仓库的形式存在；同一张GPU，可能被CUDA运行时直接调用，也可能被TensorRT、ONNX Runtime或Triton间接调度。如果分不清这些层次，回归测试就会出现“测了精度却漏了引擎构建”“换了驱动却只对比了输出张量”这类盲区。
四层部署形态：从驱动到服务
可以把GPU推理部署理解为一条自下而上的栈：最底层是CUDA运行时，它负责设备管理、内存分配、内核启动和流同步；往上是推理引擎层，包括TensorRT和ONNX Runtime，它们把模型图编译或解释为可在GPU上执行的计划；最上层是服务层，以Triton Inference Server为代表，负责模型仓库管理、并发调度、动态批处理和HTTP/gRPC接口暴露。验证切入点也随层次不同而不同：CUDA层看设备可见性、显存和流同步；引擎层看精度、延迟和引擎构建；服务层看接口契约、并发行为和批处理正确性。
CUDA运行时：验证的起点是“设备是否真的可用”
CUDA运行时是整条栈的地基。部署验证的第一步不是跑模型，而是确认nvidia-smi能列出目标GPU、驱动版本满足CUDA Toolkit要求、CUDA_VISIBLE_DEVICES能正确隔离多卡环境。一个常见陷阱是：容器内nvidia-smi正常，但torch.cuda.is_available()返回False，原因往往是容器未挂载--gpus all或驱动库路径缺失。此时应检查libcuda.so是否可被动态链接器找到，而不是反复重装框架。
显存验证同样关键。推理服务启动前，应记录空载显存占用作为基线；加载模型后再次采样，得到模型权重与运行时开销的差值。若显存增长远超权重体积，通常意味着存在中间激活未释放或缓存未清理。流同步方面，异步推理必须确保cudaStreamSynchronize或事件等待被正确调用，否则会出现“请求已返回但结果尚未计算完”的假成功。
TensorRT：引擎构建本身就是一次验证
TensorRT的部署形态是“先构建、后执行”。输入ONNX模型后，TensorRT会进行层融合、精度校准和内核自动调优，输出序列化的.plan引擎文件。验证切入点有三个：第一，构建日志中是否有层回退到未加速实现；第二，FP16或INT8量化后与FP32基准的精度偏差是否在阈值内；第三，引擎在目标GPU上的实际延迟是否达到预期。
一个可复现的验证流程是：固定ONNX输入形状与随机种子，分别用ONNX Runtime CPU EP和TensorRT FP32执行同一批输入，逐元素比较输出，记录最大绝对误差。若误差超过1e-3量级，需检查是否存在不支持的算子被替换。随后切换到FP16，重复对比，观察误差是否放大到不可接受。INT8则需要校准集，校准集分布必须贴近真实推理数据，否则精度下降会非常隐蔽。
ONNX Runtime：Execution Provider决定实际执行路径
ONNX Runtime的部署形态更接近“解释执行加插件加速”。同一个ONNX模型，可以通过providers参数指定CUDAExecutionProvider、TensorrtExecutionProvider或CPUExecutionProvider。验证的核心是确认实际生效的EP与预期一致。可以通过session.get_providers()查看，也可以开启profiling观察各算子的执行设备。
当TensorRT EP不可用时，ONNX Runtime会静默回退到CUDA EP甚至CPU EP，导致性能骤降但结果仍然正确。因此回归测试中必须把“EP绑定”作为独立断言项。另一个切入点是算子覆盖：若模型中存在CUDA EP不支持的算子，该算子会被放到CPU执行，形成GPU-CPU频繁拷贝。通过session.get_profiling_info()可以定位这些算子，判断是否需要改写模型或升级ORT版本。
Triton Inference Server：验证接口契约与并发行为
Triton的部署形态是“模型仓库加服务进程”。每个模型以目录形式组织，包含config.pbtxt和版本化模型文件。验证切入点从单模型推理扩展到服务契约：HTTP/gRPC接口的输入输出名称、数据类型、形状是否与客户端约定一致；动态批处理开启后，不同batch size的请求是否都能正确返回；并发请求下，延迟分布是否稳定。
一个实用的验证方法是：用perf_analyzer或自定义客户端，分别以并发数1、4、8发送相同请求，记录P50、P95、P99延迟和吞吐。若P99延迟随并发数急剧上升，说明批处理或实例数配置不合理。同时应验证模型版本切换：Triton支持多版本共存，客户端指定版本号后必须命中对应模型，否则回归测试会误判。
部署形态与验证切入点的对应关系
| 层次 | 部署形态 | 核心验证切入点 | 典型失败信号 |
|---|---|---|---|
| CUDA运行时 | 驱动 + 运行时库 + 设备上下文 | 设备枚举、显存基线、流同步 | 设备不可见、显存泄漏、异步结果未就绪 |
| TensorRT | ONNX → 序列化 .plan 引擎 | 构建日志、精度对齐、引擎延迟 | 层回退、量化精度骤降、引擎与GPU不匹配 |
| ONNX Runtime | ONNX图 + Execution Provider | EP绑定、算子覆盖、输出一致性 | 静默回退CPU、算子跨设备拷贝 |
| Triton | 模型仓库 + 服务进程 | 接口契约、并发延迟、版本路由 | 批处理错误、P99抖动、版本命中错误 |
理解这四层的关系后，回归测试的设计就有了清晰的锚点：底层变化（驱动升级、CUDA版本切换）优先触发CUDA层和引擎层的重验证；模型变化（结构修改、量化）优先触发TensorRT和ONNX Runtime的精度对比；服务配置变化（批处理、实例数）优先触发Triton的并发与接口验证。把验证切入点与部署形态对齐，才能避免“测了很多但漏了关键层”的常见问题。