Metatron v1：同一套人形机器人策略，为什么换“目标代码”就能换任务
NVIDIA 在 2026 年 10 月 28 日随 ProtoMotions 3 发布了 Metatron v1：一套面向 Unitree G1 的全身控制策略，可以接收路径、速度、稀疏身体目标、场景几何和起身要求。更值得关注的不是演示里机器人会走、会坐或会从地上起来，而是这些任务没有各自重新训练一套控制器——底层策略冻结后，开发者主要通过目标程序描述“接下来身体应该到哪里”。
这不是把一句自然语言直接发给电机，也不是让大语言模型参与 50 Hz 的实时控制。项目页展示的大模型用途发生在离线开发阶段：它可以帮助人编写和修改技能代码；真正运行时执行的是普通程序，程序不断产生结构化目标，Metatron 再把目标变成 29 个关节的动作。
可以把它想成滑冰教练与运动员的分工：技能程序在冰面上画出路线、标出哪只脚何时抬到哪里；冻结策略负责平衡、关节协调和应对小扰动。换路线不必重新训练运动员，但画线也不能保证任何动作都做得出来。
它接收的不是文本，而是一张“未来身体草图”
Metatron 的输入里，真正表达任务的是几类结构化目标：
- 未来若干时刻，指定身体部位的位置或朝向；
- 平面速度和朝向，例如“向前 1 米每秒，但身体朝向右侧”；
- 一段动作风格样本，例如蹲伏或敬礼姿态；
- 用盒子近似的场景几何，以及物体是否可见；
- 哪些目标有效、哪些应该忽略的掩码。
“掩码”是这里的关键。传统动作跟踪策略常拿到一段完整参考动作，像逐帧照着舞蹈视频模仿；Metatron 训练时会故意把大量未来信息遮住，有时只给速度，有时只给一只手的位置，有时再加一个物体。策略必须学习如何补齐没说出来的全身动作。
因此，同一个接口可以表达看起来不同的任务：路径跟随只需要未来落点和朝向；伸手触碰可以只约束手和躯干；坐下则把骨盆、双脚与场景盒子的关系作为目标。目标仍然是几何量，不是“请自然地坐下”这样的开放文本。
一套策略如何学会补齐缺失动作
论文给出的训练过程可以分成两层。
第一层先训练专门的跟踪策略，让它们在仿真中掌握完整动作、跌倒恢复和场景交互。这些老师拥有更完整的参考信息，目标是把基础动作做稳。
第二层再把多位老师蒸馏到一个 MaskedMimic 风格的学生里。学生看到的是随机缺失后的目标，但要尽量复现老师给出的动作。策略内部使用条件 VAE：训练时的 posterior 可以读取更多未来信息；部署时只有 prior 根据当前状态和可见目标产生潜变量，再由解码器输出动作。官方模型卡给出的实现是 64 维球面潜变量，以及六层、四头、宽度 1024 的 Transformer prior。
这种安排解释了“冻结后还能换任务”的来源：策略不是记住几段固定技能，而是在训练中反复练习“只知道部分目标时，如何补出一个物理上连贯的全身动作”。技能代码改变的是目标，不是关节控制算法本身。
但它也划出了明确边界。如果新任务要求训练数据里没有覆盖的接触模式、速度范围或身体构型，目标程序无法凭空创造能力。官方模型卡也明确说，恢复和交互仍会因目标、初始姿态与物理条件失败。
技能程序到底做什么
技能程序是有状态的目标生成器。每个控制周期，它读取当前任务进度，给未来几个时间点填入脚、手、躯干或根节点的目标，并决定哪些掩码打开。
项目页用步态修改举了一个直观例子：代码根据速度计算步频与步幅，让左右脚保持半个周期的相位差，再把未来脚部轨迹交给策略。早期版本走路不稳时，修改的是这段目标逻辑，而不是重新训练网络。论文和项目页把这称为一种快速迭代路径，但页面展示的是定性案例，不是独立控制基准。
这一分层也意味着可以审查技能逻辑。路径是否越界、手要伸向哪个物体、跌倒时谁接管目标，都能在代码层做限制；策略则专注“怎么动”。不过，技能代码可读不等于神经策略可解释，更不等于安全证明。
先跑校验，不要一上来控制真机
官方仓库提供了浏览器演示包和固定版本下载脚本。下面这组命令不连接机器人，也不下载约 459 MB 的原生检查点，只验证演示归档、固定版本配置与哈希；适合先确认仓库、Git LFS 和发布物是否一致。
git clone https://github.com/NVlabs/ProtoMotions.git
cd ProtoMotions
# demo.zip 由 Git LFS 管理；校验清单、哈希、许可证和固定模型地址
git lfs pull --include="demos/metatron/demo.zip"
python scripts/install_metatron_demo.py --check
# 只下载并验证配置、模型卡和许可证，不下载权重
python scripts/download_metatron.py \
--configs-only \
--output-dir /tmp/metatron-configs2
3
4
5
6
7
8
9
10
11
我在仓库提交 f26ba6c4e2b2721a53e3674f77cd1f28ca4ef76f 上实际执行了这两项检查：演示归档通过完整性校验并成功解包；配置下载器验证了固定版本清单，下载内容约 201 KiB。原生部署参考中的目标构造与动作历史测试也分别通过 4 项和 5 项测试。
如果只想看仿真，不必安装 Python 训练环境。官方在线演示会在浏览器里下载约 403 MB 的 FP32 模型外部权重，并用 MuJoCo 与 ONNX Runtime Web 运行；WebGPU 是推荐路径，CPU/WASM 只是回退方案。我的测试浏览器完成了 403 MB 下载，但随后因无法创建 WebGL 上下文而停止，所以没有把“网页能打开”写成实时策略已经跑通。浏览器、显卡驱动、WebGPU/WebGL 和内存仍是实际门槛。
403 MB、459 MB 与“开源”不是一回事
Metatron 当前至少有三类容易混淆的发布物：
- Hugging Face 上约 459 MB 的原生 PyTorch 检查点，包含推理权重、归一化统计和训练时 posterior，但不含优化器状态；
- 浏览器演示使用的约 403 MB FP32 ONNX 外部权重与小型图文件；
- 六机器人竞速演示的批处理导出，同样约 403 MB，但输入批次和用途不同，不能与单机器人演示互换。
ProtoMotions 源码采用 Apache-2.0；模型权重、导出模型和序列化配置采用 NVIDIA Open Model License；训练动作、机器人资产和演示动作又有各自条款。训练动作片段和家具数据没有随模型发布。仓库里的浏览器应用也只有编译后的 JavaScript/WASM 产物，没有对应的 TypeScript 工程和源码映射。
所以它是“源码框架开放、权重可下载、部分应用只发构建产物”，不能简单压缩成“全部 Apache 开源”。
从网页演示到真机，中间还隔着一整套控制系统
原生模型的接口不是一个 predict(state) 就结束。官方契约固定了 39 个输入，包括当前关节状态、八帧状态历史、九帧动作历史、未来目标、掩码和场景输入；历史错一帧，输入维度仍然正确，但语义已经错了。输出的 29 个原始动作还要经过固定映射成为 PD 目标。
网页演示能证明模型可以在特定 MuJoCo 环境中被加载和交互，不能证明真机安全。官方文档要求真机侧另行实现限位、监督与急停；C++/TensorRT 部署目录也明确标为实验性参考，不是受支持的发布产品。机器人几何、惯量、PD 增益、关节顺序、控制频率和端到端延迟都要重新验证，只有输入形状相同远远不够。
发布包给出的 ONNX 数值对齐测试最大误差为 5.55e-6，它只说明导出前后在 60 组状态上的数值接近，不是任务成功率，更不是硬件安全指标。论文中的真机演示和对照结果来自项目团队，也还不能替代第三方复现。
哪些人现在值得试
如果你在做仿真人形机器人、动作生成或目标接口设计，Metatron 最值得借鉴的是“稀疏目标 + 掩码蒸馏 + 冻结全身策略”这条分层路线。它允许你先在目标程序层快速修改任务，再决定是否真的需要重新训练。
如果你的目标是马上部署 G1 真机，它更适合作为研究起点而不是即插即用控制器。先在固定版本的 MuJoCo 环境里复现观察量、动作历史和目标掩码，再测延迟与失败恢复；最后才是带急停和人工监督的硬件检查。不要让大语言模型直接生成任意目标并绕过几何限位，也不要把一次坐下或起身演示外推成通用家庭机器人能力。
Metatron v1 的新意不是“一个模型学会所有动作”，而是把任务变化尽量推到可编程目标层，把全身协调保留给同一套策略。这种边界很实用：它既缩短了技能迭代路径，也让我们更容易看见剩下的难题——目标能否实现、传感是否可靠、延迟是否稳定，以及失败时谁来接管。
💬 评论