Déployer sur un appareil : poids, mémoire et contexte

« Fonctionne sur un GPU » peut signifier que les poids se chargent tout juste, qu’une courte requête aboutit avec un déport vers le CPU, ou qu’un contexte utile reste exploitable à vitesse interactive. Pour juger si une configuration convient, vérifiez la mémoire, la longueur de contexte et la vitesse nécessaires à votre tâche. Une session de programmation interactive et un traitement nocturne par lot ne tolèrent pas les mêmes délais.

Cette page traite de la capacité : ce qui doit tenir sur un appareil et ce que contexte et concurrence changent. La liste datée des modèles candidats se trouve seulement dans le choix des modèles de code ; pour les formats et la vitesse, la quantification et les performances d’inférence.

Commencer par le budget mémoire

La mémoire brute des poids est approximativement :

$$\text{weight bytes}\approx\frac{\text{parameter count}\times\text{bits per weight}}{8}.$$

Un modèle de 27B à quatre bits occupe environ 12,6 Gio avant les métadonnées de quantification, les tenseurs conservés à plus haute précision, les espaces de travail d’exécution et le cache KV. La taille de l’artefact est un meilleur point de départ que le calcul par nombre de paramètres lorsque la quantification exacte existe déjà.

Pour les modèles MHA ou GQA conventionnels, le cache KV d’une séquence est approximativement :

$$2\times L\times S\times d_{kv}\times b,$$

où le facteur 2 compte une clé et une valeur, $L$ est le nombre de couches, $S$ la longueur de séquence retenue, $d_{kv}$ la largeur de clés/valeurs mise en cache par couche et $b$ le nombre d’octets par élément.

Appliquons la forme de Llama 3 8B : 32 couches, 8 têtes clé/valeur de 128 dimensions chacune, soit une largeur clé/valeur de 1024, stockée en BF16 sur 2 octets. Un token occupe 2×32×1024×2 = 131 072 octets, soit 128 Kio. À 32K tokens de contexte, cela fait 4 Gio ; à 128K, 16 Gio, à peu près autant que tous les poids BF16 du modèle (8 milliards × 2 octets = 16 Go). Une limite de contexte publiée ne signifie donc pas que toute la fenêtre tient sur un GPU, s’exécute vite ou conserve une qualité suffisante pour la tâche. La note sur le cache KV détaille d’autres cas.

Le $b$ de la formule est un réglage à votre portée. Ollama fixe la précision du cache avec OLLAMA_KV_CACHE_TYPE ; sa FAQ indique que q8_0 occupe environ la moitié de la mémoire du f16 par défaut et q4_0 environ le quart, à condition que Flash Attention soit activé. Le cache de 16 Gio à 128K ci-dessus tombe à environ 8 Gio avec q8_0 ; q4_0 économise davantage et coûte davantage en qualité.

MLA et d’autres conceptions d’attention emploient des dispositions de cache différentes. La taille de lot et les séquences parallèles multiplient ce besoin.

Gardez de la place pour les jetons de sortie, les tampons temporaires, le pilote d’affichage et les variations ordinaires à l’exécution. Une configuration qui survit à un prompt en laissant presque aucune VRAM libre ne constitue pas encore un plan de capacité utile.

Premières expériences raisonnables

Le tableau suppose des poids en 4 bits, une seule séquence et un contexte d’environ 8K tokens. L’architecture, le format de quantification, le backend, la précision du cache et la prise en charge GPU déplacent tous la limite ; avec un autre format ou un contexte plus long, revenez aux formules ci-dessus. Le nom d’un modèle ne remplace pas cette étape : le Small 4 de Mistral compte 119B paramètres, et « Small » ne dit rien de sa place sur une carte grand public.

VRAM disponible	Premier essai	Point de pression probable
8 Go	3–4B quantifié ; certains modèles 7–8B à contexte court	poids, contexte et déport
12 Go	7–8B quantifié ; expériences prudentes avec des modèles plus grands	cache KV et espace de travail d’exécution
16 Go	12–14B à quantification confortable, ou un artefact 20–27B ajusté au plus près	contexte, concurrence et marge
24 Go	20–27B quantifié avec plus de place pour le cache ; certains artefacts plus grands ou MoE	long contexte et séquences multiples

Sur un Mac, la mémoire unifiée est un seul budget partagé

