32 产品 SKU 与平台定义洞察
- 章节编号:32
- 所属层:产品/平台(横向能力 H/S/R/M/D;衔接 05/11/27/26)
- 关联 ADR:ADR-127(SKU 产品线定义)、ADR-128(硬件-软件验收映射)、ADR-129(Design Win 准入标准)、ADR-130(端云 SKU 演进标签)
学习目标
- 前置知识:读过 05(TDP/功耗档)、11(power profile)、21(具身模型族)、27(benchmark 验收集)、26(客户交付/AE 流程);知道「具身推理 SoC 要同时喂饱一个 VLA 大模型 + 一个高频动作头 + 感知前端」这个基本负载画像即可。无需芯片设计经验。
- 学完产出:① 能画出「三档 Edge 系列 + Dev Kit」的 SKU 分层,并说清每档的 TDP / 内存 / 外设 / 安全岛边界从哪个客户诉求反推而来;② 能用「内存档 × INT4 模型 footprint」一句话讲清「为什么人形 OEM 必须 Edge-Pro、而 AMR 可以用 Edge-Lite」,并解释安全岛是硬门槛而非软件开关;③ 能把 SKU 的功耗 sustained 档位映射到 21 章的 chunk 延迟预算,理解「散热档」如何倒逼「实时频率」;④ 能说清 Design Win 三阶段(POC / Pilot / 量产)门槛为什么这样切,以及每阶段验收挂在哪本章;⑤ 能把一个客户诉求(如「宇树人形,要跑 GR00T-class」)映射到具体 SKU + 能力包 + 验收子集,输出一张可交付的选型单。
- 阅读姿势:盯住一条主线——「SKU 不是拍脑袋切档,而是把客户的物理约束(散热、供电、安规)翻译成硅上的硬边界,再把硬边界翻译成软件能力包与验收门槛」。每看到一个档位数字(15W / 130W / 8GB / 64GB),都追问一句:这个数字是被哪个客户的哪个物理约束逼出来的?
1. 范围与目标
定义 具身推理 SoC 产品线(SKU)、平台能力包、与软件验收的映射。弥补原 31 章仅技术栈、缺「产品化边界」的缺口。
一句话说清本章的位置:31 章回答「我们的技术栈长什么样」,而 32 章回答「这套技术栈切成几个能卖的盒子、每个盒子装什么软件、客户验收到什么程度才算 win」。SKU 是产品与工程的交界面——它把物理约束(散热/供电/安规)、软件边界(能力包)、商业门槛(Design Win)三件事,压进同一张分档表。
核心问题
- 产品线与演进有哪些 SKU?TDP/内存/外设如何分档?
- 每档 SKU 的 软件能力包(runtime/compiler/model zoo)边界?
- Design Win 准入:客户 POC 需满足哪些指标?
2. 需求洞察(具身驱动)
SKU 分档的第一性原理:不是先有芯片再找客户,而是先有客户的物理约束再反推档位。四类具身客户的散热/供电/安规约束天差地别,直接决定了他们能接受哪一档。
| 客户类型 | SKU 诉求 | 代表 |
|---|---|---|
| 人形 OEM | Edge-Pro;≥8GB;多 MIPI;Thor 对标 | 宇树/智元/Figure 类 |
| 移动操作(AMR+臂) | Edge-Lite;无风扇;15–25W | Agility/Digit 类 |
| 工厂网关 | Edge-Server;多 VLM 并发 | BMW 车间边缘 |
| 算法公司 | Dev Kit = Edge-Pro + dsa-sdk | PI/LeRobot 生态 |
2.1 从客户物理约束反推档位(为何是这四类)
把上表再往下拆一层——每类客户「能给芯片多少瓦、多少体积、要不要过安规」是完全不同的:
- 人形 OEM:躯干内部空间大、可上主动散热(小风扇/均热板),但关节/协作场景带人身安全,安规(功能安全)是硬门槛 → 需要 Edge-Pro 的散热余量 + 安全岛。
- 移动操作 AMR:平台电池供电、多为无风扇被动散热,热预算被死死卡在 15–25W;作业多为「软实时抓取」不直接接触人 → Edge-Lite 足够。
- 工厂网关:接市电、有机柜散热,要同时服务多台机器人跑共享 VLM → 只有 Edge-Server 的功耗/内存档撑得住多路并发。
- 算法公司:不量产硬件,只要一个能跑全 Model Zoo 的开发底座 → Dev Kit(= Edge-Pro 能力 + 完整 SDK)。
场景化业务症状:某 AMR 客户拿 Edge-Pro 样机跑 demo 一切正常,量产装机后批量热保护降频——根因是他们的车体是无风扇被动散热,Edge-Pro 的 30–80W sustained 档在密闭壳体里压不住结温。这不是软件 bug,是选错了 SKU 散热档。正确动作是回退到 Edge-Lite(15–25W 被动散热档),而不是去调 nvpmodel。这类症状是 SKU 分档存在的直接理由。
3. 技术现状与趋势(对标)
先看业界怎么切档,再定我们的档。下表是 2026-07 口径的主流具身推理平台横向对标(时效以官方 datasheet 为准):
| 平台 | SKU 策略 | AI TDP | 内存 | 具身案例 |
|---|---|---|---|---|
| Jetson Thor | 模块化载板 | 40–130W | 128GB | GR00T 10.9Hz |
| Jetson Orin NX/AGX | 多档 TDP | 10–60W | 8–64GB | GR00T 5.8Hz |
| 昇腾 310B/310P | 单档边缘 | 载体 TDP 以官方为准 | 8GB 级 | π0 430ms |
| Qualcomm Dragonwing IQ10 | RRD 参考设计 | 宣称 up to 700 TOPS | — | Physical AI |
| 我们(候选) | 三档 Edge 系列 | 见下表 | LPDDR 统一内存 | π0/OpenVLA 验收 |
时效口径(2026-07):Jetson Thor 已量产,128GB LPDDR5X、2070 FP4 TFLOPS(稀疏)/ 1035 FP8 TFLOPS(稠密)、功耗档 40–130W;GR00T 最新为 N1.7 GA;AGX Orin 有 64GB 版,故 Orin 系内存写 8–64GB;高通 Dragonwing IQ10 官方宣称 up to 700 TOPS(标「宣称」,非实测 VLA 延迟);昇腾边缘现役主力为 Ascend 310B(载体 Atlas 200I A2,约 20 TOPS INT8),原文「310P 8W/8GB」属可疑,统一改写为「昇腾 310B/310P」并注明具体载体 TDP 以官方为准。凡 roadmap 项均标「以官方为准」。
读这张表的姿势:Thor 是「一颗芯片 + 模块化载板」打全场,靠 40–130W 的宽功耗档覆盖多形态;而我们作为初创,无法用一颗 die 覆盖 15W~200W,只能切成三档 SKU 各打一段。这正是「三档 Edge 系列」策略的由来——用 SKU 分档换 die 复用度。
3b. SKU 定义矩阵(候选)
这是本章的核心资 产。四档(三档量产 + 一档开发)把上文所有物理约束落成硬参数:
| SKU | AI TDP sustained | 峰值 | 内存 | MIPI | 安全岛 | 目标模型 | 27 验收 |
|---|---|---|---|---|---|---|---|
| Edge-Lite | 15–25W | 40W | 8GB | 2–4 | 可选 | OpenVLA INT4;小 DP | ≥3Hz;chunk ≤200ms |
| Edge-Pro | 30–80W | 130W | 16–32GB | 4–8 | 标配 | π0 5步;GR00T-class | chunk p99 ≤100ms |
| Edge-Server | 80–200W | 250W+ | 64GB+ | N/A(PCIe 相机) | 分区 | 多路 VLM FP8 | 多租户 batch |
| Dev Kit | = Edge-Pro | — | — | — | — | 全 Model Zoo | M3 CI 同款 |
映射(05 ADR-122):Edge-Lite → LOW nvpmodel;Edge-Pro → MID/HIGH;Edge-Server → 边侧 SERVER profile(11 章)。
3b.1 每一列的产品语义(为什么是这些数)
逐列读这张矩阵——每个数字都对应一个物理或软件约束,不是随手填的:
- AI TDP sustained vs 峰值:sustained 是「壳体能持续压住的结温档」,峰值是「短时 burst(如一次 chunk 去噪)允许冲的功率」。Edge-Lite 15–25W sustained / 40W 峰值,意味着只能短暂冲刺、不能长时间满载——这直接卡死了它的实时 频率上限。
- 内存:这一列决定「能同时驻留几个模型」。8GB(Lite)只够一个 INT4 VLA + 控制小网;16–32GB(Pro)才装得下 π0(VLM + 动作专家)或 GR00T-class 双系统;64GB+(Server)是给多路 VLM 并发的。内存是最硬的功能边界(§5 详算)。
- MIPI 路数:决定接几路相机。人形多目(头 + 双手 + 环视)要 4–8 路;AMR 通常 2–4 路够;Server 走 PCIe 相机不占 MIPI。
- 安全岛:这不是一个可裁剪的软件功能,而是一块物理隔离的安全 MCU/分区。协作/人形场景带人身安全 → 必须硬件级冗余监控(看门狗 + 独立安全通道)。Lite「可选」= 不接触人的 AMR 可以省掉;Pro「标配」= 面向人形/协作,不给选。
- 目标模型 / 27 验收:每档绑定 21 章一个模型子集 + 27 章一组 benchmark 门槛,构成 ADR-128 的硬软映射。
3b.2 SKU 分档 → 能力包 / 驱动 的映射关系
SKU 不只是硬件档,它同时决定软件能力包(runtime/compiler/model zoo 特性)与驱动栈的裁剪边界。下图把「硬件档 → 软件能力包 → 驱动特性」串成一条链:
关键点:同一份代码基线,通过 manifest 里的 platform_tier 字段(20 章)编译期/装载期裁剪出三个能力包。Lite 包物理上就没有安全岛硬件,故安全通道驱动直接不编入;Pro 包必须带安全岛心跳与独立看门狗驱动。能力包边界 = 硬件 档边界,这是 ADR-128 的软件侧落点。
4. 候选方案与对比矩阵
要不要切三档?对比三个 SKU 策略候选:
| 候选 | 成本 | 演进性 | 可驾驭度 | 小结 |
|---|---|---|---|---|
| A. 三档 SKU( Lite/Pro/Server ) | 4 | 5 | 4 | 建议方案 |
| B. 单 SKU 打天下 | 5 | 2 | 3 | 无法满足 AMR 与人形价差 |
| C. 首颗仅 Dev Kit | 5 | 3 | 5 | M1–M3 可行;量产前须 A |
建议方向:M1–M3 以 Dev Kit(=Edge-Pro 能力) 验证;Tape-out 目标 Edge-Lite + Edge-Pro;Edge-Server 规模化阶段+(36 章)。
为什么不选 B(单 SKU):AMR 客户的热预算是 15–25W、人形要 30–80W + 安全岛,两者的价差可达数倍。用一颗覆盖全场的 die,要么对 AMR 过配(贵、装不进无风扇壳体),要么对人形欠配(跑不动 GR00T-class)。单 SKU 在「成本」维度看似最优(5),但演进性只有 2——卖不进任何一端的甜点区。
5. 关键权衡
三档之间的分界线,本质是三条硬约束:
- Lite 无安全岛 vs Pro 标配岛:Lite 仅软实时 AMR;人形/协作 须 Pro+岛(28 章)。安全岛是硬件门槛不是软件开关——没有物理隔离的安全分区,就过不了功能安全评估,协作场景一票否决。
- 内存档位与 INT4 模型:8GB 上限 OpenVLA/π0 INT4;7B+ 多模型须 16GB+(03/21)。内存是「能驻留几个模型」的硬天花板(§5.1 详算)。
- 软件分版:Lite 可裁剪 multi-VM/RTC;Pro 全功能——manifest
platform_tier字段(20 章)。
5.1 内存档位的算术天花板(算一遍)
「8GB 够不够」不是感觉,是可以算的。以 21 章的 footprint 口径估算(数量级):
| 组件 | INT4 footprint(估算) | 说明 |
|---|---|---|
| 单 VLA(OpenVLA 7B,INT4) | ~1.7–3.5 GB | 权重 + 量化元数据 |
| KV-cache(VLM prefill) | ~0.5–1.5 GB | 随上下文长度增长 |
| 动作头 / 控制小网 | ~0.3–0.6 GB | 300M 级,可驻 SRAM 一部分 |
| 感知前端 + 双缓冲 + OS/runtime | ~1.5–2.5 GB | ViT stub + dmabuf + 系统占用 |
| 合计(单 VLA) | ~4–8 GB | 恰好压满 Edge-Lite 8GB 上限 |
结论性观察:Edge-Lite 8GB 只够一个 INT4 VLA + 控制小网,已在上限边缘;一旦要跑 π0 的「VLM + 动作专家」双模块、或 GR00T-class 双系统(VLM + DiT 同时驻留),内存需求翻倍到 12–16GB+ → 必须 Edge-Pro 的 16–32GB。这就是「AMR 用 Lite、人形用 Pro」在内存维度的硬算术依据(回链 §3b.1 内存列 + 思考题 1)。
6. 结论与 ADR 候选
Design Win 准入(ADR-129 候选)
| 阶段 | 门槛 | 周期 |
|---|---|---|
| POC | LeRobot manifest → bundle ≤30min;1 任务 demo | ≤2 周(26) |
| Pilot | chunk p99 达标;OTA 1 次;7×24h soak | ≤3 月 |
| 量产 | signed bundle;岛 SIL 证据包(若 Pro);Fleet | 合同 |
三阶段门槛的设计逻辑(为什么这样切,详见思考题 3):POC 验「能不能跑通」、Pilot 验「稳不稳」、量产验「合不合规能不能规模化」——每阶段只验一件事,门槛逐级抬高,风险逐级出清。
- ADR-127 SKU 产品线:三档 Edge-Lite/Pro/Server + Dev Kit;与 05 TDP/06 外设/11 power profile 一一映射。
- ADR-128 硬软验收映射:每 SKU 绑定 27 章 benchmark 子集 + 21 章模型族。
- ADR-129 Design Win 准入:POC/Pilot/量产三阶段门槛;AE checklist 入 26 章。
- ADR-130 端云 SKU 标签:manifest
deployment_tier: edge-lite|pro|server;OTA 通道分轨(23)。
深入思考
下面三题每题先给题干,再用
<details>折叠一份图文并茂的参考答案。建议先合上答案自己想 3 分钟,再展开对照。
思考题 1:为何人形 OEM 必须 Edge-Pro + 安全岛,而 AMR 可用 Edge-Lite
一个宇树类人形 OEM 和一个 Agility 类 AMR 客户同时来选型,你为什么会给前者 Edge-Pro(带安全岛)、后者 Edge-Lite?请分别从内存档 × INT4 模型 footprint、以及安全岛的功能安全属性两条线论证,并说明「让 AMR 也上 Edge-Pro」和「让人形省掉安全岛」各会踩什么坑。
展开参考答案(含图)
结论:人形要跑 GR00T-class 双系统、内存需求翻倍到 16GB+,且协作场景带人身安全必须过功能安全 → 只有 Edge-Pro(16-32GB + 标配安全岛)满足;AMR 只跑单个 INT4 VLA、8GB 够用,且不直接接触人、软实时即可 → Edge-Lite 恰好卡在甜点,安 全岛是纯浪费成本。
算一遍:内存档 × INT4 模型 footprint
| 客户 | 模型形态 | INT4 footprint(估算) | 内存需求 | 匹配 SKU |
|---|---|---|---|---|
| AMR | 单 VLA(OpenVLA 7B INT4)+ 控制小网 | 权重 ~1.7-3.5GB + KV ~1GB + 系统 ~2GB | ~4-7GB | Edge-Lite 8GB ✅ |
| 人形 | π0 双模块 或 GR00T 双系统(VLM+DiT 并驻) | 两个模型 ~7-10GB + KV/双缓冲 ~2-3GB + 系统 ~2GB | ~12-16GB | Edge-Lite ❌ / Edge-Pro 16-32GB ✅ |
数量级很清楚:AMR 的单 VLA 恰好卡进 8GB;人形的双系统直接翻倍出 8GB 天花板,内存这一条就把人形挡在 Edge-Pro。
两个坑:
- 让 AMR 上 Edge-Pro:安全岛 + 更高功耗档是纯浪费——AMR 无风扇壳体压不住 Edge-Pro 的 30-80W sustained,会批量热降频(见 §2.1 业务症状),且为用不到的安全岛多付成本,甜点区尽失。
- 让人形省掉安全岛:安全岛是物理隔离的安全分区,不是软件开关;砍掉它,协作/人形场景过不了功能安全评估,一票否决——量产阶段(ADR-129)拿不到「岛 SIL 证据包」直接卡死。
回链:本篇 §3b.1 内存列与安全岛列 + §5.1 内存算术天花板。
思考题 2:SKU 功耗档与 chunk 延迟预算的映射
Edge-Lite 的验收是「chunk ≤200ms」、Edge-Pro 是「chunk p99 ≤100ms」——为什么延迟门槛跟着功耗 sustained 档走?请解释「sustained 功率档 → 可维持算力 → chunk 延迟预算」这条因果链,并说明为什么不能靠「Lite 短时冲峰值」来达到 Pro 的延迟。
展开参考答案(含图)
结论:chunk 延迟由「能持续维持的算力」决定,而持续算力被 sustained 功耗档死死卡住;峰值只能短时 burst 一次去噪,连续多步/多 chunk 会立刻触发热保护降频,所以 Lite 的峰值冲刺换不来 Pro 的稳定低延迟。
算一遍:功耗档 → chunk 延迟预算映射
| SKU | sustained 档 | 散热形态 | 可维持算力(相对) | chunk 预算 | 实时频率 | 对标(21 章) |
|---|---|---|---|---|---|---|
| Edge-Lite | 15–25W | 被动无风扇 | 1× 基准 | ≤200ms | ≥3Hz | 优于 310B/310P π0 430ms |
| Edge-Pro | 30–80W | 主动散热 | ~3–4× | p99 ≤100ms | ~5–10Hz | 逼近 Thor GR00T ~92ms/10.9Hz |
| Edge-Server | 80–200W | 机柜散热 | ~8–10× | 多路 batch | 并发吞吐 | 多租户 VLM |
一次 π0 chunk = ViT prefill(~30–50ms)+ 5 步动作专家去噪(~5×6ms)。要把 p99 压到 ≤100ms,5 步去噪必须连续跑在满算力上不降频——这需要 sustained 档能持续压住结温。Lite 的 15–25W sustained 只能维持约 1× 基准算力,连续 5 步就逼近热墙;它的 40W 峰值只够短时冲一次,冲完立刻热降频,连续 chunk 的 p99 根本压不到 100ms。
为什么不能靠 Lite 冲峰值: 峰值是「短时 burst 功率」,受结温热惯性保护——冲一次可以,连续冲(每 100ms 一个 chunk、每 chunk 5 步)会在数百毫秒内把结温顶到保护阈值,触发降频,p99 尾延迟暴涨。稳定低延迟要的是「可持续算力」,而可持续算力 = sustained 档,不是峰值。 这就是延迟门槛必须跟着 sustained 功耗档走的根因。
回链:本篇 §3b.1(sustained vs 峰值列) + §3b 矩阵 27 验收列。
思考题 3:Design Win 三阶段门槛为何这样设
POC(≤2 周,bundle ≤30min + 1 任务 demo)、Pilot(≤3 月,chunk p99 达标 + OTA + 7×24h soak)、量产(signed bundle + 岛 SIL 证据包 + Fleet)——为什么把门槛切成这三级、周期这样递增?如果把「7×24h soak」提前到 POC、或把「signed bundle」推迟到量产之后,分别会出什么问题?
展开参考答案(含图)
结论:三阶段各验一件正交的事——POC 验「能不能跑通(可行性)」、Pilot 验「稳不稳(可靠性)」、量产验「合不合规能不能规模化(合规与运维)」;门槛逐级抬高、周期逐级拉长,是为了让客户与我们都能在最低成本处尽早出清最大风险,任何阶段错位都会把高成本风险留到后期爆炸。
对比表:三阶段验什么、挂在哪本章
| 阶段 | 核心问题 | 门槛 | 出清的风险 | 验收挂靠 |
|---|---|---|---|---|
| POC | 能跑通吗? | LeRobot manifest → bundle ≤30min;1 任务 demo | 可行性风险(模型/工具链根本跑不通) | 26 章交付流程 |
| Pilot | 长期稳吗? | chunk p99 达标;OTA 1 次;7×24h soak | 可靠性风险(偶发崩溃/内存泄漏/热降频) | 27 章 benchmark + 23 章 OTA |
| 量产 | 合规且能规模化吗? | signed bundle;岛 SIL 证据包(若 Pro);Fleet | 合规 + 运维风险(安规不过、无法批量运维) | 28 章功能安全 + Fleet 管理 |
两个错位反例:
- 把 7×24h soak 提前到 POC:POC 的目的是2 周内快速判生死——若强塞一周 soak,客户还没确认「跑不跑得通」就要先烧一周机时,可行性未知却先付可靠性成本,把最该快的阶段拖慢,很多本该早死的项目被拖着流血。soak 属于「已确认可行、验稳定性」的 Pilot 阶段才划算。
- 把 signed bundle 推迟到量产之后:signed bundle(签名固件)是供应链与安全的信任根;若量产铺完货才补签名,已出厂的 Fleet 全是未签名固件,OTA 通道无法验证完整性,一旦被篡改是安全事故,且召回成本极高。签名必须在量产门槛内卡死,不能后补——这也是「量产阶段绑 signed bundle + 岛 SIL 证据包」的原因。
一句话总结:门槛这样设,是让「便宜的验证在前、昂贵且不可逆的合规在后」,每阶段只放行已出清对应风险的客户。
回链:本篇 §6 Design Win 准入表 + ADR-129。
附:信息来源
- NVIDIA Jetson module comparison(Thor 128GB / 2070 FP4 稀疏 TFLOPS / 40–130W;GR00T N1.7 GA;AGX Orin 8–64GB);05/11/27 章;01 客户细分。[内部+公开]
- Qualcomm Dragonwing IQ10「up to 700 TOPS」为官方宣称(CES/Computex 2026);昇腾 310B / Atlas 200I A2(约 20 TOPS INT8)载体 TDP 以华为官方 datasheet 为准。[公开]
- 内存 footprint / chunk 延迟粗算:基于 21 章 π0/OpenVLA/GR00T 公开 profiling 的工程估算。[估计]