华为云弹性内存存储EMS技术架构深度解析：从两层云架构到三层云架构的演进

大模型推理正在成为AI算力消耗的核心场景，但一个长期困扰行业的问题是——GPU算力买了不少，推理吞吐却始终上不去。问题的根源往往不在算力本身，而在于“存力”——即数据访问的速度和效率。

传统的“计算-存储”分离架构中，计算层（GPU/NPU）和存储层（SSD/云硬盘）之间存在巨大的性能鸿沟。GPU的显存带宽高达TB/s级别，而远端存储的访问延迟在毫秒级，两者相差几个数量级。大模型推理过程中，KV Cache的频繁读写、多轮对话的历史状态保存、公共前缀的重复计算，都受制于这个鸿沟。

华为云在2026年推出的弹性内存存储（Elastic Memory Service，简称EMS），正是为了解决这一存力痛点而生。它将传统的“计算-存储”两层云架构升级为“计算-内存-存储”三层云架构，新增的“内存层”以DRAM为主要存储介质，为LLM推理提供缓存和加速。本文将从架构设计、关键技术、应用场景三个维度，深入解析EMS的技术原理。

一、存力瓶颈：为什么算力买再多也跑不快

在深入EMS架构之前，先理解它要解决什么问题。

大模型推理的性能瓶颈主要集中在三个层面：

显存墙。单张GPU的显存容量有限（A100 80GB、H100 80GB），而大模型的参数和KV Cache都需要驻留在显存中。以Qwen2-72B模型为例，FP16精度下模型参数本身就占用约144GB显存，单卡根本放不下，必须做模型并行。即便做了并行，剩余显存能支撑的并发请求数依然极其有限。

KV Cache膨胀。多轮对话场景中，随着对话轮次增加，KV Cache呈线性增长。一个1024 token的上下文，KV Cache约占用2-4MB显存。100个并发请求就是200-400MB。长上下文场景（如32K、128K）下，这个数字会急剧膨胀。

重复计算浪费。多个请求如果使用了相同的System Prompt或公共前缀，传统方案下每个请求都要独立计算一遍这些公共部分的KV Cache，算力被白白浪费。

这三个问题的本质是同一个——显存不够用，而更便宜的DRAM内存又没有参与到推理加速中来。EMS的核心理念就是：把DRAM内存从“闲置资源”变成“加速资源”。

二、EMS产品架构：三层设计

EMS的产品架构由三部分组成：领域专用服务SDK、分布式内存池和管理面。

领域专用服务SDK：包含面向不同AI应用场景的插件和接口服务SDK，提供业务系统接入、业务数据布局和近数据处理等功能，实现业务请求的内存加速。目前主要面向大语言模型推理场景，通过分布式内存池提升处理效率并降低成本。

分布式内存池：负责跨节点的内存空间管理、数据负载均衡等任务，通过空间池化提供内存缓存共享访问。内存池采用融合部署方式，直接利用AI服务器中的空闲DRAM资源，将DRAM内存池化以实现分布式共享，并进行本地亲和调度和访问。

EMS管理面：负责EMS服务的部署、监控、升级及运维管理，通过华为云的云原生基础设施为用户提供一站式的云上运维解决方案。

三、核心技术一：DRAM池化与分层联动

EMS最核心的技术突破在于DRAM资源的池化与分层管理。

在传统的AI服务器中，每台服务器都有大量DRAM内存，但通常只被本地CPU访问，资源利用率偏低。EMS将这些分散在各服务器中的空闲DRAM资源进行池化，形成一个统一的分布式内存池。这个内存池对上层应用是透明的——推理框架可以通过EMS SDK像访问本地内存一样访问远端内存池中的数据。

更关键的是分层联动。EMS并非简单地替代显存，而是与GPU显存形成分层缓存体系：

L1缓存（GPU显存） ：存储当前正在处理的KV Cache，延迟最低

L2缓存（EMS内存池） ：存储历史对话的KV Cache和公共前缀，容量更大

L3存储（持久化存储） ：存储模型参数和冷数据

