寒武纪MLU芯片架构：硬件设计与计算能力

可视化演示

展示进程-资源分配图，通过有向图环检测算法自动识别死锁状态，切换不同配置观察死锁形成。

整体架构布局：一张“超级中央厨房”的设计图

想象你正在经营一家为整座城市供餐的“超级中央厨房”。这家厨房不是一开张就把锅碗瓢盆乱堆一气，而是先画好设计图：炒菜区、备菜区、冷库、传菜通道各占一角，每个区域互相配合又不抢道。寒武纪MLU芯片的架构设计，就像画这样一张厨房设计图——先把功能分区规划好，再考虑怎么让各个区域高效协作。

MLU把芯片划分为几个明确的功能域。计算核心域相当于灶台区，所有张量处理核心（TPC）都集中在这里；存储与IO域相当于仓库和出入口，负责运进数据、送出结果；控制调度单元则像厨房总指挥，负责下发指令、协调各区域的工作节奏。这种模块化布局的最大好处是：不同功能块可以并行运转，互不干扰，也不会因为某个区域拥堵而拖垮整条流水线。

在芯片物理实现上，各个模块通过片内总线相连，数据与指令沿着总线流动。控制调度单元下发一条指令，计算核心域执行运算，存储域供应数据——三者就像一台精密运转的机器。但现实并非完美并行：计算单元等数据时只能空转，存储单元忙不过来时计算单元也只能等待。任何一个环节慢下来，整条线的效率都会被拖低。这种串行等待的关系，可以用一个简单的延迟模型来描述：

这三部分时间累加，就是一次完整任务的耗时。所以工程师优化MLU时，不只是让灶台（计算单元）火更大，还会让备菜更快、传菜通道更宽，把每一部分时间都压下去。这正是“整体架构布局”的核心思想：先搭好合理的框架，再谈局部提速。理解了这张设计图，后面所有模块的讨论就都有了地图上的坐标。

张量计算单元：掌勺大厨与配菜师团队

超级厨房的核心是掌勺的大厨。MLU芯片的“大厨”是围绕张量计算设计的众多张量处理核心（TPC）。TPC并不是单打独斗，它内部包含三种角色：矩阵运算引擎、矢量运算单元和累加器，分别像大厨、配菜师傅和调料称量师。三者配合，才能把一道AI“菜”高效做出来。

矩阵运算引擎专门处理深度学习中最常见的矩阵乘法。矩阵乘法可以比喻为按菜谱配菜：矩阵A的每一行是一份菜谱的配料需求，矩阵B的每一列是一种食材的配给清单，两者相乘得到每道菜的最终用量矩阵C。深度学习模型的卷积、全连接等操作，本质上都可以拆解为矩阵乘法，因此矩阵运算引擎的吞吐直接决定了芯片的AI算力：

除了矩阵运算引擎，TPC还配备矢量运算单元，负责处理逐元素的激活函数、归一化等操作，就像配菜师傅把各类配料备齐；累加器则以更高精度保存中间结果，避免多次累加造成精度损失，如同用精密电子秤称量调料，保证每份菜口味稳定。算子映射则是把AI模型里的各种算子翻译成TPC上可执行的指令序列，相当于把菜谱翻译成厨师能看懂的步骤卡。理解了TPC内部的分工，就明白为什么AI芯片如此看重“张量”——因为深度学习模型几乎全是矩阵运算的组合。

片上存储层次：备菜台与小冷库

厨房要快，食材就不能总从远处的大冷库搬。MLU在芯片内部安排了多级片上存储——SRAM。SRAM容量不大，但速度极快，相当于灶台边的备菜台：食材现取现用，不用每次跑大冷库。整个存储层次像一个金字塔：越靠近计算单元，容量越小、速度越快；越远离，容量越大、速度越慢。

片上存储设计讲究分级缓冲。数据先从外部大容量内存（如HBM）搬进片上SRAM，再被计算单元取用。计算单元直接访问SRAM的速度比访问HBM快一个数量级，但如果数据搬进SRAM后只用一次就丢弃，带宽就白白浪费了。所以MLU特别强调“数据复用”——让同一份数据被多次使用，减少重复搬运。这就像一份高汤被多个菜品反复取用，而不是每道菜都重新熬一锅。

