Baseten 收购 Blaxel 将推理供应商带入 Agent Runtime

在 Baseten 以 130 亿美元估值融资 15 亿美元仅数月后，Baseten 对 Blaxel 的收购为其增加了第二层生产能力。Baseten 原本已提供 AI 模型服务，而 Blaxel 则带来了让 agent 执行代码、存储状态并维持网络连接的基础设施。

这种组合正是关键张力所在。推理供应商一直在优化模型接收输入并生成输出的瞬间。自主 agent 还需要安全的计算环境，将这些输出转化为行动，有时需要贯穿持续数小时或数天的工作流。

Baseten 现在希望通过一个平台同时掌控这两个层面。这一战略促使推理竞争对手扩展至模型端点以外，同时也向 E2B 等专业沙盒供应商发起挑战。此前 Together AI 收购 CodeSandbox 也为这笔交易提供了明确的行业先例。

这项收购并不能证明一体化基础设施必然优于专业服务。Baseten 必须在不削弱任一产品的前提下连接两个复杂系统。客户则必须判断，更简化的运营是否值得承担依赖单一基础设施供应商的风险。

Baseten 收购了什么，以及最先发生哪些变化

Baseten 收购的是执行层，而非另一家模型服务公司。

Baseten 于 2026 年 9 月 10 日宣布收购。交易财务条款未披露，两家公司也没有公布完成技术整合的时间表。

收购公告称，Blaxel 将继续运营。现有客户将继续与原团队合作，同时产品会在过渡期间持续推出新功能。

Baseten 计划推出基于 Blaxel 底层技术的产品，首先从沙盒开始。沙盒是一种隔离的计算环境，agent 可在其中安全运行代码，并与获批准的资源交互。

这很重要，因为模型推理和 agent 执行解决的是不同问题。推理服务加载模型、处理请求并返回结果。agent runtime 则在软件解读该结果并决定下一步行动时，维持周边工作流的运行。

例如，一个研究 agent 可能调用多个模型、打开文件、运行脚本，并等待人工批准。它必须在空闲时保留工作状态，随后恢复，而无需重新构建整个环境。

编码 agent 的要求更高。它需要操作系统、依赖项、凭据、代码仓库访问权限，以及执行由模型生成的不受信任代码的场所。每项任务都必须与其他用户及敏感基础设施保持隔离。

Blaxel 为这些工作负载开发了基础设施。其 agent infrastructure包括隔离的 microVM 沙盒、持久化存储、网络控制以及对长时间运行进程的支持。microVM 是一种小型虚拟机，旨在兼顾强工作负载隔离能力和快速启动。

该公司称，暂停的环境可在约 25 毫秒内恢复，同时保留内存状态。它还宣称支持超过 50,000 个并发沙盒，以及最高 512 TB 的存储空间。

这些数字是 Blaxel 公布的产品主张，并非经过独立审计的收购指标。它们仍然说明了 Baseten 所看重的能力：一层围绕 agent 而非普通请求—响应应用构建的有状态计算层。

Blaxel 还支持持久化文件系统、托管网络出口、静态 IP 地址和模型路由。当 agent 需要访问私有 API、但又不能获得不受限制的凭据时，这些控制功能就变得至关重要。

Baseten 则带来了技术栈中的模型层。它提供推理、训练和后训练基础设施；后训练包括让已训练模型适应特定行为或任务的过程。

因此，首个可见的产品变化应当是与 Baseten 推理服务更紧密连接的沙盒。更深层的目标，则是构建一个协调模型调用、执行、存储和网络连接的共享系统。

这改变了 Baseten 的定位。它不再只为生成答案的工作负载而竞争，而是试图掌控答案转变为软件行为的环境。

为什么 Agent 工作负载会拉伸传统推理平台

推理结束后 agent 仍会保持活跃，因此执行基础设施成为产品体验的一部分。

传统 AI 应用可以向模型发送提示词并展示响应。其基础设施挑战主要围绕延迟、模型可用性、吞吐量和生成 token 的成本。

agent 则增加了一个行动循环。它接收目标、请求模型输出、调用工具、评估结果，并持续推进，直到完成任务或需要干预。

