一、部署概述：先把“部署什么”说清楚

本文讨论的部署对象，是一个采用混合专家（MoE）架构的具身推理模型服务。它的典型形态是：总参数约 35B，但每个 Token 只激活约 3B 参数；输入不是纯文本，而是多路相机图像、深度信息、相机位姿、机器人本体状态与一句自然语言指令；输出也不是闲聊文本，而是结构化的推理结论——物体身份识别、空间关系判断、抓取可供性分析、任务进度估计、下一步动作建议。

部署完成后应达到的效果可以概括为四条：

1. 接口可用：机器人控制程序能通过稳定的 HTTP/RPC 接口提交“观测 + 指令”，在可预期的延迟内拿到结构化结果。
2. 时序可控：端到端延迟稳定，P99 不出现秒级抖动，不会拖累控制回路。
3. 能力可验收：上线前有一套可回归的验收矩阵，能证明模型在关键能力上没有退化。
4. 故障可回退：模型服务异常时，机器人侧有明确降级路径，而不是直接停摆或执行错误动作。

部署前必须理解的三个背景差异（这是具身模型部署与常规文本模型部署最不一样的地方）：

• 错误代价不对称。文本模型答错一句话，损失是体验；具身模型把“物体位置”判断错，损失可能是撞机、掉落或人身风险。因此安全校验和降级机制不是可选项，而是部署的一等公民。
• 显存需求与算力需求解耦。MoE 架构意味着要装下全部 35B 权重，但每次前向只计算约 3B 的激活量。这直接决定了“显存靠堆卡、吞吐靠批处理”的容量规划思路。
• 输入是多模态流而非单条请求。同一份权重，接云端离线评测和接产线实时控制，前置数据管线完全不同。

---

二、部署场景：不同场景下部署形态不一样

部署场景	推荐形态	延迟要求	部署要点
本体端侧 / 车载算力单元	本地进程或容器，量化后单卡部署	高（百毫秒级）	权重精简、内存占用受限、断网可用、功耗与散热
车间边缘机房	边缘云服务器 + 容器编排平台	中（数百毫秒）	与产线网络隔离、多机位并发、本地缓存
云端集中推理	容器平台 + 负载均衡 + 弹性伸缩	中低（秒级可接受）	多副本、批处理提升吞吐、按需伸缩控成本
混合部署（端侧小模型 + 云侧大模型）	端侧兜底 + 云端增强	分级	路由策略、降级链路、一致性口径
离线评测与数据回流环境	批处理任务 / 训练侧集群	无实时要求	与线上版本对齐、评测集版本管理

选择原则：先看延迟预算，再看数据合规边界，最后看单位成本。如果推理结果直接参与闭环控制，通常要把主推理放在离机器人最近的算力上，把大模型能力作为增强或复核环节。

---

三、架构与组件拆解

+--------------------------------------------------------------+
| 机器人本体 / 控制器（动作执行、安全围栏、急停）                |
+--------------------------------------------------------------+
                ↑ 结构化推理结果        ↓ 观测流 + 指令
+--------------------------------------------------------------+
| 接入层：API 网关 / 负载均衡 / 鉴权 / 限流 / 超时控制          |
+--------------------------------------------------------------+
| 数据管线：图像抽帧、深度对齐、位姿归一化、时序窗口拼接         |
+--------------------------------------------------------------+
| 推理服务层：模型运行时（权重加载、量化、批处理、KV 缓存）      |
+--------------------------------------------------------------+
| 支撑层：对象存储（权重/数据集） 向量或关系型数据库 日志 监控  |
+--------------------------------------------------------------+

组件职责与选型逻辑：

组件	作用	部署注意点
计算资源（云服务器 / 容器平台 / 端侧算力）	承载推理进程	GPU 显存是硬约束；关注卡间互联带宽
对象存储	存放模型权重、标定文件、评测集	大文件需校验和；跨区拉取要算带宽耗时
关系型数据库	任务记录、版本元数据	高频写入要评估连接池
缓存 / 消息队列	请求排队、结果异步回传	队列积压要有限流与丢弃策略
负载均衡 / 网关	流量分发、鉴权	长连接与超时设置要与推理耗时匹配
日志服务	结构化日志、审计	图像不落盘，元数据可留痕
监控告警	资源 + 服务 + 质量三层指标	必须包含“能力质量”指标，不只是 CPU
身份认证与密钥管理	接口鉴权、权重仓库凭证	最小权限；密钥不进镜像与代码库

