做生成式推理优化的人迟早都会撞上同一堵墙。GPU 的算力一代一代往上翻但你盯着一块 H100 跑 70B 模型输出速度还是死死卡在二十几个 token 每秒算力利用率连三成都不到。问题不在于芯片不够强而在于每一 token 都要把上百 GB 的权重从显存里搬一遍带宽成了那条永远过不去的独木桥。这时候一个新方向开始被人反复提起第一个针对生成式推理的 3D-DRAM 加速器——把计算单元直接堆进 DRAM 的层与层之间用 TSV 垂直互联把搬数据这件事从毫秒级压到微秒级。它想解决的不是算力问题而是数据搬家的成本问题。这篇内容适合三类人看正在做推理引擎和模型部署的工程师、在评估下一代 AI 芯片架构的技术决策者、以及想搞明白为什么大家都在往内存里塞计算单元的技术爱好者。我会把带宽账、容量账、能耗账三条线全部算给你看也会把这类架构的评估方法和踩坑点摊开讲。1. 为什么生成式推理需要一颗长在内存里的加速器1.1 解码阶段的账算力闲着带宽先满大模型推理分成两个截然不同的阶段很多人一开始会把它们混为一谈。Prefill预填充阶段处理整段输入 prompt做的是大矩阵乘大矩阵的 GEMM矩阵维度动辄几千算术强度很高属于典型的计算受限**Decode解码**阶段一次只生成一个 token做的是矩阵乘向量GEMV和注意力打分算术强度低得可怜。我们把这笔账算清楚。一次 GEMV权重矩阵 W 是 N×N输入向量 x 是 N×1浮点运算量是 2N² 次乘加需要从显存里读的字节数在 FP16 精度下是 2N² 字节每个权重 2 字节向量小到可以忽略。两者一除算术强度只有 1 FLOP/Byte。再看硬件的岭点Ridge Point——也就是算力和带宽的比值。以一块 A100 为例FP16 张量核算力约 156 TFLOPSHBM2e 带宽约 2 TB/s岭点大致是 78 FLOP/Byte。而解码阶段的算术强度是 1 FLOP/Byte。差了将近两个数量级。这意味着什么意味着你用掉 1% 的算力就已经把带宽跑满了。这就是为什么你在 nvidia-smi 里看到的 GPU 利用率只有 20%~30%但显存带宽已经顶到 90% 以上。更直白一点讲解码阶段的理论上限就是带宽除以模型体积。一块 2 TB/s 带宽的卡跑 7B 的 FP16 模型约 13.5 GB 权重理论上限是 148 token/s跑 70B 的 FP16 模型约 140 GB 权重理论上限就只有 14 token/s 出头。实际能跑到的还要再打个四折到七折因为 kernel 的效率、注意力开销、通信同步都会吃掉一部分。这不是工程优化能填平的差距这是架构层面的硬约束。1.2 把计算搬到数据旁边3D-DRAM 到底省了什么既然瓶颈是搬那最朴素的想法就是——别搬了。3D-DRAM 加速器的核心思路就是把运算单元从逻辑芯片里下沉到 DRAM 的堆叠层中让权重数据留在原地被就地消费。传统的做法是DRAM 颗粒在 PCB 或硅中介层上数据要经过 PHY、走线、封装引脚、片外总线才能到 GPU 的计算单元。这条路径的物理长度是毫米甚至厘米级。而 3D 堆叠把逻辑层和存储层用**硅通孔TSV**垂直连起来路径长度缩到微米级。路径短了能省下三样东西带宽上得去。并行通道数不再受封装引脚数的限制TSV 可以做到几千上万根每根速率不用很高聚合起来就能到数 TB/s 的量级。能耗降下来。驱动长走线需要大功率的 IO 缓冲器走线越长、电容越大、翻一次比特消耗的能量越多。垂直短互联的驱动成本低得多。延迟可预测。片外访问的延迟受总线仲裁、刷新、行激活影响抖动大堆叠结构里的访问路径短且确定对延迟敏感的逐 token 生成更友好。所以 3D-DRAM 加速器的价值主张不是算得更快而是在同样的算力下把每 token 的数据搬运成本砍掉一大截。这恰好命中了解码阶段的死穴。1.3 它和 HBM-PIM、近存计算、存内计算的区别在哪这块很容易被混为一谈我按计算单元离数据有多近排个序你就清楚了。路线计算单元位置数据搬运距离典型带宽量级灵活性传统 GPU 外挂显存独立逻辑芯片毫米~厘米1~3 TB/s极高近存计算2.5D 中介层与 DRAM 同封装毫米级3~8 TB/s高HBM-PIMDRAM 堆叠的基础裸片百微米级数 TB/s中3D-DRAM 加速器DRAM 层间/层内微米级数 TB/s~十 TB/s中低纯存内计算存储阵列内部纳米级极高低HBM-PIM 走的是在 HBM 堆栈最底下那颗 base die 上加算力的路子基础裸片本来就是逻辑工艺改造成本相对可控但它离 DRAM 阵列还是隔着一层。3D-DRAM 加速器更进一步把一些简单的 MAC 阵列直接铺到存储层的边上甚至和 bank 交织在一起距离更短。代价是 DRAM 工艺天生是做高密度存储的晶体管驱动能力和逻辑速度都远不如先进逻辑工艺所以只能放简单、规则、高度并行的运算比如 GEMV、乘加、向量点积、softmax 的部分近似计算。这就是这类架构的设计哲学用架构上的就近换工艺上的吃亏。复杂的非线性、动态控制、图调度还是交回给主控芯片。2. 架构拆解一颗 3D-DRAM 加速器的分层设计2.1 堆叠分层与 TSV 通道预算怎么算先说分层。一颗典型的 3D-DRAM 加速器从下往上看大概是这么几层最底层是逻辑控制层负责指令发射、地址生成、任务调度、以及与外部主机GPU 或 CPU的接口往上是若干层DRAM 存储层每层里划分成多个 bank group在这些存储层之间或旁边嵌入PIM 计算层或计算区块负责就地做乘加顶层可能还有一层专门做数据汇总和归约。TSV 的通道预算是设计的第一个硬约束我自己习惯这么估单层数据 TSV 数2048 根 单根 TSV 速率4 Gbps 单层带宽 2048 × 4 Gbps 8192 Gbps 1 TB/s 堆叠 8 层存储 8 × 1 TB/s 8 TB/s 聚合带宽这个量级不是拍脑袋来的HBM3 单堆栈已经做到 1024 位宽、6.4 Gbps约 819 GB/s把位宽和层数同时放大理论上到 8~16 TB/s 是合理的工程目标。但要注意TSV 不是越多越好每一个 TSV 都要占面积通常 5~10 微米直径加禁布区、都要耗功耗、都会影响良率。TSV 数量翻倍芯片面积和成本一起上去散热也更麻烦。所以真实设计里常见的做法是少 TSV、高频率和多 TSV、低频率之间的权衡。低频率 TSV 更省电、时序更宽松但需要更多根高频率能省面积但功耗密度上来以后堆叠结构中间的散热就成了大问题——DRAM 对温度非常敏感超过 85℃ 刷新率就得加倍性能反而掉下去。2.2 每层放什么DRAM 阵列、MAC 阵列、片上网络分层确定以后下一个问题就是每层内部的资源怎么切。我的经验是把一层拆成若干个切片slice每个切片里放一组 DRAM bank、一小块 MAC 阵列、一个本地缓冲、以及一个接片上网络的路由节点。MAC 阵列的规模要和 bank 的带宽匹配不然会一边饿死一边堵死。举个具体的一个切片里的 bank 组每秒能吐出 128 字节那么 MAC 阵列的吞吐就得能吃下 128 字节/秒对应的乘加次数。在 INT8 下128 字节就是 128 个操作数如果权重和激活都是 INT8那就是每周期 128 次乘加阵列规模大约 16×8 就够。阵列做大不会更快的因为数据供不上只会白白占面积和漏电。片上网络这块我建议用分层总线 局部 mesh的混合结构。层内用 mesh 短距离互联层间用 TSV 汇聚成一条主干总线主干上再做归约和广播。全 mesh 在 8 层以上的规模里布线会炸掉纯总线又会在热点上堵死。混合结构是折中但代价是路由逻辑复杂编译器的任务映射要做得很细否则容易出现数据在层间来回横跳的灾难。还有一点容易被忽略归约单元的位置。GEMV 之后要做累加如果每个切片各算一部分最后必须归约。把归约放在逻辑控制层是常见做法但那样一来部分和又要在 TSV 上跑一趟。更聪明的做法是在每层放一个小归约树先把层内的部分和合并只把合并后的结果往上传TSV 流量能省下好几倍。2.3 数据流与指令流GEMV 和 KV cache 访问的排布权重的排布决定了 GEMV 的效率。假定模型权重以 INT8 或 INT4 存在 DRAM 层里排布方式要保证同一次 GEMV 用到的权重尽量落在同一个 bank group 里这样一次行激活就能连续吐出一大段数据。如果权重按原始的行主序随便铺bank 冲突会非常严重有效带宽可能只剩理论值的三分之一。我的实测经验是按输出通道优先、每个 bank group 负责一段连续输出通道来切分权重行缓冲命中率能明显提升。同时把同一层的权重按 MAC 阵列的位宽做对齐填充避免跨切片读取。KV cache 的访问是另一个重点。解码阶段每生成一个 token都要把整个 KV cache 读一遍。注意这个读一遍的意思不是读整个缓存而是每个层读该层对应的那份 K 和 V。所以 KV cache 的访问模式是按层切分、每层全量读、逐 token 重复。这种模式特别适合把 KV 存在和该层权重相邻的位置——读到权重的同时顺手把 K、V 也读了不用另外跑一趟 TSV。指令流这边常见的做法是粗粒度指令 微码。控制层发出对第 i 层做 GEMV输入向量 x输出到 buffer j这样一条粗指令各切片的微码序列器自己展开成 bank 激活、数据读出、MAC 计算、部分和回写这一整套动作。这样控制层的发射压力小各切片也能并行展开。代价是微码要针对具体网络结构预先编译灵活性不如纯 SIMT 架构。3. 三条账算清楚带宽、容量、能耗3.1 权重的带宽账tokens/s 是怎么被卡死的我把这笔账写成一段可以直接跑的脚本你换成自己的模型参数就能算def decode_upper_bound(params_b, bits, bw_gbps, kv_gb0.0, efficiency0.7): params_b: 参数量十亿 bits: 权重位宽16/8/4 bw_gbps: 有效带宽GB/s kv_gb: KV cache 体积GB按批量和上下文长度估算 efficiency: 实际可达效率经验值 0.5~0.8 weight_gb params_b * 1e9 * (bits / 8) / 1e9 total_gb weight_gb kv_gb theoretical bw_gbps / total_gb # tokens/s realistic theoretical * efficiency return weight_gb, theoretical, realistic for name, p, b in [(7B-FP16, 7, 16), (7B-INT4, 7, 4), (70B-FP16, 70, 16), (70B-INT4, 70, 4)]: w, t, r decode_upper_bound(p, b, 3350) # H100 级带宽 print(f{name:10s} 权重 {w:6.1f} GB 理论上限 {t:7.1f} tok/s 实际约 {r:6.1f} tok/s)跑出来大概是这么个结果模型权重位宽权重体积理论上限实际可达7BFP1613.5 GB248 tok/s约 170 tok/s7BINT43.5 GB957 tok/s约 670 tok/s70BFP16140 GB24 tok/s约 17 tok/s70BINT435 GB96 tok/s约 67 tok/s这张表说明了两件事。第一量化对解码吞吐的收益几乎和位宽成反比从 FP16 降到 INT4理论上限翻了四倍因为要搬的字节少了四分之三。第二70B 模型在 FP16 下的天花板只有二十几个 token/s这个数字对实时对话来说勉强够用对 Agent、代码补全这种需要快速迭代的场景就非常难受了。3D-DRAM 加速器在这里的贡献是把分母上的带宽换成 8~16 TB/s 量级。同样是 70B FP16140 GB 的权重在 10 TB/s 的有效带宽下理论上限能到 71 tok/s实际也能摸到 50 tok/s 上下。这不是优化这是换了个物理层。3.2 KV cache 的容量账长上下文才是真正的吞噬者很多人只盯着权重忽略了 KV cache。我把公式写出来KV 体积 2 × 层数 × KV头数 × head_dim × 序列长度 × 批量 × 每元素字节数以 LLaMA-2 70B 为例80 层、GQA 下 8 个 KV 头、head_dim 128、FP16 存储每 token 每层 2 × 8 × 128 × 2 字节 4096 字节 4 KB 每 token 全模型 4 KB × 80 320 KB 4K 上下文 320 KB × 4096 ≈ 1.31 GB 32K 上下文 ≈ 10.5 GB 128K 上下文 ≈ 42 GB 批量 32、4K 上下文 ≈ 42 GB看到没有128K 单条上下文消耗的 KV cache差不多是 70B 模型 INT4 权重35 GB的一点二倍。而 KV cache 在解码阶段每个 token 都要被完整读一遍也就是说长上下文场景下 KV cache 的带宽压力会超过权重本身。还有一个隐蔽的成本KV cache 是动态增长的。序列每长一个 token缓存就涨一点而它的物理布局通常是按块分配的。如果不做分页管理碎片化会让有效容量打七折。这也就是为什么现在做推理服务的人都在推分页注意力和 KV 量化——不是为了省磁盘是为了省带宽。3D-DRAM 加速器在这块的优势在于它有条件把 KV cache 和权重放在同一个堆叠体内甚至让两者共享 TSV 主干。KV 的读取和权重的读取在时间上是交错的共用一条高带宽通道比走两次片外总线要划算得多。更激进的设计会直接在存储层里做注意力打分把 Q 广播过去K 就地取、就地算点积只把分数传回来。3.3 能耗账每搬一个比特要付多少电费这是最容易被忽视、但对数据中心来说最要命的一条账。文献里常见的量级是这样的数据搬运路径每次访问能耗量级片外 DRAM 完整路径含 PHY、封装、走线10~20 pJ/bit2.5D 封装上的 HBM3~5 pJ/bit3D 堆叠 TSV 垂直互联0.5~2 pJ/bit片上 SRAM0.1~0.5 pJ/bit我们拿 70B FP16 模型算一下。每生成一个 token要搬 140 GB 的权重也就是 1.12×10¹² 比特。如果走片外路径按 15 pJ/bit 算光是搬权重就要 16.8 焦耳。如果按 20 tok/s 的速度生成光权重搬运的功耗就是 336 瓦。这还没算计算本身的功耗、KV cache 的搬运、以及通信同步的开销。换成 TSV 路径按 1 pJ/bit 算同样的 1.12×10¹² 比特只要 1.12 焦耳功耗直接降到 22 瓦。差了整整一个数量级。这就是就近计算最硬的价值——它不改变你算多少它只改变你搬多少电。当然能耗账不能只看单次访问。堆叠结构本身有漏电、有刷新功耗、有散热成本。3D 堆叠的功耗密度比平面芯片高得多中间层散热困难温度一高刷新率翻倍DRAM 的动态功耗又会往上走。这也是为什么很多设计会把逻辑层放在最底下同时兼任散热通路的角色。4. 落地评估怎么在自己的模型上验证这类加速器4.1 先做一次 Roofline 分析确认瓶颈到底在哪任何优化动作之前先确认瓶颈。用 Roofline 是最快的判断方法把算力除以带宽得到岭点再把你的算子算术强度点上去。算子在岭线左边带宽受限这类架构能帮上大忙。算子在岭线右边算力受限加带宽基本没用。生成式推理里解码阶段的 GEMV、注意力打分、以及大部分逐元素的归一化操作算术强度都在 1~4 FLOP/Byte 这个区间妥妥地在岭线左边。Prefill 阶段的 GEMM 算术强度可以到几百在岭线右边。所以评估这类加速器不要拿 Prefill 的吞吐去做宣传也不要用 Prefill 的场景去否定它。正确的做法是分阶段测Prefill 阶段看 TTFT首 token 时间这类架构的贡献有限主要靠算力。Decode 阶段看 TPOT每 token 时间和吞吐这是主战场。我一般会做一张两阶段对照表把 TTFT、TPOT、吞吐、能耗四个指标分别记下来再和同代的纯 GPU 方案做对比。只报一个端到端平均吞吐很容易掩盖掉真正的收益点。4.2 软件侧的配合量化、分页、投机解码硬件再好软件不配合照样跑不出效果。几个必须一起上的动作权重量化。INT4 对带宽的收益是直接的但精度损失要评估。我建议对下路的 FFN 层大胆用 INT4对注意力的投影层用 INT8敏感层保留 FP8 或 FP16。分层混合量化比全模型统一量化效果好得多代价是要多存一份量化配置。KV 分页与量化。KV cache 用固定块比如 16 个 token 一块管理块和块之间不要求物理连续。这样做的好处是碎片化可控长序列不会因为找不到连续空间而失败。KV 量化到 INT8 时注意对 K 的量化误差比 V 更敏感通常 K 保留更高精度V 可以压得更狠。投机解码。这条在带宽受限的场景下收益特别大因为小模型做草稿、大模型做验证一次验证可以确认多个 token。原来一次搬一遍权重只能出 1 个 token现在出 3~4 个等效带宽直接翻几倍。代价是验证阶段的 batch 变大算术强度上来了对 3D-DRAM 的算力部分要求更高。这里有个平衡点草稿长度太长验证失败率高反而浪费带宽我实测 4~6 是比较稳的区间。算子融合。解码阶段每个算子单独跑一遍都要把中间结果写回再读出来白白消耗带宽。把 RMSNorm、残差加、以及部分激活融合进 GEMV 的尾处理里能省掉可观的搬运量。这件事在 PIM 架构上尤其重要因为 PIM 单元擅长规则运算不擅长来回搬运。4.3 影响范围从云端推理成本到端侧长上下文这类架构一旦成熟影响面比想象中大。云端推理成本结构会变。现在推理服务最大的成本项是显存容量和带宽带来的卡成本一块高端卡的显存容量决定了你能同时服务多少路请求。3D-DRAM 加速器把带宽和容量做成同一件事单位 token 的成本会往下走。但反过来它的通用性不如 GPU需要针对固定模型结构编译这就要求服务商在灵活性和效率之间做选择。端侧长上下文设备会变多。手机、笔记本、车载这类设备最大的限制是功耗和内存容量。3D 堆叠本身就是在有限面积里塞更多存储再加上就近计算把功耗压下来本地跑一个 7B 到 13B 模型、上下文 32K 的助手是完全可能的。这对隐私敏感、离线可用的场景意义很大。长上下文应用会被解锁。RAG、代码仓库级补全、长文档摘要、多轮 Agent这些应用共同的痛点是上下文越长越慢。当 KV cache 的读取速度不再是瓶颈这些应用才有机会真正跑顺。但它不会取代通用 GPU。训练、多模态、动态控制流、稀疏结构这些还是得靠通用架构。更现实的形态是异构GPU 负责 Prefill 和调度3D-DRAM 加速器负责 Decode 的权重流和 KV 流。5. 常见问题与排查技巧实录5.1 典型问题速查表现象大概率原因排查动作有效带宽只有峰值的三分之一bank 冲突严重行缓冲命中率低看权重排布的跨 bank 分布按输出通道重排吞吐随上下文变长急剧下滑KV cache 读取量超过权重统计每层 KV 读字节确认是否超过权重体积层间数据来回横跳TSV 利用率高但吞吐低任务映射没有做层内局部化用编译器把同一算子的数据绑定到同一层温度上来后性能不升反降DRAM 刷新率翻倍动态功耗上升降低堆叠中间层的功耗密度调整逻辑层位置部分和归约成为热点归约全部放在控制层TSV 流量翻倍每层加小型归约树层内先合并再上传量化后精度掉得厉害K 和 V 用了同一档位K 保留更高精度V 可以压得更低投机解码收益不稳定草稿长度不合理调整草稿长度到 4~6观察接受率曲线批量化后延迟反而变差算术强度上来了但算力没跟上重新做 Roofline确认是否已转到算力受限这张表是我自己整理出来的排查顺序。遇到问题先看带宽利用率再看 KV 占比再看温度最后才怀疑编译器。大部分性能不达标其实是排布问题不是架构问题。5.2 几个踩过的坑和避坑心得第一个坑把峰值带宽当有效带宽用。我见过太多评估报告直接拿 TSV 的理论带宽做上限计算得出能到多少多少 token/s的结论然后在实测里掉到三分之一。原因很简单DRAM 的行激活、预充电、刷新都会吃掉带宽再加上 bank 冲突和归约流量有效带宽能到峰值的 50%~70% 就算不错了。做容量规划的时候直接按 0.6 的系数打折会更接近现实。第二个坑只优化 Decode忘了 Prefill。端到端延迟是 TTFT 加 TPOT 乘以输出长度。如果你把 TPOT 压到很低但 TTFT 还是两秒用户感知上并不会变好。特别是长 prompt 的场景Prefill 的算力需求可能比 Decode 的带宽需求更值得优化。我的经验是先把 Prefill 的算力利用率做上去再回头攻 Decode 的带宽。第三个坑忽略 KV cache 的写放大。每生成一个 token 都要往 KV cache 里写一份 K 和 V这个写操作也是要占带宽的。很多分析只算读不算写导致理论值和实测对不上。写量是每层每个 token 4 KB70B 那个例子量级和读量在同一个数量级不能当零成本处理。第四个坑低估编译器和任务映射的工作量。硬件设计出来只是开始把模型切分成上千个微码任务、合理分配到各个切片、保证负载均衡这部分工作量往往比硬件设计还大。而且网络结构一变微码就要重新编译。评估这类架构的时候一定要把软件栈的成熟度作为独立维度来看不要只看硬件指标。提示在任何面向生产的评估里务必区分理论峰值和持续可用两组数字并且把 KV cache 的读写流量、归约流量、刷新开销全部计入。这三项加起来通常会让纸面数字缩水 30% 到 50%。第五个坑散热没提前设计。3D 堆叠的功耗密度高中间层的热量很难导出。DRAM 超过一定温度就加倍刷新性能跟着掉。我在测试里见过满载跑十分钟后吞吐下降 15%的情况。所以散热方案要在架构阶段就确定包括逻辑层的摆放位置、TSV 的密度上限、以及是否需要微流道冷却。散热不是后置工程问题它是架构约束。最后分享一个实用的小技巧在做架构对比时我习惯把每 token 能耗和每 token 成本两个指标放在一起看。有些方案吞吐很漂亮但能耗和成本都翻倍实际部署的时候并不划算。生成式推理的规模化瓶颈最终会落在电费和采购成本上而不是峰值性能上。我个人在评估这类加速器时最大的体会是它更像是把内存墙拆掉一段而不是造了一台更快的计算机。瓶颈在哪里收益就在哪里。如果你的模型和场景恰好卡在解码阶段的带宽上这类架构的价值就会非常直接如果你的场景是训练或者重计算的批处理那它帮不了你多少。先算清楚自己的账再决定要不要跟这条路线。
3D-DRAM加速器如何破解生成式推理显存带宽瓶颈
做生成式推理优化的人迟早都会撞上同一堵墙。GPU 的算力一代一代往上翻但你盯着一块 H100 跑 70B 模型输出速度还是死死卡在二十几个 token 每秒算力利用率连三成都不到。问题不在于芯片不够强而在于每一 token 都要把上百 GB 的权重从显存里搬一遍带宽成了那条永远过不去的独木桥。这时候一个新方向开始被人反复提起第一个针对生成式推理的 3D-DRAM 加速器——把计算单元直接堆进 DRAM 的层与层之间用 TSV 垂直互联把搬数据这件事从毫秒级压到微秒级。它想解决的不是算力问题而是数据搬家的成本问题。这篇内容适合三类人看正在做推理引擎和模型部署的工程师、在评估下一代 AI 芯片架构的技术决策者、以及想搞明白为什么大家都在往内存里塞计算单元的技术爱好者。我会把带宽账、容量账、能耗账三条线全部算给你看也会把这类架构的评估方法和踩坑点摊开讲。1. 为什么生成式推理需要一颗长在内存里的加速器1.1 解码阶段的账算力闲着带宽先满大模型推理分成两个截然不同的阶段很多人一开始会把它们混为一谈。Prefill预填充阶段处理整段输入 prompt做的是大矩阵乘大矩阵的 GEMM矩阵维度动辄几千算术强度很高属于典型的计算受限**Decode解码**阶段一次只生成一个 token做的是矩阵乘向量GEMV和注意力打分算术强度低得可怜。我们把这笔账算清楚。一次 GEMV权重矩阵 W 是 N×N输入向量 x 是 N×1浮点运算量是 2N² 次乘加需要从显存里读的字节数在 FP16 精度下是 2N² 字节每个权重 2 字节向量小到可以忽略。两者一除算术强度只有 1 FLOP/Byte。再看硬件的岭点Ridge Point——也就是算力和带宽的比值。以一块 A100 为例FP16 张量核算力约 156 TFLOPSHBM2e 带宽约 2 TB/s岭点大致是 78 FLOP/Byte。而解码阶段的算术强度是 1 FLOP/Byte。差了将近两个数量级。这意味着什么意味着你用掉 1% 的算力就已经把带宽跑满了。这就是为什么你在 nvidia-smi 里看到的 GPU 利用率只有 20%~30%但显存带宽已经顶到 90% 以上。更直白一点讲解码阶段的理论上限就是带宽除以模型体积。一块 2 TB/s 带宽的卡跑 7B 的 FP16 模型约 13.5 GB 权重理论上限是 148 token/s跑 70B 的 FP16 模型约 140 GB 权重理论上限就只有 14 token/s 出头。实际能跑到的还要再打个四折到七折因为 kernel 的效率、注意力开销、通信同步都会吃掉一部分。这不是工程优化能填平的差距这是架构层面的硬约束。1.2 把计算搬到数据旁边3D-DRAM 到底省了什么既然瓶颈是搬那最朴素的想法就是——别搬了。3D-DRAM 加速器的核心思路就是把运算单元从逻辑芯片里下沉到 DRAM 的堆叠层中让权重数据留在原地被就地消费。传统的做法是DRAM 颗粒在 PCB 或硅中介层上数据要经过 PHY、走线、封装引脚、片外总线才能到 GPU 的计算单元。这条路径的物理长度是毫米甚至厘米级。而 3D 堆叠把逻辑层和存储层用**硅通孔TSV**垂直连起来路径长度缩到微米级。路径短了能省下三样东西带宽上得去。并行通道数不再受封装引脚数的限制TSV 可以做到几千上万根每根速率不用很高聚合起来就能到数 TB/s 的量级。能耗降下来。驱动长走线需要大功率的 IO 缓冲器走线越长、电容越大、翻一次比特消耗的能量越多。垂直短互联的驱动成本低得多。延迟可预测。片外访问的延迟受总线仲裁、刷新、行激活影响抖动大堆叠结构里的访问路径短且确定对延迟敏感的逐 token 生成更友好。所以 3D-DRAM 加速器的价值主张不是算得更快而是在同样的算力下把每 token 的数据搬运成本砍掉一大截。这恰好命中了解码阶段的死穴。1.3 它和 HBM-PIM、近存计算、存内计算的区别在哪这块很容易被混为一谈我按计算单元离数据有多近排个序你就清楚了。路线计算单元位置数据搬运距离典型带宽量级灵活性传统 GPU 外挂显存独立逻辑芯片毫米~厘米1~3 TB/s极高近存计算2.5D 中介层与 DRAM 同封装毫米级3~8 TB/s高HBM-PIMDRAM 堆叠的基础裸片百微米级数 TB/s中3D-DRAM 加速器DRAM 层间/层内微米级数 TB/s~十 TB/s中低纯存内计算存储阵列内部纳米级极高低HBM-PIM 走的是在 HBM 堆栈最底下那颗 base die 上加算力的路子基础裸片本来就是逻辑工艺改造成本相对可控但它离 DRAM 阵列还是隔着一层。3D-DRAM 加速器更进一步把一些简单的 MAC 阵列直接铺到存储层的边上甚至和 bank 交织在一起距离更短。代价是 DRAM 工艺天生是做高密度存储的晶体管驱动能力和逻辑速度都远不如先进逻辑工艺所以只能放简单、规则、高度并行的运算比如 GEMV、乘加、向量点积、softmax 的部分近似计算。这就是这类架构的设计哲学用架构上的就近换工艺上的吃亏。复杂的非线性、动态控制、图调度还是交回给主控芯片。2. 架构拆解一颗 3D-DRAM 加速器的分层设计2.1 堆叠分层与 TSV 通道预算怎么算先说分层。一颗典型的 3D-DRAM 加速器从下往上看大概是这么几层最底层是逻辑控制层负责指令发射、地址生成、任务调度、以及与外部主机GPU 或 CPU的接口往上是若干层DRAM 存储层每层里划分成多个 bank group在这些存储层之间或旁边嵌入PIM 计算层或计算区块负责就地做乘加顶层可能还有一层专门做数据汇总和归约。TSV 的通道预算是设计的第一个硬约束我自己习惯这么估单层数据 TSV 数2048 根 单根 TSV 速率4 Gbps 单层带宽 2048 × 4 Gbps 8192 Gbps 1 TB/s 堆叠 8 层存储 8 × 1 TB/s 8 TB/s 聚合带宽这个量级不是拍脑袋来的HBM3 单堆栈已经做到 1024 位宽、6.4 Gbps约 819 GB/s把位宽和层数同时放大理论上到 8~16 TB/s 是合理的工程目标。但要注意TSV 不是越多越好每一个 TSV 都要占面积通常 5~10 微米直径加禁布区、都要耗功耗、都会影响良率。TSV 数量翻倍芯片面积和成本一起上去散热也更麻烦。所以真实设计里常见的做法是少 TSV、高频率和多 TSV、低频率之间的权衡。低频率 TSV 更省电、时序更宽松但需要更多根高频率能省面积但功耗密度上来以后堆叠结构中间的散热就成了大问题——DRAM 对温度非常敏感超过 85℃ 刷新率就得加倍性能反而掉下去。2.2 每层放什么DRAM 阵列、MAC 阵列、片上网络分层确定以后下一个问题就是每层内部的资源怎么切。我的经验是把一层拆成若干个切片slice每个切片里放一组 DRAM bank、一小块 MAC 阵列、一个本地缓冲、以及一个接片上网络的路由节点。MAC 阵列的规模要和 bank 的带宽匹配不然会一边饿死一边堵死。举个具体的一个切片里的 bank 组每秒能吐出 128 字节那么 MAC 阵列的吞吐就得能吃下 128 字节/秒对应的乘加次数。在 INT8 下128 字节就是 128 个操作数如果权重和激活都是 INT8那就是每周期 128 次乘加阵列规模大约 16×8 就够。阵列做大不会更快的因为数据供不上只会白白占面积和漏电。片上网络这块我建议用分层总线 局部 mesh的混合结构。层内用 mesh 短距离互联层间用 TSV 汇聚成一条主干总线主干上再做归约和广播。全 mesh 在 8 层以上的规模里布线会炸掉纯总线又会在热点上堵死。混合结构是折中但代价是路由逻辑复杂编译器的任务映射要做得很细否则容易出现数据在层间来回横跳的灾难。还有一点容易被忽略归约单元的位置。GEMV 之后要做累加如果每个切片各算一部分最后必须归约。把归约放在逻辑控制层是常见做法但那样一来部分和又要在 TSV 上跑一趟。更聪明的做法是在每层放一个小归约树先把层内的部分和合并只把合并后的结果往上传TSV 流量能省下好几倍。2.3 数据流与指令流GEMV 和 KV cache 访问的排布权重的排布决定了 GEMV 的效率。假定模型权重以 INT8 或 INT4 存在 DRAM 层里排布方式要保证同一次 GEMV 用到的权重尽量落在同一个 bank group 里这样一次行激活就能连续吐出一大段数据。如果权重按原始的行主序随便铺bank 冲突会非常严重有效带宽可能只剩理论值的三分之一。我的实测经验是按输出通道优先、每个 bank group 负责一段连续输出通道来切分权重行缓冲命中率能明显提升。同时把同一层的权重按 MAC 阵列的位宽做对齐填充避免跨切片读取。KV cache 的访问是另一个重点。解码阶段每生成一个 token都要把整个 KV cache 读一遍。注意这个读一遍的意思不是读整个缓存而是每个层读该层对应的那份 K 和 V。所以 KV cache 的访问模式是按层切分、每层全量读、逐 token 重复。这种模式特别适合把 KV 存在和该层权重相邻的位置——读到权重的同时顺手把 K、V 也读了不用另外跑一趟 TSV。指令流这边常见的做法是粗粒度指令 微码。控制层发出对第 i 层做 GEMV输入向量 x输出到 buffer j这样一条粗指令各切片的微码序列器自己展开成 bank 激活、数据读出、MAC 计算、部分和回写这一整套动作。这样控制层的发射压力小各切片也能并行展开。代价是微码要针对具体网络结构预先编译灵活性不如纯 SIMT 架构。3. 三条账算清楚带宽、容量、能耗3.1 权重的带宽账tokens/s 是怎么被卡死的我把这笔账写成一段可以直接跑的脚本你换成自己的模型参数就能算def decode_upper_bound(params_b, bits, bw_gbps, kv_gb0.0, efficiency0.7): params_b: 参数量十亿 bits: 权重位宽16/8/4 bw_gbps: 有效带宽GB/s kv_gb: KV cache 体积GB按批量和上下文长度估算 efficiency: 实际可达效率经验值 0.5~0.8 weight_gb params_b * 1e9 * (bits / 8) / 1e9 total_gb weight_gb kv_gb theoretical bw_gbps / total_gb # tokens/s realistic theoretical * efficiency return weight_gb, theoretical, realistic for name, p, b in [(7B-FP16, 7, 16), (7B-INT4, 7, 4), (70B-FP16, 70, 16), (70B-INT4, 70, 4)]: w, t, r decode_upper_bound(p, b, 3350) # H100 级带宽 print(f{name:10s} 权重 {w:6.1f} GB 理论上限 {t:7.1f} tok/s 实际约 {r:6.1f} tok/s)跑出来大概是这么个结果模型权重位宽权重体积理论上限实际可达7BFP1613.5 GB248 tok/s约 170 tok/s7BINT43.5 GB957 tok/s约 670 tok/s70BFP16140 GB24 tok/s约 17 tok/s70BINT435 GB96 tok/s约 67 tok/s这张表说明了两件事。第一量化对解码吞吐的收益几乎和位宽成反比从 FP16 降到 INT4理论上限翻了四倍因为要搬的字节少了四分之三。第二70B 模型在 FP16 下的天花板只有二十几个 token/s这个数字对实时对话来说勉强够用对 Agent、代码补全这种需要快速迭代的场景就非常难受了。3D-DRAM 加速器在这里的贡献是把分母上的带宽换成 8~16 TB/s 量级。同样是 70B FP16140 GB 的权重在 10 TB/s 的有效带宽下理论上限能到 71 tok/s实际也能摸到 50 tok/s 上下。这不是优化这是换了个物理层。3.2 KV cache 的容量账长上下文才是真正的吞噬者很多人只盯着权重忽略了 KV cache。我把公式写出来KV 体积 2 × 层数 × KV头数 × head_dim × 序列长度 × 批量 × 每元素字节数以 LLaMA-2 70B 为例80 层、GQA 下 8 个 KV 头、head_dim 128、FP16 存储每 token 每层 2 × 8 × 128 × 2 字节 4096 字节 4 KB 每 token 全模型 4 KB × 80 320 KB 4K 上下文 320 KB × 4096 ≈ 1.31 GB 32K 上下文 ≈ 10.5 GB 128K 上下文 ≈ 42 GB 批量 32、4K 上下文 ≈ 42 GB看到没有128K 单条上下文消耗的 KV cache差不多是 70B 模型 INT4 权重35 GB的一点二倍。而 KV cache 在解码阶段每个 token 都要被完整读一遍也就是说长上下文场景下 KV cache 的带宽压力会超过权重本身。还有一个隐蔽的成本KV cache 是动态增长的。序列每长一个 token缓存就涨一点而它的物理布局通常是按块分配的。如果不做分页管理碎片化会让有效容量打七折。这也就是为什么现在做推理服务的人都在推分页注意力和 KV 量化——不是为了省磁盘是为了省带宽。3D-DRAM 加速器在这块的优势在于它有条件把 KV cache 和权重放在同一个堆叠体内甚至让两者共享 TSV 主干。KV 的读取和权重的读取在时间上是交错的共用一条高带宽通道比走两次片外总线要划算得多。更激进的设计会直接在存储层里做注意力打分把 Q 广播过去K 就地取、就地算点积只把分数传回来。3.3 能耗账每搬一个比特要付多少电费这是最容易被忽视、但对数据中心来说最要命的一条账。文献里常见的量级是这样的数据搬运路径每次访问能耗量级片外 DRAM 完整路径含 PHY、封装、走线10~20 pJ/bit2.5D 封装上的 HBM3~5 pJ/bit3D 堆叠 TSV 垂直互联0.5~2 pJ/bit片上 SRAM0.1~0.5 pJ/bit我们拿 70B FP16 模型算一下。每生成一个 token要搬 140 GB 的权重也就是 1.12×10¹² 比特。如果走片外路径按 15 pJ/bit 算光是搬权重就要 16.8 焦耳。如果按 20 tok/s 的速度生成光权重搬运的功耗就是 336 瓦。这还没算计算本身的功耗、KV cache 的搬运、以及通信同步的开销。换成 TSV 路径按 1 pJ/bit 算同样的 1.12×10¹² 比特只要 1.12 焦耳功耗直接降到 22 瓦。差了整整一个数量级。这就是就近计算最硬的价值——它不改变你算多少它只改变你搬多少电。当然能耗账不能只看单次访问。堆叠结构本身有漏电、有刷新功耗、有散热成本。3D 堆叠的功耗密度比平面芯片高得多中间层散热困难温度一高刷新率翻倍DRAM 的动态功耗又会往上走。这也是为什么很多设计会把逻辑层放在最底下同时兼任散热通路的角色。4. 落地评估怎么在自己的模型上验证这类加速器4.1 先做一次 Roofline 分析确认瓶颈到底在哪任何优化动作之前先确认瓶颈。用 Roofline 是最快的判断方法把算力除以带宽得到岭点再把你的算子算术强度点上去。算子在岭线左边带宽受限这类架构能帮上大忙。算子在岭线右边算力受限加带宽基本没用。生成式推理里解码阶段的 GEMV、注意力打分、以及大部分逐元素的归一化操作算术强度都在 1~4 FLOP/Byte 这个区间妥妥地在岭线左边。Prefill 阶段的 GEMM 算术强度可以到几百在岭线右边。所以评估这类加速器不要拿 Prefill 的吞吐去做宣传也不要用 Prefill 的场景去否定它。正确的做法是分阶段测Prefill 阶段看 TTFT首 token 时间这类架构的贡献有限主要靠算力。Decode 阶段看 TPOT每 token 时间和吞吐这是主战场。我一般会做一张两阶段对照表把 TTFT、TPOT、吞吐、能耗四个指标分别记下来再和同代的纯 GPU 方案做对比。只报一个端到端平均吞吐很容易掩盖掉真正的收益点。4.2 软件侧的配合量化、分页、投机解码硬件再好软件不配合照样跑不出效果。几个必须一起上的动作权重量化。INT4 对带宽的收益是直接的但精度损失要评估。我建议对下路的 FFN 层大胆用 INT4对注意力的投影层用 INT8敏感层保留 FP8 或 FP16。分层混合量化比全模型统一量化效果好得多代价是要多存一份量化配置。KV 分页与量化。KV cache 用固定块比如 16 个 token 一块管理块和块之间不要求物理连续。这样做的好处是碎片化可控长序列不会因为找不到连续空间而失败。KV 量化到 INT8 时注意对 K 的量化误差比 V 更敏感通常 K 保留更高精度V 可以压得更狠。投机解码。这条在带宽受限的场景下收益特别大因为小模型做草稿、大模型做验证一次验证可以确认多个 token。原来一次搬一遍权重只能出 1 个 token现在出 3~4 个等效带宽直接翻几倍。代价是验证阶段的 batch 变大算术强度上来了对 3D-DRAM 的算力部分要求更高。这里有个平衡点草稿长度太长验证失败率高反而浪费带宽我实测 4~6 是比较稳的区间。算子融合。解码阶段每个算子单独跑一遍都要把中间结果写回再读出来白白消耗带宽。把 RMSNorm、残差加、以及部分激活融合进 GEMV 的尾处理里能省掉可观的搬运量。这件事在 PIM 架构上尤其重要因为 PIM 单元擅长规则运算不擅长来回搬运。4.3 影响范围从云端推理成本到端侧长上下文这类架构一旦成熟影响面比想象中大。云端推理成本结构会变。现在推理服务最大的成本项是显存容量和带宽带来的卡成本一块高端卡的显存容量决定了你能同时服务多少路请求。3D-DRAM 加速器把带宽和容量做成同一件事单位 token 的成本会往下走。但反过来它的通用性不如 GPU需要针对固定模型结构编译这就要求服务商在灵活性和效率之间做选择。端侧长上下文设备会变多。手机、笔记本、车载这类设备最大的限制是功耗和内存容量。3D 堆叠本身就是在有限面积里塞更多存储再加上就近计算把功耗压下来本地跑一个 7B 到 13B 模型、上下文 32K 的助手是完全可能的。这对隐私敏感、离线可用的场景意义很大。长上下文应用会被解锁。RAG、代码仓库级补全、长文档摘要、多轮 Agent这些应用共同的痛点是上下文越长越慢。当 KV cache 的读取速度不再是瓶颈这些应用才有机会真正跑顺。但它不会取代通用 GPU。训练、多模态、动态控制流、稀疏结构这些还是得靠通用架构。更现实的形态是异构GPU 负责 Prefill 和调度3D-DRAM 加速器负责 Decode 的权重流和 KV 流。5. 常见问题与排查技巧实录5.1 典型问题速查表现象大概率原因排查动作有效带宽只有峰值的三分之一bank 冲突严重行缓冲命中率低看权重排布的跨 bank 分布按输出通道重排吞吐随上下文变长急剧下滑KV cache 读取量超过权重统计每层 KV 读字节确认是否超过权重体积层间数据来回横跳TSV 利用率高但吞吐低任务映射没有做层内局部化用编译器把同一算子的数据绑定到同一层温度上来后性能不升反降DRAM 刷新率翻倍动态功耗上升降低堆叠中间层的功耗密度调整逻辑层位置部分和归约成为热点归约全部放在控制层TSV 流量翻倍每层加小型归约树层内先合并再上传量化后精度掉得厉害K 和 V 用了同一档位K 保留更高精度V 可以压得更低投机解码收益不稳定草稿长度不合理调整草稿长度到 4~6观察接受率曲线批量化后延迟反而变差算术强度上来了但算力没跟上重新做 Roofline确认是否已转到算力受限这张表是我自己整理出来的排查顺序。遇到问题先看带宽利用率再看 KV 占比再看温度最后才怀疑编译器。大部分性能不达标其实是排布问题不是架构问题。5.2 几个踩过的坑和避坑心得第一个坑把峰值带宽当有效带宽用。我见过太多评估报告直接拿 TSV 的理论带宽做上限计算得出能到多少多少 token/s的结论然后在实测里掉到三分之一。原因很简单DRAM 的行激活、预充电、刷新都会吃掉带宽再加上 bank 冲突和归约流量有效带宽能到峰值的 50%~70% 就算不错了。做容量规划的时候直接按 0.6 的系数打折会更接近现实。第二个坑只优化 Decode忘了 Prefill。端到端延迟是 TTFT 加 TPOT 乘以输出长度。如果你把 TPOT 压到很低但 TTFT 还是两秒用户感知上并不会变好。特别是长 prompt 的场景Prefill 的算力需求可能比 Decode 的带宽需求更值得优化。我的经验是先把 Prefill 的算力利用率做上去再回头攻 Decode 的带宽。第三个坑忽略 KV cache 的写放大。每生成一个 token 都要往 KV cache 里写一份 K 和 V这个写操作也是要占带宽的。很多分析只算读不算写导致理论值和实测对不上。写量是每层每个 token 4 KB70B 那个例子量级和读量在同一个数量级不能当零成本处理。第四个坑低估编译器和任务映射的工作量。硬件设计出来只是开始把模型切分成上千个微码任务、合理分配到各个切片、保证负载均衡这部分工作量往往比硬件设计还大。而且网络结构一变微码就要重新编译。评估这类架构的时候一定要把软件栈的成熟度作为独立维度来看不要只看硬件指标。提示在任何面向生产的评估里务必区分理论峰值和持续可用两组数字并且把 KV cache 的读写流量、归约流量、刷新开销全部计入。这三项加起来通常会让纸面数字缩水 30% 到 50%。第五个坑散热没提前设计。3D 堆叠的功耗密度高中间层的热量很难导出。DRAM 超过一定温度就加倍刷新性能跟着掉。我在测试里见过满载跑十分钟后吞吐下降 15%的情况。所以散热方案要在架构阶段就确定包括逻辑层的摆放位置、TSV 的密度上限、以及是否需要微流道冷却。散热不是后置工程问题它是架构约束。最后分享一个实用的小技巧在做架构对比时我习惯把每 token 能耗和每 token 成本两个指标放在一起看。有些方案吞吐很漂亮但能耗和成本都翻倍实际部署的时候并不划算。生成式推理的规模化瓶颈最终会落在电费和采购成本上而不是峰值性能上。我个人在评估这类加速器时最大的体会是它更像是把内存墙拆掉一段而不是造了一台更快的计算机。瓶颈在哪里收益就在哪里。如果你的模型和场景恰好卡在解码阶段的带宽上这类架构的价值就会非常直接如果你的场景是训练或者重计算的批处理那它帮不了你多少。先算清楚自己的账再决定要不要跟这条路线。
