企业官网建设流程全解析

9月5日，杭州见！办这场AI硬件主题聚会，其实是我和几个朋友在饭桌上聊出来的。做硬件做了十来年，眼看着AI从云端卷到终端、从算法卷到芯片，身边的工程师和产品经理都在问同一件事：AI落到硬件上，到底怎么做才靠谱？

这篇文章既算活动预告，也算我对这个方向的一次系统性梳理。我会把AI硬件拆开来讲：市面上的主流方案、工程师实战中躲不开的技术点、新人怎么入局，以及9月5日现场究竟会聊什么。如果你是嵌入式工程师、硬件工程师、产品经理，或者正在做AI应用落地，这篇内容应该对你有用。

1. AI硬件，到底是个什么行当

1.1 大模型落地，硬件才是真正的门槛

过去两年大家聊AI，聊的基本都是算法和模型：哪个模型又刷榜了、哪个参数量又翻倍了。可真到了交付阶段，所有人都会撞上同一堵墙——算力从哪里来？模型放哪里跑？功耗散不散得掉？

这堵墙就是硬件。

举个很简单的例子：一个云端大模型API调用，服务商在背后用的是成千上万张加速卡，这些卡部署在数据中心里，动辄几十千瓦的机柜功耗。这个体量普通企业玩不起，更别提端侧设备。于是大家开始把目光转向端侧推理：在手机、开发板、工控机上直接跑模型，不依赖网络，延迟更低，数据也不出设备。

可端侧推理的第一个问题就是硬件吃不消。一块普通的嵌入式主板，CPU算力有限，内存带宽也就几十GB每秒，跑一个百亿参数的大模型根本想都别想。所以你会看到，现在很多做AI硬件的团队，核心工作根本不是训练模型，而是怎么把一个已经训练好的模型塞进一个资源极其有限的设备里，还要让它跑得快、跑得稳。

这就是我理解的AI硬件：它不是某一类具体产品，而是让AI算法能在物理设备上真正跑起来的一整套工程体系。从芯片选型、电路设计、散热结构，到推理引擎、算子优化、系统集成，全都在这个范畴里。

这场聚会之所以定在杭州，也是因为杭州这边的硬件团队和AI应用团队密度确实高，做安防的、做机器人的、做智能家居的，基本都绕不开这个话题。饭桌上大家各说各的痛点，聊到最后发现都是同一个根源：硬件和算法的距离被拉得太近了，谁都得懂点对方的东西。

1.2 软件定义硬件，还是硬件定义软件

传统硬件开发的节奏是三到五年一个周期。芯片选型、原理图绘制、PCB布局、打样、测试、量产，每一步都有严格的流程和文档。但AI时代把这个节奏彻底打乱了。

现在很多项目的启动方式是：先有一个AI功能的想法，比如“做一个能识别手势的摄像头”、“做一个能在本地跑语音助手的音箱”，然后才开始想用什么芯片。甚至更极端的情况是，模型已经训好了，才发现手头的硬件跑不动，不得不回头重新选平台。这在传统硬件工程师看来是典型的“先开枪后瞄准”，但在AI硬件项目里却是家常便饭。

这也带来一个很有意思的讨论：到底是软件定义硬件，还是硬件定义软件？

我的看法是，AI硬件项目里这条界线已经被抹掉了。算法工程师必须懂一点显存带宽和内存布局，硬件工程师也必须懂一点模型量化和推理引擎。以前那种“我把接口留好，你跑什么算法都行”的思路，在AI场景下基本行不通。因为不同模型的算子对硬件的利用率差异巨大，一个在GPU上表现很好的模型，移植到NPU上可能性能缩水一半，原因可能只是某个算子不支持、或者内存分配策略不一样。

所以现在做得好的AI硬件团队，普遍是算法、嵌入式、硬件三个角色坐在一起办公，从项目第一天就开始对参数、对接口、对约束。这不是管理风格的问题，是技术路线决定的。

1.3 终端侧AI的两种路线：专用NPU与通用算力

