AI芯片开发这几年热度一直很高但很多人聊的是架构、算力、制程这些硬件话题真正干过软硬件协同的人才知道一颗芯片从点亮到能把模型跑起来、把性能压榨出来中间隔着一条巨大的鸿沟。这条鸿沟就是软硬件接口的设计质量。我前前后后参与过两颗AI芯片的完整流程一颗是面向端侧推理的小芯片一颗是面向云端训练的大芯片踩过的坑、填过的洞、撕过的文档数都数不清。这篇东西不打算讲那些浮在表面的概念我想把“AI芯片的软硬件设计”这件事拆开讲讲芯片真正从设计到跑通模型的过程中软硬件两边到底是怎么咬合的、哪些地方最容易翻车、以及为什么很多性能问题最后都指向软件工具链而非硬件本身。无论你是刚入行的芯片验证工程师、做算子库的软件工程师、还是带团队的架构师这篇内容都值得你花十几分钟过一遍。它不是教科书更像是一个做过的同事在给你划重点。1. 为什么AI芯片必须“软硬件一起设计”而不是先硬件后软件很多人第一次接触AI芯片项目时默认的流程是先定硬件架构、做RTL、流片回来之后再写软件栈。这个思路在通用CPU时代基本成立因为在通用处理器上软件生态是现成的编译器、操作系统、应用层都已经非常成熟。但AI芯片不是通用处理器它是一颗典型的DSA架构芯片也就是面向特定领域设计的专用架构。DSA的核心逻辑是用硬件上的定制化换取某个特定计算模式的效率同时把灵活性牺牲掉寄希望于编译器能在编译阶段把这些定制硬件管起来。这就带来了一个根本性的问题硬件一旦流片它的计算模式、数据通路、存储布局就全部冻结了。如果软件工具链在芯片回来之前没有并行开发、没有在仿真环境里做足够深度的软硬件联合验证那等芯片真的点亮的时刻往往就是你项目噩梦的开始。1.1 软件吃什么、硬件拉什么两条线的咬合点我们把一次AI推理过程简化一下。模型在网络层面是算子图你写一行conv2d(x, weight)这行代码在PyTorch里只是一层抽象。真正落到芯片上执行时它需要经历算子被解析成底层指令、指令被调度器分配计算单元、数据从外部存储搬到片上、计算阵列执行乘加运算、结果再搬运回去。这条链路里硬件的职责是“执行搬运和计算”软件的职责是“决定什么顺序搬、搬多少、什么时候算”。软硬件设计的本质就是在两者之间划定一条边界。边界画得好软件可以充分调度硬件资源性能逼近理论峰值边界画得差哪怕硬件峰值算力再高实际跑出来的有效算力可能只有两成。这条边界由ISA、寄存器配置、中断机制、存储映射规则等等共同决定它们就是芯片的“软件接口”。很多人以为软件接口就是SDK里那几个API其实真正的接口层面有两层第一层是给上层模型开发者的比如ONNX Runtime适配层、自研推理框架的算子API。这一层要保证“看起来像GPU那样开发便利”。第二层是给底层驱动和Runtime的比如指令下发格式、DMA描述符、Ring Buffer管理、中断机制。这一层要保证“硬件的每个能力都能被触达同时不会让软件误操作踩坏硬件状态机”。这两层中间还有一层就是编译器。任何一个AI芯片项目软件栈基本都逃不开“框架适配层、图编译器、算子编译器、运行时Runtime、驱动”这几大块。1.2 一个看似正常却慢两倍的算子往往是软硬件接口设计埋的雷我举一个真实经历过的例子。我们内部那颗端侧芯片在仿真阶段跑的ResNet50性能模型预测的延迟是5毫秒编译出来的第一个版本实测跑了11毫秒。性能差了整整一倍多。当时第一反应是算子没优化好大家蹲在那里调卷积的tiling参数折腾了一周性能只从11提升到了9。后来我们一个做验证的同事无意中发现指令解析器在每个算子结束之后都会做一次同步屏障而同步屏障会等待所有计算单元完全空闲才放行下一条指令。问题就出在这里卷积算子在最后一段循环计算单元之间负载不均衡有的PE已经算完了但还有一小撮PE在等最后一批数据从DMA搬过来。因为软硬件接口里定义了一条“算子结束时必须等待所有PE空闲”的状态机规则导致每次算子切换都白白浪费大量等待时间。而后续指令明明不依赖上一个算子的内部数据完全可以提前启动。这个问题的根不在硬件算力也不在算子算法本身而是软硬件接口把同步粒度定得太粗。后面我们把同步语义改成了“仅同步依赖边所指的存储缓冲区”并在编译器里增加依赖分析性能才回到6毫秒以内。这种问题在芯片回来之前想都想不到只能在仿真平台里通过跑真实模型才能发现。所以软硬件协同设计不只是口号它需要工具链和硬件验证平台在项目初期就深度绑定。2. 硬件侧的架构决策算力之外几乎全是存储与数据通路的故事聊到AI芯片所有人第一眼看的就是TOPS也就是每秒万亿次操作数。但真的做过芯片你就会明白TOPS只是天花板真正决定实际性能的是三件事数据能不能喂得进去、片上存储够不够用、计算单元能不能一直满载。这三件事没有一件是单纯靠堆算力能解决的。2.1 主计算阵列MAC阵列要配合数据复用而不是光堆数量AI芯片的核心计算单元是MAC阵列每个MAC单元一次做一个乘加运算。一个8x8的阵列一个周期能做64次乘加。听起来很简单但阵列的利用率取决于数据复用。卷积操作里同一个输入像素会被多个输出通道的卷积核重复使用同一个权重也会被多个输入位置的像素重复使用。如果阵列每次计算都从外部存储重新取数那带宽马上变成瓶颈算力再高也白搭。所以硬件设计里必须有线缓冲和输出缓冲。比如我们常用的策略是输入有行缓冲把输入特征图按行流水地往阵列送权重有权重缓冲一个权重复用给一批输入输出有累加缓冲等一个tile的所有累加完成后一次性写回。片内缓冲和计算阵列之间是乒乓关系一组缓冲在往阵列送数据的时候另一组缓冲正在接收DMA从外部存储搬来的新数据这样计算才不至于停下来等数据。具体来说tile大小的选择是软硬件协同的第一个分水岭。我见过很多做算法的人习惯直接选整个通道作为tile这在片内SRAM足够大时没问题但在端侧芯片上很快就发现权重放不下、输入特征图的一整行也放不下。所以算子编译器必须结合SRAM容量做分块这个分块参数直接决定实际能跑多少效率。分太小搬运次数指数级增加分太大SRAM溢出只能依赖编译器做spill性能崩盘。2.2 片上存储层级为什么SRAM容量比峰值算力更影响真实性能假设一颗芯片峰值算力是20 TOPS工作频率是1GHz那意味着每个周期要完成20000次乘加。一次MAC需要读两个操作数、写一个累加结果粗略算下来每周期至少要读40000字节的数据。如果这些数据全部从DDR拿DDR带宽就算做到100GB/s也覆盖不了这个需求。这就是AI芯片设计里常说的一句老话“算力易得带宽难求”。因此片上的多级存储就非常重要。通常AI芯片会有三级寄存器/累加器每个PE内部的数据暂存速度最快容量很小。片内SRAM通常几百KB到几MB作为主缓冲池承载tile数据、权重、中间结果。外部DDR/HBM模型参数和整幅特征图的存放地速度慢但容量大。SRAM的容量直接决定了编译器能把多远的数据“捞”到片上。如果SRAM有2MB那很多模型层级就可能整个放进去减少外部访问如果只有256KB那每一层都得分块搬运软件开销会非常重。选型时我们一般会算一个“单算子最大tile需求”输入特征图一个tile 权重切片 输出tile再加上中间缓冲和double buffer的空间4倍于计算所需的数据量。这个数算出来基本就知道SRAM该做多大了。2.3 数据通路设计软流水、ping-pong buffer与访存冲突存储层级定了之后下一个问题就是数据怎么流动。单纯把数据从DDR搬到SRAM再从SRAM送进阵列这个顺序执行的话计算单元大部分时间在空转。所以硬件上要有足够深的流水线机制。最基础的设计是DMA搬运和计算阵列并行工作。比如在计算第N个tile的时候DMA同时预取第N1个tile到SRAM的另一块缓冲里。这个机制要求SRAM至少分成两块独立缓冲也就是我们常说的ping-pong buffer。编译器在生成指令序列时必须按照“搬运、计算、搬运、计算”的节奏交错安排把计算时间隐藏到搬运时间里。但这里有个很难缠的问题外部存储访问冲突。如果多个DMA通道同时启动或者计算阵列同时发起了非对齐的数据访问DDR控制器就会产生bank冲突实际带宽瞬间掉一半。我们在调试一个视频模型时发现明明带宽估算是足够的但跑起来整体帧率就是上不去最后用硬件性能计数器一看DDR的读带宽利用率只有34%因为三个DMA通道反复抢同一个bank区间。后来在编译器调度时给DMA通道加了起始地址偏移和bank分配的互斥策略带宽利用率才恢复到70%以上。3. 软件侧的工具链把浮点运算图变成硬件能跑的指令流硬件能获取的性能上限是固定的决定实际性能的就是编译器和Runtime。很多人低估了工具链的工作量觉得“能编译跑通就行”但实际上工具链的深度直接决定芯片的生死。我常说一个观点AI芯片的竞争力一半在架构一半在编译器。如果架构是90分而编译器只能发挥50分那有效算力就是45分而一个80分架构配一个80分编译器有效算力是64分后者反而赢。3.1 编译器栈的四个层级从计算图到循环级优化再到指令级AI芯片的编译器通常分四层模型级优化拿到计算图后做算子融合、死代码消除、常量折叠。比如把ConvBNReLU融合成单个算子或者把相邻的Elementwise算子合并减少中间张量的DDR读写。算子级优化针对具体算子做计算变换。比如卷积可以转成GEMM也可以用Winograd做变换减少乘法次数或者用FFT做频域卷积在滤波核较大时更划算。循环级优化这是最核心也最繁琐的一层。编译器要把算子内部的循环做分块、向量化、并行化、重排序把循环的访问模式映射到硬件的数据通路和缓冲结构上。指令级调度生成底层指令序列安排指令发射顺序、同步点、DMA预取处理指令流水线冒险。很多人会问为什么不能像GPU那样直接用现有的TVM或MLIR做一套适配就完了理论上确实能这么干但AI芯片的一大特点就是各家硬件差异极大。有的芯片支持动态形状、有的只支持静态形状有的PE阵列是大块SIMD有的是众多小核MIMD风格。TVM的调度模板是为GPU的线程结构设计的换到自定义DSA上你得自己写大量的调度原语和代码生成后端这活本质上就是在做一个行业级编译器难度和工作量都不小。3.2 SIMT与SIMD的路线之分这是个架构决策不只是软件风格GPU走的是SIMT路子一组线程在硬件上按锁步方式执行但线程是独立的允许存在分支发散。AI芯片则常见两种风格SIMD风格一个大PE核内包含多个ALU向量单元一条指令控制所有单元做同样的操作。优点是指令开销小控制逻辑简单缺点是对数据排列要求很高遇到不规则访问时效率暴跌。SIMT风格每个PE可以有自己的执行流但同一组PE共享取指和调度。优点是可以容忍一定程度的负载不均衡和条件分支缺点是控制逻辑复杂指令带宽开销大片上存储消耗高。我们那两颗芯片恰好走的是两条路线。端侧那颗是SIMD风格编译器洗数据洗得很痛苦任何padding、stride不规则的算子都要通过数据搬运指令去解决云端训练那颗则更接近SIMT风格写kernel的时候像在写微型GPU内核但控制流的复杂性导致验证工作量大增。对做编译器的人来说这个选择带来的差异是巨大的SIMD架构需要强大的内存对齐分析和向量化passSIMT架构则需要更复杂的调度器来管理并发执行单元。如果架构师和编译器负责人不是从一开始就坐在一起定这条路线后面几乎一定出大坑。3.3 算子映射的典型流程以卷积为例的tiling与数据搬移我以3x3卷积为例说说在硬件上实际的映射流程。假设输入特征图是CxHxW输出是CxHxW片内SRAM只能容纳输入的一个横条带和三倍输出通道的权重切片。那么软件要做的事情大致是按输出通道切分一次处理C_tile个输出通道对应的权重切片。按空间位置切分一次处理H_tile行、W_tile列的空间范围确保输入patch和输出patch都放得下。生成DMA搬运描述符把输入patch从DDR搬到SRAM输入缓冲把权重切片搬到权重缓冲。发射计算指令让MAC阵列对输入patch执行滑窗卷积累加结果暂存在输出缓冲。搬运回写当前tile计算完后把输出缓冲的数据搬回DDR。这几个步骤每一步都有调度讲究。比如第3步要在第4步计算上一个tile的同时预取否则计算会等搬运第4步内部还要按行安排循环顺序保证每个输入行缓冲从SRAM里只读一次重复利用。我们实际调优时发现tile的行高H_tile如果取得太小行缓冲复用效率极低搬运量能占到总耗时的一半取太大又会溢出SRAM。最终是通过一个成本模型去搜索最优tile参数而不是拍脑袋定一个固定值。下面是一个极简的伪代码示意描述编译器生成一个卷积tile的计算规划# 伪代码卷积tiling调度示意 for co_tile in range(0, C_out, T_co): for h_tile in range(0, H, T_h): for w_tile in range(0, W, T_w): # 双缓冲DMA预取下一个tile的数据到SRAM dma_wait(next_buffer_ready) dma_start(next_tile_desc) # 异步搬运 swap_buffer(current, next) # 计算当前tile for ci in range(C_in): for kh in range(3): for kw in range(3): acc input_sram[ci][hkh][wkw] * weight_sram[co_ci][kh][kw] # 回写输出 dma_start(writeback_desc)实际工程里的调度器会结合硬件寄存器资源、DMA通道数量、缓冲冲突等条件把这个伪代码展开成真正的指令序列并在指令之间插入合适的等待与同步。3.4 调度器与存储分配为什么编译器写得好等于多出一个架构师如果把算子编译器拆开一半的工作在“循环变换”另一半在“存储分配”。存储分配说的是哪些数据在什么时间必须放在某块SRAM空间里什么时候可以释放、覆盖。这个问题的难度不亚于写一个寄存器分配器因为所有tile数据都存在生命周期。举一个常见的坑。编译器一开始比较简单它会按算子依次分配SRAM空间当前算子的输入、权重、输出各占一块独立空间。但模型很深时中间张量一个接一个产生如果每次分配都用全新空间那2MB的SRAM可能在第5层就爆了。所以存储分配器需要做“张量生命周期分析”让前一层释放的空间被后一层复用。我们刚开始没有做这个分析跑MobileNet时只能把tile放得特别小性能惨不忍睹。后来实现了基于存活性分析的存储复用同样一颗芯片MobileNet的端到端性能直接提升了40%。这个40%不是任何硬件改动换来的纯粹是软件优化。4. 软硬件接口驱动、Runtime与一次完整推理的调用链谈完编译器和硬件架构终于要落到连接两者的那根轴心——Runtime和驱动。这根轴最容易被忽视但它是芯片真正能被“用起来”的关键。一个企业级AI芯片项目里Runtime团队和驱动团队往往是最后才组建的但恰恰是他们决定芯片发布时是“能亮”还是“能用”。4.1 设备侧Runtime的核心职责指令队列与异步机制设备侧Runtime的职责可以概括成一句话把主机端下发的算子指令安全、高效地喂给硬件执行单元并管理所有硬件资源。这里最核心的是指令队列。硬件通常提供一组寄存器软件往里写指令描述符芯片内部的微码或硬件状态机再从队列里取指令执行。要做到安全和高效指令队列通常设计为环形缓冲也就是Ring Buffer。它的好处是不用每次下发指令都切换用户态和内核态主机侧Runtime只需维护头部和尾部指针连续写入一批指令后只需要通知一次硬件“有新指令”。硬件取完指令自然会更新尾部指针两边通过共享内存和门铃机制通信。这里有一个安全性的讲究驱动必须严格校验指令描述符里的地址偏移、长度、ID范围。我们遇到过内部测试时某个算子生成的描述符长度超出了SRAM边界直接导致硬件状态机跑飞。后来在硬件设计里增加了地址保护机制越界访问会被截断并产生中断但在此之前驱动侧的校验仍然是第一道防线。4.2 主机侧五件事一次推理在主机侧的完整准备流程从主机侧看一次典型的推理调用大约要经历五个步骤模型加载与图编译读取模型文件经过图编译器和算子编译器生成可执行的二进制指令流。显存与缓冲分配为模型权重、输入输出张量分配设备内存描述符。这个环节要注意内存对齐通常对齐到64字节或更高否则DMA效率骤降。算子指令构建把编译好的指令序列打包成指令描述符写入Ring Buffer。门铃触发写硬件寄存器通知芯片侧有新的执行批次。结果同步与回收等待推理完成事件回收输出张量处理错误状态。很多小白上手时会困惑为什么每次调用都有这么大的固定开销其实在真实的高性能推理引擎里第1步和第2步会被缓存下来图编译一次生成可执行文件持久化保存内存缓冲通过内存池复用。真正每次推理只走第3到第5步。前两部的缓存设计就是推理引擎性能能跑起来的关键之一。4.3 同步与异步事件机制怎么避免“空等”AI芯片的推理过程天然是异步的主机侧把指令交给硬件之后理论上就可以去执行下一个任务而不需要干等硬件算完。但异步也带来了复杂的同步问题。Runtime里必须有严谨的事件机制。我们用到的模型是主机侧创建一个事件对象当硬件完成某个批次的所有算子时会通过门铃或MSI中断更新这个事件的状态。推理引擎可以对这个事件执行“等待”或“轮询”。为了减少中断开销在高吞吐场景下我们通常使用轮询也就是主机侧在等待时间内会主动检查事件状态低延迟场景才使用中断唤醒。同步粒度也要仔细设计。如果每个算子都同步一次性能基本废掉如果一批算子做完才同步又可能要承担延迟变长的代价。我们最终的做法是以“一次完整推理”作为同步点但在流式多batch场景下用事件流机制让多个推理并行流水。调同步粒度是Runtime性能优化里最磨人的部分没有通用方案只能根据硬件特性和业务负载反复调。4.4 一次完整推理的任务清单与常见接口设计错误下面是我整理的执行一次端到端推理时软硬件两层各环节的任务清单。这个东西看着简单但每一个环节都有它的坑阶段软件动作硬件动作常见坑模型解析算子图融合、内存规划无动态形状导致内存规划失败算子编译循环切分、存储分配无tile参数与SRAM容量不匹配指令下发写Ring Buffer、更新门铃取指、译码描述符未对齐导致硬件异常DMA搬运生成搬运描述符、地址计算外部存储读写地址跨界、bank冲突计算执行等待搬运完成、发射计算MAC阵列流水计算同步粒度太粗导致空等结果回写等待计算完成、生成回写描述符输出缓冲写回DDR回写与下一轮预取冲突事件通知更新事件、唤醒等待任务门铃/中断中断频率过高拖垮CPU这表格里每一行我都踩过至少一次。举个印象最深的第一版驱动里门铃寄存器写操作的时序没做内存屏障CPU先写了Ring Buffer里的描述符然后才写门铃但由于编译器重排或CPU写缓冲的乱序硬件在极短的时间内读到的是未写完的描述符导致偶发性的解析失败。这个问题在本地测试十次不一定出现一次一上服务端高并发压测就频繁发生。后来加了一条wmb()内存屏障问题就消失了。这就是典型的软硬件接口时序问题纯硬件的人很难想到纯软件的人也不会往这个方向排查。5. 真实项目中踩过的坑量化误差、未知算子与布局不匹配芯片开发到了系统集成阶段各种“不期而遇”的问题就开始密集出现了。这些问题的共性是在单独的模块测试时一切都正常一旦把模型跑起来、性能测起来问题就暴露了。我想写三个交叉领域的坑它们都直接跟软硬件协同设计相关。5.1 量化误差不是算出来的是测出来的AI芯片为了效率和存储带宽普遍把权重和激活量化到INT8甚至INT4。量化感知训练在模型侧会模拟量化误差但真正到了芯片上跑问题要复杂得多不同层之间的数据分布、不同layout转换带来的截断、还有硬件累加器的位宽都会影响最终数值。我们有一版在仿真里精度损失评估是0.4%结果芯片回来后跑一个检测模型mAP直接掉了3个点。排查下来发现累加器的位宽设计是INT32但是编译器在融合两个concat分路时把中间结果先截断到INT8再送进下一层这个中间截断在仿真评估工具里没有被建模出来。后来我们在编译器中间表示里增加了“数值精度传播”的分析pass所有中间张量的精度都被显式标注任何截断操作都在图上可视化呈现才把这类问题压住。量化这件事我唯一的建议是尽早建立端到端的bit-accurate仿真链路让模型数据从图编译、算子仿真到硬件RTL仿真全程跑同一份数值而不是各模块各自为政。链条越早打通后面流的泪越少。5.2 未知算子与降级路径Fallback机制的第一个版本几乎都会炸任何AI芯片的工具链都不可能覆盖所有算子。模型里出现一个不支持的算子时需要有降级机制通常是把该算子的计算放到主机CPU上执行结果再传回设备侧。听起来很简单但有一个隐蔽的性能陷阱降级路径的数据搬运。我们早期版本对降级算子的处理是把设备侧DDR上的整个输入张量搬到主机内存CPU算完后搬回设备侧。这个方案在公司内部一个小模型上跑通时没人觉得异样直到有人试了一个类似UNet的模型里面有几个不常见的上采样算子。结果一次前向传播里这几个算子来回搬运了差不多2GB的数据推理时间从几十毫秒暴涨到几十秒。问题的根不在“不支持算子”而在降级路径没有考虑数据局部性。后面的解决办法是在图上做算子分区把连续的CPU算子归并成一个子图整块落在一个中间张量处理单元上批量执行只在子图边界做一次数据搬运。经过这么改那种混合模型的性能从几十秒降回了一百毫秒以内。这个优化现在回头看像是“显然应该这样做”但第一版没人想到原因就是大家默认降级是临时保底方案没把它当成一个正式的软件路径来设计。5.3 布局不匹配NCHW、NHWC与内部格式的三角关系模型框架里常用的张量布局是NCHW或NHWC但AI芯片内部为了MAC阵列的访存连续性往往希望数据是以某种定制化的channel-block布局存放的。编译器在图层面上要根据算子的实际运行位置插入必要的“布局转换”算子。布局转换本身也是个算子也要占用算力和带宽。我们有一版工具链的布局转换实现是基于DMA逐元素拷贝的转换一个4D大张量的耗时甚至比真正的卷积算子还高。后来算法同事提了一个建议尽可能把布局转换融合进卷积算子的tiling过程中比如在DMA搬运输入patch时直接在地址映射阶段完成channel重排。这个功能需要DMA引擎支持“地址重映射表”属于软硬件协同设计的一个典型案例——没有硬件级的重映射支持这个融合就做不到只能靠多搬几次数据来硬扛。现在很多芯片在DMA设计阶段就会加上各种“数据重排模式”比如按固定间隔跳变、按通道翻转、按块交错。我建议做架构的朋友一定要重视DMA的地址变换能力它虽然不直接贡献TOPS但对真实模型性能的影响远大于多算一两个TOPS。5.4 理论带宽的两成从性能计数器找瓶颈最后聊一个通用的排查方法。很多性能问题看起来毫无头绪但几乎所有AI芯片都会提供一组性能计数器指令发射数、计算周期数、DMA读写字节数、等待周期数、SRAM读写冲突次数等等。性能调优的第一步不是猜而是读计数器。我们有次跑一个Transformer类的模型平均利用率只有35%而且无论怎么调tile参数都提不上去。后来看了计数器发现两个数据一个是DMA通道的利用率极低每一次搬运的数据量都很小另一个是权重SRAM的bank冲突次数高得离谱。这两条线一交叉就明白了tile切得太碎每次搬运头开销占比太大同时权重是按通道连续存放的而计算阵列访问同一bank的频率过高。解决方案是把权重在预编译阶段做一次“channel交错重排”让两个相邻输出通道的权重分布到不同bank。改完之后利用率直接到68%。硬件性能计数器是芯片里最值得投资的调试设施但它也要求在软硬件接口文档里定义清楚什么事件、在什么条件下计数、如何清零。如果没有这一层很多疑难问题根本没有办法定位。6. 从软硬件设计的角度看AI芯片的未来方向芯片行业变化很快但软硬件协同设计这个主题只会越来越重要。我在这里说说我在实际项目里感受到的、正在发生的一些方向性变化。6.1 DSA的边界为什么推理和训练很难用同一颗芯片DSA意味着硬件是为特定计算模式定制的。推理模型常见的是小batch、低延迟、权重固定硬件可以针对稀疏性、权重复用做深度优化训练则是大batch、高吞吐、需要反向传播和梯度更新内存访问模式完全不同。把这两者硬塞进同一个架构往往是两头不讨好。我们内部讨论过能不能做一颗统一的训练推理芯片结论是可以但效率很难同时极致。后来业界很多厂商选择的路线也是推出一款训练芯片和一款推理芯片共用同一套工具链和Runtime让上层用户无感。这个策略给我们做软硬件的人带来的启示是工具链的迁移成本比芯片本身的成本更值得重视。只要你软件接口设计得足够统一用户从推理芯片迁移到训练芯片的代价就能大幅降低。6.2 可重构的边界灵活性不是免费的最终由编译器来买单可重构架构比如可以在编译阶段配置计算单元互联、存储分区的芯片听起来很美好让硬件的灵活性适应不同模型。但代价是“配置”这个动作本身要花时间而且配置完的硬件形态它的编译映射问题远比固定架构复杂。我们在调查这类方案时最大的感受是任何一个硬件的“可配置旋钮”都会给编译器增加一个优化维度。旋钮越多编译搜索空间越大搜索空间一大要么编译时间爆炸要么靠启发式规则草草选择一个次优配置。可重构架构要落地核心是先保证编译器能够高效地探明配置空间否则硬件灵活性就是个只能供演示的摆设。6.3 从chiplet到系统级协同软硬件边界还在往后移先进封装和chiplet技术让AI芯片的形态进一步分化可能存在一个计算die、一个SRAM die、一个IO die组合起来的系统。这意味着软硬件设计的边界不再只是芯片内部而可能延伸到整个多die系统数据在die之间的传输带宽、片上互联的拥塞管理、跨die的内存一致性问题都要进入编译器和Runtime的考虑范围。还有一个趋势是“算法与芯片的深度耦合”。随着大模型普及稀疏注意力、混合专家等结构开始进入主流未来芯片可能在架构里就会内置对某些结构化稀疏的支持。而对这些结构的编译优化又会成为工具链的亮点。可以说接下来几年AI芯片的竞争会更明显地表现为软硬件联合创新的竞争谁的工具链把硬件能力释放得更充分谁的方案在真实负载上跑得更快谁就赢。最后说一点我个人的体感。这个行业里硬件团队和软件团队之间的沟通成本高得惊人。最初几个月我们为了一个同步语义双方开会吵了三天最后写进接口文档才算了结。回过头看AI芯片的软硬件设计最难的不是某一个具体的技术点而是让两个知识体系完全不同的人能够在同一个抽象层次上对齐概念、把问题描述清楚。如果你正准备进入这个领域我的建议是先别急着看那些高深的架构论文先把指令集手册、tile调度流程和Runtime的同步模型吃透。这三样东西理清楚了你也就站在了AI芯片世界里最关键的十字路口上。
