Anyscale

为什么选择 Anyscale？

Anyscale 填补了分布式 Python 代码编写与可靠运行之间的空白。虽然开源项目 Ray 提供了并行任务、Actor 模型、数据管道、模型训练、调优和推理服务的编程模型，但生产团队仍需解决集群配置、环境打包、容量调度、故障处理、遥测采集、安全访问及部署协调等复杂操作。

该平台将这些运维挑战转化为围绕 Ray 构建的托管生命周期。开发者可以在远程计算资源上进行实验，保留开发时的环境配置，并直接将同一应用提升为离线任务或持续运行的服务。平台工程师可以保持对网络、IAM、存储、加速器选择和云端容量的控制，而无需让每个机器学习 (ML) 开发者直接去操作 Kubernetes 或虚拟机集群。

与通用的云端 ML 套件相比，Anyscale 的定位更精准。它并不试图取代笔记本工具、特征存储、实验追踪、数据仓库、模型注册表或应用框架。其核心竞争力在于分布式执行层：使单个 Python 应用能够在异构的 CPU 和 GPU 资源上扩展，同时保持相对一致的开发模型。

这种专注对于现代 AI 流水线尤为重要。训练、数据清洗、批量推理、评估、检索、智能体执行和在线推理通常需要不同的扩展模式。在这些阶段统一使用 Ray 可以减少团队需要维护的无关计算系统数量，而 Anyscale 则为这一共享运行时提供了托管环境。

核心工作流程

典型的工作流程始于本地或交互式云端环境。开发者定义容器镜像、Python 依赖、环境变量以及描述所需 CPU、内存、加速器类型和扩展行为的计算配置。应用程序本身依然是 Ray 程序，无需为了 Anyscale 进行特定重写。

交互式开发应被视为临时的反馈循环，而非生产环境。开发者可以检查分布式任务、修改代码、使用代表性数据进行测试，并确认资源分配是否正确。一旦行为稳定，应用就会被表达为版本化的工作负载配置，并作为任务 (Job) 或服务 (Service) 启动。

任务 (Jobs) 适用于有明确终点的工作：数据集转换、分布式训练、嵌入向量生成、评估、批量推理或定时处理。生产配置应定义重试行为、超时、资源约束、存储位置和幂等输出策略。重试的任务绝不能在无声无息中重复记录或损坏之前的计算结果。

服务 (Services) 适用于需要持续可用端点的场景。应用应围绕 Ray Serve 副本、部署边界、请求路由和自动扩缩容信号进行设计。生产就绪不仅意味着模型加载成功，团队还必须衡量启动时间、首字延迟 (TTFT)、持续吞吐量、队列深度、加速器利用率以及在滚动更新或节点故障时的表现。

最后阶段是运营化。CLI 和 SDK 命令可以整合进 CI/CD，并使用服务账号取代个人凭据。仪表板、日志、告警、预算报告和云供应商遥测提供了同一工作负载的不同视图。配置、应用代码和部署命令都应保留在源码控制系统中，以便环境可以被复现，而非通过控制台设置来重建。

Anyscale 的适用场景

当工作负载超过单机承受能力或预计很快会达到这一规模时，Anyscale 的价值最为明显。对于处理数百万文档、图像、音频剪辑或视频帧的流水线，可以通过 Ray Data 划分任务，同时在同一个分布式应用中协调 CPU 预处理和 GPU 推理。

基础模型团队可以使用该平台进行数据集清洗、分布式训练、偏好优化、评估和推理服务。这些阶段往往具有迥异的计算特征：数据准备可能需要大量 CPU 工作节点，训练可能需要紧密协调的加速器集群，而推理则需要能够响应流量变化的弹性副本。

批量推理是另一个非常适合的场景。在大规模离线语料库上运行模型与响应交互式请求面临的问题不同。批量流水线可以通过输入分组合并、阶段间流式传输数据以及持续使用加速器来最大化吞吐量，而无需针对单个请求的延迟优化每个环节。

Anyscale 还可以托管复合 AI 应用，其中智能体、模型服务器、检索服务和 MCP 工具可以独立扩展。Ray Serve 允许这些组件作为同一个可部署应用的一部分，同时为每个组件分配不同的资源需求。

传统的机器学习依然适用。Ray 可以分发预处理、超参数调优、强化学习、计算机视觉以及非 LLM 模型的推理服务。因此，团队应根据其分布式 Python 投资组合来评估 Anyscale，而不仅仅是看是否在部署聊天机器人。

对于可以在单个实例上轻松运行的小型 API，该平台带来的杠杆作用有限。在这种情况下，容器服务或托管端点的运维和认知成本可能更低。只有当调度、并行性、异构资源或快速扩展成为真实需求而非假设的未来需求时，这种额外的抽象才具有价值。

