Les compromis sur les ressources

Ce que vous saurez faire

Choisissez un modèle et une machine qui répondent assez vite, tiennent en mémoire et suivent le volume de billets de soutien. Sachez ce que vous perdez quand vous réduisez la taille d’un modèle.

Avant de commencerCe qu’il faut savoir et avoir sous la mainEnviron 45 minutes

Ce que vous devez savoir

• Les trois façons d’obtenir un modèle et la matrice de déploiement, dans Modèle hébergé ou autohébergé.
• Les six questions sur les licences et les conditions d’utilisation des données, dans Licences et conditions d’utilisation des données.
• Ce qu’est un jeton (token) et comment un modèle écrit un jeton après l’autre, dans Prédire la suite.
• La fenêtre de contexte, le nombre de jetons qu’un modèle peut recevoir et écrire dans une requête, dans Contexte et mémoire.
• La médiane, dans Décrire un jeu de données du cours Mathématiques et statistiques essentielles pour l’IA.

Ce qu’il vous faut

• Un navigateur. L’encadré « À vous d’essayer » est facultatif et nécessite Ollama.

Les mesures proviennent d’un Mac mini M4 avec 16 Go de mémoire et Ollama 0.40.1, sans autre modèle chargé. Un exemple provient d’un essai effectué plus tôt le même jour, alors que d’autres programmes utilisaient l’ordinateur. La leçon le décrit comme « occupé ». Vos propres chiffres seront différents.

Trois chiffres au restaurant

Vous commandez un repas au restaurant. Deux durées comptent pour vous : l’attente du premier plat et le temps jusqu’à la fin du repas. La cuisine surveille un troisième chiffre : le nombre de tables qu’elle sert en une heure. Une cuisine peut servir beaucoup de tables par heure, tout en faisant attendre chaque client longtemps.

Un modèle sur un serveur a les mêmes trois chiffres. Cette leçon les mesure sur le Mac mini, avec les deux facteurs qui les limitent : la mémoire et la taille du modèle.

Le problème : le même modèle, rapide et lent

Amira envoie le billet S02 à Gemma 3 4B, qui est déjà dans la mémoire du Mac mini. La réponse est complète après 4.0 secondes. Elle décharge ensuite le modèle et envoie le billet S01. Le modèle est maintenant un fichier de 3.3 Go sur le disque. Ollama doit le charger avant de pouvoir lire un seul jeton. La réponse arrive après 10.0 secondes. Le chargement seul a pris 6.5 secondes (la médiane de 8 chargements, de 2.7 à 7.4 s).

Le modèle est le même; seul son emplacement a changé. La machine qui l’exécute compte aussi. Plus tôt le même jour, d’autres programmes occupaient presque toute la mémoire de 16 Go (l’ordinateur occupé). Le même chargement a alors pris 19 à 342 secondes : l’ordinateur devait d’abord libérer de la place.

La question « à quelle vitesse ce modèle répond-il? » n’a donc pas de réponse unique. Cela dépend de la durée que vous mesurez et de la machine.

La latence : le premier jeton et le dernier

La latence est le temps qu’une personne ou un programme attend une réponse. Pour un modèle de langage, deux latences comptent :

• Le délai avant le premier jeton (TTFT) : de la requête au premier mot de la réponse. Si l’application affiche les mots à mesure qu’ils arrivent, l’utilisateur voit que quelque chose se passe.
• Le temps total : de la requête au dernier jeton. L’assistant renvoie sa réponse dans un seul objet JSON. Ce format texte, lisible par les programmes, contient des champs nommés comme "language": "fr" entre accolades. L’application de soutien a besoin de l’objet complet avant d’afficher le brouillon. Pour Larkfield, c’est donc cette durée qui compte.

La chronologie montre comment les secondes se répartissent, pour une requête à froid et une requête à chaud.

Une requête à Gemma 3 4B (Q4_K_M) sur le Mac mini, à l'échelle. Les valeurs sont les médianes des requêtes mesurées, selon les minuteries d'Ollama. Une requête à froid charge d'abord le modèle. Une requête à chaud trouve le modèle déjà en mémoire.

Description textuelle du diagramme

Deux barres horizontales sur la même échelle de temps, avec les médianes des essais mesurés pour Gemma 3 4B (Q4_K_M) sur le Mac mini.

