GitHub
Medium
开始
运行大型语言模型（LLM）可能需要大量的计算资源。当需要尝试不同的 GPU 时，必须在云中租用算力。
手动管理这些资源耗时、容易出错、难以扩展，且存在诸多缺点。例如，无法监控每位员工花费了多少费用，也无法追踪谁经常忘记关闭虚拟机。作为 Lead DevOps，我遇到了一个为我们的团队提供简化 GPU 实例部署、管理和销毁方式的问题，特别是在 RunPod 上进行推理时使用 vLLM 的不同 GPU。
为了解决这个问题，我开发了一个 GitLab CI/CD 流水线，它能从 GitLab 界面自动完成 RunPod 图形模块的整个生命周期。
该解决方案旨在简化 GPU 资源管理，提高工作效率，并确保部署过程的透明性。在本文中，我将向您介绍如何设置以及它的工作原理。
问题
无论 RunPod 账户配置是否正确，团队成员在控制和计费方面都存在不便。GPU 计算成本高昂，因此控制，尤其是自动化控制，在这方面尤为重要。
还需要说吗？手动启动需要更多时间并需要持续关注？人难免会犯错，尤其是在多次尝试的条件下。
还有一个问题（目前尚未能完全解决）——GPU的自动范围管理。因为并行运行多个vLLM显然比串行运行更优。
解决方案：GitLab CI/CD流水线
经过研究，我得到了一个希望呈现的文件——.gitlab-ci.yml。它使用简单的cURL请求，用于创建和删除Pod，以及配置vLLM。
工作原理
我将代码分成了几个阶段：
- deploy
- listing
- destroy
- stop
- start
未来将增加更多步骤：
- 发送邮件
- 在Discourse中发送通知最后三个阶段要求必须执行 listing。因为在这一阶段会确定 Pod ID，而 Pod ID 无法在 Pod 创建阶段获取，因为部署所需时间不同，API 在部署完成前就已响应。为此，专门创建了独立的 listing 步骤。
每个步骤在 GitLab Pipeline 中都包含详细的日志记录。这有助于早期阶段，并便于新员工接入。
启动新 pipeline 时，可以覆盖变量（否则请通过修改代码来设置变量）。
安装指南（简要）
重要变量应存储在 GitLab 的 CI 项目“Variables”部分中，代码会调用这些变量。例如：
- RUNPOD_API_KEY：您的 RunPod API 密钥
- HG_TOKEN：您的 Hugging Face 令牌
- RUNPOD_SSH_PUBLIC_KEYS：用于访问 Pod 的 SSH 公钥（如适用，多个公钥请用 \n 分隔）
- RUNPOD_SSH_PRIVATE_KEY：您的 SSH 私钥，以便 GitLab Runner 可以连接到 Pod
（请使用敏感数据掩码，以防止它们以明文形式出现在日志中）
为何采用此方法有益这种方法适用于：
- 按不同级别划分AI工程师的角色——一个CI适用于所有人
- 每位员工都有自己的Pipeline空间及历史记录
- 易于按员工划分账户费用
- 易于控制运行和当前环境
- 易于以分支形式存储不同配置
- 方便快速部署任意数量的演示环境
- DevOps通用方法——支持任何工程师
- 开发团队间代码迁移简便
- 最重要的是：100%兼容GitLab工作流，在将AI元素集成到项目架构时无缝衔接