企业官网建设流程全解析

1. 新造一颗AI芯片，先想清楚这几个问题

“新造一个ai芯片的思考”——这个标题能引起很多人兴趣，但真正做过芯片的人都知道，这句话背后是大量现实问题。我不是芯片大厂的技术高管，只是一个在端侧AI领域摸爬滚打多年的从业者，做过模型部署，也参与过两三次芯片相关项目的早期评估。这篇文章想把我在这个过程中的真实思考、踩过的坑、以及最终形成的判断逻辑写下来。

先说结论：新造一颗AI芯片，技术难度远没有商业难度大。很多人以为难点在算力、在制程、在架构创新，实际上真正决定生死的往往是后面的生态、工具链、量产良率、客户验证周期。这篇文章适合三类人看：想做AI芯片创业的团队、正在评估自研芯片的公司决策者、以及单纯对芯片行业感兴趣想理解背后逻辑的普通读者。我不会堆一堆吓人的术语，而是尽量用行业里的实际经验来讲清楚这件事。

很多人会把“AI芯片”直接等同于“GPU”或“NPU”，但这是一个极大的误解。AI芯片是一个巨大的光谱：从云端训练用的超大算力芯片，到手机里那颗只有几TOPS的端侧NPU，再到摄像头里那颗专门跑人脸检测的小芯片，都是AI芯片。不同位置、不同场景、不同成本约束，决定了芯片的设计思路完全不同。如果你想把“新造一颗AI芯片”这个标题落成真正可执行的项目，第一步不是画架构图，而是先搞清楚你到底要做什么位置的芯片。

2. 第一件事：别谈“AI芯片”，先谈“给谁用”

2.1 云端训练、云端推理、端侧推理，是三条完全不同的路

我见过太多团队在项目早期犯同一个错误：把需求定义成“做一颗通用的AI芯片，既能训练又能推理，什么模型都能跑”。这个想法听起来很宏大，但实际上等于没有定义。因为训练芯片和推理芯片的成本结构、技术指标、客户预期完全不一样。

云端训练芯片，客户是各大云厂商和大模型公司。他们要的是绝对算力、显存带宽、互联能力。一颗训练芯片要考虑的是怎么让几千颗芯片组成一个集群还能高效工作，这里面的难度远超单芯片设计本身。

云端推理芯片，客户也是云厂商，但更看重每瓦性能、单位成本、延迟表现。推理市场比训练市场更大，但更分散。你需要在特定模型、特定Batch大小、特定延迟要求下证明自己的性价比。

端侧推理芯片，比如手机里的NPU、耳机里的语音芯片、摄像头里的视觉芯片。客户是终端厂商，他们最关心的是功耗、面积、成本，以及“算法能不能跑得动”。端侧芯片通常不需要跑大模型，但如果你的芯片能跑一定规格的多模态模型，那就是巨大的差异化优势。

这三条路的共同点是：都需要完整的软件栈。但不同点是：软件栈的复杂度和竞争格局完全不同。云端的CUDA生态壁垒几乎无法撼动，端侧反而还有缝隙可以切进去。如果你是初创团队，我个人的建议是优先考虑端侧或特定场景的推理芯片，而不是一上来就碰云端训练。

2.2 别做“更好的通用芯片”，要做“特定场景的最优解”

通用芯片领域的对手是谁？英伟达、AMD、Google、Amazon，每一家都有庞大的团队和几十年的积累。你做一个新的通用AI芯片，去和这些巨头拼通用性，几乎没有任何胜算。但如果你瞄准的是某个极度垂直的场景，情况就完全不同了。

举一个真实的例子：工业视觉检测。这个市场听起来不大，但需求非常刚性。工厂里的质检环节需要在极短的时间内完成缺陷检测，而且现场环境复杂，对功耗、可靠性、成本都有要求。通用GPU在这种场景下功耗太高、成本太贵，而且工业现场的部署条件往往不允许一个大机箱存在。一颗针对特定检测算法优化的芯片，功耗只有GPU的十分之一，成本只有几分之一，推理速度反而更快。这就是特定场景最优解的典型逻辑。

