简介：《基于存算一体集成芯片的大模型专用硬件架构》是一份面向大模型硬件架构研究者、芯片设计工程师与高校相关专业师生的学术论文PDF，聚焦大模型部署中的数据传输带宽瓶颈与数据中心能耗压力。文件共1个PDF，约3.49MB，完整收录何斯琪、穆琛、陈迟晓发表于《中兴通讯技术》2024年第30卷第2期的文章，便于检索、引用与精读。内容围绕存算一体集成芯片与集成芯粒方案展开，分析传统计算与存储分离架构的局限，并讨论轻量化—存内压缩协同设计、稀疏网络在存算一体硬件上的稠密映射等实现思路，对理解大模型推理能效优化和专用硬件设计具有参考价值。已有140人学习，适合作为架构调研、论文写作或技术方案论证的参考资料。

1. 为什么大模型推理通常会卡在“搬数据”上：一笔带宽账决定的架构选型

给一个 70 亿参数的大模型做推理硬件方案，最先被推翻的往往不是算力预算，而是带宽预算。按每秒一万个令牌的实时速率计算，仅仅把权重从存储搬到计算单元，就需要每秒几十太字节的搬运能力，而当前主流的高带宽存储封装单栈只有每秒零点几太字节的量级，多栈堆叠也补不上这个缺口。这个缺口不是靠堆容量能抹平的，它直接决定方案走向：计算和存储到底要不要贴在一起。基于存算一体集成芯片的大模型专用硬件架构，解决的就是这笔搬运账：把权重固定在存储阵列里，让乘加在数据所在的位置发生，再用芯粒集成绕开单芯片的面积与良率天花板。这套思路适合两类人：要做一份完整硬件架构毕设或课设的学生，以及要给推理加速卡做选型论证的工程师。

2. 带宽瓶颈如何计算：从参数规模到芯粒接口速率

架构方案里最容易空泛、也最容易被导师或评审追问的地方，就是“带宽不够”这四个字。不够多少、缺在哪个环节、换成什么结构能补上多少，必须能算。这一章把这笔账拆成三层：模型侧的增长曲线、系统侧的搬运量、器件侧的算力存储比。三层算完，架构选型就不是拍脑袋，而是被数字推出来的。

2.1 参数规模、算力需求与单芯片面积的三条天花板

先看模型侧。以注意力机制为基础的大模型在近几年呈现出一种近乎失控的增长：参数规模大约每两年增长 240 倍，对应的算力需求增长接近 750 倍。而通用硬件每两年大约只有 3.1 倍的提升，并且已经逼近物理极限。三条曲线放在一张图上，缺口就是逐年拉大的剪刀差，这个剪刀差最终会以“推理成本”的形式落到数据中心账单上。

再看制造侧。传统超大规模、超大面积的单芯片 SoC 方案，在面积继续放大时会同时遇到四个问题：晶圆利用率下降、良率随面积指数衰减、验证复杂度失控、设计成本激增。更硬的一条约束是光刻：12 英寸晶圆在光刻机的要求下，单颗芯片的最大设计面积被限制在 858 mm² 左右，掩膜版尺寸本身就是一堵墙。也就是说，即使不计成本和良率，单芯片路线在面积上也无法再大幅扩展。

第三条天花板来自封装与接口。大模型推理的瓶颈并不在乘加单元本身，而在于权重需要从片外存储反复搬到计算单元。这条通路的带宽由封装、接口速率和引脚数共同决定，属于典型的“物理上无法在短期内倍增”的环节。

三条天花板叠加，结论就比较清楚了：继续沿着单芯片 SoC 增加算力很难，可以转向“把大芯片拆成小芯片再集成”的路线。集成芯粒的思路是先把多个小颗粒芯片独立设计、独立实现，再通过先进封装重新组装成系统。这样做的好处很直接：单颗芯粒面积小、良率高、可复用，设计周期短；坏处是片间互联和封装成为新的约束项，必须在架构阶段就一并设计，不能等到后端再补。

