1. 这期周报到底在聊什么做AI硬件这行有个特别有意思的现象软件圈的人觉得硬件迭代慢硬件圈的人觉得软件那套玩法根本落不了地。我两边都待过说实话2026年开年到现在AI硬件这个赛道的变化速度已经让很多传统硬件团队开始焦虑了。这期周报我攒了两周的信息挑出来的东西都是我认为值得花时间琢磨的不是那种发个新闻稿就完事的玩意儿。先把这个周报的定位说清楚。它解决的核心问题是AI硬件领域信息太散芯片、模组、终端、供应链、开发工具链每个环节都有各自的圈子但真正做产品的人需要的是跨层的视角。比如你是一个做智能穿戴的团队你不仅要知道哪家出了新的低功耗NPU还得知道这个NPU的SDK成熟度怎么样、有没有量产案例、供货周期稳不稳定。这些信息散落在不同的渠道里我做的事情就是把它们串起来加上我自己的判断。适合谁看如果你是做AI硬件产品定义的、做嵌入式AI开发的、做硬件创业的或者你是一个软件工程师想了解AI硬件到底能干什么、现在到什么程度了这期内容应该都能给你一些有用的东西。我不会堆一堆参数让你自己判断我会告诉你这些参数在实际场景里意味着什么。这期的关键词我列一下端侧推理芯片、低功耗NPU、AI模组方案、边缘计算盒子、开发工具链、量产落地。这几个词基本覆盖了当前AI硬件从底层到应用层的主要讨论热点。2. 端侧推理芯片的格局变化2.1 为什么端侧推理突然成了焦点前两年大家聊AI硬件言必称云端训练、大模型参数规模。但从2025年下半年开始一个明显的转向出现了推理往端侧走。这个转向不是拍脑袋决定的背后有三个硬逻辑。第一个逻辑是延迟。你做一个智能门锁的人脸识别如果每次都要把图像传到云端、等结果返回、再控制电机开锁这个链路走下来少说几百毫秒网络不好的时候直接卡住。用户体验就是“这锁怎么反应这么慢”。端侧推理可以把延迟压到几十毫秒以内这个差距是质变的。第二个逻辑是隐私和合规。越来越多的场景要求数据不出设备比如医疗健康类的可穿戴设备、家庭监控摄像头。你不可能把用户的健康数据、家庭视频传到云端去处理这在很多市场已经不只是技术选择而是合规红线。第三个逻辑是成本。云端推理看起来按量付费很灵活但量大了之后成本是线性增长的。端侧推理是一次性硬件成本量越大摊得越薄。我算过一笔账一个每天处理一万次推理的设备云端方案一年下来的费用够买好几颗端侧推理芯片了。这三个逻辑叠加直接推动了端侧推理芯片的爆发。但爆发归爆发真正能用的方案和PPT上的方案差距还是很大的。2.2 当前主流端侧推理芯片的几条技术路线我先把目前市面上能看到的端侧推理芯片做个分类这样你选型的时候心里有数。第一条路线通用SoC集成NPU。这类方案的代表是高通、联发科这些手机芯片厂商他们在SoC里塞了一个NPU单元算力从几TOPS到几十TOPS不等。优势是生态成熟、开发工具链完善、供货稳定。劣势是NPU是附带的不是主业遇到特别定制化的算子支持可能不够好。适合场景智能家居中控、智能音箱、带AI功能的平板。第二条路线专用推理芯片。这类芯片只干推理这一件事架构上做了大量针对性优化。优势是能效比极高同样的算力功耗可能只有通用SoC的三分之一甚至更低。劣势是开发门槛高工具链相对不成熟而且通常需要搭配主控使用。适合场景电池供电的穿戴设备、Always-on的视觉感知模组。第三条路线FPGA/可重构架构。这类方案的优势是灵活性极高算法变了硬件可以跟着变。劣势是单位成本高、功耗大、开发难度大。适合场景小批量、算法快速迭代的工业检测设备。第四条路线存算一体架构。这是最近两年比较热的方向把计算单元和存储单元放在一起减少数据搬运的功耗。优势是能效比理论上限很高劣势是工艺成熟度还在爬坡量产案例少。适合场景对功耗极度敏感的传感器端推理。我把这四条路线的关键维度做了个对比路线算力范围能效比开发难度生态成熟度适合场景通用SoC集成NPU1-50 TOPS中等低高智能家居、平板专用推理芯片0.1-10 TOPS高中高中穿戴、视觉模组FPGA/可重构0.5-20 TOPS低高中工业检测存算一体0.1-5 TOPS极高高低传感器端这张表你选型的时候可以直接参考但要注意算力数字只是参考实际有效算力取决于你的模型能不能跑满、算子支持好不好、内存带宽够不够。2.3 选型时最容易踩的三个坑我见过太多团队在选型阶段就埋下隐患后面量产的时候痛不欲生。这里说三个最常见的坑。第一个坑只看峰值算力不看有效算力。芯片规格书上写的都是峰值算力但你的模型跑上去能用到多少是另一回事。我见过一个案例某芯片标称8TOPS结果跑一个常见的视觉模型只能跑到1.5TOPS的有效算力因为算子不支持、内存带宽瓶颈、调度效率低。选型的时候一定要拿自己的模型去实测别信规格书。第二个坑忽略工具链成熟度。芯片再好工具链不行你也用不起来。工具链包括编译器、量化工具、调试工具、模型转换工具。我建议在选型阶段就做一件事拿你的模型走一遍从训练框架到芯片部署的完整流程看看中间有多少坑。如果模型转换就卡住了后面的事都不用谈了。第三个坑低估供货周期。AI硬件芯片的供货周期波动很大尤其是专用推理芯片。我经历过一个项目选型的时候芯片厂商说8周交货结果量产的时候变成20周直接导致产品上市延期。选型的时候一定要问清楚量产阶段的供货周期是多少有没有备选方案能不能签供货保障协议提示选型阶段建议至少评估三家芯片方案不要只盯着一家。即使最后只用一家备选方案的存在也能让你在商务谈判和供货保障上有更多筹码。3. 低功耗NPU的设计逻辑与实操要点3.1 低功耗到底低在哪里“低功耗NPU”这个词现在被用得很泛但真正做低功耗设计的人知道功耗不是一个单点问题而是一个系统问题。我从几个层面拆一下。架构层面的功耗优化。NPU的功耗大头在数据搬运不是在计算本身。有研究数据表明在典型的推理任务中数据搬运的功耗可以占到总功耗的60%到80%。所以低功耗设计的核心思路是减少数据搬运把权重放在片上存储里、用数据流架构让数据在计算单元之间直接流动、做算子融合减少中间结果的读写。工艺层面的功耗优化。制程越先进同样算力的功耗越低。但先进制程的成本也越高所以这里有个平衡点。对于端侧推理芯片来说22nm到12nm是比较常见的区间再往下走成本上升太快除非出货量极大。电源管理层面的优化。这包括动态电压频率调节、多电源域设计、时钟门控等技术。好的电源管理可以让芯片在轻负载时把功耗压到极低重负载时再拉起来。这个对Always-on的场景特别重要。算法层面的优化。模型量化、剪枝、知识蒸馏这些技术可以大幅降低计算量和内存占用从而降低功耗。一个经过良好量化的INT8模型功耗可能只有FP32模型的三分之一。3.2 实测功耗的方法和注意事项规格书上的功耗数字通常是在理想条件下测的实际场景的功耗可能差很多。我分享一下我的实测方法。测试环境搭建。你需要一个可编程电源、一个高精度的电流探头、一个数据采集卡。如果没有这些设备至少需要一个能记录电流曲线的USB功率计。测试的时候要确保供电电压稳定因为很多芯片的功耗对电压很敏感。测试用例设计。不要只测一个模型要覆盖你的实际业务场景。比如你做智能门锁就要测人脸检测、人脸识别、活体检测这几个模型的功耗还要测待机功耗、唤醒功耗、连续运行功耗。每个场景的功耗特征都不一样。数据记录和分析。记录至少10分钟以上的电流曲线然后分析平均功耗、峰值功耗、功耗波动。峰值功耗特别重要因为它决定了你的电源设计余量。我见过一个案例平均功耗只有50mW但峰值功耗到了500mW电源设计没留够余量导致系统不稳定。温度影响。芯片功耗会随温度变化通常温度越高漏电越大、功耗越高。测试的时候要在高低温环境下都测一遍至少覆盖0度、25度、45度、70度这几个点。注意实测功耗的时候一定要用真实模型和真实数据不要用厂商提供的demo模型。demo模型通常是优化过的功耗表现会比真实模型好很多。3.3 低功耗设计的几个实操技巧技巧一用好DVFS。动态电压频率调节是低功耗设计的基本功。关键是要根据实际负载来调不要一直跑在最高频率。我通常的做法是设置几个档位轻负载跑低频、中负载跑中频、重负载才跑高频。切换的阈值要根据实测数据来定不要拍脑袋。技巧二做好内存分级。把最常用的权重放在最近的存储里不常用的放在远端的存储里。这个需要和算法团队配合在模型设计阶段就考虑内存布局。技巧三利用事件驱动。很多端侧推理场景不是连续运行的而是事件触发的。比如视觉感知有人经过才启动识别。这种场景下待机功耗比运行功耗更重要。要确保待机的时候芯片真的在休眠而不是在空转。技巧四注意外设功耗。NPU本身的功耗可能不高但配套的传感器、内存、接口电路的功耗加起来可能比NPU还高。做系统功耗预算的时候要把这些都算进去。4. AI模组方案的落地实践4.1 模组方案为什么越来越受欢迎以前做AI硬件很多团队是从芯片开始自己设计板子。但这几年模组方案越来越流行原因很简单省事。一个AI模组通常集成了推理芯片、内存、存储、电源管理、接口电路有的还集成了传感器和无线通信。你拿到模组基本上只需要做外围设计和结构设计开发周期可以缩短好几个月。但模组方案也不是没有代价。首先是成本模组的单价肯定比你自己买芯片做板子高。其次是灵活性模组的接口和尺寸是固定的你的产品设计要围着模组转。第三是供货模组的供货受模组厂商的芯片采购情况影响有时候比直接买芯片还不稳定。所以模组方案适合什么团队我的判断是产品定义清晰、出货量中等、开发资源有限的团队。如果你出货量极大自己设计板子更划算。如果你产品还在探索期、需求可能大变模组方案的灵活性可能不够。4.2 模组选型的关键参数选模组的时候我通常会看这几个维度算力与模型支持。不要只看TOPS数字要看支持哪些算子、支持哪些模型格式、有没有预置的常用模型。有些模组厂商会提供模型库你直接调用就行省很多事。接口丰富度。常见的接口包括MIPI CSI摄像头、I2S音频、UART、I2C、SPI、USB、GPIO。你要根据你的外设需求来选。特别要注意的是有些模组的接口是复用的用了这个就不能用那个选型的时候要看清楚。功耗表现。模组厂商通常会提供典型场景的功耗数据但你要问清楚测试条件。最好能拿到样品自己实测。开发工具链。包括SDK、编译器、调试工具、文档。工具链的成熟度直接影响你的开发效率。我建议在选型阶段就申请一套开发板实际跑一下再决定。供货与价格。问清楚量产价格、最小起订量、供货周期、有没有长期供货承诺。这些商务条款有时候比技术参数还重要。认证情况。如果你的产品要过CE、FCC、SRRC这些认证模组本身有没有过认证会直接影响你的认证周期和成本。4.3 模组集成的实操经验模组集成看起来简单但实际做的时候坑不少。我分享几个经验。电源设计要留余量。模组的峰值功耗可能远高于平均功耗电源设计要按峰值来。我通常会在模组规格书的峰值功耗基础上再留30%的余量。散热设计不能省。模组集成度高热量集中散热做不好会导致降频甚至死机。即使是低功耗模组连续跑推理的时候发热也不小。散热方案可以是散热片、导热垫、或者结构件导热。接口电平要匹配。模组的IO电平可能是1.8V、3.3V或者可配置的你的外设电平要匹配。不匹配的话要么加电平转换芯片要么烧接口。天线设计要重视。如果模组带无线通信天线的位置、净空区、匹配电路都会影响通信质量。这个最好找专业的射频工程师来调。固件升级要留后路。产品出货后难免要升级固件模组方案要确保有可靠的升级通道。OTA升级要考虑失败回滚、断电保护这些情况。提示模组选型的时候建议同时申请两到三家的开发板做对比测试。测试内容至少包括模型部署流程、实际推理性能、功耗表现、工具链易用性。这个前期投入会帮你省掉后面大量的返工时间。5. 边缘计算盒子的场景与实现5.1 边缘计算盒子的定位边缘计算盒子这个词听起来有点泛我给它一个具体的定义部署在靠近数据源的位置、具备一定AI推理能力、通过网络与云端协同的嵌入式计算设备。它和端侧芯片的区别在于它通常是一个完整的设备有外壳、有电源、有接口可以直接部署在现场。它和云端服务器的区别在于它的算力有限但延迟低、数据不出场。边缘计算盒子的典型场景包括工厂产线的视觉质检、商超的客流分析、社区的安防监控、农业的病虫害识别、医院的影像辅助诊断。这些场景的共同特点是数据量大、延迟要求高、隐私要求高、网络条件可能不稳定。5.2 硬件配置的取舍做边缘计算盒子硬件配置的取舍很关键。我按几个核心维度来说。算力配置。边缘盒子的算力从几TOPS到几百TOPS都有。选多大算力取决于你的模型复杂度和并发路数。我的经验是先确定你要跑几个模型、每个模型的计算量是多少、需要多少路并发然后倒推算力需求再留50%的余量。内存配置。内存不够是边缘盒子最常见的瓶颈。模型权重、中间特征图、输入输出数据都要占内存。我通常按模型大小的3到5倍来配内存。比如你的模型是100MB那至少配512MB内存最好1GB。存储配置。存储用来放操作系统、模型文件、日志、临时数据。建议用eMMC或者SSD不要用SD卡SD卡的可靠性和读写速度都不够。接口配置。边缘盒子通常需要网口、USB、HDMI、GPIO、串口。根据你的场景来配。比如做视觉质检至少需要千兆网口和多个USB3.0。散热与防护。边缘盒子可能部署在高温、高湿、多尘的环境里散热和防护等级要匹配。工业场景通常要求IP40以上户外场景要求IP65以上。电源配置。边缘盒子的电源要稳定建议用宽压输入支持9V到36V。还要考虑断电保护避免突然断电导致数据丢失或系统损坏。5.3 软件栈的搭建边缘计算盒子的软件栈通常包括操作系统、推理运行时、模型管理、应用框架、远程管理。操作系统。Linux是主流选择Ubuntu、Debian、Yocto都有用的。Yocto适合定制化程度高的场景Ubuntu适合快速开发。Windows IoT在工业场景也有一定份额。推理运行时。这取决于你用的推理芯片。常见的有TensorRT、OpenVINO、ONNX Runtime、TFLite。选型的时候要考虑运行时的算子支持、性能、易用性。模型管理。边缘盒子通常要支持多模型、多版本、远程更新。我建议用一个模型管理服务来统一管理包括模型的下载、加载、卸载、版本切换。应用框架。如果你的盒子要跑多个应用建议用容器化方案比如Docker。每个应用一个容器互不干扰升级也方便。远程管理。边缘盒子通常部署在无人值守的地方远程管理能力很重要。包括远程监控、远程配置、远程升级、远程重启。我建议至少实现一个心跳机制盒子定期向云端上报状态云端可以下发指令。5.4 部署现场的常见问题边缘计算盒子部署到现场后遇到的问题往往和实验室里完全不一样。我列几个常见的。网络不稳定。现场的网络条件可能很差丢包、延迟、断网都是常态。你的软件要能处理这些情况断网时本地缓存数据、网络恢复后补传、关键操作不依赖网络。供电不稳。现场的供电可能波动很大电压不稳、突然断电、频繁开关机。硬件上要做好电源防护软件上要做好数据持久化和异常恢复。环境恶劣。高温、高湿、多尘、震动都会影响盒子的可靠性。选型的时候要看工作温度范围、防护等级、抗震指标。维护困难。现场可能没有专业运维人员出了问题要远程解决。所以你的系统要有完善的自诊断和远程恢复能力。数据安全。边缘盒子上的数据可能涉及隐私要做好加密存储和传输。设备本身也要有防拆、防篡改机制。注意边缘计算盒子的部署成本不只是硬件成本还包括安装成本、运维成本、网络成本。做方案的时候要把这些隐性成本算进去不然报价的时候会亏。6. 开发工具链的现状与选择6.1 工具链为什么是AI硬件的隐形门槛很多人评估AI硬件方案的时候只看芯片参数忽略了工具链。但实际做项目的时候工具链的好坏直接决定开发效率和最终产品质量。我见过太多案例芯片参数很漂亮但工具链难用到让人想砸键盘最后项目延期好几个月。工具链的核心环节包括模型训练框架对接、模型转换、量化、编译、部署、调试、性能分析。每个环节都有坑工具链好的方案能让你少踩很多坑。6.2 主流工具链的对比我把目前常见的几类工具链做个对比工具链类型代表方案优势劣势适合团队芯片厂商自研各芯片厂商的SDK与芯片深度适配、性能优化好生态封闭、学习成本高深度绑定该芯片的团队通用推理框架ONNX Runtime、TFLite跨平台、生态好、社区活跃性能可能不是最优多平台部署的团队编译器方案TVM、MLIR自动化程度高、支持多后端学习曲线陡、调试困难有编译背景的团队云厂商方案各云厂商的边缘推理服务端云协同好、管理方便绑定云厂商、有持续费用用该云服务的团队选工具链的时候我建议从这几个维度评估模型支持范围、量化能力、性能表现、调试便利性、文档质量、社区活跃度。最好拿你的实际模型走一遍完整流程再决定。6.3 模型部署的实操流程我以一个典型的视觉模型部署为例说一下完整流程。第一步模型训练与导出。在PyTorch或TensorFlow里训练好模型导出为ONNX格式。导出的时候要注意算子兼容性有些自定义算子可能不被支持。第二步模型转换。用芯片厂商的工具把ONNX模型转换为芯片支持的格式。这一步是最容易出问题的常见问题包括算子不支持、维度不匹配、数据类型不兼容。第三步模型量化。把FP32模型量化为INT8减小模型体积、提升推理速度。量化需要校准数据校准数据的分布要尽量接近实际数据。第四步模型编译。把量化后的模型编译为芯片可执行的二进制。编译的时候可以做一些优化比如算子融合、内存复用。第五步部署与调试。把编译好的模型部署到设备上跑实际数据对比精度和性能。如果精度下降太多要回退到量化前的模型检查。第六步性能调优。根据性能分析结果做调优比如调整线程数、优化内存布局、调整批处理大小。6.4 工具链使用的经验技巧技巧一版本管理要严格。工具链的版本更新可能带来不兼容建议锁定版本升级前充分测试。技巧二保留中间产物。模型转换、量化、编译的中间产物都要保留出问题的时候方便排查。技巧三建立回归测试。每次模型更新或工具链更新都要跑一遍回归测试确保精度和性能没有退化。技巧四关注社区。工具链的很多问题社区里已经有人踩过坑了多搜多问能省很多时间。技巧五和厂商FAE保持沟通。芯片厂商的FAE通常有丰富的经验遇到搞不定的问题可以直接找他们。7. 量产落地的关键节点7.1 从Demo到量产的距离很多团队在Demo阶段很顺利一到量产就各种问题。我总结了一下从Demo到量产要跨过几个坎。一致性。Demo可能只做了一台量产要做几千几万台。每台设备的性能、功耗、稳定性都要一致。这要求你的硬件设计有足够的容差、软件有完善的校准机制。可靠性。Demo跑几个小时就行量产设备要跑几个月甚至几年。可靠性测试包括高温老化、低温启动、振动测试、跌落测试、EMC测试。可制造性。Demo可以手工焊接、手工调试量产要上产线。你的设计要适合自动化生产包括PCB布局、元件选型、测试点设计。成本。Demo阶段不太在意成本量产阶段成本直接决定产品能不能卖出去。要在性能、可靠性、成本之间找平衡。认证。不同市场有不同的认证要求CE、FCC、SRRC、RoHS、REACH等等。认证不通过产品就不能卖。7.2 量产测试方案的设计量产测试是保证一致性的关键。我分享一下我的做法。功能测试。测试每个接口、每个功能是否正常。包括摄像头、音频、网络、USB、GPIO。性能测试。测试推理性能是否达标。通常跑一个标准模型测推理时间和精度。功耗测试。测试各场景的功耗是否在规格范围内。老化测试。抽样做长时间老化测试发现早期失效。校准。对传感器、时钟、射频等需要校准的部分做校准。测试方案要平衡覆盖率和测试时间。测试太全了产线节拍跟不上测试太少了漏检率高。我的经验是关键功能100%测试非关键功能抽检。7.3 供应链管理的实操经验AI硬件的供应链比普通硬件复杂因为涉及芯片、模组、传感器等多个环节。我分享几个经验。多源供应。关键物料至少要有两个供应商避免单一供应商出问题导致断供。安全库存。根据供货周期和需求波动设置合理的安全库存。供货周期长的物料要多备。来料检验。每批来料都要做检验包括外观、尺寸、电气性能。AI芯片还要做功能测试。供应商关系。和关键供应商保持良好关系了解他们的产能规划、技术路线、商务政策。风险管理。识别供应链的风险点制定应对预案。比如某芯片停产了怎么办、某供应商涨价了怎么办。提示量产阶段建议做一次完整的DFM分析让有经验的制造工程师评审你的设计。很多量产问题在DFM阶段就能发现和解决比到了产线再改成本低得多。8. 常见问题与排查技巧实录8.1 推理性能不达预期怎么排查这是最常见的问题。我按排查顺序列一下。第一步确认模型是否真的跑在NPU上。有些框架会静默回退到CPU你以为在跑NPU实际在跑CPU。用性能分析工具确认一下。第二步检查量化是否生效。如果模型没有量化或者量化没生效性能会差很多。确认模型的数据类型和量化参数。第三步检查内存带宽。NPU算力再高内存带宽不够也跑不快。用带宽分析工具看看是不是瓶颈。第四步检查算子支持。有些算子NPU不支持会回退到CPU拖慢整体性能。看看有没有算子回退的情况。第五步检查调度。多线程、多核的调度策略会影响性能。试试不同的线程数和核绑定策略。第六步检查散热。温度过高会导致降频性能下降。测一下满载时的温度。8.2 精度下降怎么排查量化后精度下降是常见问题。排查思路如下。确认下降幅度。先量化下降了多少是否在可接受范围内。通常INT8量化下降1%到3%是正常的。检查校准数据。校准数据的分布是否接近实际数据。如果校准数据偏差大量化精度会差。检查敏感层。有些层对量化敏感可以对这些层保持FP16或者FP32。尝试不同的量化策略。per-tensor和per-channel的效果不一样试试哪种更好。检查预处理和后处理。有时候精度下降不是模型的问题而是预处理或后处理的问题。8.3 系统不稳定的排查系统不稳定可能表现为死机、重启、卡顿。排查思路如下。检查电源。电源不稳是最常见的原因。测一下各路电源的纹波和瞬态响应。检查散热。温度过高会导致芯片保护性降频或重启。测一下关键器件的温度。检查内存。内存不足或内存泄漏会导致系统不稳定。监控内存使用情况。检查驱动。驱动版本不匹配或有bug会导致系统不稳定。确认驱动版本和固件版本匹配。检查日志。系统日志里通常有线索。看看有没有内核报错、驱动报错、应用报错。8.4 常见问题速查表问题现象可能原因排查方法解决方案推理速度慢模型跑在CPU上性能分析工具确认检查NPU驱动和模型转换推理速度慢内存带宽瓶颈带宽分析工具优化内存布局、减少数据搬运推理速度慢散热不足降频测温度改善散热精度下降量化校准数据偏差检查校准数据分布用实际数据做校准精度下降敏感层量化逐层分析敏感层保持高精度系统重启电源不稳测电源纹波优化电源设计系统重启温度过高测温度改善散热系统卡顿内存不足监控内存优化内存使用或增加内存模型加载失败模型格式不兼容检查模型格式重新转换模型接口不工作电平不匹配测电平加电平转换或调整配置8.5 几个独家避坑技巧技巧一早期就做端到端测试。不要等硬件全部做完才做软件测试早期就用开发板做端到端验证尽早发现问题。技巧二建立性能基线。在项目初期就建立性能基线后续每次变更都对比基线及时发现性能退化。技巧三保留多个版本的模型。FP32、FP16、INT8的模型都保留出问题的时候可以快速切换对比。技巧四做好温度监控。在关键器件旁边放温度传感器实时监控温度避免过热降频。技巧五电源设计留足余量。峰值功耗可能远高于平均功耗电源设计要按峰值来留30%以上余量。技巧六重视EMC设计。AI硬件通常有高速接口EMC问题很常见。早期就做EMC设计不要等认证不过再改。技巧七和芯片厂商FAE建立联系。遇到搞不定的问题FAE通常能给出关键提示。早期就建立联系不要等出问题才找人。技巧八做好版本管理。硬件版本、软件版本、模型版本、工具链版本都要严格管理避免版本混乱导致的问题。这期周报的内容就是这些。AI硬件这个领域变化很快我尽量挑那些经过验证、有实际参考价值的信息来分享。如果你在做AI硬件相关的项目遇到具体问题欢迎交流。我个人的经验是这个领域没有银弹每个方案都有取舍关键是搞清楚自己的核心需求是什么然后在各个维度上做合理的平衡。
