12 推理运行时洞察
- 章节编号:12
- 所属层:R 运行时层(与 13 章实时调度强耦合;承接 04/08 系统接口)
- 关联 ADR:ADR-034(运行时框架)、ADR-035(异构调度/异步)、ADR-036(内存管理)、ADR-037(多模型/footprint)
- 上游依赖:01(多频率/batch≈1)、03(内存/KV)、04(统一内存/NoC)、07/08(ISA/同步/显式 DMA)、15(IREE/编译产物)
学习目标
- 前置知识:读过 01 章负载画像(知道 batch≈1、多频率、chunk 延迟这些具身特有约束)与 15 章编译器基础(知道 AOT 会把整张图编译成
.vmfb类字节码);了解 π0 类模型「VLM 前缀 + 动作专家多步迭代」的部署结构(见 M 层 21 章);对「编译态静态图 vs eager 逐算子解释」有直觉即可,不需要写过 IREE/TensorRT。 - 学完产出:① 能说清「运行时」在整条栈中的职责边界——它不做算子实现(那是 16 章 kernel),也不做时间片抢占裁决(那是 13 章实时),而是负责加载编译产物、编排异构设备、管理内存、驱动执行循环;② 能画出 IREE 三层(HAL/VM/后端)如何把一张编译图落到自研 DSA 上,并解释为什么它与我们的 MLIR 编译栈「同源」是 决定性优势;③ 能用「编译态静态图消除了逐算子调度抖动」一句话讲清为什么确定性延迟必须走 AOT 而非 eager,并算一遍两者的调度开销差;④ 能说清 KV-cache / 前缀复用如何把 π0 的 chunk 延迟从「每步重算全序列」降到「prefill 一次 + suffix 增量」,并算一遍一个 chunk 的延迟账;⑤ 能解释「双缓冲(double buffering)」如何在 RTC 异步 chunk 场景下把「生成下一 chunk 的耗时」藏进「执行当前 chunk 的时间」里,消除 chunk 边界停顿。
- 阅读姿势:盯住一条主线——「运行时的一切设计,都是为了让加速单元在 batch≈1 的低延迟约束下永不空等」。云端 serving 靠堆 batch 提吞吐,而具身端侧只有一个请求、一个本体、一条实时控制回路;运行时能做的不是「攒批」,而是用异步异构掩盖设备间等待、用 KV-cache 消除重复计算、用双缓冲掩盖 chunk 边界、用编译态静态图消除调度抖动——四把武器都指向同一个敌人:延迟的不确定性。
1. 范围与目标
运行时负责把编译产物(.vmfb 类)在芯片上加载、调度、执行:内存管理、异构(NPU+CPU+DSP+ISP)调度、多模型并发、与 Driver/HAL 对接。实时确定性保证见 13 章。
核心问题
- 业界主流运行时有哪些?各大厂用什么?复用哪种(IREE / ONNX Runtime / TVM / 厂商式自研…)还是自研?
- 异构多设备如何异步并发调度(不让设备轮流等待)?
- 内存如何管理(统一内存/零拷贝/KV-cache)?
- 多模型并发与端侧极小 footprint 如何兼顾?
- 具身特有的 chunk 执行语义(π0 流匹配、RTC 异步)对运行时执行循环提出哪些超出通用推理的诉求?
2. 需求洞察(承接上游)
- batch≈1 低延迟(01)⇒ 低调度开销、流水化执行。
- 多频率并发(01:认知/感知/控制)⇒ 异构设备异步并发(NPU 算时 CPU/DSP 不空等)。
- 统一内存 + 零拷贝(04)⇒ NPU↔CPU 数据免拷贝(VLA 前后处理)。
- 软件管理内存 + 显式 DMA + 弱序同步(08)⇒ 运行时与编译器协同编排,而非依赖硬件 cache 一致。
- KV-cache/动态 shape/多模型(03)⇒ 灵活内存分配 + 隔离。
- 端侧 footprint 小、可离线(01)⇒ AOT、轻量运行时、可裁剪。
- 确定性(→13)⇒ 运行时须支持优先级/抢占接口。
- chunk 语义 + 双缓冲(21/RTC)⇒ 运行时执行循环须能「执行当前 chunk 的同时生成下一 chunk」,把生成延迟藏进执行窗口。
3. 技术现状与趋势(点名 + 来源)
3.1 业界主流运行时方案与各厂选型(全景)
| 类别 | 代表 | 定位 | 各厂/落地 |
|---|---|---|---|
| 编译器+运行时(MLIR) | IREE | AOT 编译 + HAL/VM 运行时,端到中心,30KB | LF AI 项目;AMD MLPerf SDXL |
| 自动调优编译+运行时 | TVM(Graph Executor/VM/AOT) | 自动调优 + BYOC 接入加速器 | 多家国产/嵌入式 BYOC |
| 跨平台运行时 + EP | ONNX Runtime(ORT) | 图执行 + Execution Provider 插件 | EP 生态:TensorRT EP、华为 CANN EP、QNN EP… |
| 厂商专用运行时 | NVIDIA TensorRT / TensorRT-LLM(C++,Jetson/DRIVE) | 厂商深度优化 + 引擎编译 | 机器人/车端事实标准(Jetson/DRIVE Thor) |
| 华为 CANN(ACL + GE 图引擎 + Runtime + TBE) | 昇腾全栈运行时 | 昇腾设备;Ascend CL(ACL)接口 | |
| Qualcomm QNN(AI Engine Direct) | Snapdragon NPU 运行时 | 移动/机器人;配 LiteRT | |
| 边缘/端侧引擎 | LiteRT(原 TFLite)/ ExecuTorch / TFLite-Micro / MNN / NCNN / llama.cpp | 极小 footprint 端侧推理 | 手机/IoT/MCU;ExecuTorch=PyTorch 原生端侧(多模态、XNNPACK/Vulkan/CoreML/NPU 后端) |
| 数据中心 serving | vLLM / SGLang / Triton / Dynamo | 高吞吐 多请求服务(KV-aware) | 云端(非端侧) |
关键观察:
- 没有任何现成厂商运行时适配一颗全新 DSA——TensorRT/CANN/QNN 均绑定各自硬件;故新芯片厂商要么自研运行时(如华为 CANN、NVIDIA TensorRT 路线),要么复用可重定向框架(IREE/TVM/ORT-EP)并补硬件后端。
- 运行时与编译器强耦合:ORT/TVM/IREE 各自配套编译路径;选运行时须与 15/16 章编译栈一致(我们是 MLIR/IREE 路线)。
- 机器人/车端事实标准是 NVIDIA TensorRT / TensorRT-LLM,但其封闭绑 NVIDIA;开放可重定向路线以 IREE/TVM/ORT 为主。
命名勘误:早期资料曾把 Jetson/DRIVE 上的边缘 LLM 推理栈称作「TensorRT Edge-LLM」,该命名未见 NVIDIA 官方 datasheet 一致背书;本章统一按官方口径写作 TensorRT-LLM(数据中心与边缘同名产品线),避免以讹传讹。以官方最新命名为准。
3.2 候选运行时框架对比(面向我们自研 DSA)
| 候选 | 与 MLIR 编译栈契合 | 异步异构 | 端侧 footprint | 实时可扩展 | 生态/前端 | 自研工作量 | 小结 |
|---|---|---|---|---|---|---|---|
| A. IREE + 自定义 HAL | 5 | 5 | 5(30KB) | 3(需扩展) | 4(PyTorch/ONNX/StableHLO) | 3 | 与 15/16 同源、可裁剪、HAL 外部驱动 |
| B. ONNX Runtime + 自定义 EP | 2 | 3 | 3 | 2 | 5(ONNX 生态) | 3 | 生态好但图执行式、与 MLIR codegen 不同源 |
| C. TVM + BYOC | 3 | 3 | 4 | 2 | 3 | 3 | 自动调优强,但与 IREE 路线分叉 |
| D. 完全自研(类 CANN/TensorRT) | 4 | 4 | 4 | 5(可定制) | 1 | 5 | 控制力最强但人力/风险最大 |
IREE 三层(HAL 设备抽象 + 运行时后端 + VM 字节码调度;
IREE_EXTERNAL_HAL_DRIVERS外部驱动;调度与执行一起编译、30KB 嵌入式)与我们 MLIR 编译栈(15/16)同源,是契合度最高项;ORT-EP/TVM 的价值在生态前端,可作补充适配层;纯自研控制力最强但成本最高。
3.2a IREE 三层如何落到自研 DSA(新增)
理解 IREE 为什么是主线候选,最直接的方式是把它的三层拆开,看编译产物 .vmfb 在运行时是怎么一步步走到 DSA 硬件上的。
读这张图的要点:编译态把「哪个算子在哪个设备上、按什么顺序、数据怎么搬」全部静态固化进 .vmfb;运行态的 VM 只是「照本宣科」地按字节码发射 command buffer,HAL 把它翻译成设备无关的提交/同步原语,最后由外部 DSA 驱动(我们唯一需要重写的一层)下发到硬件。这解释了两件事:一是为什么 footprint 能压到 30KB(运行时不含编译器、不做 autotune);二是为什么「与 MLIR 同源」是决定性的——DSA Dialect 里表达的 flow_step(流匹配循环)、显式 DMA 语义,从编译态一路直达运行态,中间不需要再翻译一次。
3.3 异步异构执行(端侧 SoC 关键能力,任何候选都需具备)
- IREE/Roofline 在边缘 SoC(NXP/Apple/Qualcomm)验证异步跨设备执行:调度线程 + 计算线程、非阻塞提交、frontier 同步、共享内存零拷贝 + 模型分区异步边界 → CPU/GPU/NPU 并行而非轮流。
- TensorRT-LLM 等厂商运行时则在自家硬件上做 prefill/decode + CUDA graph 优化。
- 判断:异步异构 + 零拷贝是端侧多频率并发的硬性能力,选型时作为必备项评估。
3.4 内存与多模型(任何候选都需具备)
- 统一内存零拷贝(04)+ 编译期 buffer 放置规划;KV-cache 分页(03);多模型并发 + 隔离。
- 判断:运行时内存管理与编译器(15/16)协同;KV/动态 shape 走轻量分页 + 硬件辅助 DMA(03/08)。
3.5 KV-cache 与前缀复用:π0 chunk 的延迟命门(新增)
具身端侧 batch≈1,吞吐不是问题,单次 chunk 延迟才是。π0 类模型的部署结构是「VLM 编码一段固定前缀(图像 + 指令 token)→ 动作专家在这段前缀之上跑多步流匹配/去噪」。若每一步都把整段前缀重新过一遍 attention,前缀就被算了 N 次——这正是 KV-cache 要消灭的浪费。
为什么这对 DSA 运行时是硬约束:KV-cache 不是「有更好、没有也行」的优化,而是把 π0 chunk 延迟从 O(N × 全序列) 拉回 O(prefill + N × suffix) 的数量级差。运行时侧必须提供:① KV-cache 的分页内存分配(03 章,长上下文时避免整块预留);② 前 缀 buffer 在多步循环中驻留不释放(靠编译期 buffer 放置规划锁定);③ 与显式 DMA 协同,把前缀 KV 留在片上 SRAM 而非反复搬进搬出 HBM。这条链路任何一环缺失,chunk 延迟都会退化回「无 cache」形态。具体的延迟账在 §深入思考·思考题 2 里算一遍。
3.6 双缓冲与 RTC 异步 chunk(新增)
π0 的 Real-Time Chunking(RTC)是 2026 流匹配部署的事实标准:执行当前动作 chunk 的同时,后台生成下一个 chunk,靠 inpainting 拼接边界。对运行时而言,这直接翻译成一个经典的**双缓冲(double buffering)**执行循环——两块 chunk buffer 轮流扮演「正在执行」和「正在生成」的角色。
双缓冲掩盖了什么:朴素单缓冲的时间线是「生成 chunk → 执行 chunk → 停顿等生成下一个 → 再执行」,chunk 边界处出现一段控制回路的空窗(机器人动作卡顿)。双缓冲把「生成下一 chunk 的耗时」完全藏进「执行当前 chunk 的时间窗」里——只要单 chunk 的执行时长(例如 50Hz × H=50 步 ≈ 1 秒动作)大于单 chunk 的生成延迟(chunk 延迟 ~76–100ms),生成就永远赶得上执行,边界零停顿。运行时的责任是提供两块隔离的 chunk buffer + 一个非阻塞的后台生成提交路径(对接 3.3 的调度/计算线程分离),并配合 inpainting 处理新旧 chunk 的重叠段。掩盖机制的时间账见 §深入思考·思考题 3。
3b. 由演进反推的诉求(定性)
| 维度 | 当前 | 未来(多模型/长上下文) | 运行时含义 |
|---|---|---|---|
| 并发 | 认知+感知+控制 | 更多任务 | 异步异构 + 优先级(13) |
| 内存 | 统一/零拷贝/KV | 长上下文 KV 膨胀 | 分页 KV + 显式 DMA |
| footprint | 端侧轻量 | 多设备形态 | 可裁剪 + 外部 HAL |
| 部署 | AOT .vmfb | 端云协同(24) | 一致运行时跨端边中心 |
| chunk 执行 | 同步 chunk | RTC 异步 chunk | 双缓冲 + 非阻塞后台生成 |
4. 候选方案与对比矩阵
候选与多维对比见 3.2。综合"与 MLIR 编译栈契合 × 异步异构 × footprint × 实时可扩展 × 生态 × 工作量":
- 建议方向:以 A(IREE + 自定义 DSA HAL 驱动)为主线候选——与 15/16 章 MLIR 编译栈同源、异步异构成熟、30KB 可裁剪、HAL 外部驱动机制清晰;叠加 ONNX/框架前端适配层(借鉴 ORT-EP 思路补生态);硬实时关键路径评估"thin 静态调度运行时"(13 章),不依赖 VM 解释开销。
- 保留再评估:若实时确定性对 VM 开销不可接受,或生态优先级高于编译同源,则 D(自研)/B(ORT-EP)权重上升——待 13 章实时分析与基 线模型 profiling 后定。
5. 关键权衡、风险与依赖
- 复用 vs 实时定制:IREE 异步调度面向吞吐/通用,硬实时确定性需扩展(优先级/抢占/静态调度,13 章)——这是与通用运行时最大的 gap。
- DSA HAL 驱动是关键工作量:对接 08 章同步/显式 DMA 语义 + 09 章 Driver。
- footprint vs 功能:端侧裁剪 vs 多模型/动态——分档构建配置。
- 编译态静态图 vs eager 的确定性取舍:AOT 把调度序列固化进
.vmfb,消除逐算子的 Python/解释开销与调度抖动 → 延迟低且方差小(硬实时友好);eager 逐算子解释灵活但每步都有调度决策,延迟抖动大。具身控制回路要 p99 而非均值,故走 AOT——量化见 §深入思考·思考题 1。 - 依赖:13(实时)、09(Driver)、08(同步语义)、15/16(编译产物)、03/04(内存)。
6. 结论与待决项
初步结论
- 主线候选:IREE + 自定义 DSA HAL 驱动(与 MLIR 编译栈同源、可裁剪、HAL 外部驱动);叠加 ONNX/框架前端适配补生态;纯自研(类 CANN/TensorRT)作为高控制力备选。论证见 3.1–3.2。
- 任何候选都须具备:异步异构调度(调度/计算线程 + 非阻塞提交 + frontier 同步)实现 NPU/CPU/DSP 并发。
- 统一内存零拷贝 + 编译期 buffer 规划 + KV 分页;与编译器协同。
- AOT + 轻量可裁剪;为 13 章实时扩展预留优先级/抢占接口(硬实时路径或走 thin 静态调度运行时)。
- chunk 执行循环内置双缓冲 + 非阻塞后台生成,支撑 π0 RTC 异步 chunk(21 章 ADR-047 联动)。
待决项
- IREE VM 解释开销在硬实时路径是否可接受 vs 关键路径走静态预编译(与 13 联合)。
- DSA HAL 驱动抽象边界(与 08/09 联合)。
- 多模型内存隔离粒度(与 13/03 联合)。
- 双缓冲放 runtime 内置 vs 应用层库(与 21 章 RTC 待决项联合)。
ADR 候选
- ADR-034 运行时框架:主线候选 IREE + 自定义 DSA HAL 驱动(与 MLIR 编译栈同源)+ ONNX/框架前端适配;备选纯自研(类 CANN/TensorRT);依 13 章实时分析与 profiling 终选。
- ADR-035 异构调度:异步异构(非阻塞提交 + frontier 同步 + 调度/计算线程分离)。
- ADR-036 内存管理:统一内存零拷贝 + 编译期 buffer 规 划 + KV 分页 + 显式 DMA。
- ADR-037 多模型/footprint:VM 多模型并发 + 分档可裁剪 + AOT。
7. 端→边→中心演进影响
- 同一 IREE 运行时 + DSA HAL 跨端/边/中心一致(VM + 外部 HAL);差异在并发规模与多租户(中心)。
- 不可逆点:HAL/同步接口随 08/09 冻结,预留扩展。
深入思考
下面三题每题先给题干,再用
<details>折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。
思考题 1:编译态静态图 vs eager 对确定性延迟的影响
同一个 π0 动作专家的 5 步流匹配循环,一种跑在 PyTorch eager(逐算子 Python 解释 + 逐个下发 kernel),另一种走 IREE AOT 编译成 .vmfb(调度序列静态固化)。结合 3.2a 的 IREE 三层 与 5 节的确定性取舍,解释为什么控制回路必须选 AOT,并算一遍两者的调度开销差与延迟方差差异。
展开参考答案(含 eager vs AOT 延迟构成图 + 算一遍)
结论:eager 每执行一个算子都要回到宿主端做一次调度决策与下发,这些开销既叠加进延迟均值,又因宿主端抖动放大 p99;AOT 把整条调度序列离线固化进字节码,运行时只按序发射,单步调度开销压到接近零、方差也随之收敛——具身控制回路要的是稳定的 p99 而非好看的均值,所以走 AOT。
用具体数字算一遍(数量级估算,单 chunk 5 步流匹配、每步约 40 个算子):
- 算子总数:5 步 × 40 算子/步 = 200 个算子发射。
- eager 单算子宿主开销:Python 派发 + kernel launch + 同步,保守取 ~10μs/算子(端侧宿主更慢,常达数十 μs)。总调度开销 ≈ 200 × 10μs = 2ms。
- AOT 单算子发射开销:VM 按字节码顺序发射 command buffer,无 Python、无逐算子同步决策,取 ~0.5μs/算子。总开销 ≈ 200 × 0.5μs = 0.1ms。
- 均值差:仅调度这一项,eager 比 AOT 多 ~1.9ms——对一个目标 76–100ms 的 chunk 已是 2%~2.5% 的净损耗,且这还只是均值。
- 方差差才是关键:eager 的每次宿主往返都暴露给操作系统调度抖动(GC、线程切换、其他进程),200 次往返的抖动逐次叠加,p99 相对均值可能上浮 20%~50%;AOT 只在「加载 + 发射」两点接触宿主,抖动源从 200 个塌缩到 ~2 个,p99 贴近均值。
为什么控制回路只认 p99:机器人 伺服按固定频率(如 50Hz,20ms 一拍)取用动作,一旦某个 chunk 延迟 p99 击穿预算,就是一次动作卡顿或丢拍——用户体感是「手抖了一下」。均值再漂亮也救不了偶发的长尾。所以 12 章主线候选虽以 IREE VM 为基础,但硬实时关键路径明确保留「thin 静态调度运行时」选项(见 5 节与待决项),就是要把 eager 式的逐步解释开销从关键路径上彻底摘掉。回到 3.2a:AOT 的确定性红利,本质来自「调度决策在编译态一次性做完、运行态不再重做」。
思考题 2:KV-cache / 前缀复用如何降低 π0 chunk 延迟
π0 部署为「VLM 编码固定前缀 → 动作专家在前缀之上跑多步 suffix 迭代」。结合 3.5 节的前缀 KV-cache 机制,论证为什么没有 KV-cache 时 chunk 延迟会随步数线性恶化,并算一遍:已知 prefill 一次约 46ms、单步 suffix 增量约 6ms、共 5 步,对比有无 KV-cache 的 chunk 总延迟。
展开参考答案(含有无 cache 延迟构成图 + 算一遍)
结论:前缀是 chunk 里最贵的一段(prefill 46ms),多步迭代真正变化的只是很短的 suffix;KV-cache 把前缀的 attention 结果算一次就锁在片上复用,让每一步只付 suffix 的增量成本——于是 chunk 延迟从「N × 全序列」塌缩成「一次 prefill + N × suffix」,这是数量级而非百分比的差异。
用具体数字算一遍(对齐 21 章 π0@4090 公开 profiling:prefill 46ms、5 步去噪 ~30ms):
- 无 KV-cache:每一步流匹配都要把「前缀 + suffix」整段重新过一遍 attention。单步 ≈ prefill 全量 46ms + suffix 6ms = 52ms。5 步 = 5 × 52ms = 260ms。chunk 延迟随步数线性膨胀,且前缀越长(高分辨率图像 token 多)恶化越猛。
- 有前缀 KV-cache:前缀只在第一步 prefill 一次(46ms),其 K/V 写入 cache 并驻留片上;此后每一步只对短 suffix 做增量 attention(读复用前缀 KV),单步仅 ~6ms。总 = prefill 46ms + 5 × 6ms = 46 + 30 = 76ms。
- 收益:260ms → 76ms,约 3.4× 加速;而这恰好把 chunk 延迟从「远超 100ms SLO」拉回「≤100ms 候选靶标」以内(对标 GR00T Thor 92ms)。
- 步数敏感性:无 cache 下每加一步 +52ms,有 cache 下每加一步仅 +6ms——KV-cache 让「加步数换精度」的边际成本降了近一个数量级,这也是为什么减步(OneDP/OFP 1-NFE)与 KV-cache 是两条互补而非互斥的优化路径。
运行时侧的落地要求(呼应 3.5):① 前缀 buffer 在多步 flow_step 循环中锁定驻留、不被内存分配器回收(靠 15/16 章编译期 buffer 放置规划标注生命周期);② KV 走分页分配(03 章),长上下文时避免一次性预留整块;③ 配合显式 DMA(08 章)把前缀 KV 留在片上 SRAM,避免每步从 HBM 反复搬运——否则「省了计算却赔了带宽」,退化回无 cache 形态。这条链路是 ADR-036(内存管理)把「KV 分页」列为核心能力的直接动因。
思考题 3:双缓冲如何掩盖 chunk 边界
π0 RTC 要求「执行当前 chunk 的同时生成下一 chunk」。结合 3.6 节的双缓冲执行循环,分析朴素单缓冲为什么会在 chunk 边界产生控制回路空窗,并算一遍:在单 chunk 执行时长 1000ms、单 chunk 生成延迟 76ms 的条件下,双缓冲能否做到边界零停顿?若生成延迟涨到 1200ms 又会怎样?
展开参考答案(含单缓冲 vs 双缓冲时间线图 + 算一遍)
结论:双缓冲用两块隔离 buffer 让「生成」与「执行」在时间轴上并行——只要单 chunk 的执行时长大于单 chunk 的生成延迟,生成就永远在执行播完之前备好下一块,chunk 边界零停顿;一旦生成延迟反超执行时长,双缓冲也救不了,边界必然出现空窗,此时只能靠减步/量化把生成延迟压回执行时长以下。
用具体数字算一遍:
- 场景参数:单 chunk = H=50 步动作 @ 50Hz 控制频率 → 执行时长 = 50 / 50Hz = 1000ms;单 chunk 生成延迟(含 KV-cache,见思考题 2)= 76ms。
- 单缓冲时间线:生成(76ms)→ 执行(1000ms)→ 停顿等下一 chunk 生成(76ms) → 执行……每个 chunk 边界都插入一段 76ms 的控制回路空窗,50Hz 下相当于丢约 3–4 拍,机器人动作可见卡顿。
- 双缓冲时间线:执行 chunk0 的 1000ms 窗口里,后台在另一块 buffer 上生成 chunk1 只需 76ms,用掉窗口的 7.6%,还剩 924ms 富余。chunk0 播完时 chunk1 早已就绪 → 无缝切换,边界停顿 = 0。
- 临界条件:双缓冲有效的充要条件是 生成延迟 ≤ 执行时长。本例 76ms ≪ 1000ms,余量极大。
- 反例(生成延迟涨到 1200ms):执行 chunk0 只有 1000ms,而生成 chunk1 要 1200ms → chunk0 播完时 chunk1 还差 200ms 没好 → 每个边界仍有 ~200ms 空窗,双缓冲失效。此时唯一出路是把生成延迟压回 1000ms 以下:减步(OneDP/OFP 单步化)、更激进量化(INT4)、或把前缀 KV 更好地驻留片上——双缓冲只掩盖「生成 ≤ 执行」的差,掩盖不了「生成 > 执行」的赤字。
运行时侧的落地要求(呼应 3.6):① 两块隔离的 chunk buffer 轮流扮演「执行 / 生成」角色;② 后台生成走非阻塞提交(对接 3.3 调度/计算线程分离),不阻塞伺服下发线程;③ 新旧 chunk 重叠段用 inpainting 平滑拼接(RTC 语义,21 章 ADR-047)。这正是 6 节把「双缓冲放 runtime 内置 vs 应用层库」列为待决项、并与 21 章 RTC 待决项联合的原因——它横跨运行时执行循环与模型部署模式两层。
附:信息来源
区分公开/估计;参考时间 2026-06。
- IREE 运行时:iree.dev、iree-org/iree C-API 文档(HAL/VM/驱动三层、command buffer、VM 多设备调度、30KB);Deployment configurations(HAL 驱动/设备、
IREE_EXTERNAL_HAL_DRIVERS)。[公开] - 异步异构边缘执行:Roofline 案例《Asynchronous Heterogeneous Execution for Edge SoCs》《Vulkan 1.3 HAL for IREE》(调度/计算线程、非阻塞提交、frontier 同步、共享内存零拷贝、模型分区异步边界、NXP/Apple/Qualcomm 验证)。[公开 + 媒体]
- 业界运行时方案与各厂选型(3.1–3.2):MDPI《Comparative Analysis of Modern Acceleration Frameworks》(Jetson Orin 上 PyTorch/ORT/TensorRT/TVM/JAX 对比)、ONNX/TensorRT/TFLite 选型博客;NVIDIA TensorRT / TensorRT-LLM(Jetson/DRIVE Thor,机器人/车端 C++ 运行时);华为 CANN(ACL + GE + Runtime + TBE;ONNX Runtime CANN EP);Qualcomm QNN + LiteRT;ExecuTorch 1.0(PyTorch 原生端侧);LiteRT/MNN/NCNN/llama.cpp;vLLM/SGLang/Triton/Dynamo。[公开 + 媒体]
- π0 chunk 延迟 profiling(prefill 46ms、5 步去噪 ~30ms、chunk ~76ms@4090;RTC 异步 chunk):Physical Intelligence, arXiv:2410.24164, arXiv:2506.07339;pi.website。[公开]
- KV-cache / 前缀复用 / 双缓冲延迟账:基于上述 π0 公开 profiling 的工程估算。[估计]
- 运行时取舍:基于上述公开资料的工程判断。[估计]