2.2 用令牌速率反推带宽需求：一份可以自行复算的推导

模型侧的账，用一份可执行脚本算最清楚。下面这段脚本把“参数量 → 每令牌搬运字节数 → 带宽需求”串起来，并且把几种典型架构的接口速率放在一起对比。

# 大模型推理带宽/算力/存储预算复算脚本 # 所有参数均可替换，用于方案阶段快速做架构对比 def inference_budget(params_billion, token_rate, weight_bits=8, hidden=4096, ffn=11008, layers=32, target_tops=None): """ params_billion: 模型参数量（十亿） token_rate: 目标令牌速率（令牌/秒） weight_bits: 权重位宽，INT8 取 8 hidden/ffn/layers: 全连接层维度，用于核算力与存储 """ # 1) 每个令牌需要搬运的权重字节数（解码阶段每令牌过一遍全部权重） bytes_per_token = params_billion * 1e9 * weight_bits / 8 # 2) 带宽需求 = 单令牌搬运量 × 令牌速率 bw_Bps = bytes_per_token * token_rate bw_TBps = bw_Bps / 1e12 # 3) 三层连续全连接层（FC0/FC1/FC2）的算力与存储 macs_per_layer = (hidden * ffn + ffn * hidden + hidden * hidden) total_macs = macs_per_layer * layers tops = total_macs * token_rate * 2 / 1e12 # 1 MAC = 2 ops capacity_GB = total_macs * weight_bits / 8 / 1e9 # 4) 算力存储比，单位 ops/byte，数值上等于令牌速率 ratio = tops * 1e12 / (capacity_GB * 1e9) return { "带宽需求(TB/s)": round(bw_TBps, 3), "算力需求(TOPS)": round(tops, 2), "容量需求(GB)": round(capacity_GB, 3), "算力存储比(ops/byte)": round(ratio, 1), } # 70 亿参数模型，1 万令牌/秒的实时推理目标 print(inference_budget(7, 10_000)) # 输出约：带宽 64 TB/s 量级，算力 68 TOPS，容量 3.4 GB

脚本里最关键的一行是bytes_per_token。解码阶段每个令牌都要把全部权重过一遍，所以带宽需求等于“参数量 × 位宽 ÷ 8 × 令牌速率”，与批大小、序列长度都无关，只和模型尺寸与目标速率挂钩。这解释了一个常被误判的现象：把令牌速率从每秒 1 个提到每秒 1 万个，算力需求只涨到 68 TOPS（对一颗芯片来说并不夸张），但带宽需求涨到了 64 TB/s（对任何现有封装来说都不现实）。

参数说明与调参建议：weight_bits从 8 降到 4，带宽直接减半，这也是权重量化在推理侧收益立竿见影的原因；token_rate是业务指标，做方案论证时应先固定它再倒推硬件，而不是先有硬件再编速率。算力存储比那一项的输出值在数值上恰好等于令牌速率，这个巧合背后是“每字节权重只参与一次乘加”的解码特性，后面第 3 章会用它来反推存边架构的并行度设计。

对比之下，采用分离式计算架构时，GPU 与高带宽存储之间的数据搬运量就是上面算出来的量级；而在存算一体架构里，权重常驻阵列，接口上只需要搬运输入激活和输出结果，同样令牌速率下带宽需求能压到每秒几十吉比特的量级，差距超过三个数量级。这不是靠“带宽优化技巧”省出来的，而是数据通路结构变了。

2.3 算力存储比：大模型和卷积网络比较数值时需要注意

第二个容易被误用的指标是算力存储比。拿前面算出的 68 TOPS 与 3.4 GB 相除，得到约 20 ops/byte。而经典卷积网络在图像任务上的算力存储比要高出一到两个数量级，通常在每千字节上百 GOPS 的量级。两者不是一个量级的负载：卷积网络是计算密集，大模型解码是访存密集。

