Infrastructure pour former des modèles d'apprentissage automatique

Quand on parle d'infrastructure pour l'apprentissage automatique, on pense tout de suite aux GPU. Les NVIDIA A100, H100, les instances GPU dans le cloud. Ce cadre est parfait pour un certain type de boulot : entraîner de gros réseaux neuronaux, surtout les transformateurs et les gros modèles de vision, où la vitesse de multiplication matricielle détermine le temps qu'il faut pour finir le boulot.

Ça ne colle pas vraiment pour une bonne partie du boulot de ML dans la vraie vie. L'ingénierie des fonctionnalités, le ML classique, le réglage des hyperparamètres, le service d'inférence et le gradient boosting n'ont pas besoin d'accélération GPU. Ils ont besoin de processeurs rapides, d'une grosse RAM et d'un stockage I/O qui ne ralentit pas en plein boulot. C'est exactement ce qu'offre un serveur bare metal dédié.

Choisir entre GPU et CPU pour les tâches de ML

Quand le GPU est le bon choix

L'entraînement des réseaux neuronaux avec un grand nombre de paramètres profite du parallélisme des GPU, car les frameworks modernes d'apprentissage profond décomposent l'entraînement en opérations matricielles que les GPU exécutent des milliers de fois plus vite que les CPU. Un réseau neuronal convolutif s'entraînant sur ImageNet, un BERT affiné sur un gros corpus, un modèle de diffusion pour la génération d'images : ce sont des charges de travail pour GPU. Les exécuter sur un CPU, c'est techniquement possible, mais ça ne sert à rien pour des ensembles de données plus gros que des jouets.

Les instances GPU dans le cloud sont utiles quand les tâches GPU sont rares et que tu n'as pas besoin d'avoir du matériel GPU dédié. Les instances A100 à 3-10 $ de l'heure sont parfaites pour les entraînements occasionnels.

Quand les serveurs dédiés CPU sont les meilleurs

Plusieurs types de tâches ML tournent plus vite sur des processeurs avec plein de cœurs que sur des instances GPU dans le cloud, et ça coûte beaucoup moins cher :

• Boosting par gradient (XGBoost, LightGBM, CatBoost) : ces frameworks sont super optimisés pour le parallélisme CPU. L'entraînement XGBoost sur 16 cœurs avec OpenMP est vraiment rapide. L'accélération GPU pour le boosting par gradient est utile pour les très gros ensembles de données, mais ça ajoute de la complexité et des coûts qui ne sont pas vraiment rentables pour les ensembles de données de moins de 10 Go.
• scikit-learn à grande échelle : les forêts aléatoires , les SVM et les méthodes d'ensemble sont parallélisées sur les cœurs du processeur. Un processeur EPYC à 16 cœurs gère la recherche par quadrillage croisée validée sur des centaines de combinaisons de paramètres en moins de temps qu'il n'en faudrait à une instance cloud monocœur pour en traiter une fraction.
• Pipelines d'ingénierie des caractéristiques : le calcul des caractéristiques basé sur Pandas , Polars et Spark consomme beaucoup de mémoire et est limité par les E/S. Avec 192 Go de RAM, toute ta matrice de caractéristiques reste en mémoire. NVMe permet d'éviter que le chargement des données à partir des fichiers Parquet ne devienne un goulot d'étranglement.
• Réglage des hyperparamètres : lancer 16 essais Optuna en parallèle, chacun comme une tâche d'entraînement à un seul thread, utilise les 16 cœurs en même temps. C'est mieux que de payer pour une instance GPU qui reste presque inactive pendant la phase d'évaluation de chaque essai.
• Service d'inférence ML : la plupart des points de terminaison d'inférence de production pour le ML classique, les modèles tabulaires et les petits réseaux neuronaux tournent sur CPU. Les exigences en matière de latence sont généralement de l'ordre de quelques dizaines de millisecondes, ce que l'inférence CPU gère facilement.

AMD EPYC 4545P pour l'apprentissage automatique

Avantages architecturaux

L'AMD EPYC 4545P est un processeur à 16 cœurs et 32 threads qui utilise l'architecture Zen 4 d'AMD. Pour les tâches de ML, trois trucs architecturaux sont importants :