我看到很多团队在定义芯片的时候，总是想把所有AI算法都“支持”上，结果架构越做越复杂，最后流片成本高得离谱，性能又提不上去，陷入了“什么都能干，什么都干不好”的尴尬境地。正确的逻辑应该是：选定一个场景，搞清楚这个场景里跑的几个核心模型是什么，计算特性和访存特性是什么样的，然后围绕这些特性去定制架构。哪怕这颗芯片对外只能跑这几个模型，只要在这个场景里具备碾压性的性能或成本优势，就能找到客户，就能活下来。

3. 架构怎么选：从算力公式推导到指令集选择

3.1 先粗算一下：你的算力到底需要多大

很多团队在定义芯片时最容易被一个数字迷惑：XX TOPS。大家都在比这个数字，好像越大越好。但实际上，TOPS只代表理论峰值算力，真实落地时要除以一个效率系数，而这个系数往往低得让人吃惊。

做一个粗算：假设你想在端侧跑一个7B参数的大模型，单Token生成需要2倍参数量（约14 GFLOPs）的计算量。如果你希望在手机上达到20 Token/s的生成速度，需要的算力就是14 GFLOPs × 20 = 280 GOPS，也就是0.28 TOPS。听起来很小对吗？但这个计算没有考虑KV Cache的访存压力、Softmax等非矩阵运算的开销、以及内存带宽的限制。实际部署时，你需要的峰值算力往往是理论值的几倍甚至十几倍。

做芯片估算时，我建议用最简单也最可靠的办法：拿掉成熟芯片跑你的目标模型的实测数据，记录它用了多少算力、多少带宽，再按你的目标性能要求折算。不要凭空算，因为模型的实际计算量和理论FLOPs之间往往差着20%到50%的额外开销，比如注意力计算里的mask操作、位置编码、LayerNorm等。

具体部署性能和录绕计算能力，都应在完成模型选型、量化方案、算子融合策略之后才能核算，但“选型先行”的思路必须是固定的：先模型后芯片，不能先芯片后模型。很多硬件团队习惯先定算力指标再找模型适配，最后发现跑实际的Transformer时效率极低，因为访存模式和预期完全不同。

3.2 指令集选择：用RISC-V还是自研私有ISA

很多人会问：新做一个AI芯片要不要自研指令集？我的答案是：不要，除非你有足够的理由。自研ISA的代价不仅是设计指令解码器的工程量，更可怕的是整个工具链都要自己造。编译器、汇编器、调试器、反汇编器、模拟器，这些东西投入巨大，对初创团队而言是致命的。

更为务实的选择是以RISC-V为基础，做自定义扩展。RISC-V的Vector扩展（RVV）已经能覆盖大多数并行计算需求，而针对Transformer里的矩阵乘法、Softmax、GELU等算子，可以增加少量自定义协处理器指令或自定义向量指令。这样既保留了工具链的成熟度，又能在关键算子上实现专用加速。

我自己参与评估过的一个项目就是基于RISC-V做的AI扩展，最终只增加了不到20条自定义指令，却把特定模型的推理能效提升了近一倍。这说明RISC-V的自定义空间足够用，不一定非要“另起炉灶”才显得高级。

还需要考虑生态成熟度：RISC-V的软件栈这几年发展很快，已经有了官方的rvv-intrinsic文档、llvm和gcc的完整支持。很多端侧芯片团队已经在RISC-V上跑通了Andes、SiFive、平头哥等多个内核，这为后续的开发部署提供了宝贵的参考经验。对比之下，自研ISA意味着你连一个基础的开发板都得自己画，风险完全不在一个量级。

4. 核心设计权衡：算力、带宽、内存，一个都不能少

4.1 先说带宽：AI芯片真正卡脖子的瓶颈

很多第一次做AI芯片的人都低估了带宽的重要性。CPU时代靠频率取胜，GPU时代靠并行线程压峰值算力，到了AI推理时代，市场已经清楚发现：大部分模型的性能瓶颈不是算力，而是内存带宽。

用Transformer模型举个例子：推理时每生成一个Token，都需要把全部模型权重从内存搬到计算单元。7B模型用FP16存储，权重数据量约14GB。如果在DDR4-3200的平台上，理论带宽约25.6GB/s，意味着光搬运权重就要0.55秒。这种情况下，无论你芯片的TOPS标得多高，实际生成速度都会被带宽锁死在不到2 Token/s。

