企业官网建设流程全解析

干了这么多年AI芯片，我最大的感触是：芯片设计圈里有一个非常尴尬的普遍现象——PPT上标的xx TOPS很高端，实际把模型一跑，性能连一半都摸不到。问题很少出在某个模块不够强，而是出在软硬件各自精彩，合在一起却处处打架。这次系列第六篇，就想把AI芯片软硬件设计中那些决定“纸面算力能否变成真实性能”的关键环节，掰开揉碎讲一遍。

这篇文章适合正在做AI芯片架构、编译器、算子库或者底层系统软件的人，也适合刚入行、想理解软硬件到底怎么协同的工程师。我会从负载画像、硬件选型、软件栈设计到最后的调试调优，按一条完整的项目链路来聊，其中每一个坑都是我们真实踩过的。

1. 整体设计思路：从应用反推架构，别先造核再找场景

1.1 先画负载画像，再定计算粒度

很多团队做AI芯片，习惯是先定一个“通用AI加速器”的概念，比如设计一个8x8的脉动阵列，然后到处找应用来跑。这个顺序反了。正确做法是先拿真实负载做画像，再决定计算粒度、存储大小和数据通路。

负载画像不是简单看模型类型，而是要统计五组数据：算子类别占比、各类算子的FLOPs分布、访存字节数、并行度、数据类型。拿经典的ResNet50和现在主流的大模型对比，差异非常明显。ResNet50里卷积层占了90%以上的计算量，数据复用度高，适合用大块脉动阵列；但到了Transformer，LayerNorm、Softmax、Gelu这类“小算子”虽然FLOPs占比不高，访存占比却很高，如果你只优化GEMM，整体加速比会被这些算子拖死。

我们做过一次实测：一个轻量级Transformer模型，如果只针对矩阵乘法优化，理论上可以把矩阵乘法加速20倍，但端到端只加速了3倍，原因就是非矩阵算子的耗时占了将近70%。所以负载画像的结论直接影响架构方向，比如你要不要为RMSNorm做一个专门的归一化单元，要不要支持高效的向量指令，这些都在架构定义阶段就该定下来。

画负载画像的具体操作也不难。先用Python脚本把ONNX或者编译后的IR模型跑一遍，统计每个节点的输入输出shape和FLOPs，再用一个简单的内存访问模型估算访存量。下面这个表是我们常用的统计格式，字段别嫌多，后期每一条都有用：

最后必须把计算强度分布画成直方图。软硬件平衡点设计，就藏在这张图的“中位数”和“长尾”里。

1.2 软硬件边界：指令集就是合同

指令集是软硬件之间最核心的合同。硬件团队看到的是微架构，软件团队看到的是伪指令，两边靠这个接口对齐。但AI芯片的指令集设计有一个容易踩的误区：想做得太灵活，结果谁都不舒服。

我们第一版自定义指令集时，为了让编译器容易生成代码，加了非常多的寻址模式和条件执行，觉得这是“通用性”。结果硬件流水线关键路径被各种复杂逻辑拖累，时序只能跑到设计频率的70%；编译器也苦不堪言，指令选择阶段的状态空间爆炸，光是优化一条向量load就要穷举几十种组合。

后来痛定思痛，把指令集砍到不到20条核心指令：标量load/store、向量load/store、显式DMA搬运、矩阵乘累加指令、向量算术指令、同步指令。效果立竿见影。硬件逻辑简单了，编译器做模式匹配也清晰了。这里我想强调一句：对AI芯片来说，“少而精准”的指令集，远远好过“大而全”。

真正的软硬件协同，是把指令集设计成“编译器的高层IR可以直接对应”的形态。比如矩阵乘，我们只提供两种指令：一种是整块矩阵乘累加（A矩阵在片上SRAM，B矩阵在另一个SRAM，输出到累加器），另一种是带移位和广播的灵活模式。这样Kernel开发时就只做图匹配，不用去拼指令序列。

1.3 算力与带宽的平衡

纸面算力是最唬人的参数。很多芯片算力标得很高，但真实性能受片上带宽、DDR带宽、存储层级共同制约。Roofline模型是我每次设计方案必用的工具。

