Loading...

📈

自适应算力伸缩(ACS)

根据工作负载需求和性能要求，动态调整计算资源。

复杂度: high资源感知优化

In 30 seconds

What: 实时监控负载指标，自动增减计算资源，在控制成本的同时维持性能目标。
When to use: 服务面临难以预测的流量峰值、波动的算力需求，或需要在性能保证与基础设施开支之间取得平衡时。
Watch out: 扩缩容决策滞后于需求变化，若阈值和预测模型调校不当，就会引发级联故障或资源浪费。

Loading technique guide…

Patterns

Loading...

Loading Agentic Design…

Agentic Design面向生产环境 AI 智能体的模式与工具

专家支持价格

设计模式与技术

Loading...

📈

自适应算力伸缩(ACS)

根据工作负载需求和性能要求，动态调整计算资源。

复杂度: high资源感知优化

In 30 seconds

What: 实时监控负载指标，自动增减计算资源，在控制成本的同时维持性能目标。
When to use: 服务面临难以预测的流量峰值、波动的算力需求，或需要在性能保证与基础设施开支之间取得平衡时。
Watch out: 扩缩容决策滞后于需求变化，若阈值和预测模型调校不当，就会引发级联故障或资源浪费。

核心机制

自适应算力伸缩会根据实时需求和 SLO 自动调整计算容量(pod/副本、节点/虚拟机、GPU 工作节点)。它将指标驱动的策略(如 p95 延迟、队列长度、利用率)与稳定窗口、冷却期以及预测式/计划式伸缩结合起来,在保持性能的同时最小化成本。典型技术栈将服务级自动伸缩(HPA/KEDA/Ray Serve)与集群/虚拟机级自动伸缩(Cluster Autoscaler、AWS ASG、Azure VMSS、GCP MIG)分层组合,并配合面向负载的批处理。

工作流 / 步骤

采集信号:p95 延迟、队列深度/等待时间、CPU/内存/GPU 利用率、错误率、RPS/TPS。
设定目标:SLO(延迟、可用性)、预算(成本/能耗)以及副本数的上下限。
选择策略:目标跟踪还是步进伸缩;将扩容与缩容行为分开设定。
执行伸缩:调整副本数(HPA/KEDA/Ray Serve),然后供给容量(ASG/VMSS/MIG、Cluster Autoscaler)。
稳定化:应用 stabilizationWindow/冷却期与速率限制,避免抖动。
预热:保留温池,或针对日周期与突发流量采用计划式/预测式伸缩。
观测与调优:监控 KPI 与按阶段的归因,并定期优化信号与阈值。

最佳实践

使用与负载匹配的信号:GPU 上的 LLM 服务应优先看 p95 延迟和队列深度,而非 CPU%。

分别设定扩容(快速、激进)与缩容(缓慢、保守)策略,并配合稳定窗口。

为冷启动开销大的模型预热工作节点;使用温池或基于计划与预测的伸缩。

分层使用自动伸缩器:服务层(HPA/KEDA/Ray Serve)+ 集群/虚拟机层(Cluster Autoscaler/ASG/VMSS/MIG)。

用最小/最大副本数以及最大 surge/drain 加以约束;使用 Pod Disruption Budget 与优雅排空。

智能批处理(vLLM/TGI/Triton 动态批处理),并限制每请求 token 数以稳定尾部延迟。

合理规格化节点;对 GPU 做装箱;在适当场景使用 MIG/MPS;避免资源碎片化。

采用 SLO 驱动的目标(例如保持 p95 < 目标值),并在多租户集群中监控租户间公平性。

记录决策日志并编写运维手册;上线前模拟突发流量与故障模式。

何时不宜使用

任何冷启动或再平衡都不可接受的超低延迟硬实时链路。
缺少分片或粘性路由策略、且强会话亲和的有状态负载。
受许可或配额限制、增加副本也无法提升吞吐的服务。
无弹性底层资源的气隙隔离或固定容量环境。

常见陷阱

对 GPU 受限的推理使用 CPU%;应改用队列延迟/深度与 GPU 利用率。
缺少稳定窗口/冷却期以及扩缩容策略对称,导致抖动。
忽视预热时间、镜像拉取或大模型加载时间 → 长时间违反 SLO。
没有最小容量或余量;Cluster Autoscaler 的滞后让 pod 自动伸缩器无资源可用。
在没有请求缓冲/预热器的情况下缩容到零 → 严重的冷启动代价。
过度依赖平均值;应以 p95/p99 为目标并防范突发到达。

关键特性

指标驱动的自动伸缩(延迟、队列深度、利用率、错误率)。

通过外部系统实现的事件驱动伸缩(KEDA:Kafka、SQS、Redis、Prometheus)。

面向日周期规律与已知事件的预测式与计划式伸缩。

多层伸缩:服务、节点/虚拟机与集群容量的协调。

感知 SLO 的策略,具备区分的扩缩容行为与稳定化机制。

考虑成本与能耗的约束与预算,并带有按租户的配额。

KPI / 成功指标

相对 SLO 的 p50/p95/p99 延迟;队列等待时间;突发下的错误/超时。
吞吐量(RPS/TPS、tokens/秒)与伸缩延迟(达到容量的时间)。
每次成功请求的成本;实例/GPU 小时数;过度/不足配置的时间占比。
自动伸缩事件频率与稳定性(无抖动);饱和余量。
多租户集群中的租户公平性与配额遵守情况。

Token / 资源使用

