24 端云协同与伴随服务洞察
- 章节编号:24
- 所属层:D 部署与服务层(端→边→中心桥接;承接 23 Fleet、29 遥测)
- 关联 ADR:ADR-083(编译云与 CI farm)、ADR-084(模型/制品分发 CDN)、ADR-085(遥测与回流最小闭环)、ADR-086(远程推理与 π0 云路径边界)
- 上游依赖:18(autotune farm)、20(compile)、22(bundle)、23(Fleet)、29(telemetry)
学习目标
- 前置知识:读过 21 章(具身模型支持,尤其 π0/GR00T 的 chunk 延迟画像)与 23 章(Fleet/OTA);知道「1kHz 伺服 / 200Hz 视觉运动 / 数十 Hz 策略」这套分频率控制栈;对「往返时延 RTT」「量化(INT4/FP8)」「制品签名分发」有基本概念。无需分布式系统或 MLOps 平台经验——本章从「哪段计算放哪里」而非「怎么搭 K8s」切入。
- 学完产出:① 能一句话讲清端云分工的铁律——控制环(1kHz 伺服、VLA chunk)默认本地,云只做编译、分发、遥测分析、OTA——并用「云 RTT vs 控制周期」的数量级对比证明为什么控制环不能依赖云;② 能把一次具身任务的计算拆成「必须端侧 / 可卸载到云边」两类,说清判据是「是否落在实时闭环里」而非「模型大小」;③ 能设计一套断网降级策略,说清网络从「在线」退化到「弱网 / 断网」时,伴随服务(遥测、远程推理、OTA)如何逐级降级而控制环岿然不动;④ 能读懂本章 ADR 候选(ADR-083~086),把「端云边界」翻译成「compile farm 门禁 + CDN 分发 + 遥测最小闭环 + 远程推理红线」的可执行输入;⑤ 能对照 §3.1 横评表,判断 NVIDIA NGC、Physical Intelligence 云路径、Figure 全 onboard 三条路线各自的取舍,以及自研 toolchain 的差异化窗口。
- 阅读姿势:盯住一条主线——「端云边界不是按算力大小切的,是按『是否在实时闭环里』切的」。一个 7B VLA 只要它的输出要闭合到 1kHz 伺服,就必须端侧;一个几百 GB 的编译 autotune 任务,因为它离线、不进闭环,就该上云。读每一行分工表时不要问「这东西大不大」,要问「它断网了机器人会不会摔」。
1. 范围与目标
定义 云端/边缘如何支撑端侧:编译 farm、模型分发、telemetry 后端、field data 回流(31 章预研)。扩展阶段 建 最小伴随服务,非完整 MLOps 平台。
核心问题
- 哪些工作在云、哪些必须在端?判据是什么?
- autotune/compile farm 如何与 18 L2 Agent 衔接?
- π0 远程推理 vs Figure onboard 边界?
- 断网 / 弱网 时伴随服务如何降级,而控制环如何岿然不动?
- 对标 NVIDIA NGC、LeRobot Hub、Physical Intelligence cloud?
2. 需求洞察(具身驱动)
| 场景 | 端云分工 |
|---|---|
| VLA 编译(18) | 云/边 farm;端仅 load vmfb |
| GR00T 级实时 | 端侧 92ms;云不做闭环 |
| 模型下载 | CDN + 23 OTA |
| 失败 rollout 视频 | 边侧缓冲→云 (29/31) |
| QAT/蒸馏(19) | 小规模云 GPU;非训练集群 |
原则(01 章):1kHz 控制与 VLA chunk 默认本地;云做 compile、分发、analytics、OTA。这条原则不是保守,而是被物理时延逼出来的——下一节先把「为什么控制环不能上云」用数量级摆清楚。
2.1 一条铁律:实时闭环必须端侧
判断某段计算能否上云,只有一个问句:它是否落在一个有实时死线的闭环里? 落在闭环里 → 端侧;不在闭环里(离线、批处理、可异步) → 云/边皆可。
为什么这样切:实时闭环的死线是硬的——1kHz 伺服每 1ms 必须产出一个力矩指令,晚了机器人就会抖动甚至摔倒。而任何一次公网往返(RTT)都远超这个预算(详见 §3.4 与「深入思考」思考题一的算一遍)。反过来,编译一次要几分钟、autotune 要几小时,这些计算离机器人当下的动作十万八千里,放在云上批量跑反而更省端侧算力。大小不是判据,死线才是。
3. 技术现状与趋势
3.1 TOP 级端云协同方案深度对比(2025–2026)
| 公司 | 编译/优化云 | 模型分发 | 仿真/评测云 | 端侧闭环 | 具身案例 | 优势 | 劣势 |
|---|---|---|---|---|---|---|---|
| NVIDIA | NGC build;Isaac Sim/Lab | NGC catalog | Omniverse/Isaac Sim | Jetson Thor 本地 | GR00T train→deploy | 全栈 | 闭源;绑 CUDA |
| Physical Intelligence | 自研训练 | 官网/合作 | 内部 bench | RTC 本地;远程可选 | π0/π0.7 | 模型中立 | 云细节少 |
| Figure | 内部 | ❌ 公开 | 内部 | 100% onboard | Helix 02 | 无云依赖 | 不可复用 |
| LeRobot/HF | 用户 GPU | HF Hub | 社区 | 本地 | π0/OpenVLA | 开放权重 | 无 compile farm |
| Google DeepMind | TPU 云 | — | 内部 | RT-2 偏云 | 研究 | 规模 | 非边缘产品 |
| AWS | SageMaker | S3/ECR | — | Greengrass | 通用 | 托管 | 非 VLA 原生 |
| 我们(目标) | ISS/autotune farm(24/30) | CDN+OTA(23) | Isaac 拓扑参考 | manifest local SLO | π0/GR00T 靶 | 开源 toolchain | farm 待建 |
横评结论:三条路线的端侧闭环无一例外都在本地(Thor 本地、π0 RTC 本地、Figure 100% onboard),差异只在「云端支撑」这一侧——NVIDIA 靠全栈闭源云、PI 靠模型中立可选远程、Figure 干脆不要云。这印证了 §2.1 铁律:闭环没有争议地放端侧,厂商们真正竞争的是『云怎么支撑端』,而非『能不能把闭环搬上云』。 我们的差异化窗口是「开源 toolchain + 硬件中立的 compile farm」,踩在 PI 模型中立与 LeRobot 开放权重的交集上。
3.1a 端云边界深度对比(具身专项)
| 模式 | 代表 | 优势 | 劣势 | 我们策略 |
|---|---|---|---|---|
| Fully onboard | Figure Helix | 低延迟;隐私;无网依赖 | 算力/功耗高 | 默认 SLO 模型 |
| Cloud brain | 早期 RT-2 部署 | 大模型 | latency/断网 | 禁止 1kHz/VLA SLO |
| Hybrid compile | NVIDIA GR00T | 云训练+边推理 | 需 NGC | 我们 compile farm |
| Remote assist | π0 teleop | 人在环 | +200ms 仍可做精细操作(RTC) | demo 标签 local-only |
3.1b Isaac Sim vs 我们 ISS farm(仿真分工)
| 维度 | Isaac Sim(云/工作站) | 我们 ISS/cycle-approx farm |
|---|---|---|
| 用途 | 视觉/物理 sim2real;数据生成 | 编译正确性/性能/tuning |
| 优势 | 照片级渲染;GR00T 官方训练链 | bit-exact ISA;CI 门禁 |
| 劣势 | 不验证 DSA kernel | 无物理交互 |
| 关系 | 互补:Sim 管「物理世界像不像」 | ISS 管「芯片指令对不对」;规模化阶段与 31 数据闭环合流 |
3.2 编译云(衔接 18 ADR-066)
Developer push manifest → CI compile(ISS gate) → autotune farm(L1/L2)
→ signed bundle → CDN → 23 OTA → robot
- ISS gate:MR 必过;硅后 nightly 回归。
- L2 Agent:仅在 farm 跑;输出 spec PR,非端侧 LLM。
这条流水的核心特征是单向、离线、可异步:开发者提交后,编译与 autotune 在云端 farm 慢慢跑,产出签名 bundle 经 CDN 下发。机器人任何时刻拿到的都是「已经编好、已经签名」的成品,不依赖云的实时应答——这正是它能安全上云的原因(与 §2.1 铁律一致)。
3.2a 影子模式:云端评测不进闭环
一个容易被误当成「云闭环」的场景是影子模式(shadow mode):让云端的大模型或新版策略与端侧当前策略并行推理同一份输入,但只记录云端输出、不接入执行。
影子模式的价值:在不冒任何执行风险的前提下,用真实现场数据评估「云端大模型 / 候选新版本会怎么做」,为后续 OTA 升级或蒸馏提供离线打分。关键红线:影子路径的输出绝不接入执行——它是只读的观察者。一旦云端影子输出被接回控制,就退化成被 §3.1a 明令禁止的 Cloud brain,断网即失控。因此影子模式的数据回传走 §3.3 的异步遥测通道,断网时直接丢弃,不影响端侧生产策略半分。
3.3 遥测与回流(29/31 预研)
| 数据 | 路径 | 用途 |
|---|---|---|
| chunk_ms / Hz | 端→Fleet | SLO |
| 热/功耗 | 端→Fleet | 11 章 |
| 失败 episode | 边缓冲→云 | 31 评测 |
| 影子模式打分 | 边缓冲→云 | 3.2a 离线评估 |
| 禁止 | 原始视频默认上云 | 28 隐私 |
遥测的设计原则是尽力而为(best-effort)、可丢弃、不阻塞:所有回传都先落边侧缓冲,网络好时批量上云,网络差时本地暂存,缓冲满则按优先级丢弃。遥测链路的任何阻塞都绝不能反压到控制环——这是断网降级(§3.4a)能成立的前提。
3.4 远程推理边界
| 允许 | 禁止 |
|---|---|
| 非实时 demo、teleop 辅助 | 1kHz 闭环 |
| 超大 VLA 原型 | 量产 GR00T 级 latency SLO |
π0 RTC:远程时 delay 更大;runtime 须 Training-Time RTC 兼容(21)。远程推理只在「延迟本就宽松」的场景成立——teleop 辅助有人 在环、demo 无硬死线;而 π0 的 RTC(实时 chunk)机制让「+200ms 延迟仍能完成精细操作」,是远程推理唯一能沾边实时任务的技术缓冲(详见 21 章)。但一旦是量产 SLO 闭环,远程推理一律禁止——这条红线由 ADR-086 固化。
3.4a 断网降级:控制环岿然不动
真实现场的网络是不可靠的。伴随服务的设计必须回答:从「在线」退化到「弱网」再到「断网」,系统如何逐级降级,而控制环始终不受影响?
降级三原则:① 控制环全程零依赖云——在线、弱网、断网三态下 1kHz 伺服与 VLA chunk 一律本地全速,这是不动点;② 伴随服务优雅降级——遥测降频→缓冲→落盘,OTA 暂停→等窗口,远程/影子直接禁用,任何一项失败都不反压闭环;③ 恢复即回补——网络恢复后,边侧缓冲的遥测按优先级补传,OTA 在空闲窗口续拉。因为控制环本就不在云端闭环里(§2.1),断网对它而言只是「少了个可选的观察者」,而非「大脑掉线」。
3.5 趋势
- compile in cloud, run on edge——行业默认。
- Agent CI farm(30 章)与 compile farm 合一。
- field data 闭环 规模化阶段(31)。
- 影子模式 + 离线评测 成为大模型端侧落地的安全阀:先影子观察、再蒸馏、后 OTA,全程不冒执行风险。
- π0.7 / GR00T N1.7 GA(2026) 均以本地闭环为默认形态,远程推理仅作可选路径——「云支撑端」而非「云替代端」已是共识。
4. 候选方案
| 候选 | 小结 |
|---|---|
| A. 自建 compile farm + S3-compatible CDN + Fleet API | 建议方案(M3+) |
| B. 纯 GitHub Actions + manual USB | M1–M2 |
| C. 全托管 SageMaker | 非主线 |
6. 结论与 ADR
- 编译/autotune 在云/边 farm;端只跑 signed bundle。
- VLA 闭环默认本地;远程仅 demo/非 SLO。
- 最小 telemetry 喂 29/11/18;尽力而为、可丢弃、不反压闭环。
- 断网降级 三态设计:控制环不动,伴随服务优雅降级 + 恢复回补。
- ADR-083 编译云:ISS CI gate;autotune farm;L2 Agent 仅 farm。
- ADR-084 制品分发:CDN + 23 OTA;bundle 签名;LeRobot Hub 可选镜像。
- ADR-085 遥测最小闭环:chunk_ms/Hz/thermal/power → Fleet;无默认原始视频;边侧 缓冲、断网落盘、恢复回补。
- ADR-086 远程推理边界:禁止 1kHz 上云;远程须 RTC-aware;SLO 模型 local-only 标签;影子模式只读不接入执行。
深入思考
每题先给题干,再折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。
思考题 1：为何控制环不能依赖云
有人提议:「我们端侧算力紧张,不如把 1kHz 伺服控制或 VLA chunk 生成放到云端大机器上跑,端侧只做传感器采集和执行,这样端侧成本能砍一大半。」结合 §2.1 铁律与 §3.4 远程推理边界,把「云 RTT」与「控制周期」放在一起算一遍,论证这个提议为什么在物理上不成立,以及远程推理唯一能沾边的场景是什么。
展开参考答案（含 RTT vs 控制周期时序图 + 算一遍）
结论:1kHz 伺服的控制周期只有 1ms,而任何一次公网往返(RTT)动辄几十到上百毫秒,比控制周期大两三个数量级;把控制环放上云,意味着每个周期都要赌一次网络往返赶不赶得上死线,而网络还会抖动、丢包、断连,所以控制环必须端侧,云永远只能做离线、无死线的支撑工作。
用具体数字算一遍(数量级估算):
- 1kHz 伺服的死线:控制周期 = 1 / 1000 Hz = 1ms。每个周期必须产出一个力矩/位置指令,晚了就抖动。
- 一次公网 RTT:同城数据中心乐观 ~10–30ms,跨区 ~50–100ms,移动网络 / 弱网可达 数百 ms 甚至丢包重传到秒级。
- 对比:RTT 30ms 是控制周期 1ms 的 30 倍;即便乐观取 10ms,也是 10 倍。换句话说,云端每回一个指令,端侧已经错过了 10–100 个控制周期——伺服环根本无法闭合。
- VLA chunk 同理:π0 chunk 本地生成 ~76ms、GR00T ~92ms;若改走云,光 RTT 就吃掉几十毫秒且方差极大,一次网络抖动就让 chunk 断供、机器人停顿。而本地生成延迟稳定、无网络方差。
- 远程推理唯一能沾边的场景:延迟本就宽松的任务——teleop 辅助(人在环,§3.4)、无死线 demo、超大模型原型。π0 的 RTC 机制能容忍 +200ms(21 章),但那是异步 chunk 双缓冲在藏延迟,不是把实时闭环搬上云。
要点:端侧成本能不能省,和控制环能不能上云是两个问题。控制环的物理死线决定了它必须本地;要省成本应该从量化(INT4)、模型蒸馏(OneDP 单步)、片上驻留(§21 章 3b)入手,而不是赌网络。
回链:详见 §2.1「实时闭环必须端侧」铁律图、§3.1a「Cloud brain 禁止 1kHz/VLA SLO」、§3.4 远程推理边界,以及 §6 ADR-086「禁止 1kHz 上云」。
思考题 2：哪些任务可卸载到云 / 边
既然控制环必须端侧,那到底哪些具身任务可以安全卸载到云或边?有人凭直觉认为「大模型上云、小模型端侧」,结合 §2.1 判据、§3.2 编译流水与 §3.2a 影子模式,论证为什么「模型大小」是错的判据、「是否在实时闭环里」才是对的判据,并把常见任务分成「必须端侧」与「可卸载」两类。
展开参考答案（含任务卸载判定图 + 对比表）
结论:判据不是模型大小,而是「这段计算是否落在一个有实时死线的闭环里」。编译一个几百 GB 中间产物的 autotune 任务离线、无死线,理应上云;而一个几百 M 的动作专家因为要闭合到 50Hz 控制,必须端侧。凡是离线、批处理、可异步、失败可重试的,都能卸载到云/边;凡是进实时闭环、断网即失控的,一律端侧。
任务分类对比表:
| 任务 | 大小直觉 | 在实时闭环? | 正确归属 | 理由 |
|---|---|---|---|---|
| 1kHz 伺服控制 | 极小(几十 K 参数) | 是,死线 1ms | 端侧 | 断网即摔,与大小无关 |
| VLA chunk 生成(π0/GR00T) | 大(数 B 参数) | 是,喂控制 | 端侧 | 「大」却必须本地——反证大小非判据 |
| 200Hz 视觉运动(Helix S1) | 中 | 是,死线 5ms | 端侧 | 高频闭环 |
| 模型编译 / autotune | 巨大(GB 级中间产物) | 否,离线 | 云/边 farm | 「巨 大」却上云——再证大小非判据 |
| QAT / 蒸馏 | 大,需 GPU | 否,离线批处理 | 云小规模 GPU | 失败可重试 |
| 遥测分析 / SLO 统计 | 小 | 否,可异步 | 云 | best-effort |
| 失败 episode 评测 | 中(视频) | 否,可缓冲 | 边缓冲→云 | 隐私,边侧就近 |
| 影子模式候选评估 | 大 | 否(只读不接入执行) | 云/边 | §3.2a,断网直接丢 |
| 多机共享 VLM(网关) | 大 | 否(非闭环调用) | 边侧 | 就近降延迟 |
为什么大小是错的判据:表中两个反例最有说服力——VLA chunk「很大」却必须端侧(它喂控制),编译产物「巨大」却该上云(它离线)。若按大小切,会得出「把 7B VLA 搬上云」的灾难性结论(见思考题一)。正确的问句永远是:断网了,这段计算缺失会不会让机器人当下失控? 会 → 端侧;不会 → 云/边随便放。
回链:详见 §2.1「实时闭环必须端侧」铁律与判定图、§3.2 编译流水(离线可卸载的典型)、§3.2a 影子模式(大模型只读不接入),以及 §6 ADR-083/086。
思考题 3：断网降级策略如何设计
现场机器人的网络时好时坏甚至完全断连。请设计一套断网降级策略:当网络从「在线」退化到「弱网」再到「断网」 时,伴随服务(遥测、OTA、远程 teleop、影子模式)分别如何降级,而控制环为什么能在三种状态下都岿然不动?结合 §3.3 遥测原则与 §3.4a 三态降级图论证。
展开参考答案（含三态降级状态机图 + 算一遍）
结论:断网降级的第一原则是「控制环全程零依赖云」——因为它本就不在云端闭环里(思考题一/二),断网对它只是少了个可选观察者,而非大脑掉线;其余伴随服务全部设计成尽力而为、可丢弃、不反压:遥测降频→缓冲→落盘,OTA 暂停→等窗口,远程/影子直接禁用,网络恢复后按优先级回补。整套策略的不动点永远是那个端侧闭环。
用一次断网事件算一遍(设机器人正在执行叠衣任务,网络突然断 30 秒):
- t=0 断网瞬间:控制环正在跑本地 π0 chunk + 1kHz 伺服,零变化——它读取的是本地已下发的 signed bundle,不查云。机器人继续叠衣,毫无停顿。
- 遥测:t=0 前实时上云的 chunk_ms/Hz/热功耗,此刻转为边侧缓冲;缓冲区按环形队列存 30 秒数据,若更长则按优先级丢弃低价值样本(§3.3 尽力而为)。
- OTA:若恰好有新 bundle 在下载,暂停并保留断点,绝不半吊子刷入;继续用现有 bundle。
- 远程 teleop / 影子:若当时挂着远程辅助,立即降级为端侧全自主(π0 RTC 早已按本地自主设计,+200ms 容忍本就为弱网准备);影子路径直接禁用,其只读输出丢弃即可(§3.2a)。
- t=30s 网络恢复:边侧缓冲的 30 秒遥测按优先级批量回补上云,OTA 在空闲窗口 续传断点,远程/影子重新可用。全程控制环没有任何一个周期受影响。
三原则复述:① 控制环零云依赖(不动点);② 伴随服务优雅降级、不反压闭环;③ 恢复即回补。这套策略之所以成立,根子还是 §2.1 铁律——把闭环留在端侧,断网就从「灾难」降级成「暂时少了些锦上添花的云服务」。
回链:详见 §3.4a 三态降级图、§3.3 遥测「尽力而为、可丢弃、不反压」原则、§3.2a 影子模式「只读不接入」,以及 §6 ADR-085(遥测缓冲回补)/ADR-086(远程 RTC-aware)。
附:信息来源
区分公开/估计;参考时间 2026-06。
- NVIDIA NGC / Isaac Sim / Omniverse(编译云 + 仿真数据生成):developer.nvidia.com;Isaac docs 2025–2026。[公开]
- Physical Intelligence π0 / π0.7 远程推理(RTC 本地为主、远程可选;π0.7 为 2026-04 最新):pi.website;arXiv:2410.24164。[公开,版本以官方为准]
- Figure Helix 02 全 onboard(S2/S1/S0 三层全本地,无云依赖):figure.ai/news/helix-02。[公开]
- LeRobot HF Hub(开放权重分发,无 compile farm):github.com/huggingface/lerobot。[公开]
- GR00T N1.7 GA on Jetson Thor(端侧本地闭环 ~92ms/10.9Hz;云做训练链):NVIDIA Isaac 2025–2026;数值以官方 datasheet 为准。[公开,版本以官方为准]
- Real-Time Chunking / Training-Time RTC(远程 +200ms 容忍;异步双缓冲):arXiv:2506.07339。[公开]
- 公网 RTT / 控制周期数量级:基于同城/跨区/移动网络 RTT 与 1kHz 伺服周期的工程估算。[估计]
- 18/23/29/30/31 章。[内部]