---

四、前置准备清单

1. 资源与硬件

• 明确显存预算：能否单卡装下全部权重；不能则规划多卡张量并行。
• 确认卡间互联与主机内存带宽，MoE 模型的专家分发对内存/互联带宽敏感。
• 端侧部署还要确认散热、功耗上限和可用内存。

2. 运行环境与依赖

• 统一的运行时版本（语言运行时、驱动、加速库、推理框架），并在开发/测试/生产间锁版本。
• 依赖以锁定清单方式管理，禁止“latest”。
• 生产镜像一次构建、多环境复用，避免环境差异。

3. 模型权重与配置

• 权重来源、版本号、校验和、量化方式必须记录在案。
• 词表/预处理器与权重版本严格配对，错配会静默降智。
• 配置文件与代码分离，用环境变量注入敏感项。

4. 标定与数据依赖

• 相机内参、外参、手眼标定参数、坐标系定义。
• 时序窗口长度、抽帧策略、坐标系归一化约定。
• 这套约定必须与训练/评测阶段一致，否则线上指标无法与基线对比。

5. 网络与权限

• 机器人侧到推理服务的访问路径、端口、白名单。
• 若涉及跨区或跨网，评估专线/对等连接与延迟。
• 服务账号最小权限：只授予读取指定存储桶、写入指定日志集合的权限。

6. 基线准备

• 上线前必须先有一份“当前最优版本”的离线评测结果，作为灰度对比与回滚依据。

---

五、资源规划：把显存和算力分开算

这是 MoE 具身模型部署最容易踩坑的地方。推荐用下面这套通用估算方法（数值为量级参考，需以实测为准）：

显存 ≈ 权重占用 + KV 缓存 + 激活与临时缓冲 + 运行时开销

项	估算方式	35B 权重量级参考
权重（半精度）	参数量 × 2 字节	约 70 GB
权重（8 位量化）	参数量 × 1 字节	约 35 GB
权重（4 位量化）	参数量 × 0.5 字节	约 18 GB
KV 缓存	与并发数 × 上下文长度成正比	需按压测结果预留

算力侧：由于每 Token 仅激活约 3B 参数，单请求的计算量接近一个 3B 稠密模型，这意味着在显存装得下的前提下，吞吐主要靠提高并发与批处理效率来提升，而不是靠增加单卡算力。这条特性正是“不显著增加推理开销”的工程含义。

规格建议（通用）

• 单卡可容纳：优先单卡 + 高批并发，减少通信开销。
• 单卡不可容纳：多卡张量并行，卡数取能整除注意力头数的值，避免切分不均。
• 高并发云端场景：多副本 + 负载均衡 + 动态批处理，副本数按 P99 延迟目标反推，不要按平均值算。
• 端侧场景：优先量化 + 缩短上下文 + 限制并发为 1~2，用确定性换取稳定性。

容量预留：预留 20%~30% 显存作为峰值缓冲；预留一台同规格冗余节点用于滚动发布与故障切换。

---

六、部署流程：从环境初始化到灰度放量

Step 0　环境初始化
统一运行时与驱动版本，创建服务账号，配置日志与监控上报通道。此步的目的是消除环境差异——很多“线上才出现”的问题，本质是三套环境的依赖版本不一致。

Step 1　创建资源与打通网络
按容量规划创建计算实例、挂载存储、配置安全组与访问控制。先把“机器人侧能否连通服务端口”这件事验证掉，再往下走，避免后面把网络问题误判为模型问题。

Step 2　权重落盘与完整性校验
从对象存储拉取权重，逐一校验校验和与版本号，确认预处理器与词表匹配。

校验清单：
[ ] 权重文件数量与清单一致
[ ] 每个文件校验和匹配
[ ] 模型版本号 = 目标版本号
[ ] 量化配置与预期一致
[ ] 预处理器 / 坐标系配置版本匹配

Step 3　推理服务配置
加载权重、设定并行度、上下文长度、批处理与排队参数、超时与限流策略。先用极小并发启动一次冒烟测试，确认权重能正确加载且输出格式合规。

Step 4　启动与健康检查
健康检查必须包含“能加载且能推理”，而不只是“端口在监听”。仅监听端口的探活会在权重加载失败时给出假阳性。

