企业官网建设流程全解析

1. 先想清楚：新造AI芯片到底要解决什么问题

AI芯片这四个字这两年已经被聊到快起茧了。但真到“新造一颗”的层面，大多数人第一反应是堆算力、追制程、对标某家头部产品，这其实是最容易走偏的地方。我自己在这个圈子里摸爬滚打了十几年，见过太多团队拿着好技术却死在了需求错位上——芯片做出来了，客户用不上；或者客户要的，芯片做不到。所以聊新造AI芯片之前，我特别想先把“问题定义”这个环节拎出来说透。

1.1 需求驱动比技术驱动更重要：场景决定架构

芯片行业有一个很容易被忽视的规律：一款芯片的成功，技术只占三成，剩下七成在于它能不能精准命中某个真实场景的痛点。新造一颗AI芯片，第一件事不是研究该用7nm还是5nm，也不是纠结算力要做到多少TOPS，而是先回答三个问题：这颗芯片给谁用？跑什么模型？在什么功耗和成本约束下工作？

举个例子，同样是AI芯片，云端训练芯片和边缘推理芯片的设计逻辑几乎是对着干的。云端训练要求极高的并行计算能力和超大存储带宽，对功耗相对宽容；边缘推理则恰恰相反，功耗、面积和成本都是硬约束，性能反而要往后靠。如果你把这两个场景混在一起设计，最后大概率做出来一颗两头不讨好的芯片——跑训练算力不够，跑推理功耗又压不住。

这里我建议大家做一个非常务实的动作：把目标场景的模型结构、数据流特征、算力需求、带宽需求全部量化成一个“需求清单”。比如做自动驾驶芯片，就去采集实际跑过的感知模型，记录每个卷积层、Transformer层的计算量和访存量；做AIoT芯片，就要明确跑的是哪种轻量化模型，量化精度能接受多少损失。这张清单是所有架构决策的起点。

1.2 从AI工作负载看芯片设计的三个核心约束

把需求梳理清楚之后，就进入了AI芯片设计的核心矛盾。我做了一张图在脑子里存了很多年——AI工作负载有三个核心约束相互拉扯：算力、带宽、功耗。

算力好理解，就是MAC阵列（乘累加单元阵列）能跑多快的问题。但算力堆上去之后，带宽跟不上，计算单元就一直在“空转”等数据；带宽解决了，功耗又可能爆掉。这三者的关系就像木桶效应，短板决定整体表现，而且彼此之间还会互相制约。

经典的做法是在架构层面解决这三者的矛盾。过去十年AI芯片架构演进，有一条主线就是为了在算力和带宽之间找平衡：从早期靠增大片上SRAM缓存来减少对外部存储的访问，到后来发展出数据流（Dataflow）架构，通过改变数据在计算阵列中的流动方式来复用数据，尽可能减少搬运。我见过不少团队一上来就堆算力，结果流片回来带宽墙死死卡住，实际利用率只有30%——这个坑踩过的人应该都有共鸣。

对于新造AI芯片，我始终强调一个观点：先有场景和约束，后有架构和算力。芯片不是一个可以“先做出来再找市场”的产品，它的研发周期动辄两三年，等不起也改不起。

2. 架构选型：主流AI芯片路线的对比与决策

2.1 从GPU到NPU再到ASIC：三种主流路线各有各的算盘

现在市面上能看到的AI芯片方案，无外乎三大路线：通用GPU路线、NPU（神经网络处理器）路线、以及ASIC（专用定制）路线。这三条路线没有绝对的好与坏，只是在“通用性”和“专用性”的坐标轴上各居其位。

GPU路线最典型的就是NVIDIA的A100、H100系列。它的底子是图形处理架构，但通过引入Tensor Core等专用单元，把矩阵乘法的效率做到了极致。GPU最大的优势在于生态成熟——CUDA平台积累了海量开发者，任何新模型出来，几乎当天就能在GPU上跑起来。自己造GPU这种路线，难度在于必须同步搞定CUDA级别的软件生态，这比芯片本身的难度更大。

NPU路线是当前国产AI芯片最主流的选择，也是我认为对新玩家最友好的切入点。NPU的本质是面向神经网络的计算流做架构优化，比如高通、联发科手机SoC里的AI引擎，以及各种云端推理芯片。NPU不需要兼容GPU那样几十年积累的图形生态，只需要围绕AI算子优化。它的设计自由度更高，可以从数据流、存储层次、计算精度等多个维度做定制，做出差异化特征。

ASIC路线则是把场景锁定到极致，比如Google的TPU。TPU从第一代开始就明确“我只是为了跑推理/训练而生的”，把一切与AI无关的功能全部砍掉，换来极致的能效比。ASIC的局限也非常明显：一旦算法范式变化，硬件就面临淘汰风险。比如Transformer大模型兴起之后，很多为CNN设计的ASIC直接失去了用武之地。

