HJ·OSPrédiction d'usage mémoireTRAVAIL.SYS

Fiche projet

Prédiction d'usage mémoire

Machine learning contre la sur-allocation mémoire de pipelines bio-informatiques

Cadre
Sophia Genetics
Période
2025.04 → 2025.09
État
Livré

Contexte

Dans un pipeline bio-informatique, chaque tâche demande une allocation mémoire avant de démarrer. Le système en place — une table par tranches de 100 Mo sur la taille du plus gros fichier d'entrée, qui ne se met à jour qu'à la hausse — est très sûr et très pessimiste : environ 1200 To de RAM sur-alloués en trois mois. Le stage le confronte à des modèles appris. Le code est resté chez Sophia Genetics ; cette fiche s'appuie sur le support du tech talk de fin de stage.

Contraintes

  • Se tromper vers le bas est plus cher que se tromper vers le haut : l'échec d'une tâche coûte l'analyse entière, le gaspillage ne coûte que du cloud.
  • Le système en place fait zéro échec : le battre sur le gaspillage sans créer d'échecs est tout l'arbitrage.
  • L'entrée est un journal d'exécution brut, à reconstruire par tâche, par échantillon et par partition avant d'apprendre quoi que ce soit.

Décisions techniques

  1. Un modèle par type de tâcheLes journaux quotidiens de l'exécuteur deviennent des jeux hebdomadaires par cluster, puis des features — taille du plus gros fichier d'entrée, tailles et nombre d'échantillons, taille du panel de gènes, historique mémoire et CPU. Chaque type de tâche a son modèle, pas un modèle global qui moyenne des comportements différents.
  2. Ensembles d'arbres, choisis pour s'expliquerDecision Trees et Random Forest écartés dès la pré-analyse ; XGBoost, CatBoost et LightGBM comparés à fond. Le gradient boosting est retenu pour son interprétabilité : l'importance de chaque feature se lit en valeurs SHAP, et la taille du plus gros fichier d'entrée domine.
  3. Une perte asymétrique contre la sous-prédictionUne fonction de perte custom pénalise la sous-prédiction plus que la sur-prédiction, avec un facteur de pondération balayé sur échelle logarithmique pour trouver la zone d'équilibre entre échec de tâche et gaspillage de RAM.
  4. Un score en argent plutôt qu'une métriqueLoss = c_fail · F + c_waste · W : le coût d'un échec (humain et infra) contre le prix du gigaoctet-seconde de VM gaspillé. Les modèles se comparent en argent, pas en métriques abstraites.

Résultat

Sur les familles de tâches étudiées, la mémoire réservée totale est divisée par deux à dix selon la famille — la sous-prédiction restant à quelques pour cent sur les plus gros volumes — d'après le support du tech talk. Le stage livre l'étude comparative et la baseline ; le microservice de prédiction est dessiné, pas déployé.

Parc

PythonPandas / NumPyscikit-learnXGBoostLightGBMCatBoostSHAPMatplotlib / Seaborn / PlotlyAzure Blob Storage
TRAVAIL.SYS
© 2026 Hugo Juskowiak — session TRAVAILHJ·OS