news 2026/7/2 1:18:31

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

作者头像

张小明

前端开发工程师

1.2k 24
文章封面图
云原生工程化部署:GPU 资源别被调度系统浪费掉

云原生工程化部署: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}")

五、总结

云原生 AI 应用部署要围绕 GPU 资源、负载类型、弹性策略和可观测性设计。Kubernetes 能提供调度基础,但成本和稳定性取决于团队是否真正理解 AI 工作负载的资源特征。

版权声明: 本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若内容造成侵权/违法违规/事实不符,请联系邮箱:809451989@qq.com进行投诉反馈,一经查实,立即删除!
网站建设 2026/7/2 1:17:01

AI 辅助:JVM GC 调优实战:别只盯着 Full GC 次数

AI 辅助:JVM GC 调优实战:别只盯着 Full GC 次数 一、GC 调优的第一步:先建立基线 JVM GC 调优最容易陷入单指标思维。看到 Full GC 就紧张,看到 Young GC 频繁就调大堆,看到暂停时间长就换收集器。实际上,…

作者头像 李华
网站建设 2026/7/2 1:15:01

OpenEvals框架解析:LLM应用评估实战指南

1. OpenEvals 评估框架深度解析 作为一名长期从事AI应用开发的工程师,我深知评估环节的重要性。OpenEvals是LangChain团队推出的开源评估框架,专门用于系统性评估大语言模型(LLM)应用的质量表现。这个工具彻底改变了我们过去凭感觉判断AI效果的工作方式。…

作者头像 李华
网站建设 2026/7/2 1:13:33

AI 辅助:万亿级数据迁移复盘:校验比搬数据更难

AI 辅助:万亿级数据迁移复盘:校验比搬数据更难 一、数据迁移的难点在差异闭环,不在复制速度 万亿级数据迁移中,搬数据本身通常不是最难的,真正困难的是校验、追增量、处理失败和控制业务影响。数据量足够大时&#xff…

作者头像 李华
网站建设 2026/7/2 1:12:10

易经与算法实验:用机器学习分析卦象变化要先去神秘化

易经与算法实验:用机器学习分析卦象变化要先去神秘化 一、跨界实验要先把问题变成数据问题 用机器学习分析易经卦象变化,听起来很容易滑向玄学化表达。但如果把它当作传统文化文本和符号系统的计算分析实验,就可以保持严谨。关键是先去神秘化…

作者头像 李华
网站建设 2026/7/2 1:11:57

MH迈汇:从公开信息出发,拆解风控思路与流程清晰度

外汇市场信息更新频繁,平台口碑的形成更依赖长期一致性:入口是否好找、说明是否前后一致、提示是否稳定出现。围绕MH迈汇,下面从稳定体验与信息呈现等角度做一次正面观察。外汇相关平台的价值,体现在长期一致性与信息呈现的细致程…

作者头像 李华
网站建设 2026/7/2 1:09:38

useNavigate、useParams、useLocation 用法

useNavigate、useParams、useLocation 是 React Router v6 中最常用的三个 Hooks,它们只能在函数组件中使用。一、useNavigate(页面跳转)作用:用来进行页面跳转,相当于以前 React Router v5 的 history.push() 和 hist…

作者头像 李华