2.2 对新造AI芯片创业者的现实建议

综合来看，如果今天有一个新团队找我问“应该选哪条路”，我的建议非常明确：除非你有极强的软件生态积累，否则不要碰通用GPU；除非你有非常确定的长期场景且算法演进慢，否则不要一上来就做纯ASIC。最稳妥的切入点是NPU路线，而且最好是“半定制”的思路——计算单元面向主流模型做优化，同时保留一定程度的可编程能力，方便适配新的算子。

这个思路的核心在于“跟随主流但留有后手”。现在大模型是绝对的主角，Transformer架构成为事实标准，那么芯片架构就应该围绕Transformer的特征来设计：支持大矩阵乘法、支持长序列的并行解码、针对注意力机制优化带宽调度。但同时，CNN和传统NLP模型在存量市场仍然大量存在，所以计算单元不能在架构上完全锁死。

我经常给团队打一个比方：做AI芯片架构有点像开餐厅。你可以开一家只做招牌菜的店（纯ASIC），效率极高但客人选择少；也可以开一家大而全的饭店（通用GPU），什么菜都有但招牌菜未必突出；最聪明的做法是开一家“招牌菜极强、但也能做家常菜”的餐厅——这就是NPU半定制路线的精髓。

3. 硬件核心设计：算力、带宽与存储的平衡术

3.1 算力不只是TOPS：MAC阵列和实际利用率才是关键

很多芯片发布会喜欢标一个非常亮眼的TOPS数字，但懂行的人都知道，这个数字里面水分太大。TOPS是理论峰值算力，而实际能达到的算力取决于一个关键指标：MAC阵列利用率。以我见过的芯片为例，标称算力100 TOPS，实际跑ResNet可能只能达到60%-70%，跑Transformer可能只有40%-50%，遇到动态形状的输入甚至更低。

MAC阵列利用率为什么这么难做上去？核心原因还是数据喂不饱计算单元。一个典型的AI芯片内部，计算单元是一块巨大的二维阵列，每个周期要执行成千上万次乘累加。但计算单元所需要的数据，如果不在最近的SRAM里，就要从更远的内存层次去搬，而搬数据的速度远低于计算速度，于是计算单元大量时间都在“等待数据”。

解决这个问题的核心思路叫“数据复用”。举个例子，一个卷积核在一个特征图上滑动时，中间的计算结果可以被多个输出位置复用。如果架构上设计好了数据流，让数据在被计算完之后尽可能多地留在片上给后续计算用，就能显著减少访存请求。具体实现方式包括权重固定（Weight Stationary）、输入固定（Input Stationary）、输出固定（Output Stationary）等数据流方案，每种方案适合的场景不一样。我见过一些团队在这一层面的优化做得很好，只用一半的MAC阵列就能打平对手满阵列的效果，这就是架构设计的价值。

3.2 存储墙问题：为什么HBM和大缓存缺一不可

存储墙是每一代AI芯片都绕不过去的坎。单颗HBM（高带宽内存）能提供几百GB/s到数TB/s的带宽，但成本极其昂贵，而且封装难度大。更现实的问题是：外部存储带宽即使做得再高，也远赶不上计算阵列的消耗速度。因此，片上存储层次的设计往往决定了芯片最终性能的上限。

我自己做架构设计时有一个经验值：对Transformer类的推理负载，片上SRAM至少需要把单个batch的中间激活值装下。假设一个7B模型的KV Cache在推理时占用几十MB，那么片上缓存至少要做到几十MB量级，否则每个Token生成都要回外部存储器拿数据，性能会断崖式下降。这也是为什么新一代AI芯片都在拼命加大片上SRAM——某些高端芯片的片上存储已经做到几十MB甚至上百MB。

另外一个重要技巧是减少“中间激活”的存储开销。Transformer的层数很深，每一层都有巨大的中间结果需要暂存。业界目前的一个主流做法是“算子融合”：把多个计算操作融合成一个kernel，在计算过程中尽量保持数据在寄存器或L1 cache里，避免把中间结果写回外部存储。这个技术看起来是软件层的优化，实际上它倒逼了硬件的可编程性设计——芯片必须支持灵活的数据流调度，才能实现有效的算子融合。

3.3 互联设计与“解放算力”的最后一公里

如果算力、存储都解决了，还有一块硬骨头摆在面前：芯片与芯片之间、片内计算核之间的互联。大模型训练和超大batch推理几乎必然是多卡协同，互联带宽直接决定多卡效率。

