中国算力市场，不能只讲“堆卡”的故事

摘要：当以“降本”闻名的马斯克对外公布由 10 万个液冷 H100 GPU 组成的超大集群，并宣布未来几个月内还要再增加 10 万颗 GPU 时，业界对 AI 基础设施的衡量标准，一时间变得有些单一——大家更倾向于对比卡的数量，而对集群性能，尤其是特定业务场景下的性

当以“降本”闻名的马斯克对外公布由 10 万个液冷 H100 GPU 组成的超大集群，并宣布未来几个月内还要再增加 10 万颗 GPU 时，业界对 AI 基础设施的衡量标准，一时间变得有些单一——大家更倾向于对比卡的数量，而对集群性能，尤其是特定业务场景下的性能表现，考量不足。

2025 年甫一开年，DeepSeek 就大幅降低了预训练成本，继而在 3 月份，蚂蚁 Ling 团队给出了基于国产算力的新成本优化方案，2025 国产的 GenAI 的主题显然是极为务实的。这种务实的背景是，国内的 AI 应用市场，正处于爆发中，即将到来的是无数挑战传统 SaaS 的 AI 原生应用，以及被智能编程武装起来的“超级团队”。

这些应用和团队需要的是，更有针对性的算力基础设施，更灵活的算力获取方式，更安全可靠的算力获取保障，针对训推一体和多模态数据的全局优化。

算力规模的扩展当然是必需的，也是当下算力开支的主要方向。但在规模问题之外，更紧迫的问题是对基建整体性能的调优。

这事儿听起来没有“堆卡”震撼，但难度却绝不容小觑——这要求头部云厂商，必须开始着手翻新整个基础设施。

推理加速和降本，还有很多“文章”可做

实际上，这种翻新也是有明确“偏好”的，其中最显眼的部分来自 GTC 2025 ，黄仁勋话里话外的意思是：整个 AI 产业正在经历结构性的转变——从做基础模型预训练，转向推理业务。曾经在大模型预训练这条赛道上，抢下行业接近 90% 利润的英伟达，如今认为，在 2028 年的智算中心预算支出里，推理芯片需求占比将达 70%。

造成这种转变的原因主要有两个：一是可供大模型做预训练的公开数据有限，行业内公开的、深度的数据合作还很少，导致做预训练的规模受限；二是行业已经从“百模大战”的阶段，进入“AI 应用落地”阶段，对推理的需求大幅增加。据 Omdia 在 2024 年年中预测，全球生成式 AI 软件收入在 2024 年增长 124%，复合年增长率将达到 53%。

这其中包含了从 ChatBot 形态的简单推理业务，过渡到覆盖智能驾驶、具身智能、端侧智能等对模型推理表现要求更高的业务场景。

对企业而言，主要是解决四个关键问题：

如何让大模型的冷启动更快些

如何让推理的速度更快些

如何支撑推理业务的流量洪峰

如何进一步降低网络成本和存储成本

必须要声明的是，以上四个问题都不是新问题，尤其是推理降本，据李飞飞团队发布的报告显示，过去两年间，推理成本已经降低 280 倍。但科技行业始终追求的是复制成本最低，边际效应最大化。所以到了 2025 年，AI 应用落地的进程中，以上技术命题仍然是云服务迭代焕新的主流方向。

而从阿里云在 4 月 9 日 AI 基础设施峰会上的众多发布来看，情况也是如此。阿里云搞定这事儿的核心思路之一，是 PAI 。

据官网介绍，PAI 是阿里云专为开发者打造的一站式机器学习平台，主要由可视化建模（Designer）、交互式建模（DSW）、分布式训练（DLC）、模型在线服务（EAS）等核心功能模块组成。简单理解就是，PAI 解决的是 AI 落地问题，AI 开发在基础设施搭建、工具框架部署、运维合规等方面的复杂工作，帮助企业从 0 到 1 开发、训练、部署、推理一个模型服务，与 AWS SageMaker、Google Vertex AI 相似。

