Dimensionner le CPU et la mémoire d’une sandbox

Une sandbox réserve le CPU et la mémoire qu’elle demande pendant toute la durée de son exécution. Choisissez chaque valeur en fonction du travail que la sandbox doit effectuer. Le ratio entre ces deux valeurs influe sur les Nœuds qui disposent de la capacité nécessaire pour satisfaire la demande de ressources ; la consommation réelle, elle, dépend de la charge de travail. Ce guide explique comment choisir un ratio, vérifier qu’il correspond à votre charge de travail et plafonner ce que les autres utilisateurs d’un exécuteur peuvent demander.

Pourquoi le ratio est important

Pour le placement sans serveur, CoreWeave mesure le CPU et la mémoire séparément, en fonction de la capacité que vous réservez et non de celle que vous consommez. Un sandbox qui demande 1 CPU et 64 Gio de mémoire est facturé pour la totalité des 64 Gio pendant toute sa fenêtre d’exécution, même s’il n’alloue jamais plus de 1 Gio. Le ratio influe également sur le placement. Un nœud dispose d’une quantité fixe de chaque ressource : des demandes de ressources répétées qui privilégient une ressource peuvent donc le saturer tout en laissant l’autre inutilisée. Prenons un exemple simplifié : un nœud doté de 32 CPU allouables et de 128 Gio de mémoire allouable. Deux bacs à sable demandant chacun 1 CPU et 64 Gio réserveraient la totalité des 128 Gio, mais seulement 2 des 32 CPU. Cet exemple ne tient compte que des demandes de ressources des charges de travail ; le placement réel prend également en compte la surcharge du runtime, les autres charges de travail et les éventuels budgets d’allocation de nœud.

Partir du profil de l’hôte

Pour un placement sur CoreWeave Kubernetes Service (CKS), comparez votre demande de ressources au CPU et à la mémoire allouables des Nœuds éligibles, ainsi qu’aux éventuels budgets d’allocation des Nœuds. Tenez compte des ressources allouables plutôt que de la RAM nominale installée sur un Nœud. Pour un placement sans serveur, CoreWeave gère la capacité et la politique : ne partez pas du principe que chaque demande de ressources utilise un SKU de Nœud particulier. Une demande de ressources cpu de 1 réserve un vCPU. Pour obtenir le nombre de Gio par CPU, divisez la mémoire demandée en Gio par le nombre de CPU demandés. Les demandes de ressources dont la mémoire par CPU dépasse le ratio allouable d’un Nœud éligible risquent d’être limitées par la mémoire. À l’inverse, les demandes de ressources dont la mémoire par CPU est inférieure à ce ratio risquent d’être limitées par le CPU. La capacité disponible et les autres charges de travail influent également sur le placement. Choisissez le CPU et la mémoire à partir de mesures effectuées sur une charge de travail représentative, puis ajustez chaque ressource en fonction de son utilisation. Les allocations suivantes illustrent le calcul du ratio ; il ne s’agit pas de recommandations adaptées à une charge de travail précise :

Demande de ressources	Calcul	Ratio
2 CPU, 4 Gio	4 / 2	2 Gio par CPU
8 CPU, 16 Gio	16 / 8	2 Gio par CPU
4 CPU, 24 Gio	24 / 4	6 Gio par CPU

Une demande de ressources doit également respecter la politique qui régit son placement, laquelle peut imposer un maximum inférieur à celui que permet le profil de l’hôte. Voir Limites et quotas. Pour les bacs à sable GPU, le CPU et la mémoire doivent être dimensionnés séparément : une demande de ressources GPU ne réserve que des GPU. Voir Bacs à sable GPU.

Définir les demandes de ressources et les limites

Pour le placement sans serveur, qui est le mode par défaut, définissez des demandes de ressources et des limites identiques pour le CPU et la mémoire. La valeur demandée correspond à la valeur réservée et comptabilisée pour votre facturation. Avec des valeurs identiques, aucune marge de dépassement n’est possible : dimensionnez donc la demande de ressources en fonction du pic de la charge de travail. La sandbox suivante réserve 2 CPU et 4 Gio pendant toute la durée de son exécution :

from cwsandbox import Sandbox

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

Pour demander une valeur inférieure à la limite, utilisez le placement CKS sur un exécuteur dont la politique autorise des valeurs différentes. Voir QoS Burstable.

Mesurer la consommation de vos bacs à sable

Avant de modifier une demande de ressources, comparez la capacité réservée à la consommation réelle. Les requêtes suivantes nécessitent un accès aux métriques de l’organisation CoreWeave via Grafana ou l’API de métriques ; consultez les prérequis des métriques. Si vous utilisez des identifiants d’authentification Forge, consultez Afficher l’utilisation des sandbox pour connaître les graphiques d’utilisation disponibles. La requête suivante renvoie la mémoire consommée sur l’ensemble de la flotte, exprimée en fraction de la mémoire réservée :

sum(cwsandbox_sandbox_memory_working_set_bytes)
/
sum(cwsandbox_sandbox_requested_memory_bytes)

La requête suivante effectue la même comparaison pour le CPU :

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

Un résultat nettement inférieur à 1 signifie que la flotte réserve davantage que l’utilisation mesurée. Une moyenne calculée sur l’ensemble de la flotte peut masquer certains bacs à sable fortement sollicités : examinez donc les pics au niveau de chaque charge de travail avant de réduire l’une ou l’autre ressource. Considérez l’utilisation mesurée comme une borne inférieure : avec l’isolation microVM, ces valeurs sont relevées à l’intérieur de l’invité et n’incluent ni la surcharge liée à la virtualisation ni les processus sidecar. Réduisez les demandes de ressources progressivement plutôt que de les ramener directement à la valeur mesurée. La requête suivante renvoie la mémoire réservée agrégée par CPU demandé, en Gio par CPU :

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

Plafonner les demandes de ressources sur un exécuteur

Une politique de l’exécuteur borne ce que tout conteneur de cet exécuteur peut demander et, au moyen des plafonds, le total de ressources qu’une sandbox entière peut obtenir après résolution. Définissez conjointement les limites de CPU et de mémoire afin qu’une sandbox ne puisse pas demander une ressource indépendamment de l’autre :

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

Vos administrateurs configurent cette politique pour le placement CKS. Pour le placement sans serveur, c’est CoreWeave qui gère la politique. Toute demande de ressources qui dépasse un maximum échoue avec l’erreur CWSANDBOX_RESOURCE_CEILING_EXCEEDED. Voir Configurer une politique de sandbox et la référence ResourceConstraints. Ces limites s’appliquent à chaque ressource de façon indépendante : une politique qui autorise 8 CPU et 32 Gio autorise également 1 CPU avec 32 Gio. Pour limiter la part d’un nœud que les bacs à sable d’un exécuteur peuvent occuper au total, voir Configurer les budgets d’allocation de nœud.

Sandbox

Utiliser les Sandbox

Gérer les bacs à sable

Référence

Dimensionner le CPU et la mémoire d’une sandbox

Pourquoi le ratio est important

Partir du profil de l’hôte

Définir les demandes de ressources et les limites

Mesurer la consommation de vos bacs à sable

Plafonner les demandes de ressources sur un exécuteur

​Pourquoi le ratio est important

​Partir du profil de l’hôte

​Définir les demandes de ressources et les limites

​Mesurer la consommation de vos bacs à sable

​Plafonner les demandes de ressources sur un exécuteur

Pourquoi le ratio est important

Partir du profil de l’hôte

Définir les demandes de ressources et les limites

Mesurer la consommation de vos bacs à sable

Plafonner les demandes de ressources sur un exécuteur