这里我想插一个实操经历：有一次我们测一款自研芯片，单卡跑ResNet-50性能完全达标，但一上多卡数据并行训练，效率直接掉到单卡时代的65%。排查了半天发现，问题出在互联接口上的同步机制——核间通信在等待同步信号时浪费了大量时钟周期。后来我们在硬件里加了异步流水线机制，多卡效率才拉回到接近线性加速的水平。这个问题的本质是：算力再强，如果数据搬来搬去的时间占比太高，整体效率就上不去。

对互联设计，我的建议是优先关注两点：一是高带宽低延迟的片间通信接口，比如目前主流的类NVLink方案或CXL接口方案；二是通信协议的硬件卸载能力，尽量把数据搬运和同步逻辑下沉到硬件，减少主控CPU的参与。

4. 软硬协同：AI芯片的隐藏战场

4.1 没有编译器，芯片只是一块昂贵的镇纸

这是我最想强调的一个观点，也是不少AI芯片团队栽过跟头的地方。很多团队花两年时间把芯片做出来了，结果SDK和编译器一团糟，模型根本跑不起来——芯片在实验室里可能表现优异，但客户做不了任何实际工作。

编译器的核心任务，是把深度学习框架里的模型图（Graph）映射到底层硬件指令上。一个高效的编译器要做到三件事：第一，把算子拆分并映射到合适的计算单元上；第二，调度数据流让数据尽可能在片上复用；第三，自动做算子融合和内存分配优化。这三件事每一件都极其复杂。我见过一个实际案例：同款芯片，官方编译器生成的代码只能达到理论性能的45%，而一个团队花了三个月手写kernel关键算子，把性能拉到了85%。这中间的差距就是编译器的价值空间。

对于新造AI芯片的团队，我建议在硬件设计阶段就把编译器团队拉进来，而不是等芯片快流片了才开始写编译器。编译器决定了芯片能否被客户真正用起来，它的开发周期不比硬件短。芯片界有个老话叫“软硬协同”，但在AI芯片时代，这句话的分量比任何时候都重。

4.2 算子库与基准测试：空口无凭，跑分见真章

除编译器外，算子库（Kernel Library）是另一块拦路虎。算子库是预先优化好的底层函数集合，相当于给上层框架和开发者提供“积木”，比如卷积函数、矩阵乘法、归一化、激活函数等。一个完整的算子库需要覆盖至少几十个常用算子，而且每个算子都要针对不同shape、不同数据类型做极致优化。

这里分享一个常见的“陷阱”：想用benchmark数据对外宣传芯片性能，但benchmark模型往往需要配套的优化算子才能发挥实力。如果算子库不全或者优化不到位，跑出来的benchmark数据就会很惨。所以我的习惯是，在项目立项时就把算子库的覆盖面列入验收标准：至少覆盖PyTorch和ONNX Runtime中95%以上的常用算子，并对头部模型全流程跑通做验收。

另外千万不要忽略量化支持。目前主流推理芯片都支持INT8和FP16，新造芯片至少要支持这两种精度的原生计算。现在大模型推理还流行FP8、INT4这类更激进的低比特量化，这些都会影响硬件的指令集和数值格式设计，必须在芯片定义阶段就想清楚，而不是等流片后打补丁。

4.3 生态兼容：是走捷径还是自建平台

“生态”这个词在AI芯片领域几乎等同于“未来”。一个新芯片要融入现有的AI软件生态，最务实的路径是兼容主流框架。目前来看，抽象层次有两个选择：一是兼容到图编译器层面，比如对接ONNX Runtime或TVM，让模型可以无缝转换；二是兼容到底层接口层面，比如提供类PyTorch的算子接口。

从我的实操经验来讲，AI芯片团队最容易在产品早期犯的错误是“过度自建生态”。明明客户用PyTorch训练好的模型，你要他为了你的芯片去学一套新框架，这个学习成本大到足以劝退客户。正确的策略是“顺应为主，差异为辅”：核心对接PyTorch等主流框架，保证客户模型可以“无感”迁入；极少数的差异化能力（比如特殊算子的硬件加速）再作为可选项开放。

5. 从流片到量产：AI芯片落地的最后一步

5.1 流片成本与风险控制的现实考量

流片是整个芯片项目中最紧张、也最花钱的环节。先进工艺的一次MPW（多项目晶圆）流片费用动辄数百万美元，Full Mask（全掩模）更是千万美元起步。对创业团队来说，流片之前必须做足风险控制，否则一次失败就可能拖垮整个公司。

我见过多个团队，总结下来降低流片风险有三大抓手：第一，尽可能在FGA（现场可编程门阵列）上做充分的验证，先把数据通路、控制逻辑、软件栈全部在FPGA上跑通，再开始物理实现；第二，重视仿真覆盖率和随机验证用例设计，关键模块的功能覆盖要到95%以上；第三，预留DFT（可测试性设计）接口，包括扫描链、BIST（内建自测），否则芯片一旦出问题，连定位故障的手段都没有。

