摘要

  • Ion Stoica 是 UC Berkeley 教授、Sky Computing Lab 主任，也是 Conviva、Databricks 和 Anyscale 的联合创始人；Databricks 将其列为执行董事长。
  • 他的研究一再把分布式状态置于更简洁的接口之后，从 Core-Stateless Fair Queueing 和 Chord，到 Mesos 的资源邀约、Spark 的血缘机制、Ray 与 SkyPilot。
  • 这些系统由学生、教师、工程师和开源贡献者组成的团队共同创建；Stoica 在其中分别担任过合著者、导师、实验室主任和公司联合创始人。
  • 这些抽象降低了编程与运营负担，却没有让网络、加速器、云、价格或治理变得统一；成功的抽象还会形成新的控制平面和依赖关系。

分布式系统始于一场关于状态应置于何处的争论

人们常通过集群、调度器、存储系统、云和加速器等技术设施来描述分布式计算。这些产品之下存在一个更持久的设计问题：系统的哪个部分必须记住什么，哪些参与方可以在看不到全局的情况下行动？

把所有状态集中在一处，会让决策更容易理解，直到决策者负载过重或无法使用。分散状态可以提高规模和韧性，却会带来不一致、协调成本和棘手的故障模式。用接口隐藏问题可以帮助程序员，但隐藏的工作不会消失，而会成为控制平面的责任。

从这种张力来看，Ion Stoica 的研究脉络格外连贯。Core-Stateless Fair Queueing 把流量估算移向网络边缘，并在数据包中携带信息，使核心路由器不必为每次通信维护一张表。Chord 把节点和键映射到一个环中，使参与节点无需维护全局目录也能定位数据。Internet Indirection Infrastructure 使用会合标识符，使通信不再绑定固定的目的地址。Mesos 把资源提供给应用框架，而不是强迫一个调度器理解所有工作负载。Ray 向应用公开任务和 actor，同时在应用之下管理放置与故障恢复。

这些系统的用途和成熟度各不相同。有些成为广泛用于教学的协议，而非通用基础设施；有些成为开源项目；还有数个系统构成了公司的技术根基。它们共同采取的做法，是在直接协调成本过高的边界上建立一个小型、可扩展的契约。

这种连续性使 Stoica 成为观察现代基础设施的一个有用视角，但也会造成归功误区。指导项目的教授、塑造算法的合著者、为团队筹措资金的实验室主任，以及帮助创办公司的创始人，做的并不是同一项工作。Spark 与 Matei Zaharia 及 AMPLab 社区密不可分。Ray 的主要作者包括 Philipp Moritz、Robert Nishihara 和更广泛的 RISELab 团队。Databricks 列出七位联合创始人。Berkeley 的实验室贡献了学生、员工、代码和不属于任何个人的机构文化。

真正值得关注的故事，并非一个人独自创造了一系列成功平台，而是一个研究计划如何反复识别复杂性正在何处积聚，继而建立一种足够精简、可供社区使用，又足够宽广、可让产业围绕其成长的抽象。

早期公平性研究揭示了把状态移向边缘的代价

Stoica 在布加勒斯特完成早期学业后，于 2000 年在 Carnegie Mellon University 获得博士学位。他的研究生工作直面了共享基础设施建设者熟悉的问题：当系统跟踪每个用户时，更容易实现公平，但跟踪所有用户又可能阻碍系统扩展。

如果路由器为每个流维护单独的队列和速率估算，就能作出细粒度决策。在繁忙的核心网络中，流的数量可能极其庞大，成员变化也很快。逐流状态会在数据包处理必须保持高速的位置消耗内存、处理能力和运营精力。

Dynamic Packet State 和 Core-Stateless Fair Queueing 探索了另一种分工。边缘设备估算流的速率，并把信息写入数据包。核心路由器可以根据该标签作出概率性丢包决定，而不必维护完整的流表。核心并非真的无状态；它仍保留汇总配置并执行算法。它只是不保存与单个流相关的状态。

这一设计体现了贯穿 Stoica 职业生涯的模式。复杂性没有被消除，而是被移到被认为拥有更多上下文或容量的边界。边缘必须对流量分类并给出可信估算，数据包必须以核心能够理解的形式携带信息。如果边缘说谎或测量不准，核心的近似判断就可能出错。封装和加密也会让“流”的定义更复杂。

因此，评价一种抽象时，应看它重新分配了哪些责任。核心无状态公平机制可以让中心更简单、更易扩展，同时建立起对边缘的信任关系。这种权衡在受控网络内可能很有吸引力，但在政策或激励不一致的组织之间会更加困难。

这项工作没有成为公共互联网通用的服务质量架构。它的重要性部分在于方法：找出使机制变得昂贵的状态，判断在哪里能以更低成本表达这种状态，并说明迁移过程中损失了何种精度或信任。

后来的系统把同样的推理用于键、集群资源、数据血缘和 AI 任务。处理单元变了，架构直觉没有变。

Chord 把不断变化的点对点系统化为一个环

21 世纪初的点对点研究热潮催生了许多系统，其中的机器会加入、离开和发生故障，却没有一个知道所有位置的中央目录。在这种环境中寻找特定对象，既是查找问题，也是维护问题。设计既要回答今天的查询，也要持续修复明天所需的信息。

