AI 的大部分投资回报都耗费在基础架构而非模型上

AI 带来的收益很少能在损益表上体现出来，这通常是架构问题，而非模型问题。团队交付了一个可运行的试点项目，却眼睁睁看着收益被延迟、失控的算力成本以及未预料到的安全事件吞噬殆尽。尽管模型表现出色，但其底层基础架构最初并非为了在生产环境中承载此类工作负载而设计。

Akamai 委托开展了两项研究，旨在通过压力测试找出这种脱节发生在哪个环节。2026 年 AI 推理现状对 200 名在生产环境中运行 AI 推理的从业人员进行了调研，其中四分之三是工程师和架构师，并且大多数人还是部署决策者。2026 年 API 安全影响研究对来自六个行业和 10 个国家或地区的 1,840 名安全专业人士进行了调研。

综合这两份报告，可以得出同一个结论：大多数团队都在使用专为模型训练设计、但被勉强用于推理的基础架构进行扩展，而由此产生的短板最终体现为成本、延迟以及安全风险。

当同时具备以下三项要素时，这些短板才得以消除：

1. 一种能够适应实时运行条件的架构

2. 内置于该架构中而无需外部集成的安全性

3. 部署位置足够靠近用户以满足实时响应目标的推理

单独拿出来看，这些要素中的任何一项都不是什么新鲜事物。问题在于将它们视为由不同团队负责的独立项目。

首先，我们从剖析其本质开始。推理是指训练好的模型接收新输入并返回输出结果的实时过程。每次推理调用都会以 API 调用的形式进行，因此模型与 API 并非相互独立的关注点。它们具有相同的请求路径、相同的故障模式，以及相同的攻击面。这一主线贯穿于这两项调研之中。

集中式推理并未走向末路。对于模型训练、批量作业以及对延迟不敏感的工作负载来说，将算力集中在少数几个大区域通常是明智之举——Akamai 正是以这种方式运行大量工作负载的。数据所得出的结论更为具体，也更具实用价值：集中化对于特定且不断增长的一类工作负载已不再适用，而许多团队尚未对此重新设计架构。

《AI 推理现状报告》发现，75% 的企业已将生成式 AI (GenAI) 投入生产环境，但其基础架构未能跟上步伐。现在，越来越多的此类工作负载具有严格的实时延迟要求，这是与远程区域之间的往返传输所无法满足的；60% 的从业者认为靠近用户和数据很“重要”或“至关重要”。

尽管如此，仍有 46% 的从业者依然在单一的集中式区域内运行推理。这正是矛盾所在：并非集中化在所有场景下都失效了，而是越来越多的生产推理需要在更靠近最终用户的位置运行，这是集中化布局所无法满足的。

最先失效的工作负载是可以预测的：实时交易中的欺诈评分、语音智能体、实时个性化推荐，以及任何在返回答案前需串联多次模型调用的智能体工作流。在网络传输中，每次跳转都会叠加前一次的延迟。如果将工作负载集中于单一区域，则随着使用量的攀升，排队延迟将会不断增加——恰恰在工作负载最无法承受的时候，增加了数百毫秒的延迟。

因此，真正的问题不在于将“集中式与分布式”之争奉为某种教条，而在于哪些工作负载需要靠近用户，哪些不需要。做得好的团队会针对每个工作负载深思熟虑地解答这一问题，而不是默认将所有工作负载都部署在单一区域，并默默承受由此带来的延迟代价。

投资回报率低通常表明，团队正在依靠运营措施来弥补缺陷，而不是从架构层面解决问题。关键指标在于单位经济效益：单个推理请求的成本，通常按每个 token 或每次查询来衡量。如果您无法看到该指标，便无法对其进行优化，也无法在它失控时及时察觉并进行干预。

大多数团队都无法看到该指标：77% 的企业缺乏用于追踪推理成本的、一致的单位经济效益指标。这意味着，大多数企业无法判断某个特定工作负载在扩展时的成本会降低还是增加。这种可见性盲区同时也是安全漏洞。token 消耗量的异常激增通常是拒绝钱包 (DoW) 攻击的首要迹象，在这类攻击中，攻击者会刻意通过增加推理量来导致费用攀升。

当低投资回报表现为高延迟和低转化率时，地理位置往往是罪魁祸首。实时推理具有突发性并且对延迟敏感，无法通过公共互联网加远程数据中心提供可靠的支持。

数字是不会骗人的。如果您的端到端时间预算为 250 毫秒，其中计算耗时 100 毫秒，API 握手耗时 50 毫秒，那么留给数据传输的时间只剩下 100 毫秒。进行跨大陆的数据传输时，在模型开始执行任何工作之前，该时间预算便已被消耗殆尽。

将推理部署在分布式入网点上可确保繁重的工作在用户所在区域内完成，从而绕过公共互联网的拥堵，并消除集中化布局所带来的速度限制。该响应之所以感觉像原生响应，是因为从网络的角度来看，它是本地响应。