这个循环改变了失败的定义。模型端点可能成功返回指令，但周边任务仍可能因依赖项故障或网络请求超时而失败。

长时间运行的 agent 还会带来状态管理问题。工作流可能在等待人员、外部任务或计划事件时暂停。每次暂停后重新构建所有文件和进程，会增加延迟和工程工作量。

Blaxel 的持久化沙盒旨在保留这类工作上下文。Baseten 可以将它们部署在其推理服务旁边，减少每个 agent 循环涉及的供应商数量和网络边界。

仅靠物理邻近并不能保证性能更好。在客户获得有意义的改进之前，这些平台必须协调调度、身份验证、可观测性和故障恢复。

商业逻辑仍然直接。如果客户在别处组装其余的 agent 技术栈，推理供应商就有沦为可互换端点的风险。沙盒供应商面临相反的风险，因为推理平台可以将执行能力打包进更广泛的合同中。

Baseten 依托的资本基础远大于 Blaxel 独立运营时的规模。其 6 月发布的 Series F 更新披露了 15 亿美元融资和 130 亿美元估值。

Baseten 还表示，在此前一年中，其营收增长了 20 倍，推理量增长了 40 倍。这些数字直接来自公司，尚未获得独立公开验证。

这笔融资发生在其 2026 年 2 月宣布 3 亿美元 Series E 之后。Baseten 将后续融资描述为其 18 个月内的第四轮融资。

这种节奏为公司提供了收购技术、聘请基础设施专家并跨区域扩张的资源。同时，它也提高了外界预期：Baseten 应能从每位客户身上获取超出单纯推理业务的更多价值。

agent 为这种扩张提供了路径。一次 agent 任务可能涉及多次模型调用、反复的沙盒活动、保留的存储，以及与外部系统受控连接。

因此，同时拥有执行和推理能力可以提高 Baseten 在基础设施支出中的份额。它还可提供更多有关 agent 工作负载如何在推理与行动之间流转的运营数据。

这正是 Baseten 收购 Blaxel 背后的机制。Baseten 并非只是为其仪表板增加一项功能，而是在将控制范围延伸至自主工作负载的完整周期。

如果整合能减少配置工作并让故障更易追踪，开发者可能从中受益。企业买家则可能受益于整合后的安全策略、支持服务和区域部署选项。

同样的整合也可能形成依赖。围绕单一供应商的推理、存储、沙盒生命周期和网络原语设计的应用，比模型端点更难迁移。

这种权衡将决定采用情况。团队必须比较一体化控制平面的便利性，与组合专业组件所带来的灵活性。

Baseten 收购 Blaxel 将推理变成全栈竞争

这笔交易使安全的 agent 执行能力成为竞争要求，而此前各家公司主要围绕模型推理构建产品。

Baseten 的主要战略对手是模块化基础设施路线。在这种方式下，开发者选择一家推理供应商、另一家沙盒服务商，以及用于存储、可观测性和网络连接的独立工具。

模块化能够保护选择权。团队可在不迁移整个生产技术栈的情况下替换表现不佳的组件，也可选择适合特殊安全或性能要求的专业产品。

代价则是整合工作。工程师必须管理跨服务的身份验证、关联日志、在区域间移动数据，并在多个控制平面间定义恢复行为。

Baseten 正在押注，构建 agent 的团队会更偏好高度协同的平台。其推理调度器可以了解 agent 沙盒在何处运行、调用哪个模型，以及工作流必须保留哪些状态。

这种架构可减少服务间不必要的数据移动。它还可让 Baseten 围绕完整工作负载调优硬件分配，而不是只优化孤立的模型请求。

设想一个审查大型代码仓库的编码 agent。它可能生成补丁、运行测试、检查错误、修改依赖项，并请求另一模型审查结果。

模块化部署能够支持每一步。不过，工程团队必须决定沙盒状态如何在模型调用之间保留，以及工具使用期间如何保护凭据。

一体化部署可以在整个循环中提供统一的身份和监控系统。实际价值取决于 Baseten 是否能在不限制部署选择的情况下实现这种协同。

Baseten 表示，合并后的平台将把模型的“大脑”置于执行“肌肉”旁边。这一比喻概括了战略，但客户将依据启动延迟、故障隔离和策略执行等细节作出判断。

