3. 模型版本治理框架设计
在 IGX 平台上做模型量产部署，模型文件本身只是交付物的一部分。真正决定“能不能上车、能不能回滚、能不能审计”的，是围绕模型建立的一套版本治理框架。本节围绕四个相互咬合的构件展开：版本命名规范、元数据管理、模型注册中心，以及与 MLOps 流水线的集成策略。它们的关系不是并列的四件事，而是一条从“标识”到“描述”到“存储”再到“自动化流转”的治理链。
一、版本命名规范：让版本号自己会说话
IGX 面向的是车载、医疗、工业等强合规场景，模型版本必须可追溯、可比较、可排序。建议采用四段式语义化命名：
<模型名>-<语义版本>+<训练数据版本>.<构建号>
示例：
perception-detector-v2.3.1+ds2024.11.07.0031
occupancy-net-v1.0.0+ds2025.01.15.0007其中语义版本遵循 MAJOR.MINOR.PATCH：MAJOR 表示输入输出接口或张量形状发生不兼容变更（例如检测头从 3 类扩展到 8 类），MINOR 表示精度或结构改进但接口兼容，PATCH 表示仅重训练或超参微调。训练数据版本用 ds<日期>.<序号> 标识，构建号由 CI 自动递增。这样命名后，版本号天然可排序，运维人员看到 v2.3.1 与 v2.4.0 就能判断是否涉及接口变更，是否需要重新做集成测试。
需要特别约定的是：禁止使用 latest、final、new 这类浮动标签作为部署引用。部署清单中必须写死完整版本串，浮动标签只允许出现在开发调试阶段。
二、元数据管理：模型的身份档案
版本号解决“叫什么”，元数据解决“是什么、从哪来、能不能用”。建议为每个模型版本维护一份 JSON 元数据清单，随模型文件一同入库。关键字段包括：
- 溯源信息：训练数据版本、代码 commit、训练框架与 CUDA/TensorRT 版本；
- 结构信息：输入张量形状、数据类型、输出语义、预处理与后处理参数；
- 精度指标：mAP、IoU、量化前后精度差、各子集表现；
- 部署约束：目标 IGX 型号、支持的 JetPack/IGX 软件栈版本、显存占用、推理时延；
- 合规状态：是否通过功能安全评审、是否完成签名、审批人。
元数据不是文档，而是可被流水线读取的结构化数据。例如部署前校验脚本会读取 deploy_constraints.igx_sw_version，与目标设备的软件栈版本比对，不匹配则直接阻断发布。这就是元数据从“记录”变成“门禁”的关键一步。
三、模型注册中心：单一可信源
模型注册中心（Model Registry）是治理框架的存储与状态中枢。它保存模型制品（.onnx、.plan、.engine）、元数据清单、签名文件，并维护每个版本的生命周期状态。建议采用五状态模型：
| 状态 | 含义 | 允许的操作 |
|---|---|---|
| Draft | 训练产出，未验证 | 仅开发环境拉取 |
| Validated | 精度与合规校验通过 | 可进入预发布 |
| Staged | 已在影子设备验证 | 可灰度发布 |
| Production | 量产在用 | 可被 OTA 引用 |
| Deprecated | 已弃用但保留 | 仅回滚使用 |
状态迁移必须由流水线自动触发并留痕，禁止人工直接改状态。注册中心还应支持按“模型名 + 状态”查询，例如“取 perception-detector 当前 Production 版本”，供 OTA 服务动态解析。
四、与 MLOps 流水线的集成策略
治理框架只有嵌入流水线才真正生效。集成策略可归纳为“三道门禁 + 一次回写”：
- 入库门禁：训练完成后，CI 自动生成元数据、计算哈希、上传注册中心，状态置为 Draft；缺少必填元数据字段则拒绝入库。
- 验证门禁：在 IGX 目标硬件上跑精度回归与性能基准，达标后状态迁移到 Validated；精度下降超过阈值（示例：mAP 下降 > 1.5%）则阻断。
- 发布门禁：灰度设备运行 24 小时无异常，状态迁移到 Staged 再到 Production，同时回写部署记录（设备 ID、版本、时间）到注册中心，形成“模型—设备”双向追溯。
下面这张图展示了四个构件之间的数据流与状态流转关系：
五、落地要点与常见陷阱
在实际项目中，治理框架最容易失败的地方不是技术，而是约定执行不彻底。以下三点值得特别注意：
- 元数据必填字段校验前置：把校验放在 CI 入口，而不是等到部署时才发现缺字段。示例做法是在流水线中加一步
validate_metadata.py，检查input_shape、precision、igx_sw_version等字段是否存在且格式合法。 - 状态迁移不可逆但可回退：Production 可以回退到 Staged（发现问题时），但 Draft 不能直接跳到 Production。回退操作同样要记录原因和操作人。
- 注册中心与 OTA 解耦：OTA 服务只查询“模型名 + Production”解析出具体版本，不直接引用文件路径。这样模型升级时 OTA 配置无需改动，治理框架自动生效。
总结来说，IGX 模型版本治理框架的核心不是某个工具，而是一套“命名可读、元数据可查、状态可控、流水线可自动执行”的约定体系。把这四件事做扎实，模型从训练到量产部署的每一步都有据可依，回滚和审计才真正可靠。