芯片架构设计是芯片流片前很重要的一个环节，俗称pre-silicon，芯片架构设计的好坏，决定了芯片产品的质量，决定了芯片产品是否易用，决定了芯片产品的性能，决定了芯片产品在市场上是否具有持久性。芯片生产是个大工程，芯片硬件和芯片软件具有非常不同的特性，芯片软件在release后可以持续完善和优化，但芯片硬件一经流片就无从更改（重新流片一次要几千万）。
打个形象的比喻，芯片架构设计就像大楼施工前的图纸设计，各种事情（户型，地基，车位，绿化，布线，监控，采暖，上下水，采暖，空调，通风，电梯，安全，材料选取，成本等）都要考虑好，一经施工，无从更改，要么成为精品小区，要么成为烂尾楼。
芯片架构设计概览
在架构设计前，需要进行市场需求调研，同时进行竞品调研，保障芯片在生产出来的时候，能满足市场需求，能有更大竞争力。
市场需求调研
目前大语言模型和多模态模型蓬勃发展，芯片设计前需要进行尽可能多的市场调研，涉及如下方面：
-大模型的模型规模和计算类型是什么趋势？算力和带宽需求是什么？
-大模型的输入sequence length是否更长？多模态模型和LLM模型的输入sequence length有什么区别？
-芯片是面向大模型的推理，还是训练？市场需要的性能目标是什么？
-是否需要互联？互联带宽多少？
-未来的大模型的技术变化趋势？什么样的attention优化技术是最优的？
-芯片的面向客户对各种low precision的接受度和需求度如何？
-芯片面向客户的编解码需求是什么样的？性能指标是什么？
-客户的部署习惯影响芯片的使用和设计，一定要摸清？客户业务的痛点是什么？
-存储需求是什么样的？
-芯片需要达到的性价比指标是什么？
-客户的软件生态是什么样的？
竞品调研
竞品调研主要考察当前市场上比较top的芯片厂商的软硬件设计情况，同时，预测各厂商的未来技术趋势，目前大模型背景下，市场上比较top的芯片厂商如下：
-英伟达
-AMD
-谷歌
-华为
硬件架构设计
1.top厂商的芯片架构概览
nvidia gpu架构
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
最上面图是H100的总体架构，最下面图是一个SM内部的架构图，详细可以看白皮书。
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
tpu架构
添加图片注释，不超过 140 字（可选）
添加图片注释，不超过 140 字（可选）
昇腾架构
添加图片注释，不超过 140 字（可选）
2.硬件架构设计需要考虑的事情
整个的芯片设计的主要部分是SoC的设计，system on chip，SoC是由许许多多的IP组成的（自己设计或者买第三方的），chip designer的任务就是将这些IO装进SoC这个大箱子，装得要多，性能要好。大概需要考虑如下事情：
-面积
面积太小，放不下那么多资源，面积太大，同比竞品竞争力差（成本高）
-功耗
功耗低，供电不足，处理跟不上，功耗高，费电（大数据中心的电费还是很可观的）
-频率
整个芯片有一定的工作频率，每个IP也有自己的工作频率，高频率干活快，低频率干活慢。
-颗粒
纳米决定能装多少东西，尺寸有多大，目前美国就是在这方面卡我们脖子。台积电已经能做3纳米了。
-存储
用hbm，还是用gddr，这两者存储大小，峰值带宽，价格差距较大，需要根据模型应用需求和性价比考虑。目前芯片其实主要是在卖存储，所以搞存储的闷声发大财（尤其是在当前大模型背景下）。
-cpu core
无论是host端cpu core的数量及并行度，还是device端cpu core（例如，华为昇腾架构内的AI cpu core）的数量及并行度，都影响任务的异构并行处理，因为有些是适合device的AI tensor或vector计算任务，有些是适合cpu的非规则计算任务（例如，图和树的遍历与检索）。
-host和device间的访问延时与访存开销
需要考虑host与device间的通信一次的latency，因为有可能需要多次互通。
需要考虑host memory与device memory的互访互联及带宽，对大模型和推荐系统（embedding table）有益，可以看看nvidia的grace Hopper+grace cpu架构：
添加图片注释，不超过 140 字（可选）
-uvm统一虚拟内存，unified virtual memory
可以带来编程与处理的便捷性，可以很灵活的调度存储flow
-device memory bandwidth
带宽越大，传输越快，利于memory或IO bound的任务，所以，具体要看你的需求和场景，取决于选多大的带宽合适（既便宜，有满足需求）
-多级存储及shared memory(例如，nvidia)
需要考虑要几级memory?要不要dma？每级memory多少存储空间？这个其实和你的任务需求也是有关的，和你调度任务流水的方式也有关。
-多级cache(例如，nvidia的L1/L2)
你的cache有多少级？每级cache多大？指令cache和数据cache如何划分？cache的一致性和maintenance如何保障？硬件预取和软件预取是否完善？预取latency是多大？
-算力
算力，和带宽一样，其实是一个重要的指标？和场景与客户需求有关。需要什么精度的计算？每种精度的TOPS或TFLOPS是多少（取决于你的任务的TFLOPs或 TOPs）？需要稀疏计算（结构化稀疏，还是非结构化稀疏）吗？
-执行与调度模型
你的runtime的调度机制是什么样的？能支持最大outstanding是多少？
采用simd还是simt架构？simt架构的线程数及资源分配如何？simt的多线程调度开销如何？多线程间是否能隐藏指令流开销？
如果你只处理向量或matrix计算，那么，simd可能是最高效的，不需要simt的灵活性。如果你处理标量任务，那么，simt（如，nvidia implicit simd）可能更好。详细的simd与simt的机制最好熟练掌握。
-总线宽度
总线宽度和处理数据位宽，其实对调度很有影响取决于你的任务或需求粒度。
-互联拓扑和带宽
对大模型训练影响很大。
软件架构设计
芯片设计，讲究一个软硬协同设计，如果不考虑软件或客户的使用方式，不从top down是看架构设计，那么，设计出来的芯片硬件大概率是烂尾楼，兼容性差，迁移性差，软件编程难用，过分注重单一计算或单一模型（性能泛化差），等等一系列问题和痛点。
具体关注哪些？
-pytorch等框架或客户框架的eager mode和图模式分别如何执行的？
-框架或客户需要什么样的算子或api？
-模型的变种如何的？输入输出形状如何变化的？如何做通用支持？不要受限于具体形状或固定pattern。
-软件栈如何兼容c++语法？如何用最直接的方式编程？这些映射到硬件需要满足什么需求？例如，cuda
-软件的编码方式和生成的code size多大？例如，cuda
-模型部署方式？都线程？多进程？多模型并行？
-不同计算类型？每种类型的利用率分析？模型内的多分支结构？框架的多operator并行调度？
-你是否让用户关注了太多软件细节和调度细节？资源分配细节？这个导致软件不好用，软件可能本身也不是这样用的。
-算子的数据流编写方式需要反馈硬件，协同设计。
总之，希望以客户需求和习惯为目标，以技术发展趋势为原则指导芯片设计，坚持top->down，而不是down->top。
性能评估与建模
一个好的建模平台，对架构设计至关重要，因为架构设计之前，没有实实在在的东西，都是虚的，需要验证的内容太多，建模平台完备主要体现：
-灵活配置资源，验证各种数据流和计算流
-底层cost model健全，仿真器更趋向于真实硬件
-benchmark健全，测试无死角