企业官网建设流程全解析

最近这一年，和不少同行聊天，话题总会绕回到同一个地方：在当前这个算力需求暴涨的节点，自己从头造一颗AI芯片到底还值不值？问这个问题的人，有大厂里负责芯片立项的，有拿了融资正在找方向的创业团队，也有做软件出身、看了算力账单之后心痒难耐的工程师。我自己在这行摸爬滚打了一些年，谈不上有标准答案，但关于"新造一颗AI芯片"这事的完整思考，确实积累了不少。这篇就把我立项前反复琢磨过的问题摊开讲一讲：从要不要做、做什么，到架构怎么选、生态怎么补，最后再算一算这笔账到底划不划算。

这篇内容适合谁看？一句话——所有想在AI芯片方向动真格的人。无论你是要给公司写立项报告的负责人，还是在评估自研和采购之间取舍的技术管理者，又或者只是想弄明白AI芯片到底难在哪儿的软件工程师、学生，这篇都能给你一个相对完整的思考框架。我会尽量少用"黑话"，把那些真正决定成败但又经常被忽略的环节掰开揉碎。

1. 为什么在算力爆炸的节点，反而要冷静问一句"凭什么"

1.1 算力缺口的真实体感，和它留下的缝隙

先把背景摆出来。大模型从几亿参数涨到几千亿参数，多模态、视频生成、Agent这类应用又把推理侧的调用量拉高了几个数量级。任何一个亲手部署过模型的团队，都会对"排队等卡"这件事有切身体会。我之前帮一个客户调生成式AI服务，他们采购的GPU服务器，从下单到上架硬生生等了两个季度，中间所有业务都处于"看天吃饭"的状态。

这种供需错配确实给了新玩家入场的机会。但机会存在，不代表每个人都有资格拿。赛道里既有通用GPU巨头，也有专门做推理加速的NPU团队，还有做国产替代的各种玩家。新造一颗芯片，首要问题是：凭什么用户会放弃已经调通的软件栈，转头用你的卡？

我见过太多团队在这个问题上犯迷糊。他们看到算力缺口，就下意识认为自己造芯片也能分一杯羹，实际上一算账，连竞品的零头都摸不到。真正的缝隙在哪儿？在于现有方案在某些特定场景下效率不够高、成本降不下来、或功耗压不下去。比如数据中心里推理长尾效应严重，通用GPU对稀疏计算的支持并不完美；比如端侧设备需要极低功耗但又能跑大模型，通用硬件根本塞不进去。这些缝隙，才是新芯片活下去的土壤。

1.2 三条技术路线，入场前就得选边站

做芯片之前，首先要面对技术路线选择。目前你能走的路基本就三条：ASIC（专用定制）、GPGPU（通用并行计算）、FPGA（半定制可重构）。

ASIC的代表就是各类NPU、TPU，针对特定计算模式做极致优化，单位算力功耗比漂亮，但设计周期长、一旦定版就很难改。GPGPU的代表不用多说，可编程性好、生态成熟，但同样意味着控制逻辑复杂，指令调度、缓存一致性、通用计算单元一个都不能少，开发难度比ASIC高一个量级。FPGA介于两者之间，不需要流片就能改电路，适合小批量、验证期，但做FPGA的芯片无法直接对标通用GPU，更多是用在通信加速、原型验证、以及需要灵活迭代的专用设备里。

我的建议很直接：如果你是一个预算有限的创业团队，想做训练芯片，基本等于选择地狱难度；如果做推理，ASIC路线相对现实；如果只是想做加速卡板卡级别的方案，也许先别碰芯片，FPGA或SoC集成NPU反而更划算。选错了起点，后面所有努力都是在错误的地基上盖楼。

2. 先别急着画架构图，把"造来干嘛"这四个字想透

2.1 训练芯片和推理芯片，根本不是同一个物种

很多人一说AI芯片，脑子里就是"能跑神经网络就行"。但训练和推理对芯片的要求差异之大，几乎像做服务器CPU和做手机基带一样，完全是两种设计哲学。

训练芯片要的是吞吐能力和可扩展性。一个千亿参数模型训练，任务要切到几百上千张卡上并行，每张卡不仅要算得快，还要跟得上数据交换节奏。这时候芯片内部的计算单元可以粗犷，但互联、显存带宽、通信同步容错，每一块都不能拖后腿。训练场景里精度也讲究，混合精度训练需要FP16、BF16甚至FP32的完整支持，不能让梯度一洗就崩。