Chord 由包括 Stoica、David Karger、Frans Kaashoek、Robert Morris 和 Hari Balakrishnan 在内的团队于 2001 年在 SIGCOMM 发表，给出了一个刻意保持精简的答案。它把节点和键散列到同一标识符空间，将其排列成逻辑环，并把每个键分配给后继节点。参与节点保存其直接后继的信息，以及一组数量呈对数增长、跨度更远的“指针”。查询沿着逐步接近目标的标识符移动，直至到达负责该键的节点。

一致性哈希限制了成员变化时需要迁移的数据量。稳定化过程会在节点频繁加入或离开后修复后继与指针信息。该设计没有让每个参与节点了解整个网络，而是向每个节点提供足够的结构化知识，使其能够高效路由查询。

Chord 成为经典教学案例，是因为其机制既足够紧凑、便于推理，又足够丰富，能够呈现分布式系统的现实。标识符距离不等同于网络时延；逻辑上相邻的节点在物理上可能相距很远。复制、访问控制、存储一致性和针对恶意参与者的防御，都不在基础查找协议之内。应用仍须决定键代表什么，以及如何处理不可用或相互冲突的数据。

不应把论文的影响力等同于某项生产服务，也不应归功于一人。Chord 是团队成果，后来的分布式哈希表发展出了其他结构和安全属性。公共互联网的大部分也没有重组为一个 Chord 环。

它持久的启示在于有限知识。如果覆盖网络在名称与责任之间提供稳定关系，参与节点就能在庞大而不断变化的系统中导航。这个环在仍然不可靠、连接状况不一的机器之上形成了一种控制抽象。

这一思想后来以不同形式出现在云控制平面中。应用很少了解每台主机，而是依赖调度器、元数据服务或对象目录，把逻辑请求映射到当前资源。Chord 在去中心化最受关注的时代明确提出了映射问题。后来的系统为提高性能而集中控制平面的部分功能，同时保留同样精简的应用接口。

Internet Indirection Infrastructure 放松了地址与端点的绑定

互联网路由通常把数据包发往目的地址。当接收方移动、多个接收方需要获得同一数据，或服务希望在多个可能的端点间作出选择时，这种模型就会变得笨拙。Internet Indirection Infrastructure（即 i3）探索了 IP 之上的一层：发送方把数据发往标识符，接收方则安装触发器，把这些标识符绑定到当前位置。

会合点把应用使用的名称与当前能够接收流量的地址分离。同一种机制可以表达移动性、组播、任播和服务组合。接收方只需更新触发器即可改变位置，不必要求所有发送方学习新地址。

这种抽象十分优雅，因为它用一种间接寻址机制复用了多种网络功能。其困难在于，间接寻址基础设施本身变得至关重要。节点必须可达、性能可靠并受到防滥用保护；标识符需要认证和政策约束；通过覆盖网络路由还可能增加时延，或形成一条忽视底层网络经济条件的路径。

i3 没有大规模取代普通互联网路由，但这并不说明研究失败。它展示了表达力强的机制与可部署的制度安排之间反复出现的差异。公共会合层需要运营方、激励机制、安全保障和迁移路径。现有互联网已经拥有地址分配、DNS、内容分发系统和针对具体应用的变通办法，每一部分背后都有既有参与方。

Stoica 围绕 Chord 和 i3 的工作表明，不必更换每台路由器，也能在网络之上创建新的控制点；同时也表明，新控制点必须受到治理。软件可以分发标识符，但仍需要有人运营节点、制定滥用规则并承担容量成本。

这种经验与今天的多云系统有关。把工作负载映射到供应商的代理工具看起来不同于会合覆盖网络，却面临同一个制度问题。抽象可以重定向请求，但无法让不同选择变得等价，也无法保证中间方始终中立。

Berkeley 把开源社区纳入研究方法

Stoica 加入 University of California, Berkeley 后，其工作融入了一种实验室模式：结合教师引导、学生主导的系统建设、同行评审研究和早期开源发布。随着研究议程演变，实验室名称从 AMPLab、RISELab 变为如今的 Sky Computing Lab，但方法仍清晰可辨。

研究系统不仅要孤立地演示算法，还应处理真实工作负载。学生构建完整度较高的实现，用户开始使用，运营反馈再返回实验室。这条路径扩大了影响，也为创办公司创造了条件，同时模糊了学术发明与商业产品之间的简单界线。

教师贡献研究问题、资金、指导、架构判断和机构连续性。学生和员工常常负责写代码、运行实验，并成为推动系统继续发展的维护者或创始人。产业合作方提供工作负载、硬件和约束条件。开源贡献者则在论文发表后继续改变项目。成功成果属于这张角色网络。

Stoica 在多个项目中的知名度可能掩盖这一结构。他在 Spark 的学术历程中担任导师和合著者，但 Matei Zaharia 主导了最初工作，并成为关键技术人物和公司人物。Ray 源于 Philipp Moritz、Robert Nishihara 及更广泛团队的工作。Mesos 也有多位主要设计者。准确叙述并不会削弱 Stoica 的作用，而是说明实验室领导工作究竟包含什么。

