9月5日杭州一场关于AI硬件的线下交流局。这个主题我琢磨了好一阵子从朋友圈里发起邀约开始身边已经有不下二十位朋友在问到底聊什么有没有议程能不能带自己的项目来现场碰一碰先说清楚这场交流想解决什么问题。过去两年AI大模型把所有人的注意力都拉到了云端ChatGPT、Agent、多模态好像只要有个API Key就能做产品。但真正跑过落地项目的人心里都清楚模型再强最后总要跑在某个设备上。手机、机器人、边缘盒子、工业控制器、智能穿戴这些设备才是AI真正“触达物理世界”的那双手。硬件选型怎么定、算力够不够、功耗压不压得住、部署链路顺不顺每一个问题都能让项目在Demo阶段反复返工。所以这场局本质上就是给硬件工程师、嵌入式开发者、AI应用开发者以及所有正在做“AI硬件”产品的人摆一张桌子坐下来聊。适合谁只要你正在做或打算做带AI能力的设备不管是刚画完第一块板子还是已经在量产的边缘产品都值得来。这一篇我先把要聊的核心话题拆开也算是给来现场的朋友一份“课前预习材料”。1. AI硬件到底是什么为什么现在值得专门聊1.1 从“会发光”到“会思考”硬件正在经历三个变化我这几年接触的硬件项目明显感觉到三个方向性的变化。第一个变化是算力下沉。以前提到AI大家的直观感受是高性能计算集群、云端GPU做一次推理要经过漫长的网络请求来回几百毫秒。而现在越来越多的场景要求实时响应比如工业质检的缺陷识别产线上一秒钟要处理几十张图像数据根本不可能传到云端再传回来。于是NPU、GPU、DSP这些加速单元被集成到SoC里瑞芯微、晶晨、全志这些做嵌入式平台的厂商都把AI算力当作核心卖点。端侧推理从“可选”变成了“默认”。第二个变化是交互重构。过去我们做智能硬件交互方式基本就是按键、屏幕、App最多加个语音唤醒。现在不一样了视觉识别、语音理解、手势控制这些能力直接把硬件的交互门槛拉低了一大截。一个传统的摄像头加上AI识别能力之后就不再是简单的监控设备而是一个能感知环境、做出判断的智能节点。硬件厂商之间的竞争从“谁的做工好”变成了“谁能把AI能力用得更自然”。第三个变化是开发方式的融合。以前硬件工程师画板子写驱动算法工程师在服务器上训模型两边基本是两条平行线。现在做AI硬件产品硬件工程师必须懂的模型部署的基本概念——量化精度、内存占用、推理延迟算法工程师也要理解硬件的资源约束。光有算法没硬件跑不起来光有硬件没算法就是一块贵铁。这种融合带来一个直接结果市场上极其缺“既懂硬件、又能把AI模型落到板子上”的复合型人才。1.2 别用“智能硬件”四个字糊弄人AI硬件的典型形态很多样很多人一提到AI硬件第一反应是机器人是人形机器人、机器狗。其实落地最快、出货量最大的AI硬件往往是那些看起来没那么酷、但实实在在解决问题的设备。应用场景不同对硬件的需求差异非常大我简单梳理一下常见形态。边缘计算盒子大多基于瑞芯微RK3588、算能BM1684这类中高端SoC跑目标检测、人脸识别、OCR这类视觉模型常见于园区安防、明厨亮灶、智慧加油站等场景。工业机器视觉设备强调稳定性和实时性通常搭配工业相机和光源控制器对EtherCAT这类工业总线的支持要求很高主要用于产线缺陷检测、字符识别。智能座舱与车载设备兼顾性能与功耗要做音区识别、DMS驾驶员监测、手势交互还得考虑车规级的温度和震动要求。智能穿戴与健康设备核心约束是功耗用的都是MCU级别加轻量级NPU跑的是经过极大量化压缩的小模型比如心率异常检测、跌倒检测。AIoT网关把传感器数据在本地做预处理和过滤只把有价值的数据上传云端核心看中的是低功耗和长期运行的稳定性。这些产品背后共同的技术底座是同一套东西——算力芯片选型、模型转换与量化、推理框架部署、外设与传感器的适配。而这些恰恰是这次线下交流想深入聊的内容。1.3 杭州这场局为什么会凑到一起选择杭州当聚会地点其实不是随手定的。杭州这几年在AI赛道的积累大家有目共睹。做互联网应用的那拨人现在大量转型做AI产品他们有场景、有数据、有用户思维但普遍缺硬件的供应链经验和工程化能力。与此同时杭州周边还有一批从消费电子、安防产业里走出来的硬件团队他们有成熟的硬件设计体系但在AI算法和模型部署上刚起步不久。两边的人需要一张桌子坐下来聊聊。另外从供应链角度看长三角地区做模具、做PCB、做结构件的配套非常完善很多AI硬件创业团队都把研发中心放在杭州把生产放在周边城市。在杭州聊AI硬件聊完第二天就能去供应链现场看产线、对工艺这是很多其他城市不具备的便利条件。所以我特别期待这场交流不是搞一个正式的行业峰会而是一群做实事的人聚在一起带着各自踩过的坑、趟过的路聊点真实有用的东西。2. AI硬件落地要怎么选型算力、框架和部署链路2.1 先别急着买开发板想清楚这五个问题再说每次有人问我“做AI硬件应该买哪块开发板”我一般都会反问他五个问题。这些问题没想清楚板子买回来大概率也是吃灰。第一你跑什么模型目标检测类的YOLO系列、语音识别类的WakeNet、还是生成式的LLM不同模型对算力、内存、带宽的压力完全不一样。跑一个YOLOv5s的实时视频流检测和跑一个7B参数的对话模型对硬件的要求是两个量级。第二实时性要求有多高工业质检可能要30帧以上智能门锁的人脸识别允许延迟一两秒AI陪伴玩具对首响时间要求宽松得多。实时性要求直接决定你需不需要NPU加速以及需要多强的NPU。第三功耗约束是什么电池供电的设备平均功耗必须控制在几百毫瓦级别市电供电的设备可以放开用十几瓦甚至几十瓦的算力芯片。功耗和算力永远是一对矛盾想清楚哪个优先级更高再谈选型。第四部署环境有多恶劣工业现场的高温、户外设备的宽温需求、医疗设备的环境认证这些都会筛掉一大批芯片方案。很多消费级芯片在实验室跑得好好的一到工业现场就频繁死机不是芯片不行而是根本没按工业级设计。第五量产成本目标是多少开发阶段用一两千块的开发板没问题但量产阶段如果BOM成本要控制在几百块选型思路就得完全换一套。这时候往往要考虑用国产中低端平台牺牲一部分算力换成本优势。这五个问题本质是在帮你界定“够用”的边界。AI硬件的选型不是选最强的而是选最匹配的。2.2 算力不等于一切TOPS、内存带宽和量化精度怎么看很多硬件工程师习惯性地看芯片的TOPS每秒万亿次操作觉得这个数值越大越好。但真实项目里TOPS只是纸面参数实际效果要打很多折扣。我举一个实际例子。某款宣称6TOPS算力的平台在跑YOLOv5s模型时理论帧率应该能到60帧以上但实际部署出来只有25帧。问题出在哪一是模型转换过程中的算子优化不到位部分算子回退到CPU执行二是内存带宽跟不上NPU要等数据从DDR搬过来计算单元处于饥饿状态。算力再强喂不饱也没用。所以选硬件平台时除了TOPS还要重点看内存带宽和量化精度支持。内存带宽决定了数据搬运的上限带宽不够NPU算力再多也是空转。量化精度方面主流平台都支持INT8量化但有些老平台只有FP16没有INT8同样的模型跑起来内存占用和速度差距可能有两三倍。另一个容易踩的坑是算力虚标。有些芯片标称的算力是在极稀疏、极低精度的条件下测出来的实际跑密集型卷积时根本达不到。比较靠谱的做法是找官方或者第三方公布的“真实模型Benchmark”——比如同一颗芯片跑YOLOv5s或MobileNet的实测帧率而不是只看TOPS数字。2.3 边缘AI部署不是把模型塞进去就完事很多第一次做边缘AI的工程师以为模型训练好了转成对应的格式烧进板子里就能跑。实际部署过程远比这复杂链路里的每一步都可能翻车。先说模型转换。训练框架里用的是浮点模型而边缘设备为了性能通常要转成INT8量化模型。这一转精度损失是必然的关键看损失多少。量化校准需要准备有代表性的校准集校准集选不好量化后精度可能暴跌。我见过一个项目量化后mAP直接掉了15个点最后是换了校准集、调整了量化策略才救回来。再说推理框架。不同芯片厂商有各自的推理引擎瑞芯微的RKNN、Intel的OpenVINO、NVIDIA的TensorRT适配和调优方式完全不同。同一个模型在不同的推理引擎上性能差异巨大有些引擎对某些算子支持不全模型转换时直接报错需要去改写模型结构用支持的算子替代不支持的算子。然后是驱动适配。NPU驱动、ISP驱动、编解码单元驱动每一层都要和内核版本匹配。很多嵌入式Linux项目系统一升级NPU驱动就崩原因就是驱动和内核的版本耦合关系没处理好。这些坑不亲手踩一遍光看文档是意识不到的。所以做边缘AI部署最好的学习路径不是找一本教科书从头看而是拿一块真实的开发板把一个真实模型从训练端一路部署到板子上走一遍完整的链路中间的所有坑都记下来。这个过程走通了以后换任何平台都是相似的套路。3. 硬件工程师怎么接住AI这波浪潮3.1 传统硬件的基本功依然是立身之本这几年AI概念满天飞但我的判断一直很坚定硬件工程师吃饭的本事依然是那些看起来“不性感”的基本功。原理图设计、PCB布局布线、信号完整性、电源完整性、EMC设计、可靠性测试这些能力在AI硬件时代不但没有过时反而更加重要。为什么因为AI硬件普遍工作频率更高、算力更大、供电更复杂。一颗旗舰SoC的供电往往需要多路大电流DCDC每一路都有严格的时序要求DDR和PCIe的高速信号布线稍有不慎系统跑起来就是随机死机。这些问题的排查靠的还是老一代硬件工程师沉淀下来的方法论。所以我一直建议年轻的硬件工程师别被“AI浪潮”带偏节奏。先把模拟电路、数字电路、信号完整性这些基础啃扎实再谈AI的方向。地基不牢上面盖再高的楼都会塌。我在面试硬件工程师时基本必问电源纹波、地弹、ESD防护这类基础问题能答得透彻的哪怕没有AI项目经验我也愿意给机会。3.2 新时代要补的三门课AI硬件给硬件工程师提出了新的要求总结起来是三门课。第一门课看得懂模型和算子。不需要你会训练模型但至少要知道什么是卷积、什么是Transformer、模型大概有多大、跑一遍推理的内存开销怎么估算。这样才能在选型时心里有数不会被算法工程师一句“这个模型需要8GB内存”吓到也不会盲目买回一块算力过剩的开发板。第二门课玩得转嵌入式Linux和驱动。现在的AI硬件基本都是跑Linux系统的。交叉编译工具链、设备树、内核模块、根文件系统裁剪这些以前偏软件工程师的活儿现在硬件工程师也必须有所了解。因为硬件设计完调试阶段必须要自己把系统跑起来不可能每次都依赖软件同事硬件工程师懂Linux调试效率能翻倍。第三门课会用AI工具辅助硬件开发。现在AI编程辅助工具已经成熟到可以生成寄存器配置代码、DeviceTree片段、调试脚本、自动化测试用例。硬件工程师完全可以让AI帮你写I2C探测脚本、生成串口调试程序、分析日志异常。我自己试过让AI辅助写Verilog的简单模块生成速度比自己从零写快得多虽然代码质量还需要人工审查但效率上的提升是实实在在的。3.3 一条可以参考的成长路线经常有在校学生或者刚入行的工程师问我想往AI硬件方向发展应该怎么规划学习路径。我一般给出这样一条参考路线。第一阶段51单片机。虽然听起来土但51单片机是理解CPU如何执行指令、寄存器如何工作、外设如何被操作的最佳入门载体。花三个月把51玩透后续学任何平台都是降维打击。第二阶段STM32。从裸机开发走向RTOS理解中断、任务调度、信号量、消息队列这些嵌入式核心概念。这个阶段要多做几个完整的小项目比如智能家居网关、带屏幕的温控器、基于BLE的设备。第三阶段嵌入式Linux。从STM32进入到嵌入式Linux是一个门槛较高的跨越。要学的包括Linux基础命令、交叉编译环境搭建、驱动开发入门、根文件系统构建。这个阶段配合一块成熟的开发板把系统跑起来、把外设驱动调通是最重要的目标。第四阶段AI SoC与边缘计算。进入RK3588、Jetson这类带NPU的中高端平台学习模型转换、推理部署、性能调优。到这里你就具备了完整的产品开发能力——从原理图到系统到AI应用一个人能扛一整条链路。这条路走下来正常节奏大概需要两三年的时间。没有捷径但每一步都是在为后面的AI硬件开发打地基。4. 现场准备聊的几个硬核话题我先抛砖引玉4.1 把大模型塞进边缘设备硬件要做到什么程度这是最近被问得最多的话题。很多人想把LLM大语言模型部署到本地设备上做私人助理、本地知识库、离线对话机器人。那么问题来了跑一个7B参数的模型到底需要什么样的硬件我简单算一笔账。7B模型以INT4量化后体积大约是4GB左右。模型加载进内存时还要预留推理过程中的KV Cache和中间激活值保守估算至少需要6GB可用的内存空间。这就意味着你至少要有一台内存不低于8GB的设备而且这8GB里还必须留一部分给操作系统。内存带宽同样关键。LLM推理是典型的内存带宽瓶颈型任务带宽越好每秒生成的Token数越高。DDR4 3200的理论带宽大约是25.6GB/s跑7B INT4模型时理论最大生成速度只有6-7 token/s体验非常勉强。而LPDDR5-6400的双通道带宽能到51.2GB/s速度可以勉强翻倍。这也是为什么现在很多AI PC内置的是LPDDR5x高频内存而不是传统的DDR4。至于算力芯片端侧跑LLM目前有两种路线一种是纯CPU跑靠内存带宽硬扛大厂的高端SoC和桌面平台可以做到勉强可用的水平另一种是带NPU加速像高通的骁龙X系列、苹果的M系列都能用NPU加速部分Transformer算子但前提是推理框架对这些芯片做了专门的优化。现场我会把我这边测试过的一组真实数据带过去包括低端ARM板、x86迷你主机、带NPU的开发板三者跑同样模型的性能对比到时候直接摊开看。4.2 设备授权、硬件指纹与运维台账嵌入式产品避不开的问题做AI硬件产品做到一定程度一定会遇到授权管理的问题。设备给客户了怎么控制功能的使用期限怎么防止一套软件到处复制这时候就需要硬件指纹技术。硬件指纹的原理是把设备上唯一且不容易被篡改的硬件信息提取出来组合成一个字符串。常见的信息源包括SoC内部唯一的UID、eMMC的CID序列号、Flash的ID、有线网卡的MAC地址、蓝牙MAC等。把这些信息拼接起来做一个不可逆的哈希运算作为这台设备的唯一标识。授权系统的核心逻辑就是把这个硬件指纹和授权信息绑定。比如设备首次联网时把硬件指纹上报到授权服务器服务器生成一个用私钥签名的授权文件下发到设备端。设备端在离线状态下用预置的公钥验证签名确认授权有效后再运行对应功能。这里面最关键的防绕过机制就是让关键业务逻辑依赖硬件指纹的校验结果校验不通过就拒绝执行核心算法。校验本身要在安全环境下运行最好用TrustZone这类硬件级安全区防止被直接调试绕过。设备台账的管理还涉及另外一个问题——在线率。做设备管理系统的朋友应该深有体会设备一批发出去客户用了没、联网了没、有没有离线使用这些都只能靠设备主动上报才能知道。所以硬件设计阶段就要预留好远程管理的通道哪怕是一个低功耗的NB-IoT模块也比完全离线管理靠谱得多。4.3 嵌入式Linux里那些“看起来小、处理起来大”的坑做嵌入式Linux开发最大的感受就是问题永远出在最想不到的地方。我先把之前踩过的一个典型坑拿出来讲——Linux下Chromium的硬件视频解码。某次做一款带屏幕的智能终端用瑞芯微的方案系统是官方的嵌入式Linux里面带了一个Chromium浏览器。刚开始跑普通网页没问题但一打开视频播放页面CPU占用率直线飙升机器发烫播放卡顿明显。查了一圈发现Chromium默认用的不是VPU硬件解码而是走了软件解码的路径。软件解码1080P视频CPU就算满负荷也很难顶住。解决办法是启用Chromium的硬件视频解码支持需要在内核里确认VPU驱动正常加载Chromium启动时加上特定的参数还必须在视频解码相关的配置里打开特定开关。这里的难点在于嵌入式平台的Chromium往往经过定制和桌面版Chromium的配置方式不完全一样。网上搜到的资料很多是桌面版的方案直接套到嵌入式平台上根本不起作用。只能从官方源码和工程师论坛里一点点翻资料再结合日志分析逐步排查。这类问题的共性是驱动、中间件、应用三个层级之间的适配。芯片厂商往往只提供底层的驱动中间件层的适配要靠方案公司或者开发者自己解决。所以我的建议是碰到这种问题先固化几个关键日志文件的查看路径再锁定是驱动层、框架层还是应用层的问题逐层缩小范围别在一个层面死磕。4.4 硬件安全与防抄板、防篡改的几种做法AI硬件产品还有一个不能回避的话题——安全。硬件产品的安全分为几层防抄板、防固件提取、防通信劫持。防抄板是硬件产品最现实的需求。我自己做过的主要方案是把关键算法与芯片的唯一ID绑定。具体做法量产时用AI工具批量生成每台设备唯一的授权码授权码的计算基于芯片UID和厂商密钥的HMAC运算。芯片启动时固件自动从Security ID寄存器里读取UID用同样的算法计算一遍授权码两边不一致就拒绝运行核心功能。这个方案的优点是不用额外增加硬件成本缺点是UID可以被读出来安全性取决于密钥的保管程度。如果对安全等级要求更高就要上硬件安全芯片。这类方案的工作原理是在MCU和主控之间加一颗独立的安全芯片密钥存储在安全芯片内部无法通过外部总线读取。解密、签名运算都在安全芯片内部完成主控只能拿到运算结果拿不到密钥本身。这就是真正意义上的“一拆即损坏”——拆机时只要检测到外部干预动作安全芯片立即擦除内部密钥让设备彻底失效。通信层的安全也不能忽视特别是BLE设备。做智能硬件的人应该有所了解BLE通信默认是明文或者弱加密的非常容易被抓包重放。现在比较成熟的做法是在应用层做Token签名——每次通信都携带一个签名值签名算法结合时间戳、随机数和预共享密钥。签名校验失败则丢弃数据不执行任何指令。这比依赖底层的加密链路要更可控因为应用层签名即使被破解也只影响当前协议版本修改协议就能规避。5. 9月5日杭州的这场交流怎么玩、聊什么、能带走什么5.1 这次活动适合哪些人来我先说清楚活动的调性不是专家讲座不是带货直播更不是纯社交的酒会而是一场小范围的、以“聊透问题”为目的的技术交流会。适合来的人包括硬件工程师正在做或者计划做AI硬件产品想了解别人怎么选型、怎么部署、怎么避坑。嵌入式软件工程师在做Linux系统、驱动移植、应用开发想了解AI产品对软件架构的新要求。AI算法工程师习惯了云端部署想了解端侧部署的约束和技巧。产品经理和创业者有AI硬件的想法想和一线工程师深度聊聊方案可行性避免拍脑袋做产品。如果你只是对AI这个概念感兴趣没有任何实际项目经验那这场聊天的内容可能会有点深。建议先做一点功课哪怕是买一块一百多块的开发板跑通一个Demo再过来听会更有收获。5.2 现场大概怎么安排场地定在杭州时间是9月5日下午。具体的场地地址因为人数还在确认我会提前在组建的交流群里发定位。流程不搞那种“台上讲两小时、台下刷手机”的形式核心是让每个人都有开口的机会。我的初步想法是这样先安排一轮快闪自我介绍。来的每个人都用一分钟简单说明自己正在做什么、遇到了什么问题、最想聊什么话题。别小看这一分钟很多人讲着讲着就能发现自己真正关注的核心问题是什么。然后是主题开放麦。我会把上面文章里提到的几个话题——边缘部署、硬件指纹授权、嵌入式Linux的坑、硬件工程师转型——分别放在几张小桌上。大家自由选择加入感兴趣的话题组聊完一圈还可以换桌。每桌有一位话题召集人负责引导讨论节奏。最后是Demo分享。如果你手头有正在做的项目欢迎带过来现场演示。不需要多精致哪怕是一个跑得歪歪扭扭的机器人原型、一块裸板加一个摄像头都能成为最受欢迎的讨论素材。做硬件的人都知道实物一摆出来问题一目了然比PPT有用一百倍。5.3 来之前建议准备什么来之前我给各位三个小建议。第一带着真问题来。那种“我想了解AI硬件”之类的模糊问题在现场很难得到有效回应。但是“我在RK3588上部署YOLOv8遇到了算子不支持的问题”“我的BLE设备总在锁屏后掉线”这类具体问题一定会有人给你实在的建议甚至直接帮你定位到是哪一层的bug。第二带着项目来晒一晒。哪怕是翻车项目也完全可以。做技术交流失败经验往往比成功经验更值钱。你踩过的坑可能刚好是另一个人正在爬的坡分享出来不光帮了别人也可能从别人的反馈里获得新思路。第三带着联系方式来。现场加了微信之后主动备注清楚自己的名字、行业、正在做的事。会后真正的高价值交流往往在这个阶段才刚开始。关于这场交流我还会在后续几天把一些不方便在公开平台上细聊的实战案例整理成小册子带来现场分发给到场的各位。到时候见。说点个人体会。做AI硬件这条路上最深的感受就是一个人的经验边界太窄了。软件出身的团队不懂供应链硬件出身的团队搞不定模型部署产品出身的团队算不清成本结构。而这些能力的补齐最快的途径不是看书、不是上网课而是找一个真实的场景坐下来跟一群正在踩坑的同行聊上两三个小时。9月5日杭州这张桌子已经摆好就看谁来坐了。