Physical AI 系统不是提交一次训练任务就能完成的工程。合成数据生成、后训练、评估、失败样本回流和再次训练会持续循环，而且每个阶段对 GPU、存储和调度的要求都不同。NVIDIA Cosmos 3 可以承担这条流水线中的模型与数据处理工作，而运行在 Amazon EKS 上的 SageMaker HyperPod 则提供持久、具备故障恢复能力的 GPU 集群底座。
这类平台真正需要优化的不是“GPU 看起来有多忙”，而是 GPU goodput：分配出去的 GPU 时间中，有多少最终转化成了有效的数据生成、训练或评估进度。
模型工厂不是一张串行任务表
一条可持续运行的 Physical AI 流水线通常包含三个核心环节：
- 合成数据生成：构造场景、动作和环境变化，产出视频、传感器数据或训练样本。
- 后训练：使用生成数据、真实数据和困难样本继续调整模型。
- 闭环评估：在目标任务或仿真场景中测试模型，将失败案例重新送回数据生成与训练环节。
三个环节不应紧耦合成一个超长容器进程。更稳妥的做法是把数据集、检查点和评估报告存入共享对象存储，把每个阶段建模为可重试的 Kubernetes 工作负载。这样，某个节点或任务失败时，只需重跑当前阶段，不必重新执行整个周期。
HyperPod 集群是持久资源，因此镜像缓存、监控、调度策略和共享存储连接可以跨任务复用。EKS 则负责声明式调度、任务隔离以及与现有 Kubernetes 工具链集成。两者结合后，团队可以把注意力从临时集群生命周期转向流水线吞吐量和失败恢复。
用数据契约连接三个阶段
模型工厂最容易被忽视的部分不是训练代码，而是阶段之间的契约。建议为每轮迭代生成唯一的 RUN_ID，并采用固定的对象路径：
s3://physical-ai-factory/runs/<RUN_ID>/synthetic/
s3://physical-ai-factory/runs/<RUN_ID>/checkpoints/
s3://physical-ai-factory/runs/<RUN_ID>/evaluation/
s3://physical-ai-factory/runs/<RUN_ID>/manifest.json
manifest.json 可以记录数据版本、基础模型、容器镜像摘要、随机种子、训练参数和评估阈值。任务完成后先写数据文件，再原子地写入完成标记。下游任务只消费带有完成标记的产物，避免读取尚未上传完整的数据集或检查点。
闭环评估也不应只给出一个平均分。对于机器人、自动驾驶或视觉控制任务，更有价值的输出通常包括场景类别、失败原因、置信度区间以及可复现的场景种子。数据生成阶段据此增加困难场景的采样权重，才能形成真正的闭环。
可以这样拆分 EKS 工作负载
下面是一个可改造的 Kubernetes Job 模板。它不假定 Cosmos 3 的具体 CLI，而是约定镜像内提供 /opt/factory/run-stage.sh。运行前需要替换镜像地址、S3 存储桶、IAM service account，以及集群实际使用的 GPU resource name 和节点标签。
apiVersion: v1
kind: Namespace
metadata:
name: physical-ai
---
apiVersion: batch/v1
kind: Job
metadata:
name: cosmos-post-train-demo
namespace: physical-ai
labels:
app.kubernetes.io/name: cosmos-model-factory
factory.stage: post-train
spec:
backoffLimit: 3
ttlSecondsAfterFinished: 86400
template:
metadata:
labels:
app.kubernetes.io/name: cosmos-model-factory
factory.stage: post-train
spec:
restartPolicy: Never
serviceAccountName: physical-ai-runner
nodeSelector:
workload.example.com/accelerator: gpu
containers:
- name: worker
image: 111122223333.dkr.ecr.us-west-2.amazonaws.com/cosmos-factory:latest
imagePullPolicy: IfNotPresent
command: ["/bin/bash", "-lc"]
args:
- >-
/opt/factory/run-stage.sh
--stage post-train
--input "${RUN_ROOT}/synthetic"
--output "${RUN_ROOT}/checkpoints"
env:
- name: RUN_ID
value: "2025-physical-ai-001"
- name: RUN_ROOT
value: "s3://physical-ai-factory/runs/2025-physical-ai-001"
- name: NCCL_DEBUG
value: "WARN"
resources:
requests:
cpu: "16"
memory: 128Gi
nvidia.com/gpu: "8"
limits:
cpu: "16"
memory: 128Gi
nvidia.com/gpu: "8"
保存为 post-train-job.yaml 后，可用以下命令提交并观察任务：
kubectl apply -f post-train-job.yaml
kubectl -n physical-ai wait \
--for=condition=complete \
job/cosmos-post-train-demo \
--timeout=24h
kubectl -n physical-ai logs \
job/cosmos-post-train-demo \
--all-containers=true
生产环境中，可以为 synthetic-data、post-train 和 evaluation 分别维护 Job 模板，再由 Argo Workflows、Tekton、Airflow 或内部控制器按产物状态触发。具体编排器不是关键，关键是每个阶段都必须支持幂等重试，并能从最近的完整检查点恢复。
把 GPU goodput 变成一等指标
GPU 利用率只能说明设备在采样瞬间是否执行计算，无法回答计算是否产生了有效进度。任务可能因为重复计算、频繁重启、数据加载停顿或多卡同步阻塞而保持较高利用率，却没有持续产出可用结果。
可以为每个阶段定义：
GPU goodput = 有效工作所消耗的 GPU-seconds / 已分配的 GPU-seconds
“有效工作”必须按阶段具体化：
| 阶段 | 有效进度示例 | 常见损耗 |
|---|---|---|
| 合成数据 | 通过质量检查的样本数 | 无效场景、写入失败、重复生成 |
| 后训练 | 已提交的有效 step 或 token | 数据等待、检查点恢复、通信停顿 |
| 闭环评估 | 完成且结果可复现的场景数 | 仿真初始化、超时、损坏输出 |
假设监控系统已经暴露 factory_effective_gpu_seconds_total 和 factory_allocated_gpu_seconds_total 两个计数器，可以用下面的 PromQL 观察各阶段一小时窗口内的 goodput：
sum by (stage) (rate(factory_effective_gpu_seconds_total[1h]))
/
sum by (stage) (rate(factory_allocated_gpu_seconds_total[1h]))
还应同时记录排队时间、启动时间、检查点恢复时间、数据读取等待和失败重试次数。只有把这些指标与 goodput 放在一起，才能判断应该增加 GPU、改善数据供给，还是调整任务粒度。
落地时优先检查这些问题
开始时不必立即把所有阶段自动化。先选择一个可重复的 Cosmos 3 工作流，固定输入输出契约，并在 HyperPod 上连续运行多个周期。随后再逐步增加并发、弹性调度和自动失败样本回流。
上线前应确认：任务能从检查点恢复；节点故障不会破坏共享产物；镜像和数据版本可以追溯；每个阶段都有完成标记；评估失败能够映射回具体场景；GPU goodput 能按阶段、任务和模型版本切分。
这种架构的代价是需要维护 Kubernetes 模板、可观测性和数据契约。但对于需要反复生成数据、训练和评估的 Physical AI 系统，持久集群与闭环流水线能把故障恢复和资源效率变成平台能力，而不是每次实验都重新解决的问题。