而 PAI 则是通过全新的模型权重服务来解决大模型冷启动，以及提升扩容效率、应对流量洪峰的问题；通过分布式推理引擎 Llumnix 以及流量感知的 PD 分离推理服务共同完成推理加速，最后通过提升 KV Cache 的命中率，来进一步降本。

模型权重服务，简单来说就是围绕模型权重进行管理、存储、分发等操作的一系列服务。模型在首次启动或长时间未使用后重新启动时，需要加载模型权重并准备好进行推理，也就是模型的“冷启动”。所谓“全新模型权重服务”，和冷启动效率的提升关系颇大。

根据本次发布，阿里云官方给出的优化成绩是：缩短大参数模型冷启动时间，0 到 100 节点冷启动加速 21X；50 到 100 节点扩容加速 12X；降低模型存储侧网络压力，减少带宽成本。

而分布式推理引擎 Llumnix，看起来是对标 NVIDIA 开源的 Dynamo 推理框架。Llumnix 通过跨模型实例的请求运行时重新调度来解决 LLM 推理服务中的负载均衡、资源碎片化、优先级区分等问题，通过高效可扩展的实时迁移技术来迁移请求及其内存状态。用一句话总结就是， Llumnix 可以直接影响终端感受到的推理速度。

根据大会发布数据，相比 Round-robin 请求调度，Llumnix 可以将 TTFT P99 响应延迟（从发出请求到第一个 Token 返回）降低最高 92%；TPOT P99 （后续每个 Token 的平均返回时间）响应延迟降低最高 15%。

当然，改善 TPOT 数据表现是一个复合型工程，PD 分离的技术实现情况，也必须被纳入计算。

大模型推理可以笼统分为 Prefill（预填充）阶段和 Decode（解码）阶段，前者处理用户输入的 prompt，生成 KV 缓存（Key-Value Cache），属于计算密集型任务，需要高并行度和显存带宽；后者基于 KV 缓存逐 Token 生成输出，属于存储密集型任务，依赖低延迟的显存访问和高效的批处理调度。

传统操作方式是允许两阶段在同一 GPU 集群运行，但资源争抢会导致吞吐下降和长尾延迟增加。例如，prefill 阶段占用大量算力时，decode 阶段的实时生成能力会被挤压。

所谓 PD 分离，就是对 Prefill（预填充）阶段和 Decode（解码）阶段进行隔离，分别进行资源调度。但仅实现预填充与解码阶段的物理资源隔离也不够好，这缺乏动态调整能力，容易导致预填充集群空闲时解码任务无法抢占资源。

所以阿里云本次发布的是 PAI-EAS 多机 PD 分离部署架构，其核心在于通过分层调度与动态资源协同实现更高效的算力利用和延迟控制，给出的答卷是端到端服务吞吐提升 91%。

这里涉及到两个关键组件：LLM Gateway，LLM Scheduler。前者作为全局流量入口，负责请求的协议转换（REST/GRPC）和负载均衡。后者专为多模态大模型设计的协议适配层，支持文 / 图 / 视频输入的混合解析，并通过请求分片技术将长文本拆解为多段并行预填充（Prefill），解决单机显存不足的问题。

预填充任务在多机 GPU 上并行生成 KV Cache，并通过 RDMA 网络同步至解码集群，并在解码阶段通过动态批处理（Dynamic Batching）聚合多个请求，共享 KV Cache。

而所谓流量感知，是指系统能够实时监测和分析网络流量或请求流量的情况，让智能路由更智能一些。

这里出现的 KV Cache，也是个热门概念。实际上，KV Cache 是 Transformer 架构的核心组件，已成为突破大模型推理性能瓶颈、优化服务经济性的关键基础设施。

原本 KV Cache 的显存占用会随上下文长度线性增长，但 Transformer 架构本来就包含自回归生成时的重复计算，因此留有很大的优化空间。