举个例子。假设某芯片INT8峰值算力是100TOPS，片上SRAM到计算阵列的聚合带宽是50TB/s，那么这个片上平衡点是2K FLOPs/Byte。如果一个卷积层计算强度是1K FLOPs/Byte，它就只能落到带宽受限区，实际最多发挥50TOPS。如果计算强度是4K FLOPs/Byte，才能勉强进入计算受限区。而真实的模型里，很多算子的计算强度就是在几十到几百之间，尤其那些elementwise算子，压根就跑不上去。

所以架构设计时，我一般会先算一个“目标负载覆盖度”：把上一步画像里所有算子的计算强度分布画出来，再画一条Roofline曲线，看哪些算子落在计算受限区，哪些落在带宽受限区。如果绝大多数算子都在带宽受限区，那优先加的就不是MAC阵列，而是片上SRAM带宽和bank数。这个决策顺序非常关键，因为它直接决定芯片面积花在哪里。

1.4 从模型到硬件的需求拆解清单

最后把负载画像整理成一份可执行的需求清单，通常包含这几项：

• 需要支持的算子集合：必须覆盖目标模型，还要预判未来半年的新算子形态
• 数据类型：FP32/FP16/BF16/INT8/INT4，以及是否需要混合精度
• 最小可支持的模型规模：决定片上SRAM和外部DDR容量的下限
• 端到端目标延迟：决定整个软件栈的优化预算和硬件流水线深度
• 峰值算力与持续算力之比：越接近1，说明软硬件协同做得越好

这份清单是后面所有设计评审的依据，也是软硬件两个团队对齐的“宪法”。如果没有这份东西，后期一定会出现“软件怪硬件不支持，硬件怪软件不优化”的扯皮局面。

2. 硬件侧核心模块：计算阵列、存储与数值格式

2.1 计算阵列的选择：脉动阵列、SIMD还是可重构

硬件团队最常见的争论就是计算阵列到底选什么风格。脉动阵列、SIMD、可重构阵列各有拥趸，但放到软硬件协同的视角里，判断标准很简单：编译器能不能高效地把算子映射上去。

脉动阵列的优势是数据复用极强，卷积场景下能效比很高。缺点是灵活性差，遇到矩阵转置、不规则slice或者动态shape就会非常痛苦。SIMD引擎灵活，编程模型接近CPU，编译器好写，但能效比通常比脉动阵列低一个档次。可重构阵列在我看来是个中间的妥协，但复杂的互联网络会吃掉大量面积，而且编译器需要做更细粒度的布局布线，难度陡增。

我们的实际选择是“主核SIMD + 专用矩阵加速单元”的混合方案。主核数量在8到16个，每个主核带一条宽SIMD向量流水线，负责处理非矩阵算子；矩阵加速单元做成16x16的脉动阵列，专注GEMM和Conv。软件栈先做算子分类，把算子图谱拆成两类，分别调度到不同的执行单元上，中间通过共享SRAM交互。这个方案不是最极致的能效，但软硬件配合的顺畅度最高，开发周期也最可控。

你在硬件设计时还要注意一个细节：脉动阵列的输入数据广播方式。有的设计是把数据从左侧广播进每个PE，有的设计是数据和权重都从两个方向流入。选择时会直接影响编译器生成DMA指令的复杂度，以及你能不能在乘法展开的同时做便宜的广播。我们后期为了支持大kernel而改过数据流方向，改了之后编译器的kernel template几乎重写了一遍，这个代价在架构阶段就该考虑。

2.2 片上存储与数据搬运

存储层级的设计往往决定了AI芯片的真实性能。很多新团队堆了一大块SRAM就觉得万事大吉，但其实更关键的是“这块SRAM能以多快的速率喂给计算阵列”。

片上SRAM需要分成多bank，且bank数量要和计算阵列的并行度匹配。比如16个PE，每个PE每周期要读8字节权重和8字节输入，那么SRAM至少需要提供128字节/周期的带宽。如果SRAM只有一个64字节的接口，哪怕容量再大，计算阵列也得空转。

地址交错映射也很重要。一个常见坑是SRAM只有4个bank，但计算单元的访存粒度是64字节，同一行数据很容易落在同一个bank，导致bank conflict。我们后来改成8bank、地址按128字节交错，访存吞吐立刻提高了近一倍。修改成本其实不高，无非是地址解码逻辑多了一点，收益却非常可观。