解决思路有三个：一是提高DRAM带宽，比如用LPDDR5/HBM，但成本和功耗会上升；二是减小权重体积，比如用INT4量化，把14GB降到3.5GB，这样同样带宽下Token速度翻了4倍；三是在片内缓存上想办法，把部分权重或KV Cache留在SRAM里，减少对DRAM的重复访问。

实际上，最终方案要把三者结合起来：合适的DRAM接口、激进的量化方案、智能的数据复用策略。请不要把TOPS当作核心KPI来定，带宽更值得认真考虑。一个合适的表达方式是“有效算力/带宽比”：在给定的模型、Batch大小、精度条件下，芯片实际能达到的算力利用率。这个值能到40%以上已经算不错了，60%以上是优秀水平。如果架构的阵列利用率只有20%，那标称的TOPS基本就是在骗客户。

4.2 存储层次怎么设计：SRAM不是越大越好

片内SRAM的大小直接影响性能，也直接影响芯片面积和成本。SRAM在芯片上非常奢侈，一颗28nm工艺下，1MB SRAM大约要占0.4~1平方毫米；如果做一颗100MB SRAM的AI芯片，光存储部分就可能占据超过一半的芯片面积，成本完全失控。

那怎么平衡？关键是访存分析。拿卷积网络来说，输入特征、权重、中间激活值各有不同的复用率。对卷积层而言，权重可以被batch内所有样本复用，这是天然的高复用；但中间激活值往往只能复用一次，根本不需要全部放在片上。分析模型对数据的最优复用次数之后，才能推算出真正需要的片上缓冲大小。

实际项目里有一个经验法则：先把目标模型按算子粒度拆开，统计每个算子的计算量和访存量，计算理论最优的计算访存比。再根据这个比值估算SRAM容量需求。通常你会发现，需求的理想值在几MB到几十MB之间，而真正的设计方案往往在性能和成本之间折衷，取一个偏小的容量，用流水线调度和双缓冲来隐藏DRAM延迟。

4.3 计算阵列怎么排：脉动阵列、SIMD还是可重构数据流

NPU核心的计算单元主流方案有三个：脉动阵列、SIMD+向量单元、可重构数据流阵列。

脉动阵列是Google TPU采用的经典方案，核心思路是把数据像水一样“流”过一整片计算单元阵列，每一级只做一次乘法累加再传给下一级。优点是数据复用率极高、控制简单，非常适合矩阵乘法。缺点是对非规则形状的计算（比如Transformer的Attention矩阵）支持不灵活，利用率会掉。

SIMD+向量单元是CPU/GPU的延伸路线，灵活性强，可以很好处理各种算子，但编译器调度和寄存器分配会非常复杂。可重构数据流阵列是近年学术热门，可以在运行时改变数据通路，灵活性很高，但编译器复杂度和验证难度几乎是前两者的两倍以上。

我的观点是：对初创团队来说，选择脉动阵列和向量单元的混合架构是最务实的方向。矩阵乘法用脉动阵列，其他算子（Softmax、LayerNorm、激活、量化）用向量单元。这样既保住了核心算力的效率，又具备处理非矩阵算子的能力。很多商业芯片也是这么设计的，例如各类NPU IP的方案中都包含“MAC阵列+向量处理引擎”的结构。

5. 软件栈：芯片成功的一半，甚至更多

5.1 只有硬件没有软件，芯片就只是一块石头

这是整个行业最容易被轻视的部分。很多人认为芯片流片成功就大功告成了，实际上流片成功只是第一步，后续软件工具链的工程量往往比硬件设计还要大、还要持久。硬件芯片验证顶多一到两年，而软件栈的收敛可能要三到五年。

完整的AI芯片软件栈包含几个层次：编译器（把PyTorch模型转换并映射到芯片上）、运行时（驱动、内存管理、任务调度）、算子库（针对芯片定制的高性能算子实现）、调试工具（profiler、日志系统、可视化工具）、以及模型移植工具（把PyTorch/TensorFlow模型转换到芯片的中间表示）。

以编译器为例，AI编译器需要做算子融合、量化插入、数据布局转换、内存规划等大量优化。主流路线是TVM、MLIR或自研编译框架。但无论选哪个，都需要大量工程师去做底层适配和调优。我见过一个芯片项目，硬件流片后半年了，模型还在跑不通CPU模拟器，就是因为编译器后端迟迟没做好。这个时候，芯片只能躺着吃灰。