Berkeley 模式还孕育了一类特定公司。Databricks 和 Anyscale 并不是先隐藏协议、再出售访问权，而是围绕用户已经可以自行运行的开源系统成立。商业机会在于让这些系统更易于大规模运营、集成和支持。

这种安排形成了持久张力。开源可以扩大采用范围并建立共享技术基础；托管平台可以为工程投入提供资金并降低客户负担；公司有动力围绕开放核心增加专有控制、集成和商业机制。学术实验室重视发表和通用性，公司则重视可靠性、差异化和收入。

Stoica 的职业生涯正处于这一转折点。他的重要性与其说在于论文变成初创公司，不如说在于实验室反复选择能够在实验室之外存续的抽象，并建立把它们带入生产环境的机构。

Chord、Spark、Mesos 和 Ray 的传播不仅依靠代码，也依靠一套词汇。环、血缘、资源邀约、任务和 actor，为工程师提供了描述分布式行为的概念。如果团队无需先掌握每个内部组件就能理解一个系统，它会更容易被采用。

大学工作是这一过程的核心。论文定义机制和假设，课程与研讨会把它们转化为共享的思维模型，学生再把这些思想带入公司、开源项目和后续研究。因此，Stoica 作为教授和实验室主任的影响超出了他署名的代码或创始人头衔。

这些词汇也可能固化为教条。简洁的示意图会让用户忘记抽象成立的条件。Chord 的环可能掩盖物理时延，Spark 的血缘可能掩盖重新计算的成本，actor 看起来可能像普通对象，实际却会遭遇消息延迟和分布式故障。良好的教育既要讲解接口，也要讲清抽象泄漏之处。

Stoica 于 2024 年当选 National Academy of Engineering 院士，是对其在分布式与云系统领域累积成果的认可。这项荣誉不会重新分配合作者的贡献，而是肯定一位研究者所发挥的作用：他帮助把多个困难的系统边界表达得足够清晰，让他人能够继续建设。

这可能是基础设施影响最持久的形式。产品会改名，公司会扩展，但清晰的抽象可以存续，因为一代代工程师能够使用它、批评它，并识别其假设何时不再成立。

Conviva 检验了分布式系统研究能否改善一次视频会话

Stoica 于 2006 年联合创办 Conviva，早于后来那些源自 Berkeley 的数据和 AI 公司。该业务处理了一个连接网络、测量和应用体验的问题：流媒体质量取决于一条没有任何单一参与方能够完整看到的链路。观看者的连接、内容分发路径、播放器行为、设备和内容提供方，都可能影响卡顿和启动时间。

测量平台可以收集会话证据，帮助服务选择或调整交付方式。它与 Stoica 研究的概念联系，并非某个 Chord 或 i3 算法直接变成产品，而是分布式观察结果必须足够快地转化为控制决策，才能影响体验。系统必须根据不完整数据作出推断，并跨越自身并不拥有的网络运行。

Conviva 的成立展示了学术系统思维转化为商业服务的一条早期路径。客户购买的不是关于分布式状态的论文，而是围绕流媒体的可见性、分析和运营行动。公司必须在真实流量下维护数据处理流程、集成和模型，再向负责内容与交付的团队解释结果。

归功边界仍然重要。Conviva 是一家拥有众多工程师和高管的公司，不能把当前产品归于一位创始人。公司的财务表现和私人所有权也与 Stoica 的个人记录不同。这里真正相关的是时间与制度背景：在 Spark 或 Ray 成为公司基础之前，他已经帮助建立了一项把网络规模证据转化为应用服务的业务。

这段经历很可能强化了其后续工作中可见的一条经验：当基础设施改变客户能够管理的单位时，它才会产生价值。流媒体提供方不想分析每条数据包路径，而是需要可靠了解用户体验并找到改善方式。当抽象能把复杂的分布式行为转化为运营选择，同时又不假装底层不确定性已经消失时，它才算成功。

Mesos 把调度变成一场资源协商

随着数据中心把不同工作负载整合到共享集群，中央调度器面临一个不切实际的目标：要么试图理解每个框架的优先级、放置规则和执行模型，要么公开资源，让专用框架自行作出更多决定。

Mesos 选择了第二条路径。代理节点向主节点报告可用资源，主节点向框架发出资源邀约。框架接受邀约中的一部分，并按自身调度器的决定启动任务。工作完成或分配变化后，资源重新回到可用池。

这种两级设计使主节点成为代理方，而非无所不知的应用大脑。Hadoop、MPI 和其他框架可以共享集群，而不必放弃自己的调度逻辑。集群运营方通过分配、配额和公平机制保留政策控制；框架则负责判断哪些任务适合收到的资源。

这种分离提高了可扩展性，也带来新问题。框架可能作出糟糕的放置决定，或低效占用资源；资源邀约可能把集群切分为不适合大型作业的小块；不同资源类型之间的公平需要政策；主节点和代理节点仍须具备容错能力并可靠维护状态。

Mesos 影响了更广泛的编排领域，尽管容器平台和其他调度器发展出了不同的控制模型。把它的贡献视为一种架构主张，比宣称某个设计获胜更准确：共享基础设施可以通过分离资源分配和应用专用调度来扩展。