Step 5　接入机器人侧数据管线
接入图像抽帧、深度对齐、位姿归一化，验证同一份观测在离线与在线两条链路上得到一致的模型输入。这一步的一致性直接决定了线上能力能否用离线评测结果来预测。

Step 6　小流量灰度 → 全量
先在单台机器人或非关键工位放量，观察延迟与输出分布，再逐步扩大。

通用配置片段（示意）

service:
  name: embodied-reasoning-inference
  replicas: 2
  port: 8080
  health_check:
    path: /health/ready          # 需确认权重已加载
    interval_seconds: 10
    timeout_seconds: 3
    failure_threshold: 3
runtime:
  parallel_degree: 2             # 与可用卡数、注意力头数对齐
  max_context_tokens: 8192
  max_batch_size: 16
  queue:
    max_pending: 64
    timeout_seconds: 5
    overflow_policy: reject      # 溢出直接拒绝，不排队拖垮控制回路
request:
  timeout_seconds: 3
  temperature: 0.1               # 结构化输出建议低温度
  output_schema: json            # 强制结构化输出
  retry:
    max_attempts: 1              # 具身场景慎用重试

---

七、关键配置说明与风险点

配置项	作用	风险点
并行度	决定多卡切分方式	设置不当会导致加载失败或显存不均
量化方式	降低显存占用	过度量化可能损伤空间与物理关系判断精度，需回归验证
最大上下文	时序窗口长度	过长会显著增加 KV 缓存与延迟
批处理大小	提升吞吐	过大会拉长单请求排队时间，P99 恶化
队列上限与溢出策略	保护服务与实时性	无限排队会让控制回路延迟雪崩
超时	防止请求堆积	与机器人控制周期不匹配会频繁超时
重试次数	提升成功率	具身场景下重试可能造成动作重复执行，应默认关闭或配合幂等
采样温度	输出稳定性	结构化结论场景应低温并强制 schema
优雅停机	滚动发布不中断	需等待在途请求完成，并先从负载均衡摘除
限流阈值	防止过载	阈值过低会误伤正常任务

---

八、与机器人本体的集成部署

具身模型的部署不止于“服务起来”，还包括把输出安全地接到执行端。

输入侧
统一坐标系与时间戳，做多相机图像对齐与深度配准，保证送给模型的观测在时间上属于同一时刻。时间戳错位的观测会让模型把“物体没动”误判为“相机在动”，反之亦然。

输出侧
必须加三道校验：

1. 结构校验：字段、枚举值、类型符合预定义 schema。
2. 语义校验：动作是否在当前场景的可执行集合内；关节限位、力控上限、工作空间边界。
3. 安全校验：物理隔离围栏、急停通路、任务超时兜底。安全约束应实现为独立于模型的硬规则，不能被模型输出覆盖。

降级策略
当推理服务不可用、超时或输出校验失败时，按预设优先级降级：先退到基于规则的传统感知与规划模块，再退到“停止并保持”，最后才是请求人工接管。任何情况下，降级路径都不能依赖模型自身“知道自己不确定”。

---

九、上线验证：既要验证服务，也要验证能力

1. 服务层验证

• 健康检查通过，就绪探针返回成功。
• 接口连通、鉴权生效、限流按预期触发。
• 结构化输出 100% 通过 schema 校验。
• 日志无异常堆栈，监控无告警。

2. 能力回归验证（部署验收的核心）

不要只看总分，要建立按能力维度拆分的验收矩阵。可参考业界对具身推理能力的通用拆解方式，把能力划分为实体识别、空间关系、时序变化、物理规律、可供性、任务理解、社会情境、证据引用等大类，并在其下细化二级能力项；同时把推理方式、输入形式、输出形式作为独立维度分别标注，避免维度混用导致的指标重叠。

验证维度	典型扰动/用例	通过标准（示例）
物体身份稳定性	视角旋转、遮挡、光照变化	身份判定一致率不低于基线
相机运动辨识	仅相机移动、场景静止	不误报物体位移
任务进度判断	中间态、已完成、未完成	与人工标注一致率不低于基线
空间关系	上下、内外、遮挡、距离	关系判定准确率不低于基线
物理合理性	悬空、穿透、支撑关系	不产生违反常识的结论
复合任务	主能力 + 辅助能力联合判断	联合任务单独统计，不并入单项