推理芯片则完全反过来，核心诉求是单样本延迟和吞吐/功耗比。在线服务要毫秒级响应，token要稳定流出，不卡顿。推理不需要那么庞大的多卡协同，反而更看重单卡能不能把模型完整装下，访存能不能喂饱计算单元。精度上FP8、INT8量化之后能保证精度不降就行，INT4甚至更低也在疯狂尝试。

所以，立项第一件事不是选工艺，而是回答一个问题：你做的到底是训练、推理，还是两者兼顾？理清这个边界，后面才能谈微架构。想"什么都做"的结果通常是什么都做不好，设计目标被稀释，做出来一颗什么都比不过别人的四不像。

2.2 一个从需求倒推规格的实际例子：7B模型的推理芯片

用实际例子来演示思考过程。假设我们要做一颗数据中心推理芯片，目标场景是并发跑Llama 3 8B类的模型，单卡要支撑比较高的并发token吞吐。这颗芯片该怎么定指标？

先算一下需求。8B参数模型，在解码阶段，生成一个token大约需要2×8B=16G FLOPs的计算量。如果希望单卡生成吞吐达到每秒2000个token，那需要的峰值算力就是 16G × 2000 = 32T FLOP/s。考虑到实际利用率不可能100%，一颗FP16算力在30~50 TFLOPS的芯片才比较从容。再看显存：8B模型FP16权重占16GB，加上KV Cache、中间激活，单卡怎么也得配32GB起步，理想是64GB，否则模型都塞不下，谈什么生。最后看带宽：生成阶段是典型的访存密集，算力/访存比太夸张的话，芯片会一直饿着肚子等数据。按当前主流加速卡的配比，芯片算力40T级别，配HBM总带宽至少要有1~2TB/s才算健康。

你看，从这个简单的推导就可以发现：我们还没画任何电路，就已经把算力、显存、带宽三个最核心的硬件指标定出来了。这就是"应用定义芯片"的实际操作方式。反过来，很多团队先选了工艺、买了IP，再想着怎么把指标凑出来，方向就反了。

2.3 数据中心、边缘、端侧，三个战场打法完全不同

同样是推理芯片，放在数据中心、边缘服务器、手机/车载里，约束条件天差地别。

数据中心里的AI芯片，可以用最好的工艺，可以配HBM，功耗可以放到两三百瓦甚至更高，对散热和供电的容忍度都很高，成本相对不敏感。边缘场景，比如园区小盒子、工业控制电脑，功耗限制在几十瓦，只能用LPDDR这类存储，封装也受限，但同样要跑得动十几B参数的模型。端侧就更加极端，几瓦甚至不到一瓦的功耗墙，每一毫瓦都要抠。

我见过一个典型的失败案例：一家公司一开始想做面向数据中心的推理卡，做了一半发现成本撑不住，又转头想改造成边缘设备。结果微架构里的很多设计——比如针对HBM的访存调度、功耗管控模块——在边缘场景根本用不上，等于白扔了大量面积，性能和功耗双双不达标。这个教训说明，场景必须在架构设计之前定死，中途换赛道，基本等于重新做一颗芯片。

3. 计算单元、存储墙和互联，AI芯片的三大命门

3.1 脉动阵列与SIMT之争，本质是"专用够不够"之争

AI芯片的核心计算单元，不外乎两条路线。一条是脉动阵列（Systolic Array），数据像流水一样在计算阵列里依次流过，每个计算单元做一次乘加后马上把结果传给下一个。这种结构对矩阵乘极其高效，面积利用率高，功耗也低。你去看很多NPU、TPU，内部都是这种思路。

另一条是SIMT（单指令多线程），本质上跟GPU类似，靠大量小核心配合调度器并行执行，灵活性高，能跑各种杂乱的计算形态。这种结构的代价是控制逻辑、缓存、调度器会吃掉大量面积，功耗预算也高。

现在的新锐做法，很多是两种混着来：大矩阵走脉动阵列，复杂小算子走通用向量/标量单元。但"混着来"也有成本，异构核心之间的数据搬运和调度切换会带来额外开销，设计验证工作量更大。

