Presentation: The Infrastructure Challenge Behind Production AI

生产AI背后的基础设施挑战 - InfoQ

InfoQ 首页 演讲 生产AI背后的基础设施挑战

AI、机器学习与数据工程

面向智能体时代的工程实践：如何设计、构建、测试和运营AI驱动的系统（7月16日网络研讨会）

生产AI背后的基础设施挑战

点赞

新下拉阅读列表

• 阅读列表

查看演讲

• 垂直

• 水平

• 全屏

速度：

• 1x

• 1.25x

• 1.5x

• 2x

01:03:14

概述

演讲者们解释了在大规模可靠运行AI系统的真实情况。虽然模型构建问题已得到解决，但如何在持续高压下维护生产数据库仍是一个挑战。他们讨论了新兴的架构决策如何区分能够优雅扩展的团队与面临灾难性故障的团队，以及工程领导者今天必须重新思考的内容。

人物介绍

Simerus Mahesh 是 Forge 的联合创始人兼工程师。Alex Infanzon 是 Cockroach Labs 的高级系统工程师。Meryem Arik 是 Doubleword 的联合创始人兼首席技术官。Luca Bianchi 是 MESA 的首席技术官。Renato Losio 是 InfoQ 的高级编辑、云专家和AWS数据英雄。

关于会议

InfoQ Live 是专为现代软件从业者设计的虚拟活动。参与由世界级实践者主持的研讨会。在可选的 InfoQ 圆桌会议上聆听软件领导者分享经验。

INFOQ 会议

• 2026年7月9日，东部时间中午12点 从日志噪声到事件智能：AI辅助可观测性的成熟度模型 演讲者：Nicolas Jung - Datadog日志产品管理经理

• 2026年7月16日，东部时间下午1点 面向智能体时代的工程实践：如何设计、构建、测试和运营AI驱动的系统 演讲者：Juveria Kanodia - Harness工程高级总监

• 2026年8月6日，东部时间下午1点 构建高风险事件响应的AI代理评估 演讲者：Brianne Bujnowski - Datadog AI高级产品市场经理，Benjamin Barton - Datadog高级软件工程师

演讲实录

Renato Losio：我们将讨论生产AI背后的基础设施挑战。关于今天的话题，简单说几句。众所周知，AI已经从我们几年前可能进行的实验，转变为如今持续运行整个业务操作的系统。随着采用率的增长，我们面临的一大挑战不再是仅仅构建模型，而是如何在大规模上可靠地运行它们。在过去的几个月里，我们看到像GitHub这样的大型组织——这是我们许多人每天依赖的平台——讨论他们在扩展能力时遇到的挑战，以及在AI带来的增加工作负载下所承受的压力。如果GitHub规模的公司都在重新思考其基础设施，我们其他人应该从中学习什么？

今天，AI可能不仅在增加负载，更在根本改变我们在生产环境中经历的负载形态。

我的名字是Renato Losio，我是InfoQ的高级编辑。今天我将与四位来自不同公司、国家、行业和背景的专家进行讨论，他们将分享各自的见解。他们都是该领域的专家，将回答您的问题并就所有开放话题提供反馈。在开始讨论之前，我想给每位专家一个机会进行简短的自我介绍。

Luca Bianchi：我是Luca Bianchi，MESA的首席技术官。我专注于为受严格监管的行业开发软件。我们在该领域拥有产品，这种工作负载的变化是我们正在经历的，因为昨天我们的工作负载主要集中在数据库上，而现在则主要集中在代币上。工作负载的形态和数量都发生了巨大变化。

Alex Infanzon：我是Alex Infanzon，Cockroach Labs的解决方案架构师，与工程团队合作解决数据基础设施挑战。我每天与原生AI公司、金融科技公司和平台团队交流，帮助他们理解智能代理应用为何在原型阶段有效但在生产环境中失败。最近最有趣的讨论不再聚焦于模型本身，而是聚焦于支撑模型的底层基础设施。

Meryem Arik：我是Meryem，Doubleword的联合创始人之一。我们是一家推理服务提供商，早在ChatGPT出现之前就开始从事推理和模型服务工作。当时人们并未意识到其重要性。最近我们一直在深入探讨代币经济学，以及推理服务在生产环境中面临的代币成本和可扩展性问题。

Simerus Mahesh：我叫Simerus，我是名为Forge的公司的创始团队成员。这是一家位于旧金山的初创公司，获得了Greylock、Palantir、BoxGroup等机构的支持。此前我在Meta、Google、PlayStation等公司工作，主要负责数据中心、云基础设施以及智能代理系统相关的基础设施建设。现在我主要专注于AI安全领域，整体致力于生产环境AI代理的基础设施建设。