5.2 直接支持PyTorch模型，比支持“全生态”更务实

很多芯片厂商都喜欢对标CUDA，号称“支持所有主流框架”。但实际上，对一颗新芯片而言，最重要的不是支持全生态，而是让主流的PyTorch模型能够轻松跑起来。第三方库的适配和算子覆盖是逐步累积的，一开始想覆盖全部等于什么都做不完。

当前AI模型迭代非常快，Llama、Qwen等大模型系列每个月都在发新版本。如果你的工具链只支持某个特定老版本，客户试一次就会放弃。所以，软件栈最重要的设计原则是“跟进速度”：新的公开模型出来之后，需要多快能在你的芯片上跑起来，并且精度和性能达标。这个速度常常比绝对的性能优化更加关乎生死。

我一般建议团队把“一个模型跑通”的时间目标定在两周以内。也就是说，从拿到一个新的PyTorch模型权重开始，到能在芯片模拟器或FPGA原型上得到正确结果，这个周期两周内闭环，才有商业化的可能性。

5.3 模拟器和FPGA原型：软件先行是铁律

很多团队在做芯片的同时就在做模拟器和FPGA原型，但优先级和投入往往不够。实际上，模拟器和FPGA平台应该跟芯片架构同步甚至前置开发。因为只有软件团队在真实模型上迭代，才能及时发现架构设计上的缺陷，比如某个算子的矩阵拆分方式不对、某处缓冲容量不够。这些如果在流片后才暴露，修改成本和周期都是灾难级的。

还有一个更现实的理由：客户合作需要早期评估。当你想和某个终端厂商谈合作时，对方很可能要求你先在一个月内把他们的模型跑在你的芯片评估环境上。如果只有一套不稳定的模拟器，这种合作几乎不可能推进。所以，FPGA原型系统不只是硬件验证工具，更是早期商务拓展的关键票证。

6. 成本账：流片、量产、工具链投入，别只看光罩费

6.1 流片费用到底要准备多少钱

流片费用经常被低估。很多人以为只算MPW（多项目晶圆）或者Full Mask的费用，实际上整个芯片研发成本远不止这一项。先进制程（7nm及以下）的MPW费用动辄几千万人民币，Full Mask更是上亿。而成熟制程（28nm或以上）的MPW可能只需要几百万，但性能和功耗竞争力也有限。

对初创AI芯片来说，我建议先问自己：我的产品真的需要7nm吗？端侧AI芯片的高性价比区间常常在28nm到12nm之间，这些制程的成熟度很高，设计参考多，IP丰富，流片风险低。而且核心卖点不依赖极致制程，而是靠架构和场景优化做出特性，这样的创业路径成功率更高。做一颗芯片，与其追求最先进制程，不如把需求场景做深、把功耗成本和周期做可控。

台面上的费用还包括IP授权费。PCIe、DDR、USB、SerDes等IP都需要采购，一颗端侧芯片的IP成本可能在百万元级别。在后续正式的量产投入上，光刻、封装、测试、良率爬坡，都是一轮又一轮的真金白银。芯片创业没有足够的融资储备，连初版流片都不一定走得到。

6.2 量产的隐性成本：良率、封测、失效分析

流片成功不等于产品可用。量产阶段良率爬坡往往需要好几个月，刚开始的良率可能只有50%甚至更低，这一点在先进制程上尤其明显。芯片制造、封装、测试环节的成本，在总成本中的占比也会逐渐变大。

更麻烦的是失效分析：AI芯片内部有大量重复的计算单元，任何一个单元出问题，性能可能降级但功能可能仍正常。这类“部分失效”的芯片在测试环节很难完全识别，容易在客户现场才暴露。很多成熟厂商会准备一套利用“坏件降级”的逻辑，比如把多核芯片中的坏Core屏蔽掉，做成更低规格的产品出售，这样良率的损失能被补回来一部分。

对于初创公司，我的建议是：在产品定义初期就规划好“多版本SPU策略”。同一颗芯片，通过屏蔽部分计算单元、降频、裁剪规格，形成高、中、低三个产品线，这样既可以提高良率利用率，也能覆盖更多价格敏感的客户。

6.3 工具链投入有多大：往往是芯片成本的1.5到2倍