很多第一次接触AI硬件的人都会问：做端侧AI，到底是选带NPU的芯片，还是选一个通用处理器硬扛？

这个问题的答案取决于场景，我展开说说。

专用NPU路线的典型代表是瑞芯微RK3588、算能BM1684这类芯片，它们内部集成了针对卷积、矩阵运算优化的专用加速单元，跑AI推理的效率很高，能效比也好看。但代价是，NPU的编程模型和GPU完全不同，算子库支持有限，很多在GPU上轻易能跑的模型结构，到了NPU上可能要做结构改动甚至重新训练。我见过不少团队栽在这上面：模型在PC上跑得好好的，移植到NPU平台后精度没问题，但性能就是上不去，最后只能一层一层排查算子支持情况，非常折腾。

通用算力路线的代表是英伟达的Jetson系列，以及一些用GPU做推理的工控机。这条路线的优势是软件生态完善，CUDA生态下几乎所有模型都能跑，开发效率高。代价是成本高、功耗高，而且受供应链影响比较大。

还有一种折中方案是用手机SoC或者带较强CPU/GPU的处理器硬跑。比如现在很多AI眼镜、AI翻译机用的是高通或联发科的平台，直接调用它们自带的AI加速库，效果也不错，但定制空间相对有限。

我自己做选型的时候有个习惯：先画一张表，把“目标帧率、可用功耗、量产成本、开发周期”四个维度列清楚，再决定走哪条路线。没有哪个平台是绝对最好的，只有当下这个项目最合适的。

2. 做AI硬件，绕不开的几个技术模块

2.1 算力选型：从显卡规格到开发板配置

如果只是做算法验证，一台带好显卡的PC就够了；但要做产品，就得面对算力选型这个现实问题。

前阵子有个朋友问我，想跑一些3D生成类的模型，Trellis这类项目训练或推理到底需要什么硬件。我当时给他算了一笔账：如果只是推理，一块24GB显存的消费级显卡基本能跑，但要做训练或者调优，显存就得往48GB以上走，那就是A6000或者A100这个级别了。更关键的是，显存带宽决定了数据搬运的速度，很多情况下模型算得再快，数据喂不进去也是白搭。

这个道理在端侧设备上同样成立。选嵌入式平台时，除了看CPU核数和主频，更要关注内存通道数和带宽。我实测过不少开发板，同样的模型在单通道LPDDR4和双通道LPDDR5上跑，推理耗时能差出一倍。很多人选型只看芯片型号，买回来一测才发现性能不达标，问题往往就出在内存配置上。

还有一个容易忽略的点是散热。AI推理是典型的持续高负载场景，芯片满负荷运行时功耗会急剧上升。如果开发板或者机箱的散热设计跟不上，芯片会主动降频，性能直接腰斩。我之前做过一个边缘盒子项目，实验室环境测试帧率稳定，装进客户现场的密闭机柜后帧率掉了40%，排查到最后就是过热降频。后来换了带风扇的散热模组，问题才解决。

所以选型这件事，我的建议是不要只看芯片厂商宣传的算力TOPS，那是理论峰值，实际能跑到多少，跟你的散热、内存、主板设计都有关系。最好的办法是拿你的真实模型去目标板卡上实测，跑一版完整的推理流程，记录帧率和功耗，再做决定。

2.2 端侧推理部署：模型压缩、推理引擎和算子优化

算力平台选好之后，真正的工作才刚刚开始。把一个训练好的模型部署到端侧设备，中间至少隔着模型转换、量化、算子适配、内存优化这几道工序。

模型转换是第一关。PyTorch训练出来的模型通常是动态图结构，端侧推理引擎需要的是静态图或者特定格式。常见路径是先导出ONNX，再转换成目标平台的格式。这个阶段最常遇到的问题是某些算子不被目标引擎支持，一旦遇到就需要找替代方案：要么改写模型结构，要么用更高版本的引擎，要么干脆手写算子。说实话，算子适配是AI硬件落地中最耗时的一环，没有之一。

