什么是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负载天然适合ASIC
2.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导出为ONNX：
python 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 INT8，batch=4，实测约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数值重要得多。
