在以百亿乃至千亿参数大语言模型LLM为核心的线上推理服务中流量通常呈现出极强的潮汐波动性与瞬时脉冲特征。面对突发峰值流量如何既保证严苛的 SLA 服务等级协议如首字时延 TTFT 200ms端到端 P99 时延 1.5s又能在流量低谷期迅速回收昂贵的高端 GPU 算力实例是分布式推理基础设施设计的核心命题。传统的 Kubernetes HPAHorizontal Pod Autoscaler大多基于 CPU 使用率或 GPU 利用率GPU Utilization作为扩缩容指标。然而在大模型推理的真实物理世界中“GPU 算力利用率高”与“服务已处于性能瓶颈”完全是两码事。例如在开启连续批处理Continuous Batching与 PagedAttention 机制后由于预分配的 KV Cache 已经把显存占满GPU 显存占用率恒定在 90% 以上而在高并发请求涌入时由于 Decode 阶段显存带宽受限GPU 计算单元利用率可能只有 40%但此时网关队列里的排队时延却已急剧攀升至数秒以上。如果继续沿用传统基于硬件指标的扩缩容集群必然陷入“峰值扩容迟钝引发超时灾难、低谷缩容过激导致频繁冷启动”的恶性循环。为此Ray Serve 提供了基于原生分布式 Actor 模型的弹性扩缩容引擎。本文将深入拆解 Ray Serve 内部调度机理通过构建基于请求排队时延与并发积压深度的弹性扩缩容控制算法为大模型推理服务构建灵敏且稳健的弹性护城河。架构透视Ray Serve 扩缩容控制回路Ray Serve 的请求流转与控制流转采用典型的解耦架构主要由以下三类核心组件协同完成Serve Controller集群的中枢大脑负责协调所有 Deployment 的生命周期管理。它周期性默认每 100ms向各个代理与副本轮询指标运行扩缩容算法并向 Ray 核心调度器发出动态创建或销毁 Actor 的指令。HTTP Proxy / Router集群的流量网关。Proxy 接收外部客户端的推理请求并在内存中维护每个下游副本Replica Actor的活跃连接数与待处理请求队列。Replica Actors真正加载大模型权重并在 GPU 上执行 Forward 计算的工作单元。每个 Replica 会持续上报自己当前正在处理的请求数Ongoing Requests以及完成处理的吞吐速率。在该架构下流量无需经过复杂的外部中心化指标收集系统如 Prometheus而是直接在网关代理的内存中完成毫秒级状态同步这使得 Ray Serve 能够以远超传统 K8s HPA 的极高敏捷度响应突发流量。核心算法调校从并发数到排队时延Ray Serve 默认的自动扩缩容算法基于“目标活跃并发数Target Ongoing Requests”。其基本数学模型为$$\text{期望副本数} \lceil \frac{\sum \text{当前所有副本进行中的请求数}}{\text{每个副本的目标并发数}} \rceil$$但在实际生产中单依靠并发数仍然无法准确感知因 Prompt 长度差异导致的处理时间倾斜。例如10 个长度为 50 Tokens 的短请求并不会对显存带宽造成压力而 2 个长度为 8000 Tokens 的超长文本便足以将注意力机制计算推向瓶颈。因此我们需要在 Ray Serve 配置中引入多维约束并针对模型特性精细调优以下关键参数。生产级弹性配置实战以下是一个针对 70B 大模型推理部署的生产级 Ray Serve 声明式配置示例proxy_location: EveryNode http_options: host: 0.0.0.0 port: 8000 applications: - name: deepseek_serving route_prefix: /v1/chat/completions import_path: serving_app:entrypoint runtime_env: pip: - vllm0.7.3 - ray[serve]2.42.0 deployments: - name: VLLMWorker autoscaling_config: min_replicas: 2 max_replicas: 16 initial_replicas: 4 # 核心目标每个推理 Worker 维持的平均并发连接数 target_ongoing_requests: 12.0 # 扩容感知敏捷度控制 upscale_delay_s: 3.0 # 缩容冷却等待时间避免震荡 downscale_delay_s: 300.0 # 平滑度权重0 到 1 之间数值越小扩缩越渐进 smoothing_factor: 0.6 # 动态伸缩步长限制 upscaling_factor: 2.0 downscaling_factor: 0.5 graceful_shutdown_timeout_s: 60 max_ongoing_requests: 32 ray_actor_options: num_cpus: 8 num_gpus: 4 # 每副本采用 4 卡张量并行 resources: A100_80GB: 4核心参数深度剖析与防抖设计在调优上述扩缩容参数时必须理解以下三项控制参数在数学与控制论层面的深层含义1.upscale_delay_s与瞬时突发平抑upscale_delay_s定义了集群判定“确实需要扩容”所必须维持的持续时间窗口。在推理集群中不能仅因网络中出现持续 500ms 的瞬时抖动就盲目申请 4 张高端 GPU。我们将该值设置为3.0秒意味着只有当排队并发持续超出水位线超过 3 秒时控制器才会启动 Actor 调度有效过滤了微秒级网络震荡带来的惊群效应。2.downscale_delay_s与模型冷启动防卫在大模型场景下创建一个新的 Worker Replica 往往需要拉取数十 GB 的权重文件、初始化 CUDA 上下文并执行预热推理冷启动时间通常在 30 秒至 2 分钟之间。如果缩容过于激进在短暂的业务低谷刚一出现就杀掉实例那么数分钟后的下一波小高峰必然导致严重的请求堆积。因此我们将downscale_delay_s设置为300.0秒5 分钟给予实例充足的驻留缓冲区。3.smoothing_factor指数移动加权平均Ray Serve 控制器内部采用指数移动加权平均EMA来计算当前的期望副本数计算公式如下$$\text{平滑副本数}{t} \alpha \times \text{即时计算副本数} (1 - \alpha) \times \text{平滑副本数}{t-1}$$其中 $\alpha$ 即为smoothing_factor。通过将 $\alpha$ 设置为0.6能够让控制回路在快速响应突发流量占 60% 权重的同时保留对历史平稳水位的记忆占 40% 权重彻底消除弹性系统常见的阶跃锯齿振荡。链路闭环结合 KEDA 实现与底层云原生节点联动Ray Serve 运行在已有的 Ray 集群内部但当业务流量达到极限、当前 K8s 物理节点上的 GPU 已经全部耗尽时Ray 控制器无法无中生有地创造物理卡。此时必须打通 Ray Serve 与底层 Kubernetes 的集群自动扩缩容机制Cluster Autoscaler。我们通过 KEDAKubernetes Event-driven Autoscaling监听 Ray Serve 暴露的 Prometheus 指标ray_serve_deployment_queued_queries队列排队请求总数apiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: ray-worker-nodes-autoscaler namespace: ray-system spec: scaleTargetRef: apiVersion: ray.io/v1 kind: RayCluster name: ray-llm-cluster minReplicaCount: 2 maxReplicaCount: 8 triggers: - type: prometheus metadata: serverAddress: http://prometheus-k8s.monitoring.svc:9090 metricName: ray_serve_deployment_queued_queries query: sum(ray_serve_deployment_queued_queries{deploymentVLLMWorker}) threshold: 10 # 当网关堆积未处理请求超过 10 个时触发 K8s 物理 Node 扩容当队列堆积触发阈值后KEDA 会立即通知 RayCluster CRD 增加 Worker Pod 数量进而触发云厂商 Cluster Autoscaler 自动向物理机架借调空闲的 GPU 节点。整个过程完全由业务排队延迟驱动实现了从“应用网关队列”到“底层裸金属算力”的纵向贯通。总结大模型推理时代的弹性扩缩容已经从传统的“资源利用率静态匹配”演变为“请求排队时延与显存吞吐动态博弈”。通过深入挖掘 Ray Serve 原生的 Actor 控制回路结合基于并发与排队时延的精细化 EMA 调谐策略我们不仅能够将推理服务的 P99 时延紧紧压制在服务等级红线以内更能在低峰期自动化实现极致降本为智算中心的高效稳定运行提供坚实的技术支点。