生产AI中的意外基础设施瓶颈

Renato Losio：我想从一个非常个人的好奇心开始。对于在该领域非常专业的各位来说，你们在生产AI中见过最令人惊讶的基础设施瓶颈是什么？因为我有自己的经验，但经验有限。你们有没有什么建议，或者有什么是你们没想到会发生的？

Meryem Arik：有没有什么事情是你们没想到会发生的？我认为发生的一切都在我们的预测范围内。四年前我们公司成立时有两个主要预测：一是开源模型会因为成本、性能、隐私等原因取得成功；二是代币成本将成为一个非常严重的问题，人们在AI和代币上的支出增长速度会非常快。这两点已经被证明是正确的。让我们感到惊讶的是，这些预测的准确性以及实现速度之快。

杰文斯悖论是我们在行业中经常讨论并深知的一个现象。谈论和了解它是一回事，但真正经历它时，情况可能截然不同。例如，我们可能预计代币成本每年会增长10倍，但实际情况对大多数组织而言更像是增长了100倍。变化的规模远超我们的预期。我认为我们在方向上是正确的，但真正让我们感到意外的是变化的速度，这使得为生产环境构建系统变得异常困难。假设我去年构建一个生产级应用，那么我构建的规模可能比今年实际需要的规模低一个数量级。这带来了大量挑战和复杂性。

Renato Losio：你有没有看到类似的情况？有没有其他反馈？

Alex Infanzon：是的，确实如此。代币成本正在上升，这是一个巨大的挑战，正在打破各规模公司的预算。这些成本确实难以管理。我还看到其他一些导致成本激增的因素。人们过去认为GPU限制是主要原因，但我们现在看到的不仅是GPU成本，还有数据中心消耗的能量。如今，如果你想拥有一个数据中心，必须提前数年规划，因为需要考虑有足够能源供应的地点，以支持这些AI应用的运行。这是基础设施层面的问题。在更上一层，我们看到的是传统数据层维护成本变得越来越高。

传统数据库并不适合应对AI的高吞吐量和高约束需求。分布式SQL的使用正是解决这一问题的方案之一。我们越来越频繁地看到数据库被用于存储所有这些信息，并使AI应用实现运营。你可以存储代理的使用数据，然后生成关于代币行为的报告，分析它们消耗的内存，进行可追溯性处理等。如今，基础设施成本正以指数级速度增长。

资源限制

Renato Losio：Alex还提到了电力问题。总体而言，你最可能首先耗尽的资源是什么？是GPU、数据库容量、网络还是工程时间？

Luca Bianchi：实际上，首先耗尽的通常是外部系统的可用性。如果你使用的是内部GPU，无论是云服务还是本地部署，这都不重要。如果你正在部署GPU，可能需要考虑电力供应和硬件短缺的问题。但对我们大多数人而言，很可能是直接依赖外部供应商，比如公共云或其他替代方案。在转向AI的过程中，我遇到的最大挑战之一是外部系统的可用性可能在数小时内发生剧烈变化。让我举个例子，我过去经常遇到数据库的定期或反复出现的问题。

你部署数据库时，清楚数据库可以根据给定的延迟进行扩展或缩减，或者可能被限流，但这些指标是明确的，你可以处理并缓解这些问题。另一方面，当你使用AI端点时，比如发送一条消息并期望在30秒内收到回复，这个回复可能会失败，可能延迟三到四倍于预期时间，或者可能收到被截断的回复。这取决于具体情况。当我们将时间从中午调整到下午3点时，我曾遇到过一些非常棘手的问题。唯一的变化是新的区域刚刚开始运行。美国地区开始运行，他们开始使用相同的端点和受限资源，随后我们被限流，这种变化只是在当天晚些时候发生。在使用外部AI资源时，这已成为一种新的挑战。

Renato Losio：在个人层面，您对基础设施瓶颈有什么体验？您认为最具挑战的部分是什么？或者您之前遇到过哪些问题？

Simerus Mahesh：我认为可以呼应Alex关于能耗和电力的讨论，我认为在处理基础设施和管理数据中心时，这是一个非常关键的因素。我曾在一个数据中心优化团队工作，直接优化了电力消耗。我从未发现这本身是瓶颈，尤其是从DevEx或生产相关的原因来看。我认为主要的瓶颈是计算能力。根据我的经验，大多数拥有自己数据中心的公司，其资源短缺主要来自计算能力，因为运行工作负载需要大量资源。在进行此类操作时，尤其是在垂直扩展或水平扩展的规模上，需要很多东西。随着AI和代理的出现，有时即使响应完成，某些任务仍会继续运行，因为它们不遵循常规的线程模型，而是更像进程模型。例如，如果代理启动了一个子代理，即使父代理因某些原因死亡，子代理仍可能继续运行。这与操作系统有一些相似之处。回到主题，我看到的主要瓶颈是计算能力。这些公司正在投入大量精力优化和配置自己的Kubernetes环境，以管理这些工作负载。这是一个不断增长的系统挑战。虽然随着时间推移有所改善，但随着AI工作负载变得越来越不可预测，我看到这种情况导致的不确定性和故障也在增加。

