Après avoir obtenu votre premier résultat, il est facile de vouloir essayer des modèles plus grands. Vous pouvez passer de 0.5B à 7B, mais l'appareil d'origine n'est peut-être plus suffisant.
Lors de la sélection des ressources, distinguez d'abord quelques éléments. CPU et GPU gèrent le calcul, la mémoire et la mémoire vidéo stockent les données en cours d'exécution, et le disque sauvegarde les fichiers du modèle. Le fait qu'un modèle puisse être téléchargé signifie uniquement que le disque a assez d'espace — pour qu'il puisse fonctionner correctement, cela dépend également de la mémoire, de la mémoire vidéo et de la puissance de calcul. Le même modèle, selon la précision à laquelle vous le chargez, la longueur de l'entrée et le nombre de requêtes traitées simultanément, affectera tous l'utilisation des ressources. L'inférence et l'entraînement ont également des besoins différents.
Commençons par examiner ce que CPU et GPU sont chacun aptes à faire, puis estimons combien d'espace les paramètres du modèle occuperont, pour préparer le choix d'un ordinateur portable ou d'une instance cloud.
CPU et GPU diffèrent considérablement dans leurs approches de calcul.
CPU est conçu pour le calcul général, chaque cœur disposant de capacités de contrôle et de calcul relativement complètes. Il peut prendre des décisions, sauter et planifier des tâches en fonction du processus d'exécution du programme, traitant flexiblement différents types de tâches de calcul.
GPU utilise une architecture de calcul parallèle, contenant un grand nombre d'unités de calcul qui peuvent exécuter un grand nombre de tâches de calcul simultanément. Il est adapté au traitement de tâches avec de grandes échelles de données et une forte répétitivité de calcul.
La vitesse de traitement de CPU et GPU dépend du type de tâche et de l'échelle de calcul.
Pour les scénarios impliquant une grande quantité de jugement logique, de contrôle de programmes et de planification de tâches, CPU a une efficacité d'exécution plus élevée. Les tâches comme le fonctionnement d'un système d'exploitation et les requêtes de base de données sont bien adaptées au CPU.
Pour les tâches de calcul parallèle à grande échelle, GPU peut fournir un débit de calcul plus élevé. La multiplication de matrices et les opérations de convolution dans l'apprentissage profond peuvent être divisées en plusieurs sous-tâches parallèles, exécutées simultanément par les unités de calcul du GPU, améliorant l'efficacité de calcul globale.
Cependant, les avantages du GPU ne deviennent significatifs que lorsque l'échelle des tâches de calcul est importante. Lorsque le volume de données est petit, les ressources de calcul du GPU ne peuvent pas être pleinement utilisées, et le transfert de données et la planification des tâches entre CPU et GPU apportent également des coûts supplémentaires. Dans ce cas, utiliser le CPU peut être plus efficace.
Se connecter pour rejoindre la discussion
Les coûts de CPU et GPU incluent non seulement les prix d'achat du matériel, mais aussi la consommation électrique pendant le fonctionnement, ainsi que les coûts d'utilisation et de maintenance ultérieurs.
En matière d'approvisionnement en matériel, le CPU est standard — les serveurs ordinaires et les ordinateurs personnels ont tous besoin d'une configuration CPU. Les GPU haute performance utilisés pour l'entraînement et l'inférence IA sont généralement coûteux. En plus du GPU lui-même, vous devez également considérer les coûts des serveurs, de la mémoire vidéo, du stockage et du matériel de support.
Pendant le fonctionnement, le GPU a une consommation électrique élevée lors de l'exécution de calculs à grande échelle. Plus il y a de GPU dans un serveur, plus la pression sur l'alimentation et le refroidissement est grande, et les coûts d'électricité et de refroidissement des centres de données augmenteront considérablement.
En matière d'utilisation et de maintenance, l'écosystème CPU est relativement mature, et la maintenance des serveurs est relativement simple. Le GPU nécessite de considérer la compatibilité des pilotes, des frameworks de calcul et de l'environnement matériel. Les conflits entre différentes versions peuvent empêcher les modèles de fonctionner normalement. Les environnements multi-GPU impliquent également la communication des données entre les appareils, ce qui a des exigences pour les connexions matérielles et la configuration logicielle.
L'entraînement et l'inférence ont des besoins en ressources différents, et les modèles de différentes tailles et types ont également des différences significatives en ressources de calcul. La sélection du matériel doit considérer de manière globale l'échelle du modèle, le volume de données, les exigences de performance et les besoins en ressources dans les scénarios d'entraînement et d'inférence.
Dans la phase d'entraînement du modèle, lorsque l'échelle de données est petite, le CPU peut répondre aux besoins d'entraînement de la plupart des modèles d'apprentissage automatique traditionnels, tels que la régression linéaire, la régression logistique et les forêts aléatoires. Certains réseaux neuronaux légers peuvent également utiliser le CPU pour l'entraînement, mais à mesure que le volume de données et la complexité de la structure du modèle augmentent, le temps d'entraînement augmentera considérablement. Si vous avez besoin d'ajuster fréquemment les modèles, l'utilisation du GPU peut réduire le temps d'entraînement.
L'entraînement de grands réseaux neuronaux et de grands modèles de langage nécessite une calcul matriciel important, avec des exigences élevées en puissance de calcul et en capacité de mémoire vidéo. Les grands modèles de langage avec des milliards de paramètres, comme Qwen, ont besoin de s'appuyer sur des appareils d'accélération haute performance comme le GPU pour l'entraînement.
Les exigences du modèle pendant l'inférence diffèrent de celles de l'entraînement. Pour les scénarios avec de plus petites échelles de paramètres et de volumes d'accès inférieurs, le CPU peut répondre aux besoins d'inférence, et l'utilisation des ressources peut également être réduite par des méthodes comme la quantification. Pour les grands modèles, les services à haute concurrence et les scénarios nécessitant une réponse rapide, le GPU peut fournir une efficacité d'inférence plus élevée.
CPU et GPU ont chacun des scénarios applicables, et vous devez considérer de manière globale l'échelle du modèle, le volume de données, les requêtes concurrentes, les exigences de performance et les coûts de déploiement.
L'évaluation des besoins en ressources d'un modèle dépend principalement de deux indicateurs : l'échelle des paramètres et la précision des données.
L'échelle des paramètres du modèle est généralement exprimée en B, où 1B représente 1 milliard de paramètres. Les paramètres sont les valeurs numériques que le modèle apprend pendant l'entraînement. Pendant l'inférence, ces paramètres doivent être chargés en mémoire (CPU) ou en mémoire vidéo (GPU). Plus le nombre de paramètres est élevé, plus les ressources occupées sont importantes.
La précision des données fait référence au format numérique utilisé pour stocker et calculer les paramètres du modèle. Les formats courants incluent FP32, FP16, BF16 et les formats de quantification comme INT8 et INT4. Pour le même nombre de paramètres, une précision de données plus élevée signifie plus de ressources occupées.
L'espace de stockage estimé pour 1B paramètres à différentes précisions est le suivant :
| Précision | Espace par 1B paramètres (approx.) | Utilisations courantes |
| FP32 (Précision simple) | 4GB | Entraînement, inférence haute précision |
| FP16 (Demi-précision) | 2GB | Entraînement, inférence |
| BF16 | 2GB | Entraînement, inférence |
| INT8 | 1GB | Inférence quantifiée |
| INT4 | 0.5GB | Inférence quantifiée basse précision |
Poids du modèle = Nombre de paramètres × Espace de stockage par 1B paramètres à cette précision. Pour un modèle 7B avec inférence en précision FP16, l'occupation des poids du modèle est d'environ : 7 × 2GB ≈ 14GB.
Pendant l'inférence du modèle, en plus du chargement des poids du modèle, des ressources supplémentaires sont nécessaires pour le KV Cache, le framework d'exécution et le calcul temporaire.
Le KV Cache est utilisé pour stocker les informations relatives aux Token déjà calculées pendant le processus de génération, évitant les calculs redondants. Son utilisation dépend de la structure du modèle, de la longueur du contexte et du nombre de requêtes simultanées. Plus le contexte est long, plus les informations à stocker sont nombreuses ; plus les requêtes traitées simultanément sont nombreuses, plus l'utilisation du KV Cache augmente.
Formule d'estimation de l'utilisation des ressources d'inférence :
Mémoire requise pour l'inférence CPU ≈ Poids du modèle + Overhead du framework et temporaire.
Mémoire vidéo requise pour l'inférence GPU ≈ Poids du modèle + KV Cache + Overhead du framework et temporaire.
Parmi celles-ci, les poids sont statiques, l'overhead du framework est fondamentalement constant, et la variable réside entièrement dans le KV Cache. Dans les scénarios de séquences longues, l'espace du KV Cache doit être réservé.
Les besoins en ressources de la phase d'entraînement du modèle sont supérieurs à ceux de la phase d'inférence. En plus du stockage des poids du modèle, les gradients, les états de l'optimiseur et les résultats intermédiaires pendant l'entraînement doivent également être stockés, nécessitant plus de ressources. Les besoins en ressources d'entraînement dépendent du type d'optimiseur et de la stratégie d'entraînement.
(1) Entraînement complet du modèle
Pour l'entraînement complet du modèle, les poids du modèle, les gradients, les états de l'optimiseur et les activations doivent être stockés simultanément. En prenant l'entraînement complet avec optimiseur Adam et précision FP16 comme exemple, chaque 1B paramètre nécessite environ :
| Composant | Par 1B paramètres |
| Poids du modèle (FP16) | 2 GB |
| Gradients (FP16) | 2 GB |
| États de l'optimiseur | 8 GB |
| Copie FP32 des poids | 4 GB |
| Sous-total (sans activations) | 16 GB |
Remarque : L'optimiseur Adam doit sauvegarder deux copies des états en précision FP32 (moment et variance), donc les états de l'optimiseur prennent 8GB ; la copie FP32 des poids est utilisée pour la mise à jour des paramètres de l'optimiseur.
La formule d'estimation préliminaire pour l'entraînement complet est :
Mémoire vidéo requise pour l'entraînement GPU ≈ Nombre de paramètres × 16 Byte + Overhead d'activation
Mémoire requise pour l'entraînement CPU ≈ Nombre de paramètres × 16 Byte + Overhead d'activation
L'entraînement GPU est limité par la capacité de la mémoire vidéo, tandis que l'entraînement CPU est limité par la vitesse de calcul. Par exemple, un modèle 7B avec entraînement complet en FP16 sur GPU nécessite au moins 7B × 16 Byte ≈ 112GB de mémoire vidéo, et le besoin réel sera plus important après ajout des activations.
(2) Affinement efficace des paramètres (comme LoRA)
Pour l'affinement des grands modèles, les méthodes d'affinement efficace des paramètres comme LoRA (Low-Rank Adaptation) sont plus couramment utilisées en pratique. LoRA ne met pas à jour tous les paramètres du modèle original pendant l'entraînement ; il gèle les poids du modèle original et n'entraîne que les paramètres d'adaptation à rang faible nouvellement ajoutés, réduisant considérablement les besoins en mémoire vidéo.
Mémoire vidéo pour l'entraînement LoRA ≈ Poids du modèle de base + Paramètres LoRA + Gradients et états de l'optimiseur des paramètres LoRA + Activations.
Parmi celles-ci, les poids du modèle de base doivent uniquement être chargés et ne participent pas aux mises à jour ; les paramètres ajoutés par LoRA ne représentent que 0,1%~1% du modèle original, et leurs gradients et overhead de l'optimiseur sont presque négligeables. La mémoire vidéo réelle dépend principalement des poids du modèle, de la longueur du contexte, de la taille du lot et des méthodes d'optimisation du framework d'entraînement. L'affinement LoRA peut réduire considérablement les besoins en mémoire vidéo par rapport à l'entraînement complet.
Par exemple, en chargant un modèle 7B avec FP16, les poids du modèle prennent 4GB. Sur un seul GPU avec 24GB de mémoire vidéo, l'affinement LoRA peut généralement fonctionner (avec des ajustements appropriés de la taille du lot et de la longueur du contexte). L'utilisation de QLoRA (quantification du modèle de base en INT4) peut réduire davantage l'utilisation de la mémoire vidéo, permettant l'affinement sur un matériel plus limité.