企业官网建设流程全解析

1. 从一张白纸开始聊“造AI芯片”这件事

“新造一个AI芯片”这个念头，最早是在一次跟朋友吃饭时冒出来的。当时桌上几个人在聊大模型训练成本，有人随口说了一句“要是能自己搞一颗专门跑推理的芯片，是不是就不用看别人脸色了”。这句话本身没什么，但回家路上我一直在想：如果真从零开始设计一颗AI芯片，到底要面对哪些问题？是堆算力就行，还是说架构、内存、软件栈这些东西一个都不能少？

先泼一盆冷水。造AI芯片不是画一张架构图、跑几个仿真、流片回来就能用的事。它更像是在一个已经被巨头把持的赛道上，找一条别人没走通或者不愿意走的路。你面对的不仅是技术问题，还有生态问题、成本问题、时间窗口问题。一颗7nm芯片流片费用动辄几千万美元，5nm更是上亿，这还不算IP授权、EDA工具、验证团队、软件团队的开销。所以“新造一个AI芯片”这个命题，首先要想清楚：你造给谁用？跑什么模型？替代谁？还是说开辟一个全新的场景？

我写这篇东西，不是要教谁去流片，那也不现实。我想做的是把“造AI芯片”这件事拆开，从需求定义、架构选型、内存墙、软件栈、验证流片这几个维度，把我自己踩过的、看到的、推演过的东西摊开来聊。适合对芯片设计有兴趣的工程师、正在做AI加速器选型的系统架构师，以及单纯好奇“芯片到底难在哪”的技术爱好者。读完你至少能明白，为什么有些AI芯片纸面参数很好看，实际跑起来却拉胯；为什么有些公司烧了几十亿最后连个水花都没有。

2. 先想清楚这颗芯片到底要跑什么

2.1 训练芯片和推理芯片是两码事

很多人一上来就说“我要做AI芯片”，但训练和推理对芯片的要求几乎相反。训练需要高精度（FP32、BF16甚至FP64）、大内存带宽、片间互联要快、编程模型要灵活，因为训练过程中梯度更新、优化器状态、激活值都要存，对显存容量和带宽的胃口是无底洞。推理则更看重低延迟、高吞吐、低功耗，精度可以降到INT8、INT4甚至更低，很多时候还要做算子融合、量化、剪枝。

我见过一个团队，一开始想做通用AI芯片，训练推理通吃。结果架构设计时为了兼顾训练的大内存需求，把片上SRAM做到很大，功耗和面积直接爆炸；推理场景下这些SRAM又用不满，成本降不下来。最后两头不讨好。所以第一步不是画架构，是明确场景。你是要做云端训练卡，还是边缘推理盒子，还是手机端NPU？这三个场景对应的芯片规格差异巨大。

2.2 模型形态决定硬件形态

另一个容易被忽略的点是：你打算支持什么模型。Transformer和CNN对硬件的需求完全不同。CNN有大量卷积操作，数据复用率高，适合用脉动阵列做矩阵乘；Transformer的核心是注意力机制，里面有大量矩阵乘和Softmax，还有KV Cache这种动态增长的内存需求。如果你要支持MoE（混合专家）模型，那对片上网络和内存带宽的要求又上一个台阶，因为专家路由会导致不规则的访存模式。

我在推演阶段做过一个粗略的算力需求估算。假设你要跑一个70亿参数的模型，INT8量化后权重占7GB左右，每生成一个token需要读取全部权重一次。如果目标吞吐是每秒20个token，那内存带宽至少需要7GB×20=140GB/s。这还没算KV Cache和激活值的开销。如果你把目标定在每秒100个token，带宽需求直接飙到700GB/s以上。这个数字一出来，你就知道HBM是跑不掉的，GDDR6都够呛。所以模型形态不是软件团队的事，它在最底层决定了你的内存子系统设计。

2.3 算力数字背后的陷阱

规格书上写“256 TOPS INT8”看起来很唬人，但实际利用率可能只有20%到30%。为什么？因为算力峰值是在理想条件下测出来的：所有MAC单元都在工作，数据供给不断流，没有调度开销。真实模型里，算子之间的依赖、内存访问的延迟、控制流的跳转都会让算力利用率打折扣。

我习惯用一个简单的公式来估算实际有效算力：有效算力 = 峰值算力 × 数据复用率 × 调度效率 × 内存供给满足率。数据复用率取决于你的缓存设计，调度效率取决于编译器和运行时，内存供给满足率取决于带宽和延迟。这四个乘数里任何一个掉到0.5以下，最终有效算力就只剩峰值的6%左右。所以不要被TOPS数字迷惑，要问清楚在跑具体模型时的端到端吞吐是多少。

3. 架构选型：脉动阵列、存内计算还是可重构

3.1 脉动阵列的甜区和边界

脉动阵列（Systolic Array）是TPU带火的结构，核心思想是让数据在PE阵列中流动，每个PE做乘加后把结果传给下一个PE，减少内存访问。它的甜区是规则的大矩阵乘，比如CNN里的卷积展开成矩阵乘，或者Transformer里的全连接层。数据复用率高，能效比好。