为不可预测的工作负载规划容量

Renato Losio：准备容量很困难，但我想知道，像Luca提到的，当工作负载可能快速变化且几乎无法预测API行为时，您如何规划容量？您可能会遇到一种情况，与过去相比，这不是一个峰值，而是在一夜之间达到10%或某个比例。您如何真正为这种情况做规划？您又如何尽量减少副作用？

Meryem Arik：我认为这非常困难，除非这是你的工作，否则最好不要尝试。我在开源模型推理领域工作了一段时间，过去的一个关键用例是希望通过开源模型推理实现自主部署。实际上，推理任务的复杂性已经超出了大多数公司自主部署的能力范围，因为这意味着你需要完成完整的容量规划和构建整个推理堆栈，这远超任何企业愿意承担的工作量。我认为这应该由专业的推理公司来完成。正如之前有人提到的，当你使用多租户端点时，会不可避免地遇到“噪音邻居”效应。

你会发现当美国用户早上活跃时，端点响应速度会明显变慢。目前有很多基础设施提供商，尤其是专门从事推理服务的提供商，在容量规划方面做得非常出色，他们在这方面的能力很可能比你更强。正如之前提到的，全球的算力资源始终无法满足需求。即使是最优秀的容量规划团队和最顶尖的推理服务提供商，也难以完全满足算力需求。在某些时候，“噪音邻居”效应仍然不可避免。我认为我们在这方面已经做得相对不错。我们主要处理大规模任务和长期运行的智能体任务，因此不会像其他人那样频繁遭遇“噪音邻居”问题，但这仍然非常具有挑战性。

我认为，除非这是你的全职工作，否则自行进行容量规划和GPU资源规划的人会发现这非常困难。这是我想要提醒大家的。

每个开发人员的AI成本衡量

Renato Losio：公司是如何决定每个开发人员的AI成本的？公司应该为这个预留多少平均预算？你对如何根据投入成本衡量结果有什么见解吗？

Alex Infanzon：这取决于具体情况。这取决于你采购的基础设施、使用的模型以及AI应用的类型。成本的计算非常复杂。以至于Uber最近在5月公开表示，他们在年度预算的前四个月就用完了全年预算。我估计每个用户的成本在200到500美元之间。这种高消耗是由他们为鼓励用户使用AI而设置的激励措施引发的。他们通过游戏化机制刺激用户使用AI，导致使用频率比原本高出X倍。实际上，他们设计了排行榜系统，使用AI越多，用户在排行榜上的位置就越靠前。

Renato Losio：你基本上是在说这些激励措施是错误的，导致了成本的激增。

Alex Infanzon：你必须让工程师意识到成本问题，同时要记住，当你使用AI应用代理时，它们非常渴望帮助用户回答问题。它们会想出各种方法。如果某些功能无法正常工作，它们会不断循环尝试，反复尝试，尝试不同的路径。它们富有创造力。但正是这种创造力会导致更多的令牌使用和资源消耗。试图控制成本可能会变得一团糟。现在的问题不是成本本身有多高，而是如何帮助你的组织、IT部门对成本负责并加以控制？正如提问者所说，这确实是当前存在的一个现实问题。你可能会面临资源耗尽的情况。不过，Meryem的团队和产品在应对这类情况时可以提供很大帮助。

Meryem Arik：我认为团队在令牌成本上的支出差异非常大。只要这些支出带来了生产力，我认为花大量钱在令牌上并没有问题。例如，我认识一些在NVIDIA等公司工作的朋友，他们团队中某位成员每月在令牌上的支出高达1.5万美元，但他们并不在意，因为实际上他们需要为这个团队招聘人员。这提升了团队的工作效率。我们正在做的事情远超以往的想象。这些令牌的使用是非常高效的，因此每月花费1.5万美元是完全合理的。我也知道其他公司，他们每人每月只花200美元，却还在抱怨。我记得Uber的限额或上限是1500美元左右。