• Requête à froid, billet S01 : charger le modèle (6.5 s, gris), lire la requête de 576 jetons (1.3 s, bleu), rédiger la réponse de 122 jetons (3.3 s, pâle). Le premier jeton arrive après 7.8 s; la réponse est complète après 11.1 s.
• Requête à chaud, billet S02 : aucun chargement. Lire la requête de 573 jetons (1.3 s), puis rédiger la réponse de 97 jetons (2.6 s). Le premier jeton arrive après 1.3 s; la réponse est complète après 3.9 s.

Une requête à chaud comprend deux parties, et vous pouvez calculer chacune. Gemma lisait la requête à environ 438 jetons par seconde et écrivait à environ 37 jetons par seconde. La lecture est plus rapide que l’écriture. Le modèle lit tous les jetons de la requête ensemble, mais écrit un jeton après l’autre. Pour le billet S02 :

• lecture : 573 jetons ÷ 438 jetons par seconde ≈ 1.3 s
• écriture : 97 jetons ÷ 37 jetons par seconde ≈ 2.6 s
• total : environ 3.9 s. Les minuteries d’Ollama ont mesuré 3.9 s.

Cela vous indique ce qui ralentit une requête. Une longue politique dans la requête ajoute du temps de lecture. Une longue réponse ajoute du temps d’écriture, et l’écriture est environ 12 fois plus lente par jeton. Un modèle qui « raisonne » avant de répondre écrit des centaines de jetons supplémentaires. Qwen3 4B a eu besoin d’environ 1 900 jetons et de 64 secondes par billet.

Comment utiliser ces mesures : gardez le modèle en mémoire entre les requêtes, avec le paramètre keep_alive d’Ollama. Mesurez le temps total des requêtes à chaud. Présentez le temps à froid séparément : il se produit après chaque redémarrage.

Le débit : les billets par heure

Le débit est la quantité de travail qu’un système termine par unité de temps : ici, les billets par heure.

Les deux chiffres se rejoignent dans une file d’attente. Pendant un des tests d’Amira, d’autres programmes envoyaient aussi des requêtes au même serveur Ollama. Sa requête à chaud nécessitait environ 4.1 secondes de travail. Mais sa propre horloge indiquait 12 à 47 secondes. Pendant le reste du temps, la requête attendait derrière d’autres requêtes. Quand les requêtes arrivent plus vite que le serveur ne les termine, chaque requête attend plus longtemps.

Un Mac mini qui répond à un billet à la fois, en environ 5 secondes, termine environ 3 600 ÷ 5 = 720 billets par heure. Larkfield reçoit environ 45 billets par jour. Même une journée de soldes avec 100 billets en une heure utilise moins d’un sixième de cette capacité. Pour Larkfield, le débit n’est pas la limite; la latence et la qualité le sont.

Dans une plus grande boutique, le débit devient la limite. À 45 000 billets par jour, soit environ 1 900 par heure, une machine ne suffit pas. Il faut plus de machines, ou un serveur qui répond à plusieurs requêtes à la fois. Une API hébergée masque ce problème, parce que le fournisseur ajoute des machines. Mais vous rencontrez la limite sous une autre forme : une limite de débit. C’est le nombre de requêtes ou de jetons que votre compte peut envoyer par minute.

La taille du contexte et la mémoire

Imaginez un bureau. Un plus grand bureau peut contenir plus de documents ouverts à la fois. Mais il prend plus de place dans la pièce, même quand il est presque vide.

Comme ce bureau, un modèle réserve de la mémoire pour sa fenêtre de contexte au chargement. Dans Ollama, le paramètre num_ctx définit la taille de la fenêtre. Faites d’abord une prédiction : si la fenêtre est 16 fois plus grande, la mémoire augmente-t-elle 16 fois?

