云原生服务的预算治理“预算有限时先优化哪一项”首先要落到可观察、可回滚的工程动作上。本文从配置、调用链和运行指标三个层面梳理判断方法重点说明应先收集什么证据、怎样做小范围验证以及何时应停止扩张改动。文中出现的故障现象、容量规模、延迟和资源数值均为说明机制的示例并非可直接套用的线上结论。实际阈值应结合服务目标、依赖能力、流量形态和压测结果确定涉及生产变更时应先灰度并保留回滚路径。GPU 闲置与 Sidecar 内存膨胀的现场诊断在一套典型的 AI 检索增强与推理服务架构中集群资源开销主要由两部分构成运行 Envoy/Istio 的 Sidecar 代理层以及挂载 NVIDIA A100/H100 的 LLM 推理节点。诊断监控指标时经常能看到两类典型异常Envoy 控制面全量推送导致 Sidecar 占用 1.5GB 内存随着集群微服务数量增加Envoy 会加载所有服务的 Endpoint 路由表即便当前推理服务只需要调用 2 个下游工程。HPA 依据 CPU 阈值扩缩容导致 GPU 节点提前空转或过载爆显存传统 K8s HPA 监测cpu_utilization 80%但 LLM 推理瓶颈在 KV Cache 内存与 GPU-UtilCPU 占用率高往往只是 HTTP/gRPC 解析的假象。第一优先项对 Sidecar 控制面与 EnvoyFilter 施加“外科手术”如果你手头只有一周时间降低账单第一件事绝对不是改模型代码而是裁剪 Envoy 的配置数据流。集群内部默认的控制面如 Istio Pilot会将全量 Cluster、Listener、Endpoint 推送给每一个 Sidecar。在拥有 300 服务的集群中单个 Envoy 内存开销就能达到 800MB 到 2GB。1.1 使用 Sidecar CRD 进行命名空间级隔离通过配置Sidecar资源限定推理网格服务仅接收特定 Namespace 的路由信息apiVersion: networking.istio.io/v1alpha3 kind: Sidecar metadata: name: llm-inference-sidecar-scope namespace: ai-serving spec: workloadSelector: labels: app: llm-gateway egress: - hosts: - ./* - istio-system/* - vector-db/qdrant.svc.cluster.local仅此一项改动集群内 50 个推理相关 Pod 的 Sidecar 内存占用即可从平均 1.2GB 降至 90MB 左右直接省出数台高配内存型宿主机的租赁成本。1.2 关闭无用的 Envoy 统计指标Envoy 默认产生的 Metric 数量极其庞大数十万个维度不仅消耗 Pod 本身 CPU 处理 Prometheus scraping还会压垮监控 TSDB 实例。在 Mesh 配置中精简统计信息meshConfig: defaultConfig: proxyStatsMatcher: exclusionRegexps: - .*http.*downstream_rq_time.* - .*cluster.*upstream_cx_connect_ms.* inclusionPrefixes: - http.upstream_rq_completed - http.downstream_rq_5xx第二优先项引入基于 Token 指标与 KV Cache 的 Pod 弹性伸缩传统利用 CPU/Memory 指标做弹性伸缩HPA在 AI 云原生后端里基本失效。显存被 KV Cache 占满时 CPU 占用可能只有 20%而请求在 Queue 中排队时 CPU 却因为 Busy-loop 飙到 100%。2.1 基于 vLLM/TGI Prometheus Metrics 的 KEDA 配置我们需要根据vllm:num_requests_waiting等待队列长度和vllm:gpu_cache_usage_percKV Cache 显存使用率来进行 Pod 级别的扩缩容。安装 KEDA 并配置ScaledObjectapiVersion: keda.sh/v1alpha1 kind: ScaledObject metadata: name: vllm-gpu-autoscaler namespace: ai-serving spec: scaleTargetRef: name: vllm-qwen-72b-worker minReplicaCount: 1 maxReplicaCount: 8 cooldownPeriod: 300 pollingInterval: 15 triggers: - type: prometheus metadata: serverAddress: http://prometheus-k8s.monitoring.svc:9090 metricName: vllm_gpu_cache_usage_perc query: sum(vllm_gpu_cache_usage_perc{namespaceai-serving}) / count(vllm_gpu_cache_usage_perc{namespaceai-serving}) threshold: 0.85 - type: prometheus metadata: serverAddress: http://prometheus-k8s.monitoring.svc:9090 metricName: vllm_num_requests_waiting query: sum(vllm_num_requests_waiting{namespaceai-serving}) threshold: 52.2 缩容缩期中的“优雅冷却Graceful Shutdown”机制GPU 节点启动慢加载 70B 模型权重大约需要 90-180 秒一旦缩容触发过快极易造成流量塌陷。设置cooldownPeriod: 3005分钟冷却期防止指标短暂下降引发剧烈抖动Thashing。Envoy 配置preStop钩子让 Pod 进入Terminating状态后继续消化完已分配到当前 Pod 的 Token 序列流再销毁。第三优先项后端 gRPC 长连接与 Envoy Dynamic Routing 流量治理AI 推理通常以 SSEServer-Sent Events或 gRPC Stream 形式向前端吐出 Token。传统 Round-Robin 负载均衡会导致某些 Pod 承载了 10 个长长文本推理请求而另一些 Pod 承载了 10 个短文本请求显存与计算资源极度失衡。利用 Envoy 的LEAST_REQUEST负载均衡策略配合 HTTP/2 流控apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: vllm-backend-lb namespace: ai-serving spec: host: vllm-qwen-72b-worker.ai-serving.svc.cluster.local trafficPolicy: loadBalancer: localityLbSetting: enabled: true consistentHash: null simple: LEAST_REQUEST connectionPool: tcp: maxConnections: 1024 http: http1MaxPendingRequests: 100 maxRequestsPerConnection: 10通过限制maxRequestsPerConnection强迫客户端或 Ingress 网关在长连接上定期重新握手从而将请求均匀分发给刚扩容出来的空闲 GPU 节点。架构优化落地的资源对比结果在某中型 AI SaaS 后端架构调优中我们按照上述优先级落地了方案运行两周后收集到的实测数据如下治理阶段Envoy 单 Pod 内存GPU 平均利用率峰值 P99 响应延时月度预算缩减比例未治理初始状态1350 MB32%4.2s100%基准线阶段一Envoy Sidecar 作用域裁剪92 MB33%4.1s-12%阶段二基于 KEDA/Token 队列弹性95 MB74%2.8s-35%阶段三Dynamic Routing 均衡调优98 MB81%1.9s-41%预算有限时绝不能漫无目的地同时推行所有优化方案。第一时间清理 Envoy 控制面冗余配置拿掉多余的内存开销随后改写弹性伸缩指标让 GPU 节点的扩缩容真正基于推理队列状态而非 CPU。这两步搞定后集群自然能在业务平峰期自动退租高昂的 GPU 实例把每一分钱都用在刀刃上。