• Prise en charge AVX-512 : ça permet des opérations en virgule flottante vectorisées pour les bibliothèques numériques comme NumPy et Intel MKL. Les frameworks ML compilés avec la prise en charge AVX-512 tournent 20 à 40 % plus vite sur les processeurs compatibles par rapport aux systèmes limités à AVX-256.
• Cache L3 de grande taille : ça réduit le temps d'accès à la mémoire pour les paramètres de modèle et les données de caractéristiques auxquels on accède souvent pendant les boucles d'entraînement. L'entraînement XGBoost profite particulièrement des structures de données résidant dans le cache.
• Bande passante mémoire DDR5 : la DDR5 offre environ 1,5 fois la bande passante théorique de la DDR4. Pour les opérations qui dépendent de la bande passante mémoire, comme les multiplications de grandes matrices sur un processeur, cette bande passante se traduit directement par un calcul plus rapide.

Ces différences ne sont pas négligeables. Lors de l'entraînement XGBoost avec un ensemble de données de 5 Go, la combinaison de 16 cœurs, AVX-512 et bande passante DDR5 sur un système EPYC donne des résultats qui rivalisent avec l'entraînement accéléré par GPU pour ce type de charge de travail.

Capacité de mémoire pour le chargement des ensembles de données

Le gros problème pratique le plus courant dans le ML basé sur CPU, c'est le chargement des données. Une matrice de caractéristiques avec 50 millions de lignes et 200 caractéristiques au format float32 prend environ 40 Go de RAM. Sur un système avec 32 Go, ce jeu de données doit être chargé par morceaux, ce qui complique chaque étape du pipeline d'entraînement.

Sur un système de 192 Go, cette matrice de caractéristiques de 40 Go se charge une seule fois et reste en mémoire pendant les cycles de validation croisée, les comparaisons d'algorithmes multiples et l'analyse de l'importance des caractéristiques. Pas de fractionnement. Pas de rechargement entre les expériences. Le gain de vitesse dans l'itération des expériences est énorme, surtout pendant les phases exploratoires.

TensorFlow et PyTorch sur CPU

Formation CPU pour les petits réseaux neuronaux

Toutes les formations de réseaux neuronaux n'ont pas besoin d'un GPU. Les réseaux peu profonds, les réseaux neuronaux tabulaires (TabNet, SAINT) et les petits modèles de séquences formés sur des ensembles de données de taille moyenne fonctionnent bien sur un CPU quand le nombre de paramètres du modèle reste en dessous de 10 à 50 millions environ.

PyTorch utilise OpenMP pour le parallélisme CPU. En mettant OMP_NUM_THREADS=16 et torch.set_num_threads(16) sur un système à 16 cœurs, on s'assure que l'entraînement PyTorch utilise tous les cœurs disponibles. Pour les tailles de lots qui rentrent dans le cache CPU (petits modèles, couches denses), le débit d'entraînement est plus élevé qu'on ne le pense souvent.

L'optimisation CPU de TensorFlow utilise Intel MKL-DNN (oneDNN), qui tire parti d'AVX-512 sur le matériel compatible. Les versions de TensorFlow avec AVX-512 sont nettement plus rapides sur EPYC que sur les anciens systèmes Xeon qui ne prennent pas en charge AVX-512.

Le chargement des données, le vrai problème

Pour les boucles d'entraînement du processeur, le chargeur de données est souvent plus lent que le passage en avant du modèle. Les chargeurs de données PyTorch avec num_workers=8 ou plus sur un système à 16 cœurs peuvent précharger les lots assez rapidement pour éviter que la boucle d'entraînement ne s'essouffle.

NVMe change encore la donne. La lecture des fichiers Parquet pour l'entraînement par lots sur un SSD SATA plante souvent. Sur NVMe 5 Go/s en lecture séquentielle, les threads du chargeur de données restent en avance sur la boucle d'entraînement, même avec des lots de grande taille. C'est important pour les modèles entraînés sur des données d'images, du texte tokenisé à partir du disque ou des données tabulaires provenant de grandes partitions Parquet.

Réglage des hyperparamètres Parallélisme

La recherche d'hyperparamètres est super parallèle. Chaque essai est indépendant. Sur un système à 16 cœurs, tu peux faire tourner 16 essais en même temps sans avoir à te soucier de la communication entre les processus.

Optuna, Ray Tune et GridSearchCV de scikit-learn permettent tous de faire des essais en parallèle grâce au multiprocessing de Python. Une recherche par grille sur 256 combinaisons de paramètres qui prendrait 8 heures en mode mono-thread se fait en à peu près 30 minutes sur 16 cœurs. Cette compression change la façon dont les équipes ML bossent.

Les solutions cloud pour ce cas d'utilisation facturent soit un prix par cœur, ce qui peut vite coûter cher pour les recherches longues, soit demandent de lancer des clusters Ray distribués, avec les frais de gestion que ça implique. Un serveur dédié qui utilise les 16 cœurs pour une recherche de 30 minutes n'a pas de frais de coordination de cluster.

