从算力到智能体,面向 Agentic AI 的基础设施演进

作者:阿里云大数据AI技术日期:2026/8/4

摘要

当大模型的能力边界不断扩展,真正决定 AI 价值上限的已不再只是算法本身,而是支撑其落地的基础设施体系。本文基于 2026 Agentic AI 超级智能体系统架构峰会演讲,系统阐述了阿里云 PAI 平台如何围绕算力、推理与场景三条主线构建面向 Agentic AI 的全栈基础设施——从数十万卡集群的统一调度与训推一体,到企业级 Token 服务 TokenWorks 的 KV Cache 感知调度与 SLO 保障,再到 Physical AI、自动驾驶、具身智能等场景化方案的落地,以及 Agentic 交互与 AI 原生数据管线的融合,展现了一条从"有算力"到"用好算力"再到"智能驱动"的清晰演进路径。

演讲人: 周文超(阿里云智能研究员,人工智能平台PAI负责人,百炼平台AI搜索负责人)

从算力底座到场景落地,AGI不仅是模型更是千行百业的高效应用

当前 AI Infra 架构可分为以下几个核心层次。

最底层是算力。阿里云人工智能平台 PAI 管理着多种异构计算资源,包括不同规格的 CPU 和 GPU,以及高带宽网络、存储等。该平台承担着资源池化与弹性调度的职责。算力的规模和稳定供给,决定了 AI 智能的上限。

算力层之上是 AI 的两大核心环节——训练和推理。训练环节重点关注 GPU 资源的使用效率(MFU)。将 MFU 从百分之十几、二十几提升至百分之五十甚至更高,直接决定了模型训练的速度和资源消耗。推理环节同样如此。近年来,学术界和工业界的一个核心技术突破是如何实现更高效的 LLM Serving,使大模型在算力平台上完成高效推理。过去一年,该领域涌现了大量新技术:PD 分离、KV Cache 的多层级利用(从本机内存到跨机内存再到 SSD),以及 MTP 技术提升 Acceptance Rate 等。计算效率的提升,是模型生产和应用的基础。

再上一层是企业 Token 服务的保障体系。有了训练和推理能力,便可产出高质量的模型并生成高质量 Token。下一个目标是实现高效率的 Token 产出,并提供稳定的效率保障。确定性的 SLO 至关重要,尤其在 Agentic AI 时代,Token 的稳定性和效率直接决定上层服务的可靠性。SLO 已从单一的 P99 延迟演变为更复杂的指标体系,不仅涵盖整体延迟,还包括 TTFT 和 TPOT 等具体约束条件。在此基础上,需要实现 Token 成本的最小化,并确保 TTFT、TPOT 及成本在较长周期内实现 99.9999% 甚至 99.99999% 的 SLO 达成率。这是企业级 Token 服务乃至 Agentic AI 落地的前提。

最上层是场景化的 AI 工程。Token 产出之后,仍需将其应用于具体场景,以创造真正的业务价值。这需要从通用平台走向行业纵深,覆盖智驾、具身智能、AI Coding、多模态探索等不同应用场景,构建行业纵深的场景化 AI 工程。

阿里云人工智能平台 PAI

阿里云人工智能平台 PAI 的架构分为 IaaS、PaaS、MaaS 和解决方案 四层。

最底层是 IaaS,依托阿里云在云时代的深厚积淀。计算方面,支持 CPU、GPU 等多种计算类型;存储方面,提供 CPFS 等面向 AI 工作负载的高带宽存储;网络方面,具备跨 Region 和 Region 内的两层高速网络,保障 51.2Tbps 的高速互联。此外,结合 MaxCompute、EMR、Flink 等大数据平台,提供 AI+Data 的高效解决方案。

IaaS 之上是 PaaS 层,也是 PAI 投入最多精力构建的部分,在 AI Infra 中具有最大的设计空间和发展潜力。PAI 拥有两个核心引擎——训练引擎 DLC 和推理引擎 EAS,并在引擎之上提供多种大模型开发和应用工具:IDE(DSW,Notebook 式开发工具,支持交互式建模)、Agentic 工具(以 Agentic 方式与平台交互,同时更好地支持 Agent 工作负载)、以及多模态 AI 和 Physical AI 等场景化工具。最终目标是让 AI 算力、智能和数据形成飞轮效应。

