Matt Garman¶
- 背景: AWS CEO。EC2 的首任 GM；自述 2005 年作为商学院实习生做过"AWS 对谁最有用"的内部分析，答案是创业公司。
- 定位: ⚠️ 本库第三位超大规模云厂商一号位（另两位是 Satya Nadella 与 Mark Zuckerberg 在数据中心议题上的表态）。✅ 而本库认为他这一期的独特价值在于他是唯一一位把"agent 作为用户"讲到具体技术后果的——不是战略表述，而是尾延迟、权限粒度、数据库持久性这类可验证的东西。
⚠️ 本库唯一的一手材料是 a16z 2026-10-08 那期。全部性能、份额与收入数字均为他口述，本库一条未核实。 ⚠️ 而需要先说明的是这期的场合：这是在一家风投机构的频道上接受采访，而主持人自述"我们所有的创业公司都在问怎么拿到 GPU""我们会继续把他们送到你这儿来"——所以它既是产品叙事，也是一次面向该机构投资组合的渠道沟通。
核心观点¶
⚠️⚠️ "agent 作为用户"：三条具体的技术后果¶
- ⚠️⚠️ 尾延迟是本库认为他最该被长期引用的一条："他们其实非常在意尾延迟（tail latencies），这很有意思——人不总在意 S3 的 P99.9 延迟，而 agent 确实在意、而且会被它卡住。"（视频页 [00:08:04]）⚠️ 他由此给出一条未核实的竞争主张："这也正是为什么 agentic workflow 在 AWS 上往往比在别处表现更好。" ✅ 本库认为背后的机制（agent 的长链路会把尾延迟累积成阻塞，而人类交互会把它平均掉）是可独立评估的。
- ⚠️⚠️ 一次坦率的承认：有些东西对 agent 是过度工程的："很多 agent 想创建一个数据库、干一点活、然后让这个数据库消失"，而 Aurora 的五个九持久性"对 agent 用例来说是过度工程的"。⚠️ 但他明确拒绝了最直接的解法："我们并不真的想有一个非持久的选项……因为你永远不太清楚被创建的那个数据库是想留很久还是很短。"（视频页 [00:13:05]–[00:14:05]）
- ⚠️⚠️ 四样"全新的积木"，而他强调这不是复用：compute sandbox、gateway、⚠️ 给 agent 的权限 vs 给人/service role 的权限。⚠️ 权限那条最具体："你不会想直接给它（人的）权限然后让它去做任何你能做的事。你其实想要非常有时间盒的、短期的权限，只去做一个任务。你可能根本不想给它整个工具的权限——你可能想要非常细粒度的权限。"（视频页 [00:14:05]–[00:15:06]）
- ⚠️ 沙箱侧的一条产业观察：Firecracker microVM "我们大概十年前发明的"，⚠️ 而"很多做沙箱的创业公司都在用 Firecracker"；他说这是巧合不是预见——"它不是为 agent 而生的，但它对 agent 其实相当好用"（视频页 [00:15:06]–[00:16:06]）。
- ⚠️ 为 agent 降门槛的具体产品变化：新建 AWS 账号不需要信用卡、可用 Gmail 注册、"不到 30 秒跑起来"，VPC / IAM 全走默认；⚠️ 而设计点是没有迁移——"你已经在一个真正的 AWS 账号里了"（视频页 [00:10:05]–[00:12:05]）。⚠️ 他也承认这一层此前是输的："你只是在试点什么，你说部署——很多时候那会去到我们某些有更易用层的合作伙伴那里。"
⚠️⚠️ 瓶颈：永远只有最新的那一个¶
- ⚠️⚠️ 框架（引《The Goal》）："结果发现从来没有一个约束，永远只有最新的那个约束。所以你必须考虑所有的约束，而你一撞上一个，就又有另一个。" ⚠️ 他对 2028 的直接回答是拒绝预测："那个约束是什么？我其实不知道。我认为会有一个。"（视频页 [00:27:11]–[00:28:12]）
- ⚠️ 在建约束清单（本库见过最完整的一份）：电力 → 内存 → TSMC 产能 → HBM → 网络部件 → 供应链里的小故障（连接器）→ 硬盘 / SSD，另加资本、数据中心本身、以及 ⚠️ "建楼的施工人员，施工人员今天是很紧的"。
- ⚠️⚠️ 而那条地理限定解释了为什么总量充足也不够："可能是：嘿，我们在印度尼西亚有一大堆电力，但在德国不够……因为结果发现不是所有东西都是完全可替换的（fungible）。"（视频页 [00:28:12]）
- ⚠️ 他们十年前就开始往下穿透供应链："往下四层、五层，哪个部件可能给我们造成问题，并确保我们在那上面有了保障供应。" 历史触发事件是泰国洪水导致的硬盘短缺（视频页 [00:29:12]）。
- ⚠️⚠️ 电力的变化幅度："15 年前如果我们需要更多电，我们就让电力公司再给我们几兆瓦，他们就直接给了，因为 10 兆瓦不算多。" 而现在自带电力（表后与"付资本→进电网→拿 credit"两种模式都做），自述过去十年每年最大的可再生电力采购方之一。⚠️ 规划期："那是你要想到 20 年之后的规划……而这是我们以前从来不必想的事情。" 供应侧从多个季度变成多年（26/27/28）。⚠️ 他把这条变成价值主张："他们不会去规划自己 2028 年的内存占用——他们做不到这件事。"（视频页 [00:25:10]–[00:27:11]）
- ⚠️ 一条值得记的承认：弹性被 AI 负载消耗掉了（视频页 [00:21:08]）："我认为最痛的一件事是，随着 GPU 的真正爬坡，很多弹性不幸地消失了。" ✅ 本库标注：弹性正是云最初的核心卖点。
⚠️ 资本、分配与泡沫¶
- 口径（均为自述）：营收约 1690–1700 亿美元、增长 37%（[00:01:00]）；⚠️ capex "2026 年 2200 亿美元……这是我们有过的最大的一笔支出——也许是任何公司在单一年份里有过的最大支出"，且"我们预计短期内不会放慢"（[00:17:06]）；⚠️ "未来几年要买 200 万片 NVIDIA GPU"，而他自己加了一句 "谁知道这够不够"（[00:20:08]）。
- ⚠️ GPU 分配率（本库此前没有的口径）："对最终收到的请求里，大概 60% 以某种形式说了是——有时候晚一点，有时候在不同的区域，有时候是略有不同的配置。" ⚠️ 而他说不全卖给大实验室是主动选择："我们本可以把每一片卖给那些大型前沿实验室然后就收工。我们选择不这么做。"（视频页 [00:19:07]）
- ⚠️ 创业公司在 AWS 的历史权重："可能 30% 到 40% 的 AWS 营收来自那些曾经是创业公司的公司"（⚠️ 他自称"不精确的数字"）。⚠️ 而他给的前瞻机制本库认为是这一节最好的商业逻辑："银行五年后会想要的某种能力，是创业公司今天就想要的。"（视频页 [00:03:00]–[00:04:00]）
- ⚠️⚠️ 而他的泡沫回答里最该被核查的是那条集中度对照："你去看一些 neocloud 或者市面上其它一些供应商，你有时会看到 30%、40%、50%、60% 集中在一两个客户上。我们远远不到那个程度——我们最高也就是个位数百分比，而且通常比那更低。"（视频页 [00:22:09]）⚠️ 本库记为一条可被财报检验的结构性声明。
- ⚠️ 他对创业公司层面的泡沫直接承认："是不是每一家十亿美元的创业公司都能成？不，不会。但那就是这个游戏。" 类比是互联网泡沫——"互联网仍然是个东西……那些有持久业务的公司做得相当好"。
- ⚠️ 而他对企业 ROI 给的是逸事式证据，本库标为未核实："你去跟客户聊……几乎每个人都会说'哦，是的'。"
- ⚠️ 他对"你们应该最先叫出需求拐点"的回答是资本配置口径，没有给任何拐点判据（视频页 [00:23:10]）。✅ 本库记下这处回避。
⚠️⚠️ 自研芯片：一条"每步先证明再加码"的路径¶
- ⚠️ 他自己给整段定的性："它是一个很好的例子，说明 Amazon / AWS 会怎么创新、怎么随时间迭代、怎么继续把我们能做的想得更大——但是一路验证过去（prove our way there）。"（视频页 [00:33:13]）
- 路径：虚拟化税 → 网络卸载卡（约 13–14 年前，"还不完全是裸金属，但更接近了"）→ 为卸载存储虚拟化而收购一家"在卸载卡上有 ARM 核"的公司（⚠️ 公司名全程未出现，本库不补）→ Nitro（裸金属、无 VM 虚拟化、一切走卡上 API）→ Graviton（把那些 ARM 核做成服务器）→ Trainium（约五六年前启动）。
- ⚠️⚠️ Nitro 的那条安全后果本库认为最该被记住："我们当时可以合法地告诉人们：对于跑在那上面的你的任何 VM，我们没有访问权。" ⚠️ 而他对竞争格局的解释："我们一直领先、别人一直比较慢，因为这不是一件人们能泛化地做的事。"（视频页 [00:34:13]–[00:35:15]）
- ⚠️⚠️ 而那条下注依据是全期最清晰的一次技术判断："我们看了并看到 ARM 核在变快的那个斜率，还看到功耗利用率和那条曲线——你就知道这个架构在哪里会对某些部分真的很好的那个交点会发生。而它们只是需要有人来驱动这个生态。"（视频页 [00:36:16]）
- ⚠️ Graviton 的数字（均为自述）：便宜 20% + 性能好 20%，"过去大概五六年一直是这样"；"我们每年落地的 Graviton 芯片比任何其它类型都多"；"前 100 大客户里大概 90% 以上都在用"；"有客户把整个机群搬过来、把服务器数量砍掉了一半"。⚠️ 他的表述："这是客户降低账单最容易的单一方式。"
- ⚠️⚠️ Trainium 的角色反转：⚠️ "结果发现 Trainium 其实也许是现在市场上最好的推理芯片——从绝对性能和性价比的角度。" ⚠️ 而被问技术原因时他只说"架构就是有点不一样，而且便宜得多"，没有给任何可核验的依据，本库记为未核实的竞争主张。（视频页 [00:38:16]）
- ⚠️ 他自嘲了命名："我们在命名上很糟糕……原本我们有一颗叫 Inferentia 的芯片做推理、Trainium 做训练。"
- ⚠️ 状态：Trainium 3 在市场、Trainium 4 已宣布未发布；产能"已经卖光了，大概到明年年底左右"；"Bedrock 上的大部分流量都跑在 Trainium 上"；"我们和 Anthropic、OpenAI 都有很好的协议在 Trainium 上构建"，另有半打到一打创业公司。
⚠️ 企业 agent：两条阻碍，以及 eval 的空白¶
- ⚠️⚠️ 阻碍一是思路："不要只是复制 Bob 做第 1、2、3、4、5 步，所以 agent 也做 1 到 5 步，然后 Bob 在最后检查一遍——那不是你想要的模型。" ⚠️ 而正确的提法是："如果我想达成某件事，一个 agent 能怎么用不同的方式做到？它可以用大规模并行的方式做，可以试 50 种不同的东西……要重新思考一台计算机会怎么解决一个问题，而不是一个人会怎么解决一个问题。"（视频页 [00:41:16]）
- ⚠️ 阻碍二是信任："企业感到紧张，可能很恰当地（maybe appropriately）让他们没法直接说'去吧，放开干'。你其实不想让一个 agent 发疯、不小心删掉一个生产数据库。" ⚠️ 他对企业现状的判断："大多数企业建的 agent 都相对简单直接……而且基本是非自治的，还是人在环里"，但"客户今天仍然从中拿到了很多价值"。
- ⚠️⚠️ 而 eval 那句承认本库认为是全期最该被引用的一句（视频页 [00:43:16]）：问题清单是"怎么有一个持续的测试回路？怎么把数据标注成让 eval 真能近似你在生产里要做的事？怎么在生产里度量并回测，这样你不会看到 drift？"，⚠️ 而落点是："所有这些都是企业今天不知道怎么解决的问题。我其实不确定今天有谁真的擅长解决这些。"
- ⚠️ 他给的 FDE 模式有明确的退出条件："我们想训练我们的客户让他们自己能做这件事。这不是那种传统的、我想要一个永远持续的人力驱动业务、你一遍遍付咨询费……在 45 天里做这些工作，然后你就离开，那个客户已经准备好了。" 依据是"他们不想在未来五年被一支外部队伍绑住"。
- ⚠️ Bedrock 的卖点收敛成一条数据边界："你的数据永远不离开你的 VPC……他们永远看不到你的 prompt。" ⚠️ 措辞很强："让那些数据回到模型提供方，我认为是一件危险的事。" ⚠️ 而他自述三年前"因为慢于进入 AI 世界而挨了很多骂"，现在给的结果是"绝大多数（从 PoC 到生产的客户）都落在 AWS 的 Bedrock 上"，⚠️ 并声称"OpenAI 的负载在往 Bedrock 迁移"（本库未核实）（视频页 [00:45:17]–[00:47:17]）。
- ⚠️ 开源权重 + 自有数据这条路他给了"实际发生在哪"的观察：客户相信后训练/微调/蒸馏到开源权重模型能"以更低价格得到一个表现更好的模型"，⚠️ 前置条件是"他们确实需要有一个好的 eval 来真正证明那是真的"；⚠️ 而落地位置是 SageMaker——"他们今天确实是在 AWS 上用 SageMaker 做，而且也通过 SageMaker 托管推理。" ⚠️ 他对企业行为的概括："他们基本上实际上是在建自己的定制模型。"（视频页 [00:47:17]–[00:49:18]）
⚠️ 安全与内部使用¶
- ⚠️⚠️ "机器速度的安全"："客户在某个时点会需要机器速度的安全，而不是人速度的安全——不是一个告警、某个人进去看一眼。" 产品是 Continuum（用强模型找漏洞并结合环境上下文做优先级排序："它是怎么配置的、权限在哪里、哪里可能有补偿性控制"）；⚠️ 来源是内部实践——"Continuum 基本上就是我们把内部做的事情暴露出来。"（视频页 [00:50:19]–[00:51:20]）
- ✅ 本库标注：这与 Kevin Mandia 两天前那期的"人留在检测与响应环里就一定太慢" 是同一条判断，而两人分别站在云厂商与安全厂商一侧——本库认为这构成一次有价值的同向佐证。
- ⚠️ 内部使用：Amazon Quick 推给了每一位 Amazon 员工；⚠️ "HR 团队在建 agent，去驱动那些过去需要几人团队花几周做的事，现在一个人几小时就能做"；财务团队建 agent 拉税务规则做合规。⚠️ 结构性意义："过去被软件开发者卡住的事情，现在业务线的人能够自己解锁。"（视频页 [00:52:21]）
- ⚠️⚠️ 而他对自己工程组织的描述本库认为值得单记："我们叫他们 frontier team，他们思考的是 agentic development 而不是传统开发。而这不是代码补全——它真的是 agent 优先：agent 写所有的代码，你只是在管理一支 agent 团队、并驱动它。"（视频页 [00:53:21]）
- ⚠️⚠️ 组织形态他明确说没有答案："我不知道那个神奇答案。我们在积极思考。" ⚠️ 具体变化是："一个团队长期拥有某一类能力，可能有 10 个人；而今天你能创新得这么快，那件事可以是三到四个人。" ⚠️ 而后果不是裁员而是流动性："他们造东西造得这么快，你其实想把他们挪到不同的项目和问题上去。" ⚠️ 他对人数的判断是温和的："会有很多人、很长一段时间。"（视频页 [00:54:22]–[00:55:22]）
⚠️ 数据中心的社会许可（本库记为立场而非事实）¶
- ⚠️ 他同意行业传播做得不好："我认为我们需要更主动发声、更坦率。" 三条实质内容是水（"用水量真的真的非常小，大部分用自由空气冷却"）、高薪就业、⚠️ 以及税收——"某个县的每个人每年少交 5000 美元的税，因为我们带来的税收。而我们不告诉他们，他们甚至不知道。"（⚠️ 转述一份未具名报告，本库未核实）
- ⚠️⚠️ 而他公开划了同行，本库认为这本身是一条值得记录的产业表态："不是所有数据中心运营方都那么做……他们不太在意监管，他们认为规则不适用于自己……而这给整个行业造成了问题，因为所有人都被归到那一类里去了。" ⚠️ 收口把多数留在好人一侧："数据中心社区的大部分其实是相当好的行为者，只有少数几个不是。"（视频页 [00:30:12]–[00:32:13]）
⚠️ 本页的三条限定¶
- ⚠️⚠️ 场合：AWS CEO 在一家风投机构的频道上接受采访，主持人自述"我们会继续把（我们的创业公司）送到你这儿来"。✅ 本库把机制性论证当作可独立评估的内容收录，⚠️ 把全部数字标为自述未核实。
- ⚠️⚠️ 最该被核查的三条：capex 2200 亿 / "也许是任何公司单年最大支出"；客户集中度"个位数百分比" vs neocloud "30%–60%"（可被财报检验）；GPU 请求约 60% 的"说是"率。⚠️ 两条性能声明本库记为未核实的竞争主张："agentic workflow 在 AWS 上往往更好"、"Trainium 也许是市场上最好的推理芯片"（被问技术原因时他未展开）。
- ⚠️ 本库记下三处他被问到但没有回答的问题，因为它们本身是信息：① "infra 团队会被 agent 取代"——他只答了基础设施就绪度那一半；② "你们应该最先叫出需求拐点"——给的是资本配置口径，无判据；③ 企业 agent "已经是一个相当大的生意"——全期无任何收入或使用量数字。