但脉动阵列的边界也很明显。遇到不规则计算，比如稀疏矩阵、动态形状的注意力、或者控制流复杂的算子，脉动阵列的利用率会骤降。因为它的数据流是静态调度的，一旦形状变化，阵列边缘的PE就闲置了。我见过一个设计，跑BERT的时候利用率还有60%，跑GPT这类自回归模型时因为序列长度动态变化，利用率掉到25%以下。所以如果你要做通用性强的AI芯片，纯脉动阵列不够，需要配合向量单元或者可重构数据通路。

3.2 存内计算：听起来很美，工程上很难

存内计算（Compute-in-Memory）这两年很热，原理是在SRAM或RRAM阵列里直接做乘加，省去数据在内存和计算单元之间搬运的功耗。理论上能效比可以做到传统架构的10倍以上。但工程上的坑非常多。

首先是精度问题。模拟存内计算受工艺偏差、温度漂移、噪声影响很大，做INT8还行，做FP16几乎不可能。其次是外围电路面积。存内计算阵列需要ADC/DAC做模拟数字转换，这些电路的面积和功耗可能比省下来的还多。再就是可编程性差，一旦流片，支持的算子就固定了，没法像GPU那样灵活编程。我的判断是，存内计算适合特定场景的固定算子加速，比如always-on的语音唤醒、传感器信号处理，但要做通用AI推理，目前还早。

3.3 可重构架构的取舍

可重构架构试图在灵活性和能效之间找平衡。粗粒度可重构阵列（CGRA）让PE之间的连接可以动态配置，支持不同的数据流模式。好处是能适应多种算子，坏处是配置开销和编译复杂度高。每次切换算子都要重新配置互连，这个开销在细粒度算子切换时很致命。

我个人的倾向是：如果你的目标模型集合比较固定，比如就支持那么三五种主流模型，那针对性地设计数据通路比追求通用可重构更划算。如果你要做的是一个平台型芯片，要支持未来未知的模型，那可重构是不得不走的路，但要做好编译器极其复杂的心理准备。编译器团队的人数可能是硬件团队的两倍。

4. 内存墙：AI芯片真正的瓶颈

4.1 为什么算力上去了，性能没上去

AI芯片发展到现在，算力已经不是最稀缺的资源了。7nm工艺下，每平方毫米能塞进去的MAC单元越来越多，但内存带宽的增长速度远远跟不上。这就是所谓的“内存墙”。一个典型的矩阵乘，计算量是N³，数据量是N²，计算密度随N增长而提高。但实际模型里N往往不大，比如注意力头的维度通常是64或128，这时候数据搬运的开销就压过了计算。

我做过一个测算：在128×128的矩阵乘里，如果片上缓存能存下整个矩阵，那计算和访存的比例还算健康。但如果矩阵大到缓存装不下，需要频繁从HBM读取，那带宽就成了瓶颈。HBM3的带宽大概是800GB/s到1TB/s，看起来很大，但分摊到每个MAC单元上，可能每个周期只能喂几个字节的数据。而一个MAC单元每个周期需要两个操作数，这就供不上了。

4.2 片上缓存的层次设计

解决内存墙的一个方向是把缓存做深做细。L0寄存器文件、L1 SRAM、L2 SRAM、HBM，每一层的容量、带宽、延迟都不同。设计的关键是让数据在正确的时间出现在正确的层级。比如权重可以常驻L2，激活值在L1和L0之间流转，KV Cache放在HBM但用预取隐藏延迟。

这里有个经验：片上SRAM不是越大越好。SRAM的漏电功耗随面积增长，而且大SRAM的访问延迟也会增加。我见过一个设计把L2做到64MB，结果功耗里SRAM占了40%以上，芯片面积也下不来。更合理的做法是根据模型的数据复用模式来定缓存大小。比如Transformer的KV Cache，如果序列长度是2048，头维度是128，层数是32，那KV Cache大小大概是2048×128×32×2×2字节，约32MB。这个数字可以作为L2设计的参考。

4.3 近存计算和HBM的配合

近存计算（Near-Memory Computing）是把一部分计算逻辑放到HBM旁边，减少数据在PCB上的搬运。HBM的堆叠结构天然适合做这件事，因为TSV（硅通孔）可以提供很高的内部带宽。但近存计算的挑战是散热和良率。HBM本身发热就大，再塞计算逻辑进去，热密度会非常高。而且HBM的良率本来就不高，加上计算逻辑后测试更复杂。

我的看法是，近存计算适合做数据预处理和后处理，比如量化、反量化、激活函数，这些操作计算量不大但数据搬运频繁。把她们放到HBM旁边，能省不少带宽。但核心的矩阵乘还是放在主die上，因为需要灵活的调度和缓存。

5. 软件栈：芯片流片成功只是开始

5.1 编译器决定芯片好不好用

一颗AI芯片的硬件参数再漂亮，如果编译器拉胯，实际性能可能连十分之一都发挥不出来。编译器要做的事情包括：图优化、算子融合、内存分配、指令调度、量化插入。每一步都影响最终性能。

