具身智能术语表
- 适用范围：本系列技术洞察文档
- 维护约定：新章引入的具身/机器人/模型/部署专有名词须在本表登记
本表按模型与算法 → 压缩与优化 → 部署与运行时 → 系统与中间件 → 硬件与芯片 → 评测与数据组织。解释面向 AI Infra 技术选型读者，非纯学术定义。
学习目标
- 前置知识：读过 00 层导览与 01 章负载画像（知道「具身智能 = 感知-行动闭环 + 硬实时约束」）；对 Transformer / 量化 / 编译器有基本概念即可。无需机器人学或控制理论背景——本表的职责就是把跨章节冒出来的黑话拉平，让你带着一份「随手可查的锚点」读后续技术章。
- 学完产出：① 能在 VLA / VLM / ER / 动作专家 / 双系统 / 三系统之间不打架地区分，知道哪个是「认知」哪个是「动作头」；② 能说清扩散策略、流匹配、一致性策略、单步策略（OneDP/OFP）在去噪步数—延迟这条轴上的位置，理解「减步」与「量化」为何正交；③ 能区分硬实时 / 软实时 / 准实时 / WCET / jitter，并说出各自在具身栈里落在哪个频率带、由谁（安全岛 / RTOS / NPU）承担；④ 能不混淆 TOPS / TFLOPS、稀疏 / 稠密、bit / byte，读芯片 datasheet 时不被口径忽悠。
- 阅读姿势：把本表当作全站术语锚点——它不是让你一次读完的散文，而是一部字典。建议先扫一遍分类图（下一节 mermaid）建立心智地图，遇到具体章节的陌生词再回本表精查。盯住一条主线：具身术语的所有区分，最终都服务于「在有限端侧算力/功耗下，把一个多模态大模型压进硬实时的控制回路」这一个工程命题。凡是新章引入的专名，都应先回本表登记再展开，避免同一个概念在不同章各叫各的名。
术语全景：六大分类如何咬合成一条具身推理链
下图把本表六大分类还原成一条从模型到硬件的落地链路——先看清楚它们如何咬合，再逐表精读会轻松很多：
读图要点：这是一条单向落地 + 指标反推的闭环。模型（1）太大跑不动 → 压缩（2）；压好了要有 runtime 承接（3）；runtime 要嵌进实时回路（4）；回路跑在具体芯片上（5）；最后用评测（6）量化好坏，再把「不达标」反推回模型/压缩层。本表的每一行术语，都能在这张图上找到它的位置。
1. 模型与算法(Model & Algorithm)
| 中文 | English | 解释 |
|---|---|---|
| 具身智能 | Embodied AI / Embodied Intelligence | 智能体拥有物理本体(机器人)，通过感知-行动闭环与环境交互；负载含 VLA、扩散策略、分层控制等，对延迟/确定性/能效有硬约束。 |
| 视觉-语言-动作模型 | Vision-Language-Action (VLA) | 统一处理图像/语言指令并输出机器人动作的策略模型；代表 OpenVLA、π0、GR00T、Gemini Robotics。动作可为离散 token 或连续向量/轨迹。 |
| 视觉-语言模型 | Vision-Language Model (VLM) | 多模态理解模型(图像+文本)，不直接输出低层动作；在具身栈中作"认知/任务规划"层(System 2)。常与独立动作头组合。 |
| 具身推理 | Embodied Reasoning (ER) | Google Gemini Robotics 提出的规划/推理模型，与 VLA 执行模型分工："先想再做"；负责工具调用、子目标分解，非 1kHz 控制。 |
| 扩散策略 | Diffusion Policy | 用扩散模型生成连续动作序列的策略；Columbia/MIT 2023 代表作；需多步去噪，端侧靠减步(DDIM/一致性蒸馏)压缩延迟。 |
| 流匹配 | Flow Matching | 连续归一化流的一种训练/采样范式；π0 动作头采用流匹配 + Euler 积分；较扩散可更少步数(如 5 步)达到相近质量。 |
| 动作分块 | Action Chunking | 一次推理输出未来 H 步动作(如 H=50)，执行期间可异步生成下一块(RTC)；降低有效策略频率需求，提高控制平滑性。 |
| 实时分块 | Real-Time Chunking (RTC) | Physical Intelligence 提出的异步执行方案：执行当前 action chunk 同时生成下一 chunk，用 inpainting 衔接；容忍 +200ms 注入延迟。 |
| 训练期 RTC | Training-Time RTC | 在训练阶段加入 action prefix / delay conditioning，消除推理期 inpainting 开销；H100 上约 108ms vs 135ms。 |
| 离散动作 token | Discrete Action Tokens | 将连续关节/末端动作量化为 bin(如 256-bin)，用自回归 LM 预测；OpenVLA 路线；prefill 重、decode 串行。 |
| 跨本体 | Cross-Embodiment | 同一策略适配不同机器人(关节数/动作维度不同)；π0 等通过 state/action padding 与条件化实现；编译器须支持动态 shape 子集。 |
| 双系统架构 | Dual-System Architecture | 低频大模型(VLM) + 高频动作头(DiT/扩散/小 Transformer)流水线；GR00T N1.5/N1.7、Gemini VLA+ER 均属此类。 |
| 三系统架构 | Triple-System Architecture | Figure Helix 02：S2 认知 VLM(7–9Hz) + S1 视觉运动(200Hz) + S0 运动先验(1kHz，~10M 参数)；模型分级即系统级压缩。以官方为准。 |
| 扩散 Transformer | Diffusion Transformer (DiT) | 用 Transformer 骨干做扩散/流匹配动作头；GR00T System 1、部分 VLA 动作专家采用；可独立 TensorRT/AOT 编译。 |
| 动作专家 | Action Expert | π0 中与 VLM 共享前缀、专责动作生成的 ~300M 子网络；多步流匹配在 suffix 上迭代，VLM 前缀可 KV-cache。 |
| 一致性策略 | Consistency Policy | 将扩散策略蒸馏为少步/单步一致性模型；~10× 推理加速；小策略网(ACT/Diffusion Policy)常用。 |
| 单步扩散策略 | One-Step Diffusion Policy (OneDP) | NVIDIA Research：Diffusion Policy → 单步 KL 蒸馏；1.5Hz→62Hz；动作头可编译为单次前向。 |
| 单步流策略 | One-Step Flow Policy (OFP) | 从零训练的自蒸馏流匹配，1-NFE 超 100 步 baseline；硬件只需优化单次前向。 |
| 混合一致性策略 | Hybrid Consistency Policy (HCP) | 短 SDE 随机前缀 + 单步 consistency jump；平衡多模态与实时性。 |
| 动作分块 Transformer | Action Chunking with Transformers (ACT) | ~80M CVAE+Transformer baseline；输出 action chunk；常作具身实验对照组。 |
| Octo | Octo | 27–93M 模块化 Transformer 策略；开源研究友好；小模型 baseline。 |
| 世界模型 | World Model | 学习环境动力学/未来状态的模型(常含 3D/视频 attention)；扩展阶段+ 算子；端侧部署算力/带宽压力大于当前 VLA。 |
| 投机解码 | Speculative Decoding | 小模型 draft + 大模型 verify，加速 AR decode；TensorRT Edge-LLM EAGLE-3；VLA 离散 token 路线可用。 |
| 前缀缓存 | Prefix Caching / KV-cache | VLM 对固定视觉+语言前缀的 K/V 张量缓存，避免每步重算；π0/OpenVLA prefill 优化的核心。 |
2026-07 时效补注（以官方为准）：本表模型族以 2026 年中公开信息为准——Physical Intelligence 已迭代至 π0.7（流匹配动作头，5B 级）；NVIDIA GR00T N1.7 已 GA（双系统 VLM+DiT，Isaac 栈）；Figure Helix 02 三层（S2/S1/S0） 为官方口径。具体参数/频率随版本演进，以厂商 datasheet 与官方博客为最终依据。
2. 压缩与优化(Compression & Optimization)
| 中文 | English | 解释 |
|---|---|---|
| 训练后量化 | Post-Training Quantization (PTQ) | 训练完成后用校准集确定 scale/zero-point；OpenVLA NF4、GR00T nvfp4 量产主路径；快速但具身须用 rollout 验收。 |
| 量化感知训练 | Quantization-Aware Training (QAT) | 训练期模拟量化误差；精度优于 PTQ 但成本高；用于旗舰任务或 PTQ 不达标时 LoRA+QAT 补精度。 |
| 非对称量化 | Asymmetric Quantization | 视觉塔/LLM/动作头采用不同 bit-width 与格式；如 ViT FP8 + LLM W4A8 + DiT FP16 计算；对标 GR00T Thor。 |
| 动作空间敏感量化 | Action-Centric Quantization | QVLA：按 action-space sensitivity 而非 hidden-state 误差分配 bit；通道级 16 混合。 |
| 权重量化 | Weight-Only Quantization (W4A16 等) | 仅压缩权重，激活 FP16/BF16；OpenVLA NF4；算力瓶颈在激活/访存时仍有效。 |
| 激活量化 | Activation Quantization (W4A8/W8A8) | 权重与激活均低比特；需硬件 MAC 与 scale 单元支持；FP8/NVFP4 为 Blackwell 端侧标杆。 |
| NVFP4 | NVFP4 (NVIDIA FP4) | Blackwell 16 值块缩放 FP4 格式；Jetson Thor GR00T LLM 采用；较 INT4 AWQ 约 1.1–2.3× 吞吐(公开 benchmark)。 |
| AWQ | Activation-aware Weight Quantization | 权重量化 PTQ 方法；Orin 时代 INT4 主流；与 NVFP4 在 Thor 上并存。 |
| GPTQ / NF4 | GPTQ / NF4 (NormalFloat4) | LLM 社区 PTQ；OpenVLA 默认 NF4(bitsandbytes)；非芯片专用 layout。 |
| 知识蒸馏 | Knowledge Distillation | 大模型(teacher)→小模型(student)；OneDP/OFP/Helix 模型分级均属广义的系统级或步数蒸馏。 |
| 步数蒸馏 / 减步 | Step Distillation / NFE Reduction | 扩散/流匹配从 100→10→5→1 步；与权重量化正交；π0 10→5 步、GR00T DiT 4 步为实例。 |
| 函数评估次数 | Number of Function Evaluations (NFE) | 扩散/流匹配单条轨迹所需前向次数；1-NFE = 单步策略，极大简化 runtime loop。 |
| 结构化稀疏 | Structured Sparsity (2:4) | 每 4 权重留 2 非零；NVIDIA 稀疏 FP4 需硬件支持；具身量产验证不足，端侧基线阶段不依赖。 |
| 剪枝 | Pruning | 移除权重/通道；QVLA 将 0-bit 与量化统一；非结构化剪枝具身验证少。 |
| 神经架构搜索 | Neural Architecture Search (NAS) | 自动搜索网络结构；中心/边缘吞吐场景有研究，端侧具身基线阶段以已知 VLA 架构 + PTQ/减步为主，NAS 作 规模化阶段前瞻。 |
| 低秩适配 | Low-Rank Adaptation (LoRA) | 冻结主权重、训 练低秩增量；OpenVLA 任务微调标准做法；与 INT4 PTQ 叠加。 |
| 校准集 | Calibration Dataset | PTQ 确定 scale 的样本集(通常 512–1024 帧/轨迹)；须覆盖目标场景，支持端侧 recalibration。 |
| 块缩放 | Block Scaling | NVFP4/INT4 按块(如 16 值)共享 scale；硬件须原生支持，否则 dequant 开销抵消收益。 |
3. 部署与运行时(Deployment & Runtime)
| 中文 | English | 解释 |
|---|---|---|
| 预填充 | Prefill | AR/VLM 对整段输入(图像 token+语言)的一次性前向，计算密集；π0 prefill ~46ms@4090。 |
| 解码 | Decode | 自回归逐 token 或动作步生成；OpenVLA 瓶颈之一；KV-cache 优化主要针对 decode 阶段。 |
| KV 缓存 | KV-cache | 存储 attention 的 Key/Value 避免重复计算；VLA 长上下文与多步推理的内存/带宽热点。 |
| 分块双缓冲 | Chunk Double-Buffering | RTC 运行时同时持有"执行中 chunk"与"生成中 chunk"；IREE/runtime 须扩展异步调度。 |
| 提前编译 | Ahead-of-Time (AOT) | 编译期固定图/调度，产物如 IREE .vmfb、TensorRT engine；端侧量产首选，对比 eager PyTorch。 |
| 即时执行 | Eager Execution | PyTorch 动态逐 op 执行；开发/仿真用；GR00T Thor eager ~117ms vs TRT ~92ms。 |
| 模型清单 | Model Manifest | 描述 model_family、quant、action_dim、embodiment 的 YAML/JSON；LeRobot 与国内 demo 的事实 SSOT 接口。 |
| LeRobot | LeRobot (HuggingFace) | 开源机器人 ML 栈(数据/训练/推理)；π0/OpenVLA/ACT 统一入口；SDK 应对齐 manifest。 |
| 零拷贝 | Zero-Copy | 传感器→NPU 不经 CPU bounce buffer；dmabuf + IREE HAL import；可省 5–15ms。 |
| 动态形状 | Dynamic Shape | action_dim/state_dim 随机器人变化；编译器采用 max dim + padding 等受限多态。 |
| 多虚拟机 | Multi-VM | 单 runtime 加载多模型(VLM+DiT+ER)；IREE multi-module；Gemini/GR00T 双模型编排基础。 |
| 流匹配步原语 | Flow Step Primitive | 编译器 IR 中对扩散/流匹配迭代 loop 的语义节点(如 dsa.flow_step)；便于 loop fusion 与 1-NFE 分支。 |
| 最坏执行时间 | Worst-Case Execution Time (WCET) | 一段代码/kernel 在最坏输入与硬件竞争下的执行时间上界；硬实时可调度性分析的输入，须可静态/测量界定而非平均值。 |
| 抖动 | Jitter | 同一任务多次执行的延迟波动幅度（如 p50 与 p999 之差）；控制回路怕 jitter 甚于怕高均值——它破坏时间确定性。 |
4. 系统与中间件(System & Middleware)
| 中文 | English | 解释 |
|---|---|---|
| 机器人操作系统 2 | Robot Operating System 2 (ROS 2) | 具身中间件事实标准；DDS 通信、ros2_control 执行器接口；认知层可用，1kHz 硬实时不宜经 DDS。当前发行版如 Jazzy Jalisco / Kilted Kaiju（以官方为准）。 |
| ros2_control | ros2_control | ROS 2 统一硬件抽象层；对接 EtherCAT/关节驱动；模型输出 action → 轨迹/力控接口。 |
| NITROS | NVIDIA Isaac NITROS | Isaac 零拷贝 GPU 感知管道；GXF 组件 + type adaptation；对标我们 dmabuf + IREE 感知桥。 |
| 直接内存缓冲区 | DMA-BUF (dmabuf) | Linux 跨设备共享缓冲区机制；相机 ISP→NPU 零拷贝基础。 |
| 硬实时 | Hard Real-Time | 截止期必须满足(如 1kHz 控制 p999)，错过即系统失效；通常驻 RTOS/安全岛，非 PREEMPT_RT 单独保证。 |
| 软实时 | Soft Real-Time | 平均/尾延迟有目标但可偶发超时(如 VLM 7–9Hz)，超时只降体验不致命；NPU 大模型推理层。 |
| 准实时 | Firm / Near Real-Time | 介于软硬之间(如 30–100ms VLA chunk)，偶发超时结果作废但不危险；可 RTC 补偿。 |
| 功能安全岛 | Safety Island | 独立 MCU+SRAM+IO，ASIL-D 级；1kHz 伺服/EtherCAT 主站；与 Linux 主计算域隔离。 |
| 抢占式实时 Linux | PREEMPT_RT | Linux 内核抢占补丁；适合软实时 BE 负载；不能替代 1kHz 硬控制岛。 |
| EtherCAT | EtherCAT | 工业实时以太网，≤1ms 周期；安全岛 MCU 作主站，ros2_control 对接。 |
5. 硬件与芯片(Hardware & Chip)
| 中文 | English | 解释 |
|---|---|---|
| 领域专用架构 | Domain-Specific Architecture (DSA) | 为 AI 推理定制的加速器(非通用 GPU)；本项目核心算力形态，需 MLIR 编译器托管。 |
| 每秒万亿次运算 | Tera Operations Per Second (TOPS) | 整数算力峰值指标(通常 INT8)；端侧具身更关注 TOPS/W(能效) 与小 batch 有效利用率。注意与浮点 TFLOPS 口径不同。 |
| 每秒万亿次浮点运算 | Tera Floating-Point Operations Per Second (TFLOPS) | 浮点算力峰值(FP16/BF16/FP8 等)；训练与浮点推理口径；1 TFLOPS 与 1 TOPS 不可直接互换。 |
| 能效 | TOPS/W (Energy Efficiency) | 每瓦算力；端侧核心 KPI；DRAM 访存能耗约为计算的 100–200×，片上 SRAM 复用关键。 |
| 稠密算力 | Dense Compute | 无稀疏假设的满密度乘加吞吐；实测基线，datasheet 标称的「稀疏」值通常是它的 2×。 |
| 稀疏算力 | Sparse Compute (2:4) | 依赖 2:4 结构化稀疏的标称吞吐；须权重满足稀疏模式才可达，具身量产验证不足，别拿稠密实测对标稀疏标称。 |
| 低功耗双倍数据率内存 | LPDDR5X/6 | 端侧机器人主存；容量 GB 级、带宽 ~100–300GB/s；VLA 权重与 KV 主存放处。 |
| 高带宽内存 | High Bandwidth Memory (HBM) | 边缘/中心形态；端侧具身基线采用 LPDDR，HBM 作演进选项。 |
| 片上静态存储 | On-Chip SRAM / Scratchpad | 低功耗高带宽；驻留动作专家分块、KV 片段；软件管理(08 章弱序+显式 DMA)。 |
| 存算一体 | Compute-in-Memory (CIM) / Near-Memory | 近存/存算预研；端侧基线阶段不依赖，03 章预研轨道。 |
| Jetson Thor | NVIDIA Jetson Thor | Blackwell 端侧 SoC；GR00T 公开靶标 92ms/10.9Hz；NVFP4+FP8 量化标杆。 |
| 昇腾 310P | Ascend 310P | 华为端侧 NPU；公开 π0 FP16 ~430ms；无 BF16；国内具身 demo 参考基线。 |
| Dragonwing IQ10 | Qualcomm Dragonwing IQ10 | 车规/Physical AI 平台；700 TOPS 宣称；QNN+VLA 战略，细节少于 NVIDIA。 |
| 统一内存 | Unified Memory | CPU+NPU 共享物理地址空间；mmap + 显式 DMA；禁止 UVM 式隐式页迁移(具身确定性)。 |
6. 评测与数据(Evaluation & Data)
| 中文 | English | 解释 |
|---|---|---|
| 任务级评测 | Task-Level Benchmark | 以叠衣/抓取/装箱成功率、延迟、能耗为准；非仅 TOPS 或 token perplexity；如 VLABench 等。VLA-Perf 等新 benchmark 待核/社区。 |
| Rollout 验收 | Rollout Evaluation | 在仿真或真机轨迹上评估策略成功率；具身量化验收必项，优于 offline token 精度。 |
| 控制频率 | Control Frequency (Hz) | 策略输出或伺服环频率；π0 语义 50Hz chunk，Helix S0 1kHz，GR00T Thor ~11Hz E2E。 |
| 端到端延迟 | End-to-End Latency | 传感→动作输出的整链 ms；移动抓取目标 ~100ms；VLA chunk 是主瓶颈。 |
| 有效毫秒每瓦 | Effective ms/W | 单位能量下可完成的有效推理毫秒；11 章电源 KPI，对比 Thor/310P/ExecuTorch。 |
| 仿真到真机 | Sim-to-Real | Isaac Sim / MuJoCo 等训练数据迁移真机；数据闭环 31 章。 |
| 现场数据回流 | Field Data Loopback | 量产机器人日志/失败 case 回传云端，持续评测与微调；Tesla/Figure/Isaac 共性能力。 |
7. 产品·部署·合规
| 中文 | English | 解释 |
|---|---|---|
| 产品线/SKU | Stock Keeping Unit / Product SKU | 可销售硬件档位；本库 Edge-Lite/Pro/Server(32 章)。 |
| Design Win | Design Win | 客户选型我方芯片/栈的里程碑；POC→Pilot→量产(32 ADR-129)。 |
| 参考架构 | Reference Architecture | 架构摘要数据流与分层；00-reference-architecture-one-pager。 |
| 应用场景矩阵 | Application Scenario Matrix | 形态×行业×任务×指标；33 章。 |
| 本体形态 | Robot Morphology | 人形/臂/四足/AMR 等；决定外设与 SKU。 |
| 零拷贝传感 | Zero-Copy Sensing | MIPI→dmabuf→NPU；对标 NITROS(34 章)。 |
| 本体感知 | Proprioception | 关节 state/IMU/力矩；作为 VLA state token 输入。 |
| 全身控制 | Whole-Body Control (WBC) | 多关节协调控制；通常 200Hz–1kHz；岛侧(35 章)。 |
| 模型预测控制 | Model Predictive Control (MPC) | 优化式控制；可与 VLA 高层目标结合。 |
| 动作块消息 | ActionChunk (ROS 2) | VLA 输出 chunk 的 ROS 2 类型；35 ADR-139 候选。 |
| 远程临场 | Teleoperation (Teleop) | 人遥操作；LeRobot 数据采集；非量产 SLO。 |
| 仿真到真机 | Sim-to-Real | 仿真训练迁移真机；Isaac Sim/MuJoCo(31 章)。 |
| 合成数据 | Synthetic Data | 仿真生成训练数据；与 field 数据比例见 31 §3.6。 |
| 边缘仅本地 | Edge-Only / Local-Only | 数据与推理不出厂；PIPL/隐私 SKU(28/31)。 |
| 设备画像 | Device Profile / Fleet Profile | OTA/Fleet 中的设备配置元数据(23 章)。 |
| 工业机器人安全 | ISO 10218 | 工业机器人安全要求；VLA 非 SIL 输入(28 章)。 |
| 个人服务机器人安全 | ISO 13482 | 移动服务机器人安全；协作场景。 |
| 个人信息保护法 | PIPL (China) | 中国数据合规；field video 默认本地。 |
| 通用数据保护条例 | GDPR | 欧盟隐私；telemetry L0 默认(29 章)。 |
| 多租户 | Multi-Tenancy | 边缘网关多客户 VLM 隔离；36 ADR-143。 |
8. 缩写索引(Quick Index)
| 缩写 | 全称 |
|---|---|
| VLA | Vision-Language-Action |
| VLM | Vision-Language Model |
| ER | Embodied Reasoning |
| RTC | Real-Time Chunking |
| PTQ / QAT | Post-Training / Quantization-Aware Training |
| NFE | Number of Function Evaluations |
| DiT | Diffusion Transformer |
| DSA | Domain-Specific Architecture |
| AOT | Ahead-of-Time |
| WCET | Worst-Case Execution Time |
| TOPS / TFLOPS | Tera Operations / Floating-Point Operations Per Second |
| ADR | Architecture Decision Record |
| SSOT | Single Source of Truth |
| A | Application & Domain |
| D | Deployment & Service |
| M | Model |
| C | Compiler & Kernel |
| R | Runtime |
| S | System Software |
| I | Interface |
| H | Hardware |
| X | Cross-Cutting Capabilities |
| P | Product Definition |
深入思考
下面三题每题先给题干，再用
<details>折叠一份图文并茂的参考答案。本表是字典，这三题则是「怕你把最容易混的三组术语背下来却用错」——建议先合上答案自己想 3 分钟，再展开对照。
思考题 1：三类动作头术语辨析——扩散策略 / 流匹配 / 单步策略
本表在第 1 节列了扩散策略、流匹配、一致性策略、OneDP、OFP、NFE 等一串「动作头」相关词。请辨析：扩散策略、流匹配、单步策略（OneDP/OFP）三者到底差在哪一个轴上？ 为什么说「减步」（步数蒸馏）与「量化」是两条正交的优化？并用一个数量级估算说明，从 100 步降到 1 步对端侧 chunk 延迟意味着什么。
展开参考答案（含动作头术语关系图 + 步数-延迟算一遍）
结论：三者差在「一条动作轨迹要跑几次网络前向（NFE）」这一根轴上——扩散策略多步（几十到上百）、流匹配少步（5～10）、单步策略压到 1 步；而量化改的是「每一次前向本身多快/多省」，两者一个管次数、一个管单次成本，完全正交，可以叠加。
三者的准确区分：
- 扩散策略：训练目标是「学去噪」，采样时要从纯噪声出发迭代几十上百步（DDPM），每步一次网络前向。质量高、多模态好，但 NFE 大 → 端侧慢。
- 流匹配：训练目标改成「学一个把噪声搬到数据的向量场」，采样用 Euler 积分，同样质量下步数可压到 5～10（π0 走这条路）。它不是「更好的扩散」，而是另一套连续变换的训练/采样范式，代价更低。
- 单步策略（OneDP/OFP）：把多步过程蒸馏/训练成一次前向就出结果（1-NFE）。OneDP 是从扩散蒸馏而来，OFP 是从零自蒸馏的流匹配——殊途同归到 NFE=1。
为什么减步与量化正交：一条轨迹的端侧耗时 ≈ NFE × 单次前向耗时。减步动的是 NFE（乘法的左因子），量化动的是 单次前向耗时（右因子）。两者互不干扰、可相乘叠加——这也是为什么量产栈（如 GR00T Thor）会同时用 nvfp4 量化 + 4 步去噪。
用步数-延迟算一遍（假设动作专家单次前向 ~6ms，取本表 §3b 口径）：
| 方案 | NFE | 动作头轨迹耗时 | 能否满足 50Hz（≤20ms/步语义）/ 100ms chunk |
|---|---|---|---|
| 原始扩散 | 100 | 100 × 6 = 600ms | ❌ 远超 |
| 流匹配（π0 减步） | 5 | 5 × 6 = 30ms | ✅ 加 prefill 后逼近 ~76ms |
| 单步（OneDP/OFP） | 1 | 1 × 6 = 6ms | ✅ 大幅余量，runtime loop 极简 |
读这组数：从 100 步到 1 步，动作头部分从 600ms 压到 6ms（100×），且 runtime 从「跑一个 while 循环 + 中间张量反复读写」简化为「单次前向」——这正是本表把「流匹配步原语（dsa.flow_step）」列为编译器 IR 一等公民、同时要求保留「1-NFE 快路径」分支的原因（详见 §3 部署与运行时、以及第 1 节动作头术语群）。
思考题 2：实时性术语——硬实时 / 软实时 / 准实时 / WCET / jitter 在具身语境的区别
本表第 4 节把实时性拆成硬实时、软实时、准实时，第 3 节又补了 WCET 与 jitter。请说清：这三档「实时」在具身栈里各落在哪个频率带、由谁承担、错过截止期的后果分别是什么？ 为什么控制工程师常说「怕 jitter 甚于怕高均值延迟」？WCET 又为什么是硬实时可调度的前提？
展开参考答案（含实时性分档-频率带映射图 + 对比表）
结论：三档实时的分界不在「快慢」，而在「错过截止期的后果」——硬实时错过即系统失效（1kHz 伺服，安全岛承担）、准实时错过则该次结果作废但不危险（VLA chunk，NPU/RTC 承担）、软实时错过只降体验（VLM 认知，NPU 承担）；jitter 之所以比高均值更可怕，是因为控制回路要的是「可预测的按时到达」，而 WCET 正是把「最坏也不会迟到」这句话变成可数学验证的前提。
三档对比表：
| 维度 | 硬实时 Hard | 准实时 Firm | 软实时 Soft |
|---|---|---|---|
| 典型频率带 | 1kHz 伺服/EtherCAT | 30–100ms VLA chunk（~10–50Hz 语义） | 7–9Hz VLM 认知 |
| 承担者 | 安全岛 MCU + RTOS（非 PREEMPT_RT） | NPU 动作头 + RTC 双缓冲 | NPU 大模型推理域 |
| 错过截止期后果 | 系统失效——机器人可能失稳/伤人 | 该次结果作废，靠旧 chunk / RTC inpainting 兜底 | 仅体验下降，思考慢一拍 |
| 关键指标 | p999 / WCET 上界 | p99 chunk 延迟 | 平均 / p95 |
为什么怕 jitter 甚于怕高均值：控制回路是一个按固定周期采样-计算-下发的闭环。若每周期延迟稳定在 0.9ms（即使偏高但可预测），控制器可以按此整定、闭环稳定；但若延迟在 0.2ms～1.5ms 之间随机跳（jitter 大），采样间隔忽长忽短，等效于给系统注入了随机相位噪声——轻则抖动、重则发散。均值高只是「慢但稳」，jitter 大是「时快时慢、不可预测」，后者直接摧毁时间确定性，这正 是硬控制必须放安全岛而非跑在通用 Linux 上的根因。
为什么 WCET 是硬实时前提：硬实时的承诺是「p999/最坏情况也不迟到」。要在数学上证明一组任务能被按时调度（可调度性分析，如 RMS/EDF），调度器必须知道每个任务的执行时间上界——这就是 WCET。用平均执行时间做调度分析毫无意义：平均达标但最坏超时，照样在最坏那一拍失效。因此硬实时代码要求 WCET 可静态分析或可测量界定（无无界循环、无不可预测的缓存/分支行为），这也是为什么 1kHz 控制不宜经 DDS（ROS 2）——通信栈的延迟上界难以严格界定（呼应本表 ROS 2 与 PREEMPT_RT 词条）。
思考题 3：算力术语易混淆点——TOPS vs TFLOPS、稀疏 vs 稠密、bit vs byte
本表第 5 节列了 TOPS、TFLOPS、稠密算力、稀疏算力等。读芯片 datasheet 时，「700 TOPS」「92ms/10.9Hz」「INT4/1.7GB」这些数字最容易被混淆或被营销放大。请辨析：TOPS 与 TFLOPS 能不能直接比？稀疏标称与稠密实测差多少？bit 与 byte 在「INT4 权重 1.7GB」这类换算里最常见的坑是什么？
展开参考答案（含算力口径易混点关系图 + 内存换算算一遍）
结论：TOPS 是整数（通常 INT8）峰值、TFLOPS 是浮点峰值，口径不同不能直接互换；datasheet 上的「稀疏」值通常是稠密实测的 2×（需 2:4 结构化稀疏才可达，具身量产多半用不上）；而「INT4 权重 N GB」这类换算最常见的坑，是把 bit 和 byte 搞混——1 byte = 8 bit，INT4 是 4 bit = 0.5 byte，算错就会把内存需求估大或估小一倍。
三组易混点逐一拆：
- TOPS vs TFLOPS：OPS 是「整数运算次数」，FLOPS 是「浮点运算次数」。Qualcomm「700 TOPS」多指 INT8 整数峰值；NVIDIA 报 GR00T 时更常用 FP4/FP8 的 TFLOPS/PFLOPS。二者度量不同数据类型的算术单元，不能直接换算比大小——一颗高 TOPS 的芯片不代表浮点推理也强，反之亦然。看 datasheet 先问：这是什么 dtype 的峰值？
- 稀疏 vs 稠密：稠密（Dense）是无稀疏假设的满密度吞吐，是你实测能拿到的基线；稀疏（Sparse，2:4）要求每 4 个权重恰有 2 个为零，硬件才能跳过零值把吞吐翻倍。datasheet 常把「稀疏」的 2× 数字印在最显眼处，但具身模型量产极少满足 2:4 稀疏（本表已标注端侧基线阶段不依赖），所以做算力预算要用稠密口径，别拿稠密实测去对标稀疏标称，否则会高估一倍。
- bit vs byte：精度（INT4/INT8/FP8/FP16）以 bit 计；内存占用与带宽以 byte 计。1 byte = 8 bit，换算要 ÷8。最常见的坑是直接拿「参数量 × bit」当 byte 数，凭空放大 8 倍。
用内存换算算一遍（验证本表「单 VLA INT4 约 1.7–3.5GB」是否自洽，取一个 5B 参数的 π0.7 级模型）：
| 精度 | 每参数 bit | 每参数 byte | 5B 参数权重内存 |
|---|---|---|---|
| FP16 | 16 bit | 2 byte | 5e9 × 2 = 10 GB |
| INT8 | 8 bit | 1 byte | 5e9 × 1 = 5 GB |
| INT4 | 4 bit | 0.5 byte | 5e9 × 0.5 = 2.5 GB |
读这组数：5B 参数 INT4 权重 ≈ 2.5GB，正落在本表「1.7–3.5GB」区间内（下界对应更小的 3B 级、上界含少量 KV/激活缓冲），换算自洽。若这里把 bit 当 byte 直接算成 5e9 × 4 = 20GB，就会误判为需要超大主存、错误否掉 8GB 端侧方案——这正是 bit/byte 混淆在选型阶段的真实代价（呼应本表 §5 硬件、以及 §2 压缩与优化的量化词条）。
附:与洞察章节的映射
| 术语域 | 主要章节 |
|---|---|
| VLA/π0/GR00T/Helix | 01, 21 |
| 量化/蒸馏/减步 | 19 |
| 运行时/KV/RTC | 12, 13, 14 |
| ROS 2/NITROS/dmabuf | 09, 10, 25, 34 |
| DSA/内存/Thor | 02, 03, 07, 11 |
| 任务级 Benchmark | 27, 31 |
| SKU/场景/Design Win | 32, 33, 26 |
| 控制/WBC/1kHz | 35, 13 |
| 端→边→中心 | 36, 24 |