量化是第二关，也是最考验经验的一关。把FP32的模型变成INT8甚至INT4，模型的体积和推理速度都会有质的提升，但精度多多少少会有损失。怎么选校准数据集、怎么评估量化误差、哪些层不适合量化，这些问题没有标准答案，只能靠实测。我的经验是，先做全模型INT8量化，如果精度掉得厉害，再逐层分析，把敏感层保留为FP16，通常能找到性能与精度的平衡点。

推理引擎的选择也很有讲究。市面上常见的有ONNX Runtime、TensorRT、OpenVINO、Tengine、NCNN，还有各大芯片厂商自研的引擎。同一个模型在不同引擎上的表现差异非常大，有的引擎对某种算子的优化特别好，换个引擎性能就崩了。所以我的建议是不要迷信某个引擎，多跑几个版本对比一下，找到最适合你当前平台和模型组合的那一个。

另外还有一个不得不提的层面：在Linux环境下做硬件解码。很多AI视觉项目需要同时处理多路视频流，如果CPU软解，几个720P的流就能把负载拉满，根本没有余量跑推理。正确的做法是用平台自带的硬件解码模块，比如Rockchip平台的MPP库，把解码任务交给专用硬件，CPU只负责推理逻辑。但这也意味着你的代码要跟平台强绑定，移植性会变差。这是一个需要权衡的取舍。

2.3 设备授权与硬件指纹：经常被忽视的隐形项目

AI硬件项目做到后期，大多会面临一个很现实的问题：怎么防止自己的软件和模型被别人抄走。很多团队只关注功能实现，等到要量产交付了才发现，自己的程序只要复制一份到另一台设备上就能跑，版权和收益完全没有保障。

这时候硬件指纹和设备授权就是绕不开的课题了。

所谓硬件指纹，就是通过读取设备的唯一硬件标识来生成一个不可伪造的ID。最常见的来源是CPU序列号、MAC地址、Flash的唯一ID、或者某些芯片内置的UID。但直接用单一硬件标识做授权有个问题：用户换一块网卡、换一个存储芯片，授权就失效了，反而惹来一堆售后投诉。所以我一般建议把多个硬件信息组合起来，做一个加权哈希，生成一个相对稳定的指纹。

有了设备指纹之后，还要设计授权流程。常见做法是：设备首次启动时生成指纹和激活请求，用户把激活码发回给厂家，厂家用私钥签发授权文件，设备导入后完成激活。这里面涉及到一组公钥私钥体系，授权文件要做签名校验，防止被篡改。

再往深一层，就是硬件信任根的概念。所谓信任根，就是系统中最底层、最不可篡改的那个信任锚点。在嵌入式设备里，通常会用一颗独立的安全芯片来存储密钥，所有敏感操作都在这颗芯片内部完成，即使攻击者读出了Flash内容，也拿不到核心密钥。这个思路做出来的设备，即使被人拆开研究，也很难被彻底破解。

顺便说一下硬件保密里的“防拆”设计。热搜词里有一条“硬件保密一拆损坏”，这是很多做加密设备团队的做法：在PCB上布置张力检测回路或者防拆开关，一旦设备被拆开，检测到异常就立即擦除敏感数据或者锁死芯片。这在金融终端、税控设备上很常见。但防拆设计会增加成本和制造复杂度，到底做到什么程度，取决于你的产品值不值得被破解。

2.4 通信协议定制：从BLE到EtherCAT的演进

AI硬件很少是孤岛，它总要跟其他设备通信。通信协议这块看着基础，实际上水很深，而且直接决定产品的用户体验和可靠性。

我最早做单片机项目时，通信协议基本都是自己定的：一个帧头、一个命令字、若干数据、一个校验。这种私有协议简单直接，适合51单片机这种资源紧张的平台，但扩展性很差。后来做智能硬件，遇到BLE设备之间的通信，就要认真考虑GATT服务的设计了。一个典型问题是：设备状态需要主动上报，但BLE的写通道带宽有限，怎么设计特征值和通知机制才能兼顾实时性和功耗？这里面的细节太多了，比如MTU大小、连接间隔、数据分包策略，每一个都能影响用户体验。

