这两年只要聊到具身智能绕不开一个话题端侧小模型和云端大模型到底哪条路线才是正经方向。我身边搞机器人的朋友有的把宝全押在端侧觉得响应快、可控、离线也能跑也有的直接接云端API图省事、效果好、迭代快。两边吵得不可开交但真要落地一个机械臂抓取任务、或者一台双足机器人走楼梯问题远比想象中复杂。这篇文章我不站队只把我实际调模型、跑部署、看现场的经验摊开来讲顺便聊聊这两条路线背后的技术账、成本账和工程账希望能给正在选型或入坑具身智能的朋友一点参考。先交代一下背景我近几年主要在做机械臂和移动机器人的感知与控制方案接触过从几百万参数的端侧小模型到千亿级云端大模型的不同组合也踩过不少部署和联调的坑。具身智能和纯文本大模型最大的区别在于它必须处理物理世界的连续动作、传感器噪声和高实时性约束而且要长期在真实环境里稳定运行。这就导致很多人把“大模型跑在哪”当作核心问题来讨论但真正决定成败的往往不是模型本身而是整个系统如何分工。1. 路线之争的本质不是“谁能取代谁”而是“谁解决什么问题”很多讨论一上来就问“端侧强还是云端强”这其实是一个伪命题。具身智能的场景太多样了工业分拣、家庭服务、医疗辅助、巡检勘探每个场景对时延、隐私、成本、泛化能力的要求都完全不同。端侧小模型和云端大模型本来就在解决不同层面的问题放在一起比输赢就像问“发动机和方向盘谁更好”一样没有意义。1.1 端侧小模型的定位贴身执行与实时闭环端侧小模型顾名思义是把模型部署在机器人本体上的计算单元上可能是嵌入式板卡、边缘小主机或者机器人控制器自带的NPU。它的核心优势是快不用上传数据、不用等网络、不用看云端脸色所有推理都在本地完成。以机械臂抓取为例一个典型的视觉引导动作需要在几十到一两百毫秒内完成“看到、理解、规划、下发”的闭环。如果这一步依赖云端从图像采集、压缩编码、网络传输、云端推理到结果下发至少需要300毫秒以上复杂模型甚至要一两秒而在产线上这已经足够让传送带多走好几个工位了。端侧模型哪怕精度差一点但响应时间是硬性要求这一条就足以解释为什么很多工业场景至今仍然在用传统视觉算法和小模型不是大家不想用大模型是真的用不起这个延迟。另一个关键因素是可靠性。工厂、仓库、野外这些地方的网络环境远没想象中稳定。我见过一个客户在厂区部署AGVWi-Fi覆盖看着满格但一台机器人靠近金属货架密集区就掉线云端指令下不来整条产线停摆。这种场景下端侧是底线云端是锦上添花顺序不能反。1.2 云端大模型的优势大参数量带来的泛化与推理能力云端大模型的价值也不难理解参数量大、训练数据广、能处理复杂语义和跨任务迁移。具身智能最大的痛点之一就是泛化——训练时见过的场景和物体有限但真实世界是开放的。比如家用机器人要能听懂“帮我把茶几上那个白色的东西拿过来”这句话里涉及语义解析哪个是白色的、物体定位茶几在哪、空间关系理解茶几上、动作生成走过去抓起来。这种开放的指令理解能力端侧一个几B的小模型确实很难做到而云端大模型依托海量数据和更高算力能直接把“语言理解视觉感知动作规划”拉通。另一个云端独有的价值是持续进化。端侧模型部署之后很难更新但云端可以隔几天就换一版更强的模型机器人只要联网就能“变聪明”。对很多创业团队来说云端方案大大降低了技术迭代成本不需要每改一次模型就跑到现场去刷机调试这也是一条非常现实的技术账。1.3 为什么现在这个问题突然变得重要最近一两年具身智能的模型能力上来了很多团队开始做真机落地而不是停留在仿真环境。一旦进入量产和规模化阶段算力成本、功耗、体积、时延、网络依赖这些工程约束就会浮出水面。端侧和云端的分工问题不再只是学术讨论而是直接决定产品形态、硬件成本和商业模式。我自己见过不少团队Demo阶段用云端大模型跑得很好一进入POC就卡住了客户要求数据不出厂区、产线断网必须可用、机器人响应不能超过200毫秒。这些硬约束一出来云端方案就只能退居备份端侧小模型反而成了主角。所以路线之争背后其实是“技术能力”和“工程现实”之间的拉扯。2. 端侧小模型的真实能力能做什么不能做什么端侧模型被很多人低估也被很多人高估。低估的人觉得“几百MB的模型能有什么智能”高估的人觉得“手机都能跑大模型了机器人肯定也行”。真实情况处在两者之间端侧模型的定位不是无所不知而是在物理约束内把一件事做快、做好。2.1 当前端侧小模型的能力上限先说结论以现在的硬件水平端侧小模型指1B~7B参数量、经过量化和剪枝之后部署在边缘设备上的模型在具身智能里能胜任三类任务感知类任务目标检测、语义分割、姿态估计、异常检测。这些任务对推理能力要求不高但对实时性和稳定性要求极高是端侧的强项。局部动作规划比如机械臂的动态避障、移动机器人的局部路径规划。小模型也能学会“看到障碍物就往左偏一点”这类策略不需要太强的推理能力。嵌入式语义理解理解固定的指令模板比如“抓红色方块”“去充电桩”“回到待机位”。这种封闭集合里的指令理解小模型完全可以搞定。但如果任务超出这个范围比如遇到一个训练集里没有的物体、需要多步推理的复杂指令、或者需要结合环境上下文做开放式决策端侧模型就会明显力不从心。我在一个机械臂抓取项目里试过用2B参数的模型做端侧部署目标识别和抓取点在标准光照和简单背景下没问题但一遇到透明容器、反光金属或堆叠遮挡识别准确率直接从90%掉到60%以下。后来只能把“难样本”送到云端大模型做二次确认端侧负责快速初筛云端负责疑难杂症效果才算能看。2.2 端侧部署的技术关键量化不是万能的端侧模型能跑起来主要靠两个手段模型压缩和硬件适配。量化是目前最常用也最成熟的压缩方式把模型权重从FP16压缩到INT8甚至INT4体积可以缩小3到7倍推理速度大幅提升。但量化不是没有代价精度损失在敏感任务上会被放大。举个例子一个抓取模型需要输出毫米级的抓取点坐标如果用INT4量化坐标精度可能从正负2毫米恶化到正负5毫米以上对于小尺寸零件来说直接就是抓不住。我后来采用的是混合量化视觉部分用INT8保留精度语义部分用INT4压缩体积实测下来在精度和速度之间拿到了一个比较好的平衡点。硬件适配方面如果你打算在机器人本体上跑模型优先认准带NPU的芯片平台比如瑞芯微RK3588、地平线旭日系列、英伟达Orin Nano等。不同平台的算子支持和性能差异很大一个模型在这块板子上跑20毫秒换一块板子可能要200毫秒不能只看理论算力。我踩过的坑是直接按PyTorch的算子逻辑写模型到了NPU上大量算子不支持被迫重写。建议在选型阶段就把目标硬件确定下来用硬件厂商的推理框架做模型转换而不是回过头来适配。2.3 端侧小模型的不可替代优势说几个只有端侧才能做到的事情这些都是云端方案无论如何都绕不开的硬指标离线可用机器人不是每时每刻都有好网络地下车库、金属车间、偏远野外断网是常态。端侧模型保证了最基本的可用性。实时闭环做机器人控制的人都知道“感知-决策-控制”时延每增加一毫秒系统稳定性都可能出现质变。端侧推理消除了网络这个最大不确定性。隐私与安全很多工业场景客户明确要求图像和数据不能出设备本地处理是唯一合规路径。这已经不是技术选择而是合同要求。低边际成本云端API按调用计费一个日夜运行的机器人一天可能调用几万次算下来一年费用惊人。端侧部署是一次性硬件成本长期看更划算。3. 云端大模型的真正价值为什么不能只靠它也不能没有它说完了端侧的好处再回过头看云端。云端大模型的问题很多——延迟高、依赖网络、成本不可控但它依然在具身智能的版图中占据核心位置。原因也很简单有些事端侧真的做不到。3.1 云端大模型解决的是“理解”和“泛化”问题具身智能最终目标之一是让机器人像人一样适应开放环境。人在家里、办公室、医院能应对无数种没有预设过的场景靠的不是背答案而是举一反三的能力。当前端侧小模型受限于参数量和田字训练资源这种开放式迁移能力还很弱。云端大模型在语言理解、常识推理、复杂任务拆解方面的优势是端侧短期内无法追赶的。我在一个服务型机器人项目里做过对比测试。同样一条指令“地上有个洒了的果汁帮我处理一下”端侧小模型只能识别出“果汁”和“地面”然后输出“拿起拖把”这种单一动作云端大模型能更进一步判断果汁是液体需要吸水材料、要避开滑倒风险、先清理再擦干、用完的清洁工具要复位。这种多步推理和常识组合能力说实话只有大参数量模型才跑得出来。再一个价值是数据集作用。端侧小模型不是天生就小而是从大模型蒸馏出来的。大模型在云端完成训练和蒸馏端侧拿到的是“压缩后的学生模型”相当于大模型在现实任务里积累的经验以参数形式固化到机器人本体。这样一来云端大模型的意义就不只是运行时充当大脑更是端侧模型的“老师”和“训练师”。3.2 云端方案的现实问题延迟、带宽与成本云端大模型不是没有代价尤其当它用在实时控制链路上时问题会被放大。第一个是延迟。我自己实测过典型的端到端链路机器人拍照→上传云端→云端推理→结果返回弱网环境下至少500毫秒好的网络也要150至200毫秒。这个数字对“对话”场景没问题对“避障”场景就太漫长了。大多数运动控制要求10到50毫秒内做出反应云端在这个层面天然不达标。第二个是带宽。机器人是传感器怪兽一台带多路相机的机器人每秒产生几十兆到上百兆数据全部实时上传不现实——不仅带宽扛不住流量费也扛不住。更合理的做法是端侧先做数据筛选和压缩只把关键帧或异常事件上传云端让云端做深度分析再下发策略。第三个是可靠性。云端服务一旦故障或者网络抖动机器人就变“僵尸”了。即便做了断网续传和本地缓存也无法保证所有情况下的无缝切换。我之前和一个做仓储物流机器人的团队聊过他们上过云端策略后来因为一次云服务商故障导致三十多台机器人同时停摆从此以后云端只做远程监控和数据分析控制决策全部回归端侧。3.3 云端与端侧的合理协作方式不是二选一而是分三层经过几次项目打磨我逐渐形成了自己的分层思路现在基本沿用这种架构端侧实时层负责控制闭环、状态感知、安全兜底。所有毫秒级响应的任务都在这一层完成模型小、速度快、离线可用。边缘近端层放在本地网关或边缘服务器上的中等规模模型10B~30B负责跨设备的协同感知、短时预测和局部决策比端侧强又比远端快。云端大脑层大参数量VLA或多模态模型负责长期规划、开放语义理解、技能学习与更新、跨场景经验沉淀。它不直接控制机器人但会生成规则和策略定期下发到端侧。这个架构的好处是把“快”和“聪明”分开处理。端侧保证“饿不死”云端负责“吃得更好”。用技术语言说就是“近端控制、远端认知”这也是我觉得短期内最务实、最能落地的解决方案。4. 路线选择的决策框架从六个维度判断你的项目该偏重哪边每个项目情况不同我总结了一个六维度决策框架专门用来判断具身智能项目应该偏重端侧还是云端。照这个框架过一遍基本能形成初步判断。4.1 关键维度对比速查表维度倾向端侧小模型倾向云端大模型响应时延要求10~100毫秒级响应控制闭环可容忍数百毫秒以上延迟网络环境网络不稳定、存在断网风险网络稳定、带宽充足数据敏感性涉及隐私、商业秘密数据不出设备数据脱敏后可外传算力与功耗供电有限、发热敏感、空间受限有充足的机柜空间与供电泛化/语义难度任务封闭、指令集合固定、场景重复开放场景、自由指令、多步推理商业模式硬件出售为主软件持续迭代周期长SaaS订阅、API调用按量计费这六个维度不是并列的优先级有先后。第一看时延如果任务要求毫秒级响应直接先定端侧为主第二看网络只要存在断网风险云端就不能作为唯一大脑第三再看数据约束和商业模式。很多团队栽跟头就是因为在选型阶段只盯着“模型能力强不强”忽略了这些工程约束。4.2 典型场景的选型建议举几个我实际接触过的案例工业质检与分拣固定产线、固定环境、任务封闭、要求高稳定性这种场景选端侧为主云端做模型更新和异常样本分析。家庭服务机器人指令开放、环境多变、但涉及隐私这种场景适合“端侧执行云端理解”的混合架构云端管语义端侧管动作中间通过本地网关衔接。巡检机器人往往在野外或地下环境作业网络基本不可靠但又需要较强的环境感知和异常判断能力。这种场景必须以端侧为主云端只能在有信号时同步数据。导览/客服类人形机器人动作简单、交互为主实时控制压力不大可以以云端大模型为核心端侧只做基本的运动控制和本地语音唤醒。4.3 成本测算的实操思路成本和资源规划也是路线决策的重要组成部分特别是自建模型环节很多人低估了这一点。如果你的团队想自己训练端侧模型而不是用开源模型GPU成本是一个绕不开的账。以微调一个7B模型为例用单张消费级24G显卡配QLoRA方案大约只需要15到20G显存就能在一个晚上完成多轮全量训练这种方式适合小规模验证或快速换场景迭代。但如果要做全参数微调或从零预训练就得考虑至少4张以上A100/H100级别的集群配置机器租赁费用一个月几万起步。很多人好奇为什么正规的开源模型微调教程和云端训练方案贵核心成本基本都耗在不间断GPU占用、数据清洗和多轮验证上。对于绝大多数机器人公司我更建议的策略是开源模型打底少量业务数据微调优先走端侧部署路线云端大模型在初期用API方案顶上等业务跑通了再考虑自建大模型或私有化部署。一句话不要为了“拥有大模型”而做大模型你的目标是机器人能用而不是算法榜单有名次。5. 实操经验从机械臂项目看端云协同部署怎么做前面讲了这么多理论最后分享一个我自己做过的小项目把端云协同的思路落到具体实现上也顺便回答一些朋友常问的部署细节问题。5.1 项目背景与整体架构项目目标是一台六轴机械臂要在一条模拟产线上完成“识别物料→抓取→按颜色分类放置”的任务。产线上有三类不同颜色和形状的物料偶尔会出现未知物体需要告警。整体约束是控制闭环必须在100毫秒内完成网络时有波动IPC摄像头画面不能完全上传云端。架构上我是这样拆的端侧控制器是一块RK3588开发板跑一个2B量化的视觉模型负责物料识别和抓取点检测时延控制在50到80毫秒。本地网关跑一个7B的语义模型负责把“红色圆片放到左侧”“蓝色方块放到中间”这类指令解析成结构化动作序列时延约200毫秒。云端接了一个开源的多模态大模型只在“未知物体出现”或“连续两次抓取失败”时调用让它描述当前画面并给出处理建议时延允许2到5秒。这个分工很明确常规动作全部端侧消化未知异常才交给云端判断。实测下来整个产线日运行几百次抓取端侧完成了95%以上的决策云端只起到了兜底和督学的作用。5.2 端侧模型部署的步骤与关键细节如果你也想复现这种方案端侧部署的流程大致是四步模型转换。把训练好的PyTorch模型先转成ONNX通用格式再用目标硬件厂商的推理框架转成专用格式。以RK3588为例对应工具是RKNN-Toolkit。这里要注意转换不是一次成功可能因为算子不兼容反复调整最好在转换前就用厂商文档确认算子支持清单。量化校准。用真实场景的图片做量化校准集而不是用原始训练集这样能显著降低量化精度损失。我吃过这个亏用训练集校准的量化模型到了现场反光场景下误检率直接翻倍。推理优化。开启动态batch、内存复用、多线程优化。实测下来这几项加起来能把推理速度提升30%到50%相当于不花钱多买了一块算力板。异常兜底。端侧一定要做模型置信度门槛低于阈值就触发云端请求或者走保守策略。这个门槛值得反复测试设太高会把简单问题复杂化设太低又会导致误判延误。5.3 云端与端侧联调的常见坑最后说几个联调阶段最容易踩的坑都是亲身经历时间同步。如果端侧和云端要融合判断同一个事件两边的时间戳对不上分析就是一团乱麻。部署前先统一NTP时钟同步最好再在数据链路里带上本地时间戳。数据格式不一致。端侧做图像预处理时用的尺寸、归一化参数如果和云端训练时不一致模型表现会大打折扣。这个看似小问题但排查起来特别费时间建议一开始就把预处理流程封装成统一模块。网络切换重连。机器人移动过程中网络切换云端连接会自动断开如果代码不做重连机制和消息补发会出现指令丢失。我踩过这个坑后在端侧加了一个“指令序号确认回执”的机制基本解决了丢指令问题。模型版本管理。端侧云端各一套模型两边迭代不同步会出现行为不一致。建议在系统里引入模型版本号每次请求或上报都附带版本信息方便排查问题。如果要用开源工具搭建云端服务vLLM和Ollama是两条常见路径。vLLM吞吐量高、支持高并发适合多机器人同时调用和复杂推理场景但配置复杂度偏高Ollama上手门槛低一条命令就能启动本地模型服务适合快速验证和中小规模部署。按我的习惯如果只是联调测试先上Ollama如果要做量产验证再迁到vLLM并通过Higress这类网关管理多个模型服务的路由和负载均衡这样后续接入不同开源模型时不需要改业务代码。6. 谁会是最终的赢家我的判断和理由回到最开始的问题端侧小模型和云端大模型谁会赢经过这些年的实践我的判断是这样的短期看云端更强长期看端侧会赢下大多数场景但最终的形态一定是端云协同而不是任何一方的单点胜利。这个判断基于三个理由。第一物理世界的实时性要求决定了端侧不可或缺。机器人要进入工业、家庭、商业等真实场景就必须在本地完成大部分实时决策。云端可以很聪明但“聪明却来不及用”在产品层面就是无效的。第二随着芯片算力提升和模型压缩技术发展端侧的“能力天花板”正在快速抬高。几年前端侧只能跑几MB的小模型现在几百MB到几GB的中等模型已经能在嵌入式平台上流畅运行。按照这个趋势未来会有越来越多的模型能力下放到端侧云端负责的反而是更高层的抽象推理和长期学习。第三端侧数据的规模效应会形成新的壁垒。有意思的一点是分布式机器人在端侧产生的真实交互数据经过脱敏和回流后可能是“具身智能”这一轮技术迭代中最稀缺的训练燃料。谁能让端侧模型在真实环境里稳定服役并可持续地采集数据谁就拿到了下一轮进化的入场券。所以我的建议很明确不要纠结“端侧还是云端”这个二选一的问题而是尽快建立一个“端侧执行、云端认知、数据回流”的协同体系。在小规模场景里用端侧模型打底按需接入云端大模型等数据和业务量积累到一定程度再考虑自建或者微调自己的模型。这条路可能不是最炫的但在我看过的项目里是最稳、最能落地、也最有可能真正跑通商业闭环的。回到我个人的体会上这几年最大的感触是搞具身智能算法只是冰山一角真正拉开差距的是工程化能力——你能不能把模型塞进一块功耗5瓦的板子里、能不能在弱网环境下保全系统可用性、能不能让机器人在没人盯着的时候稳定跑一周不宕机。端侧小模型和云端大模型说到底都只是工具箱里的不同工具最终比拼的还是谁更懂物理世界、更能解决真实问题。