Ressources

Utilisez ces exigences pour dimensionner le cluster avant d'exécuter helm install.

Minimum (évaluation / petites équipes)

Ces chiffres supposent la pile complète par défaut : interface Plateforme, Agentic, Cortex, Analytics, Postgres intégré, SeaweedFS et StarRocks mono-pod pour les tables gérées. Pour fonctionner sur des nœuds plus petits (4 vCPU / 16 Go), réduisez les composants optionnels. 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 Helm définit ces requests et limits mémoire par pod pour les valeurs par défaut mono-réplica. La request est ce que le scheduler réserve. Votre pool de nœuds doit satisfaire la somme des requests des services activés avant que les pods puissent être planifiés ; c'est donc votre plancher réservé. La limit est le plafond de burst avant qu'un pod soit OOM-killed.

Pour dimensionner les pools de nœuds : additionnez les requests comme plancher réservé, vérifiez la somme des limits pour le pire cas de burst, puis ajoutez environ 30 % de marge pour les pods kube-system, les sidecars Dapr (~250 MiB chacun), le plan de contrôle Dapr et la petite infra intégrée comme OPA / Lakekeeper (~128 MiB chacun).

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é.

Les limits ont été révisées pour la dernière fois le 2026-05-18 (rollout de minification binaire v1.3.5-rc.54, PR #1142, qui a environ doublé le RSS stable des applications SSR ; la limit platform a ensuite été portée à 2 GiB le 2026-05-29). Les requests ont été ajustées le 2026-07-06 (PR #2257) pour suivre le RSS stable mesuré. Les anciennes requests sous-estimaient l'usage réel 2 à 4 fois, donc le scheduler surcompactait les nœuds et les pods étaient évincés pendant les rollouts sous pression mémoire. Si vous franchissez l'une de ces limites lors d'une mise à niveau sur un cluster existant, vérifiez la marge du pool de nœuds avant helm upgrade.

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.