Reference · Company dossier
AWS 的机器人平台尝试已完成从“托管垂直服务”到“云基础设施＋开源参考栈”的退守：RoboMaker（2018–2025）与 RoboRunner（2021–2024）均已停服，现由 IoT Greengrass、SageMaker、Batch 与 2026 年 10 月发布的 Physical AI Toolchain 承接机器人和物理 AI 负载。[确
Amazon Web Services 是 Amazon.com 的云计算子公司，2006 年成立，CEO 为 Matt Garman（2024 年 6 月上任）；AWS 占全球云基础设施支出 28%（Synergy，2026 年二季度）。[确认] 机器人业务不是独立法人，没有独立财务报表和对外负责人，归属 IoT 与物理 AI 产品线；RoboMaker 于 2018 年 11 月 26 日在 re:Invent 发布。[确认] 因此本节以组织沿革代替创始人叙事。[推测]
无独立融资，全部由 Amazon 自有资金与资本开支支持；AWS 分部收入在 Amazon 财报中合并披露，机器人相关收入从未单独披露。[确认] 因此没有估值、融资轮次或股权结构可比，可比的只有战略投入：GPU/EC2 容量、与 NVIDIA 的联合工程，以及 2025 年以来的物理 AI 组织投入，具体金额[未获取]。对客户而言，这意味着“供应商承诺风险”高于财务风险——服务可被随时关停，且已发生两次。[确认]
已停服务：RoboMaker（Cloud9 开发环境、Gazebo 仿真、按仿真单元计费、经 Greengrass 做 OTA 车队部署、ROS 云扩展接入 Lex/Polly/Rekognition/Kinesis/CloudWatch；2024 年 9 月宣布、2025 年 9 月 10 日停服）；RoboRunner（跨厂商机器人车队编排与共享空间管理，2022 年 11 月 GA，2024 年 3 月 14 日完全关停）。[确认] 现存能力：IoT Core（MQTT、设备影子、Jobs）、Greengrass V2（边缘运行时，AWS 称运行于数百万设备；V1 于 2026 年 10 月 7 日停服）、IoT Device Management、SageMaker、EC2 GPU、Batch（大规模仿真编排）、Kinesis Video Streams、Bedrock AgentCore。[确认] 2026 年 10 月 7 日发布 Physical AI Toolchain：开源参考架构加 IaC，串联 Isaac Sim/Lab/GR00T/Cosmos/OSMO，数据走 Zarr 到 LeRobot、训练用 PyTorch 与 Hugging Face、导出 ONNX、控制交给 ROS 2。[确认]
AWS 当前的机器人相关技术栈由四层组成。边缘层是 Greengrass V2，负责在机器人或网关上下发容器、管理证书、执行本地推理与离线缓存；接入层是 IoT Core，提供 MQTT 消息、设备影子与批量任务；数据与训练层是 S3、SageMaker、Batch 与 Kinesis Video Streams；参考架构层是 2026 年 10 月发布的 Physical AI Toolchain，把 Isaac Sim、Isaac Lab、GR00T、Cosmos、OSMO 与 LeRobot 串成一套可部署的模板。[确认]
历史上还有一层已经消失。RoboMaker 在 2018 年发布，提供 Cloud9 开发环境、Gazebo 仿真、按仿真单元计费、经 Greengrass 做车队 OTA，以及把 ROS 节点接到 Lex、Polly、Rekognition、Kinesis 与 CloudWatch 的云扩展；服务在 2025 年 9 月 10 日停止支持。RoboRunner 负责跨厂商车队编排与共享空间管理，2024 年 3 月 14 日关停。[确认]
现存栈的数据流大致是：仿真或实机采集产生 rosbag 与 MCAP 文件，转成 Zarr 存入 S3，再转成 LeRobot 数据集；SageMaker 上用 PyTorch 与 Hugging Face 训练，导出 ONNX；Greengrass 把模型与容器下发到边缘设备；运行数据经 IoT Core 与 Kinesis 回流到数据湖。[确认] 工具链的衔接顺序有官方文档，各段的实际流转细节属于推断 [推测]。数据流每一段都由独立服务承担，粘合工作留给客户。
AWS 不提供机器人感知算法。可用的能力是通用的：Kinesis Video Streams 接入摄像头画面并支持回放与提取帧，SageMaker 训练视觉模型，Bedrock 调用多模态模型做语义标注，Greengrass 把推理容器部署到边缘。[确认] 上述服务如何组合成感知流水线由客户设计 [推测]。
感知的实时性由边缘算力决定。避障、定位与抓取需要在几十毫秒内完成，云端往返延迟在几十到几百毫秒，无法进入控制回路；AWS 的定位是提供训练、标注与下发通道。[推测] 定位与建图算法仍由客户或 ROS 2 社区提供，AWS 没有自研的 SLAM 或地图服务。[确认]
失败模式偏工程侧。视频回传的带宽与存储成本随相机数量线性上升，长时间留存全量视频的费用会超过机器人本体的折旧；跨区域传输在跨国厂区里受数据主权限制；边缘设备的证书轮换与网络中断处理需要额外配置。[推测] 替代方案是本地部署的开源栈加自建对象存储，功能相近，运维责任转移给客户。
控制回路留在机器人上。ROS 2 节点跑在机载计算机或边缘工控机上，Greengrass 只负责部署、配置与日志收集 [确认]；云端不参与关节级控制 [推测]。这一分工符合时延约束，也意味着 AWS 在运动控制与操作策略上没有技术积累。
云端承担的是仿真验证。Batch 可以并行启动大量仿真作业，对同一策略做参数扫描与回归测试 [确认]；OSMO 负责任务编排与资源调度 [确认]。单次可启动的作业规模未披露 [未获取]。这套能力对开发阶段的迭代有价值，对现场运行的直接贡献有限 [推测]。
Physical AI Toolchain 把上述部件固化成参考架构：基础设施用 IaC 描述，仿真环境预置，数据格式与训练脚本沿用 NVIDIA 的接口。[确认] 客户拿到的是可运行的模板，仍需自己填业务逻辑。失败模式在于版本漂移：Isaac、GR00T、LeRobot 的接口迭代快，模板的维护节奏能否跟上，公开材料没有承诺。[未获取]
数据层是 AWS 的相对强项。S3 提供几乎无限的存储与生命周期策略，Zarr 适合存放大规模多维数组，LeRobot 提供机器人数据的通用格式，SageMaker 提供分布式训练与实验管理。[确认] 合成数据由 Cosmos 生成，预训练策略可用 GR00T，导出统一走 ONNX，部署回到 Greengrass。
格式转换是主要的损耗点。rosbag 与 MCAP 记录的是带时间戳的消息序列，转成 Zarr 与 LeRobot 需要处理坐标系、单位、丢帧与时钟同步，转换脚本通常由客户自己维护。[推测] 一旦字段映射出错，训练集与实机行为就会出现难以定位的偏差。
验证边界在仿真到现实。大规模并行仿真能覆盖长尾场景，接触摩擦、柔性物体与传感器噪声的保真度仍不足，策略上线前需要实机采数。[推测] 若客户把仿真结果当作验收依据，实际部署的失败率会高于预期。数据出云的流量费用也需要提前估算，全量回传在多个厂区同时运行时是一笔持续开支。[推测]
AWS 不制造机器人，硬件侧只有边缘计算设备与云端的 GPU 实例。Greengrass 认证的网关、工控机与摄像头模组由合作伙伴提供 [确认]，AWS 规定运行环境与安全基线 [推测]，具体型号未获取 [未获取]。GPU 实例的供给受全球算力市场影响，训练任务的排队时间在需求高峰会明显拉长。[推测]
边缘硬件的约束同样具体。工厂车间的网关要满足宽温、防尘与电磁兼容，机柜空间与供电预算都很紧，Greengrass 的容器化部署会带来额外内存开销，低端设备往往跑不动完整的推理运行时。[推测] 这部分工程由合作伙伴承担，AWS 只保证软件层兼容。
供应链风险落在芯片与网络两侧。训练依赖高端 GPU，边缘推理依赖低成本加速器，两类器件的交期波动会直接影响项目进度；跨国部署还要处理出口管制与本地化要求。[推测] 这些风险对客户是间接的，对 AWS 是资本开支与区域规划的约束。
接口以 AWS 既有服务为主：IoT Core 用 MQTT 与设备影子，Greengrass 用容器与 Lambda，SageMaker 用 Python SDK，基础设施用 CloudFormation 或 CDK 描述。[确认] 身份与权限走 IAM，密钥走 KMS，日志与指标走 CloudWatch，合规体系可以直接复用。
可观测性是拼接出来的。机器人本体的关节温度、电池状态与任务进度需要自定义指标上报 CloudWatch，再配告警与仪表盘；AWS 没有面向机器人车队的专用视图。[推测] 客户要么自建，要么采购 Formant、InOrbit 这类第三方服务，后者与 AWS 的关系是客户关系。
迁移成本低，对客户有利，对 AWS 不利。训练栈以开源组件为主，数据存放在 S3 的开放格式里，换云厂商的工作量主要是重写 IaC 与权限策略。[推测] 低锁定意味着低议价能力，客户可以按价格随时迁移。
第一条可证伪条件来自 NVIDIA。如果到 2027 年底，NVIDIA 以 DGX Cloud 或托管版 Isaac 直接面向机器人客户交付，把仿真、合成数据与训练打包成单一合同且报价低于 AWS 的同类组合，AWS 的托管角色会被压缩为机房供应商，Physical AI Toolchain 的附加值下降。
第二条在客户自建。如果到 2027 年底，MCAP 成为机器人数据的通用格式，训练栈稳定在 PyTorch 与 LeRobot 上，客户用 Kubernetes 加对象存储就能复现整套流程，AWS 只剩下算力与存储的租金，价格战不可避免。判定阈值是主要机器人厂商在采购文件中把 MCAP 列为交付格式。
第三条是需求错位。如果机器人厂商最痛的问题是现场运维、异常诊断与车队调度，而这些恰好是 AWS 没有产品的部分，那么 Toolchain 解决的是开发阶段的问题，采购预算会流向 Formant、InOrbit 或自建平台。观察指标是 Toolchain 发布一年后的公开客户数量与续用情况，目前为零披露。[未获取]
反向证据同样存在。若 AWS 把 Toolchain 与 Amazon 自身的机器人运营经验绑定，提供经过验证的仿真场景库与运维指标模板，客户可以省去大量试错，规模经济就会转化为产品差异。Amazon 在 300 多个履约中心运行超过 100 万台机器人，这套自用经验是其他云厂商没有的资产。[确认]
直销加合作伙伴（系统集成商、ISV、NVIDIA），通过 Marketplace 分发；目标客户是机器人厂商、制造企业、自动驾驶与无人机公司，而非终端工厂的自动化部门。[推测] 最强 reference 是 Amazon 自身：超过 100 万台机器人在 300 多个履约中心运行，DeepFleet 模型用 SageMaker 训练，这套“自用＋外销”叙事是 AWS 相对纯平台公司的优势。[确认]
NVIDIA 是事实标准：Isaac Sim/Lab、Omniverse、GR00T、Cosmos 覆盖仿真、合成数据与 VLA 训练，AWS 的 Toolchain 实质是把 NVIDIA 栈托管到自家云上。[确认] 云侧对手为 Azure（IoT Operations 加 NVIDIA）与 Google Cloud（已放弃独立机器人平台）；数据与可观测性侧为 Foxglove、Rerun；运维 SaaS 侧为 Formant、InOrbit；开源侧是 ROS 2 加 Gazebo。[确认/推测]
风险包括：平台连续性——RoboMaker、RoboRunner、Greengrass V1 接连关停，客户对“再投入一个 AWS 机器人服务”高度警惕；产品商品化，算力价格战压缩毛利；缺少垂直产品团队，路线随 NVIDIA 与 Amazon 内部优先级摆动；数据主权与出口管制影响跨国部署。[确认/推测] 结论：AWS 不再卖“机器人平台”，而卖“物理 AI 的算力、存储与边缘运行时”；对客户是低锁定、低差异化的底座，适合训练、仿真与数据湖，不适合作为机器人运维与数据工作流的核心。若需求是“跑起来”，它便宜且稳；若需求是“沉淀机器人数据资产”，它给不了。[推测]
Philosophy sword
融合主轴尚未定义。这里将放：一句话定性、三线状态、三项判定与反证条件。
预留位 · 不参与当前分析