这个差别直接决定了存储介质和阵列结构的选法。经典交叉阵列做存内计算时，算力存储比约等于“时钟频率 × 2”，因为一次阵列级乘加在一个时钟周期内完成，而阵列深度决定了它能装多少权重。当负载的算力存储比远低于这个值时，交叉阵列会长时间处于“等数据”的状态，并行度上不去。

针对这一点，存边计算的做法是把乘加逻辑分布在片上权重缓冲 SRAM 的边缘，让算力存储比变成“时钟频率 × 2 ÷ 存储深度”。存储深度可以按宏单元的容量来配，等于把算力存储比做成了一个可调参数，而不是被阵列结构锁死。这个调整听起来只是公式变化，落到实现上意味着：权重可以按输入通道方向切块、展平后存进不同列，输出通道方向的并行度靠增加宏单元数量来堆，近存计算里成熟的数据流映射方法可以直接搬过来用。

提示：做方案对比时，务必把“算力存储比”和“峰值算力”分开列。只报峰值算力的方案，在解码类负载上通常兑现不了。

3. 总体架构设计：CPU 与存算一体芯粒的分工与数据流

算完账，架构的骨架其实已经被约束住了：主机侧负责调度、采样、非矩阵类算子；加速侧负责全连接层和注意力的矩阵运算；两者之间只走输入输出，不走权重。这一章把这个骨架展开成可实现的模块划分、数据流映射和多芯粒扩展方案。

3.1 存算分离与存算一体的数据通路对比

分离式架构的数据通路是：主机 CPU 通过高速串行总线把请求发给加速卡，加速卡上的计算芯片从外部高带宽存储里反复读取权重，算完把结果写回，再经总线返回。这条通路上真正昂贵的不是计算，而是“权重读一遍、用一次、丢掉、下个令牌再读一遍”。

存算一体架构把这条通路改成：主机 CPU 通过同一套总线把输入激活送到存算加速卡，权重常驻在加速卡的存算阵列里不动，乘加在阵列内部完成，只把输出激活送回主机。外部存储的角色从“权重的家”降级为“激活的暂存”，容量需求和带宽需求同时下降一个数量级。

这里有一个容易在设计文档里写漏的点：主机侧的矢量计算单元和小算力 NPU 并不是冗余的。注意力模块里的 softmax、层归一化、掩码、采样这些操作，计算量不大但访存模式零碎，放在存算阵列里做反而低效。合理的分工是主机侧处理这些“非规则但轻量”的算子，存算侧只处理“规则且重”的矩阵乘。方案里如果只画一颗存算芯片，评阅时基本会被问“softmax 在哪算”。

从带宽对比看，同为每秒一万令牌的目标速率，分离式架构需要几十太字节每秒的片外带宽，存算一体架构只需要每芯粒每秒几十吉比特量级的接口速率，节省幅度超过三个数量级。这个数字也解释了为什么单芯粒接口速度可以做得比较保守，从而绕开一部分高速接口的工艺与管制约束。

3.2 存边计算架构：把乘加逻辑挪到 SRAM 的边缘

存边计算的物理形态是：一片 SRAM 阵列，边缘挂一排乘加单元和归约树，权重按行或按列静态存放，输入激活从一侧流入，部分和从另一侧汇出。它的好处是既能用上 SRAM 的高能效，又不像交叉阵列那样被阵列深度绑死并行度。

数据流映射的具体做法是：权重在计算开始前预先加载进宏单元，沿输入通道方向切块后展平，存入宏单元的不同列；输出通道方向的并行度靠堆多个宏单元实现，形成空间并行。下面这段配置脚本描述了一次映射的参数组织方式，实际综合时可以把它转成宏单元的配置寄存器表。