数据搬运方面，DMA不是“发出请求然后等完成”这么简单，必须支持多级预取和descriptor chain。写GEMV这种算子时,尤其依赖一种double buffer的办法：当前block正在被计算阵列处理时，DMA已经在搬运下一个block的数据。这样访存延迟被完全隐藏。硬件上需要至少两个ping-pong buffer，软件上则要在SRAM里做双份缓存区的调度。我们曾经在某版芯片里只做了一个DMA channel，结果一个kernel中途切换数据源时，计算流水线停等了200多个周期，直接导致端到端性能下降了20%。后来加了独立的load/store通道才解决。

2.3 数值精度与累加策略

数值格式的选择和软硬件的绑定程度，可能比你想的还要深。推理平台的现状是INT8占据主流，FP16/BF16用于大模型和高精度场景，FP32基本只在CPU fallback。你的硬件支持哪些格式，直接决定编译器能否做子图级别的量化调度。

INT8推理要特别注意scale的处理方式。per-tensor scale实现简单，但精度不如per-channel。硬件设计上，你需要为每个通道或者每组通道准备scale/bias的寄存器数组，并且支持在DMA搬运后做一次“反量化+加偏置”的融合。否则软件只能把量化操作拆成额外kernel，访存开销会吃掉所有性能。

累加器宽度是最容易被低估的设计参数。矩阵乘法的partial sum动辄几十万次累加，如果用FP16做累加，精度会崩到没法看；用FP32累加，面积和功耗只增加不到20%，但数值稳定性提升巨大。我们内部有一条铁律：任何矩阵单元的输出累加器至少比输入精度宽一倍，INT8输入配INT32累加，FP16/BF16输入配FP32累加。这条规矩看着简单，却救了我们不止一次。

另外，硬件必须支持饱和截断而不是溢出回绕。INT8乘法累加之后，结果可能在int32范围内，但转回int8输出时，如果超过[-128,127]就应当截断到边界值，而不是像C语言那样轮回。编译器生成的kernel里，也要在存储输出前插入一次饱和处理指令。这个功能如果不能硬件原生提供，软件就会多出好几条比较分支指令，拉低性能。

2.4 面积、功耗和时序的三角博弈

每个硬件模块的选择，最后都要在面积、功耗、时序上做妥协。问题在于这些妥协往往不只是硬件内部的事，它会直接影响软件能生成什么样的调度。

拿关键路径来说。矩阵累加链如果做成全组合逻辑，周期时间会很长，频率上不去。为了跑到600MHz，我们不得不在累加器之间插入两级流水线寄存器。硬件频率稳定了，但编译器需要知道：一个矩阵指令的结果，要等多少个周期才能被后续指令使用。这个latency数字必须写进性能模型和编译器的调度算法里。如果硬件团队不把这组数字维护好，软件就只能按悲观值等待，浪费性能。

面积也是同样道理。为了给计算阵列提供足够带宽，我们增加bank数量、加宽DMA总线，面积和功耗相应上涨。这时就要用“面积换性能的收益”来评估。比如增加一组独立小SRAM做权重缓存，可能多占3%面积，但能让卷积权重搬运带宽翻倍，只要对目标负载确实有效就值得。最怕的是全凭感觉加东西，流片后发现有大量资源闲置，那才是最大的浪费。

2.5 给软件留的“后门”：调试接口和可观测性

很多硬件设计团队只顾功能正确，完全不考虑软件的调试需求。结果一上板性能不对，软件工程师只能对着波形图硬猜，效率极低。我建议每位架构师在定义寄存器列表时，额外留三类后门：

• 性能计数器：每个执行单元、每个DMA channel、每个SRAM port的使用率、等待周期、冲突次数
• 流水线状态寄存器：可以实时读出所有执行单元当前在做什么、在等待谁
• 手动触发模式：允许软件把计算单元和DMA停到某个周期边界，便于前后状态对齐

这三类后门不会增加多少面积，但能救活你的调试流程。后面讲到的性能优化案例，如果没有这些计数器，根本不可能把问题定位到“DMA读取等待过长”这种层级。

3. 软件栈：编译器、算子库与运行时如何补齐硬件短板

3.1 图优化与算子融合的作用

硬件定了以后，软件栈的首要任务是“补短板”。其中收益最大、也最需要和硬件特性绑定的，就是图优化和算子融合。