可观测性将尤其重要。当 agent 产生错误结果时，开发者需要还原涉及的模型输入、工具调用、文件变更和网络响应。

如果这些记录仍然彼此割裂，统一的商业平台就只能提供有限的运营价值。如果 Baseten 能可靠地关联这些记录，整合就不只是捆绑采购。

这项收购也改变了 Baseten 与独立沙盒公司的关系。Blaxel 此前曾与 E2B、Modal、Daytona、Northflank 和 Fly.io 的 Sprites 等服务竞争。

一些竞争者强调快速的临时执行，另一些则优先考虑持久化环境或在客户云端内部部署。正确的选择取决于工作负载持续时间、安全要求和预期并发量。

E2B 是一个有价值的比较对象，因为它将自身定位为围绕安全、即时计算环境构建的 agent cloud。根据 E2B 的时间线，其沙盒在 2026 年 6 月累计启动次数已超过 10 亿次。

E2B 还表示，在此期间，其软件开发工具包下载总量达到 6000 万次。这些由公司公布的指标表明，独立的 agent 执行已成为一个重要的基础设施类别。

Baseten 正在挑战这样一种假设：这一类别将始终独立于推理服务。其整合后的平台可以利用已与 AI 应用公司建立的商业关系。

Blaxel 带来了内部自行复制需要时间才能获得的专业能力。其团队从一开始便专注于持久执行、存储、网络和工作负载隔离。

此次收购使 Baseten 能够比自行构建所有组件更快推进。它也让 Blaxel 获得资本与客户分发渠道，这些是早期基础设施公司难以轻易建立的。

不过，整合并不会消除模块化路径。云原生团队仍可通过标准 API，将推理服务提供商与沙盒服务结合使用。

开放模型强化了这一替代方案，因为客户在不同提供商之间迁移推理服务，通常比迁移专有应用平台更容易。Baseten 必须让协同能力，而非单纯的可用性，成为整合的理由。

这种压力也延伸至模型服务竞争对手。Fireworks AI、Together AI、Modal 以及大型云平台，都必须决定希望掌控多大程度的智能体运行时。

它们可以开发执行产品、收购专业公司，或继续专注于推理，同时支持紧密集成。每种应对方式都伴随着不同的工程成本和生态系统影响。

Together AI 已经验证过整合打法

Baseten 正在遵循既有的整合模式，但市场尚未证明单一技术栈必然胜出。

Together AI 于 2024 年 12 月收购了 CodeSandbox。这笔交易将推理平台与可运行 AI 生成代码的云端开发环境连接起来。

CodeSandbox 表示，此次整合将让代码执行更贴近模型，同时保留其现有的社区产品。CodeSandbox deal 还推出了一个 SDK，用于创建和管理隔离环境。

Together 随后推出了 Code Sandbox 和 Code Interpreter 产品。其公布的规格包括可定制的 microVM、内存快照、持久化文件系统和基于会话的执行。

这与 Baseten 收购 Blaxel 背后的逻辑相似。两家收购方均起步于模型基础设施，随后加入可让生成代码安全运行的环境。

较早的这笔交易提供的是战略先例，而非已获验证的结果。产品公开可用并不能揭示客户留存、单位经济效益，或整合两套基础设施架构的难度。

尽管如此，Together 的行动为 Baseten 提供了一个竞争参照点。若继续等待，Baseten 可能会在竞争对手从生产级智能体工作负载中学习时，仍依赖外部沙盒供应商。

这些收购也揭示了基础设施公司预期价值将在哪些环节累积。模型 API 依然不可或缺，但智能体执行会在计算、存储和网络方面创造额外消耗。

这一转变从两个方向给专业供应商施压。超大规模云服务商可以提供通用虚拟机和托管 AI 服务，而推理初创公司可以构建更聚焦的智能体平台。

独立沙盒公司必须证明，专业化能带来足够的性能、可移植性或开发者体验，以抵御捆绑销售。如果客户拒绝基础设施锁定，其独立性也可能成为优势。

