最近，Sam 可以说是时间管理大师：一边与马斯克打官司，一边开始训练GPT-6，与微软解绑后第二天就搭上AWS的快车，还和AWS CEO Matt Garman罕见同框录了一场播客！“OpenAI和微软官宣分手”的消息刷屏网络，大家都还在剖析这对绑定了好几年的“AI神仙CP”突然散伙的原因时，OpenAI 已经切换到下一站：亚马逊的AWS——Bedrock托管代理，把 OpenAI 最强的模型和Agent “搬进”去。
在这场访谈里，他们谈论了超多硬核内容：
首先，是 OpenAI 和 AWS 的合作原因。从两位 CEO 的表述来看，大概有三点：企业客户真实需求、让Agent更易用以及AWS+OpenAI的模型优势互补。
“这些东西现在太难做了，如果我们能把它变简单，就能为开发者和企业创造更多价值；还有很多事情是目前根本无法可靠实现的。我认为通过这次合作，不仅仅是“更易用”，我们还会一起探索出一些全新的能力，让人们构建出以前即使付出巨大代价也做不到的产品和服务。”
第二，AI 的下一阶段是什么样的？Sam 的观点是“虚拟同事”：从“输入文本得到文本”，甚至“输入代码得到代码”，转向“在公司内部运行的智能代理，完成各种工作”。
而“虚拟同事”可能是目前最接近的说法，但还没有人找到一个真正准确的词。我们正在一起打造一个新产品，帮助企业构建这种有状态的代理，并让它们投入使用。我们还不完全确定未来人们会怎么称呼或使用它，但如果你看看像 Codex 这样的产品，就能大致看到发展方向。
第三，Agent 运行的最终形态。当主持人以Codex（模型+harness的结合）为例，问为什么现在在本地更容易让 Agent 工作？
Sam 的回答是：
其实我们一开始是让它跑在云上的。但是由于你的整个环境都在本地——电脑已经配置好了，数据也在那里，不需要额外考虑太多事情，所以更容易跑起来。
他也认为本地运行并不是最终形态，未来显然会发展到：Agent 运行在云上，当你有高强度任务、或者关掉电脑时，可以把工作交给云端继续执行。
但在短期内，本地环境带来的易用性更重要。
第四，Bedrock 托管代理和 Bedrock AgentCore 之间的关系。
AWS CEO Matt 的观点是：AWS 和 OpenAI 团队一起，把 AgentCore 的组件、OpenAI 的模型，以及其他能力组合起来，共同构建了这个产品。
我们认为人们很长一段时间都会自己构建智能Agent，但大多数用户还是会希望有更简单的方式，不需要自己去配置所有组件，这也是我们这次合作推出的部分内容。
简单来说，Bedrock 托管代理是一种“托管体验”；而 AgentCore 则更底层，你可以自己选模型。
并且，就目前来说Bedrock 托管代理是OpenAI 与AWS 的独家合作。
第五，关于 token 计费方式。按“token计费”是目前大模型企业主流的订购方式。Sam 把OpenAI 称为一个“智能工厂”而不是“token 工厂”
在他看来，“按token计费”的模式未来可能会改变，并且给出了GPT5.5的例子：我们刚发布的 5.5 模型，单个 token 的价格比 5.4 更高，但完成同样任务所需的 token 数量却大幅减少。用户根本不关心用了多少 token，他们只关心事情有没有完成，以及对应的价格和可用的算力。
第六，与 Google 的竞争表现。主持人提到上一次的采访时“Sam 对于挑战 Google 很有信心”，那么实际的表现如何？
Sam 的表述是：“ 比预期好，ChatGPT 可能是自 Facebook 以来，第一个真正大规模的新消费级产品。”
而且 Google 依然是一家非常强大的公司，它在很多方面仍然被低估。不过总体来说，我对 ChatGPT 的表现是满意的。
除了OpenAI与谷歌对比外，AWS也被问到类似的问题：谷歌的全栈整合路线和AWS的平台路线，AWS选择的中立路线是策略还是意外？
Matt的回复是“从 AWS 创立开始，我们就一直把合作伙伴视为核心战略的一部分。我们的理念是：合作伙伴成功，我们就成功。”
我们更倾向于“做大蛋糕”，而不是试图独占一切。当然，有些公司会选择“全部自己做”，那也是一种路径。但我们认为，让客户自由选择最适合他们的产品更重要。如果客户选择我们自己的产品，那很好；如果他们选择合作伙伴的产品，但运行在 AWS 上，我们也认为这是成功。
当然，除了这些还有更多精彩的地方！
迫不及待分享给大家！
AI 与当年 AWS 的相似之处：把工具交给创作者
主持人：Matt，这是你第一次来 Stratechery。不过有点遗憾的是，有 Sam 在，我们大概没法做常规的“了解嘉宾”环节了。而且他估计也不想听我们回忆在 Kellogg 商学院的往事，不过能请到校友上节目还是很高兴的。
Matt Garman：是的，很高兴来到这里。下次我可以再来，我们可以聊得更深入一点。
主持人：那太好了。你从实习生时期就在 AWS 工作，现在在这波 AI 浪潮中负责整个组织。从构建 AI 业务的角度来看，哪些方面和当年构建“通用算力”业务（姑且这么说）是相似的？又有哪些是真正不同的？
Matt Garman：我觉得相似的地方在于，我再次看到了那种兴奋感——开发者可以做以前做不到的事情。AWS 刚起步时，很酷的一点是，开发者突然可以接触到原本只有那些投入数百万美元建设数据中心的大公司才能拥有的基础设施。只要一张信用卡和一点钱，他们就能启动应用，这极大拓展了互联网创造的可能性。我们的理念一直是：让人们构建他们想要的任何东西，我们不会预设他们应该做什么；只要把强大的工具交到他们手中，全球的创造力就会产出有趣而惊人的东西。
我认为现在这波变革至少同样重要，甚至更具变革性。现在你不需要花十年去学习编程才能构建应用，也不需要数百人的团队和数月时间。小团队就能快速构建、快速迭代，AI 正在释放各个领域的创新潜力。从这个角度看，这和当年非常相似，而且看到客户能做出什么真的很令人兴奋。
训练时代vs推理时代：采用速度远超预期
主持人：不过 AWS 刚出现时，你们几乎是唯一的玩家，所有利弊都由你们承担。而且当时强调的是“通用算力”：可替代、弹性、廉价。但在 AI 尤其是训练阶段，似乎胜出的模式更偏向垂直整合的超级集群、先进网络，以及软硬件的紧密结合。这对你来说算不算一种意外？因为 AWS 最初对大规模计算有自己的一套理念，而 AI 早期的发展似乎并不完全契合。
Matt Garman：我不觉得这是完全不同的，只是变化在于采用速度之快，这点可能让所有人都感到意外。Sam，如果你不同意也可以补充，但我觉得大家都被这种速度震惊了。
如果回到云计算刚起步的时候，我们花了很长时间去解释“为什么一家卖书的公司会提供算力服务”。在 2006 年，这并不是理所当然的事情，需要大量教育市场的工作。
主持人：不过现在是不是也需要一些解释？比如很多人还停留在“训练时代”，而你们在谈“推理时代”，这本身就是一个转变。
Matt Garman：确实需要，但不同的是，人们理解的速度完全不一样。从“这是个有趣的聊天机器人”，到“它可以在企业里完成实际工作”，确实需要一点教育，但相对于技术发展的速度来说，这个过程已经非常快了。
YC 和云计算同步发展
主持人：我们很快会聊到今天的产品，但 Sam，从初创生态的角度来看，回顾 AWS 带来的变革，它降低了门槛，让任何人都可以开始创业。有种子轮、天使投资，创业门槛被大幅提前。相比之下，今天 AI 带来的变化，有什么相同或不同？
Sam Altman：我认为有四个重要的平台级时刻：互联网、云计算、移动互联网，以及 AI。对我来说，第一个真正亲身经历的是云计算。在 YC 早期，很难夸大云对初创公司的影响。以前创业公司需要租机房、组服务器，这是非常复杂的事情，还要筹很多钱。尽管云计算发生在 YC 开始后不久，我想大概是第二年。
主持人：所以 YC 和云计算其实是同步发展的？我正要问——最终来说，它们真的是比当时你意识到的更加紧密相连吗？
Sam Altman：是的，当时感觉两者是高度同步的。YC 从一开始就在“乘着云计算的浪”。
云计算与 AI：初创公司再次获得加速器
主持人：有了 AWS，创业启动所需的资金大幅降低。
Sam Altman：没错，这是一个巨大的赋能变化。当时 YC 听起来很疯狂，因为大家觉得几万美元不可能支持一家创业公司——光服务器就要这么多钱。但云计算彻底改变了这一点，让小资金也能启动公司。
通常在大的平台变革中，初创公司会占优势，因为它们可以用更快的周期、更少的资本做事情，这是它们击败大公司的经典路径。我职业生涯早期亲眼见证了云计算带来的这种变化，而现在看 AI，也有非常相似的趋势。但正如 Matt 所说，这一次的速度快得惊人。
主持人：相比云计算时代，现在这些既有的大公司，是不是采用 AI 的速度要快得多？
Sam Altman：确实有这种情况，但更让我印象深刻的是初创公司的收入增长速度——我最近在 YC 演讲时问大家：“一个优秀公司在 YC 结束时应该达到怎样的收入水平？”他们说：“这个标准几乎每个月都在变，甚至同一批次的开始和结束答案都不一样。”这种情况以前从未发生过。人们在这个新平台上构建规模化业务的速度，是我前所未见的。
初创公司首选 AWS：大家都习惯了
主持人：Matt，在云计算时代，AWS 基本上是所有初创公司的首选，这给了你们巨大优势。那么今天为什么你们仍然能成为首选？毕竟现在很多人直接基于 OpenAI 的 API 构建，或者你们其实是从另一个角度切入——拥有庞大的既有客户基础，他们在主动要求 AI，而对 Sam 所说的这批新公司反而了解更少？
Matt Garman：我觉得有几个原因。首先，我们对与 OpenAI 的合作非常兴奋，这对很多初创公司都会很有意义。但即便现在你去看，大多数正在扩张的初创公司依然运行在 AWS 上，这背后有很多原因：规模、可用性、安全性、可靠性，以及完整的生态系统——其他软件厂商在 AWS 上，客户也在 AWS 上。
主持人：大家不管愿不愿意，都用过 AWS 控制台，所以也习惯了。
Matt Garman：而且我们会提供帮助。我们投入大量时间支持初创公司，不只是提供云资源额度，还包括系统架构建议、市场进入策略等，这些都很受欢迎。我们始终认为，初创公司是 AWS 的生命线——从一开始就是，现在依然如此。我每个季度都会去硅谷或其他地方，直接和创业者交流，确保我们做的产品真正符合他们的需求。确实，现在竞争比 20 年前更激烈，但这对我们来说依然至关重要，我们也投入了大量精力来满足他们。
主持人：可以这么理解吗——很多直接用 OpenAI API 的公司，通常会用 AWS 来做常规计算，再用 OpenAI 来做 AI？
Matt Garman：是的，这是目前非常常见的一种模式。
AI 的下一阶段：虚拟同事
主持人：那我们聊到今天的发布：Bedrock 托管代理，由 OpenAI 提供模型支持。如果我理解没错，这并不是简单地把 OpenAI 模型放进 AWS（我猜这也不被允许），而是把 OpenAI 的前沿模型封装进一个 AWS 原生的 Agent 运行环境，包括身份管理、权限、日志、治理和部署。Sam，这样描述对吗？
Sam Altman：描述得很好。
主持人：那这到底是什么？用更通俗的话解释一下。
Sam Altman：我认为 AI 的下一阶段，是从“输入文本得到文本”，甚至“输入代码得到代码”，转向“在公司内部运行的智能代理，完成各种工作”。
“虚拟同事”可能是目前最接近的说法，但还没有人找到一个真正准确的词。我们正在一起打造一个新产品，帮助企业构建这种有状态的代理，并让它们投入使用。我们还不完全确定未来人们会怎么称呼或使用它，但如果你看看像 Codex 这样的产品，就能大致看到发展方向。
模型和 harness 越来越融合，
预训练和后训练的界限逐渐模糊
主持人：模型之外的那一层——harness、工具、状态（你很强调这个词）、记忆、权限、评估，对 Agent 真正发挥作用有多重要？
Sam Altman：重要性怎么强调都不为过。我现在已经不再把“harness”和“模型”看成完全可以分离的东西。比如我用 Codex 时，有时候它帮我完成了一个很厉害的任务，但我其实并不清楚——
主持人：到底是模型厉害，还是harness厉害？
Sam Altman：对，就是这个问题。
主持人：那这个harness和模型的协同是怎么实现的？是在后训练阶段？提示词？还是其他方式？
Sam Altman：两者都有。它不太属于预训练的一部分，但更有意思的是，我们已经多次看到，原本被认为可以分离的东西，逐渐被更紧密地整合在一起。比如最初的工具调用，一开始并没有被深度整合进训练过程，但后来我们越来越多地把它融入进去。
我也认为，模型和 harness 未来会越来越融合；同样，预训练和后训练之间的界限也会逐渐模糊。这听起来有点老生常谈，但确实如此——我们还处在一个非常早期的阶段，就像当年的 Homebrew Computer Club 一样，整个行业还远未成熟。
备注：家酿计算机俱乐部是一个计算机业余爱好者组成的俱乐部，于1975年3月5日在一个车库内成立，由弗莱德·莫尔与戈登·弗伦奇发起。
主持人：这正是我觉得有意思的地方。我几周前写过，在任何价值链中，最终都会出现一个关键的整合点——两个部分必须紧密结合才能真正发挥作用，而价值也会集中在那里。我当时的观点是，“模型+harness”的整合就是这个关键点。这显然符合你的利益，但听起来你也认同。
Sam Altman：这当然符合我的利益，我也确实认同。但更广泛地说，用户真正关心的是——你在 Codex 里输入你想要的结果，它就真的能实现。
从“榨取价值”到“开箱即用”：OpenAI+AWS
主持人：你不在乎实现细节。
Sam Altman：我不这么认为。在我们逐渐弄清楚这一切的过程中，已经有很多例子表明我们不得不在系统提示层面做一些事情，而后来又没有做。这里的普遍观察是，随着模型变得越来越聪明，你就有更多的灵活性来让它们按照你想要的方式行事，这听起来像是一个显而易见的事实，但它——
主持人：就像教一个 10 岁的小孩，比教一个 5 岁的小孩更容易。
Sam Altman：没错。回想 GPT-3 时代，我们为了从模型里榨出一点点实用价值，需要做很多复杂操作，而现在模型开箱即用就能理解并很好地执行任务，这种趋势可能还会继续发展很长一段时间。
Matt Garman：我补充一点——我完全同意。当你和客户交流时，他们其实很清楚自己想让这些系统做什么。但在我们这次合作之前，客户基本被迫自己去把这些东西拼起来。他们希望模型和 Agent 能记住彼此的协作方式，能接入他们现有系统，而且不仅是第三方工具，还包括他们自己的工具。他们希望系统能理解自己的数据、应用和运行环境，而这些集成工作目前几乎都要每个客户自己完成。
我们这次合作的核心，就是共同打造一种新产品，把这些要素更紧密地整合在一起，让客户更容易实现目标。比如身份体系已经内置在产品里，访问数据库的认证也可以在 AWS 的虚拟私有云内部完成。很多事情以前当然也能通过 OpenAI API + AWS 各自实现，但通过这种联合构建，我们可以大幅降低复杂度，让客户更快获得价值，在企业环境中完成他们想做的事情。
合作原因：让 Agent 简单好用
主持人：所以你的意思是，在通用框架中构建一个功能齐全的Agent会更困难？还是说你会让它变得更容易？或者有没有可能，如果你不把它们整合在一起，甚至根本无法做任何事？
Sam Altman：可以用你之前的类比来理解。在 AWS 出现之前，你也可以自己买服务器、搭网络、雇工程师，一样能做很多事情。但一旦你只需要登录 AWS 控制台，点一下“我要一个 S3 实例”，很多事情就变得容易得多。基础工作的“启动成本”大幅下降，你就能做更多事情。
现在用模型也是类似。每次我看到有人用我们的模型，或者尝试搭建 Matt 说的这些系统，我一方面很高兴他们觉得这像魔法一样，另一方面又很抓狂——因为他们为了让东西“能跑起来”经历了太多痛苦。这不仅发生在开发者身上，普通用户用 ChatGPT 时也是这样：不断复制粘贴、拼接复杂提示词。我知道这些都会消失，我对此非常期待。但现在还太早，也还很原始。
主持人：只要别把你们和 BBEdit 的集成功能删掉就行，这是我最大的请求，也是 ChatGPT 应用我最喜欢的功能。
Sam Altman：好吧。
主持人：谢谢。
Sam Altman：总结来说，第一，这些东西现在太难做了，如果我们能把它变简单，就能为开发者和企业创造更多价值；第二，还有很多事情是目前根本无法可靠实现的。我认为通过这次合作，不仅仅是“更易用”，我们还会一起探索出一些全新的能力，让人们构建出以前即使付出巨大代价也做不到的产品和服务。
Agent 本地运行并非最终形态
主持人：我想稍后再回到要构建的事情这个话题。但先说回 Codex——它是模型+harness的结合，而且是本地运行的。为什么现在在本地更容易让 Agent 工作？
Sam Altman：其实我们一开始是让它跑在云上的，而且我认为最终你确实希望它在云中运行。
主持人：当然。我正在经历向这项云服务的过渡，但为什么你又回到了本地？
Sam Altman：因为你的整个环境都在本地——电脑已经配置好了，数据也在那里，不需要额外考虑太多事情，所以更容易跑起来，尽管这不是最终形态。但未来显然会发展到：Agent 运行在云上，当你有高强度任务、或者关掉电脑时，可以把工作交给云端继续执行。这会非常好。不过在短期内，本地环境带来的易用性更重要。
本地和云端：建立一个跨越的桥梁
主持人：我有个类比：传统安全模型像“城堡+护城河”，而现在在向“零信任”转变——每个系统都有独立权限和认证机制。从这个角度看，本地运行就像一个“自建的城堡”，一切都在里面，默认简单安全。但如果要在生产环境中真正运行这些 Agent，似乎就必须一开始就在云端环境里构建。这样理解对吗？
Matt Garman：我不认为有任何计算模式完全摆脱了客户端。本地运行有其优势，比如连接性、延迟、本地算力，以及访问文件和应用的能力。就像大多数 iPhone 应用也都有本地组件一样。本地客户端确实有其特点，正如 Sam 所说，它简单易用，效果很好，但同时也受限于一定的范围。
比如你无法扩展你的笔记本算力；在企业环境中，多人协作、权限管理、安全边界都会变复杂。所以我不会说本地不好，只是它和云是不同的形态。最终你会需要一个跨越两者的“桥梁”。
区分人和Agent：
最终我们需要的是一种全新的机制
主持人：这正是我的问题。在云计算时代，我们用容器把本地和生产环境统一。但现在如果是 Agent——比如一个“虚拟同事”，它有自己的身份、权限等——那你在构建它时，似乎就必须在和部署环境一致的体系中完成。
Sam Altman：这里还有太多问题需要解决。举个例子，如果你是公司员工，你使用某个服务时是用一个账户，那你的 Agent 应该用你的账户，还是用一个独立账户，让系统能区分“人”和“Agent”？
主持人：如果你有很多 Agent 呢？
Sam Altman：对，这就更复杂了。我猜最终我们需要的是一种全新的机制，比如“某个 Agent 以你的身份登录，但系统会标记它是 Agent 而不是真人”。但目前我们甚至还没有这样的基础概念。未来很快我们就需要解决这个问题，而且类似的问题还会有很多。随着 Agent 逐渐进入职场，承担越来越自主、复杂的任务，我们现在关于软件运作方式、访问控制、权限体系的很多认知，都需要被重新定义和演进。
企业的安全问题可以被解决
主持人：Matt，从安全性、访问控制这些角度来看，你们是怎么思考 Agent 的？
Matt Garman：我确实认为，当你把更多工作负载迁移到云上时，可以由一个中心化的组织来对安全进行更多控制
。而且我们和客户沟通时，他们最担心的就是：“我很喜欢这些强大模型和 Agent 带来的潜力，但我怎么确保不会因为用错而导致公司级灾难？”这种担忧是普遍存在的。
但这些问题是可以解决的。比如，你可以让系统运行在自己的 VPC（虚拟私有云）中，从而清楚它能访问什么；或者通过网关控制权限，就像你给企业内部系统分配角色一样。这些能力是过去 20 年逐步建立起来的——不仅是初创公司在用 AWS，全球银行、医疗机构、政府都在用。正是这些成熟的安全体系，能帮助客户更放心地加速采用这项技术，同时保持必要的防护。
很多企业，尤其是风险厌恶型组织，一旦有了明确的安全边界，比如“只要它在沙箱里运行，我就可以放心加速”，反而会更愿意大规模尝试这些新技术。
Bedrock 托管代理是
建立在 AgentCore 基础之上的产品
主持人：你提到的这些能力，其实已经通过 AgentCore 对外提供了。那么，Bedrock 托管代理（由 OpenAI 提供模型支持）和 Bedrock AgentCore 之间是什么关系？
Matt Garman：我们这次一起构建的产品，本质上是建立在 AgentCore 这些基础组件之上的，把这些能力整合在一起。
主持人：所以那上面是不是有一个超级套件？
Matt Garman：可以这么理解。AWS 和 OpenAI 团队一起，把 AgentCore 的组件、OpenAI 的模型，以及其他能力组合起来，共同构建了这个产品。
Matt Garman：AgentCore 本质上是一套“原语”，就像 AWS 早期那样，如果你想自己构建 Agent 工作流，可以用它：你可以配置记忆模块、安全执行环境、权限系统等。目前已经有客户在生产环境中用这些能力做出很酷的东西。
主持人：但不是用 OpenAI 模型？
Matt Garman：但与 OpenAI 不同，他们今天必须使用不同的模型，这是真的。实际上，这不是真的，我们有人正在使用 OpenAI 来做这件事。
主持人：哦，只是调用另一个云或其他什么。
Matt Garman：严格说，也有人在用——只是他们是直接调用 OpenAI 的 API，而不是在 Bedrock 内部原生集成。所以这是一个开放生态，你可以自由组合各种能力来构建系统。我认为这种方式会长期存在，就像就像 Sam 的比喻一样，今天仍然有人喜欢自己“组装电脑”一样。
我们认为人们很长一段时间都会自己构建智能Agent，但大多数用户还是会希望有更简单的方式，不需要自己去配置所有组件，这也是我们这次合作推出的部分内容。
Bedrock 托管代理：AWS 与 OpenAI 的独家联合产品
主持人：我确认一下——Bedrock 托管代理是一种“托管体验”；而 AgentCore 则更底层，你可以自己选模型（无论在 AWS 还是其他地方）。Sam，这和你们在 Azure 上提供的 OpenAI API 是不同的，对吗？
Sam Altman：对，是这样的。
主持人：你对这种划分很有信心？未来不会有冲突？
Sam Altman：我认为未来肯定会演进，但作为一个起点，这种方式我非常满意。
主持人：这是 AWS 独家的合作吗？还是未来会扩展到其他云？
Sam Altman：目前我们是和亚马逊独家合作，我们对此很期待。
主持人：这种“独家”是因为用到了 AWS 的 API，还是说这种托管模式本身暂时只会在 AWS 上？
Sam Altman：从理念上讲，这是我们两家公司共同打造的产品。
主持人：明白了。那关于数据——你刚才提到，客户也可以自己调用 API 拼接系统。但在这个托管方案中，数据是留在 AWS 内部的，那么 OpenAI 具体能看到什么，这意味着什么？
Matt Garman：是的。整个系统都运行在你的 VPC 中，数据会被保护在 Bedrock 环境内。
主持人：那这些 OpenAI 模型是在 Bedrock 上运行，对吗？会用到 Trainium 吗？
Matt Garman：会是混合架构——一部分用 Trainium，一部分用 GPU。
备注：Trainium 是 AWS 自主研发的 AI 训练和推理芯片，专为机器学习和深度学习工作负载设计，旨在提供高性能和成本效益。
主持人：这是时间问题，还是能力问题？
Matt Garman：两者都有。我们会根据不同任务选择合适的基础设施，但长期来看，会有越来越多的工作运行在 Trainium 上。
Sam Altman：我们也非常期待让模型运行在 Trainium 上。
主持人：我可以想象。
Trainium：既支持训练也支持推理，用户无需关心底层
主持人：聊一下 Trainium。它这个名字其实不太准确——未来更多是做推理而不是训练，对吗？而且用户通常是通过像 Bedrock 这样的托管服务来使用，甚至都不知道底层用的是什么算力，这样理解对吗？
Matt Garman：首先，AWS 的命名问题我负责。
主持人：我有一个名为 Stratechery 的口碑网站，所以我完全理解糟糕的命名。
Sam Altman：我觉得 Trainium 这个名字挺酷的。
Matt Garman：确实挺酷的。
主持人：这是一个很酷的词，感觉它更像是推理芯片，而不是训练芯片。
Matt Garman：不过不管名字，它既适用于训练也适用于推理。而且我们对这款芯片非常有信心，无论是当前版本还是未来版本，它都会成为一个重要业务，并推动很多合作场景的发展。
其实就像 GPU 一样，大多数用户不会直接操作这些硬件，而是通过抽象层来使用。比如你调用 OpenAI，哪怕底层是 GPU，你也不会直接接触 GPU。同样，不管是 GPU、Trainium 还是 TPU，你接触的都是接口，而不是芯片本身。
未来也会如此。真正直接编程这些硬件的人非常少，因为系统太复杂、规模太大。训练模型需要巨大的资金和专业能力，并不是很多团队能做到。像 OpenAI 这样的团队非常擅长从大规模算力中榨取价值，但这种能力并不普遍。因此，对所有加速芯片来说，抽象层都会是主流。
Sam：我们不是 token 工厂，而是“智能工厂”
Sam Altman：Ben，我越来越觉得我们公司的本质是一个“token 工厂”。但客户真正关心的是：我们能以最低成本，提供最高质量的“智能单位”，而且要有足够的规模和供给能力。
主持人：你觉得未来还会继续用“按 token 计费”这种模式吗？长期来看合理吗？
Sam Altman：我认为不会。其实有个很有意思的例子——我们刚发布的 5.5 模型，单个 token 的价格比 5.4 更高，但完成同样任务所需的 token 数量却大幅减少。用户根本不关心用了多少 token，他们只关心事情有没有完成，以及对应的价格和可用的算力。
所以也许我说“token 工厂”并不准确，我们更像是一个“智能工厂”。我们只想用最低成本提供尽可能多的“智能单位”。至于这是通过更大的模型、较少的 token，还是更小的模型、更多的 token，或者是 GPU、Trainium，甚至其他方式实现，用户其实并不关心。
事实上，用户根本不会接触这些。当你在 Codex 里输入需求，或者在一个有状态运行环境里构建 Agent 时，你不应该需要思考这些细节，只会惊讶于“为什么这么便宜却能做这么多事”。
token 减少主要靠模型进步，harness 只是辅助
主持人：那 token 使用减少，主要是模型的功劳，还是 harness？
Sam Altman：主要是模型，harness也有一点贡献。
主持人：Matt，我也问 Sam 一个类似的问题——你们未来会不会为其他模型提供类似的托管服务？
Matt Garman：目前我们专注于和 OpenAI 的合作，对正在做的事情非常兴奋。至于未来，时间还很长。
主持人：好吧，这个回答很官方，我理解。
只要价格足够低，对“智能”的需求几乎是无限的
主持人：聊聊客户需求。Sam，从用户角度来看，当系统真正上线运行时，OpenAI 和 AWS 的责任如何划分？如果数据都在 AWS 里，并且系统运行在更高层，是不是 AWS 需要承担主要责任？
Matt Garman：可以这么理解。当客户需要支持时，会联系 AWS 支持团队，这是 AWS 环境的一部分，你的客户经理也会协助你。如果在构建过程中需要 OpenAI 的帮助，我们也会一起参与。如果遇到需要他们解决的问题，我们会升级给他们处理。但对客户来说，AWS 是一线支持。
主持人：Sam，从规模来看，这块业务相对于你们核心 API 业务会有多大？
Sam Altman：我希望它会非常大。我们在这上面投入了很多资源，也承诺会购买大量算力，我相信它会产生可观收入来支撑这一切。我越来越觉得，只要价格足够低，对“智能”的需求几乎是无限的。
主持人：所以它的需求弹性很大？价格下降，需求就上升？
Sam Altman：确实如此，但再次强调，你可以降低水的价格，也许你会多喝一点水，也许你会从每天洗一次澡增加到每天洗两次，这里存在一定的弹性，但总会有一个时刻你会说，“你知道的，我已经足够的水了”。
主持人：如果你必须购买，无论水价多高，你都会买水。
Sam Altman：其他公用事业，如果电价更便宜，你当然会使用更多，但如果你将智能视为一种公用事业，我所知道的其他公用事业中，我总是想：“我只需要更多，只要价格足够低，我就用更多”。
Matt Garman：不过从另一个角度看，算力其实也是类似的。如果你看今天的计算成本和 30 年前相比，已经低了不知道多少个数量级，但现在的计算需求反而更大。
AI也会走计算机的路径：
成本并非首要问题，需求集中于最前沿模型
主持人：确实，人们通常不会特别去考虑算力成本，除非到了非常高的规模。那 AI 还需要多久，才能达到这种“不再纠结成本”的阶段？
Sam Altman：我觉得现在成本已经不是首要问题了。现在更多客户在问的是：“不管多少钱，你能不能给我更多？我需要更多算力，我愿意多付钱。”
当然，我们仍然会持续大幅降低成本。而一个有趣的现象是，目前市场上有相当多的需求集中在最前沿的模型上，这一点有点出乎我意料。我还不确定这种情况会不会持续。
主持人：对，这点很有争议。前沿模型成本很高，但用户似乎还是愿意用最先进的，而不是上一代。
Sam Altman：目前确实如此。
Matt Garman：这其实说明我们离最终目标还很远，需求还有巨大空间。就像 40 年前的计算机一样，当时非常昂贵，而现在每个人手机里的算力都远超当年，而且我们卖出了数十亿台设备。我认为 AI 也会走类似的路径。
未来会出现多层次模型：一些更小、更便宜、更快的模型，甚至能完成今天顶级模型还做不到的任务；同时也会有超大模型，用于攻克像癌症这样的难题。但现在我们还处在非常早期阶段。当你在这么早期阶段就看到如此巨大的需求和增长，这对未来来说是非常令人兴奋的。
我们已经接近一种全新的计算范式
主持人：有没有一种更“现实”的解读：Sam，你有很多客户想用 OpenAI，但他们的数据都在 AWS，不愿迁移；Matt，你这边的客户也在说“我们都在 AWS，能不能直接用 OpenAI 模型？”于是你们合作满足了这个需求，而且因为 AWS 体量最大，这个需求本身就非常巨大。是不是这就是最简单的答案？还是说你们确实认为，这种合作能带来差异化价值，甚至吸引新的客户？
Sam Altman：我们当然非常高兴能接触到 AWS 的客户，确实有很多人喜欢 AWS。这一点是真的。
Matt Garman：这一点确实完全正确。反过来也一样，我们的客户也非常期待能够用上 OpenAI 的技术。
Sam Altman：但我确实认为，我们一起在构建一些全新而重要的东西。我希望一年后大家回头看这件事时，讨论的重点不会只是“终于可以在 AWS 上用这些模型了”，而是会说：“我们当时没有意识到，这个新产品有多重要。”我觉得，在模型能力、运行环境以及整体能力层面，我们已经接近一种全新的计算范式，这会和过去“我需要一个模型 API”这种思路完全不同。
Matt Garman：我完全同意。第一点当然很好，但第二点才是我们真正兴奋的地方。
AI 技术栈需要中间层，但可能只是过渡结构
主持人：说到这里，我之前提到想回到一个问题。我有个假设，不一定对——在未来的 AI 技术栈中，可能会出现一个关键的“中间层”：底下是各种数据库、SaaS 应用和企业数据，上面是 Agent 或运行环境，而中间还需要一层来打通这些系统。OpenAI Frontier 似乎已经在触及这一点。这是你们正在做的事情吗？还是一个尚未被构建的机会？
Sam Altman：你说得完全对，这一层是需要的。我最近和很多大型企业客户交流，他们的需求其实很一致：他们想要一个 Agent 运行环境，一个管理层，能够把数据接入 Agent，同时还能监控 token 消耗和成本，还希望有一个类似工作空间的界面——最好是像 Codex 那样——给员工使用。现在这些需求已经非常统一，但真正把这一整套产品做出来，还有很多工作要做。
主持人：听起来甚至需要“双层 Agent”：一层在中间持续连接和探索各种数据源，另一层是用户交互界面。这个理解对吗？
Sam Altman：在当前阶段，我同意这是一个合理的结构。但随着模型越来越智能，我们还不知道未来的架构会长什么样。
现在在用户层面，人们确实希望能和多个 Agent 交互，让不同 Agent 之间协作；在企业管理层面，也需要各种控制机制，去管理 AI 如何访问文件系统等。但到某个阶段，你会发现这些结构可能只是“历史包袱”，其实应该直接融入模型本身。
未来的系统可能会重构
主持人：而且某个时刻你会意识到，你毫无理由地坚持着过去，这应该只是模型中的一部分。也就是说，未来可能会整体重构？
Sam Altman：对，到了某个时候，我们可能会说：“既然能力已经这么强了，那就重新设计整个系统架构。”
Matt Garman：我也同意。我觉得一定会出现一些新的形态，但现在我们还不知道具体是什么。这也是有意思的地方——让客户去尝试、去构建，然后我们从中学习，再去让产品变得更简单、更快、更好。
挑战Google的表现很好：
ChatGPT是自Facebook以来第一个大规模新消费级产品
主持人：Sam，这是我们第二次做这种产品发布采访了。上一次是和 Kevin Scott 一起聊 New Bing，当时你对挑战 Google 很有信心。现在回头看，你觉得结果如何？
备注：Kevin Scott，微软公司首席技术官兼人工智能执行副总裁。
Sam Altman：我觉得我们做得比预期更好。ChatGPT 可能是自 Facebook 以来，第一个真正大规模的新消费级产品。
主持人：也就是说，你们确实超出预期，但主要体现在 ChatGPT，而不是其他方向？
Sam Altman：不完全是。我们的 API 业务也做得很好，尤其是 Codex，但当时我并没有预料到这一点。当时我更关注的是，这种新的语言界面是否会改变人们在互联网上获取信息的方式。
而且 Google 依然是一家非常强大的公司，它在很多方面仍然被低估。不过总体来说，我对 ChatGPT 的表现是满意的。
Google 和 AWS 的两条路线：全栈整合和平台
主持人：Matt，我也想问你一个类似的问题。最近 Google 的 Thomas Kurian 提到他们的“全栈整合”——从芯片到模型再到 Agent 全部打通。而你们现在是和另一家公司合作，并不是完全垂直整合。过去有人批评 AWS 没有最前沿模型，但现在进入推理时代，你们本来就擅长服务企业客户。是不是某种程度上，这种“中立性”反而让你们处在更好的位置？这是策略，还是意外？
备注：Thomas Kurian，
1996年加入甲骨文，2015年出任产品开发总裁；2018年11月起担任谷歌云首席执行官， 任期内主导混合云战略转型，提出“多云即未来”理念。
Matt Garman：某种程度上是有意为之。从 AWS 创立开始，我们就一直把合作伙伴视为核心战略的一部分。我们的理念是：合作伙伴成功，我们就成功。
我们更倾向于“做大蛋糕”，而不是试图独占一切。当然，有些公司会选择“全部自己做”，那也是一种路径。但我们认为，让客户自由选择最适合他们的产品更重要。如果客户选择我们自己的产品，那很好；如果他们选择合作伙伴的产品，但运行在 AWS 上，我们也认为这是成功。
这种理念也体现在 Bedrock 平台上——我们希望支持多种模型、多种能力。这种开放策略一直贯穿于数据库、计算平台等各个层面。我们认为客户很认可这种方式，我们也会继续坚持。
越往上层走，选择就越多
主持人：确实很有意思。从软件、平台到基础设施，各家公司都说要服务所有人。但 AWS 是从基础设施起步的，这似乎让你们有更大的灵活性去和 Sam 这样的公司在中间层合作——他提供软件，你们一起构建平台。
Matt Garman：是的。不过也有一些例外，比如像 S3 这样的基础设施组件，我们是唯一提供方。但越往上层走，选择就越多。我们认为，不可能有一家公司掌控所有应用，而在模型和服务层，参与者会更多；在基础设施层，反而更少。我们的策略就是拥抱整个生态，这对客户是最有利的。
主持人：Sam，最后有什么想说的吗？
Sam Altman：我觉得 Matt 说得很好。我确实认为，现在开发者能够构建的新一代产品潜力巨大。考虑到未来一年模型能力会快速提升，我们现在一起构建这样一个平台，时机非常合适，我相信大家会喜欢。
主持人：很好。Matt、Sam，感谢你们做客 Stratechery。
Matt Garman：谢谢邀请。
Sam Altman：谢谢。
参考链接：
https://x.com/mattsgarman/status/2049219365279764824?s=20
——好文推荐——
Token效率国内第一！MiMo-V2.5 Pro登顶开源Agent王者；罗福莉：OpenClaw是巨大分水岭，模型与Harness需同步演进，MLA不符合Agent范式
OpenAI下场造手机？高通股价已暴涨！Sam：现在的硬件配不上AI！前苹果CEO：OpenAI是库克时代以来最大的竞争对手
DeepSeek太狠了，两天连砍两次价！百万Token输入只要0.025元！同行都看懵了！网友：国产模型+国产算力就是这么牛！
