Nous l'utilisons chaque jour

Refroidissement

Pilotage du ventilateur du GPU

La tâche, sur la capture 1 : le ventilateur du GPU est branché sur la carte mère ; il doit suivre la température du GPU, tourner à fond pendant une minute pour confirmer que le pilotage fonctionne, puis recevoir des niveaux optimaux, et après un redémarrage tout doit fonctionner automatiquement.

1. 1
   Demande

   Un simple message Telegram, sans commandes techniques.

2. 2
   Reconnaissance

   D'abord, sans droits d'administrateur, l'agent a établi : carte Z10PA-U8, GPU Tesla P100, température du GPU lisible (39 °C), mais encore rien pour piloter le ventilateur. Il a demandé les droits d'administrateur avec une seule commande et a exposé son plan. Une fois l'accès obtenu, il a trouvé la puce Nuvoton NCT7904D (9 entrées tachymétriques, 4 canaux PWM) et, en faisant passer chaque canal de 0 à 255, a fait la correspondance : pwm2 → fan5, jusqu'à ~5300 RPM, c'est la turbine de la P100. Les trois autres canaux sont restés en automatique BIOS.

3. 3
   Une minute à pleine vitesse

   pwm2 = 255 pendant 60 secondes : en 5 secondes, fan5 est passé de 1468 à 5294–5421 RPM et le GPU est descendu de 37 à 31 °C. Ensuite, le pilotage est revenu à la courbe (255 → 195 → 90) ; les relevés du tachymètre confirment que cela fonctionne.

4. 4
   Courbe

   ≤35 °C → 35 %, 45 °C → 47 %, 60 °C → 67 %, 75 °C → 86 %, ≥85 °C → 100 % (la P100 réduit ses fréquences à 91 °C, il reste donc une marge). La vitesse change en douceur, d'au plus ±15 % toutes les 5 secondes ; si nvidia-smi ne répond plus, le ventilateur passe en mode de secours à ~78 %.

5. 5
   Redémarrage

   Le pilote se charge automatiquement et le pilotage tourne comme un service à démarrage automatique. L'agent a vraiment redémarré la machine et a tout revérifié depuis zéro : module chargé, service actif, fan5 à 1319 RPM, GPU à 35 °C.

