端到端技术洞察总纲(硬件 → 软件体系)
- 适用对象:面向具身智能(Embodied AI) 的 AI 推理芯片创业项目
- 产品形态:端侧本体 → 边缘侧 → 中心推理
- 文档定位:端到端技术总纲——定义洞察目标、方法论、技术体系架构、章节边界与决策链路;各章节按本总纲形成可追 溯的技术选型输入。
- 关联:本目录沉淀具身智能推理芯片的技术洞察、选型依据与 ADR 候选。
学习目标
- 前置知识:你应当对「AI 芯片」「推理」「量化」有直觉性认识,知道「机器人要看、要想、要动」这条主线即可;不需要读过后面 39 篇任何一篇。本篇是整套洞察的总入口与地图,其余章节都从这里派生。若你完全没有芯片背景,可先扫一眼 01 负载与场景建立负载直觉,再回到本篇看全景。
- 学完产出:① 能画出具身智能推理芯片的九层全栈(硬件 H → 软硬接口 I → 系统软件 S → 运行时 R → 编译算子 C → 模型 M → 部署 D → 应用 A + 横向能力 X + 产品 P),并说清每层「回答什么核心问题」;② 能解释为什么具身智能必须做「芯片 → 编译 → 运行时 → 模型 → 部署」的全栈协同(co-design),而非在单层做局部最优;③ 能把「1kHz 控制周期」这类端侧实时性约束自上而下拆成每层的时延预算,理解硬约束如何反向决定选型;④ 拿到这 39 篇的推荐阅读路径,知道自己该从哪一篇进、按什么顺序读。
- 阅读姿势:盯住一条主线——「具身智能的芯片工程,本质是让一整条从传感器到关节电机的物理闭环,在毫秒级预算内可靠闭合」。它和「云端大模型堆算力」最大的不同,是被实时性、确定性、功耗、安全四条物理红线死死约束。读完你会明白:为什么不能只买最强的算力芯片就完事,而必须把每一层都掰开、按端侧约束重新算一遍账。
一、背景与目标
1.1 业务背景
- 芯片尚未定型,整体处于立项/组建期;软件与硬件需协同定义(co-design)。
- 目标场景:具身智能(人形/移动机器人、机械臂等),负载为 VLA(Vision-Language-Action)、扩散策略(Diffusion Policy)、多模态感知、世界模型 + 传统控制混合。
- 形态演进:端侧(机器人本体)→ 边缘侧(车间/网关/边缘服务器)→ 中心推理(数据中心),功耗/规模/多租户诉求逐级变化。
1.2 洞察目标
- 形成从硬件到软件的端到端技术地图,无盲区地识别每一层的关键技术决策点。
- 以具身场景需求驱动,给出每个决策点的候选方案、权衡与建议方向。
- 输出可直接用于技术选型的结构化结论(选型输入 + 决策记录 ADR 候选)。
- 贯通端→边→中心演进视角,确保早期决策不堵死未来路径。
1.3 非目标(本阶段不 做)
- 大规模分布式训练集群 / 训练并行 / 数据湖(属云训练 Infra);仅保留 QAT/蒸馏所需小规模训练。
- 具体芯片 RTL 微架构实现细节(由硬件团队主导,本洞察只到"软硬接口/可编程性"约束层)。
二、洞察方法论(每章统一流程)
每个洞察章节遵循统一的"六步法",保证可比较、可汇总、可决策:
- 范围与目标:本章覆盖的技术域、要回答的核心问题。
- 需求洞察(具身驱动):从具身负载/场景反推该层的硬性指标(延迟、确定性、功耗、精度、内存、安全)。
- 技术现状与趋势:工业界(竞品/标杆)、学术界、开源生态(MLIR/IREE/LLVM/ROS2 等)现状与走向。
- 候选方案与对比矩阵:列出可选项,按"性能 / 成本 / 风险 / 生态成熟度 / 演进性 / 团队可驾驭度"打分。
- 关键权衡、风险与依赖:跨层耦合、单点风险、对上下游接口的约束。
- 结论与待决项：建议方向 + 未决问题 + ADR 候选。
硬性约束（如 1kHz 控制不进 DDS）写为需求红线；方案取舍经 ADR 确认。写作参考：12 章、13 章。
决策标尺(打分维度,1–5 分)
| 维度 | 含义 |
|---|---|
| 性能/能效 | 对端侧 TOPS/W、延迟、确定性的贡献 |
| 成本 | BOM / 研发 / 维护成本 |
| 风险 | 技术不确定性、人才稀缺度、踩坑概率 |
| 生态成熟度 | 开源/工业生态支撑、可复用度 |
| 演进性 | 对端→边→中心演进的兼容/可扩展性 |
| 可驾驭度 | 以小规模高工程密度团队能否落地 |
信息来源与具体化要求(强制,每章必须满足)
为避免"空泛结论",每章洞察必须做到"有据、具体、可量化、可演进":
- 信息来源(必填):每个关键论断标注来源——论文(arXiv/会议)、公司官方(博客/技术报告/数据手册)、开源仓库、行业报告或内部 profiling;区分"公开"与"推测/估计",标注时间。
- 具体模型(必填):涉及负载/模型时,点名当前业界最常用的具体模型(如 OpenVLA、π0/π0.7、Diffusion Policy、GR00T N1.7、Helix 02 等),给出结构(主干/参数量/算子构成)与演进趋势。
- 具体公司方案(必填):涉及落地时,点名具体公司及其采用的方案(如 Figure Helix 的三系统、NVIDIA Jetson Thor + GR00T 等),说明其硬件/软件选择。
- 具体场景(必填):涉及场景时,给出具体任务(如叠衣物、装箱、上货架、移动抓取),而非泛指"具身"。
- 量化的芯片诉求(必填):由模型/场景的演进反推芯片需具备的算力(TOPS/能效)、功耗(W)、内存(容量/带宽) 等指标,并给出量级与依据。
- 演进映射(必填):说明"随模型/场景演进 → 芯片诉求如何变化",支撑前瞻设计。
三、端到端技术体系架构
自底向上分 9 层 + 4 类横向能力;每层即后续一个或多个洞察章节。
全栈层次与依赖关系一图读懂
上面的组件图给出层级,下面这张依赖流向图补充「每层向上提供什么、向下依赖什么」——它是理解「为什么必须全栈协同」的骨架:控制闭环的实时约束从最上层(应用/控制)一路向下传导,而算力/带宽的物理上限从最下层(硬件)一路向上封顶,中间任何一层错配都会让整条链路失效。
九层缩写定义
| 缩写 | 英文全称 | 中文层级 | 核心问题 |
|---|---|---|---|
| A | Application & Domain | 应用与领域层 | 机器人中间件、参考应用、任务级评测如何对 接芯片能力 |
| D | Deployment & Service | 部署与服务层 | 模型/运行时如何打包、分发、升级、回滚与 Fleet 管理 |
| M | Model | 模型层 | VLA、扩散/流匹配、感知模型如何压缩、导入与部署 |
| C | Compiler & Kernel | 编译与算子层 | MLIR/IREE、DSA Dialect、codegen、kernel 与调优如何承载模型 |
| R | Runtime | 运行时层 | 推理、异构调度、实时确定性、多模型并发如何运行 |
| S | System Software | 系统软件层 | Driver、OS/BSP/RTOS、电源热管理如何提供稳定执行环境 |
| I | Interface | 软硬接口层 | ISA、内存模型、同步原语、固件 ABI 如何冻结软硬契约 |
| H | Hardware | 硬件层 | DSA、存储、互联、制程封装、外设与安全岛如何支撑负载 |
| X | Cross-Cutting Capabilities | 横向能力 | 安全、可观测、AI-Native 研发基础设施、数据闭环如何贯穿全栈 |
| P | Product Definition | 产品定义层 | SKU、场景、感知、控制边界和部署形态如何汇总为产品判断 |
四、分章节洞察大纲
每章一个文件;编号即建议产出顺序。先打通"需求→硬件→软硬接口→编译/运行时"主线,再外扩部署/应用/横向能力。
第 0 部分:需求与场景(洞察的输入)
- 01 具身智能负载与场景需求洞察:VLA/扩散策略/多模态/世界模型的算子构成、算力/内存/带宽画像、延迟与实时性、精度容忍度、功耗预算、安全等级;端/边/中心三形态的需求差异。
A. 硬件层(H)
- 02 DSA 微架构与数据流洞察:计算阵列形态、数据流(WS/OS/RS)、精度支持(INT4/INT8/FP8/BF16)、稀疏支持、可编程性取舍。
- 03 存储与内存层级洞察:片上 SRAM 容量/带宽、LPDDR/HBM、近存/存算、内存墙对具身小批量的影响。
- 04 互联与 SoC 异构集成洞察:NoC、CPU+NPU+DSP+ISP 协同、chiplet、对外 PCIe/CXL(面向边缘/中心)。
- 05 制程·封装·功耗热与能效洞察:工艺节点、封装、TOPS/W 目标、散热与 DVFS 空间。
- 06 外设与实时 IO/安全岛洞察:MIPI/CSI 传感器接口、实时 IO、车规/安全岛(具身/移动平台)。
B. 软硬接口层(I)
- 07 ISA 与编程模型洞察:指令集抽象层级、可编程性 vs 效率、是否暴露给编译器、与 MLIR 后端的契合。
- 08 内存模型·同步原语·固件 ABI 洞察:一致性模型、DMA/同步、固件与控制核职责、寄存器 ABI 稳定性。
C. 系统软件层(S)
- 09 Driver 架构洞察:KMD/UMD 分层、DMA/中断、用户态运行时接口、多平台。
- 10 OS/BSP/RTOS 与实时方案洞察:Linux+PREEMPT_RT vs RTOS 双系统、安全启动、BSP。
- 11 电源·热·能效管理洞察:DVFS、功耗策略、软硬协同能效优化(端侧核心 KPI)。
D. 运行时层(R)
- 12 推理运行时选型洞察:内存管理、异构调度、HAL 抽象。
- 13 实时与确定性调度洞察:控制闭环延迟保证、优先级抢占、QoS、隔离。
- 14 多模型/多任务编排洞察:端侧多应用并发、动态 shape、资源仲裁。
E. 编译与算子层(C)
- 15 AI 编译器与 IR 栈洞察:MLIR 全栈、自定义 DSA Dialect、前端对接(PyTorch/ONNX/StableHLO)。
- 16 后端 Codegen 与指令调度洞察:指令选择/调度/资源分配、LLVM 后端 vs 自定义汇编、kernel 前端(Triton 等)的取舍。
- 17 算子/Kernel 策略洞察:自动生成为主 vs 手写兜底、算子覆盖路线、模板沉淀。
- 18 Auto-tuning 与性能建模洞察:cost model、调优搜索、性能可预测性。
F. 模型层(M)
- 19 模型压缩与优化洞察:量化(PTQ/QAT,INT4/8/FP8)、剪枝、蒸馏、NAS、稀疏、混合精度;精度-能效权衡。
- 20 框架前端与模型格式洞察:PyTorch/ONNX/StableHLO 导入、torch-mlir/onnx-mlir、格式与版本兼容。
- 21 具身模型支持洞察:VLA/扩散策略/多模态/世界模型的部署难点与算子/精度/实时需求。
G. 部署与服务层(D)
- 22 端侧部署与打包洞察:模型/运行时打包、端侧镜像、版本与回滚。
- 23 OTA·设备管理·Fleet 洞察:海量设备远程更新、灰度、provisioning、设备画像。
- 24 端云协同与伴随服务洞察:编译云、模型分发、遥测后端、数据回流(端→边→中心承上启下)。
H. 应用与领域层(A)
- 25 具身中间件与系统集成洞察:ROS2、传感器/执行器、实时控制桥、与运行时的接口。
- 26 SDK 与参考应用洞察:开发者体验、Model Zoo、参考应用、客户 POC 路径。
- 27 任务级评测与 Benchmark 洞察:具身任务级精度/成功率/时延/能效基准与数据集。
横向能力(X)
- 28 安全与功能安全洞察:模型加密/安全启动/TEE、机器人安全标准(ISO 10218 工业机器人 / ISO 13482 个人护理机器人)、隐私合规。
- 29 可观测性与遥测洞察:Profiler/Debugger、端侧/Fleet 遥测、问题归因。
- 30 AI-Native 研发基础设施洞察:私有代码模型/RAG/Agent CI、仿真/FPGA 农场、研发效能。
- 31 数据与评测闭环洞察:field data 回流、持续评测、数据治理(端→边→中心数据通路)。
产品定义与物理闭环
- 参考架构：端侧参考架构；M1–M5 追溯。
- 32 产品 SKU 与平台定义:Edge-Lite/Pro/Server;Design Win 准入;与 05/11/27 映射。
- 33 应用场景矩阵:形态×行业×任务×指标;国内/全球权重。
- 34 传感器·感知与 proprioception 栈:MIPI→dmabuf→ViT;多模态优先级。
- 35 控制栈与 VLA 边界:WBC/MPC/1kHz 岛;ActionChunk 接口;安规红线。
- 36 端→边→中心演进规划:端侧本体、边缘侧与中心推理的多租户、互连和 SKU 演进。
全貌覆盖矩阵
| 能力域 | 必须掌握的问题 | 覆盖章节 |
|---|---|---|
| 具身负载与场景 | VLA/扩散/流匹配、控制频率、延迟、功耗、场景优先级 | 01, 21, 27, 33 |
| 硬件与软硬接口 | DSA 数据流、存储、互联、外设、安全岛、ISA、内存模型、固件 ABI | 02–08, 34, 35 |
| 系统软件与运行时 | Driver、OS/BSP/RTOS、DVFS、IREE HAL、实时调度、多模型编排 | 09–14 |
| 编译与算子 | MLIR/IREE、DSA Dialect、后端 codegen、算子库、auto-tuning、性能模型 | 15–18 |
| 模型优化与格式 | PTQ/QAT、混合精度、蒸馏、模型格式、manifest、具身模型适配 | 19–21 |
| 产品化与生态 | 打包、OTA、Fleet、端云协同、ROS2、SDK、参考应用 | 22–26, 32 |
| 安全、观测与数据闭环 | Secure boot、功能安全、telemetry、profiler、数据回流、持续评测 | 28–31 |
| 演进与平台取舍 | 端侧本体、边缘网关、中心推理、SKU、互连、租户隔离 | 32–36 |
五、分阶段推进顺序
洞察按依赖关系分批推进：先打通需求→硬件→软硬接口→编译/运行时→模型主线，再扩展系统软件与部署集成，最后覆盖规模化与产品定义。
| 阶段 | 产品形态 | 章节重点 | 主要产出 |
|---|---|---|---|
| 主线 | 端侧（具身本体） | 01 需求；02–08 硬件与接口；12–16 运行时与编译；19–21 模型 | 软硬协同约束、核心 ADR 候选 |
| 全栈 | 端侧 + 边缘 | 09–11 系统；17–18 算子；20 框架；22–25 部署；28/30 安全与研发 | 接口冻结输入、SDK/部署方案 |
| 规模 | 边缘 → 中心 | 05–06 硬件补充；14 多任务；23–24 Fleet；26–27 生态评测；29/31 遥测与数据 | 演进规划、多租户选型 |
| 产品 | 量产准备 | 32–36 参考架构、SKU、场景、感知、控制 | 验收基线、正式 ADR 沉淀 |
红线：软硬接口层（07–08）须与 RTL 冻结同步定稿；滞后调整代价极高。
六、与技术选型的衔接
- 每章输出：结论摘要、对比矩阵、建议方向、待决项、ADR 候选。
- 汇总至选型总表与 ADR 目录（组织内维护文档）。
- 决策链：技术洞察 → 选型矩阵 → ADR → 产品与工程规划回写。
与技术约束的衔接(继承现有结论,洞察中再验证)
- 现有倾向:DSA + 全栈 MLIR + 运行时 + AI-Native 研发基础设施;Triton 等可移植 kernel DSL 的取舍按洞察分析评估(见 15 章),不预设结论。
- 这些将在 02/07/12/15/16/17 等章中作为"现有假设"被重新审视与压力测试,洞察可推翻或强化。
七、洞察执行约定
- 单章篇幅可控,每章保持结论、依据、权衡、接口约束和信息来源完整。
- 每章注明:关联 ADR。
- 引用外部资料需标注来源与时间;竞品信息区分"公开/推测"。
- 与硬件团队强相关的章(H/I 层)必须联合评审。
2026 时效锚点(roadmap 项以官方为准):VLA 主流已到 π0.7;NVIDIA GR00T N1.7 GA;Figure Helix 02 三层分频(S2 视觉语言 7–9Hz / S1 视觉运动 200Hz / S0 伺服 1kHz);边缘算力 Jetson Thor 已量产;机器人中间件 ROS 2 LTS「Lyrical Luth」(2026-05);机器人安全参照 ISO 10218 / ISO 13482(而非单一依赖 ISO 26262 车规)。
深入思考
下面三题每题先给题干,再用
<details>折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。这三题分别对应本篇最想传递的三个判断:为何全栈、约束如何下压、路径怎么读。
思考题 1:为什么具身智能必须做「全栈协同」而非单点优化
有人主张:「买一块最强算力的边缘 AI 芯片,把最好的 VLA 模型塞进去就行,何必自己从芯片到部署做九层全栈?」结合本篇 三、端到端技术体系架构的九层依赖图,论证为什么单点最优(如只堆算力、或只优化模型)在具身场景会失效,而全栈协同(co-design)是必要条件。
展开参考答案(含全栈木桶/瓶颈传导图)
结论:具身智能是一条从传感器到关节电机、必须在毫秒级预算内可靠闭合的物理闭环;它的性能由「最短板的那一层」决定而非「最强的那一层」,任何单点最优若 与相邻层错配,富余的能力都会被浪费或被瓶颈吃掉——所以必须全栈按同一套端侧约束协同设计。
为什么单点最优会失效——三条具体反例:
- 只堆算力,不管带宽与内存墙:具身推理是 batch=1 的小批量,GEMM 的 M 维退化到 1,算力单元大量空转——瓶颈在访存带宽而非峰值 TOPS(见 03 存储层级、3b 由演进反推芯片诉求「带宽 > 峰值算力」)。花大价钱买的 TOPS 跑不满。
- 只优化模型,不管编译与算子覆盖:π0 的流匹配 loop、OpenVLA 的自定义
predict_action无法纯 ONNX 导出,若编译器 IR 里没有 first-class 的flow_steploop 原语,再好的模型也编译不出高效 kernel(见 21 具身模型支持 §5.1、15 编译器)。 - 只优化推理,不管运行时与实时性:VLA 软实时 + 1kHz 伺服硬实时若跑在同一个不做优先级隔离的调度器里,一次 VLA 推理抖动就会击穿控制周期,机器人「卡顿摔倒」——这是 13 实时调度的红线。
用「木桶」算一遍:设端到端 chunk 延迟预算 100ms(对标 GR00T on Thor 92ms)。若硬件算力足够但前处理内存搬运吃掉 40ms、编译器没融合算子又浪费 30ms,只剩 30ms 给推理——原本 60ms 的模型根本塞不进,整条闭环失败。反之把每层各优化 15%,乘起来才是 0.85⁴ ≈ 0.52,近乎腰斩的整体收益——这正是协同设计的乘 性收益远大于单层加性收益的根因。
回到本篇 三、体系架构:九层图不是「organizational 目录」,而是一条延迟/带宽/功耗预算逐层分配的账本——全栈协同的本质,是让这本账在每一层都对得上。
思考题 2:1kHz 控制周期如何自上而下压成每层时延预算
Figure Helix 02 的最内层 S0 伺服跑在 1kHz——即每 1ms 必须产出一次关节指令。请把这个「最上层应用的实时约束」自上而下拆解:它如何逐层影响 H/I/S/R/C/M 各层的选型?给出一个 1kHz 控制周期下的逐层时延预算算例。
展开参考答案(含 1kHz 约束下压的时延预算图)
结论:1kHz = 1ms 硬周期是一条不可协商的物理红线,它从最上层一路下压,决定了「哪些计算能进这个周期、哪些必须移出去」;答案是把 VLA 大脑(慢、软实时)与伺服控制(快、硬实时)在架构上彻底分层解耦——1kHz 环里只允许放确定性极强的小网/传统控制,VLA 以 chunk 形式异步喂入。
逐层「算一遍」——把 1ms 周期拆成预算(数量级估算,对标 Helix 三层分频):
| 层 | 在 1kHz(1ms)环内的角色 | 时延预算 | 选型后果 |
|---|---|---|---|
| A 应用 | WBC/MPC 前馈 + 反馈解算 | ~0.3–0.5ms | 只能跑小网/传统控制,VLA 必须移出该环 |
| R 运行时 | 抢占调度 + 上下文切换 | <0.05ms | 需优先级抢占 + 分域,禁止 VLA 阻塞该环 |
| S 系统软件 | 中断响应 + 任务唤醒抖动 | <0.1ms | RTOS 或 Linux PREEMPT_RT,抖动 <100us |
| I 软硬接口 | DMA 取传感器 + 写指令 | ~0.1ms | 确定性 DMA、有界同步原语,不可无界等待 |
| H 硬件 | 实时核/安全岛执行 | ~0.2ms | 需独立实时核/安全岛,与 DSA 物理隔离 |
| 合计 | — | ≈ 1ms 内闭合 | 富余极小,任何一层超支即击穿 |
关键洞察:VLA 根本进不了这个 1ms 环。 π0/GR00T 的单次 chunk 推理是 76–92ms 量级(见 21 具身模型支持),等于 76–92 个 1kHz 周期。所以三层分频架构(Helix S2 7–9Hz VLM / S1 200Hz 视觉运动 / S0 1kHz 伺服)的本质,就是让不同实时等级的计算各跑各的频率,用 ActionChunk + RTC 双缓冲把慢速 VLA 的输出异步喂给快速控制环——这正是 13 实时调度、35 控制栈与 VLA 边界要冻结的红线。
回到本篇 学习目标第 ③ 条:这就是「端侧实时性约束自上而下决定每层选型」的完整链条——上层一个 1kHz 数字,下压成了从 RTOS 抖动预算到硬件安全岛的一整套硬性要求。
思考题 3:阅者应按什么路径读完这 39 篇
面对本篇 四、分章节洞察大纲列出的 39 篇洞察(01–36 + 参考架构/术语/本篇),不同角色(芯片架构师 / 编译运行时工程师 / 模型算法工程师 / 产品与决策者)应该分别按什么路径切入与阅读?给出一张推荐路径图。
展开参考答案(含四类角色阅读路径图)
结论:不要从 01 顺序读到 36——那是「产出顺序」而非「阅读顺序」;应先读本篇总纲建立地图,再按你的角色沿「主线优先、按需外扩」的路径切入,所有人都以 01(负载画像)为共同起点,以 21(具身模型支持)为全栈交汇枢纽。
四条推荐路径对比表:
| 角色 | 起点 | 主线(必读) | 外扩(按需) | 为什么这样读 |
|---|---|---|---|---|
| 芯片架构师 | 00 → 01 | 02 DSA → 03 存储 → 04 互联 → 05 制程 → 06 外设 → 07/08 接口 | 11 能效、34 感知、35 控制 | 从负载反推硬件,接口层(07/08)与 RTL 冻结同步,最优先 |
| 编译/运行时工程师 | 00 → 01 → 21 | 12 运行时 → 13 实时 → 15 编译器 → 16 codegen → 17 算子 → 18 调优 | 14 多模型、20 框架、09 driver | 21 给出模型侧算子/loop 需求,是编译运行时的输入清单 |
| 模型/算法工程师 | 00 → 01 → 21 | 19 压缩 → 20 框架 → 21 具身模型 → 27 评测 | 15 编译器(理解可编译性)、13 实时 | 关心量化/减步/RTC 如何落到芯片,21 是主场 |
| 产品/决策者 | 00 | 32 SKU → 33 场景 → 36 演进 → 参考架构 | 27 评测、28 安全、24 端云 | 关心边界、SKU、验收与演进,自顶向下读结论 |
通用建议(三步法):① 先地图后细节——任何角色都先读本篇 00 + 01 负载画像,建立「九层 + 端侧约束」的全局观;② 沿主线打通闭环——按上表主线一次读完一条垂直链路(如架构师的 02→08),形成对该层的系统认识;③ 在 21 汇合再外扩——21 具身模型支持是全栈交汇枢纽(它同时向下压算子需求、向上承接负载画像),读完它再按项目阶段外扩系统软件(09–11)、部署(22–26)与横向能力(28–31)。
回到本篇 五、分阶段推进顺序:那张表按「主线 → 全栈 → 规模 → 产品」的产出批次组织,而本题给的是按阅读角色组织的正交视图——两者结合,你就知道「先写什么」和「先读什么」分别怎么排。
下一篇 → 01 具身智能负载与场景需求洞察:把视野从「全栈地图」收敛到「输入端」,讲清 VLA/扩散策略/多模态的算子构成、算力内存带宽画像与实时性约束——它是驱动后面每一层选型的需求源头。