融合的本质是减少中间结果落回DDR的次数。传统框架里，一个Conv+BN+ReLU会被拆成三个kernel，每个kernel都读一遍写一遍DDR。如果芯片的片上SRAM能装下完整的中间feature map，编译器就可以把三者融合成一个kernel：先从DDR读入输入，依次做卷积、批量归一化、ReLU，最后只把最终结果写回DDR。访存总量直接减少约三分之二，端到端性能可以提升30%到50%。

Transformer模型也有类似的融合模式。QKV三个投影本来是三个独立的GEMM，但它们的输入是同一个张量X，编译器可以先把三个权重矩阵拼成一个大的 [3H, N] 矩阵，做一次更大的GEMM，再把输出切回三份。这样不仅减少了kernel启动开销，还让矩阵乘法在大维度上更高效。类似Gelu可以融合到上一个GEMM的输出Epilogue阶段，LayerNorm也可以和前面的残差加融合。

做一个好用的融合引擎，关键是硬件必须提供相应的支持，比如在DMA里可以做“load数据时同时加一个偏置”的融合运算，或者在矩阵乘法的输出端挂一个epilogue单元，用来做激活、缩放、截断。没有这些硬件配合，图优化只能做到“少跑几次kernel”，做不了真正的数据在片上流转。

3.2 算子映射策略

每个算子怎么映射到多核上，是编译器里最费心思的部分。目标只有一个：在负载均衡、数据通信量和流水线利用率之间找到最优解。

GEMM的切分比较成熟，通常是M维切给不同的核，K维切给同一个核的时间片，N维切给向量单元。但像Softmax这种算子，它的计算强度极低，读一遍数据做几次算术就结束，片上的访存带宽才是瓶颈。所以不要用多个核去算同一个Softmax，反而会让多个核同时访问同一块SRAM，造成带宽争抢。更合理的做法是把数据按batch或者head维切开，每个核处理自己的部分，互不干扰。

Transformer里还有一个经常被忽视的融合点：KV cache的更新。自回归解码时，每次生成一个新token，需要把新的KV向量追加到已有的KV cache中。如果每步都复制整个cache，内存带宽会爆掉。我们做过一次优化，让编译器把KV cache切分成固定大小的tile，DMA只更新tile内新增部分，其余部分仍然留在片上。这相当于在算子映射里加了一个数据生命周期管理，效果立竿见影。

算子映射一定会在runtime里引入同步点。尤其当多个算子在多核上并行执行并有依赖关系时，编译器必须显式插入barrier指令。这些同步点的开销很大，能合并就合并。我们的经验是，最好在编译阶段做一次“同步点合并优化”，把本来需要三次barrier的算子流水，压缩到只做一次全局同步，其余用局部依赖信号控制。

3.3 内存布局与访存优化

算子层面经常被优化的，是数据在SRAM和DDR中的排布方式。同样的算子和硬件，数据排布不同，性能差距能到数倍。

拿卷积举例。NCHW布局下，相同空间位置的通道数据在内存里是不连续的，SIMD向量化加载很困难；NHWC布局则让同一像素的多个通道连续存放，刚好匹配向量单元的宽度。Transformer里的GEMM也类似，B矩阵的K维要保证连续，才能让DMA按最大突发长度搬运。编译器需要有自动的layout转换能力，能在算子之间插入一个layout转换，或者通过融合避免转换。

实际写Kernel时，tile大小的计算必须精确。假设片上SRAM可用512KB，数据类型为INT8，我们想算一个MxN的矩阵乘，K维作为切分维度tileK。每个A tile大小 = tileM * tileK * 1，B tile = tileK * tileN * 1，输出累加器 = tileM * tileN * 4（INT32累加）。如果选tileM=128，tileN=128，tileK=64，那么A占64KB，B占64KB，累加器占64KB，总计192KB，在512KB内完全放得下。如果贪心选tileM=256，tileN=256，tileK=64，累加器就要256KB，加上A和B共128KB，再加上其他临时数据，SRAM就紧张了。编译器要能自动搜索这个tile参数，并基于实际绕开bank冲突，而不是用固定模板。

DMA指令的地址对齐也很关键。我们要求所有DMA搬运的起始地址按128字节对齐，长度按64字节对齐，否则硬件会退化成多个小突发，效率直接减半。编译器在分配SRAM地址时，也必须按这个对齐规则来做。这些细节看起来不起眼，但会让性能模型里的“有效带宽”和“理论带宽”产生巨大差异。

3.4 性能profiling不能只看算子时间

