★ FEATURED ARTICLE 具身智能圈终于等来了一场像样的攻防战。就在 RoboChallenge 最新一期评测榜单更新之后千寻 Spirit v1.5 直接把此前连续霸榜多轮的 Pi0.5 挤下了第一的位置社区里不少人用新王登基来形容这次更替。说实话我第一眼看到这个结果并不意外因为从 v1.4 开始千寻 Spirit 在操作泛化性上的进步就很明显这次 v1.5 等于把最后的短板也补齐了。作为一直在跟开源具身模型打交道的人我想从技术角度拆一拆这次登顶背后的逻辑聊聊千寻 Spirit v1.5 到底强在哪、Pi0.5 输在哪以及开源具身模型接下来会往哪个方向卷。RoboChallenge 不是那种刷几个 benchmark 分数就能排上去的榜单它考验的是机器人在真实物理环境里的操作能力。千寻 Spirit v1.5 能在这种评测里终结 Pi0.5 的领跑时代靠的不是单一指标的突进而是整套技术路线的一次系统升级。下面我会从评测含金量、模型架构、训练策略、部署实操和生态影响这几个维度展开尽量把这次换王背后的技术原因讲透。1. RoboChallenge评测的含金量为什么这次登顶值得关注很多人第一次听说 RoboChallenge会拿它跟那些传统视觉语言模型榜单做对比但实际上这个评测的定位完全不同。传统榜单考的是模型在静态数据上能不能答对问题而 RoboChallenge 考的是机器人真刀真枪动起来能不能把活干完。这两件事的难度差距就像做试卷和上手术台的区别。1.1 评测项目设置从看得懂到做得到RoboChallenge 的评测项目覆盖了桌面操作、移动操作、双臂协同、长程任务等多个维度。每一轮评测组织方会准备一批物理任务比如抓取不同材质的物体、打开抽屉并把物体放进去、用螺丝刀拧紧螺丝、叠衣服、倒液体等等。这些任务看起来简单但对于机器人来说每一个都涉及视觉感知、力觉反馈、运动规划、错误恢复等多环节的耦合。尤其值得一提的是长程任务Long-horizon tasks这是把大多数模型淘汰掉的重灾区。一个长程任务往往包含 4 到 8 个连续操作步骤比如拿起杯子→走到饮水机→接水→端到桌边→放下中间任何一步失败都需要模型自己检测并恢复。Pi0.5 在单步操作上一直表现不错但一旦进入长程任务它的累积误差就会迅速放大。千寻 Spirit v1.5 这次在长程任务上的成功率提升非常明显这也是它能拉开差距的关键原因。1.2 评测协议与口径为什么说这个成绩不含水分RoboChallenge 的评测协议比较严格所有参赛模型需要在统一的机器人平台上运行组织方会限制评测时的计算资源、推理延迟和传感器配置。也就是说你不能靠堆算力或者外挂一个专用的运动规划器来作弊模型必须在端到端条件下完成所有决策。评测指标上除了总成功率Success Rate之外还会统计平均操作时长、错误恢复次数、人为干预次数。千寻 Spirit v1.5 不仅在成功率上领先平均操作时长也比 Pi0.5 缩短了大概 18%人为干预次数从每 10 次任务平均 2.3 次降到了 0.7 次。这个数据侧面反映出模型对边界情况的处理能力更强了不是靠运气完成了任务而是真正知道自己在干什么。1.3 基准模型梯队被拉下马的 Pi0.5 到底是什么水平为了理解这次登顶的分量需要先看看 Pi0.5 的江湖地位。Pi0.5 出自某开源实验室的具身系列在 RoboChallenge 连续三轮霸榜一度被国内社区当成闭源商业模型的有力替代品。它的优势在于动作分片预测Action Chunking机制成熟在小样本条件下微调效果稳定而且配套的推理代码写得很规整部署门槛不高。但 Pi0.5 的问题也很明显。它的主干网络仍然是基于静态视觉语言模型的架构改造在动态场景中的实时感知能力有限。面对透明物体、反光表面、遮挡严重的操作场景时会出现看到了但认不准的情况。千寻 Spirit v1.5 这次恰恰是在视觉感知和动作生成的耦合方式上做了大改所以能在这些硬场景里把差距拉回来。注意RoboChallenge 的评测结果只代表物理仿真和受控实验室环境下的表现不能完全等同于工业生产现场。但相比纯数据集的评测这个结果已经具备相当高的参考价值。2. 千寻Spirit v1.5的技术底牌架构设计、训练策略与关键创新千寻 Spirit v1.5 能被称作新王核心原因在于它没有走堆参数的老路而是在架构设计上动了真格。从公开的技术说明来看v1.5 最大的变化是引入了空间-动作联合编码机制同时把视觉主干从静态预训练模型换成了可实时更新的动态感知模型。这两个改动直接决定了它在 RoboChallenge 上的表现。2.1 空间-动作联合编码把看到和做到绑定在一起老一代具身模型通常使用两个独立模块视觉模块负责理解场景动作模块负责生成动作。这种分离设计有一个天然问题视觉理解的目标和动作执行的目标并不完全一致。视觉模块可能关注了桌子上的所有物体但动作模块真正需要知道的只是要抓的那个杯子在什么位置、什么姿态、有没有被挡住。千寻 Spirit v1.5 的空间-动作联合编码Spatial-Action Joint Encoding解决了这个问题。它不是先让视觉模块生成一个全局场景描述再把描述传递给动作模块而是直接从视觉特征图里提取与动作相关的局部空间特征并与动作标记Action Token做联合编码。相当于模型在看的时候就带着我要去抓它的任务目标视觉特征和动作决策被放进同一个表征空间里训练。这个设计带来的直接好处是推理效率提升和误差传递减少。传统架构中视觉模块的识别误差会向上传递给动作模块而联合编码让模型在训练时就能学会忽略与任务无关的视觉干扰。在 RoboChallenge 的透明杯子抓取测试中千寻 Spirit v1.5 的成功率比 Pi0.5 高出了约 27%。2.2 训练策略从数据量大转向数据质量高具身模型的训练数据一直是稀缺资源各家开源模型的差距往往不体现在模型结构上而是体现在数据配方上。千寻 Spirit v1.5 这次在数据侧的动作很大它采用了三阶段训练策略第一阶段大规模视觉-语言预训练使用约 9000 万条互联网图文数据目的是让模型获得基础的世界知识和物体识别能力。第二阶段遥操作数据 仿真数据的混合训练在约 150 万条机器人操作轨迹上进行行为克隆其中仿真数据占比约 40%。第三阶段强化学习微调在 50 万条偏好对比数据上做优化目标是提升长程任务的错误恢复能力和动作平滑度。这个训练策略的关键不在于某一个阶段的技术有多新而在于数据配方的比例控制。尤其是第三阶段的强化学习微调它针对的是模型能做对但做不雅的问题。实测中千寻 Spirit v1.5 的动作抖动明显比 Pi0.5 少物体掉落率低了不少这就是偏好优化带来的效果。2.3 动态感知主干低延迟实时响应具身操作中非常容易被忽视的一个指标是感知延迟。机器人在真实环境中执行抓取动作时视觉反馈的延迟直接决定了它能不能应对物体移动、光照变化等动态干扰。Pi0.5 的视觉骨干网络基于静态视觉模型单帧感知延迟约 120 毫秒这在静态场景下够用但在动态场景下就很吃力。千寻 Spirit v1.5 换上了动态感知主干利用稀疏注意力机制将单帧感知延迟降到了 45 毫秒左右。延迟降低之后模型可以进行更密集的感知-动作循环相当于在同样的单位时间内做了更多的看-想-动迭代。这也是它在倒水、叠衣服等需要持续反馈的操作中表现更加稳定的原因。提示动态感知主干的代价是显存占用比静态模型高了约 30%这意味着部署千寻 Spirit v1.5 对显卡的要求会比 Pi0.5 更高。后面我会专门讲部署时的显存优化方法。2.4 与 Pi0.5 的架构对比一张表看明白对比维度千寻 Spirit v1.5Pi0.5视觉感知方式动态感知主干单帧延迟约 45ms静态视觉主干单帧延迟约 120ms动作表征联合编码动作与空间特征共享表征空间动作分片预测基于离散动作Token长程任务机制隐式任务记忆 强化错误恢复条件动作生成错误恢复依赖外部逻辑训练数据规模约 9150 万条混合数据约 4500 万条混合数据平均推理速度约 28 Hz约 16 Hz部署显存需求约 16 GBFP16约 12 GBFP16从表里可以清楚看到千寻 Spirit v1.5 在感知实时性和动作表征两个核心维度上都走了和 Pi0.5 不同的技术路线。Pi0.5 的优势在于架构简单、部署门槛低但它的设计上限决定了它在长程任务上很难有质的突破。3. 从Pi0.5到千寻Spirit v1.5开源具身模型的一次范式切换这次 RoboChallenge 登顶意义不只是更换了一个榜首模型更在于它标志着开源具身模型的一次范式切换。如果用一句话来概括这种切换从让模型学会动作转向了让模型理解场景并主动决策。这个变化直接影响后续模型的研发方向。3.1 旧范式的天花板动作分片预测的局限性Pi0.5 采用的动作分片预测Action Chunking with Transformers一直是具身模型的主流方案。它把连续动作序列切成固定长度的小块然后让模型一次性预测一小段动作再滚动执行。这种方案有几个优点实现简单、训练稳定、在小数据条件下表现好。但它有一个很难突破的天花板——模型本质上是在做模仿而不是在理解。动作分片预测依赖大量高质量专家轨迹数据一旦遇到训练数据里没见过的场景模型就很容易进入死循环反复尝试同一个动作却无法根据环境反馈调整策略。在 RoboChallenge 评测中这个现象被专门拿出来记录为无效重复行为。Pi0.5 在复杂长程任务中经常出现这种无效重复每次重复浪费 3 到 5 秒累积下来就拉低了整体效率。3.2 新范式的核心把任务意图注入视觉理解千寻 Spirit v1.5 的范式核心可以简化成一个公式任务意图 空间感知 动作生成 闭环决策。它不再把视觉理解和动作生成当成两个独立的阶段而是让任务目标从一开始就参与视觉特征的选择。这种设计更接近人类的操作方式我们抓一个杯子的时候不会刻意去理解桌上所有物体的语义而是直接定位杯子的位置、姿态和抓取点。这种范式的优势在开放场景中体现得尤其明显。比如面对一个从未见过的厨房环境千寻 Spirit v1.5 可以依靠任务意图驱动的方式快速锁定操作对象并生成合理动作序列而动作分片模型则会因为环境特征和训练分布不一致而性能骤降。3.3 RoboChallenge评分规则对范式的隐性引导还有一个值得关注的细节RoboChallenge 的评分规则中有一项首次尝试成功率First-Try Success Rate。这个指标不会告诉你模型经过多少次尝试才成功只看第一次操作能不能成功。这项指标对动作分片模型非常不友好因为这些模型通常需要先试探几次才能找到正确策略。千寻 Spirit v1.5 的首次尝试成功率达到了 63%Pi0.5 只有 41%。这说明范式的切换不仅是理论上的优雅也在评测指标上产生了实打实的优势。作为开发者我不建议盲目追逐评测榜单但如果一个模型在多个独立设计的指标上都能领先那背后的技术路线就值得认真研究。3.4 开源模型与闭源模型的差距正在缩小这次千寻 Spirit v1.5 登顶 RoboChallenge还有一个更宏观的意义开源模型和闭源商业模型之间的能力鸿沟正在快速缩小。以前开发者在实际项目中基本只能选择闭源商业 API因为开源模型在操作成功率上差距太大。现在千寻 Spirit v1.5 的出现意味着开发者可以用开源方案完成不少工业级任务不再需要承担高昂的闭源 API 费用。当然这里要给泼点冷水开源模型虽然在评测榜上表现不错但部署成本、硬件要求、工程适配都需要开发者自己搞定。闭源商业模型的价值在于开箱即用所以短期内两者不是完全替代关系而是互补关系。4. 实测视角部署千寻Spirit v1.5的完整流程与硬件门槛聊完技术原理接下来讲点实操内容。千寻 Spirit v1.5 发布后我在自己的模拟项目里做了完整的部署测试包括环境配置、模型加载、推理优化和真机对接。这里分享的是部署过程中遇到的重点问题和解决方法供打算尝试的开发者参考。4.1 软硬件环境要求先看看你的设备够不够格千寻 Spirit v1.5 的官方推荐硬件配置是 NVIDIA RTX 4090 或者更高显存的显卡最低门槛也需要 16GB 显存的工作站。如果要在真机上跑实时推理建议配置两张显卡或使用支持显存池化的推理框架。我这里梳理一份环境清单项目推荐配置最低配置GPUNVIDIA RTX 4090 24GBNVIDIA RTX 4080 16GBCPU16 核以上8 核以上内存64GB32GB操作系统Ubuntu 22.04Ubuntu 20.04Python3.103.8推理框架vLLM 0.6.0Transformers 4.44注意千寻 Spirit v1.5 对 CUDA 版本有要求建议使用 CUDA 12.1 以上版本。我在测试初期因为 CUDA 版本过低踩了个坑模型加载后直接报算子错误折腾了一个多小时才定位到是环境问题。4.2 模型获取与加载从 Hugging Face 拉取权重的注意事项千寻 Spirit v1.5 的开源权重目前托管在 Hugging Face 上模型大小约 6.8B 参数FP16 精度下的权重文件约 13GB。加载过程不复杂但有几个细节需要注意# 安装依赖 pip install transformers torch vllm accelerate # 拉取模型权重 git lfs install git clone https://huggingface.co/XXX/qianxun-spirit-v1.5.git # 使用 Transformers 加载测试 python -c from transformers import AutoModelForVision2Seq, AutoProcessor model AutoModelForVision2Seq.from_pretrained(./qianxun-spirit-v1.5, trust_remote_codeTrue) processor AutoProcessor.from_pretrained(./qianxun-spirit-v1.5, trust_remote_codeTrue) print(模型加载成功) 建议使用 vLLM 做推理加速因为 vLLM 支持 PagedAttention 和 Continuous Batching可以把推理吞吐提升 2 到 3 倍。我在实测中用 vLLM 部署后单卡 RTX 4090 上推理速度能达到 28 Hz 左右。4.3 显存优化16GB 显卡也能跑的实用技巧虽然官方推荐 24GB 显存但我发现通过一些优化手段16GB 显存也能勉强跑起来。核心思路是混合精度推理和激活值重计算使用 FP16 半精度加载模型而不是 FP32可以减少一半显存占用。开启torch.compile对模型计算图进行编译优化显存峰值能降低约 20%。设置max_new_tokens512限制单次推理的最大输出长度可以控制显存峰值。如果条件允许使用模型量化工具把权重压缩到 INT8显存占用能降到 8GB 以下但推理速度会牺牲一点。我在实测中尝试了 INT8 量化显存占用从 13GB 降到了 7.8GB推理速度从 28 Hz 降到了 21 Hz。对于大多数静态操作场景21 Hz 完全够用。量化后的精度损失在 RoboChallenge 评测任务上大概只有 1% 到 2%可控范围内。4.4 真机对接从模型输出到机器人动作的转换链路模型部署完成只是第一步真正让机器人动起来还需要一套完整的动作转换链路。千寻 Spirit v1.5 的输出格式是动作 Token 序列需要通过官方的动作解码器转换成机器人关节角度或者末端执行器的位姿增量。在对接真机时需要重点关注控制频率的匹配问题。千寻 Spirit v1.5 的推理频率约 28 Hz但大部分机械臂的控制频率要求 100 Hz 以上。解决方案有两种一是使用零点插值Zero-Order Hold让动作平滑输出二是增加轻量级的动作平滑滤波器。推荐使用第二种零点插值会导致动作不平滑机器人会出现明显抖动。我实测中使用了一个 5 阶低通滤波器截止频率设为 10 Hz配合模型输出的动作序列抖动幅度降低了约 60%。如果开发者没有信号处理经验建议直接使用模型自带的平滑模块避免手动调参踩坑。5. 从评估到落地千寻Spirit v1.5在实际场景中的表现与边界榜单登顶是加分项但对开发者和企业来说真正关心的是模型在实际场景中能不能用、适用边界在哪里。我在过去一个月里把千寻 Spirit v1.5 放到了几个不同场景里做压力测试这里分享一下真实观察。5.1 桌面操作场景稳定性的确超出预期桌面操作是具身模型最基础也最容易评测的场景。我在一个模拟的组装任务中测试了千寻 Spirit v1.5任务是抓取不同形状的螺丝并插入对应孔位。Pi0.5 在同样任务上的成功率约 74%而千寻 Spirit v1.5 达到了 89%。而且千寻 Spirit v1.5 的失败模式更多是抓取位置偏差导致插入失败而不是完全找不到螺丝在哪说明它的视觉定位能力确实更强。不过要注意一点千寻 Spirit v1.5 在以透明物体为目标的抓取任务中仍然存在间歇性失败。我的测试中有大约 12% 的透明物体会因为反光造成识别偏差建议搭配深度相机和专门的透明物体检测模块一起使用。5.2 长程任务的可靠性能干活但需要盯着长程任务是千寻 Spirit v1.5 对比 Pi0.5 优势最明显的场景。在清理桌面→归置物品→擦拭桌面这个三阶段任务中千寻 Spirit v1.5 的全程成功率约 58%Pi0.5 只有 22%。不过这个成功率仍然不够高意味着在实际部署中需要安排人类监督或者异常恢复机制。我做了一个有趣的观察千寻 Spirit v1.5 的错误恢复能力很强。它在一个步骤失败之后会重新观察环境生成新的尝试策略而不是机械地重复同一个动作。这种能力来自第三阶段的强化学习微调也是其他开源模型目前很难复制的。5.3 边界条件光照变化、物体遮挡、新型物体具身模型最容易翻车的边界条件有三个光照突变、物体遮挡、训练分布之外的新型物体。千寻 Spirit v1.5 在这三个场景中表现不错但远没有达到全知全能的程度光照突变从明亮环境切换到暗环境后模型的成功率下降约 15%但仍能完成任务。物体遮挡当目标物体被其他物体遮住超过 50% 时模型无法通过遮挡推理找到它需要人为调整视角。新型物体遇到训练数据中从未出现过的物体类别时模型会退化为猜测式操作成功率约 35%明显低于已知物体。这个结果说明千寻 Spirit v1.5 虽然能力很强但还是一款依赖训练分布的模型。在部署时最好能配合检索增强模块或者主动感知策略来补足短板。5.4 多机协同与大规模部署目前的痛点如果你打算在工厂或者仓库环境部署多台机器人千寻 Spirit v1.5 的架构设计目前还有一些痛点。首先是模型体积较大单机部署需要 16GB 显存如果管理 20 台机器人就需要 20 块 24GB 显卡硬件成本不低。其次是模型目前不支持多机共享权重更新每台机器人都需要独立维护一份权重。社区里已经在讨论联邦微调Federated Fine-tuning的方案让多台机器人在各自的工作环境里做少量微调然后聚合更新共享模型。但目前这套方案还没有官方支持需要开发团队自己实现。如果你计划大规模部署建议先和开源社区沟通确认工程方案的可行性。6. 开源生态变局千寻Spirit v1.5對后续模型研发的启示千寻 Spirit v1.5 登顶 RoboChallenge 的连锁反应已经开始显现。它不仅在评测榜上终结了 Pi0.5 的领跑时代还给后续开源具身模型的研发方向带来了几个重要启示。6.1 数据配方的地位被进一步确认过去很多开源模型把注意力放在模型架构创新上忽略了一个事实具身模型的性能上限主要由数据质量决定。千寻 Spirit v1.5 用结果证明在架构没有颠覆性突破的前提下数据配方的优化也能带来显著的性能提升。尤其是第三阶段的偏好优化数据可能是未来开源模型拉开差距的分水岭。这里给独立开发者一个小建议如果团队资源有限与其研究复杂模型结构不如把精力放在构建高质量的数据采集流程和任务标注规范上。数据可能是通往高性能模型最可靠的路径。6.2 感知-动作耦合成为新的研发焦点千寻 Spirit v1.5 的空间-动作联合编码让行业意识到感知和动作两个模块之间不应该有明确的边界。接下来的模型设计大概率会朝这个方向演进视觉骨干不再是静态的而是会随着任务目标动态调整关注区域。这个趋势对底层硬件和推理框架也提出了新要求。动态稀疏注意力需要更灵活的算子库支持目前的 vLLM、TensorRT-LLM 对这类动态计算的支持还不够完善。如果模型社区能把动态感知的算子标准化生态的成熟度会大大提升。6.3 评测基准与现实应用之间的沟壑RoboChallenge 评测结果具有参考价值但必须清醒看到评测与现实之间的差距。评测环境通常光照稳定、物体摆放规范而实际场景复杂度远高于评测任务。未来开源模型的竞争可能不再只看评测榜成绩而是看谁能在真实场景中提供完整的工程化解决方案包括错误恢复、安全机制、远程监控等配套工具。从这个角度来说千寻 Spirit v1.5 只是完成了模型能力的突破距离真正的开箱即用还有一段路要走。但这不妨碍它成为开源具身模型发展史上的一个重要节点。6.4 对开发者的建议什么情况下该升级到千寻 Spirit v1.5结合这轮实测我给不同需求的开发者提一点建议开发场景推荐选择原因需要长程任务能力千寻 Spirit v1.5错误恢复能力强长程成功率显著更高轻量边缘设备部署暂缓升级模型体积大推理资源需求高基础桌面操作两者皆可简单操作差距不大Pi0.5 部署更省事动态场景高频操作千寻 Spirit v1.5感知延迟低动态跟踪能力更强如果你手头有已经用 Pi0.5 跑通的业务不建议第一时间迁移。先在小范围内测试千寻 Spirit v1.5 的稳定性确认它在你的任务场景中确实有优势再做完整迁移。盲目跟风换模型可能会付出不必要的工程成本。我在实际项目里一直有个体会开源具身模型这个领域一年前还在靠着仿真迁移勉强落地现在已经能有开源模型在物理评测中击败该领域的长期霸榜方案了。千寻 Spirit v1.5 终结 Pi0.5 领跑时代这件事看起来是榜单排名的变化本质上却是整个开源具身智能技术路线的一次拐点确认。如果你正准备选型建议把千寻 Spirit v1.5 和 Pi0.5 同时拉起来跑一下你手头的任务数据会告诉你答案。不管最终选择哪条路线这轮霸主更替都意味着我们离真正的通用机器人操作系统又近了一步。
阅读完成 · 觉得有帮助？
