Ressources

Utilisez ces exigences pour dimensionner le cluster avant d'exécuter helm install. Elles découlent de ce que les valeurs par défaut du chart réservent réellement, service par service ci-dessous. Un test du chart rend les valeurs par défaut et échoue dès que ces tableaux ne leur correspondent plus : une version qui fait grossir un service met donc aussi cette page à jour.

Minimum (évaluation / petites équipes)

D'où viennent ces chiffres : les services de la pile par défaut demandent ensemble environ 24 Gio de mémoire, et chacun des 14 sidecars Dapr ajoute 128 Mio et 50m de CPU — soit environ 26 Gio et 4,4 vCPU que le scheduler doit placer avant que quoi que ce soit ne démarre. Une première installation demande un peu plus pendant quelques minutes. Les 6 Jobs d'amorçage des schémas demandent ensemble 0,5 vCPU et 1,25 Gio, et ils tournent pendant que les workloads démarrent : le pic est donc d'environ 4,8 vCPU et 27,5 Gio. Ajoutez environ 30 % pour kube-system, le plan de contrôle Dapr, Traefik, la réservation propre du kubelet et les pics de rollout : 8 vCPU et 40 Go de mémoire de nœud sont le plancher qui planifie proprement. Les volumes persistants réclament 125 Gio par défaut (tableau ci-dessous).

Remarque : dimensionnez pour le pic de la première installation, pas pour le régime établi. Si les nœuds ne peuvent pas accueillir à la fois les workloads et les Jobs d'amorçage, le scheduler place les pods qu'il atteint en premier. Si c'est db qui reste en attente, les Jobs qui en ont besoin atteignent leur délai de 10 minutes et l'installation ne converge pas. La page Dépannage décrit la reprise.

Ces chiffres supposent la pile complète par défaut. Pour tourner plus petit, désactivez les composants dont vous n'avez pas besoin — voir Helm → Réduction pour les installations à faibles ressources.

Recommandé (production)

Remarque : les ressources GPU sont sous licence contractuelle (votre JWT de licence reflète vos droits), mais Scrydon n'applique pas les limites GPU au runtime. Les nœuds GPU ne sont nécessaires que si vous prévoyez d'exécuter des modèles d'inférence locaux dans votre cluster.

Mémoire par service

Le chart définit une request et une limit mémoire sur chaque workload Scrydon. La request est ce que le scheduler réserve : la somme des requests (multipliées par les réplicas) est donc votre plancher, et les pods ne sont pas planifiés tant que le pool de nœuds ne peut pas la contenir. La limit est le plafond de burst avant qu'un pod soit OOM-killed.

Chaque pod d'application Scrydon porte aussi un sidecar Dapr qui demande 128 MiB et 50m de CPU. Le plan de contrôle Dapr et Traefik ne définissent aucune request ; la marge de 30 % ci-dessus les couvre.

api-platform inclut le modèle local ONNX d'embeddings. Le modèle et le tokenizer occupent environ 23 MiB sur disque (environ 48 MiB avec les fichiers du runtime ONNX WASM), mais l'inférence demande davantage de mémoire résidente : un essai isolé du binaire Linux arm64 compilé atteignait 866 MiB après un lot de 100 textes. La request de 2 GiB et la limite de 4 GiB existantes laissent de la place pour le modèle et l'API ; mesurez le pic RSS avec votre trafic.

Le calcul isolé des notebooks s'ajoute à ces ressources et est planifié dans runtimePlane.workloadNamespace. Chaque runtime interactif actif réserve 4 GiB pour Marimo, 1 GiB pour le contrôle de source, 512 MiB pour son broker et 128 MiB pour l'enforcer de sortie (5,625 GiB au total). Un job de notebook réserve 4 GiB pour son runner, plus 128 MiB pour le broker et 128 MiB pour l'enforcer (4,25 GiB au total). Dimensionnez le pool de nœuds Kata/KVM pour le nombre prévu de sessions et de jobs simultanés ; l'ouverture des documents ne consomme pas cette capacité. Un pool d'exécution préchauffé (runtimePlane.execPool, désactivé par défaut) ajoute une réservation permanente : 1,1 CPU et 2,125 GiB par pod d'Agent du pool et 1,35 CPU et 1,375 GiB par pod de Function du pool, plus le surcoût du RuntimeClass Kata, qu'ils servent ou non.