这是一个非常容易让投资人惊讶的数据：一颗AI芯片的软件工具链投入，往往比芯片本身的设计成本更高。从编译器、算子库、到模型适配和调试工具体系，一个完整软件团队的规模至少是硬件团队的一半，甚至持平。而且软件团队的支出是持续性的，芯片流片完成后，软件团队还要继续服务客户、适配新模型、修复问题，这个周期可能是五到十年。

如果预算有限，一个务实的策略是“复用生态而不是重建生态”：尽量基于TFLM、TVM、ONNX Runtime等开源运行时做适配，集中精力在高频算子和编译器后端上做突破，而不是从头写一套全自研的框架。这样能用两到三个人的工作量，解决大部分通用模型的适配成本。

7. 生态突围：在巨头的夹缝里找到自己的位置

7.1 不要试图挑战CUDA生态，要找巨头不屑于做的场景

说这句可能会让一些人不舒服，但在AI芯片行业里，现实就是如此残酷。CUDA不只是硬件接口，而是一整套经过十几年打磨的生态体系。想做训练芯片、想做通用GPU替代者，就要面对的是全世界最庞大的开发者生态和十几年积累的软件资产。这不是技术问题，而是时间不可压缩的问题。

好消息是，AI推理时代出现了大量垂直场景，巨头并没有精力一一覆盖。例如：智能座舱里的多模态交互芯片、工业缺陷检测的专用加速器、边缘视频分析的摄像头AI芯片、医疗器械里的AI推理加速模块。这些场景的共同点：模型相对固定、延迟要求高、功耗成本敏感、客户不愿意为通用算力过度买单。在这些场景里，新的专用AI芯片有实实在在的机会。

以智能座舱为例，要同时跑语音识别、手势识别、疲劳监测、多路摄像头感知，传统方案要么用一颗大算力GPU，功耗高成本高；要么用多个小芯片拼接，软件复杂度高。而一颗专门为座舱AI设计的芯片，如果能在一颗芯片里把多路视觉语音处理得又好又省电，就非常有竞争力。这些需求在文档和公开资料里都能感受到明确的趋势信号，终端厂商也确实在积极寻找替代方案。

7.2 与客户做联合定制：让你的芯片一开始就有“锚点用户”

芯片最危险的阶段是“流片后无客户”。为避免这个结果，最好在定义初期就找到一两个核心合作客户，让他们深度参与需求定义和模型选型。这通常被称为“Marquee Customer锚点客户”策略。

跟客户联合定制的好处非常实际：一方面，芯片的第一个版本就是按客户的真实模型和需求做的，验证目标非常具体，合作推进速度会快很多；另一方面，由于拿到了大客户背书，后续其他客户跟进时更有信心。这在芯片行业里是相当普遍的破局方式，尤其适合初创公司。

但联合定制也有一个需要警惕的坑：不要做成一锤子买卖。如果芯 芯片完全按照客户的某一个私有模型定制，模型一变，芯片就废了。比较合理的做法是：确定一个模型家族或算子模式（比如某种量化的Transformer），在这个范围内做定制，即使具体模型参数变了，芯片依然能高效运行。

7.3 开源策略：芯片也能走“开发者优先”路线

端侧AI芯片有个特点：开发者的使用门槛直接影响产品采纳率。如果在早期能把部分软件栈、SDK和模型示例开源出来，就能吸引一批独立开发者和中小客户先行试用。这种模式在RISC-V和嵌入式领域已经被证明有效，AI芯片同样可以借鉴。

但开源也要想清楚边界：核心算子库和编译器后端建议保留一部分独家优化能力，避免被复刻；SDK、示例、模型转换工具可以开源。这样既获得了生态，又不至于把自己的核心壁垒暴露在竞争对手面前。更关键的是，开源后的反馈能快速帮助你的软件团队发现工具链的痛点，比内部测试要高效得多。

我见过一个做端侧视觉芯片的团队，他们的策略就是在GitHub上公开了一套模型部署示例和性能评测报告，很多中小集成商看到后主动联系他们，把芯片方案集成到了自己的产品里。这种方式前期听起来很慢，却是在巨头生态夹缝中慢慢积累信任的稳妥路径。

8. 大模型浪潮下：新的AI芯片该不该押注LLM

8.1 端侧大模型是机会，但不是每个团队都适合追