PaaS 之上是 MaaS 层。底层的基础设施和 AI 算力平台支撑了 Model as a Service,包括 ModelScope、阿里云百炼,以及 OpenAI、Anthropic、Hugging Face 等第三方 MaaS 平台,通过不同协议使用底层的 AI Infra。

最上面是解决方案层,覆盖 Agent、自动驾驶、具身智能、科研智算等不同行业和场景。

算力的应用效率是AI迭代和应用的关键

PAI统一调度引擎:训推一体的高效调度

PAI 的核心能力之一是统一资源调度

资源呈现显著的异构性和多元性,体现在多个维度。

第一是算力的异构与多样性。CPU、GPU 以及日趋丰富的 GPU 类型——包括英伟达 GPU、阿里云 PPU 和国产生态 GPU——种类繁多。能否在统一的资源池中实现混合调度,在调度时将不同卡型统一管理,是关键能力所在。

第二是网络的多样性。卡与卡之间可能处于同一机器、同一机架、跨机架甚至跨机房等不同拓扑位置,网络带宽和延迟保障差异显著,直接影响大规模训练和推理的整体效率。因此调度时需考虑网络拓扑亲和性——例如使用 Tensor Parallel 进行训练或推理时,应将相关任务优先分配到高速互联的 GPU 上。

PAI 的统一调度引擎综合考虑了算力多样性、网络多样性以及多种调度策略(FIFO、Round Robin、是否允许抢占等)。配额分配后的使用模式——固定配额还是允许闲时复用和抢占——进一步扩大了调度空间。

PAI 平台将所有这些调度能力集成于统一的调度器中,结合阿里巴巴训练 Qwen、Wan 等大模型积累的实践经验,在管理的数十万卡算力集群中实现了 90% 以上的有效算力利用率。

资源、调度和工作空间三层体系:实现算力精细化管理

另一个关键维度是易用性。企业中与 AI 算力相关的角色包括:资源购买方(决定采购规模)、资源分配方(管理不同团队的资源配比)和资源使用方(模型开发团队、数据开发团队等)。

不同角色需要不同的资源管理视图。

资源购买阶段,PAI 提供 AI 资源组的概念,可统一管理 GPU、CPU、内存、存储等资源,实现可观测、可管可控。

资源分配阶段,通过定义 Quota(资源配额)来保障各团队的资源互不干扰,每个配额内可自由使用。

资源使用阶段,在 AI 工作空间内进行资源绑定,例如将部分 GPU 用于训练、另一部分用于推理,在使用层面实现资源管控。

购买、分配、使用三层体系协同,实现了算力的精细化管理,这也是 PAI 平台在业界广受认可的核心能力。

PAI-DLC 超大规模分布式训练服务

训练服务是另一个与算力密切相关的核心领域。

在调度引擎之上,训练引擎针对多种训练任务和阶段进行了深度优化,涵盖预训练、后训练、MoE 模型训练和多模态模型训练等。

以 MoE 训练为例,PAI 引入了 Chunk Flow 技术。由于训练的 Context Window 长度可变,定长训练会导致大量 GPU 空跑和资源浪费。PAI 将变长训练组织为等长的 Chunk,显著提升了训练效率,在 MoE 模型训练中可实现约三倍的资源使用效率提升。

此外,PAI 集成十余种主流训练框架,支持一键启动复杂的训练和 Rollout 操作。

综合来看,在训练方面:10 万卡算力集群管理的卡数过去一年增长约三倍;MoE 训练 MFU 最高超过 80%;训练任务量过去一年增长超百倍,每月有超过 4000 万个训练任务在平台上运行

Agentic时代的推理服务

进入 Agent 时代,推理服务领域发生了根本性变化。Agentic Inference 具有以下四个显著特征。

单次对话如同一次长跑——可涵盖数十轮交互,上下文可达数十万 Token。Prefill 和 Decode 分离已成为标配,无论是 Coding 场景还是 Agentic 场景,上下文日趋冗长,两阶段分离势在必行。同一查询还需多个实例协作,甚至在探索 Attention 与 Forward 的进一步分离(AFD 分离)。

KV Cache 已成为核心资产。过去一年,KV Cache 从一项辅助优化手段演变为核心议题。其命中率从 60%—70% 持续攀升,在部分 Coding 场景下已超过 95%。每一个百分点的提升都意味着推理时 GPU 资源的节省——尤其从 95% 到 96%,看似仅提升一个百分点,但未命中率从 5% 降至 4%,实际资源节省达 20%。在阿里内部和 PAI 平台上,KV Cache 的优化是重点投入方向,确保在多轮对话和 Coding Agent 环境中充分发挥其价值。

