Ressources nécessaires pour faire tourner le solveur

Ce que fait le solveur pendant un calcul

Quand vous lancez le calcul d'un planning mensuel, Planopti construit un modèle pour le solveur CP-SAT de Google OR-Tools : une variable booléenne par combinaison possible « cette personne, ce jour, ce shift » (assign[e, d, s]), les règles dures sous forme de contraintes, les règles souples sous forme de pénalités à minimiser. Pour 75 personnes, 31 jours et 55 types de shift, cela représente jusqu'à 128 000 variables avant que le solveur n'élimine celles que les qualifications rendent impossibles.

Le solveur explore ensuite l'espace des plannings possibles. Il ne le fait pas en essayant tout : il propage les conséquences de chaque décision, coupe les branches qui ne peuvent plus battre la meilleure solution connue, et fait tourner plusieurs stratégies de recherche en parallèle qui s'échangent leurs découvertes. C'est ce travail, et rien d'autre, qui consomme les ressources de la machine. Le reste de l'application (saisie, affichage, exports) coûte à peu près autant qu'un tableur ouvert.

Processeur : le poste principal

CP-SAT est un solveur multi-threads. Son paramètre num_workers fixe le nombre de recherches menées en parallèle, et la documentation d'OR-Tools le définit sans ambiguïté : « the number of parallel workers (i.e. threads) to use during search », à garder en dessous du nombre de processeurs de la machine. Planopti laisse ce paramètre à zéro, ce qui signifie « utilise tous les cœurs disponibles ». Pendant le calcul, chaque cœur est donc occupé à cent pour cent.

Trois conséquences pratiques :

• Les cœurs physiques comptent, pas les cœurs logiques. L'hyperthreading présente deux threads par cœur, mais deux workers CP-SAT sur le même cœur physique se partagent le même cache et les mêmes unités de calcul. Un processeur « 8 cœurs, 16 threads » se comporte comme 8 workers utiles, pas 16.
• Les rendements décroissent. Passer de 1 à 4 workers change beaucoup, de 4 à 8 encore nettement, de 8 à 16 de l'ordre de 10 à 20 % sur la qualité obtenue dans le même temps. Notre article sur la recherche multi-thread détaille ces mesures.
• La fréquence importe moins que le nombre de cœurs. Un processeur de serveur à 2,5 GHz avec 8 cœurs fait mieux qu'un processeur de portable à 4 GHz avec 4 cœurs, parce que la recherche de portfolio tire parti de la diversité des stratégies, pas de la vitesse d'une seule.

Recommandation : 4 cœurs au minimum, 8 cœurs physiques pour une équipe de moins de 300 personnes. Au-delà de 16 cœurs, le gain ne justifie plus le coût pour un calcul qui tourne quelques minutes par mois.

Pourquoi pas de carte graphique

La question revient souvent, parce que « calcul intensif » évoque aujourd'hui les GPU. Un GPU excelle quand des milliers d'opérations identiques s'appliquent à des données régulières : multiplier des matrices, traiter des pixels, entraîner un réseau de neurones. La programmation par contraintes fait l'inverse. Chaque worker suit un arbre de décisions dont chaque branche dépend de la précédente, propage des contraintes sur des structures irrégulières, et prend des décisions différentes de son voisin. Ce travail est séquentiel par nature à l'intérieur d'un worker, et le parallélisme utile se compte en dizaines de workers, pas en milliers.

OR-Tools ne contient d'ailleurs aucun code GPU : le mot n'apparaît nulle part dans ses paramètres. Une carte graphique installée sur le serveur de planification resterait inactive du début à la fin du calcul.

Mémoire : proportionnelle au modèle

La mémoire consommée dépend de la taille du modèle (nombre de variables et de contraintes) et du nombre de workers, car chaque worker conserve ses propres structures de recherche. Pour donner un ordre de grandeur : un modèle de 100 000 variables booléennes avec 8 workers tient sans difficulté dans quelques gigaoctets. OR-Tools se protège lui-même avec le paramètre max_memory_in_mb, à 10 000 Mo par défaut : si un calcul dépasse 10 Go, le solveur s'arrête proprement et rend la meilleure solution trouvée plutôt que de mettre la machine à genoux.

Recommandation : 8 Go de mémoire au minimum, 16 Go pour être à l'aise jusqu'à 300 personnes avec 8 workers. Au-delà, ou avec 16 workers, prévoir 32 Go. Rappelez-vous que le système d'exploitation, la base de données et le navigateur en prennent aussi une part.

Temps de calcul : un réglage

CP-SAT est un solveur « anytime » : à tout moment il détient la meilleure solution trouvée jusque-là, et la limite de temps est un paramètre que vous fixez. Arrêter plus tôt donne un planning un peu moins bon, jamais un planning invalide. En pratique, quelques minutes suffisent pour une équipe de 50 à 150 personnes, dix à vingt minutes pour 300. Planopti affiche l'évolution du score pendant le calcul, ce qui permet de voir quand il ne bouge presque plus.

Ce point change la façon de dimensionner : le serveur travaille à plein régime quelques minutes par mois, ou quelques fois par mois quand on relance après une modification, puis ne fait presque rien. Il n'a pas besoin d'être dédié. Un serveur qui héberge déjà d'autres services convient, à condition que ses cœurs soient libres au moment du calcul.

Disque, réseau, système

• Disque : la base de données SQLite, l'historique des plannings et les exports occupent quelques gigaoctets au plus. Un disque standard suffit ; le calcul se fait entièrement en mémoire.
• Réseau : pendant le calcul, rien ne sort de la machine. Le moteur est embarqué, aucun service externe n'est appelé. En mode local, le serveur peut être coupé d'internet.
• Système : Windows 10 ou 11, Windows Server, Linux ou macOS, avec Python 3.12, que nous installons. Les planificateurs n'ont besoin que d'un navigateur récent, sur n'importe quel poste.

Trois configurations types

Ces trois profils couvrent les industries réglementées que nous visons : un service hospitalier, une escale aéroportuaire, une équipe de sécurité ou de logistique. Pour des effectifs plus importants ou des règles très nombreuses, nous mesurons le temps de calcul sur vos données avant de recommander une configuration.

Liste de contrôle

• Combien de cœurs physiques, et sont-ils libres au moment du calcul ?
• Au moins 8 Go de mémoire disponibles, 16 Go recommandés.
• Quelques gigaoctets de disque pour la base et les exports.
• Un système supporté (Windows, Linux, macOS) et un compte pour l'installation.
• Une limite de temps de calcul décidée avec les planificateurs : quelques minutes, ajustable ensuite.
• Aucune carte graphique à prévoir.