Apple Silicon n’a pas de VRAM séparée. Selon la documentation de MLX, le CPU et le GPU accèdent directement au même réservoir de mémoire, si bien que les poids ne sont pas copiés de l’un à l’autre. La contrepartie : le modèle partage cette mémoire avec le système, le navigateur et l’éditeur. Un Mac de 16 Go laisse au modèle bien moins de 16 Go.

Metal fournit une valeur de référence pour ce que le GPU peut utiliser. recommendedMaxWorkingSetSize est une approximation du nombre d’octets que le GPU peut allouer sans nuire à ses performances ; rester en dessous garde le GPU rapide. mlx-lm prévient que les modèles volumineux par rapport à la RAM totale peuvent être lents. Quand le modèle tient, macOS 15 et ultérieur permet de relever la limite de mémoire verrouillée avec sudo sysctl iogpu.wired_limit_mb=N, où N dépasse la taille du modèle en mégaoctets tout en restant inférieur à la mémoire de la machine.

La vitesse dépend ensuite de la bande passante mémoire. D’après les caractéristiques du MacBook Pro chez Apple, le M6 de 16 Go offre 153 Go/s. Le M5 Pro offre 307 Go/s et le M5 Max à GPU 40 cœurs 614 Go/s. Un même fichier 4 bits décode sur ces trois machines avec des plafonds à peu près proportionnels à la bande passante ; le calcul se trouve dans les performances d’inférence.

Ce tableau reprend les hypothèses du précédent, une fois servis le système et les applications courantes :

Mémoire unifiée	À peu près comparable à	Point de pression probable
16 Go	une carte de 8–12 Go : 7–8B quantifié, contexte court	le système et les autres applications se disputent la mémoire
24–32 Go	une carte de 16 Go : 12–14B, ou un artefact 20–27B ajusté au plus près	contexte et marge
48–64 Go	une carte de 24 Go ou plus : 20–32B avec long contexte, certains MoE	la bande passante fixe la vitesse
128 Go	des MoE plus grands ou des artefacts quantifiés de classe 70B	bande passante et temps de préremplissage

Sur un Mac, un même modèle existe souvent en fichiers GGUF et MLX, avec des quantifications, des tailles et des vitesses différentes ; le choix du runtime indique quel runtime lit quoi.

Le déport est un compromis, pas un échec

Le déport vers le CPU ou la mémoire système peut permettre d’exécuter un modèle plus grand, mais il déplace les données sur un chemin bien plus lent et peut réduire fortement la vitesse de décodage. Il n’existe pas de seuil universel en jetons par seconde : la pénalité dépend du modèle, des couches déportées, de la bande passante mémoire, du PCIe ou d’une autre interconnexion, du backend, de la longueur du prompt et de la taille de lot. Une même optimisation du déport peut rapporter plusieurs fois plus sur une machine que sur une autre. ExLlamaV3 a accéléré le déport CPU dans plusieurs versions d’octobre ; après une mise à jour ou sur une nouvelle machine, remesurez avec votre propre charge.

La résidence complète sur GPU est souhaitable pour les travaux sensibles à la latence, pas une règle pour toute charge de travail. Un traitement nocturne par lot peut tolérer un déport qui rendrait une boucle de programmation interactive désagréable.

Procédure d’adéquation

1. Définissez la tâche, la concurrence, la longueur d’entrée, la réserve de sortie et la latence acceptable.
2. Choisissez un artefact, un modèle de prompt et un runtime précis.
3. Commencez avec un contexte court et une séquence.
4. Consignez la consommation maximale de mémoire GPU et de RAM, le déport, le temps jusqu’au premier jeton, la vitesse de décodage et le résultat de la tâche.
5. Augmentez le contexte séparément de la concurrence afin que la source d’un échec soit visible.
6. Testez la dépendance informationnelle la plus longue requise par la charge de travail réelle, et non seulement un prompt rempli de texte de remplissage.
7. Conservez une marge opérationnelle et consignez la configuration réellement testée.

Un modèle plus petit, entièrement résident, peut battre un modèle plus grand déporté dans une boucle d’outils. Un contexte plus long peut aussi ralentir le système sans l’aider davantage à trouver les bonnes preuves. Utilisez le protocole d’évaluation locale pour décider à partir des tâches plutôt que du nombre de paramètres.

Le guide d’estimation mémoire d’Accelerate montre comment estimer la mémoire des paramètres selon leur type numérique sans charger tous les poids. Comparer cette estimation au calcul ci-dessus, puis mesurer le runtime complet : cache, activations et buffers temporaires demandent un budget supplémentaire.

Mes lectures