随着小尺寸语言模型在端侧逐步落地，越来越多的AI芯片团队开始把“跑大模型”作为卖点。这个大方向没有错，尤其是多模态能力正在快速往终端渗透，端侧AI芯片如果能高效跑通7B甚至13B级别的量化模型，就具备很强的差异化优势。

但这里有两个现实问题。第一，大模型的迭代速度极快，芯片的架构固化周期却长达两到三年。今天你针对Llama 3的架构做定制优化，明年新模型可能就换了一种注意力实现或新tokenizer，你的硬件可能就跑不动或效率大降。第二，端侧跑大模型的场景并不一定是刚需，很多应用场景用云端方案更简单更反复迭代。

我的建议是：芯片架构要针对“Transformer基本算子族”做通用加速，而不是针对某个单一模型做优化。矩阵乘法、注意力计算、KV Cache管理、量化算子、激活函数、位置编码，这些都是Transformer生态的共性。只要把这些共性算子做扎实，无论模型怎么迭代，芯片都能保持较高的适用性。

8.2 量化能力：比算力更值得大力投入的方向

要想在端侧高效跑大模型，INT8已经不够，INT4甚至INT3量化成为核心能力。量化不仅是把权重变成低比特，更需要在推理过程中处理好激活值的动态范围、离线校准、混合精度等细节。这会直接影响模型的输出质量和稳定性。

很多团队低估了量化支持的工作量。一个看似简单的INT4矩阵乘法，要做到高精度、不损失模型效果，需要在量化校准算法、硬件溢出处理、饱和策略等方面做大量打磨。而一旦偏离了训练框架里标准量化流程，精度恢复就成了一个长期工程。

因此，在对芯片架构做规划时，不要只考虑FP16/BF16的高精度计算能力，也要为INT4/INT8设计相应的计算路径和数据通路。将来你会发现，很多客户真正看重的是低比特量化后的实际精度效果。把量化做得足够好，甚至比单纯把TOPS做高更能打动客户。

8.3 从推理往训练延伸是陷阱还是机会

很多团队流片稳定后会考虑往训练方向延伸，比如支持LoRA微调、支持边缘侧的轻量训练。这个方向有一定空间，但风险也不小。训练任务在反向传播时涉及大量的梯度张量存储和数据复用，对Buffer和带宽的要求比推理高很多。硬件的复杂度会呈指数上升。

更为稳妥的选择是：先用推理芯片把产品市场站稳，等收入和客户基础积累到一定规模之后，再去评估训练扩展的必要性。不要在一代芯片上同时追求推理和训练能力，否则很可能两边都做不好。

9. 我的个人判断与实践建议

9.1 新造AI芯片的成败关键，通常不在芯片本身

复盘很多失败的AI芯片项目，最终原因往往不是芯片性能不达标，而是销售周期太长、资金链断裂、软件工具链迟迟不能用、或者没有在关键时间点拿到锚点客户。芯片行业是一个“长时间、强验证、重生态”的行业，想做好它的关键，其实是把项目拆成多个阶段去验证，而不是一口气把所有问题留到流片后解决。

这决定了团队的组织形态和资金规划。一款新芯片从立项到量产，哪怕一切顺利也至少需要24到36个月。如果你的资金只能支撑18个月，那么从一开始就应该把产品定义范围砍半，优先把最小可用版本做出来，而不是追求满足所有想象空间。

9.2 从FPGA原型开始找客户，比什么都重要

芯片行业有个不成文的经验：流片前的FPGA原型系统是最高效的商务工具。当客户看到一个真实的FPGA开发板在跑他们的模型，并且能给出达到目标的功耗和性能数据时，合作信心会大幅提升。

但FPGA原型的设计也要贴近真实芯片：内存控制器行为、带宽限制、算子支持范围都要尽量模拟最终芯片。如果FPGA上的性能比芯片乐观很多，客户在POC阶段的表现就会被“硬刺破”，造成信任崩塌。很多团队喜欢拿FPGA的验证结果刻意宣传，但最终都会在真正的ASIC验证阶段付出代价。

我的建议是：FPGA原型性能可以比最终芯片稍弱，但绝不能明显乐观；在客户交流时，要把模拟器和FPGA的差距明确讲清楚，建立长期信任比短期展示更重要。

9.3 如果让我重来一次，我会怎么做

