最近在啃一篇国外的AI芯片架构综述文章原文干货密度很高但篇幅实在太长很多地方还默认读者已经有了芯片设计基础我一边翻译一边补了不少背景资料和生产环境里踩过的坑。今天干脆把这篇“译解”整理成一份更完整的实战笔记从计算核心、存储层级、片上互联、指令集到具体芯片的架构解读一次讲透希望帮有同样困惑的人省点时间。这篇内容适合三类人正在做模型部署和推理优化的工程师看到算力参数却不知道怎么评估芯片真实水平的技术选型者以及刚进入半导体芯片行业的初级从业者。即使你暂时用不到底层细节了解AI芯片的设计思路对理解算力成本和模型性能上限也有直接帮助。1. 拆解AI芯片架构的核心思路1.1 算力瓶颈的本质数据传输比计算更贵原文最开篇的部分没有直接讲芯片结构而是抛出了一个灵魂拷问为什么AI计算这么吃硬件很多从业者第一反应是“因为模型参数多、计算量大”但真正决定芯片设计方向的是数据搬运的开销远大于计算本身。我做了个很简单的类比把芯片想象成一个中央厨房计算单元是大厨数据是食材。问题从来不是大厨切菜不够快而是食材从仓库搬到案板上的时间太长大厨大部分时间在等配菜。芯片内部的存储层级就是仓库和案板之间的关系寄存器是随手能拿的调料缓存是台面上的备菜区显存是冷藏库而内存则是远处的批发市场。每一级之间的搬运速度完全不在一个量级功耗和延迟也完全不同。这就是为什么现代AI芯片架构设计的第一原则不是堆更多计算核心而是想方设法让数据离计算单元更近让计算单元始终处于饱和状态。原文把这个逻辑称为“以数据为中心的架构设计”我的理解就是一个MAC阵列如果有一半时间在等数据那它标称的TOPS就要打五折实际能效远低于理论值。1.2 我重排后的主线算力、数据、控制三位一体整篇文章内容非常庞杂翻译初稿超过一万字。为了阅读和落地我把它重新组织成了三条主线这个结构也推荐你带着去读任何芯片架构文档。第一条主线是算力从哪里来对应计算单元设计包括SIMD、SIMT、张量核心、脉动阵列这些不同流派各自用什么方式提高计算吞吐。第二条主线是数据怎么喂对应存储层级和片上互联核心关注带宽、延迟、缓存策略和NoC拓扑。第三条主线是指令如何下达对应指令集架构和配套的软件栈回答的是编译器如何把PyTorch算子一步步变成芯片认识的指令。这三条线缺一不可。只看算力会掉进参数陷阱只看存储会忽略计算特性只看指令集又很难评估生态好坏。原文其实也隐含了这条逻辑只是主线被大量的细节淹没重新梳理后更容易建立整体框架。2. 核心细节解析AI芯片架构的四大基石2.1 计算单元流派通用、并行、专用三条路线计算单元是芯片最核心的区域也是不同芯片架构分道扬镳的地方。原文梳理下来大致有三条技术路线这里用一张表格做对比流派代表产品设计哲学优势劣势通用标量/向量核心CPU低延迟、强控制流灵活通用适合复杂逻辑并行度有限算力密度低大规模并行核心GPU/NPU高吞吐、宽SIMT并行计算能力极强控制流弱延迟较高专用矩阵计算单元TPU/张量核心硬件直连矩阵运算能效比极高面积利用率高灵活性差依赖编译器配合先看CPU路线这个大家最熟悉。CPU的设计目标是把单条指令跑得尽量快所以核心面积大量用于分支预测、乱序执行、缓存一致性这些控制逻辑真正做计算的ALU占比其实不高。这适合跑操作系统和复杂业务逻辑但用来做矩阵乘法功耗和效率都很吃亏。GPU路线走的是另一个方向用大量简单核心堆出超高并行度。英伟达的SMStreaming Multiprocessor里面包含几十个CUDA核心每个核心其实挺简单但整个芯片可以同时跑几千上万个线程。张量核心则是更进一步的专用化它直接针对4x4或8x8的小矩阵乘法做了硬件优化一条指令就能完成一次小矩阵乘累加操作比用通用CUDA核心硬算快得多。脉动阵列是TPU走的路由Google在2017年公开设计思路是把一组ALU排成阵列数据像在流水线上一样逐拍在阵列中流动每个计算单元只和相邻单元通信。好处是数据复用率极高读一次数据可以参与多次计算大幅降低了对带宽的要求。缺点也很明显阵列一旦固定下来对新算子形状的支持就全靠编译器调度碰到非典型算子效率会急剧下降。2.2 存储层级与带宽墙算力再高也怕数据断供原文用了大量篇幅讨论存储系统这也是我觉得翻译过程中收获最大的部分。芯片内部的数据搬运遵循一个铁律越靠近计算单元越快、越贵、容量越小。现代AI芯片基本都有完整的存储层级寄存器文件、片上SRAM、L2缓存、片外HBM或DDR最后才是系统主存。这里有一个关键概念叫算术密度即每次主存访问对应的浮点运算次数。如果算法算力密度太低也就是单位数据量的计算量太少那么芯片的算力再高也无法发挥整体性能会被访存延迟和带宽卡死。业内用Roofline模型来评估这一点横轴是算术密度纵轴是可达性能两者交汇处就是性能天花板。举个例子ResNet这类CNN的卷积层算术密度相对较高数据复用比较充分而某些大模型的Embedding查表和Gather操作几乎是无计算纯访存的这类层就注定性能上不去。理解了Roofline模型你在评估AI芯片时就会多一个心眼不再只看TOPS数字而是会结合自己模型的实际算力密度来判断这颗芯片到底合不合适。片内SRAM的容量和带宽往往是被低估的指标。以英伟达A100为例片上共有40MB的L2缓存和约108MB的SRAM包含寄存器文件和共享内存等但片内带宽可以达到每秒十几TB级别反观片外HBM的带宽只有2TB/s左右差了一个数量级。这意味着如果算子能完全在片内完成数据复用性能至少能翻好几倍。编译器优化的本质很多时候就是尽量把数据留在片内。2.3 片上互联与多Die趋势芯片之间的交通网计算单元和存储搞定了还要解决怎么把一个计算核心的数据高效送到另一个核心的问题这就是片上互联的工作。早年的SoC用简单的总线所有设备挂在一条共享总线上简单但带宽有限一旦多个核心同时访问存储就会严重拥堵。现代高性能AI芯片普遍转向了NoC架构即片上网络。NoC的拓扑多种多样常见的有环形、网格、交叉开关等。原文重点提到了环形总线英伟达在Volta到Ampere时代的GPU内部有多个环形网络专门负责不同数据类型的传输比如L2缓存访问走一条环计算单元间通信走另一条环。环的好处是布线简单、可扩展性好但延迟会随着节点数量增加而升高。到了Hopper架构英伟达开始引入更多片内交叉开关和直连路径来缓解延迟问题。更值得关注的是多Die和Chiplet趋势。随着制程逼近物理极限单颗大芯片的良率和成本越来越难看业界开始把一颗大芯片拆成多个小芯片再用先进封装和片间互联把它们粘在一起。AMD的MI300系列有多个计算Die英伟达的H100也包含了多个计算Die通过NVLink封装互联。片间互联的带宽和一致性协议已经成为新一代AI芯片架构的核心竞争点。翻译到这里时我最大的感受是芯片架构越来越像城市交通规划既要保证主干道高带宽总线的吞吐又要解决断头路和红绿灯同步和一致性问题带来的延迟。所谓“分布式架构”的理念早已从软件领域渗透到了芯片内部设计。2.4 指令集架构AI芯片的“语言”很多做算法的人只把芯片当“硬件”其实芯片能够认什么指令直接决定了软件栈长什么样。指令集架构是硬件和软件之间的契约不同AI芯片的指令集差异非常大这也是为什么同一个模型换一颗芯片就要重新做适配的根本原因。原文把指令集分为几种风格。CPU用的是复杂但灵活的指令集x86指令的长度都不固定一条指令能做很复杂的事CPU内部会有解码器把它拆成微操作ARM和RISC-V则走精简路线指令定长、规整适合低功耗设备。GPU的指令集则是为大规模并行优化的英伟达有PTX这种虚拟指令集作为中间层再编译到硬件相关的SASS指令这样既能兼容不同代际硬件又能让厂商做深度优化。NPU的情况更特殊。以Google TPU为例它的指令集非常简单核心就是读取数据到片上缓存、执行矩阵运算、把结果写回存储几乎没有分支跳转因为跑神经网络很少需要复杂控制流。这种极简化指令集的好处是可以把芯片面积几乎全留给计算单元坏处是灵活性很差不是所有算子都能高效映射到硬件上。用户提到的RK3588这类SoC也很有意思它内部有独立的NPU模块指令集是厂商私有的配套的RKNN工具链会把PyTorch模型转换优化成NPU可执行的指令序列。这个转换过程能否成功、效率如何完全取决于指令集的表达能力。所以看一颗AI芯片好不好用不能只看硬件参数还要看它的编译器到底能把你的模型编译得多高效。3. 实操视角怎么看懂一块AI芯片的架构规格3.1 从规格书抓关键参数别只盯着TOPS拿到一份芯片规格书外行人很容易被大数字吸引比如XX TOPS、XX TFLOPs但真正有经验的工程师看芯片至少会同时注意几个层面的信息。算力参数要分清精度。同为20 TOPSINT8精度和FP16精度的实际计算量差别巨大而稀疏计算下的TOPS又和稠密计算完全不同很多芯片厂商喜欢标榜稀疏算力来拉高数字实际模型根本达不到那么高的稀疏率。带宽参数更要仔细看内存带宽的数值通常远低于算力需求的匹配值这正好可以套用前面提到的Roofline模型来验证芯片设计是否均衡。还要看存储容量和层级例如片上SRAM有多大L2缓存多少支持多大容量的DDR或LPDDR。对边缘设备来说这些指标决定了你到底能不能跑大模型很多时候不是算力不够而是放不下参数和中间激活值。另一个容易被忽略的指标是互连接口带宽比如PCIe版本和通道数、片间高速链接口数量这直接决定了多卡集群扩展的天花板。说到底评估一颗AI芯片就像判断一辆车的性能马力是算力油箱和油耗是存储和功耗变速箱是编译器。单看任何一项都不能下结论必须综合来看。3.2 实战案例用RK3588的NPU做架构拆解用户热搜词里多次出现RK3588这确实是一款很有代表性的国产边缘AI芯片我拿它做个具体案例来演示怎么解读架构。RK3588是一颗8核CPU4个A76加4个A55加Mali GPU加NPU的SoCNPU部分号称6 TOPS算力INT8在很多边缘设备上都有应用。看规格书发现这颗NPU其实是3个核心组成的NPU集群每个核心是一个独立的MAC阵列支持INT4/INT8/INT16/FP16多种精度。关键的地方在于它的激活函数ReLU、Sigmoid等和池化操作有对应的硬件加速单元这意味着模型中的一部分算子可以直接硬件完成不需要全部跑到CPU上模拟。实际用RKNN工具链转换模型时会发现工具链会把模型中的算子做融合处理例如把卷积和后续的激活函数融合成一个算子这样就能减少对外部带宽的访问。这个融合策略正是NPU架构设计目标的直接体现把数据尽量留在片内把算力尽量用满。同时也注意到一个架构限制NPU的片上缓冲有限如果模型的特征图层数特别大可能放不下工具链会自动做一些切分而切分会导致性能损失。理解这个你在设计模型时就会主动避开过大的中间特征图。所以如果你拿到一款带NPU的SoC建议第一步先跑一遍它的官方工具链样例观察编译日志里模型被拆分成了几个子图有哪些算子被回退到CPU。这些信息比任何规格书都能更快让你摸清AI芯片的真实架构水平。3.3 对比看大厂英伟达、Google、AMD的设计思想看完RK3588这种中端SoC再回头看大厂产品的架构思路你会更有感觉。英伟达的核心思想是通用加专用结合。GPU里的CUDA核心负责通用并行计算Tensor Core负责矩阵运算最近几年又加入了Transformer引擎这样的专用模块。这种“组合拳”让GPU能应对各种模型结构又不至于在矩阵计算上太吃亏。Hopper架构的SM还引入了分布式共享内存允许一个SM内部的不同子核心共享数据进一步减少数据搬移。Google TPU的思路更加极端就是围绕矩阵乘法做极致优化。最新几代TPU的架构规格没有完全公开但从已公开的信息看它的核心仍是脉动阵列并针对Transformer做了大量优化。Google的整套软件栈XLA、TensorFlow、JAX也都是为了最大化利用TPU而精心设计的。所以TPU的性能神话离不开软件栈的高度定制它本质上是一个软硬协同设计的产物不能脱离软件空谈架构。AMD的CDNA系列架构其实也在学英伟达的路数用Infinity Fabric做片内片间互联在MI300上做了大面积的Chiplet集成。微软、Meta这些都大量采购了AMD的卡做推理性价比是它最核心的卖点但软件生态的成熟度一直是被诟病的地方。一个芯片架构再好编译器不争气落地效果就得打折这句话在AMD身上表现得尤其明显。3.4 拿到新芯片后我会做的第一件事经常有人问我拿到一款新AI芯片该怎么快速评估我的实践顺序基本固定。首先翻内存带宽和片上缓存规格心里先算一笔账用Roofline模型估算这颗芯片对算术密度的最低要求马上就能判断适合跑哪些模型。接着跑几个标准的基准模型比如ResNet50、MobileNet、ViT-B/16记录端到端延迟和吞吐重点对比文档宣称算力和实际推算出来的有效算力之间的差距。第三步直接上Profiler工具看算子的时间分布找出哪个算子在拖后腿。如果发现大量时间花在数据搬运而非计算上那说明模型的访存模式可能和芯片架构不匹配需要调整算子融合策略或改变内存布局。最后我用一个自己业务中的真实模型做端到端压测测试多batch并发时的吞吐曲线看它是不是线性扩展这里能看出芯片在多任务并发场景下的真实能力。这套流程走下来一颗芯片的架构底细基本就摸清了。如果你只做了一轮基准测试就开始评估很容易被亮眼的峰值指标误导。4. 常见问题与避坑实录4.1 TOPS陷阱算力虚标和稀疏性问题几乎每颗AI芯片都标称自己的TOPS有多高但实际能跑出来的性能常常远低于标称值。最常见的原因有三个精度虚标、稀疏虚标、峰值功耗限制。很多芯片标称的TOPS其实是INT4稀疏模式下的理论值如果用户实际跑FP16稠密模型性能可能只有标称值的十分之一还不到。我拿一款标称6 TOPSINT8的NPU做过测试实际跑MobileNet时有效算力大概只有标称值的四到五成这已经算不错的了。算子形状不匹配、数据排布不对、内存访问pattern不好每一层都会损耗一点最后积少成多。看算力参数时一定要确认三个要素什么精度、是否稀疏、持续还是峰值。还有一个容易踩的坑是INT8和FP16的切换问题。有些芯片支持混合精度计算但切换精度时可能需要重新编排数据布局中间会有性能惩罚。模型推理时不是所有层都适合INT8频繁切换反而会拖慢整体速度。所以看到芯片支持很多精度时不要高兴得太早先想清楚你的模型哪些层能用INT8哪些层必须保留FP16比例直接影响最终性能。4.2 内存带宽不够时算力越高越浪费这是一个非常经典的案例。客户买了一块算力很高的AI加速卡跑大型Transformer模型时发现性能比预期低了将近一半怎么调算子都上不去。我用Profiler一看发现大部分SM都在等待数据计算单元利用率不到百分之五十带宽已经完全跑满。这种情况的根源很简单Transformer中大量操作是Memory Bound的比如Embedding、LayerNorm、残差连接和Gather操作。这类操作的计算量很低却要频繁访问显存一旦带宽吃满计算单元再快也只能空等。这也是为什么H100这样的卡要配HBM3高带宽显存而且把L2缓存加大到50MB都是为了喂饱计算单元。如果你也遇到算力高但性能上不去的情况第一反应不应该是调计算图而应该先查内存带宽是不是已经瓶颈了。判断方法很简单算一下实际运行时的有效带宽除以理论带宽如果超过八成那问题基本就锁定在带宽上。此时优化方向应该是减少访存总量比如算子融合、数据复用、更小的激活值精度而不是试图把计算再优化。4.3 软件栈成熟度有时候比硬件本身更关键芯片是硬件但对业务开发来说真正接触最多的是芯片背后的软件工具链。同样一款芯片如果编译器和算子库做得不好性能可能只有理论值的两三成而且会疯狂报错。我遇到过一个案例某家芯片的硬件规格非常漂亮但跑一个新出的模型结构时工具链里连算子keyword都还没有只能退回到CUDA兼容模式用通用算子跑性能暴跌好几倍。所以评估AI芯片时我强烈建议把软件栈的成熟度权重放在和硬件参数同等的位置。打开官方文档看看支持哪些框架版本用的编译器基于什么技术栈有没有现成的模型库算子覆盖度如何出问题时的报错提示是否友好社区反馈是否活跃。这些看起来“软”的指标往往决定了项目的真实排期。原文里也提到了一个观点我很认同现代AI芯片的竞争早就从单纯的硬件设计竞争变成了“硬件编译器算子库开发工具”的全栈竞争。芯片架构要发挥实力离不开编译器的调度和优化而编译器的基础又决定了它对新模型的支持速度。4.4 功耗与散热小芯片也有大难题最后聊一个容易被忽略的方向功耗和散热。很多人拿到开发板后发现芯片标称算力挺高但跑一段时间后性能明显下降这大概率是碰到了温度墙或功耗墙。芯片有热设计功耗的限制当温度达到阈值频率会主动下降来保护设备也就是业内常说的“降频”。这个现象在边缘设备上尤其明显。比如某款SoC标称算力不错但实际放在密闭的小盒子里没有主动散热跑不到两分钟就开始降频有效算力可能只剩下六成。这也解释了为什么有些开发板宣传算力很高但实际做推理时延时不稳定波动很大。做AI芯片选型时一定要把散热条件纳入考量。同一种芯片在带风扇的座舱设备和不带风扇的手持设备里实际可用算力可能是完全不同的两个数量级。另外还要注意供电设计很多边缘AI芯片全速运行时会有明显的电流尖峰如果供电模块设计不足性能同样会被限制。5. 结合实际场景说一说怎么选型5.1 做一个简单的AI芯片选型打分表综合前面讲的架构知识我做了一张自己的选型评分表每次评估芯片时都会按照维度打分这里分享给读者参考。评估维度权重看什么打分方法算力匹配度25%你的模型能不能吃到算力精度和稀疏要求用Roofline模型验证不只看TOPS带宽匹配度20%HBM/DDR带宽片上SRAM大小对比模型访存需求查带宽利用率软件工具链20%算子覆盖度、编译器优化质量、文档社区跑基准模型和真实业务模型测试功耗与散热15%热设计功耗、降频策略、实际能效比满负荷跑温升测试生态与成本20%开发板/模组价格、供应链、部署经验综合对比方案总成本这张表不是标准答案但它至少能帮团队在选型时把讨论从“谁的TOPS高”引导到“谁的架构真正匹配我们的业务”。我自己实际使用下来一张表做完哪些芯片是纸面数据漂亮、哪些是真能落地基本就一目了然了。5.2 模型类型的匹配度分析不同模型结构对芯片架构的要求差异巨大。我在实际工作中接触到的几类模型匹配逻辑完全不同这里单独拿出来说因为这是最容易被人忽略的选型失误点。CNN类模型以卷积为主体空间特征复用多算术密度较高非常适合有大量MAC阵列的NPU和GPU。像RK3588的NPU、英伟达的Tensor Core跑ResNet这类模型基本能把算力发挥得不错算子融合的空间也大。Transformer类模型对带宽和矩阵计算的综合要求更高。自注意力层中矩阵乘法量大但LayerNorm、Softmax这些归一化操作访存比例高。所以一颗芯片如果只有很强的矩阵计算单元但带宽不足、片上缓存不够大跑Transformer照样会卡在带宽瓶颈上。这也是英伟达在Hopper架构上加大L2缓存和带宽的动因。推荐系统模型则更复杂Embedding查询是典型的Memory Bound操作而MLP部分又是Compute Bound两种算子交替出现对芯片的调度和管理能力要求很高。有些芯片跑CNN很猛跑推荐系统却表现平平根本原因就是架构对不规则数据访问的支撑不够。5.3 云边端场景下架构选择的差异同样是AI芯片云端和边缘端的架构取舍完全不一样。云端的核心诉求是吞吐和能效所以大厂会不惜工本堆HBM带宽、网络互联和专用加速模块。英伟达的数据中心GPU普遍配了NVLink口就是为了把所有卡连接成一个算力池让大规模并行训练成为可能。边缘端则把功耗、成本和面积放到了更优先的位置。RK3588这样的SoC把NPU、GPU、CPU集成在一颗芯片上芯片面积有限不可能放太多的片上缓存架构设计上就更依赖工具链做算子级优化来弥补硬件资源的不足。这类芯片的能效比常常比云端GPU更出色但绝对算力差距巨大。还有一类极端的端侧场景比如智能手表上的语音唤醒和MCU级的AI推理芯片面积和功耗预算都以毫瓦为单位架构上往往会极度“阉割”甚至只保留固定几类操作的原生支持。理解场景差异后选型逻辑就非常清晰了不是选“最强大”的芯片而是选“最匹配场景”的芯片。6. 从架构视角看行业趋势6.1 Chiplet与先进封装一颗芯片的边界在消失原文在最后部分讨论了行业趋势其中最让我印象深刻的趋势是Chiplet模式正在重新定义“芯片”这个概念。早期我们说的芯片架构通常指一块芯片内部的结构现在的大算力AI芯片更像是由多颗小芯片组成的一个异构系统通过先进封装和高速互联紧密地粘在一起。这种变化背后的原因很现实。制程到3nm以下之后单芯片的面积越大良率越低成本指数级上升。与其费力造一颗巨大的单芯不如把芯片拆成计算Die、存储Die、IO Die等不同模块分别采用最适合的制程制造再用2.5D/3D封装把它们集成起来。AMD的MI300X就大量使用了这种结构英伟达的H100内部其实也包含多颗Die。这个趋势对架构设计的直接影响体现在互联协议上。传统的片上总线显然不够用了业界正在推动UCIe这样的开放片间互联标准目标是让不同厂商的小芯片像搭乐高一样组合起来。未来的AI芯片架构可能会从设计一颗芯片逐步演变为设计一个由多个小芯片组成的计算系统。对普通开发者来说理解Chiplet并不需要直接参与设计但要知道使用这些芯片时片内互联和片间互联之间存在性能差异多卡通信的延迟和带宽局限性有时候比计算本身更能左右整体性能。6.2 软硬协同设计成为主旋律另一个明确的趋势是硬件架构已经很难脱离软件单独设计了。TPU是软硬协同的典型谷歌的编译器可以和硬件架构做深度绑定实现极致的算子调度。现在连英伟达也在强调“系统软件”的重要性不断强化其软件栈的深度这是因为芯片的能力上限最终要靠软件来释放。我在翻译原文的过程中一直体会到的观点是AI芯片架构设计的每一个选择背后最终都会落到“软件能否充分利用它”。可编程性、编译友好性、算子适配度这些软件指标和硬件架构是双螺旋式发展的。如果一个架构设计让编译器很难生成高效代码那它在市场上的竞争力就会受到严重制约哪怕硬件规格再好看。这一点在做技术选型时要格外注意。比如某颗芯片的硬件规格很强但编译器还不成熟就需要付出额外的工程成本来适配模型。项目排期紧张时软件栈的成熟度往往比峰值性能更值得优先考虑。6.3 大模型的算力需求倒逼架构演进最后一定要提大模型对AI芯片架构的倒逼效应。Transformer架构及其工作原理现在的模型动辄几百亿、上千亿参数单芯片根本放不下于是模型并行、张量并行、流水线并行成为必选项对芯片之间互联带宽的要求极其苛刻。英伟达的NVLink带宽一代比一代高AMD的Infinity Fabric也在跟进就是为了解决这个分布式训练和推理的通信瓶颈。另一方面推理侧的优化也在反哺架构设计。大模型推理时KV Cache占用的显存巨大内存带宽的需求异常突出所以很多新一代AI芯片都在想办法增加高带宽存储或继续扩大片上缓存。原文提到了一个有趣的方向将部分KV Cache放到更近的存储层级这直接影响芯片内部buffer的设计思路。作为从业者我判断AI芯片架构的演进方向大概率会越来越“专”。针对Transformer的架构优化、针对MoE架构的动态路由调度、针对长上下文的存储优化这些都会成为新一代芯片的卖点。理解架构趋势既有助于选型也能帮助我们预判未来模型部署会面临什么样的硬件环境。翻译完这篇文章我最大的收获不是记住了多少芯片型号和参数而是建立了一套从计算、存储、互联到软件栈的系统分析方法。以后再看到任何一款AI芯片都能迅速判断它适合什么模型、会在哪里遇到瓶颈这种能力比知道一串新名词要值钱得多。希望这篇笔记也能帮你建立起同样的分析框架在 AI 芯片的选型和模型部署路上少踩几个坑。