TyKaoz, l'application macOS que je développe, transforme un dossier de documents en wiki : un modèle lit chaque source, puis crée ou complète des pages (une par personne, entreprise ou projet) à l'aide d'outils d'écriture. On interroge ensuite ce wiki, et chaque réponse cite les pages d'où elle vient. Tout peut tourner sur le Mac, en MLX.
La question qu'on me pose le plus souvent est simple : j'ai un Mac de 16 Go (ou 24, ou 36), quel modèle dois-je prendre ? Plutôt que de répondre au jugé, j'ai construit un banc d'essai et j'ai fait passer les modèles un par un.
Les limites, d'abord
Ces chiffres valent pour un corpus : 32 documents en français, sur une entreprise fictive. Chaque modèle a fait une exécution par ordre de lecture des sources ; les verdicts viennent d'un juge LLM ; les réponses portent sur 40 questions, et sur 40 questions un écart de quelques points relève du bruit (l'intervalle de confiance à 95 % fait environ ±15 points). Les vitesses ont été mesurées sur une seule machine, un M3 Pro de 36 Go. Lisez ce qui suit comme un ordre de grandeur pour un usage documentaire en français, pas comme un classement général des modèles.
Le banc d'essai
Le corpus raconte la vie d'une PME bretonne fictive de l'énergie marine : comptes rendus, articles de presse, courriels et rapports, sur plusieurs années. Il contient 23 entités à retrouver, 110 faits de référence, et dix pièges : cinq contradictions entre sources (deux documents donnent deux valeurs différentes) et cinq remplacements (une information en remplace une plus ancienne : un départ, un nouvel effectif). Un modèle qui construit un wiki fiable doit signaler les premières et mettre à jour les secondes, sans perdre le reste.
Deux épreuves :
- L'ingestion : le modèle lit les 32 sources une à une et écrit le wiki. On mesure le rappel des entités, la perte de faits (un fait présent à un moment qui a disparu à la fin), les contradictions signalées, les remplacements faits, et la sensibilité à l'ordre : on refait l'ingestion dans l'ordre inverse, puis on compte les faits qui diffèrent entre les deux wikis.
- Les réponses : on fige un wiki, celui construit par le meilleur modèle, et chaque candidat répond à 40 questions de six types : simples, à plusieurs étapes, de synthèse, de dates, sur une contradiction, et sans réponse dans le wiki (où il faut le dire plutôt qu'inventer). Quarante autres questions restent de côté pour le rapport final, sans avoir servi à régler quoi que ce soit.
Le juge est Mistral Small 4 en NVFP4, servi par vLLM sur mon DGX Spark (le montage de cet article, dont j'ai mesuré la qualité ici). Avant de lui faire confiance, j'ai annoté moi-même 30 verdicts de chaque épreuve : il est d'accord avec moi sur 28 des 30 faits, et sur les 30 réponses. Quand il dit qu'un fait est présent, il doit citer mot pour mot le passage du wiki qui le montre, et la citation est vérifiée.
Mon propre outil de mesure se trompait
Un premier passage donnait des pertes de faits de 6 à 12 % chez tous les modèles, y compris les meilleurs. En relisant les cas un par un, j'ai trouvé que plus de la moitié de ces pertes venaient du correcteur, pas des modèles :
- un verdict positif dont la citation était mal recopiée (deux passages collés, un titre gardé entre crochets) devenait négatif ;
- les extraits soumis au juge ignoraient le titre de la page : sur la page d'une personne, le paragraphe qui décrit son rôle sans répéter son nom n'était jamais montré ;
- la normalisation du texte supprimait les caractères non ASCII, si bien qu'un tiret insécable soudait deux mots et que la citation devenait introuvable ;
- deux faits de référence étaient tronqués au caractère
#, que YAML lit comme un commentaire.
Une fois ces défauts corrigés, les pertes des meilleurs modèles tombent à 0 ou 1 %. Deux pièges étaient aussi mal posés et ont été réécrits. Le calibrage du juge n'a pas bougé. Si vous évaluez des modèles avec un juge LLM, relisez vos échecs à la main : les miens disaient autant de choses sur mon code que sur les modèles.
L'ingestion : aucun modèle local ne passe
Les seuils sont ceux que je me suis fixés pour un wiki digne de confiance. « Ordre » est la part des faits qui diffèrent entre les deux ordres de lecture.
| Modèle | Rappel | Perte | Contradictions | Remplacements | Ordre |
|---|---|---|---|---|---|
| Seuil | ≥ 85 % | ≤ 2 % | ≥ 4/5 | ≥ 4/5 | ≤ 5 % |
| Mistral Small 3.2 4‑bit Mac, 13 Go | 83 % | 2 % | 2/5 | 4/5 | 26 % |
| Gemma 4 26B 4‑bit Mac, 14 Go | 61 % | 0 % | 1/5 | 1/5 | 23 % |
| Mistral Small 3.2 6‑bit Mac, 18 Go | 52 % | 5 % | 1/5 | 3/5 | 30 % |
| Qwen 3.6 35B 4‑bit Mac, 20 Go | 83 % | 6 % | 2/5 | 3/5 | 23 % |
| Gemma 4 26B 8‑bit Mac, 26 Go | 91 % | 0 % | 1/5 | 1/5 | 26 % |
| Mistral Small 4 Suisse | 78 % | 5 % | 2/5 | 2/5 | 43 % |
| gpt‑oss‑120b France | 87 % | 1 % | 3/5 | 2/5 | 11 % |
| Qwen 3.5 397B France | 87 % | 0 % | 5/5 | 5/5 | 4 % |
La mémoire indiquée est le pic mesuré pendant l'ingestion. Les modèles « Suisse » et « France » sont hébergés chez des fournisseurs européens. Comme référence hors concours, Claude obtient 83 % de rappel, 0 % de perte, 4/5 et 4/5.
Seul Qwen 3.5 397B franchit tous les seuils. Les modèles locaux couvrent les faits correctement (Gemma 26B en 8-bit retrouve même plus d'entités que lui), mais ils échouent là où un wiki se distingue d'un tas de notes : ils signalent rarement les contradictions, appliquent rarement les remplacements, et un quart de leurs faits change selon l'ordre de lecture des documents. Votre wiki dirait autre chose si vous aviez déposé vos fichiers dans un autre ordre.
Mistral Small 3.2 en 4-bit est le local le plus proche du but. Dans 13 Go, il retrouve autant d'entités que Qwen 3.6, perd peu de faits et applique quatre remplacements sur cinq, au seuil. Mais il ne signale que deux contradictions, et un quart de ses faits dépend encore de l'ordre de lecture.
La quantification pèse lourd : Gemma 26B passe de 61 % à 91 % de rappel entre 4 et 8 bits. Elle ne change rien, en revanche, au traitement des contradictions. Et plus de bits n'aide pas toujours : Mistral Small 3.2 fait moins bien en 6 bits qu'en 4 sur toutes les mesures. Il écrit moins (162 écritures tentées contre 277) et laisse près de la moitié des entités sans page. Sur une seule exécution, une partie de cet écart peut tenir au hasard ; le sens, lui, est net.
Côté vitesse, sur le M3 Pro, Gemma 26B ingère une source en moins de deux minutes, Qwen 3.6 en sept, parce qu'il raisonne longuement avant d'écrire, et Mistral Small 3.2 en huit à neuf. Parmi les modèles hébergés, gpt-oss-120b couvre presque aussi bien que Qwen 3.5 397B pour environ quatre fois moins cher, mais ne vérifie pas les contradictions.
Les réponses : un Mac de 48 Go suffit
L'ingestion se fait une fois par document. Les questions, elles, reviennent tous les jours. Si le wiki est construit par un grand modèle, quel modèle local peut l'interroger ? Ici, tous répondent sur le même wiki, celui de Qwen 3.5 397B.
| Palier | Modèle | Pic mémoire | Réponses justes | Durée par question |
|---|---|---|---|---|
| 8 Go | Gemma 4 E4B 4‑bit | 4,4 Go | 32 % | 9 s |
| 16 Go | Gemma 4 E4B 8‑bit | 7,8 Go | 25 % | 8 s |
| 24 Go | Gemma 4 26B 4‑bit | 14,4 Go | 48 % | 22 s |
| 24 Go | Mistral Small 3.2 4‑bit | 12,8 Go | 45 % | 37 s |
| 32 Go | Qwen 3.6 35B 4‑bit | 19,6 Go | 60 % | 57 s |
| 48 Go | Gemma 4 26B 8‑bit | 26,1 Go | 75 % | 22 s |
Le palier est la plus petite configuration de Mac où le pic mesuré laisse assez de place au système et aux autres applications. Tous ces modèles ont tourné sur la même machine de 36 Go : la qualité ne dépend pas de la machine, la vitesse si.
Gemma 4 26B en 8-bit répond juste à toutes les questions simples (10 sur 10) et à toutes les questions sur une contradiction (3 sur 3), avec un peu plus de difficulté sur les dates (5 sur 6). Il faiblit sur les questions à plusieurs étapes et de synthèse (4 sur 7 chacune), où il manque souvent un élément de la réponse attendue, et sur les questions sans réponse (4 sur 7), où il comble parfois le vide au lieu de dire qu'il ne sait pas.
Qwen 3.6 fait moins bien et plus lentement : il raisonne longtemps avant chaque réponse. Sous 24 Go, un tiers de réponses justes ne suffit pas à fonder une décision sur le wiki. L'écart entre les deux variantes de Gemma E4B, en revanche, tient dans le bruit.
Sur 24 Go, Mistral Small 3.2 et Gemma 26B se valent : trois points d'écart, c'est du bruit. Mistral cite presque toujours une page qu'on lui a vraiment montrée (29 fois sur 30), mais il échoue aux trois questions sur une contradiction : il donne une seule valeur là où le wiki en porte deux.
Avant d'accuser le modèle
Avant la nuit complète, chaque modèle passe un pré-filtre : l'ingestion des neuf premières sources. Mistral Small 3.2 y a d'abord obtenu 0 %. Il n'avait écrit aucune page, parce que le modèle de conversation fourni avec sa conversion MLX décrivait les appels d'outils dans un format antérieur à celui que le modèle a appris. Ses appels n'étaient jamais reconnus. Une fois le gabarit réécrit au bon format, il retrouve trois quarts des faits ou plus au même stade (74 à 83 % selon les exécutions).
Sa première nuit complète a révélé un second défaut, cette fois dans TyKaoz. Mistral termine ses lignes par deux espaces, le saut de ligne de Markdown, y compris la ligne --- qui ouvre l'en-tête d'une page. Il lui arrive aussi d'écrire le premier champ sur cette même ligne, voire l'en-tête entier. L'application ne reconnaissait pas ces variantes : la page perdait son titre, et l'écriture était refusée. Trois correctifs plus tard, son rappel passe de 70 % à 83 %, et la part des faits qui dépend de l'ordre de lecture de 40 % à 26 %. Le banc devait évaluer des modèles ; il a aussi trouvé des bugs dans mon application.
Apertus 8B, lui, n'écrit toujours aucune page, mais pour une autre raison. Il appelle bien ses outils, mais il encode mal une page de plusieurs lignes dans leurs arguments : les retours à la ligne disparaissent, l'en-tête de la page devient illisible, et chaque écriture est refusée. Là, c'est une limite du modèle.
MiMo-7B-RL, candidat pour les Mac de 8 Go, s'arrête aussi au pré-filtre, avec 22 % des faits. C'est un modèle de raisonnement, et il raisonne si longtemps qu'il atteint la limite de 4 096 jetons d'un tour avant d'avoir appelé un outil : cinq sources sur neuf n'ont produit aucune page, et les pages écrites contiennent des textes à compléter au lieu des faits.
Avant de conclure qu'un modèle est faible sur une tâche à outils, vérifiez qu'il reçoit les outils dans le format qu'il connaît, et que votre code lit bien ce qu'il écrit.
Ce qu'il faut en retenir
- Pour construire le wiki, aucun modèle qui tient sur un Mac de 48 Go ne suffit : il faut un grand modèle. Dans ce banc, seul Qwen 3.5 397B y parvient. gpt-oss-120b est une option économique si l'on accepte de vérifier soi-même les contradictions.
- Pour l'interroger, un Mac de 48 Go avec Gemma 4 26B en 8-bit donne trois réponses justes sur quatre, en une vingtaine de secondes, sans qu'aucune question ne quitte la machine.
- Sur 24 et 32 Go, c'est utilisable avec prudence : une réponse juste sur deux, en vérifiant les sources citées. Sur 24 Go, Mistral Small 3.2 en 4-bit et Gemma 4 26B en 4-bit répondent aussi bien l'un que l'autre ; Mistral construit un meilleur wiki, mais quatre fois plus lentement.
- Sur 8 et 16 Go, le wiki local n'est pas fiable aujourd'hui, et MiMo-7B-RL n'y change rien. Ces modèles restent utiles pour converser, pas pour fonder une décision sur vos documents.
Il manque encore deux mesures. Mistral Small 3.2 en 8-bit passe le pré-filtre, mais sur mon Mac de 36 Go sa nuit complète bute sur la mémoire : des heures sur une seule source, jusqu'à la limite de dix heures, avec un swap presque plein. Il faudra le mesurer sur un vrai Mac de 48 Go. Reste aussi le palier 128 Go sur le DGX Spark, avec gpt-oss-120b servi en local. Je mettrai cet article à jour avec leurs chiffres.