26 SDK 与参考应用洞察
- 章节编号:26
- 所属层:A 应用与领域层(承接 22/25/20/21;面向客户 POC)
- 关联 ADR:ADR-103(SDK 分层与 CLI 体系)、ADR-104(Model Zoo 与 manifest 模板)、ADR-105(参考应用:叠衣/抓取 POC)、ADR-106(DX 对标:Isaac/QIRP/LeRobot)
- 上游依赖:20(manifest)、22(bundle)、25(ROS2)、27(benchmark)
学习目标
- 前置知识:读过 20 章(模型 manifest schema)、22 章(bundle 打包/签名)、25 章(ROS2 集成)与 27 章(benchmark 验收集)概览;知道「具身模型三大部署形态(单体 VLA / VLM+动作专家 / 双系统)」出自 21 章;对「AOT 编译产物(vmfb)」「OTA/Fleet」有基本概念。无需读过全部软件栈——本章从「怎么把 15–25 章能力打包成开发者能一条命令用起来的产品」这个交付视角切入,而非底层实现。
- 学完产出:① 能说清 dsa-sdk 的三层结构——C 运行时(
libdsa_runtime)/ Python 绑定 / ROS2 一等公民——各层面向哪类用户(OEM / 算法团队 / 工厂 IT),以及分层如何把接入门槛从「懂 MLIR 全栈」降到「会写一份 manifest」;② 能把dsa deploy --manifest pi0.yaml这条命令背后的 compile → pack → deploy 三件套流水在时间轴上拆开算一遍,论证为什么 <30min 首包是可达的工程目标而非营销数字;③ 能说清 Model Zoo 的 manifest 与 27 章验收集的绑定关系——为什么「Zoo 里每个模型都挂一条验收 SLO」是 Model Zoo 区别于「一堆权重文件」的本质;④ 能对照 §3.1 横评表,说清 Isaac / QIRP / LeRobot / CANN 四家 DX 各自的强项与我们 dsa-sdk 的差异化定位(MLIR 全栈 + LeRobot 对齐);⑤ 能读懂本章 ADR 候选(ADR-103~106),把「SDK 产品化」翻译成「CLI 契约 + manifest schema + 参考应用仓库结构」的可执行输入。 - 阅读姿势:盯住一条主线——「SDK 的全部价值,在于把『我们内部工程师才懂的编译/部署链』收敛成客户三条命令、一份 manifest 就能跑通的开发者体验(DX)」。读横评表时不要只看「谁功能多」,要问「客户从拿到板子到看见机器人动,中间要跨过几道坎」——门槛每少一道,Design Win 的概率就高一档。所有 CLI、Model Zoo、参考应用的设计,本质都在回答同一个问题:如何让一个不懂我们 DSA 内部的算法工程师,在一天内跑出第一个 demo。
1. 范围与目标
定义 开发者 SDK、CLI、Model Zoo、参考应用、客户 POC 路径。把 15–25 章能力 产品化。
核心问题
- SDK 分层如何(C API / Python / ROS2)?
- 对标 JetPack+Isaac、QIRP、LeRobot、CANN 的 DX?
- 一条命令从 manifest 到 robot 跑起来?
- Model Zoo 放什么(π0/OpenVLA/GR00T-class)?
本章在文档体系中的位置:15–20 章造「编译器 + 运行时 + manifest」这台发动机,21 章定「跑什么模型」,22/25 章解决「打包与机器人集成」,27 章定「怎么验收」。本章(26)是把这一整条链封装成开发者产品的最后一跳——如果说前面各章是「零件」,本章就是「说明书 + 一键装配线」。一个再强的编译栈,若客户要读 10 篇内部 wiki 才能跑起来,商业上等于不存在。
2. 需求洞察
| 用户 | 诉求 |
|---|---|
| 机器人 OEM | C++ ROS2 + Yocto 集成 |
| 算法团队 | Python + LeRobot 对齐 |
| 工厂 IT | OTA + Fleet CLI |
| 我们 AE | POC ≤2 周 |
硬性指标: dsa deploy --manifest pi0.yaml ≤30min 首包;SDK 文档 Quick Start ≤1 天。
2.1 四类用户的「接入路径」画像
四类用户的技术栈、耐心阈值、成功判据完全不同,SDK 分层的根本理由就是用一套底层能力,为每类用户暴露一个「刚好够用、不多不少」的入口:
| 用户 | 技术栈锚点 | 最短成功路径 | 「多一道坎就流失」的痛点 |
|---|---|---|---|
| 机器人 OEM | C++ / Yocto / ROS2 | Yocto layer 拉 meta-dsa → 板级 bring-up → dsa_ros_inference 节点 | 若只给 Python,OEM 无法进 Yocto 镜像,直接出局 |
| 算法团队 | Python / HuggingFace / LeRobot | pip install → 复用 LeRobot manifest → 本地跑 rollout | 若强制学新 manifest 格式,算法团队宁可留在 LeRobot |
| 工厂 IT | 无 ML 背景,只有运维 | Fleet CLI 一条命令灰度下发,dashboard 看状态 | 任何需要「懂模型」的步骤都是坎;要「零 touch」 |
| 我们 AE | 全栈但时间紧 | 一份 manifest 打通 compile→pack→deploy,≤2 周出 POC | 每多一个手工步骤,POC 周期就拖一周 |
这张表就是 SDK 分层的需求根据:C 运行时喂 OEM 的 Yocto/ROS2,Python 绑定喂算法团队的 LeRobot 生态,Fleet CLI 喂工厂 IT 的零 touch 运维——同一份 libdsa_runtime,三层不同抽象,各取所需。
3. 技术现状与趋势(2025–2026)
3.1 TOP 级机器人 AI SDK 深度对比
| 栈 | SDK 形态 | 编译/deploy | Model Zoo | 参考应用 | 优势 | 劣势 |
|---|---|---|---|---|---|---|
| NVIDIA JetPack+Isaac | apt/docker;Isaac ROS/GR00T | TensorRT/ModelOpt | NGC GR00T/Cosmos | Manipulator demo | 最全 | 闭源;CUDA 锁 |
| Qualcomm QIRP | Yocto layer;qrb_ros_nn_inference | QNN/AI Hub | QNN model zoo | IQ10 demos | 车规 | VLA 新 |
| LeRobot | pip install lerobot | 无 AOT | HF Hub π0/OpenVLA | teleop/sim | 最低门槛 | 非量产 RT |
| 华为 CANN | CANN toolkit | ATC → .om | ModelZoo | 310P π0 demo | 国产 | 非 ROS 原生 |
| ExecuTorch | pip;.pte | export CLI | 示例 | 手机/IoT | PyTorch 1.0 GA | 机器人弱 |
| IREE(上游) | iree-compile | vmfb | 通用 ML | 少机器人 | 开放 | 无具身 DX |
| 我们 dsa-sdk | dsa-compile/pack/deploy | bundle | manifest Model Zoo | 叠衣/抓取 | MLIR 全栈+LeRobot 对齐 | 从零 |
横评的一句话结论:Isaac 「最全但绑 CUDA」、LeRobot 「最易上手但不量产」、QIRP/CANN 「能量产但 ROS/具身 DX 弱」——没有一家同时做到『开放 + 量产 RT + LeRobot 级易用 + ROS2 一等』,这正是 dsa-sdk 的差异化窗口。代价是「从零」:生态、文档、参考应用都要自建。Isaac ROS / Isaac Sim 的具体版本号与组件命名以官方 release 为准。
3.1a DX 深度对比
NVIDIA Isaac(标杆)
| 优势 | 劣势 | 我们借鉴 |
|---|---|---|
| JetPack 一键 BSP;Isaac 教程+GEM | 绑 Thor;license | Yocto layer + 参考 launch |
| NGC 模型一键拉取 | NGC 账号/闭源 | CDN + signed bundle |
| Isaac Sim sim2real 链 | 重 | 规模化阶段 31 章 回流 |
LeRobot(生态入口)
| 优势 | 劣势 | 我们借鉴 |
|---|---|---|
| HF 数据集+训练+推理统一 | 无量产 OTA/安全 | manifest schema 兼容 |
| π0/OpenVLA 社区最大 | Python only | 开发态 LeRobot;部署态 dsa-sdk |
Qualcomm QIRP
| 优势 | 劣势 | 我们借鉴 |
|---|---|---|
| meta-qcom-robotics Yocto | QNN 封闭 | meta-dsa recipe 结构 |
| 车规文档 | VLA tutorial 少 | ROS2 lifecycle node 模板 |
3.2 SDK 分层(候选)
3.2a 分层如何把接入门槛「层层降维」
SDK 分层不是「把代码分几个包」,而是把「懂 DSA 内部」这件难事,沿用户技能梯度切成台阶,让每类用户只需跨过自己那一级。下图把「从裸编译器到机器人跑起来」的门槛拆成四级台阶:
逐级读这张图:
| 层级 | 暴露给用户的抽象 | 用户需要懂什么 | 屏蔽掉了什么 |
|---|---|---|---|
| C 运行时 | dsa_load(bundle) + dsa_forward(io) | C ABI、内存生命周期 | 编译器内部、DSA Dialect、tiling 策略 |
| Python 绑定 | model.infer(obs);LeRobot manifest 兼容 | pip、numpy、LeRobot 用法 | C ABI、bundle 结构、量化细节 |
| CLI 三件套 | dsa compile/pack/deploy --manifest x.yaml | 一份 YAML manifest 字段 | 全部编译/打包/下发的中间产物 |
| Fleet CLI | dsa fleet rollout --group A | 灰度策略、设备分组 | 单机部署、模型、bundle 一切细节 |
这就是「降低接入门槛」的机制:每上一层,用户需要掌握的知识就少一截,而下层能力一点不丢——OEM 仍可下钻到 C 层做深度集成,算法团队停在 Python 层,工厂 IT 只碰 CLI。门槛从「懂 MLIR 全栈(内部工程师级)」一路降到「会写一份 manifest(运维级)」,这正是 SDK 把内部能力产品化的核心价值。
3.1b DX 评分矩阵(1–5)
| 维度 | Isaac | QIRP | LeRobot | CANN | dsa-sdk(目标) |
|---|---|---|---|---|---|
| Quick Start | 3 | 3 | 5 | 3 | 4 |
| 量产 deploy | 5 | 4 | 1 | 4 | 4 |
| ROS2 一等 | 5 | 4 | 2 | 2 | 4 |
| 开放/audit | 2 | 3 | 5 | 3 | 5 |
| OTA/Fleet | 4 | 4 | 1 | 3 | 4 |
3.3 CLI 三件套:一条命令从 manifest 到 robot
dsa deploy 表面是「一条命令」,内部是 compile → pack → deploy 三段流水的编排。理解这三段各干什么、各耗多久,才能论证「≤30min 首包」不是拍脑袋:
三段的职责边界:
- compile:吃 manifest,走 15/20 章的 MLIR 导入 + IREE AOT,吐出
vmfb。这是最耗时的一段——尤其含流匹配flow-steploop、KV-cache 的 VLA。 - pack:把
vmfb+ 权重 + manifest 元数据封成一个可分发、可签名的 bundle(22/28 章),打上版本戳。 - deploy:bundle 下发到目标板,校验签名后加载,拉起
dsa_ros_inferenceROS2 节点,机器人开始执行。
为什么是「三件套」而非「一个大命令」:三段解耦后,compile 可在 CI 里预跑并缓存 bundle,现场 POC 只需 pack(若权重变)+ deploy;OEM 也能只取 compile 产物自己集成。一条 dsa deploy 是三件套的糖,但三件套本身是可拆的契约——这正是 §6 「CLI 三件套」ADR-103 的设计动机。
3.4 POC 路径(ADR-105,≤2 周)
| 天 | 活动 | 产出 |
|---|---|---|
| D1–2 | LeRobot manifest → dsa-compile | vmfb |
| D3–4 | dsa-pack + Thor 类板 bring-up | bundle |
| D5–7 | dsa_ros_inference + 叠衣/抓取 | demo video |
| D8–10 | 27 bench + OTA 试跑 | POC 报告 |
3.5 Model Zoo(ADR-104)
| 模型 | manifest | 验收(27) |
|---|---|---|
| π0.7-class | zoo/pi0.7.yaml | chunk ≤100ms |
| OpenVLA 7B INT4 | zoo/openvla-int4.yaml | ≥3Hz |
| Diffusion Policy | zoo/dp.yaml | 10Hz |
| GR00T-class DiT-only | zoo/groot-dit.yaml | DiT ≤50ms |
3.5a Model Zoo 与 27 章验收集的绑定关系
Model Zoo 不是「一堆权重文件」,而是「一组带验收契约的可复现部署配方」。上表最右列「验收(27)」是关键:Zoo 里每个 manifest 都挂一条 27 章的验收 SLO,这让 Model Zoo 从「模型仓库」升级为「质量基线」。下图说明这个绑定如何形成闭环:
这个绑定为什么重要:
- 对客户:从 Zoo 拉一个
pi0.7.yaml,拿到的不只是「能加载的模型」,而是「已在 27 章验收过、承诺 chunk <100ms 的部署配方」——客户信任的是 SLO,不是权重本身。 - 对我们:Zoo 与 27 章绑定后,任何模型入库前必须过验收,防止「Zoo 里躺着一堆没人验证过的破配置」。这对应 21 章 M5 里程碑「Model Zoo 架构:OpenVLA/π0 配置 YAML(非完整权重)」——Zoo 的资产是 manifest + 验收契约,权重可选镜像(ADR-104 「HF 可选镜像」)。
- 版本语义:Zoo 用 semver;某个模型 manifest 改了量化策略 → 重新过 27 bench → SLO 达标才升版本。验收是入库的门禁,不是入库后的抽查。
3.6 参考应用(ADR-105)
| 应用 | 任务 | 栈 |
|---|---|---|
| dsa-demo-fold | 叠衣 | 3 cam + π0 + ros2_control |
| dsa-demo-pick | 桌面抓取 | 1 cam + OpenVLA/DiT |
参考应用的定位:它是「Model Zoo(有什么模型)」和「POC 路径(怎么部署)」之间的活样板——客户不需要从空白开始,叠衣/抓取两个 demo 直接给出「相机接入 → manifest → ROS2 node → ros2_control 执行」的完整可跑骨架。参考应用仓库放在 Demo 仓库
10-apps/(ADR-105),AE 做 POC 时以此为模板改配置,而非从零搭。
3.7 客户 Persona 与 Design Win(ADR-129,v4)
| Persona | 入口 | POC 路径 | 成功标准 | AE 周期 |
|---|---|---|---|---|
| 人形 OEM(宇树/智元类) | LeRobot + Yocto | π0 manifest → bundle → ros2 | chunk ≤100ms;OTA 1 次 | ≤2 周 |
| 工业 AMR | C++ SDK | OpenVLA Lite + Fleet | ≥3Hz;15–25W | ≤3 周 |
| 算法公司(PI 生态) | Python pip | 同 manifest 多端 | rollout 不降 | ≤1 周 |
| 工厂 IT | Fleet CLI only | 23 灰度 + 29 dashboard | 零 touch deploy | 试点 3 月 |
Design Win Checklist(32 ADR-129):
- manifest compile ≤30min
- 27 bench 报告(ms+Hz+W)
- 28 签名 bundle
- 可选:岛 SIL 规划(Pro SKU)
4. 关键权衡、风险与依赖
4.1 跨层耦合
- manifest schema 是本章与 20/21/27 章的公共契约:字段(
model_family/quant/action_dim/验收 SLO)一旦对外发布,改动即破坏兼容 → 须版本化并向后兼容。 - LeRobot 对齐是双刃剑:对齐 LeRobot manifest 降低算法团队门槛,但 LeRobot 快速迭代(21 章 §3.8)→ importer 须版本 pinning,否则上游一改 schema,我们的兼容层就断。
- CLI 三件套依赖 22 章 bundle 格式与 28 章签名:
dsa-pack的产物结构、签名方案不能与 22/28 章漂移。
4.2 单点风险
| 风险 | 说明 | 缓解 |
|---|---|---|
| 从零建生态 | Isaac/LeRobot 有多年社区沉淀,我们 Model Zoo/参考应用/文档全新 | 优先对齐 LeRobot manifest 复用其模型生态;参考应用只做叠衣/抓取两个精品 |
| Quick Start ≤1 天不达标 | DX 靠文档 + 样板,任何一步卡住都拖垮首日体验 | 参考应用做成「clone 即跑」;CLI 报错须可读、可自愈 |
| compile ≤30min 超时 | 含流匹配 loop + KV-cache 的 VLA 编译重 | CI 预编译 + bundle 缓存;现场只 pack+deploy(见 §3.3) |
| 多端 rollout 不一致 | 同 manifest 多端,量化/shape 差异致 rollout 降 | 27 章多端 bench 作门禁;padding 子集统一 shape(21 章 §5.1) |
6. 结论与 ADR
- CLI 三件套:compile → pack → deploy。
- 双入口:LeRobot(研发) + dsa-sdk(量产)。
- Model Zoo manifest 驱动,与 27 benchmark 绑定。
- ADR-103 SDK 分层:C
libdsa_runtime+ Python + ROS2;CLI 统一。 - ADR-104 Model Zoo:manifest 模板;HF 可选镜像;semver。
- ADR-105 参考应用:叠衣+抓取;Demo 仓库
10-apps/。 - ADR-106 DX 对标:Quick Start 对齐 LeRobot 简洁 + Isaac 完整 deploy 链。
roadmap 提示(以官方为准):2026 年 SDK 生态的两条外部主线——LeRobot 作为国内 π0 部署事实入口持续快速迭代,π0.7 / GR00T N1.7 均已 GA——意味着 Model Zoo 的对标目标是移动靶。dsa-sdk 的兼容字段须预留 π0/OpenVLA/GR00T/Gemini 扩展位,避免上游版本跳变时 manifest schema 破裂。具体版本节奏与组件命名以各厂商官方 release 为准。
深入思考
下面三题每题先给题干,再用
<details>折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。
思考题 1:SDK 分层如何降低接入门槛
同样一套底层 DSA 编译/运行时能力,为什么要拆成 C 运行时 / Python 绑定 / CLI 三件套 / Fleet CLI 四层,而不是给客户一个统一大 API?结合 §3.2a 的分层台阶图与 §2.1 四类用户画像,论证「分层」如何把接入门槛从「懂 MLIR 全栈」降到「会写一份 manifest」,并说明如果只提供单一 Python 入口会漏掉哪类关键客户。
展开参考答案（含分层降门槛因果链图 + 算一遍）
结论:四类用户的技能栈与耐心阈值天差地别——OEM 只进 C/Yocto、算法团队只碰 Python、工厂 IT 只会点 CLI;分层的本质是「同一份底层能力,为每类用户暴露一个刚好够用的抽象」,让每类人只需跨过自己那一级台阶,而不必懂下面所有层。单一入口必然对某类用户「过高或过低」——只给 Python 就把无法进 Yocto 镜像的机器人 OEM 直接挡在门外。
用「所需知识量」算一遍(定性量化,说明门槛如何逐层塌缩):
- 裸底层:客户要跑通一个模型,需掌握 ≈ MLIR 方言 + DSA Dialect + HAL + tiling + bundle 格式 + 签名 ≈ 6 类深度知识——只有我们内部编译工程师具备,客户几乎 0 人可用。
- C 运行时层:屏蔽掉编译器全部内部,OEM 只需 C ABI + CMake 集成 ≈ 2 类知识,且都是 OEM 本就具备的。可用客户群从「0」扩到「所有机器人 OEM」。
- Python 绑定层:再屏蔽 C ABI 与 bundle,算法团队只需 pip + numpy + LeRobot 用法 ≈ 1.5 类知识,且对齐他们熟悉的 LeRobot,几乎零学习成本。
- CLI + manifest 层:屏蔽一切中间产物,AE/工厂 IT 只需 会填一份 YAML manifest ≈ 0.5 类知识——这是「会写一份 manifest」就能部署的终点。
若只给单一 Python 入口会漏掉谁:机器人 OEM 要把推理进程编进 Yocto 镜像 + ROS2 lifecycle node,C ABI 是硬约束——Python 运行时进不了他们的量产系统(§2.1 「若只给 Python,OEM 无法进 Yocto 镜像,直接出局」)。同样,工厂 IT 也不会为了下发一个模型去学 Python。分层不是过度设计,而是「一份能力覆盖四类不可合并的用户」的必要条 件。
回链:详见 §3.2a 分层台阶图与逐级抽象表、§2.1 四类用户接入路径画像,以及 §6 ADR-103「C
libdsa_runtime+ Python + ROS2;CLI 统一」。
思考题 2:Model Zoo 与 27 章验收集的关系
为什么说 Model Zoo 的本质资产是「manifest + 验收契约」而非「一堆权重文件」?结合 §3.5a 的绑定闭环图与 21 章 M5 里程碑「Model Zoo 放配置 YAML(非完整权重)」,分析「每条 manifest 挂一条 27 章 SLO」这个设计如何把 Model Zoo 从「模型仓库」升级为「质量基线」,以及如果 Zoo 与验收解耦会发生什么。
展开参考答案（含 Zoo-验收门禁对比图 + 对比表）
结论:客户从 Zoo 拉一个模型,真正信任的不是权重本身,而是「这份配方已在 27 章验收过、承诺 chunk <100ms」这条 SLO;所以 Model Zoo 的资产是『manifest(可复现部署配方)+ 验收契约(质量承诺)』,权重只是可选镜像。把验收设成入库门禁,Zoo 就从『能加载的模型集合』升级为『每个都过质量线的基线库』;一旦解耦,Zoo 会退化成『一堆没人验证过、部署了才发现跑不动的破配置』。
两种模式对比:
| 维度 | Zoo 与验收绑定(门禁) | Zoo 与验收解耦(仓库) |
|---|---|---|
| Zoo 的资产 | manifest + 验收契约(SLO) | 一堆权重/配 置文件 |
| 客户信任来源 | 「已过 27 bench,承诺 chunk <100ms」 | 「据说能跑」,须自己验 |
| 入库把关 | SLO 达标才入库,semver 打绿标 | 无门禁,随手上传 |
| 踩坑时机 | 入库前 CI 拦截 | 客户现场部署才暴露 |
| 对应设计 | ADR-104 + 21 章 M5「配置 YAML」 | 反面教材 |
「挂一条 SLO」如何升级 Zoo 的性质:上表 §3.5 每个模型都挂了验收列——pi0.7-class → chunk ≤100ms、OpenVLA INT4 → ≥3Hz、GR00T-class DiT-only → DiT ≤50ms。这条 SLO 是 Zoo manifest 与 27 章 benchmark 的引用绑定:CI 里 Zoo 任何模型新增/改量化策略,都自动跑 27 bench,未过 SLO 就拒绝入库。于是 Zoo 里躺着的每一份 manifest 都是「过了质量线的配方」——这正是 21 章 M5「Model Zoo 架构:配置 YAML(非完整权重)」的深层含义:Zoo 卖的是经过验收的『部署确定性』,不是权重。
解耦的后果:若 Zoo 只当权重仓库、验收另做,客户拉一个 openvla-int4.yaml 部署下去,可能量化 kernel 精度没验过、频率跑不到 3Hz——问题在客户现场才暴露,信任一次性崩塌。绑定后,验收是「入库门禁」而非「入库后抽查」,把风险拦在 CI 里。
回链:详见 §3.5a Zoo-验收闭环图与「验收是入库门禁」表、§3.5 Model Zoo 验收列,以及 21 章 M5 里程碑与本章 ADR-104「manifest 模板;semver」。
思考题 3:LeRobot manifest→bundle 流水线为何 ≤30min
dsa deploy --manifest pi0.yaml 的硬指标是 首包 ≤30min。结合 §3.3 的 compile→pack→deploy 三段流水图与 §4.2「compile 可 CI 预编译 + bundle 缓存」,把这条流水在时间轴上拆开算一遍,论证 ≤30min 为什么可达;并说明「三件套可拆」的设计如何让现场 POC 把耗时从「全量 30min」压到「几分钟」。
展开参考答案（含三段流水时间预算图 + 算一遍）
结论:≤30min 的大头在 compile(含流匹配 loop + KV-cache 的 VLA 编译最重),pack/deploy 都是分钟级;把三件套拆开后,compile 可在 CI 里预跑并缓存 bundle,现场 POC 只需 pack(若权重变)+ deploy,耗时从「全量 30min」压到「几分钟」——所以 ≤30min 是『首次全量』的上界,稳态迭代远快于此。
用时间预算算一遍(数量级估算,以实测为准):
- compile(大头):LeRobot manifest → MLIR 导入 → IREE AOT 编译。π0 类含 流匹配
flow-steploop + 前缀 KV-cache,是编译最重的部分,估 15–25min。这是 ≤30min 预算的主要消耗者。 - pack:把
vmfb+ 权重 + manifest 元数据封成 signed bundle,加 28 章签名 + 版本戳,基本是 IO + 签名开销,估 1–3min。 - deploy:bundle 下发到 Thor 类板,校验签名、加载、拉起
dsa_ros_inference节点,估 1–3min。 - 合计首次全量:≈ 25min + 3min + 3min ≈ <30min,预算成立——但几乎全部时间压在 compile 一段。
「三件套可拆」如何把现场耗时压到几分钟:关键在 §3.3/§4.2 的洞察——compile 是纯函数(manifest 不变则产物不变),可在 CI 里预跑并缓存 bundle。于是现场 POC 的真实路径是:
- manifest 未变:直接取缓存 bundle → 只
deploy≈ 1–3min。 - 仅权重变:重
pack+deploy≈ 2–6min,跳过最重的 compile。 - 模型结构变:才需全量 compile,回到 ≤30min。
这就是三件套拆分的价值:≤30min 是「首次全量」的天花板,而日常迭代因缓存命中,压到分钟级——对应 §4.2 缓解「compile ≤30min 超时」的策略。若做成不可拆的一个大命令,每次都全量编译,POC 每改一次权重就等半小时,DX 直接崩溃。
回链:详见 §3.3 compile→pack→deploy 三段流水图与职责边界、§4.2「CI 预编译 + bundle 缓存」缓解项,以及 §2 硬性指标「≤30min 首包」与 §6 ADR-103「三件套可拆的契约」。
附:信息来源
- NVIDIA Isaac/JetPack;Qualcomm QIRP;LeRobot;IREE docs。[公开,版本以官方为准]
- π0.7 / GR00T N1.7 GA、LeRobot 生态节奏:见 21 章来源;各厂商官方 release。[公开,以官方为准]
- CLI 三件套时间预算、Model Zoo 验收绑定:基于本项目工程设计的估算。[估计]