Gemma 26B affinée sur un MacBook de 24 Go : l'assistant hors ligne réussit 703 conversations sur 766

Six mois de travail, un MacBook avec 24 Go de mémoire unifiée et une contrainte stricte : ni cloud ni abonnement. L'auteur du projet a construit un assistant vocal pour macOS qui ne bavarde pas, mais agit : il ouvre des dossiers, cherche des fichiers, lance des films, lit le courrier. Pour cela, il a affiné Gemma 4 26B A4B (un MoE avec ~4 milliards de paramètres actifs) par QLoRA via mlx-lm. Les règles, qui occupaient auparavant environ 5 000 tokens de prompt système, ont migré dans les poids d'un petit adaptateur LoRA. Sur un banc d'essai gelé de 766 conversations, la version v4b avec prompt court en a résolu 703, avec une médiane de réponse de 1,64 seconde.

Le cerveau choisit un outil au lieu d'écrire du texte

L'application est écrite en Electron, avec des processus distincts autour de la fenêtre. L'écoute repose sur Python, avec un détecteur de parole et Whisper en build MLX. Le cerveau, c'est llama-server (llama.cpp) avec Gemma quantifiée en 4 bits et une LoRA au format GGUF. La voix est synthétisée par Qwen-TTS à partir d'un enregistrement de référence. Un assistant en Swift gère les fonctions système de macOS (son, microphone, écho). Un watchdog relance tout processus qui plante, et la voix remonte en 7 secondes environ.

À chaque réplique, le modèle renvoie une seule étape dans un JSON de format fixe, avec les champs think, tool, args, say et next. La fenêtre exécute l'outil et, si nécessaire, renvoie le résultat au modèle. Toute modification ou suppression de fichiers exige une confirmation vocale. ChatGPT, Claude et Gemini renvoient le même format si l'utilisateur les a connectés : les outils leur sont transmis via leurs appels de fonctions natifs. Le llama-server local est alors arrêté et libère environ 13 Go.

Un banc d'essai de 766 conversations et une passe de réparation

Avant d'entraîner le modèle, l'auteur a constitué un banc d'essai gelé : des phrases accompagnées d'étapes de référence, sur lesquelles il ne s'entraîne jamais. Il couvre les commandes sur les dossiers, la recherche de films, le courrier, les questions sur des documents, les chaînes de répliques, les refus et les erreurs de reconnaissance vocale. Deux leçons ont coûté cher. L'évaluation réplique par réplique écartait plus de 400 chaînes et dressait un tableau trop rose : il faut donc comparer des conversations entières. Les exemples construits à partir des erreurs du banc d'essai gonflent le score sur ce même banc, si bien qu'une évaluation honnête exige un jeu de données neuf.

Évolution des versions (le banc est passé de 533 à 766 conversations ; la comparaison directe n'est donc valable qu'à taille égale) :

• Sans adaptateur, prompt complet : 475 sur 533 (89 %), médiane de 1,94 s
• v3, prompt complet : 487 sur 533 (91 %), médiane de 1,63 s
• v4 avec de nouvelles sections (documents, plans, anglais, chaînes) : 684 sur 766
• v4b, prompt court : 703 sur 766, médiane de 1,64 s

Avec la v4, le modèle a progressé sur les nouvelles sections mais régressé sur les anciennes. « Включи фильм » (« lance le film ») se mettait à lancer de la musique, « найди фильм » (« trouve le film ») perdait son type de recherche, et « свою папку » (« mon dossier ») se confondait avec le dossier de notes. La passe de réparation a réglé le problème : 416 exemples sur ces cas, plus un échantillon aléatoire de données anciennes et nouvelles, soit environ 1100 au total.

Le réentraînement a duré encore ~1000 pas, avec un learning rate de 1,5e-5 au lieu de 3e-5 et sans validation. Il a pris environ 70 minutes et donné le meilleur résultat de tout le projet. À l'inverse, un entraînement repris de zéro faisait oublier au modèle ce qu'il savait déjà.

Ce qui a cassé sur le laptop

La limite de Metal dicte la longueur des exemples : pas plus de ~1400 tokens, sinon l'erreur Insufficient Memory survient. Entraîner avec le prompt complet est physiquement impossible sur un Mac, ce qui plaide une fois de plus pour le transfert des règles dans les poids. Le script écarte d'avance les exemples qui ne tiennent pas. La vitesse est de 0,25–0,4 pas par seconde, une passe dure environ trois heures, et le modèle s'entraîne donc la nuit.

Les autres embûches :

• Le Mac se mettait en veille. Après un entraînement, l'évaluation sur le banc d'essai a duré six heures. Désormais, toute la chaîne (entraînement, conversion en GGUF, banc d'essai) tourne sous un seul caffeinate -i -s.
• Plantages mémoire. Le navigateur et l'indexation Spotlight poussent le swap à 6–7 Go, et les plantages coïncidaient avec la validation tous les 200–400 pas. La parade : sauvegarder des checkpoints, reprendre automatiquement avec --resume-adapter-file et désactiver la validation aux dernières étapes.
• Modifier un script bash à la volée a fait tomber la chaîne sur une syntax error, car bash lit le fichier au fil de l'exécution.
• Gemma 4 a nécessité deux petits correctifs dans mlx-lm, et la conversion de l'adaptateur en GGUF demande un environnement séparé avec torch.

L'ingénierie ne manque pas non plus autour du modèle. Le film est atténué non pas sur le nom de l'assistant, mais dès le début de la parole : si la voix dépasse de 6 dB le « plancher flottant » et que ce n'est pas de l'écho, le son baisse, puis revient après 2,5 secondes sans nom prononcé. Un défaut de synthèse, où « сэр » devient « сёр » environ une prise sur trois, est détecté par l'acoustique.

La voyelle est mesurée par analyse LPC d'ordre 12, et l'on compare le deuxième formant (environ 2000–2300 Гц pour « э », 750–900 Гц pour « ё »). La vérification prend environ 3 ms, le détecteur repère 39 défauts sur 46, et la phrase est resynthétisée avec une autre prise. Les questions sur les documents sont confiées à Spotlight : recherche en 60–700 ms, deux ou trois meilleurs fichiers, fenêtres d'environ 600 caractères, et réponse fondée uniquement sur elles.

Les plans DWG sont analysés par LibreDWG compilé en WebAssembly dans un thread séparé, puis convertis en SVG et mis en cache.

Une recette pour votre projet

Si vous construisez un agent local, commencez par le banc d'essai, pas par l'entraînement. Gelez un jeu de conversations et ne comparez les versions que sur lui. Pour l'évaluation finale, gardez un échantillon neuf, que ni le modèle ni vous n'avez vu.

Les règles qui traînent des milliers de tokens de prompt dans chaque requête gagnent à être transférées dans une LoRA : la précision et la latence s'améliorent en même temps. Ajoutez les nouvelles compétences par-dessus l'adaptateur existant, sur un mélange de données anciennes et nouvelles, avec un learning rate réduit. 24 Go suffisent pour un modèle MoE de 26B si l'on réduit la longueur des exemples, sauvegarde des checkpoints et empêche la machine de s'endormir. La prochaine étape de l'auteur : une mémoire personnelle et un auto-apprentissage à partir des phrases que l'assistant n'a pas comprises.