从计算到存储，阿里云打通 AI 落地的“任督二脉”

云计算的牌桌上，AI 算力竞赛已是刀刀到肉。当行业逐渐对“堆卡”祛魅，真正的较量早已转移到看不见的战场——架构是否精妙；是否紧密贴合业务需求；以及如何破解规模定律（Scaling Law）效应减弱的魔咒。

在 8 月 14 日的飞天发布时刻，国内公有云一哥阿里云亮出底牌，发布通用计算、容器计算及存储服务三项产品更新。这三大产品看似“分管”不同任务，实则巧妙地串联出一条 AI 落地业务场景的完整路径，每一步都为下一步铺平道路，环环相扣，层层递进。

对于行业而言，阿里云此次发布的意义也不止于一次产品升级，其背后的产品升级逻辑也在引导行业重新思考——AI 时代，云基础设施的本质到底是什么。

场景化实例，定义极致性能与资源利用效率

传统 x86 服务器运行数据密集型业务时，常常卡在“算力不够强、吞吐不够快、内存不够大”这三道硬限制上。

此次飞天发布时刻，阿里云共发布三款企业级实例，把同一批 AMD 硬件做成三档规格，用户按需取用即可：

• u2a：CPU 与内存比例适中，价格最低，适合日常网站或轻量推理等通用需求。

• g9a：CPU 主频更高，能大幅提升单进程任务数据的处理效率，适合在线型应用场景。

• g9ae：采用物理核设计，算力更高，内存带宽更大，I/O 能力更强，适合高并发的计算密集型任务。

三款实例均搭配了 AMD 最新第五代 EPYC 处理器（Turin ）。阿里云和 AMD 双方的合作最早可追溯到 Rome 时期，当时就与 AMD 合作进行芯片定制，到 Milan 时期开始规模商业化，性能提升 15%，Genoa 时期性能则提升 25%。

到今天，服务于数据中心的 EPYC 系列处理器，采用业界领先的 chiplet 架构，已经演进到第五代，即 AMD EPYC 处理器都灵 (Turin)。Turin 采用了全新的“Zen 5”核心架构，Zen 5 架构每时钟周期指令（IPC）比上一代提升 17%；结合 Turin 支持全链路 AVX 512 的能力，为 AI 和高性能计算（HPC）提供高达 37% 的 IPC 提升。

在 Turin 处理器基础上，通过阿里云软硬一体的 CIPU 架构驱动，此次发布的三款企业级实例实现了针对差异化场景的产品布局，让不同业务直接落在最匹配的档位，节省资源的同时也帮企业节省了算力预算。

首先来看面向中小型企业的 u2a。

“u”实例为通用算力型“universal”实例的简称，是一款为中小企业量身定制的云服务器。基于阿里云飞天云计算操作系统和云基础设施处理器（CIPU），“u”实例让中小企业像使用水、电和煤气一样，便捷获取性能强劲、性价比出众的云计算服务，无需投入精力自建或运维硬件设施。

此次全新升级的 u2 系列中，阿里云推出了首个基于 AMD EPYC 处理器的“u”实例——u2a。该系列涵盖两款细分产品，提供了企业级独享算力，目前仍处于定向邀测阶段，预计于 8 月 30 日正式开启商业化。

u2a 采用自研双单路服务器架构，单颗 CPU 故障不会影响另一颗，能够显著提升服务器的稳定性。性能上，u2a 实例性能基线较 u1 提升 20%，支持最高 15% 的算力突发能力；网络基线带宽为 16Gbps，支持突发至 25Gbps；最大规格可支持 64vCPU。

面向通用场景，u2a 能满足企业不同层级的数据处理需求，通过屏蔽代系差异和较 u1 提升 50% 的性价比，将企业级算力的门槛大幅降低，让更多中小企业能享受到技术红利。

跟随 u2a 一同发布的，还有第九代 ECS 性能旗舰产品，AMD 企业级实例 g9ae。