如果不确保推理过程的安全性，就无法对其实现规模化。如果将安全视为一条平行的工作流，那么必须付出性能上的代价。这两项研究都表明，真正的失效模式并非拓扑结构，而是那些未受保护、未经测试以及看不见的 API。

以下数据令人触目惊心：87% 的企业在过去一年中经历过 API 安全事件，相较 2022 年的 76% 有显著增长。在经历过安全事件的团队中，针对与 AI 相关 API 的攻击是本次研究中最常被提及的 API 相关安全事件类型，有 42% 的受访者报告曾遭受针对与 AI 技术相关 API 的攻击。

目前，平均每起事件每年造成的损失达 70 万美元，而严重程度排名前四分之一的事件，其造成的损失更是超过 180 万美元。与 AI 相关的 API 并非未来的风险，而是眼下的现实威胁。

与此同时，可见性却在不断下降。只有 23% 的企业知道哪些 API 会返回敏感数据，较 2022 年 40% 的比例大幅下降。您无法保护自己看不到的资产，而 AI 正在以人工盘点无法企及的速度，不断扩大资产版图。助手类工具会快速生成大量从未经过安全审查的端点。对于找到未受防护路径的攻击者而言，自然语言接口使得通过提示注入来提取数据变得轻而易举。

关键在于，入口点并不是全部。在攻破单个暴露的 API 后，攻击者会尝试横向移动到具有真正价值的组件中：即管理 AI 数据的特征存储库以及保存模型权重与逻辑的存储库。

微分段是一种旨在隔离各个工作负载的安全最佳实践，它可以遏制攻击的影响范围。大多数企业尚未实施该方案，但那些已实施微分段的企业能够以更快的速度遏制攻击。众所周知，基于网络的传统分段方法不仅复杂、繁琐，而且效果不佳。由 AI 驱动的现代微分段技术可以解决这一问题，但同时也面临着根深蒂固的偏见带来的挑战。如果您将这种分段机制集成到执行推理的同一网络中，则可以避免在保护与性能之间做出妥协。

其实现模式是基于身份的。各企业应：

• 通过工作负载身份而非 IP 地址来定义访问权限，从而确保特定的推理服务只能访问特定的特征存储库，而无法访问其他任何资源

• 执行持续 API 发现，以找出那些仍然连接着生产数据的废弃测试端点

因此，安全将成为架构的固有属性，而不再是开发人员可以绕过且仅在特定时间点进行的审计。

这两项研究揭示的深层问题在于企业层面，而非技术层面。各团队分别负责构建流量和安全机制，而这两种机制之间的断层正是问题频发的环节。

这种断层最终体现为信心的差距：40% 的高管表示其 API 测试已达到较高成熟度，但只有 28% 的 DevSecOps 团队对此表示认同。领导层以为问题已得到解决，因此基础架构始终面临资源不足问题，资金却流向了其他相关工具。领导层认为受保护的资产与实际受保护资产之间的差距正不断扩大。

要消除这一差距，要求负责管理流量的团队与负责流量安全的团队在同一个（或者至少是相融合的）控制平面上协同工作。当检测与遏制机制共享同一平面时，典型提示注入或 DoW 攻击的异常请求模式便可以触发对受影响推理端点的自动隔离，而不会出现“人在回路中”的情况。只有当分布式部署与安全防护不再是相互独立的系统时，才能实现这种同步。

以下两项能力将能够实现规模化扩展的团队与陷入停滞的团队区分开来：

1. 可移植性。成熟的运营团队能够显著降低发生供应商锁定的风险，因为他们可以根据成本和容量的变化，在托管 GPU、托管 API 以及无服务器运行环境之间灵活分配工作负载。

2. 运行时治理。对传入的恶意提示和传出的数据泄露响应的控制是在网络层强制执行的，而不是附加在应用程序上。

将上述功能整合至单一平台，使分布式部署、安全防护与流量调度共享同一个控制平面，这样便消除了安全防护与性能之间的权衡问题。您可以一目了然地了解正在运行的程序、运行位置以及是否正遭受攻击。

这正是 Akamai 一直致力于解决的内容分发与安全领域的难题，而现在他们正着手解决生产环境中的推理挑战。这个将推理部署在靠近用户所在位置的全球网络，同时也负责管理其周围的 API 安全、微分段和分布式拒绝服务 (DDoS) 防护。正是凭借这种广泛的覆盖范围，一个网络才得以同时兼顾两项任务。

其根本原因在于，现有的基础架构尚未将适应性架构、安全防护与分布式部署整合到同一基础之上。性能与防护之间的差距正在扩大，但这种差距既非结构性的，也不会永久存在。当负责处理流量的团队同时在基础架构上把控安全，并且该基础架构专为承载推理而构建（而非为勉强应对推理而经过改造）时，这一差距便不复存在。

如需深入了解，请阅读 2026 年 AI 推理现状和 API 安全影响研究。