我说点很多人不爱听的话：AI芯片里真正吃性能的，其实是Transformer里的Attention、Softmax、LayerNorm这些旁路算子。纯矩阵乘用脉动阵列没问题，但Attention里有大量非规整的访存和逐元素操作。如果你把宝全压在矩阵乘上，一颗芯片跑起来，GPU能从容灵活地处理各种算子组合，你可能要频繁在专核和通用核之间搬数据，一搬就是损失。所以计算单元怎么设计，真的得看你目标模型scope，千万别拿"跑通几个人家的常用模型"当验收标准，要考虑算子分布的多样性。

3.2 存储墙：为什么HBM这个话题绕不开

AI芯片设计里最常被引用的一个词是"存储墙"：计算单元越来越快，但数据从内存到计算的路上越来越堵。以当前数据中心的AI加速卡为例，要做到数百TFLOPS级别的算力，内存带宽必须做到TB/s级别。目前能到这个量级的只有HBM（高带宽内存）。

HBM是通过3D堆叠DRAM颗粒并借用硅中介层与计算芯片连接，带宽能拉得很高，但代价也很直接：成本贵、供应链紧张、封装复杂、功耗还不低。HBM3E目前单颗堆叠带宽可以超过1TB/s，然而一颗中间层芯片的面积就那么大，放两颗HBM封装已经非常紧张。

如果预算有限，替代方案是LPDDR5X/GDDR方案，容量可以做得很大，成本可控，但带宽通常只有HBM的十分之一左右。这种方案适合低算力、边缘设备，强行放到数据中心，算力一上去就会撞到带宽天花板。说到近存计算——把存储和计算做到更近的位置，甚至用存算一体技术突破带宽瓶颈——听起来很美，实际工程化还很不成熟，数模混合信号的设计、校准、可靠性和量产一致性全是坑。作为第一颗芯片，我建议直接放弃存算一体，把它当研究方向而非产品方向。

3.3 片内互联：没人讨论但处处卡脖子的部分

芯片内部有几十上百个计算核，它们之间怎么通信，直接影响最终效率。这里面的核心就是NoC（片上网络）和缓存一致性设计。

NoC要保证多个计算核心同时访问数据时不会互相踩踏。设计不当，会出现"算力叠加了但性能不叠加"的诡异现象——加核不加速。尤其做推理芯片，算子执行顺序和数据重用模式复杂，网络拥塞会导致利用率大幅下滑。

缓存一致性更是隐形杀手。多核心同时维护一份模型权重和中间状态，如果走GPU那套复杂的缓存一致性协议，设计难度极高；如果干脆不做一致性、用软件去管理共享内存，虽然直接但编程门槛高，用户骂娘。很多自研AI芯片，纸面算力很好看，实测一跑多核并行，效率只有40%~60%，问题十有八九出在片内互联。这套东西短时间内看不出来，但会在后期用极其痛苦的方式给你回旋镖。

4. 单芯片性能再好看，集群一拉就露馅

4.1 片间互联方案的大局观

今天做AI芯片，几乎没人能单卡打天下。训练千亿模型要多卡并行，推理服务在流量大的时候也要横向扩展。片间互联成了一个决定产品命运的因素。

片间互联的主流路径我看着有三条。第一，PCIe，成熟便宜，但带宽有限，多卡做大规模并行时数据同步会拖后腿。第二，类NVLink的私有高速互连协议，带宽高延迟低，但得自研物理层和协议栈，工程量巨大。第三，RoCE/InfiniBand这类网络方案，走以太网调度，扩展到几十卡、几百卡相对方便，但单跳延迟和带宽又吃亏。

做芯片立项时，很多人只盯着单芯片，觉得"我卡快就行"。实际上客户买你的卡是要组集群的。你的片间互联能力如果跟不上，单卡再快，用户一扩到8卡、16卡，性能线性度掉得厉害，立刻就没有买单意愿。反过来，片间互联做得好的芯片，单卡指标稍微普通一点，集群性能反而能拉出优势。

4.2 扩展性设计的残酷细节：线性度与多卡协同