还有一点是关于工艺选择。新造AI芯片不一定非要用最先进的制程。对于推理场景，28nm到12nm的成熟工艺配合优秀的架构设计，在很多情况下能做到和先进工艺相近的功耗表现。先进工艺的性能红利毋庸置疑，但开发和流片成本也是指数级上升。我自己倾向于“性能目标反推工艺选择”：设定好功耗和算力指标，再评估哪个工艺节点可以达标且成本最低。

5.2 客户验证阶段：真实场景才是最好的试金石

流片回来之后，很多团队会松一口气，但实际上最考验人的阶段才刚刚开始。芯片点亮、跑通测试程序，这只是从0到1；真正从1到N，是让客户在自己的真实场景里跑起来。这一步我建议重点准备两样东西：一个开箱即用的参考设计板卡，一个带全套工具链的SDK交付包。客户拿到手后，最好24小时内就能跑通一个示例模型。

我踩过的一个坑是：我们的芯片在自研开发板上性能很漂亮，但客户在自己的硬件主板上怎么都跑不出同样效果。最后排查发现是供电设计问题——参考板用的电源模块品质较好，客户的量产方案则选用了低成本电源模块，在高负载时电压跌落导致频率自动降下来了。这就提醒我们，芯片级验证时就要覆盖“客户可能出现的各种恶劣环境”，最好在芯片内部加电源监控和时钟节流机制，在性能下降时主动报警，而不是默默降频。

另外一个经验：在客户验证阶段不要只展示跑分，一定要跑对方真实场景的最小闭环用例。比如做AI摄像头芯片，就带一个真实的端到端人脸识别演示；做语音芯片，就带完整的唤醒-识别-响应链路。客户看到真实场景的效果，比看几百页PPT都管用。

5.3 量产和新品迭代：从追赶到建立护城河

芯片一旦通过客户验证，马上又要进入量产环节。量产没你想的那么简单——良率爬坡、封装测试、批次一致性、供应链管理，每一个环节都可能导致交付延迟。这里我特别想说一下产能规划：很多AI芯片创业公司在量产阶段才意识到，代工厂的产能不是你想排就能排的，尤其先进制程产能紧张时，提前一年就要锁定产能。这不算技术问题，但确实是很多技术团队容易忽略的经营问题。

再说迭代：第一款AI芯片从立项到量产往往需要两到三年，而AI模型可能每半年就更新一次。所以芯片架构一定要有前瞻性。我建议在做第一颗芯片时，就规划好第二代产品的方向，在架构上预留扩展接口，比如增加对稀疏计算的支持、增加对动态形状模型的处理能力。芯片不像软件可以随时发补丁，它的灵活性体现在架构设计的“预先留白”上。

6. 踩过的坑与经验复盘：给新造AI芯片团队的几点忠告

6.1 五个最容易被低估的问题

我把自己和同行们经历过的各种教训梳理了一下，选出五个最典型、也最具共性的问题，写成了一份“避坑清单”，大家可以对照着自查：

这里特别想展开说一下Roofline模型。它是一个非常经典的分析工具，用来直观地判断一个负载在给定硬件上是“计算受限”还是“带宽受限”。横轴是计算密度（单位数据量的计算次数），纵轴是可达性能。如果你的模型工作负载落在了带宽受限区，那么就算再加MAC阵列也毫无意义，应该优先解决带宽问题。这个工具在架构评估阶段简直到处都用得上，强烈推荐团队里人人都能画一下。

6.2 从第一颗芯片到持续成功的自然法则

最后我想分享一个个人体会。做AI芯片，本质上是在做一件“长跑”的事。第一颗芯片的成功只是一个起跑点，真正拉开差距的是后续的系统能力：有没有一套可持续演进的架构路线？软件栈能不能跟上模型迭代速度？供应链能不能稳定保障？这些都不是一次流片能证明的，而是需要团队持续投入、不断沉淀。

在我参与过的项目里，最让我惋惜的不是技术上的失败，而是一些团队在拿到流片成功后陷入“虚假的安全感”，以为芯片做出来就大功告成了，结果产品和市场严重脱节，最后被快速变化的模型生态和客户需求抛弃。

新造AI芯片这件事，门槛高、周期长、风险大，但很值得做——因为算力在今天已经不只是技术问题，而是实实在在制约AI落地的瓶颈。如果有人问我的建议，我会说：先想清楚场景和约束，把编译器当成芯片的一部分来设计，用真实客户模型来验收你的芯片。把这些基础打牢，再谈架构创新和算力突破。这是我个人在实操中最深的体会，也是我想重点分享给后来者的经验。