1. 核心能力速览这次我们聊的“HBM 不只是内存”不是一个开源工具也不是一张显卡驱动更新而是三星对 HBMHigh Bandwidth Memory高带宽内存技术路线的一次方向性调整。过去十年HBM 在 AI 芯片里的角色很明确把数据高速喂给计算单元自己只负责存和传。三星的新愿景是让 HBM 从“存储部件”变成“参与计算的系统组件”简单说就是让数据在靠近内存的地方就开始处理而不是全部搬到 GPU/CPU 核心后再算。从现有的材料来看这次方向有几个值得关注的点能力项说明技术方向HBM 从纯存储向存内计算、近数据计算、智能内存方向演进核心价值降低数据搬运开销缓解 AI 算力芯片的“内存墙”瓶颈潜在影响对象大模型训练、推理、RAG 检索、向量数据库、边缘计算、HPC重点收益带宽利用率提升、功耗降低、端到端任务延迟下降硬件形态HBM 堆叠结构 计算逻辑单元/控制逻辑增强具体产品方案需以三星官方发布为准软件影响内存分配、数据布局、算子库、编译链路、性能分析工具都要重新适配适合读者AI 部署工程师、大模型推理优化人员、存储/内存方向开发者、硬件评测爱好者从材料看三星并没有给出完整的公开技术参数比如具体带宽数字、存内计算单元的运算精度、延迟提升百分比等这些都不能凭空编造。但方向本身已经足够影响后续软硬件选型判断如果 HBM 开始承担计算任务那我们在代码里对“显存/内存”的认知就要变了。2. 适用场景与使用边界2.1 适合谁第一类是大模型推理优化工程师。当前推理瓶颈往往不在算力而在显存带宽和容量。如果 HBM 能够完成一部分数据预处理、向量计算、KV Cache 管理那 GPU 核心的压力会小很多批量推理的吞吐可能明显提升。第二类是训练框架开发者。大规模训练时梯度累积、张量并行、序列并行都涉及大量跨设备数据交换。HBM 如果提供近数据规约或者内存侧梯度聚合能力通信时间就可能压缩。第三类是向量数据库、RAG 应用背后的基础设施团队。向量检索本质上是“计算密集 带宽密集”型任务HBM 侧如果能做近数据相似度计算查询延迟和功耗都会更可控。2.2 不适合什么场景HBM 新愿景不适合普通个人开发者。现在个人电脑上的“内存优化”“内存清理”和 HBM 没有直接关系网上的内存清理工具、内存压缩开关教程也不适用。HBM 目前主要服务数据中心、AI 服务器和高端计算场景普通用户近期不会有可感知变化。同时HBM 存内计算也不是所有算法都适合。它擅长数据密集、逻辑简单的操作复杂控制流、稀疏不规则访问、动态图类的计算仍然要回到通用计算单元。遇到这类情况ROI 就要重新评估。2.3 安全与合规边界HBM 常被误传为“禁售”“限制”等这类表述容易涉及地缘争议本文不讨论。需要明确的是数据中心里的 HBM 存储着模型权重和用户数据任何新硬件特性例如近数据计算都不应该绕过权限检查也不应该把未经授权的数据复制到计算单元。部署前先确认数据合规、模型授权和审计边界。3. HBM 为什么需要“不只是内存”3.1 内存墙问题现代 AI 计算里芯片算力增长远快于内存带宽增长。GPU 可以很快做矩阵乘法但数据如果喂不进去计算单元就只能空转。这个差距就是“内存墙”。传统 HBM 解决了一半问题用 3D 堆叠和宽接口把带宽拉高但数据依然要走“内存 - 总线 - 计算核心 - 寄存器 - 计算单元”这条完整路径。三星新愿景的着眼点就是把一部分计算下沉到 HBM 内部。比如数据聚合、归约、比较、筛选这类操作在 HBM 的存储体附近就能完成不需要把整个数据块搬到 GPU 核心。数据搬得少延迟就低功耗也低。3.2 传统 HBM 的角色传统 HBM 本质上是一块高带宽存储工作模型是计算核心发起读请求。HBM 控制器解析地址。数据从 DRAM Cell 中读出经过 TSV硅通孔和逻辑层。数据通过 Interposer 传到计算核心。计算核心完成运算结果再写回。这里有大量数据搬运。对于矩阵乘法这种算子输入矩阵和中间结果需要在 HBM 和计算核心之间来回移动越大的模型搬运开销越高。3.3 新愿景的变化三星的路线图里HBM 会比传统 HBM 多做几件事存内计算在 DRAM 阵列附近加入轻量级计算逻辑直接处理部分算子。近数据计算在 HBM 逻辑层集成处理单元处理数据过滤、格式转换、归约等任务。智能内存控制根据访问模式动态调整数据布局减少数据搬家。需要强调的是从材料看这些还是“方向”不是已经商用的具体规格。实际落地时会面临良率、功耗、编程模型等多重挑战。4. 软件系统栈面临的变化HBM 改变之后最先受影响的不只是硬件而是整个软件栈。以下几点是开发者后续需要关注的。4.1 内存分配与数据布局如果 HBM 内部有计算单元数据布局就不能只考虑“连续读写的带宽”还要考虑“哪部分数据要在 HBM 里先算掉”。传统malloc/cudaMalloc这种统一分配方式可能不再最优内存分配器需要感知 HBM 的计算能力。后续可能出现类似给普通数据分配普通 HBM 页。给适合近数据计算的数据分配“可计算页”。给热点数据分配具备缓存一致性的特殊区域。这类似 NUMA 时代把线程和内存绑定到同一节点只不过现在是把计算任务绑定到靠近它的 HBM 存储体。4.2 算子库与编译链路像 cuBLAS、cuDNN 这样的算子库后续如果要发挥 HBM 计算能力需要提供“近内存算子”或者“PIM 算子”。编译器也需要知道哪些子图可以卸载到 HBM。这时候类似原始子图A B - C - D 可卸载子图A B - CHBM内完成 保留在核心C - D复杂映射这种子图划分大概率会由编译器自动完成但开发者需要理解它否则性能特征会很迷。4.3 调试与性能分析现在开发者靠nvidia-smi看显存占用靠rocm-smi看 AMD GPU靠perf看 CPU 事件。HBM 如果承载了计算任务还需要看到HBM 内部计算单元利用率。HBM 到核心的数据搬运量。HBM 内完成的算子耗时。功耗拆分存储功耗、计算功耗、搬运功耗。这些性能观测项在现有工具链里大概率没有直接指标需要硬件厂商补齐。5. 面向开发者的验证思路虽然具体硬件还没到开发者手里但现在可以先准备一套验证方法等开发板或云实例开放时直接套用。5.1 建立基线先跑一组当前硬件上的标准任务作为基线。建议覆盖纯带宽测试连续读、连续写、混合读写。典型 AI 算子矩阵乘、Attention、Reduce、Gather。端到端推理一个小模型的完整推理延迟和功耗。示例脚本逻辑# 带宽基线测试以常见工具为例实际命令按具体环境调整 bandwidth_test --read_size 1G --mode read bandwidth_test --read_size 1G --mode write bandwidth_test --read_size 1G --mode copy5.2 定位可迁移算子把任务里的算子逐一列出标记哪些是数据密集型且逻辑简单的。这些算子最可能被 HBM 计算单元接管。判断标准输入数据远大于输出数据。计算操作简单比如加法、比较、取最大值。对数据局部性要求不高。没有复杂控制流比如动态循环、分支跳转。典型例子包括向量归一化、Top-K 筛选、Embedding 聚合、简单的相似度计算。5.3 模拟近数据处理效果采用 CPU/GPU 侧预聚合来模拟“如果数据不用全搬会省多少时间”。先算一遍数据搬运量再算一遍预聚合后的搬运量对比端到端时间。import numpy as np import time # 模拟传统方式全部数据搬到计算核心 data np.random.rand(1024, 1024).astype(np.float32) start time.time() result np.sum(data, axis0) trad_time time.time() - start # 模拟近数据方式先做部分归约减少搬运量 start time.time() partial np.sum(data.reshape(1024, 256, 4), axis2) # HBM内聚合 result2 np.sum(partial, axis1) # 核心继续聚合 new_time time.time() - start print(ftraditional: {trad_time:.4f}s, new: {new_time:.4f}s)这个脚本不能说测试精确但能帮你理解数据量压缩得越早越能减少后续搬运开销。5.4 实际环境回归测试等实际支持 HBM 新特性的硬件出来后可以直接复用以上流程重点观察能否把预聚合算子“下发”到 HBM。真实延迟是否比模拟数据更好。显存占用、功耗、温度变化。是否需要手动指定数据布局还是编译器自动处理。关键点是不要一上来就直接跑大模型先从小算子开始确认行为符合预期再逐步扩大。6. 批量任务与调用接口的预期HBM 如果引入计算能力对上层接口设计也会产生连锁影响。6.1 批处理窗口传统批量推理中GPU 会把多个请求拼成一个 batch提高利用率。HBM 介入之后部分请求可能在数据进入 GPU 核心之前就被处理掉。比如 batch 里的重复前缀、公共 KV Cache如果能在 HBM 里提前去重GPU 计算负担会明显下降。对批量任务开发者来说后续要关注的接口可能包括支持把某个算子绑定到 HBM 计算单元。支持“批内预过滤”和“批内去重”。支持指定输出数据留在 HBM而不是立即写回主存。6.2 批量任务通用模板在没有实际 API 前可以先按下面的伪代码设计任务队列方便后续迁移# 批量任务处理模板实际接口需要以厂商 SDK 为准 tasks load_tasks(input_dir) for task in tasks: # 第一步判断任务是否适合 HBM 近数据计算 if is_offload_candidate(task.operator): # 第二步把任务提交到 HBM 计算队列 handle submit_to_hbm(task) else: handle submit_to_compute_core(task) result wait_and_collect(handle) save_result(result, output_dir)这个模板的意义在于提前把“任务是否需要近数据处理”的逻辑抽象出来后续只需要替换submit_to_hbm和submit_to_compute_core的真实实现业务层不用大改。6.3 失败重试近数据计算如果异常应该能回退到传统路径。批量任务里要保留一个开关# 策略配置示例 hbm_compute: enabled: true fallback: true # 失败时是否回退到 GPU 核心计算 timeout_ms: 50 max_retry: 2这个设计比较重要。HBM 内计算单元的调度策略、并发能力、资源隔离机制目前都没有公开材料保守的工程做法就是“能卸载就卸载不能卸载就回退”保证任务永远不卡死。7. 资源占用与性能观察方法HBM 新愿景的直接目标是提高性能但资源占用观察方式会和现在不同。7.1 现有观测工具先用现有工具建立习惯# 查看显存占用和 GPU 利用 nvidia-smi -l 1 # 查看内存带宽部分系统工具 perf stat -e mem-stores,mem-loads ./benchmark # 查看 CPU 内存带宽 numastat -v这些工具可以让你在硬件升级前就清楚当前瓶颈在哪里。如果一个任务已经达到带宽极限HBM 新特性才有明显收益如果瓶颈在计算或锁竞争HBM 再强也帮不上忙。7.2 新版需要新增的指标后续如果有 HBM 计算能力建议至少观察HBM-to-GPU 数据流量单位GB/sHBM 内计算算子平均执行时间被卸载算子数量 / 总算子数量因数据少搬运而节省的功耗功耗在数据中心是一个关键指标。近数据处理减少搬运后同样的训练/推理任务可能以更低功耗完成这意味着总功耗预算不变的情况下可以塞进更多计算卡。7.3 如何降低资源占用无论是否使用 HBM 新特性这几个方向都可以提前做减少中间张量用算子融合替代多步写回。数据布局对齐保证 HBM 访问连续减少地址碎片。减少 dtype 转换FP32 和 BF16 混用会增加内存搬运。提前过滤无效数据注意不要为了过滤而引入更大开销。对多数 AI 服务来说真正的问题不是“内存不够”而是“数据搬运太多”。HBM 计算化本质是在给数据搬运做减法。8. 常见问题与排查方法问题现象可能原因排查方式解决方案新增 HBM 计算功能后训练结果不一致算子数值精度发生变化对比卸载前后中间张量的误差分布开启更高精度计算或关闭该算子的卸载近数据计算队列延迟波动大批内数据大小不均观察队列长度和任务耗时分布增加任务切分或加超时回退带宽利用率没有提升数据布局碎片化用性能分析工具看内存访问模式统一对齐减少小对象高频读写卸载后功耗不降反升HBM 计算单元与核心计算单元争抢功耗对比不同算子的功耗分时曲线调整卸载策略只对收益最大的算子卸载代码无法编译工具链不支持 HBM 算子属性查看编译日志确认算子是否被识别使用旧路径编译或者升级 SDK批量任务卡死HBM 队列排队阻塞未设置超时查看队列状态和超时计数加超时回退转移到核心计算新工具链不兼容旧模型模型用了内存布局约束之外的特性检查模型算子与布局标记重新导出模型更新布局配置显存占用虚高调试模式下保留大量中间结果关闭调试日志开启内存池复用建立内存复用池减少反复分配从实际情况看第一批踩坑大概率集中在“数值一致性和调试工具缺失”上尤其是混合训练精度下HBM 内计算单元的数值表现会直接影响到最终收敛结果。提前保留一份“只走 GPU 核心计算”的备用链路是值得做的工程备份。9. 最佳实践与使用建议把 HBM 新愿景落到实际工程里可以使用以下策略先做瓶颈分析。确认任务到底卡在带宽还是卡在计算。如果带宽已经打满HBM 新特性才有明显价值。选对卸载算子。只把数据密集、逻辑简单、结果可以验证的算子下沉到 HBM比如大矩阵的归约、Top-K、相似度粗筛。保留回退机制。所有依赖 HBM 计算能力的路径都必须有 CPU/GPU 回退版本这是分布式系统和数据工程的常识在异构内存场景里同样适用。建立可对比基线。升级硬件前后同一任务跑一遍记录延迟、吞吐、功耗和电价成本。没有基线数据性能优化就无从谈起。关注工具链成熟度。硬件能力强是一回事SDK、驱动、调试工具完备是另一回事。第一代开发工具通常问题不少起步阶段建议控制生产环境切换的节奏。合规和授权先行。HBM 中存储的数据涉及模型权重、用户数据、企业机密。任何新硬件特性都必须在授权范围内使用尤其不建议在未审计的工具链中传入生产数据。从工程角度看HBM 新愿景最有价值的不是“跑分更高”而是它提供了一条绕过内存墙的新路径。路径本身是好路径但要不要走、先走哪一段还是要看你的任务特征。比如大模型推理的 KV Cache 管理、RAG 系统里的向量粗筛、训练任务里的梯度压缩与聚合这些场景和 HBM 新特性高度匹配优先实验而图神经网络里的稀疏不规则访问则短期内更适合留在传统计算路径里。10. 总结与下一步三星提出“让 HBM 不只是内存”本质上是在 AI 计算走到带宽瓶颈之后把计算能力和存储能力重新组合。这个方向不用等产品落地现在就值得业务和技术人员关注你和 HBM 的关系会在未来几年从“申请显存”变成“编排存储侧的计算资源”。最容易踩的坑不是硬件不支持而是软件思维没跟上——继续把所有计算都默认放在 GPU/CPU 核心只把 HBM 当容量池用那新特性的收益就浪费了。最快的验证方式是在当前环境里列出所有算子的“数据搬运倍数”找到输入输出比很高的算子先做模拟卸载等真实硬件和 SDK 出来后用一套统一的任务提交代码直接切换。建议收藏备用。后续随时可以回来对照哪些算子被 HBM 接管了哪些接口变了哪些显存优化手段要重写。技术路线走到今天内存不再是配角它要被重新定义而软件会跟着再长出一层新体系。