4. 模型训练与版本产出

在 IGX 平台上，模型版本治理的起点并不是部署，而是训练与微调阶段产生的每一个可追溯产物。IGX 开发套件（如 IGX Orin Developer Kit）通常配备 NVIDIA dGPU 或 iGPU、JetPack/L4T 或 IGX 软件栈、CUDA、TensorRT、Triton 等组件，其训练环境与数据中心 GPU 存在差异：显存容量有限、功耗与散热约束明显、驱动与容器版本绑定更紧。因此，本节的核心任务是：在 IGX 开发套件上完成模型训练或微调，并把实验跟踪、检查点管理与版本快照三者串成一条可复现的产出链。

一、训练/微调在 IGX 上的实际约束

在 IGX 上做训练或微调，首先要明确“能训什么、不能训什么”。以 IGX Orin 64GB 为例，其 GPU 显存约 64GB 共享内存架构，实际可用于训练的显存受系统与显示占用影响。对于视觉检测、缺陷分类、语音唤醒等边缘任务，通常采用以下策略：

• 小模型全量训练：如 ResNet-18、MobileNetV3、YOLOv8n，batch size 可设 16～32，输入 640×640，混合精度 AMP 开启。
• 大模型微调：如 ViT-B/16、Whisper-small，采用 LoRA 或冻结主干只训分类头，显存占用可下降 40%～70%。
• 梯度累积：当 batch size 受显存限制时，用 accum_steps=4 模拟更大 batch，但需同步调整学习率。

一个可参考的微调命令示例如下，使用 PyTorch 与 AMP，在 IGX 上以 8 个 epoch 微调缺陷分类模型：

python train.py \
  --data /data/defect_cls \
  --model resnet18 \
  --pretrained \
  --epochs 8 \
  --batch-size 16 \
  --lr 3e-4 \
  --amp \
  --output-dir /workspace/runs/defect_cls_v1 \
  --save-every 1 \
  --seed 42

其中 --save-every 1 表示每个 epoch 保存一次检查点，--seed 42 固定随机种子，保证同一数据与配置下结果可复现。训练过程中应观察 loss 曲线、验证集准确率、GPU 显存占用与温度。若显存接近上限，可降低 batch size 或启用梯度检查点。

二、实验跟踪：把“一次训练”变成可检索的记录

实验跟踪的目标是回答三个问题：这次训练用了什么数据、什么超参数、得到了什么指标。在 IGX 上，推荐使用 MLflow 或 Weights & Biases（wandb）作为跟踪后端，本地记录元数据，远端同步看板。关键记录字段包括：

• run_id：唯一实验标识，建议与版本快照 ID 关联。
• 数据集指纹：数据路径、样本数、类别分布、预处理版本、SHA256 摘要。
• 超参数：模型名、学习率、batch size、epoch、优化器、AMP 开关、LoRA rank。
• 指标：train_loss、val_loss、val_acc、mAP、推理延迟（ms）、显存峰值。
• 环境：IGX 型号、L4T 版本、CUDA/cuDNN、PyTorch/TensorRT 版本、容器镜像 tag。

例如，在训练脚本中嵌入 MLflow 记录：

import mlflow
mlflow.set_tracking_uri("http://mlflow.local:5000")
mlflow.set_experiment("igx-defect-cls")

with mlflow.start_run(run_name="resnet18_lora_r8"):
    mlflow.log_params({"lr": 3e-4, "batch": 16, "amp": True, "lora_r": 8})
    mlflow.log_metric("val_acc", 0.932, step=epoch)
    mlflow.log_artifact("checkpoints/epoch_8.pt")
    mlflow.set_tag("igx_model", "IGX-Orin-64GB")
    mlflow.set_tag("l4t", "35.4.1")

这样，任何一次训练都能通过 run_id 回溯到具体配置与产物。对于量产部署，实验跟踪记录是模型版本快照的“出生证明”。

三、检查点管理与版本快照

检查点（checkpoint）是训练过程中的中间产物，版本快照（snapshot）则是经过筛选、可交付的最终产物。两者不能混为一谈。检查点管理要点：

• 命名规范：{model}_{dataset}_{date}_{epoch}_{metric}.pt，例如 resnet18_defectcls_20250612_e8_acc0.932.pt。
• 保留策略：保留 best、last 与每 N 个 epoch 的检查点，避免磁盘被占满。
• 完整性校验：保存后计算 SHA256，写入 manifest 文件。
• 元数据绑定：每个检查点附带 JSON，记录 run_id、数据指纹、超参数、指标。

版本快照则是在检查点基础上，经过验证后固化的交付单元。一个快照应包含：模型权重、推理配置（输入尺寸、归一化参数、类别映射）、ONNX/TensorRT 引擎、精度基线、测试报告。快照 ID 建议采用语义化版本，如 defect-cls-v1.2.0，并写入模型注册表。

四、从训练到快照的完整链路

下面这张图展示了在 IGX 开发套件上，从数据准备、训练/微调、实验跟踪、检查点管理到版本快照的完整数据流与产物关系。图中区分了“过程产物”与“交付产物”，并标出了关键校验点。

图中左侧是数据准备，中间是训练与实验跟踪，右侧是检查点管理，下方是版本快照。虚线表示元数据绑定关系，实线表示产物流转。关键校验点位于快照生成之前，确保只有通过完整性校验与指标验证的检查点才能进入交付环节。

五、可执行的版本快照清单

为了让版本快照真正可交付，建议在 IGX 上维护一份快照清单，字段如下表所示。该清单可直接作为模型注册表的录入模板。

当快照状态为 validated 时，才允许被后续的量产部署流水线拉取。若校验失败，应记录失败原因并保留原始检查点，便于回溯与重训。

总结来说，在 IGX 开发套件上完成模型训练与版本产出，关键不在于“训出一个模型”，而在于把数据、超参数、指标、检查点与快照串成一条可追溯、可校验、可复现的链路。实验跟踪负责记录过程，检查点管理负责保存中间状态，版本快照负责固化交付单元。三者各司其职，才能支撑后续的量产部署与模型治理。