对于大数据、搜推广、视频转码等数据密集型业务，g9ae 实例瞄准内存带宽、I/O 带宽不足的行业痛点，基于 Turin D 处理器，创新性地采用了物理核设计，摒弃了传统的超线程虚拟化思路。这意味着每个 vCPU 都独占 L3 缓存和内存通道，算力不再因通道带宽不足而被压制。

阿里云之所以能首创物理核设计，离不开底层硬件的支持。

事实上，Turin 包含 Turin-C（Turin Classic）、Turin-D（Turin Dense）两款 CPU，都使用 Zen5 的微架构，其中 Turin-C 使用了 Zen5 CCD，而 Dense 是 Zen5c CCD。

Zen5 和 Zen5c 微架构相同，指令集相同，IPC 提升相同，区别在于 Zen5c 的核心计算单元（CCD）通过芯粒（chiplet）架构支持更高的核心密度，从而支持阿里云实现首创的 “物理核设计”。

“物理核”设计让 g9ae 实例单 vCPU 算力提升高达 60%，在视频转码等业务中性能提升高达 65%，并能极大降低核心交易系统的长尾时延，性能输出更稳定。

在 AMD 强大硬件的基础上，阿里云自研操作系统又将其性能充分“兑现”了出来。阿里云弹性计算产品经理姬少晨介绍，g9ae 的极致性能还来源于软硬件的深度融合。阿里云把自研的 Alibaba Cloud Linux 3 与 AMD 最新的 Turin 服务器做了“基因级”适配，涉及两百多个内核补丁、改了近 2 万行代码，相当于把操作系统“重新编译”了一遍，专门针对 AMD 的多核、内存通道、IO 路径做优化。

针对 MySQL 查询场景，操作系统存储引擎的预读机制会把数据提前加载到 CPU 的高速缓存中，再借助 g9ae 的超大内存带宽，查询速度再提升 10%；针对搜推训练场景，操作系统的网络协议栈采用“零拷贝”技术，数据包从网卡到应用内存“一次到位”，单节点推理性能再提 15%。

除极致性能外，端到端的数据安全能力也是 g9ae 的一大亮点。g9ae 开机即由 CIPU 可信根从 BIOS 到 kernel 再到操作系统开启全链路度量，防止恶意植入；运行期间，AMD 机密计算给内存加硬锁，数据可用不可见；在数据传输阶段，首发 VPC 加密能力，实现了数据传输过程中的安全防护。

然而，尽管 g9ae 性能强大，但真实业务场景产生的 AI 负载远非单个计算实例所能承载。AI 工作负载远比传统 Web 应用复杂，它有状态、角色多样、且需“同生同死”。

以一个 32B LLM 模型推理为例，模型启动瞬间可能占用 65GB 显存，接下来可能因并发请求膨胀到 200GB。推理服务在短时间内可能从 8 卡扩展到数百卡，再逐步缩回——这对于整个系统的调度、存储及网络通信效率都提出了更严苛的要求。

单实例性能提升虽显著，但 AI 负载的复杂性要求更全面的基础设施支持。要破解这些难题，就需要上述企业级实例和容器、存储服务协同作战。

容器激活“算力流通”，存储激活“数据流通”

容器作为云原生时代弹性计算的核心技术，在 AI 时代，它也逐渐从十年前“让应用跑起来”的封装工具，升级为未来算力的通用接口。

这场变革中，Kubernetes 已经成为承载 AI 负载的事实标准，是当前最主流、最广泛采用的 AI 基础设施平台。根据 CNCF 2024 年度用户调研，已有 52% 的受访终端用户在 Kubernetes 上运行 AI/ML 工作负载。我们确实也看到，主流云厂商、大模型实验室，以及新兴的 AI 初创公司几乎都选择以 Kubernetes 作为 AI 应用的运行底座。

这种情况下，企业面临的问题就不再是“要不要上 Kubernetes”，而是“怎样把 Kubernetes 用得更好”。