阿里云这次发布对 KV Cache 做了进一步升级，提升了请求调度效率，使千万级活跃用户场景下， KV Cache 命中率提升 10X。

然而，对于云计算而言，脱离计算、网络、存储这“三大件”去谈推理加速属于“空中楼阁”，而阿里云强化 AI 基础设施的核心落脚点是灵骏集群。

对基础设施的要求，也变了

灵骏集群的主要关注点，仍然是“三大件”，但在侧重场景上，却出现了很大的变化，其中最主要的变量，仍然是从预训练转向推理场景后，构建在 IaaS 层之上的业务场景变化很大。

与预训练业务更偏好高算力 GPU 相比，推理业务更偏好高显存带宽 GPU，存储也需分级缓存，结合对象存储（如 OSS）实现冷热分层。同时也需要算力本身有一定自愈能力，避免对业务造成影响。

在网络层面，预训练业务的需求可以总结为：对吞吐量的要求高，尤其是张量并行通信带宽，但对延迟不敏感，可以接受分钟级的延迟。而推理业务对延迟非常敏感，很多场景都是实时交互，比如自动驾驶决策，且需要应对突发性高并发要求。

至于存储，推理业务更看重对数据访问模式的优化，以及内存显存直连优化，对能效比也更为敏感。

阿里云灵骏集群是支持超大规模 AI 训练与推理的智算基础设施，可提供超大规模、超强性能的智能算力，灵骏集群通过 HPN7.0 高性能网络架构可实现单集群 10 万张 GPU 卡互联，万卡规模下性能线性度可以达到 96%。

在服务器层面，阿里云采用磐久 AI 计算服务器，单台服务器支持 8-16 张 GPU 卡，配备 3.2Tb/s RDMA 网络与 400Gb/s 存储访问网卡，满足大规模紧耦合计算需求。GPU 实例通过硬件级优化（如显存带宽提升、计算指令集加速）实现 MFU（Model FLOPs Utilization）提升 20% 以上。

在 4 月 9 日的 AI 基础设施大会上，能看到灵骏集群的各项数据又有更新，主要是围绕 AI 负载进行优化，包括整合计算（GPU 集群、磐久服务器）、网络（HPN）、存储（CPFS）硬件，搭配统一资源池、全局调度等软件模块，以形成高可靠、高性能的云超级计算机。

具体包括：

● EBS：灵骏支持块存储，快速集群扩缩容

● CPFS：单客户端吞吐提升至 40GB/s

● VPC：VPC 带宽能力全面升级，提升至 200Gbps

● HPN 优化：支持 IPV6，全面支持多路径能力，优化专家并行的网络通信性能（性能提升 25%）

● 优化故障自愈系统：通过 PAI AI Master、AI Task、AI Cluster 与灵骏故障自愈系统、运维监控系统联动，提升系统稳定性与算力利用率。

涵盖了网络、存储和系统稳定性问题，可见阿里云围绕算力有效利用率做了较多工作。

在网络能力的优化方面，灵骏采用多路径并行传输与 IPV6 通信域扩展，显著提升了跨 Segment 的任务处理效率。这显然与今年 AI 应用出海的大趋势是相互呼应的。

在存储方面， CPFS 迎来了升级。

在架构层面，CPFS 采用高性能并行架构，升级了全链路 RDMA 技术、容量性能水平扩展、CIPU 硬件加速隔离、全分布式元数据管理、弹性多租 Serverless 化。而且 CPFS 在端侧缓存和分层存储有许多优化成绩，包括：弹性文件客户端 EFC 支持分布式缓存（借助 GPU 内存 / 本地盘加速）、支持 KVCache 存储、与 OSS 数据流动（Tb 级带宽）、分层存储。