同样的主张也出现在 Stoica 的早期工作中。中心保留足以执行共同契约的状态，却避免按应用细节表达每个流或工作负载。智能被移向拥有更多上下文的一层，而层与层之间的接口决定系统能否保持一致。

对运营方而言，启示很实际。抽象不会消除政策，而是决定由谁实施政策。资源邀约给框架自由，也让框架行为成为影响集群效率的一部分。运营方不仅必须监测中央分配器，也要监测每个接受邀约的框架所作的决定。

Mesos 帮助确立了集群可以成为“平台的平台”这一理念。Spark 随后通过为数据应用提供更高层的抽象来利用这种环境。

Mesos 把分配描述为邀约，但邀约并非来自中立资源池。在框架看到资源之前，主节点已经应用了公平规则、配额和优先级。在云或 AI 集群中，这些选择决定哪个团队获得稀缺加速器，以及哪个截止期限会被延误。

这种抽象的价值在于，它把共同分配与工作负载专用调度分开，却也可能让蕴含组织权力的政策显得只是技术问题。配额反映预算和承诺；优先级类别决定哪些工作可以中断；预留通过牺牲当前利用率来保护未来容量。

即使接口发生变化，现代调度器也继承了同一个问题。自动放置应公开其目标和例外，而不应把自身选择呈现为唯一高效的答案。

Stoica 的系统研究历程表明，可扩展性往往来自把决策移到边界。治理则要求明确仍留在中心的决定：始终有人决定谁会收到资源邀约。

Spark 把丢失的中间数据视为可以重复的计算

Spark 之前的数据处理系统常把中间结果写入磁盘，以此作为阶段之间的持久边界。这种方法支持故障恢复，却会让迭代算法和交互式分析变得昂贵。Spark 的弹性分布式数据集（RDD）通过转换和血缘来表达分区集合。如果一个分区丢失，系统通常可以根据较早的数据重新计算，而不必复制每个中间结果。

这一思想把容错与编程模型结合起来。开发者可以表达对分布式集合的转换，运行时则跟踪每个分区如何生成。把工作数据保留在内存中，可加速反复访问同一数据集的工作负载。系统仍会进行混洗、读取存储并遇到数据倾斜；它没有让数据移动变得没有成本。

Spark 源于 Matei Zaharia 与 Berkeley AMPLab 社区的工作，Stoica 和许多合作者也参与其中。后来，Spark 扩展至 SQL、流处理、机器学习和广泛的数据平台，这一演进涉及规模大得多的开源社区。把它描述为 Stoica 的个人发明，会抹去那些主导并维护该系统的人。

他的作用主要体现在机构层面。实验室支持该项目，帮助界定系统问题，并把研究与用户连接起来。Databricks 于 2013 年成立时，Stoica 成为七位联合创始人之一。对于希望使用 Spark 能力、又不愿自行组装整套运营技术栈的组织，Databricks 提供了一条托管路径。

商业平台后来远远超出了最初的 RDD 论文。数据治理、湖仓架构、机器学习、AI 服务、安全和云集成都成为产品的一部分。公司的当前规模不能用来精确衡量一篇论文或一位创始人的贡献。

不过，Spark 仍标志着 Stoica 职业生涯的一个转折点。抽象的核心不再主要是网络数据包或点对点查找，而是程序员看到的数据对象，以及运行时看到的恢复计划。血缘使系统能够把机器故障隐藏在一段确定性的转换历史之后。

这种转变也形成了新的控制。运行时决定放置、执行和重新计算；托管服务可以决定版本、存储集成和成本。编程变得更容易，同时也加深了对实现这种便利的层的依赖。

Alluxio 表明数据位置可能主导计算抽象

Tachyon 后来更名为 Alluxio，它从 Berkeley 系统研究环境中诞生，是一个旨在让数据可供多个计算框架使用的分布式存储层。其设计利用内存和血缘思想来加速访问，同时连接应用与底层存储系统。项目和公司由各自团队与治理机制发展，但在更广泛的实验室控制平面研究中占有一席之地。

集群调度器可以把任务放到可用机器上，但如果数据位于别处、网络成为瓶颈，这种放置就很糟糕。数据抽象可以通过提供统一命名空间并管理缓存或移动来减少这种摩擦，但它不会让所有存储系统变得相同，也不会消除一致性和持久性选择。

该项目说明一种抽象如何暴露出对另一种抽象的需要。Mesos 在多个框架间共享计算资源，Spark 让分布式集合可编程，公共数据层则处理在引擎和存储之间移动工作集的成本。随着技术栈增长，可能在局部性、淘汰和恢复问题上相互冲突的控制平面也越来越多。

对运营方而言，这提醒人们不能逐层孤立地优化资源利用率。调度器可能显示 CPU 分配率很高，而作业仍在等待数据；内存缓存可以提升速度，却会占用另一项工作负载所需的容量；血缘可以恢复丢失的分区，但重新计算可能要读取远程存储，并造成网络流量激增。

不应把 Stoica 视为 Alluxio 的唯一创建者。该项目的相关性在于概念层面：Berkeley 的项目组合反复发现这样一些缺失接口——各系统单独看都可编程，放在一起却效率低下。每个新层都会让整体更易使用，同时引入又一个必须管理其故障和政策的有状态服务。

