Le déport vers le CPU permet de faire fonctionner un modèle surdimensionné en stockant une partie de ses poids dans la RAM du système, au lieu d’exiger que le modèle entier reste dans la mémoire de l’accélérateur.
Sur un serveur IA domestique, cela peut transformer un modèle qui refuse de se charger sur un seul GPU en service local utilisable. Le compromis est direct : la pression sur la VRAM diminue, mais la mémoire du CPU, le trafic PCIe ou interconnexion et, parfois, l’exécution sur le CPU entrent dans le chemin d’inférence. Le déport est avant tout une technique d’augmentation de capacité, et une technique de performance uniquement lorsque la hiérarchie mémoire est suffisamment rapide.
Un modèle surdimensionné échoue lorsque le périphérique rapide ne peut pas contenir l’état requis
Un modèle local a besoin d’espace pour ses poids, ainsi que pour le cache KV, les activations, les tampons temporaires et les réservations du runtime. Si l’accélérateur ne peut pas contenir l’état résident requis, le chargement peut échouer avant même le début d’une inférence utile.
Hugging Face Accelerate considère l’inférence de grands modèles comme un problème de répartition des poids du modèle entre les différents niveaux de mémoire disponibles. Le déport vers le CPU ajoute la RAM du système comme niveau de stockage plus lent pour l’état du modèle.
Le modèle devient exécutable parce qu’une plus petite partie doit rester en VRAM au même moment, et non parce que l’accélérateur a gagné de la mémoire physique.
Les poids déportés restent dans la RAM du système jusqu’à ce que leur couche soit nécessaire
Un runtime peut conserver certains tenseurs de paramètres sur le CPU pendant que la couche ou le groupe de couches actif s’exécute sur le GPU. Au fur et à mesure de l’exécution, les poids nécessaires sont transférés vers l’accélérateur, tandis que les anciens peuvent être renvoyés vers la mémoire système ou supprimés de la mémoire du périphérique.
DeepSpeed ZeRO-Inference peut conserver les poids du modèle en mémoire CPU ou NVMe et les diffuser couche par couche vers le GPU. Cela réduit la quantité maximale de données résidentes dans l’accélérateur, tout en intégrant le transfert des poids à l’exécution.
Le placement des couches peut également être statique : certaines restent sur le CPU et y sont exécutées, tandis que d’autres restent sur le GPU. Dans les deux cas, la pression sur la mémoire du périphérique est échangée contre des chemins mémoire et de transfert plus lents.
Le chemin PCIe ou la mémoire unifiée fait partie de chaque token
Si les poids doivent traverser le PCIe pendant l’exécution avant propagation, la latence et la bande passante du transfert se trouvent directement sur le chemin critique de l’inférence. Un modèle qui tient entièrement dans la VRAM peut réutiliser ses poids résidents à la bande passante du périphérique ; un modèle déporté peut devoir récupérer de gros tenseurs à plusieurs reprises.
PyTorch documente la mémoire hôte verrouillée et le comportement des transferts du CPU vers le GPU, illustrant pourquoi les déplacements entre l’hôte et le périphérique constituent un domaine de performance distinct des calculs du GPU.
C’est pourquoi le déport vers le CPU peut transformer un plantage par manque de mémoire en modèle fonctionnel, mais plus lent. La capacité est résolue en premier ; le débit peut fortement diminuer.
Davantage de RAM système augmente la capacité, mais ne garantit pas la vitesse
Il faut suffisamment de RAM pour contenir la partie déportée, ainsi que le système d’exploitation, le cache de pages, les conteneurs, les bases de données et les autres services du serveur domestique. Dès que le modèle déborde sur le swap, une configuration lente peut devenir inutilisable.
Linux documente la récupération mémoire et le swap dans le cadre de la hiérarchie mémoire du système. Un modèle déporté partage ce même budget de RAM avec tous les autres processus.
Un serveur domestique qui exécute également un NAS, un indexeur de photos et une base de données multimédia doit conserver une véritable marge de sécurité, au lieu de dimensionner la RAM uniquement en fonction de la taille du fichier du modèle.
La quantification et le déport résolvent des aspects différents du problème d’ajustement
La quantification réduit le nombre d’octets utilisés par les poids, ce qui peut diminuer la quantité de mémoire occupée sur le GPU comme sur le CPU et réduire le volume des transferts. Le déport modifie l’emplacement de ces octets pendant l’exécution.
NVIDIA NeMo documente la quantification FP8, INT8 et INT4 après l’entraînement afin de réduire la mémoire du modèle. Un modèle quantifié peut tenir entièrement sur le GPU et éviter le déport ; un modèle plus volumineux peut toutefois nécessiter les deux techniques.
La bonne démarche consiste d’abord à définir le niveau de précision et la qualité de modèle acceptables, puis à choisir le placement. Déporter une représentation inutilement volumineuse peut gaspiller de la bande passante.
Utilisez le déport vers le CPU lorsque l’exécution du modèle compte davantage que le débit maximal
Le cas d’usage le plus pertinent est celui d’un modèle local utilisé occasionnellement, qui dépasse la VRAM mais fournit malgré tout une latence acceptable lorsque l’état est partiellement stocké en RAM. Cette solution est moins intéressante pour un service interactif multi-utilisateur, où chaque token doit franchir à plusieurs reprises une liaison lente.
Le guide de ZimaSpace consacré à la mémoire et au dimensionnement des accélérateurs pour un NAS IA constitue la base de planification : le déport doit être considéré comme une solution de repli pour la capacité, au sein de la charge de travail complète d’un serveur domestique.
Mesurez l’utilisation de la VRAM et de la RAM, le volume d’octets transférés entre l’hôte et le périphérique, le temps jusqu’au premier token, le nombre de tokens produits par seconde et l’effet sur les autres services auto-hébergés. Une configuration qui se charge techniquement mais force l’utilisation du swap ou ralentit le NAS n’est pas une solution adaptée.
L’explication de ZimaSpace sur la résidence et l’éviction des modèles couvre un compromis voisin : libérer de la mémoire de l’accélérateur augmente la capacité disponible pour d’autres tâches, mais peut contraindre la requête suivante à repayer le coût du chargement ou du transfert.
FAQ
Le déport vers le CPU combine-t-il la RAM et la VRAM en un seul pool de mémoire rapide ?
Non. Il permet au runtime de répartir l’état du modèle entre les deux niveaux, mais la RAM du CPU et la VRAM du GPU ont des bandes passantes et des latences différentes. Les transferts entre elles peuvent devenir le principal goulot d’étranglement de l’inférence.
Ajouter davantage de RAM accélérera-t-il un modèle déporté ?
Uniquement lorsque le système manque actuellement de RAM, utilise le paging ou ne peut pas conserver en mémoire l’état déporté prévu. De la RAM supplémentaire inutilisée ne supprime ni les coûts du PCIe ni ceux de l’exécution sur le CPU.
Le déport vers un SSD est-il identique au déport vers le CPU ?
Non. Le déport vers un disque ajoute un niveau de stockage encore plus lent lorsque la RAM est insuffisante. Il peut augmenter davantage la capacité, mais les pages du modèle doivent traverser le stockage puis généralement la mémoire système avant l’exécution sur l’accélérateur.
Centre Tech & IA
Plus à lire

Les caméras domestiques peuvent-elles synchroniser les événements sans services horaires cloud ?
Une explication axée sur les mécanismes de l’heure de la caméra sans cloud, ses compromis liés aux ressources partagées, trois FAQ sur la diffusion...

Un service d’IA local peut-il détecter les couches de modèle corrompues avant l’inférence ?
Une explication axée sur les mécanismes de la détection des couches de modèle corrompues, de ses compromis en matière de ressources partagées, de trois...

Un système RAG peut-il être restauré sans régénérer chaque embedding ?
Une explication de la restauration RAG sans réencodage, axée sur le mécanisme, de ses compromis en matière de ressources partagées, trois FAQ sur la...

