当前位置：首页 > news >正文

云原生工程化部署：GPU 资源别被调度系统浪费掉

news 2026/7/2 1:30:47

云原生工程化部署：GPU 资源别被调度系统浪费掉

一、AI 工作负载上 K8s，真正贵的是 GPU 空转

云原生 AI 应用部署和普通 Web 服务不同，最大的变量是 GPU。GPU 昂贵、稀缺、对驱动和运行时敏感，如果调度策略粗糙，很容易出现资源空转、任务排队、显存碎片和节点利用率不均。把 AI 服务放进 Kubernetes，不只是写一个 Deployment，还要重新设计资源申请、弹性策略和观测指标。

首先要区分训练、批量推理和在线推理。训练任务通常是长时间占用 GPU，对吞吐和数据读取要求高；批量推理可以排队，适合按任务调度；在线推理要求低延迟，需要稳定副本和快速扩缩容。不同负载混在同一套调度规则里，会互相影响。

二、负载分层：训练、批推理和在线推理不能共用一套节奏

flowchart TD A[AI 工作负载] --> B{负载类型} B -- 训练 --> C[批任务队列与独占 GPU] B -- 批量推理 --> D[任务调度与吞吐优化] B -- 在线推理 --> E[低延迟服务与弹性扩缩] C --> F[GPU 利用率监控] D --> F E --> F

Kubernetes 中申请 GPU 通常通过设备插件暴露资源，例如nvidia.com/gpu。但只申请 GPU 数量不够，还要考虑显存、模型大小、batch size、冷启动时间和节点亲和性。某些模型只占用半张卡的算力，却因为资源粒度限制独占整卡，成本会很难看。可以根据环境评估 MIG、时间分片或模型合并部署，但这些方案都会增加运维复杂度。

三、资源配置实践：CPU、内存和 GPU 要一起申请

一个在线推理服务的资源配置应明确 CPU、内存和 GPU，避免调度器只看到 GPU 需求，看不到周边资源压力。

resources: requests: cpu: "2" memory: "8Gi" nvidia.com/gpu: "1" limits: cpu: "4" memory: "12Gi" nvidia.com/gpu: "1"

四、观测与降级：高峰期要可控变慢，而不是直接炸掉

观测指标必须覆盖 GPU。只看 Pod CPU 和内存，会错过显存占用、GPU 利用率、推理队列长度和模型加载耗时。在线推理服务还要监控 P95/P99 延迟、超时率、冷启动次数和每次推理成本。没有这些指标，就无法判断是模型太慢、batch 策略不合理，还是 GPU 被分配得太碎。

部署策略上，建议先把模型服务、业务网关和异步队列分开。业务网关负责鉴权和限流，模型服务专注推理，队列负责削峰。高峰时如果直接让所有请求打到模型服务，GPU 会被瞬间压满，用户得到的不是慢响应，就是超时。用队列和降级策略可以把系统从“炸掉”变成“可控变慢”。

还要准备容量回放。上线前用历史流量和合成峰值测试不同 batch、并发和模型版本的表现。GPU 成本高，靠线上试错很贵；没有容量模型的扩容，很容易变成“多买几张卡”的粗放方案。

资源隔离也要提前规划。训练任务可以接受排队，在线推理通常不能；实验模型可以使用低优先级节点，核心模型需要稳定节点池。若所有工作负载共享同一组 GPU 节点，批处理任务很可能挤压在线服务。更稳的做法是按负载类型划分节点池，并用 taint、toleration 和 priority class 控制调度顺序。

生产落地补充：从能跑到可维护

从生产落地角度看，这类方案不能只停留在主流程。更关键的是把输入校验、失败分支、资源上限和回滚路径提前写清楚。主流程通常容易在演示环境里跑通，真正暴露问题的是异常输入、依赖抖动、并发放大和权限边界。一篇技术方案如果没有解释这些约束，读者很难判断它能否放进真实系统。

评估时建议先定义三类指标：正确性指标、稳定性指标和成本指标。正确性指标回答结果是否可信，稳定性指标回答失败时是否可控，成本指标回答持续运行是否划算。三类指标要同时进入验收清单，不能只用平均耗时或单次成功率证明方案有效。

异常路径补充：把失败当成接口契约

下面的补充片段强调一个原则：调用方必须得到稳定、可解释的错误，而不是在超时、空输入或依赖失败时收到模糊结果。代码不追求覆盖所有业务细节，而是展示输入校验、超时控制和错误封装这三个生产系统最容易遗漏的环节。

from __future__ import annotations import asyncio from dataclasses import dataclass @dataclass class GuardedResult: ok: bool value: str = "" error: str = "" async def run_with_guard(input_text: str, timeout: float = 3.0) -> GuardedResult: if not input_text.strip(): return GuardedResult(ok=False, error="input cannot be empty") try: async with asyncio.timeout(timeout): # 真实项目中这里放模型调用、数据库查询或外部服务请求。 await asyncio.sleep(0.01) return GuardedResult(ok=True, value=f"accepted: {input_text}") except TimeoutError: return GuardedResult(ok=False, error="operation timeout") except Exception as exc: return GuardedResult(ok=False, error=f"operation failed: {exc}")