# 存边宏单元的权重组装与映射配置 # 目标：把一层全连接权重切成列块，铺到 N 个 COMB 宏上 def build_mapping(in_ch, out_ch, macro_cols=64, macro_rows=256, macros=4): """ in_ch / out_ch: 该层输入、输出通道数 macro_cols: 单个宏单元一行能放多少个权重（列方向） macro_rows: 单个宏单元能放多少行（深度） macros: 并行使用的宏单元颗数 """ # 每个输出通道的权重沿输入通道切块，每块长度 = macro_cols blocks_per_out = (in_ch + macro_cols - 1) // macro_cols # 输出通道按宏数量均分，实现输出方向的空间并行 outs_per_macro = (out_ch + macros - 1) // macros mapping = [] for m in range(macros): for b in range(blocks_per_out): mapping.append({ "macro": m, "block": b, "in_start": b * macro_cols, "in_end": min((b + 1) * macro_cols, in_ch), "out_start": m * outs_per_macro, "out_end": min((m + 1) * outs_per_macro, out_ch), "depth_needed": outs_per_macro, # 占用宏单元行数 }) # 校验：占用行数不能超过宏深度，否则需要增加宏或二次切分 assert all(x["depth_needed"] <= macro_rows for x in mapping), "宏深度不足" return mapping for item in build_mapping(4096, 11008)[:3]: print(item)

macro_cols决定了单次阵列操作的向量宽度，macro_rows决定了能同时驻留多少个输出通道的权重，macros决定了输出方向的空间并行度。三者共同决定算力存储比。实践中的调参顺序是：先按片上 SRAM 总面积和工艺节点定macro_rows，再按目标算力定macros，最后用macro_cols对齐位宽和累加器位宽。断言那一行不是装饰，depth_needed超过宏深度时，如果只增加宏数量而不调整切分策略，会得到一堆溢出越界的地址，仿真阶段表现为随机错值，非常难查。

3.3 多芯粒集成的划分与扩展性

单颗芯粒的容量是有上限的。以 12/14 nm 工艺估算，一颗 10 TOPS、200 MB 存储的芯粒，计算电路面积约 8 mm²，存储面积约 300 mm²，折算下来算力密度只有 0.0325 TOPS/mm²。这个数字说明两件事：一是存储面积占绝对主导，想提高容量只能堆芯粒；二是算力密度低不是设计失误，而是这类架构的固有特征，方案文档里必须主动解释，否则会被当成缺陷。

四颗 65 nm 的 SRAM 存边计算芯粒，通过扇出型 2.5D 封装集成在一起，是这套方案里比较典型的一个规模点：算力和容量都能获得接近线性的提升，封装工艺也相对成熟。超过四颗之后，映射方法需要重新设计，否则算力不会随芯粒数量线性增长，原因在于芯粒间的激活广播和部分和归约开始成为瓶颈，互联拓扑和切分粒度都要跟着改。

芯粒划分的一般原则可以归纳成三条：把同一层的权重尽量聚在同一颗芯粒上，减少跨芯粒的权重访问；把需要频繁交换部分和的通道切在同一封装内，避免走封装外总线；给每颗芯粒留出独立的激活缓冲，避免共享缓冲成为串行点。

3.4 单芯粒预算表：方案文档里必须有的那张表

评审看方案，第一眼找的就是这张表。缺了它，后面的模块设计再细也会被质疑“没有量化依据”。

表格里最后一行是这套方案最容易被忽略的价值点：因为权重不出片，片间接口只需要承载激活和部分和，速率要求被压到很低，封装难度和功耗随之下降。做方案论证时，应该把这一行单独强调，它比“峰值算力多少 TOPS”更能说明架构的合理性。

4. 轻量化与存内压缩的协同设计：稀疏网络在存算阵列上如何稠密映射

前面三章解决的是“权重怎么不搬家”，这一章解决“权重怎么少占地方”。稀疏化本身并不新鲜，难点在于：把非结构化剪枝后的稀疏矩阵直接塞进规则阵列，零值仍然要占存储单元，压缩等于白做。这一章给出的是软硬件协同的一条路径：剪枝策略、位掩码编码、路由网络三件事必须一起设计。

4.1 剪枝子组大小与稀疏率的确定方法

