企业官网建设流程全解析

• 模型推理服务
• 人工智能
• 后端
• 大模型
• MLOps
• LLMOps

本文是 BentoCloud 管理员实操指南，聚焦如何通过Standby Instances（待机实例）功能在流量到来之前预先准备一批云机器，让 AI 应用在需求激增时能够立刻扩容、降低首请求延迟。读者读完可以掌握待机实例的适用场景、前置条件（BYOC 与 Admin 角色）、控制台配置步骤、计费影响，以及它与自动扩缩容、实例类型等机制的配合方式。

什么是 Standby Instances

Standby Instances 是 BentoCloud 提供的一项资源预热能力：它允许管理员提前在云服务商（CSP）侧预置指定数量的云机器。这些机器由云服务商预先完成资源分配，因此当你的 AI 应用因流量上涨需要扩容时，它们可以立即投入服务，而不是等待底层云资源从零开始创建。

这一机制的核心价值在于缩短扩容路径：

• 常规扩容路径：请求激增 → 触发扩缩容策略 → 向云服务商申请新实例 → 等待实例就绪 → 开始服务请求；
• 启用待机实例后的路径：请求激增 → 扩缩容策略触发 → 直接启用已就绪的待机实例 → 立即服务请求。

两者的差异主要体现在"等待实例就绪"这一段。对于延迟敏感的在线推理场景（例如 LLM 应用、实时推荐），意外的流量尖峰如果碰上云资源启动延迟，会产生明显的首请求等待，待机实例正是针对这一痛点设计的。

关键概念与工作方式

根据 configure-standby-instances.rst 的说明，待机实例的工作方式可以概括为三点：

1. 数量即承诺：你设置的待机实例数量，表示 BentoCloud 需要为你的应用保持"就绪"状态的额外实例数量。
2. 动态保持：BentoCloud 会持续保证这一数量的实例始终可用，即使应用在扩缩容过程中（无论是扩容还是缩容），待机实例的保有量也不会被破坏。
3. 就绪即计费：待机实例即使当前没有实际服务任何 Deployment，也会产生费用，因为它们必须维持在"就绪"状态以便随时快速扩容。

需要强调的是，待机实例不是为单个 Deployment 设置的副本数，而是面向集群（region）维度、按实例类型分别规划的一批"后备资源池"。它与下文要讲的自动扩缩容中的min_replicas/max_replicas是互补关系：前者保证扩上去的实例"有货可用"，后者定义单个 Deployment 副本数的上下边界。

前置条件：仅 BYOC 用户 + Admin 角色

原文档明确给出两项使用限制，这是配置前必须确认的前提：

• 仅限 BYOC 用户：该功能当前只对 Bring Your Own Cloud（BYOC）用户开放。BYOC 是 BentoCloud Enterprise 计划中的部署模式，允许将 BentoCloud 的 AI 推理平台部署进企业自己的私有云环境（如 AWS、Google Cloud、Microsoft Azure、Oracle Cloud Infrastructure），运营商与 Deployment 运行在你自己的 VPC 中，数据与模型不出你的网络边界，参见 bring-your-own-cloud.rst。待机实例需要向云服务商预占计算资源，因此只有在 BYOC 模式下，BentoCloud 才拥有在你的云账号内预置机器的权限链路。
• 仅限 Admin 角色：只有拥有 Admin 角色的用户才能配置待机实例。这一权限约束在 manage-users.rst 的角色权限表中也有明确记录——在"Configure standby instances"一行，Admin 列标记为 ✓，Developer 与 Endpoint User 均无此权限。Admin 同时拥有"查看和编辑账单信息""添加和移除用户"等最高权限，将待机实例（一项直接产生云资源费用的操作）限定在 Admin 范围内，是合理的权限边界设计。

配置步骤

在满足 BYOC 与 Admin 角色两个前置条件后，按以下步骤在 BentoCloud 控制台配置待机实例：

1. 进入 BentoCloud 控制台的Clusters（集群）区域。
2. 选择你想要配置待机实例的目标集群（即目标 region），点击Standby Instances（待机实例）入口。
3. 在弹出的对话框中，根据你预期的业务需求，为每种实例类型分别设置待机实例数量。
4. 点击Submit（提交）完成配置。

配置的核心输入是"每个实例类型各多少个待机实例"。也就是说，你需要对集群内可能承载流量的每类机型（CPU 机型、各类 GPU 机型）分别做数量规划，而不是只填一个总数。

在配置前查看可用实例类型

在为各实例类型规划数量之前，先确认集群中实际可用的实例类型清单。BentoCloud 提供了 CLI 命令来查询：

bentoml deployment list-instance-types

该命令的实现位于 deployment.py（list_instance_types函数），它最终调用 BentoCloud 控制面 API 的/api/v1/instance_types接口（见 client.py 中的list_instance_types方法），并且支持通过--cluster参数限定到指定集群查询。这与你配置 Deployment 时使用的实例类型体系（如cpu.2、gpu.a100.1）是一致的。

与 Deployment 实例类型设定的关系

在部署配置中，实例类型决定了单个 Deployment 的副本运行在什么规格的机器上。BentoCloud 支持通过三种方式指定实例类型：

• BentoML CLI：bentoml deploy --instance-type "gpu.a100.1"；
• Python API：在bentoml.deployment.create(..., instance_type="gpu.a100.1")中指定；
• 配置文件：在部署配置的services.<服务名>.instance_type字段中声明。

相关内容可参考 configure-deployments.rst。如果未显式指定实例类型，BentoCloud 会根据配置中的resources字段自动推断最合适的机型。为待机实例做规划时，应优先覆盖那些你最可能在流量尖峰时扩容到的实例类型——通常是承载主要在线流量的 CPU/GPU 机型。

