最近在推进一个 AI 大模型项目上线时遇到一个很现实的问题模型效果还没完全验证GPU 和电力成本先上来了。更让人头疼的是集群里经常出现“排队等卡但卡真正跑起来的时间不到一半”的情况。把问题拆开看其实就是三件事AI 算力需求暴涨、电力成本上升、资源利用率却没有同步跟上。“AI 电力荒”不是新闻标题而是工程团队每天都能感受到的预算压力。既然算力资源越来越贵我们就不能只关心“模型效果”还要关心“一度电能跑多少次推理”。这篇文章想分享的就是AI工程实践中的一把“新铲子”把 GPU 利用率、弹性伸缩、推理加速、成本可视化串起来的一套落地方法。文章会从概念讲起然后给出可直接复制的 YAML、命令行和 Python 示例再补充常见坑点与工程建议。1. 背景与核心概念AI 电力荒下的新铲子是什么1.1 从“算力焦虑”到“电力焦虑”过去几年AI 大模型的训练和推理主要看算力是否够用团队关注的是“多少钱能买多少张卡”。但进入大模型常态化部署阶段之后问题悄悄变了卡买回来了电费、机房容量、散热、PUE 开始成为瓶颈。一个典型的 8 卡 GPU 服务器满载功耗可能接近普通家庭一个月的用电量。如果集群里大部分时间都在跑低效任务、空转等待、重复加载模型那么电费就变成了“无效成本”。不管是自建机房还是使用云 GPU最终都会体现到账单上。所以我更愿意把“AI 电力荒”理解成一个工程问题在有限的电力与算力预算下如何让每一次模型调用都更快、更省、更稳定。这不是要我们放弃大模型而是要用更精细的调度和可观测手段把有限的资源用在刀刃上。1.2 “新铲子”到底指什么“淘金热里最赚钱的是卖铲子的人”这句话放在 AI 时代同样适用。大模型是金矿而“铲子”就是支撑大模型从训练走向生产的一系列工程工具和方法。在 AI 电力荒背景下我理解的新铲子包括四类弹性算力工具Kubernetes、HPA、KEDA让 GPU Pod 按真实负载伸缩。推理加速工具vLLM、TensorRT-LLM 这类支持连续批处理和 PagedAttention 的推理框架。模型瘦身工具量化、蒸馏、剪枝降低显存占用和单次推理功耗。可观测与成本核算工具Prometheus、Grafana、DCGM Exporter让能耗和利用率变得可见。这篇文章会围绕这四类展开。它们不是互相替代的关系而是从不同层面解决“算力浪费”的问题。对后端开发者来说理解这套工具链比单纯会调 API 更能提升 AI 项目的交付质量。1.3 为什么后端工程师也要关注 AI 电力成本很多后端工程师觉得自己不训练模型只调用接口电力成本与自己无关。但实际上生产环境里的 AI 服务推理路径往往由后端团队维护。举一个例子AI Agent 工作流。一个 Agent 任务可能需要多次调用大模型包括规划、工具调用、结果总结。如果后端代码对并发控制不当或者没有做缓存、没有区分任务优先级同一个请求就会产生好几倍的 token 消耗和 GPU 时间。单次调用看不出问题放大到每天几十万次请求电力成本和响应延迟都会明显上升。另外部署模型时选择的 GPU 规格、副本数、显存利用率、推理引擎参数也都由后端或 MLOps 团队决定。因此掌握资源治理思路是 AI 工程实践里不可绕过的一环。2. 应对 AI 电力荒的四种“新铲子”思路2.1 弹性算力让 GPU 按需启停很多团队部署模型服务时习惯固定 2 个副本常驻。如果业务请求集中在白天晚上几乎没人访问GPU 白白空转一整晚电费和资源占用都会持续产生。正确的思路是让服务具备“弹性”请求量大时自动扩容空闲时自动缩容到 0 或 1 个副本。Kubernetes 的 HPA 可以基于 CPU、内存指标伸缩但在 GPU 场景下更推荐基于 GPU 利用率或者请求队列深度来伸缩。弹性算力不是银弹它适合有一定流量波动的推理服务。对于需要低延迟且持续高并发的核心业务可以设置最小副本数避免冷启动影响体验。2.2 推理加速从显存和吞吐量入手同样的模型用不同的推理引擎吞吐量可能相差数倍。vLLM 是当前社区使用较广的推理加速框架它通过 PagedAttention 降低了显存碎片通过连续批处理提高 GPU 利用率。在同样一张 A100或同级别GPU上部署同一个 7B 模型vLLM 的吞吐量通常比朴素实现有显著提升。虽然具体提升幅度取决于硬件、模型和请求长度但整体趋势是可以确定的。推理加速带来的收益是很直接的单位时间完成更多请求单次请求的平均耗电量下降总成本随之下降。2.3 模型瘦身量化、蒸馏、剪枝推理速度不仅取决于引擎还取决于模型本身。模型参数量越大前向计算需要的算力和显存越高。量化就是最常见的手段之一比如把模型权重从 FP16 压缩为 INT8 或 INT4可以降低显存占用同时在一部分 GPU 上获得更高吞吐。蒸馏则是用大模型生成数据训练一个规模更小的模型让小模型在特定任务上接近大模型的效果。剪枝则关注删除模型中冗余参数或通道。模型瘦身适合两类场景一类是服务端对时延和成本敏感另一类是边缘设备部署。需要注意的是量化可能会带来精度损失需要通过评测集验证后再上线。2.4 可观测与成本核算让能耗可见很多团队上了 Kubernetes却没有部署任何 GPU 监控。GPU 利用率、显存占用、功耗、温度都是黑盒。黑盒状态下优化最多只能靠猜测。可观测工具先把数据暴露出来再把成本映射到指标上。比如通过 DCGM Exporter 采集 GPU 利用率与功耗通过 Prometheus 存储指标再通过 Grafana 展示。这样能直观看到“哪个服务最耗电”“哪个 Pod 长期利用率低”后续优化才有依据。3. 环境准备与版本说明3.1 基础环境本文的示例偏向生产环境常见的 Kubernetes GPU 调度场景同时也包含单机推理验证。操作系统推荐 Ubuntu 22.04 或同类 Linux 发行版。Kubernetes 集群建议使用 1.26 以上版本并提前安装 NVIDIA GPU Operator 或 NVIDIA device plugin让集群可以调度nvidia.com/gpu资源。GPU 驱动版本需要与容器运行时和 CUDA 版本匹配。由于不同厂商、不同云平台的驱动版本差异较大本文不锁定具体版本大家在实际部署时使用当前稳定版本即可。推理引擎以 vLLM 为主要示例。vLLM 更新速度较快不同版本的启动命令有差异较新版本推荐vllm serve旧版本使用python3 -m vllm.entrypoints.openai.api_server。文中会给出两种命令的说明。3.2 示例项目结构为了便于演示我整理一个简单的目录结构ai-power-toolkit/ ├── k8s/ │ ├── llm-deployment.yaml │ ├── llm-service.yaml │ └── llm-hpa.yaml ├── monitor/ │ ├── prometheus-scrape.yaml │ ├── dcgm-exporter.yaml │ └── grafana-alert.yaml ├── client/ │ ├── openai_sdk_demo.py │ └── concurrent_test.py └── README.md这不是一个完整的代码仓库但可以当作项目脚手架。接下来几个章节会按这个结构逐个落地。4. 实战一用 Kubernetes 构建弹性 GPU 推理服务4.1 编写 GPU 推理服务 Deployment先创建一个命名空间隔离资源kubectl create namespace ai-infra然后编写k8s/llm-deployment.yaml使用 vLLM 部署一个 7B 级别的开源模型。这里以 Qwen2.5 系列为例实际部署时替换成你的模型路径即可# 文件路径k8s/llm-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: llm-inference namespace: ai-infra labels: app: llm-inference spec: replicas: 1 selector: matchLabels: app: llm-inference template: metadata: labels: app: llm-inference spec: containers: - name: vllm image: vllm/vllm-openai:latest command: - vllm - serve args: - Qwen/Qwen2.5-7B-Instruct - --host - 0.0.0.0 - --port - 8000 - --gpu-memory-utilization - 0.9 - --max-model-len - 8192 ports: - containerPort: 8000 resources: limits: nvidia.com/gpu: 1这段配置需要注意几点resources.limits中声明了nvidia.com/gpu: 1表示该 Pod 需要一张 GPU。--gpu-memory-utilization 0.9表示 vLLM 最多使用 90% 的显存预留部分给 CUDA context 等额外开销。--max-model-len 8192限制了最大输入和输出总长度避免显存被超长请求打爆。如果你的集群中 GPU 资源紧张可以从0.9下调到0.8或0.7以降低单 Pod 显存占用便于更多副本调度。4.2 创建 Service 暴露服务Deployment 创建后Pod 的 IP 是会变化的需要 Service 提供稳定的访问入口。使用 NodePort 类型方便测试# 文件路径k8s/llm-service.yaml apiVersion: v1 kind: Service metadata: name: llm-inference namespace: ai-infra spec: type: NodePort selector: app: llm-inference ports: - name: http port: 8000 targetPort: 8000 nodePort: 30080应用配置kubectl apply -f k8s/llm-deployment.yaml kubectl apply -f k8s/llm-service.yaml等待 Pod 处于 Running 状态kubectl -n ai-infra get pods如果镜像较大首次拉取可能需要几分钟。看到1/1 Running后可以查看日志确认 vLLM 是否完成模型加载kubectl -n ai-infra logs -f deployment/llm-inference日志中出现类似Application startup complete或模型加载完成的输出就说明服务已经就绪。4.3 配置基于 GPU 利用率的弹性伸缩生产环境里固定 1 个副本通常不够。我们可以通过 HPA 让副本数在 1 到 5 之间自动伸缩。GPU 场景的伸缩指标建议使用 DCGM Exporter 采集的 GPU 利用率。HPA 配置如下# 文件路径k8s/llm-hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: llm-inference-hpa namespace: ai-infra spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: llm-inference minReplicas: 1 maxReplicas: 5 metrics: - type: Pods pods: metric: name: gpu_utilization target: type: AverageValue averageValue: 60应用配置kubectl apply -f k8s/llm-hpa.yaml需要注意这里用到的gpu_utilization指标名需要由 Prometheus Adapter 或 KEDA 从 DCGM Exporter 采集后暴露给 Kubernetes 自定义指标 API。不同监控组件的指标命名可能不同具体名称以你集群中实际配置为准。HPA 的伸缩策略可以加一个稳定窗口避免频繁伸缩spec: behavior: scaleDown: stabilizationWindowSeconds: 300 scaleUp: stabilizationWindowSeconds: 60这样在流量瞬间波动时不会因为单个毛刺就触发大规模扩展或收缩对电力成本和稳定性都更友好。4.4 验证弹性伸缩效果使用一个简单的压测脚本向 vLLM 服务发送并发请求。以 Python 的httpx为例# 文件路径client/concurrent_test.py import asyncio import httpx SERVICE_URL http://node-ip:30080/v1/chat/completions async def send_one(client, index): payload { model: Qwen/Qwen2.5-7B-Instruct, messages: [{role: user, content: 请写一段关于杭州西湖的简短介绍。}], max_tokens: 256, } resp await client.post(SERVICE_URL, jsonpayload) return index, resp.status_code async def main(): async with httpx.AsyncClient(timeout120) as client: tasks [send_one(client, i) for i in range(50)] results await asyncio.gather(*tasks) for index, code in results: print(frequest {index}: {code}) asyncio.run(main())压测过程中观察 HPA 状态kubectl -n ai-infra get hpa如果配置正确副本数会随着并发请求增加而扩展。测试结束后等待稳定窗口过去副本数会回落到最小值。这个行为就是“按需用电”的关键。5. 实战二基于 vLLM 的推理加速与显存优化5.1 vLLM 为什么能省电vLLM 的核心优化之一是 PagedAttention它把 KV Cache 分成固定大小的块像操作系统的虚拟内存一样管理从而降低显存碎片提高显存利用率。另一个关键优化是 Continuous Batching。传统推理服务通常等待一个批次全部生成完后再处理下一批请求。而 Continuous Batching 可以动态地在每个解码步骤插入新的请求让 GPU 始终在处理有效计算而不是等待空闲。GPU 利用率提高后完成相同数量请求的总耗电时间会下降。5.2 单机启动 vLLM 服务单机验证时可以直接在命令行启动vllm serve Qwen/Qwen2.5-7B-Instruct \ --host 0.0.0.0 \ --port 8000 \ --gpu-memory-utilization 0.9 \ --max-model-len 8192如果你的 GPU 显存较小可以先使用量化后的模型。以下命令将模型指定为 AWQ 量化版本vllm serve Qwen/Qwen2.5-7B-Instruct-AWQ \ --host 0.0.0.0 \ --port 8000 \ --quantization awq \ --gpu-memory-utilization 0.9 \ --max-model-len 8192量化后的模型权重要小得多推理时的显存占用和单步功耗都会降低缺点是需要通过评测确认精度是否满足业务要求。5.3 使用 OpenAI SDK 访问 vLLM 服务vLLM 提供了兼容 OpenAI 的 HTTP 接口因此客户端代码可以直接使用openaiPython SDK# 文件路径client/openai_sdk_demo.py from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY, ) response client.chat.completions.create( modelQwen/Qwen2.5-7B-Instruct, messages[ {role: user, content: 用一句话解释什么是 AI 电力荒。} ], temperature0.7, max_tokens256, ) print(response.choices[0].message.content)运行python client/openai_sdk_demo.py看到模型返回结果说明 vLLM 推理链路已经打通。在生产环境中可以用同样的接口对接内部系统。5.4 多副本部署时的显存与调度建议单卡显存不足时vLLM 支持张量并行和流水线并行。以两张 GPU 为例vllm serve Qwen/Qwen2.5-7B-Instruct \ --tensor-parallel-size 2 \ --host 0.0.0.0 \ --port 8000不过在多副本场景下更推荐“单 Pod 单模型副本”的朴素方案由 Kubernetes 负责副本之间的负载均衡。这样调度简单故障域也更清晰。当模型大到单卡放不下时才考虑在 Pod 内部使用多卡并行。6. 实战三能耗与成本可视化监控6.1 部署 DCGM ExporterGPU 信息的采集通常依赖 DCGM Exporter。它暴露了 GPU 利用率、显存使用、温度、功耗等指标。在 Kubernetes 中可以使用 DaemonSet 在每个节点上运行一个 exporter 实例。# 文件路径monitor/dcgm-exporter.yaml apiVersion: apps/v1 kind: DaemonSet metadata: name: dcgm-exporter namespace: ai-infra spec: selector: matchLabels: name: dcgm-exporter template: metadata: labels: name: dcgm-exporter spec: containers: - name: dcgm-exporter image: nvidia/dcgm-exporter:latest ports: - containerPort: 9400 name: metrics resources: limits: nvidia.com/gpu: 0这里将 GPU 请求设置为 0是因为 exporter 本身不需要独占 GPU但它可以读取宿主机 GPU 信息。6.2 配置 Prometheus 抓取指标假设集群中已经安装 Prometheus只需要添加一个抓取任务# 文件路径monitor/prometheus-scrape.yaml scrape_configs: - job_name: dcgm-exporter kubernetes_sd_configs: - role: pod relabel_configs: - source_labels: [__meta_kubernetes_pod_label_name] action: keep regex: dcgm-exporter - source_labels: [__meta_kubernetes_pod_namespace] action: replace target_label: namespace - source_labels: [__meta_kubernetes_pod_ip] action: replace target_label: instancePrometheus 抓取到指标后可以在查询页面输入dcgm_gpu_utilization如果返回了 GPU 利用率序列说明采集链路正常。常用的指标还包括dcgm_gpu_mem_useddcgm_gpu_power_usagedcgm_gpu_temp6.3 配置 Grafana 看板与告警Grafana 中配置数据源指向 Prometheus然后创建一个 Dashboard。最常用的三个面板GPU 利用率查看每个 GPU 的实时使用率。GPU 功耗查看单卡功耗和总功耗。显存使用量判断是否有显存浪费。同时可以配置告警规则。下面是一个简单的 Prometheus 告警示例当某个 GPU 利用率长期低于 20% 时发出提醒# 文件路径monitor/grafana-alert.yaml groups: - name: gpu-alert rules: - alert: GpuUtilizationLow expr: avg(dcgm_gpu_utilization) 20 for: 30m labels: severity: warning annotations: summary: GPU 利用率低于 20% description: 集群中 GPU 平均利用率持续偏低建议检查服务副本数和请求量。这个告警的价值在于低利用率往往意味着两种可能。要么是业务请求量确实少可以缩容要么是服务配置不合理比如模型加载时间过长、并发控制有问题。7. 常见问题与排查思路7.1 GPU 利用率很低但响应速度很慢问题现象常见原因解决思路GPU 利用率低响应慢单请求串行处理没有开连续批处理检查推理服务是否使用 vLLM 或类似引擎GPU 利用率低响应慢模型加载路径缓慢或频繁加载确保模型已预热避免频繁 reloadGPU 利用率低响应慢客户端并发不足压测时使用并发脚本不要单线程调用7.2 显存溢出 OOM问题现象常见原因解决思路请求时报 OOMmax-model-len 设置过大在显存允许范围内下调 max-model-len请求时报 OOMKV Cache 占用过多降低 gpu-memory-utilization留出余量请求时报 OOM模型超过单卡显存使用量化模型或开启多卡并行7.3 HPA 不生效问题现象常见原因解决思路HPA 不扩缩容自定义指标没有暴露检查 Prometheus Adapter 指标名是否正确HPA 不扩缩容没有安装 metrics-server 或 adapter按集群版本安装对应组件HPA 频繁抖动稳定窗口设置过短增加 stabilizationWindowSeconds7.4 缩容后重新扩容太慢冷启动过程中模型需要重新加载到显存耗时可能从几秒到几分钟不等。如果业务对延迟敏感建议设置最小副本数为 1 或 2避免缩容到 0 导致冷启动影响体验。另一种思路是使用模型缓存或预热机制让新 Pod 创建后立即加载已缓存的权重文件减少从远端拉取模型的时间。8. 最佳实践与工程建议8.1 先量化再上 Kubernetes如果业务对精度要求不是极高可以优先考虑量化模型。量化后单卡可承载的模型规模更大副本数可以更少电力成本也更低。但量化前一定要准备一份评测数据集对比量化前后在关键指标上的差异不能只看显存下降就上线。8.2 给模型服务设置合理的副本数和资源水位不要把 GPU 显存全部打满。建议预留 5% 到 10% 的显存余量防止 CUDA context、内存碎片和瞬时峰值导致 OOM。副本数的设置也要结合业务流量曲线不要为了节省成本把所有服务都缩到 0也要避免固定副本数常年空转。8.3 监控先行优化后置先部署 DCGM Exporter、Prometheus、Grafana再开始调整参数。有了数据才能判断瓶颈是 GPU 算力、显存容量还是并发控制。没有监控的集群任何优化都很难验证效果。8.4 AI Agent 与工作流也要做资源治理AI Agent 开发越来越流行但 Agent 任务往往带来“长尾调用”一个任务可能触发几十次模型调用而且大部分调用并不需要最高精度的模型。一个可行的实践是简单任务走小模型或缓存。复杂任务走大模型。给 Agent 任务设置最大 token 数和超时时间防止失控请求长期占用 GPU。对重复性文本生成优先使用缓存层。这样可以从业务层面减少无效计算比单纯优化推理引擎更有效。8.5 保证安全与合规边界在生产环境操作集群时需要遵循最小权限原则。使用独立的命名空间隔离不同业务配置 RBAC 限制操作权限。涉及删除 Deployment、调整副本数或升级推理引擎时先在测试环境验证再执行生产变更。另外如果使用云 GPU要关注实例规格切换的成本。不同实例类型价格差异很大容量和性能也完全不同。部署前先做一次小规模压测确认规格和成本是否符合预期避免上线后频繁迁移。8.6 用 AI 辅助工具加速工程调试写监控脚本、部署 YAML、排查日志时可以借助 Cursor 等 AI 编程工具生成初稿再结合本地环境修正。这些工具本身也消耗算力但它能把工程师从重复劳动中解放出来。重点是把 AI 生成的内容当作“初稿”而不是“终稿”关键配置仍需人工审查。9. 总结与下一步学习路线本文从“AI 电力荒”这个现实问题出发介绍了几类有效的“新铲子”弹性算力调度、vLLM 推理加速、模型量化和可观测监控。通过 Kubernetes Deployment HPA 示例完成了 GPU 推理服务的弹性伸缩配置通过 vLLM 启动和 OpenAI SDK 调用演示了推理加速的基本流程通过 Prometheus 与 DCGM Exporter让 GPU 功耗和利用率变得可观测。下一步可以继续学习这些方向Kubernetes 自定义指标与 KEDA掌握更复杂的弹性伸缩策略。vLLM 的 PagedAttention 实现细节理解 KV Cache 管理对显存的影响。TensorRT-LLM 的模型编译与优化适合对时延要求更高的线上服务。大模型评测与量化精度分析为模型瘦身提供数据支撑。Cost 可视化平台建设把 GPU 功耗、价格和业务请求量关联起来。如果你正在上线 AI 大模型服务建议先部署监控再优化推理引擎最后再调整弹性策略。先把“一度电能跑多少个请求”这个指标盯住你就能在 AI 电力荒里找到那把真正顺手的新铲子。