• De notre côté : une commande pour accorder les droits d'administrateur, la réponse «Ready» et une confirmation en cours de route.
• ≈ 30 minutes (06:26–06:57 d'après les captures)

Configuration

Question technique, à la voix

Une tâche pratique : par message vocal, nous avons demandé comment le système est organisé. Il a répondu avec les données réelles de nos machines : matériel, disques, modèle d'IA et vitesse. Si un point n'est pas clair, il suffit de demander tout de suite ce qu'il signifie.

Ce que montre la réponse : deux machines, claryel01 et P2002 ; processeur, mémoire, GPU et disques ; versions des logiciels ; modèle d'IA ; vitesse mesurée.

Dans cette tâche, le modèle de secours était externe (Grok) et sans filtre. Pour notre système local, ce n’est pas acceptable : le modèle de secours a donc été remplacé par un second modèle local. Aujourd’hui, les modèles cloud ne sont appelés que via le filtre et, si nécessaire, après confirmation explicite de l’utilisateur.

Un terme technique n'est pas clair ? Demandez-le tout de suite au système, directement dans la conversation : il vous l'explique avec des mots simples.

Parc de machines

Trois machines, un seul agent

La demande, sur la capture 1 (07:47) : pour chaque machine avec Strata, taille et type de mémoire, NVMe, GPU et mémoire vidéo, version de Strata, modèle, version de l'agent et vitesse du modèle sur cette machine ; réponse courte et en anglais.

L'agent a analysé lui-même le réseau et a confirmé qu'il y a trois machines (les autres adresses sont une imprimante et le port Wi-Fi du Mac). Les trois utilisent Strata v0.1.45 avec le même modèle Qwen3.8-Flash-Next IQ3_S (contexte 262 144), donc les réponses sont cohérentes quelle que soit la machine qui répond.

Vitesse de génération : P2002 46.8 tok/s, Mac Studio 60.0 tok/s (la plus rapide), P1005 16.2 tok/s : un modèle de 78 Go pour 31 Go de mémoire, cette machine sert donc aux tâches de fond. Les trois sont pilotées par une seule instance de l'agent sur claryel01 ; le secours suit la chaîne P2002 → Mac Studio → Grok.

Dans cette tâche, le modèle de secours était externe (Grok) et sans filtre. Pour notre système local, ce n’est pas acceptable : le modèle de secours a donc été remplacé par un second modèle local. Aujourd’hui, les modèles cloud ne sont appelés que via le filtre et, si nécessaire, après confirmation explicite de l’utilisateur.

Installation

Strata sur une nouvelle machine : l’agent a franchi seul tous les obstacles

Il n’existe pas de build prête pour Mac : le moteur Metal se compile depuis les sources (~5–15 min). La build 0.1.45 pour Mac était cassée ; l’agent a trouvé la PR ouverte #2895, l’a appliquée à la version, et la recompilation a réussi.

Le modèle de 79 Go : via HuggingFace sur Starlink, cela aurait été ~6,5 Mo/s (~3,4 h) ; l’agent l’a donc copié avec rsync depuis P2002 grâce au transfert de l’agent SSH, en 2 h 05 min. Ensuite, chaque requête au moteur renvoyait 400 ; l’agent a trouvé dans le code source le contournement --no-prefill-borrow.

Résultat : le Mac ≈ P2002 en génération (~58 contre ~57 tok/s) et nettement plus rapide en prefill (+36 %). L’agent a enregistré tous les obstacles dans la compétence strata-mac-deploy : la prochaine fois, ce sera presque une copie.

Mise à jour

L’agent a mis à jour le moteur de son propre « cerveau »

Question (04:30) : quelle version de Strata utilise le « cerveau » et quelle est la dernière sur GitHub ? Réponse : P2002 tourne en v0.1.43.1, la dernière est la v0.1.45 (publiée le 17 octobre 2026). L’agent a prévenu que la mise à jour redémarrerait le moteur sur lequel il fonctionne lui-même : quelques minutes d’arrêt, avec un retour arrière comme garantie.

Sur la commande « mets-toi à jour » (04:31), l’agent a lancé la mise à jour séparément de lui-même : git pull → compilation du moteur HIP 0.1.45 → redémarrage du service, tandis qu’un surveillant contrôle le moteur pendant 5 minutes et revient à la 0.1.43.1 s’il ne redémarre pas. La compilation a été propre (34 Mo, 0 erreur), mais le remplacement du fichier en cours d’utilisation a échoué (« Text file busy ») et le moteur s’est arrêté. L’agent a gardé l’ancien fichier en réserve, installé le nouveau manuellement et redémarré le service.

Vérification (04:50) : la v0.1.45 tourne, modèle Qwen3.8-Flash-Next IQ3_S, contexte 262 144. Vitesse avec le même script : réponse courte 31,0 (avant 33,5–33,7), génération de 1024 jetons 47,7 / 44,4 (avant 53,0–60,1), prefill 1,5K 874 / 531 (avant 488–490). Lecture de l’agent : prefill nettement meilleur, génération inférieure de ~10–20 % sur deux mesures ; avec deux mesures seulement, il ne parle pas de régression et propose 3–4 mesures de plus et un retour à la 0.1.43.1 si le ralentissement se confirme.

Dans cette tâche, le modèle de secours était externe (Grok) et sans filtre. Pour notre système local, ce n’est pas acceptable : le modèle de secours a donc été remplacé par un second modèle local. Aujourd’hui, les modèles cloud ne sont appelés que via le filtre et, si nécessaire, après confirmation explicite de l’utilisateur.

Surveillance

Contrôle matinal de la maison et des ordinateurs

L’ensemble sur l’image : Strata v0.1.43 + Qwen3.8-Flash-Next (IQ3_S) + l’agent. L’agent lit les capteurs Home Assistant (température, humidité, mouvement, lumière, énergie) et vérifie les sauvegardes, les disques et la température des ordinateurs. Nous lui parlons via Telegram.

Ce que le contrôle a trouvé : la pièce des ordinateurs est à 28,8 °C, nettement plus chaude que les autres pièces, il faut vérifier la ventilation et le refroidissement ; les piles des capteurs du bureau (20 %) et de la terrasse (30 %) sont à remplacer ; le capteur de porte « Leo » indique ON, mais la valeur peut être périmée et doit être vérifiée sur place.

Viktor n’a même pas ouvert l’interface de Home Assistant. Outils d’appoint ce jour-là : ChatGPT a dessiné l’image du post, ChatGPT Go + Codex ont aidé à la configuration, et l’agent faisait de temps en temps appel à Grok 4.7 comme modèle supplémentaire pour les raisonnements complexes.

Dans cette tâche, le modèle de secours était externe (Grok) et sans filtre. Pour notre système local, ce n’est pas acceptable : le modèle de secours a donc été remplacé par un second modèle local. Aujourd’hui, les modèles cloud ne sont appelés que via le filtre et, si nécessaire, après confirmation explicite de l’utilisateur.

Une illustration du post, pas une capture d’écran.

Vitesse du modèle

31 tok/s avec la RAM presque libre : le modèle est lu depuis le SSD

Réglages : modèle Qwen3.8-Flash-Next IQ3_XXS (~47 Go), contexte 64K (65 536 jetons), cache KV 8 bits, mode low-RAM : une partie des « experts » du modèle est lue depuis le SSD. Carte graphique AMD Radeon RX 9070, ~16 Go.

Le résultat sur le moniteur Strata : 12 136 jetons en 396,3 s, génération 31,0 tok/s, VRAM 15,7 sur 16 Go, RAM 3,2 sur 31 Go, GPU 45 °C. 5 681 « experts » (9,2 Go) sont en mémoire vidéo, le reste est lu depuis le disque.

Conclusion : un grand modèle tourne sans énorme quantité de RAM, car le moteur garde l’essentiel en mémoire vidéo et lit le reste depuis un SSD rapide. C’est une voie vers des ordinateurs bien plus abordables pour l’IA locale.

Vitesse du modèle

Contexte 256K : 26 requêtes sur une seule carte graphique de 16 Go

L’objectif était simple : comprendre comment automatiser plus tard ces exécutions sur différents matériels et comment présenter les résultats pour la comparaison. Machine : Intel Core Ultra 7 270K Plus, 31 Go de RAM, AMD Radeon 16 Go.

Le bilan depuis dimanche matin (09:44) : 26 requêtes, 169 326 jetons de prompt lus à 108 tok/s (1 923 247 autres repris du cache de conversation), 166 539 jetons écrits à 20,5 tok/s en moyenne. Le contexte est rempli à 62 % (162k sur 256k).

Tout ne s’est pas passé sans accroc : la liste montre une requête « Closed » et une « Stopped ». La vidéo du post original montre le modèle en train d’écrire une longue réponse technique ; Viktor y explique aussi ce qui n’a pas marché.

Vitesse du modèle

Plus de RAM : 45 tok/s sur un contexte de 164 000 jetons

Ordinateur : Intel Core Ultra 7 270K Plus (24 threads), AMD Radeon 16 Go, 62 Go de RAM, contexte 262 144 jetons. Le moteur utilise désormais aussi la RAM : 53,5 Go occupés sur 62.

Deux requêtes d’environ 162 000 jetons chacune : la première lue à 1 176 tok/s, génération 48,3 tok/s ; la seconde reprise presque entièrement du cache de conversation (162 199 jetons), génération 45,2 tok/s.

Le compromis est clair : avec plus de RAM, la génération est nettement plus rapide, mais il reste moins de mémoire pour d’autres tâches. Avec 31 Go, le moteur touchait à peine la RAM et l’ordinateur restait libre pour d’autres travaux.

Vitesse du modèle

Un vieux Xeon et une Tesla P100 : 19–27 tok/s

Le modèle ne tient pas en RAM et tourne depuis la mémoire vidéo (15,7 sur 16 Go) et un disque NVMe en PCIe 3.0. Le processeur est à environ 45 %, la RAM presque libre : l’ordinateur peut servir à d’autres travaux.

Sur le moniteur : génération actuelle 26,9 tok/s ; dans l’historique des requêtes, 19,3 tok/s sur une réponse courte (253 jetons) et 25,3 tok/s sur une longue (12 686 jetons en 504,1 s). Carte graphique à 36 °C, 97 W sur 250.

Pour nous, c’est le repère de prix essentiel : même un matériel ancien et peu coûteux, avec un moteur bien configuré, convient déjà au travail réel.