Databricks 把开源采用转化为商业运营责任

研究论文可以描述一种机制，并在选定工作负载下评估它。公司却必须支持成千上万名客户，而他们的数据、安全要求和故障模式都与论文测试环境不同。Databricks 是 Stoica 经历中最清晰的制度扩展示例。

公司由包括 Ali Ghodsi、Matei Zaharia、Ion Stoica 和其他 Berkeley 同事在内的一群人创立。公司当前资料将 Stoica 列为联合创始人兼执行董事长。这一职位不同于首席执行官、项目维护者或每项产品的作者，主要涉及公司治理和长期战略，而非每项服务的具体运营。

商业化 Spark 不只是托管一个开源二进制文件。客户需要集群配置、升级、身份集成、数据访问、性能诊断、合规和可预期的支持。随着产品扩展，公司形成了一个平台，其价值和锁定效应已无法简化为 Spark 本身。

这是开源基础设施公司的常见经济逻辑。共享项目降低采用成本，原则上也给用户保留退出路径；托管服务则通过简化运营，并增加可能无法顺利迁移到其他地方的能力来获得收入。客户提高了生产力，同时接受了与供应商之间的依赖关系。

Stoica 的研究主题有助于解释这种模式的吸引力。有用的抽象让客户专注应用，而不是机器。商业平台把这一承诺扩展到采购、安全和生命周期管理。隐藏的系统变得更庞大，供应商决策的后果也变得更重要。

估值和融资轮次不是衡量技术贡献的可靠证据。它们变化很快，并且属于公司，不能自动归于某位创始人。可辩护的结论应更克制：Databricks 表明，当一个组织承担维持可靠性所需的工作后，学术控制抽象可以成为大型企业平台的中心。

这种组织能力与原始软件同样重要，也意味着平台未来不仅受研究理念影响，还会遵循客户经济条件和公司激励。

Ray 把任务和 actor 变成 AI 运行时的基本单位

机器学习应用产生了难以整齐纳入批处理数据引擎的执行模式。强化学习、模拟、超参数搜索和模型服务可能同时包含短任务、长期存在的有状态组件和细粒度依赖。开发者需要一种表达这种混合模式的方法，而不必为每个项目都构建定制分布式系统。

Ray 公开了两个主要编程概念。远程函数变为分布式任务，类可以变为 actor，即接收方法调用并在多次操作之间持续存在的有状态进程。对象存储和控制组件在这些接口之下管理数据与调度。应用可以描述工作图，运行时则在集群中放置执行并从故障中恢复。

这种架构没有消除分布式问题。只有应用语义允许时，任务才能重试；actor 可能在故障时留下需要重建的状态；对象占用内存并跨网络传输；调度决定还会与加速器、放置组和数据局部性相互作用。Python 接口使这些问题更容易处理，却没有让它们变得无关紧要。

Ray 于 2018 年发表的 OSDI 论文是 Berkeley RISELab 团队的成果，主要作者包括 Philipp Moritz 和 Robert Nishihara。该项目形成了开源社区，数位贡献者后来与 Stoica 一同成为 Anyscale 的联合创始人。归功边界很重要，因为 Ray 的实现和当前路线图早已超出一位教师导师的工作。

Ray 展示了状态位置的又一次转变。应用命名任务、actor 和对象，而不是机器。运行时的全局控制与本地调度组件维护足够的信息，以放置工作并从故障中恢复。程序员放弃直接控制主机，以换取更实用的组合单位。

这种交换在 AI 领域很有吸引力，因为工作负载变化迅速，加速器集群又很昂贵。它也有风险，因为运行时成为运营事实的来源。调度器缺陷、对象存储压力或版本不兼容，可能同时影响多个应用。即使 API 没有提及，可观测性和升级纪律也会成为编程模型的一部分。

因此，Ray 的重要性并不在于让分布式 AI 变得简单，而在于通过共同概念使一大类分布式 AI 应用变得可编程，同时把困难工作集中到组织必须学会运营的运行时中。

Anyscale 商业化了 Ray，但并不等同于 Ray 社区

Anyscale 于 2019 年成立，是一家围绕 Ray 建立的商业公司。这种关系类似较早的 Spark 与 Databricks 路径，但二者并非同一组织，也不面向同一市场。Ray 仍是一个拥有公司外部贡献者和用户的开源系统；Anyscale 则提供托管运营、企业集成和支持。

这种区别对客户很重要。项目版本受维护者和贡献流程治理，托管服务则遵循产品路线图、服务条款和商业优先级。代码可能在两者间流动，但一方并不能自动证明另一方的能力或政策。

托管 Ray 可以显著降低运营负担。集群配置、自动扩缩、镜像管理、日志和故障恢复，都需要许多应用团队不愿自行承担的工程工作。供应商可以把这些工作标准化，并复用服务不同客户所积累的经验。

这项服务也在用户与底层云之间增加了一个控制层。它决定如何封装运行时、支持哪些功能，以及如何处理遥测和升级。客户可能仍能独立运行 Ray，却会逐渐依赖托管服务周围积累的工作流程、集成和运营知识。

