Flash想让大模型少堆GPU，先过带宽和耐久两关- 大数跨境

首页

Flash想让大模型少堆GPU，先过带宽和耐久两关

半导体产业报告

2026-09-10

导读：HBF把Flash推到GPU显存位置，靠的是容量；能不能跑出推理收益，要看读带宽、写入速度和耐久能不能一起跟上。

HBF（High-Bandwidth Flash）试图将 Flash 推至 GPU 显存层级，其核心优势在于容量。然而，能否在推理场景中实现收益，取决于读带宽、写入速度及耐久性是否能同步跟上。

大模型推理正加剧显存危机。以 Llama 3 405B 为例，其权重约 756GB，128K 上下文下单请求 KV cache 近 50GB；若按 10 tokens/s 服务目标，单 token 需读取近 800GB 数据。单纯堆叠 HBM GPU 虽能解决容量瓶颈，却导致显存带宽采购过剩，实际利用率不足。

## 01| 大模型率先挤满单卡显存

405B 参数级模型使单卡 GPU 遭遇容量墙。NVIDIA H200 单卡 HBM3e 容量为 141GB，带宽 4.8TB/s；HGX H200 集群（8 卡）总容量达 1,128GB，带宽 38.4TB/s，勉强容纳超 800GB 的模型权重、KV cache 及计算缓冲。

该方案虽可行，但成本与资源利用率不佳。模型分片依赖 NVLink 等高速互连，容量与带宽被捆绑采购。问题在于，LLM decode 阶段往往受限于容量而非带宽，导致大量 HBM 带宽闲置。

当前 GPU 采购逻辑已被显存容量主导。随着模型与 KV cache 持续增长，系统被迫增加 GPU 数量以满足容量需求，即便新增的计算力与带宽未被充分利用。

## 02| HBF 的核心诱惑：减少 GPU 堆叠

High-Bandwidth Flash（HBF）旨在重构这一账本。闪迪设想的 HBF 相比 HBM4 拥有超 10 倍容量，同时提供可比带宽。容量的跃升使得模型权重和长上下文 KV cache 可留存于单卡附近，无需依赖多卡拼接显存。

三种 GPU-memory 架构对比：

HBM-only：每 GPU 配 8 个 HBM stack；
HBM-HBF：每 GPU 配 1 个 HBM stack 和 7 个 HBF stack，HBM 专用于中间数据；
HBF-only：每 GPU 配 8 个 HBF stack，并在 logic die 集成 40MB SRAM 保存中间数据。

配置差异显著。HBM4 方案单 GPU 容量为 288GB，而 HBF/HBF+ 方案可达 3,620GB 或 4,096GB。量级变化直接推高 batch size，摊薄模型权重读取成本，从而提升单 GPU 吞吐量。

## 03| 容量扩张后，带宽不可掉队

HBF 的优势并非无偿获取。其潜力建立在 GPU core、memory stack 及互连均达峰值的前提上，目前尚缺芯片与系统稳定达成该峰值的工程验证。

读带宽是首要门槛。HBF/HBF+ 按单 stack 1.6TB/s 建模，8 stack 可达 12.8TB/s；而基于低延迟 NAND 的 CONV/CONV+ 方案仅 2.45TB/s 至 2.80TB/s。高读带宽是 HBF+ 超越 HBM 方案的关键前提。

NAND 侧面临挑战。Z-NAND 和 XL-FLASH 等低延迟 NAND，单 stack 带宽约 80GB/s 至 256GB/s；即使页读取延迟压至 1µs，达标仍需每 die 具备 27 个 plane。乐观估计下，传统 NAND HBF 模型单 stack 带宽仅约 350GB/s。容量可渲染愿景，但读带宽将工程拉回现实。

## 04| 长上下文收益显著，写入成本随之而来

HBF 在长上下文和宽松 SLO 场景下收益更大。测试覆盖 SHORT、MID、LONG 三类负载，LONG 场景输入长达 103.5K token。上下文越长，KV cache 占用越高，HBF 大容量越能支撑大 batch；SLO 放宽后，系统更易通过大 batch 摊薄权重读取开销。