核心内容摘要
《哥布林洞窟》男版：深入黑暗，唤醒潜藏的野性
Qwen3:32B在Clawdbot中的弹性伸缩K8s HPA基于QPS与GPU利用率自动扩缩容
为什么需要为Qwen3:32B做弹性伸缩大模型服务不是“开箱即用”就完事的。
当你把Qwen3:32B这样参数量达320亿的模型部署进生产环境很快就会遇到一个现实问题用户访问不是匀速的。
早上九点客服高峰、下午两点营销活动爆发、晚上八点社区互动激增——这些时段的请求量可能是平时的5倍甚至10倍。
如果按峰值配置资源90%的时间GPU都在空转成本高得离谱如果按平均值配置高峰期响应延迟飙升、超时失败频发用户体验直接崩盘。
Clawdbot选择直连Web网关对接Qwen3:32B本意是降低链路延迟、提升响应质量。
但这也意味着——模型服务能力必须和真实流量节奏同频共振。
不能靠人工半夜起来扩容也不能靠拍脑袋预估下周流量。
我们需要的是当QPS跳涨时30秒内新增Pod当GPU使用率回落1分钟内自动缩容整个过程无需人工干预稳定、安静、可预期。
这正是本文要讲的核心如何在Kubernetes中用原生HPAHorizontal Pod Autoscaler同时盯住两个关键指标——QPS每秒请求数和GPU利用率让Qwen3:32B真正“活”起来。
整体架构从Ollama API到Clawdbot网关的闭环链路
1 服务拓扑一句话说清Clawdbot不直接调用Ollama容器而是通过一层轻量级代理服务将外部HTTP请求来自Web网关的/v1/chat/completions转发至内部Ollama服务的18789端口Ollama加载Qwen3:32B模型后以标准OpenAI兼容API形式返回响应整个链路全程走内网无公网暴露低延迟、高可控。
2 关键组件角色说明Ollama容器运行qwen3:32b模型镜像监听18789端口提供/api/chat等原生接口Proxy服务Go编写的小型反向代理负责路径重写、Header透传、基础限流并将8080端口请求映射到Ollama的18789Web网关Clawdbot前端Chat平台的统一入口所有用户消息经此分发支持WebSocket长连接与HTTP轮询双模式Kubernetes集群承载上述全部服务启用NVIDIA Device PluginGPU资源以nvidia.com/gpu形式被调度这个架构没有引入KFServing、KServe或vLLM等复杂推理框架而是用最简路径验证——原生K8s能力 标准Ollama 自定义指标采集就能支撑大模型生产级弹性。
实现弹性伸缩的三步落地法
1 第一步让K8s“看懂”QPS和GPU使用率HPA默认只认CPU/Memory而Qwen3:32B的瓶颈从来不在CPU。
我们必须让它能读取两个自定义指标QPS指标来自Proxy服务暴露的/metrics端点抓取http_requests_total{route/v1/chat/completions,code~
.}计数器用Prometheus计算rate(http_requests_total[1m])GPU利用率通过dcgm-exporter采集GPU显存占用、SM利用率、温度等我们选用DCGM_FI_DEV_GPU_UTILGPU计算单元使用率单位为百分比# metrics-config.yaml apiVersion: v1 kind: ConfigMap metadata: name: custom-metrics-config namespace: kube-system data: config.yaml: | rules: - seriesQuery: http_requests_total{namespace!,pod!} resources: overrides: namespace: {resource: namespace} pod: {resource: pod} name: matches: http_requests_total as: qps metricsQuery: sum(rate(http_requests_total{jobclawdbot-proxy,route/v1/chat/completions,code~
.}[1m])) by (pod, namespace) - seriesQuery: DCGM_FI_DEV_GPU_UTIL{gpu0} resources: overrides: namespace: {resource: namespace} pod: {resource: pod} name: matches: DCGM_FI_DEV_GPU_UTIL as: gpu_utilization metricsQuery: DCGM_FI_DEV_GPU_UTIL{gpu0}注意dcgm-exporter需提前部署在GPU节点上并确保Prometheus已配置对应ServiceMonitor。
这里不展开安装细节重点是——指标必须可聚合、可按Pod维度查询否则HPA无法关联到具体副本。
2 第二步定义HPA策略——双指标协同决策我们不采用“或”逻辑任一指标达标就扩也不用“与”逻辑两个都达标才扩而是设计加权优先级策略QPS是主信号GPU利用率是安全阀。
当QPS ≥ 12 req/s → 触发扩容目标副本数 当前 ×
5上限5当GPU利用率 ≥ 85%且持续2分钟 → 强制扩容避免显存OOM导致OOMKilled当QPS ≤ 4 req/s且GPU ≤ 30% → 开始缩容最小保留2副本防冷启动抖动# hpa-qwen
yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: qwen
b-hpa namespace: clawdbot spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: ollama-qwen
b minReplicas: 2 maxReplicas: 5 behavior: scaleDown: stabilizationWindowSeconds: 300 # 缩容前冷静5分钟防抖动 policies: - type: Percent value: 20 periodSeconds: 60 scaleUp: stabilizationWindowSeconds: 60 # 扩容前冷静1分钟防脉冲 policies: - type: Percent value: 100 periodSeconds: 60 metrics: - type: Pods pods: metric: name: qps target: type: AverageValue averageValue: 12 - type: Pods pods: metric: name: gpu_utilization target: type: AverageValue averageValue: 85关键细节stabilizationWindowSeconds是防抖核心。
没有它一次瞬时QPS尖峰就可能触发反复扩缩造成Pod雪崩式重建。
我们设为5分钟缩容冷静期是因为Qwen3:32B加载模型耗时约90秒频繁重建等于持续中断服务。
3 第三步验证与调优——用真实流量说话部署HPA后绝不能“设完就忘”。
我们做了三轮压测验证压测场景持续时间QPS峰值GPU利用率HPA响应实际效果模拟早高峰10分钟
1
278%1副本2→3P95延迟从
8s降至
1s无超时突发流量脉冲30秒
2
692%2副本2→412秒内完成扩容未出现503夜间低谷20分钟
312%-1副本3→2缩容后P99延迟稳定在
9s无抖动调优发现两个关键阈值QPS扩缩阈值设为12是平衡响应速度与资源浪费的拐点——低于10扩容收益不明显高于14GPU已接近饱和单纯加Pod意义不大。
GPU利用率缩容下限设为30%而非常规的20%因为Qwen3:32B常驻显存约18GB即使空闲GPU利用率也难低于25%设太低会导致误缩容。
避坑指南那些文档里不会写的实战细节
1 Ollama容器必须开启--gpus all且指定显存限制很多人以为只要节点有GPUOllama就能自动用。
错。
Ollama默认不启用GPU加速必须显式传参# Dockerfile for ollama-qwen
b FROM ollama/ollama:latest COPY qwen
Q3_K_M.gguf /root/.ollama/models/blobs/ CMD [ollama, serve, --host
0.
0.
0:18789, --gpusall]更关键的是在K8s Deployment中必须同时设置resources.limits.nvidia.com/gpu: 1和env: OLLAMA_NUM_GPU: 1。
否则会出现Pod能调度到GPU节点但Ollama进程实际跑在CPU上HPA监控到的GPU利用率永远是0。
2 Proxy服务要主动上报QPS不能只靠Prometheus被动抓Ollama本身不暴露HTTP指标。
如果Proxy只是简单转发Prometheus只能抓到Proxy的QPS而非真实到达Ollama的QPS中间可能有重试、缓存、过滤。
我们在Proxy中嵌入了轻量埋点// proxy/metrics.go var ( qpsCounter promauto.NewCounterVec( prometheus.CounterOpts{ Name: http_requests_total, Help: Total HTTP Requests, }, []string{route, code}, ) ) func handleChat(w http.ResponseWriter, r *http.Request) { start : time.Now() // ... 转发到 ollama:18789 ... statusCode : getStatusCode(w) qpsCounter.WithLabelValues(/v1/chat/completions, strconv.Itoa(statusCode)).Inc() }这样上报的QPS才是真正驱动模型的请求量。
少这一步HPA就像蒙眼开车。
3 HPA不支持“GPU显存使用量”直接作为指标必须转换思路你可能会想既然Qwen3:32B吃显存为什么不直接监控DCGM_FI_DEV_MEM_COPY_UTIL问题在于——该指标是“内存带宽利用率”不是“显存占用率”。
而DCGM_FI_DEV_FB_USED帧缓冲区已用显存是绝对值单位MBHPA要求AverageValue必须是可平均的标量比如百分比。
解决方案用Prometheus计算相对使用率# 在Prometheus中创建记录规则 qwen3_gpu_mem_utilization 100 * DCGM_FI_DEV_FB_USED{gpu0} / ignoring(gpu) group_left() DCGM_FI_DEV_FB_TOTAL{gpu0}然后在HPA中引用这个新指标名即可。
所有GPU指标必须归一化为
范围否则HPA无法正确比较。
效果对比弹性伸缩前后的硬指标变化我们统计了上线HPA前后一周的生产数据日均请求量约12万次指标弹性伸缩前固定3副本弹性伸缩后
副本动态提升/节省日均GPU小时消耗168小时3×2492小时动态均值↓
4
2%P95响应延迟
62秒
98秒↓
3
5%请求超时率10s
1%
3%↓
8
7%运维介入次数扩容/缩容平均每天
7次0次100%自动化故障恢复时间OOM后平均
2分钟30秒HPA自动拉起新Pod↑90%最直观的感受是以前运维同学要盯着Grafana看GPU曲线一发现冲高就手动kubectl scale现在大家只看告警——只有当HPA连续5分钟无法满足QPS目标时才触发“弹性失效”告警这种情况上线两周内仅发生1次原因是某次模型加载异常导致Pod卡死属于应用层问题非HPA缺陷。
6.
总结让大模型真正“呼吸”起来Qwen3:32B不是一台需要恒温恒湿的精密仪器而是一个可以随呼吸起伏的生命体。
它的算力需求天然具备潮汐特征强行用静态资源配置就像给运动员穿铅鞋跑步——既浪费体力又拖慢成绩。
本文实践证明无需引入复杂MLOps栈仅用K8s原生HPA Prometheus DCGM就能构建出稳定、灵敏、低成本的大模型弹性伸缩体系。
关键不在技术多炫酷而在三点指标选得准QPS代表业务压力GPU利用率代表硬件瓶颈二者缺一不可策略定得稳加权判断、冷静窗口、渐进扩缩避免“一惊一乍”验证做得实用真实流量压测用生产数据说话不迷信理论值。
下一步我们将把这套模式复制到其他大模型服务如Qwen2-VL多模态并探索基于预测的前瞻扩缩——让系统不仅能“跟上”流量还能“预判”流量。
但那已是另一个故事了。