Stoica 的联合创始人身份把研究系统与这一商业机构连接起来，但并不意味着他目前负责每一项产品决定；具体运营职务应以公司当前页面为准。稳定的事实是，在项目转向生产使用时，他参与创办了这家公司。

战略问题在于，商业层究竟会通过资助维护和扩大采用来增强开放运行时，还是会让最有价值的运营能力难以在其他地方复制。这两种情况可以同时发生：开源代码可能保持健康，客户仍可能发现更换托管平台的成本很高。

这种张力并非 Ray 独有的缺陷，而是成功抽象带来的经济后果。一旦接口吸引用户，组织就能围绕消除接口之下残留的运营痛点建立业务。客户必须决定愿意忘掉多少这样的痛点。

Sky computing 在仍有差异的云之间进行协商

Sky Computing Lab 把抽象问题扩展到单一集群或供应商之外。理论上，云应用可以根据价格、加速器可用性、数据位置或韧性，在多个区域和供应商之间选择。实际中，各家云提供不同的服务、身份体系、网络、配额和计费方式。迁移工作还可能产生出站费用和漫长的传输时间。

SkyPilot 是这一研究议程中的一个项目。用户可以描述作业和资源需求，工具随后帮助选择云与区域、配置资源并执行工作负载。接口可以根据掌握的信息搜索可用加速器并比较成本，从而减少为每个供应商分别编写部署流程的需要。

该系统无法把云变成可互换的商品。同一种加速器周围可能配有不同的网络或存储；托管数据库或身份服务可能在别处没有直接等价物；数据重力可能压过计算价格；出站费用和合同承诺会改变表面上最便宜的放置方案；账面存在的配额也可能在作业启动时无法使用。

跨云放置还会形成新的信任边界。代理工具需要多个环境的凭据，并根据某些假设作出成本和可用性决定，而这些假设应当可见。工具故障可能阻塞多个供应商上的工作负载，尽管这些供应商原本彼此独立。

如果把 sky computing 视为一个议价和可移植性层，而不是“全球只有一朵云”的承诺，其主张最有说服力。拥有经过测试的部署路径，用户就能应对资源短缺和价格变化；如果应用依赖专有服务，即使批处理作业本身可移植，用户仍会受到限制。

Stoica 当前的研究职位把早期分布式查找和集群调度工作，与这种市场结构连接起来。现在的分配单位是由不同公司拥有的加速器集群，控制平面除了 CPU 和内存，还必须考虑资金、监管和组织政策。

这一挑战格外清楚地揭示了抽象的边界。软件可以提供共同请求，但无法消除合同、网络距离或电力约束造成的资源差异。好的控制平面应帮助用户理解这些差异，而不是等到账单或故障发生时才暴露它们。

vLLM 和 Chatbot Arena 把实验室带到 AI 基础设施的中心

Stoica 当前的 Berkeley 页面列出了 vLLM、Chatbot Arena、SkyPilot、Ray 和 Spark 等项目。这份清单显示了 Sky Computing Lab 研究议程的广度，但不应被理解为实验室主任亲自设计了每个系统。

vLLM 处理大语言模型推理问题，在这一领域，加速器内存和调度决定系统能够服务多少请求。高效的键值缓存管理和连续批处理等技术可以提高利用率。该项目拥有自己的主要作者、维护者和社区。它与 Stoica 的联系体现在机构层面：项目属于他领导的研究环境，也是让昂贵 AI 资源变得可编程这一广泛尝试的一部分。

Chatbot Arena 利用人类偏好比较评估模型输出，在供应商经常选择性发布基准测试的市场中提供共享证据。该平台也面临抽样、代表性、滥用和治理问题。排名只是来自特定人群和特定时期的观察结果，并非对智能或安全性的永久衡量。

这些项目共同说明控制平面问题如何扩大。运行时必须放置工作，推理引擎必须分配内存和批量处理请求，评估平台必须分配人类注意力并保护比较的完整性。每一项都通过接口把稀缺资源转化为服务。

实验室模式再次发挥关键作用。项目可以公开发布、吸引产业用户，随后支持公司或独立机构。教师领导者可以连接主题和资金，而不抹平作者归属。因此，最好把实验室理解为孕育系统的环境，而不是把全部功劳转给主任的品牌。

AI 提高了利害程度，因为资源成本格外显眼。利用率的小幅提升就可能改变运营方所需的加速器数量，调度错误则可能让昂贵机器闲置，一项基准测试甚至可能改变投资方向。现在的抽象不仅影响软件生产力，也影响资本配置。

因此，Stoica 当前的工作是延续，而非突然转向 AI。机器变了，反复出现的问题没有变：什么接口能让众多用户共享稀缺的分布式系统？又是哪种隐藏的权力决定如何共享？

Kubernetes 划分了控制问题，而非取代 Mesos 或 Ray

现代基础设施讨论常把编排系统视为争夺唯一胜者的竞争者。考察它们各自的控制单位会更有意义。Kubernetes 通过声明式集群模型调度和管理容器与服务；Mesos 向框架提供资源；Ray 管理应用层任务、actor 和对象，并且经常运行在 Kubernetes 已经配置好的基础设施上。