我认为你在令牌上的支出应该根据你从中获得的价值来决定。如果你认为每位员工每月能从5万美元的支出中获得价值，那么你就应该花这笔钱。你需要确保从中获得相应的价值。这就像价值捕获，对某些人来说这确实是个难题。同时，正如Alex所说，还有一些人存在“令牌耗尽”现象，即人们让代理不断循环执行任务，最终为了解决简单问题而采取非常愚蠢的方式。如果这些支出是有用的，我完全不介意花大钱在令牌上。对我们来说，我们在令牌上投入了大量资金，但我认为整体而言我们部署得非常高效，因此我并不在意。

Alex Infanzon：这也是一个衡量投资回报率（ROI）的问题。正如你所说，如果你没有获得投资回报，那你就只是在浪费金钱。

Simerus Mahesh：我们正在构建一个治理平台，其核心功能是能够监管代理的行为，包括它们的支出等。基本上，要回答部分参与者的提问，你需要为所有部署的代理（甚至组织内部运行的代理）添加某种可观测性（observability）类型的包装层。你可以通过特定方式收集这些数据。例如，对于所有Claude Code会话和Codex会话，这些遥测数据和日志实际上会被直接存储在你的文件系统中。如果你想实现原生解决方案，可以直接访问这些数据。回到Alex刚才提到的内容，我认为如今治理是一个非常重要的问题。首先，我们不希望让工程师为所欲为，因为如果他们粘贴了大量生产代码，或者不小心泄露了API密钥，会带来严重风险。

我们需要某种方式来精确控制哪些数据被输入到这些模型中。这实际上是我和我的团队目前正在解决的一个非常重要的层次。这是一个非常大的问题。显然，要开发一个开箱即用的解决方案需要耗费大量时间，这也是我们目前重点关注的原因。而更定制化的解决方案可能会显得有些笨拙，我认为你可能可以在内部实现一个简单的解决方案，但要实现更稳健的方案，可能还是需要依赖开箱即用的解决方案。

在生产环境中跟踪公司数据

Renato Losio：实际上，这让我想到下一个问题，这个问题与如何在生产环境中跟踪公司数据有关，以及在不使用大量数据进行实验时面临哪些挑战？你们在所在领域是否有处理敏感数据的经验？

Luca Bianchi：这是一个相当困难的问题，因为我们非常清楚，或者说应该非常清楚这些挑战。要找到一个能适应所有不同使用场景的解决方案非常困难。让我再详细解释一下。我们知道需要保留某些数据并确保其他数据的安全性。所需保留或安全性的程度会根据客户类型、目标行业以及所管理数据的性质而变化。这意味着有时你无法找到一个适用于所有情况的解决方案。让我举个例子。我曾遇到过许多客户，他们选择直接使用自托管模型，这样他们就可以在自己的网络边界内管理所有数据、所有数据处理流程。

问题在于，由于两个因素，这些成本以及系统的规模和可扩展性在事前很难规划。第一个因素是底层硬件资源的价格不断变化，另一个因素是模型的准确性和模型本身也在不断变化。如果你需要提前为未来六个月做规划，然后说“好的，我需要选择哪种模型投入生产，或者使用通义千问的某个版本”，而现在就必须做出规划。我基本上无法预知这六个月会发生什么。这非常困难。要实现100%的数据本地化，也非常困难。

另一方面，我看到很多公司采用了一种方法，我们也在利用这种方法，即使用不同类型的模型。一些本地模型可以处理非常敏感且未匿名化的数据，然后通过一个匿名化层剥离所有最敏感的数据，再利用前沿模型来平衡数据安全、数据本地化与成本和前瞻性之间的关系。因为目前要预测未来六个月的情况对我来说非常困难。

Alex Infanzon：过去几年我注意到，数据库层正在逐渐演变为控制平面。过去数据库只是后台存储数据的仓库，而在如今的智能代理AI系统中，数据库已经成为了控制平面。为什么会这样？因为代理生成的大量交易和指标（如遥测数据）都存储在数据库中，从而可以生成使用情况报告、令牌使用量等信息。此外，数据库还存储了代理的身份信息，包括代理的元数据。为什么这很重要？现在你必须管理这些代理的身份。

出于安全考虑，你必须管理代理的身份，通过身份来控制代理的访问权限，并在需要时撤销代理的访问权限。同时，数据库之所以成为控制平面，是因为现在需要追踪代理的行为并记录日志，以便对环境中的操作进行审计，这些日志也可以存储在数据库中。关于本地性问题，正如Luca提到的，你需要一个全球分布的数据库，能够为本地应用提供低延迟访问。通过分布式SQL技术，你可以实现这一目标，即数据库在全球多个区域分布，但对外表现为一个统一的逻辑数据库。这就是核心理念。

