21 具身模型支持洞察
- 章节编号:21
- 所属层:M 模型层 + R/C 交界(模型部署形态驱动算子/运行时/编译需求)
- 关联 ADR:ADR-046(基线具身模型族与验收集)、ADR-047(VLA/扩散动作头部署模式)、ADR-048(多系统/多频率编排)、ADR-049(具身算子覆盖优先级)
- 上游依赖:01(负载/场景)、12(运行时)、13(实时)、15/16(编译器)、19(压缩)、07/08(软硬接口)
学习目标
- 前置知识:读过 01 章(负载/场景画像)与 12/13/15/19 章软件栈概览;知道 Transformer 推理的 prefill/decode 两段、KV-cache 是什么;对「量化(INT4/FP8)」「动态 shape」有基本概念。无需机器人学或控制理论背景——本章从「模型部署形态」而非「运动学」切入。
- 学完产出:① 能说清具身模型三大部署形态——单体 VLA、VLM + 动作专家、双系统流水线——各自的内存/延迟画像与对芯片的不同诉求;② 能把 π0 类「VLM prefill + 流匹配去噪 chunk」这套流水在时间轴上拆开算一遍延迟,理解为什么「看 chunk 延迟」而非「看单 token」;③ 能解释 cross-embodiment (跨本体)为什么给编译器带来动态 shape 压力,以及「固定 max dim + padding」这套 shape polymorphism 子集的取舍;④ 能对照 §3.4 横评表,说清 Thor+GR00T、π0+RTC、Helix 三系统各自代表的技术路线,并判断自研 DSA 的差异化窗口在哪;⑤ 能读懂本章的 ADR 候选(ADR-046~049),把「模型选型」翻译成「算子覆盖 + runtime 能力 + 编译器 loop 原语」的可执行输入。
- 阅读姿势:盯住一条主线——「具身模型对芯片的诉求,全部由『部署形态』而非『参数量』决定」。一个 7B 单体 VLA 和一个 3B VLM+300M 动作专家,参数量接近,但前者要优化 AR decode、后者要优化「前缀 KV-cache + 多步 suffix 迭代」,落到编译器/runtime 是两套完全不同的活。读表格时不要只看模型名,要问「它是哪种部署形态、卡在哪一段延迟」。
1. 范围与目标
本章定义具身智能特有模型族(VLA/扩散策略/多模态/分层控制)在自研 DSA 芯片上的部署难点、算子/精度/实时需求与 SDK 支持路线。衔接 01 章负载画像与 12/13/15/19 章软件栈,给出"基线能力必须跑通哪些模型、怎么跑"的可执行输入。
核心问题
- 基线能力须支持哪些具体模型/变体(OpenVLA/π0/GR00T/Diffusion Policy/Helix 类)?
- VLA 与扩散/流匹配动作头的部署模式有何不同?对编译器/运行时的接口需求?
- 多系统/多频率(Helix S0/S1/S2)如何在单 SoC 上编排?
- 具身模型有哪些长尾算子/动态 shape 痛点?算子覆盖优先级?
- Demo 仓库(
ai-chip-sw-platform-demo)与量产栈的模型贯通路径?
2. 需求洞察(具身驱动)
2.1 具体场景/任务
| 场景 | 代表模型 | 部署形态 | 关键指标 |
|---|---|---|---|
| 桌面/厨房叠衣物、清桌 | π0/π0.5 | 单 VLA + 流匹配,50Hz | chunk 延迟 ≤100ms |
| 移动抓取/装箱 | OpenVLA 7B | 离散动作 token 自回归 | 3–5Hz 策略 + 1kHz 伺服 |
| 仓储 tote 搬运 | 任务级策略 + 小网 | Digit/Agility 类 | 准实时 + 高可靠 |
| 工厂零件分拣 | GR00T N1.5 / 自研 VLA | 双系统 VLM+DiT | VLM 软实时 + 动作头迭代 |
| 精细操作(点火/插网线) | π0 + RTC | 异步 chunk 执行 | +200ms 延迟仍成功 |
2.2 硬性指标(反推自 01/19 章)
- 延迟:π0 prefill 46ms + 5 步去噪 ~30ms ≈ 76ms@4090(BF16);端侧 INT4 + DSA 目标 ≤50–80ms/chunk。
- 频率:策略 1–50Hz;视觉运动 200Hz(Helix S1);伺服 1kHz(S0)——须 13 章分域调度。
- 内存:单 VLA(INT4) 1.7–3.5GB + KV + 感知缓冲 + 控制小网 → ≥8GB 主存。
- 精度:VLA rollout 成功率;非 perplexity——OpenVLA 4-bit 已证可行。
- 多本体:π0 cross-embodiment;输入 state/action 维度随机器人变化 → 编译器须支持 动态 shape 子集。
2.3 端 / 边 / 中心
- 端侧本体:1×VLA + 1×控制小网 + 1×感知前端;全本地(A100 级云推理仅作开发)。
- 边缘侧:多机器人网关跑共享 VLM;端侧只跑轻量策略。
- 中心:训练/蒸馏/大模型推理;不在 端侧基线阶段 范围。
3. 技术现状与趋势(点名 + 来源)
3.1 具身模型族与部署架构
- ViT/CNN: DINOv2, SigLIP, 深度/分割/SLAM
- 7B 级 VLM: OpenVLA, PaliGemma/Gemma backbone
- Token AR: OpenVLA (256-bin discrete)
- Flow/Diffusion: π0 (10→5 步), GR00T DiT, Diffusion Policy
- 中型 Transformer: 全传感→全关节
- ~10M 参数; 硬实时; 可 CPU/DSP 或 NPU 静态调度
3.2 代表模型部署要点(点名)
| 模型 | 结构摘要 | 部署难点 | 业界做法 |
|---|---|---|---|
| Gemini Robotics 1.5 | VLA + Embodied Reasoning(ER 1.6) 双模型;VLA 执行 + ER 规划/工具调用 | 两模型 agentic 编排;think before act | On-Device 本地;SDK 50–100 demo 微调 |
| OpenVLA 7B / OpenVLA-OFT | DINOv2+SigLIP → Llama-2 7B;256-bin 动作 token AR;OFT 用并行解码+连续动作+L1 头替代自回归 | 双视觉塔 + 7B;原版 prefill 重,OFT 大幅提吞吐 | 4-bit PTQ;LoRA;HF+bitsandbytes;QVLA 混合 bit;OFT 显著提速(以官方为准) |
| π0 / π0.5 / π0.7 | PaliGemma 3B/Gemma3 4B VLM + 300M 动作专家;流匹配 H=50;π0.7(2026-04) 为最新 | 10(→5)步迭代;KV-cache 前缀;cross-embodiment shape | BF16;RTC 异步;远程推理可选 |
| GR00T N1.7 (GA) | 双系统:VLM(System 2)+ DiT 扩散(System 1);N1.7 为 2026 GA 版(非 N1.5) | 两模型流水线;backbone PyTorch + DiT TensorRT | Isaac + Thor nvfp4/fp8;4 步去噪;Thor ~10.9Hz(以官方为准) |
| Diffusion Policy | 50–100M U-Net/Transformer;DDPM | 100 步→需 DDIM/一致性减步 | 小网可 CPU/GPU;10–20 步 |
| Helix 02 | 三层:S2 VLM(7–9Hz)+ S1 200Hz Transformer + S0 1kHz | 三模型三频率;全程 onboard | 双 RTX;自研编排 |
| ACT | ~80M CVAE+Transformer;动作 chunk | 相对轻量;易端侧 | 常作 baseline |
| Octo | 27–93M 模块化 Transformer | 小模型研究友好 | 开源社区 |
3.3 部署模式对比(具身特有)
| 模式 | 描述 | 代表 | 对芯片/软件诉求 |
|---|---|---|---|
| A. 单体 VLA | 视觉+语言+动作一体 | OpenVLA | 大模型 INT4;AR decode 优化;KV-cache |
| B. VLM + 动作专家 | 共享前缀;动作用小网迭代 | π0 | 前缀 KV-cache + 多步 suffix 重算;模块边界清晰 |
| C. 双系统流水线 | VLM 低频 → DiT/扩散高频 | GR00T | 两模型内存切换/并发;中间 tensor 传递 |
| D. 三系统分级 | S2→S1→S0 逐级 | Helix | 13 章多域调度;模型 footprint 分级 |
| E. 异步 Chunk(RTC) | 执行当前 chunk 同时生成下一 chunk | π0 RTC | 运行时 双缓冲 + inpainting;延迟鲁棒 |
| F. 双模型 Agentic(VLA+ER) | VLA 执行 + 推理/planning 模型编排 | Gemini Robotics 1.5 | 两 VM + 工具调用;云端/端侧可拆分 |
3.4 TOP 级 AI 推理芯片具身模型部署横向对比(2025–2026)
对标 07/15/19 章;从模型族、部署栈、端侧频率、量化、优劣势五维对比。
| 公司/平台 | 主力具身模型 | 部署栈(硬件→软件) | 端侧性能(公开) | 量化策略 | 优势 | 劣势 |
|---|---|---|---|---|---|---|
| NVIDIA Jetson Thor | GR00T N1.7 (GA), Cosmos VLM, 客户 VLA | Isaac Sim/Lab → ModelOpt → TensorRT Edge-LLM + DiT TRT;C++ 无 Python 推理 | GR00T E2E ~92ms(10.9Hz) TRT;117ms eager;DiT alone 49ms(以官方为准) | LLM nvfp4, ViT fp8, DiT fp8, 4 steps | 唯一公开完整 VLA+扩散 Thor 基准;Figure/Agility/Boston Dynamics 早期采用 | 闭源;绑 CUDA/TRT |
| NVIDIA Jetson Orin | GR00T, 客户策略 | TensorRT / PyTorch | GR00T 173ms(5.8Hz) TRT;300ms eager | INT4 AWQ | 出货量大 | VLA 频率不足 10Hz |
| Qualcomm Dragonwing IQ10 | 客户 VLA/VLM(平台级) | QNN + ROS2 + MLOps;IQ10 RRD 参考设计 | 700 TOPS 宣称;具体 VLA ms 未公开 | Hexagon INT8/INT4 | 功能安全子系统;Physical AI 全栈;人形伙伴多 | 大模型部署细节少于 NVIDIA |
| Google DeepMind | Gemini Robotics 1.5 + ER 1.6;On-Device | Gemini Robotics SDK;50–100 demo 微调;Agentic 双模型 | On-Device 低延迟本地;具体 ms 未公开 | 未公开 | 跨本体(ALOHA→Franka→Apollo);Boston Dynamics Atlas 2026 | 仅合作伙伴;栈不开放 |
| Physical Intelligence | π0/π0.5/π0.7(2026-04) | PyTorch + RTC;硬件中立 | π0.5 76ms/chunk@4090,5 步;RTC 97ms 但无停顿 | BF16 为主;减步+RTC | 2026 流匹配事实标准;模型中立→可跑我们芯片 | 无官方量化权重 |
| Figure AI | Helix 02 三系统 | 自研编排 + 双 NVIDIA RTX | S2 7–9Hz / S1 200Hz / S0 1kHz | 模型分级(小/中/大三层) | 全程 onboard 标杆 | 无开放 SDK |
| Stanford/OpenVLA | OpenVLA 7B | HF + bitsandbytes;LeRobot | 4-bit ~3Hz@A5000 | NF4 PTQ + LoRA | 开源生态最大 | 非实时;AR 路线渐旧 |
| 华为昇腾 310P | π0(LeRobot) | CANN + torch_npu;真机叠衣 demo | ~430ms/推理(FP16) | FP16(310P 无 BF16) | 国内首个公开 π0 端侧真机 | 延迟远未实时 |
| 宇树 Unitree | UnifoLM-VLA-0 | 待公开 | — | — | 出货量大;潜在客户 | 大脑栈 未成熟 |
| Tesla Optimus | FSD 栈(私有) | 全私有 | — | 推测 INT8/稀疏 | 垂直整合 | 零生态 |
TOP 级对标结论:
- 量产标杆 = NVIDIA Thor + GR00T N1.7:非对称 nvfp4+fp8 + DiT TRT + 4 步 ≈ 11Hz——这是我们端侧 VLA 频率/延迟的公开靶标(具体 Hz/ms 以官方 datasheet 为准)。
- 趋势模型 = π0 流匹配 + RTC:50Hz 控制语义,但算力侧看 chunk 延迟(~76–100ms) 而非单次 token;π0.7(2026-04)为最新。
- 新兴范式 = Gemini VLA+ER 双模型 Agentic:规划与执行分离 → 我们 runtime 须预留 多 VM + 跨模型 tensor 传递(12 章 ADR-037)。
- 国内机会:310P π0 430ms vs Thor GR00T 92ms——~4.7× 差距;若 INT4+减步+DSA 小 batch 做到 <100ms,对宇树/智元/千寻等是强卖点。
3.5 最新研究:快速策略与单步动作生成(2024–2026)
| 方法 | 类型 | 效果 | 部署含义 |
|---|---|---|---|
| OneDP(NVIDIA) | Diffusion→1-step 蒸馏 | 62Hz vs 1.5Hz | 动作头可编译为 单次前向;极大简化 runtime loop |
| OFP | Flow→1-NFE 自蒸馏 | 1 步超 100 步 baseline | 流匹配不必保留 5–10 步循环 |
| OpenVLA-OFT | VLA 微调:并行解码 + 连续动作 + L1 头 | 大幅提吞吐(替代 AR;倍数以官方为准) | AR VLA 可去自回归 loop;importer 须支持连续动作头 |
| Consistency Policy / HCP | 扩散一致性 | ~10× 加速 | 小网(ACT/Diffusion Policy)首选 |
| QVLA | VLA 混合 bit 量化 | 1.49× + 98.9% 任务保持 | importer 须标注 per-channel bit |
| Training-Time RTC | 训练期 delay conditioning | 108ms vs 135ms | 与芯片无关但 runtime 须 chunk 双缓冲 |
3.6 具体公司方案(汇总)
| 公司 | 模型 | 部署栈 | 来源 |
|---|---|---|---|
| NVIDIA | GR00T N1.7 (GA) + Cosmos | Isaac → ModelOpt → Edge-LLM/TRT → Thor | Isaac docs 2025–2026 |
| Qualcomm | 平台级 VLA/VLM | QNN + Dragonwing IQ10 RRD + ROS2 | CES/Computex 2026 |
| Google DeepMind | Gemini Robotics 1.5 + ER 1.6;On-Device | SDK;Atlas/Apollo/Boston Dynamics | deepmind.google 2025–2026 |
| Physical Intelligence | π0 系列 | PyTorch + RTC | pi.website;arXiv |
| Figure | Helix 02 | 自研三系统 + 双 RTX | figure.ai |
| Stanford | OpenVLA + QVLA | HF + 混合 bit 研究 | openvla;ICLR 2026 |
| 华为/千寻 | π0 叠衣 | CANN + 310P + LeRobot | devpress.gitcode.com |
| 宇树 | UnifoLM-VLA-0 | 待公开 | 2026.1 |
| Agility/Boston Dynamics | 任务级 + Jetson/Thor 生态 | NVIDIA 早期采用 | NVIDIA 新闻稿 |
3.7 多模态与世界模型部署(前瞻,端侧基线阶段 边界)
总纲 M 层要求覆盖多模态/世界模型;端侧基线阶段以 VLA+扩散/流匹配为主,本节界定边界与演进接口。
| 类型 | 代表 | 部署难点 | 端侧基线阶段 策略 |
|---|---|---|---|
| 多模态感知(ViT+深度+语言) | DINOv2/SigLIP/Cosmos | 多路相机 + 异构前处理;dmabuf 零拷贝 | P1:ViT stub + 单路 RGB;完整多模态 扩展阶段 |
| 世界模型(视频/3D 预测) | Genie、UniSim、部分 Cosmos | 3D/video attention、长序列、算力 >> VLA | P2 预研;IR 预留,不阻塞 M3 |
| VLA+ER 双模型 Agentic | Gemini Robotics 1.5 | 两 VM 编排、think-before-act 延迟 | 架构参考;端侧基线阶段 双系统(VLM+动作头)简化 |
判断:世界模型不是 端侧基线阶段 验收阻塞项,但编译器 自定义 op 扩展路径(15 ADR-028) 与 runtime multi-VM(12 ADR-037) 须在 端侧基线阶段 预留,避免 IR 无法表达 3D attn/长视频 loop。
3.7a 世界模型代表与部署难点(2025–2026)
| 模型/平台 | 类型 | 算力/内存 | 与 VLA 关系 | Round |
|---|---|---|---|---|
| Google Genie 2 | 视频/交互世界 | 云 GPU | 数据生成;非端侧闭环 | P2 研究 |
| NVIDIA Cosmos | 视频/VLM 基础 | Thor 可部分 | GR00T 训练链 | P1 观察 |
| UniSim/UniSim2 | 3D 预测 | 高 | sim 数据 | P2 |
| 星海图 世界模型 | 国内生态 | — | 开发者 | 33 国内 |
部署含义:世界模型 3D/video attention 为 P2 算子(17 章);M3 不阻塞;Edge-Pro 16GB+ 为远期最低配置。
3.8 开源/生态
- LeRobot(HuggingFace):统一数据/训练/推理;支持 π0/OpenVLA/ACT;我们的 SDK 应兼容 LeRobot 模型 manifest。
- ROS2 + MoveIt:执行层;模型输出 action → 轨迹/抓取规划接口(25 章)。
- MLIR/onnx-mlir/torch-mlir:模型导入(15/20 章);VLA 自定义 forward 须 custom op 扩展。
- IREE:多模型 VM + HAL;具身须扩展 RTC 式异步调度(12 章)。
3.9 趋势判断
- 流匹配/扩散动作头成为默认(π0/GR00T);单步蒸馏(OneDP/OFP) 正快速成熟 → 编译器须同时支持 多步 loop + 1-NFE 快路径。
- RTC/训练时 RTC 是 π0 延迟标准解法;runtime 须内置 chunk 双缓冲。
- 双模型 Agentic(VLA+ER)(Gemini/GR00T 双系统)成为 TOP 厂商共性 → 多 VM 编排是刚需。
- 模块化(VLM+专家) 优于单体 VLA —— 利于压缩(19 章)与分频率部署。
- LeRobot 是国内 π0 部署事实入口(昇腾 demo) → Model Zoo 必须对齐。
- Thor GR00T ~10.9Hz(以官方为准)是端侧公开靶标;310P π0 430ms 是国产现状 —— 差异化窗口明确。
3b. 由演进反推的芯片诉求(量化)
| 模型演进 | 算力/内存/带宽/实时 |
|---|---|
| OpenVLA 7B → π0.7 5B | 权重 +50%;流匹配步数可减 → 带宽 > 峰值算力 |
| 单体 VLA → VLM+专家 | 动作专家 300M 可驻 SRAM;片上驻留收益大 |
| 同步 chunk → RTC | 延迟容忍度提高,但 runtime 并发度 +1 |
| 单系统 → Helix 三系统 | 同时驻留 10M+300M+7B(INT4);多模型 VM(12 章 ADR-037) |
| 100 步扩散 → 5 步流匹配 | 单步算力需求 ×5 但仍需 ≤20ms/步 才够 50Hz |
基线验收算力粗算(π0 级,INT4,5 步流匹配去噪) — 对标 GR00T Thor ~92ms(以官方为准):
- ViT prefill: ~30–50 ms(目标 ≤ Thor backbone 38ms)
- 5 步动作专家去噪(单步 × 5): ~5×6ms = 30ms(GR00T DiT TRT 49ms/4 步 作参考;单步开销口径以实测为准)
- 合计目标 ~60–80ms → 逼近 Thor;显著优于 310P 430ms
4. 候选方案与对比矩阵
4.1 基线模型族选择
| 候选 | 性能/能效 | 成本 | 风险 | 生态成熟度 | 演进性 | 可驾驭度 | 小结 |
|---|---|---|---|---|---|---|---|
| A. OpenVLA 7B + Diffusion Policy + 感知 stub | 4 | 4 | 2 | 5 | 4 | 5 | ADR-004 原案;生态最好;AR 路线 |
| B. π0 类(流匹配)+ ACT + 感知 stub | 5 | 3 | 3 | 4 | 5 | 4 | 更贴近 2026 趋势;RTC 复杂 |
| C. GR00T N1.5 对齐栈 | 4 | 2 | 4 | 4 | 3 | 3 | NVIDIA 绑定过深 |
| D. 仅小模型(Octo/ACT) | 3 | 5 | 2 | 4 | 2 | 5 | 无法验证 VLA 压力 |
建议方向:B 为主、A 为兼容——π0 类覆盖流匹配+RTC(2026 趋势候选);OpenVLA 覆盖 AR VLA(生态/客户兼容候选);Diffusion Policy 作扩散 baseline;最终 M3 验收集待模型+编译联合评审(§6.2)。
4.2 部署栈路线
| 候选 | 性能/能效 | 成本 | 风险 | 生态成熟度 | 演进性 | 可驾驭度 | 小结 |
|---|---|---|---|---|---|---|---|
| E. MLIR 导入 → IREE AOT → DSA HAL + RTC 扩展 | 5 | 3 | 3 | 3 | 5 | 4 | 建议方案(主线);与 12/15 章候选一致 |
| F. ONNX Runtime + 自研 EP | 4 | 4 | 3 | 4 | 4 | 4 | 生态补位候选 |
| G. 纯 PyTorch eager(开发态) | 3 | 5 | 2 | 5 | 2 | 5 | 仅仿真/原型 |
5. 关键权衡、风险与依赖
5.1 跨层耦合
- VLA 自定义 forward(如 OpenVLA
predict_action、π0 flow matching loop)无法纯 ONNX 导出 → 须 torch-mlir custom op 或 Python 图截断 + 编译热点子图。 - RTC 横跨模型(训练)与运行时(执行) → 19 章 ADR-045 + 12 章异步调度 + 13 章时间确定性。
- Cross-embodiment 动态 shape:action dim/state dim 变化 → 编译器 shape polymorphism 子集(固定 max dim + padding)。
5.2 算子覆盖优先级(具身 P0)
| 优先级 | 算子/模式 | 来源模型 | 备注 |
|---|---|---|---|
| P0 | GEMM/FC(batched M=1) | 全部 | 02/16 章核心 |
| P0 | Multi-Head Attention + KV-cache | OpenVLA/π0 VLM | 03/12 章 |
| P0 | LayerNorm/RMSNorm/Softmax | Transformer 全系 | 融合 |
| P0 | 流匹配/扩散迭代循环(while) | π0/GR00T/Diffusion Policy | 编译器 loop tiling |
| P1 | ViT patch embed + 2D conv | DINOv2/SigLIP | 04-kernels 扩展 |
| P1 | Cross-attention(视觉→语言) | OpenVLA/π0 | 不规则 mask |
| P1 | Action chunk reshape/gather | π0 H=50 | 动态 |
| P2 | 3D conv / video attn | 世界模型(未来) | 扩展阶段 |
| P2 | MoE routing | 大 VLM(未来) | 规模化阶段 |
5.3 单点风险
- π0 未官方发布 INT4 权重 → 须自研 PTQ 并验证 rollout(19 章)。
- OpenVLA 4-bit 在非 NVIDIA 硬件无官方支持 → 我们须自证 INT4 kernel 精度。
- Helix 三系统对我们 startup 过重 → 端侧基线阶段 用 双系统(VLM+动作头) 简化,13 章保留扩展。
- LeRobot 快速迭代 → importer 须版本 pinning + manifest schema 稳定。
5.4 Demo 仓库贯通(对齐 00-minimal-e2e-platform-demo-plan.md)
| Demo 阶段 | 模型相关交付 | 对应洞察 |
|---|---|---|
| M1 | 手写 linalg.mlir tiny-gemm | 算子 P0 基础 |
| M2 | 05-importer ONNX→IR;manifest 含 model_family/quant/action_dim | 本章 + 19 章 |
| M3 | E2E CI 跑通 tiny-gemm;预留 openvla-block / flow-step lit 测试 | 算子 P0/P1 |
| M5 | Model Zoo 架构:OpenVLA/π0 配置 YAML(非完整权重) | 26 章前置 |
6. 结论与待决项
6.1 初步结论
以下基于 §3 TOP 芯片部署横向对比、§3.7 多模态/世界模型边界与 §4 矩阵;非正式 ADR。
- 基线模型族候选(§4.1):倾向 π0 类流匹配 VLA(主) + OpenVLA(AR 兼容) + Diffusion Policy + 轻量感知 stub;对标参考 GR00T N1.7 on Thor,非绑定 NVIDIA 栈。
- 部署模式候选:倾向 B(VLM+动作专家) + E(RTC 异步 chunk);C(双系统 VLM+DiT)、F(VLA+ER Agentic) 作架构参考,端侧基线阶段 简化为双系统。
- 公开延迟靶标(验收输入,非承诺):GR00T Thor ~92ms/10.9Hz(以官方为准);π0 76ms@4090;310P π0 430ms —— M3 应量化对比,目标 chunk ≤100ms 为候选 SLO。
- 编译/runtime 能力候选:KV-cache + 多步/单步 loop 双路径 + chunk 双缓冲 + multi-VM;与 12/13/15 章候选联动。
- SDK 候选:对齐 LeRobot manifest;预留 Gemini/OpenVLA/GR00T/π0 扩展字段;世界模型 P2,不阻塞 端侧基线阶段。
6.2 待决项
- π0 vs OpenVLA 谁作 M3 E2E 首个完整 VLA(2 周内模型+编译联合定)。
- RTC 放 runtime 内置 vs 应用层库(与 12 章联合)。
- 动作专家是否可 独立编译为 sub-module(内存/调度收益待 profiling)。
- UnifoLM-VLA-0 等国内模型是否纳入 端侧基线阶段 兼容列表。
6.3 ADR 候选
- ADR-046 基线具身模型族与验收集:倾向候选 π0 类(5 步流匹配)+ OpenVLA 7B(INT4/QVLA)+ Diffusion Policy(OneDP/10 步)+ ViT stub;延迟靶标候选 ≤100ms/chunk(对标 GR00T Thor 92ms);验收 = rollout + 频率 + p99;LeRobot manifest;M3 前联合定稿。
- ADR-047 VLA/扩散动作头部署模式:倾向候选 VLM(AOT+KV)+ 动作专家(多步 loop + 1-NFE 快路径);DiT 可 独立 AOT 子模块(学 GR00T);RTC 异步 chunk;OpenVLA AR 兼容。
- ADR-048 多系统/多频率编排:端侧基线阶段 倾向 双系统(VLM+动作/DiT);预留 VLA+ER Agentic 双 VM(Gemini 式);1kHz 伺服走 CPU/DSP/安全岛(需求红线,非方案锁定)。
- ADR-049 具身算子覆盖优先级:倾向 P0 = GEMM/MHA+KV/LN/Softmax/迭代 loop;P1 = ViT conv/cross-attn/chunk ops;P2 世界模型;compiler/runtime loop fusion + while 调度为 P0 能力候选。
7. 端→边→中心演进影响
| 维度 | 端侧 | 边缘 | 中心 |
|---|---|---|---|
| 模型 | π0/OpenVLA INT4 | 共享 VLM FP8 | 全精度 GR00T 级 |
| 部署 | RTC + 全本地 | 模型分区(端小/cloud 大) | 训练/蒸馏 |
| 编排 | 双系统 | 多租户 VLM 服务 | batch 推理 |
不可逆点:动作头 流匹配/扩散迭代 若未在编译器 IR 中表达为 first-class loop,后续融合优化空间小 → 端侧基线阶段在 DSA Dialect 引入 dsa.flow_step 或等价 loop 原语。规避:即使第一版手写 unroll 5 步,IR 层仍保留语义 loop 节点。
深入思考
每题先给题干,再折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。
思考题 1:三种部署模式的内存与延迟取舍
同样面对「视觉+语言+动作」这套具身推理,业界给出了三种部署形态:单体 VLA(OpenVLA)、VLM + 动作专家(π0)、双系统流水线(GR00T)。结合 §3.3 部署模式表与 §3b 芯片诉求,把这三种形态在「主存占用」「首步延迟」「持续频率」三个维度上算一遍,并说明为什么「模块化(VLM+专家)」在端侧 DSA 上往往比单体 VLA 更划算。
展开参考答案(含三形态内存/延迟对比图 + 算一遍 )
结论:单体 VLA 把视觉、语言、动作压进一张 7B 网络,内存省一点但每一步动作都要过完整大模型,持续频率被 AR decode 卡死;VLM+动作专家把「重的语义前缀」算一次并缓存 KV,之后只让 300M 小专家反复迭代动作,持续频率显著提升、片上驻留收益大;双系统进一步把 VLM 和扩散头解耦成两个可独立编译、独立调频的子模块,代价是两模型内存切换与中间 tensor 传递的 runtime 复杂度。
用具体数字算一遍(INT4/BF16 混合,数量级估算,均以官方/实测为准):
| 维度 | A 单体 VLA(OpenVLA 7B) | B VLM+专家(π0 类) | C 双系统(GR00T 类) |
|---|---|---|---|
| 主存占用 | 7B INT4 ≈ 3.5GB + KV | VLM 3–4B ≈ 1.7–2GB + 专家 300M ≈ 0.15GB + KV | VLM + DiT 两份,须同时或切换驻留,峰值更高 |
| 首步延迟 | prefill 重(双视觉塔 + 7B) | VLM prefill 一次 ~46ms + 首步去噪 | VLM ~38ms(Thor backbone)+ DiT 首步 |
| 持续频率 | AR decode 逐 token → ~3Hz | 前缀 KV 复用,只迭代小专家 → 数十 Hz | DiT 4 步 → Thor ~11Hz(以官方为准) |
为什么模块化更划算:端侧 DSA 的 SRAM/带宽是稀缺资源。单体 VLA 每步都要把 7B 权重从主存搬过一遍——「带宽 > 峰值算力」(§3b);而 VLM+专家把语义前缀算一次缓存成 KV,后续只让 300M 专家常驻片上 SRAM 反复迭代,权重搬运量骤降,这正是 §3b「动作专家 300M 可驻 SRAM,片上驻留收益大」的由来。双系统把这一思路推到极致——VLM 和扩散头彻底解耦、独立编译、独立调频,但换来 runtime 要处理两模型的内存切换与中 间 tensor 传递(对应 12 章 ADR-037 multi-VM)。
回链:详见 §3.3 部署模式对比表(A/B/C 三行)、§3b「单体 VLA → VLM+专家」与「同步 chunk → 双系统」演进行,以及 §6.3 ADR-047「VLM(AOT+KV)+ 动作专家」候选。
思考题 2:π0 流匹配 chunk 如何契合设备实时性
π0 用「VLM prefill + 流匹配多步去噪」生成一个动作 chunk(H=50),控制语义是 50Hz。但硬件侧看到的不是「50Hz 单动作」,而是「一个 chunk 的端到端延迟」。结合 §2.2 硬性指标(prefill 46ms + 5 步去噪 ~30ms)与 §3.5 的 RTC,拆开这条流水,解释为什么「看 chunk 延迟而非单 token」,以及 RTC(异步 chunk)为什么能在延迟波动下仍不停顿。
展开参考答案(含 chunk 时间轴流水图 + 算一遍)
结论:流匹配一次生成一整段 H=50 的动作 chunk,而不是逐个动作;所以只要「chunk 端到端延迟(prefill 一次 + 若干步去噪)」小于「一个 chunk 覆盖的执行时长」,机器人就永远有动作可执行——这才是实时性的正确口径。RTC 更进一步:在执行当前 chunk 的同时异步生成下一个 chunk,把生成延迟藏进执行时间里,即使某次生成慢了,双缓冲也能续上,不停顿。
用具体数字算一遍(以 π0 类 @4090 公开口径为参考,以官方为准):
- 一个 chunk 的生成延迟 = prefill 46ms + 5 步去噪 30ms ≈ 76ms。
- 一个 chunk 的执行时长:H=50 个动作,若控制 50Hz(每动作 20ms)→ 一个 chunk 覆盖 50 × 20ms = 1000ms 的执行。
- 对比:生成 76ms < 执行 1000ms → 机器人执行完当前 chunk 之前,下一个 chunk 早已生成好,流水永不断供。这就是「看 chunk 延迟」而非「看单 token」的原因——单个 token/动作的延迟没有意义,有意义的是「生成一个 chunk 是否赶得上执行完上一个 chunk」。
- RTC 的价值:同步方案里,若某次生成抖动到 135ms,执行会短暂等待;RTC 让 chunk N+1 在 chunk N 执行期间异步生成(§3.5「Training-Time RTC 108ms vs 135ms」),并用 inpainting 平滑衔接边界,即使单次生成慢也不停顿——代价是 runtime 要做 chunk 双缓冲(§5.1、§3.9)。
回链:详见 §2.2 硬性指标(prefill 46ms + 5 步去噪)、§3.5「Training-Time RTC」行、§3.3 模式 E(异步 Chunk RTC),以及 §6.3 ADR-047「RTC 异步 chunk」。
思考题 3:cross-embodiment 动态 shape 对编译器的要求
π0 主打 cross-embodiment(跨本体):同一个模型部署到不同机器人,输入的 state 维度、输出的 action 维度会随本体变化。结合 §2.2「编译器须支持动态 shape 子集」与 §5.1「shape polymorphism 子集」,分析为什么这给 AOT 编译器带来压力,以及「固定 max dim + padding」这套折衷方案的取舍。
展开参考答案(含动态 shape 编译路径图 + 对比表)
结论:AOT 编译器要提前把计算图固化成针对确定 shape 的高效 kernel,而 cross-embodiment 的 state/action 维度在部署时才确定、还可能一台机器一个值——纯动态 shape 会让编译器要么放弃优化、要么为每个 shape 重新编译。工程折衷是只支持一个「动态 shape 子集」:固定一个 max dim、对不足的维度做 padding,用一份编译产物覆盖一族本体,代价是 padding 带来的算力浪费。
三种策略对比:
| 策略 | 优点 | 代价 | 适用 |
|---|---|---|---|
| 纯静态(每 shape 重编) | 每份 kernel 最优 | 本体数 N → N 份产物,编译/分发爆炸 | 本体固定、数量极少 |
| 纯动态 shape | 一份产物通吃 | 放弃 tiling/向量化等静态优化,或 JIT 运行时开销 | 原型/开发态 |
| max dim + padding(子集) | 一份产物覆盖一族本体,保留静态优化 | padding 维度做无用计算,算力有浪费 | 端侧基线首选 |
为什么 padding 可接受:具身模型的 state/action 维度通常只有几十(远小于视觉 token),padding 到 max dim 带来的额外计算相对整个 VLM+专家推理是小头;而换来的是「一份编译产物 + 稳定的 kernel 性能 + 免去每本体重编」。这正是 §5.1「固定 max dim + padding」的工程逻辑,也对应 §5.3「Helix 三系统对我们过重 → 端侧基线用双系统简化」的同一取舍哲学——在能覆盖需求的前提下,选择编译器最 好驾驭的那个 shape 子集,而不是追求完全的动态泛化。
回链:详见 §2.2「多本体 → 动态 shape 子集」、§5.1「Cross-embodiment 动态 shape → shape polymorphism 子集」,以及 §6.3 ADR-046/049 中关于算子覆盖与动态维度的候选口径。
附:信息来源
区分公开/估计;参考时间 2026-06。
- Isaac GR00T 部署性能(Thor ~92ms/10.9Hz TRT;Orin 173ms/5.8Hz;backbone 38ms+DiT 49ms):nvidia-isaac-gr00t mintlify optimization/tensorrt docs;具体数值以官方为准。[公开]
- Isaac GR00T Thor 量化(nvfp4/fp8;4 denoising steps):GitHub NVIDIA/Isaac-GR00T #415。[公开]
- GR00T N1.7 GA(2026 GA 版,非 N1.5):NVIDIA Isaac 发布说明。[公开,版本以官方为准]
- Gemini Robotics 1.5 + ER 1.6 + On-Device(双模型;50–100 demo;Atlas/Apollo):deepmind.google;The Robot Report 2025;Boston Dynamics partnership 2026。[公开]
- Qualcomm Dragonwing IQ10 Physical AI(700 TOPS;VLA/VLM;IQ10 RRD):BusinessWire CES 2026;edge-ai-vision.com Computex 2026。[公开]
- 昇腾 310P π0 LeRobot 部署(~430ms FP16;叠衣真机):devpress.gitcode.com。[公开]
- QVLA / OneDP / OFP / RTC:见 19 章来源;arXiv:2602.03782(待核), 2410.21257, 2603.12480(待核), 2506.07339。[公开]
- π0 / π0.5 / π0.7(2026-04):Physical Intelligence, arXiv:2410.24164;pi.website。[公开]
- Real-Time Chunking / Training-Time RTC:arXiv:2506.07339, arXiv:2512.05964(待核);pi.website。[公开]
- OpenVLA-OFT(并行解码+连续动作+L1 头):openvla-oft 项目/论文;倍数以官方为准。[公开]
- NVIDIA Isaac GR00T N1.7 + Jetson Thor:NVIDIA Isaac 2025–2026;developer.nvidia.com TensorRT Edge-LLM blog。[公开]
- Figure Helix 02 三层(S2 7–9Hz / S1 200Hz / S0 1kHz):figure.ai/news/helix-02;频率以官方为准。[公开]
- Diffusion Policy:Chi et al., 2023;ACT:Zhao et al., ALOHA, 2023。[公开]
- LeRobot(HuggingFace) 机器人 ML 栈:github.com/huggingface/lerobot。[公开]
- Demo 方案:../dev/00-minimal-e2e-platform-demo-plan.md。[内部]
- 延迟/算力粗算:基于 π0/RTC 公开 profiling 的工程估算。[估计]