微调机器人，最坑的往往不是模型参数

大多数微调指南都在讲模型本身：学习率、检查点、训练步数。PrismaX 的消融实验写了个不一样的版本——他们围绕 π0.5 在 YAM 抓取放置数据上的微调，花了同样多的篇幅讲模型之外的东西：灯光、相机位置、机械臂校准、推理 bug。

一个微调好的策略跑在物理设备上，设备的小细节能决定它到底能不能用。

这项工作的背后是 PrismaX 在 IROS 的演示。团队在 YAM 数据采集台上收集了一套干净的数据，想让模型跑在另一套基于 YAM 但略有不同的设备上。动机很实际：大实验室可以按 CAD 图纸复制设备，小实验室通常只有现成的旧设备想复用。

为了搞清楚什么因素真正起作用，他们做了消融：一次只改一个变量，观察结果。他们还构建了一个路径追踪 YAM 模拟器，每天能跑数千次 π0.5 rollout，不用反复重置场景，并且已经开源，让人能在自己的设备上复现同样的实验。

发现 1：别只训练 expert

一个教训是：应该同时训练 action expert 和 backbone，而不是只训练 expert。最明显的证据来自灯光实验。

发现 2：灯光能毁掉捷径

硬光把只训练 expert 的 checkpoint 成功率砍掉大约一半。同样的灯光对完整微调没有任何影响。

如果你为了省算力只想训练模型的一部分，这个代价值得掂量：便宜的 checkpoint 在完整版轻松应对的条件下会变得很脆弱。

发现 3：相机位置最容易被忽略

团队每次只动相机几度、几厘米。抬高相机几乎没影响。平移相机直接崩了。

这个差异值得记住。一个任务可能在某个阶段看起来正常，换个阶段就失败，而且只测“能不能抓起来”并不能说明设备真的没问题。匹配相机的粗粒度属性（比如视场角）也被证明是有效的。

发现 4：机械臂校准毫不留情

模型对机械臂本身极其敏感。磨损或零位不准的机械臂，只要累计编码器偏移几度，准确率就能掉到接近零。

发现 5：推理 bug 藏在眼皮底下

这份报告还讲了推理 bug，后续跟进内容显示坑有多深。一个 Python 管道缓冲区悄悄给每次 rollout 增加了几百毫秒延迟。修复并优化流水线后，每步推理时间从 230 多毫秒降到 87 毫秒，机器人开始复现人类操作员的暂停和纠正习惯。

快速检查清单

如果你要在自己的设备上微调 π0.5，按这个顺序排查：

• 匹配训练数据的相机视场角和位置
• 检查机械臂零位和编码器偏移
• 考虑同时训练 backbone 和 expert
• 在不同灯光下测试，别只测最优条件
• 观察实时视频流的延迟，不只盯着机械臂
• 抓取和放置分别评估，两者可能独立失败