Ressources
Exigences CPU, mémoire, disque et GPU pour les déploiements Scrydon
Utilisez ces exigences pour dimensionner le cluster avant d'exécuter helm install.
Minimum (évaluation / petites équipes)
| Ressource | Exigence |
|---|---|
| CPU | 6 vCPU |
| RAM | 32 Go |
| Disque | 80 Go (base de données + StarRocks + images) |
| GPU | Non requis |
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)
| Ressource | Exigence |
|---|---|
| CPU | 16 vCPU |
| RAM | 64 Go |
| Disque | 200 Go SSD |
| GPU | Facultatif. Requis uniquement pour l'inférence de modèles IA locaux, par exemple Ollama dans le cluster. |
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).
| Service | Request mémoire | Limit mémoire | Notes |
|---|---|---|---|
platform (UI) | 1 GiB | 2 GiB | Shell SSR + routes de plan de contrôle |
agentic (workflow app) | 2 GiB | 4 GiB | Application la plus lourde : moteur de workflow + hôte d'acteurs Dapr |
agentic-realtime | 256 MiB | 512 MiB | Fan-out WebSocket |
analytics (UI) | 1.5 GiB | 2 GiB | SSR + rendu de graphiques ; RSS stable le plus élevé |
cortex (chat UI) | 1 GiB | 2 GiB | SSR + proxy de streaming LLM |
api-platform (auth/API) | 1 GiB | 2 GiB | Catalogue + sources de workspace |
api-ontology | 256 MiB | 512 MiB | Optionnel |
api-table | 256 MiB | 512 MiB | Activé par défaut ; soutient Managed Tables. Désactiver avec apiTable.enabled: false. |
marimo-sidecar | 512 MiB | 2 GiB | Kernel Python pour les notebooks analytics |
infra.db (Postgres) | 256 MiB | 1 GiB | Intégré. Désactiver si vous utilisez Postgres géré. |
infra.seaweedfs | 256 MiB | 1 GiB | Intégré. Désactiver si vous utilisez S3 géré. |
infra.starrocks | 2 GiB | 8 GiB | Activé par défaut (allin1 mono-pod). Désactiver avec infra.starrocks.enabled: false ou remplacer par l'opérateur StarRocks pour du multi-AZ. |
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.