La mémoire utilisée par Gemma 3 4B (Q4_K_M) sur le Mac mini pour trois tailles de fenêtre de contexte (num_ctx d'Ollama), selon ollama ps. Une fenêtre 16 fois plus grande a ajouté environ 0,3 Go.

Description textuelle du graphique

Un graphique linéaire avec trois points : la mémoire utilisée par Gemma 3 4B (Q4_K_M) une fois chargé, pour trois tailles de fenêtre de contexte. 4,096 tokens: 2.89 GB; 16,384 tokens: 2.93 GB; 65,536 tokens: 3.18 GB.

La mémoire augmente, mais bien moins que 16 fois : elle passe de 2.89 Go à 3.18 Go. Les poids restent les mêmes pour chaque taille; seule la partie réservée au contexte augmente. D’autres modèles peuvent réserver beaucoup plus de mémoire que Gemma 3. Mesurez donc le modèle que vous choisissez. La requête de Larkfield contient environ 600 jetons et la réponse, environ 100. Une fenêtre de 4 096 jetons suffit donc, avec de la place en réserve.

L’erreur inverse est pire. Si une requête dépasse la fenêtre, Ollama ne s’arrête pas avec une erreur. Il garde seulement la dernière partie de la requête et répond quand même. Contexte et mémoire montre l’effet sur les réponses. Réglez donc num_ctx pour votre plus longue requête réelle et vérifiez le nombre de jetons de requête rapporté par Ollama.

La quantification : une copie plus petite du même modèle

Une photo enregistrée avec une qualité réduite produit un fichier plus petit. Habituellement, vous ne voyez pas la différence. À quelques endroits, des détails fins disparaissent.

Les poids d’un modèle sont des milliards de nombres. La quantification stocke chaque nombre avec moins de bits. Le fichier du modèle est donc plus petit et nécessite moins de mémoire. (Un bit est un 0 ou un 1; 8 bits forment un octet.) Le principe est d’arrondir. Supposons qu’un poids vaut 0,137 et que tous les poids de son bloc sont entre −1 et 1 :

• Avec 8 bits, il y a 256 niveaux entre −1 et 1, espacés d’environ 0,008. Le niveau le plus proche est 0,1373 : une erreur de 0,0003.
• Avec 4 bits, il y a seulement 16 niveaux, espacés d’environ 0,13. Le niveau le plus proche est 0,133 : une erreur de 0,004, plus de dix fois plus grande.

Le nom indique le nombre de bits. Q8_0 garde environ 8 bits par poids. Q4_K_M en garde environ 4 à 5, avec une échelle distincte pour chaque petit bloc de poids. Dans Ollama, les modèles de ce cours utilisent Q4_K_M par défaut. Amira télécharge la version Q8_0 de Gemma 3 4B (gemma3:4b-it-q8_0). Elle compare les deux sur le même ordinateur et les mêmes 24 billets.

• Q4_K_M
• Q8_0

Le même modèle, Gemma 3 4B, avec deux quantifications : la taille du fichier sur le disque et la mémoire utilisée une fois chargé (fenêtre de contexte de 4 096 jetons).

Description textuelle du graphique

Un graphique à colonnes avec quatre colonnes. Taille sur le disque : Q4_K_M 3.34 Go, Q8_0 4.99 Go. Mémoire une fois chargé, avec une fenêtre de contexte de 4 096 jetons : Q4_K_M 2.89 Go, Q8_0 4.53 Go.

Faites maintenant une prédiction : la plus grosse copie est-elle plus rapide ou plus lente? Est-elle meilleure pour les billets de Larkfield?

Vitesse d'écriture des deux quantifications sur le Mac mini : la médiane des requêtes mesurées, selon les minuteries d'Ollama. La lecture de la requête était à peu près aussi rapide pour les deux (environ 440 jetons par seconde).

Description textuelle du graphique

Un graphique à colonnes avec deux colonnes : la vitesse d’écriture de Gemma 3 4B en jetons de sortie par seconde. Q4_K_M : 37. Q8_0 : 23. Lecture de la requête : Q4_K_M 438 et Q8_0 452 jetons par seconde.

Q8_0 écrit environ 37 % plus lentement. Écrire un jeton exige de lire tous les poids en mémoire une fois, et Q8_0 a plus d’octets à lire. Un billet à chaud a pris 5.3 secondes au lieu de 4.0.

La qualité est la surprise. Amira fait traiter les 24 billets par les deux copies, avec la même requête, et vérifie les étiquettes automatiquement :

Vérification rapide (24 billets)	Q4_K_M	Q8_0
JSON valide	24	24
Étiquette de langue correcte	23	23
Catégorie correcte	20	20
needs_human correct	8	9

(La ligne needs_human utilise le corrigé rectifié du billet D02, comme l’explique le module 4.) Les étiquettes sont presque les mêmes : une seule diffère entre les deux copies. Les réponses ne le sont pas : 23 des 24 réponses ont changé de formulation. Une vérification des étiquettes ne peut pas dire quelle formulation est meilleure. Une personne doit donc lire les réponses.

Camille lit les réponses en français et trouve la principale différence. Q4_K_M est passé du français à l’anglais au milieu de 4 de ses 11 réponses en français. Pour le billet S12, au sujet d’un banc de jardin fissuré :

Q4_K_M: Je suis désolé d'apprendre que votre banc de jardin est fissuré. Our warranty covers garden tools and furniture for defects for 2 years, ...
Q8_0:   Je suis désolé d'apprendre que votre banc de jardin a une fissure. Selon notre politique de garantie, les outils de jardinage et meubles ont une garantie de 2 ans contre les défauts. ...

Q8_0 est resté en français dans les 11 réponses. Pour une équipe de soutien au Québec, cette différence compte plus qu’une seconde par billet. Dire « une copie plus petite est presque identique » est donc une supposition, pas un fait. Pour cette tâche, l’arrondissement a réduit la qualité dans la deuxième langue. Et 24 billets, c’est peu. Le module 4 note les réponses en les lisant avec une grille. Il montre aussi comment distinguer une vraie différence du hasard. Il a noté l’essai principal du cours avec Gemma 3 4B, qui utilise Q4_K_M. La copie Q8_0 n’a pas de notes selon la grille. Cette comparaison repose donc sur les étiquettes et sur la lecture des réponses en français par Camille.

Le matériel : le modèle tiendra-t-il en mémoire?

Pour prendre une décision, un calcul répond à la plupart des questions sur le matériel. La mémoire nécessaire à un modèle correspond environ à :

• ses poids : le nombre de paramètres (les poids) × les bits par poids ÷ 8, en octets;
• plus le contexte : la mémoire réservée pour la fenêtre (le graphique ci-dessus);
• plus de la place pour le système d’exploitation et les autres programmes sur la machine.

Essayez avec Mistral 7B : 7,2 milliards de paramètres à environ 4,9 bits par poids (Q4_K_M) donnent 7,2 × 4,9 ÷ 8 ≈ 4,4 Go. Son fichier fait 4.4 Go. Il utilisait 4.9 Go de mémoire avec une fenêtre de 4 096 jetons. Un modèle de 70 milliards de paramètres avec le même nombre de bits nécessite environ 70 × 4,9 ÷ 8 ≈ 43 Go pour les poids seuls. Il ne tient pas dans 16 Go. Sur une machine de 16 Go, le choix réaliste est un modèle quantifié d’environ 4 à 8 milliards de paramètres.

Si un modèle ne tient pas dans la mémoire du processeur graphique, Ollama en exécute une partie sur le processeur principal. C’est plus lent. La colonne PROCESSOR (processeur) de ollama ps l’indique. Sur le Mac mini, tous les modèles de cette leçon affichaient 100% GPU (entièrement sur le processeur graphique). Quand toute la machine manque de mémoire, l’ordinateur déplace des données vers le disque, et tout ralentit. C’est pourquoi le chargement à froid a pris plusieurs minutes pendant le test d’Amira.

Quand chaque compromis compte

• La latence compte quand une personne attend. Le débit compte quand le volume est élevé.
• La taille du contexte et la quantification comptent pour la mémoire sur votre propre machine. Mesurez la qualité sur vos propres billets avant de choisir une copie plus petite.
• Le matériel fixe la limite supérieure : calculez la mémoire avant d’acheter ou de télécharger.
• Avec une API hébergée, le fournisseur gère la plupart de ces questions. Vous voyez seulement la latence, les limites de débit et le prix.

À vous d’essayer : mesurer votre propre modèle (facultatif)

Faites cet exercice seulement si vous avez Ollama et le modèle gemma3:4b. Consultez l’encadré « À vous d’essayer » de Modèle hébergé ou autohébergé. Testé avec Ollama 0.40.1 sur macOS.

1. Ouvrez un terminal.
2. Exécutez une requête et demandez les durées : ollama run gemma3:4b --verbose "Write one sentence about garden hoses."
3. Lisez les lignes sous la réponse. load duration (durée de chargement) indique le chargement, prompt eval rate (vitesse de lecture de la requête) indique la vitesse de lecture et eval rate (vitesse d’écriture) indique la vitesse d’écriture.
4. Exécutez la même commande à nouveau. La durée de chargement est maintenant presque nulle : le modèle est à chaud.

Vos vitesses dépendent de votre ordinateur. Comparez-les aux chiffres de cette leçon.

Erreur courante

Un banc d'essai a mesuré la mauvaise chose

Symptôme : Tomás chronomètre une requête pour chaque modèle local et rapporte : « Gemma 3 4B a pris presque six minutes pour un billet. Il est beaucoup trop lent pour nos agents. »

Cause : sa seule requête était à froid, sur un ordinateur occupé. Le chargement seul a pris 342 secondes, parce que d’autres programmes avaient rempli la mémoire. Sur un ordinateur peu occupé, le même chargement prenait environ 6.5 secondes, et une requête à chaud, 4.0 secondes. Une seule mesure masque aussi les variations de durée entre les essais.

Solution : envoyez d’abord une requête pour mettre le modèle à chaud, sans la compter. Mesurez ensuite plusieurs billets et présentez la médiane. Présentez le temps à froid séparément, avec l’état de la machine (autres programmes, mémoire libre). Indiquez toujours la durée mesurée : premier jeton ou temps total.

Conséquence pour le travail en IA : des chiffres de vitesse sans leurs conditions sont trompeurs. Un chiffre publié de « jetons par seconde » ne dit rien sur la longueur de votre requête ou de votre réponse. Il ne dit rien non plus sur votre matériel ou un démarrage à froid. Mesurez votre propre tâche, de la même façon pour chaque modèle candidat.

Vérification des connaissances

Vérifiez votre compréhension

L'application de soutien de Larkfield affiche le brouillon seulement après avoir reçu tout l'objet JSON. Quelle latence Amira doit-elle rapporter : le temps jusqu'au premier jeton ou le temps total? Quand l'autre mesure serait-elle utile?

Afficher la réponse

Le temps total : l’application ne peut rien faire avec un objet JSON incomplet. L’agent attend donc le dernier jeton. Le temps jusqu’au premier jeton compte quand une application affiche les mots à mesure qu’ils arrivent, comme une fenêtre de clavardage. L’utilisateur voit alors la réponse commencer rapidement.

Vérifiez votre compréhension

Prédisez : Grace ajoute une longue section à la politique de soutien. Chaque requête passe donc d'environ 600 à environ 1 800 jetons. Les réponses gardent la même longueur. Qu'arrive-t-il au temps de lecture et au temps total d'une requête à chaud sur le Mac mini?

Afficher la réponse

Le temps de lecture triple environ : 1 800 jetons à environ 438 jetons par seconde donnent environ 4.1 s plutôt qu’environ 1.4 s. Le temps d’écriture reste à peu près le même, car la réponse garde la même longueur. Le total augmente donc d’environ 2.7 s, passant d’environ 3.9 s à environ 6.7 s. La fenêtre de 4 096 jetons reste assez grande. Avec une API hébergée, la requête plus longue coûte aussi trois fois plus en jetons d’entrée.

Exercice du module

Cet exercice réunit les trois leçons : qui fait fonctionner le modèle, ce que les conditions permettent, et le coût en temps et en mémoire.

Exercice guidé : deux options, un budget, une règle de confidentialité

Grace fixe les conditions pour l’assistant de soutien. Tous les nombres ci-dessous sont fictifs, créés pour cet exercice.

• Budget : au plus 60 $ par mois, tout compris. Le temps du personnel coûte 40 $ l’heure.
• Règle de confidentialité : un billet peut quitter Larkfield seulement pour un fournisseur qui ne l’utilise pas pour l’entraînement et le supprime dans les 30 jours.
• Volume : 1 400 billets par mois; au plus 100 durant l’heure la plus occupée.
• Vitesse : le brouillon est prêt en moins de 10 secondes (temps total, à chaud).

	Option A : « Northwind API » (hébergée)	Option B : « Desk server » (poids ouverts)
Prix	1 $ par million de jetons d’entrée, 5 $ par million de jetons de sortie	Mini PC de 32 Go, 1 200 $, utilisé pendant 24 mois; électricité : 4 $ par mois
Jetons par billet	800 en entrée, 150 en sortie	aucun prix par jeton
Temps du personnel	1 heure par mois (clé API, facture, vérifications)	4 heures par mois (mises à jour, redémarrages, vérifications)
Temps total par billet	médiane de 2,5 s	6 s à chaud; 40 s après un redémarrage
Conditions	N’utilise pas les données de l’API pour l’entraînement; supprime les entrées et sorties dans les 30 jours; traite les données aux États-Unis	Aucun fournisseur; le billet reste sur la machine de Larkfield
Mémoire	responsabilité du fournisseur	un modèle 7B, Q4_K_M : environ 4,4 Go, plus le contexte

1. Calculez le coût d’un billet avec l’option A.
2. Calculez le coût mensuel de l’option A, temps du personnel compris.
3. Calculez le coût mensuel de l’option B, temps du personnel compris.
4. Vérifiez chaque option selon la règle de confidentialité.
5. Vérifiez chaque option selon la vitesse et le volume.
6. Vérifiez que la mémoire de l’option B peut contenir son modèle.
7. Écrivez deux phrases pour Grace : quelle option respecte toutes les conditions, et ce qui reste inconnu.

Afficher un exemple de réponse

1. 800 × 1 $ ÷ 1 000 000 + 150 × 5 $ ÷ 1 000 000 = 0,0008 $ + 0,00075 $ = 0,00155 $ par billet.
2. 1 400 × 0,00155 $ = 2,17 $ pour les jetons, plus 1 heure × 40 $ = 42,17 $ par mois. Le coût respecte le budget de 60 $.
3. 1 200 $ ÷ 24 = 50 $ pour la machine, 4 $ pour l’électricité, 4 heures × 40 $ = 160 $ de temps du personnel : 214 $ par mois. Le coût dépasse le budget.
4. Option A : elle n’utilise pas les billets pour l’entraînement et les supprime dans les 30 jours. Elle respecte donc la règle. La règle ne précise aucune région; sinon, « traite les données aux États-Unis » pourrait la rendre non conforme. Option B : rien ne quitte Larkfield, donc elle respecte la règle.
5. Option A : 2,5 s respecte la limite de 10 s; le fournisseur traite 100 billets par heure (vérifiez la limite de débit du compte). Option B : 6 s à chaud respecte la limite de 10 s. Une machine termine 3 600 ÷ 6 = 600 billets par heure, soit plus de 100. Après un redémarrage, le premier billet prend 40 s : gardez le modèle chargé.
6. Environ 4,4 Go de poids plus le contexte, dans 32 Go : il y a largement assez de mémoire.

Note pour Grace : « L’option A respecte le budget, la règle de confidentialité, la vitesse et le volume, à environ 42 $ par mois. L’option B respecte toutes les conditions sauf le budget : elle coûte environ 214 $ par mois, surtout en temps du personnel. Nous ne savons pas encore si l’un ou l’autre modèle rédige de bonnes réponses à nos billets. Le module 4 mesure cela. »

Votre tâche : la règle de confidentialité change

L’avocat de Larkfield relit la règle de confidentialité et la rend plus stricte : aucun billet ne peut quitter les ordinateurs de Larkfield. Tout le reste demeure inchangé. Vérifiez de nouveau les deux options. Écrivez ensuite trois ou quatre phrases pour Grace : ce que vous recommandez et ce qu’elle doit décider.

Afficher un exemple de réponse

L’option A ne respecte plus la règle de confidentialité : chaque billet va au fournisseur, peu importe ses conditions. L’option B est la seule qui respecte la règle. Mais elle coûte environ 214 $ par mois, pour un budget de 60 $. Aucune option ne respecte donc toutes les conditions, et la réponse honnête consiste à le dire. Grace doit choisir. Elle peut augmenter le budget à environ 215 $ par mois. Ou elle peut réduire le coût de l’option B, par exemple avec une machine que l’équipe entretient déjà. Cela réduirait le temps du personnel nécessaire. L’option la moins chère, A, n’est plus un choix possible, car une exigence obligatoire passe avant le prix.

Vérification du module

Vérifiez votre compréhension

Rappel : en une phrase chacune, que sont la latence, le débit et la quantification?

Afficher la réponse

La latence est le temps d’attente d’une personne ou d’un programme pour une réponse, jusqu’au premier ou au dernier jeton. Le débit est la quantité de travail qu’un système termine par unité de temps, comme le nombre de billets par heure. La quantification stocke chaque poids d’un modèle avec moins de bits. Le modèle utilise ainsi moins d’espace disque et de mémoire, généralement avec une petite perte de qualité.

Vérifiez votre compréhension

Prédisez, puis vérifiez dans cette leçon : Larkfield remplace Gemma 3 4B Q4_K_M par Q8_0 sur le Mac mini. Qu'arrive-t-il à la mémoire, à la vitesse d'écriture et à la qualité sur les 24 billets?

Afficher la réponse

Mémoire : davantage. Le fichier Q8_0 fait 5.0 Go plutôt que 3.3 Go. Il a utilisé 4.5 Go de mémoire plutôt que 2.9 Go. Il tient encore dans 16 Go. Vitesse d’écriture : plus lente, environ 23 plutôt que 37 jetons par seconde, car chaque jeton nécessite la lecture de plus d’octets. Qualité : sur les 24 billets, les étiquettes étaient presque identiques. Mais Q8_0 n’est jamais passé du français à l’anglais; Q4_K_M l’a fait dans 4 des 11 réponses en français. Le compromis oppose la mémoire et la vitesse à la qualité en français. Seul un test sur vos propres billets le révèle.

Vérifiez votre compréhension

Complétez : Gemini 3.5 Flash est offert avec le quota gratuit et avec l'API Gemini payante. Tomás dit : « C'est le même modèle, donc notre règle de confidentialité donne la même réponse pour les deux. » Expliquez pourquoi il a tort, en distinguant les capacités d'un modèle des conditions de service d'un fournisseur.

Afficher la réponse

Les capacités d’un modèle sont ce qu’il peut faire : ses réponses aux billets de Larkfield, sa vitesse, ses langues. Avec le quota gratuit et l’API payante, elles sont identiques, car c’est le même modèle. Les conditions de service décrivent ce que le fournisseur fait des données que vous envoyez. Elles appartiennent au service, pas au modèle. Les conditions de l’API Gemini (dernière mise à jour le 28 avril 2026) précisent ceci. Avec le quota gratuit, Google utilise le contenu pour améliorer ses produits, et des réviseurs humains peuvent le lire. Avec le service payant, Google n’utilise pas les requêtes pour améliorer ses produits. Le même modèle peut donc respecter la règle de confidentialité de Larkfield sur un service, mais pas sur l’autre. Les preuves sur les capacités (un test) et celles sur les conditions (les pages du fournisseur) répondent à des questions différentes. Une décision exige les deux.

Fin du module 3

Revenir à un état connu

Ce module ne modifie aucun fichier. Si vous avez téléchargé des modèles dans un encadré « Essayez » et voulez récupérer l’espace disque :

1. Ouvrez un terminal.
2. Listez les modèles : ollama list
3. Supprimez chaque modèle dont vous n’avez plus besoin, par exemple : ollama rm gemma3:4b

Récapitulatif

• La latence a deux formes : le temps jusqu’au premier jeton et le temps total. Mesurez les requêtes à chaud et rapportez séparément le démarrage à froid. Une requête à chaud à Gemma 3 4B a pris environ 4.0 s : lecture à environ 438 jetons par seconde, écriture à environ 37.
• Le débit mesure le travail par heure. Une machine à 5 s par billet termine environ 720 billets par heure, bien plus que les besoins de Larkfield.
• Une fenêtre de contexte plus grande réserve plus de mémoire sur votre propre machine. Choisissez sa taille selon vos requêtes réelles.
• La quantification stocke les poids avec moins de bits. Gemma 3 4B en Q4_K_M a utilisé 2.9 Go et écrit 37 jetons par seconde; en Q8_0, 4.5 Go et 23. Mais Q8_0 a gardé toutes les réponses françaises en français; Q4_K_M ne l’a pas fait.
• Le module 3 en bref : décidez qui fait fonctionner le modèle, puis lisez la licence et les conditions d’utilisation des données. Vérifiez ensuite que le matériel, la vitesse et le budget conviennent. Les exigences obligatoires passent en premier; la qualité vient ensuite, au module 4.

Le module 4 crée ensuite le jeu de test qui mesure la qualité.

Leçon suivante : Créer un jeu de test représentatif