サンドボックスの CPU とメモリのサイジング

サンドボックスは、実行中は常に、リクエストした CPU とメモリを予約し続けます。それぞれの値は、サンドボックスで実行する処理に合わせて選択してください。両者の比率によって、リクエストに対応できるキャパシティを持つノードが変わります。一方、実際の消費量はワークロードによって異なります。このガイドでは、比率の選び方、その比率がワークロードに合っているかを測定する方法、およびランナーを使用する他のユーザーがリクエストできる量に上限を設定する方法について説明します。

比率が重要な理由

サーバーレス配置では、CoreWeave は CPU とメモリを個別に計量します。計量の対象は、実際に消費したキャパシティではなく、予約したキャパシティです。1 CPU と 64 GiB のメモリをリクエストするサンドボックスは、実際には 1 GiB を超えて割り当てることがなくても、実行期間全体にわたって 64 GiB すべてが計量されます。比率は配置にも影響します。ノードが持つ各リソースの量は固定されているため、一方のリソースに偏ったリクエストが繰り返されると、もう一方のリソースに空きがあってもノードが埋まってしまうことがあります。簡略化した例として、割り当て可能な CPU が 32 個、割り当て可能なメモリが 128 GiB のノードを考えてみましょう。1 CPU と 64 GiB をそれぞれリクエストする 2 つのサンドボックスは、128 GiB のメモリをすべて予約しますが、CPU は 32 個のうち 2 個しか予約しません。この例ではワークロードのリクエストのみを考慮しています。実際の配置では、ランタイムのオーバーヘッド、他のワークロード、およびノード割り当て予算も考慮されます。

ホストの構成を基準にする

CoreWeave Kubernetes Service (CKS) での配置では、リクエストを、対象となるノードの割り当て可能な CPU とメモリ、およびノードの割り当て予算と比較してください。ノードに搭載されている公称 RAM ではなく、割り当て可能なリソースを基準にしてください。サーバーレスでの配置では、CoreWeave がキャパシティとポリシーを管理します。すべてのリクエストが特定のノード SKU で実行されるとは想定しないでください。 cpu リクエストに 1 を指定すると、1 vCPU が予約されます。リクエストしたメモリ (GiB) をリクエストした CPU 数で割ると、CPU あたりの GiB を算出できます。CPU あたりのメモリが対象ノードの割り当て可能な比率を上回るリクエストでは、メモリがボトルネックになる可能性があります。逆に、CPU あたりのメモリが少ないリクエストでは、CPU がボトルネックになる可能性があります。空き容量や他のワークロードも配置に影響します。代表的なワークロードの測定結果に基づいて CPU とメモリを選択し、各リソースの使用状況に応じて調整してください。以下の割り当ては比率の計算方法を示す例であり、特定のワークロード向けの推奨値ではありません。

リクエスト	計算	比率
2 CPU、4 GiB	4 / 2	CPU あたり 2 GiB
8 CPU、16 GiB	16 / 8	CPU あたり 2 GiB
4 CPU、24 GiB	24 / 4	CPU あたり 6 GiB

リクエストは、その配置に適用されるポリシーも満たす必要があります。ポリシーによっては、ホストの構成で許容される値よりも低い最大値が設定されている場合があります。制限とクォータを参照してください。 GPU サンドボックスでは、CPU とメモリを別途指定する必要があります。GPU リクエストで予約されるのは GPU のみです。GPU サンドボックスを参照してください。

リクエストと制限を設定する

デフォルトのサーバーレス配置では、CPU とメモリのリクエストと制限を同じ値に設定します。リクエストした値がそのまま予約され、その分が課金されます。リクエストと制限が同じ値だとバーストの余地がないため、ワークロードのピーク時に合わせてリクエスト値を決めてください。次のサンドボックスは、実行中は常に 2 CPU と 4 GiB を予約します。

from cwsandbox import Sandbox

sandbox = Sandbox.run(
    resources={"cpu": "2", "memory": "4Gi"},
)

制限値より少ない量をリクエストするには、リクエストと制限に異なる値を指定できるポリシーが設定されたランナーで CKS 配置を使用します。Burstable QoS を参照してください。

サンドボックスの使用量を測定する

リクエストを変更する前に、予約キャパシティと実際の消費量を比較してください。以下のクエリを実行するには、Grafana またはメトリクス API 経由で CoreWeave の組織メトリクスにアクセスできる必要があります。詳しくはメトリクスの前提条件を参照してください。Forge の認証情報を使用している場合は、サンドボックスの使用量を表示するで利用可能な使用量チャートを確認してください。次のクエリは、フリート全体で予約済みメモリのうち実際に消費されたメモリの割合を返します。

sum(cwsandbox_sandbox_memory_working_set_bytes)
/
sum(cwsandbox_sandbox_requested_memory_bytes)

次のクエリでは、CPU についても同じ比較を行います：

sum(rate(cwsandbox_sandbox_cpu_usage_seconds_total[5m]))
/
(sum(cwsandbox_sandbox_requested_cpu_millicores) / 1000)

結果が 1 を大きく下回る場合、フリートは測定使用量を上回るリソースを予約しています。フリート全体の平均値では、使用量の多い個々のサンドボックスが埋もれてしまうことがあるため、いずれかのリソースを削減する前に、ワークロード単位のピークを確認してください。測定使用量は下限値として扱ってください。microVM 分離では、これらの値はゲスト内部で取得されるため、仮想化のオーバーヘッドやサイドカープロセスは含まれません。リクエストは測定値まで一気に下げず、段階的に削減してください。次のクエリは、リクエストされた CPU あたりの予約済みメモリの集計値を GiB/CPU 単位で返します。

sum(cwsandbox_sandbox_requested_memory_bytes) / 1024^3
/
(sum(cwsandbox_sandbox_requested_cpu_millicores) / 1000)

ランナーでリクエストに上限を設定する

ランナーのポリシーは、そのランナー上の各コンテナーがリクエストできる量を制限します。さらに上限値を通じて、サンドボックス全体として最終的に割り当てられるリソース量も制限します。サンドボックスが一方のリソースだけを単独でリクエストできないように、CPU とメモリの制限は併せて設定してください。

{
  "constraints": {
    "resources": {
      "minCpu": "500m",
      "maxCpu": "8",
      "minMemory": "1Gi",
      "maxMemory": "32Gi",
      "cpuCeiling": "8",
      "memoryCeiling": "32Gi",
      "requireLimits": true
    }
  }
}

このポリシーは、CKS 配置の場合は管理者が設定します。サーバーレス配置の場合は、CoreWeave がポリシーを管理します。最大値を超えるリクエストは CWSANDBOX_RESOURCE_CEILING_EXCEEDED で失敗します。詳しくは、サンドボックスポリシーを設定するおよび ResourceConstraints リファレンスを参照してください。これらの上限はリソースごとに個別に適用されます。たとえば、8 CPU と 32 GiB を許可するポリシーでは、1 CPU と 32 GiB の組み合わせも許可されます。ランナー上のサンドボックスが合計で確保できるノードのリソース量を制限するには、ノード割り当て予算を設定するを参照してください。