对于 LLM 推理,跟踪 tokens/秒、并发请求数和 KV 缓存内存。使用批处理以及上下文/token 上限来约束尾部延迟;优先以队列深度和 p95 延迟作为主要信号。对于 GPU 节点,监控 VRAM/SM 利用率与模型加载时间,并确保自动伸缩器有容量余量。

信号:队列深度、p95 延迟、GPU 利用率、请求并发数、token 预算。
控制手段:动态批处理、最大新增 token 数、提示词长度限制、温池。
效率:缓存 KV/前缀;对大模型分片;对 GPU 做装箱;避免利用率低的小 pod。

最佳应用场景

突发、日周期或活动驱动的流量(电商、发布会、直播活动)。
具备动态批处理与严格延迟/成本 SLO 的 GPU LLM 服务。
以积压长度为明确信号的事件驱动处理(队列/流)。
需要成本控制、公平性与可预测 SLO 的多租户平台。

参考资料与延伸阅读

学术论文

实现指南

工具与库

Kubernetes HPA/KEDA/Cluster Autoscaler;AWS ASG;Azure VMSS;GCP MIG。
vLLM、Text Generation Inference (TGI)、NVIDIA Triton Inference Server。
Prometheus + Grafana;CloudWatch;Azure Monitor;GCP Cloud Monitoring。

社区与讨论

Loading technique guide…

Patterns

设计模式与技术

Loading...

核心机制

工作流 / 步骤

采集信号:p95 延迟、队列深度/等待时间、CPU/内存/GPU 利用率、错误率、RPS/TPS。
设定目标:SLO(延迟、可用性)、预算(成本/能耗)以及副本数的上下限。
选择策略:目标跟踪还是步进伸缩;将扩容与缩容行为分开设定。
执行伸缩:调整副本数(HPA/KEDA/Ray Serve),然后供给容量(ASG/VMSS/MIG、Cluster Autoscaler)。
稳定化:应用 stabilizationWindow/冷却期与速率限制,避免抖动。
预热:保留温池,或针对日周期与突发流量采用计划式/预测式伸缩。
观测与调优:监控 KPI 与按阶段的归因,并定期优化信号与阈值。

最佳实践

使用与负载匹配的信号:GPU 上的 LLM 服务应优先看 p95 延迟和队列深度,而非 CPU%。

分别设定扩容(快速、激进)与缩容(缓慢、保守)策略,并配合稳定窗口。

为冷启动开销大的模型预热工作节点;使用温池或基于计划与预测的伸缩。

分层使用自动伸缩器:服务层(HPA/KEDA/Ray Serve)+ 集群/虚拟机层(Cluster Autoscaler/ASG/VMSS/MIG)。

用最小/最大副本数以及最大 surge/drain 加以约束;使用 Pod Disruption Budget 与优雅排空。

智能批处理(vLLM/TGI/Triton 动态批处理),并限制每请求 token 数以稳定尾部延迟。

合理规格化节点;对 GPU 做装箱;在适当场景使用 MIG/MPS;避免资源碎片化。

采用 SLO 驱动的目标(例如保持 p95 < 目标值),并在多租户集群中监控租户间公平性。

记录决策日志并编写运维手册;上线前模拟突发流量与故障模式。

何时不宜使用

任何冷启动或再平衡都不可接受的超低延迟硬实时链路。
缺少分片或粘性路由策略、且强会话亲和的有状态负载。
受许可或配额限制、增加副本也无法提升吞吐的服务。
无弹性底层资源的气隙隔离或固定容量环境。

常见陷阱

对 GPU 受限的推理使用 CPU%;应改用队列延迟/深度与 GPU 利用率。
缺少稳定窗口/冷却期以及扩缩容策略对称,导致抖动。
忽视预热时间、镜像拉取或大模型加载时间 → 长时间违反 SLO。
没有最小容量或余量;Cluster Autoscaler 的滞后让 pod 自动伸缩器无资源可用。
在没有请求缓冲/预热器的情况下缩容到零 → 严重的冷启动代价。
过度依赖平均值;应以 p95/p99 为目标并防范突发到达。

关键特性

指标驱动的自动伸缩(延迟、队列深度、利用率、错误率)。

通过外部系统实现的事件驱动伸缩(KEDA:Kafka、SQS、Redis、Prometheus)。

面向日周期规律与已知事件的预测式与计划式伸缩。

多层伸缩:服务、节点/虚拟机与集群容量的协调。

感知 SLO 的策略,具备区分的扩缩容行为与稳定化机制。

考虑成本与能耗的约束与预算,并带有按租户的配额。

KPI / 成功指标

相对 SLO 的 p50/p95/p99 延迟;队列等待时间;突发下的错误/超时。
吞吐量(RPS/TPS、tokens/秒)与伸缩延迟(达到容量的时间)。
每次成功请求的成本;实例/GPU 小时数;过度/不足配置的时间占比。
自动伸缩事件频率与稳定性(无抖动);饱和余量。
多租户集群中的租户公平性与配额遵守情况。

Token / 资源使用

信号:队列深度、p95 延迟、GPU 利用率、请求并发数、token 预算。
控制手段:动态批处理、最大新增 token 数、提示词长度限制、温池。
效率:缓存 KV/前缀;对大模型分片;对 GPU 做装箱;避免利用率低的小 pod。

最佳应用场景

突发、日周期或活动驱动的流量(电商、发布会、直播活动)。
具备动态批处理与严格延迟/成本 SLO 的 GPU LLM 服务。
以积压长度为明确信号的事件驱动处理(队列/流)。
需要成本控制、公平性与可预测 SLO 的多租户平台。