企业官网建设流程全解析

磐久UMX：UALink+下一代AliSCM，GPU直连的PCM内存池

PCM

PCM是Phase-Change Memory（相变内存）。它用一种特殊材料在两种状态间切换来存数据：结晶态和非晶态的电阻不同，控制器读取电阻就能判断存的是 0 还是 1。写入时会用电加热改变材料状态；断电后状态仍能保持，所以它是非易失性内存。(st.com)

放回这篇文章的语境里：PCM 是AliSCM 背后的存储介质，目标是承接 HBM 放不下、但又不适合放到较慢 SSD 上的温 KV Cache。它不是比 HBM 更快，而是希望以较大的容量和较低的成本，补上 HBM 与 SSD 之间的一层。

GPU

先抓住一点：**GPU 平时并不是每做一步计算都要 CPU 帮忙搬数据。**CPU主要负责调度、启动任务、准备数据；真正运行模型计算时，GPU主要从自己的 HBM 里读写数据。文章讨论的是：HBM 不够放时，GPU怎么高效使用外面的内存。

HBM是High Bandwidth Memory（高带宽内存），它描述的是一种强调高带宽的内存类型。

HBM，芯片架构

**很多用于 AI 和 HPC 的独立 GPU 加速卡有自己的 HBM。**这里“自己的”是说 HBM 通常紧挨着 GPU，集成在同一个封装里，专门给 GPU 高速读写。例如 AMD Instinct MI300X 配有 192GB HBM3。(amd.com)

不过，不是所有 GPU 都用 HBM：一些显卡用 GDDR；集成显卡则可能直接使用 CPU 所用的系统内存。

普通 CPU 通常使用 DDR 内存，比如主板上的 DDR DIMM，并不通常配 HBM。但确实有少数例外：Intel Xeon CPU Max 系列集成了 HBM；AMD MI300A 则把 CPU 和 GPU 芯片放在同一封装里，共享 HBM。(intel.com)

所以，前面文章里说的“GPU 的 HBM”，就是 GPU 身边那一层高速但容量有限的内存。文章想讨论的是：HBM不够放时，能不能让 GPU 通过互联访问外部更大、更便宜的内存。

原本流程

原本怎么跑

以大模型推理为例，流程大致是：

1. CPU接收请求、准备输入，并安排 GPU 执行。
2. 模型权重通常提前放进 GPU 的 HBM。
3. GPU处理输入提示词（prefill），计算各层结果，并把后续生成会用到的KV Cache写入 HBM。
4. 每生成一个新 token，GPU都要读取之前的 KV Cache 来计算，再把新 token 对应的 KV 追加进去。
5. 对话越长、同时处理的请求越多，KV Cache 通常就越大。HBM装不下时，系统可能减少并发或上下文长度，也可能把部分 KV 移到 CPU 内存、远端内存或 SSD，之后需要时再取回来。这样的分层缓存和卸载在现有推理软件中已经存在。(developer.nvidia.com)

可以把它想成：GPU的 HBM 是工作台，KV Cache 是不断堆上来的工作材料。工作台满了，就得把暂时不用的材料搬到别处；但材料搬远了，再取回来就要花时间。

问题

文章认为卡在哪里

它盯着的核心问题是HBM 的容量和成本：KV Cache 越来越大，但不能简单地把所有数据都放进高成本的 HBM。

外部存储各有取舍：CPU DRAM、远端内存或 SSD 能提供额外容量，但数据需要经过相应的链路和设备；越慢的层，越不适合频繁访问。文章希望找到一层比 HBM 容量大、比 SSD 更适合频繁读写、又能让 GPU较直接访问的内存。

要注意，文章把 CXL 概括为“CPU的协议、GPU不能原生用”，这是为了突出新路线而做的简化。实际系统能否让 GPU访问某类外部内存，要看整个平台的硬件和软件支持，不能只看协议名称。UALink的特点是提供 GPU/加速器之间的 load/store/atomic 内存访问语义；它并不意味着任何 GPU、PCM 设备接上去就能直接工作。(ualinkconsortium.org)

文章想法

文章想怎么解决

它提出把内存按热度分层：

• 活跃、马上要算的 KV 留在 GPU HBM。
• 暂时不活跃、之后可能复用的温 KV 放到 AliSCM 的 PCM。
• 更冷的数据再放到 SSD。

同时，设想让 GPU经由UALink Switch访问外部 PCM：

GPU → UALink 交换网络 → 内存端点/控制器 → PCM

这样做的目标是让外部内存成为 GPU更容易访问的“扩展内存层”，减少数据为了访问外部容量而绕行或反复搬运的成本。UALink相关资料描述了这种 load/store/atomic 访问方式，也说明跨加速器的数据一致性需要软件协同处理。(ualinkconsortium.org)

所以，它要解决的不是“GPU算得不够快”，而是：

• GPU显存装不下越来越多的 KV Cache；
• 用 HBM 承载所有 KV 的成本太高；
• 下沉到更慢的内存或存储后，访问和搬运可能拖慢推理；
• 希望增加可用容量，同时尽量保持 GPU访问路径短、成本可控。

它不打算用 PCM 替代 HBM，而是让 HBM 继续放最热的数据，PCM 接住一部分温数据。PCM 仍然比 HBM 慢，文章提出的效果也有待具体产品和实测验证；特别是 GPU到 PCM 的真实端到端延迟、带宽和软件管理方式，不能仅凭架构示意图判断。