在此次飞天发布时刻，阿里云正式对外宣布了 ACK 和 ACS 两项容器服务的最新进展，核心就是向用户提供一种把 Kubernetes 用得更好的方法论。

其中，阿里云容器服务 ACK 在保障稳定性和提升 AI 部署效率两个维度均有新突破。

稳定性方面，ACK 通过高效管理运维异构资源以保障业务稳定性，并实现三项能力突破：

• 异构资源管理： 通过统一的 ACK 控制面，将 GPU、灵骏、远程直接内存访问（RDMA）、智算版并行文件系统（CPFS）等异构智算资源纳入同一技术栈，用户无需再为每类硬件单独适配。

• GPU 故障自愈： 平台先为硬件或软件异常建立标准化判别模型；一旦触发规则，立即隔离故障 GPU，防止错误分配，随后调用 IaaS 层接口尝试修复，修复成功后自动解除隔离并重新调度任务，显著降低人工干预。

• 在线实时 GPU AI Profiling：借助 eBPF 与 library injector，用户在不改代码、不重启服务的情况下即可实时抓取 GPU 运行时数据——涵盖 CUDA kernel（含 NCCL 通信算子）及 PyTorch 高层调用——按时间轴还原现场，在线定位瓶颈，官方数据显示诊断效率提升 50% 以上。

此外，为帮助企业以更低成本、更高效率、更强稳定性将大模型落地到生产环境，并让模型能力真正高效、安全地赋能业务流程，ACK 此次也全新发布了云原生 AI 套件 Serving Stack。

该套件包括 RoleBasedGroup 控制器（简称 RBG）和 Gateway Inference Extension（简称 GIE）两大组件。

RoleBasedGroup 控制器（简称 RBG）是该套件在 Kubernetes 集群中针对 LLM 推理工作负载的抽象层。

RBG 支持主流 LLM 推理引擎，如 vLLM、SGLang、TRT-LLM 等，兼容各类推理性能优化架构，如 Dynamo、Mooncake 等。 RBG 能够将分布式推理工作负载中的不同任务角色（如 Prefill worker、Decode worker、Router 等），灵活地抽象为独立的 Role；并支持采集不同角色的关键监控指标（如 TTFT、TPOT、Token throughput、Request rate 等），联动推理运行时可支持基于 SLO（如平均 TTFT/TPOT）的弹性伸缩。

同时，RBG 还内置对 HPA、cronHPA、KPA、AHPA、KEDA 等 Kubernetes 生态中各类应用弹性伸缩架构的兼容，以适应不同场景需求；并结合 Fluid 的分布式缓存和数据预热技术，能够大幅提升 LLM 推理服务弹性伸缩的响应速度和效率。在 Deepseek R1 推理服务启动速度测试中，Fluid 在 220 秒内将 671B 模型权重数据从远程对象存储读取到 GPU 显存中，达到 10GiB/s 以上的带宽。这将 Deepseek R1 模型加载耗时减少了 90%。

GIE 则是 ACK 基于 Kubernetes Gateway API 的推理扩展组件，支持灰度发布、过载检测、请求排队、熔断限流。在 Qwen、Deepseek 等模型推理服务压测中，长尾场景下的首包延迟提升 73%，缓存利用率提升 90%，前缀感知负载均衡优化带来 40% 的响应速度提升。

总的来看，在云原生 AI 套件 Serving Stack 中，RBG 负责 LLM 推理服务的部署，更新，升级等全生命周期管理，并根据业务指标动态调整实例规模，GIE 负责根据实时请求负载情况和模型处理能力智能路由流量。两者一起打配合，让大模型生产化部署做到低成本、高效率，同时具备强稳定性。

容器计算服务 ACS 此次则新上线了 AMD 通用算力，并在以下五个维度实现技术突破：

• 性能： 在视频编解码、图形渲染、大数据等计算密集型场景，AMD 实例端到端性能最高提升 55%。

• 规格：CPU 与内存最小粒度为 0.5vCPU、1GiB 步长，且 CPU 和内存配比可在 1:1～1:8 之间自由组合，更贴近实际负载，避免资源浪费。

