同じ20台に600件を詰めると、大きい順なら60件、小さい順なら258件が載りました。
GPUでは要求と上限が必ず一致するので、余らせて詰め込むことができません。詰め方だけが効きます。
多めに要求して余らせる書き方ができません。書いた数がそのまま押さえる数になります。
Kubernetes GPUの割り当ては、機器の差し込みを通じて行われます。公式はKubernetesは、まとまりの中の異なる節にまたがるAMDとNVIDIAのGPUを管理するための、安定した対応を、機器の差し込みを使って含んでいると述べています。
書き方には制約があります。公式は上限だけを指定して要求を書かないことはできる。Kubernetesが既定で上限を要求の値として使うためであると説明しています。
両方書く場合の制約も明示されています。上限と要求の両方にGPUを指定することはできるが、その2つの値は等しくなければならないという記述です。
4番目が効きます。載らなかった分は、他で埋められません。
使う量を多めに申告する余地がない代わり、詰め方の良し悪しがそのまま結果に出ます。次の節で数えます。
節の側に、機器を扱うための差し込みを入れておく必要があります。入っていなければ、そもそも要求できません。
入ったあとは、節が持つGPUの数が公開されます。その数を要求で割った値が、1台に載る仕事の上限になります。
Kubernetes includes stable support for managing AMD and NVIDIA GPUs (graphical processing units) across different nodes in your cluster, using device plugins.原文Kubernetes 公式ドキュメント「Schedule GPUs」 この内容の有効期限2027-02-18
同じ台数・同じ仕事でも、置く順番で載る数が変わります。空いた分は使えません。
Kubernetes GPUでは、書いた上限がそのまま押さえる数になります。公式も上限だけを指定して要求を書かないことはできる。既定で上限が要求の値として使われると述べています。
だから詰め方が結果を決めます。順番を変えて数えました。
1台の容量 80・20台。仕事 600件の要求の合計は 8474 全部を隙間なく詰められたとしても 106台ぶんになる 詰め方 載った仕事 載らなかった 使えた容量 空いたまま 来た順に詰める 127件 473件 99.2% 13 大きい順に詰める 60件 540件 99.9% 1 小さい順に詰める 258件 342件 97.3% 44
小さい順なら258件、大きい順なら60件です。4.3倍の差になります。
「使えた容量」の列は逆を向きます。大きい順が99.9%で最も高い値です。
大きい仕事だけを詰めれば、隙間はほとんど出ません。1つの仕事が容量の多くを占めるためです。
それでも載ったのは60件です。使えた容量が高いことと、多く載せられることは別になります。
どちらを取るかは目的で決まります。件数を通したいのか、大きい仕事を通したいのかです。
使えた容量が最も高い詰め方が、載る件数では最少になる。
You can specify GPU limits without specifying requests, because Kubernetes will use the limit as the request value by default.原文Kubernetes 公式ドキュメント「Schedule GPUs」 この内容の有効期限2027-02-18
分ければ順番は早く回ってきます。ただし1件あたりが遅くなる構成では所要が伸びます。
Kubernetes GPUでは、要求と上限が食い違いません。公式は上限と要求の両方にGPUを指定することはできるが、その2つの値は等しくなければならないと定めています。
押さえる数が決まっているので、1つの仕事にどれだけ割り当てるかが設計の中心になります。
処理能力の合計を同じにしたまま、分け方だけを変えた場合を数えました。
全体の到着は毎分 0.32件。処理能力の合計はどの構成でも同じで、使用率は8割になる 1台にまとめると1件あたりは速く、分けると1件あたりは遅くなる 構成 1件あたり 実測の使用率 平均の待ち 95%点の待ち 合計の所要 1台（速い） 2.5分 78.9% 9.3分 32.8分 11.8分 2台（中くらい） 5.0分 78.9% 8.2分 31.0分 13.2分 4台（遅い） 10.0分 78.9% 6.8分 28.9分 16.8分 8台（もっと遅い） 20.0分 78.9% 5.2分 26.0分 25.2分
待ちは9.3分から5.2分へ減ります。分けるほど順番が早く回ります。
合計の所要は11.8分から25.2分へ増えます。2.1倍です。
1件を早く終わらせたいなら、まとめて割り当てます。学習のような長い仕事が該当します。
順番が回ってこないことを避けたいなら、細かく分けます。試行を多く回す場面が該当します。
並べ方でも同じ量が動きます。その計測はGPUスケジューラの記事にあり、短いものから流すと両方の待ちが減りました。
仕事ごとの要求の大きさは式で作った分布で、実際の構成の値ではありません。分布が変われば、詰め方ごとの差も変わります。台数を変える計測も、処理能力の合計を同じに保つという前提で、1台あたりの能力が下がる構成を想定しています。同じ性能の台を増やす場合には当てはまりません。ここで見せているのは、余らせて詰められない前提のもとでは詰め方がそのまま結果になるという関係です。
You can specify GPU in both limits and requests but these two values must be equal.原文Kubernetes 公式ドキュメント「Schedule GPUs」 この内容の有効期限2027-02-18
同じ課題を持つ会社にとって、動いている設定は「作る時間」を買えるということです。ServiceDockは自作のワークフローやテンプレートを出品できるマーケットプレイスです。手数料や出品の流れは出品者向けページにまとまっています。
出品の仕組みを見る