ASIC芯片凭什么跑AI？从原理到选型实战

什么是ASIC为什么它可以用来跑AI几个月前我接到一个AI推理加速的项目第一个摆在面前的问题就是主控芯片到底选什么当时的候选方案里有GPU、有FPGA、也有一个叫ASIC的方案。团队里有人直接说“ASIC听起来就是专门写死的芯片灵活性太差”有人则坚持“要追求极致性能和成本就得走ASIC”。聊到后面我发现一个问题很多做算法的人对ASIC的理解其实停留在“定制芯片”四个字上至于它为什么和AI这么投缘内部到底怎么把神经网络跑起来或者在什么场景下才值得选它——这一堆问题并不是所有人都能讲清楚。这篇文章我就把这个话题摊开聊。不堆教科书定义主要结合自己实际做项目时对ASIC的认知变化说清楚它是什么、靠什么本事跑AI、以及真让你来选型或者评估一个ASIC方案时应该盯住哪些点。1. ASIC到底是什么从通用芯片到“一颗只干一件事”的芯片1.1 CPU、GPU、FPGA、ASIC的定位差异要理解ASIC最粗暴的办法就是把它跟其他几个常听到的芯片类型放一起对比。CPU是通用计算核心它的设计目标是什么都能干。不管是跑操作系统、处理文字、做科学计算它都能应付因为里面有复杂的控制逻辑、分支预测、乱序执行这一类机制。GPU原本是为图形渲染设计的特点是大量并行的小计算单元后来被拿来做通用并行计算也就是GPGPU这条路。FPGA则是“半定制”的代表它内部有大量可编程的逻辑资源你可以通过硬件描述语言把电路“画”出来而且可以反复擦写重新配置。ASIC就完全不同了。它的全称是Application-Specific Integrated Circuit专用集成电路。顾名思义这颗芯片从设计阶段就只为某一种或某一小类应用服务。比如一颗专门做比特币哈希计算的芯片它设计时就只干SHA-256这件事一颗专门做视频编码的芯片它内部就围绕H.264、H.265的编码流程来搭电路。我把这几种芯片做了一张对比表这样大家一眼就能看出差异芯片类型设计目标灵活性每单位计算的能效开发周期典型场景CPU通用计算极高较低短操作系统、日常软件GPU并行图形/通用计算高中等较短图形渲染、AI训练、科学计算FPGA可重构硬件中中高中等通信基带、原型验证、小批量产品ASIC特定任务几乎为零极高长流片不可逆手机芯片、AI推理卡、专用矿机对比里最扎眼的一项就是灵活性。ASIC在制造完成后内部电路完全固定你想让它干设计之外的事情基本无能为力。但正是这种“死板”给了它极高的效率和极低的功耗。这就好比你请一个只会做宫保鸡丁的厨师他天天做这一道菜火候、配料、流程都被打磨到极致而CPU相当于一个全能厨师让他做什么菜都能做但每道菜的准备时间和冗余动作也多得多。1.2 一个关键理解ASIC不是“软件”而是“电路”很多人刚接触ASIC时往往有一个误区觉得ASIC和CPU一样是在里面“跑程序”的只不过程序写死在芯片里了。这个理解不完全对。CPU的执行方式是取指令、译码、执行它的内部有通用寄存器、ALU、控制单元程序是一段存储在内存里的指令序列动态变化。FPGA则通过配置比特流把查找表和触发器连接起来本质上是把一位硬件工程师设计出来的电路结构临时搭建在可编程逻辑上。ASIC的做法更极端——它直接把算法变成物理电路。比如做卷积操作CPU是循环读取数据、执行乘加指令而ASIC是直接设计一堆乘法器和加法器用硬连线的数据通路把特征图数据流进去经过一层流水线后直接把结果流出来。整个过程没有“取指令”这个动作没有程序计数器也不存在“软件在跑”。数据从一端进来结果从另一端出去中间的数据搬运和计算完全由物理电路完成。这也是为什么ASIC常常被称为“把软件固化成硬件”——你把算法中确定不变的部分直接做成电路换来的是时间上、功耗上数量级的优势。2. 为什么AI负载天然适合ASIC2.1 AI计算的核心大量的乘加运算和固定数据流我经常被问ASIC能跑AI是不是因为AI则“简单”其实不是算法的逻辑简单而是AI的基础计算模式高度集中且有规律。以最常见的卷积神经网络为例一层卷积干的活就是拿一个固定尺寸的卷积核在输入特征图上滑动每个位置做一次“对应元素相乘再累加”的操作。这一连串操作拆到最底层就是乘法指令和加法指令的重复执行。全连接层、Transformer里的矩阵乘法本质也都是在做大规模的乘加。这种负载有两个特点。第一计算模式极其规整不需要复杂的分支判断不需要动态的逻辑控制几乎可以百分百转成硬件数据通路。第二数据量极大但同时具有很高的并行度。比如一个batch里有256张图每张图有64个通道每个通道的卷积都可以独立计算这就给硬件设计提供了天然的并行空间。所以ASIC做AI的时候设计者可以把大量乘加单元叠在一起设计成脉动阵列或者SIMD阵列。某颗专为矩阵乘设计的加速芯片在一个周期内可以完成数千次乘加操作而同样功耗约束下的CPU每个周期只能完成几次到几十次乘加。这就是数量级的差距。我在实际中接触过一个已量产的AI推理芯片内部就是256个乘加单元组成一个计算阵列。跑一个简单的分类模型时它的主频只有1GHz左右功耗还不到5瓦但吞吐量却是同级别GPU的几倍。反观CPU跑同样模型风扇狂转、功耗飙到几十瓦性能还只有它的十分之一不到。差别就来自“针对性”。2.2 从“通用指令”到“专用电路”的性能三连跳理解ASIC跑AI的优势可以把它拆成三个维度来看算力密度、功耗效率、确定性。第一是算力密度。CPU和GPU需要大量面积去做控制逻辑、缓存、访存调度真正用来做乘加的ALU面积占比并不高。而ASIC可以把80%以上的晶体管面积都用在计算阵列和紧邻的片上存储上。单位面积下的有效算力自然就高。业内常说的TOPS/W每瓦特多少万亿次操作这个指标ASIC通常能做到几十甚至上百而普通GPU往往是个位数到十几。第二是功耗效率。功耗的核心来源是开关活动和数据搬运。CPU每执行一条指令要经历取指、译码、访问寄存器、执行、写回多个环节每一步都产生动态功耗。ASIC把中间环节全部砍掉数据直接流入计算单元配合深度流水和片上数据复用功耗可以压得非常低。这对端侧设备来说是致命的优势。我做过一个端侧人脸检测的项目用某ASIC方案的功耗只有1.2瓦左右如果换成低功耗GPU光是核心供电就要奔着5瓦去了。第三是确定性。通用处理器因为有很多调度、缓存命中、并发竞争的问题同一段代码在GPU上跑几次耗时可能都有抖动。但ASIC没有操作系统、没有缓存一致性问题每层网络的延迟几乎是固定的。这在一些对时间敏感的场景比如自动驾驶的前融合感知、工业视觉的节拍控制非常值钱。2.3 从神经网络模型到硬件电路编译与映射ASIC不是把PyTorch模型直接塞进芯片里。真实流程是模型先通过编译器完成解析和优化再把算子映射到芯片内部的硬件资源上。目前主流的AI编译器比如TVM、MLIR这类工具链做的事情本质上就是把计算图翻译成ASIC可以执行的“调度序列”。但这里有个需要区分的地方ASIC本身没有通用指令集它的“程序”更像是一系列配置——告诉片上控制器按照什么顺序启动计算阵列、从哪里加载权重、往哪里写结果。某公司的AI加速卡配套的编译器会把一个训练好的卷积网络翻译成一串控制寄存器的配置值再加上权重数据最后一起加载进芯片。运行的时候芯片按照这段配置完成推理过程里没有取指令、译码的环节。这也解释了一个现象为什么ASIC对算子类型非常挑剔。如果模型里出现编译器不支持的算子就得人工改写网络结构、拆算子或者干脆放弃这颗芯片。比如有些ASIC对普通Conv3x3支持极好但对Dilated Conv、动态卷积支持很差我在项目里就遇到过因为网络里有一个自定义算子导致整颗芯片方案不可用的情况。后面在常见问题里我会详细说这个坑。3. 场景观察ASIC在AI世界里到底承担了什么角色3.1 云端推理大尺度、大批量、极致成本AI推理是目前ASIC落地最密集的场景之一。推理和训练有个很不一样的地方训练要不断调整权重需要灵活的框架支持GPU目前仍然占主导推理则模型结构固定、数值范围可以压缩非常适合专用化。在公有云的推理服务里典型情况是大规模的图片分类、目标检测、语音识别请求。这类请求特点是海量、重复、单一。把这类负载放在通用GPU上逻辑上能跑但成本和功耗极其浪费。很多云厂商做推理服务时后台已经悄悄铺了大量自研或定制的ASIC芯片靠的就是每瓦性能和单位成本。我曾经有一个做内容审核系统的朋友他们之前用几块GPU做图像分类推理后来换成了某家公司的ASIC推理卡。同等吞吐下整机功耗从两千多瓦直接掉到六七百瓦机柜数量和服务器采购成本都下来了。这是ASIC在云端最成熟的打法不求通用只在某个细分模型家族内做到极致能效。3.2 端侧智能NPU就是最典型的ASIC其实很多人手里就握着ASIC——手机里的NPU就是典型例子。手机SoC中的NPU是专门为AI算子设计的硬件单元它就是一颗嵌入式的ASIC。平时我们用的相机场景识别、语音助手、实时字幕都跑在NPU上。端侧ASIC和云端ASIC还有一点不一样它更在意面积和功耗也更多和CPU、GPU、ISP集成在同一颗SoC上。它能承接模型但模型往往得经过量化、剪枝才能装进去。我做过一个在手机端跑姿态估计的Demo原始FP32模型大约30MB用NPU工具链量化为INT8后直接缩到8MB左右速度从CPU上的200多毫秒降到50毫秒以内效果还基本不受影响。这种端侧NPU本质上就是一颗为AI而生的ASIC只是藏得更深。3.3 “专用与通用的边界”ASIC不是万能药ASIC也不是所有AI场景都香。最典型的就是大模型训练和需要频繁迭代算法的场景。训练的要求是“灵活、可编程、支持各种奇怪算子和动态Shape”这正是ASIC最不擅长的地方。一旦网络结构频繁变化一颗新流片的ASIC可能三个月就落后了。FPGA和GPU因为可编程反而能在这种阶段保持优势。我之前在模拟项目X里试过用ASIC跑一个小规模的Transformer推理静态Shape下效果很理想但一旦要支持变长输入、动态beam search工具链就开始吃力了最后还是要靠CPU兜底。做选型时一定搞清楚自己模型的稳定期有多长——如果算法还在剧烈变化期先别急着上ASIC。4. 实操心得从选型到部署ASIC方案怎么落地4.1 评估一颗AI ASIC不能只看算力很多人在选ASIC时第一句话问“多少TOPS”。我可以直接说这个数字在真实部署里参考价值有限。因为标称算力往往是峰值算力是在最理想的数据流、最大的利用率下才可能达到的。真实跑一个ResNet或Transformer算子混合在一起数据搬运、内存带宽、中间结果重新加载都会把实际吞吐拉低一大截。我更推荐先看三样东西片上存储容量、内存带宽、以及工具链成熟度。片上存储决定了权重能不能全放进去内存带宽决定了数据搬运的天花板工具链则决定你从PyTorch模型到能跑的推理程序要花多少时间。任何一个短板都可能让标称算力成为纸上数字。另外一个评估维度是支持的量化格式。现在主流推理ASIC都支持INT8很多还支持INT4。但需要注意不同芯片对量化粒度的处理不一样。有些芯片per-tensor量化精度掉得厉害有些支持per-channel效果就好很多。我做过一个目标检测模型在一颗只支持per-tensor量化的芯片上mAP从0.72掉到0.61完全不可接受后来换了一颗支持per-channel的芯片mAP掉了0.02左右基本无损。4.2 模型适配与算子映射的实用技巧拿到一块新的AI ASIC整个流程通常是这样的先把训练好的模型导出成通用格式比如ONNX然后用厂商提供的编译器跑一遍“模型转换”看看哪些算子能被硬件直接执行哪些算子需要“软核”模拟哪些完全不支持。操作上我有个习惯先跑一个基准模型比如ResNet50或者MobileNet目的不是看性能而是验证整条工具链能跑通。然后把自己业务模型中的每一个算子在编译日志里单独过一遍做一个算子支持清单。如果发现某几个算子不支持通常有几个绕法改写模型结构把算子替换为支持算子的组合调整模型训练方式让网络刻意避开很罕见的算子实在不行就在端侧用CPU算子兜底。但我要补一句CPU兜底是个双刃剑一旦数据在ASIC和CPU之间来回拷贝性能会被拖垮。所以尽量在模型设计阶段就把目标芯片的算子支持列表发给算法团队一起对齐。4.3 实测过程用ASIC跑一个分类模型要经历什么我拿一次实际部署过程来演示。硬件是一块PCIE接口的AI推理加速卡内部主芯片是一颗ASIC工具链基于MLIR改造支持ONNX模型导入。软件环境是Ubuntu系统安装了厂商SDK和Python接口。第一步把PyTorch训练好的ResNet18导出为ONNXpython export_onnx.py --weights resnet18.pth --output resnet18.onnx第二步用厂商的转换工具把ONNX编译为目标平台的二进制accel-compile --input resnet18.onnx --output resnet18.accel --precision int8 --batch-size 4第三步加载模型到加速卡上跑一次推理python run_inference.py --model resnet18.accel --images val_imgs/ --repeat 1000整个过程中最费时间的不是推理本身而是“模型转换精度验证”。我第一版转出来之后发现精度掉了不少排查下来问题出在BN层折叠时的一个参数处理不对。这说明工具链虽然号称“一键转换”但实际跑起来仍需要算法工程师参与核对关键层精度。整个过程走完最终性能数据很亮眼单卡跑ResNet18 INT8batch4实测约5000帧每秒单帧功耗只有0.8毫焦。对比原来用某款CPU跑吞吐提升了45倍能效提升了接近80倍。这个例子很能说明ASIC的威力也说明了“怎么跑AI”这个问题的答案不是唯一的。4.4 常见的几类问题与排查速查表最常见的四类问题我做成一个速查表给大家备用现象可能原因处理方案编译时报算子不支持模型里有目标芯片未实现的算子改写模型结构或调整算子组合转换后精度大幅下降量化粒度不合理或敏感层量化损坏改为per-channel量化或对敏感层保留FP16实测吞吐远低于标称TOPS内存带宽受限或小算子过多加大batch融合小算子优化数据布局推理结果偶发错误板卡驱动或PCIe链路问题检查固件版本、压力测试内存稳定性这里有一条经验很重要拿到新板卡先做“稳定性压测”别一上来就上业务模型。比如用厂商自带的测试程序连续跑一晚观察第二天有没有出错溢出。我在某公司提供的ASIC板卡上遇到过跑半小时后偶发一个错误输出查了很久最后发现是PCIe链路在特定负载下出现信号质量问题。这种问题如果不是提前压测到了上线阶段才暴露会非常痛苦。5. 关于AI ASIC的一些技术延展5.1 大模型时代ASIC还能继续“打”吗随着大语言模型爆发很多人质疑ASIC会不会退场。我的观点是不但不退ASIC反而在大模型推理里找到了新战场。大模型推理有非常明显的结构性特征Prefill阶段计算密集Decode阶段访存密集。针对Decode阶段batch小、访存高的特点很多新款ASIC开始加大片上SRAM容量同时优化权重加载调度让每次生成的Token尽量复用缓存的权重。这类改动在GPU上因为架构太通用很难做到极致在ASIC上则可以针对Transformer结构做专门的数据流设计。我做过的模拟项目X中尝试用ASIC跑一个7B参数的量化模型虽然还不能完全替代GPU但在批处理大小为1的在线流式场景下每Token的延迟已经能压到几十毫秒级别功耗只有GPU方案的十分之一。这说明ASIC并不排斥大模型只是对设计者的技术判断和创新要求更高了。5.2 从“专用AI芯片”到“可定制AI芯片”AXIC的“专用性”虽然强但目前不少公司在走一条中间路线在核心计算阵列保持专用但外层加上一定程度的重配置能力。也就是说针对不同算子家族保留可切换的数据通路配合高级编译器动态映射。这本质上是把ASIC和FPGA的思想做了折中——计算单元硬化为高效电路而数据调度和控制部分保留少量可编程能力。我在实际用过的某款加速卡上就见到类似设计卷积和矩阵乘共享一部分硬件资源通过配置寄存器切换工作模式。这让同一颗芯片既能跑CNN也能跑Transformer的部分算子某种程度上缓解了“流片后就不能改”的焦虑。5.3 选择ASIC之前我建议你想清楚的事最后给正准备做AI芯片选型的朋友几个建议。先评估你的模型变化频率。如果三个月换一个新结构ASIC可能会成为桎梏如果模型结构稳定、量又非常大ASIC是越用越划算。再评估你的部署规模。做几十台服务器原型FPGA或者高端GPU可能开发效率更高做到几千台甚至几万台ASIC省下的功耗和单颗成本才真正有意义。然后算清工程投入。ASIC方案的工具链、驱动、交叉编译、调试环境都需要大量人力。最后别忽略生态。没有成熟工具链和活跃开发者社区的ASIC哪怕参数再漂亮落地也是噩梦。我在项目里遇到过标称性能极强但文档贫乏的方案最后开发周期比预期多了一倍。从我自己的实操体会来说ASIC从来不是“银弹”它是“工程权衡到极致之后的答案”。如果你的场景和它匹配能拿到的收益是惊人的如果不匹配硬上也只会给自己挖坑。动手之前先想清楚自己的负载特征和工程预算比纠结单颗芯片的TOPS数值重要得多。