计费与成本影响

原文档明确提示：待机实例即使没有实际服务 Deployment，也会持续产生费用。

原因在于它们必须维持在"就绪（ready）"状态——实例已从云服务商处完成分配与预热，随时可以接管请求。这部分预占的云资源处于"可用但可能空闲"的状态，云服务商按实例本身计费，BentoCloud 也会将对应成本体现出来。

因此在规划数量时，需要做好成本权衡：

• 待机实例越多，尖峰到来时的扩容越快、用户体验越好，但闲置成本越高；
• 待机实例过少，则可能在突发流量下退回"等待云资源创建"的老路，失去预热意义。

从源码结构看，BentoCloud 的部署与资源管理都围绕"集群（cluster）"维度展开——CLI 与 SDK 中大量接口以/api/v1/clusters/{cluster}/...形式按集群路由（见 client.py），待机实例同样作用于集群维度。规划时应结合每个集群（region）内各实例类型的实际承载量来分配预算。

与自动扩缩容的协同工作

待机实例解决的是"资源有没有货"的问题，而 BentoCloud 的自动扩缩容解决的是"资源什么时候用"的问题，两者应配合使用。

副本边界：min_replicas 与 max_replicas

自动扩缩容通过 autoscaling.rst 中描述的机制动态调整 Deployment 的副本数。你可以为 Deployment 设置扩缩容边界：

• BentoML CLI：bentoml deploy --scaling-min 1 --scaling-max 2；
• Python API：bentoml.deployment.create(..., scaling_min=1, scaling_max=3)；
• 配置文件：在services.<服务名>.scaling.min_replicas / max_replicas字段中设置。

当流量上涨触发扩容时，扩出来的新副本需要实例资源承载——如果集群内没有空闲实例，扩容只能等待新实例创建；待机实例正是为这一时刻准备的"即插即用"资源池。

扩容信号：concurrency 与外部队列

要获得灵敏的扩容响应，还需要为 Service 配置合理的concurrency阈值。例如在@bentoml.service装饰器中声明：

@bentoml.service( traffic={ "concurrency": 32, # 单个副本并发处理的请求数阈值 } ) class MyService: ...

当每个副本的并发请求数超过该阈值时，BentoCloud 会自动扩容副本数；也可启用external_queue将超出阈值能力的请求先缓冲到外部队列，再依据队列积压情况触发扩容。待机实例的存在，让这种自动扩容在尖峰流量下"扩得动、扩得快"。

与 Scale-to-Zero 的对比

值得区分的是，BentoCloud 还支持 Scale-to-Zero（将min_replicas设为 0，空闲时副本缩到零以节省成本）。Scale-to-Zero 是在"不用时释放资源"，待机实例则相反，是在"需要前预留资源"。两者策略取向不同：

• 追求极致成本、容忍冷启动延迟 → Scale-to-Zero；
• 追求快速响应、愿意为确定性付费 → 待机实例（并按需叠加合适的min_replicas）。

在 BYOC 环境中的落地考量

由于待机实例本质上是向你的云账号预占资源，在 BYOC 环境下还需关注云服务商的配额。以 AWS 为例，在 aws.rst 的 BYOC 设置指南中，BentoCloud 明确要求提前在目标 region 申请足够的服务配额：

• CPU 机型：需要足够的"Running On-Demand Standard instances"配额（示例要求 32 vCPUs），用于基础设施负载、镜像构建任务以及 CPU 服务实例；
• GPU 机型：根据需求申请对应配额，例如 T4/A10G 归入"Running On-Demand G and VT instances"，A100/H100/H200/B200 归入"Running On-Demand P instances"。

待机实例数量增加后，会同时消耗这些配额。因此规划待机实例时，应一并核算配额余量，必要时提前在云服务商控制台申请配额提升，否则可能出现"策略配置了待机数量、但云侧配额不足导致实例无法预置"的情况。GCP、Azure 等云平台同理，需要在对应 region 预留足够的 vCPU/GPU 配额。

配置建议与最佳实践

综合上述机制，给出以下实操建议：

1. 按实例类型分别规划：先通过bentoml deployment list-instance-types --cluster <集群名>确认可用的实例类型，再针对承担主要在线流量的类型设置待机数量，避免为低频类型过度预留。
2. 结合扩缩容边界设定：让待机实例数量与max_replicas的潜在扩容空间匹配——预估最坏情况下会扩到多少个副本，为这个数量留出待机余量。
3. 核算成本与配额：在提交前评估待机实例的闲置成本，并确认云服务商配额充足；BYOC 用户可参考 aws.rst 提前申请配额。
4. 仅由 Admin 操作：待机实例涉及持续费用支出，应作为受控的管理员操作，配合 manage-users.rst 中的角色权限体系执行。
5. 与扩容信号配合：为关键 Service 配置合理的concurrency与外部队列，确保自动扩容在尖峰到来时能及时触发，从而真正用上待机实例（参见 autoscaling.rst）。

相关文档索引

• 管理员指南总览（Administering）：包含用户管理、环境隔离、BYOC 与待机实例等全部管理员向指南；
• Bring Your Own Cloud（BYOC）：了解 BYOC 部署模式的架构与适用场景；
• AWS BYOC 设置指南：申请配额与完成云侧授权的完整步骤；
• 并发与自动扩缩容：concurrency、外部队列、Scale-to-Zero 与扩缩容策略的细节；
• 配置 Deployment：实例类型与扩缩容边界的 CLI / Python API / 配置文件三种设置方式；
• 管理用户与角色权限：确认 Admin 角色对"Configure standby instances"的专属权限。

• 模型推理服务
• 人工智能
• 后端
• 大模型
• MLOps
• LLMOps