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

Cette page traite de la capacité : ce qui doit tenir sur un appareil et ce que contexte et concurrence changent. Les candidats datés illustrent ces contraintes. Pour le comportement, lire le choix des modèles de code ; pour les formats et la vitesse, la quantification et les performances d’inférence.

« 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.

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ù $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. 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

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

Ce sont des points de départ, pas des garanties de compatibilité. L’architecture, le format de quantification, le backend, la précision du cache et la prise en charge GPU peuvent déplacer fortement la limite.

Exemples actuels à tester

• Qwen3.6-27B : Apache-2.0, 27B paramètres, un encodeur de vision, un contexte natif de 262K et une voie documentée vers environ 1M tokens. La fiche liée recommande vLLM ≥0.19.0 ou SGLang ≥0.5.10 et montre des exemples de service sur huit GPU, pas une configuration quantifiée testée sur 16 Go ni un nombre minimal de GPU. Qwen conseille au moins 128K de contexte pour préserver les capacités de raisonnement ; réduire le contexte pour tenir en mémoire est un compromis de qualité à évaluer, pas un gain de capacité sans contrepartie.
• gpt-oss-20b : Apache-2.0, 21B paramètres au total et 3,6B actifs. Sa fiche de modèle décrit un artefact MXFP4 conçu pour fonctionner dans 16 Go de mémoire et impose le format de réponse Harmony.
• Mistral Small 3.1 24B : la fiche de modèle distingue un chemin quantifié pour GPU grand public d’exigences de service BF16 beaucoup plus grandes. C’est un rappel utile que le seul nom du modèle n’indique pas son usage mémoire.

Une limite de contexte publiée ne signifie pas que toute la fenêtre tient sur un GPU, s’exécute vite ou conserve une qualité suffisante pour la tâche.

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. L’ampleur de cette pénalité dépend du modèle, des couches déportées, de la bande passante mémoire, de l’interconnexion, du backend, de la longueur du prompt et de la taille de lot. Il n’existe pas de seuil universel en jetons par seconde.

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 l’usage maximal GPU/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 · Les notes ouvertes sont mémorisées dans ce navigateur.