当代理访问意大利的数据时，由于访问的是本地区域的节点，因此会获得较低的延迟。对代理来说最关键的一点是，所有这些信息必须保持同步且始终一致。这是关键所在。在这些类型的应用中，你不能接受最终一致性。否则，代理将基于错误信息采取行动，而对代理错误操作进行回滚将变得极其困难，因为这会触发一系列不可控的连锁反应。

AI应用的回滚

Renato Losio：实际上，干净地回滚AI能力有多容易？我主要想到的是传统应用，但就AI应用而言，这种回滚具体意味着什么？

Meryem Arik：你所说的容量规划具体指什么？

Renato Losio：如果我想到了一个非常简单的传统应用，我会想到我的应用集群随着节点数量的增减进行扩展或收缩，数据库的容量也会相应调整。但当我想到令牌数量、所有资源数量都在增长时，我开始思考：如果我想拥有一个按使用量付费的弹性容量，该如何实现容量收缩？如何对AI应用进行回滚？可能我所处的思维模型完全不同。可能我年纪足够大，还不习惯这些新方法。

Meryem Arik：大多数在生产环境中使用AI的人（除了一些受严格监管的行业外），都是通过第三方API提供商与AI进行交互。

Renato Losio：他们把问题推给了第三方。

Meryem Arik：他们把这个难题推给了别人。我必须面对的问题是，如何快速实现实例的扩容和缩容？如何在不同模型之间快速切换？例如在我的技术栈中，假设我提供了20个不同的模型，但GPU算力是固定的，我该如何根据用户需求灵活提供所有模型？目前有一个活跃的研究社区正在探索如何优化冷启动性能，如何实现更快的扩容。对大多数人来说，他们已经将这个问题交给了推理服务提供商，但对我们而言，这是一个需要切实解决的现实问题。

Simerus Mahesh：我认为我可以从另一个角度来分析这个问题。显然，这取决于你所说的"回滚"具体指什么。有些操作，比如回滚系统提示、模型版本或功能开关，可以通过标准的回滚流程来实现，这相对简单直接。但当我们面对自主代理系统时，回滚一个已经产生实际影响的AI能力就变得非常困难了。这些代理可能正在处理生产环境中的代码，它们的输出不仅仅是文本。代理可能已经创建了文件、修改了配置、发起了代码拉取请求、调用了云API，这些操作在某种程度上是不可逆的，还可能更新了数据库、队列中的状态，甚至触发了Jenkins等下游工作流或CI/CD流水线。

在这种情况下，我认为回滚的概念已经不再仅仅是部署的回退，而是更多地需要补偿产生的副作用。我认为正确的做法是在发布之前就设计好回滚机制，比如使用功能开关、进行预演测试（dry run）模型以及设置审批关卡。特别是对于这些自主代理系统，治理机制在当今显得尤为重要。我们还需要采用类似ACID数据库的幂等操作。我认为最干净的回滚方式，往往就是从一开始就防止不可逆操作的自动执行。我认为这个问题没有明确的答案，因为存在太多变量和不同的可能性。我认为预防措施在这里是关键，尤其是在处理自主代理时。

Luca Bianchi：我完全同意，因为要回滚代理执行的工作确实非常困难。这有点奇怪，因为对话历史记录很容易恢复和保存。问题在于代理的推理过程，以及它选择使用某个工具而不是其他工具的原因，这些是不容易回滚的。我可以回滚某个操作的效果。比如你执行了数据库查询，我可以回滚这个查询并做任何我想做的事情。但要回滚导致这个查询或工具选择的推理过程，就非常困难了。

我们在智能代理系统中面临一些不确定性，需要通过防护措施来处理，或者专注于操作的影响本身。

Alex Infanzon: 我完全同意你的观点。我们目前正在与一家大型信用卡提供商合作，我之所以提到这一点，是因为一旦引入代理并让多个代理协同工作，一个代理可能会基于过时或错误的数据触发某些操作，并将这些错误传递给另一个代理。该代理会继续执行自己的操作，可能触发另外两个代理执行后续操作，这些操作的结果会被持久化存储到某个地方。由于这些信息和记录都是基于初始代理的错误假设得出的，因此最终结果都会是错误的。我们正在为这家信用卡公司工作，目前我们正在与另外两家公司合作，其中一家名为DBOS，该产品的主要功能是帮助追踪代理的工作流程。

工作流程实际上会存储在数据库中，并且可以进行回滚操作，从而采取相应措施。你可以确切知道代理执行的每一步操作，因此可以追溯问题并进行修复。我们合作的另一家公司名为Memori，他们负责将代理的内存状态存储并持久化到数据库中。此外，他们还能利用数据库中代理已学习到的知识和过往操作记录，编写和配置更优质的提示词，并将这些信息注入到新的提示词中，继续执行后续操作。这也是非常重要的一点。关键在于，通过数据库中的向量搜索，你实际上可以查找相似性，找到数据库中存储的与当前内存中相似的历史记录。

