第6章 · 性能分析与部署

第6章 · 性能分析与部署

章节摘要：从 ORT_ENABLE_PROFILE 定位热点算子，用 SessionOptions 策略化调参，再在 CI 中固定 ONNX opset、ORT 版本与 EP 组合。性能工作从「手工改参数」升级为可观测、可回归的治理闭环。

本章要解决的问题

前五章把"怎么跑、在哪跑、怎么分资源、怎么压缩"都讲完了，第6章收口成两条线：怎么知道瓶颈在哪（Profiling）与怎么让性能可回归（策略化 + CI）。没有 profile，优化就是盲改；没有 CI 门禁，升级一次 ORT 或换一次 EP 就可能让线上指标静默恶化。

本节目标

1. 生成并解读 ORT profile JSON
2. 组装 low_latency / high_throughput 策略包
3. 设计模型转换与推理的 CI 门禁

治理闭环总览

闭环的四步：Profile 定位热点 → 把调参沉淀成命名策略 → 策略随部署 manifest 发布 → CI 回归验证并回到第一步。性能不再是"上线前调一次"，而是持续可观测、可回滚的工程活动。

核心方法与产出

子章节

6.1 Profiling 与瓶颈定位

ORT_PROFILE、perf_test 与算子耗时占比。

6.2 SessionOptions 调优参数

策略单元与 Provider 专有选项。

6.3 部署模式与 CI 实践

云/边/端部署与版本契约。

前置与后续

• 前置：第2章图优化（Profile 里的算子对应融合前后）、第3章 EP（热点归属）、第4章内存线程、第5章量化
• 后续：本章是教程终点，但治理闭环持续运行
• 贯穿线索：所有调优动作都要落到"可测量、可回归、可回滚"三原则

三原则与治理闭环

性能治理的三原则贯穿本章：可测量——没有 profile 不谈优化；可回归——每项改动进 CI 有基线对比；可回滚——策略与版本分离，出问题一条命令回滚。三原则把性能工作从"上线前调一次"变成"持续治理"。

常见性能问题速查

调参记录模板

每次调参都留一条结构化记录，字段固定：日期、模型版本、ORT 版本、EP、策略名、改动参数、P50/P99 前后、业务指标、结论。这条记录是团队性能资产的原子单位——半年后没人记得的事，记录记得。

# 调参记录模板
- date: 2025-01-15
- model: model.onnx (sha256 前8位)
- ort: 1.17.0 / ep: tensorrt
- policy: cloud_trt_fp16_v2
- change: trt_max_workspace_size 1G -> 2G
- p50: 9.1 -> 8.2 ms
- p99: 15.4 -> 13.9 ms
- metric: mAP 0.921 -> 0.920（噪声内）
- conclusion: workspace 提升融合，保留
​

术语表