1. 从AI Infra到Agentic Infra一场算力底层的范式跃迁最近和几个做AI应用的朋友聊天大家普遍有个感觉模型本身的能力迭代确实快但真正要把一个想法落地从原型变成稳定、可扩展的服务最头疼的往往不是模型调参而是背后那套支撑体系——也就是我们常说的AI基础设施。这就像你有了一个顶级的赛车引擎但如果没有与之匹配的底盘、悬挂和传动系统它可能连赛道都上不去更别说跑出好成绩了。“AI Infra”这个词这几年听得耳朵都快起茧子了。它本质上解决的是“如何高效、稳定地训练和部署AI模型”的问题。从早期的GPU集群管理、分布式训练框架到后来的模型服务化、推理优化整个技术栈已经相当成熟。但行业的需求永远在变。当大模型从“炫技”走向“实用”当AI应用从简单的问答、生图进化到能够自主规划、执行复杂任务的智能体时原有的基础设施开始显得力不从心。这就引出了我们今天要聊的核心Agentic Infra或者说面向智能体时代的基础设施重构。为什么说这是“重构”而不是“升级”因为需求变了。传统的AI Infra核心对象是“模型”。它的目标是让这个模型跑得快、吃得少、服务稳。但Agentic Infra的核心对象是“智能体”。一个智能体是什么它可能是一个由多个模型、工具、记忆模块和决策逻辑组成的复杂系统。它需要与环境持续交互处理流式输入进行长链条的规划和反思甚至多个智能体之间还要协作。这对底层的算力调度、资源管理、状态保持、工具调用都提出了全新的、更苛刻的要求。华为云这次提出的“极致重构AI算力底座”在我看来正是瞄准了这个范式跃迁的关口。它不再是简单地说“我的GPU更多、更快”而是试图回答一个更根本的问题当AI从“计算密集型”任务转向“交互密集型”和“认知密集型”任务时我们的算力底座应该如何被重新定义和构建这背后涉及从芯片、服务器、网络到软件栈的全栈思考。接下来我就结合自己的观察和实践拆解一下这场重构背后的核心逻辑、关键技术点以及它对我们这些一线开发者意味着什么。2. 需求之变为什么传统AI Infra不够用了要理解为什么需要Agentic Infra我们必须先看清智能体应用与传统AI模型服务到底有哪些本质不同。这不仅仅是“更复杂”那么简单而是架构哲学上的差异。2.1 从静态推理到动态工作流传统的模型服务无论是CV、NLP还是推荐模型其工作模式大多是“静态”的。用户发起一个请求比如一张图片、一段文本服务加载模型执行一次前向推理返回结果然后请求结束。整个过程的上下文是短暂的状态是无关的。基础设施要保证的是高并发下的低延迟和高吞吐资源分配通常是请求级别的、短暂的。而智能体应用更像是一个持续运行的“进程”或“服务”。以一个客服智能体为例它需要与用户进行多轮对话记住对话历史根据上下文决定调用知识库搜索、订单查询API或者生成一个待办事项。它的生命周期可能长达数分钟甚至更久期间涉及多次模型调用、工具调用和状态更新。这对基础设施提出了几个新要求有状态服务智能体的“记忆”对话历史、执行状态、中间结果需要被持久化或高效地在内存中维护。传统的无状态服务架构需要引入额外的状态管理组件如向量数据库、键值存储并处理好状态同步和故障恢复。长时资源占用一个活跃的智能体会长时间占用计算资源尤其是用于维持上下文的大模型实例这与传统短平快的推理请求模式冲突需要新的资源调度策略比如支持“常驻实例”与“弹性实例”的混合部署。复杂工作流编排智能体的执行路径不是线性的。它可能根据条件分支、循环、并行执行多个子任务。这就需要底层有强大的工作流引擎来编排这些步骤管理依赖处理错误和重试。注意很多团队初期会用简单的Python脚本串联起模型调用和工具但当智能体逻辑复杂后会立刻陷入“面条代码”和难以调试的困境。一个专门的工作流编排层是智能体应用从玩具走向生产的关键。2.2 从单一模型到异构计算图传统AI应用通常围绕一个或少数几个核心模型构建。而一个功能完整的智能体其内部可能是一个“异构计算图”。这个图里可能包含大型语言模型负责核心的规划、推理和生成。小型或专用模型用于特定任务如情感分析、代码补全、语音识别。工具/函数调用外部API、查询数据库、执行代码。记忆模块短期工作记忆、长期知识存储向量数据库。决策与反思模块评估行动结果调整策略。这些组件对算力的需求截然不同。LLM需要高带宽内存和强大的张量计算能力一些小模型可能对延迟极其敏感工具调用则主要是I/O密集型。传统的AI Infra往往为单一类型负载优化例如一个GPU集群专门做批量训练另一个CPU集群做在线推理难以高效调度这种混合的、动态的计算图。2.3 从追求吞吐量到保障“任务成功率”与“响应流畅性”对于传统推理服务核心指标是QPS每秒查询数和P99延迟。目标是在给定资源下服务尽可能多的请求。但对于智能体尤其是与用户直接交互的智能体用户体验的指标变得多维且复杂任务完成率智能体能否独立、正确地完成一个复杂任务如订机票、写报告步骤成功率每一次模型调用、工具调用的成功率如何响应时间可预测性虽然单轮响应时间重要但用户更在意整个任务完成的“端到端”时间是否在预期内且中间不要有长时间的“卡顿”。流式交互体验能否支持token级的流式输出让用户感觉智能体在“实时思考”这就要求底层基础设施不仅要算得快还要算得“稳”和“准”。需要更精细的监控、更智能的故障转移比如一个工具调用失败能否自动重试或切换备用方案、以及对整个任务链路的可观测性。3. 重构核心华为云算力底座可能发力的三个层面基于上述需求分析我们可以推测一次“极致重构”绝不会是单点的优化而必须是体系化的革新。我认为华为云可能会从硬件、资源调度、软件栈三个层面进行深度融合的设计。3.1 硬件层为Agent负载定制的计算架构通用GPU如NVIDIA H系列固然强大但其设计初衷是面向大规模并行训练和批量推理。智能体负载有其独特特征频繁的上下文切换、对内存带宽和容量的极致要求用于长上下文、以及CPU与GPU、网络之间的紧密协同。昇腾AI处理器与NPU的协同华为的昇腾Ascend系列AI处理器是其核心筹码。针对智能体场景硬件设计可能会更强调大内存与高带宽支持单卡或卡间聚合更大的内存容量以容纳超长上下文如128K甚至1M tokens的模型和KV Cache这是智能体保持连贯性的基础。低延迟互联通过华为的CloudEngine网络交换芯片和RDMA技术实现服务器内GPU/NPU间、以及跨服务器节点间的超低延迟通信。这对于将大模型参数、中间状态在多个计算单元间快速同步至关重要是实现高效并行推理和复杂工作流的基础。异构计算单元集成在同一芯片或板卡上更紧密地集成通用CPU核心、AI计算核心NPU以及可能的数据处理单元减少数据搬运开销适应智能体中模型计算、逻辑判断、I/O处理交织的混合负载。存储与内存的革新智能体的“记忆”需要高速存取。除了依赖分布式内存池可能会看到与持久内存PMem或超高速SSD如NVMe over Fabric的更深度集成实现状态数据的近乎内存级访问速度与持久化能力的平衡。3.2 调度与编排层从管理“容器”到调度“智能体”Kubernetes已经成为云上AI工作负载的事实标准但它原生是为微服务设计的其调度的最小单元是Pod容器组。对于智能体来说这还不够“贴身”。面向DAG的智能调度器华为云可能会在K8s之上构建一个更高级的调度器它的调度单元不是一个Pod而是一个描述智能体工作流的有向无环图。这个调度器能理解图中节点模型推理、工具调用之间的依赖关系、资源需求特征GPU内存型、CPU计算型、高IO型并进行全局优化调度。例如它将有依赖关系的两个节点尽量调度到同一台机器或同一个机架以减少网络延迟或者为高优先级的用户交互节点预留资源。弹性与混部策略分级弹性对于承载用户会话的“常驻智能体”实例采用预测性扩缩容保持基线资源以保障体验对于后台批量处理任务采用激进的弹性伸缩充分利用闲时资源。作业混部将在线智能体推理任务延迟敏感与离线模型微调任务吞吐敏感在同一个集群内混合部署通过精细化的资源隔离如基于昇腾芯片的算力隔离、内存带宽隔离和优先级调度提升整体集群利用率。这需要极其深厚的硬件虚拟化和内核调度能力。状态与生命周期管理提供一套标准化的SDK或Sidecar组件帮助智能体应用方便地保存、加载和迁移其运行状态。当某个节点故障或需要资源回收时调度器能协同状态管理组件将智能体及其完整状态迁移到健康节点实现“无感故障恢复”。3.3 软件栈与框架层降低Agent开发与部署门槛这是最贴近我们开发者的一层。华为云需要提供一套完整的工具链和框架让开发者能聚焦智能体业务逻辑而非底层设施。统一的智能体框架支持目前市场上有LangChain、LlamaIndex、Semantic Kernel等多种智能体开发框架。华为云的平台需要提供与这些主流框架的深度集成和优化。例如提供官方的、针对昇腾硬件优化的LangChain工具集成或者推出自己的、更贴合其硬件特性的高阶框架内置对工作流、状态管理、工具生态的原生支持。模型服务化增强传统的模型服务如Triton Inference Server主要针对单次推理。面向智能体模型服务需要增强高效的流式输出与中断处理支持Token级的流式返回并能响应用户的中断指令。对话Session管理服务端高效管理多轮对话的上下文缓存减轻客户端负担。多模型协同服务能够将一个智能体涉及的多模型大模型、小模型打包成一个复合服务进行部署和调度简化运维。工具与API生态的云原生集成智能体的能力边界取决于其能调用的工具。华为云可以将其丰富的云服务数据库、中间件、大数据、音视频处理等封装成易于智能体调用的标准化“工具函数”并提供一个安全、高性能的内网调用通道。同时支持开发者快速将自己的业务API注册为工具并自动生成对应的描述OpenAPI Schema供大模型理解和调用。全链路可观测性与评估平台这是智能体应用运维的“眼睛”。平台需要提供从用户输入、智能体内部决策链Chain-of-Thought、工具调用、到最终输出的全链路追踪。不仅能监控延迟、错误率等传统指标还能定义和评估业务层面的指标如“任务完成度”、“工具调用准确率”。基于这些数据可以构建持续的评估体系用于智能体的迭代优化。4. 实战推演基于新底座部署一个电商客服智能体假设我们现在要基于华为云这套“重构后的算力底座”部署一个具备复杂能力的电商客服智能体。这个智能体不仅能回答商品咨询还能处理退货、查询物流、甚至根据用户聊天记录推荐商品。我们来推演一下关键步骤和可能享受到的基础设施红利。4.1 智能体工作流定义与资源预估首先我们需要定义这个智能体的核心工作流。它可能包含以下模块意图识别与会话管理一个较小的NLP模型实时分析用户query的意图咨询、售后、闲聊。核心对话引擎一个千亿参数级别的大语言模型负责生成回复、进行复杂推理和规划。工具集search_product调用商品搜索引擎API。check_order_status调用订单数据库。initiate_return调用售后流程系统。get_user_profile从用户中心获取历史行为。记忆存储向量数据库存储本次会话的上下文和重要的用户信息片段。资源预估大模型实例需要常驻占用高内存GPU/NPU资源。假设使用华为云提供的昇腾910集群中的一个实例配备64GB以上高带宽内存。小模型实例意图识别模型较小可部署在CPU或低算力NPU上支持更高并发。工具调用层需要与多个后端VPC内的服务通信对网络延迟和稳定性要求高。状态存储需要低延迟的缓存服务如Redis和向量数据库。4.2 利用新特性进行部署与调优使用智能体专用工作流描述语言我们不再写一堆分散的部署脚本而是使用一个声明式的YAML或DSL来描述整个智能体应用。这个描述文件会定义各个组件大模型服务、小模型服务、工具代理、记忆库以及它们之间的数据流DAG。我们将其提交给华为云的“智能体调度平台”。# 伪代码示例 agent_app: name: ecommerce_customer_service components: - name: intent_classifier type: model framework: pytorch resource: cpu:2, memory:4Gi model_path: ... - name: llm_core type: model framework: mindspore # 假设使用华为MindSpore优化版 resource: npu:1 (type: ascend-910, memory: 64GB) model_path: ... - name: tool_broker type: service image: tool-broker:latest resources: ... connections: [order_db, product_search, after_sales] - name: session_memory type: vector_db backend: cloud_vector_db # 华为云托管的向量数据库服务 spec: ... workflow: - step: classify_intent component: intent_classifier - step: generate_response component: llm_core depends_on: [classify_intent] inputs: [user_query, intent, session_context] - step: execute_tool_if_needed component: tool_broker depends_on: [generate_response] condition: response.requires_tool享受智能调度与弹性平台接收到我们的描述后其智能调度器会分析DAG和资源需求。它可能会将intent_classifier和tool_broker这种需要与外部系统频繁通信的组件调度到离业务VPC网络更近的节点。而为llm_core这个大模型实例则分配一个专有的、具备高速互联能力的NPU节点。当客服高峰期来临平台可以自动为intent_classifier组件扩容多个实例同时保证每个llm_core实例的会话状态被妥善管理实现水平扩展。内网工具调用的性能与安全我们定义的tool_broker组件在部署时自动获得了访问我们指定的内部数据库和系统的安全凭证与网络通道通过华为云的VPC对等连接或私有服务集成。工具调用全部发生在云内网延迟极低且安全。平台还可能提供工具调用的熔断、降级和重试策略配置我们无需自己实现。全链路监控与调试在智能体运行后我们可以在控制台看到一个可视化的执行链路图。每一次用户会话我们都能清晰地看到意图识别结果 - 大模型生成的思考过程 - 调用了哪个工具、输入输出是什么 - 最终回复。当有用户投诉“客服答非所问”时我们可以快速定位到是意图识别错了还是工具返回了错误数据亦或是大模型的理解有偏差。4.3 成本与性能的平衡策略这套强大的底座必然不便宜但我们可以利用其特性进行优化大模型实例共享对于llm_core我们可以配置为“多租户共享实例”。即一个加载好的大模型实例同时处理多个不同用户的会话。调度器负责将不同会话的请求交错发送给该实例并管理好各自的上下文缓存。这能极大提升昂贵NPU资源的利用率。基于负载的动态规格切换在夜间低峰期平台可以自动将部分智能体实例从高性能NPU规格迁移到成本更低的CPU推理规格如果模型支持或更小规格的NPU上次日高峰前再切换回来。这一切由平台基于策略自动完成对服务无感。利用分级存储智能体的长期记忆如用户画像向量可以存放在性能稍低但成本更优的分布式存储上而本次会话的活跃上下文则放在超高速缓存中。5. 挑战与展望Agentic Infra走向成熟的必经之路尽管前景诱人但构建成熟的Agentic Infra仍面临诸多挑战这也是华为云和所有入局者需要攻坚的方向。5.1 标准化与互操作性的挑战目前智能体领域框架众多各有各的抽象和接口。一个在LangChain上开发的智能体能否无缝迁移到另一个基于华为自有框架的平台上这就需要行业在智能体描述、工具接口、状态表示等方面逐步形成事实标准或开放协议。华为云作为大厂其态度很关键是全力推广自己的封闭生态还是积极拥抱和贡献开源社区推动接口标准化这会影响开发者的选型。5.2 复杂度的管理与开发者体验功能越强大系统越复杂。如何让普通开发者而不仅仅是基础设施专家也能轻松使用这些高级功能提供简洁明了的抽象、丰富的模板、可视化的编排工具、以及详尽的调试支持是降低门槛的关键。否则这套系统可能只会被少数头部公司使用。5.3 安全、合规与可控性智能体能够自主调用工具和API这带来了巨大的安全风险。一个被恶意提示词操控的智能体可能会调用删除数据库的API。因此基础设施必须提供强大的安全沙箱、严格的工具权限管控、完整的操作审计日志以及对生成内容的过滤审查能力。同时智能体的决策过程需要可解释尤其在金融、医疗等敏感领域满足合规要求。5.4 评估体系的建立如何量化评价一个智能体基础设施的好坏传统的QPS、延迟指标已不适用。需要建立一套新的评估体系可能包括复杂任务的成功率、平均完成步骤数、工具调用的准确率与延迟、状态管理的可靠性、以及单位成本所能支持的同时在线智能体数量等。这套评估体系本身也是技术实力的体现。从我个人的角度看华为云这次提出的“极致重构”是一次从底层硬件到顶层应用的全栈对齐目标直指下一代AI应用的核心形态。它不仅仅是技术的堆砌更是对AI生产力范式变化的深刻回应。对于开发者而言这意味着我们未来构建复杂AI应用时有望获得一个更强大、更贴心、也更“智能”的云上家园。当然最终的效果如何还要看其产品落地的细节、开放程度以及对开发者生态的培育。但毫无疑问这场从AI Infra到Agentic Infra的演进已经拉开了序幕而我们正身处其中。