这些系统可能重叠，但提出的不是同一个问题。容器编排器可以确保 Ray 头节点和工作节点集群正在运行，Ray 仍要决定应用任务在哪里执行，以及如何放置有状态 actor。云调度器还可能在这两个系统启动前先选择区域。它们构成的是控制平面的层级，而不是清晰的替代关系。

这种层级可以发挥作用，因为每一层各有所长；也会让诊断变得困难，因为任务缓慢可能来自应用调度、容器限制、节点压力、网络拥塞或云容量。多个层级的自动扩缩器可能响应同一个信号并同时过度调整。资源请求在沿技术栈向下传递时也可能转换失真。

Stoica 的工作有助于解释这种分层架构为何持续存在。一个通用调度器必须同时理解硬件分配、服务生命周期、框架语义和应用依赖。分离决定可以让每个系统独立演进，代价是需要协调。

组织选择平台时，不应追逐潮流。真正的问题是每项决定应由哪一层负责，以及如何发现冲突。在 Kubernetes 上运行 Ray，可以结合成熟的基础设施管理与应用运行时，但也要求团队同时理解两者。运营负担已经从编写调度器，转移为治理调度器之间的边界。

AI 调度也是资本配置决定

当前 AI 工作负载改变了 Stoica 长期研究问题背后的经济条件。CPU 集群即使浪费资源，仍可能完成有用工作；大型加速器集群十分昂贵，糟糕的放置、闲置内存或停滞的集合通信会立刻造成财务与能源后果。

Ray 等运行时或 vLLM 等推理引擎可以通过更紧密地安排工作、共享状态并适应需求来提高利用率。跨云工具还可以搜索稀缺加速器。这些决定配置的不只是机器时间，也决定哪家供应商获得支出、数据流向何处，以及会用到哪些电力和网络约束。

这使性能证据具有政治和商业影响。偏向某种加速器或调度器的基准测试可能改变采购方向；不透明的放置算法可能把敏感数据发往组织并未打算使用的区域；成本优化器可能选择每小时价格较低但网络较慢的实例，延长作业时间并增加总能耗。

因此，控制平面需要比吞吐量更丰富的目标，可能包括截止期限、容错、数据位置、碳强度、预留承诺和中断成本。没有一个标量能涵盖所有目标。系统应说明作出某项选择的原因，以及放宽了哪些约束。

Stoica 的抽象传统适合这种环境，因为它试图为异构资源提供精简接口。风险在于，接口会隐藏管理团队真正需要治理的稀缺性。仅提出“加速器”请求远远不够，因为内存容量、互连、软件版本和供应合同都会决定任务是否可行。

下一个持久的系统将让请求保持简单，同时让权衡可供检查。这比自动调度更难，因为它把基础设施软件视为财务和能源治理的一部分，而不只是开发者工具。

故障恢复是这些系统共同的隐藏契约

Stoica 职业生涯中的抽象在组件消失时采取不同响应。Chord 在节点离开后修复路由状态；Spark 可以根据血缘重建部分丢失分区；Ray 可以在应用定义的条件下重试任务并重建 actor；多云启动工具可以在容量不可用时尝试另一个区域。无论哪种情况，只有明确说明故障模型，接口才可信。

恢复不等同于正确性。重试纯计算可能安全；重试向客户收费或更新外部数据库的操作，则可能造成重复工作。根据血缘重建数据可能恢复数值，却遗漏外部副作用。把工作负载移到另一朵云可能恢复计算，却违反数据位置规则。

控制平面无法推断所有应用语义。它提供重试、检查点、副本和重启政策等机制，并要求用户声明哪些操作能够容忍这些机制。这又是把状态移向拥有更多上下文一方的例子：运行时知道哪个工作节点发生故障，应用则知道重复工作是否合法。

运营成熟度取决于对这一契约的测试。团队需要故障注入、幂等接口、持久检查点，以及恢复时间符合业务目标的证据。在健康机器上运行的基准测试，几乎无法证明一个主要承诺是韧性的系统是否可靠。

与 Stoica 相关的系统常因速度或规模受到赞誉。它们更深层的共同成就，是把局部故障变成可编程事件，而不是异常谜团。余下的风险在于，恢复 API 的便利会鼓励用户假定应用能够提供超出实际能力的保证。

抽象会通过性能、成本和安全发生泄漏

成功的基础设施抽象让开发者可以忽略细节，直到细节成为瓶颈。Spark 用户可以使用 dataframe 和 SQL，但数据倾斜、混洗和存储仍决定性能；Ray 用户可以启动任务，但对象移动和 actor 放置仍决定时延；SkyPilot 用户可以请求 GPU，但配额、出站费用和供应商政策仍决定作业是否经济。

这种泄漏并不说明抽象是错误，而说明接口触及了真实边界。问题始于营销把抽象说成边界已经不再重要的证据。

运营团队需要看到接口之下的情况。他们必须了解分配了哪些资源、为何选择某个位置、数据移向何处，以及重试如何影响成本。优化一个指标的控制平面可能恶化另一个指标。更快的任务调度可能增加网络争用；重新计算丢失数据可能节省复制成本，却延长关键作业；跨云放置可能降低每小时计算价格，却增加传输费用。

治理也以同样方式发生泄漏。开放 API 可能隐藏专有调度器；托管服务可能提供可移植代码，却保留高效运营所需的遥测数据和经验；基金会可以治理项目，但大部分维护者可能由少数雇主出资。用户最终需要知道谁能改变接口、弃用行为或优先处理某类工作负载。

