Choisir le bon modèle

Choisir un modèle est une fonction de trois entrées : votre budget mémoire, votre cas d'usage et votre plancher de qualité. Les benchmarks n'informent que la troisième ; les deux premières sont de l'arithmétique. Optimiser l'une en ignorant les autres, c'est ainsi qu'on finit avec un modèle qui brille aux benchmarks et ne sait pas faire la vraie tâche du mardi.

Les trois entrées

1. Budget — VRAM sur GPU, mémoire unifiée sur Apple Silicon. Règle empirique : poids en Q4_K_M ≈ 0.6 GB par milliard de paramètres, puis ajoutez cache KV et frais généraux — la méthode complète est le calcul de VRAM.
2. Cas d'usage — ce que le modèle doit faire quotidiennement ; détail ci-dessous.
3. Plancher de qualité — le niveau sous lequel la sortie ne vous sert à rien. Un compagnon d'écriture tolère plus de slop qu'un générateur de code dont la sortie doit compiler.

Le budget plafonne aussi le contexte : un plan à contexte géant sur une petite carte signifie juste échanger la pression du cache KV contre la qualité des poids. Tout se monnaie.

Exemple détaillé, GPU 16 GB → ~13.5 GB utilisables après la part de l'OS : un 14B en Q4_K_M (~8.5 GB de poids) avec du contexte généreux, ou un 8B en Q6_K (~6.6 GB) avec un contexte énorme. Les deux tiennent ; le cas d'usage tranche.

Partez du cas d'usage

• Chat général et écriture — un instruct de taille moyenne (classe 8–14B) en Q5–Q6 couvre la plupart des gens. Au-delà de ce palier, la préférence de style compte plus que les points de benchmark.
• Assistant de code — privilégiez les lignées codeuses fortes (Qwen Coder, descendants de DeepSeek-Coder) et gardez le contexte long : la valeur, c'est compléter en milieu de fichier avec le contexte du dépôt autour. Le vrai code punit aussi les quants bâclés plus tôt que le chat.
• Documents longs — vérifiez que le contexte revendiqué est un contexte utilisable. Beaucoup de modèles « 128k » écoutent bien le début et la fin et réduisent le milieu en bouillie. Testez avant de faire confiance ; voir le protocole ci-dessous.
• Coréen / multilingue — Qwen d'abord, Gemma ensuite. Les deux gèrent le coréen honorablement ; les familles anglophones d'abord montrent des fissures en grammaire et niveaux de politesse. Détails dans familles de modèles.
• Travail à forte charge de raisonnement — préférez les checkpoints réglés raisonnement (mode thinking de Qwen3, R1-distill) ; ils échangent de la latence contre de l'exactitude en maths et planification, et la quantification leur fait plus mal — gardez le quant haut.
• Extraction en masse bon marché — un petit instruct (1.5–3B) avec sortie structurée bat un grand modèle à plusieurs fois le coût par document. Ne dépensez pas un 8B pour du travail en forme de regex.
• Agents et usage d'outils — l'exigence réelle est le suivi d'instructions et la discipline de format, pas le QI brut. En pratique, cela signifie classe ≥7–9B, plus si vous pouvez : un appel d'outil malformé peut démolir toute une chaîne. Voir agents.

Lire les benchmarks sans se faire avoir

Habitudes qui vous gardent honnête : préférez les delta relatifs sur le même harness aux chiffres absolus ; traitez les écarts sous 2 points comme du bruit ; méfiez-vous des affirmations sans protocole reproductible ; et lisez la discussion sur la contamination autour d'un benchmark, souvent plus informative que le classement lui-même.

La défense la moins chère est la triangulation : un modèle réellement bon le montre à travers des signaux indépendants — évals de labo, arène, fils communautaires et votre propre jeu de prompts. Quand les signaux divergent, fiez-vous aux plus proches de votre charge. Vos 20 prompts dominent tout classement à vos fins, parce qu'ils échantillonnent votre distribution réelle.

Le signal de la communauté locale

Les benchmarks tournent sur les prompts des labos. Votre meilleur signal, ce sont des gens exécutant le même fichier que vous allez télécharger :

