1. 这期周报到底在聊什么做AI硬件这行有个特别明显的感受软件圈发版是按周甚至按天算的硬件圈却常常是“憋大招”——要么几个月没动静要么一周之内好几家同时甩出新品。所以从今年年初开始我给自己定了个规矩每周固定花两个晚上把散落在各处的AI硬件动态捋一遍攒成一份周报。这份“AI硬件周报-202603第2期”就是第二周的产出覆盖的时间窗口大致是三月中旬那一周。先给不太熟悉这个领域的朋友交个底所谓AI硬件范围比很多人想象的要宽。它不只是“能跑大模型的设备”而是泛指一切把AI能力作为核心卖点或核心功能的实体产品——从带NPU的端侧计算模组、AI眼镜、智能录音笔到边缘推理盒子、机器人关节控制器甚至包括为AI训练专门设计的散热和供电方案。这一周的信息量相当密集我前后翻了十几份公开的技术文档、产品页和开发者社区的讨论帖最后筛出来四条值得展开讲的主线。这份周报适合谁看如果你是做嵌入式开发、端侧算法部署的工程师里面关于算力和内存带宽的取舍分析应该对你有用如果你是产品经理或者硬件创业者关于形态创新和场景落地的部分能帮你判断方向哪怕你只是个数码爱好者想搞清楚“AI硬件现在到底发展到哪一步了”也能从这些具体案例里获得比看发布会更真实的认知。我不会堆砌参数而是尽量把每个产品背后的设计逻辑和它解决的问题讲透。2. 端侧算力模组这一周最值得盯的三件事2.1 算力堆叠的路线之争大核还是小核集群这一周有两家模组厂商几乎同时更新了他们的端侧AI计算模组产品线有意思的是两家走了完全相反的路线。A厂商的新模组主打“单核大算力”一颗主处理器峰值算力标称到了48 TOPS配套的内存带宽给到了LPDDR5X 8533MT/sB厂商则走“小核集群”路线用四颗12 TOPS的中等核心通过片上网络互联总标称算力也是48 TOPS左右但单核只有12 TOPS。表面看总算力一样实际用起来差别很大。我拿一个典型的视觉检测场景做了个粗略估算假设模型是YOLOv8-medium输入分辨率640×640INT8量化。单核方案在跑单路视频流时延迟能压到8毫秒左右但如果你想同时跑四路就得排队因为一颗核心同一时刻只能处理一个推理任务。小核集群方案单路延迟会到15毫秒上下但四路可以真正并行总吞吐反而更高。这里有个很多人会踩的坑厂商标称的TOPS是理论峰值实际有效算力往往要打六到七折取决于内存带宽和调度效率。选型时别只看TOPS数字一定要问清楚“在什么精度下、什么batch size下、内存带宽是多少”。我的建议是如果你的应用是单路高帧率、对延迟极度敏感的场景比如高速产线上的缺陷检测大核方案更合适如果是多路并发、对单路延迟不那么苛刻的场景比如多摄像头安防分析小核集群的吞吐优势就体现出来了。这一周我还注意到一个细节A厂商的文档里悄悄把“支持多模型并行”改成了“支持多模型分时复用”这个措辞变化其实就是在暗示单核方案的并行能力有限。2.2 内存带宽正在成为真正的瓶颈这一周我在开发者社区里看到好几个帖子都在讨论同一个问题算力明明够为什么跑大模型还是卡答案几乎都指向内存带宽。有个做端侧对话机器人的开发者分享了一组实测数据他用的模组标称算力40 TOPS跑一个70亿参数的模型量化到INT4之后模型体积大约3.5GB理论上算力完全够用但实际推理速度只有每秒4到5个token体验很差。我帮他算了一笔账70亿参数INT4模型每生成一个token需要读取大约3.5GB的权重数据因为自回归生成是逐token的每次都要把全部权重过一遍。如果内存带宽是50GB/s那理论上限就是50除以3.5大约每秒14个token。实际因为调度开销和缓存命中率的问题能到一半就不错了。所以瓶颈根本不在算力而在内存带宽。这一周有个好消息是有厂商开始把LPDDR5T引入端侧模组带宽能到9600MT/s比上一代提升了大约12%。别小看这12%对于大模型推理来说带宽提升几乎能线性转化为token生成速度的提升。我个人的判断是接下来半年端侧AI模组的竞争焦点会从“拼算力”转向“拼带宽”选型的时候一定要把内存带宽和容量放在和算力同等重要的位置。2.3 散热设计被低估的隐形门槛这一周还有一件事让我印象很深。有个做边缘推理盒子的团队在社区里吐槽说他们的产品在实验室跑得好好的一到客户现场就频繁降频。后来排查发现是散热设计没做好盒子内部风道不合理连续跑高负载推理半小时后模组温度冲到95度触发温控降频算力直接掉到标称值的一半。这个问题在端侧AI硬件里特别普遍因为很多团队是从软件或者算法转过来的对热设计不够重视。我的经验是选模组的时候一定要看它的热设计功耗TDP和结温上限然后按照最坏情况来设计散热方案。自然散热的话每瓦功耗大概需要15到20平方厘米的散热面积如果空间受限就得考虑主动散热但风扇的寿命和噪音又是新问题。这一周我看到一个比较巧妙的方案有厂商把模组和散热片做成一体化封装用相变材料填充间隙热阻比传统硅脂方案低了大约30%。虽然成本高一些但对于那些外壳封闭、没有风道的小型设备来说这个溢价是值得的。毕竟算力再高一降频就全白搭。3. AI眼镜形态创新背后的取舍逻辑3.1 这一周的新品到底新在哪AI眼镜这个品类最近热度很高这一周又有一款新品发布。我仔细看了它的技术规格和几个提前拿到样机的开发者分享发现它和上一代产品相比最大的变化不是算力提升而是重量分布和交互逻辑的调整。上一代产品把电池和主板都放在镜腿里导致前后配重严重失衡戴久了鼻梁特别累。这一代把电池移到了镜腿尾部主板拆成两块分别放在左右镜腿整体重量虽然只轻了8克但佩戴舒适度提升非常明显。交互逻辑上这一代把触控区域从镜腿侧面移到了镜腿顶部用食指自然搭上去就能操作不需要刻意去找位置。这个改动看起来很小但实际用起来差别很大。我试过上一代产品每次想切歌或者唤醒助手都要低头找触控区动作很别扭。新款的交互位置更符合人体工学盲操准确率高了不少。3.2 显示方案的选择光波导还是Micro LEDAI眼镜的显示方案一直是行业争论的焦点。这一周我和几个做光学模组的朋友聊了聊目前主流路线还是光波导和Micro LED两种。光波导的优势是镜片可以做得比较薄外观接近普通眼镜但光效低通常只有百分之几的光能到达眼睛所以需要比较亮的投影源功耗和发热都上去了。Micro LED的优势是亮度高、对比度高、响应快但目前的难点在于全彩化红色Micro LED的效率和寿命还是短板。这一周有个做AR眼镜的团队分享了一个折中方案用单色绿色Micro LED加光波导只做信息提示不做全彩显示。这个方案的好处是绿色Micro LED技术最成熟亮度足够功耗可控而且对于导航提示、消息通知这类场景单色显示完全够用。我觉得这个思路很务实与其追求全彩但体验拉胯不如先把单色场景做扎实。如果你在评估AI眼镜方案我的建议是先想清楚核心场景是什么。如果是信息提示类单色光波导方案性价比最高如果是观影或者游戏那必须上全彩Micro LED或者BirdBath方案但重量和功耗就很难控制了。3.3 续航和算力的平衡术AI眼镜最大的尴尬是算力强的续航差续航好的算力弱。这一周有个开发者分享了他的实测数据某款AI眼镜在连续拍照识别模式下续航只有不到两小时如果只是偶尔唤醒语音助手能撑到六小时左右。这个差距说明续航瓶颈主要出在摄像头和无线传输上而不是待机功耗。目前行业里比较主流的做法是“端侧轻量处理加云端重载处理”。眼镜端只做唤醒词检测和简单的图像预处理真正的识别和生成放到手机或者云端。这样做的好处是眼镜端功耗低但代价是依赖网络延迟也高。这一周我看到有厂商在尝试“端侧中等模型加云端大模型”的混合架构把一些常见的识别任务放在端侧完成只有复杂任务才上传云端。这个方向我觉得是对的但前提是端侧模型的精度要够用否则用户会觉得“智能”变“智障”。4. 边缘推理盒子从能跑到好用的距离4.1 部署体验正在成为核心竞争力这一周我花了不少时间研究边缘推理盒子的部署流程。说实话这个品类目前的痛点根本不是算力不够而是部署太麻烦。我试了三个不同品牌的盒子没有一个能做到开箱即用。有的需要手动编译驱动有的文档里写的命令和实际系统版本对不上还有一个连SSH默认密码都没在说明书里写清楚。这一周有个厂商发布的新品在部署体验上做了改进预装了容器化运行时常用的推理框架和模型都以镜像形式提供用户只需要拉取镜像、挂载模型文件、配置端口就能跑起来。我看了他们的快速上手文档从开箱到跑通第一个推理任务大概需要十五分钟。这个速度在目前的边缘推理盒子里算是相当优秀的。选边缘推理盒子的时候我建议把“部署体验”的权重放高一些。算力差20%可能只是推理速度慢一点但部署体验差可能导致项目延期好几周。可以要求厂商提供试用镜像或者在线Demo环境亲自跑一遍再决定。4.2 模型转换和量化工具链的成熟度边缘推理盒子能不能跑某个模型很大程度上取决于厂商提供的模型转换和量化工具链。这一周我在一个开发者群里看到有人吐槽说他用的盒子只支持特定版本的ONNX稍微新一点的算子就不认导致他不得不把模型拆成好几段分别转换再拼接工作量翻倍。这个问题其实很普遍。我的经验是选盒子之前先确认三件事第一工具链支持哪些模型格式ONNX、TensorFlow Lite、PyTorch Mobile是不是都支持第二量化工具支持哪些精度INT8、INT4、混合精度分别是什么流程第三有没有现成的模型库常见模型是不是已经预转换好了。这三件事确认清楚能省掉后面很多麻烦。这一周有个好消息是有厂商开始提供“一键量化”工具上传模型文件后自动分析算子兼容性给出量化建议甚至能预测量化后的精度损失。虽然还不完美但比之前手动调参的方式友好太多了。4.3 实际场景中的稳定性考验边缘推理盒子和实验室开发板最大的区别是它要在无人值守的环境里连续运行几个月甚至几年。这一周有个做智慧园区的朋友分享了他的踩坑经历盒子在实验室跑了一周没问题部署到现场后第三天就死机了。排查发现是现场电压不稳盒子电源模块没有做足够的宽压设计电压波动一大就重启。这个案例提醒我评估边缘推理盒子的时候除了算力和软件生态还要看工业级设计。工作温度范围是不是够宽电源输入是不是支持宽压有没有看门狗和自动恢复机制这些在实验室里看不出差别到了现场就是生死线。我个人的经验是如果部署环境不是恒温恒湿的机房一定要选工业级产品消费级的盒子省下的钱后面都会以运维成本的形式还回去。5. 机器人关节控制器这一周的技术小进展5.1 一体化关节模组的趋势这一周我在看机器人相关的技术动态时注意到一个明显的趋势越来越多的厂商在推一体化关节模组把电机、减速器、编码器、驱动器、控制器全部集成到一个模块里。这种方案的好处是体积小、布线简单、一致性高特别适合协作机器人和人形机器人的关节设计。我对比了几家的一体化关节模组参数发现关键差异在减速器类型和编码器精度上。谐波减速器精度高、体积小但成本也高行星减速器成本低、扭矩大但精度和背隙控制差一些。编码器方面磁编码器成本低、抗污染能力强但精度通常不如光电编码器。选型的时候要根据具体应用来定不能只看价格。这一周有个做人形机器人的团队分享了他们的选型经验腿部关节用谐波减速器加双编码器方案保证精度和响应速度手臂关节用行星减速器加单编码器方案控制成本。这个思路很务实不同部位的要求不一样没必要一刀切。5.2 力控和柔顺控制的实际落地机器人关节控制这一周还有一个值得关注的点是力控技术的落地。传统的机器人关节主要做位置控制就是“走到某个角度”但协作机器人和人形机器人需要力控就是“用多大的力去推”。这一周有个团队分享了他们在力控方面的进展通过电流环估算力矩结合关节端的力矩传感器做闭环实现了比较柔顺的碰撞检测和拖动示教。我看了他们的演示视频机械臂碰到人手时会立刻停止并回退反应时间大概在10毫秒左右。这个性能对于协作场景来说基本够用了。不过他们也提到力控的难点在于摩擦力和重力的补偿不同姿态下关节需要输出的力矩不一样补偿模型没做好就会出现“要么太软要么太硬”的问题。如果你在做力控相关的开发我的建议是先把重力补偿和摩擦补偿做扎实这两个是基础。基础没打好上层算法再花哨也没用。补偿参数可以通过系统辨识来获取比手动试凑高效得多。5.3 通信总线的选择EtherCAT还是CAN FD这一周还有个讨论比较多的话题是关节控制器的通信总线选择。EtherCAT带宽高、实时性好但成本也高而且需要专用的主站芯片CAN FD成本低、布线简单但带宽和节点数有限。目前工业机器人主流还是EtherCAT但一些做消费级机器人的团队开始转向CAN FD因为成本压力太大了。我的看法是如果关节数量少、控制频率要求不高CAN FD完全够用但如果关节数量多、需要高频率的力控闭环EtherCAT的优势就体现出来了。这一周有个团队分享了一个折中方案主干用EtherCAT末端执行器用CAN FD通过网关转换。这样既保证了核心关节的实时性又降低了整体成本。6. 这一周踩过的坑和攒下的经验6.1 参数标称值的解读技巧这一周我在整理各家产品参数的时候发现一个很普遍的问题厂商标称的参数往往是在最理想条件下测出来的实际使用中很难达到。比如算力标称值通常是在最高频率、最大功耗、最优散热条件下测的实际部署时为了控制功耗和温度往往要降频运行。内存带宽标称值也是理论峰值实际有效带宽受调度和访问模式影响能到七八成就不错了。我的经验是看参数的时候要养成“打折”的习惯。算力打七折带宽打八折功耗往上浮20%这样估算出来的性能更接近实际。另外尽量找第三方评测或者开发者社区的实测数据比厂商的标称值靠谱得多。这一周我就参考了好几个开发者的实测分享修正了我之前对一些产品的判断。6.2 选型时的优先级排序这一周和几个做硬件的朋友聊天大家有个共识AI硬件选型最怕“什么都想要”。算力要高、功耗要低、体积要小、成本要便宜、生态要好这五个条件同时满足的产品基本不存在。关键是想清楚自己的核心场景最看重什么然后做取舍。我一般会建议按这个优先级来排第一是场景匹配度产品能不能解决你的核心问题第二是稳定性能不能在目标环境里长期可靠运行第三是生态成熟度工具链和文档是不是完善第四是成本第五才是算力冗余。很多人把算力放在第一位结果买回来发现生态不成熟开发周期拖了几个月算力再高也没用上。6.3 开发者社区的信息挖掘方法这一周我大部分有价值的信息其实不是从厂商发布会或者新闻稿里来的而是从开发者社区的讨论帖里挖出来的。厂商的官方信息往往经过包装只讲优点不讲缺点但开发者在实际使用中遇到的问题和解决方案才是最有参考价值的。我的方法是先看厂商的官方文档了解基本规格然后去开发者社区搜相关讨论重点看“踩坑”“求助”“对比”这类关键词的帖子。如果一个产品在社区里讨论热度高、问题有人解答、厂商技术人员也参与互动那这个产品的生态通常比较健康。反过来如果一个产品在社区里几乎没人讨论那就要谨慎了可能意味着用户基数小或者厂商支持力度不够。这一周我还注意到一个细节有些厂商会在社区里主动发布“已知问题列表”和“路线图”这种做法虽然暴露了产品的不足但反而增加了可信度。毕竟没有完美的产品坦诚沟通比遮遮掩掩更让人放心。6.4 快速验证方案可行性的小技巧这一周我帮一个朋友快速验证了一个端侧AI方案的可行性用的方法我觉得可以分享给大家。他的需求是在一个低功耗设备上跑关键词识别我建议他先不要买硬件而是用现成的开发板加上USB麦克风先跑通算法流程确认模型精度和延迟满足要求之后再根据算力和内存需求去选具体的模组。这样做的好处是算法验证和硬件选型解耦避免买了硬件才发现算法跑不通。而且开发板通常生态更成熟调试工具更完善验证阶段效率更高。等算法验证通过了再根据实际的算力、内存、功耗需求去筛选模组目标更明确不容易被厂商的参数忽悠。这一周我就是用这个方法帮朋友省了一笔不必要的采购费用。他原本看中了一款算力很高的模组但实际验证下来他的模型只需要不到十分之一的算力就能跑最后选了一款便宜得多的方案效果完全一样。所以我的建议是先验证需求再匹配硬件顺序不能反。7. 下周值得关注的方向这一周的信息整理下来我个人的感受是端侧AI硬件正在从“拼参数”进入“拼体验”的阶段。算力已经不再是唯一的瓶颈内存带宽、散热设计、部署体验、生态成熟度这些“软实力”越来越重要。下周我打算重点跟踪三个方向一是端侧大模型推理的优化方案特别是KV Cache管理和投机采样在端侧的应用二是AI眼镜的光学方案进展看看有没有新的全彩Micro LED方案出来三是机器人关节控制器的国产供应链动态最近这个领域变化很快。如果你也在做AI硬件相关的开发或者选型欢迎交流。我每周都会把整理的内容发出来一方面是给自己做个记录另一方面也希望能帮到同行少踩一些坑。毕竟这个领域变化太快一个人闷头搞很容易走弯路多交流才能跟上节奏。