带宽是整个系统的生命线。存储带宽B表示每秒能搬运多少数据。对于采用双倍速率（DDR/HBM）的接口，带宽由接口频率、数据位宽和双倍速率共同决定：

实际应用中，一次矩阵乘法需要把输入特征图、权重从HBM搬到SRAM，再流经计算单元。如果数据复用设计得好，一次搬运可以支撑多次乘加运算，计算利用率就会显著提升。这正是“用搬运次数换计算效率”的智慧：SRAM容量不是越大越好，关键是让每一块SRAM里的数据都被榨干价值。

互联与带宽：传菜通道与冷库传送带

一家大型厨房，炒好的菜要同时送往几十个包间；一个多芯片AI系统，数据要在不同芯片之间高频流动。MLU的互联方案就是为AI“吃数据”而生的传菜系统。没有畅通的传菜通道，灶台火力再旺，菜品也送不出去。

片间互联解决的是“多张卡怎么协作”的问题。训练大模型时，单张芯片装不下全部模型参数，需要多块MLU组成集群。片间互联通道把多块芯片连成一张大网，每一跳都在搬运着梯度与权重。HBM接口则是芯片与外部高带宽内存之间的“冷库传送带”，提供数TB/s级别的带宽，确保计算单元永远有数据可算。PCIe通道主要负责与主机CPU通信，相当于厨房对外的进货大门，接收指令和预处理后的数据。

多条通道并行，总带宽叠加。如果每条通道的带宽为 $B_{\text{per}}$，共有 $N_{\text{link}}$ 条通道，则聚合带宽为：

除了带宽，还有一致性协议在幕后工作。多块芯片同时读写同一份数据时，一致性协议保证大家看到的是最新值，避免“数据打架”。这就像多个厨房共用一个食材账本，必须确保谁取了多少都记录清楚。缓存一致性是复杂但必要的机制，也是国产互联方案走向成熟的关键挑战。

算力评估指标：出菜速度的核算方法

饭店好不好，不看灶台最大火力，而看实际翻台率。评估MLU芯片，也不能只盯标称峰值算力。峰值算力是理论极限，相当于所有大厨拼命颠勺时的极限出菜数；真实项目里，还要看能效比、实际利用率和模型吞吐，这些指标共同决定了芯片在真实负载下的表现。

能效比衡量的是“每度电做多少菜”，即每瓦特功耗能完成的计算量。对数据中心而言，电费是运营成本的大头；对边缘设备而言，功耗直接决定散热方案和电池续航。因此能效比是AI芯片的重要评价维度。而实际利用率则反映了计算单元在真实任务中被有效使用的程度：

实际利用率和峰值算力之间的差距，往往就是存储带宽和互联带宽拖的后腿。一个模型在MLU上的吞吐，即每秒能处理多少样本，是用户最关心的终极指标。它综合反映了架构设计与软件调优的水平。“能用上的算力才是真算力”，这句话解释了为什么有些芯片标称算力很高，跑起真实模型却不如预期。选型时，务必用真实模型跑一跑吞吐和利用率，而不是只看宣传册上的数字。

场景适配优化：不同宴席的接待方案

超级中央厨房要应对各种宴席：婚宴、商务宴、外卖单。MLU也需要针对不同的AI工作负载做适配优化。最常见的两类场景是训练与推理，它们的需求差异很大，就像研发新菜谱和按菜谱批量出菜是两种完全不同的活儿。

训练场景像研发新菜谱：要反复试验、调整配比，需要高精度和大批量数据，计算强度极高，对存储带宽的消耗也非常大。推理场景像按已定菜谱批量出菜：延迟要低、吞吐要高，精度要求相对宽松，可以适当使用低精度量化（如FP16/INT8）来提速。因此MLU在不同场景下会采用不同的数据精度和算子调度策略，例如训练用FP32保证收敛质量，推理用INT8换取更高吞吐。评价适配效果，常用加速比。假如一个模型在原平台的运行时间是 $T_{\text{baseline}}$，在MLU上的时间是 $T_{\text{MLU}}$，加速比为：

