Why AI Infrastructure must evolve for Agent Experience
- 播出日期:2026-07-08
- 嘉宾:Akshat Bubna,Modal CTO
- 主持 / 对谈者:Swyx、Vibhu
- 场合:围绕 Modal 完成 Series C 后的一次访谈。开场提到前一天的庆祝活动布置了多件艺术装置,Modal 的产品被放在展台上,与 Rodin 作品并置展示。
- 核心议题:Modal 的起源、Kubernetes 的局限、从 Developer Experience 到 Agent Experience、弹性推理、GPU 快照、沙箱、DeFlash、Auto Endpoints、多云容量池、生产级智能体基础设施,以及编码智能体带来的 CI 与 SDK 变化。
- 全集时长:约 3475 秒,即约 57 分 55 秒。
- 说明:用户提供的英文材料在 26:40 至 40:55 之间明确标注“中段省略”。本笔记保留该区间的时间锚点与主题名称,但不补写未提供的具体发言、数字或结论。
Modal 最初并不是一家明确以 GPU 推理为唯一定位的公司。Akshat 回忆,他通过一位投资人认识 CEO Eric;Eric 当时已经在思考一种新的运行时,问题意识来自工作流编排产品为何如此难用:它们往往建立在 Kubernetes 上,而 Kubernetes 难以管理,不擅长突发式负载和自定义镜像,开发者体验也很差。
团队最初把“更好的运行时”视为一种通用基础原语。它可以处理 ETL、任务队列以及各种需要快速扩缩容的计算任务,也可以进一步支撑更垂直的产品。Modal 当时考虑过数据工程和传统机器学习推理,包括计算机视觉与 XGBoost;公司在 ChatGPT 发布前一年就已经把 GPU 加入产品,只是没有预料到 GPU 工作负载会变得如此重要。
Modal 的另一项早期设计原则是“软件定义基础设施”或“自配置基础设施”:把硬件、扩缩容和环境要求通过 decorator 与业务代码放在一起,而不是要求开发者维护大量 YAML。随着编码智能体开始直接编写、部署和调试软件,这种设计被重新解释为 Agent Experience:智能体不必阅读数百个 Kubernetes 文件,而可以通过少量有类型、可执行的代码或 CLI 操作,获得完整运行环境。
本期对话还显示,Modal 并不试图取代所有云计算形态。Akshat 明确表示,它没有打算与面向常驻 Web 服务的平台竞争;Modal 集中处理需要专用计算、跨区域调度、快速扩缩容、沙箱隔离以及 CPU/GPU 协同的工作负载。其当前范围包括推理、训练、批处理和沙箱,并希望继续沿着“模型生命周期”和“智能体生命周期”扩展。
这期访谈的主线,不是“Modal 又增加了哪些 GPU”,而是 AI 工作负载正在迫使云基础设施重新定义最基本的抽象。传统 Kubernetes 更适合缓慢扩容、长期运行的 Web 服务;Modal 面对的却是模型上线、区域流量波动、强化学习 rollout、批量编码、后台智能体与短生命周期沙箱。这些任务可能从零启动,也可能在单一区域迅速从约 1000 张 GPU 增长到 1500 张,强化学习甚至会同时需要 10 万个沙箱。因此,真正的产品并非裸 GPU,而是冷启动、快照恢复、区域容量、可靠投递、尾延迟控制、持久化存储和网络隔离的组合。
第二条主线是 DX 向 AX 的迁移。Modal 并不认为智能体时代会让基础设施体验失去意义;相反,代码可能更少被人直接阅读,但可观测性、CLI、快速迭代和明确边界会更重要。Modal Bench 的思路尤其关键:观察智能体经常尝试调用、甚至“幻觉”出来的能力,再判断是否应将其变成真实 CLI 或产品接口。这里的 AX 不是彻底抛弃 DX,而是把同一套低摩擦、可组合、可观察的原语开放给机器操作。
第三条主线是开放技术与托管产品并存。Modal 将 DeFlash 等推理优化开源并与 SGLang 团队协作,同时通过 Auto Endpoints、GPU 快照、弹性扩缩容和生产运维提供额外价值。争议集中在三点:开源优化能否形成长期商业差异;17 家云与裸金属供应商之上的可靠性层是否足够稳健;以及智能体权限究竟应交给 LLM 动态判断,还是必须保留不可逾越的硬边界。Akshat 的立场相当明确:模型可以参与软性决策,但沙箱级安全仍需硬护栏。
- Series C、艺术派对与公司定位的变化 — 00:00 🎧 · ▶️
- Modal 的起源:新运行时、突发负载与代码内配置 — 00:39 🎧 · ▶️
- 从 DX 到 AX:智能体不应阅读数百个 Kubernetes 文件 — 04:32 🎧 · ▶️
- 沙箱、智能体循环与早期 proto-Cognition — 09:14 🎧 · ▶️
- 弹性推理:从零扩容、GPU 快照与 10 万个沙箱 — 12:12 🎧 · ▶️
- DeFlash、推测解码、Auto Endpoints 与生产级推理 — 15:24 🎧 · ▶️
- 模型生命周期、后台智能体与 17 家云组成的 supercloud — 22:00 🎧 · ▶️
- 网络化沙箱、多节点训练与容量规划:转写缺失区间 — 26:40 🎧 · ▶️
- 开放模型、实时音视频、硬护栏与专用沙箱 — 40:55 🎧 · ▶️
- AI 让基础设施重新令人兴奋,模型 API 却可能不够黏 — 46:06 🎧 · ▶️
- CI、运行时沙箱、SDK 语言与 Modal Bench — 51:50 🎧 · ▶️
- 收尾:专注、执行与“还有很长的路” — 57:28 🎧 · ▶️
💬 他们说了什么:
Swyx 首先祝贺 Modal 完成 Series C,并提到前一天的派对、照片和周边产品。Akshat 说现场有多件艺术装置,Modal 的产品被放在展台上,与 Rodin 作品并置。主持人随即指出,Modal 刚成立时并不是一家明确的“GPU inference company”,并请 Akshat 回顾公司的起源。这个开场把融资节点与产品路线变化连接起来:公司并非从一开始就只围绕大语言模型,而是先建立更通用的运行时。Series C 的具体融资金额、投资方和估值均未在所给转写中出现。
💡 为什么重要:
开场提醒听众,Modal 今天以 GPU、推理和智能体基础设施受到关注,但其底层设计早于当前生成式 AI 热潮。理解这一点,有助于解释为什么它同时覆盖推理、训练、批处理和沙箱,而不是只提供单一模型 API。
⚡ 争议点:
节目只提到 Series C,并没有给出可验证的融资条款;不能仅凭本期内容判断融资规模或市场估值。
💬
Akshat 通过一位投资人认识了 Modal CEO Eric,当时 Eric 正在思考为什么工作流编排产品如此难用。他的答案是,这些产品通常运行在 Kubernetes 上,而 Kubernetes 难管理、不适合 burstiness 和 custom images,开发者体验也很差。团队认为,更好的运行时本身就是有价值的基础原语:serverless functions 可以支持 ETL、任务队列和各种突发式处理。Modal 也曾设想以这些原语构建垂直产品,数据工程可能是最先落地的方向之一;推理也在早期考虑范围内,但当时主要是计算机视觉、XGBoost 等传统推理。公司在 ChatGPT 发布前一年加入了 GPU,却没有预料到这会变得如此重要。为了避免大量 YAML,Modal 把硬件和扩缩容配置压缩到与代码共置的 decorator 中;Akshat 承认配置层是一种 DSL,但强调用户仍然拥有自己的代码。
💡
Modal 的核心判断不是“Kubernetes 完全无用”,而是 AI 与计算密集型任务的负载形态不同:它们更依赖专用加速器、自定义环境和快速扩缩容。把基础设施要求放进代码,也为之后让智能体直接修改和运行基础设施奠定了接口基础。
⚡
DSL 仍可能形成平台依赖;“用户拥有代码”并不自动消除配置、运行时行为和运维流程上的迁移成本。Akshat 表示公司没有收到太多这方面的反对,但这只是其客户经验陈述。
💬
Akshat 说,Modal 已经让 SDK 团队从思考 Developer Experience 转向思考 Agent Experience。其理由是,DX 的主要好处同样适用于 AX:没有必要让智能体阅读数百个 Kubernetes 文件,再写缺乏类型约束的 YAML。智能体可以只修改几个 decorator,然后获得可自配置的运行时,并立刻看到改动的实际效果。Modal 从客户反馈中观察到,智能体使用 Modal 的速度比操作其他底层环境更快。Swyx 将其概括为:基础设施要求与执行代码被放在同一位置。Akshat 同时强调,即使人类不再频繁阅读代码,可观测性仍然极其重要;Modal 把更多能力推向 CLI,方便智能体自行调查,但最终仍需要人类解释运行状况并做判断。
💡
AX 并不只是为产品加一个聊天框,而是重新审视基础设施是否能被机器准确发现、调用、调试和观察。代码阅读的重要性可能下降,但结果可见性、日志、指标和人类决策接口反而更加关键。
⚡
“Modal 对智能体更快”来自公司及客户交流,没有展示统一基准或对照结果。DX 与 AX 究竟只是高度相似,还是最终会产生根本不同的产品形态,本期并未完全解决。
💬
Swyx 回忆自己约三年前开发 smol developer,需要突发式计算,因此尝试使用 Modal functions;项目登上 Hacker News 后还给 Modal 带来明显流量峰值。他把这段经历称为“proto-Cognition”,即后来编码智能体形态的早期雏形。Akshat 说,Modal 同期正在接触需要 sandboxing 的客户,并于 2023 年 5 月构建了沙箱,当时行业尚未普遍意识到这会成为重要产品。团队发布的第一个示例,就是把 smol developer 放进循环,让智能体能够迭代自身。当时的模型并没有针对循环、自我修正和成熟工具调用接受足够训练;Akshat 回忆,模型大约运行十轮后就会发散,无法继续产生有意义的结果。Swyx 反思,理想路线应当是收集失败、构建基准、收集示例并构造强化学习环境,但也承认当时很难对模型进步建立如此强的信念。
💡
这一段说明,沙箱并不是在编码智能体成为热点后才临时添加的功能,而是来自更早的客户需求与实验。它也表明基础设施可能先于模型成熟:运行时已经能够形成循环,但模型能力不足以稳定利用它。
⚡
Swyx 关于“卖给 Meta 十亿美元级、再卖给 Elon 六百亿美元”等说法是玩笑式反事实,不应当作真实交易或估值证据。所谓“proto-Cognition”也是回顾性类比,而非当时已经被验证的产品定义。
💬
Akshat 表示,Modal 当前最大的用例是 elastic inference,最早找到产品市场匹配的领域则是自定义模型推理。公司一度避开通用 LLM 市场,服务 Suno 的音频、Runway 的视频,以及机器人和计算生物学公司;这些客户通常在别处训练自有模型,再使用 Modal 完成部署和扩缩容。流量具有日夜周期,也会在产品发布时突然上涨;客户还会在多个区域部署多个模型,不同区域的高峰周期并不同步。Modal 因而重点投资自动扩缩容,并把 GPU snapshotting 纳入产品:系统可以保存包括 torch.compile 模型在内的 GPU 状态,使后续冷启动更快。Akshat 举例说,大规模生产环境关注的不再只是从零扩到一,而是如何在特定区域迅速从约 1000 张 GPU 扩至 1500 张。强化学习 rollout 更加突发,有时需要同时启动 10 万个沙箱;训练前的编码类批处理也可能临时需要数千张 GPU。
💡
这把“AI 云”的竞争点从 GPU 是否存在,推进到容量能否在正确区域、正确时间、以足够快的速度出现。快照和恢复技术直接影响冷启动,而区域级弹性决定平台能否承受发布、批处理和强化学习带来的尖峰。
⚡
从 1000 扩到 1500 张 GPU、10 万个沙箱等是嘉宾描述的工作负载形态,转写没有给出客户名称、持续时间、成功率或性能报告。快照“更快”也没有附带具体冷启动数据。
💬
Modal 开始深入 LLM 推理,因为团队认为自身跨区域自动扩缩容优势并未在其他平台上普遍存在,但过去缺少模型层面的工作。Akshat 说,公司通过引入相关人才,已经能够追求 frontier-level model performance,并开源了 block-based speculator DeFlash。推测解码的基本方法,是让较小的 draft model 预先预测多个 token,再由较大的模型批量验证;逐 token 推理容易受内存带宽限制,而批量验证能够更有效地利用计算。只要 draft model 的 accept length 足够高,就可能获得原模型速度的数倍提升;Vibhu 用“2 到 4 倍”概括,Akshat 表示认同。Akshat 强调,大模型不会接受自己原本不会接受的 token,因此质量不应下降,不过运行第二个模型可能增加计算成本。Auto Endpoints 则允许用户通过 UI 或 CLI 创建已经包含这些优化的端点,用户可以查看代码、自行运行,或退出简化体验进入完整 Modal 工作流。谈到生产级价值时,他还列出真正的弹性、缩容至零、尾延迟控制,以及确保每个请求至少被投递一次。
💡
这一策略试图把开源推理技术与托管基础设施分开定价:底层优化可以进入开源生态,商业价值则来自持续调优、自动扩缩容和生产可靠性。Auto Endpoints 也缓和了“简单 API”与“可修改代码”之间的矛盾。
⚡
“达到专有供应商同等性能”“frontier-level performance”与“2 到 4 倍”均缺少本期内的基准配置、模型、硬件和成本说明。推测解码不降低输出质量,并不等于它在所有负载上都更便宜或具有相同尾延迟。
💬
面对“Modal 不会做什么”的问题,Akshat 表示公司会跟随用户,目前重点是模型生命周期与智能体生命周期。模型侧包括数据准备、训练和推理;智能体侧则包括后台智能体、沙箱、持久存储及其他配套能力。Ramp Inspect 被称为成功的后台智能体案例,它使用快照和快速扩缩容,让系统表现得更有响应性;Akshat 还提到 Rahul。谈到 GPU 与 CPU 的关系时,Vibhu 引用其从 Jensen 的 GTC keynote 得出的“inference inflection”观察:过去可粗略看作 8 比 1 的 GPU/CPU 关系,现在更接近 1 比 1,因为智能体经常等待或调用 CPU 密集型任务。Modal 自己没有数据中心,而是在全球 17 家云提供商、新云和裸金属提供商之上运行。Akshat 将这种资本较轻的路线解释为聚焦软件层,并称 Modal 在不同供应商之上构建了自己的可靠性层,以处理 GPU 掉线等情况。用户也可因数据本地性或延迟要求,把 CPU、GPU、沙箱和模型放在欧盟、美国或澳大利亚等特定区域。
💡
Modal 的“supercloud”定位,是把碎片化容量聚合成相对统一的运行时,而不是自行拥有全部数据中心。对智能体而言,CPU、GPU、文件系统和区域网络的共置,可能与单一 GPU 的峰值性能同样重要。
⚡
8 比 1到 1 比 1是 Vibhu 的概括,并非节目给出的普遍行业统计。17 家供应商之上的可靠性层是否能完全屏蔽底层差异,也没有独立可用性数据支持。
💬
可见转写在 26:40 开始谈到 Modal 从 compute、storage 和 networking 层构建产品,并提及用户需要 networked sandboxes。用户提供的时间提示把 26:40 标为“Networked sandboxes, private IPv6, and RDMA”,把 32:48 标为“Multi-node training, post-training, and auto research”,把 37:36 标为“Compute strategy, capacity planning, and batch tiers”。但正文在这一位置明确显示“中段省略”,直到 40:55 才恢复。因此,无法从所给转写确认 private IPv6、RDMA、多节点训练、自动研究、容量规划或 batch tiers 的具体实现、数字和嘉宾原话。本节只保留话题边界,不根据标题反向推导技术细节。
💡
这一缺口正好覆盖多节点、网络和容量策略等关键基础设施议题,如果强行补全,很容易把常见行业做法误写成 Modal 的实际能力。明确资料边界比生成看似完整、实际上未经转写支持的总结更可靠。
⚡
时间提示只能证明节目存在相应话题锚点,不能替代逐字内容。相关技术主张必须回听音频或查看未删节转写后再核实。
💬
Akshat 预测,会有数千家更多公司对自有模型做 post-training,并部署开源模型,因此 Modal 正在思考从 training gym 到高性能 endpoint 的完整产品形态。其他垂直方向有所不同:实时音频和视频需要 regional routing 与 fallback,以把 GPU 放在尽可能接近用户的位置,降低视频流等场景的延迟。智能体侧除了沙箱和持久文件系统,还会需要其他生产栈能力,但他没有立即披露具体产品。谈到权限时,Akshat 对由 LLM 在沙箱层直接中介权限持怀疑态度,因为缺少硬边界可能导致数据被 exfiltrate。他主张硬护栏始终存在,同时可以搭配由模型参与的软护栏。对于 Gemini、OpenAI、Claude 等 managed agents,他认为这类产品适合从零开始,但 Ramp 这类生产级应用会需要更细粒度地控制文件持久化、快照恢复、网络乃至 GPU。Modal 不强制规定 agent harness 必须运行在哪里,而是把自身角色定位为可受控的专用沙箱基础设施。
💡
这一段把智能体安全从“提示模型谨慎行事”提升到基础设施隔离问题。生产智能体的关键差异不只是模型能力,而是执行环境能否限制数据、网络、持久状态和硬件访问。
⚡
“完美 LLM 能否充当内核”被作为思想实验提出,但 Akshat 没有接受这一前提。硬护栏与模型中介权限之间如何具体分工,节目没有给出完整架构。
💬
Swyx 说,基础设施领域曾一度显得无聊,早年即使展示可以启动很多沙箱,也很难让人兴奋;现在情况已经改变。Akshat 认为,原因之一是当前 AI 工作负载需要极大规模。除 LLM 外,Modal 还服务药物发现、计算生物学与机器人公司,他点名 Chai Discoveries,并提到一些机器人已进入实际部署。Modal 目前是 cloud-only,没有 air-gapped 或本地部署版本,其目标也不是只服务 LLM 推理市场。谈到类似 Replicate 的模型 API 路线时,Akshat 表示 Modal 有意避开单纯提供模型 API,因为那可能更多服务较不黏的 hobbyist 市场;Modal 更希望服务需要代码级灵活性的产品公司。Suno 是他给出的例子:Suno 不在 Modal 上训练,但把全部推理放在 Modal,因为它拥有完全自定义的模型架构。对视频方向,与会者还讨论了由语言模型调用工具、代码和多个视频模型来编排更长视频,以及让智能体使用 FFmpeg 或更完整的制作工具。
💡
Modal 试图避免沦为可替换的模型调用层,而把差异化押在自定义代码、架构、工作流和运行时控制上。智能体编排视频等生产流程,也会把需求从单次生成扩展到多工具、多步骤的完整系统。
⚡
“模型 API 市场不够黏”是 Akshat 的产品判断,本期没有提供留存率或客户数据。关于生物科技、机器人和视频智能体的未来影响,多数仍是方向性观察,而非量化结果。
💬
Akshat 表示 Modal 看好 CI 市场,因为更多编码智能体将运行更多 CI,而现有原语仍可改进。CI 的浪费不仅来自测试本身,也来自准备 artifacts、依赖和环境;内存快照与恢复可能让这些任务更高效。节目提到 Gitpod 已改名为 Ona,并讨论其团队加入 OpenAI 后可能带来的影响;Swyx 把 CI 环境称为 build-time sandboxes,把智能体执行环境称为 runtime sandboxes。Akshat 认为两者配置面不同,运行时沙箱更需要镜像、存储等控制。Modal 最早选择 Python SDK,因为数据与机器学习用户主要使用 Python;现在也有 Go 和 TypeScript SDK,运行时用 Rust 编写,并不绑定 Python。训练和推理用户仍主要使用 Python,而不直接进行 ML 的智能体应用更多使用 TypeScript。Modal Bench 用来识别智能体在哪里失败、尝试调用什么能力;如果智能体反复“幻觉”出某个合理功能,团队会把这视为产品反馈,考虑加入真实 CLI,并把过去仅在 UI 中提供的日志和指标移到 CLI。
💡
编码智能体可能把 CI 从开发辅助流程变成高频计算负载,因而放大环境准备和恢复成本。Modal Bench 也展示了一种新的产品研究方式:不只访谈人类用户,还观察智能体如何误用、猜测和探索产品表面。
⚡
“智能体幻觉出的功能就是产品需求”并非总成立;有些调用可能只是模型错误,而不是普遍需求。节目也没有给出 Modal Bench 的任务集、成功率或对比结果。
💬
Swyx 感谢 Akshat,并表示这次对 Modal 的更新很有价值。主持人把 Modal 的成功归因于“focus”以及“really good execution”。Akshat 对此表示感谢,但补充说公司“还有很长的路要走”。双方随后结束访谈。
💡
这句收尾与整期内容一致:Modal 没有宣称已经覆盖所有智能体基础设施,而是从运行时、弹性、沙箱与可观测性逐层扩张。其路线依赖持续执行,而不是某一个单独的模型或硬件优势。
⚡
“成功来自专注与执行”属于主持人的综合评价,不是可独立量化的公司绩效结论。
- Akshat Bubna:Modal CTO,本期主要嘉宾。
- Eric:Modal CEO;早期从工作流编排与 Kubernetes 的痛点出发,思考新的运行时。
- Swyx:主持 / 对谈者;曾开发 smol developer,也曾在 Cognition 工作。
- Vibhu:主持 / 对谈者;讨论推理、强化学习、GPU/CPU 比例和基础设施市场。
- Modal:提供面向 AI 应用的云原语,覆盖推理、训练、批处理和沙箱。
- Cognition:转写提到 Modal 曾派工程师嵌入该公司,以降低沟通延迟。
- Peyton:Akshat 推测,嵌入 Cognition 的 Modal 工程师是 Peyton。
- Ramp:使用 Modal 构建 Ramp Inspect,也在 Modal 上运行面向外部的 accounting agent。
- Rahul:在 Ramp Inspect 讨论中被点名。
- Suno:在其他地方训练自定义模型,但据 Akshat 所述,其全部推理运行在 Modal。
- Runway:被列为 Modal 早期自定义视频模型推理客户。
- Chai Discoveries:被列为计算生物学 / 药物发现方向的公司案例。
- Anthropic:Akshat 表示 Modal 很高兴与其合作;其他 foundation labs 未具名。
- SGLang 团队:Modal 与其紧密合作,并希望把推理改进贡献给开源生态。
- Gitpod / Ona:作为 CI/CD 和沙箱基础设施案例被讨论。
- OpenAI、Gemini、Claude:出现在托管智能体、编码智能体与生态竞争的讨论中。
- Meta、Elon:只出现在 Swyx 的玩笑式反事实中,不代表真实交易。
“We’ve changed our SDK team to think about agent experience instead of developer experience.”
“我们已经让 SDK 团队从思考开发者体验,转向思考智能体体验。”
“Why would you have an agent read through hundreds of Kubernetes files and write YAML that’s not even typed?”
“为什么要让一个智能体读完数百个 Kubernetes 文件,再去写甚至没有类型约束的 YAML?”
“One thing we still see is really important is observability.”
“我们仍然认为,有一件事极其重要:可观测性。”
“Modal is a cloud platform where we’ve built the primitives from scratch for AI applications.”
“Modal 是一个云平台,我们从零开始为 AI 应用构建基础原语。”
“Running production-grade inference is a hard infra problem.”
“运行生产级推理,是一个困难的基础设施问题。”
“You always need hard guardrails.”
“你始终需要硬性护栏。”
“We see our differentiator in the software layer.”
“我们认为自己的差异化位于软件层。”
“Everything’s bullish Modal, as long as it consumes more infra.”
“只要它会消耗更多基础设施,对 Modal 来说就都是利好。”
“They hallucinate their own features.”
“它们会幻觉出产品本来没有的功能。”
“If they’re reaching for this thing, it’s product feedback. Give it to them.”
“如果它们反复尝试调用这个东西,那就是产品反馈:把这个能力给它们。”
“We have a long way to go.”
“我们还有很长的路要走。”
-
AX 不是独立于 DX 的全新哲学,而是把低摩擦基础设施接口交给新的操作主体。
Modal 没有抛弃 decorator、代码共置和自配置运行时,而是让这些设计同时服务智能体。变化最大的是 CLI、机器可访问的可观测性,以及智能体对产品表面的直接探索。
-
“人不看代码”可能提高而不是降低可观测性的价值。
当代码被视为黑盒,人类需要通过日志、指标和外部行为判断系统是否正确,再让智能体根据反馈修改实现。可观测性由开发辅助工具变成了人机协作控制面。
-
快照是多个场景之间的共同基础原语。
GPU 快照用于减少模型冷启动;后台智能体使用快照提升响应性;CI 也可能通过内存快照和恢复减少准备依赖与 artifact 的浪费。不同产品表面背后,复用的是同一类状态保存能力。
-
智能体基础设施天然横跨 CPU、GPU、文件系统与网络。
智能体并不是持续占用 GPU 的单一进程,它会调用工具、读写文件、执行代码并等待外部步骤,因此 CPU 与 GPU 的相对瓶颈会不断切换。
-
开源推理优化并不必然削弱托管平台价值。
Modal 希望把 DeFlash 等技术贡献给开放生态,同时通过区域容量、弹性、尾延迟、至少一次投递与专家支持形成产品差异。这是一种“开放算法、托管系统”的定位。
-
智能体的错误行为可以转化为产品发现机制。
Modal Bench 不只记录智能体是否完成任务,还关注它们试图调用哪些不存在的功能。若某种“幻觉”反复出现且符合用户意图,就可能说明产品缺少自然的接口。
-
硬安全边界与智能决策并非二选一。
Akshat 接受模型参与软性权限判断,但不认同用 LLM 替代沙箱层的不可越界限制。生产系统的关键是把概率性判断放在确定性边界内部。
-
本笔记未引入转写外的行业数据。
特别是融资金额、Modal 客户规模、DeFlash 的独立基准、17 云的可用性,以及被省略中段的 private IPv6、RDMA 和多节点训练细节,均未用外部材料补写。
- Series C 细节:转写只确认主持人祝贺 Modal 完成 Series C,没有金额、估值、领投方或正式公告日期。
- DeFlash 性能:“与专有供应商性能相当”和“2–4 倍”缺少模型、硬件、批量大小、上下文长度、成本与尾延迟数据。
- GPU 快照效果:Akshat 只说后续冷启动“快很多”,没有给出绝对时间或百分比。
- 弹性规模:1000 到 1500 张 GPU、数千 GPU 批处理与 10 万个沙箱均需结合具体客户、时间窗口和成功率核实。
- 17 云可靠性:Modal 声称自己的可靠性层可以屏蔽 GPU 掉线等问题,但本期没有 SLA、故障率或跨供应商迁移数据。
- 请求“至少一次”投递:需要进一步确认其语义、重试机制,以及重复执行如何由客户处理。
- DX 与 AX 的相似度:所谓 cosine similarity 约 0.9 是主持人的比喻,不是正式研究结论。
- 硬护栏实现:节目表达了原则立场,但没有披露沙箱逃逸防护、密钥隔离、网络策略或审计机制。
- Ramp、Suno 等客户描述:相关使用方式来自 Akshat 的口述,本期没有客户方独立陈述。
- Gitpod / Ona 与 OpenAI:节目中的组织变化和未来 Codex Cloud 推测需要结合正式公告核实。
- 模型 API“不黏”:这是产品战略判断,没有留存率、收入结构或客户迁移数据。
- 26:40–40:55 内容缺口:private IPv6、RDMA、多节点训练、post-training、auto research、容量规划和 batch tiers 的具体内容必须回听音频;不能根据时间标题补全。
- 日期与原始发布信息:本笔记采用用户指定日期 2026-07-08;所给转写本身没有口述播出日期。
- 用真实工作负载测量冷启动、扩容速度、尾延迟和区域容量,而不是只比较 GPU 单价。
- 把硬件、镜像、扩缩容与网络需求放进可版本控制、可被智能体修改的代码接口。
- 同时提供 UI 与 CLI 可观测性,让人类和智能体都能访问日志、指标与运行状态。
- 将快照恢复分别用于模型加载、后台智能体状态和 CI 环境准备,并验证实际节省。
- 为智能体执行环境建立硬网络边界、持久存储策略与密钥隔离,不要只依靠提示词约束。
- 要求供应商在相同模型、硬件和流量分布下说明推测解码加速,而不是只接受“数倍提升”。
- 分别测试吞吐、首 token 延迟、尾延迟、冷启动、成本和输出一致性。
- 检查缩容至零后的恢复时间,以及突发流量下的区域可用容量。
- 确认“至少一次投递”是否可能造成重复推理,以及应用层需要承担什么去重责任。
- 评估能否查看和修改端点代码,避免被限制在完全不透明的模型 API 中。
- 区分托管智能体的原型便利与生产沙箱所需的控制能力。
- 明确文件如何持久化、快照如何恢复、网络可以访问哪些目标、是否需要 GPU。
- 收集智能体反复尝试调用但产品不存在的命令,把它们作为潜在接口需求,而非一律视为模型错误。
- 在人类不直接审阅全部代码的情况下,加强结果级验证、日志检查和异常回滚。
- 对长循环任务记录每轮失败原因;早期 smol developer 的经验表明,模型可能在约十轮后发散。
- 不要把“拥有 GPU”误认为已经具备生产级推理能力。
- 判断业务究竟只需标准模型 API,还是需要自定义模型架构、tokenizer、推理代码和工作流。
- 如果存在全球实时音视频需求,应单独评估区域路由、fallback 与算力到用户的距离。
- 对跨多家云的“supercloud”方案,要求查看底层故障处理、供应商差异屏蔽与数据本地性保证。
- 回听 26:40–40:55 的原始音频,再对网络化沙箱、RDMA、多节点训练和容量层级作技术判断。