Renato Losio: 从技术角度来看，搜索本身并不是回滚。

实时Saga模式与回滚

参与者1：在对话过程中逐步构建的实时Saga模式是否有助于实现回滚？

Alex Infanzon: 如果你能够追踪每个代理的每一步操作并记录所有更新，那么Saga模式是有效的。当模型或代理出现故障时，你可以回滚并追溯操作，撤销已执行的步骤。这是唯一可行的方法。过去，所有这些信息都存储在数据库的日志中，只需查看日志即可回滚事务。如今情况更加复杂，因为你不是在回滚一个事务，而是在回滚一系列发生在不同代理上的操作，这些代理具有不同的状态。这就是问题所在。

Renato Losio: 正如Luca提到的，这些操作可能本身并不可逆。你可能需要进行补偿，需要在说出口后立即采取行动。

参与者2：实际上，我一直在思考这个问题的含义。我们之前提到过隐私问题，但对安全问题讨论得不多。我一直在想，谁会是受影响最严重的？是数据团队、平台团队、值班团队还是安全团队？目前谁在资源能力方面面临最大的挑战？我的感受是，我们说资源能力是有限的。我们有有限的资源，可能在几个小时或几天内只能扩展10个实例。即使是GitHub这样的大公司也曾面临类似挑战。接下来会怎样？谁该为此负责？目前谁面临的挑战最大？

Simerus Mahesh：我做过很多SRE工作、软件工程工作和生产工程工作。我认为我可以自信地说，目前仍然是SRE，比如轮值的SRE人员，甚至平台工程师，但主要是轮值的SRE人员。原因主要是AI工作负载的变化速度非常快。在正常产品中，流量增长通常只与用户增长或已知的发布相关。但对AI系统而言，相同数量的用户突然可能产生远超预期的流量或负载。仅仅因为代理新增了一个提示词或工具调用，甚至只是上下文长度增加，就可能导致代理进入更激进的循环。这可能会使基础设施的需求瞬间增加十倍。

这基本上说明了即使用户流量正常，生产系统也可能崩溃。显然，当试图解决这些问题时，首先想到的通常是SRE。即使请求数量本身并不显眼，但每个请求现在在后台执行的工作量却大幅增加。举个例子，代理可能运行更长时间、调用更多工具、创建更多状态。轮值人员面对的不仅是更多流量，而是工作负载的成本和行为可能在一夜之间发生巨大变化。这正是导致睡眠不足的原因。

Alex Infanzon：我认为数据库在未被证明无罪之前总是有罪的。通常问题总是出在数据库上。当工程师决定更改数据库的嵌入向量时，数据平台团队需要迁移包含4000万行甚至更多数据的模式，这会带来巨大挑战。或者当安全团队发现代理访问权限存在治理漏洞时，需要数据平台团队构建审计日志的也是他们。正如Simerus提到的，当代理循环导致数据库被频繁访问时，SRE团队会在凌晨2点被通知。猜猜看，谁会出现在这个电话会议中？是数据库管理员（DBA）。我从事DBA工作多年，深知在证明数据库无责之前，你总是需要承担全部责任。

Renato Losio：我们是在说老规矩——DBA总是第一个被怀疑的对象吗？

Alex Infanzon：是的，你总是会被视为责任人。你的数据库运行缓慢，你的数据库性能不佳，数据有误。是的，我知道。在被证明无罪之前，你总是有罪的。这正是关键所在。正如我们所说，要处理这些复杂问题非常困难。我对数据平台团队所付出的努力表示由衷的同情。但另一方面，我认为数据库正在重新成为智能体AI的控制平面，因为现在我们需要在所有应用中的所有智能体之间保持状态一致性。

Renato Losio：你同意这个观点吗？你是否认为数据库始终是主要问题所在？

Luca Bianchi：是的。我认为如果不说是最主要的，至少是最重要的因素之一。因为在当今这个世界中，我们有很多可以轻易被生成代码替代的组件，最终所有东西都会撞上数据库。归根结底，你迟早会被数据库狠狠打脸，或者被设计糟糕的数据库、性能不足、数据结构不够完善导致难以检索等问题困扰。与过去相比，现在有一些显著的不同之处。过去我们设计数据库是为人类服务的。我记得Hernandez写过一本非常著名的书《Database Design for Mere Mortals》（《凡人数据库设计》）。其核心思想是让程序员能够为人类展示数据而设计数据库。

