生成AIを試すための共用マシンをゆるく管理する

こんにちは id:masawada です。
みなさま年末年始はいかがお過ごしでしたでしょうか。自分は年始にかけて風邪をこじらせたため何もできておらず、2025年が締まっておりません。

さて本日は駅伝企画第一区の走者として、社内で各種実験用に設置しているGPU搭載マシンの運用についてご紹介します。

物理マシンを管理するモチベーション

スマートバンクでは生成AIの利活用を推奨しており、業務の様々な場面で取り入れています*1。この一環で、多様な実験用途としてGPUを搭載した物理マシン(愛称: ビットコ掘り太郎*2 )を1台運用しています。タイトルには生成AIを試すためと書きましたが、実際には用途を絞っておらず、機械学習や大規模データ処理など、GPU・CPUリソースを必要とするあらゆる実験に利用可能です。

この目的を達成するだけならばクラウドのGPUインスタンスを都度起動する方法もあるでしょう。しかし、それには以下のようなデメリットもあります。

インスタンスの起動自体に時間がかかる
時間課金されてしまい、実質的に用途が制限される
- 長時間のジョブを気兼ねなく回せない
- あまり頻繁に使われないような実験用のサービスを立ち上げづらい

これらはエンジニアがリソースを「雑に」扱うことを阻害してしまいます。そこで、自由な実験を促進することを目的に共用の物理マシンを設置して運用しています。

この目的にあわせるのであれば、マシン自体の管理についてもあまり厳密にせず「ゆるく」行うのがよいでしょう。本記事では、ゆるく管理するために採用している方針をいくつかご紹介します。

物理マシンをそのまま提供する

VMやコンテナによる論理的な分離は行わず、物理マシンをそのまま利用者に提供しています。利用者はSSHでログインし、ホスト環境を直接操作できます。

当初はVMやコンテナ単位で貸し出す構成も検討しましたが、その場合、これらを管理するための仕組み自体の構築・運用が必要になります。加えて、ワークロードの特性上GPUパススルーの設定が必須となるため、構成や運用の複雑さがさらに増してしまいます。このような管理コストは利用の妨げになると判断しました。

また、VMを介する場合にはハイパーバイザによるオーバーヘッドが発生し、利用可能なリソースが減少します。実験用途において計算資源をできるだけ有効に活用してもらうためにも、物理マシンを直接利用してもらう構成が最もシンプルであると考えています。

利用者が限定的であり、かつサービスの実運用には関わらない実験的な用途のみを想定しているからこそ採れる選択肢ではあるかと思います。

構成管理をやりすぎない

マシンの構成管理にはmitamaeを使っています。ただし、最初からすべてをIaC化することは求めていません。

github.com

実験マシンの性質上「とりあえず手で入れてみる」「動いたら残す、ダメなら消す」といった試行錯誤が頻繁に発生します。この段階で厳格にIaCを強制すると、レシピを書く手間がボトルネックになり、実験のスピードが落ちてしまいます。

そこで「試行錯誤の段階では手作業OK、ただし運用が固まったらIaC化すること」というルールにしています。最終的にどのようなものが動いているかを把握できる状態を維持することが目的です。mitamaeのレシピとして残しておけば、仮に実験のなかで環境を致命的に破壊してしまっても再現できますし、なぜこの設定が入っているのかの記録にもなります。

業務に迷惑をかけないガードレールを敷く

自由に使ってもらう一方で、業務に支障が出ないようガードレールを設けています。

例えば物理マシンネットワークの上流が業務ネットワークと共用の場合、物理マシンで巨大なデータをダウンロードすると帯域を食い潰してしまうリスクがあります。LLMや機械学習の実験では数十GBのモデルをダウンロードすることも珍しくありません。これが業務時間中に発生すると、他のメンバーの業務に迷惑をかけてしまいます。

そこで、Linuxの tc（traffic control）を使って送受信帯域に上限を設けています。本来であればルータやスイッチ側でQoSを設定するのがベストですが、ネットワーク機器の設定変更には調整コストがかかることも多いため、端末側で手軽に制限をかけられる tc は便利な選択肢です。

ビットコ掘り太郎では、起動時にsystemdで以下のスクリプトを実行することで帯域制限を行っています。

#!/bin/bash

set -euo pipefail

sudo modprobe ifb
sudo ip link add ifb0 type ifb
sudo ip link set ifb0 up

sudo tc qdisc add dev "$NETWORK_DEVICE" ingress
sudo tc filter add dev "$NETWORK_DEVICE" parent ffff: \
    protocol ip u32 match u32 0 0 action mirred egress redirect dev ifb0

sudo tc qdisc add dev ifb0 root tbf rate "${BANDWIDTH_BIT}mbit" burst 32kbit latency 400ms
sudo tc qdisc add dev "$NETWORK_DEVICE" root tbf rate "${BANDWIDTH_BIT}mbit" burst 32kbit latency 400ms