一家做对话大模型的头部实验室自研的第一颗AI芯片跑起来了。消息传出来搞AI基建的群里没几个人在意峰值算力是多少大家翻来覆去讨论的是另一个细节这颗芯片周围那圈配套从交换芯片到光模块再到互联协议没有一样来自那家传统GPU大厂。一颗芯片能点亮说明算力这条路终于有了另一种走法旁边站的不再是熟悉的GPU大厂说明这条路是真的走通了。下面从几个角度把它拆开为什么头部实验室要自研芯片、所谓“跑起来”到底意味着什么、真正要把这类芯片落地成一个大模型推理集群需要跨过哪些坑以及这件事对我们这些做AI基建和模型部署的人有什么实际影响。适合正在搞大模型推理优化、算力平台建设、芯片软件栈的工程师也适合想看清自研AI芯片成本账的技术负责人。1. 一颗自研芯片点亮为什么大家都在意“旁边”1.1 从“买卡”到“造卡”是被成本和安全双重逼出来的大模型公司过去几年最大的支出不是人力而是算力采购。做一次千亿参数模型的全量训练往往要调动上万张加速卡连续跑几十天电费、机房、网卡、存储加在一起账单高得吓人。关键是这种需求不是一次性的模型训练完还要持续推理用户每次提问都在消耗的真金白银。头部实验室一年在GPU相关硬件上的花费足够养好几支芯片团队这就是自研芯片最直接的动力。除了价格还有一个更硬的约束供应周期和路线自主权。热门GPU型号长期处于供不应求状态靠抢配额来扩集群对业务节奏影响很大。与其被单一供应商牵着走不如针对自己最频繁的计算模式做一颗专用芯片。大模型推理工作负载高度规律主要就是Transformer那一套运算矩阵乘法、归一化、注意力、逐位激活函数。把通用计算里大量冗余的调度逻辑和缓存结构去掉只保留这些高频运算的加速路径等量性能下的功耗和成本可以低一截。实际算账时不能只看芯片单价得看整体TCO。一颗ASIC从设计、流片到软件适配前期投入确实烧钱但只要流片成功、负载稳定每颗芯片的边际成本会显著低于同性能的通用GPU。一个日均调用量很大的推理业务两三年省下来的电费和采购费就能把研发成本摊平。这也是为什么“能点亮”会比“跑出多高算力”更让人兴奋——它意味着这条成本曲线真的走得通。1.2 “旁边”的物理答案和生态答案仔细看整机柜系统会发现所谓“旁边”有两层意思。物理层面一颗AI芯片不会孤立工作。它旁边一定有内存颗粒、供电模块、时钟芯片、SerDes往上还有机柜内部的交换芯片、光模块、网卡。传统GPU方案里这些环节大量使用了同一家GPU厂商的私有协议和配套产品计算节点和交换节点紧紧绑在一起客户要扩容就只能沿着同一套技术栈往深处走。而现在这颗自研芯片的周边配套来自多家不同供应商互联走的是开放式协议接口也标准化了。说明这套系统从一开始就不希望被任何一家原厂锁死。生态层面旁边站的是谁更重要。传统加速卡的优势从来不止硬件算力还有伴随了十几年的软件生态算子库、调试工具、性能分析器、集合通信库、框架适配层。这些东西让用户“拿到卡就能跑”。自研芯片没有这些遗产反而意味着软件栈可以按新需求重写不必兼容一大堆历史负载。大模型推理的场景非常集中与其在通用生态里绕弯路不如为Transformer专门设计一套轻量运行时。打个比方原来买算力像买整套精装厨房烟机灶具烤箱都是一家品牌坏了只能找同一家售后自研芯片的玩法是只买一块自己设计的灶台旁边的管线、阀门、开关全部按通用标准采购自己组装、自己调参。自由度更大但对自己动手的要求也更高。1.3 行业里真正在观察的三个信号一是供应链开始出现“第二选择”。训练和推理负载可以拆开通用GPU继续用于探索性训练专用芯片稳定承接大规模推理。算力资源不再只押在一个篮子里议价空间也随之打开。二是软件生态从封闭走向开放。既然旁边没有原厂生态可以依赖新芯片的编译器和运行时就必须拥抱开源工具链底层中间表示设计得靠拢行业标准方便算子自动生成和适配。这对整个开发者社区是好事至少不用再对着私有API重写一遍。三是定价逻辑会被重新审视。一旦有一家大客户愿意用自研芯片跑主力推理GPU的市场份额会被一点点切走传统厂商在高端产品上的定价权就不再那么稳固。长期看这对所有买算力的人都是积极信号。2. 自研芯片的技术底盘为Transformer而生不为通用计算买单2.1 计算单元矩阵乘法阵列、向量单元和专用指令AI推理芯片的算力核心不是什么魔法而是把最常用的运算做成专用电路。自研芯片内部通常安排了大面积脉动阵列或类脉动阵列专门处理矩阵乘法。脉动阵列的特点很朴素数据在计算单元之间按节奏流动每个乘加结果都在本地累加不需要频繁访问寄存器堆功耗和面积都比通用GPU上的SIMT式并行更省。在此基础上还会有独立的向量单元处理逐元素运算。Transformer里大量出现的LayerNorm、RMSNorm、非线性激活函数都属于“读一批数据、算一下、写回去”的模式。通用GPU能用通用ALU跑但专用芯片可以用向量流水线一条指令处理很长一段连续数据减少了取指和调度的开销。除了硬件单元指令集也要定制。上分块的注意力计算、KV Cache的页式管理、可变序列长度的批量decode都可以做成专用指令或硬件接口。这些能力通用GPU也有但需要用底层原语一点点拼出来自研芯片可以在ISA层面直接表达编译器生成代码的路径更短运行时也更容易做得轻量。设计这种计算阵列时有个核心取舍固定形状。芯片的脉动阵列尺寸、SRAM容量、数据移动宽度都是围绕某一类主流模型结构定的。如果未来模型结构发生剧烈变化硬件的适配成本会很高。这是专用化必然付出的代价也是头部实验室敢下注的原因——大模型虽然层数、宽度经常变但Transformer的基础计算模式已经稳定了好几年针对它定制是比较安全的判断。2.2 存储与带宽算力再高喂不饱就是废铁很多第一次接触AI芯片的人会盯着TOPS/TFLOPS看但真正做推理优化的人最先看的是内存带宽。大模型推理分两个阶段预填充阶段是计算密集需要大量矩阵乘法解码阶段变成了存储密集每生成一个token几乎都要把权重从内存读一遍。如果内存带宽不够再高的算力也只能空转等待数据。可以算一笔简单的账。一个70亿参数的模型用BF16存储权重大约14GB。在单芯片上做decode时每出一个token至少要完整读一遍所有权重。假如目标是每秒输出500个token那就需要至少7TB/s的内存带宽。这已经是一个非常高的数字接近当前最先进HBM方案的极限。如果把模型再放大到千亿参数单芯片根本放不下必须做多芯片并行同时把模型切到多颗芯片上每颗芯片只读一部分权重再额外承担通信开销。所以自研芯片设计里片上SRAM的容量和HBM通道数量一样关键。典型做法是设计多级数据流权重矩阵按块从HBM拉到片上SRAM在SRAM里完成一次或多次复用再写回结果。计算kernel要围绕SRAM容量来切分数据块切得太大放不下切得太小又会让搬运次数翻倍。这个过程可以用一个简单模型估算对一次矩阵乘法如果把A矩阵块和B矩阵块都装进SRAM片外只需要读一次、写一次块越大算术强度越高效率越好。芯片上SRAM面积有限这个平衡直接决定了实际能跑出多少有效算力。2.3 互联与系统Scale-up、Scale-out和“旁边”的新方案单芯片性能只是开始大模型推理和训练真正麻烦的是把几百上千颗芯片组织成一个集群。这里牵扯到两套网络。Scale-up指机柜内部的超高速互联负责把少量计算芯片组成一个“大芯片”主要服务于张量并行。传统GPU在这层用的是私有互联协议带宽高、延迟低但完全封闭。自研芯片再走老路就没意义了因此新方案倾向于采用开放或半开放的底层接口让不同厂商的PHY、交换芯片、光模块可以混插。带宽也许比私有方案略低但胜在成本可控、供应灵活。Scale-out指机柜之间的大规模组网主要走以太网。之前GPU方案里有个很深的生态绑定就是集合通信库和网卡深度绑定换一张网卡可能整个训练框架都要跟着改。自研芯片如果采用标准以太网再配一个自己的集合通信库就能把集群规模做得更大甚至跨机房调度。通信拓扑对性能影响极大。大模型并行时张量并行要求微秒级延迟通常放在同一个Scale-up域内数据并行和流水线并行对带宽和延迟要求略低可以跨Scale-out域。如果拓扑和并行模式不匹配通信就会变成瓶颈。因此芯片系统设计阶段就要根据典型模型尺寸规划好每颗芯片的网络端口数量、交换机收敛比、自适应路由策略。“旁边站的不是GPU大厂”翻译成技术语言就是这整套通信决策不再依赖原厂私有协议而是自己主导的开放系统。3. 从点亮到跑通模型一个硬件成品到可用产品的过程3.1 点亮只是第一关Bring-up到底在做什么“跑起来了”这个词在外行眼里像开机实际做芯片的人知道点亮只是漫长调试的第一步。芯片通电后首先要确认时钟稳定、复位成功、JTAG链路可访问然后通过调试口把内部测试向量灌进去检查各个子模块的输出是否和仿真结果一致。内存控制器要跑内存自检计算阵列要跑基本算力测试SerDes要完成环回测试。任何一步卡住都得回到寄存器级看状态。很多团队在点亮后兴冲冲跑第一个GEMM发现性能比仿真预期低20%第一反应是后端物理设计没做好其实大概率是时钟频率没校准、电源噪声偏大、或者访问存储的仲裁器配置不对。这类问题通常只能通过芯片里的性能计数器去定位。所以自研芯片设计时一定要在早期就把完整的事件计数体系做进去否则等流片回来再补硬件就来不及了。点亮之后还要经历老化测试、压力测试、边界电压测试。芯片在低温下能跑不代表在高温下也能稳定。特别是大模型推理这种连续高负载的业务芯片发热很快如果电源设计和散热扣得紧频率会主动下压性能跟着掉。这个阶段最考验耐心一个小问题可能要反复烧机几天才能复现。3.2 软件栈关卡从第一个Kernel到完整推理入口芯片能跑硬件测试之后软件团队开始通过运行时加载微码然后把最简单的向量加法跑通。再往下就是平移算子库。一般来说会按这个顺序推进全连接层GEMM、归一化、Softmax、注意力分裂计算最后拼成一个完整的Transformer解码层。每过一个阶段都有一个标志性事件。单算子跑通不算什么算子之间的数据搬运才是大坑。在GPU上框架层会自动处理张量分配和异步拷贝自研芯片前期往往没有这套成熟机制需要工程师手工保证数据在正确的时机放到正确的内存位置。举个例子前一个算子输出还在片上SRAM时如果被下一个算子当成普通内存地址读取就可能拿到旧值。接入高层框架也是个坎。要保证PyTorch或类PyTorch接口下模型定义不变同时自定义后端处理算子调度。这一步通常借助开源图编译器来做模型先被翻译成计算图图编译器中转成目标芯片能识别的指令。图编译器的自动融合能力决定了算子能不能合并、KV Cache能不能更高效地管理。可以说硬件点亮之后真正拉开差距的是编译器团队。为了直观说明映射思路下面这段伪代码展示了矩阵乘法在片上SRAM有限的条件下如何分块搬运。这种分块策略是所有AI芯片软件栈的共同底层逻辑。for m_block in range(0, M, BLOCK_M): for n_block in range(0, N, BLOCK_N): # 从HBM加载两个矩阵块到片上SRAM load A_block[m_block, :] to SRAM load B_block[:, n_block] to SRAM # 在片上完成这个小块的乘加 for k_block in range(0, K, BLOCK_K): load A_sub from SRAM load B_sub from SRAM C_block A_sub B_sub # 写回结果到HBM store C_block to HBMBLOCK_M、BLOCK_N、BLOCK_K的选择不是拍脑袋的要看片上SRAM容量和HBM带宽。块越大数据复用越多但可能超出SRAM容量块太小搬运开销会淹掉计算时间。实际工程中往往要测好几轮找出特定形状下的最优值。3.3 性能评估别只看峰值算力看Roofline给一颗新芯片做评估我的建议是先画一张Roofline模型图把计算峰值和内存带宽画成两条线然后把自己模型里的关键算子按算术强度标进去。算子在线的右侧受算力限制在线的左侧受带宽限制。Transformer解码阶段的大多数算子都受带宽限制尤其是权重读取那部分。这就意味着单纯堆算力没用先把带宽解决才是正路。实际评估时建议做几组微基准测试每组测试只改变一个变量。第一组连续读取大块HBM数据测实际带宽第二组在片上SRAM里做矩阵乘法测计算峰值第三组同时跑多个算子看调度器和内存带宽竞争带来的损耗。跑完这些再拼接成完整模型性能下降才好定位是哪一层引起的。下面的表是一组评估自研推理芯片时会重点盯住的指标和参考目标评估维度关键指标大模型推理场景下的参考目标算力BF16 TFLOPS、实际利用率端到端利用率高于50%访存HBM带宽、有效带宽占比带宽利用率超过70%互联节点内通信带宽、节点外通信带宽张量并行通信开销占比低于5%能效tokens/s/kW比同代通用方案高30%以上时延首token延迟、每token延迟首token低于2秒增量token低于50毫秒这些目标不是某颗芯片的真实参数而是我建议做评估时画的及格线。能有效利用带宽和互联的资源远比只比纸面峰值有意义。4. 跑起来之后真正的硬仗在“旁边”的系统4.1 供电、散热、封装这些“旁边”环节决定能不能量产一颗AI芯片的功耗动辄几百瓦传统的风冷方案已经接近极限。点亮之后整机柜要解决的第一个事情不是软件而是怎么把几百瓦热量散出去同时保证电源在瞬时负载变化时不掉压。大模型推理的负载波动极其剧烈batch里突然加入新请求时计算单元同时启动电流尖峰可能导致其他芯片电压跌落最终表现为奇怪的随机错误。排查到最后可能不是逻辑问题而是电源完整性差了一点。先进封装也是重要一环。为了在更小面积上塞下更多计算单元和缓存芯片常采用更复杂的封装方案把多颗裸片和HBM堆叠在一起。封装内的信号完整性、热应力、翘曲控制都是流片后才暴露的难题。很多时候旁边那颗不起眼的电源管理芯片反而决定了整颗AI芯片能不能稳定跑到标称频率。做系统集成的人要留出足够的调试接口否则出了问题连温度点都测不到。这类问题在演示Demo里看不见只有真正上规模、跑满载时才会出现。我见过一个团队花了两周调算子核最后发现罪魁祸首是供电相位配置和一个固定频率噪声发生共振。这种事没有捷径只能靠扎实的整机测试和足够多的传感器数据。4.2 集群网络当集合通信库换成自己家的自研芯片集群最容易踩的坑是网络调试。原来用GPU方案时集合通信库和网卡深度集成拓扑感知和拥塞控制都封装好了用户基本不用管。换成开放以太网之后这些问题全部浮出水面。第一个要做的是点对点延迟和带宽基线测试。不要直接跑大模型先用一个简单的ping-pong基准测两台节点之间的实际延迟再测多节点同时通信时的带宽收敛情况。很多集群性能差不是因为网卡慢而是交换机缓存太小、拥塞控制参数不合理或者光纤链路中有个别劣化链路。劣化链路在低负载时看不出来一旦多卡同时做AllReduce就会成为黑洞拖慢全局。第二个坑是拓扑感知。大模型并行通信有明确的方向性张量并行是同一个超节点内部的小规模高带宽通信数据并行是跨节点的大块梯度同步。如果调度器不了解物理拓扑把所有rank均匀打散在机架和交换机上那通信模式就会变乱延迟高的链路拖垮整轮迭代。解决办法是给调度器增加网络拓扑描述让离线模型分析器根据拓扑生成rank映射优先把通信量大的rank放在同一个交换域内。调网络时我通常会给团队一张排查清单先抓交换机端口计数器看有没有丢包和PFC暂停再在通信链路两端同时打流对比双向带宽最后把集合通信分成两步跑分别测梯度分块和聚合定位到底哪一步慢。小问题往往是慢烟不抓计数器很难发现。4.3 从单机到多机调度器和内存也要跟着改自研芯片要真正服务于生产光有一颗芯片能跑没有用还必须有资源调度系统和多租户隔离能力。GPU生态里这些能力都是沉淀好的新芯片需要自己搭。调度器至少得知道三类信息每台节点上有几颗芯片、芯片之间是否共享同一个Switch域、当前节点的剩余内存带宽和算力比例。如果调度器只按“卡数”分配不考虑互联域很容易出现一个任务的两颗芯片被分到两个不同机架导致本来应该走超高速互联的通信变成了跨交换机的远距离通信性能落差可能达到数倍。调度器还应该在分配时预留一部分带宽给通信不能让计算任务把网络占死。另一个常被忽略的是内存池管理。LLM推理会有大量KV Cache这些缓存在不同请求之间动态伸缩。传统GPU的显存池用CUDA的默认策略就能跑个七七八八自研芯片的驱动不一定提供同样成熟的内存池应用层必须自己管理。如果不做显式管理频繁分配和释放会造成碎片推理吞吐会随运行时间明显下降。我的经验是在运行时层就实现一个专用的KV Cache池按页分配提前预留峰值需要的空间而不是遇到新请求再临时申请。5. 行业变量与工程师的新考题5.1 GPU的护城河被动摇没那么快也没那么慢自研芯片要取代GPU还要很长时间。通用GPU的优势在于通用性从计算机视觉到科学计算从训练到推理同一套硬件都能跑同一套软件生态都能支持。专用芯片只能在特定负载上做到高性价比。但大模型推理已经是一个足够大的单一市场头部实验室一年产生的推理请求量完全撑得起一颗ASIC的研发和量产。所以更准确的说法是GPU不会被整体取代但会被从中分走最肥的一块业务。真正让GPU大厂感到压力的不是硬件跑分而是客户在软件层面拥有了议价权。一旦头部客户愿意投入编译器团队、维护自研运行时就不再需要原厂的每一次软件迭代。GPU厂商再动辄改API、改驱动行为客户可以选择不跟随。开源编译器在这中间的推动作用很大。过去芯片厂商靠私有编译器和算子库建立生态壁垒现在开源工具链让新芯片可以复用大量调度优化和代码生成逻辑。硬件本身不再是无法绕开的天花板软件栈的适配速度比十年前快得多。这也是越来越多公司敢碰自研AI芯片的底气所在。5.2 AI Infra工程师需要补哪几门课这件事对普通做模型部署和推理优化的工程师影响很大以后可能不是所有人都会面对GPU环境接触的芯片可能是自研ASIC玩法完全不同。我觉得至少有三件事值得提前准备。第一是建立“带宽”直觉。拿到一个算子先判断它是计算密集还是访存密集判断标准很简单算一下需要读多少字节数据做多少次浮点运算然后和芯片的峰值算力、内存带宽对比。解码阶段大部分算子都是带宽瓶颈这就意味着优化方向是减少内存拷贝、做算子融合、降低数据精度。第二是会看互联拓扑。至少要知道张量并行、流水线并行、数据并行分别对通信有什么要求能读懂集群的网络拓扑图知道哪些节点在同一个机柜、哪些要跨交换机。遇到通信瓶颈时能快速判断是网络硬件问题还是并行切分策略问题。第三是敢于用底层性能计数器。自研芯片的调试工具肯定不如成熟GPU生态那么顺手但设计之初一般都会留下丰富的事件计数接口。与其靠猜不如花时间熟练使用注册表读取工具、链路调试口、跟踪日志。性能优化这件事数据永远是第一位的经验排第二。5.3 如何判断自研芯片方案适不适合你的业务不是每家公司都该跟风做自研芯片也不是有自研芯片就能立刻替代GPU。如果现在要评估一个自研芯片方案是否值得用我一般会看几个条件。工作负载是否足够固定。如果一个团队每天跑几十种不同结构的模型ASIC的固定加速路径可能帮助有限如果核心业务就是两三个固定的大模型做在线推理那ASIC的优势非常明显。自研芯片的量是否足够大。至少是几千片的用量才能摊薄研发成本。如果一年只消耗几百片继续租用云上的GPU可能更划算。软件团队能不能消化。芯片流片只是开始后面要有人做编译器适配、算子开发、运行时维护。如果软件团队只有两三个人不建议贸然切入。供应链和工艺也很现实。先进工艺产能紧张封装和HBM的采购同样要看上游脸色。自研芯片只是把依赖从“买到卡”变成“买到产能和IP”并没有消除产业链上的物理依赖只是换了一种更可控的方式。最后一个考量是容忍度。是不是能接受在上线初期性能达不到预期慢慢调优。如果业务对稳定性极其敏感最好先小规模试点铺开之前留出充足的验证时间。我自己在类似的原型芯片项目里做过算子迁移最大的体会是性能问题很少出在计算逻辑本身而往往出在任务调度和访存模式上。拿到一颗新芯片第一周先别急着移植完整模型把内存地址映射、事件计数器、链路调试口全部摸透再跑几个微基准测试把理论和实测对齐。做LLM推理的优先测decode阶段的权重读取带宽和Attention的KV Cache命中率这两点决定绝大多数用户体验。很多团队前几周都在折腾光纤和PCIe兼容性最后发现模型跑不起来只是因为某个电源轨在瞬时负载下掉电。这种“旁边”的问题才是最考验人的。 
长河君 · 2026/10/26 20:02:41 · 阅读 1.2k 自研AI芯片点亮：开放式互联与软件栈如何改写大模型推理基础设施
一家做对话大模型的头部实验室自研的第一颗AI芯片跑起来了。消息传出来搞AI基建的群里没几个人在意峰值算力是多少大家翻来覆去讨论的是另一个细节这颗芯片周围那圈配套从交换芯片到光模块再到互联协议没有一样来自那家传统GPU大厂。一颗芯片能点亮说明算力这条路终于有了另一种走法旁边站的不再是熟悉的GPU大厂说明这条路是真的走通了。下面从几个角度把它拆开为什么头部实验室要自研芯片、所谓“跑起来”到底意味着什么、真正要把这类芯片落地成一个大模型推理集群需要跨过哪些坑以及这件事对我们这些做AI基建和模型部署的人有什么实际影响。适合正在搞大模型推理优化、算力平台建设、芯片软件栈的工程师也适合想看清自研AI芯片成本账的技术负责人。1. 一颗自研芯片点亮为什么大家都在意“旁边”1.1 从“买卡”到“造卡”是被成本和安全双重逼出来的大模型公司过去几年最大的支出不是人力而是算力采购。做一次千亿参数模型的全量训练往往要调动上万张加速卡连续跑几十天电费、机房、网卡、存储加在一起账单高得吓人。关键是这种需求不是一次性的模型训练完还要持续推理用户每次提问都在消耗的真金白银。头部实验室一年在GPU相关硬件上的花费足够养好几支芯片团队这就是自研芯片最直接的动力。除了价格还有一个更硬的约束供应周期和路线自主权。热门GPU型号长期处于供不应求状态靠抢配额来扩集群对业务节奏影响很大。与其被单一供应商牵着走不如针对自己最频繁的计算模式做一颗专用芯片。大模型推理工作负载高度规律主要就是Transformer那一套运算矩阵乘法、归一化、注意力、逐位激活函数。把通用计算里大量冗余的调度逻辑和缓存结构去掉只保留这些高频运算的加速路径等量性能下的功耗和成本可以低一截。实际算账时不能只看芯片单价得看整体TCO。一颗ASIC从设计、流片到软件适配前期投入确实烧钱但只要流片成功、负载稳定每颗芯片的边际成本会显著低于同性能的通用GPU。一个日均调用量很大的推理业务两三年省下来的电费和采购费就能把研发成本摊平。这也是为什么“能点亮”会比“跑出多高算力”更让人兴奋——它意味着这条成本曲线真的走得通。1.2 “旁边”的物理答案和生态答案仔细看整机柜系统会发现所谓“旁边”有两层意思。物理层面一颗AI芯片不会孤立工作。它旁边一定有内存颗粒、供电模块、时钟芯片、SerDes往上还有机柜内部的交换芯片、光模块、网卡。传统GPU方案里这些环节大量使用了同一家GPU厂商的私有协议和配套产品计算节点和交换节点紧紧绑在一起客户要扩容就只能沿着同一套技术栈往深处走。而现在这颗自研芯片的周边配套来自多家不同供应商互联走的是开放式协议接口也标准化了。说明这套系统从一开始就不希望被任何一家原厂锁死。生态层面旁边站的是谁更重要。传统加速卡的优势从来不止硬件算力还有伴随了十几年的软件生态算子库、调试工具、性能分析器、集合通信库、框架适配层。这些东西让用户“拿到卡就能跑”。自研芯片没有这些遗产反而意味着软件栈可以按新需求重写不必兼容一大堆历史负载。大模型推理的场景非常集中与其在通用生态里绕弯路不如为Transformer专门设计一套轻量运行时。打个比方原来买算力像买整套精装厨房烟机灶具烤箱都是一家品牌坏了只能找同一家售后自研芯片的玩法是只买一块自己设计的灶台旁边的管线、阀门、开关全部按通用标准采购自己组装、自己调参。自由度更大但对自己动手的要求也更高。1.3 行业里真正在观察的三个信号一是供应链开始出现“第二选择”。训练和推理负载可以拆开通用GPU继续用于探索性训练专用芯片稳定承接大规模推理。算力资源不再只押在一个篮子里议价空间也随之打开。二是软件生态从封闭走向开放。既然旁边没有原厂生态可以依赖新芯片的编译器和运行时就必须拥抱开源工具链底层中间表示设计得靠拢行业标准方便算子自动生成和适配。这对整个开发者社区是好事至少不用再对着私有API重写一遍。三是定价逻辑会被重新审视。一旦有一家大客户愿意用自研芯片跑主力推理GPU的市场份额会被一点点切走传统厂商在高端产品上的定价权就不再那么稳固。长期看这对所有买算力的人都是积极信号。2. 自研芯片的技术底盘为Transformer而生不为通用计算买单2.1 计算单元矩阵乘法阵列、向量单元和专用指令AI推理芯片的算力核心不是什么魔法而是把最常用的运算做成专用电路。自研芯片内部通常安排了大面积脉动阵列或类脉动阵列专门处理矩阵乘法。脉动阵列的特点很朴素数据在计算单元之间按节奏流动每个乘加结果都在本地累加不需要频繁访问寄存器堆功耗和面积都比通用GPU上的SIMT式并行更省。在此基础上还会有独立的向量单元处理逐元素运算。Transformer里大量出现的LayerNorm、RMSNorm、非线性激活函数都属于“读一批数据、算一下、写回去”的模式。通用GPU能用通用ALU跑但专用芯片可以用向量流水线一条指令处理很长一段连续数据减少了取指和调度的开销。除了硬件单元指令集也要定制。上分块的注意力计算、KV Cache的页式管理、可变序列长度的批量decode都可以做成专用指令或硬件接口。这些能力通用GPU也有但需要用底层原语一点点拼出来自研芯片可以在ISA层面直接表达编译器生成代码的路径更短运行时也更容易做得轻量。设计这种计算阵列时有个核心取舍固定形状。芯片的脉动阵列尺寸、SRAM容量、数据移动宽度都是围绕某一类主流模型结构定的。如果未来模型结构发生剧烈变化硬件的适配成本会很高。这是专用化必然付出的代价也是头部实验室敢下注的原因——大模型虽然层数、宽度经常变但Transformer的基础计算模式已经稳定了好几年针对它定制是比较安全的判断。2.2 存储与带宽算力再高喂不饱就是废铁很多第一次接触AI芯片的人会盯着TOPS/TFLOPS看但真正做推理优化的人最先看的是内存带宽。大模型推理分两个阶段预填充阶段是计算密集需要大量矩阵乘法解码阶段变成了存储密集每生成一个token几乎都要把权重从内存读一遍。如果内存带宽不够再高的算力也只能空转等待数据。可以算一笔简单的账。一个70亿参数的模型用BF16存储权重大约14GB。在单芯片上做decode时每出一个token至少要完整读一遍所有权重。假如目标是每秒输出500个token那就需要至少7TB/s的内存带宽。这已经是一个非常高的数字接近当前最先进HBM方案的极限。如果把模型再放大到千亿参数单芯片根本放不下必须做多芯片并行同时把模型切到多颗芯片上每颗芯片只读一部分权重再额外承担通信开销。所以自研芯片设计里片上SRAM的容量和HBM通道数量一样关键。典型做法是设计多级数据流权重矩阵按块从HBM拉到片上SRAM在SRAM里完成一次或多次复用再写回结果。计算kernel要围绕SRAM容量来切分数据块切得太大放不下切得太小又会让搬运次数翻倍。这个过程可以用一个简单模型估算对一次矩阵乘法如果把A矩阵块和B矩阵块都装进SRAM片外只需要读一次、写一次块越大算术强度越高效率越好。芯片上SRAM面积有限这个平衡直接决定了实际能跑出多少有效算力。2.3 互联与系统Scale-up、Scale-out和“旁边”的新方案单芯片性能只是开始大模型推理和训练真正麻烦的是把几百上千颗芯片组织成一个集群。这里牵扯到两套网络。Scale-up指机柜内部的超高速互联负责把少量计算芯片组成一个“大芯片”主要服务于张量并行。传统GPU在这层用的是私有互联协议带宽高、延迟低但完全封闭。自研芯片再走老路就没意义了因此新方案倾向于采用开放或半开放的底层接口让不同厂商的PHY、交换芯片、光模块可以混插。带宽也许比私有方案略低但胜在成本可控、供应灵活。Scale-out指机柜之间的大规模组网主要走以太网。之前GPU方案里有个很深的生态绑定就是集合通信库和网卡深度绑定换一张网卡可能整个训练框架都要跟着改。自研芯片如果采用标准以太网再配一个自己的集合通信库就能把集群规模做得更大甚至跨机房调度。通信拓扑对性能影响极大。大模型并行时张量并行要求微秒级延迟通常放在同一个Scale-up域内数据并行和流水线并行对带宽和延迟要求略低可以跨Scale-out域。如果拓扑和并行模式不匹配通信就会变成瓶颈。因此芯片系统设计阶段就要根据典型模型尺寸规划好每颗芯片的网络端口数量、交换机收敛比、自适应路由策略。“旁边站的不是GPU大厂”翻译成技术语言就是这整套通信决策不再依赖原厂私有协议而是自己主导的开放系统。3. 从点亮到跑通模型一个硬件成品到可用产品的过程3.1 点亮只是第一关Bring-up到底在做什么“跑起来了”这个词在外行眼里像开机实际做芯片的人知道点亮只是漫长调试的第一步。芯片通电后首先要确认时钟稳定、复位成功、JTAG链路可访问然后通过调试口把内部测试向量灌进去检查各个子模块的输出是否和仿真结果一致。内存控制器要跑内存自检计算阵列要跑基本算力测试SerDes要完成环回测试。任何一步卡住都得回到寄存器级看状态。很多团队在点亮后兴冲冲跑第一个GEMM发现性能比仿真预期低20%第一反应是后端物理设计没做好其实大概率是时钟频率没校准、电源噪声偏大、或者访问存储的仲裁器配置不对。这类问题通常只能通过芯片里的性能计数器去定位。所以自研芯片设计时一定要在早期就把完整的事件计数体系做进去否则等流片回来再补硬件就来不及了。点亮之后还要经历老化测试、压力测试、边界电压测试。芯片在低温下能跑不代表在高温下也能稳定。特别是大模型推理这种连续高负载的业务芯片发热很快如果电源设计和散热扣得紧频率会主动下压性能跟着掉。这个阶段最考验耐心一个小问题可能要反复烧机几天才能复现。3.2 软件栈关卡从第一个Kernel到完整推理入口芯片能跑硬件测试之后软件团队开始通过运行时加载微码然后把最简单的向量加法跑通。再往下就是平移算子库。一般来说会按这个顺序推进全连接层GEMM、归一化、Softmax、注意力分裂计算最后拼成一个完整的Transformer解码层。每过一个阶段都有一个标志性事件。单算子跑通不算什么算子之间的数据搬运才是大坑。在GPU上框架层会自动处理张量分配和异步拷贝自研芯片前期往往没有这套成熟机制需要工程师手工保证数据在正确的时机放到正确的内存位置。举个例子前一个算子输出还在片上SRAM时如果被下一个算子当成普通内存地址读取就可能拿到旧值。接入高层框架也是个坎。要保证PyTorch或类PyTorch接口下模型定义不变同时自定义后端处理算子调度。这一步通常借助开源图编译器来做模型先被翻译成计算图图编译器中转成目标芯片能识别的指令。图编译器的自动融合能力决定了算子能不能合并、KV Cache能不能更高效地管理。可以说硬件点亮之后真正拉开差距的是编译器团队。为了直观说明映射思路下面这段伪代码展示了矩阵乘法在片上SRAM有限的条件下如何分块搬运。这种分块策略是所有AI芯片软件栈的共同底层逻辑。for m_block in range(0, M, BLOCK_M): for n_block in range(0, N, BLOCK_N): # 从HBM加载两个矩阵块到片上SRAM load A_block[m_block, :] to SRAM load B_block[:, n_block] to SRAM # 在片上完成这个小块的乘加 for k_block in range(0, K, BLOCK_K): load A_sub from SRAM load B_sub from SRAM C_block A_sub B_sub # 写回结果到HBM store C_block to HBMBLOCK_M、BLOCK_N、BLOCK_K的选择不是拍脑袋的要看片上SRAM容量和HBM带宽。块越大数据复用越多但可能超出SRAM容量块太小搬运开销会淹掉计算时间。实际工程中往往要测好几轮找出特定形状下的最优值。3.3 性能评估别只看峰值算力看Roofline给一颗新芯片做评估我的建议是先画一张Roofline模型图把计算峰值和内存带宽画成两条线然后把自己模型里的关键算子按算术强度标进去。算子在线的右侧受算力限制在线的左侧受带宽限制。Transformer解码阶段的大多数算子都受带宽限制尤其是权重读取那部分。这就意味着单纯堆算力没用先把带宽解决才是正路。实际评估时建议做几组微基准测试每组测试只改变一个变量。第一组连续读取大块HBM数据测实际带宽第二组在片上SRAM里做矩阵乘法测计算峰值第三组同时跑多个算子看调度器和内存带宽竞争带来的损耗。跑完这些再拼接成完整模型性能下降才好定位是哪一层引起的。下面的表是一组评估自研推理芯片时会重点盯住的指标和参考目标评估维度关键指标大模型推理场景下的参考目标算力BF16 TFLOPS、实际利用率端到端利用率高于50%访存HBM带宽、有效带宽占比带宽利用率超过70%互联节点内通信带宽、节点外通信带宽张量并行通信开销占比低于5%能效tokens/s/kW比同代通用方案高30%以上时延首token延迟、每token延迟首token低于2秒增量token低于50毫秒这些目标不是某颗芯片的真实参数而是我建议做评估时画的及格线。能有效利用带宽和互联的资源远比只比纸面峰值有意义。4. 跑起来之后真正的硬仗在“旁边”的系统4.1 供电、散热、封装这些“旁边”环节决定能不能量产一颗AI芯片的功耗动辄几百瓦传统的风冷方案已经接近极限。点亮之后整机柜要解决的第一个事情不是软件而是怎么把几百瓦热量散出去同时保证电源在瞬时负载变化时不掉压。大模型推理的负载波动极其剧烈batch里突然加入新请求时计算单元同时启动电流尖峰可能导致其他芯片电压跌落最终表现为奇怪的随机错误。排查到最后可能不是逻辑问题而是电源完整性差了一点。先进封装也是重要一环。为了在更小面积上塞下更多计算单元和缓存芯片常采用更复杂的封装方案把多颗裸片和HBM堆叠在一起。封装内的信号完整性、热应力、翘曲控制都是流片后才暴露的难题。很多时候旁边那颗不起眼的电源管理芯片反而决定了整颗AI芯片能不能稳定跑到标称频率。做系统集成的人要留出足够的调试接口否则出了问题连温度点都测不到。这类问题在演示Demo里看不见只有真正上规模、跑满载时才会出现。我见过一个团队花了两周调算子核最后发现罪魁祸首是供电相位配置和一个固定频率噪声发生共振。这种事没有捷径只能靠扎实的整机测试和足够多的传感器数据。4.2 集群网络当集合通信库换成自己家的自研芯片集群最容易踩的坑是网络调试。原来用GPU方案时集合通信库和网卡深度集成拓扑感知和拥塞控制都封装好了用户基本不用管。换成开放以太网之后这些问题全部浮出水面。第一个要做的是点对点延迟和带宽基线测试。不要直接跑大模型先用一个简单的ping-pong基准测两台节点之间的实际延迟再测多节点同时通信时的带宽收敛情况。很多集群性能差不是因为网卡慢而是交换机缓存太小、拥塞控制参数不合理或者光纤链路中有个别劣化链路。劣化链路在低负载时看不出来一旦多卡同时做AllReduce就会成为黑洞拖慢全局。第二个坑是拓扑感知。大模型并行通信有明确的方向性张量并行是同一个超节点内部的小规模高带宽通信数据并行是跨节点的大块梯度同步。如果调度器不了解物理拓扑把所有rank均匀打散在机架和交换机上那通信模式就会变乱延迟高的链路拖垮整轮迭代。解决办法是给调度器增加网络拓扑描述让离线模型分析器根据拓扑生成rank映射优先把通信量大的rank放在同一个交换域内。调网络时我通常会给团队一张排查清单先抓交换机端口计数器看有没有丢包和PFC暂停再在通信链路两端同时打流对比双向带宽最后把集合通信分成两步跑分别测梯度分块和聚合定位到底哪一步慢。小问题往往是慢烟不抓计数器很难发现。4.3 从单机到多机调度器和内存也要跟着改自研芯片要真正服务于生产光有一颗芯片能跑没有用还必须有资源调度系统和多租户隔离能力。GPU生态里这些能力都是沉淀好的新芯片需要自己搭。调度器至少得知道三类信息每台节点上有几颗芯片、芯片之间是否共享同一个Switch域、当前节点的剩余内存带宽和算力比例。如果调度器只按“卡数”分配不考虑互联域很容易出现一个任务的两颗芯片被分到两个不同机架导致本来应该走超高速互联的通信变成了跨交换机的远距离通信性能落差可能达到数倍。调度器还应该在分配时预留一部分带宽给通信不能让计算任务把网络占死。另一个常被忽略的是内存池管理。LLM推理会有大量KV Cache这些缓存在不同请求之间动态伸缩。传统GPU的显存池用CUDA的默认策略就能跑个七七八八自研芯片的驱动不一定提供同样成熟的内存池应用层必须自己管理。如果不做显式管理频繁分配和释放会造成碎片推理吞吐会随运行时间明显下降。我的经验是在运行时层就实现一个专用的KV Cache池按页分配提前预留峰值需要的空间而不是遇到新请求再临时申请。5. 行业变量与工程师的新考题5.1 GPU的护城河被动摇没那么快也没那么慢自研芯片要取代GPU还要很长时间。通用GPU的优势在于通用性从计算机视觉到科学计算从训练到推理同一套硬件都能跑同一套软件生态都能支持。专用芯片只能在特定负载上做到高性价比。但大模型推理已经是一个足够大的单一市场头部实验室一年产生的推理请求量完全撑得起一颗ASIC的研发和量产。所以更准确的说法是GPU不会被整体取代但会被从中分走最肥的一块业务。真正让GPU大厂感到压力的不是硬件跑分而是客户在软件层面拥有了议价权。一旦头部客户愿意投入编译器团队、维护自研运行时就不再需要原厂的每一次软件迭代。GPU厂商再动辄改API、改驱动行为客户可以选择不跟随。开源编译器在这中间的推动作用很大。过去芯片厂商靠私有编译器和算子库建立生态壁垒现在开源工具链让新芯片可以复用大量调度优化和代码生成逻辑。硬件本身不再是无法绕开的天花板软件栈的适配速度比十年前快得多。这也是越来越多公司敢碰自研AI芯片的底气所在。5.2 AI Infra工程师需要补哪几门课这件事对普通做模型部署和推理优化的工程师影响很大以后可能不是所有人都会面对GPU环境接触的芯片可能是自研ASIC玩法完全不同。我觉得至少有三件事值得提前准备。第一是建立“带宽”直觉。拿到一个算子先判断它是计算密集还是访存密集判断标准很简单算一下需要读多少字节数据做多少次浮点运算然后和芯片的峰值算力、内存带宽对比。解码阶段大部分算子都是带宽瓶颈这就意味着优化方向是减少内存拷贝、做算子融合、降低数据精度。第二是会看互联拓扑。至少要知道张量并行、流水线并行、数据并行分别对通信有什么要求能读懂集群的网络拓扑图知道哪些节点在同一个机柜、哪些要跨交换机。遇到通信瓶颈时能快速判断是网络硬件问题还是并行切分策略问题。第三是敢于用底层性能计数器。自研芯片的调试工具肯定不如成熟GPU生态那么顺手但设计之初一般都会留下丰富的事件计数接口。与其靠猜不如花时间熟练使用注册表读取工具、链路调试口、跟踪日志。性能优化这件事数据永远是第一位的经验排第二。5.3 如何判断自研芯片方案适不适合你的业务不是每家公司都该跟风做自研芯片也不是有自研芯片就能立刻替代GPU。如果现在要评估一个自研芯片方案是否值得用我一般会看几个条件。工作负载是否足够固定。如果一个团队每天跑几十种不同结构的模型ASIC的固定加速路径可能帮助有限如果核心业务就是两三个固定的大模型做在线推理那ASIC的优势非常明显。自研芯片的量是否足够大。至少是几千片的用量才能摊薄研发成本。如果一年只消耗几百片继续租用云上的GPU可能更划算。软件团队能不能消化。芯片流片只是开始后面要有人做编译器适配、算子开发、运行时维护。如果软件团队只有两三个人不建议贸然切入。供应链和工艺也很现实。先进工艺产能紧张封装和HBM的采购同样要看上游脸色。自研芯片只是把依赖从“买到卡”变成“买到产能和IP”并没有消除产业链上的物理依赖只是换了一种更可控的方式。最后一个考量是容忍度。是不是能接受在上线初期性能达不到预期慢慢调优。如果业务对稳定性极其敏感最好先小规模试点铺开之前留出充足的验证时间。我自己在类似的原型芯片项目里做过算子迁移最大的体会是性能问题很少出在计算逻辑本身而往往出在任务调度和访存模式上。拿到一颗新芯片第一周先别急着移植完整模型把内存地址映射、事件计数器、链路调试口全部摸透再跑几个微基准测试把理论和实测对齐。做LLM推理的优先测decode阶段的权重读取带宽和Attention的KV Cache命中率这两点决定绝大多数用户体验。很多团队前几周都在折腾光纤和PCIe兼容性最后发现模型跑不起来只是因为某个电源轨在瞬时负载下掉电。这种“旁边”的问题才是最考验人的。