GitHub
Medium
開始
大規模言語モデル（LLM）の実行には、大きな計算リソースが必要です。異なるGPUを試す必要がある場合、クラウドの計算リソースをレンタルしなければなりません。
これらのリソースを手動で管理するのは時間がかかり、ミスを招き、スケーリングが困難で、多くの欠点があります。たとえば、各従業員がどれだけの費用をかけたかの管理がなく、仮想マシンを頻繁にシャットダウンしない人がいるなどの問題があります。私はLead DevOpsとして、RunPodにおけるGPUインスタンスのデプロイ、管理、削除を簡易化する方法を提供する必要に直面しました。特に、チーム内でvLLMを用いたインフェレンスの実行に焦点を当てていました。
この問題を解決するために、私はGitLab CI/CDパイプラインを設計し、RunPodのグラフィックモジュールのライフサイクルをGitLabのインターフェースから完全に自動化しました。
このソリューションの目的は、GPUリソースの管理を簡素化し、作業の効率を向上させ、デプロイプロセスの透明性を確保することです。この投稿では、設定方法とその動作について詳しく説明します。
問題
RunPodのアカウントが正しく構成されているかどうかに関わらず、チームメンバーの管理と課金の制御には不便さがあります。GPU計算は高コストであり、そのため、特に自動化された制御が重要です。
手動起動の必要性は、時間と継続的な注意を要するという点で、言うまでもありませんか？人間は繰り返しの試行の中で間違いを犯すのが普通です。
もう一つの問題（まだ確実に解決できていない）は、GPUスコープの自動管理です。複数のvLLMを並列で実行する方が、順次実行するよりも明らかに効率的です。
解決策：GitLab CI/CDパイプライン
調査の結果、私が提示したいファイルが完成しました — .gitlab-ci.yml。このファイルは、Podの作成・削除、vLLMの設定に必要な単純なcURLリクエストを使用しています。
仕組み
コードを以下のステージに分割しました：
- deploy
- listing
- destroy
- stop
- start
今後追加されるステップは：
- メール送信
- Discourseへの通知送信最後の3段階では listing が必須です。この段階で Pod ID が判明するため、Pod の作成段階では取得できません。Pod のデプロイには異なる時間がかかり、API はデプロイが完了する前に応答するためです。そのため、別途 listing ステップを用意しています。
各ステップには GitLab Pipeline への詳細なログ記録が含まれており、初期段階でのトラブルシューティングに役立ち、新規社員の導入にも便利です。
新しいパイプラインを実行する際には、変数のオーバーライドが可能です（変数の設定はコードの編集ではなく、GitLab の変数設定画面で行う必要があります）。
インストール手順（簡易版）
重要な変数は GitLab の CI プロジェクト内の「変数」セクションに保管してください。コードはこれらの変数にアクセスします。例えば、以下のような変数です：- RUNPOD_API_KEY: RunPodのAPIキー
- HG_TOKEN: Hugging Faceのトークン
- RUNPOD_SSH_PUBLIC_KEYS: ノードへのアクセスに使用する公開SSHキー（複数ある場合は\nで区切る）
- RUNPOD_SSH_PRIVATE_KEY: GitLab Runnerがノードに接続するために使用する秘密鍵（感覚データのマスクを適用して、ログに明文で表示されないようにしてください）
なぜこのようなアプローチが有効なのかこのアプローチは以下の点に有効です：
- 異なるレベルのAIエンジニアを役割別に分けることができる（1つのCIが全員に適用可能）
- 各従業員に個別のパイプラインスペースと履歴が提供される
- アカウントのコストを従業員ごとに簡単に分割可能
- 実行状況や現在のスタンドの管理が容易
- 異なる設定をブランチとして簡単に保存可能
- 任意の数のデモスタンドを迅速に展開可能
- DevOpsにおける汎用的アプローチであり、どのエンジニアも対応可能
- 開発チーム間でのコード移動が容易
- 最も重要な点は、AI要素をプロジェクトアーキテクチャに統合する際、GitLabワークフローとの100％互換性を提供すること