市场未必会收敛为一种架构。小型团队可能偏好整合服务，因为这能减少运维工作；大型企业则可能选择模块化组件，以保留供应商议价能力和部署控制权。

受监管工作负载带来了另一层分化。买方可能要求在自己的云账户内执行、保留详细审计记录、满足数据驻留要求，或使用私有网络。

Baseten 和 Blaxel 都讨论了安全性与区域可用性，但收购公告并未提供完整的企业级整合路线图，也没有说明现有 Blaxel 合同将如何随时间变化。

大型云服务商仍是重要的竞争力量。Amazon Web Services、Microsoft Azure 和 Google Cloud 已将模型访问能力与广泛的计算及安全服务结合起来。

这些平台无需收购一家专门的沙盒初创公司，也能支持智能体工作负载。不过，开发者仍需将许多通用服务组装成面向智能体的架构。

Baseten 的机会在于将这一架构作为连贯的产品提供。其挑战是，在企业控制能力上匹敌云服务商，同时在工作负载针对性的速度和易用性上超越它们。

该公司还与直接基于开源虚拟化工具进行构建的团队竞争。Firecracker、gVisor 和容器隔离技术让经验丰富的组织能够搭建定制执行层。

购买托管平台会将大量运维负担转移给供应商。自行构建则保留控制权，但需要具备调度、安全、容量规划和事件响应方面的专业能力。

因此，这场竞争远不止基准延迟。买方将比较部署灵活性、可靠性、调试能力、安全边界，以及运行智能体所需的总体人力投入。

最强的信号将来自生产迁移。如果客户将分散的推理和沙盒供应商整合至 Baseten，整合论点便会更具可信度。

如果客户仅将 Baseten 的新沙盒用于实验，这项收购看起来就更像防御性的功能扩展。Baseten 需要持续运行、同时覆盖平台两侧的工作负载。

整合风险位于模型与机器之间

Baseten 必须证明，合并两款产品能降低运维复杂度，而不是把复杂度隐藏在一份合同之后。

基础设施收购在产品架构图层面往往看起来很清晰。真正困难的工作出现在身份系统、计费指标、部署区域、服务限制和支持流程中。

Baseten 和 Blaxel 在交易前很可能做出了不同的架构决策。它们必须在不干扰任一平台现有运行应用的前提下协调这些决策。

公开公告承诺将保持 Blaxel 客户服务的连续性。这令人安心，但如果 Baseten 需要统一账户或网络，连续性可能与快速整合发生冲突。

分阶段推进可以降低迁移风险，但也可能延迟收购所应带来的优势，使客户面对的仍是两个相邻产品，而非一个协同系统。

安全性带来的风险最高。智能体沙盒通常执行开发者并未编写或审查的模型生成代码。

隔离机制必须遏制恶意软件包、意外文件访问、失控进程，以及访问未经授权网络资源的尝试。持久状态又增加了一层担忧，因为敏感数据可能会跨会话持续可用。

microVM 边界可以改善隔离，但不能解决所有应用层问题。智能体仍可能滥用应用程序有意提供的凭据。

开发者需要精细化权限、受控的网络出口、密钥注入和完整的活动记录。Baseten 必须说明这些控制措施如何贯穿模型调用和执行环境。

当单个工作流依赖这两个层级时，可靠性也会变得更难保障。如果沙盒不可用，即使模型端点正常工作，也无法完成任务；反之亦然。

客户需要反映组合工作流的服务级承诺。单独的可用性数字可能掩盖至少一个必需组件发生故障的概率。

容量规划构成另一项考验。推理工作负载消耗昂贵的加速器，而许多沙盒任务依赖 CPU、内存和存储。

Baseten 必须在不同区域高效调度这些资源。过度配置会损害经济性，而容量不足则会在智能体恰需行动时造成启动延迟。

该公司称 Blaxel 专为毫秒级配置和持久执行而设计。这些说法需要在持续的客户工作负载下得到验证，而不只是通过短暂演示。

单位经济效益仍未披露。Baseten 没有公布收购价格、Blaxel 的营收或预期财务贡献。

reported deal terms 仅确认财务细节未被披露。因此，买方无法评估这笔交易反映的是强劲需求、战略紧迫性，还是两者兼具。

