FlashAccel: Leveraging High-Bandwidth Flash (HBF) for High-Throughput LLM Inference
Xinyu Wang, Yalong Xue, Xiaotian Sun, Xiaoyu Zhang, Xinjiang Zhang, Chunmeng Dou, Xueqi Li, Xiaoming Chen
cs.AR
2026-07-11
FlashAccel 把高带宽闪存与 HBM 共置于 GPU，用预取和专用布局消化 4μs 读延迟。仿真里，六叠 HBF 的 CSI 方案在 100ms 延迟约束下每卡吞吐 2.49 倍、能效 1.93 倍。
HBM 容量已经跟不上 LLM 推理。权重动辄上百 GB，长上下文和多轮对话再把 KV cache 撑到单卡装不下。H100 跑 Qwen3-32B，大约 64GB 留给权重，剩下 16GB 只能撑 8 条 8K 请求。Decode 阶段是访存瓶颈，batch 上不去，算力就闲着；KV 也存不住，多轮复用变成反复重算。扩卡能解容量，跨机通信和成本一起上来。
High-Bandwidth Flash（HBF）是一类把闪存峰值带宽拉到接近 HBM 的专用栈，密度更高，还非易失。把 HBF 塞进 GPU，容量够了。但闪存读延迟约 4μs，HBM 大约 100ns，差 40 倍；带宽要靠几千个 plane 同时读才拉得满；HBF、HBM、SRAM 三套资源也没有现成管理栈。容量优势不会自动变成吞吐。
FlashAccel 是中科院计算所的软硬件协同方案，把 HBF、HBM 和 GPU 核绑成一套异构内存加速器。硬件有两种接法。级联集成 CSI 把 6 叠 HBF 接到 H200 原有 6 叠 HBM 旁边，容量和带宽都加。共置集成 CLI 用 5 叠 HBF 换掉 5 叠 HBM，只留 1 叠 HBM，更省、带宽少 16.7%。每叠 HBF 是 8 颗 SLC Flash die 加 1 颗 base die，单叠 192GB 闪存加 32MB SRAM，标称 768GB/s。每颗 die 拆成 96 个 plane，再每 32 个绑成一个 megaplane，共用命令电路。对外读粒度叫 hyperpage：一次把所有 megaplane 上同一偏移的页一起读出来，把平面并行吃满。电路 die 上每个 plane 放 32KB SRAM，base die 再放一层 cache，用来预取、盖掉那 4μs 的阵列读时间 tR。
数据怎么摆，决定带宽能不能摸到峰值。权重按推理图的执行顺序切成 megapage，round-robin 铺到全部 megaplane，打成连续 hyperpage。单看一个 12MB 的 MoE expert，只能点亮大约 3072/4916 个 plane；按访问顺序排好，连续读才不会被源码声明顺序里夹着的无关矩阵拖成 straggler。
KV cache 更难，活跃请求集合每步都变。FlashAccel 沿用 PagedAttention 的 KV block，把一层里 N 个 token 的 slice 对齐到 megapage，并且一块 Flash block 只属于一个请求，驱逐时直接擦、不做搬移。读之前做一次选择性复制：超载 megaplane 上多出来的页拷到 HBM，访问改走 HBM，HBF 侧就能按平均负载发 hyperpage。新 KV 先攒在 HBM，凑满 K 个 megablock（K 等于 megaplane 数）再一次性并行写回，写也能走 hyperpage。M=32 是折中：再大，HBM 里要缓冲的 KV 会把 CLI 撑爆。
系统层砍掉传统闪存转换层 FTL。权重只读、KV 只追加，物理地址写进对象元数据就够，GPU 直接发物理地址。编程接口把 HBF、HBM、SRAM 映射进同一套虚拟地址：NandMmap 映射权重，GroupCreate / GroupMmap / GroupWrite 管一组活跃请求的 KV，SramPrefetch / SramRelease 让内核显式预取。运行时把预取从计算图里抽成队列，和计算异步重叠。页表先指向 HBF，数据到了再改指向 SRAM，计算侧始终走同一个虚拟地址。
评测是搭在 LLMCompass 上的事件驱动仿真，基线是 DGX-H200 的 8×H200（每卡 141GB HBM3e、4.8TB/s）。模型覆盖 Qwen3-235B、Qwen3-Coder-480B、LLaMA3.1-405B、DeepSeekV3-671B。上下文两档：长上下文 8.11K/2.53K，agent 多轮 15K/6K。延迟 SLO 取 50ms 和 100ms，每组用满足 SLO 和容量约束的最大 batch。LLaMA3.1-405B 在 15K/6K 下每条请求要 10GB KV，8×H200 的 batch 上限 30；50ms SLO 下 8×CSI 理论 batch 能到 110。
| 配置 | 100ms SLO 每卡吞吐 vs 8×H200 | 备注 |
| 8×CSI | 2.49× | 6 叠 HBF 并排，主结果 |
| 8×CLI | 2.00× | 5 叠 HBF 换 HBM，带宽少 16.7% |
| 全设置平均 8×CSI | 2.10× | 含 50ms SLO |
同 batch=256 的 Qwen3-235B 上，完整 FlashAccel 的延迟跟纯 HBM 只差约 4%。拆掉预取、权重布局、KV 布局，吞吐分别掉 55%、7%、15%；什么都不做的 Plain HBF 掉 65%，已经低于 HBM GPU。预取是三件套里贡献最大的那件。
50ms 更紧。CLI 在 DeepSeek-V3 和 Qwen3-235B 上会略输给基线，带宽不够。4 卡 CSI/CLI 在 50ms 下，LLaMA-405B 和 Qwen3-480B 光读权重就超过 50ms，这组配置直接服务不了。扩到 16 卡，HBM 系统跨出 NVLink 走 RDMA，带宽大约掉 9 倍，专家并行的 all-to-all 把吞吐吃掉；8 卡 HBF 每卡吞吐反而高于 16 卡 HBM。
多轮 KV 复用上，8×CSI/CLI 能把所有 session 的 KV 留下，命中率到理想值；16×H200 的命中率仍低 50%。需要重算的 token 最多少 89%。写方面，CSI 读带宽 4.6TB/s，写只有 245.8GB/s；最重配置每卡每秒写 988MB KV，占 3.9ms，开销 0.4%。按 5 年、1M 次擦写（保持时间从 3 年降到 3 天，论文保守只按 10 倍延寿）算，1152GB 的 CSI 有 1,125,000 TBW，对上 148,570TB 写入。读能量 8pJ/bit，是 HBM3e 的 2.68 倍，CSI/CLI 的整机功耗升到 1.31×/1.23×，但每焦耳产出的 token 仍到 1.93×/1.66×。单叠面积 149mm²，比 HBM3e 的 121mm² 大 1.23 倍，密度仍高 6.50 倍。
这不是又一个「把权重丢 SSD」的 offload 故事。普通 SSD 带宽差一个数量级，decode 延迟在数据中心里不可用。AiF、Lincoln、Cambricon-LLM 那些 in-flash 方案把计算塞进闪存，面向端侧，带宽几百 GB/s、算力几个 TFLOPS，KV 也不往闪存里放。FlashAccel 的判断更干脆：高吞吐场景该让 GPU 继续算，闪存只负责把容量和带宽补上。
对做推理系统的人，这篇可迁移的部分主要是布局和接口：执行序铺权重、按请求隔离 Flash block、超载 slice 复制到 HBM、凑齐 megablock 再并行写回。硬件本身还是纸面栈，HBF 商用进度要另看。如果目标是在 NVLink 域内用更少卡撑更大模型，CSI 这条路在仿真里说得通。
全部数字来自扩展 LLMCompass 的仿真，没有流片，也没有在真实 HBF 上跑通服务栈。HBF 的时序沿用 XL-Flash 的 tR=4μs、tProg=75μs，plane 容量还按缩小 4 倍做了保守处理，但仍是模型。预取要改 kernel、改页表、改调度，工程量被一笔带过。
写寿命成立的前提是 KV 写入量接近他们用 DeepSeek 报告和 agent 长度比推出来的 988MB/s，以及保持时间可以按 10 倍延寿来算。MHA、更长上下文，或更高 QPS 会把这笔账改掉。CLI 在 50ms SLO 上已经摸到带宽墙。面积按 96 层 wordline 算比 HBM 大 23%，300 层以上的密度是展望，不是这套设计已经做到的。
论文也写明：闪存写带宽和耐久远不如 DRAM，只是在 GQA/MLA 把写入量压下去之后，才够把 KV 放进 HBF。