网关同样至关重要。传统网关已基本失效——Round Robin 和一致性哈希等方式无法感知 KV Cache,必然导致命中率下降并影响 TTFT 和 TPOT。现代网关需要实现 KV Cache-Aware Routing。网关还承担着更多职责:在 MaaS 或推理场景中需要处理多种协议(如 Anthropic 协议、Responses 协议),同时承担翻译、调度和计费等功能。

SLO 的定义也发生了根本性变化。当前工业实践中的 SLO 本质上是一个约束优化问题——约束条件涉及 TTFT 和 TPOT,优化目标是单 Token 成本或百万 Token 成本。推理的服务单位也从资源快速演进到了 Token:在 LLM 时代,推理经历了从同步推理到异步推理再到流式推理的演进,以 Token 作为服务粒度。

Agent 时代由于上下文极长,推理过程有时如同在 Token 中摸索前行——可能消耗大量 Token 而编码进展有限。因此需要实现高效、低成本、高质量的 Token 利用。

PAI TokenWorks 企业级推理服务

PAI 推出了 TokenWorks——企业级专属推理服务,支持数据不出域的私有化部署,提供具有 SLO 保障的推理服务。TokenWorks 针对前述每个问题都进行了专项优化。

流量高效调度方面,实现了 KV Cache-Aware 的网关流量调度,确保 KV Cache 命中率足够高。通过从 HBM 到内存再到 SSD 的多层缓存架构,命中率可稳定在 90% 以上,部分场景可达 95%。

引擎深度优化方面,针对不同 Attention 机制(从 DeepSeek V4 到 K3 等),实施算子融合,采用 D-Spark、D-Flash 等技术提升推理引擎效率。

此外还包括模型预热缓存、用户 Token 管理等功能,实现成本可核算、可治理。这些技术能力最终以 Token 形式交付——对客户而言,即为具有 SLO 保障的专属 Token 服务,数据可管可控、不出域、安全。

场景化是AI业务价值体现的必经之路

物理 AI 为例,可以清晰地看到 AI Infra 的演进方向。

Physical AI 是当前备受关注的领域,其发展呈现双轮驱动格局:一侧通过 Physical AI 模拟物理世界,捕捉物理规律,生成符合物理规律的世界仿真;另一侧通过 LLM/VLM 提炼和抽象人类知识。两者相互促进——Physical AI 中基于仿真的反馈可用于 LLM/VLM 的强化学习训练,而 LLM/VLM 在数据标注、清洗和扩增等方面也反向推动了世界模型的训练。

PAI 平台构建了 Physical AI 的全栈能力。底层是算力层,统一管理不同 GPU 和资源。中间层集成了 Physical AI 领域主流的仿真、训练和测试框架。上层是场景化的平台能力:Notebook Gallery 组件沉淀了数百个业界最佳实践模板,支持一键启动;DSW 提供交互式开发环境,支持自定义环境的探索验证与调试,以及低延迟可视化的机器人仿真环境。模型的上线和部署则依托训练平台 DLC 和推理平台 EAS。

完整的解决方案还涵盖数据合成、真机与仿真数据的联合管线、模型训练验证与上线。PAI 与 Isaac、Cosmos 等合作伙伴持续协作,不断提升 Physical AI 全栈能力。

Physical AI 的研发全流程包括:数据生产(真机采集数据,如车辆和人形机器人,数据不足时通过仿真进行扩增和增强)、数据加工(标注、筛选、画质增强等)、模型训练(预训练、后训练,含微调和 RLHF)以及模型评测。PAI 平台在该研发全流程中与客户和合作伙伴共同打造,使之更贴合 Physical AI 的研发实践。

Agentic PAI:AI驱动的PAI操作入口

AI 正加速进入千行百业,PAI 平台本身也积极拥抱 Agentic 交互方式。

Agentic PAI 将平台能力以自然语言交互的方式呈现,从资源管理到训练、部署、运维乃至故障排查,均可以 Agentic 方式进行,支持 CLI 和 Chat 等交互形式。 PAI 平台已沉淀了大量训练、推理和 RL 任务,训练本身即是一项复杂的系统工程,Agentic 方式能够帮助客户更高效地完成模型训练、部署和运维。

这也便于客户将 PAI 能力快速集成到企业内部 AI 平台。大型企业通常拥有自有的 AI 部署管理和观测平台,通过 Agentic 接口,PAI 的能力可快速融入企业自有的 AI 平台体系。

