宇树与智元机器人“共用一个大脑”的模型 Demo 在机器人社区里引起了不少讨论。标题里的“神秘模型”和“10 分钟一镜到底”指向了两个关键信号一是模型试图跨多个异构机器人本体工作二是演示者想用一条不剪辑的连续视频证明系统在真实环境里能持续运行。对做模型部署、机器人控制和具身智能的工程师来说真正值得关注的不是“哪个公司又炫技了”而是这类 Demo 背后必须解决的技术链路一个大脑如何接收不同机器人的传感器输入如何输出动作模型推理用什么精度部署在什么硬件上以及“一镜到底”到底能证明什么、不能证明什么。目前公开信息里并没有给出完整模型结构所以下面不猜具体模型而是讨论任何一套“共享大脑”系统都必须面对的工程问题。读完你可以理解机器人基础模型的架构主线知道 FP32、FP16、BF16、TF32 这些数值格式怎么选明白为什么 vLLM 在昇腾 910B A2 上不一定能启动 embedding 和 reranker 模型也能拿到一份从“能跑 Demo”到“可信实验”的验证清单。1. “共用一个大脑”的技术本质从固定流程到跨本体机器人基础模型1.1 共享大脑不是远程遥控很多人第一次看到“宇树智元共用一个大脑”时第一反应是“是不是一台服务器在远程控制所有机器人”。远程遥控确实能实现一个操作员切换多台设备但它不是“共用一个大脑”。共享大脑指的是多个不同厂家、不同结构的机器人本体运行同一个基础模型模型根据各自的相机画面、关节状态和任务指令直接输出各自的动作。这里的关键词是“跨本体”。宇树有轮足、四足和双足人形机器人智元机器人也有人形产品它们的高度、关节数、质量分布、相机安装位置都不一样。如果模型针对某一台机器人单独训练换一台机器人就失效那就谈不上共享大脑。真正的共享大脑必须把“感知—理解—动作”这三段能力从某个具体硬件里抽离出来让动作输出层变成可替换的适配接口。这也是具身智能Embodied AI领域现在的核心路线不再为每台机器人单独写一套基于规则的控制脚本而是让模型从多模态输入中直接预测动作再交给底层运动控制器执行。1.2 VLA 模型为什么能跨机器人工作这类系统的学名通常叫 VLA即 Vision-Language-Action 模型。名称里的三个词已经说明了它的输入输出Vision相机图像有时还包括点云、深度图。Language任务指令例如“把杯子放到托盘上”或“向前走 1 米”。Action机器人动作可以是关节角度目标、末端速度、轮速指令等。VLA 把动作也当成一种“语言”来处理。工程师把连续的动作空间做离散化比如把每个关节角度映射成 0 到 255 的整数 token模型就像生成自然语言一样逐个预测动作 token。这样不同机器人的动作只要都能编码成同一套 token 格式模型就具备跨本体工作的可能性。为什么同一套模型参数能适应不同本体常见方案有三种本体条件化模型输入里附上一段“本体描述”包含关节数、关节名、相机内外参、运动学树等元信息让模型根据本体信息动态调整输出。分部适配共享大模型负责感知和推理每台机器人挂一个轻量级适配层例如 LoRA 或独立策略头把共享特征映射到具体关节空间。统一运动接口上层模型只输出目标点、方向、末端位姿这类“意图”底层用传统控制器完成具体执行。这三种方案可以叠加使用。实际项目中常见的是“共享大模型 每台机器人一个小适配器”既保留了绝大多数共享参数又避免让一个大模型记住所有机器人的控制细节。1.3 10 分钟一镜到底能证明什么不能证明什么一镜到底源自影视术语意思是整条视频没有剪辑、没有切镜头。用在机器人 Demo 里它的潜台词是我不是从几十次录屏里挑了一条最成功的也没有在关键动作处做后期拼接系统确实连续工作了 10 分钟。这个形式能有效证明三件事系统是实时在线运行的不是离线渲染或逐帧后处理。存在一个可以持续工作的闭环模型输出动作传感器反馈状态循环往复。10 分钟内没有用人工介入或者剪辑掩盖失败至少从视频可见范围内看是一致的。但它不能证明三件事泛化能力。一次成功只能说明模型在这一个场景、这一条轨迹上有效换了光照、换了物体位置、换了背景成功率是多少单条视频看不出来。统计成功率。需要多少次独立尝试、成功多少次、失败时如何恢复这些都需要实验重复而不是一条录屏。安全边界。一镜到底展示的是“顺利情况”遇到传感器故障、关节卡死、模型输出了非法指令系统能不能安全停下来视频里往往看不到。所以专业团队看这种 Demo第一反应不是“好强”而是“这条视频对应的日志在哪里能不能复现”。这也是后面第 4 节要展开的内容。2. 一个共享大脑系统的模块组成与运行链路2.1 感知-规划-执行三层闭环拆开看“一个大脑”实际由三层组成它们各自独立运行但共享同一份模型状态。感知层负责把原始传感器数据转成模型能读的特征。相机帧要做缩放、归一化、时间戳对齐关节角度、角速度、力矩这类本体感知数据要统一单位如果有多相机或者 LiDAR还要做外参标定和融合。感知层的输出是结构化的张量而不是直接把原始图像丢给模型。规划层是 VLA 模型的核心部分。它把感知特征、任务指令和历史记忆拼在一起通过 Transformer 结构推理出下一步意图。输入可以是一句话加当前帧也可以是一段轨迹加环境地图。输出则是动作 token 序列或者是一段 JSON 格式的控制指令。执行层把模型输出翻译成电机可以执行的信号。这一层通常包含动作 token 反离散化、关节限位和速度限幅、力矩保护、碰撞检测、底层控制周期调度。执行层也会把关节实际状态反馈给感知层形成完整的闭环。这三层的关系可以简单理解成感知层负责“看懂”规划层负责“想清楚”执行层负责“做得稳”。共享大脑共享的主要是中间那一层感知和执行经常按本体单独配置。2.2 动作是怎么变成机器人关节指令的如果模型输出的是动作 token那么消费端必须解决“token 到真实关节指令”的转换问题。这个转换链是跨本体共享的关键接口。第一步是动作编码。训练阶段工程师把真实关节轨迹记录成一段 token 序列。例如某个 7 自由度机械臂每个关节角度归一化到 [-1, 1]再量化成 8 bit 整数每次模型输出 7 个 token 就代表一组关节目标。量化粒度决定了动作精度256 档对大多数机械臂够用但对要求亚毫米精度的精密操作可能不够得换 4096 档或直接输出连续值。第二步是反离散化和去抖动。模型生成的 token 经过 softmax 采样后是一个概率分布直接取 argmax 会丢失信息采用温度等参数控制随机性又可能产生抖动。常见做法是对概率分布做 softmax 平滑再对动作序列做滑动窗口滤波。滑动窗口滤波能明显降低抖振但会引入相位延迟窗口越长延迟越大。这个 trade-off 要在实际机器人上调试不能只盯着视频看。第三步是安全过滤。模型不是永远可靠的它的输出必须经过关节限位、速度限幅、碰撞检测和力矩保护才能发给电机。安全过滤不通过时应该保持上一帧指令或者触发急停而不是把错误指令直接发下去。2.3 实时性预算机器人大模型比聊天大模型难在哪普通大模型服务对延迟的容忍度是秒级用户等两三秒出结果可以接受。机器人不一样一个控制周期可能是 10 到 50 毫秒错过这个周期机械臂可能已经撞上去或者抖起来。所以机器人侧不会让模型直接以 500Hz 输出电流环指令而是分成两个速率高层模型以 10 到 20 Hz 输出动作目标底层控制器以 500 到 1000 Hz 执行电机控制。如果 10 Hz 的规划周期出现一次 100 毫秒的延迟机器人就要在缺失目标的状态下运行一个周期表现出来就是动作卡顿。除了延迟绝对值更关键的是延迟抖动。平均延迟 80 毫秒不可怕可怕的是有时候 40 毫秒、有时候 150 毫秒。底层控制器无法预测下一帧什么时候到动作就容易发飘。因此机器人模型部署必须做固定周期调度给推理设置明确的时间预算并增加超时保护。这里也顺带说一句很多机器人项目使用 EtherCAT 作为底层总线和控制协议主站周期、从站配置和驱动模式如果没配好即使模型推理稳定运动控制周期照样会抖动。模型层跑得好不代表整机系统稳要分环节验证。3. 模型推理部署的精度、框架与硬件适配3.1 先看懂 FP32、FP16、BF16、TF32 再选型把大模型部署到 GPU 或昇腾这类 AI 加速卡上第一个要面对的问题就是数值格式。很多部署报错并不是代码写错而是精度格式选错导致溢出、精度劣化或算子不兼容。四个常见格式要分清FP32 是单精度浮点数32 位里 1 位符号、8 位指数、23 位尾数。它数值范围大、精度高是调试时的默认格式也是 embedding 模型和 reranker 模型输出评分时比较稳妥的选择缺点是显存占用和计算量是 FP16/BF16 的两倍。FP16 是半精度浮点数16 位里 1 位符号、5 位指数、10 位尾数。它计算快但指数范围只有 5 位最大值只有 65504。激活值一旦偏大就容易溢出训练时要配合 loss scaling推理时某些层也可能出现 Inf 或 NaN。BF16 也是 16 位1 位符号、8 位指数、7 位尾数。它的指数范围和 FP32 完全一样所以不容易溢出但尾数只有 7 位精度比 FP16 更低。对大模型推理来说BF16 往往是比 FP16 更安全的默认选择因为 Transformer 里大量激活值对范围敏感、对低精度尾数相对宽容。TF32 严格说不是存储格式而是 NVIDIA Ampere 及之后架构在 Tensor Core 上加速 FP32 矩阵乘法的一种计算模式。它把 FP32 的尾数截断到 10 位但保留 FP32 的指数范围累计用 FP32 完成。开启 TF32 后矩阵乘法速度提升明显精度介于 FP16 和 FP32 之间适合对精度要求不太极端的训练和推理场景。整理成表格更好对照数值格式位数指数位尾数位数值范围主要特点推荐场景FP3232823约 ±3.4e38精度高、内存大、通用性强调试、embedding、reranker、CPU 推理FP1616510约 ±65504计算快、范围小、易溢出训练配合 loss scaling、部分 GPU 推理BF161687与 FP32 相同范围大、尾数精度低大模型训练和推理默认选择TF3219 位有效计算810与 FP32 相同加速 FP32 矩阵乘、精度居中Ampere 及以上架构的 matmul 加速实际选型时还要考虑硬件算子支持。昇腾平台上 BF16、FP16 的支持情况和 NVIDIA 不完全一致要以当前 CANN 版本为准最好先用一个固定模型做对比实验再决定全量部署格式。3.2 vLLM 启动生成模型没问题embedding 和 reranker 却不一定vLLM 是当前很流行的大模型推理服务框架核心优势是 PagedAttention 显存管理、连续批处理、OpenAI 兼容 API吞吐量高。但它最初是为“decoder-only 生成式模型”设计的核心路径是“输入 prompt流式生成 token”。embedding 和 reranker 模型需要的是另一套语义embedding 要从最后一层隐状态里做池化CLS、mean 或 eos输出一个定长向量reranker 要把 query 和 doc 拼成一对输入输出相似度分数。这就解释了为什么在昇腾 910B A2 等平台上会出现“不能通过 vllm 启动 embedding 向量和 reranker 模型”的现象。vLLM 新版虽然开始支持--task embed、--task rerank这类参数但支持程度取决于两件事一是模型架构是否在支持列表里例如 BGE、bge-reranker 这类 BERT 架构并不一定被完整支持二是硬件后端是否实现了对应算子昇腾上要依赖 vllm-ascend 适配层算子覆盖范围落后于 NVIDIA 很常见。典型报错包括ValueError: Unsupported task type: embedNotImplementedError: the model class Xxx is not supported for embedding task昇腾后端算子编译失败提示某个自定义 op 不支持模型加载成功但调用/v1/embeddings接口返回 500处理思路是不要死磕“让 vLLM 干所有事”。vLLM 只负责生成式大模型embedding 和 reranker 用专门的推理服务跑。embedding 可以用 FlagEmbedding、BGE 官方脚本或 TEIreranker 可以用 TEI rerank 或独立封装服务。昇腾平台上可以检查 MindIE 对对应模型的支持情况能跑通再谈性能优化。3.3 昇腾 910B A2 上的落地注意事项昇腾 910B A2 这类国产加速卡在机器人公司和互联网公司里越来越常见但部署时的约束也比 NVIDIA 平台多。常见问题集中在依赖版本和算子支持上。环境层要确认四样东西匹配固件驱动、CANN 版本、torch_npu 版本、vllm-ascend 版本。任意一个版本对不上启动时都可能报莫名其妙的算子错误。设备状态用npu-smi info查看对应 NVIDIA 的nvidia-smi。跑大模型时建议先把生成式模型单独验证一遍确认 torch_npu 和 CANN 链路没问题再集成 embedding、reranker 等附加服务。昇腾上的算子编译有时会花费较长时间第一次启动慢不代表有问题但如果在日志里看到Unsupported op基本就是算子覆盖问题不要靠改代码硬绕过先查支持矩阵。显存方面昇腾平台同样存在碎片化问题长期运行 Reranker 或多路并发时要注意监控 HBM 占用。如果机器人系统还需要同时跑图像编码器、VLA 模型和底层视觉模型建议把不同模型拆到不同进程或不同设备上避免一个进程崩溃带走整机。4. 一镜到底 Demo 的验证体系从“能跑”到“可信”4.1 拆解 10 分钟里必须记录的指标一条录屏只能说明“这段视频里系统看起来正常”但系统是不是真的稳定要看指标。机器人 Demo 一镜到底时至少要把下面这些指标记录下来指标含义记录方式建议重点关注任务成功率目标是否完成人工打点或自动判据单一 Demo 不统计正式实验要多次人工干预次数是否有操作员接管日志事件一镜到底里应为 0但要诚实标记推理延迟均值/P99模型从输入到输出耗时每帧打点P99 比均值更能暴露抖动控制周期抖动实际周期与设定周期的偏差控制器日志抖动大会导致动作发飘上下文或 KV 缓存增长长序列运行后显存占用变化监控指标10 分钟会不会爆显存指令漂移任务是否偏离原意回放日志长时任务常见问题关节指令抖动相邻帧指令差值是否异常动作日志抖动大说明滤波或量化有问题记录指标不是为了发论文而是为了出问题时能回放定位。一次 10 分钟跑下来如果只有录屏没有日志任何异常都只能靠肉眼猜。4.2 录像以外的数据时序日志与回放一镜到底视频是给观众看的工程验证要的是和时间戳绑定的数据流。推荐记录四类数据。传感器数据要有统一的 UTC 时间戳相机的每一帧、关节的每个状态都要能对上否则回放时根本不知道模型看到的是什么。模型输入输出要记录 prompt 的版本、输入图像的 hash、输出的原始 token、反离散化后的目标值这样能判断某个失败是模型生成错还是后续处理错。控制器数据要记录实际发送给电机的指令和电机反馈的实际角度很多“看起来抖”的问题最终都出在这个环节。最后还要有人工标记把整个过程中任何一次人工接管、暂停、急停都记成独立事件。有了这些数据才能回答最核心的问题那一次成功是模型做得好还是外部条件刚好没触发失败分支。可复现的关键不是“把代码跑一遍”而是“把输入、状态、环境、日志全部对齐后再跑一遍”。4.3 可复现 Demo 检查清单发布或复盘一个机器人模型 Demo 前建议逐项检查下面这些点模型权重、推理框架、运行库的版本号是否全部记录能否用同一个 hash 重建环境。场景布置、物体位置、光照条件是否固定和训练数据是否有泄露。随机种子和采样参数是否固定温度、top_p 是否写入配置。录像、传感器日志、模型日志是否时间同步帧率和时间戳是否一致。有没有明确标记人工干预事件甚至包括“场景里有人远程准备接管”这种潜在干预。是否在多个场景、多个初始条件下重复测试而不是只跑一次。失败案例是否保留不能只挑成功案例。安全机制是否演示过比如模型输出非法指令时系统如何回退。这一套检查清单放在项目里比什么都管用。它能直接把“看起来酷炫的 Demo”变成“可以被质疑和验证的实验”。5. 最小实现用开源 VLM 动作头搭建“一个大脑”推理骨架5.1 示例定位与限制为了能直观理解共享大脑的接口设计这里给出一个最小推理链路骨架。它把图像、关节状态和指令一起喂给一个开源 VLM让模型输出关节目标值再通过一个适配器转成机器人指令。必须说明这不是