要点总结
- 无论应用程序是主动运行模型、连接外部 AI 服务、向管道提供数据,还是提供核心基础设施,几乎每个应用程序都是 AI 系统的一部分。
- 用户需求现在需要复杂的、多步骤的处理流程,这涉及到专门的计算资源(如 GPU 和 CPU)、多层存储(如向量数据库和对象存储)以及低延迟网络,以确保响应时间在 500 毫秒以内。
- 随着推理任务在所有人工智能计算任务中占比达到约三分之二,实时模型执行(而非一次性模型训练)正逐渐成为分布式系统性能的核心驱动力。
- 由于人工智能系统跨越多个地域和监管边界,数据引力迫使模型和基础设施必须迁移到数据合法且实际存储的位置,而不是反过来让数据迁移到模型和基础设施所在的位置。
- 现代人工智能应用依赖于持续的数据传输,这使得传统的单一云定价模式变得过时。 在设计评审的初期忽视数据传输费用,可能会导致后期出现巨额账单。
如您所在的企业也在考虑采购云服务或进行云迁移,
点击链接了解 AkamaiLinode 解决方案,现在申请试用可得高达 5000 美元专属额度。
几年前,我们谈论人工智能应用时,似乎它们属于独立的软件类别:传统应用在这里,人工智能应用在那里。 在大多数应用领域,这条界限正在逐渐消失。
4个应用操作类别
尽管并非每个应用程序都使用大型语言模型(LLM),但大多数应用程序现在都属于以下四种操作类别之一:
- 包含人工智能
- 连接人工智能
- 将数据馈送至人工智能
- 支持向人工智能提供数据的内容。
包含人工智能
例如,模型或推理调用可能在应用程序的代码路径内运行,例如嵌入了聊天机器人的辅助工具,或者具备设备端物体检测功能的照片应用。
连接人工智能
例如,即使通过中间集成,应用程序调用外部 AI 服务,或客户关系管理(CRM)软件通过第三方摘要 API 路由工单也算在内,即使团队中没有人将 CRM 视为"AI 产品"。
将数据馈送至人工智能
例如,该应用程序提供数据,供其他地方的模型进行训练、检索或微调。或者,一个运行了15年的企业资源规划(ERP)系统,只要有人将其数据库连接到检索增强生成(RAG)管道,它就会成为这个数据集的一部分,而无需对ERP系统本身进行任何修改。
支持向人工智能提供数据的内容。
例如,该应用程序属于基础设施范畴,包括身份认证、存储和网络等。 即使应用程序本身不处理任何提示,它也可能依赖于其他 AI 系统在运行时所需的可观测性或编排功能。
这些关系合在一起,就构成了我所认为的AI生态系统:包括应用、基础设施、数据和服务,这些要素共同实现了人工智能的运作,无论其中任何一个是否被单独视为"AI应用"。
当然,你在读完这篇文章后可能会认为自己的项目是例外情况。 虽然总有例外情况,但这种情况正变得越来越少见。 根据麦肯锡最新发布的全球人工智能调查报告,88% 的企业现在至少在一种业务职能中常态化使用人工智能,而这一比例在一年前仅为 78%。
传统系统如何被整合到现代人工智能工作流程中?
并非所有应用程序都需要每时每刻都调用大型语言模型(LLM)。 许多组织仍然依赖已有数十年的应用。 制造系统、ERP 平台、医疗软件、政府应用和金融系统仍然在企业运营中发挥着关键作用。 有些团队维护的代码甚至比云计算技术还早出现。 但即使是这些应用,现在也正被纳入人工智能工作流程中,无论人们是否对此有计划。
也许客户支持助手可以从旧数据库中检索信息。 也许某个内部搜索助手正在索引15年来没人碰过的文件。 或许运营数据正悄然为某个预测性维护模型提供支持。 应用本身并没有多大变化,但周围的一切都变了。
这意味着您的应用程序运行在一个人工智能生态系统中,无论您是否刻意构建了它。
分布式 AI 流水线如何推动现代应用架构的发展?
应用架构曾经遵循一种非常熟悉的模式:用户与应用程序交互,应用程序查询数据库,数据库返回结果。 你甚至可以在一张餐巾纸上画出这些内容...... 或者让AI为你完成这项工作(图1)。

