Faire tourner un modèle de langage en local : ce qu'il faut mesurer avant d'acheter la machine
Avant de choisir entre un modèle de 32 et de 72 milliards de paramètres, il faut savoir quoi mesurer. Voici le protocole que nous appliquons et les ordres de grandeur à vérifier sur votre propre matériel.
Le choix d'un modèle local ne se décide pas sur un classement public, mais sur trois mesures faites chez vous : la mémoire réellement consommée, le délai avant le premier mot affiché, et la qualité des réponses sur vos propres documents. Un modèle plus gros qui déborde de la mémoire est plus lent qu'un modèle plus petit qui y tient.
Pourquoi les classements publics ne suffisent pas ?
Ils mesurent des capacités générales sur des jeux de tests standardisés. Votre besoin est particulier : répondre à des questions de gestion en français, sur vos documents, avec un temps de réponse acceptable pour un utilisateur qui attend devant son écran.
Un modèle qui domine un classement peut très bien être inutilisable chez vous parce qu'il ne tient pas en mémoire.
Quelle est la contrainte qui décide de tout ?
La mémoire. Un modèle doit être chargé intégralement pour fonctionner à vitesse normale. S'il n'y tient pas, le système compense sur le disque et les performances s'effondrent — pas de quelques pourcents, mais d'un ordre de grandeur.
La compression du modèle, appelée quantification, réduit la place occupée en abaissant la précision des poids. Une compression sur quatre bits divise l'empreinte par environ quatre par rapport au format d'origine, au prix d'une dégradation faible sur la plupart des usages métier.
Ordre de grandeur à vérifier vous-même : comptez environ un demi-gigaoctet de mémoire par milliard de paramètres en compression quatre bits, plus la mémoire nécessaire au contexte. Un modèle de 32 milliards de paramètres se loge donc sur une machine bien équipée ; un modèle de 72 milliards demande une configuration nettement plus généreuse.
Que faut-il mesurer, exactement ?
| Mesure | Comment | Pourquoi |
|---|---|---|
| Mémoire occupée | Relevé pendant une génération longue | Détermine si le modèle tient |
| Délai avant le premier mot | Chronomètre du départ à l'affichage | C'est ce que l'utilisateur ressent |
| Vitesse de génération | Mots produits par seconde | Confort de lecture en continu |
| Qualité métier | Jeu de 30 questions réelles, notées à l'aveugle | Seul critère qui compte vraiment |
| Comportement à plusieurs | Trois requêtes simultanées | Révèle l'effondrement en usage réel |
Comment construire le jeu de test ?
Prenez trente questions que vos équipes posent réellement, avec leurs réponses attendues. Faites-les passer à chaque modèle candidat, et faites noter les réponses par quelqu'un qui ignore quel modèle a produit laquelle.
C'est fastidieux, et c'est la seule méthode qui vous évitera d'acheter une machine pour un modèle que vos utilisateurs n'accepteront pas.
Faut-il toujours prendre le plus gros modèle possible ?
Non. Sur des questions de gestion structurées, l'écart de qualité entre un modèle moyen et un très gros modèle est souvent plus faible que l'écart de confort dû au temps de réponse.
Notre règle : le plus gros modèle qui tient confortablement en mémoire avec de la marge pour le contexte, jamais celui qui la sature.
Mis à jour le 11 août 2026