到了工业场景，EtherCAT又是一个完全不同的世界。它属于实时以太网协议，数据帧在从站之间逐个传递，每个从站处理自己的数据后继续转发，微秒级的同步精度。做EtherCAT学习的人基本都是冲着运动控制去的，因为伺服驱动器之间需要严格的时钟同步，差一微秒整个设备就会抖动甚至失控。

AI硬件里的通信协议设计，核心原则其实只有一条：搞清楚你的系统里面，哪个环节对延迟最敏感，哪个环节对带宽最敏感，然后针对性设计。不要什么都往高带宽、低延迟方向堆，成本和功耗都是代价。我在很多项目里见过一个通病：通信需求没有想清楚就照着最高规格设计协议，最后硬件资源被通信模块吃掉一大半，留给AI处理的部分所剩无几。

3. 硬件工程师成长路上的典型场景与踩坑记录

3.1 从51单片机到嵌入式Linux：一个必经的坎

很多硬件工程师的入门都是从51单片机开始的，我也不例外。51的好处是简单、直观、资源透明，所有逻辑都在裸机上跑，出了问题很容易定位。但一旦开始做AI硬件，51这套技能基本就不够用了，因为AI推理需要操作系统、内存管理、多线程调度，这些都需要一个完整的嵌入式Linux环境来支撑。

从裸机开发切到嵌入式Linux，最大的心理门槛是：你不能再像以前那样完全控制每一行代码的执行顺序了，代码运行在操作系统之上，有进程调度、有中断优先级、有设备树，出错的方式比裸机时代复杂得多。

我的经验是，跨过这个门槛最好的办法是买一块主流开发板，从交叉编译工具链搭起，先写一个最简单的应用，然后逐步加功能：GPIO点灯、串口通信、摄像头采集，最后跑一个小型AI识别程序。这个过程走一遍，你就把嵌入式Linux的整个工具链摸熟了。

还有一个很实际的点：现在的AI硬件项目，十有八九都是恩智浦、瑞芯微、全志或者英伟达这类平台的方案，这些平台的官方SDK已经把底层驱动做得很完善了，你真正要花精力的是应用层和AI推理层。很多年轻工程师总觉得要从驱动开始造轮子，其实没必要，能用好半成品也是本事。

3.2 Windows驱动数字签名问题：一次现场排查实录

做硬件研发，免不了要和各种调试工具、仿真器、虚拟仪器打交道。前阵子有个同事在Win7的老机器上装一个调试设备的驱动程序，系统弹了一行字：“Windows无法验证此设备所需的驱动程序的数字签名”，驱动直接装不上。

这个报错非常典型，Win7时代尤其常见。原因很简单，现在的驱动都要求有微软的签名认证，如果驱动没有正确签名，或者系统时间不对导致证书校验失败，就会触发这个提示。对于测试设备来说，很多厂商的驱动更新不及时，签名过期或者缺失，于是就被系统拒了。另外Win7是出了名的对硬件变更敏感，有时只是换了某个硬件，原来能用的驱动也会突然提示签名问题。

当时我们的处理方案有三个，按优先级排列：第一，先关掉驱动强制签名机制，Win7开机时按F8，选择“禁用驱动程序签名强制”，能临时解决问题；第二，检查驱动文件是否完整，重新安装官方最新版本驱动；第三，如果可能是系统时间偏移导致的证书校验失败，先校正时间再装驱动。那个项目排查下来，最终是第二种方案解决的——驱动文件本身损坏了，重新下载安装包后一切正常。

这件事给我一个很深的印象：AI硬件项目里，你永远不知道问题会出现在哪个层级。芯片、电路、驱动、系统、应用、算法，每一层都可能出问题。所以硬件工程师的排查能力，很多时候比编码能力更重要。

3.3 硬件保密与防拆设计：一拆损坏的取舍

前面提到硬件指纹和信任根，这里再展开聊聊防拆设计。