• 弹性：AMD 实例可支持分钟级万个 Pod 弹出，并支持 AHPA 预测式伸缩；用户可按需单独使用 AMD，或采用 AMD 与其他异构芯片混合部署。

• BestEffort 模式：新增可抢占式 AMD 实例，价格为常规实例的 20%；系统在资源紧张时自动驱逐这些实例，能够满足离线批处理、测试等对稳定性要求低、对成本极敏感的业务。

• 成本优化： 推出按日承诺付费计划，用户以“每日预计使用规模”提前锁定折扣，进一步压低长期算力价格。

整体来看，ACS 以“容器算力”形态将通用算力切分得更碎、更便宜，ACK Pro 则在容器编排层让 GPU 像水电一样随取随用、故障自愈，两条线合起来指向同一个结论：

单纯采购算力资源已经无法满足 AI 负载的需求，贴合负载需求灵活地调度算力资源，已经成为 AI 算力发展的主线。

然而，要让 AI 真正落地业务场景，只实现算力的灵活调度还不够，还需解决计算过程中产生数据的去向问题。

AI 训推产生的大量权重、日志、KV-Cache 均需长期留存；多轮对话、个性化推荐等场景又要求毫秒级找回历史状态；一旦存储跟不上算力弹性，就会出现 GPU 空转、成本飙升的尴尬局面。

因此，灵活调度算力的下一步，就是灵活调度存储。目前，Agentic AI 的趋势已经把 AI 任务对灵活调度存储的需求推到极致。

在此次飞天发布会上，阿里云表格存储 Tablestore 还宣布全面升级 AI 场景支持能力：

• 功能方面，Tablestore 升级多元索引能力，新增 JSON 格式，相对嵌套（Nested）数据类型性能更好，成本更低；并支持多列向量，降低数据冗余，加速关联查询；

• 数据模型方面，Tablestore 推出了全新开源的 AI Agent Memory 框架，瞄准对话记忆和知识管理两大场景，预置了会话（session）、消息（message）、知识库（knowledge）三大通用数据模型，让开发者无需关注底层存储细节，更加专注业务创新本身。

• 生态方面，Tablestore 可通过 OpenMemory MCP（模型上下文协议）一键部署 AI 记忆方案，并接入开源 Dify，提供高可用性向量存储方案以及 Spring AI，承接记忆（Memory）和知识（Knowledge）引擎的存储需求。

在上述更新基础上，Tablestore 又通过 DiskANN 等先进向量检索算法，按需计费与自动弹性伸缩能力以及默认支持跨可用区部署三项升级，较传统自建方案降低 30% 的整体存储成本。

小   结

阿里云的这套连招，每一步都在试图让基础设施匹配业务，而不是业务迁就基础设施。

过去，企业必须先“买下”一台规格固定的机器，再去削足适履地改写应用；如今，ACS 把算力切成 0.5 vCPU 的微小单元，ACK Pro 把 GPU 故障自愈、AI Profiling、分布式推理调度做成水电煤一样的基础服务。当算力可以按需膨胀、按秒计费、按故障自愈，业务逻辑第一次不必再为底层资源让步。

更进一步看，当容器层把“计算”抽象到极限，存储层必须同步把“记忆”抽象到极限——Tablestore 以 PB 级弹性、毫秒级检索、开源 Memory Framework，让智能体的“长期记忆”也变成可插拔的公共服务。于是，应用只需描述“我要多少算力、我要记住什么”，而不必关心“我从哪里买机器、我把数据放哪”。

阿里云此次发布会也越发凸显了云计算的本质不只是算力资源，而是一种“服务”属性。未来，算力与存储也将继续“服务化”，价格曲线与性能曲线或许会逐渐解耦，企业只为业务峰值买单。

当资源不再成为瓶颈，真正的竞争将回到业务创新本身——谁的场景抽象得更准，谁的模型迭代得更快，谁就能在下一轮浪潮中胜出。