• Tendances Hugging Face et comptes de téléchargement — popularité lente à bouger, coûteuse à manipuler durablement.
• Quelles livraisons les quantificateurs communautaires (bartowski, mradermacher) quantifient sur toute l'échelle — un filtre d'importance correct.
• Les fils r/LocalLLaMA — cherchez le nom du modèle, triez par récent ; les éloges et plaintes récurrentes sont réels. Appliquez « à ce jour » doublement ici : le consensus local a une demi-vie de semaines.
• Rapports spécifiques par quant — la qualité du modèle X en Q4 est une question différente du modèle X en FP16, et les deux diffèrent de ce que le labo a rapporté.

Matrice de recommandations

Points de départ à ce jour par palier VRAM, en supposant environ des quants Q4_K_M et un contexte modéré — recoupez le matériel dans paliers de GPU :

Traitez la matrice comme un point de départ de recherche, pas un évangile — le terrain se reclasse chaque trimestre. Le conseil stable dans chaque palier : préférez les générations récentes, et préférez plus gros-en-Q4 à plus petit-en-Q8 jusqu'au plancher Q4 (en dessous, les dégâts de quantification gagnent — voir quantification).

Une règle stable de plus : quand deux modèles sont à égalité, prenez la licence plus amicale. Apache-2.0 et MIT ne reviennent jamais vous mordre ; les licences communautaires parfois — voir poids ouverts vs API fermées.

Essayez avant de vous engager

30 minutes disciplinées battent une semaine de vibes :

1. Constituez un jeu fixe de 10–20 prompts — vos vrais cas les plus durs : un courriel coréen à réécrire, un diff buggé à corriger, un résumé de document avec un fait vérifiable enterré dedans.
2. Exécutez chaque candidat sur les mêmes prompts, mêmes réglages d'échantillonnage, même niveau de quant. Ne faites varier qu'une chose à la fois.
3. A/B à l'aveugle : mélangez les sorties et jugez sans savoir quel modèle a produit quoi. Un tableur et un ami font l'affaire ; votre modèle actuel le plus fort comme juge aussi.
4. Vérifiez le coréen spécifiquement : cohérence des niveaux de politesse (존댓말/반말), particules naturelles, pas de calques anglais. Les modèles qui « savent le coréen » écrivent souvent de l'anglais traduit déguisé en coréen.
5. Vérifiez le long contexte : enterrez un fait à 70% de profondeur dans un long collage et demandez-le. Ce seul test disqualifie plus de modèles « 128k » que n'importe quel classement.
6. Relancez les égalités à température 0 — le bruit d'échantillonnage se déguise en différences de modèle plus souvent que quiconque ne l'admet.

Le harnais peut tenir en quatre lignes de shell contre un llama-server lancé :

while IFS= read -r prompt; do
  curl -s http://localhost:8080/v1/chat/completions \
    -H 'Content-Type: application/json' \
    -d '{"messages":[{"role":"user","content":"'"$prompt"'"}],"temperature":0.7}' \
    >> out-model-a.jsonl
done < prompts.txt

Même boucle, un fichier de sortie par modèle ; puis lisez-les côte à côte étiquettes masquées.

Quand une API fermée gagne encore

Le local, c'est le contrôle, la confidentialité et le coût marginal à gros volume — pas la capacité frontière. À ce jour, les API fermées les plus fortes battent encore les poids ouverts les plus forts en raisonnement difficile et longues chaînes agentiques, avec zéro installation : pas de VRAM, pas de réglage moteur, pas de maths de quant.

Sur le coût, chiffres prudents : un 8B local en Q4 est effectivement gratuit par jeton une fois le matériel acquis ; une API frontière facture de l'ordre de quelques dollars par million de jetons. Au volume hobby, les deux s'arrondissent à zéro ; à des millions de jetons par jour, le local gagne rien que sur le prix. L'écart de capacité — pas le prix — est la raison honnête de garder une clé d'API sous la main.

Un schéma durable est l'hybride : modèle local par défaut, API pour les rares prompts qui le coincent. Pesez le compromis consciemment dans poids ouverts vs API fermées.

Voir aussi : paliers de GPU · familles de modèles · agents · poids ouverts vs API fermées