Le carnet de labo : ce qu'on a essayé sur l'infra, ce qu'on a gardé
Un homelab, c'est une suite d'expériences. La plupart des comptes rendus ne montrent que ce qui a marché. Voici le carnet entier : ce que nous avons essayé, la mesure qui a tranché, et ce que nous en avons fait. Chaque ligne renvoie au tutoriel complet quand il existe.
Comment ces chiffres ont été obtenus. Mesurés sur nos propres machines (voir le protocole), en général en un seul passage, vitesses relevées par le serveur lui-même ; nous ne publions pas les journaux bruts. Ce sont des ordres de grandeur sur ce matériel, pas des garanties sur le vôtre. Les chiffres extérieurs sont accompagnés de leur source.
Ce que vous y gagnez. Des mois d'essais et d'erreurs en une page. Avant d'essayer quelque chose, regardez s'il est ici : le chiffre qui a tranché pour nous peut trancher pour vous.
Gardé
| Essai | Le chiffre qui a tranché |
|---|---|
| Un modèle MoE de 177B sur deux cartes grand public (tutoriel) | 55,6 jetons/s, 2,1 fois plus vite une fois les poids bien placés |
| Décodage spéculatif, MTP (tutoriel) | 65,7 jetons/s pour un 27B sur une carte |
| KVMem pour les longs contextes d'agents (tutoriel) | 48/48 en rappel, plat au-delà de 100k jetons, −4,9 Go de VRAM |
| Un juge de 0,8B sur le processeur, puis un 9B (tutoriel) | 0,87 à 0,91 sur de vrais mails, 0,05 s par décision |
| Un classifieur d'intention entraîné plutôt qu'une recherche par mots-clés | 84,0 % contre 63,7 %, et 72,6 % pour « toujours la valeur par défaut » |
| Régénérer la description des périphériques GPU au démarrage (tutoriel) | la cause supprimée à la source, à chaque démarrage |
Rejeté
| Essai | Pourquoi |
|---|---|
| Compresser le cache V en q4_0 (tutoriel) | lecture du prompt 21 fois plus lente pour 1,8 Go gagnés |
| Charger les poids du modèle en résident plutôt qu'en projection mémoire | +3 % de vitesse, puis deux gels de la machine : 47,6 Go de RAM impossibles à libérer |
| Une calibration des probabilités meilleure sur le papier | 86,9 % au lieu de 84,0 %, mais elle ne prédisait plus jamais la classe « difficile » |
| Un second petit juge, aligné plutôt qu'entraîné | 0,42 à 0,55 sur les mêmes mails : supprimé |
| Demander à un agent, dans son prompt, de consulter le juge | il l'a fait 0 fois sur 3 ; le routage est passé dans le code |
En pause
| Essai | Où il s'est arrêté |
|---|---|
| La voix en duplex intégral (parler en même temps, comme au téléphone) | un modèle de 35B plus les modèles de parole : trop lourd à côté de tout le reste sur deux cartes. Rendre la voix de la maison plus réactive passe d'abord |
| Une bascule automatique entre KVMem et llama.cpp seul | basculer coûte 17,9 s ; deux préréglages suffisent |
| Guider un modèle local jeton par jeton avec le serveur de langage | pas de masquage de jetons dans llama-server ; le contournement, découper la requête en segments, ne coûte que 0,7 ms chacun. Faisabilité prouvée, pas encore construit |
La méthode
- Une variable à la fois, trois runs, médiane et écart.
- Mesurer là où ça sert : un agent dans une vraie session, pas un
curl. - Casser exprès pour voir le test passer au rouge (voir les tests validés par mutation).
- Noter le verdict, avec son chiffre, le jour même.
Utile ? Dites-nous ce qu'il faut mesurer ensuite.