做AI硬件产品，模型和算法往往是核心资产。如果你把模型直接存在普通Flash里，对手拿到设备后用编程器就能把固件读出来，逆向工程几乎没有门槛。所以很多团队会做加密存储，也就是把模型文件用密钥加密后再写入存储设备，运行时再解密加载到内存。密钥放在安全芯片里，这样即使固件被读走，没有密钥也解不开。

再进一步就是防拆。我见过的一个方案是在外壳内部和PCB之间布置多个微动开关，只要打开外壳，开关状态变化就会被主控检测到，触发立即擦除密钥。还有更硬核的做法，直接把密钥存储区域用灌胶封死，或者使用一种特殊电池，断电后密钥自动消失。这些设计叫“一拆损坏”或者“自毁”，成本都不低。

这里有个很现实的取舍：你的产品值不值得加这些防护。如果你的AI硬件是大众消费类产品，破解成本可能比产品本身还高，那就没必要做太复杂的防护；但如果是企业级的边缘计算设备，里面跑着定制模型和客户数据，防拆设计就是必须的。我给团队的建议是：先评估资产价值，再决定安全投入。

3.4 AI硬件的测试闭环：性能、功耗与稳定性

算法测试和硬件测试完全是两种思维。算法工程师关心的是准确率、召回率，硬件工程师关心的是帧率、功耗、温升、长时间运行的稳定性。AI硬件如果只做算法验证就交付，大概率会在现场翻车。

我通常会给AI硬件项目做三层测试。第一层是功能测试：跑通完整的AI流程，确认结果正确。第二层是性能测试：持续压测目标帧率，记录CPU、GPU、NPU占用率和内存占用率。第三层是环境测试：高温、低温、高湿度、长时间老化，这一层最容易暴露问题。很多开发板在实验室的24度环境里跑得挺好，一放进密闭机柜或者户外设备箱，温度一上来就降频，性能大跳水。

还有一个容易忽略的点是测试数据要和真实场景匹配。做视觉识别的，一定要准备真实场景的素材来测试，不要拿干净的数据集甚至网上的图片来跑。真实场景的光线、遮挡、运动模糊都会影响AI效果，但这些问题不是算法层面能完全解决的，很多时候和摄像头选型、镜头焦距、安装位置都有关系。这也是为什么我总是强调，做AI硬件的人一定要去现场看设备运行的真实情况。

4. 9月5日杭州现场，我们想聊点什么

4.1 三个圆桌主题和我的预期

这次聚会，我们设计了三个圆桌环节，每个都对应AI硬件从业者当下最关心的问题。

第一个圆桌聊端侧AI落地的真实成本。很多人一上来就问“这个芯片能跑多少TOPS”，但其实TOPS只是个参考值，真正决定成本的是：你需要多少内存、多大Flash、什么等级的电源管理、什么样的散热结构。一个能跑模型的低成本方案，物料成本可以从两百元到两千元不等，差距全在这些看起来不起眼的配套细节里。

第二个圆桌聊大模型与硬件的协同设计。现在很多团队用大模型做Agent类的应用，但Agent系统一旦要跑在端侧设备上，就面临一个尴尬：大模型动辄几GB权重，端侧设备的存储和内存根本扛不住。这个圆桌我们想聊聊，在模型变小、推理引擎优化、软硬件裁剪这些方向上，大家有什么实践经验。

第三个圆桌是硬件工程师成长话题。我特意邀请了从51单片机一路做到AI硬件平台的工程师来分享踩坑经历。很多年轻工程师问“要不要学Linux”“要不要学算法”，答案其实不是要不要，而是怎么在现有基础上一步步往上走。这个话题最没有鸡汤味，全是过来人的挫折和试错，我觉得会非常有意思。

4.2 现场硬件演示与开发板实测区

光聊不练没什么意思，所以现场我们会放一批真实硬件，大家可以直接上手把玩。

我剧透几个：有跑着开源大模型的开发板，实时对话的那种；有几款不同价位的边缘AI盒子，正在跑目标检测，大家可以现场比较它们的帧率和画质；还有一个用BLE通信控制的小型机械臂，展示AI视觉引导抓取的工作流程。如果你是芯片选型困难户，现场对比是最直观的解决方案。