图 1:传统应用架构
而如今的这个版本可没法在餐巾纸上画出来了。 现在,单个用户请求调用多个模型、从向量数据库中检索嵌入数据、访问对象存储、调用 API、与代理框架交互以及在 GPU 基础设施上执行推理后再返回响应,已成为一种常见现象。 然后,观测平台可以对该响应进行分析,记录以确保合规性,并触发另一个自动化工作流程(如图 2 所示)。

图 2:当前应用架构
如今,构建应用程序需要的不仅仅是选择一个模型。计算、存储 和网络都已成为架构设计上的考量因素。
计算
并非该流程中的每个步骤都需要相同的计算能力。 代理的推理过程由 GPU 完成,但它的大部分实际操作(如调用工具、读取文件、查询数据库和调用 API)则由 CPU 执行。 如果你认为每个步骤都需要 GPU,那么你就会过度配置那些不需要的部分。 如果你认为每个步骤都能容忍延迟,那么你最终会做出一个无法交付的产品。
存储
AI 工作流程越来越多地涉及向量数据库、对象存储、操作数据库和外部 API。 数据存储的位置会影响延迟性、可移植性,并最终影响输出架构和成本。 这些决策不仅涉及部署细节,还涉及架构设计。
网络
网络连接可能会带来规模瓶颈问题。 在多代理管道中,50个连续调用的工作流程并不少见,这可能会在到达用户之前产生数秒的累积传输延迟。 根据我们的《2026年人工智能推理现状》报告,这对82%的需要在500毫秒内获得端到端响应的组织来说是一个致命问题,而越来越多的组织(64%)已经将目标设定在250毫秒以内。
您无需构建人工智能即可成为人工智能的骨干
应用程序是分布式系统的参与者,而分布式系统则越来越以人工智能为中心。 即使是那些告诉你他们"不做人工智能产品"的公司也是如此。 例如:
- 软件公司可以提供一个供客户部署人工智能工作负载的 Kubernetes 集群。
- 存储平台可能包含其他人的训练数据。
- 身份提供商可以确保模型访问的安全性。
- 内容分发网络可以将推理过程更贴近用户。
- 可观测性平台可以帮助工程师理解日益复杂的AI系统。
这些都不是人工智能应用本身,但它们都是人工智能应用的重要组成部分。
如今,GPU 基础设施在分布式系统性能中发挥着更核心的作用。德勤预计,到2026年,推理将占所有人工智能计算的约三分之二,而2023年这一比例仅为三分之一。 "执行推理"步骤不再是一次性操作。 这正逐渐成为现代应用架构的一个常见主题。
数据成为架构基础
一旦你开始以这种方式审视应用程序,你就会发现一种普遍存在的模式:一切都围绕着数据流动------无论是提示、检索、嵌入、模型响应还是 API 调用。
所有这些都不是什么新鲜事。 早在"LLM"这个词流行之前,分布式系统就已经是数据密集型的了。 十年前,内容分发网络、大数据管道和移动优先架构都迫使人们不得不认真思考数据引力的问题。 不同之处在于速度:人工智能正在以比大多数建筑团队预想的更快的速度加剧同样的问题。
现代人工智能应用不仅需要大量计算(虽然这确实是必要的),还对数据量有很高要求。 应用软件的功能越强大,它在服务、区域、基础设施和用户之间交换的信息量就越大。 这改变了云基础设施的设计方式。
基础设施必须向数据靠拢 分析师:
虽然分布式架构并非新鲜事物,但人工智能却消除了最后一个稳定的锚点,这一点是前所未有的。 CDN 仍然需要一台源服务器。 多区域数据库仍然需要一个主区域。 AI 管道没有对应的概念:模型、所需数据和提出问题的用户可能位于三个不同的位置,三者都无法声称"属于"某个位置。
模型在单一位置运行。 向量数据库则存储在其他地方。 推理过程需要在专门的 GPU 基础设施上进行,而这种基础设施正日益需要部署在允许存储数据的任何地方。 无论身处何地,用户都希望获得快速的响应。
数据引力
这就是所谓的"数据引力"。数字现实公司的数据引力指数对此进行了简明描述:"数据具有引力------随着数据集的增长,它会吸引应用程序和服务,从而形成更多数据生成的良性循环。" 也就是说,数据具有质量,随着其规模和重要性的增长,移动或复制变得更加困难,因此它会将应用程序和基础设施吸引到自己的轨道上。
其中有些重力是物理作用的结果。 这在某种程度上是刻意设计的:云服务提供商在数据导入时不收取任何费用,但在数据导出时则收取高额费用,这正是导致工作负载始终固定在最初落地位置的原因。
人工智能正在加速上述两种趋势的发展。 数据引力曾经是一个存储问题。 现在这是一个架构问题,因为模型必须部署在数据可以合法且实际存储的位置,而不是反过来让数据适应模型。
数据流动量的增加并不会自然而然地成为一个问题。 当基础设施经济学假设数据应该存储在单一位置时,这就成了一个问题。 而这正是大多数公有云定价模型仍然在鼓励的做法。
旧定价模式遭遇新架构挑战
云定价与当今应用的开发方式并不完全匹配。 当大多数工作负载都在同一地点运行时,对数据流出网络的行为进行收费是一个合理的模式。 但人工智能的应用却不是这样。 它们是根据设计进行分发的,这意味着数据始终处于流动状态。
每次交互都是一系列分布式请求,这些请求在不同服务之间传递,而这些服务通常位于不同的位置。 因此,基础设施成本越来越多地反映了应用程序传输数据的频率,而不仅仅是它们所消耗的计算资源。
行业分析师估计,云数据传输费用每年总计在700亿至800亿美元之间,随着各组织部署更多基于人工智能的应用,这一数字还将继续增长。 与此同时,出口定价已成为云服务提供商之间迁移工作负载的最大障碍之一。
定价一直影响着架构设计,这就是FinOps的核心理念。 改变的只是在设计流程的早期就必须进行定价讨论。 以前,一个团队可以先设计出理想的人工智能流程,然后再去计算其成本。 如今,出口费用在设计评审阶段就已开始计算,甚至在建筑图纸最终确定之前就已经出现。
你无法选择退出生态系统。
如果每个应用程序都包含人工智能、与人工智能相连、为人工智能提供数据,或者支持向人工智能提供数据,那么实际问题就不是"我的应用程序是否使用了人工智能?" 根据我们的定义,它可能已经存在了,无论是直接存在还是间接存在。 更重要的问题是,你的基础设施在建设时是否假设了数据会持续流动,或者这种假设是否是在事后才被添加的。
而这个问题的答案其实能预测接下来会发生什么。 为动态数据构建的平台无需重新设计架构,即可集成新模型、新区域或新合规要求。 那些基于数据静止不动的假设所设计的平台,会产生意想不到的运营成本,而这些成本通常只有在收到云服务账单时才会显现出来。 数据引力与数据传输成本已不再是边缘问题,而是标准架构设计中必须考虑的因素。
你无法选择不参与生态系统。 你只能决定是否要为它而付出努力。
需要更多帮助吗?
需要帮助来了解您的AI生态系统吗? 与 Akamai 团队会面,获取人工智能咨询服务。
如您所在的企业也在考虑采购云服务或进行云迁移,
点击链接了解 AkamaiLinode 解决方案,现在申请试用可得高达 5000 美元专属额度。