Anyscale：弹性推理

为什么需要 Anyscale：从自建 GPU 集群到声明式弹性伸缩

自建推理服务的成本往往被低估。团队需要预先规划 GPU 实例配额，在大促或新功能上线前提前扩容；流量回落后，闲置 GPU 仍在持续计费。为了应对流量波动，通常要搭建 Kubernetes 集群、HPA（基于资源的水平自动伸缩器）或 KEDA（基于事件的伸缩器），同时处理 GPU 驱动、节点池、污点容忍与容器镜像管理。即使集群跑起来了，推理流量与 CPU 利用率之间并非线性关系——一个 token 生成请求可能让 GPU 利用率很低但排队很长，基于资源利用率的伸缩策略会误判。故障恢复同样棘手：节点宕机后 Pending 的 Pod 需要人工介入，模型冷启动加载数分钟还会触发超时。

Anyscale 的解法是把这些负担从基础设施层转移到应用层。它基于 Ray Serve 的声明式自动伸缩，通过 autoscaling_config 定义最小副本数、最大副本数与每个副本的期望并发请求数；平台会按实际排队深度动态增减副本，支持缩到 0。用户可以指定 GPU 型号（如 A10G、L4、H100），平台负责在所选云区域中预配实例、注入模型运行时、健康检查与失败重启。计算资源通过自带云（BYOC）模式落在你自己的云账户中，成本透明，但省去了集群弹性的全部工程投入。

与 Modal、Baseten 等同赛道工具相比，Anyscale 的气质更接近“带托管层的分布式计算框架”而非“纯无服务器容器运行器”。它保留了 Ray Data（分布式数据处理）与 Ray Train（分布式训练）的生态，推理服务可以复用同一套 Ray 集群与调度语义，在已在用 Ray 的团队中迁移成本最低。它的学习曲线也相应更高——需要理解副本、资源声明、runtime_env（运行时环境）这些概念，但这换来了对伸缩行为与基础设施粒度更精细的控制。

安装与环境配置：5 步就绪

完成以下步骤即可在本机安装 Anyscale CLI 并连接到云端平台。