我们还设置了自带的实测环节：你带上自己的模型或者代码，现场找一块顺眼的开发板直接部署测试。这个环节没有标准答案，就是让大家在真实环境里碰一碰，看看会遇到哪些坑。我们几个组织者会一直在，遇到问题随时拉过来讨论。

4.3 报名提醒和适合哪些人

这次活动没有设置太高的门槛，但考虑到场地容量有限，还是需要提前报名。适合来的人我列三类：第一类是正在做或者准备做AI硬件产品的工程师和产品经理；第二类是算法工程师想了解硬件落地瓶颈的；第三类是刚入行不久、想听听行业真实情况的年轻朋友。

如果只是想听概念、听完就走，那这次活动可能不适合你。我们更希望来的人带着自己的真实问题，哪怕是“我买了一块某某开发板，跑模型总是报错”这种非常具体的小问题，也欢迎现场拿出来聊。活动的核心目标就是让问题在现场被解决或者至少被理解和记住。

5. 给即将入场的人几句实在话

5.1 学习优先级：先跑通再深入

如果你是个刚接触硬件的新人，又对AI硬件方向感兴趣，我的建议是：不要一上来就追最新的模型结构，也不要执着于啃完某本大部头的书。先把一条最简单的链路跑通：买一块主流开发板，搭好环境，跑一个现成的人脸检测或者语音识别例程，然后在它的基础上改一改，哪怕只是换一个检测目标，你都能学到非常多的东西。

很多硬件工程师的成长路径其实不是靠系统学习，而是靠一个个真实的项目喂出来的。每碰一个项目，被坑一次，你的知识边界就扩大一圈。与其花半年时间学完所有理论再动手，不如先动手，在动手过程中发现缺什么就补什么。这条路走的弯路可能更多，但踩过的坑都变成了自己的经验。

另一个建议是尽早建立“系统思维”。做AI硬件的人，不能只盯着自己手上的那一层。画板子的人要想想算法为什么这么设计，写算法的人要了解板子的算力边界，做产品的人要理解供应链和成本结构。很多时候产品的失败不是某个环节技术不行，而是各环节之间没有对齐。

5.2 值得长期盯的几个方向

结合我自己的观察，接下来一段时间有几个AI硬件方向值得持续关注。

第一个是端侧大模型推理。随着模型小型化和推理引擎的优化，在本地跑大模型会成为越来越多产品的标配，隐私和延迟是两个核心驱动因素。第二个是AIoT的智能化升级，传统物联网设备接入AI能力后，可以从“数据采集器”变成“智能决策器”，这里面的想象空间很大。第三个是AI Agent在硬件设备端的落地。现在AI Agent大多是跑在云端的，但如果能和硬件设备联动，比如让Agent直接控制传感器、执行器、机械臂，那就真正把AI从对话拉进了物理世界。

还有一个观察点：AI编程对硬件工程师的影响。现在已经有AI工具能生成Verilog代码了，也能辅助做PCB布局和电路设计的某些环节。这会不会改变硬件工程师的工作方式？我的看法是，底层逻辑不会变——你需要深刻理解硬件特性和系统约束，才能判断AI生成的代码对不对。AI是工具，不是替代品，但这个工具会淘汰那些只会按套路做事的人。

5.3 我的个人体会

做了这么多年硬件，我最大的体会是：硬件项目没有“差不多就行”这回事。软件出Bug可以快速修复，硬件如果前期某个设计考虑不周，改板周期按周计算，产线问题按批计算，代价完全不是一个量级。所以在AI硬件项目里，前期的参数论证和技术验证做得越扎实，后期返工的痛苦就越少。

另一个体会是：AI硬件的成功靠的是跨学科碰撞。我见过最厉害的项目组，不是每个人都懂所有东西，而是每个人都能听懂对方在说什么。软件工程师能理解硬件工程师说的“电源纹波”，硬件工程师能理解软件工程师说的“推理延迟”，这种互相理解才是项目推进的润滑剂。

9月5日，杭州见。带上你的项目、你的问题、你的开发板，我们当面聊。