Anyscale 如何改变 Ray 的运维

自托管 Ray 需要组织自行决定如何创建、升级、隔离、监控和修复集群。Kubernetes 虽能提供基础，但增加了 Operator 管理、Pod 调度、扩缩容集成、存储配置、Ingress、密钥管理、可观测性和版本兼容等工作。虚拟机部署则需要另一套针对镜像、网络、实例生命周期和故障恢复的自动化方案。

Anyscale 在保留 Ray API 的同时，减轻了这些平台工程负担。需要说明的是，它并未完全消除对基础设施的所有权，尤其是在 BYOC（自带云账号）部署中。云管理员仍需配置信任关系、网络路径、存储、IAM 角色、配额、加速器可用性和成本控制。

因此，职责划分只是发生了变化，而非消失。Anyscale 负责运行控制平面和托管运行时的行为；客户则控制数据平面、应用代码、权限、依赖项和选定的基础设施。团队应在生产前记录这一边界，以免发生事故时就哪个系统拥有故障组件产生争论。

当多个团队都需要 Ray 时，这种模式可以减少内部平台的工作量。组织可以统一定义支持的镜像、计算模板、云身份、项目和工作负载模式，而不是让每个项目都去创建自己的集群启动器、仪表板、部署脚本和恢复程序。

代价是依赖于专有的管理平面和优化过的运行时。虽然应用代码基于开源 Ray 概念（相比完全专有的编程模型减少了锁定风险），但如果组织日后离开 Anyscale，部署配置、运维流程和治理集成仍需要迁移工作。

LLM 与智能体工作负载

对于 LLM 推理服务，核心架构将负责编排的 Ray Serve 与负责推理的 vLLM 相结合。这使得将模型层面的关注点（如 KV 缓存管理和持续批处理）与集群层面的关注点（如副本放置、节点选择、自动扩缩容和故障恢复）分离开来。

部署规模应根据测量数据而非仅凭模型参数量决定。上下文长度、并发量、量化、张量并行、投机采样、Adapter 使用和响应长度都会改变内存需求和吞吐量。一个启动成功的模型，如果请求路由导致 GPU 利用率不足，或者副本在加载权重上花费过多时间，其经济效益依然很差。

多模型部署需要另一层规划。共享基础设施可以提高利用率，但无关模型可能会竞争内存或导致不可预测的扩展行为。团队应使用接近生产环境的提示词分布和并发量对每种路由策略进行基准测试，而不是仅依赖合成的最大吞吐量测试。

批量推理应与在线服务分开评估。离线处理可以激进地合并输入并优先考虑加速器饱和度，而在线服务必须平衡吞吐量与长尾延迟和首字延迟。复用相同的模型权重并不意味着同一套配置对两种路径都是最优的。

智能体应用在模型服务器之外增加了编排工作。一个智能体可能会调用检索系统、数据库、代码沙箱、MCP 服务器或其他智能体。这些组件通常与 LLM 有着不同的扩展和安全要求。将应用视为多个可独立扩展的部署，可以避免为了执行轻量级工具而分配昂贵的 GPU。

Anyscale Agent Skills 将此工作流扩展到编码智能体。它们可以帮助生成工作负载配置、检查失败的运行、解释 Ray 和 vLLM 错误，或建议资源变更。这些技能是很有用的加速器，但生成的部署决策仍应根据预算、安全策略和基准测试结果进行验证。智能体可以识别可能的配置不匹配，但在没有明确约束的情况下，它无法确定组织可接受的生产成本或风险。

同类工具对比

Databricks 提供了一个涵盖数据工程、治理、分析、笔记本、模型开发和 AI 服务的更广泛的湖仓一体环境。如果数据和运维治理已经以 Delta Lake 和 Unity Catalog 为中心，它通常是自然选择。Anyscale 更专注于基于 Ray 的分布式执行，当工作负载需要在数据、训练和推理之间进行自定义 Python 编排时，它更具吸引力。

Amazon SageMaker AI 提供了一系列 AWS 原生的开发、训练、部署、注册表和治理服务。对于深耕 AWS 的组织，它减少了集成工作，但工作流可能涉及多个独立的 SageMaker 产品和配置模型。Anyscale 提供了更统一的 Ray 编程模型，并可以跨云供应商运行。

Google Vertex AI 对于以 Google Cloud、BigQuery、Gemini 为核心的组织具有类似优势。它提供了更多全托管的模型 API 和生命周期产品，而 Anyscale 则让开发者对分布式 Python 应用和开源模型运行时拥有更大的控制权。