Infrastructure de service d'inférence

Latence et débit pour les terminaux de production

La plupart des points de terminaison d'inférence ML de production n'ont pas besoin d'un GPU. Les modèles tabulaires, les moteurs de recommandation, les classificateurs de détection de fraude et les modèles NLP avec moins de 100 millions de paramètres traitent les requêtes en 1 à 20 ms sur les processeurs modernes. L'inférence GPU ajoute des coûts d'infrastructure et une complexité qui ne se justifient pas, sauf si vous utilisez de grands modèles linguistiques ou générez des images.

Un serveur dédié qui tourne sous FastAPI ou TorchServe peut gérer de quelques centaines à quelques milliers de requêtes d'inférence par seconde pour des modèles ML tabulaires classiques, selon la complexité du modèle et la charge de calcul des fonctionnalités. Pour les équipes qui paient actuellement pour des instances d'inférence GPU servant des modèles relativement petits, passer à l'inférence CPU sur du matériel dédié permet généralement de réduire les coûts d'infrastructure d'inférence de 60 à 80 %.

Mise en cache et mémoire du modèle

Pour garder plusieurs versions de modèles en mémoire en même temps, il faut de la RAM. Une plateforme ML qui gère 10 versions de modèles différentes, chacune pesant entre 2 et 4 Go, a besoin de 20 à 40 Go de mémoire juste pour la mise en cache des modèles, sans compter la charge liée au traitement des requêtes. Avec 192 Go, tu as assez de place pour stocker tout le registre des modèles en mémoire, en plus de la couche applicative et du système d'exploitation, sans aucun conflit.

Comparaison des coûts : options d'infrastructure ML

Cas d'utilisation	Option Cloud	Coût du cloud	InMotion Hosting	InMotion Hosting
XGBoost / boosting par gradient	c5.4xlarge (16 vCPU)	Environ 480 $ par mois	Extrêmement dédié (16 cœurs)	349,99 $ par mois
Réglage des hyperparamètres (en parallèle)	c5.4xlarge spot	Environ 150 $ par mois + risque	Avancé dédié	149,99 $ par mois
Service d'inférence CPU	c5.2 très grand x2	Environ 480 $ par mois	Essentiel Dédié	99,99 $ par mois
Ingénierie des fonctionnalités en mémoire à grande échelle	r5.4xlarge (128 Go)	Environ 780 $ par mois	Extrêmement dédié (192 Go)	349,99 $ par mois

Ce qui reste sur Cloud GPU

Les serveurs CPU dédiés ne remplacent pas les GPU cloud pour toutes les tâches. Le réglage fin des grands modèles linguistiques, la formation des transformateurs de vision à partir de zéro et la formation à la diffusion stable restent liés aux GPU. L'approche pratique pour la plupart des équipes ML :

• Faites de l'ingénierie des caractéristiques, de l'EDA, du gradient boosting et de l'inférence sur une infrastructure CPU dédiée.
• Utilisez des instances GPU spot dans le cloud pour les tâches de formation périodiques en apprentissage profond.
• Utilise l'inférence CPU dédiée pour tous les modèles, sauf les très gros réseaux neuronaux.
• Mettez en place des pipelines de prétraitement des données sur un stockage dédié NVMe plutôt que sur un stockage objet dans le cloud.

Cette approche hybride combine les avantages des deux options en termes de coût et de performances, sans imposer un choix d'infrastructure unique à des charges de travail ayant des exigences différentes.

Tout est prêt

Le serveur dédié ExtremeInMotion Hosting est livré avec un processeur AMD EPYC 4545P, 192 Go de RAM DDR5 ECC et deux NVMe de 3,84 To gérés par l'équipe APS InMotion Hosting. La configuration de l'environnement Python, CUDA (si vous ajoutez plus tard un GPU externe) et l'installation du framework ML font partie de la configuration standard du serveur pour laquelle InMotion Solutions peut vous aider dans le cadre de son service Premier Care.

• Découvrez les serveurs dédiés : inmotionhosting .com/dedicated-servers
• Comparez les niveaux de prix : inmotionhosting .com/dedicated-servers/dedicated-server-price
• Détails sur Premier Care : inmotionhosting .com/blog/inmotion-premier-care/

Pour les équipes qui dépensent plus de 300 $ par mois en instances CPU cloud pour des charges de travail ML, le passage à du matériel dédié est rentabilisé dès le premier cycle de facturation.