不同角色从中获得的收益各有侧重:算法工程师和模型训练者关注开发效率和训练稳定性,可将数百个 Worker 的日志交由 AI 分析,专注于模型本身,无需在海量日志中人工排查 Loss 异常;部署和推理工程师关注服务上架、运维和性能,部署、扩缩容、灰度发布和故障排查可一站式完成;平台资源管理者和成本负责人可快速实现成本洞察,查看 GPU 利用率、排名和环比趋势等。

Agentic 全模态数据处理管线

模型训练离不开数据。对阿里云而言,AI 与 Data 紧密相连。在 Agentic 时代,全模态数据处理管线同样备受关注。

数据管线涵盖数据治理、资源管理、开发体验和多模态数据纳管等方面。阿里云大数据平台正从传统数仓向 AI Native 数据平台转型,可将复杂的 AI 推理场景简化为一行 SQL,使熟悉 SQL 的开发者将 AI 能力直接嵌入已有的开发平台和流程中。通过异构资源的灵活调度,多种模型覆盖全场景。这是大数据平台与人工智能平台联合打造的成果,将大数据产品从传统数仓平台到 AI Native 数据平台的转型

结语

从算力到智能体,作为行业从业者可以看到一条清晰的趋势——从单纯关注算力,到算力如何更好地支撑智能体,AI Infra 层面正在经历深刻的演进与变革。阿里云大数据AI 平台将持续助力千行百业,共享 AI 红利。


从算力到智能体,面向 Agentic AI 的基础设施演进》 是转载文章,点击查看原文


相关推荐


AI名词完整入门教程【看懂各种黑话】
一条泥憨鱼2026/7/27

🌈个人主页:一条泥憨鱼(欢迎各位大佬莅临) 🎬精选专栏:数据结构与算法,Java ,AI与Agent 前言: Harness、Loop、MCP、Agent、Skill……每次看到这些词都想关掉页面? 我懂。先别管它们 看一个你大概率会遇到的场景: ▎ 你是一个课程主理人,手头攒了几十份直播逐字稿、一堆学员问答、案例截图、产品说明。你想搞一个「AI 内容生产小助手」——能读你的资料,帮你出公众号文章、小红书文案、课程大纲。拿不准的信息它会先翻知识库,需要配图的时候能自己生


C++11核心特性全解:从C++98到现代C++的全面升级(万字总结)
邪修king2026/7/19

观众老爷们大家好 我是邪修KING 本文属于系列C++ 进阶篇 ,欢迎来到C++进阶篇博客 C++重点语法运用! 一、C++11简介:为什么需要C++11? C++11 是 C++ 的第⼆个主要版本,并且是从 C++98 起的最重要更新。它引⼊了⼤量更改,标准化了既 有实践,并改进了对 C++ 程序员可⽤的抽象。在它最终由 ISO 在 2011 年 8 ⽉ 12 ⽇采纳前,⼈们曾使 ⽤名称“C++0x”,因为它曾被期待在 2010 年之前发布。C++03 与 C++11 期


我开源了 BeeWeave,给 AI Agent 搭一个越用越懂你的知识创作台
超级东哥CyberFD2026/7/11

GitHub 项目地址 : github.com/ptonlix/bee… 事情是这样的。 过去一段时间,我一直在用 Claude Code、Codex、OpenClaw 这些 Agent 做研究、写文章、整理知识。 它们很强,真的很强。你把资料扔进去,它能总结。你给一个主题,它能起草。你让它分析一个仓库,它也能很快摸清结构。 但我反复遇到一个很烦的问题。 每开一个新会话,很多事情都要重新讲一遍。 我以前研究过什么,我对某个问题已经形成了什么判断,上一篇文章留下了哪些线索,哪些资料可信,哪些坑已


FPGA与STM32的双核协奏曲:硬核拆解中速采集卡的高速数据流与双缓冲机制
zlinear数据采集卡2026/7/3

zlinear开源电子 前言 大家好,我是ZLinear的硬件工程师。 在之前的博文中,我们聊了常速采集卡DABL-7606的过采样算法与通信协议。不少读者看后私信问:“张工,如果我的采样率要求更高,比如要到200K甚至500K SPS,同时还要输出多路DDS波形和带加减速的PWM脉冲,单靠一颗STM32还能扛得住吗?” 答案是:很难,且极其吃力。 当采样率攀升到百K级别,且涉及多通道同步、复杂波形输出时,单核MCU的中断响应延迟和DMA总线带宽就会成为明显的瓶颈。为了彻底打破这个性能


