不用堆GPU了？中科院团队推出FlashAccel，LLM推理能效近翻倍

当下大语言模型的落地部署中，算力与存储的矛盾正在愈发突出：一方面模型参数规模持续遵循缩放定律增长，数百亿、数千亿参数的模型逐渐成为产业常用选项，另一方面长上下文、多轮对话、智能体等场景的普及，让推理过程中的KV缓存占用也同步飙升。

目前主流GPU搭载的高带宽内存（HBM）容量增长速度远跟不上模型和缓存的扩容需求，单卡H200的141GB HBM甚至无法完整存放千亿参数模型的权重，更不用说预留空间给KV缓存，这直接限制了推理批次大小，导致算力利用率低下，企业往往需要部署多卡集群才能满足业务需求，随之而来的是硬件成本飙升、跨卡通信开销大、系统复杂度升高等一系列问题。

论文标题：FlashAccel: Leveraging High-Bandwidth Flash for High-Throughput LLM Inference

论文链接：https://arxiv.org/pdf/2607.10186

研究背景

大语言模型推理过程分为预填充和解码两个阶段，其中解码阶段需要频繁访问模型权重和KV缓存，属于内存 bound 任务，内存容量的限制会直接拉低整体吞吐量。

容量不足首先会限制解码阶段的批次大小，小批次会降低权重相关操作的算术强度，导致GPU算力利用率偏低；其次内存压力会迫使KV缓存被提前驱逐，多轮对话场景下无法复用历史缓存，需要重复计算增加开销；最后单卡容量不足意味着必须采用多卡部署，不仅硬件成本翻倍，跨卡通信开销最高可占总延迟的20%，系统可靠性也会随着集群规模扩大而下降，千卡规模的集群平均每7.9小时就会出现一次故障。

此前已有不少方案尝试用普通闪存缓解内存容量瓶颈，这类方案通常将模型权重存在闪存中，配合存内计算利用闪存内部并行性，但是整体带宽只有数百GB/s，算力也远低于GPU，仅适合边缘场景的低吞吐量需求，无法满足数据中心的高吞吐推理要求。

高带宽闪存（HBF）的出现为解决这个问题提供了新的思路，它的带宽与HBM相当，同时保留了闪存高密度、非易失的特性，和GPU集成后可以大幅扩展内存总容量，但是直接应用HBF也面临三个核心挑战：

• 一是闪存本身访问延迟比HBM高40倍左右，会拖累端到端推理延迟；
• 二是HBF的峰值带宽需要极高的并行度才能达成，不合理的数据布局会大幅降低带宽利用率；
• 三是HBF、HBM、GPU的异构内存资源缺乏成熟的管理方案，传统的页表机制不支持持久化，传统闪存栈的地址转换开销又过高。

针对这些挑战，中科院计算所的团队提出了FlashAccel，这是一套软硬协同的异构内存系统，从架构、数据布局、系统软件三个层面协同优化，充分释放HBF的容量优势，同时规避其固有缺陷，最终实现高吞吐量的大语言模型推理。

FlashAccel核心设计思路

FlashAccel将HBF、HBM和GPU核心整合为统一的异构加速系统，通过分层设计解决HBF的落地痛点。

硬件架构设计

FlashAccel提供两种HBF与GPU的整合方案：第一种是共置整合（CLI），将HBF和GPU放在同一封装内，部分替换HBM栈，在提升总内存容量的同时降低HBM成本；第二种是级联整合（CSI），将HBF通过HBM基片与GPU菊花链连接，保留全部HBM栈，最大化HBM的容量和带宽。在异构内存的分工上，HBM负责存储小体积、频繁更新的中间数据，利用其低延迟特性保障性能；HBF负责存储大体积、读为主的模型权重和KV缓存，利用其高容量特性扩展系统内存上限。

每个HBF栈包含8个闪存die和1个基片，通过硅通孔（TSV）互连，每个闪存die扩展到96个plane以提升平面级并行度。团队还利用闪存电路die上的闲置硅区，为每个plane配备了SRAM缓存，基片上也集成了额外的SRAM，总SRAM容量足够支撑双缓冲流水线，用于数据预取以隐藏闪存的高访问延迟。

数据布局优化

要充分发挥HBF的峰值带宽，需要让数据访问尽可能匹配闪存的并行特性，FlashAccel针对权重和KV缓存的不同访问特点设计了专属的数据布局。

静态模型权重的推理执行顺序是固定的，因此可以离线完成布局优化：FlashAccel将每个算子的权重切分为页大小的单元，按照执行顺序轮询映射到所有plane和通道，当前算子的权重映射完成后，紧接着从最后一个分配的plane的下一个位置开始映射下一个算子的权重，从全局视角实现权重在所有plane上的负载均衡，配合预取机制可以让HBF的带宽利用率接近峰值。