典型模型方面，卷积网络（如ResNet）在MLU上表现优异，因为卷积可以映射为大量并行矩阵运算；Transformer结构则对存储带宽和互联要求更高，是新一代芯片优化重点。性能调优时，工程师会把小算子融合成大算子、调整数据在SRAM中的排布、选择合适精度，让每一拍时钟都用在刀刃上。就像厨师会根据宴席类型调整备菜流程——宴席不同，后厨的动线也要跟着变。

软件栈配合：菜谱管理与配菜师

光有灶台还不够，厨房正常运转还需要菜谱管理软件、预制菜包和熟练的服务员。MLU的软件栈就是AI芯片的“操作系统与服务体系”。寒武纪推出的CNToolkit是完整的开发工具链，内置编译器、调试器和性能分析工具，把开发者写的AI模型编译成MLU能执行的指令序列。

算子库CNNL就像预制菜包：把常用的卷积、归一化、池化等算子预编译好，开发者直接调用，不用从零手写底层实现。框架适配层则负责对接TensorFlow、PyTorch等主流深度学习框架，让开发者几乎无感地切换硬件后端——就像点菜系统升级了，但顾客点菜的方式没变。当模型从CPU/GPU迁移到MLU时，数据要经过主机端再到设备端，端到端延迟可以记为：

虚拟化与多卡管理让一块物理MLU可以分割给多个用户使用，就像厨房里的多个档口共享中央资源。完整的软件栈决定了芯片的“好用程度”：硬件是实力，软件是演技，两者配合才能把芯片性能真正发挥出来。对开发者而言，选芯片也是在选软件生态——工具链顺不顺，直接决定项目落地的速度。

AI 应用场景

Python 演示

"""MLU两级流水线模拟器模拟数据块依次经过"搬运(Load)"和"计算(Compute)"两个阶段,展示流水线重叠如何提升整体吞吐与部件利用率"""  class MLU_PipelineSim:    """模拟MLU上数据搬运与计算两级流水线"""     def __init__(self, load_latency=4, compute_latency=6):        self.load_latency = load_latency      # 搬运阶段耗时(周期)        self.compute_latency = compute_latency  # 计算阶段耗时(周期)        self.load_free = 0      # 搬运单元下次空闲时刻        self.compute_free = 0   # 计算单元下次空闲时刻        self.load_busy = 0      # 搬运单元累计忙碌周期        self.compute_busy = 0   # 计算单元累计忙碌周期     def run(self, num_blocks):        """按贪心调度送入 num_blocks 个数据块"""        finish_time = 0        for _ in range(num_blocks):            load_start = max(self.load_free, 0)            load_end = load_start + self.load_latency            compute_start = max(load_end, self.compute_free)            compute_end = compute_start + self.compute_latency             self.load_free = load_end            self.compute_free = compute_end            self.load_busy += self.load_latency            self.compute_busy += self.compute_latency            finish_time = compute_end         return {            "总耗时": finish_time,            "搬运利用率": round(self.load_busy / finish_time * 100, 1),            "计算利用率": round(self.compute_busy / finish_time * 100, 1),        }  if __name__ == "__main__":    print("===== MLU 两级流水线模拟 =====")    for n in [1, 4, 20]:        sim = MLU_PipelineSim(load_latency=4, compute_latency=6)        result = sim.run(n)        print(f"数据块数: {n:>2}  总耗时: {result['总耗时']:>3} 周期  "              f"搬运利用率: {result['搬运利用率']}%  "              f"计算利用率: {result['计算利用率']}%")

1. compute_start = max(load_end, self.compute_free)计算必须等数据搬运完成且计算单元空闲，这是流水线调度的核心约束
2. self.load_free = load_end更新搬运单元的可用时刻，让下一个数据块能紧接着开始搬运
3. self.load_busy += self.load_latency累计搬运单元的忙碌周期，用于最终计算利用率
4. for _ in range(num_blocks)顺序调度所有数据块，模拟真实场景中连续不断的数据流
5. round(self.load_busy / finish_time * 100, 1)用忙碌时间除以总耗时算出利用率百分比，直观反映部件空转程度

常见误区

面试题