开发了一个进阶版Apple健康
神奇的程序员2026/6/25

前言 使用iPhone + Apple Watch组合有段时间了,当初买的时候,想着用它来记录我的跑步数据,但是坚持了没多久,我就懒惰了,手表最大的作用就成了睡眠监测工具了,由于作息一直比较规律(晚11~早7),就没怎么关注过这些。 最近半年时间,时不时的熬夜写开源项目,我开始关注自己的健康状况了,打开系统自带的的健康app把玩了一番,发现它的数据特别全,但是有几个不好用的地方: 首页的内容比较分散,指标都是以列表的形式进行展示的 指标层级较深,需要切来切去,很多指标我更希望将他们展示到一个大


Mac 软件推荐
yuanyxh2026/6/16

OrbStack 轻量 Linux 系统、Docker 容器、K8S 容器,用它的原因是工作/开发环境在系统里拉太多屎了,开个 Linux 虚拟机隔离工作环境,本地代码编辑器 + ssh 远程连接开发,这种模式适合 web 前端/后端。 安装: brew install orbstack 使用: VSCode 安装 RemoteSSH 插件,连接 host@orb 除了隔离环境,还可以导入导出镜像,方便打包整体环境;或在后台运行服务。 缺点:Linux 虚拟机有一定内存占用 Tart macO


每日一个开源项目(第125篇):taste-skill - 给 AI 装上审美,让前端不再千篇一律
冬奇Lab2026/6/9

引言 "AI 生成的前端,为什么看起来都一个样?" 这是"每日一个开源项目"系列的第125篇文章。今天的主角是 taste-skill——一套给 AI Agent 配上「审美」的前端设计技能包。 让 AI 写前端代码已经很普遍了,但结果往往大同小异:居中排版、蓝色主色调、卡片式布局、圆角阴影,整齐但无聊。问题不在于 AI 不会写代码,而在于它没有任何关于「这个设计应该有什么气质」的约束。 taste-skill 的答案很直接:用一套经过研究积累的设计规则文件,告诉 AI 什么是品位,什么是


09-不要只让 AI 进入 Plan 模式,要先给 AI 一套工程制度
颜进强2026/6/1

上篇:不要只让 AI 进入 Plan 模式,要先给 AI 一套工程制度 这两篇文章的核心目的只有一个:通过业务决策和技术决策,让我们向 AI 提需求时,AI 在 Plan/决策阶段就能更精准。 AI 写代码并不难,难的是让 AI 在一开始做方案时,就知道项目的业务边界、技术边界和执行流程。 这篇是上篇,主要讲为什么要把业务决策和技术决策沉淀下来,以及它们如何帮助 AI 更准确地做方案。 下篇会继续讲:技术决策、rules 和 skills 到底怎么分工,避免文档越写越多,AI 反而越容易混乱。


我为我的龙虾斩分身:OpenClaw 多智能体实操
飞哥数智谈2026/5/12

飞哥数智谈,全栈工程师,在济南这个二线城市做 AI 社群,AI·Spring 社群发起人,同时,担任 TRAE Friends 社区济南 Fellow,致力于 AI 提效与 AI 编程普及与落地。 很久没有写关于 OpenClaw 的文章了,但并不意味着我不再喜欢小龙虾,相反,我依然觉得 OpenClaw 是个具有深远意义的产品。 或者,准确地说,龙虾类产品意义重大,但此处的龙虾并不特指 OpenClaw,可以是 Hermes,可以是 QClaw,也可以是 XClaw。 它们实现了 AI 智能


OpenClaw 多模型配置与切换详解
七夜zippoe2026/5/2

目录 热门文章推荐摘要一、引言:为什么需要多模型支持1.1 AI 模型生态的多元化现状1.2 多模型支持的核心价值 二、支持的模型提供商2.1 OpenAI2.2 Anthropic(Claude)2.3 Qwen(通义千问)2.4 Ollama(本地模型) 三、模型配置详解3.1 基本配置结构3.2 模型选择配置3.3 自定义提供商配置3.4 模型参数配置 四、模型切换机制4.1 Default 默认模型4.2 Reasoning 推理模型4.3 Per-Session 会

首页编辑器站点地图

本站内容在 CC BY-SA 4.0 协议下发布

Copyright © 2026 聚合阅读