Grok自动扩容：CPU与显存驱动的动态实例策略
线上Grok推理服务在遭遇突发流量时，手动扩缩容完全跟不上——单实例CPU利用率冲上85%，GPU显存逼近90%，这类毫秒级抖动必须依赖自动化策略。以下方案基于Prometheus采集CPU与GPU显存指标，设置双阈值告警（CPU>85%、GPU显存>90%，持续2分钟），再结合HPA behavior定制“扩容迅猛、缩容保守”的行为策略，绑定自定义/外部指标实现亚分钟级弹性伸缩。
配置Prometheus抓取Grok核心指标
定位到Prometheus配置目录，编辑prometheus.yml，在scrape_configs区块新增一个采集任务：
```yaml - job_name: 'grok-inference' static_configs: - targets: ['localhost:9090'] metrics_path: /metrics ```确保Grok服务已开放/metrics端点——如果未启用，需在run.py中调用start_http_server(9090)并注册prometheus_client的指标，否则所有告警规则都会失效。修改后重启Prometheus加载新配置。
定义关键扩缩容触发条件
创建告警规则文件grok-autoscale.rules.yml，写入以下两条规则：
① CPU过载告警（触发扩容）：
【expr】 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
② GPU显存临界告警（触发扩容）：
【expr】 gpu_memory_used_percent{device="0"} > 90
两条规则必须同时满足“持续2分钟”才触发动作——避免瞬时峰值造成误扩。显存指标名称必须与nvidia-smi exporter实际暴露的label完全一致，device="0"不能写成"gpu0"或省略。
部署Kubernetes HPA并绑定指标
方法一：基于自定义指标（推荐）
快速生成HPA模板：
kubectl autoscale deployment grok-inference --cpu-percent=70 --min=1 --max=8
然后用kubectl edit hpa grok-inference将metrics字段替换为：
方法二：使用KEDA适配器（适用于非标准指标）
先安装KEDA Operator，再创建ScaledObject资源将Prometheus查询结果映射为伸缩信号源。这种方式支持复杂多条件组合，但需额外维护KEDA组件。
设置扩容步长与冷却窗口
必须手动编辑HPA YAML，因为kubectl autoscale命令无法生成behavior字段。若跳过此步，默认的激进缩容策略可能直接杀掉仍在处理长推理请求的Pod。
在HPA的behavior下：
- scaleUp设
stabilizationWindowSeconds: 300（防止5分钟内频繁震荡），policies：type: Percent, value: 200, periodSeconds: 60。 - scaleDown设
stabilizationWindowSeconds: 600（缩容更保守，避免误杀），并设置selectPolicy: Disabled——禁用自动缩容，仅靠显存+CPU双指标联合触发扩容。
配置完成后，即使流量回落，HPA也不会立即缩减Pod数量，给长任务留足缓冲时间。
验证自动扩容链路是否打通
对Grok服务发起持续压测：
locust -f load_test.py --headless -u 50 -r 10 --host http://grok-service
同时监听Kubernetes事件流：
kubectl get events --sort-by='.lastTimestamp' | tail -20
当CPU和显存双指标持续超过阈值2分钟后，应看到类似事件：
ScalingReplicaSet grok-inference-7c8d9b4f5 → Scaled up replica set grok-inference-7c8d9b4f5 from 1 to 3
再检查新Pod状态：
kubectl get pods -l app=grok-inference ——确认新实例处于Running且Ready=True。整条链路打通后，后续流量激增也能自动扛住。