HBF并非廉价版HBM：低带宽容量型负载是机会，密集与高批量推理可能成为成本陷阱

概览

这份Hot Chips 2026教程从系统架构角度研究HBF在AI推理中的适用边界。核心结论是，HBF的价值来自大容量而非高带宽：它可改善小批量MoE、稀疏长上下文KV及本地专家存储，但在密集模型、高批量或强调机架吞吐的部署中，HBM仍是更经济的选择。

核心观点

报告首先将HBF放入以β和α描述的存储技术版图：β代表每GB成本，α代表单位容量可提供的带宽。HBF处于低β、低α的容量型位置，可在同等成本下提供约8—16倍于HBM的容量，但不能被视为廉价版HBM。报告用公式“$mem = β·max(C, I·b/α)”判断存储成本，其中C是需要容纳的数据量，I·b是带宽需求；真正决定经济性的不是购买多少便宜GB，而是容量约束和供数带宽约束中较高的一项。因而，低$/GB并不自动等于低$/token。 工作负载特征决定HBF是否落在有效区间。MoE模型可以完整保存庞大的专家权重，但每个Token只激活少量专家，因此在小批量B、较低访问强度I下，模型主要受容量而非带宽限制，低带宽可能足够。密集模型则需要更广泛地读取权重；随着批量、访问强度或I·b上升，HBF的带宽不足会迫使系统配置更多容量来满足供数需求，越过临界点后HBM反而更便宜。报告因此把HBF的优势限定在“小B、低I”的MoE子区间，而将Dense和高B负载留给HBM。 部署比较包括纯HBM、纯HBF和“2×HBF＋6×HBM”的混合方案，三者可做到相同成本但容量和带宽不同。短上下文、低批量模拟中，HBF可以在成本上获胜，但约85%的容量处于闲置状态；HBM则可能为超过容量墙后的性能付费。长上下文情形同样不是容量越大越好：只有I·b保持较低时，额外容量才有经济价值。混合方案尝试让HBM充当热门专家缓存，但在混合查询下专家热度会趋于平坦，因此缓存只在低批量或将相似查询成组处理时有效。 报告进一步进行了72-GPU机架级、以解码为中心的模拟：模型为Kimi-K2 1T、FP4，主要上下文为100万Token输入和1000 Token输出，并补充32k/8k及1k/8k场景；每个数据并行实例的批量为1—512，张量并行用于满足容量，数据并行填满机架，成本按三年资本开支与运营开支摊销后的比率表示。纯HBM配置为TP8·DP9，纯HBF为TP1·DP72，混合配置为TP2·DP36。纯HBM、纯HBF及混合方案的每个数据并行实例容量分别为2.3 TB、4.1 TB和2.5 TB；全机架容量分别为20.7 TB、294.9 TB和89.3 TB，即1倍、约14倍和4.3倍。 容量扩张伴随着带宽代价。纯HBM机架聚合带宽为1,584 TB/s，纯HBF为922 TB/s、约0.6倍；混合方案为1,418→279 TB/s。相应每GPU带宽分别为22.0 TB/s、12.8 TB/s和19.7→3.9 TB/s。在机架成本和功耗相当的条件下，报告结论是HBM始终能处理更多Token；HBF更适合以单机或单实例容量为约束的部署，因为它能让原本需要多GPU容纳的模型装入一块GPU。换言之，“机架级每Token成本”和“单机能否装下模型”会导向不同的内存选择。 HBF的硬件特征也限制了适用方式。报告列出的三个等级最大用户带宽分别为0.384、1.536和3.072 TB/s，互连速率分别为8、16和32 GT/s；容量配置包括8层256 GiB和16层512 GiB。接口支持64 B—4 KiB读取、4 KiB写入及4 KiB页，而实现最大带宽需要64 KB读取、1 MB写入并按64 KB对齐。HBF通过DMA读写，不面向GPU缓存层级；与HBM混用时需要独立内存管理。其数据在85°C下上电保持时间约24小时，生命周期必须由主机管理，并需谨慎控制写入以达到约10年寿命或避免耗尽100%耐久度。整体上它是读取优化、写入受限、主机管理的介质，数据放置首先是软件问题。 软件生态方面，报告将vLLM视为当前生产部署的默认重点，同时列举SGLang、LMDeploy和Modular MAX等通用推理引擎，以及TensorRT-LLM、OpenVINO、AWS Neuron和Google JetStream等厂商优化栈。现有vLLM路径主要针对CPU或LMCache，并未直接支持HBF。要使用HBF，需要新增分配器或后端、冷热数据放置策略、异步预取以及耐久度遥测，否则硬件容量优势无法转化为生产推理收益。 Kimi K3示例展示了较明确的数据放置方案。该2.8T模型总权重为1.56 TB，其中93%的字节、约1.45 TB，是MoE专家权重，具有“写一次、冷读取”的特征，报告认为适合HBF专家池；其余7%、约110 GB权重更适合HBM。每条100万Token序列的KV Cache约为30 GB，HBF还可作为KV卸载池和前缀缓存，并以更大容量替代主机DRAM锁页内存。由此形成分层架构：HBF保存庞大但较冷的专家权重和卸载KV，HBM保存活跃权重及高带宽数据。 稀疏注意力进一步扩大HBF的适用空间。对长上下文或多轮KV，系统可以低成本保存完整上下文，只读取top-k部分；报告给出的读取比例φ＝top-k/context约为1%—2%，低于临界值φ*=α/l。在这一条件下，HBF容量可以保留全部KV，而较低读取量避免触及带宽墙。不过这项优势明确依赖DSA、CSA、Kimi-Linear等稀疏注意力模型，并不适用于需要密集读取全部上下文的架构。 HBF容量还可能减少专家并行通信。传统示例以8块GPU分片专家并在每层执行all-to-all；若两个节点可分别在本地HBF中保存专家，就能减少专家并行分片，并显著降低或消除all-to-all通信。容量由此不仅解决模型能否装下的问题，还可能回购一部分通信开销，但收益仍取决于专家访问局部性及预取带宽。 最终结论是，HBF是一种精确工具而非通用替代品：它只在低带宽需求的MoE小批量/低访问强度和长上下文稀疏KV场景中具备成本优势，区间之外则可能成为陷阱。若要扩大其价值，读取带宽α必须提高，相对HBM的每GB成本差距β必须保持足够大，同时还要解决写入耐久度、写带宽、延迟和软件支持问题。