关键点：对每一条能力都要有“上线前基线值”，并与旧版本同集对比。仅看整体均分，很容易出现“总分上涨、关键能力回退”的情况，而这恰恰是产线上最危险的形态。

3. 端到端与稳定性验证
跑完整任务闭环，记录端到端延迟分布（关注 P95/P99 而非均值）、连续运行时长、显存增长曲线（排查泄漏）、错误率。做一轮压测确认过载行为是“快速拒绝”而非“缓慢雪崩”。

4. 灰度与回滚
按机器人个体或工位灰度，设定明确回滚触发条件：P99 延迟超阈值、schema 校验失败率上升、关键能力指标下降超过设定幅度、出现安全相关异常。回滚要能一键切回上一版本权重与配置，且权重与配置版本需成对管理——只回滚权重不回滚配置，是常见的二次故障来源。

---

十、常见问题与排查

现象	可能原因	排查思路
加载权重时显存不足	未量化、并行度设置不当、KV 缓存预留过大	核对权重占用估算；降低上下文与并发；调整切分
服务已监听但请求失败	权重尚未加载完成，健康检查过宽	就绪探针改为校验模型状态
P99 延迟远高于均值	批处理排队、队列积压、卡间通信瓶颈	观察队列长度与批大小分布，压测定位瓶颈
输出格式不稳定	温度过高、未强制 schema、预处理器版本不匹配	降低温度、启用结构化输出约束、核对预处理器
线上表现与离线评测差距大	数据管线不一致（坐标系、抽帧、时间戳）	对同一观测做输入比对，逐步对齐预处理
推理变“笨”	量化精度损失、版本错配、词表不匹配	对比不同量化版本的回归结果
偶发超时后动作异常	开启重试导致动作重复	关闭重试或引入幂等键与状态机
显存随时间增长	缓存未释放、连接未回收	长时间运行观察内存曲线，检查资源释放

---

十一、运维与优化

监控指标要分三层，缺一层就会出现“看着都正常但机器人在犯错”：

1. 资源层：显存占用与碎片、利用率、温度、主机内存、网络带宽。
2. 服务层：QPS、延迟分布、队列长度、错误率、超时率、限流触发次数、副本健康度。
3. 质量层（具身场景特有且最关键）：结构化输出合规率、关键能力抽样准确率、低置信度样本比例、降级触发次数、人工接管次数。

稳定性保障
健康检查 + 自动重启 + 优雅停机 + 限流 + 超时 + 副本冗余；关键工位建议双副本跨可用区部署；权重与配置纳入版本管理，支持快速回滚。

能力闭环运维
把线上采集到的失败样本按能力维度归类，识别短板能力项，再定向补充与调整训练数据配比，而不是盲目扩大数据规模。已有研究表明，仅调整不同数据域的训练权重就会明显影响下游表现，因此数据配比调整应作为一次正式的版本变更，走回归评测与灰度发布流程。

安全与合规
接口双向鉴权、传输加密、密钥托管、日志脱敏（图像与视频建议不落原始数据，仅保留元数据与哈希）、审计留痕、最小权限服务账号、定期凭证轮换。

成本控制

• 按延迟目标而非峰值估算配置副本数，配合定时或指标驱动的弹性伸缩。
• 离线评测与在线服务分池，避免批任务抢占线上资源。
• 对象存储配置生命周期策略，清理中间产物与过期数据集副本。
• 定期治理闲置实例与超额预留，按实际 P95 负载而非平均值做容量复核。

---

十二、总结

这类具身推理模型的部署，难点不在“把服务启动”，而在于三点：一是资源规划的错位风险——MoE 架构下显存要装下全部参数、算力却只消耗激活部分，容量估算必须显存与算力分开算；二是输入输出的一致性——只有线上预处理与离线评测完全对齐，验收结论才对生产有意义；三是安全边界的独立性——物理世界的安全约束必须做成模型之外的硬规则，并配套明确的降级链路。

关键动作可以压缩成一条主线：统一环境 → 校验权重 → 配置并行与批处理 → 健康检查含推理验证 → 对齐数据管线 → 按能力维度做回归验收 → 小流量灰度 → 三层监控运维 → 失败样本回流驱动数据配比迭代。把这条主线跑通，模型的能力提升才能稳定转化为机器人可信赖的实际行为。