芯片架构设计及其作用

芯片架构设计是芯片流片前很重要的一个环节，俗称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健全，测试无死角