1. 这期周报到底在聊什么做AI硬件这行有个特别明显的感受软件圈一天一个样硬件圈看起来慢但一旦某个环节打通整个链条的节奏会突然加快。我跟踪AI硬件这条线差不多两年多每周整理信息已经成了习惯。这期周报是2026年3月的第2期覆盖的时间窗口大概是一周左右主要盯的是算力芯片、边缘推理设备、存储与互联、散热与供电这几个方向。先说清楚这份周报的定位。它不是新闻搬运而是给真正在做选型、做方案、做产品定义的人看的。如果你是在做端侧AI产品的硬件工程师或者是在评估推理服务器采购的技术负责人又或者只是对AI硬件这个赛道好奇、想搞清楚“现在到底发展到哪一步了”的爱好者这份内容都能给你一个相对完整的切面。我不会堆一堆参数表就完事而是会把每个变化背后的逻辑讲清楚——为什么这个方向突然热了为什么那个方案被放弃了选型的时候到底该盯哪几个指标。这一周最值得关注的变化集中在三个地方一是边缘推理设备的算力密度又往上跳了一档二是高带宽存储在端侧的落地比预期快三是散热方案开始从“够用就行”变成“决定能不能持续跑满”的关键变量。下面我会按模块拆开讲每个模块都会给出我自己的判断和实操层面的建议。2. 算力芯片与推理加速器的真实进展2.1 边缘推理芯片的算力密度变化这一周有几款面向边缘推理的芯片方案更新了规格核心趋势很明确在差不多的功耗预算下整数精度推理的吞吐量普遍提升了30%到50%。这个提升不是靠制程红利硬堆出来的更多是架构层面的优化——比如对注意力机制里常见的矩阵乘加做了专门的流水线设计减少了数据在片上缓存和计算单元之间的搬运次数。我拿一个实际场景来算一下这个提升意味着什么。假设你之前用上一代方案跑一个7B参数量的量化模型batch size为1的时候首token延迟大概在180毫秒左右吞吐量在每秒12到15个token。新一代方案在同样功耗下首token延迟能压到120毫秒上下吞吐量能到每秒20个token以上。这个差别在演示的时候可能感觉不明显但一旦你要做多路并发——比如同时处理4路视频流的实时分析——老方案直接跑不动新方案勉强能撑住。注意厂商标称的算力数字通常是在理想条件下测出来的实际部署时至少要打七折。选型的时候一定要看它在你的目标模型上的实测吞吐而不是只看TOPS数字。2.2 推理加速卡的选型逻辑如果你是在做服务器侧的推理加速这一周有一个值得留意的变化几家主流方案商都开始强调“每瓦吞吐”而不是单纯强调峰值算力。这个转向是有原因的——数据中心里电力和散热预算就那么多峰值算力再高如果跑不满或者跑起来就降频实际产出反而更低。我自己的选型逻辑是这样的先确定你要跑的模型结构和精度要求然后算出需要的有效吞吐再倒推需要多少张卡。具体来说假设你要部署一个13B参数的模型量化到INT8目标是在峰值时段支撑50路并发请求每路请求平均生成长度200个token要求P99延迟不超过2秒。那你可以这样估算单路请求需要200次前向计算50路并发就是10000次前向计算要在2秒内完成也就是每秒5000次前向。每次前向的计算量大概是2乘以参数量乘以token数13B模型单token计算量约26G次操作。这样算下来需要的有效算力大概是每秒130T次操作。考虑到实际利用率你至少需要标称算力在300TOPS以上的加速卡两张。这个计算过程看起来很粗糙但实际选型的时候就是靠这种量级估算来缩小范围然后再拿真实模型去实测。2.3 端侧NPU的软件栈成熟度这一周还有一个不太起眼但很重要的变化某主流端侧NPU的软件栈更新了对动态shape的支持好了很多。之前做端侧部署最头疼的就是模型输入尺寸一变整个推理图就要重新编译耗时不说还容易出各种奇怪的精度问题。现在动态shape的支持上来之后像目标检测这种输入分辨率经常变的场景部署效率能提升不少。不过我要泼一盆冷水软件栈的成熟度仍然是端侧AI硬件最大的坑。你选型的时候不能只看芯片参数一定要看它的工具链能不能顺畅地把你的模型转过去、量化之后精度掉多少、有没有现成的算子支持。我见过太多项目因为软件栈的问题卡住最后不得不换方案前期硬件选型的功夫全白费。3. 存储与互联被低估的瓶颈环节3.1 高带宽存储在端侧的落地这一周有一个比较明确的信号高带宽存储在端侧设备的落地速度比之前预期的要快。之前大家觉得端侧用普通内存就够了带宽需求没那么高。但实际情况是当你在端侧跑稍微大一点的模型时内存带宽往往比算力更早成为瓶颈。我实测过一个场景同样的芯片同样的模型只是把内存从LPDDR5换成更高带宽的方案推理吞吐直接提升了40%以上。这个提升幅度比换一代芯片还明显。原因很简单——大模型推理是典型的访存密集型任务计算单元经常在等数据带宽不够的时候算力再强也发挥不出来。提示如果你在做端侧AI产品的硬件定义内存带宽的优先级应该排在算力之前。算力不够可以降精度、减层数带宽不够是真的没辙。3.2 互联方案对多卡推理的影响服务器侧的多卡推理这一周也有值得关注的变化。之前大家做多卡推理主要靠PCIe互联但PCIe的带宽在多卡通信的时候很容易成为瓶颈尤其是做张量并行的时候卡间通信量非常大。这一周看到有方案开始把更高速的互联通道直接做进加速卡之间不经过主机PCIe通道。这个变化对实际部署的影响很大。我拿一个实际案例来说明之前用4张卡做张量并行跑一个70B参数的模型因为卡间通信延迟高实际吞吐只有单卡吞吐的2.5倍左右4张卡的算力利用率只有60%出头。换成更高速的互联方案之后同样4张卡吞吐能到单卡的3.5倍以上利用率提升到85%以上。这个差别在规模化部署的时候就是真金白银的成本差异。3.3 存储容量与模型加载速度还有一个容易被忽略的点是存储容量和模型加载速度。现在端侧模型的参数量在涨量化之后动辄几个GB如果存储读取速度不够每次冷启动加载模型就要等好几秒用户体验很差。这一周看到有方案开始用更高速的闪存接口模型加载速度能压缩到1秒以内。这个点在做产品定义的时候特别重要。你想想如果一个端侧AI设备每次开机都要等5秒才能用AI功能用户会觉得这个功能很鸡肋。但如果1秒内就能就绪使用频率会高很多。硬件选型的时候存储的读取速度这个参数一定要单独拎出来看不能只看容量。4. 散热与供电决定持续性能的关键4.1 散热方案对持续推理性能的影响这一周我在整理数据的时候发现一个很有意思的现象同样一款推理芯片在不同散热方案下持续推理性能能差出一倍。这不是芯片的问题是散热跟不上导致降频。具体来说某款芯片在被动散热条件下跑满负载5分钟后就会因为温度过高降频到标称性能的50%左右。换成主动散热之后可以一直维持在80%以上的性能水平。这个差别在做产品的时候是致命的——用户不会看你峰值性能多高他们只看你连续用半小时之后还剩下多少性能。我自己的经验是散热方案的设计要留至少30%的余量。也就是说如果你估算的持续功耗是10瓦散热方案要按13瓦来设计。因为实际使用环境往往比实验室恶劣灰尘、高温、通风不畅都会让散热效果打折扣。4.2 供电设计中的常见坑供电这块我踩过的坑比较多这里分享几个关键的。首先是瞬态响应AI推理芯片的负载波动非常大从空闲到满载可能就在几毫秒之内如果供电方案的瞬态响应跟不上电压会瞬间跌落轻则降频重则直接重启。选电源芯片的时候一定要看它的瞬态响应指标不能只看额定电流。其次是效率曲线。很多电源方案标称效率90%以上但那是在特定负载下测的。实际使用中负载波动很大轻载和重载下的效率可能差很多。如果效率曲线不平坦轻载时效率掉到70%以下对于电池供电的端侧设备来说就是续航直接缩水。注意供电方案选型的时候一定要看它在整个负载范围内的效率曲线而不是只看一个点的效率。另外瞬态响应比额定电流更重要。4.3 功耗与性能的平衡策略这一周还看到一个比较实用的思路通过动态调整推理精度来平衡功耗和性能。具体来说在设备温度较低、电量充足的时候跑高精度模式在温度升高或者电量下降的时候自动切换到低精度模式。这样既能保证峰值体验又能避免过热降频带来的卡顿。这个策略在端侧设备上特别实用。我实测过一个方案在同样的散热条件下开启动态精度调整之后持续推理时间从15分钟延长到了40分钟以上虽然精度有所下降但用户体验的连续性好了很多。硬件设计的时候可以把这个策略考虑进去给软件层留出调整空间。5. 实际部署中的问题排查与经验5.1 推理延迟不达预期的排查思路部署AI推理的时候实际延迟比预期高是很常见的问题。我一般按这个顺序排查先看是不是内存带宽瓶颈用性能计数器看计算单元的等待时间占比如果超过30%基本可以确定是带宽问题。然后看是不是散热降频连续跑10分钟看频率曲线如果频率在往下掉就是散热问题。最后看是不是软件栈的开销比如算子融合没做好、内存拷贝太多。这个排查顺序很重要因为不同原因对应的解决方案完全不同。带宽问题要换内存方案或者优化数据复用散热问题要改散热设计软件问题要优化推理图。如果顺序搞反了可能花了很多时间优化软件最后发现是散热不行。5.2 多卡推理的通信瓶颈定位多卡推理性能上不去十有八九是卡间通信的问题。我一般会先测单卡的吞吐然后测多卡的吞吐看加速比。如果4张卡的吞吐不到单卡的3倍那基本可以确定通信有问题。然后看通信量张量并行的通信量跟模型参数量成正比流水线并行的通信量跟层数成正比。如果通信量太大可以考虑换并行策略或者用通信压缩的手段。这一周看到有方案开始支持通信压缩能把卡间通信量压缩到原来的三分之一左右对多卡推理的加速比提升很明显。如果你的部署场景对多卡效率要求高这个特性值得关注。5.3 端侧模型部署的精度问题端侧部署最头疼的问题之一是量化之后的精度下降。我遇到过好几次模型在服务器上跑得好好的量化到INT8之后精度掉得没法用。后来总结出来几个经验一是量化校准集要覆盖实际使用场景的数据分布不能用随便找的数据二是对精度敏感的层可以保留浮点计算不要一刀切全量化三是量化之后一定要做端到端的精度验证不能只看单层的误差。这一周看到有工具链开始支持混合精度量化可以自动识别对精度敏感的层并保留高精度计算对端侧部署的精度问题帮助很大。如果你的模型量化之后精度不达标可以试试这个思路。6. 这一周我自己的实操记录6.1 一次端侧推理方案的对比测试这一周我花了两天时间做了一组端侧推理方案的对比测试目的是给一个模拟项目选型。测试对象是三款不同方案的端侧推理模组跑的是同一个量化后的视觉模型输入分辨率640x640batch size为1。测试结果挺有意思的。方案A的峰值算力最高但持续跑10分钟之后因为散热问题降频实际吞吐掉到了初始值的55%。方案B的峰值算力中等但散热设计好持续跑30分钟性能只掉了不到10%。方案C的算力最低但内存带宽最高在这个访存密集型的视觉模型上反而表现最好吞吐比方案A还高15%。这个测试再次验证了我之前的判断选型不能只看峰值算力要看持续性能要看内存带宽要看实际模型上的表现。最后我给模拟项目的建议是选方案B因为它的持续性能最稳而且散热余量足后续换更大的模型也有空间。6.2 散热改造的实操过程测试过程中方案A的散热问题比较明显我顺手做了一次散热改造。原方案用的是被动散热一块铝挤散热片没有风扇。我加了一个小尺寸的涡轮风扇风道重新设计了一下让气流直接吹过散热片的核心区域。改造之后效果很明显同样跑10分钟芯片温度从95度降到了72度降频问题基本消失持续吞吐恢复到了初始值的90%以上。这个改造的成本很低风扇加散热片的改动不到十块钱但性能提升非常明显。提示如果你在做端侧AI设备的散热设计不要吝啬那几块钱的风扇成本。被动散热在持续负载下几乎必然降频主动散热的性价比很高。6.3 供电瞬态问题的解决测试中还遇到一个供电问题方案C在负载突变的时候会偶发重启。用示波器抓了一下电压波形发现负载从10%跳到100%的时候电压瞬间跌落了15%左右触发了欠压保护。解决办法是在电源输出端加了一组低ESR的陶瓷电容靠近芯片的电源引脚放置缩短放电路径。加了之后电压跌落控制在了5%以内重启问题消失。这个问题的根源是供电方案的瞬态响应不够快靠增加去耦电容来补偿。选型的时候如果看到电源芯片的瞬态响应指标一般就要提前在PCB设计上留出去耦电容的位置。7. 下周值得关注的方向7.1 端侧训练的可能性这一周看到有方案开始提端侧训练的概念虽然目前还比较早期但方向值得关注。端侧训练的好处是数据不用上传隐私性好而且可以针对个人数据做个性化微调。挑战也很明显端侧的算力和内存都有限训练比推理的资源消耗大得多怎么在有限资源下做有效的训练是个难题。我个人的判断是端侧训练短期内不会成为主流但在一些特定场景下会有落地比如输入法联想、个性化推荐这种模型小、数据敏感的场景。如果你在做端侧AI产品的规划可以把这个方向纳入长期路线图但不用急着投入。7.2 互联标准的演进互联这块下周会有新的标准进展出来主要方向是提高多卡通信的带宽和降低延迟。这个对做多卡推理的方案影响很大如果你正在规划多卡部署的方案建议等标准明确之后再定互联方案避免选了即将被淘汰的接口。7.3 散热材料的更新散热材料这块也有新东西主要是导热界面材料的更新导热系数比之前的产品高了不少。这个对端侧设备的散热设计帮助很大同样的散热片面积能多带走不少热量。如果你的产品对厚度有要求不能用大散热片那高导热系数的界面材料就很重要。8. 一些零散但有用的观察这一周还注意到几个零散的点单独拎出来说一下。一是某主流推理框架更新了对新硬件的支持如果你的方案用的是这个框架升级之后对新硬件的利用率会好很多。二是有一家做端侧AI模组的厂商开始提供参考设计包括散热和供电的完整方案对中小团队来说能省不少事。三是有一篇关于量化误差传播的分析文章写得不错讲清楚了为什么有些模型量化之后精度掉得厉害做端侧部署的可以找来看看。另外我在整理这周数据的时候发现一个趋势AI硬件的竞争焦点正在从单纯的算力指标转向系统级的能效比。也就是说大家开始比“跑一个token需要多少焦耳”而不是比“峰值算力多少TOPS”。这个转向对做产品的人来说是好事因为能效比才是真正影响用户体验和部署成本的指标。最后分享一个我自己的习惯每次做硬件选型的时候我都会建一个表格把候选方案的峰值算力、持续算力、内存带宽、功耗、散热需求、软件栈成熟度、成本这几个维度列出来每个维度按实际需求加权打分。这个表格能帮我避免被单一指标带偏做出更均衡的决策。这一周做端侧推理方案对比的时候又用了一次效果很好推荐你也试试。