CoreWeave：AI 基础设施不能只是云上的 GPU
AI 应用越来越复杂，基础设施也不能停留在「给传统云加一块 GPU」。Practical AI 对谈 CoreWeave 高级产品副总裁 Corey Sanders，讨论训练与推理的不同负载、GPU 集群里的慢节点、AI 研究循环、Agent 驱动的开发体验、多云部署，以及企业为什么最终都会建立自己的 AI 工程团队。1
这期先看什么
- 训练需要大规模、深度互联的 GPU 集群，硬件布局、网络、存储、故障观测和任务编排必须一起设计。
- 推理应用不再只是「一个问题交给一个前沿模型」，而是多个模型、多个 Agent 和多条推理路径的组合。模型、提示词、参数、缓存和成本要放进同一条持续迭代的循环里。
- CoreWeave 的产品判断是，把研究、评估、部署和优化放在尽可能顺手的工作流里，同时保留多云和跨云能力。
- Corey Sanders 预计，未来五到七年，企业会普遍拥有 AI 工程团队，今天以网页和按钮为中心的软件体验会逐渐变成遗留形态。这个时间判断属于嘉宾预测，不是已发生事实。
嘉宾卡
Corey Sanders 是 CoreWeave 高级产品副总裁。按照他在节目中的自述，他在微软工作超过 20 年，参与过 Azure 早期建设；加入 CoreWeave 后，他开始从 AI 专用基础设施的角度重新审视公有云时代形成的默认做法。1
节目官方单集页提供了 Corey Sanders 的真人头像和 LinkedIn 入口，节目 show notes 将他列为 CoreWeave 的 SVP of Product。2
按原始节目顺序整理
1. AI 应用会像云应用一样扩张，但基础设施不能照搬旧模型
Corey Sanders 先把自己的经历放回云计算的早期。他在微软待了二十多年，参与 Azure 早期建设。现在进入 CoreWeave，他看到的相似点是：AI 应用也会从少数明确场景开始，逐步扩展到更多应用、服务和工作流。1
区别在于，AI 不只是传统软件里的一个附加功能。随着应用越来越依赖模型、推理和 Agent，平台本身要为 AI 的数据、算力、网络、存储、编排和开发循环服务。把 AI 概念硬套进旧的应用开发方式，反而可能拖慢团队。
2. 训练负载：昂贵、成批、深度互联
Corey 把 AI 的基础工作分成训练和推理两条路径。训练是创建模型权重，需要大量 GPU 一起工作。训练集群不是「有空位就放几台机器」那么简单，GPU、网络和存储必须高度互联，才能让任务持续推进。1
传统公有云的一项优势，是资源可以商品化、通用化。某个地区需要更多计算，可以迅速增加计算；需要更多存储，也可以单独扩容。但 AI 训练往往要提前规划，因为 GPU 之间需要专用互联，存储和部署方式也要围绕训练任务设计。Corey 提到的网络例子包括 InfiniBand 和 RoCE，这种连接方式与普通云计算机架的要求不同。
训练过程里的浪费也不只来自 GPU 彻底坏掉。存储装载变慢、某个节点速度下降、任务调度不合适、编排器不知道底层正在发生什么，都可能让昂贵的 GPU 没有被充分利用。AI 专用平台的工作，就是把观测和编排一直做到硬件层附近，再把它们接回任务层。
3. 最大的坑可能是一块悄悄变慢的 GPU
当一个任务使用数百、数千甚至数万块 GPU 时，找出直接失效的设备已经不容易，找出「还在运行但速度变慢」的设备更难。一个慢 GPU 可能只表现为任务整体变慢，研究者却很难第一时间知道到底是哪一块设备出了问题。1
CoreWeave 在节目中提到 GPU straggler detection，也就是 GPU 慢节点检测。它要识别硬故障和软故障：前者是节点或设备直接停摆，后者是设备仍然工作，却悄悄降低吞吐。对大规模训练来说，后一类故障同样会把时间和成本推高。
4. 经验能帮你看见问题，也会带来旧假设
Corey 说，自己在微软最后几年开始接触 AI 基础设施时，逐渐看到旧云模型的边界。过去，云平台可以预留空间和电力，需求出现后再快速部署通用计算和存储。AI 集群则更像提前设计好的整体系统，不能等任务启动后才临时拼装。
他也提醒，云计算经验并不自动等于 AI 基础设施经验。一个人可能会把「过去十年这样做有效」当成默认前提，却忘了问数据规模、容器镜像、网络、存储缓存和创新节奏是否已经改变。Corey 把这归结为一个很实际的问题：过去让你走到今天的方法，不一定能带你走到下一波。
他的做法是持续追问「如果这里不一样呢」，也招聘那些会挑战自己基线的人。对他来说，创新往往先从一个不舒服但有用的问题开始：为什么还要按通用云的方式处理 AI？
5. AI 研究会从手工比较图表，走向 Agent 辅助迭代
模型研究本来就需要大量实验：改变参数、数据、控制变量，记录每次输出，再决定下一轮实验。Weights & Biases 负责实验记录、追踪和比较，但「看完实验后下一步该做什么」仍然依赖大量经验。1
CoreWeave 在节目中介绍了 ARIA，完整名称是 AI Research and Iteration Agent。它的目标是持续分析正在运行的实验，并帮助研究者判断下一步的实验方向。
Corey 对工作方式的描述很具体：研究者告诉 Agent 想改善模型的哪项表现，Agent 发起实验；实验可能在夜间运行，第二天返回结果，说明哪些方案有效、哪些没有，接着建议再跑一轮。研究者仍然负责判断「这个方向值不值得试」，但不必再手工打开控制台、比较多条折线、逐项寻找异常。
6. 推理应用会由多个模型和 Agent 组成
Corey 不把「Agentic」单独看成一种与应用无关的潮流。在他的表述里，核心还是 AI-centric application，也就是从一开始就围绕 AI 能力构建的应用。Agent 只是其中一种形态，背后都要调用模型、执行推理、分析结果或完成某个具体动作。1
他把应用区分为两类。第一类是面向内部生产力的工具，例如 Copilot。第二类是业务关键或面向外部客户的应用，例如药企的基因折叠工作流。后一类不会永远是「把一个问题发给一个前沿模型，然后返回一个答案」，而会由多个模型、多个 Agent 和多次推理调用组成。
复杂分析可以交给能力更强的模型，翻译、分类等任务则可能由更小、更便宜的模型完成。基因折叠这类专门问题，也可能需要专用模型。把所有问题都交给最大的通用模型，就像拿大锤处理每一颗螺丝，能做，但未必快、便宜或合适。
7. AI loop：每次生产请求都能反过来改进应用
AI 应用的开发不会在第一次上线时结束。生产 traces 会暴露具体问题：某类问题回答慢、某条路径成本高、某个模型的准确率不够、某种提示词会把 Agent 引向错误方向。团队可以更换模型、调整提示词、设置评估、检查价格，再决定是否微调或进行强化学习。1
Corey 把这称为 AI loop。理想状态下，开发者可以在同一条工作流里完成 traces、评估、模型注册、版本追踪、实验和部署。模型、参数和提示词的变化都留下 lineage，团队能知道「昨天的版本为什么更好」以及「哪一次修改已经进入生产」。
这套循环的意义不在于把所有人都变成模型研究员，而在于减少无效试错。Agent 可以指出「先换模型可能就够了」，而不是让团队直接投入一次昂贵的微调。
8. 优化不必以牺牲多云为代价
Corey 明确说，CoreWeave 不会是客户唯一使用的云。客户可能已经有喜欢的评估服务，也可能把训练放在别处、只把推理放到 CoreWeave，或者反过来。1
他举了 Sunk 的例子。Sunk 是 Slurm on Kubernetes，把 Slurm 的作业调度能力和 Kubernetes 的基础设施编排能力放在一起。Slurm 在研究型负载里有很强的认知度，Kubernetes 则擅长处理基础设施的生命周期和故障。两者结合后，研究者可以保留熟悉的作业调度方式，同时获得更强的编排能力。
节目还提到 Sunk Anywhere，可以把这套能力部署到其它云。Corey 用「Lock-in with love」来形容这种策略：不是靠封闭接口留住客户，而是让开放的跨云服务足够好用，让客户愿意继续使用。
9. 更低成本的关键，是减少无效试错
面对前沿研究的高算力成本，Corey 给出的方向不是只讨论单价，而是让同样的资源完成更多工作，或者用更少资源完成同一件事。1
具体路径包括：选择足够完成任务的小模型，缩小模型体量，优化提示词，减少从实验走到生产的时间，以及让 Agent 帮助判断是否真的需要微调或强化学习。更快找到能产生业务价值的版本，也是在降低成本。
他认为，前沿实验室仍然处于最前线，历史经验未必能直接帮助它们。但对大多数企业来说，它们通常落后前沿实验室一步。把硬件层的优化和 AI loop 结合起来，可以让这些企业以更低的门槛追上可用的能力。
10. 机器人需要看见动作，而不只是看见分数
在机器人、工业和制造场景里，CoreWeave 正在把实验追踪从折线图扩展到视觉结果。研究者不只看成功率变化，还能直接看到机器人如何移动，比较不同实验里动作哪里出了问题。1
再加上 ARIA 一类的 Agent，机器人训练也可以进入「观察动作、找出失败原因、提出下一轮实验」的循环。CoreWeave 还提到与 Monolith 的合作和收购后带来的工业、制造业经验，以及 Direct to Expert 这类让工程团队直接和客户讨论具体场景的方式。
由于部分服务以 Kubernetes operator 的形式提供，缓存、编排、Weights & Biases 等能力也可以延伸到其它云、边缘和本地环境。这里的重点仍然是让基础设施适应工作负载，而不是让客户把所有东西搬进一个封闭盒子。
11. 五到七年后，网站按钮可能变成遗留体验
Corey 最后的预测，是 AI 会沿着公有云走过的路径发展，但速度更快。公有云早期只是「点击按钮、点击按钮、点击按钮」，后来却支撑起云端播客、流媒体和大型在线体验。AI 也会从「我向 Agent 提问」继续往前走，变成能理解人的目标、环境和反应的交互系统。1
他的判断是，五到七年后，今天依赖网页、按钮和固定控制台的体验可能会显得过时。企业会建立自己的 AI 工程团队，但在人才和前沿研究能力补齐之前，基础设施公司需要把这些能力做成更多企业接得上、用得起的服务。
这个预测最值得注意的地方，不是具体年份是否准确，而是它把基础设施问题和产品形态放在了同一张图上：当应用从「点击一个按钮」变成「告诉系统目标，再由 Agent 运行、解释和迭代」，底层平台就不再只是提供机器，而是在提供一整条工作循环。
逐句全文翻译
以下译文基于本期官方完整逐字稿，按原始顺序保留旁白、主持人、嘉宾和广告段落，不保留英文原文。产品名、公司名、技术名词和人名保留其正式写法。1
00:01
旁白：欢迎收听 Practical AI 播客。我们会拆解人工智能在现实世界中的应用，以及它正在怎样影响我们的生活、工作和创造方式。我们的目标，是让 AI 技术变得实用、高效，并且人人都能接触。不论你是开发者、商业领袖，还是只是对这股热潮背后的技术感到好奇，这里都适合你。欢迎在 LinkedIn、X 或 Blue Sky 上关注我们，及时了解节目更新、幕后内容和 AI 洞察。你可以在 practicalai.fm 了解更多信息。
00:35
旁白：现在进入节目。
00:42
Chris：欢迎来到新一期 Practical AI。我们是一档努力让 AI 变得实用、高效、人人都能理解的播客。我们有机会和行业里各种各样很酷的人交谈。今天我要向大家介绍 Corey Sanders，他是 CoreWeave 的高级产品副总裁。最近我们经常在新闻里看到 CoreWeave，也很期待了解更多：CoreWeave 解决了哪些问题，它在 AI 世界里承担着什么位置。欢迎来到节目，Corey。
01:14
Corey：谢谢你邀请我，Chris。我本来想说，你会和各种各样很酷的人聊天，但今天你只能被迫和我待在一起了，所以我们开始吧。
01:19
Chris：不，不是这样的。我要说，你的经历真的很有意思。现在事情变化得太快了，而你在加入 CoreWeave 之前长期待在微软，看过云计算版图的很多变化。我想不出还有谁比你更适合讨论这些问题：你在 Azure 做过的事情，以及现在来到一个有些不同的问题空间。我们先从这里开始吧。你感兴趣的到底是什么问题？请从你所在的位置出发，描绘一下你眼中的世界。
02:12
Corey：这是个好问题。你说得完全对。我在加入 CoreWeave 之前，在微软工作了二十年，也参与过 Azure 早期建设。所以现在走进 CoreWeave，思考过去 Azure 早期采用的许多方法，是否正在以 AI 专用的视角重新适用，这是一段很有意思的经历。
我觉得这正是理解 CoreWeave 在做什么，以及我如何看待当前世界和行业的好方式。我们正在看到，基于 AI 的应用机会会不断发展和扩大，这和云计算早期的机会很相似。最开始可能只有一两个应用，随后人们不断扩展、成长和构建更多东西。
03:02
Corey：然后看起来好像一夜之间发生了变化。当然，实际上这用了很多年，我觉得这一次也会花很多年。每一个应用、每一项服务、每一件我们在技术世界里接触和体验的事情，都会把 AI 作为重要组成部分。
我现在工作的关键，就是应对这个转向。应用和服务的构建方式正在变化，因此需要 AI 专用的能力，也需要以 AI 为中心的应用模型。要求人们把 AI 概念套到传统的应用构建方式上，最后会拖慢他们，制造各种问题。
03:48
Corey：所以我每天真正关注的事情，是不断追问：我知道过去是这样做的，但如果从 AI 中心的角度看，还能不能换一种方式？我们怎样构建服务，让想做 AI 的人拥有一个从头到尾都以 AI 为重点的平台？
04:08
Chris：你刚才说到以 AI 为中心的方式。我们节目其实也有点类似的问题。很长时间里，我们谈的是刚刚发布的模型；过去一年，几乎什么都变成了 Agent。你能不能谈谈这里发生的视角转移？人们想到 AI 时，脑子里最先出现的通常是模型和 Agent。如果从旧的云计算方式出发，究竟缺了什么？为什么不能只是把 AI 当成一个附加功能？
早期的做法就是：好，我们可以在云里加 GPU，这样什么都有了。但你现在谈的是一种从基础设施一直到应用的不同方式。基础设施到底需要补上什么？
05:07
Chris：你如何看待这个问题？未来的基础设施应该是什么样？
05:14
Corey：当然可以。也许先解释一下 AI 的不同路径会有帮助。你提到了 Agent，所以我可以从这里开始。这些路径最初是分开的，现在又正在走向融合，这一点也值得谈。
从最基础的层面看，AI 的使用或调用大致有两个大的方面。
05:43
Corey：第一个是训练，也就是实际创建这些模型和权重。它是在做学习，和人脑学习的方式有些相似，但目标是创建我们之后会使用的输出。无论是 OpenAI、Anthropic 还是 Meta，它们都需要经历训练这一阶段。
06:09
Corey：训练需要非常具体的基础设施，而且基础设施很昂贵。很多训练工作负载都以很大的批次部署，并且高度互联。它们需要一起协同工作。
06:31
Corey：在训练领域，CoreWeave 以及更广泛的市场发现了很多会让任务变慢的地方。GPU 很贵，所以任何减慢任务完成速度的事情都会带来影响。
这包括 GPU 故障，也包括把存储里的数据加载进 GPU 时出现的问题。你需要从基础设施底层开始看：GPU 到底出了什么问题，有没有设备故障；一路向上，还要看到底哪个任务正在运行、运行在哪些基础设施上，从而优化输出。
这和普通公有云、那种有很多计算机架的传统工作负载非常不一样。
07:18
Corey：它要求重新设计硬件如何布局，尤其是硬件如何互联，这对 AI 工作负载非常独特。然后还要一路向上，直到任务编排层，让编排器知道平台底层正在运行什么。
我认为 CoreWeave 的差异化有很多部分，比如观测平台和存储平台。我们提供了许多针对大规模 AI 训练工作负载的服务，这和传统云工作负载非常不同。
我先停在这里。故事还有后半段，等会儿我会讲到。但 Chris，你有后续问题，先请你来。
08:06
Chris：没关系。你可别丢掉故事的后半段，因为你刚才说到那里时我已经完全被吸引住了，所以才追问。
我很好奇，在你加入 CoreWeave 之前，是什么时候意识到需要改变？这个转变是突然发生的，还是随着时间慢慢发生？你什么时候意识到，自己想做一些不同的事情？还有，别忘了刚才故事的后半段。
08:24
Chris：我不是要把你刚才的回答切断。你说的后半段和前半段其实很相似，只是最后得出了不同结果，对吧？
08:55
Corey：我在微软最后几年有机会参与平台里许多 AI 基础设施相关的工作，这件事很有意思。那并不是我的日常主业。我的主业是做行业解决方案，比如金融服务、零售服务，思考这些大型行业如何在工作负载里使用 AI。这其实是答案的第二部分。
但第一部分是，我逐渐参与了很多关于微软如何优化基础设施部署的讨论。那时我意识到，过去大型云计算的一项核心策略是先准备空间和电力，需求出现后，再部署你需要的东西。
09:42
Corey：某个地区需要更多计算资源，你就部署更多计算资源。几天之内，就能增加一大批计算。某个地区需要更多存储，你可以再部署一些存储。资源的商品化和可互换性，是大型云平台在自身规模下的一项巨大价值。
但处理 AI 工作负载时，这套方法并不真正成立。AI 资源需要彼此互联，需要通过 InfiniBand 或 RoCE 这类专用网络连接，也需要专用的底层存储。突然之间，你必须提前规划。
10:13
Corey：这对我来说确实是一段学习经历。加入 CoreWeave 后，我看到平台有很多部分需要为 AI 定制，从针对 AI 工作负载的专门缓存，到 Kubernetes 的专门使用方式。
Kubernetes 本来就是标准的编排方案，但它也可以针对基于裸金属的部署提供 AI 能力，尽可能把 GPU 的性能压榨出来。再往上，编排器还需要知道底层发生了什么。
那时我才真正意识到，平台有如此多的方面需要、可以、也必须针对 AI 工作负载进行定制。
11:02
Corey：我觉得直到加入 CoreWeave，我才真正理解这件事。在微软时我已经看到了它的开端，但可能那更多是一个随着时间逐步学习的过程。
你会越来越清楚地看到，平台为什么需要定制。因为这些 GPU 背后的价值和成本太高了，做定制是值得的，客户也愿意付钱来获得这些昂贵 GPU 的最大产出。
11:31
Chris：如果一个人拥有你的背景和职业经历，他在调整自己的视角，也能来到 CoreWeave 看见这些能力，那么问题是：其他 AI 从业者没有你的经历，他们怎么知道自己漏看了某些问题？你如何教育他们，让他们意识到有一组自己甚至不知道存在的基础设施问题？教育这件事要怎么做？
12:03
Corey：所以……
12:04
Chris：你怎么教他们？
12:22
Corey：这确实很难。我也得说，这对我本人同样很难。虽然你刚才的介绍让我听起来像是特别擅长这件事的人，但事实是，过去的大型云计算经验虽然非常有价值，也可能成为限制。
12:36
Corey：你会带着一堆假设进入新世界。你会想，这就是我们过去十年构建系统的方式，我们知道它为什么这样构建。但你未必会继续质疑那些本来应该质疑的东西：也许这已经是一个不同的世界。
所以在某种程度上，这正是「创新者的窘境」的核心。过去让我们成功走到今天的东西，不一定能让我们成功走到下一波。
13:08
Corey：对我来说，关键是持续提问。比如，假设某件事在基于十年通用云经验的前提下是正确的，但 AI 是否可以采用不同的假设？如果数据需求不同呢？容器镜像大小不同呢？AI 创新的整体流动方式和典型软件开发不同呢？如果这些条件不同，我们要解决哪些问题？
13:40
Corey：某种程度上，答案就是提出正确的问题。我还认为，在 AI 创新里，人类最受保护的能力之一，就是创造力，以及提出和现状不同的问题。
我们知道，AI 基于已经存在的东西。它是深度学习，是对已有内容的重新组合，其中有很多令人惊叹的能力。但人类可以进一步说：也许现有的东西就是错的。差别就在这里。
这也是我们面对 AI 和许多技术创新时必须提出的问题。即便我自认为还算擅长，真正的秘诀仍然是招聘非常优秀的人，招聘那些在这方面比我更强的人。
14:15
Corey：我会在市场上寻找这样的人，找那些会挑战我的人。他们可能会说：Corey，也许你的基线是错的。你在 Azure 里做的事情在 Azure 有效，但现在也许已经不适用了。
我会觉得，这个提醒有点刺耳，但很公平。我认为这种工作方式很有效。
15:01
Chris：你几分钟前提到训练，这吸引了我的注意力。我想回到这里。
当训练任务失败时，你提到了系统里可能发生问题的很多位置。能不能谈谈，在 AI 从业者或研究者发现任务出问题、发现任务没有沿着目标方向取得进展之前，系统内部到底发生了什么？
这里好像有一种黑箱般的神秘感。你能不能具体说说，这些问题通常在哪里出现、怎样出现，以及会带来什么后果？
15:59
Corey：这是一个同时有科学和艺术成分的领域。行业里最优秀的人往往有一种直觉，知道系统应该怎样运行。
但「任务失败」可以表示很多事情。最直接的是基础设施故障，基础设施失效，或者某个节点变慢，导致系统运行速度低于预期。
16:31
Corey：原因可能很多：存储变慢，GPU 变慢。我们最近推出了 GPU 慢节点检测，这个能力出乎意料地受到欢迎。
它关注的是基础设施内部由于各种原因出现的 GPU 降速。当一个任务使用数百、数千，有时甚至数万块 GPU 时，找到那一块变慢的设备非常困难。但任务可能因此变慢，所以问题是：到底哪一块 GPU 没有正常运行？
16:55
Corey：这种检测和观测其实很有挑战。我们认为，能发现硬件故障、软故障、慢节点，以及这些问题对任务造成的影响，是 AI 专用基础设施的一大部分。行业里所有人都在努力解决这类 AI 专用的问题。
17:41
Corey：另一方面，问题还在于研究。我们称它为研究是有原因的，因为你会运行大量实验，改变不同参数和控制变量，然后把实验结果放在一起比较、研究，理解哪种方式有效，再根据输出决定下一次实验怎么做。
18:09
Corey：Weights & Biases 位于我们平台的上层，重点就是实验追踪和比较。
我们最近听到一个很强的反馈，也刚刚发布了一个非常新的能力：你说的「艺术和科学」确实很难。识别实验发生了什么、理解实验结果，再判断正确的下一步是什么，这件事很难。
所以我们最近推出了 ARIA，也就是 AI Research and Iteration Agent。它的完整工作就是持续分析正在运行的实验，并判断下一步应该怎样做。
18:58
Corey：简单说，现在这件事主要靠有经验、有专业知识的人推动。但技术平台的一个重要作用，就是让更多人能够做这种迭代式的模型改进。用 AI 自己来帮助完成这件事，我觉得是一个很聪明的方向。
19:19
Chris：你提到 ARIA。它应该会带来一种新的工作流，新的能力和新的洞察，也会带来新的日常工作方式。它会怎样改变从业者每天做的事情？哪些东西被加入，哪些东西被拿走？它的好处是什么？
19:44
Corey：如果把我的判断推到很远，我觉得门户、控制台和标准化视图都会逐渐淡出。未来的体验会是和 Agent 交互。
这种交互到底出现在网站、控制台，还是我的 VS Code 里，我不知道，也可能所有地方都有。但核心应该是：我告诉系统，根据 traces，我想让模型在哪方面变好，接下来最好的实验怎么做？
20:21
Corey：系统会回答：好，那就运行它们。然后我可能在夜里通过手机看到，实验已经完成。Agent 会告诉我：这些实验跑完了，这个有效，那个无效，我认为这里还应该再跑一轮。
20:48
Corey：我同意，于是新一轮开始。它回来后又说：这个方案改进很大，但根据数据，也许继续迭代会有帮助。这样反复进行，一轮又一轮。
21:02
Corey：我认为这种 AI 循环会成为开发体验。研究者的大脑仍然在工作，仍然会说「我不知道这样是否有效，我们换个方式试试」。但这个判断会大量受到 Agent 对数据的分析引导。
今天的行业标准，还是进入控制台，看六次运行的折线图，再把成功率放在一起比较，靠人眼检查。但我认为世界不会一直这样发展。
21:39
Corey：我对这个方向很兴奋。我认为 Agent 主导的方式是正确方向。坦率说，我觉得未来我们和任何东西互动都会如此，不论是银行业务还是买衣服。
到那时，点击一个写着「购买」的按钮，可能会在五年后显得过时，十年后甚至有点可笑。但我们还要看它会发展得多快。
22:09
Chris：我年纪不算小了，还记得过去的一些东西。回头看几年前的体验，会觉得我们居然就这样过来了。
你几次提到 Agent。通常人们会从应用角度想：我有一个模型，我要在应用里决定使用多少个 Agent，它们是一对一还是一对多，然后给它们测试和交互。
但我想知道，基础设施这一侧是不是不太一样？你怎么看 Agent 架构在基础设施环境里的工作方式？对你来说，它们意味着什么？
23:00
Chris：从基础设施提供方的后端，到客户看到的前端，这两边分别会得到什么？能不能谈谈基础设施里的 Agent？
23:13
Corey：当然可以。我甚至想回到很久以前我回答过的一个问题。当时我说过有两条路径，我们刚才讲了第一条。
23:29
Corey：第二条是推理。它基本就是 AI 应用。我喜欢称它为 AI 应用，因为我同意你说的，大家都在谈 Agent。但从某种角度看，一切都是以 AI 为中心的应用。
Agent 只是其中一种类型。它们都会使用推理调用，利用我们刚刚创建的模型，向模型提问、要求分析，或者只是让模型做拼写检查。这些都可以发生在后端。
24:07
Corey：随着应用越来越复杂，我认为 AI 应用大致有两类。一类是内部生产力应用，比如各种 Copilot。另一类是业务关键应用，可能面向客户，也可能直接关系到企业关键工作负载，比如药企的基因折叠应用。
24:51
Corey：第二类应用会变得非常复杂。今天很多人的思路是：我有一个问题，于是调用一个前沿模型，得到一个答案，这就是我的应用。
但未来的应用会由很多 Agent、很多模型，以及很多种推理调用共同组成。它们会组合在一起，构成一个完整应用。
最深度、最困难的分析，也许会交给前沿模型。但如果有人用日语提问，你只需要把它翻译成英语，就不需要同样的深度，可以用另一个更小、更便宜的模型。
25:36
Corey：某些非常专业的工作负载，比如基因折叠，可能需要针对性很强的模型。用一个巨大通用模型解决所有问题，就像用大锤处理一颗螺丝。你当然可以把它敲进去，但并不合适。
所以，很多应用需要更深入地思考自身如何工作，也要思考它将怎样利用基础设施。
26:06
Corey：基础设施是成本的重要组成部分。应用如何利用它？有没有针对基础设施做充分优化？它是否真正理解基础设施？
26:17
Corey：我前面提到的基础设施感知、存储缓存等能力，都能让推理工作负载运行得更好、更快、更便宜。
另一个问题是：它使用了正确的模型、正确的参数和正确的提示词吗？这为 AI 应用开发打开了一种新的方式，我们把它称为 AI loop。
你永远不会把它做到「完成」。你可以继续改进提示词，也可以继续训练某个模型，让它更好一点。训练结果又会反馈到训练环节。
27:10
Corey：未来的应用可能会有三十到五十个模型互相交互。然后你会找出其中需要改进的部分：可能是成本问题，可能是结果需要更好，也可能是速度需要更快。
接着把输出送回系统，通过 Weights & Biases 这类产品处理，再用 ARIA 学习，让它一点点变好。我认为这就是这类应用的未来。它从最好的基础设施开始，一直延伸到构建优秀应用所需要的完整工作流。
27:32
广告：我们每周要创建的网页、落地页等页面似乎越来越多。它们经常变成工单和团队成员之间的交接堆积。这也是我喜欢 Framer 的原因。Framer 是我们的合作伙伴之一，提供专业网站构建平台，让团队可以实时协作，在同一个页面上迭代并立即发布。
你还可以把 Agent 接入这项工作，让 Agent 和人一起协作。Agent 带来速度和规模。
28:08
广告：人带来品味、判断和控制。如果你要从零开始做一个新网站，需要落地页，或者要重新发布网站，我建议你看看 Framer。你可以在 framer.com/practicalai 向 Framer 专家了解如何让网站发挥更大作用，也可以今天就免费开始构建。通过这个地址购买 Framer Pro 年度方案，可享受 30% 折扣。地址是 framer.com/practicalai，享受 30% 折扣。
28:42
广告：具体规则和限制可能适用。
28:46
Chris：Corey，你刚才回答那个问题时，我脑子里冒出了很多问题。
28:55
Corey：抱歉，我是不是把问题搞得太复杂了？
28:56
Chris：没有，很好，这就是我们来这里的原因。现在很多人正在思考自己的工作流，把 Agent 工程看成一种循环工程，努力让所有循环运转起来。你刚才的回答也提到了这一点。
如果人们想不断提高自己的循环工程能力，他们会经历学习曲线。假设他们现在使用 Amazon、Azure、Google 或其它平台，已经在尝试这些方法。如果他们听完节目决定迁移到 CoreWeave，你提到的这些优势和能力，会怎样改变他们在 Agent 或循环工程里搭建的东西？
他们怎样利用这些能力？需要做哪些调整？
30:11
Corey：我认为关键是，能够快速执行这个循环并从中学习，同时不要引入太多额外噪音或中断。
我很兴奋的一件事，就是研究这些循环如何变成可以组合的服务，以及你如何真正执行它们。
30:40
Corey：你可以运行推理服务，让它使用 Weave 平台记录 traces 并运行评估。这样你就能看到生产环境里的问题：某些类型的问题是不是走错路径，某些操作是不是花费太长时间。
接着你要思考，是不是应该换一个模型。生产 traces 会告诉你该在哪里改进。
31:14
Corey：ARIA Agent 可以帮助你找到这些问题。它可能会说：当遇到某类问题时，这条路径变慢了。
接下来你可以直接执行：如果我改变提示词，问题会不会解决？如果我换模型呢？比如出现了一个新模型，速度很快，那我就换模型，看看结果有没有变化。
31:28
Corey：然后我可以快速设置一个评估并运行它。你可以使用 sandbox 产品运行评估，比较两种方案。
比如，换成 Kimi 后性能变好了。那我还要检查价格是否有明显差异。价格可以接受，那么就把它换进生产，再开始下一轮循环。
32:02
Corey：这些循环可以很小。事实上，大多数修改都不是「把它放进训练工作流，做一次强化学习或微调」。这当然也可能发生。
比如模型运行得不错，但某类问题的准确率略有偏差，而且新模型也不一定能解决。这时可以微调。如果没有足够数据做微调，也可以做强化学习。
32:38
Corey：这些服务可以整合在一起运行，继续用 Weave traces 检查是否有效，再运行评估。有效，就把它接回生产。
我认为开发者会寻找三种能力。第一，尽可能把大部分工作放在一个地方完成，因为追踪 traces、维护模型注册表、记录 lineage 都更简单。
每个更新过的模型、参数和版本都能被追踪。你可以说：昨天那个版本是 3，那个版本就是我想要的。
然后上面再有一个 Agent，它知道下一步该试什么，或者你应该继续处理哪个问题。
33:14
Corey：这就是我认为真正强大的地方。我很兴奋，因为 CoreWeave 已经提供了其中很多组件，同时我们还在继续让这条工作流变得更容易，让它比今天的 CoreWeave 运行得更快。
33:32
Chris：你刚才说到可以灵活使用不同模型，但我们一直在谈垂直整合带来的性能优势。支持开放方式和把技术栈深度优化到很高性能之间，会不会存在张力？你怎样看可移植性和性能优化之间的关系？
34:08
Corey：这是个很棒的问题。我长期以来一直相信一个观点。我曾经负责在微软把第一套 Linux 基础设施部署起来，当时它叫 Windows Azure，是在 Windows Azure 上托管 Linux。
从那时到今天，我的信念都是：我们必须预期并支持多云。认为 CoreWeave 会成为人们用于 AI 应用的唯一云，我觉得是错误的。
34:58
Corey：我谈 AI loop 时，确实很兴奋地说所有组件都可以在 CoreWeave 上使用。但同时也清楚，很多客户不会使用 CoreWeave 提供的每一项服务。
他们可能已经有很喜欢的评估服务，也可能已经在别处训练，只想在这里运行推理；或者反过来，已经在别处推理，只想在这里训练。
所以，开放并提供一致的服务，是我们策略的重要组成部分。
35:25
Corey：比如 Sunk，它代表 Slurm on Kubernetes。Slurm 和 Kubernetes 都是开源项目。
我们很自豪能把这些能力做得更好。我认为差异化和价值就在于：能不能把这些开放、跨云的能力做成最好的服务，让客户因为服务最好而愿意使用我们。
所以我经常开玩笑说，这是「Lock-in with love」。
35:53
Corey：这也是我们为什么推出 Sunk Anywhere。你可以把 Sunk 部署到其它基础设施上。我们认为它在自家基础设施上运行效果最好，但客户也可以带到其它地方。
36:02
Chris：你已经几次提到 Sunk、Slurm 和 Kubernetes。能不能详细说说 Sunk？对那些在旧云环境里使用 Kubernetes 的人来说，它有什么不同，解决得好在哪里？
36:21
Chris：你能不能把它整理成一个容易理解的解释？
36:26
Corey：简单说，Kubernetes 是市场领先的平台，大家已经熟悉如何用它操作和编排基础设施，以及在基础设施上运行的工作负载。
Kubernetes 之上的平台多年来有效主导了这个市场。
Slurm 则是作业调度、编排和放置引擎，在研究型工作负载和 AI 研究里有很强的影响力。当然它不是唯一方案，行业里还有很多其它选择，我们可能可以单独做一小时节目来讨论它们的优缺点。
37:06
Corey：许多 AI 研究者了解 Slurm，也习惯使用 Slurm。问题是，在基础设施上运行 Slurm 实际上很难管理。对 AI 研究者来说，管理基础设施的上下波动和基础设施故障尤其困难。
而这些正是 Kubernetes 擅长的地方。
37:47
Corey：所以 CoreWeave 构建了 Sunk，也就是 Slurm on Kubernetes。它把两边最好的部分结合起来：Slurm 的作业调度能力，加上 Kubernetes 的编排能力和易用性，把两者放在一起形成一个平台。
这是我们直接在自家基础设施上提供的关键产品。正如我刚才说的，我们最近宣布 Sunk Anywhere，也就是可以在其它云上部署这套支持，把 Slurm 和 Kubernetes 的组合带到任意云。
38:18
Chris：这非常有意思。我还想问一个稍微转弯的问题。大家总是在谈成本，不是某个具体提供商的价格，而是进行有意义的实验和前沿研究本身需要很高的资本。
算力成本太高了。少数拥有大量资源的机构可以做很多事情，其他人会问：我怎样和他们竞争？我应该怎么接近这个问题？CoreWeave 可以做什么？行业整体又该怎么应对？
39:18
Chris：很多听众和观众可能都在想这些。你会对他们说什么？
39:26
Corey：AI loop 和整合式工作流的一个目标，就是让人用更少资源做更多事情。或者说，用更少资源完成同样的事情，具体怎么理解都可以。
优化有很多含义。比如选择一个更便宜、但足够把工作完成的模型。这样需要的基础设施更少，部署规模也更小。
39:57
Corey：也可以改进模型和微调，缩小模型体量，或者让较小规模的模型更有效。
ARIA 这类工具的目标之一，是减少试错，让实验更快走向生产。这是成本结构里很重要的一部分。你想把东西做进生产，但要花多少成本才能到那里？
40:29
Corey：如果有 ARIA 和 AI loop，你可以把东西推出去，让它开始产生收入、开始为业务创造价值，然后边运行边实验、边学习。
Agent 可能会告诉你：不要在这里花钱做微调，先改提示词，也许就能解决问题。它是在许多大型实验室积累的经验基础上，帮助你把资源用在更值得的地方。
41:06
Corey：当然，大型实验室还在最前沿。对于讨论历史知识的 Agent 来说，它们面对的问题可能仍然太新，过去经验未必有帮助。
41:16
Corey：但对那些落后前沿实验室一步的企业来说，我认为这类能力很有意义。事实上，我觉得每个企业和大型公司都希望处在这个位置，因为前沿实验室今天已经在做的事情，可能就是它们明天要面对的事情。
把这些能力和前面提到的底层硬件优化结合起来，我认为这种平台会很有价值。
41:36
Chris：很酷。另一个今年迅速扩张的方向是边缘侧的具身 Agent 工程。机器人正在和 AI 结合，快速发展。
CoreWeave 未来在这方面有什么故事？你们并不严格只做云，也面对云和边缘平台之间的混合环境，以及不同程度的具身智能和 Agent 能力。
42:12
Corey：在机器人、工业、制造等场景里，我们有几个重点。
我前面谈过模型和实验追踪技术，也谈过看各种图表。我们最近给 Weights & Biases 平台增加了专门的机器人方向。
42:51
Corey：其中一个看似简单、但价值巨大的变化，是从显示成功率的折线图，转向显示成功本身的视觉画面。
你可以看到真实的机器人如何移动，看到不同实验里发生了什么，再找出哪里出错、哪里没出错。这还没有完全进入 Agent 阶段，但我认为再把 ARIA 加上去，就能把机器人训练和迭代工作串起来，支持更多机器人工作负载。
43:31
Corey：另一个有意思的方向，是我们几个月前收购的 Monolith。
我们在很多场景里都意识到，需要直接和客户一起工作，了解他们在构建什么，帮助他们解决什么问题。很多工程资源会和客户坐在一起，讨论他们正在构建的东西、想解决的问题，然后想办法提供帮助。
44:05
Corey：这类工作以前也是 Mission Control 的一部分，我们称为 Direct to Expert，也就是直接连接专家。我们会投入资源和专业能力与客户深入合作。
Monolith 带来了工业和制造业方面的经验，我认为这对于帮助客户构建解决方案非常重要。未来我们还会继续关注其它垂直领域。
还有一点，越来越多的能力可以在其它基础设施上运行。前面提到的 Sunk、缓存服务，以及存储平台，都可以部署到其它地方。
很多能力基于 Kubernetes operator，这意味着边缘环境和本地环境也有机会使用相同的服务。Weights & Biases 等软件解决方案也可以在这些环境里发挥作用。
44:43
Chris：这太酷了。节目快要结束了。长期收听的观众和听众知道，最后一个问题通常会邀请嘉宾稍微诗意地展望一下。
我们想象一天结束，你以自己的方式放松下来，准备上床睡觉，但脑子还在转，想着不同的问题和未来会怎样。如果你愿意，能不能分享一下你的愿景或梦想？可以是 CoreWeave 的，也可以是整个行业的，或者两者都有。
我不是在问你的下一项产品发布，而是问几年后的大方向。就算判断错了也没关系，我很喜欢听人们在某个时间点对未来的思考。
45:34
Chris：当你在睡前放松下来时，脑子里会出现什么？
45:50
Corey：我可能会再次强调前面已经谈过的内容。
公有云一路发展到今天，几乎每家企业、每家公司都有自己的公有云工程团队。很多情况下，这些团队甚至已经超过了本地部署工程团队，当然也有例外。
几乎每个应用和体验背后都有云基础设施。我觉得 AI 会经历同样的过程，而且速度可能更快。每一家企业都会有 AI 工程团队，而且它们很快就会在 AI 应用方面超过传统软件团队的重要性。
47:01
Corey：我还是用云作例子。云最初的体验是点击一个按钮，再点击一个按钮，再点击一个按钮。
但现在，我们在云端录制播客，在云端基础设施上观看世界杯。我更喜欢这样的体验，而不是打开电视后问自己：这个节目到底在哪个频道？
47:24
Corey：所以 AI 的转变会远远不止「我和 Agent 聊天」。它可能会根据你对屏幕做出的表情提供视觉回应，也可能出现远超今天的全新人与系统交互方式，取代我们现在认为理所当然的现代体验。
47:54
Corey：云计算花了大约十五到二十年才走到今天，我觉得 AI 可能会把时间缩短一半。
五到七年内，世界可能就会变成这样：今天这种需要点击按钮的网站会变成遗留系统。人们可能会说，我不敢相信它们还没有把这里 AI 化，或者无论以后这个动词会是什么。
48:24
Corey：这对 CoreWeave，以及这个领域里的所有公司，都提出了一个要求：怎样通过民主化必要的能力，帮助世界走到那一步？
现在，大多数企业没有前沿实验室的研究人员，也没有足够的人才来以这种方式创新，所以会受到限制。
48:41
Corey：这和云计算最初的情况很像。当时企业也没有云计算人才。后来它们会扩充团队、培训、培养能力、招聘，这些事情都会发生。
但与此同时，就像云计算浪潮一样，我们有义务把服务做得更普及，让更多人能以更低成本交付这些价值。
这也是我为什么在这里。我说的「这里」不是 CoreWeave，而是我为什么现在还在这个行业里。这就是原因。
49:01
Chris：这个洞察非常好。我不仅觉得你说得有道理，也觉得听你这样思考很有意思，很有趣。谢谢你来到节目，和我们进行了一次很棒的对话。我学到了很多。
49:17
Chris：谢谢。
Corey：谢谢你。
49:18
Chris：CoreWeave 的 Corey Sanders。希望以后还能再邀请你回来。
49:21
Corey：谢谢你的时间，Chris。你什么时候想邀请我，我都会回来。
49:28
旁白：好了，这就是本周的节目。如果你还没有访问我们的网站，请前往 practicalai.fm，也欢迎在 LinkedIn、X 或 Blue Sky 上关注我们。你会看到我们发布最新 AI 发展相关的洞察，也欢迎加入讨论。感谢 Prediction Guard 为节目提供运营支持。
49:49
旁白：你可以在 predictionguard.com 了解他们。也感谢 Breakmaster Cylinder 提供音乐，更感谢你收听节目。今天就到这里，下周再见。
コメント
ログインするとコメントできます。