14 多模型/多任务编排洞察
- 章节编号:14
- 所属层:R 运行时层(承接 12 IREE VM、13 实时/QoS、09 MIG、21 双系统 VLA)
- 关联 ADR:ADR-099(多 VM/多 context 编排模型)、ADR-100(GR00T/Gemini 双系统流水线)、ADR-101(RTC 与 chunk 调度)、ADR-102(资源仲裁:QoS/MIG/内存组)
- 上游依赖:09(context/MIG)、11(power profile)、12(IREE VM)、13(QoS/抢占)、21(π0/GR00T/Gemini)
学习目标
- 前置知识:读过 12 章(IREE VM 与 module/HAL stream 概念)、13 章(实时/QoS/抢占/分域调度)、21 章(π0/GR00T/Gemini 双系统模型形态);了解「一个大模型低频、一个小模型高频」的具身双系统直觉即可。无需写过 CUDA stream 或 IREE HAL 代码。
- 学完产出:① 能画出「一个 SoC 上多个模型同时在线」的编排拓扑图,区分 Sequential / Pipelined / Parallel / RTC 双缓冲 / Split 五种模式,并说清各自的中间 tensor 传递路径;② 能给双系统(VLM 低频 + 动作头高频)算一遍分频编排的时间预算——在一个 VLM 周期里塞进几个动作头周期、中间 hidden state 如何复用;③ 能列出多模型并发的显存账(权重 + KV-cache + 激活 + RTC 双缓冲),判断某个内存配置能不能同时驻留几个 context;④ 能把 Helix 的 S2/S1/S0 三频率映射到运行时的三类载体(IREE module / 独立 vmfb / 安全岛),说清为什么 1kHz 那一层不能走通用 NPU 图;⑤ 能对比 TensorRT multi-engine、IREE multi-module、QNN multi-context 三种编排单元的隔离与同步代价。
- 阅读姿势:盯住一条主线——「具身编排的本质,是在同一块内存/算力上,让多个不同频率的模型互不饿死」。VLM 想慢慢想、动作头要拼命跑、伺服环一刻不能停;运行时要做的就是给它们分配算力配额、传递中间张量、并在降频/抢占时决定「谁先被牺牲」。所有 ADR 都在回答这一个问题。
1. 范围与目标
定义端侧 多模型并发、多任务流水线、动态 shape、资源仲裁 的运行时编排。13 章管 OS/RTOS 分域;本章管 NPU/IREE 域内 多 graph/多 VM。
核心问题
- GR00T VLM+DiT、Gemini VLA+ER、Helix S2/S1/S0 如何映射到 runtime?
- Thor MIG 式分区 vs 软件 QoS 如何选型?
- π0 RTC 双缓冲在编排层的语义?
- TOP 方案(TensorRT multi-engine、IREE multi-module、QNN multi-context)对比?
- 感知 CNN + VLA + 小控制网 同时在线 如何仲裁?
2. 需求洞察(具身驱动)
2.1 具体场景
| 场景 | 编排模式 | 来源 |
|---|---|---|
| GR00T N1.5 | VLM(低频)→DiT(高频) 流水线 | 21 章 |
| Gemini Robotics | VLA + ER(Embodied Reasoning) 双 Agent | 21 章 |
| Helix 02 | S2 7–9Hz + S1 200Hz + S0 1kHz 三系统 | 01 章 |
| π0 + 感知 | VLA chunk + ViT 30Hz 并发 | 17/25 |
| 多 robot profile | 换 bundle 不重启岛 | 22/23 |
2.2 硬性指标
- GR00T 级:DiT ≥10Hz 与 VLM ≥3Hz 并发不互相 OOM。
- RTC:执行 chunk N 时 chunk N+1 须已就绪或 inpaint。
- context 切换 ≤50ms(换 task,非 1kHz 环)。
- 内存:128GB 统一内存 场景下 ≥3 context 预留(对标 Thor)。
2.3 一张图看清「多模型同时在线」
先建立整体拓扑直觉:一个具身 SoC 上,感知前端、VLM 大脑、动作头、伺服环这四类负载同时存在,各自频率相差两三个数量级,共享同一块统一内存与 NPU 算力。运行时的职责就是在这张图里做「张量传递 + 算力分配 + 优先级仲裁」。
逐层读这张图:数据流是单向的(感知 → 大脑 → 动作 → 伺服),但四层在时间轴上完全重叠并发——当 VLM 花 300ms 想一次时,动作头已经跑了几十次、伺服环跑了几百次。编排的三个动作对应三条边:张量传递(视觉特征、hidden state、action chunk 如何跨模型/跨频率交接)、算力分配(谁占多少 NPU slice / stream)、优先级仲裁(算力不够时先保谁)。后文 3.x 逐一展开。
3. 技术现状与趋势(点名 + 来源)
3.1 TOP 级多模型编排方案深度对比(2025–2026)
| 栈 | 编排单元 | 并发机制 | 双系统/VLA | 具身案例 | 优势 | 劣势 |
|---|---|---|---|---|---|---|
| NVIDIA Thor MIG | GPU slice | 硬件分区 | GR00T+感知 | Thor 128GB | 硬隔离;确定性边界 | 闭源;slice 固定 |
| TensorRT multi-engine | engine | CUDA stream | VLM+DiT 分开 build | GR00T | 低延迟 | engine opaque;手动编排 |
| IREE multi-module VM | vmfb/module | HAL stream+fence | 可编排队 | 我们主线 | 开源;与编译同源 | DSA 待建 |
| ExecuTorch | .pte program | 分区 delegate | 多 program | Meta 多模型 | PyTorch 原生 | 跨 program 同步弱 |
| QNN multi-context | context binary | HTP session | QIRP | IQ10 | 车规 | 封闭 |
| vLLM/SGLang(云) | request batch | continuous batch | 云 VLA 研究 | 非端侧 | 吞吐 | ms 级不适合 1kHz |
| Helix(Figure) | 3 独立 stack | onboard 全本地 | S2/S1/S0 | Figure 02 | 无云依赖 | 双 RTX ~数百 W |
| Gemini Robotics | VLA+ER orchestrator | 云/端混合 | ER 监督 VLA | Google 2025 | Agentic | 未开源 |
3.2 代表方案深度对比
3.2.1 GR00T 双系统(NVIDIA)
| 维度 | 内容 |
|---|---|
| 编排 | Cosmos/VLM System 2 触发 → DiT System 1 burst 4 步;中间 activation device 内 |
| 优势 | 公开 92ms E2E;ModelOpt per-component 精度 |
| 劣势 | PyTorch+TRT 双 runtime;编排逻辑 应用层 |
| 我们映射 | 双 IREE VM/module + link.yaml(22);RTC 在 12 runtime |
3.2.2 Gemini VLA + ER(2025)
| 维度 | 内容 |
|---|---|
| 编排 | VLA 提议动作 → ER 模块验证/修正 → 执行 |
| 优势 | 安全/推理分离;对齐 28 章 supervisor |
| 劣势 | +latency;需多模型内存 |
| 我们映射 | 可选 第二 bundle(ER stub);非 M3 必须 |
3.2.3 π0 RTC(Physical Intelligence)
| 维度 | 内容 |
|---|---|
| 编排 | 双缓冲 chunk;执行 t 同时生成 t+1;inpainting 填 delay |
| 优势 | +200ms delay 仍成功;有效 Hz > 1/chunk_ms |
| 劣势 | Runtime 并发度+1;内存 2× action buffer |
| 我们映射 | ADR-101;IREE async fence + 12 VM 双实例 |
3.2.4 NVIDIA VLA-Perf / FlashRT(2026 研究/工具)
| 维度 | 内容 |
|---|---|
| VLA-Perf | 建模 device/server/split 延迟;Thor/4090/H100(仓库信息待核 / 社区) |
| FlashRT | π0.5 44ms@Thor;GR00T N1.6 45ms;优化 stack(仓库信息待核 / 社区) |
| 启示 | 编排须纳入 network split 边界(24);benchmark 用 Hz 非仅 ms |
注:VLA-Perf / FlashRT 的具体延迟数字来自社区仓库与预印本,尚未经官方 datasheet 核实,标「待核 / 社区」;引用时以官方发布为准,不作为验收硬指标。
3.3 编排模式分类
| 模式 | 描述 | 适用 |
|---|---|---|
| Sequential | A 完成 → B | VLM 触发 DiT |
| Pipelined | A 慢 + B 快 overlap | GR00T |
| Parallel | 感知 ∥ VLA | multi-camera + chunk |
| RTC Double-buffer | gen ∥ exec | π0 |
| Split inference | 视觉端侧 + VLM 云 | demo only(24) |
五种模式的关系:Sequential 是最朴素的串行(适合 M1 打通),Pipelined 让慢的 VLM 与快的动作头在时间轴重叠(GR00T 主线),Parallel 让互不依赖的感知与动作真并发,RTC 双缓冲是 Pipelined 的一个特化——用「生成下一 chunk」填满「执行当前 chunk」的时间,Split 则把模型拆到端/云两侧(仅 demo)。真实系统往往是几种叠加:GR00T = Pipelined(VLM→DiT)+ Parallel(感知旁路)。
3.4 资源仲裁(衔接 09/11/13)
| 机制 | 层 | 说明 |
|---|---|---|
| MIG / memory group | 09 KMD | 固定算力/内存配额 |
| priority stream | 09/12 | DiT > ViT > 后台 |
| REEF/GCAPS | 13 Plan B | BE kernel 抢占 |
| power_profile | 11 | 降频时 减并发 context |
3.4.1 ActionFlow / 系统级 VLA 调度(2025–2026 研究)
| 维度 | 内容 |
|---|---|
| 问题 | OpenVLA 等 3–5Hz;内存 bound decode;边缘需 20–30Hz 控制语义 |
| 方案 | Cross-Request Pipelining;Decode 与 Prefill 跨时间步 batch |
| 成果 | OpenVLA-7B 2.55× FPS 无重训 |
| 我们映射 | 14 章 与 RTC 正交:RTC=chunk 内;ActionFlow=跨 chunk 请求调度;Runtime 可选 L2 调度器 |
3.5 Helix 三系统 → Runtime 映射
| Helix 系统 | 频率 | 模型形态 | 我们编排 |
|---|---|---|---|
| S2 VLM | 7–9Hz | 大 VLM | IREE module low_prio |
| S1 视觉运动 | 200Hz | 小 Transformer | 独立 vmfb;岛旁 SRAM |
| S0 运动先验 | 1kHz | 10M 级 | 安全岛;非 IREE |
口径说明:Figure 官方 Helix 02(2026)公开的三层频率为 S2 7–9Hz / S1 200Hz / S0 1kHz。部分社区资料把 S0 表述为「1kHz 三系统」的扩展口径,本文沿用官方三层划分,若与官方后续发布不一致,以官方为准。三频率跨越两个数量级,正是「单 SoC 多频 率编排」的极端样本(见 3.5 节思考题)。
3.6 manifest 编排示例(ADR-099)
orchestration:
mode: pipelined_rtc # pipelined | parallel | sequential
modules:
- id: vlm
vmfb: vlm.vmfb
rate_hz: 3
- id: dit
vmfb: action_head.vmfb
rate_hz: 10
rtc: { buffer_depth: 2 }
links:
- from: vlm.hidden
to: dit.condition
qos: { dit: 0, vit: 1, background: 2 }
这段 manifest 在表达什么:两个 module(vlm 3Hz、dit 10Hz)在同一编排里,links 声明 VLM 的 hidden state 作为 DiT 的条件输入(中间 tensor 传递,device 内不落盘),rtc.buffer_depth: 2 开启双缓冲,qos 给出优先级(DiT 最高、ViT 次之、后台最低)。运行时读这份声明,建立 module graph、分配 stream、挂 fence 依赖——编排从「应用层手写循环」变成「可 git 版本化的声明」,这是相对 TRT multi-engine 手动编排的差异化点。
3.7 趋势
- 双系统/三系统成 TOP 标配(GR00T/Gemini/Helix)。
- RTC 从论文进 runtime API(21/12)。
- MIG 硬件分区 + 软件 pipeline 组合(Thor)。
- ActionFlow 类跨请求调度 与 RTC 叠加 提 effective Hz。
- π0.7 / GR00T N1.7 GA 后,动作头 footprint 更小、减步更激进 → 编排层需支持 1-NFE 快路径与多步 loop 并存(与 21 章联动)。
4. 候选方案
| 候选 | 性能 | 确定性 | 成本 | 小结 |
|---|---|---|---|---|
| A. IREE multi-module + priority stream + RTC | 5 | 4 | 4 | 建议方案 |
| B. 单 VM 串行 | 3 | 5 | 5 | M1 only |
| C. 每模型独立 OS 进程 | 4 | 3 | 2 | 内存开销大 |
倾向:A;硬件 MIG 式 memory group(09) 可选增强。方案 A 用单进程内多 module + HAL stream/fence 表达并发与依赖,既拿到 IREE 与编译同源的好处,又避免 C 方案「每模型一个 OS 进程」的内存与 IPC 开销;B 方案(单 VM 串行)只在 M1 打通阶段用,无法满足双系统并发。
5. 关键权衡、风险与依赖
5.1 跨层耦合
- 中间 tensor 传递须 device 内零拷贝(VLM hidden → DiT condition),落盘或走 host 会毁掉 92ms 级预算 → 依赖 12 章 HAL buffer 生命周期与 09 章内存组。
- RTC 双缓冲横跨模型(训练期 delay conditioning)与运行时(双 buffer + fence) → 21 章 ADR-045 + 12 章异步调度 + 13 章时间确定性。
- 1kHz 伺服环不能进通用 NPU 图(抖动不可控) → 13 章分域,走 CPU/DSP/安全岛(见 3.5 节)。
5.2 单点风险
- 多模型并发 OOM:VLM + DiT + 感知 + RTC 双缓冲同时驻留,显存账算不清就会在长任务里 OOM(见 3.4 节思考题)。
- 优先级反转:低优先级后台 kernel 占住 NPU,导致高优先级 DiT 错过节拍 → 依赖 13 章 REEF/GCAPS 抢占。
- FlashRT / vla-perf 数字为社区口径(3.2.4),不能直接作验收靶标,须官方核实。
5.3 Demo 仓库贯通
| Demo 阶段 | 编排相关交付 | 对应洞察 |
|---|---|---|
| M1 | 单 VM 串行跑通 tiny-gemm(方案 B) | 3.3 Sequential |
| M2 | manifest orchestration: 字段解析 | 3.6 |
| M3 | 双 module(vlm-stub + flow-step)Pipelined + link tensor | 3.2.1 / 3.6 |
| M5 | RTC 双缓冲 + priority stream 联调 | 3.2.3 / 3.4 |
6. 结论与 ADR
- IREE multi-module/multi-VM 表达 GR00T/Gemini/Helix 拓扑。
- RTC 双缓冲 为一等编排原语(非应用 hack)。
- QoS:DiT > 感知 > 后台;11 power 降档时 drop 后台 context。
- 对标 TRT multi-engine + MIG;差异化 manifest link.yaml + 可 git 编排。
- ADR-099 编排模型:IREE module graph;manifest
orchestration:字段(pipeline/parallel/rtc)。 - ADR-100 双系统流水线:VLM→DiT link tensor;Pipelined 默认;Sequential 可配。
- ADR-101 RTC/chunk:双 buffer;inpainting;与 21 chunk_size 绑定。
- ADR-102 资源仲裁:priority stream;memory group;与 09 MIG/QoS、13 抢占联动。
深入思考
下面三题每题先给题干,再用
<details>折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。
思考题 1:双系统分频编排的时间预算
VLM 以 3Hz 运行、动作头(DiT/流匹配)以 30Hz 运行。请结合 2.3 节的拓扑图与 3.2.1 节 GR00T 双系统,算一遍:在一个 VLM 周期里能塞进几个动作头周期?VLM 的 hidden state 如何被多个动作头周期复用?若中间 tensor 落盘会发生什么?
展开参考答案(含双系统分频时序图 + 算一遍)
结论:VLM 慢、动作头快,一个 VLM 周期覆盖多个动作头周期;VLM 只需算一次 hidden state,动作头在这段时间内反复以它为条件生成 chunk,中间张量必须 device 内零拷贝驻留——一旦落盘或走 host,搬运时间会吃掉整个高频预算,动作头就跟不上节拍。
用具体数字算一遍(3Hz VLM + 30Hz 动作头):
- VLM 周期 = 1 / 3Hz ≈ 333ms;动作头周期 = 1 / 30Hz ≈ 33ms。
- 一个 VLM 周期里能塞进的动作头周期数 ≈ 333 / 33 ≈ 10 个——即 VLM 每想一次,动作头以同一份 hidden 条件生成约 10 个 action chunk。
- hidden 复用:VLM 的 hidden state 在这 333ms 内保持不变,动作头 10 次生成都读同一块 buffer;只有 VLM 刷新时才替换。这就是「System 2 低频思考、System 1 高频执行」的算力经济学——把最贵的 VLM 前向摊薄到 10 个动作步上。
- 落盘的代价:若 hidden(设为几 MB 级 tensor)每次都 device→host→device 搬一趟,按统一内存带宽粗算,单次搬运可能吃掉数 ms;动作头周期只有 33ms,多搬几次就逼近节拍上限,高频环直接掉帧。故 3.6 节
links声明的中间 tensor 必须是 device 内 buffer(依赖 12 章 HAL 生命周期)。
回链:此题对应 2.3 节拓扑图的「VLM → 动作头」这条边 与 3.2.1 节 GR00T「中间 activation device 内」,是 ADR-100 双系统流水线的量化依据。
思考题 2:多模型并发的显存账
统一内存 128GB,要同时驻留:VLM(INT4)、DiT 动作专家、感知 ViT、以及 RTC 双缓冲。请结合 3.4 节资源仲裁与 5.2 节 OOM 风险,列一张显存账对比表,判断这套配置能否稳定驻留 3 个 context,以及 RTC 双缓冲额外吃掉多少内存。
展开参考答案(含显存构成拆解图 + 对比表)
结论:多模型并发的显存不是「权重相加」那么简单,还要叠 KV-cache、激活峰值、RTC 双缓冲;把这几项分模型列清,才能判断 128GB 够不够——通常权重只占一半,KV-cache 与双缓冲才是压垮 context 数的隐形大头。
显存账对比表(数量级估算,具体以 profiling 为准):
| 组成项 | 单模型量级 | 说明 | 是否随 context 数放大 |
|---|---|---|---|
| VLM 权重(INT4) | ~1.7–3.5GB | 21 章口径,单 VLA INT4 | 否(共享权重) |
| DiT 动作专家 | ~0.3–0.6GB | 300M 级,可驻 SRAM 附近 | 否 |
| 感知 ViT | ~0.2–0.5GB | DINOv2/SigLIP 级 | 否 |
| KV-cache | ~1–数 GB | 随序列长度、并发 context 数线性增长 | 是 |
| 激活峰值 | ~1–数 GB | prefill 时最大,决定瞬时上限 | 是 |
| RTC 双缓冲 | +1× action buffer | 双缓冲即 2× action buffer(3.2.3) | 部分 |
算一遍能否驻留 3 context:
- 权重合计(VLM + DiT + ViT)≈ 3.5 + 0.6 + 0.5 ≈ 4.6GB,权重可跨 context 共享,只算一次 。
- 每个 context 的可变开销(KV-cache + 激活)设 ≈ 数 GB;3 个 context ≈ 权重 4.6GB + 3 × 数 GB。
- RTC 双缓冲额外 +1× action buffer——action chunk 本身不大(H=50 级),但双缓冲让运行时并发度 +1,内存翻倍那部分主要落在 action buffer + 其对应激活。
- 判断:相对 128GB 统一内存,这套配置显存充裕(权重+3 context 可变开销仍远小于 128GB),瓶颈通常不是「装不下」而是「峰值抖动导致 OOM」——故 5.2 节强调降频时(11 章 power_profile)drop 后台 context、给峰值留裕量,而非把内存塞满。真正吃紧的是端侧 Edge 8–16GB 配置(21 章),那里 KV-cache 与双缓冲才是压垮 context 数的主因。
回链:此题对应 3.4 节 memory group / power_profile 与 5.2 节 OOM 风险,是 ADR-102 资源仲裁的量化依据;端侧最低配置口径见 21 章。
思考题 3:S2-S1-S0 三频率如何在单 SoC 编排
Helix 的 S2(7–9Hz VLM)、S1(200Hz 视觉运动)、S0(1kHz 运动先验)三频率跨越两个数量级。请结合 3.5 节 Helix → Runtime 映射与 5.1 节跨层耦合,分析:为什么这三层要映射到三种不同的运行时载体?为什么 S0 的 1kHz 不能走通用 NPU 图?
展开参考答案(含三频率载体映射图 + 对比表)
结论:频率越高、实时性要求越硬,就越要远离通用 NPU 的软件栈——S2 低频大模型放 IREE module 享受编译优化,S1 高频小网独立 vmfb 贴近 SRAM,S0 的 1kHz 硬实时必须下沉到安全岛/DSP,因为通用 NPU 图的调度抖动填不进 1ms 的确定性窗口。
三频率载体对比表:
| 系统 | 频率 | 周期 | 实时性 | 运行时载体 | 为什么这样映射 |
|---|---|---|---|---|---|
| S2 VLM | 7–9Hz | ~110–140ms | 软实时(可抖动) | IREE module,low_prio | 模型大、周期长,值得走完整编译/融合,抖动几 ms 无碍 |
| S1 视觉运动 | 200Hz | 5ms | 准实时 | 独立 vmfb,岛旁 SRAM | 小网频繁调用,需低启动开销 + 数据贴近算力单元 |
| S0 运动先验 | 1kHz | 1ms | 硬实时不可抢占 | 安全岛 / DSP,非 IREE | 1ms 窗口容不下通用调度抖动,须确定性执行环境 |
为什么 S0 的 1kHz 不能走通用 NPU 图(算一遍抖动预算):
- S0 周期 = 1 / 1kHz = 1ms。留给一次前向的窗口只有 1ms,且每个周期都不能错过(错一拍伺服环就失稳)。
- 通用 NPU 图经过 IREE VM 调度、HAL stream 提交、可能与 S1/S2 争抢算力,单次调度开销 + 排队抖动就可能达到甚至超过 1ms 量级——抖动本身就吃光了整个窗口。
- 且 S0 若与 S2/S1 共享同一 NPU,一旦 VLM prefill 占住算力,S0 就可能被拖延——这是 5.2 节「优先级反转」的极端形式,在硬实时环里不可接受。
- 所以下沉到安全岛/DSP:那里是确定性调度、不与通用负载争抢、可保证 1ms 节拍。 这正是 13 章「分域调度」的核心——把硬实时环从通用 NPU 域里切出去,运行时(本章)只管 NPU 域内的 S2/S1 编排,不碰 S0。
回链:此题对应 3.5 节 Helix → Runtime 映射 与 5.1 节「1kHz 伺服环不进通用 NPU 图」,是 ADR-102 资源仲裁与 13 章分域调度的联动依据;三频率口径以 Figure 官方为准(见 3.5 节口径说明)。
附:信息来源
区分公开/估计;参考时间 2026-07。
- NVIDIA VLA-Perf:github.com/NVlabs/vla-perf;arXiv:2602.18397。[公开 / 数字待核]
- FlashRT:github.com/wyp99999/FlashRT 2026。[社区 / 待核]
- Figure Helix 02 三系统(S2 7–9Hz / S1 200Hz / S0 1kHz):figure.ai/news/helix-02。[公开,以官方为准]
- π0 / π0.5 / π0.7 与 RTC:Physical Intelligence, pi.website;arXiv:2506.07339。[公开]
- GR00T N1.5 / N1.7 部署性能:NVIDIA Isaac GR00T docs 2025–2026。[公开]
- 21/12/09/13 章;Isaac GR00T docs。[公开/内部]
- 编排时间/显存粗算:基于双系统公开 profiling 的工程估算。[估计]