很多人拿到性能数据后只看“这个算子耗时多少”，然后去优化最耗时的算子，却忽略了一个问题：算子耗时里有多少是真正在计算，有多少是在等待。

我们经常见到的场景是：某个GEMM算子的统计时间是500us，但里面真正计算只有200us，剩下300us都在等前一个算子的数据过来。如果只看时间表，你可能会觉得GEMM本身优化不够，其实问题在数据依赖和DMA调度上。所以软件栈必须提供一份“周期级时间线”，把计算周期、访存等待周期、同步等待周期、流水线气泡全部拆开。

性能计数器在硬件里的作用此刻就体现出来了。我们写过一个分析脚本，每1ms采样一次所有计算单元的利用率，然后画成热力图。有一次调试，热力图显示在某些时间窗口内，8个核有6个都在等DMA，计算单元只有不到20%的利用率。顺着这个方向查，发现DMA descriptor queue深度太浅，编译器需要频繁停算来提交新的搬运任务。后来把排队深度从4加到16，利用率直接涨到80%。

3.5 运行时runtime：资源调度与动态shape

编译器负责把算子变kernel，runtime则负责把所有kernel按依赖关系调度起来，还要处理动态shape、内存池、模型生命周期。

动态shape是AI芯片软硬件设计里最头大的问题之一。Transformer推理中的batch size、序列长度经常变化，很多硬件加速器只支持静态shape，编译一次只能跑固定输入。要做动态支持，最简单粗暴的“办法”是编译多个静态shape的binary，运行时按shape选择。但如果序列长度变化很细，这个方案会占满内存。我们用的做法是runtime里加一个轻量级shape推导工具，遇到新shape时，在预先编译好的模板基础上，快速调整tile参数并重编译。这个流程要控制在几十毫秒内，用户体感才不明显。

Runtime还要负责多模型并发。两个模型同时跑，怎么分配硬件资源？实践中可以把芯片的计算单元划分为多个partition，每个partition独占一部分核和SRAM，runtime按模型的优先级和算力需求动态分配。这样的资源隔离比时间片共享更稳，因为不会出现一个模型的DMA把另一个模型的缓存全部冲掉。

4. 从仿真到落地：常见坑和调试技巧

4.1 仿真和性能模型的误差，别等流片后才暴露

很多团队早期只做功能仿真，后面靠“估算”写PPT，直到流片回来才发现性能完全不是预期。我特别建议从项目第一天就建立一个cycle approximate的架构级性能模型，用真实的指令流和访存trace驱动。

性能模型的效果有多重要？我们做某代芯片时，软件团队在模型上跑一个BERT模型，发现有一个算子需要同时用到4个DMA channel才不会因为数据搬不完而停顿。硬件团队之前只规划了2个channel，幸好性能模型提前暴露了，改设计还来得及。如果没有这个模型，流片后再发现问题，那代价就是以千万元计了。

性能模型的精度最好控制在15%以内，并且随着RTL逐步冻结，持续校准。校准方法很土但很有效：把RTL仿真的波形统计出实际周期数，和性能模型的输出逐项对比，差在哪就修哪。这样到流片时，你对最终性能的信心会远超那些靠Excel拍脑袋的团队。

4.2 软硬件调试不匹配问题：一条trace解决

软硬件协同调试最大的痛点，是两边对同一事件的认知不一致。软件说“我发了一个128字节连续读取”，硬件却因为地址没对齐，实际发出了2个64字节的读事务。这种问题靠肉眼对log真的会崩溃。

我们的解决方式，是做一个统一的“访存trace”格式，在仿真环境里自动记录每一次DMA指令的地址、长度、起始时间、结束时间，并让软件编译生成的log里也包含同样信息。调试时直接按kernel id过滤，看两边对不对得上。这套流程帮助我们抓到了好几个低级但隐蔽的bug，比如小端和大端处理不一致、DMA描述符里长度字段的位宽填错导致搬运数据截断。

调试接口里的状态寄存器也非常有用。某个DMA卡住时，读一下状态寄存器，能立刻看到它在等待哪个channel，哪个地址的response没回来。不用对着波形图一层层翻信号，效率提高好几个数量级。

4.3 典型坑：量化精度和溢出

INT8量化最坑的，不是模型掉点，而是掉点之后你根本不知道是哪里出的问题。我们曾有个模型在校准集上精度正常，换到真实数据后突然掉到没法用。最后定位到是某一层的激活值出现了一个极端大值，per-tensor的scale无法覆盖，导致饱和截断后大量信息丢失。

