亚马逊一年要花两千两百亿美元建基础设施，而且 Matt 说短期内不打算刹车。钱花到哪里去了，云又会变成什么样，是这场对话的主线。这期节目用一句话概括变化——agent 越来越多地写代码、管基础设施。Raghu 的问题是：当客户想要一个不光对人友好、对 agent 也友好的云，AWS 这门生意要改什么？
Matt 在对话里给的答案很具体。他提到 agent 想建一个数据库、干一点活就让它消失，这让 AWS 得重新想五个九的持久性到底还需不需要——但他的原则是不能提供一个不持久的选项，而是想办法同时做到用完即弃和长期可长成生产库；新用户注册账号从「先配 VPC、先定义 IAM 角色」变成三十秒、不绑信用卡就能跑起来。他本人的说法是，AWS 内部已经在做「智能体式开发」，代码全由 agent 写，工程师管的是一个 agent 团队。
Matt Garman 2005 年以 MBA 实习生身份进入亚马逊，实习课题是分析 AWS 对谁最有意思，结论是创业公司；2006 年转入 AWS，是 EC2 早期团队成员，2024 年 6 月出任 AWS CEO。这场对话从两千两百亿美元资本开支讲起，一路聊到 GPU 怎么分配、瓶颈怎么从电力转到内存和芯片、自研芯片从 Nitro 到 Graviton 再到 Trainium 的路径，最后落到企业里的 agent 怎么落地、怎么被信任。他的主要观点包括：
创业公司是 AWS 的命脉，不是边角料。 Matt 说，今天 AWS 大约 30% 到 40% 的收入来自「曾经是创业公司」的企业。而且推着 AWS 往前走的常常不是银行、医疗公司或政府，而是这些创业公司——「银行五年后想要的能力，创业公司今天就要」。
Matt 说 2026 年的资本开支是两千两百亿美元，短期内不打算刹车。 他说这比公司历史上任何一年都多，可能比任何公司任何一年都多。未来几年还要买两百万块 NVIDIA GPU，量非常大，但谁知道够不够。他还提到，过去很长一段时间投资是走在需求前面的，随着 GPU 需求爆发，很多弹性已经没有了。
AWS 非常刻意地保证给创业公司留产能。 Matt 承认完全可以把每一块 GPU 或 AI 加速器都卖给几家前沿实验室，但选择不那么干，为的是让整个生态长起来。他提到对外公开的口径是大约六成请求最终能满足，有时候要晚一点，有时候换区域，有时候配置和客户想要的稍有差别。
瓶颈永远只有一个，而且会换位置。 Matt 引用《目标》说，你刚突破一个，马上又冒出一个。电力、数据中心、资本、内存、芯片轮流卡人；十几年前缺电就找电力公司再要几兆瓦、几十兆瓦，因为十兆瓦不算什么，现在得自己出钱做电力项目、可再生能源项目，还要算清楚 2026、2027、2028 年各要什么。
自研芯片是十几年一步步验证出来的，不是一次性下注。 从把网络虚拟化卸载到网卡、收购 Annapurna 团队做出 Nitro，到 Graviton，再到 Trainium。Matt 说 Graviton 比别的芯片便宜 20%、性能还高 20%，前一百大客户九成以上都在用；Trainium 3 产能基本卖光，排到明年年底前后，Bedrock 上大部分流量跑在它上面。
agent 会建了数据库就用完扔，AWS 得重新算五个九的持久性还需不需要。 Matt 说很多 agent 想建一个数据库、干一点活就让它消失，而生产库要的持久性和可用性在这里也许就是过度设计。但他的原则是不提供一个不持久的选项，因为你不确定刚建出来的库是要留着还是只用一小会儿。他还点了几个全新的构建块：计算沙箱、网关，以及区别于人和服务角色的 agent 权限——非常有时限的短期权限。
企业采用 agent 卡在两点：思路没换，和不敢让它自主。 Matt 说大多数企业搭的 agent 还很简单、仍有人在环里，客户真正想的是怎么安全地变自主。他劝客户不要照抄现有流程，「不是 Bob 做第一步到第五步，agent 也做第一步到第五步」，而是从一张白纸重新想。评估体系今天企业普遍不知道怎么解。
AWS 内部用 agent，收益最大的是软件开发。 Matt 说 AWS 给每个员工推了 Amazon Q。HR 团队在做 agent，以前要一整个团队干好几周的事，现在一个人几个小时就能搞定，比如团队规划和资源管理；财务团队也在做 agent，去想怎么把各处的税务规则拉过来。而收益最大的地方是软件开发——不只是写代码，「我们推出新产品的节奏跟过去完全不是一个量级」。
两千两百亿美元资本开支：瓶颈永远只有一个
Raghu：最顶尖的前沿实验室把市面上能拿到的 GPU 全吃掉了，可同时你也想扶持那些将来会成为大企业的新公司。这中间的平衡你怎么考虑？
Matt：从 AWS 刚上线那天起，创业公司就是我们这门生意的命脉。他们是站在技术最前沿的创新者，最清楚什么是可能的。所以我们会很刻意地给创业公司留出算力。我们最近还宣布，接下来两年要买两百万块 NVIDIA GPU。
Raghu：你们的资本开支跟那个数差不多吧，两千亿还是多少？
Matt：差不多，2026 年是两千两百亿美元。而且我们没打算这么快就刹车，因为需求实在太大了。
Raghu：现在大家都在争论 AI 的生存性风险，还有 Hugging Face 被攻击那件事，CEO 们问你的都是些什么问题？
旁白：亚马逊计划今年投入两千两百亿美元资本开支，而 AWS CEO Matt Garman 说，他们短期内不打算放慢脚步。这一期，a16z 的 Raghu Raghuram 请来 Matt，一起拆解是什么在推动这场史上最大的基础设施扩建之一，以及 AI 正在怎样改变云本身。他们聊了 AWS 怎么决定把紧缺的 GPU 算力给谁，瓶颈怎么从电力和芯片转移到内存和施工，还有公司在自研芯片和 Trainium 上的押注。他们也谈到，当 agent 越来越多地写代码、管基础设施，会带来什么变化。Matt 还分享了 AWS 内部看到的情况：agent 现在会写代码，工程师越来越多是在管理一组一组的 agent，新产品做出来的速度快了很多。
Raghu：Matt，欢迎来节目。我们真是赶上了了不得的时代。今天想跟你聊的话题特别多。
Matt：太好了。谢谢你请我来，我很期待。
Raghu：那必须的。咱们干脆从头说起。你是 EC2 的第一任总经理，那是 2006 年，对吧？现在你们营收大概多少，一千六百亿、一千七百亿美元？
Matt：对，大概一千六百九十亿到一千七百亿美元。
Raghu：还增长百分之三十七。一千六百九十亿的基数上还增三十七，太疯狂了。
Matt：这里面门道太多了。从赚到第一块钱那天想起来，是挺有意思的。但有意思的是，这门生意能做成多大、对客户来说机会有多大，我们现在都还在早期。大部分负载，今天仍然有海量负载跑在本地，而且大家每天做的计算量都比前一天更多。所以你能看到 AI 带来的顺风，也能看到往云上迁移带来的顺风，业务增长得非常快。能参与其中，特别过瘾。
Raghu：确实。我觉得以后历史书、商业书会写这件事写上很多年。我想聊聊本地部署这块。这事儿挺让我感慨的，我当年显然是拼了命想让它们留在本地。
Matt：你那时候在本地搭了一大堆东西，现在又想把这些全都搬到 AWS 上。
Raghu：这个咱们后面再聊。那你想，早年 EC2 那会儿，你是从卖创业公司起步的。今天的 AWS 云服务，回头看你走过的这条路，什么最让你印象深刻？先说第一部分，第二部分我们聊你服务创业公司的方式发生了什么变化。
Matt：好。就像你说的，其实挺有意思的。2005 年我在 AWS 实习，那会儿它还是个内部项目，是我商学院期间的实习。我的项目就是做一份分析，看 AWS 最可能吸引谁，结论是创业公司，还挺出人意料的。
所以从 AWS 上线那天起，创业公司就是我们这门生意核心的命脉，原因有好几个。一是 AWS 给创业公司的价值主张太有吸引力了。我们花了很多时间和精力，确保自己是创业公司的好伙伴，不只是提供基础设施，还帮他们出主意，怎么把公司跑起来、架构该怎么想才能撑得住未来的规模，诸如此类的事我们为创业公司做了很多。但我们也觉得，这对我们来说是门好生意，因为今天的创业公司就是明天的企业。这个数字不精确，但我们估计，今天 AWS 大概百分之三十到四十的收入，来自在 AWS 有生之年曾经是创业公司的那些企业。所以看着这些公司一点点长大、变大、真正变成大企业，对我们来说很有意思。这也是为什么我们在创业公司身上投这么多、盯得这么紧，包括那种两个人刚在车库里起步的公司。不光是因为生意上的回报，也是因为我们是跟他们学的。
他们是站在技术最前沿的创新者，清楚什么是可能的，会推着我们的服务往前走，告诉我们他们想要什么更多的东西、什么能让他们更快、什么能帮他们拿到结果。很多时候，推得最狠的不是银行、不是医疗公司、也不是政府，而是这些创业公司。这真的帮我们变得更好，让我们走在浪头前面，因为银行五年后想要的能力，创业公司今天就要。
Raghu：对。那跟当年比，创业公司本身、还有他们想要的东西，都发生了哪些变化？他们当然都想要大量 GPU，这个我们可以聊，但除了这个之外呢？
Matt：有几个变化。一是创业公司起步的体量比当年大多了。以前他们可能融到一千万美元，有个应用的 idea，慢慢迭代。现在他们从第一天起估值就十亿美元，融了两亿美元。一个团队加一个想法，转眼就值十亿了，从我们办公室搬到你们办公室得了。而且这些想法的规模、体量和野心，我觉得需要更多资本。起步就更大了，也更烧钱，对吧？要去做训练、做一个模型，或者做现在很多人都在做的事。这是第一点。
第二点是有些东西没变。他们其实还是在想，等我规模上去了，架构怎么设计？安全怎么考虑？性能怎么考虑？我需要的能力怎么都拿到？怎么把自己搭起来，等我不止三个员工的时候，这东西还能跑得动、撑得住。这也是很多时候他们喜欢 AWS，而不是直接去用一家新兴 GPU 云的原因。他们确实需要训练之外那一整套安全和能力。这点没变，跟当年一模一样。变的是爬坡的速度，今天肯定不一样了。
另外我们也越来越常看到，团队想要一个不光对人友好、对 agent 也友好的云。这块我们花了很多时间。你该怎么想，怎么考虑大规模，怎么考虑性能，怎么有一个定义清晰的 API 接口，让 agent 能轻松跑通、跨着用。这件事我觉得我们本来就有天然优势，但我们确实又加码投入了，去确保像数据库三秒钟就能起来这种事，真的做出来让 agent 兴奋的能力。
Raghu：你们有没有推出专门面向 agent、或者面向做 agent 的人的新服务？
Matt：我们的做法是，把一些已有的服务做优化，让它们既能给人用，也能给 agent 用。所以说专门为搭建 agent 设计的服务我们肯定有，比如 AgentCore、Amazon Bedrock 这一类。但如果是拿底层组件来说，比如 S3，绝大多数公司的数据和数据湖都放在那儿。你会发现人和 agent 的大量使用场景是相似的，只不过你希望有一个——我们现在有个东西在预览阶段，也可以说是 beta，叫 AWS Context——它能帮你搭一个上下文层，让 agent 更容易在你的各个数据湖里找到它想要的数据。不管你的数据存在 Aurora、存在 S3，还是存在 AWS 里别的地方，你都能搭出这么一层上下文。人未必会那样访问数据，但 agent 完全愿意跨着这一堆东西去取。像这样的服务我们在做。
但大多数情况下，你还在意延迟怎么样、吞吐怎么样，怎么保证底层引擎真的够快、能扩展。有意思的是，agent 非常在意尾延迟。人不会总盯着 S3 的 p99.9 延迟，但 agent 会在意，会被它卡住。这正是我们长期在意的事情，从性能角度看也是最能打得出来的点。所以智能体式工作流在 AWS 上跑，通常比在别的地方都好。
Raghu：对，我们确实看到很多公司刚起步，最常听到的一句话就是 agent 帮他们把代码全写了。而且 agent 还会挑数据库、挑邮件服务器，你能想到的东西它都挑。所以你们有没有大量思考过，当然它们会读文档，AWS 平台上那些说起来有点怪的所谓老牌服务，已经存在十年的那些，你们怎么重新设计它们？
Matt：我想，是的，有些东西我们确实想过。其实最底层的那些构建块，我觉得状态相当好。我们想的是上面那一层易用性，怎么让它更好用。就拿你说的最简单的场景来说，有人特别快地写了个 app，然后让 agent 去部署。我们发现绝大多数客户会直接告诉他们的编码 agent，不管是 Kiro、Claude Code 还是 Codex，说我要在 AWS 上搭，这是我的凭证，这是我的东西，我想这么部署，然后 agent 很争气，直接就去做了。但也有一些场景，你本来就不在云上，只是试一下，说了句部署，说实话很多时候就跑到我们那些在更上层做了易用封装的合作伙伴那儿去了，我们也很喜欢这些伙伴。
不过我确实觉得有些事我们在做。如果你是全新用户，本来没有 AWS，也没配过 IAM，几个月前开个账号要难得多，二十年都是这样，你得先定义 VPC，定义 IAM 角色，这一堆东西。等你规模大了，这些其实特别重要。客户跟我们说，这个取舍很难，因为他们知道自己几个月几年后肯定要用，可眼下他们只想用服务，不想操心这些。所以我们上线了这样的东西：你今天去开一个新的 AWS 账号，这还在逐步推开，我不确定是不是已经全量了，但那些步骤你都不用做了，也不用绑信用卡，用 Gmail 账号就能注册，这些全在后台按默认帮你处理好，不到三十秒你就能跑起来，拿一个完整的 AWS 账号在做事。对这类系统来说，这更贴近 agent 想要的能力，因为它不想去走那套配 VPC 的流程。
所以有些地方我们在加易用性，挺兴奋的，也收到了客户很正面的反馈，后面还会继续做。好处是，这不是一个简化版账号、以后还得迁移。你要是说好，我现在要扩展了，要建组织，要精细调整一些东西，你直接就能做，因为你本来就在一个真实的 AWS 账号里，之后需要什么随时去开。所以不存在迁移或者搬家。这就是我们真正花力气想的事：怎么让客户不用二选一，而是有一条轻松的入口，通往我们知道客户和创业公司规模化之后一定会需要的那些深层功能。
Raghu：明白了。那 agent 接管之后，最难伺候的地方是什么？你们能成名，能变成现象级，靠的就是服务开发者，然后是基础设施团队。现在开发者被 agent 取代了，很快基础设施团队也会被 agent 取代。作为全球最大的服务商，这个转变里最难处理的是什么？
Matt：你看，就像我说的，我们大部分基础设施其实已经准备得挺好，能扛住这个规模，这是好事。有几件事挺有意思，我觉得是很有意思的范式转变。你甚至可以说我们有些系统——我不说它是过度设计，但举个例子，很多 agent 想建一个数据库，干一点活，然后就让这个数据库消失。你真的需要那个数据库有五个九的持久性吗？是吧。所以有些东西我们要重新想。当你建一个 Aurora 数据库当生产库的时候，你确实要五个九的数据可靠性，你需要持久性、需要可用性，这些都要。而放到 agent 的使用场景里，这些可以说，也许不用加也许，就是过度设计了。
所以这很难。有一种想法是，我们并不想提供一个不持久的选项，那也会惹麻烦，因为你永远不太确定刚建出来的这个数据库是想长期留着还是只用一小会儿。所以我们在下功夫想怎么同时做到这两件事：既能快速建出来、用完就扔，又不浪费太多资源，而如果真要留着，它也能持久、能长期存在，最后长成一个大型生产数据库。这些取舍我们一直在主动想，也就是传统那种「这是我的生产系统」的能力，怎么和 agent 想用的那种更短暂的基础设施对上。我觉得这是一个。但还有一堆。持久资源创建时的规模、速度和延迟是另一个有意思的点。
我们还在主动想的另一个问题是，有没有一些 agent 想要、而我们以前根本不需要的全新构建块？比如计算沙箱、网关，还有 agent 权限和人或者服务角色的权限的区别。这些很多是我们已经建好、正在建、正在认真琢磨的东西，因为它们是全新的构建块。不是把现有构建块换个用法，而是全新的。给 agent 的权限显然要不一样，你不会直接让它拿你的权限想干嘛干嘛。你要的是非常有时限的、只为了完成某个任务的短期权限。你甚至可能根本不想把整个工具的权限给它，而是想要非常细粒度地规定 agent 能在沙箱里做什么。你其实想要一个沙箱，能瞬间拉起来。
Raghu：虚拟化也要拿出看家本领了。没错。
Matt：而且它们不一样，是相似，思路相同，但关键是怎么做到足够轻量，怎么去想。好在我们在 Firecracker 微虚拟机上做了很多工作。
Raghu：其实很多做沙箱的创业公司都在用 Firecracker。
Matt：他们全都用 Firecracker，那是我们大概十年前发明的。它其实是专门为这个目的做的，不是专门为 agent 做的，但它对 agent 来说特别好用，因为能瞬间拉起来，有很好的安全边界，而且没有传统大虚拟机那种虚拟化开销。所以这些都是我们在琢磨的新构建块，而且每天都有新的冒出来。
Raghu：我这一通聊 agent 聊得够多了，后面再回来说，这话题确实有意思。不过咱们换个方向，问一个所有创业公司都会碰到、也是我们被问得最多的一个问题，就是怎么才能拿到 GPU？你们显然在运营超大规模的 GPU 集群，而且每天都在扩。但最顶尖的前沿实验室把能拿到的 GPU 全都吃掉了，祝福他们。可同时你也想扶持那些会成为明天大企业的新公司，就像你刚才说的。你怎么平衡这种代价高昂的需求，和这些小公司没什么信用额度之间的矛盾？
Matt：这个问题问得好。而且有几件事让这件事变得更难。一是要部署现在大家需要的这些算力，资本开支是巨大的，对吧？所以我们现在的——
Raghu：这笔资本开支的规模是多少，两千亿左右？
Matt：2026 年是两千两百亿美元。我有一次看到这个数字，这比我们历史上任何一年都多，可能比任何公司任何一年都多。而且我们短期内不打算放慢，因为需求实在太大了。所以到某个点上，你受限于数据中心能建多快、资本能投多快、内存和芯片这些能拿到多快。这些在不同时期都会成为瓶颈，电力、数据中心、资本、内存、芯片，轮流卡你。会盖楼的人现在特别紧缺，搞建筑的人都是高价抢的。这些我们都在拼命保障。
然后在我们能部署出来的产能上，虽然量还是很大，但我们知道还是不够，我们会非常认真地去想分配策略。我们和大的前沿实验室是很好的合作伙伴，Anthropic、OpenAI、Meta 这些大客户，他们都是我们很好的客户，我们肯定要投资他们。我们也有很多大企业客户，Salesforce、JPMC 这些大公司，他们的 GPU 或加速器需求数量少一些，有时候要 Trainium，有时候要 NVIDIA GPU，我们也得支持好他们。
同时我们非常刻意地保证给创业公司留产能。我们的做法是真的做分配。说白了就是，你说得对，我们完全可以把每一块 GPU 或 AI 加速器都卖给那几家前沿实验室和云业务，但我们选择不那么干，因为我们要让整个生态持续成长。他们会拿到很大一块，但我们也要继续支持更广的客户群，因为我们觉得整个生态更健康对我们也有利。这里面有分散风险的因素，但也因为我们都清楚，这些公司以后会变成大公司，所以尽量去支持他们。我最近看到我们对外说，大概有六成左右的请求最终是能满足的。有时候是要晚一点，有时候是在不同区域，有时候配置和客户想要的稍有差别，但我们真的在努力倾斜资源，尽量多分配。而每一个创业公司都想要更多。
Raghu：对，确实。
Matt：所以我们在努力保证这些都能供上。但这很难。就像很多人说的，这是个甜蜜的烦恼，确实是，但它终归是个烦恼。我们也在持续看，比如最近宣布未来几年要买两百万块 NVIDIA GPU，我们要落地的产能是巨大的。两百万块，量非常大，是在未来几年里，但谁知道够不够呢。到某个点，我们又会受限于其他部件。可我们确实非常刻意地给创业公司留产能。我知道产能不够是很痛苦的，但我们会继续往前推。
Raghu：你们的资本开支是什么时候跨过……就单说 AWS，那时候亚马逊整体更大，跨过比如一年十亿美元或者一百亿美元是什么时候？
Matt：这个我还真不知道，得回去查一下。不过过去几年肯定是有非常明显的增长，AI 的建设确实把我们的资本开支推上去了。可以说过去三四年，我们的资本开支明显加速了。我不记得是哪一年跨过十亿的，但既然现在都到两千两百亿了，那应该是挺早以前的事了。我们花资本开支已经花了很多年，公司在这上面的资金支持一直做得很好，AWS 本身也是我们愿意投的好业务。
而且我觉得很长一段时间里，我们的投资其实是走在需求前面的。我觉得最难受的一点是，随着 GPU 需求真正爆发，很多弹性其实都没了，希望以后能恢复。在我们核心的计算和存储这些业务上，弹性还在。所以我们已经投了挺长时间了，而且我们对现在的投入感觉很踏实。
Raghu：对，对，那当然。
Matt：经常有人问我怎么看这笔投入，是不是担心泡沫之类的。我想说，因为我们所处的这个位置，第一，我们采取的是分散的做法，产能不会全压在一个客户身上。你去看那些新兴 GPU 云或者其他一些厂商，有时候会看到一两个客户就占了三成、四成、五成、六成。我们离那个差得远，我们最高的也就个位数百分比，通常还更低。这一来我们在单个客户上的风险小很多，二来我们有一整套丰富的服务，AWS 是人们真正跑生产工作负载的地方。所以我们今天大部分用量其实是核心计算、存储和推理，这些都是应用的一部分，我认为这些工作负载不会消失，因为我们看到企业在拿到正回报。你去问客户，以今天的能力和今天的成本，你的业务有正回报吗？几乎每一个人都会说，有。
Raghu：而
Matt：那你就知道，这块不会消失，不存在哪种泡沫会让他们停掉这块支出。而且你也懂，就像 VC 的模式，每个十亿美元估值的创业公司都能成吗？不可能。但这就是游戏规则，五十年都是这样。当年也不叫十亿美元公司。
Raghu：数字变了，道理没变。
Matt：道理是一样的，对吧？你押十个，一个成了，把另外那十个的钱赚回来，不管比例是多少。
Raghu：就是那个著名的幂律。
Matt：对。互联网当年就是这样，有过泡沫，一大批互联网公司没撑下来，可互联网这个东西今天还在。而那些做成了长久生意的公司，Google、Amazon 这些，活得都挺好。所以对我们来说，这笔投资和后面继续加码，我们心里很有底。
Raghu：你们对需求的判断是没人比得上的，对吧？因为你们看的是全球，看的是每一个细分市场，大企业、大实验室、AI 原生的公司，全都看得到。所以真要说谁能先做出判断，那也只能是你们。
Matt：希望是这样，这就是我们的打算。说实话，我们花了大量时间想这件事，股东的钱怎么花，我们是非常刻意的。我们觉得自己在做很好的投资，钱往哪儿投，我们心里有相当靠谱的预判。但整体上我们非常看多。Andy 也公开讲过，AWS 的潜力非常非常大，未来十年机会就在那儿。碰上这么大的机会，你就是要投进去。
从十亿到两百亿的单子：电、内存、芯片轮流卡你
Raghu：随着这些数字越滚越大，你们的规划和流程是不是也彻底变了？你们现在签的已经不是十亿级的单子，而是五百亿、两百亿美元级别的单子。
Matt：对，也变也没变。我觉得很多时候我们对投资依然很看多，敢往前压。但流程上，确实有很多东西完全不一样了。
Raghu：2028年的需求你到底怎么估？
Matt：有些事是我们现在必须想、以前压根不用想的。回到十五年前，我们要是缺电，就找电力公司再要几兆瓦、几十兆瓦，他们就给了，因为十兆瓦不算什么，够我们继续长。现在我们得自己带电源进来，自己出钱做电力项目、做可再生能源项目。过去十年我们每年都是最大的可再生能源采购方之一，所以我们一直在不断接入新的太阳能项目、新的核电项目。
两种方式都做。很多时候这些电力项目是我们出资本、出钱建，建完并入电网，我们再拿相应的额度；有时候也做表后供电，是混着来的。以我们现在的体量，这些事全得想。这也是规划的一部分，你得想到二十年以后，电怎么解决、输电怎么解决、这笔资本怎么安排。这些以前完全不用想，因为以前根本没做过这种规划。
服务器需求也一样，以前我们按几个季度的量去想，跟供应商谈一谈；现在得按好几年去想，因为量太大了，必须算清楚2026年要什么、2027年要什么、2028年要什么。这也是我们带给客户的价值之一，客户自己真做不了这些事。他们不会去做电力规划，也不会去规划2028年的内存用量，他们做不到。所以这就是我们对一大批客户实实在在的价值：这一堆事你不用操心，我们花大量时间替你想。
Raghu：说句公道话，服务器里几乎每一个部件，你们基本上都是最大的买家，对吧？
Matt：这我可不敢说。我确定我们是比较大的部件采购方之一，这点没问题。但谁比谁大，那得看你怎么算、用什么口径衡量。
Raghu：我想引到的问题是，你觉得哪里卡得最死？就说2027、2028年，哪里又会松下来？
Matt：有意思。我绕个弯回答这个问题。我本科的时候读过一本书，当时压根没想到它会有用，那本书叫《目标》。结果发现，瓶颈永远不止一个，永远只是当下那个瓶颈。所以你得把所有环节都想着：你刚突破一个，马上又冒出一个。
2028年会卡在哪儿？我其实不认为会卡在某一个点上。对我们来说几乎是每个月都在问：电够不够？电一旦不再是瓶颈，可能就轮到内存，可能是台积电的产能，可能是HBM，可能是网络部件；也可能是供应链某个地方突然出问题，比如连接器，或者别的什么小东西。到某个阶段，这些环节你都得想到。
而且卡在哪里也很重要。比如说我们在印尼有一大堆电，但德国不够，所以你得想清楚产能要放在世界哪个地方，因为并不是所有东西都能随便换来换去，有些能，有些不能。可能是硬盘，可能是SSD。每一个部件我们都会想，我们跟踪和盘算的部件有几十万种，有些交给供应商管，很多是我们自己直接管。我们有一整个团队在做这件事，非常强，我认为是行业里最好的。这个问题我们大概十年前就看到了苗头，不只是想我们要跟踪多少台服务器，而是把整条供应链一路捋下去，往下捋四层、五层，找出哪个部件可能出问题，然后确保这个东西的供应是锁定的。你要是记得，十多年前泰国发大水，那时候谁都拿不到硬盘了。
Raghu：硬盘危机。对，后来还有内存危机。
Matt：没错。所以这些事我们都会想。我们也会想制造环节在哪儿能分散，所有这些我们都会尽量捋清楚。我们不可能做到完美，但永远会有新的供应瓶颈。
Raghu：数据中心这事，外面的争论可以说是铺天盖地。像我们这样的公司站在什么立场，大家都清楚。但你觉得，作为整个行业，我们是不是没把一件事讲明白，就是数据中心为什么对美国、对全世界都是好事？还有，Andy他们团队内部是怎么讨论应对这件事的？
Matt：这个我同意。接下来你们会听到我们更多发声。我们确实需要说得更多、更直接，因为我们做的事情其实非常多，对社区也是真有好处。比如怎么把可再生能源引到这些数据中心来，怎么做到水正，我们是下了很多功夫的。其实我们的数据中心用水量非常非常小，主要靠自然冷却。还有怎么当个好邻居，怎么把高薪工作带到我们所在的社区。
但不是所有数据中心运营方都这么做。有几个案例已经被报道得挺多，他们这方面做得不好，不太在意监管，觉得规则跟自己没关系，或者就是上线特别快，根本不想这些。结果整个行业跟着背锅，大家都被一锅端。所以我觉得你说得对。我们讲自我批评是认真的，但我们也得更大声地讲我们带来的好处，还得再想想办法，让社区更明白我们能给他们带来什么，包括他们用的那些服务。你到一个社区去问：你不用Netflix吗？人家肯定说，用啊，我当然还想用Netflix。所以强调我们带去的价值很重要。
我最近看到一份报告，我们运营的其中一个社区里，那个县的每个人一年少交五千美元的税，就是因为我们的税收贡献。可我们从来没告诉过他们，他们自己都不知道，对他们来说这是完全看不见的。所以我们就是得把这些好处讲清楚。你想想，如果你告诉社区，要不是我们在这儿，你的税单每年要多交五千美元，他们看那边那栋楼的眼神可能就完全不一样了。
Raghu：那大概还是需要更多的透明度。
Matt：我觉得数据中心这个圈子里，大部分公司，不只是我们，其实都挺守规矩的。就是有那么几家不像话，最近这些情绪，很大程度上是他们惹出来的。我们该做的是更清楚地告诉别人，谁是好公民，谁不是。
自研芯片这条路：从 Nitro 到 Graviton 再到 Trainium
Raghu：聊完硬件这个话题之前，我想聊聊 Trainium，还有你们自研芯片的整个历程。很多年前，我们就是最早用 Nitro 的合作伙伴之一。从那以后 Graviton 的进步非常大。所以当初是什么考虑让你们决定自己干？后来的进展又如何？
Matt：这其实是特别有意思的一段故事，也是亚马逊 AWS 怎么做创新的一个好例子：我们会不断迭代，把想做的事情想得越来越大，同时一步步验证着往前走，而不是一上来就赌。就拿这件事来说，大概是十三四年前。
当时我们看到，整体资源上有一块相当可观的虚拟化损耗。我们就在想怎么办。客户跟我们说，我要裸金属的性能，他们会拿一台服务器的全部资源来比。所以我们做的第一件事，是拿一张网络卸载卡，把网络虚拟化整个搬上去，让网络虚拟化接近裸金属的性能。那时候还谈不上完全等于裸金属，但已经接近多了。
然后我们就特别兴奋，说那存储虚拟化能不能也卸出去？可当时没有一张网络卸载卡能做这个。后来我们找到一家公司，他们在卸载卡上放了 ARM 核，本来是干别的事。我们问，能不能用这些核来做存储虚拟化和别的功能？他们说也许可以。我们就跟他们反复打磨。这就是 Annapurna 那个团队。
对，我们特别喜欢那个团队，非常有创新精神，使命感很强，就是想把问题解决掉，非常棒。所以我们把他们收购了，然后说，你们能不能给我们做一张大一点的卡，把网络虚拟化全部卸出去，基本交给我们一台没有虚拟化的裸金属服务器，没有虚拟机这一层，一切都通过卡上的 API 走。因为我们当时判断，第一性能会好很多，资源利用率更高，第二安全隔离会好得多。这样我们就可以理直气壮地跟客户说，你们跑在上面的虚拟机，我们一台都碰不到。这件事在过去十年给我们带来了巨大好处。说实话，这块是我们领先，别人跟进得比较慢，因为这不是谁都能做的通用活。走到这一步之后，我们就说，我们在这儿进展不错。
既然这张卸载卡上跑着一堆 ARM 核，那我们干脆把它做成一台服务器？我们先拿 Graviton 做了这件事，第一代是个性能很弱、很小的一台服务器。客户很兴奋，说我想要 ARM 服务器，这太有意思了。于是我们就一路走下去。做 Graviton 的时候我们也看了趋势，ARM 核的性能在往上走，把功耗曲线画出来一看，就知道这个架构在某些场景会变得特别好，那个交叉点一定会到，只是需要有人去把生态带起来，把缺的几块拼上。所以我们就做了 Graviton，现在它是彻底爆了。
Raghu：你们公开过 Graviton 在你们机队里占多少比例吗？
Matt：我们每年新增的 Graviton 芯片比任何其他类型都多，非常受欢迎。它便宜百分之二十，性能还高百分之二十，这个状态已经持续了大概五六年。所以价值主张非常直接。我们前一百大客户里，九成以上都在机队的某些部分用了 Graviton。这对我们和客户都是巨大的胜利，也是客户降账单最简单的一招，就是迁到 Graviton。我们有客户把整个机队迁过去，服务器数量直接砍掉一半，性能好太多了。服务器数量减半，每台还更便宜，这是大赢。
再往后，大概五六年前，我们看到 AI 算力开始起来了。当时完全没想到会是今天这个规模，但已经看出它会是个很大的变量。于是我们做了我们的第一颗芯片，Trainium。现在我们已经把第三代 Trainium 3 推向市场了，效果非常好。产能基本卖光了，大概到明年年底前后都排满了。我们也在想办法挤出一些产能，让创业公司能用上，因为效果确实好。Amazon Bedrock 上大部分流量现在都跑在 Trainium 上。我们跟 Anthropic 和 OpenAI 都有很好的合作，让他们在 Trainium 上构建，还有一批更小的创业公司。现在大概有六到十二家创业公司在 Trainium 上做东西。
Raghu：这名字听着像是训练芯片。但大家现在也拿它做推理。那从架构上看，它的强项在哪，接下来往哪走？
Matt：你说得对，起名字这块我们不行。自我批评一下，我们起名真的很糟糕，这不是我们的强项。最早我们有一颗芯片叫 Inferentia，专门做推理，Trainium 是训练。后来模型越来越大，结果你其实是希望在这种超大规模系统上跑推理的，就发现……从绝对性能和性价比来看，Trainium 现在可能就是市面上最好的推理芯片。
它的架构跟别家不太一样，而且便宜得多。所以从性价比和绝对性能两个角度看，Trainium 都很强。我们拿它做推理用得特别多，刚才也说了，今天 Bedrock 上很大一部分推理都是它跑出来的。
但它同时也是块不错的训练芯片。我觉得我们大量客户用它的场景不是在训模型，而是在用模型。所以很多人其实是在底层不知不觉就用上了它，这也是我们兴奋的地方。不过很多大客户也对拿它做训练集群感兴趣，尤其是到了 Trainium 3 和 Trainium 4。这两代我们已经发布了。Trainium 4 还没正式上线，但已经对外公布。不少人看过那个架构之后说，对，我以后所有的训练集群也要走这条路。所以对未来的大规模训练集群我们也很兴奋。是的，它两头都能打。
企业里的 Agent：从人在环里到完全自主
Raghu：那我们回到 agent 这个话题，这次从大企业、大中型企业的角度看。它们在采用上走到哪一步了？已经拿到了哪些实实在在的好处？从你的位置看，它们接下来的路线图是什么？
Matt：这个问题问得好，也是我们花了很多时间在想的事。我跟客户聊的时候发现，他们今天已经从已有的东西里拿到了不少价值。说实话，大多数企业搭出来的 agent 都还比较简单直接，而且基本不是自主的，还是有人在环里盯着。顺便说一句，客户靠这个今天就已经拿到很多价值了。他们现在真正在想的是，怎么让它变得自主，但又是安全的。
我觉得有两件事卡住了客户，让他们没法继续扩大规模。这块业务今天已经不小了，但我觉得它有巨大的机会去改变每一个客户、每一条工作流。第一件事是怎么想这件事。我们最早看到的是，企业有一条现成流程，就说好，那我让一个 agent 去跑同样的流程。我们劝他们做的其实是换个思路，不是照抄，不是 Bob 做第一步到第五步，agent 也做第一步到第五步，最后 Bob 来检查。这不是你想要的模式。你要退一步问，如果我要达成一个目标，agent 能不能用完全不同的方式去做？它可以大规模并行，可以一次试五十种做法，然后走到那个结果。关键是帮它走到正确的结果，重新想一台计算机该怎么解一个问题，而不是一个人怎么解。所以我们做的一件事，就是帮客户理解该怎么想这件事，真正从一张白纸开始。因为价值恰恰不在复制你今天在做的事，而是用全新的思路去想怎么完全不一样地解决问题。我相信你们的创业公司也都是这么想的。这是第一点。
Raghu：还有人已经在跑成群的 agent、agent 集群，随便你怎么叫。这现在太常见了。
Matt：你就得往这个方向去想。企业不像创业公司那么激进，这方面你要向创业公司学，然后再想怎么把这套搬到企业里。比如一家保险公司未必那么超前，但他们很想搞清楚怎么把审批流程做得更好。
第二点是，怎么把这些变成完全自主的工作流，以及你怎么真正信任 agent。我们花了大量时间想怎么建服务，让企业觉得自己的系统是安全的，可以放心让 agent 去做决定，有合适的护栏，数据权限也是对的，不会把生产系统删掉，不会犯下灾难性的错误。现在这种紧张感，我觉得正是拖住大家的因素。顺便说，这种紧张也许是应该的，它让企业不敢说，行，随便它去干吧。你其实并不想让一个 agent 发疯，不小心把生产数据库删了，那可就惨了。所以我们正跟客户一起把这件事推下去，既帮他们做架构设计，也坦率地说，去发明新的技术和能力来帮他们解决这个问题。这是我们会持续创新的方向之一，我们会走到那一步。我觉得我们手上有些不错的主意和技术正在酝酿，能真正帮上忙。
Raghu：那企业是不是在学着搭建评估体系之类的东西，好让这些 agent 保持可靠？他们需要帮助。
Matt：老实说，两边都要。评估怎么做，怎么有一个持续测试的闭环，怎么合理地考虑目标导向，怎么把数据标注成评估真正能用得上的样子。怎么对应你生产环境里要做的事，怎么在生产里度量、再做回测，让你不至于看到漂移。这些今天企业都不知道怎么解，我也不知道现在有谁真的解得特别好。
Matt：这就是为什么冒出这么多前场部署工程师（FDE）团队，AWS 和我们的伙伴都在往 FDE 这个动作上压，去帮客户。这是客户最需要帮助的一块。我的看法是，我们要把客户训练到能自己干这件事。这不是传统那种我想做一个靠人堆出来的、永远做不完、让客户一遍遍付咨询费的生意。
我们对 FDE 该怎么干的理解是，进到一个准备好接手、我们干完就真正自己拥有的客户那里，用四十五天做出成果，同时教会他们怎么搭评估，怎么把数据以标注好的方式准备好，全程跟他们一起干。四十到四十五天结束，我们撤出来，这个客户已经准备好、也训练到位了。这也是客户告诉我们的，他们想要的东西。他们不想未来五年都被一支外部团队绑住，但他们今天需要人帮忙。
Raghu：对，你们在 FDE 上投了很大的资源。那再往前推一步，你的一些同行说，你不能把所有数据都往一个大的前沿模型里塞，企业真正该做的是拿一个开源模型，用自己的数据、工作流、话术去后训练。你怎么看这件事？你看到客户真的在这么做吗？还是你们怎么想这个问题？
Matt：很好，第一点我完全同意。客户和企业的数据是他们最值钱的资产。所以从一开始，我们把 Amazon Bedrock 就按这个思路来做。我们保证你的数据永远不离开你的 VPC。你在 Bedrock 里跑，数据不会回到模型提供方，他们永远看不到你的 prompt，数据始终待在你自己的可信环境里。这就是企业愿意在 Bedrock 上跑的原因，也是这块业务增长这么猛的原因。我们每个月、每一周都能看到这块业务在爆发。这也是为什么 OpenAI 的负载开始往 Bedrock 上迁，为什么 Anthropic 长得这么快。所以不管你是用开源模型还是闭源的前沿模型，我觉得 Bedrock 都是一个很好的方案。
顺便说，客户也这么跟我们讲。你要是记得三年前，我们挨了不少骂。
Raghu：名字起得烂。不过这个名字不错。
Matt：Bedrock 这名字确实不错。但我们其实因为进 AI 太慢被骂得很惨，因为我们那时候是先打地基。我们说，我们不打算随便赶一个服务出来，我们要认真想清楚怎么保护客户的数据，怎么做出一个我们知道的那些场景能长期扛得住的服务。那时候挨了不少骂，但我们说，我们要去做对的东西。现在大家从概念验证走向生产，绝大多数都落在 AWS 的 Bedrock 上。原因之一就是这个，另一个原因是我们手里这整套服务。我们也提供开源模型，也提供闭源模型，还围绕它们做了一整套能力。比如 AgentCore，我们做这些积木块，就是为了让你用任何一个模型都更容易地搭 agent，模型在不在 Bedrock 里都行，你甚至可以用 Gemini 或者别的。我觉得这是我们的差异化，也是特别值得想的一件事，因为把数据送回模型厂商，我认为是件危险的事。你刚提到开放权重模型，我确实觉得有一个让我挺兴奋的场景，就是我们正在大力加强对开放权重模型的支持，努力做一个好的选择。
Matt：说实话，现在很多客户都相信，自己手里有真正有价值的专有数据，如果能掺进去，对开放权重模型做一些后训练，做一些微调，把它蒸馏下来，就能用更低的价钱拿到一个性能更好的模型。这里面有好几个环节都得同时跑通，首先你得有一个好的评估体系来真正证明这件事。目前大多数人是在 SageMaker 上做这些。我觉得我们还能再做不少事，让它更简单。但你现在去看大家实际在哪做，其实就是在 AWS 的 SageMaker 上做，推理也是通过 SageMaker 托管的。
Raghu：SageMaker 这是迎来第二春了。
Matt：它一直就是个做模型的平台嘛。现在企业在这波里干的事，本质上就是在建自己的定制模型，所以 SageMaker 是个很合适的地方。我觉得还有一些东西要接着往上搭，让它越来越容易，也能在不同开放权重模型之间做对比测试之类的。但这是个还在演化的领域，特别有意思。我们要确保一件事：客户只要手里有对的数据和专业能力、真想走这条路，那我们该有的东西都得有。
Agent 安全与企业内部实践：机器速度的防御
Raghu：聊 AI 的争论里，存在性风险、安全问题、漏洞，还有 Hugging Face 那次攻击。企业这边怎么样？CEO 们都在问你些什么？
Matt：问题挺多，说到底还是回到这一点：我上线 agent 的时候，怎么才能相信它会按我想的去做？所以我们一直在花很大力气做这方面的能力，让人们能把 agent 安全地部署到自己的环境里，把管控想清楚。
其中一些是，怎么保证 agent 有正确的权限？怎么做正确的沙箱隔离？怎么保证有一组合适的护栏？怎么有意识地想清楚你要 agent 做什么、不做什么？中间有没有人在环？我们花了很多时间跟客户一起想，怎么才能安全地部署 agent，怎么让它随着时间越来越好，以及我们还需要造哪些能力，帮大家把 agent 安全地部署进自己的环境，这里面东西很多。
另一个角度是很多人担心的：这些特别强的模型会不会被拿去做攻击服务之类的？我的看法是，对客户环境来说这确实是真实的风险，但它同时也是真实的机会。所以我们最近发布了一个服务叫 Continuum，就是用这些强大的模型帮客户保护自己的环境。它会扫一遍你的环境，用这些强模型一起找漏洞，帮客户找出以前找不到的漏洞，最重要的是顺便帮你排出优先级——因为我们了解你环境的上下文，知道它是怎么搭的、权限在哪、哪里可能有补偿性控制，让它更难或更容易被利用。Continuum 在客户那边特别受欢迎，我们对用 AI 来做 AI 安全防护这件事非常看好。说到底，有一天客户需要的是机器速度的安全，不是人的速度，不是警报响了、有人进去看一眼。所以我们在快速往前跑，帮客户把这块建起来。Continuum 团队在这方面的进展也让我特别兴奋。
Raghu：那在 AWS 内部，整体上 agent 的使用是什么状况？
Matt：Continuum 其实基本就是我们把内部在做的事对外做出来。我们自己用 AI 用得非常多，安全上用，软件开发上也用，我们用 agent。有件事特别酷：我们给每一个 Amazon 员工都推了 Amazon Q。现在我看到 HR 团队在做 agent，以前要一整个团队干好几周的事，现在一个人几个小时就能搞定，比如团队规划和资源管理。财务团队也在做 agent，去想怎么把各处的税务规则拉过来，确保我们在各种环节上合规。特别酷的是，以前非得等开发人员才能推进的事，现在业务部门的人自己就能解开，创新快多了。Q 带来的好处是巨大的，而且是野火一样地铺开。我们看到从很小的创业公司到全球最大的企业，都在把它推给自己的全部用户，用好企业里所有的数据，轻松地用上 agent 和能力来加速自己的工作。所以我们从软件开发到安全到 HR 全都在用。
Raghu：你们是出了名的什么都要度量。哪些地方收益最大？
Matt：你知道答案的，软件开发，这才是真答案。软件开发的速度，其实是整个产品开发的速度，不只是写代码。
Raghu：是实打实的。
Matt：绝对是。我们推出新产品的节奏跟过去完全不是一个量级。这点你能看出来，AWS 一直以出功能快著称，而过去一年多我们又踩了一脚涡轮，因为我们有了所谓的前沿团队，他们是按智能体式开发来想问题，而不是传统的开发方式。这真不是代码补全，是真的 agent 优先，代码全由 agent 写，你要管的是一个 agent 团队，推着它往前走。看着给客户做创新的速度变得这么快，挺好玩的。也必须这么快，因为我们的客户对新能力的需求几乎是永远不会满足的，这就是我们得干的事。
Raghu：明白。那从组织层面讲，你对组织该怎么变、怎么调整，有什么洞察吗？
Matt：我没有。不过很长时间内还是会有很多人。我确实觉得组织会变，但那个标准答案我还没找到，我们确实在认真琢磨这件事。
Raghu：所以你们内部就是各种试？
Matt：对，一直在试。我们也在琢磨小分队这种形式。举个例子，以前在产品组织里，一个团队会长期负责某一类能力，可能有十个人在干这件事。但今天创新速度太快了，不一定非得十个人，三四个人就够。而且他们做得特别快，你反而想把他们调到别的项目、别的问题上去。所以既要能运转、能维护已经做出来的东西，又要足够灵活，能在 AWS 这么大的组织里随时调动，这些是我们正在试验和摸索的事。这事挺有意思，对员工也是一种赋能，他们是真的喜欢，因为能更快地做出东西、做成更多事，不过这背后有实打实的活儿要干。
道别与致谢
Raghu：现在这个阶段实在太有意思了。非常感谢你抽时间过来，这些话题我们连着聊几个小时都聊不完，谢谢你的分享。
Matt：谢谢你们邀请我。我们很高兴你们投资的那些公司成为我们的客户，也很喜欢从他们身上学东西，很感谢这次机会。
Raghu：好，我们会继续把人往你那儿送。
原视频：Building the Cloud for an Agentic World | AWS CEO Matt Garman
https://www.youtube.com/watch?v=rn_afJaPldg
中文播客：在小宇宙App搜《播客快译》，或直接访问下面的链接
https://www.xiaoyuzhoufm.com/episode/6ac9994de742e36efcc09dfc
编译：磊哥Thomas