稀疏化的两个关键参数是子组大小和稀疏率。子组太大，压缩粒度粗，精度掉得快；子组太小，解码逻辑复杂，位掩码本身的开销就吃掉收益。取值不能靠猜，要在目标任务上做一轮扫描。

扫描的做法是：固定子组大小，逐步提高稀疏率，观察验证集指标；找到指标开始下降的拐点，再把拐点往回退一档作为工作点。在一组字符级语言建模任务的实验中，子组大小取 32、修剪掉四分之三的权重时，网络性能基本保持不变，于是工作点被定为“子组 32、稀疏率 75%”。这个结果不是普适常数，换模型、换任务都要重扫，但它给出了一个合理的出发区间。

注意：精度拐点必须用最终任务的指标来判定，不能用训练损失代替。训练损失平稳而下游指标下降的情况在这类压缩里非常常见。

4.2 位掩码编码与稠密权重的存内组织

确定了工作点，编码方式就固定下来了：权重向量按子组划分，每组按预定义稀疏度修剪，剪枝后的非零权重压成一个稠密向量，同时生成一个等长的比特掩码，用来指示稠密权重在原始向量里的位置。阵列里只存稠密向量，掩码存在旁边的掩码存储里，两者一一对应。

下面这段脚本实现了完整的编码与解码校验，可以直接拿来验证编码逻辑有没有写错。

import random def prune_group(weights, sparsity=0.75): """按绝对值保留最大的 (1-sparsity) 比例权重，返回稠密向量与位掩码""" n = len(weights) keep = max(1, int(round(n * (1 - sparsity)))) idx = sorted(range(n), key=lambda i: -abs(weights[i]))[:keep] keep_set = set(idx) mask = [1 if i in keep_set else 0 for i in range(n)] # 1 表示保留 dense = [weights[i] for i in range(n) if mask[i] == 1] return dense, mask def prefix_popcount(mask): """前缀 popcount：输出每个位置之前（含自身位置前）1 的个数， 用于把掩码位置翻译成稠密向量的下标""" out, cnt = [], 0 for b in mask: out.append(cnt) cnt += b return out # 校验：稠密向量第 k 个元素，应该落在掩码第 prefix_popcount[mask[i]] 位 weights = [round(random.uniform(-1, 1), 3) for _ in range(32)] dense, mask = prune_group(weights, 0.75) pp = prefix_popcount(mask) for i, b in enumerate(mask): if b == 1: assert dense[pp[i]] == weights[i], "编码/解码不一致" print("保留权重数:", len(dense), "掩码长度:", len(mask))

这段代码的核心是prefix_popcount。它把“原向量第 i 位”翻译成“稠密向量的第几个元素”，硬件里的实现就是一条扫描链加一个计数器。校验断言那一行是必须的：编码端和解码端只要对“前缀是否含自身”的理解差一位，整个阵列的输出就会整体偏移一个位置，现象是结果“看起来差不多但精度掉一截”，属于最费时间的 bug 之一。

4.3 蝶形路由网络：前缀 popcount 与左旋转补码

稠密权重准备好了，输入激活还得跟着一起“挤”。原始输入特征里，被剪掉权重对应的那些输入不需要参与计算，必须从输入向量里挑出来、按顺序排好，送进阵列。这个重排用蝶形网络实现：多级 2 选 1 的数据分发单元，控制信号由解码器实时产生。

解码器接收位掩码，生成每一级蝶形的控制比特，涉及两个操作。第一个是前缀 popcount，扫描掩码序列，输出当前位置之前 1 的总数，用来确定某个数据该被送到第几个输出口。第二个是左旋转补码（LRCW），本质是一次循环左移，唯一区别是移位量在运算过程中以补码形式表示，用来在每一级修正路由偏移。