如今逻辑正在发生变化。在不久的将来，我们可能会看到智能体从数据库中检索数据，甚至从多个数据库中获取信息。一些限制条件可能与我们无法在认知负荷中同时处理太多数据库或同一团队使用太多不同数据库有关，这些因素可能正在变得不那么重要。我完全同意，数据库确实是所有问题的根源。

Alex Infanzon：我需要澄清一点，数据库本身并没有失败，而是你们在指责数据库。它并没有失败。人们总是说“是数据库的问题”。就你提到的，现在有太多智能体和系统在访问数据库，DBA（数据库管理员）根本无法跟上需求。因此，在Cockroach Labs，我们正在努力让数据库变得更智能。我们正在为数据库添加人工智能能力。AI代理可以实时监控：为什么性能会停滞？为什么写入速度变慢？为什么延迟在增加？所有这些问题都可以由数据库内部的AI自动完成。早在2000年代初，Oracle就曾提出过“自主数据库”的概念。

Renato Losio：这已经过去很久了。

Alex Infanzon：我们现在正在通过在数据库中部署智能体来实现这一能力。这是从基础设施角度来看的。

基础设施：过去与现在的智慧

Renato Losio：实际上，我有一个不同角度的问题。如果我们回顾过去，有哪些曾经被认为是基础设施领域的重要原则，但如今在AI时代已经不再适用？你是否觉得有什么根本性的变化？因为现在我们仍然在说“数据库是问题的根源”，但基础设施领域除了我们已知的资源不足之外，是否还有其他重大变化？

Meryem Arik：我认为一个显著变化是运行软件的单位经济模型发生了根本性转变。过去人们热衷于投资软件业务，因为它们有很高的利润率，而且具备超强的可扩展性，因为底层基础设施成本并不是决定因素。但现在情况不同了。如今基础设施成本非常高昂，将成为企业未来成本结构中的主要部分。过去70%、80%的利润率已经成为历史。基础设施实际上已经成为企业运营中的关键成本驱动因素，甚至是最重要的成本驱动因素。这种现象在软件行业中是前所未有的。

Simerus Mahesh：就AI代理而言，更广泛地说，AI工作负载本身已经让“需求激增时只需通过自动扩展来应对”的理念变得过时。我认为这种方法在工作负载主要由人类驱动、受正常用户行为、点击模式、数据库访问模式等限制时确实更有效。但AI代理不同，一个用户操作可能触发模型调用、工具调用甚至代码执行的循环，因为它们拥有沙箱环境、重试机制、数据库读写、云API调用等能力。如果这个循环效率低下或配置错误，自动扩展不仅无法解决问题，反而可能因产品缺陷或微小低效操作引发巨大基础设施费用，甚至导致级联故障引发系统停机。

新的认知是：在扩展AI工作负载前，必须先进行边界控制。需要为运行时执行、工具调用、重试机制、多租户环境配置、安全隔离的沙箱环境以及整体影响范围设置限制。弹性计算和云资源仍然非常有价值，云平台确实是理想部署环境。但对AI代理工作负载而言，我认为“边界控制”必须优先于弹性能力，自主性必须建立在受控基础上。

Alex Infanzon：我完全同意。近年来我一直在思考的一个问题是：过去我认为应该根据预期增长做容量规划，但面对智能体AI时这几乎不可能实现。我认为更合理的做法是规划弹性架构，让系统具备弹性伸缩能力。否则你根本无法预测这些代理会生成的实际工作负载，这会带来巨大挑战。我无法预测这个工作负载，无法说“凭借当前数据库基础设施我能处理多少”。我需要让数据库具备弹性。请思考这种弹性——正如你所说Simerus，代理系统必须设置防护机制来约束需求使用范围。对我而言，弹性将是让智能体应用根据需要动态扩展或收缩的关键。

Simerus Mahesh：我完全同意。此外我认为弹性能力应该作为第二优先级，而不是替代边界控制。应该首先为代理设置边界，确保其安全性，避免过大的影响范围。因为弹性能力本身（如使用AWS时）本质上意味着无限计算资源，只是成本问题。这种特性可能引发持续的资源消耗，具体取决于自动扩展策略。如果使用Karpenter生成更多节点，或在Kubernetes环境中创建更多Pod，系统会不断扩展计算资源和容器来运行程序。这可能因配置错误或不期望的行为导致资源滥用，这非常危险，可能造成AWS账单激增，甚至导致系统变慢。

Renato Losio：我看到人们主要抱怨两个问题。一方面，你的AI工作负载可能会触发某些情况，导致账单突然激增。另一方面，由于Meryem之前提到的容量问题，云服务提供商设置了软性或硬性限制，但这些限制通常无法满足实际需求。如果你使用Bedrock，或者使用任何访问模型的工具，突然发现容量不足，这两个问题会同时出现。一方面有人抱怨容量不足，另一方面有人对基础设施的约束设置不够严格。

