Un modèle de 177 milliards de paramètres sur deux cartes grand public : l'emplacement compte plus que le débit

Niveau AvancéTemps estimé une soiréeÀ lire avant Plusieurs modèles, deux cartes graphiques : une grille plutôt qu'un numéro de jonglage, RAM, zram et swap sur une machine IA : les trois voleurs qui nous coûtaient un facteur dixUn mot inconnu ? Lexique

Un modèle à mélange d'experts (MoE) n'utilise qu'une petite partie de ses poids pour chaque jeton. C'est ce qui permet à un modèle de 177 milliards de paramètres, compressé sur 2 bits, de tourner sur deux cartes de 16 Go et la RAM : la plupart des experts attendent en RAM, les plus sollicités sont sur les cartes. Ça marche, autour de 55 jetons par seconde chez nous, une fois trois choses réglées.

Comment ces chiffres ont été obtenus. Mesurés sur nos propres machines (voir le protocole), en général en un seul passage, vitesses relevées par le serveur lui-même ; nous ne publions pas les journaux bruts. Ce sont des ordres de grandeur sur ce matériel, pas des garanties sur le vôtre. Les chiffres extérieurs sont accompagnés de leur source.

Trois mesures, dans l'ordre où elles ont été prises. Élargir le lien PCIe seul n'a rien changé, parce que l'essentiel du modèle vivait toujours derrière la carte lente. Regrouper le modèle sur une carte a doublé la vitesse.

Un peu d'histoire

L'idée du mélange d'experts est plus ancienne que l'apprentissage profond : Jacobs, Jordan, Nowlan et Hinton l'ont décrite en 1991, un ensemble de spécialistes et une porte qui choisit lequel consulter. En 2017, une équipe de Google l'a rendue clairsemée et immense : des milliers d'experts, quelques-uns seulement actifs par jeton. C'est pourquoi un modèle de 177 milliards de paramètres peut tourner à la maison : l'essentiel se repose pendant le calcul de chaque jeton.

1. L'emplacement d'abord, le débit ensuite

Notre modèle était réparti sur les deux cartes, et la grosse carte faisait tourner son lien PCIe en x4 au lieu de x16. Corriger le lien seul n'a rien donné : 26,1 avant, 22,1 après. L'essentiel du modèle vivait toujours sur la seconde carte, derrière son propre lien de quatre lignes. Regrouper le modèle sur la grosse carte, en x16, a donné 55,6. Mesurez un changement à la fois, dans l'ordre, sinon vous attribuerez le gain au mauvais.

2. Mapper les poids, ne jamais les épingler

Les options de chargement décident si les poids du modèle peuvent quitter la RAM quand la mémoire manque. Le chargement mappé (mmap) laisse le système libérer des pages qu'il pourra relire dans le fichier ; le chargement « résident » les épingle. En résident, 47,6 Go de nos 60 sont devenus une mémoire que rien ne pouvait récupérer, et la machine a gelé deux fois dans l'après-midi. Chargez les gros MoE en mmap, et tenez les voleurs de RAM à l'écart (voir RAM, zram et swap).

3. Garder le cache de prompt

Un agent renvoie le même long préfixe (instructions et définitions d'outils) à chaque message. llama.cpp garde l'état des prompts déjà lus dans un cache en RAM, --cache-ram, 8 192 Mo par défaut. Nous l'avons mis à 0 après le gel, en le confondant avec les poids : chaque tour relisait alors 11 233 jetons, 112 secondes. Avec le cache rétabli, le second tour a lu 4 jetons en 2 secondes : cinquante fois plus vite, sans rien perdre.

Pièges

Le cache de prompt garde l'état d'un prompt, pas les poids du modèle : il n'était pas la cause du gel. Deux mémoires aux noms proches ; ne coupez que celle que vous avez mesurée.

Le premier tour après le chargement paie toujours le prompt complet. Après une bascule vers un gros modèle, jouez un tour vous-même avant qu'un agent ou une personne l'utilise.

Rendez impossibles les réglages dangereux : notre test de déploiement refuse une configuration avec le cache de prompt à 0, et nous avons vérifié que le test passe au rouge quand quelqu'un essaie.

Sources

Utile ? Dites-nous ce qu'il faut mesurer ensuite.