GPUとワークロードを、可視化・共有・優先度。
GPUとGPUワークロードをまず可視化し、次に共有できるようにする運用レイヤーです。いま運用されているGPUクラスターからそのまま始められます。
NVIDIA標準のデバイスプラグイン。1つのワークロードが1枚のカードを丸ごと使います。
1枚のカードを複数のワークロードで分け合います。ここまではオープンソースです。DynamiaのHAMi Enterpriseは、オーバーコミット、優先度、ターボ、弾性メモリを追加します。
カードは1枚、仕事も1つ。残りにはだれも手が届きません。
KubernetesはGPUを整数単位でしか割り当てません。GPUを1つ要求したジョブはカードを丸ごと受け取り、そのジョブがカードの一部しか使っていなくても、残りにはほかのだれも手が届きません。多くのチームは、これが起きていること自体を見られていません。どのワークロードがどのカードに載っているのか、割り当て済みと表示されたカードが実際に稼働しているのか、どのカードが故障していてどのカードが空いているのか。そのため、カードを買い増すことになります。
割り当て29,000 MiB。カードに収まらない5,972 MiBはサーバーのメインメモリが保持します。
2本のバーは同じ物理カードであり、同じ幅で描いています。KServe環境でNVIDIA A10G 1枚を用いて測定しました。この数値はカードの種類とワークロードによって変わります。ブロックの大きさは模式的なもので、実際の要求量はモデルごとに異なります。
MIG、タイムスライシング、MPSはカードのメモリの範囲内でしか分割できません
NVIDIAは1枚のカードに複数のワークロードを載せる方法をすでに3つ提供しています。いずれも、カードが物理的に持つメモリの範囲内でしか分割できません。
MIGはカードを固定のハードウェア区画に分割します。タイムスライシングは各ワークロードに順番でカード全体を渡します。MPSは複数のプロセスが同時にカードへ処理を送れるようにします。
表を横にスクロールするとすべての列を確認できます。
| できること | 純粋なKubernetes | MIG | タイムスライシング | MPS | HAMi Enterprise+ Wave GPU |
|---|---|---|---|---|---|
| 1枚のカードを複数のワークロードで共有 | – | ✓最大7個 · プロファイル固定 | ✓制限なし | ✓最大48個 | ✓MiB単位オープンソース |
| あるワークロードのメモリを他から保護 | –該当なし | ✓ | –なし | ✓CUDA 11.4+ · 上限の設定が必要 | ✓ハード分離オープンソース |
| 1つのクラッシュで他を巻き込まない | ✓ | ✓ | ✓ | ●制約あり | ✓オープンソース |
| 対応するカード | ✓すべて | ●Ampere以降のデータセンター向けカードのみ | ✓Pascal以降 | ✓ほとんど | ✓NVIDIA、Ascend、Cambriconなど6系統オープンソース |
| カードにないメモリまでワークロードに割り当て | – | – | – | – | ✓アイドル状態のモデルをホストメモリへ |
| 重要なワークロードを優先 | – | – | – | – | ✓後回しのジョブは強制終了せず一時停止 |
| 実行中にメモリ上限を変更 | –再起動が必要 | –再起動が必要 | – | – | ✓再起動なし |
最終列で「オープンソース」と示した行は、HAMiオープンソースプロジェクトに含まれます。この表示がない3行にはHAMi Enterpriseが必要です。
NVIDIAの公式資料に基づきます。Improving GPU Utilization in Kubernetes、MIG User Guide、MPSのドキュメント。MIGはAmpere以降のデータセンター向けカードが必要なため、L40S、L4、A10Gでは利用できません。3つとも、カードの物理容量の範囲内でしか分割できず、優先度の概念がなく、実行中に上限を変更できません。
2つのステップです。最初のステップは何もインストールしません。
いま運用されているGPUクラスター上の4つの画面です。NVIDIA標準のデバイスプラグイン、カード単位の割り当て、新たなインストールはありません。すべてのカード、すべてのワークロード、29項目の点検、そして実測した需要で補正した予約値。
1枚のカードを複数のワークロードで共有し、物理的に収まる限界を超えます。メモリオーバーコミット、タスク優先度、ターボモード、弾性メモリ。このページの実測結果はここから得られたものです。
順序が重要です。まず自社の数値を確認し、そのうえでカードを共有する価値があるかを判断します。
いま運用しているクラスター上の4つの画面
Wave GPUは、クラスターがすでに出している情報を読み取り、4つの画面にまとめます。いずれもカード共有のインストールを必要としません。
クラスター内の全カードを1画面で
カード1枚にタイル1つ、クラスターの地図です。純粋なGPUクラスターでは各カードの状態とその上のワークロードを、カードを共有するクラスターではワークロードに割り当てたメモリまで表示します。
カードが丸ごとでも分割されていても、稼働中・アイドル・故障・空きをカードごとに表示します。緑は稼働中、グレーはアイドル、赤は速度低下です。
地図を離れることなく詳細が開きます。物理容量、割り当てたメモリ、実際に載っている量、ホストメモリへ退避した量、そしてカードの点検結果を1つのパネルで確認できます。
カードを共有している場合、ワークロードに割り当てたメモリ、物理上限、そしてその上限を超えて割り当てた量をそのまま描きます。使用量だけを見せるダッシュボードにはない数値です。
「GPUはいまどういう状態か」に、カード → 分割 → 割り当て → ワークロードの連なりで答えます。
各GPUワークロードが実際に何をしているか
クラスター内のすべてのGPUワークロードを1つの表で。何を使い、どう動き、どう配置されたか。
メモリと演算の使用量と予約量、直近24時間のパターン、そして現在の状態。ワークロードの速度が落ちているときは、その原因となっているワークロードまで表が示します。
Deployment、Job、InferenceServiceといったオブジェクトの種類。vLLMなどの実行ランタイム。そしてPodがまとまって同時に起動する必要があるかどうか。
配置したスケジューラー（HAMi、Volcano、KAI）と経由したキュー（Kueue）。複数のスケジューラーが同時に動くクラスターでも、配置の経路が見えたままになります。
「GPUワークロードは順調か」に、1つの表で答えます。
29項目の点検: ハードウェア12項目、共有レイヤー17項目
GPUの障害は2つの場所から来ます。ハードウェアの故障と共有レイヤーの故障は原因も対処も異なるため、分けて点検します。
XIDエラー、ECCメモリエラー、温度、PCIe、スロットリングをDCGMの信号から読み取ります。カードを共有していてもいなくても、あらゆるGPUクラスターで動作します。
この17項目はカード共有を使っている場合にのみ該当します。分離、アドミッションwebhook、デバイスプラグイン、設定ドリフト、ライセンスを対象とします。検出ごとに、その原因と影響を受けるPodを、元の記録から引用して提示します。
ラベルの再適用のような安全な修復は自動で適用します。Podの再起動は準備だけを行い、承認を待ちます。
静かに無効化された分離を、人が気づく前に見つけます。
推測で決めたGPU予約を、実測で補正します
GPUの予約はたいてい推測から始まります。GPU Sizingは、ワークロードが実際にどれだけ使っているかを測り、それに見合う予約値を提案します。
ワークロードがGPUを実際にどれだけ使っているかを測り、予約値と比較します。差が大きい場合は、より小さい値を提案します。
メモリは、そのワークロードが到達した最大値を下回っては削りません。メモリ上限を超えるとプロセスが終了するためです。すでに適正なワークロードには提案を出しません。
自動で変わるものはありません。画面で承認するか、プルリクエストとして書き出します。適用後にワークロードが上限を超えた場合は、以前の値に戻します。
予約が実測に合えば、同じカードにより多くのワークロードが安全に収まります。
いまのクラスターでそのまま動きます
上の4つの画面は、すでに運用されているGPUクラスター以外に何もインストールしません。NVIDIA標準のデバイスプラグイン、1ワークロードに1枚のカード、共有レイヤーなし。書き直すものはありません。
Wave GPUは上に載せるレイヤーです。お使いのスケジューラーは置き換えません。
Kubeflow、Kueue、KServeを使うクラスターにそのまま入ります。
PyTorch、TensorFlow、vLLMのワークロードは、いまのまま動きます。
上の4つの画面は、すでに運用されているGPUクラスター以外に何もインストールしません。ここから下は2つ目のステップ、カードを共有する話です。
DynamiaのHAMi Enterpriseで、1枚のカードを複数のワークロードが共有します
HAMiはDynamiaが開発したKubernetes向けの共有レイヤーです。基本の共有機能はHAMiオープンソースプロジェクトに含まれます。さらに4つの機能がHAMi Enterpriseで利用可能になります。オーバーコミット、優先度、ターボ、弾性メモリです。Wave GPUはこの5つすべてを運用します。どこまで共有して安全かを測り、設定を提案し、適用後に何が起きるかを見守ります。
1枚のカードを複数のワークロードが安全に共有します
「GPU 0.5個」とは要求しません。マニフェストにMiBの数値を書けば、コンテナにはちょうどその分だけが見えます。
PyTorchもTensorFlowもコード変更なしで動きます。処理はインフラのレイヤーで行われます。
NVIDIA、Huawei Ascend、Cambricon、Hygon、Iluvatar、Moore Threadsを同じ方式で扱います。
標準のKubernetesに載せるミドルウェアです。スケジューラーはそのままの位置に残ります。
resources:
limits:
nvidia.com/gpu: 1
nvidia.com/gpumem: 10000 # MiB · ハード上限
nvidia.com/gpucores: 30 # % · 競合時の取り分アイドル状態のモデルをホストメモリへ退避し、稼働中のモデルがカードを使えるようにします
オーバーコミットとは、カードが物理的に持つ量を超えるメモリをワークロードに割り当てることです。
一定時間リクエストのない推論モデルは、GPUメモリからサーバーのメインメモリへ退避します。人が片づける必要はありません。
新しいリクエストが届くと、モデルはGPUメモリへ戻ります。呼び出す側がこの動きに気づくことはありません。
メモリ上限を物理容量より大きく設定できるため、オーバーコミットなしでカードを共有する場合と比べて、同じカードに2倍から3倍の推論サービスが収まります。カードをまったく共有しない状態と比べた場合は、最後のセクションの結果のほうが大きくなります。
高価なGPUメモリが固定的な保管場所ではなくなります。いま処理しているもののための高速な置き場になります。
4つのワークロードはいずれも自分が生きていると認識しています。自分が2つのどちらに置かれているかは、どれも知りません。
すべてのモデルが同時に稼働している場合、これは成り立ちません。モデルがPCIeバスを行き来し、全体が遅くなります。価値が出るのは、ときどきしか使わないモデルの集まりです。安全な倍率はWave GPUがノードごとに算出して推奨します。
本番を優先しつつ、後ろに回ったジョブを強制終了しません
リアルタイム推論のように遅れが許されないワークロードが、要求した瞬間に演算を確保します。
優先度の低いジョブはCUDAカーネル境界で一時停止します。GPU処理の1単位と次の単位のあいだにある安全な地点です。強制終了ではありません。
一時停止したジョブは状態をGPUメモリに保持したまま、カードが空き次第そこから続きを実行します。
本番サービスが空いている区間をバッチ処理が埋めます。本番の応答時間は変わりません。
優先度の低いジョブを強制終了しません。安全な地点で止まり、カードが空けば続きを実行します。進行中の作業はそのあいだもGPUメモリに残ったままです。
有効化はアノテーション1行、nvidia.com/priorityです。ワークロードのコードは変わりません。どのワークロードを高い側にするかは、Wave GPUが過去の競合の記録をもとに提案します。
メモリ分離を維持したまま、共有していないカードに近い速度で
カードを共有するには、エンジンがすべてのGPU呼び出しを一度ずつ検査する必要があります。ワークロードが小さな処理を多く送るほど、この分が積み上がります。
メモリ分離はそのまま維持されます。省くのは演算側の検査だけです。分離を手放すわけではありません。
密度より速度が優先されるLLMサービングとリアルタイム推論で使います。
環境変数で有効にします。コードの変更はありません。
共有レイヤーのない同じカードと比べた速度の損失です。低いほど良好です。NVIDIA A10G 1枚で、小さな処理を次々と送るワークロードを用いて測定しました。
小さな処理を次々と送るワークロードで測定しました。大きな行列演算で構成されるワークロードは、全体の時間に占める検査の割合が小さいため、差もそのぶん小さくなります。
トラフィックが急増したとき、コンテナを再起動せず上限を引き上げます
コンテナを再起動せず、処理中のリクエストも切らずに、GPUメモリの上限を変更します。
トラフィックが急増してメモリが一時的に跳ね上がったとき、ワークロードはノードに残っているメモリを一時的に借ります。
負荷が収まると上限は下がり、そのメモリは同じノードのほかのワークロードに戻ります。
再起動にかかる時間がそのままサービスの応答できない時間になる、長時間稼働のLLMサービングで使います。
急増が過ぎると上限は下がり、そのメモリは同じノードのほかのワークロードに戻ります。
固定上限だけの構成では、急増の区間でプロセスが終了し、起動し直すあいだそのサービスは応答できません。
カード1枚に何個のワークロードが収まるか
同じカードに、より多くのワークロードを載せます。カードの買い増しはありません。3つの列は同じ試験を3通りの構成で実施したものなので、そのまま突き合わせて読めます。
23,028 MiBのNVIDIA A10G 1枚で、同じクラスターの同じワークロードを用いて2026年6月と7月に測定しました。結果はカードの種類とワークロードによって変わるため、3週間のパイロットでお客様のクラスターを対象に改めて測定します。