分析框架

报告先用β、α、容量C及带宽需求I·b建立内存成本方程，再按MoE与Dense、批量大小、上下文长度和访问稀疏度划分工作负载。随后比较纯HBM、纯HBF和混合配置，并用Kimi-K2的72-GPU机架模拟检验容量、带宽和三年摊销成本；最后结合Kimi K3的数据布局、vLLM软件路径、稀疏注意力及专家并行通信，确定HBF的落地条件与边界。

方法论与常识提炼

• （词表外方法）

  β—α内存成本方程

  报告以β表示每GB成本、α表示单位容量带宽，并通过$mem = β·max(C, I·b/α)比较满足容量和供数带宽所需的内存成本，用于说明低每GB价格为何不一定降低每Token成本。

• （词表外方法）

  机架级每Token成本模拟

  报告在相同72-GPU机架、成本和功耗口径下，调整张量并行与数据并行配置，比较纯HBM、纯HBF及混合内存的容量和带宽，并按三年资本开支与运营开支摊销评估推理经济性。

• 行业/产业分析框架替代效应分析

  按工作负载划分HBF替代边界

  报告没有把HBF视为HBM的全面替代品，而是按MoE或Dense、批量大小、上下文稀疏度及部署尺度判断其可替代HBM或主机DRAM的具体数据池。

标的映射与对比

研报将主题/逻辑映射到具体标的时的结构化摘要（优势、劣势、对比与风险）。

• HBF

  用于AI推理中的大容量、低带宽内存层，可承载MoE专家池、卸载KV及前缀缓存。

  优势

  同等成本容量可达HBM的约8—16倍；适合写一次、冷读取数据，并可减少专家分片和all-to-all通信。

  劣势

  带宽较低、写入受限、需要DMA和独立内存管理，生产软件支持尚不完整。

  对比

  72-GPU模拟中容量约为纯HBM的14倍，但聚合带宽约为0.6倍；机架级每Token吞吐不及HBM。

  风险

  若批量或访问强度升高、注意力读取不稀疏，带宽墙会使其由低成本容量方案变成成本陷阱。

