AI Deploy大模型本地部署帮你部署

GPU服务器租用批处理调度实操

用 Kubernetes 的 GPU 资源请求、KEDA 事件触发和 startup probe 组织批处理，并按实例与请求式 worker 的计费边界核对租用成本，覆盖慢启动、存储与回收。

GPU服务器租用批处理的核心做法，是让 Kubernetes 暴露的 GPU 资源进入 Pod 规格，再用 KEDA 的触发检查与冷却窗口把批处理事件转成扩缩容，并用 startup probe覆盖模型加载等慢启动。租用实例后，还要把“任务结束”和“计算资源停止”分开核对，避免把容器退出误当成账单已经结束。

GPU服务器租用的准备顺序

你需要准备 Kubernetes 集群、GPU 节点和厂商 device plugin。插件尚未就绪时，先按设备厂商当前文档完成安装，再配置批处理工作负载。

如果使用 NVIDIA GPU Operator，可以先按 官方安装文档给出的传统方式添加 Helm 仓库：

helm repo add nvidia https://helm.ngc.nvidia.com/nvidia \
  && helm repo update

同一安装文档的参数说明规定，Operator 与 operands 会安装到安装时指定的同一个 namespace。默认情况下，NVIDIA driver 以容器方式部署；如果节点已经预装 driver，应将 driver.enabled 设置为 false。完成仓库接入后，还要继续按当前安装页完成 chart 安装并确认集群能够正常识别 GPU。

把 GPU 资源写成可调度请求

最简写法是在容器 resources 中填写 GPU limit，让 Kubernetes 默认把 limit 当作 request。下面只是资源片段，不是完整的 Pod 清单：

resources:
  limits:
    nvidia.com/gpu: YOUR_VALUE

根据 Kubernetes 的 GPU 资源规则，未单独填写 request 时，系统会使用 limit 作为 request；如果同时填写 requests 和 limits，两者必须相等，也不能只填写 GPU request。将 YOUR_VALUE 替换为集群接受的资源数量后，再提交完整工作负载。

用 KEDA 对接批处理触发

把现有批处理事件源接入 KEDA trigger 后，需要区分事件发现间隔和缩容等待窗口。KEDA ScaledObject 规范说明，pollingInterval 决定检查每个 trigger 的间隔，默认是 30 秒；cooldownPeriod 是最后一次 trigger 处于 active 后、资源缩到零之前的等待时间，默认是 300 秒。

pollingInterval: YOUR_VALUE
cooldownPeriod: YOUR_VALUE

这两个字段不是完整 ScaledObject，也不是某个队列的固定配置。pollingInterval 应根据你能接受的触发发现延迟设置，cooldownPeriod 则要结合批处理间隙和缩容尾部调整；事件源的类型、连接及认证字段，应以对应 trigger 的当前文档为准。

如果你说的“调度”还包括 FIFO 顺序、任务优先级、并发上限、重试或死信处理，这部分取决于队列或调度项目。应检查其文档中的排序键、并发控制、失败重试和积压处理规则，不能仅凭 KEDA 扩缩容配置认定这些能力已经存在。

慢启动任务用 startup probe 验收

模型加载、文件准备等阶段可能让容器迟迟无法服务。Kubernetes 的 startup probe 配置指南建议使用与应用启动过程相同的 command、HTTP 或 TCP 检查，并让下面的时间预算覆盖最差启动时间：

failureThreshold * periodSeconds

startup probe 专门用于启动时间较长的容器，不应靠猜测健康检查 endpoint 或单纯拉长 liveness 检查间隔来掩盖启动问题。时间预算仍不够时，应继续检查应用初始化过程，而不是直接缩短探针窗口。

租用方式与成本怎么核对

选择前先从供应商当前报价或账单填入单价，不用示例费率代替真实费用。根据 Runpod Pods 计费说明，计算和存储按秒计费，数据入站和出站不收费；容器盘与卷盘按秒计费，网络卷按小时计费。部署 on-demand Pod 时，余额至少要覆盖所选配置一小时的费用；Pod 停止后，存储仍会继续计费。

可按下面的方法核算：

POD_TOTAL = BILLABLE_COMPUTE_SECONDS * YOUR_COMPUTE_RATE
          + BILLABLE_DISK_SECONDS * YOUR_DISK_RATE
          + BILLABLE_NETWORK_VOLUME_HOURS * YOUR_NETWORK_VOLUME_RATE

同一计费页的 savings plan 条款写明，方案需要预先承诺 3 个月或 6 个月，不可退款并有固定到期日；Pod 停止后，方案会应用到同一 GPU 类型的下一次部署。购买前应把承诺期、到期日、不可退款条件和停止后的适用范围列入核对清单。

对于请求式 worker，Runpod Serverless 计费说明规定，计费从 worker 启动开始，到 worker 完全停止结束，并向上取整到下一秒。可计费时间包含容器初始化与模型加载、请求执行，以及请求完成后的 idle timeout；idle timeout 默认为 5 秒。

SERVERLESS_TOTAL = BILLABLE_WORKER_SECONDS * YOUR_WORKER_RATE

其中 BILLABLE_WORKER_SECONDS 必须覆盖启动、执行和空闲等待，不能只统计模型接口处理请求的时间。

怎样确认调度成功

按以下顺序检查状态：

  1. 集群节点已经暴露 nvidia.com/gpu，批处理 Pod 获得所需资源，而不是停留在等待可调度资源的状态。
  2. startup probe 在计算出的时间预算内通过，容器进入实际工作阶段。
  3. 最后一个 trigger 不再 active 后，经过所配置的 cooldownPeriod，资源能够缩到零。
  4. 实际账单分别填入 Pod 或 Serverless 公式；停止时间、存储费用和 worker 空闲时间不要混为一项。

常见出错点

  • Pod 一直无法调度：先检查 device plugin、nvidia.com/gpu 资源值，以及 request 与 limit 是否冲突。
  • 容器反复启动：重新计算 failureThreshold * periodSeconds，并核对实际初始化路径。
  • 扩容反应或缩容等待不符合预期：分别检查 pollingInterval 与 cooldownPeriod，不要用同一个值代替两者。
  • NVIDIA 节点已有预装 driver：回到安装参数，确认 driver.enabled=false，再继续检查 Operator 状态。

这些步骤依据正文链接的官方文档整理，不包含运行或性能结果；使用前应按当前版本核对。

资料来源