Volumes persistants

Chaque volume est en ReadWriteOnce et utilise global.storageClass, ou la StorageClass par défaut du cluster lorsque cette valeur est vide.

Soit 125 GiB au total. Le volume Postgres est dimensionné pour l'évaluation ; augmentez infra.db.storage.size avant d'y placer des données de production.

AI Gateway

L’AI Gateway s'exécute à l'intérieur du pod api-platform : son coût pèse donc sur le CPU de ce Deployment et non sur un service dédié. Le chart livre auth.resources avec une request de 500m et une limit de 2000m. Cette valeur par défaut couvre le trafic de plan de contrôle qu'api-platform sert déjà ; le trafic du router s'y ajoute, et c'est la seule charge de cette page qui évolue avec la façon dont vos équipes travaillent plutôt qu'avec le nombre de services activés.

Coût d'un tour

Le coût CPU d'un tour se compose d'une petite part fixe et d'une part proportionnelle au nombre d'événements diffusés, et non au nombre d'octets. Votre posture DLP modifie le terme événementiel : il y a donc trois courbes plutôt qu'une seule.

C'est le terme événementiel qui compte. Un agent de code diffuse environ un événement par token généré : un tour qui écrit 600 tokens coûte donc à peu près cinq fois un tour qui en écrit 100, même si les deux réponses restent courtes. Notez que le DLP est presque entièrement un coût par événement, et non un coût fixe : il inspecte le flux au fil de son passage, donc une réponse plus longue paie davantage.

La taille du prompt est en comparaison quasi gratuite : un prompt de 150 Ko coûte à peu près autant qu'un prompt de 16 Ko, car le router analyse une requête une seule fois et ne la relit pas.

enforce ajoute par ailleurs environ 11 ms au temps de premier token, de façon constante : le flux est libéré par fenêtres gouvernées de 512 caractères, avec une retenue de 256 caractères pour qu'une détection à cheval sur une frontière soit tout de même prise. Ce coût est plat : il n'augmente pas avec la longueur de la réponse. audit n'ajoute aucun TTFT mesurable, car il inspecte sans rien retenir.

Dimensionner pour une population de développeurs

Dimensionnez à partir des tours par seconde, et non du nombre de développeurs disposant d'un compte. Un développeur ayant un agent ouvert ne diffuse pas en continu : il lit, édite et réfléchit entre deux tours. La fraction de temps pendant laquelle son outil diffuse réellement est le cycle d'activité, et c'est ce chiffre qui détermine votre CPU.

Pour 1 000 développeurs émettant des tours typiques de 600 tokens d'environ 15 secondes chacun :

Les vCPU provisionnés ci-dessous visent un taux d'utilisation de 65 %, pour les trois modes DLP :

Activer le DLP coûte environ 25 % de CPU en plus par tour en audit et 50 % en enforce, sur un tour d'agent typique. C'est un coût réel, mais rarement décisif : c'est le nombre de réplicas ci-dessous qui contraint d'abord.

Valider vos propres chiffres

Les valeurs ci-dessus sont un point de départ, pas un substitut à la mesure de votre trafic réel. La longueur des tours, la posture DLP et le degré d'automatisation par agents déplacent le résultat davantage que l'erreur de modélisation. Une fois le trafic réel, les métriques décrites dans la section capacité de l’AI Gateway indiquent où vous vous situez :

• scrydon_llm_router_streams_in_flight comparé à votre maxInFlight — à quelle distance un pod se trouve du délestage.
• scrydon_llm_router_admission_rejections_total — durablement non nul en régime établi signifie qu'il faut ajouter un réplica, pas des retries côté client.
• scrydon_llm_router_overhead_ms face à scrydon_llm_router_provider_ttfb_ms — sépare le temps passé dans votre plateforme du temps passé chez le fournisseur, ce qui distingue un problème de capacité d'un modèle lent.