假如现在让我重新负责一个“新造一颗AI芯片”的项目，我会按这样的顺序推进：

第一，花至少两个月的时间完成场景和模型调研，不画任何硬件架构图，只回答“哪一部分客户愿意为AI能力付费”和“他们现在最痛的点是什么”。

第二，选定一个垂直场景。选10个场景里你最熟悉的那个，做深度评测，用GPU模拟目标模型的性能和算力需求，确定大致的算力、带宽、SRAM和量化方案预算。

第三，找一个锚点客户，共同定义规格书（Spec），签下早期意向合同，让客户参与到原型验证中。

第四，先做FPGA原型和完整软件工具链，跑通客户的核心模型，拿到准确的功耗数据预测，再开始RTL设计和流片。

第五，流片的同时准备量产测试方案，以及“多版本套路”（通过屏蔽Core等方式形成多个产品档位）来扩充客户覆盖。

第六，流片回来之后，先用两到四周时间做基础验证，然后就立刻进入客户模型适配和性能调优阶段。如果这个阶段超过三个月还没跑通目标模型，说明软件栈的底子没打好，要立即替换负责人并调整资源配置。

这套流程看起来慢，实际上是把风险前置，让最昂贵的流片环节到来之前解决大部分不确定性。很多人做芯片习惯“先硬件后软件”，我经历过几次之后反而坚信：软件是否就绪，才是决定芯片项目该不该流片的判断点。

10. 另一点容易被忽视的：团队组织与节奏控制

10.1 不要迷信“全栈自研”，跨界协作才更可能成

芯片项目天然是一个跨界工程：硬件架构师、数字前端、后端、验证工程师、编译器工程师、算法工程师、驱动工程师、商务拓展，这些人语言体系完全不同，沟通成本极高。很多项目进度拖延，不是技术难题，而是团队之间的“翻译”出现了障碍。

解决方式是在项目早期设立“系统架构师”和“系统验证工程师”两类角色，他们的工作不是写代码或画电路，而是横向对齐软硬件需求和验证标准。让编译器工程师直接参与架构设计评审，让算法工程师在芯片设计早期就提供关键模型的访存分布图，这些细节如果不前置，后期返工的成本是灾难性的。

10.2 版本意识：不要在最开始就定义终极形态

芯片项目很容易犯“野心过大”的毛病。第一代就想做全功能、全场景、全精度支持，最后发布时间一拖再拖，成本严重超出预算。更务实的做法是做一个边界清晰的MVP（最小可行产品）——只支持几个核心算子和模型类型，其他功能留到下一代。虽然MVP的客户覆盖面窄，但它能帮你更快流片、更快验证商业模式、更快积累客户信任。

造芯片和做互联网产品一样，要控制贪婪。你在第一代砍掉的那些功能，会让这个项目活下来；你在第一代强塞进去的那些功能，则常常让这个项目死在流片之后的漫长调优里。

11. 聊聊我对未来的整体感觉

关于新造一颗AI芯片的思考，整理到最后，我非常坚定的一点是：这个行业的窗口期并没有关闭。GPU依然在云端训练上保持统治地位，但AI应用正在从云端向端侧、从通用模型向垂直场景快速扩散，这种扩散并不遵循“算力随便买”的逻辑，而是更加关注每瓦性能、总成本、时延和场景适配能力。

未来的AI芯片市场很可能不是“大一统”的格局，而是“专芯专用”的细分生态：每家的芯片在某个具体场景里形成最优解，然后围绕这个场景构筑软件壁垒。这对新入局者是有利的，因为专用场景需要快速响应和深度定制，这恰恰不是巨头的最强维度。

同时我也要提醒一句：芯片不是AI唯一的关键路径，但它是承载AI落地最底层的实体支撑。做芯片的这波人，如果能在模型算法、软件栈与实际场景之间找到正确的交集，将有机会比做大模型的公司更像长期主义。只是这条路既需要技术判断力，也需要商业耐心，还需要一点点运气。

我个人的体会是：不要被“算力越大越厉害”的想法绑架。很多项目的真正卡点，在于能否把一颗小但够用的芯片，在正确的时间点递到对的客户手里。从做AI芯片的那一天起，就必须同时学会做一个场景专家、算法专家、软件工程专家和商业谈判专家。这个过程很累，但非常值得。