Alex Infanzon：是的，像CockroachDB这样的数据库厂商，我们正在努力通过将计算与存储分离来减少限制。这样可以实现计算的弹性扩展。如果需要更多计算资源，只需增加计算节点；如果需要更多存储空间，只需扩展存储。我们试图将这两者隔离，从而更高效地管理基础设施。

可操作的见解

Renato Losio：我是这场圆桌讨论的参与者，我认同你强调的这个主题的重要性。我想问，作为从业者，我应该采取哪些具体行动？可能是阅读一本书、一篇文章，或者部署一个实例、设置一些防护措施？你有什么建议可以让我明天就实施？

Luca Bianchi：从明天开始，你应该重新审视你的架构，考虑AI的采用及其对基础设施的影响。我认为架构是你今天就应该优先考虑的首要问题。我建议阅读一些经典书籍，比如Neal Ford的《进化型架构》，这些书非常值得阅读，因为它们能告诉你一些原则和方法，帮助你在不断变化的世界中应用。要预见到变化。预计很快会有新的共享计算数据库发布，会有新的代理和模型出现。问题是，如何在这些变化中保持竞争力？我找到的唯一答案是构建一个能够进化、能够适应并及时利用这些新技术的架构。

Meryem Arik：我最大的建议是，对于过去6个月或12个月没有尝试过开源模型的人，现在应该尝试最新的开源模型。过去几个月它们的能力有了巨大提升，比如GLM 5.2。它们性能极佳且成本低廉，具体延迟取决于推理服务提供商。开源模型，你一定要尝试并部署它们。

Simerus Mahesh：在Luca的观点基础上，但并非完全同意。我认为不应该一开始就重新设计整个架构。这是一个持续演进的过程，无法通过一次性的操作完成，因为迁移本身就是一个非常庞大的工程。我建议先选择一个生产环境中的AI工作流，最好是关键流程，无论是对内部开发者还是生产系统本身都至关重要。然后追踪当用户或开发者触发该流程时实际发生了什么，绘制完整的执行路径，包括模型调用、工具调用和数据库查询等环节。接着围绕这条路径提出问题，例如：最大运行时间是多少？工具调用的最大数量是多少？如果某个依赖项变慢会怎样？如果模型重试失败会怎样？我认为目标是找到系统中存在无界风险的环节。

显然你可能无法立即解决所有问题，但我认为通常可以识别出一两个具体改进点，以此作为构建智能代理系统或AI系统变革的起点。我认为这是良好的第一步。

Alex Infanzon：对我而言，核心在于更严谨地评估数据基础设施。要求供应商展示数据基础设施在故障场景下的表现，而非预设负载下的表现。目前的基准测试如TPC-C存在明显局限性，它们只适用于系统100%持续运行的理想环境。供应商需要向你展示：当网络分区时会发生什么？当某个节点宕机时如何应对？当有人要求我修改模式时能否在线完成？如果整个区域失效会怎样？如果我在升级数据库软件时会遇到什么问题？

你必须要求供应商证明基准测试能真实反映系统在压力下的表现，因为AI代理将对基础设施产生巨大压力，我们清楚这一点。

更多带文字稿的演讲内容

录制时间：

2026年7月1日

演讲者：

• Simerus Mahesh
• Alex Infanzon
• Meryem Arik
• Luca Bianchi
• Renato Losio

#### 相关赞助商

#### 相关赞助

• 2026年7月9日 12:00 EDT 从日志噪声到事件智能：AI辅助可观测性的成熟度模型 演讲人：Nicolas Jung - Datadog日志产品经理

#### 本文属于AI、机器学习与数据工程主题

##### 相关主题：

• 架构与设计
• AI、机器学习与数据工程
• InfoQ现场 - 2026年6月
• InfoQ现场
• 文字稿
• 可扩展性
• MLOps
• 虚拟活动
• 性能
• 机器学习
• 基础设施
• InfoQ
• 虚拟圆桌
• 相关编辑
• InfoQ热门内容
• Anthropic负责人：HTML在保持人类参与智能代理循环方面正变得比Markdown更有效
• Google OpenRL是一个用于大语言模型后训练微调的实验性自托管API
• AWS推出工作负载凭证提供者用于自动化证书和密钥管理
• AI正在软件生命周期中向上演进：从代码审查到PRD治理
• 架构模式：超越云原生向本地优先演进 - Adam Wiggins见解
• Cloudflare发布零信任部署和迁移的代理技能