def lrcw_shift(src_bits, shift, width): """左旋转补码：循环左移，移位量按补码解释，负值等价于反向旋转""" shift %= width # 补码语义下先归一化到位宽范围 return ((src_bits << shift) | (src_bits >> (width - shift))) & ((1 << width) - 1) def butterfly_route(inputs, mask, stages): """按位掩码把输入特征路由到稠密位置，stages 为蝶形级数""" width = len(inputs) assert width == (1 << stages), "输入长度需为 2 的整数次幂" idx = [i for i, b in enumerate(mask) if b == 1] routed = [inputs[i] for i in idx] # 硬件中每级只做一次局部交换，这里用软件等价描述便于验证 ctrl = lrcw_shift(0b0011, 1, 4) assert ctrl in range(1 << 4) return routed print(butterfly_route(list(range(8)), [0,1,1,0,1,0,0,1], 3)) # 期望输出：[1, 2, 4, 7]

软件描述里看不出并行性，硬件上则是每一级只做一次相邻或跨组的 2 选 1 交换，级数等于输入长度的以 2 为底对数，延迟对输入长度是对数关系。设计时的关键约束是：路由网络的控制信号必须在同一拍内产生，不能跨拍，否则数据流水的节拍会被解码器拖住。这也是为什么解码器要用纯组合逻辑加前缀树，而不是塞进一条通用流水线。

4.4 28 nm 验证芯片的指标拆解

这套协同设计在一颗 28 nm 工艺的验证芯片上做过实现，指标可以按维度拆开看。

能效拆成两个值来报，是有意为之。生成查询、键、值矩阵这一步是全连接层的稠密计算，能效体现的是阵列本身的水平；整体注意力包含了路由与聚合的开销，能效体现的是协同设计的水平。两个数一起看，才能判断存内压缩到底有没有带来净收益。如果只报前一个数，评审很容易问“压缩开销算了吗”，答不上来就会显得方案不完整。

5. 常见问题与排查：从建模到流片最容易出问题的五个点

方案写到这一章之前都是“应该怎样”，这一章说“实际会怎样”。下面五条都是在同类项目里反复出现的问题，按“现象 → 原因 → 解决”组织，做成检查清单，比任何设计原则都省时间。

5.1 稀疏率按经验设定，精度下降后才发现子组大小取错

现象：编码和阵列仿真都通过，功能正确，但任务指标比基线低了两三个点，重训也拉不回来。

原因：子组大小是按“常见值”设定的，没有在目标任务上扫过拐点。子组过大时，一个子组里被剪掉的权重分布与权重的重要性分布不匹配，等价于做了一次粗粒度的结构破坏；子组过小时，位掩码的相对开销变高，压缩收益被吃掉，而精度又没变好。

解决：把子组大小和稀疏率做成二维扫描表，每一格记录指标，取“指标不下降前提下压缩比最高”的那一格。扫描成本远低于后期返工。经验上，字符级建模任务在子组 32、稀疏率 75% 附近比较稳，但换任务必须重扫。

5.2 交叉阵列里零权重未清干净，稠密映射实际未生效

现象：阵列规模看起来没变，功耗反而略微上升，性能提升远小于预期。

原因：非结构化剪枝后的矩阵在映射到规则阵列时，被剪掉的位置如果没有做显式清零或旁路，存储单元里残留的是旧值或随机初值。计算仍然执行，但贡献了错误的项，为了修正它又加了额外的门控逻辑，功耗就上去了。

解决：在映射流程里加一道强制检查：遍历所有被剪枝的位置，确认写入的是零或已被旁路使能覆盖。上面 4.2 节的编码校验脚本可以直接扩展成这一检查，把断言从“保留位一致”扩到“裁剪位为零”。

5.3 芯粒数量一增加，算力不线性增长

现象：从四颗芯粒扩到八颗，仿真出来的算力只有预期的六成左右，增加芯粒带来的收益递减明显。

原因：跨芯粒的部分和归约和激活广播开始成为瓶颈，原来的切分策略是按四颗设计的，切分粒度太粗，导致每一层都要跨封装交换中间结果。互联拓扑没有跟着调，串行点就出现了。