扩展性这个词说得轻巧，做起来全是细节。多卡协同训练或推理，最怕的就是通信拖累计算。假设你芯片有40T算力，片间互联带宽只有100GB/s，那每次梯度同步、中间激活交换都会成为瓶颈。并行度一拉高，实际加速比可能只有1.5倍甚至更离谱。

我自己参与过一个项目，当时只做了PCIe 4.0 x16的互联，觉得"够用了"。结果客户拿去做多节点训练，一测就是线性度惨不忍睹。后来才知道，训练任务随时需要AllReduce，把几千亿参数的梯度数据同步到每个节点，PCIe那点带宽根本撑不住。本来我们以为自己做的是一颗芯片，最后发现做的是"单卡还行的芯片"，市场直接砍掉一半。这个坑踩得非常痛。如果新造芯片，一开始就要把片间互联方案当成芯片架构的一部分，想清楚支持多少卡、用什么拓扑、跑什么通信库，甚至得把NVLink这种高带宽私有协议当成基准目标来对标。

4.3 新入场团队最容易低估的：网卡、交换机和驱动

这其实是集群层面最尴尬的现实：很多芯片团队没有网络背景。他们以为芯片造出来了，接个网卡就能组成集群。但实际上一套训练集群要处理RDMA、拥塞控制、故障接管、路由拓扑，软件栈极其庞杂。你的芯片要支持这些，就得配套做驱动、固件和通信库，每一项单独拿出来都是一个队伍一年的工作量。

如果你不做训练集群，只做推理加速卡，单机内多卡互联相对简单，但要想清楚服务器里怎么和CPU通信、怎么和宿主机的内存做数据交换、是否支持标准PCIe枚举。很多定制芯片死在"客户插上卡发现系统不识别"这种看起来很低端的问题上。

5. 生态是隐形门槛，硬件的失败往往死于软件

5.1 "兼容CUDA"听着简单，实际上是个大坑

造AI芯片，绕不开一个灵魂拷问：怎么让用户的程序跑起来？最省事的想法是"兼容CUDA"。这个方向我也认真评估过，但结论是：没有足够的资金和耐心，别轻易碰。

兼容CUDA的技术路线有几种。一种是在驱动层面直接翻译CUDA API调用，把cuBLAS、cuDNN这些库调用导向自己的算子库，这种方案对上层框架表现友好，但工作量极其庞大，因为CUDA的API面太宽了，每一条指令、每一个库函数都要单独处理。另一种是在编译器层面，比如接入开源生态，把CUDA kernel想办法转译成自己的IR再编译到目标硬件，听起来优雅，但实际会遇到无数边界情况，很多kernel写得非常依赖GPU的执行模型，翻译后的性能惨不忍睹。

这里分享一个观察：市面上声称兼容CUDA的国产芯片，实测下来大多只能覆盖部分常用算子。你用PyTorch跑ResNet没问题，但跑一个冷门的大模型推理仓库，可能就缺算子或性能暴跌。所以兼容CUDA不是一条捷径，而是一条"看起来近、走起来远"的险路。

5.2 编译器、算子库、推理引擎，一个都不能少

硬件造出来之后，你要么接入PyTorch、ONNX Runtime等框架，要么提供一个高效的推理引擎。两条路都需要做大量的算子实现工作。一个Transformer模型里，常见算子少说几十个，每个算子要针对你的硬件指令集手写优化。如果做个比喻，硬件是一台跑车，算子库就是适配各种路面的赛道胎，没有赛道胎，发动机再强也上不了赛道。

编译器更是重灾区。从框架图到硬件的调度映射，每一步都涉及大量决策：哪些算子融合、数据布局怎么排、循环怎么展开、内存调度怎么优化。业界常说一颗芯片的成败，一半在硬件、一半在编译器，这个比例我觉得在AI芯片里和实际体感差不多。

我强烈建议：做芯片的同时，软件团队必须同步组建，甚至应该软件先行。流片之前就把编译器和算子库在模拟器上全部调通。等芯片回来再找软件问题，一个bug一次流片周期就是几个月，根本耗不起。

5.3 开发者不可能为了你重写代码：迁移成本是最大护城河

最后，也是最容易被忽视的：用户习惯。今天全球AI开发者都习惯了在GPU上写代码、调试、部署。你的芯片就算推理速度快两倍，如果开发者要在你的平台上多花两周做适配，他们大概率不会用。这就像大家已经习惯用微信，这时候你做出一个传输速度更快的通讯软件，功能再强也没人迁。