同时，阿里云 CPFS 文件存储系统经全链路优化，单客户端吞吐性达到 40GB/s，单计算节点缓存吞吐 15GB/s，配合目录级权限控制，在保障模型训练速度的同时实现企业级数据隔离，为大规模 AI 训练提供了高效的存储支持。

阿里云的 CPFS、KV Cache 已经形成了架构上的协同效应——CPFS 以 TB 级吞吐量将模型参数加载至 KV Cache，KV Cache 提供实时 K/V 向量，减少 GPU 显存占用，最后将推理结果异步落盘至 CPFS，支持冷热分层。

除此之外，OSS 对象存储服务的优化也同样值得关注。

阿里云 OSSFS 2.0 在单线程读取 100GB 文件场景中实现吞吐性能提升 7.65 倍，Qwen-2.5-72B 超大规模模型的数据拉取速度提升 7.73 倍，意味着存储层与 AI 算力的协同优化进入了一个新阶段。

同时，资源池 QoS 新增的 BucketGroup 流控能力，实现多 Bucket 业务分组池化管理，将存储资源管理粒度从单点扩展至业务单元。

这也契合企业混合云架构下存储资源集约化运营的趋势，尤其适用于需要跨地域协同的全球化 AI 训练场景。

从地区覆盖来看，新加坡成为继北京、上海等核心节点后第五个具备 100Gbps 缺省读吞吐能力的地域。随着东南亚成为 AI 芯片供应链关键节点，该地域的存储带宽升级可直接支撑 10 万卡级 GPU 集群的并发数据访问需求。结合 OSS 加速器产品吞吐密度提升 50%、最大性能达 100GBps 的能力，阿里云正在构建覆盖训练、推理、边缘计算的全球数据高速公路，为多模态大模型、自动驾驶等场景提供跨地域数据协同的基础支撑。

阿里云 OSS 的升级某种程度上揭示了云存储的进化方向：从被动承接数据存储转向主动参与计算优化。OSSFS 2.0 的突破验证了"存储即服务"向"存储即算力"的范式转换，而 BucketGroup 流控则是进一步加强精细化运营的思想体现。

整体来看，灵骏智算集群和人工智能平台 PAI，已经成为阿里云支撑 AI 推理需求和 AI 应用落地的枢纽，阿里云甚至还在结合自己对客户业务的理解，继续将这种优势外扩，使之也蔓延到了算力高可用、网络安全等其他领域。

AI 应用大热，算力高可用成了必选项

要服务好 AI 应用落地这一宏观趋势，在性能层面满足业务要求，通常是 ToB 业务的准入门槛，能在多大程度上做好高可用以及安全合规服务，对最终业务落地也有较大影响。

由于跟客户走得足够近，云计算企业的嗅觉都很敏锐，因此对算力高可用的关注也比较及时。

在万亿参数模型训练成为行业标配的今天，对服务可用性的要求已从 99.9% 的常规标准，进化为毫秒级响应 + 零故障容忍”的双重阈值。从云服务层面，避免单节点故障造成的推理中断，已经是个必选项，不然成本会高到客户无法忍受。

而这种算力高可用的强需求，主要体现在算力高可用、实时数据同步、动态扩展性等多个方面。

具体来说，MoE 模型的分布式架构需要云计算平台具备跨地域冗余存储和智能流量调度能力，确保单点故障时专家模块的无缝切换，同时需要支持弹性资源分配以应对突发负载，并通过细粒度快照技术实现模型状态与训练数据的实时备份；此外，云计算平台还需要高效的故障检测与自动化恢复机制，并结合增量备份策略，最小化灾难场景下的服务中断时间和数据丢失风险，从而保障大规模 AI 服务连续性。

另一项关乎业务连续性的重要课题是网络安全，在 GenAI 时代，发动一场网络攻击的成本足够低，但危害足够大，共同导致网络安全事件的频发。

这, 就涉及到一个公有云必须解决的关键任务：云产品必须最大限度地集成安全能力，也是阿里云的一项长期工作。