Stoica 的系统具有价值，部分原因在于它们把这些边界表达得足够清楚，可供研究。Mesos 区分资源邀约与框架决定；Ray 区分任务和 actor 与底层集群；sky computing 区分工作负载请求与满足请求的供应商。每次分离都会形成一个可以分配责任的位置。

下一步工程工作通常不是消除这个位置，而是测量它、公开政策并给用户保留退出路径。抽象降低认知负担，问责则防止这种降低变成盲目依赖。

抽象让应用能够命名任务、actor 或数据集，而不是主机。运行时随后持有凭据、放置状态，以及在众多机器上启动代码的权限。攻破这样的控制平面，可能比攻破一个工作节点更有价值。

Mesos 主节点、Spark 协调器、Ray 控制组件和多云启动工具的架构各不相同，但都会成为信任边界的一部分。它们需要经过认证的通信、最小权限云凭据、受保护的元数据，以及不会接受过期或伪造状态的恢复机制。

开源可见性可以促进审查，托管运营可以统一应用补丁和监测，但二者都不能保证配置安全。平台可能通过权限过大的服务账户提供安全运行时；用户也可能隔离工作节点，却让调度器成为跨越多个租户的单一路径。

安全模型应当跟随抽象。如果任务是工作单位，身份和政策就应能在任务层表达，而不是无条件继承自集群。如果代理工具可以在多个云之间选择，其凭据就不应在每朵云中都拥有不受限制的权限。

讨论 Stoica 的工作时，人们通常关注可扩展性和可编程性。同样的状态迁移也会形成集中的攻击目标。抽象越擅长运营分布式系统，就越需要谨慎限制其自身权限。

开源分散作者贡献，公司集中运营责任

与 Stoica 相关的项目横跨多种治理模式。Apache Spark 遵循 Apache Software Foundation 的社区流程；Ray 是拥有自身维护者和商业生态的开源项目；研究原型在论文发表后可能没有长期机构；Databricks 和 Anyscale 则是对客户、员工和投资者负责的公司。

这些模式解决不同问题。基金会可以维护中立的项目治理和发布纪律，却不承诺服务等级协议。公司可以提供支持、安全响应和产品路线图，也可以改变价格、封装功能，并优先服务带来收入的客户。大学可以探索高风险思想并公开方法，但资助周期和学生更替无法保证长期维护。

Stoica 的职业生涯跨越了这三种模式。这赋予他不同寻常的影响力，也要求准确描述其角色。创始人可以持有股权和董事会职务，而不负责维护开源代码库；教授可以指导由学生主导实现的研究；执行董事长可以影响战略，而不担任首席执行官。

公司的财务成功既不是个人资产负债表，也不能证明某种算法普遍优越。私人估值波动很大，收入除技术价值外，还反映销售、集成和市场条件。公开资料可以确认公司成立和当前职务，却不能据此猜测个人财富。

更重要的问题是这些机构能否相互促进。商业工程师可以贡献从生产环境中学到的修复方案；开放社区可以防止一家供应商定义整个接口；大学可以测试替代方案。当公司用于差异化的层依赖一个用户期望保持中立的项目时，冲突就会出现。

不存在永久适用的公式，边界必须逐个项目治理。Stoica 的经历表明，从研究到公司的路径为何能够产生持久基础设施，也说明为什么绝不能把它误解为实验室向创始人的简单所有权转移。

Stoica 的影响建立在其他社区可以继续建设的边界之上

罗列 Chord、Mesos、Spark 和 Ray，容易把一段职业生涯变成知名名词清单。更有价值的联系在于架构：每个系统都找到了一个位置，使分布式复杂性能够通过更小的契约表达。

核心无状态公平机制要求边缘携带核心无力保存的信息；Chord 使用一致性放置和局部路由状态，而不是全局目录；Mesos 提供资源，而不规定每个任务；Spark 记录血缘，而不复制每个中间结果；Ray 公开任务和 actor，而不是机器；SkyPilot 表达工作负载需求，再在供应商之间协商。

这些抽象没有一个是完整的。它们都假定组件合作、元数据准确，并有运营机构支持；当隐藏层的行为偏离模型时，它们都可能失败。它们的成功来自即使存在这些限制，仍然有用。

Stoica 在这一系列项目中的具体贡献各不相同，各团队理应获得明确认可。他持久的角色，是一位帮助把这些边界转化为项目、实验室和公司的研究者与机构建设者。National Academy of Engineering 于 2024 年选举他为院士，以认可其更广泛的分布式与云系统成果；荣誉属于个人，系统则仍是集体成就。

现代 AI 基础设施使同样的问题变得更加昂贵。加速器、网络和电力无法被随意浪费。让应用看到更简单视图的控制平面可以提高利用率并加快开发，也可能成为某个供应商、调度器或平台积聚权力的位置。

Stoica 研究传统的下一代成果，将取决于其抽象在跨越云和公司时能否保持可检查性。可编程性之所以有价值，是因为用户不必了解每台机器；韧性则要求用户仍然知道，自己不再亲自作出的决定究竟由谁作出。