Pourquoi ce sujet est important
Un grand modèle est polyvalent, mais cette polyvalence coûte en latence, tokens et infrastructure. Pour une tâche étroite avec un format clair, un modèle de 1 à 8 milliards de paramètres peut offrir un meilleur compromis et fonctionner sur du matériel accessible.
Reconnaître les bonnes tâches
Classification, extraction, reformulation, routage, modération spécialisée et réponses RAG très contraintes sont de bons candidats. Les tâches ouvertes, le raisonnement long, le code complexe et les instructions ambiguës favorisent souvent un modèle plus puissant.
Mesurer plutôt que supposer
Construisez un jeu de cas réel et comparez petit modèle, grand modèle et baseline déterministe. Mesurez qualité, taux JSON valide, latence, mémoire et coût par réussite. Analysez les erreurs graves, pas seulement la moyenne.
Utiliser le contexte et les outils
Un petit modèle peut réussir si le système réduit la difficulté : retrieval précis, schéma de sortie, exemples, règles et outils déterministes. Ne lui demandez pas de mémoriser toute la connaissance métier ou d’autoriser une action.
Quantification et matériel
La quantification réduit mémoire et peut accélérer l’inférence, avec une perte éventuelle. Benchmarkez la version exacte sur CPU, GPU ou appareil cible. Mesurez temps au premier token, débit, consommation et concurrence.
Fine-tuning avec prudence
Un ajustement peut améliorer format, ton ou classification, mais ne corrige pas des données médiocres. Commencez par prompting et évaluation. Conservez un jeu de test séparé et vérifiez les régressions générales après entraînement.
Router entre petit et grand
Traitez les cas simples avec le SLM et escaladez les demandes ambiguës ou critiques. Le routeur peut être une règle, un classifieur ou un score calibré. Mesurez le coût des erreurs de routage et prévoyez un fallback.
Sécurité et edge
Un modèle local limite certains transferts mais n’annule pas les risques : logs, données sur l’appareil, extraction des poids et actions restent à protéger. Définissez mises à jour, révocation et télémétrie minimale.
Exemple concret
Une application extrait quatre champs de factures. Un modèle 3B quantifié atteint le seuil sur 97 % des documents et renvoie les cas invalides à un modèle plus grand. Le coût diminue, la latence est stable et les données restent dans l’infrastructure, sans prétendre traiter les factures ambiguës.
Les erreurs fréquentes
- choisir uniquement selon le nombre de paramètres
- tester sur dix exemples simples
- demander au petit modèle une tâche trop ouverte
- quantifier sans mesurer la qualité
- fine-tuner avant d’avoir une baseline
- ne pas prévoir d’escalade
Checklist
- [ ] Tâche étroite définie
- [ ] Grand modèle et règles comparés
- [ ] Erreurs critiques pondérées
- [ ] Matériel cible benchmarké
- [ ] Quantification évaluée
- [ ] Sorties structurées validées
- [ ] Routeur et fallback testés
FAQ
1 à 8B désigne-t-il toujours un petit modèle ?
C’est un ordre de grandeur courant, mais le matériel, l’architecture et l’usage déterminent le caractère “petit”.
Un SLM peut-il faire du RAG ?
Oui si le retrieval fournit un contexte précis et si la réponse attendue est suffisamment contrainte.
Faut-il fine-tuner ?
Pas systématiquement. Commencez par prompt, exemples et validation structurée.
Comment savoir quand escalader ?
Utilisez règles et signaux calibrés sur un jeu de cas, pas la confiance verbale du modèle seule.