对于私有公司的收购而言，未披露财务信息属正常情况。但这依然限制了外界对 Baseten 如何激进地评估执行层价值的判断。

客户锁定也是合理担忧。采用专有沙盒生命周期控制的开发者，日后可能面临大量迁移工作。

可移植的容器镜像有所帮助，但不会自动迁移内存快照、网络策略、存储状态或可观测性历史。Baseten 应明确哪些层级采用开放格式和标准接口。

评估该平台的团队应在提交敏感工作流前测试退出路径，并记录依赖关系、导出要求和被中断任务的行为。

他们还应保留自己的运营知识。一套可搜索的知识库可以在供应商变更期间保存架构决策、事件记录和迁移假设，以便随时查阅。

这些风险都不会否定这项收购。它们界定了将战略公告转化为可靠基础设施所需完成的工作。

Baseten 拥有资本、推理经验，以及一支专注于智能体执行的收购团队。尚未解决的问题是，这些资产能否成为开发者可以信赖的统一系统。

三个信号将揭示全栈模式是否奏效

产品整合、客户采用和竞争对手反应，将决定 Baseten 的扩张能否形成持久的平台优势。

第一个信号是 Baseten 基于 Blaxel 技术构建的首个沙盒版本。该公司已将沙盒确定为起点，使这款产品成为检验执行与推理协同的最早测试。

该版本应明确客户是否会获得一个账户、一个身份模型、共享的区域部署，以及关联的可观测性。若只是更名的 Blaxel 界面，则代表整合程度有限。

开发者还应关注 Baseten 如何处理持久状态与网络。这些特性对长期运行的智能体而言，比针对启动时间的狭义优化基准更重要。

若发布版本提供统一的策略与调试能力，将强化 Baseten 的论点。若仅提供基础沙盒 API 且运维控制仍然分离，则会削弱这一论点。

第二个信号是现有 Baseten 客户的采用情况。根据其融资公告，该公司服务的 AI 应用开发商包括 Cursor、Notion、Harvey、Abridge 和 Decagon。

这些名称不应被解读为已确认使用 Blaxel 基础设施的客户。Baseten 尚未公开说明哪些客户将采用整合后的平台。

同时使用推理和持久沙盒的生产工作负载证据将具有重要意义。案例研究应包括工作流时长、故障恢复、安全配置以及可量化的运维变化。

开发者活动可以提供更早的指标。文档深度、软件开发工具包采用情况、社区示例和支持讨论，能够揭示整合产品是否解决了真实问题。

最有力的验证将来自客户整合。若团队用一体化方案替代原本分别采购的推理与执行服务，就能证明这种整合确实创造了足以改变架构的价值。

第三个信号来自竞争对手的反应。Together AI 已通过 CodeSandbox 构建了相关技术栈，而 E2B 仍专注于智能体计算环境。

Fireworks AI、Modal 和云服务商可能会通过推出新的执行产品或建立合作伙伴关系来应对。它们的决策将显示，Baseten 究竟发现了一个必要的平台层，还是仅仅增加了一项可选功能。

收购将进一步强化整合论点。独立服务商之间更强的互操作性，则会支持模块化这一替代路径。

由于工作负载结构差异很大，价格不应主导早期比较。采购方应关注完整智能体任务中的可靠性、安全边界、可移植性，以及工程投入。

Baseten 收购 Blaxel 之所以重要，是因为它将此前相邻的服务纳入了 Baseten 的核心平台战略。该公司押注于：生产级智能体需要协同设计的推理与执行能力。

这一押注尚未得到验证。Baseten 必须将 Blaxel 的持久化环境转化为能够与其模型基础设施自然协同、并经受严苛生产环境考验的服务。

在下一个产品周期中，开发者和企业采购方应提出一个实际问题：这套组合系统是否消除了他们目前需要跨多个供应商完成的工作？

如果答案能够被量化，Baseten 就能从推理服务商转变为智能体基础设施平台。如果不能，专业化服务仍将保有其最有力的论据。

未来三个月应会揭示首批产品细节、客户部署情况和竞争性回应。这些信号将表明，集成式智能体 AI 基础设施会成为一个持久品类，还是另一项捆绑功能。