• HBM

  用于高带宽、活跃权重及密集或高批量推理，是报告的基准内存方案。

  优势

  机架级带宽和Token吞吐更高，适合Dense、高B及频繁访问的数据。

  劣势

  每GB成本较高，容量受限时需要增加张量并行或GPU数量才能容纳模型。

  对比

  纯HBM机架容量为20.7 TB、聚合带宽为1,584 TB/s；纯HBF分别为294.9 TB和922 TB/s。

  风险

  在以单机容量为主要约束的低带宽负载中，可能为超过实际需要的带宽付费。

关键数据

• HBF相对容量定位同等成本约8—16× HBM容量HBF以容量优势换取较低带宽，并非廉价版HBM。
• HBF三个等级最大用户带宽0.384 / 1.536 / 3.072 TB/s对应Grade 1、Grade 2和Grade 3。
• HBF互连速率8 / 16 / 32 GT/s对应三个硬件等级。
• HBF容量配置8层256 GiB；16层512 GiB体现其大容量定位。
• 72-GPU机架容量HBM 20.7 TB；HBF 294.9 TB；混合89.3 TB分别为1×、约14×和4.3×。
• 每数据并行实例容量HBM 2.3 TB；HBF 4.1 TB；混合2.5 TB模拟配置分别为TP8·DP9、TP1·DP72和TP2·DP36。
• 机架聚合带宽HBM 1,584 TB/s；HBF 922 TB/s；混合1,418→279 TB/s纯HBF约为纯HBM的0.6×。
• 每GPU带宽HBM 22.0 TB/s；HBF 12.8 TB/s；混合19.7→3.9 TB/s反映大容量配置的带宽代价。
• 机架模拟模型Kimi-K2 1T @ FP4主要上下文为100万Token输入/1000 Token输出，批量为每个DP 1—512。
• 成本口径三年摊销包含资本开支与运营开支，并以比率展示。
• 低批量HBF容量利用约85%闲置容量HBF虽在低B下具备成本优势，但大量容量未被使用。
• Kimi K3总权重1.56 TB模型规模为2.8T。
• MoE专家权重1.45 TB，占93%字节具有写一次、冷读取特征，报告认为适合HBF。
• 其余权重110 GB，占7%报告认为更适合HBM。
• 每条长序列KV Cache30 GB/100万Token序列HBF可用于KV卸载池和前缀缓存。
• 稀疏注意力读取比例φ约1%—2%报告称其低于临界值φ*=α/l，可将完整KV保存在HBF而只读取top-k。
• 上电数据保持约24小时，85°C需要主机管理数据生命周期。
• 目标使用寿命约10年需要谨慎管理写入，否则可能耗尽100%耐久度。

影响与含义

报告认为，AI内存配置应由工作负载和部署尺度共同决定，而不能只比较每GB价格。HBF可让超大模型或KV池在更少GPU、单机或本地节点中容纳，并可能降低专家并行通信；但在追求高机架吞吐、使用密集模型或提高批量后，其低带宽会推高每Token成本。实际部署更可能采用分层方案：HBF承载庞大且冷的数据，HBM保留活跃且带宽敏感的数据。

风险

• 批量、访问强度或I·b升高后，HBF会触及带宽墙，HBM可能成为更低成本的选择。
• 热门专家缓存在混合查询下可能失效，因为专家热度会趋于平坦。
• HBF写入耐久度、写带宽和延迟需要主机侧严格管理，否则可能影响寿命与可用性。
• 现有vLLM路径主要面向CPU或LMCache，缺少HBF分配器、放置策略、异步预取和耐久度遥测。
• 稀疏KV场景的优势依赖稀疏注意力模型；密集读取上下文时该优势不成立。

后续跟踪

• 关注HBF读取带宽α能否提高，以及相对HBM的每GB成本差距β能否维持。
• 关注写入耐久度、写带宽和延迟问题能否得到处理。
• 关注vLLM等推理引擎是否加入HBF后端、专用分配器、放置策略、异步预取及耐久度遥测。
• 关注多智能体访问的局部性、预取带宽上限以及内存配置与工作负载的匹配。
• 关注稀疏注意力模型和相似查询批处理能否将实际访问比例维持在HBF的有效区间。