所以很多团队真正做的不是"芯片"，而是"降低迁移成本"。要么提供值得放弃的标准接口、只做场景杀手锏，比如极低功耗或极低成本；要么深度绑定某个特定场景，比如只做视频生成推理、只做多模态端侧部署，让用户在现场就能拿到显著的收益。没有这个定位，芯片做得再精致，也只能躺在Demo台上吃灰。

6. 算清楚这笔账：一次流片、整套工具链、三年时间

6.1 流片只是开始：昂贵的"一次机会"

很多人以为造芯片最大的开销是流片这件事。流片贵不贵？看工艺节点：28nm相对便宜，几百万人民币能打样；7nm、5nm一次流片几十百万美元级别的成本，更不用说先进制程还需要拿到产能优先级，这些都还不是有钱就能搞定的事。

但流片失败才是最贵的。先进制程的一次流片，回来后如果性能不达预期，你要花大量时间定位是逻辑bug、物理实现问题、还是工艺偏差。芯片不像软件可以天天改，每次改版都是一轮"设计-实现-流片-测试"的长循环。行业里常见的情况是：第一版流片主要目的只是"跑通"，真正能用的产品往往是第二版甚至第三版。你要把每一轮流片的成本乘以三到四倍，这才是真实的预算。

6.2 人才、IP和工具链，三座隐性成本大山

除了流片，芯片设计里还有三座隐性大山。第一是人才：一个做过大规模SoC设计的团队，成员基本得有十年以上经验，且覆盖架构、前端、后端、验证、物理设计、软件栈，这种团队人力成本一年下来数字非常吓人，而且市场上人才稀缺，组队周期动辄半年一年。

第二是IP：SerDes、PCIe、DDR控制器、HBM控制器这些模块，基本都要买第三方授权。每个IP都有授权费、集成、验证、维护成本，攒齐一套你也得准备千万量级的预算。

第三是EDA工具：新思、Cadence、西门子这几家的工具链，按年授权每年费用都是百万美元起步。除非有特殊渠道拿到优惠，否则小团队在起跑线上就已经感受到了什么叫"落后就要多付钱"。

钱的问题还不是最致命的。更致命的是时间——一颗AI芯片从立项到量产，三年太乐观，五年正常。但AI行业的变化速度是半年一个新模型、一年多一个新架构。你三年前定的算力指标，出来时可能已经无法满足市场上的新模型需求。做芯片最需要的一种能力，是对行业节奏的判断：要么走快周期路线，主攻变化相对慢的垂直场景；要么垫高软件兼容性，让硬件不管模型怎么变，都能通过软件层面跟上。

6.3 给不同背景团队的务实建议

聊了这么多，最后说一说根据不同背景，到底该怎么选路径。

如果你是大厂且已经有成熟芯片团队，可以认真评估自研训推一体芯片，配合自己的云和软件生态，形成垂直整合。但记住：sponsor的耐心才是最大的限制条件，一旦三年看不到回报，项目很容易被砍。你要在立项那一刻就把阶段性milestone定义清楚，用能用的小项目先证明团队能力。

如果你是创业团队且预算有限，我建议别碰训练芯片，也别急着做通用加速卡。找一个具体且痛点明确的场景，比如端侧大模型推理、视频生成加速，把芯片做成场景专用，配合软件栈提供端到端方案。通用性越低，生态压力越小，活下来的概率越大。

如果你只是技术爱好者或个人研究者，不一定要流片。可以在FPGA上做AI加速器原型验证，或者基于开源指令集做软核实现，同样可以深入理解AI芯片的架构。芯片设计的乐趣和知识积累，不一定非得用一颗真正的硅片来兑现。

关于"新造一颗AI芯片"这件事，我做过的失败项目和见过的教训，最后都指向一个道理：芯片不是终点，而是整套系统工程的原点。比硬件更难的是让这颗芯片在正确的场景里、以正确的成本、被正确的软件生态承接。如果你问我值不值得，我的答案是——值得的前提是，你已经想清楚前面每一道题，而不是只看到算力缺口的诱惑。希望这篇思考能帮你少走一些我走过的弯路。