我见过最离谱的案例是，一个算子融合没做好，中间结果反复写回HBM，带宽直接打满，算力利用率掉到5%。后来编译器团队花了三个月优化融合策略，性能翻了四倍。所以硬件团队和编译器团队必须从第一天就坐在一起，不能等流片回来再补软件。

5.2 算子库的覆盖度

除了编译器，算子库的覆盖度也很关键。PyTorch里一个模型可能用到几百个算子，如果你的芯片只支持其中80%，剩下的20%就要回退到CPU，性能断崖式下跌。更麻烦的是，有些算子虽然功能一样，但参数不同，比如不同dilation的卷积、不同activation的融合，都需要单独实现。

我的建议是，先支持主流模型的全部算子，再考虑长尾。可以用一个优先级列表：Transformer的矩阵乘、LayerNorm、Softmax、GELU优先；CNN的卷积、BN、ReLU优先。每支持一个算子，都要在真实模型上验证端到端性能，不能只看单元测试。

5.3 量化工具链的坑

量化是AI芯片提效的重要手段，但量化工具链的坑非常多。训练后量化（PTQ）简单但精度损失大，量化感知训练（QAT）精度好但需要重新训练模型。而且不同模型对量化的敏感度不同，Transformer对激活值的量化特别敏感，因为Softmax的输出范围动态变化很大。

我在实践中发现，INT8量化在CNN上通常没问题，但在Transformer上，如果不做per-channel量化或者混合精度，精度掉点可能超过5%。所以量化工具链要支持细粒度的量化策略，比如权重per-channel、激活per-tensor，关键层保持FP16。这些策略需要和编译器、运行时配合，不是孤立的一个工具。

6. 验证、流片与成本控制

6.1 功能验证的覆盖率

芯片设计里，验证的工作量通常占整个项目的60%以上。AI芯片的验证更复杂，因为要验证的不仅是硬件逻辑，还有编译器和硬件的协同。比如一个算子融合后的指令序列，在仿真里跑通了，但实际芯片上因为时序问题出错，这种bug很难抓。

我的经验是，验证要分三层：单元级验证PE阵列和缓存，子系统级验证数据通路和调度，系统级验证完整模型。系统级验证最好用FPGA原型，虽然频率低，但能跑真实模型，发现仿真发现不了的问题。FPGA原型上跑一个BERT，如果精度和性能都符合预期，流片风险就小很多。

6.2 流片成本的构成

流片成本不只是掩膜版费用。7nm的掩膜版大概1500万美元，5nm要3000万以上。加上IP授权费（比如HBM控制器、PCIe控制器、DDR控制器），EDA工具授权费，验证IP费，封装测试费，一颗芯片从设计到量产，没有几千万美元下不来。而且流片一次不一定成功，如果发现bug要改版，又是一次流片费用。

所以很多初创公司会选择先用FPGA做原型，或者用Chiplet的方式，把不同功能拆成小芯片，降低单次流片风险。Chiplet的另一个好处是可以混合工艺，计算die用先进工艺，IO die用成熟工艺，成本更可控。

6.3 良率和功耗的平衡

先进工艺的良率是个现实问题。7nm的良率初期可能只有50%到60%，意味着你流片100颗，只有一半能正常工作。而且AI芯片的功耗通常很高，散热设计不好会导致降频，实际性能打折扣。

我见过一个设计，为了追求峰值算力，把频率拉到2GHz，结果功耗超标，只能降到1.5GHz使用，性能反而比不过频率低但功耗控制好的竞品。所以架构设计阶段就要做功耗预估，用EDA工具跑功耗分析，不能等流片回来再补救。

7. 一些个人体会和踩过的坑

先说一个最容易被低估的事情：散热。AI芯片的功耗密度很高，尤其是训练卡，动辄300W到700W。风冷压不住，得上液冷。但液冷系统的成本、可靠性、维护都是问题。我见过一个数据中心，因为液冷管路接头老化，漏液把整机柜的芯片都烧了。所以散热方案要在芯片设计阶段就考虑，比如热界面材料的选择、封装基板的热过孔设计。

另一个坑是PCIe带宽。很多人只关注芯片内部的算力，忽略了主机接口的带宽。如果PCIe只有Gen3 x16，带宽约16GB/s，而模型权重有几十GB，加载一次权重就要好几秒。训练时梯度同步也要走PCIe，带宽不够会拖慢整个集群。所以至少要用Gen4或Gen5，或者用NVLink这类专用互联。

还有一个经验：不要试图一次做一颗完美的芯片。芯片设计周期长，等流片回来，可能市场风向已经变了。更务实的做法是小步快跑，先做一颗针对特定场景的芯片，比如只做推理，只支持Transformer，把成本和风险控制住。等这颗芯片跑通了，再迭代扩展。我见过太多团队一开始野心太大，结果资金烧完，芯片还没流片。

最后说一个心态问题。造AI芯片是长跑，不是短跑。从定义到量产，三年算快的。这期间要不断跟编译器团队、模型团队、系统团队对齐，还要盯着工艺和封装的变化。如果没有足够的耐心和资金储备，建议先从FPGA加速卡或者IP授权做起，别一上来就流片。芯片这行，敬畏心比野心更重要。