步骤一：注册平台账号。 访问 [console.anyscale.com](https://console.anyscale.com) 注册账户，新账户自带试用额度，可在沙箱环境体验，无需立即绑定云账户。

步骤二：获取 API 令牌。 在控制台进入 Settings → API Keys，点击生成令牌并复制。令牌是 CLI 登录的唯一凭证，妥善保管，不要提交到代码仓库。

步骤三：安装 Anyscale CLI。 通过 pip 安装，要求 Python 3.9 及以上版本。同时安装开源 Ray 的 Serve 组件，以便本地编写与调试服务代码。

步骤四：CLI 登录。 运行 anyscale login --token 并粘贴令牌。凭证将保存在 ~/.anyscale/anyscale.yaml，后续命令自动携带，无需重复登录。

步骤五：连接云账号。 在控制台的 Clouds 页面添加 AWS 或 Google Cloud 凭据，Anyscale 将使用你的凭据在指定区域预配 EC2/GCE 计算资源（包括 GPU 实例）。若仅体验功能，可暂时跳过，使用平台自带的沙箱资源。

验证环境是否就绪，运行以下命令应能看到 CLI 版本号与项目列表：

# 安装 CLI 与本地 Ray Serve 依赖pip install anyscalepip install "ray[serve]" # 登录（令牌在控制台 Settings → API Keys 获取）anyscale login --token <你的令牌> # 验证anyscale --versionanyscale status

快速上手：15 分钟跑通第一个弹性推理服务

最小可用流程的核心思路：在本地用 Ray Serve 定义推理服务，配置自动伸缩参数，然后通过 Anyscale CLI 部署到云端，最后用 curl 请求外部端点验证弹性效果。

步骤一：创建项目目录并初始化。 在本地新建目录，将代码纳入 Git 版本管理。Anyscale 以项目为单位组织代码、计算环境与部署，云端构建时拉取仓库中代码。

步骤二：编写服务定义文件 deploy.py。 用 @serve.deployment 装饰器声明一个推理服务，autoscaling_config 指定最小 0 副本、最大 4 副本，每个副本最多同时处理 8 个请求。这里选择 TinyLlama 作为演示模型，部署后空闲自动缩到 0，有请求时自动拉起。

步骤三：配置服务环境 serve.yaml。 指定服务名、入口路径与运行时依赖。Anyscale 会在云端安装这些依赖并构建镜像。

步骤四：部署服务。 在项目根目录运行 anyscale deploy -f serve.yaml，等待服务状态变为 RUNNING。期间可在控制台的 Services 页面查看日志与副本状态。

步骤五：调用服务。 服务就绪后，通过 anyscale services list 获取外部端点，随后用 curl 发送 POST 请求，传入 prompt 参数。首次请求可能因冷启动耗时数秒，后续请求延迟回到正常水平。

完整代码示例：

进阶技巧：将 min_replicas 改为 1 可保证常驻实例、消除冷启动延迟；把模型文件预下载到自定义镜像中可显著加快副本拉起速度。生产环境建议在 CI 中执行 anyscale deploy，实现代码合并即发布。

# deploy.py —— Ray Serve 最小推理服务from ray import servefrom transformers import pipeline @serve.deployment(    autoscaling_config={        "min_replicas": 0,        "max_replicas": 4,        "target_num_ongoing_requests_per_replica": 8,    },    ray_actor_options={"num_gpus": 1},)class LLM:    def __init__(self):        self.pipe = pipeline(            "text-generation",            model="TinyLlama/TinyLlama-1.1B-Chat-v1.0",            device=0,        )     async def __call__(self, request):        data = await request.json()        out = self.pipe(data["prompt"], max_new_tokens=64)        return {"response": out[0]["generated_text"]} app = LLM.bind()

# serve.yaml —— 部署配置name: tiny-llm-demoimport_path: deploy:appruntime_env:  pip:    - transformers    - torch    - accelerate

# 部署与验证anyscale deploy -f serve.yamlanyscale services list # 用服务端点发起请求（端点地址在上一条命令输出中）curl -X POST https://<service-endpoint>/ \  -H 'Content-Type: application/json' \  -d '{"prompt": "世界上最高的山峰是"}'

核心能力详解：4 大支柱

支柱一：声明式自动伸缩。 Ray Serve 的自动伸缩是 Anyscale 弹性推理的核心机制。它不依赖 CPU/GPU 利用率，而是基于 target_num_ongoing_requests_per_replica（每个副本正在处理与排队中的请求总数）计算所需副本数：当实际值持续超过目标，系统增加副本；持续低于目标，则缩减副本。伸缩方向与幅度由 upscale_delay_s（扩容触发等待时间）和 downscale_delay_s（缩容等待时间）平滑控制，避免流量抖动带来副本震荡。该机制天然适配 LLM 推理的长请求、高并发特性——GPU 利用率低但排队严重的场景也能准确扩容。

支柱二：无服务器 LLM 端点。 Anyscale Endpoints 提供完全托管的无服务器推理：从模型目录中选择开源模型（包括 Llama、Mistral、DeepSeek 系列等）创建端点，即可获得 OpenAI 兼容的 /v1/chat/completions API。平台自动处理冷启动、并发扩容与故障转移，按生成的 token 数量计费，闲置时零成本。它适合把开源模型当作“API 服务”消费的团队，无需理解 Ray、副本或集群概念，也无需提供云账户凭据。

支柱三：多模型与异构硬件编排。 Ray 的调度器将每个副本（actor）绑定到具体资源声明上：通过 ray_actor_options={"num_gpus": 1} 指定 GPU 需求，也可以声明内存、CPU 与自定义资源标签。同一个服务内可以混合声明 GPU 与 CPU 副本，例如 GPU 副本跑生成模型、CPU 副本跑检索或后处理逻辑。runtime_env 支持按服务或按副本注入不同 Python 依赖，使多模型共存时的依赖冲突最小化。

支柱四：可观测性与故障恢复。 Anyscale 为部署的服务提供内置健康检查：副本持续无响应时自动重启，实例级故障由平台重新调度到新节点。控制台提供吞吐量、P50/P95/P99 延迟、副本数量与资源利用率的指标视图，指标可通过 API 导出用于自定义告警。配合 Ray 的分布式日志系统，可以在一个界面中检索跨副本的请求链路，定位慢请求与异常堆栈。跨可用区部署策略则进一步提升容灾能力。

生产部署与监控：从上线到运维

部署方式一：Anyscale Services。 面向有稳定流量的在线推理。以 Git 仓库为单一事实来源，CI 中执行 anyscale deploy 完成滚动更新，旧的副本按顺序下线，实现零停机发布。生产环境建议将 min_replicas 设为大于等于 1，并配合健康检查路径（/healthy）让平台准确判断副本就绪状态。通过配置项启用跨可用区分配，增强单可用区故障时的可用性。

部署方式二：Anyscale Endpoints。 面向低频、突发或不规律调用。不需要提供云凭据，使用时按 token 付费。适合产品原型、内部工具、定时任务等场景；若流量已经稳定且量大，应迁移到 Services 以降低单位成本。Endpoints 的冷启动时间受模型体积影响，数亿参数模型首次请求可能等待数秒，对延迟敏感且流量高的业务不适用。

可观测性配置。 在控制台 Metrics 页面监控 QPS、延迟与副本数，设置基于 P95 延迟的告警规则；将指标导出接入 Prometheus/Grafana，复用已有的告警渠道。日志方面，所有 stdout/stderr 自动汇聚到平台日志中心，可按服务名与时间范围检索。发布前务必在预发环境观察一次完整的扩缩容周期，确认伸缩参数与业务流量匹配，避免上线后才发现扩容滞后或缩容过快。

<p class="para-label">避坑清单：</p>

<ul class="dash-list"><li>不要用 GPU 利用率作为伸缩依据：LLM 推理中排队比利用率更能反映瓶颈，只配置 target_num_ongoing_requests_per_replica 这个请求队列目标，不要试图用利用率阈值控制副本数。</li><li>min_replicas=0 不等于零延迟：长时间空闲后首个请求要等模型加载，延迟可能达到数秒甚至更久；对延迟敏感的服务保留至少 1 个常驻副本。</li><li>max_replicas 必须设置上限：无限扩展在突发流量下会让账单失控，建议结合历史峰值加 50% 冗余，并同步配置告警。</li><li>模型下载路径要规避：首次启动时从 Hugging Face 拉取权重会拖慢冷启动并可能超时，应提前将模型文件放入自定义镜像或对象存储。</li><li>注意 GPU 实例配额：每个云区域对热门 GPU 实例类型有配额限制，扩容可能因配额不足失败，提前在云控制台申请足够配额。</li></ul>

版本迭代

Anyscale 平台本身为 SaaS 滚动发布，没有独立版本号；其能力演进与底层开源框架 Ray 的版本节奏深度绑定。Ray 从 1.0 的 API 稳定，到 2.0 的全面重写，再到 LLM 时代对 Serve 自动伸缩与推理稳定的持续强化，构成了 Anyscale 弹性推理能力的演进主线。截至训练数据，Ray 仍在按季度节奏发布新版本，下表列出的最新正式版之后可能已有更新版本。

AI 应用场景

常见误区

面试题