Azure Machine Learning 与 Azure 的身份验证、网络、注册表、流水线、端点和企业治理深度集成。当团队希望将 Ray 作为共享计算引擎，同时将资源保留在 Azure 租户内时，Anyscale 的 Azure 部署非常适用。选择取决于主要抽象层应该是 Azure ML 的资产生命周期还是可移植的 Ray 应用。

Modal 专注于无服务器 (Serverless) Python 函数、容器、定时任务和 GPU 端点，只需极少的基础设施配置。对于隔离的函数和小型服务，它可能更易用。Anyscale 的概念体系更大，但更适合有状态的分布式应用、Ray 库、大型数据流水线和多节点执行。

Runhouse 专注于通过 Python 使现有计算资源可用，并在本地与远程环境之间迁移函数或服务。对于已经管理好基础设施的团队，它可以提供更轻量的运维层。Anyscale 为 Ray 工作负载提供了一个更完整的托管控制平面，包括调度、生产服务、治理和集群级可见性。

自托管 Ray 或 KubeRay 也是一个重要的替代方案，尽管它不是商业平台。它免去了 Anyscale 的平台费用并给予组织完全控制，但将运行时升级、集群生命周期、仪表板、可靠性工程、开发者工具和支持压力转移到了内部平台团队。相关的对比指标应该是总工程成本和事故成本，而非仅看基础设施价格。

最佳配置实践

从运行真实数据路径的最小代表性工作负载开始。生成随机输入的笔记本可以验证语法，但无法暴露对象存储压力、序列化开销、数据倾斜、远程存储瓶颈或模型加载时间等问题。

分离应用配置与基础设施配置。代码应表达任务和 Actor 的需求，而可复用的计算定义则描述批准的节点系列、竞价实例 (Spot) 策略、扩展限制和网络。这可以防止每个开发者都去“发明”一套略有不同的生产集群。

针对异构工作负载使用专门的工作节点组 (Worker Groups)。CPU 预处理、GPU 推理、协调节点和轻量级服务不应自动接收相同的实例类型。明确的资源标签和放置要求有助于调度器分配各阶段任务，而不浪费昂贵的加速器容量。

优先使用云对象存储来存放持久化输入、输出、检查点和模型产物。节点本地磁盘适用于缓存和临时文件，但不应作为重试或集群更换后所需状态的唯一存放点。

锁定生产环境使用的 Ray 和依赖版本。自动采用新的基础镜像或库版本可能会改变序列化、调度、模型内核或 GPU 兼容性。每次升级一个环境，并在提升环境前运行相同的基准测试和评估套件。

为 CI/CD 和生产自动化配置服务账号。个人 API 密钥应仅限于交互式开发，设置短有效期，且绝不要嵌入镜像或仓库中。应用密钥应通过工作负载身份从云供应商的密钥管理器获取，而不是在控制台中维护明文环境变量。

在向大型开发团队开放平台前，设置最大集群规模和加速器配额。自动扩缩容在运维上很有用，但错误的并行设置可能会请求远超预期的容量。预算是告警机制而非强行关机控制，因此云配额和 Anyscale 资源限制应提供强制性的边界。

处理敏感数据或内部服务时使用私有网络。必须考虑完整路径：开发者访问、控制平面通信、对象存储、容器注册表、模型下载、遥测和生产端点流量。仅将最终的模型端点设为私有并不能保证其余数据流的安全。

从本地 Ray 迁移

在增加集群规模之前，应先使本地 Ray 应用具备确定性和可移植性。移除关于本地路径、预装包、主机凭据和进程全局状态的假设。输入和输出应使用每个工作节点都能访问的共享存储或云 URI。

资源声明必须明确。在笔记本电脑上运行成功的代码可能依赖于隐含的 CPU、内存或 GPU 可用性。在分布式集群中，Ray 使用这些声明来调度工作，不准确的数值会导致超额认购、硬件闲置或任务无法放置。

仔细测试序列化边界。在单个本地进程中运行的函数、类、闭包和依赖项在传输到远程工作节点时可能会失败。大型对象不应在任务定义中重复捕获，而应存储一次或通过 Ray Data 流式传输。

分阶段迁移到 Anyscale。首先在交互式工作区中复现本地工作负载，然后将其打包为离线任务，最后才增加计划任务、重试、队列或生产数据。这有助于区分应用错误与部署和基础设施错误。

从自托管 Ray 或 KubeRay 迁移

基于标准 Ray API 的应用通常无需根本性重写即可迁移，但运维配置无法直接转换。Kubernetes 清单、Helm values、自动扩缩容设置、Ingress 配置和自定义监控脚本需要映射到 Anyscale 云、计算配置、镜像、任务和服务中。

迁移前盘点每一项外部依赖。这包括对象存储、数据库、注册表、身份角色、密钥、仪表板、告警规则、调度器和 CI/CD 凭据。一个看似独立的工作负载可能依赖于当前平台团队安装的多个集群级组件。