KV缓存的布局相对复杂，因为每一步的活跃请求都会动态变化，FlashAccel采用了多步优化策略：

• 首先将新写入的非驻留KV块聚合为尽可能多的完整超页再写入HBF，剩余不足一个超页的块随机分配到不同plane避免热点；
• 写入完成后计算所有plane的平均负载，将过载plane的多余KV块卸载到HBM，利用HBM的低延迟特性平衡负载，避免额外的HBF写入损耗寿命；
• 访问KV缓存时按照超页粒度读取，最大化并行度，配合FlashAttention按块计算部分注意力结果再按请求归约，避免plane访问冲突；
• 每步解码新生成的KV缓存先暂存在HBM中，凑够完整超页后再批量写回HBF，避免小写入浪费带宽。此外FlashAccel选择了256KB的KV块大小，在平衡plane负载的同时控制HBM的占用压力。

系统软件设计

FlashAccel的系统层包含HBF感知的存储管理层和统一编程模型两部分，解决异构资源的管理和使用问题。

存储管理层针对大语言模型推理的写入特性做了轻量化设计：模型权重和KV缓存都属于追加写的数据，不需要原地更新，因此FlashAccel去掉了传统闪存栈中的闪存转换层（FTL），直接在对象的索引元数据中记录每个数据单元的物理地址，省去了两层地址转换的开销。同时采用隔离块分配策略，将权重对象和每个请求的KV缓存对象放在独立的块中，删除某个请求的KV缓存时不会影响其他对象，减少写放大降低闪存损耗。

编程模型向上层应用暴露统一的虚拟地址空间，应用不需要关心数据实际存储在HBM、HBF还是SRAM中。针对权重和KV缓存的不同访问特点，编程模型提供了专属接口：

• 权重是静态只读的，通过NandMmap接口一次性映射到虚拟地址空间即可长期复用；
• KV缓存需要按请求分组访问，通过GroupCreate将当前步活跃请求的KV缓存逻辑上组合为一个组对象，配合GroupMmap、GroupArrange、GroupWrite接口完成分组读取、负载均衡和追加写入操作。

此外还提供了SramPrefetch预取接口，将预取操作和计算任务异步执行，让闪存访问延迟和计算过程重叠，进一步隐藏HBF的高延迟，就算预取未完成，应用也可以直接访问HBF中的数据，不会出现执行阻塞。

性能表现与应用价值

团队在四种主流大语言模型上完成了测试，包括Qwen3-235B、Qwen3-Coder-480B、LLaMA3.1-405B、DeepSeekV3-671B，覆盖了不同的注意力机制和FFN结构，同时设置了长上下文、智能体多轮对话两种典型工作负载，基准为8卡DGX-H200节点。

测试结果显示，在100ms的延迟约束下，8卡CSI配置的FlashAccel单卡平均吞吐量是8卡H200的2.54倍，能效提升1.93倍；成本更低的8卡CLI配置吞吐量也达到了H200的2.04倍。即便仅用4卡CSI配置，因为HBF容量足够支撑大模型权重和KV缓存，不需要跨卡通信，单卡吞吐量仍然超过8卡H200，大幅降低了部署硬件成本。

多轮对话场景下，FlashAccel的高内存容量可以存储所有会话的KV缓存，缓存命中率达到100%，而16卡H200的KV缓存命中率比FlashAccel低50%，需要重复计算的词元数量是FlashAccel的近9倍，进一步放大了性能差距。寿命方面，按照最高写入负载计算，单卡HBF每天的写入量不到1TB，1TB容量的SLC HBF足够支撑5年以上的部署需求，不存在寿命瓶颈。

消融实验显示，FlashAccel的三个核心优化缺一不可：去掉预取机制会导致吞吐量下降55%，去掉KV缓存布局优化会导致吞吐量下降15%，去掉权重布局优化会导致吞吐量下降7%，三个优化共同作用才让HBF的性能追上甚至超过纯HBM的方案。

目前FlashAccel不需要修改大模型本身，仅需在硬件和系统层面完成适配即可落地，对于云服务商和大模型服务提供商而言，这套方案可以大幅提升推理吞吐量，降低单位服务成本，同时减少部署所需的GPU数量，降低集群系统复杂度。未来随着3D闪存技术的发展，HBF的存储密度还会进一步提升，面积开销也会持续降低，有望成为下一代AI加速卡的标准配置，从根本上解决大语言模型推理的内存容量瓶颈。