最近大半年我一直在折腾一套东西把具身机器人的大脑从云端往机器人本体上搬。说白了就是让机械臂和轮式底盘在不联网、不依赖服务器的条件下自己完成感知、规划、操作这一整条链路。上周我把一套Agentic native架构的端侧推理引擎完整跑通了从视觉输入到机械臂执行全程本地推理实测结果比预期强不少但踩坑也多。这篇把整个过程和盘托出给正在做具身智能、或者打算入局具身智能学习路线的人一个参照。先说结论性的东西这次实测用的是六轴协作机械臂加一套轻量级计算平台跑的是多模态感知加操作规划的一体化模型。引擎是专门为Agentic native设计的目标检测、实例分割、动作生成管线全部在设备端完成整个闭环的端到端延迟控制在300毫秒以内物体抓取成功率在标准桌面场景下稳定在90%以上。这个数据放在云端方案里不算惊艳但放在端侧、放在真机上意义完全不一样。下面拆开讲。1. 具身机器人跑推理为什么本地是硬门槛先聊一个很多人忽视的问题具身机器人为什么非得在端侧跑推理直接连云端不是更省事吗我之前也觉得云端算力强、模型大、效果肯定更好。直到我把一个简单的物体抓取任务从云端迁到本地测试才彻底明白端侧不是可选项而是必选项。第一个原因是延迟不可控。控制一个机械臂去抓一个移动的物体整个闭环的每一毫秒都算数。视觉传感器采集图像传输到云端云端推理再把结果传回来这趟来回在实验室网络环境下要80到150毫秒。听起来不多但加上相机曝光、图像编码、执行器响应端到端轻松突破400毫秒。对于一个正在从传送带上滑过的工件400毫秒的延迟意味着机械臂已经错过了最佳抓取窗口。具身智能对实时性的要求远高于普通对话、生成类AI这是物理世界给的时间约束。第二个原因是稳定性。工厂车间、仓储物流、户外巡检这些场景的网络环境根本没有保证。信号抖动一次云端推理超时一次机器人的行为就是一次不可预估的停顿。做机器人的朋友都懂不可预估的停顿意味着安全隐患轻则任务失败重则撞坏工件甚至伤到人。这一点上端侧推理有天然优势计算在本地网络不参与决策回路行为的一致性就能保证。第三个原因更隐性是数据隐私和合规。具身机器人在现实环境里采集的图像包含大量环境信息有些是产线布局有些是仓储库存有些甚至涉及人员活动。这些数据全部传云端对很多企业来说是不可接受的。端侧推理意味着原始数据不出设备直接完成处理这是架构层面的安全兜底。所以端侧推理引擎这几年在具身智能领域备受关注本质上不是在追求更快的推理速度而是在追求可控的延迟边界、稳定的行为表现和数据私域化。这三个属性缺一样具身机器人就不适合走出实验室。2. Agentic native的真相不是一个模型是一套循环架构Agentic native这个词最近在圈子里很火但很多人的理解停留在表面认为它代表AI能自主做决策。实测之后我的理解更具体了Agentic native是一种系统架构理念它要求推理引擎从底层就把感知、决策、行动当作一个完整的循环来设计而不是拼接三个独立模块。传统做法是感知一个模型、规划一个模型、控制一个模型三个模型用中间数据串起来。这种管道的最大问题是信息丢失。感知模型输出的bounding box和类别已经把视觉信息抽象掉了一大半规划模型拿着这堆抽象结果去算轨迹它根本看不到场景里的几何细节。等到执行模型走完流程你发现机械臂把杯子抓翻了因为感知阶段盒子框得不精确规划阶段轨迹就没避开杯口边缘。这不是模型能力不行是架构在中间环节就把信息浪费掉了。Agentic native的做法不一样。它在底层预留了多模态token空间视觉特征、文本指令、动作编码都在同一套表示空间里流转。感知阶段精修的feature不是扔给下一个模块而是保留在token流里持续参与后续的决策。规划模块可以直接访问高分辨率的视觉特征动作生成也拿得到这些信息。整个流程像一个连续对话的智能体而不是一个流水线上的三班工人。这次实测的引擎在架构上有几个明显特征。它的语义理解接口和决策循环是同一个数据通路没有中间序列化、没有格式转换。用户下发指令后引擎会先生成一个内部目标表示然后这个表示会一直存在指导整个任务直到完成或者被新指令显式替换。分配完子任务的每个动作片段之后引擎会把实际执行结果反馈回表示层形成一个闭环。这套机制让我第一次直观理解了原生和包装的区别。如果只是把prompt叠加、工具调用这些Agent框架的能力做出来那还是典型的包装路线真正Agentic native从张量形状、内存规划到算子调度都围绕多轮闭环设计这不是插件能补出来的东西。具身机器人需要的是动作连续性和环境适应性前一轮的错误动作必须能通过下一轮感知修正这要求推理引擎原生支持持续运行而不是每次调用重新初始化状态。3. 实测平台搭建与基准设计机械臂加边缘GPU的真实工况说清楚平台配置才能讨论数据。这次实测用的机器人本体是一台六轴协作机械臂加上一个电动夹爪末端装了深度相机。算力平台用的是带边缘GPU的嵌入式工控机整机功耗上限大约是25瓦。25瓦大概是什么概念比很多游戏笔记本在待机时的功耗还要低塞在机械臂底座里完全不需要额外散热改造。模型侧用的是针对动态场景优化的多模态推理网络。要说明的是它并非超大参数级别的通用模型而是面向机器人操作场景进行结构精简的专用模型包含视觉塔、语义融合层和动作解码头三大部分。整套模型用INT8量化后体积约为1.8GB完整加载进显存后剩余空间仍然很宽裕。我设计了一套比较接近真实工况的测试基准。标准桌面场景桌面上随机放置三个物体系统拿到自然语言指令后需要识别目标物体、规划抓取姿态、避开障碍物路径然后完成抓取。每次任务限定在15秒内完成超时记为失败。总共跑100次记录成功次数、单次决策时延、内存峰值等指标。另外还有一项是连续通断压力测试任务连续跑2小时看稳定性。同样的任务我也用纯云端方案跑了一组对比。云端方案的模型版本完全一样只是推理部署在数据中心侧通信走局域网。这样对比的意义在于算力基准相同的情况下单纯看端到端链路谁更稳。搭建环境时有一个细节值得强调端侧引擎对传感器的适配比想象中敏感。深度相机输出的点云数据在Tensor Core上做采样和编码时如果采样密度和模型训练时不匹配推理精度会明显掉。解决办法是在引擎外部加了一层数据适配正则化把不同相机的位深、分辨率、噪声特征统一映射到模型预期的分布区间。这一步不做再好的模型也白搭。4. 实测数据拆解延迟、内存和抓取成功率到底什么水平先放实测数据。标准桌面抓取任务端侧引擎方案端到端平均时延280毫秒包括相机采集20毫秒、目标检测和姿态估计120毫秒、轨迹规划60毫秒、动作执行80毫秒。云端方案端到端平均时延440毫秒其中纯计算只有100毫秒剩下的340毫秒全部消耗在数据传输和多次同步上。这个对比已经说明问题了云端的计算确实强但延迟的瓶颈根本不在计算在于通信。100次抓取任务端侧方案成功93次其中有3次失败是机械结构本身的夹持滑动真正算法层面的失败只有4次。云端方案成功89次失败里有6次是因为端到端延迟导致抓取时机偏移。数据表明在同样的抓取策略下延迟就是成败的决定性变量之一。模型的显存峰值约为5.2GB传统上大家会认为边缘GPU跑多模态模型很吃力但实测下来1.8GB的INT8量化模型配合引擎的分层加载机制把峰值压在了非常可控的范围。分层加载的意思是视觉塔常驻显存语义融合层按需加载动作解码头在推理前才调入。这个策略对显存紧张的场景非常实用不过需要引擎精度设计为层间管道化传统框架很少这么干。连续2小时压力测试设备温度稳定在62摄氏度左右没有触发降频任务完成率94.7%。这里说明一个关键点决定长时稳定性的往往不是峰值算力而是散热设计和功耗调度。引擎里做了一些针对性优化比如在机械臂等待工件到位时动态切换低功耗模式只保留视觉感知模块常开决策模块进入睡眠状态。这类功耗优化看似不起眼却是端侧具身智能走向产品化的必经之路。延迟抖动方面端侧方案的P95接近350毫秒最大单次抖动120毫秒。云端方案P95到了600毫秒最大抖动380毫秒。这个数据验证了一件事端侧推理的行为一致性远优于云端。对于机器人控制来说稳定的延迟边界比平均延迟数字更重要。你宁可每次都多等50毫秒也不能接受忽快忽慢。5. 端侧部署踩坑实录量化掉精度、动态Shape和散热墙这一章是我最想写的因为所有数据背后都是踩坑换来的教训。端侧引擎的部署过程和纯软件项目完全不同每一步都涉及到物理硬件出问题就是整个系统层面的问题。第一个坑是量化带来的精度衰减。模型从FP16压到INT8之后视觉塔的特征图出现明显退化最直观的表现是细长物体的姿态估计偏移了约5度。5度对于抓取来说已经很致命了夹爪下去直接会把细长的螺丝刀碰倒。排查了很久才发现问题不在量化算法本身而在于模型的归一化层在低比特下数值分布被压缩了。解决方案是把归一化层单独保留FP16精度其余部分用INT8。这个混合精度方案让姿态估计误差从5度降回了1度以内。量化不是一刀切的事敏感层必须特殊处理。第二个坑是动态Shape导致的算子编译延迟。端侧推理引擎支持动态输入尺寸但传统框架在动态尺寸下会频繁触发算子重新编译单次编译耗时可能到400毫秒任务直接被卡死。这个问题在云端不那么明显因为云端的CPU核多、内存大、预热机制成熟到了端侧就成了大问题。我的解决办法是固定推理分辨率在相机端直接做缩放模型接收的总是标准尺寸。牺牲了一点点精度但换来了稳定可预测的延迟。对机器人应用来说可预测的延迟永远优先于极致的精度。第三个坑是散热和功耗的联动效应。刚开始跑长时任务的时候一切指标都很正常跑了大概40分钟之后推理延迟逐渐变大从280毫秒一路爬到500毫秒。第一反应是模型出了问题查了一圈才发现是GPU因为温度接近阈值自动降频了。边缘平台的风道设计对机械臂内部这种空间位置很敏感风扇被遮挡之后散热效率骤降。重新规划了风道位置之后温度稳定在65摄氏度左右。这类问题在纯软件层面完全不可见但真实的具身机器人系统里散热和算法是同一件事的两面。还有一个经验值得单独说内存碎片的累积效应。长时间跑多轮任务之后显存碎片越来越多空闲容量显示还有1GB但实际已经分配不出一个连续的大块内存。引擎在一次动作解码时突然报显存不足整个任务中断。排查到最后发现是动态加载层的分配模式有问题。解决办法是在引擎里加了一个显存池复用机制将常用tensor预先分配好空间缓存复用排查了一整天最后改了一行分配策略就解决了。6. 这个引擎适合谁用以及它现在的边界测试做完我一直在思考这套引擎适用的场景边界。它不是万能的但也有相当清晰的使用边界。如果你做的是固定工位的上下料机械臂场景相对固定、物体种类有限、动作模式标准化那么这套Agentic native的端侧方案可以做到一次部署长期稳定运行。你获得的最大收益是可预测的延迟和数据本土化。如果你做的是移动抓取机器人在开放空间里的任务环境多变、物体类别不确定、指令复杂程度高那么更要关注通用型视觉语言模型在端侧的运行效率。当前这个引擎在多模态理解深度上还有限面对长尾指令或未见过的物体类别时成功率会显著下降。这不是引擎架构的问题而是小型专用模型的知识容量天然比不上云端超大模型。这也是为什么我认为短期内端侧和云端不会是替代关系而是互补关系端侧负责时间敏感的核心操作闭环云端负责大场景理解、语义规划等高层次的慢决策。实测下来Agentic native的这套引擎以1.8GB的INT8模型跑出了90%以上的抓取成功率已经把端侧推理从能用推进到了可用。下一步有价值的优化方向包括更高效的注意力机制压缩、针对机械臂动力学模型的联合解码以及在开源数据集基础上的姿态估计微调。对于正在规划具身智能学习路线的人来说我的建议是结构化的推理引擎优化方法论、视觉语言模型的轻量化部署、真实物理环境的调试能力这三个方向都比单纯追模型榜单更有长期价值。这套端侧引擎在实际部署里还有很多可以聊的细节比如指令理解的鲁棒性调优、模拟器到真机的迁移策略这些都会直接影响落地效果。后面我会继续在这个方向上做新实验有新数据了再更新实测结论。
最近大半年我一直在折腾一套东西把具身机器人的大脑从云端往机器人本体上搬。说白了就是让机械臂和轮式底盘在不联网、不依赖服务器的条件下自己完成感知、规划、操作这一整条链路。上周我把一套Agentic native架构的端侧推理引擎完整跑通了从视觉输入到机械臂执行全程本地推理实测结果比预期强不少但踩坑也多。这篇把整个过程和盘托出给正在做具身智能、或者打算入局具身智能学习路线的人一个参照。先说结论性的东西这次实测用的是六轴协作机械臂加一套轻量级计算平台跑的是多模态感知加操作规划的一体化模型。引擎是专门为Agentic native设计的目标检测、实例分割、动作生成管线全部在设备端完成整个闭环的端到端延迟控制在300毫秒以内物体抓取成功率在标准桌面场景下稳定在90%以上。这个数据放在云端方案里不算惊艳但放在端侧、放在真机上意义完全不一样。下面拆开讲。1. 具身机器人跑推理为什么本地是硬门槛先聊一个很多人忽视的问题具身机器人为什么非得在端侧跑推理直接连云端不是更省事吗我之前也觉得云端算力强、模型大、效果肯定更好。直到我把一个简单的物体抓取任务从云端迁到本地测试才彻底明白端侧不是可选项而是必选项。第一个原因是延迟不可控。控制一个机械臂去抓一个移动的物体整个闭环的每一毫秒都算数。视觉传感器采集图像传输到云端云端推理再把结果传回来这趟来回在实验室网络环境下要80到150毫秒。听起来不多但加上相机曝光、图像编码、执行器响应端到端轻松突破400毫秒。对于一个正在从传送带上滑过的工件400毫秒的延迟意味着机械臂已经错过了最佳抓取窗口。具身智能对实时性的要求远高于普通对话、生成类AI这是物理世界给的时间约束。第二个原因是稳定性。工厂车间、仓储物流、户外巡检这些场景的网络环境根本没有保证。信号抖动一次云端推理超时一次机器人的行为就是一次不可预估的停顿。做机器人的朋友都懂不可预估的停顿意味着安全隐患轻则任务失败重则撞坏工件甚至伤到人。这一点上端侧推理有天然优势计算在本地网络不参与决策回路行为的一致性就能保证。第三个原因更隐性是数据隐私和合规。具身机器人在现实环境里采集的图像包含大量环境信息有些是产线布局有些是仓储库存有些甚至涉及人员活动。这些数据全部传云端对很多企业来说是不可接受的。端侧推理意味着原始数据不出设备直接完成处理这是架构层面的安全兜底。所以端侧推理引擎这几年在具身智能领域备受关注本质上不是在追求更快的推理速度而是在追求可控的延迟边界、稳定的行为表现和数据私域化。这三个属性缺一样具身机器人就不适合走出实验室。2. Agentic native的真相不是一个模型是一套循环架构Agentic native这个词最近在圈子里很火但很多人的理解停留在表面认为它代表AI能自主做决策。实测之后我的理解更具体了Agentic native是一种系统架构理念它要求推理引擎从底层就把感知、决策、行动当作一个完整的循环来设计而不是拼接三个独立模块。传统做法是感知一个模型、规划一个模型、控制一个模型三个模型用中间数据串起来。这种管道的最大问题是信息丢失。感知模型输出的bounding box和类别已经把视觉信息抽象掉了一大半规划模型拿着这堆抽象结果去算轨迹它根本看不到场景里的几何细节。等到执行模型走完流程你发现机械臂把杯子抓翻了因为感知阶段盒子框得不精确规划阶段轨迹就没避开杯口边缘。这不是模型能力不行是架构在中间环节就把信息浪费掉了。Agentic native的做法不一样。它在底层预留了多模态token空间视觉特征、文本指令、动作编码都在同一套表示空间里流转。感知阶段精修的feature不是扔给下一个模块而是保留在token流里持续参与后续的决策。规划模块可以直接访问高分辨率的视觉特征动作生成也拿得到这些信息。整个流程像一个连续对话的智能体而不是一个流水线上的三班工人。这次实测的引擎在架构上有几个明显特征。它的语义理解接口和决策循环是同一个数据通路没有中间序列化、没有格式转换。用户下发指令后引擎会先生成一个内部目标表示然后这个表示会一直存在指导整个任务直到完成或者被新指令显式替换。分配完子任务的每个动作片段之后引擎会把实际执行结果反馈回表示层形成一个闭环。这套机制让我第一次直观理解了原生和包装的区别。如果只是把prompt叠加、工具调用这些Agent框架的能力做出来那还是典型的包装路线真正Agentic native从张量形状、内存规划到算子调度都围绕多轮闭环设计这不是插件能补出来的东西。具身机器人需要的是动作连续性和环境适应性前一轮的错误动作必须能通过下一轮感知修正这要求推理引擎原生支持持续运行而不是每次调用重新初始化状态。3. 实测平台搭建与基准设计机械臂加边缘GPU的真实工况说清楚平台配置才能讨论数据。这次实测用的机器人本体是一台六轴协作机械臂加上一个电动夹爪末端装了深度相机。算力平台用的是带边缘GPU的嵌入式工控机整机功耗上限大约是25瓦。25瓦大概是什么概念比很多游戏笔记本在待机时的功耗还要低塞在机械臂底座里完全不需要额外散热改造。模型侧用的是针对动态场景优化的多模态推理网络。要说明的是它并非超大参数级别的通用模型而是面向机器人操作场景进行结构精简的专用模型包含视觉塔、语义融合层和动作解码头三大部分。整套模型用INT8量化后体积约为1.8GB完整加载进显存后剩余空间仍然很宽裕。我设计了一套比较接近真实工况的测试基准。标准桌面场景桌面上随机放置三个物体系统拿到自然语言指令后需要识别目标物体、规划抓取姿态、避开障碍物路径然后完成抓取。每次任务限定在15秒内完成超时记为失败。总共跑100次记录成功次数、单次决策时延、内存峰值等指标。另外还有一项是连续通断压力测试任务连续跑2小时看稳定性。同样的任务我也用纯云端方案跑了一组对比。云端方案的模型版本完全一样只是推理部署在数据中心侧通信走局域网。这样对比的意义在于算力基准相同的情况下单纯看端到端链路谁更稳。搭建环境时有一个细节值得强调端侧引擎对传感器的适配比想象中敏感。深度相机输出的点云数据在Tensor Core上做采样和编码时如果采样密度和模型训练时不匹配推理精度会明显掉。解决办法是在引擎外部加了一层数据适配正则化把不同相机的位深、分辨率、噪声特征统一映射到模型预期的分布区间。这一步不做再好的模型也白搭。4. 实测数据拆解延迟、内存和抓取成功率到底什么水平先放实测数据。标准桌面抓取任务端侧引擎方案端到端平均时延280毫秒包括相机采集20毫秒、目标检测和姿态估计120毫秒、轨迹规划60毫秒、动作执行80毫秒。云端方案端到端平均时延440毫秒其中纯计算只有100毫秒剩下的340毫秒全部消耗在数据传输和多次同步上。这个对比已经说明问题了云端的计算确实强但延迟的瓶颈根本不在计算在于通信。100次抓取任务端侧方案成功93次其中有3次失败是机械结构本身的夹持滑动真正算法层面的失败只有4次。云端方案成功89次失败里有6次是因为端到端延迟导致抓取时机偏移。数据表明在同样的抓取策略下延迟就是成败的决定性变量之一。模型的显存峰值约为5.2GB传统上大家会认为边缘GPU跑多模态模型很吃力但实测下来1.8GB的INT8量化模型配合引擎的分层加载机制把峰值压在了非常可控的范围。分层加载的意思是视觉塔常驻显存语义融合层按需加载动作解码头在推理前才调入。这个策略对显存紧张的场景非常实用不过需要引擎精度设计为层间管道化传统框架很少这么干。连续2小时压力测试设备温度稳定在62摄氏度左右没有触发降频任务完成率94.7%。这里说明一个关键点决定长时稳定性的往往不是峰值算力而是散热设计和功耗调度。引擎里做了一些针对性优化比如在机械臂等待工件到位时动态切换低功耗模式只保留视觉感知模块常开决策模块进入睡眠状态。这类功耗优化看似不起眼却是端侧具身智能走向产品化的必经之路。延迟抖动方面端侧方案的P95接近350毫秒最大单次抖动120毫秒。云端方案P95到了600毫秒最大抖动380毫秒。这个数据验证了一件事端侧推理的行为一致性远优于云端。对于机器人控制来说稳定的延迟边界比平均延迟数字更重要。你宁可每次都多等50毫秒也不能接受忽快忽慢。5. 端侧部署踩坑实录量化掉精度、动态Shape和散热墙这一章是我最想写的因为所有数据背后都是踩坑换来的教训。端侧引擎的部署过程和纯软件项目完全不同每一步都涉及到物理硬件出问题就是整个系统层面的问题。第一个坑是量化带来的精度衰减。模型从FP16压到INT8之后视觉塔的特征图出现明显退化最直观的表现是细长物体的姿态估计偏移了约5度。5度对于抓取来说已经很致命了夹爪下去直接会把细长的螺丝刀碰倒。排查了很久才发现问题不在量化算法本身而在于模型的归一化层在低比特下数值分布被压缩了。解决方案是把归一化层单独保留FP16精度其余部分用INT8。这个混合精度方案让姿态估计误差从5度降回了1度以内。量化不是一刀切的事敏感层必须特殊处理。第二个坑是动态Shape导致的算子编译延迟。端侧推理引擎支持动态输入尺寸但传统框架在动态尺寸下会频繁触发算子重新编译单次编译耗时可能到400毫秒任务直接被卡死。这个问题在云端不那么明显因为云端的CPU核多、内存大、预热机制成熟到了端侧就成了大问题。我的解决办法是固定推理分辨率在相机端直接做缩放模型接收的总是标准尺寸。牺牲了一点点精度但换来了稳定可预测的延迟。对机器人应用来说可预测的延迟永远优先于极致的精度。第三个坑是散热和功耗的联动效应。刚开始跑长时任务的时候一切指标都很正常跑了大概40分钟之后推理延迟逐渐变大从280毫秒一路爬到500毫秒。第一反应是模型出了问题查了一圈才发现是GPU因为温度接近阈值自动降频了。边缘平台的风道设计对机械臂内部这种空间位置很敏感风扇被遮挡之后散热效率骤降。重新规划了风道位置之后温度稳定在65摄氏度左右。这类问题在纯软件层面完全不可见但真实的具身机器人系统里散热和算法是同一件事的两面。还有一个经验值得单独说内存碎片的累积效应。长时间跑多轮任务之后显存碎片越来越多空闲容量显示还有1GB但实际已经分配不出一个连续的大块内存。引擎在一次动作解码时突然报显存不足整个任务中断。排查到最后发现是动态加载层的分配模式有问题。解决办法是在引擎里加了一个显存池复用机制将常用tensor预先分配好空间缓存复用排查了一整天最后改了一行分配策略就解决了。6. 这个引擎适合谁用以及它现在的边界测试做完我一直在思考这套引擎适用的场景边界。它不是万能的但也有相当清晰的使用边界。如果你做的是固定工位的上下料机械臂场景相对固定、物体种类有限、动作模式标准化那么这套Agentic native的端侧方案可以做到一次部署长期稳定运行。你获得的最大收益是可预测的延迟和数据本土化。如果你做的是移动抓取机器人在开放空间里的任务环境多变、物体类别不确定、指令复杂程度高那么更要关注通用型视觉语言模型在端侧的运行效率。当前这个引擎在多模态理解深度上还有限面对长尾指令或未见过的物体类别时成功率会显著下降。这不是引擎架构的问题而是小型专用模型的知识容量天然比不上云端超大模型。这也是为什么我认为短期内端侧和云端不会是替代关系而是互补关系端侧负责时间敏感的核心操作闭环云端负责大场景理解、语义规划等高层次的慢决策。实测下来Agentic native的这套引擎以1.8GB的INT8模型跑出了90%以上的抓取成功率已经把端侧推理从能用推进到了可用。下一步有价值的优化方向包括更高效的注意力机制压缩、针对机械臂动力学模型的联合解码以及在开源数据集基础上的姿态估计微调。对于正在规划具身智能学习路线的人来说我的建议是结构化的推理引擎优化方法论、视觉语言模型的轻量化部署、真实物理环境的调试能力这三个方向都比单纯追模型榜单更有长期价值。这套端侧引擎在实际部署里还有很多可以聊的细节比如指令理解的鲁棒性调优、模拟器到真机的迁移策略这些都会直接影响落地效果。后面我会继续在这个方向上做新实验有新数据了再更新实测结论。
/YOLO火焰烟雾检测)
/YOLO工程车辆检测)