当GPU显存不足时，系统自动将不活跃的KV Cache从显存卸载到EMS内存池；当需要再次访问时，再从EMS内存池加载回显存。整个过程对上层应用透明，开发者无需修改推理代码。

据华为云官方数据，EMS的盘级存储架构配合三合一芯片，可实现TB级读取速度，整体性能领先业界50%。

四、核心技术二：以存代算，消除冗余计算

大模型推理中有一个容易被忽视的性能浪费——公共前缀的重复计算。

假设一个客服场景中，所有用户请求都包含相同的System Prompt（例如“你是一个专业的客服助手，请用中文回答……”）。在传统推理架构下，每个用户请求都要独立计算这一段Prompt的KV Cache。如果有100个并发请求，这段公共前缀就被计算了100次。

EMS的解法是KV Cache缓存与共享。当第一个请求计算完公共前缀的KV Cache后，系统将其存入EMS内存池。后续请求到达时，推理框架通过EMS SDK直接从内存池中读取这段KV Cache，无需重新计算。

这种“以存代算”的策略带来两重收益：

减少冗余计算：公共前缀越长、并发请求越多，节省的算力越显著

降低首Token时延（TTFT） ：传统方案中，首Token生成必须等完整Prefill阶段完成。有了EMS缓存后，公共部分直接命中，只需计算用户输入的差异化部分，TTFT大幅降低

五、核心技术三：本地亲和调度与访问

分布式内存池面临的一个经典问题是——数据放在哪个节点上？访问时从哪个节点读？

如果数据存放在节点A，而请求被调度到节点B，那么每次访问都要跨节点读取，网络延迟会抵消掉内存加速的效果。EMS通过本地亲和调度解决这个问题。

当推理框架通过EMS SDK写入KV Cache时，系统会记录写入的节点位置。后续调度器在分配推理任务时，优先将请求调度到数据所在的节点，实现“数据在哪里，计算就在哪里”。这种亲和性调度大幅减少了跨节点数据访问，将内存池的性能优势最大化。

六、访问方式与生态集成

EMS提供了两种访问方式：

API方式：通过RESTful API直接发放和管理EMS资源，适用于需要精细控制存储资源的场景。

SDK方式：模型推理框架（如vLLM）及企业自研推理框架通过集成EMS SDK访问弹性内存存储服务。这种方式对开发者最友好——只需在推理框架中集成EMS SDK，即可透明地使用EMS内存池加速，无需修改模型代码或推理逻辑。

目前，EMS主要面向大语言模型推理场景。随着技术成熟，未来有望扩展到更多AI应用场景，如文生图、视频生成等对内存带宽和容量有高要求的任务。

七、从两层架构到三层架构：一场存力革命

EMS的意义不仅在于一个具体产品，更在于它代表了一种架构范式的转变。

传统的“计算-存储”两层架构中，计算层和存储层之间隔着巨大的性能鸿沟。EMS引入的“内存层”恰好填补了这个鸿沟——它比存储快得多（DRAM纳秒级延迟 vs SSD微秒级延迟），比显存便宜得多（DRAM单位成本远低于HBM）。

这种三层架构让AI基础设施的资源配比更加灵活：热数据驻留显存，温数据缓存内存池，冷数据沉淀持久化存储。每一层各司其职，共同构成了一个从快到慢、从贵到廉的完整存储梯队。

总结

华为云EMS通过DRAM池化、以存代算、本地亲和调度等关键技术，将分散在各AI服务器中的空闲DRAM资源整合为一个统一的分布式内存池，为大模型推理提供高性能缓存加速。它解决的不仅是“显存不够用”的表面问题，更是“算力买了跑不满”的深层矛盾。

对于正在将大模型推理搬上生产环境的团队来说，理解EMS这类内存池化技术的原理，有助于在架构设计中做出更合理的资源规划——与其一味堆GPU，不如想想如何让现有的显存和内存更高效地协同工作。算力可以买，但存力瓶颈买再多的卡也解决不了。