用一套 NVIDIA Cosmos 3 跑通机器人策略训练到底需要多
最让我质疑的是，大多数团队习惯给生成数据准备一组卡，给训练准备一组，给评估再准备一组。这种碎片化的资源管理在面对像 NVIDIA Cosmos 3 这种全能型模型时简直是浪费。因为 Cosmos 3 的架构设计非常反直觉：它采用了 Mixture-of-Transformers (MoT) 结构，并且在训练和推理之间做了刻意的非对称设计。最核心的一点是，它把视频、图像、动作和声音全部统一成了同一个 token 流。这意味着同一个模型家族可以同时扮演“前向动力学世界模型”（生成视频）、“逆向动力学动作标签器”和“可部署的动作策略”。
既然一个模型能干三件事，为什么还要分三拨卡？把这三类工作负载全部调度到同一个持久化的 GPU 节点池里，通过时间分片共享资源，这才是正经的工程实践。
如果要实操构建这样一个工厂，我建议直接上 SageMaker HyperPod 搭配 EKS。最关键的细节在于存储层，你必须配置一个支持多 TB 级的共享存储层，否则在处理像 DROID 这种机器人数据集时，数据加载会直接变成整个 pipeline 的瓶颈。
这里分享一个我在调试机器人策略阶段（Robot-policy stage）时使用的核心配置逻辑。虽然具体的任务调度由 Kubernetes 处理，但你需要在 Job Manifest 里明确定义资源请求，以确保在进行分布式后训练时，不同节点间的通信不会因为拓扑问题导致性能暴跌。
以下是我在部署 Cosmos 3 物理 AI 工作流时，针对 DROID 数据集训练阶段参考的资源定义片段（简化版）：
apiVersion: batch/v1
kind: Job
metadata:
name: cosmos3-robot-policy-train
spec:
template:
spec:
containers:
- name: cosmos3-trainer
image: nvidia/cosmos3-training:latest
resources:
limits:
nvidia.com/gpu: 8 # 每节点8卡，确保 NVLink 互联
memory: "512Gi"
cpu: "64"
env:
- name: DATASET_PATH
value: "/shared/droid-dataset/v1"
- name: MODEL_CONFIG
value: "mot_joint_attention_v3"
command: ["python", "train_policy.py", "--config", "configs/droid_policy.yaml"]
restartPolicy: OnFailure在实际跑这个闭环时，我发现一个非常残酷的真相：衡量成本的标准绝对不是某个单次任务的峰值吞吐量，而是所谓的 "GPU Goodput"（有效产出）。因为你预留的容量是固定付费的，如果你的 pipeline 在生成数据和模型训练之间切换时有太多的停顿或资源闲置，你的单位成本会高得离谱。
Cosmos 3 这种单 trunk 处理所有模态的设计，本质上是在通过架构统一来对冲资源碎片化。它不再需要一个 Diffusion-Transformer 视频生成器配一个 VLM 文本条件模型，而是每层都进行了集成。这种设计在工程上的直接结果就是：你可以把一个原本需要三套基础设施的复杂流程，压缩到一个统一的控制平面下。
如果你打算尝试，记得重点检查你的共享存储带宽，因为在分布式后训练阶段，模型权重和数据集的频繁同步会瞬间吃掉所有 IO。