使用代表性工作负载对比运行时行为。托管的 Anyscale Runtime 与 Ray API 兼容，但包含可能影响启动、扩展、调度或性能的平台优化和运维行为。在将吞吐量提升作为迁移标准前，先验证输出的正确性。

为重要服务暂时保持双环境运行。发送影子流量或回放记录的请求，对比延迟和输出，然后测试节点丢失、滚动更新和缩容行为。只有当运维流程和告警生效时，迁移才算完成，而不仅仅是第一次部署返回成功响应。

从托管 ML 平台迁移

从 SageMaker、Vertex AI、Azure Machine Learning 或 Databricks 迁移通常不仅仅是转换一条训练命令。现有系统可能拥有实验元数据、模型注册表、流水线、特征访问、端点认证、血缘追踪和审批工作流。

决定哪些系统应保留权威地位。Anyscale 可以作为分布式计算层运行，同时继续向 MLflow、Weights & Biases 或另一个注册表报告运行情况。同时更换所有外围服务会增加迁移风险，且未必能改善工作负载。

在分发任务前，将供应商特定的流水线步骤转换为普通的 Python 组件。数据访问、计算、产物发布和部署之间的清晰边界使 Ray 实现更易于测试，并能使供应商 SDK 调用远离核心模型逻辑。

模型推理客户端应依赖于稳定的内部 API，而非直接依赖平台生成的端点。这允许流量在旧系统和新推理系统之间切换，而无需修改每一个下游应用。

成本与容量规划

Anyscale 的定价基于消费，因此没有单一的代表性月度价格。总成本包括选定的 CPU 和 GPU 资源、平台消费、持久存储、镜像和模型传输、网络、闲置开发环境、失败的尝试以及可选的支持承诺。

优化的相关单位是成功的任务产出的成本。如果更昂贵的 GPU 能显著加快批处理速度，其总体成本可能更低；而如果输入读取或单点协调步骤导致并行工作节点闲置，大型集群反而是一种浪费。

按阶段衡量利用率。当一个模型副本饱和而其他几个副本闲置时，整体 GPU 利用率看起来可能还可以。同样，高 CPU 利用率可能代表有用的预处理，也可能代表过度的序列化和解压工作。

竞价实例 (Spot) 可以降低可重启任务的成本，但必须先设计好检查点和重试行为。如果每次中断都会导致漫长的训练任务从头开始，那么低廉的时薪也就失去了意义。关键的在线服务应使用反映其恢复时间目标 (RTO) 的容量策略。

缩容至零 (Scale-to-zero) 可以减少闲置推理成本，但会引入冷启动延迟。模型权重大小、镜像缓存、节点可用性和初始化决定了这种折中是否可以接受。某些应用即使在平均流量较低时也需要保留最小数量的热副本。

共享集群和任务队列可以在工作负载兼容时提高利用率。它们也可能产生“嘈杂邻居”行为或不可预测的等待时间。在多个团队共享预留容量前，应定义好优先级、抢占机制、归属权和最大并发量。

运维权衡

Ray 使分布式 Python 变得更易触达，但它并不能让分布式系统的表现像一个巨大的单进程一样。网络分区、节点丢失、重复执行、部分输出、内存压力、倾斜、背压和依赖项不匹配依然是应用层需要关注的问题。

Anyscale 减少了团队必须拥有的基础设施代码量，但开发者仍需理解 Ray 的任务、Actor、对象存储、数据、训练和推理模型。缺乏这些知识，团队可能会通过增加集群规模来应对每一次失败，而不是纠正应用瓶颈。

BYOC 增强了数据控制并允许使用现有的预留实例，但上线过程需要 ML、云架构、网络、安全和财务团队的协作。如果配置错误，保护环境的 IAM 和网络限制也可能阻止镜像拉取、存储访问、仪表板连接或服务路由。

托管云提供了更快的评估路径，但其区域、网络、基础设施、支持或审计选项与生产环境中的客户托管部署不同。成功的托管原型不应被视为已解决企业部署要求的证据。

供应商可移植性也有局限。Ray 代码可以跨环境运行，但实例名称、加速器可用性、IAM 系统、存储 URL、网络拓扑和定价各不相同。可移植性在应用层最强，在基础设施层较弱。

智能体技能可以减少查阅文档和日志的时间，但它们引入了另一个生成的配置来源。由编码智能体提出的变更应像手动编写的基础设施代码一样，经过审查、版本化和测试。

因此，评估 Anyscale 的最佳视角是将其视为 Ray 的托管运营模式，而非分布式系统工程的捷径。它可以消除大量无差别的平台工作，但生产可靠性仍取决于细致的工作负载设计、测量、安全边界和容量规划。