解决方案是per-channel量化，同时硬件上保证每个通道的scale是独立加载的。编译器生成的kernel需要在每个输出通道的epilogue里乘上对应scale，并做一次饱和处理。如果你的硬件只有per-tensor scale，软件就得把输出拆出来单独做逐通道运算，访存开销非常大。

FP16也有类似的坑。矩阵乘法输入如果超过65504，直接变成inf。我们调一个超大语言模型时，某层LayerNorm的输出在fp16下居然出现了几千的值，正常情况不至于，后来发现是前面的残差连接在长序列下累积出了一个很大的激活值。给硬件加一个clip单元，或者让编译器在关键节点插入饱和截断指令，都能避免。

还有一种数值问题是累加溢出。INT32累加器并非无上限，如果tileK太大，比如tileK=8192，小的乘法结果累加也可能超INT32。这时编译器要自动把循环分裂成多个部分累加，定期把INT32结果转成INT8写回，再从新累加。这些逻辑如果只靠手写kernel，很容易漏，最好在编译器后端自动处理。

4.4 性能调优实录：一个Transformer解码器的优化

用一个真实的例子来说明完整的调优过程。我们部署一个7B规模的Transformer解码器，第一版端到端性能只有理论峰值的30%。对这个结果，我们没有第一时间骂硬件，而是用时间线分析工具把耗时拆开：

• 矩阵乘法相关：52%
• KV cache更新：20%
• Softmax和归一化：15%
• Kernel切换开销：8%
• 其他同步等待：5%

第一刀优化是图融合。把QKV投影合并成一个大的GEMM，然后在一个kernel里完成缩放、加bias、截断。这个优化让矩阵乘法相关耗时下降了接近20%。第二刀是优化KV cache布局。把KV cache按层、按head切成固定块，并且把新增token的更新用DMA做增量搬运，不再整个重读。KV cache更新的耗时从20%降到了8%。第三刀是并行切分。解码时序列维度是1，batch很小，单纯多核并行GEMM并行度不够，但可以把多个独立head的GEMM并行分配到不同核上。这样多核利用率提高，同步点也减少了。

三轮优化后，端到端性能从30%提升到了75%。剩下25%的空隙，主要来自片上网络冲突和部分低效算子。我们没有继续硬啃，而是先上线，让实际场景的数据回来再针对性优化。这个经验是：性能优化要做到“每一步都有数据支撑”，不要一上来就盲目重写kernel。

4.5 顺手好用的工具和习惯

最后分享几个我们团队内部效率很高的工具和习惯，不涉及具体商业软件，都是自己写脚本就能搞定的。

第一，做一个“编译日志可视化”工具。把编译器生成的kernel序列、每段kernel的预期周期、DMA等待时间、同步点全部输出成HTML时间线。这样你在评审性能时，不用口头争“应该是谁的问题”，直接看时间线，问题一目了然。

第二，建立“回归性能基线”。每次硬件小版本或者编译器提交，都自动跑一批代表性模型，记录端到端性能和算子级耗时，生成对比报告。有基线在，谁把性能优化了、谁把它弄坏了，一目了然。这个习惯也不需要高深技术，一个Python脚本加一个定时任务就够。

第三，软硬件两个团队每两周做一次联合性能评审。不是互相汇报进度，而是拿最新的模型benchmark数据，一起看性能时间线，一起归因。很多大问题都是在这种非正式讨论里提前暴雷的，等正式评审时反而都是小事。

结尾

做了这么多AI芯片项目，我个人体会是，软硬件设计从来没有“一锤定音”的时刻，它更像一个持续迭代的闭环：负载画像推动架构定义，架构能力约束编译器策略，编译器优化又反过来暴露硬件的短板，硬件再在下一次迭代中补齐。坚持这个闭环的团队，不一定能把每个指标都做到极致，但至少不会出现那种“芯片很先进，模型却跑不快”的尴尬。

如果你正在规划一款新的AI芯片，或者给现有芯片做软件栈，我建议你把至少30%的精力放在软硬件接口和性能模型上。别以为只是花点时间做做文档，实际上，这个接口的数据结构、同步语义、调试后门，才是决定这颗芯片最后能不能被用户接受的核心。上面这些坑，我们基本都踩过，写出来就是希望你能少走几步弯路。