解决：先做一次互联流量统计，找出跨芯粒流量最大的那几层，把切分粒度沿输出通道方向细化；同时给每颗芯粒配独立激活缓冲，把共享缓冲改成点对点。芯粒规模继续往上时，映射方法本身要重做，不能沿用四芯粒的配置。

5.4 只按峰值算力做功耗预算，忽略封装与散热

现象：架构仿真完美，热仿真一跑，结温超标，标称频率降不下来，实测性能只有设计值的七成。

原因：存算一体架构的算力密度低，但存储面积大，热量分布很不均匀，乘加阵列集中在边缘，SRAM 阵列铺满大部分面积，峰值算力对应的功耗峰值集中在少数热点上。按平均功耗做散热设计，热点必然超标。

解决：把功耗预算按区域拆，分别给计算边缘区和存储区设定功耗密度上限，热仿真按区域热点而不是平均功耗跑。封装选型时把热阻作为与带宽同级的指标来评估。

5.5 仿真用理想 SRAM 模型，流片后时序不达标

现象：RTL 仿真和门级仿真都过，流片回来频率上不到目标值，或者良率异常低。

原因：存内计算对 SRAM 位单元的读写裕度极其敏感，行为级模型里读操作是零延迟、无穷驱动，实际位单元在低压下读出摆幅很小，加上阵列规模大、走线长，时序和噪声裕度都不够。定制位单元的晶体管数量、驱动能力、读出放大器阈值这些参数，在前期模型里常被简化。

解决：从设计第一天起就用带时序与噪声的存储器模型，关键路径上跑蒙特卡洛；对低压工作点单独做读写裕度分析，把最低工作电压留出足够余量。这条问题的成本很高，属于前期少做一步、后期多花几个月的那类问题。

6. 验收与答辩：用一组可复算的指标证明架构成立

方案交上去，评审通常只做三件事：看你的账算不算得清、看你的结构能不能对得上账、看你有没有验证过。所以答辩材料不要从“技术趋势”讲起，从一张指标表讲起，让每一个数字都能被现场的追问追到底。

第一层是带宽账。开口就给出目标令牌速率下的带宽需求，以及存算一体架构下的接口速率，两者放在同一张表里，标注清楚算法和公式。这一层的作用是确立问题真实存在，并且你的架构确实把它解决了。评审如果追问“为什么是这个速率”，现场用 2.2 节的脚本心算一遍，比任何解释都有说服力。

第二层是容量与并行度。给出单芯粒容量、宏单元深度、输出通道并行度三者的关系式，说明在给定面积下为什么选这个组合。这一层最容易被问的是“为什么不多堆几颗芯粒”，答案要用 5.3 节的扩展性分析来接，承认非线性并给出拐点位置，比硬说线性更可信。

第三层是稀疏协同的净收益。把压缩前后的存储占用、能效、精度三项并列，明确说明压缩开销已经计入。用 4.4 节那张表的形式，把生成 QKV 的能效和整体注意力的能效分开报。

第四层是覆盖面。至少在三个维度上有验证数据：功能层（编码解码一致性）、架构层（映射后的算力与容量）、实现层（时序、面积、功耗）。只有功能仿真而没有实现层数据，是这类方案最常见的失分点。

答辩现场还有一个很实际的小技巧：把最容易出错的两条（5.2 的零权重未清、5.5 的存储器模型过理想）主动写进“已识别风险”那一页，附上你的应对措施。评审看到你自己先把问题摆出来，追问的火力会明显下降，剩下的时间就能用来讲你的架构亮点。反过来，被现场问出一个你完全没想过的坑，前面所有数字的可信度都会打折。

从那以后我每次带这类硬件架构方案，都强制走一遍“算账 → 画表 → 复算脚本 → 风险页”这四步，哪怕时间再紧也不跳。翻车的方案几乎都不是因为想法不对，而是因为某笔账只在脑子里算过、没落到纸上、也没被第二个人复算过。希望这套结构能帮到你，把手上那份方案从“看起来有道理”变成“经得起追问”。

本文还有配套的精品资源，点击获取