Une IA locale pour surveiller vos rigs : un LLM hors ligne qui lit les logs de vos mineurs

Il est 3 h du matin et une hashboard vient de tomber offline. Le temps que vous vous réveilliez, consultiez le tableau de bord et plissiez les yeux devant un mur de lignes de journal cryptiques, vous avez perdu des heures de hashrate et vous n’êtes toujours pas certain s’il s’agissait d’un câble nappe desserré, d’un déclenchement thermique, ou d’un pool qui a tranquillement cessé d’accepter les shares. Tout mineur qui a fait tourner du matériel pendant la nuit connaît ce sentiment : les données sont bien là dans l’API du mineur, mais les lire et savoir ce qu’elles signifient sont deux compétences bien distinctes.

C’est exactement le genre de travail de fond pour lequel un language model local est efficace. Pas en s’exécutant sur le mineur — nous serons précis à ce sujet dans un instant — mais sur une machine hôte que vous possédez déjà, qui surveille les journaux, traduit le charabia d’erreurs de puces en français clair, et vous oriente vers la cause probable avant que vous ayez fini votre café. Pas de compte cloud, pas de télémétrie, aucun prompt qui quitte votre réseau. Juste un assistant discret qui lit ce que disent vos rigs et vous aide à les surveiller. Voyons concrètement à quoi cela ressemble, et tout aussi important, ce qu’il ne peut pas faire.

Le problème de chute de hashrate à 3 h du matin

Un Antminer moderne est une machine bavarde. Sa carte de contrôle expose une API — la classique socket TCP cgminer/bmminer sur le port 4028, plus une interface web et, sur la plupart des firmware, des journaux téléchargeables — qui diffuse le hashrate par carte, les températures de puces, le régime des ventilateurs, les compteurs d’erreurs et l’état du pool. L’information nécessaire pour diagnostiquer presque toute panne s’y trouve. Le problème, c’est le volume et le vocabulaire.

Un seul S19 produit des centaines de lignes de journal par heure sur trois hashboards et 114 puces par carte sur le Pro. Quand quelque chose casse, le symptôme est généralement un compteur laconique ou un mot d’état hexadécimal : une chaîne qui lit 0 puce trouvée, une erreur asic, un capteur de température qui renvoie une valeur absurde, une carte qui démarre mais n’atteint jamais le hashrate cible. Pour un technicien chevronné, c’est familier. Pour un mineur résidentiel avec deux machines dans le garage, c’est du bruit. Et quand vous passez à un petit Hashcenter d’une douzaine de rigs mixtes sur différents firmware — Bitmain d’origine ici, BraiinsOS+ là, VNish sur le troisième — même le format des journaux change d’une machine à l’autre. Vous finissez par basculer de context entre trois vocabulaires juste pour déterminer quelle carte réasseoir.

Cette tâche d’appariement de motifs contre un vocabulaire connu est précisément ce qu’un language model fait bien. La question est comment en pointer un vers vos rigs sans livrer vos données opérationnelles au serveur de quelqu’un d’autre.

Ce qu’un LLM local peut réellement faire avec les journaux de mineur

Posons d’abord les attentes honnêtement, car le battage autour de l’« AI ops » est épais. Un model local n’est pas un oracle magique, et ce n’est certainement pas un substitut à la compréhension de votre matériel. Ce qu’il fait bien, c’est lire, résumer et expliquer. Concrètement, un LLM local nourri de vos journaux de mineur peut :

• Résumer un mur de journaux en une phrase. « La carte 2 sur 192.168.1.103 signale zéro puce depuis 02:14, les deux autres cartes sont saines » est bien plus utile à 3 h du matin que 400 lignes brutes.
• Traduire des compteurs cryptiques en langage clair. Il peut prendre un code d’erreur ou un mot d’état et expliquer, en mots, vers quel sous-système il pointe et quelles en sont les causes courantes.
• Repérer une tendance avant qu’elle ne devienne une panne. Une température de puce qui grimpe de 0,5°C par heure, ou un taux d’erreurs matérielles qui monte lentement, est le genre de pente qu’un model peut signaler à partir d’une fenêtre de journal quand vous ne regardez pas le graphique.
• Rédiger la prochaine étape. « Réasseoir le câble nappe sur la chaîne 2, et si le nombre de puces reste à zéro après un redémarrage, suspecter la carte » — une liste de départ, pas une garantie.
• Répondre aux questions en context. Vous collez le journal et demandez « pourquoi cette carte a-t-elle cessé de hasher ? » et obtenez une réponse ancrée et lisible au lieu d’ouvrir cinq onglets de navigateur.

Ce qu’il ne fait pas, c’est s’exécuter sur l’ASIC, et il n’appuie pas sur les boutons à votre place. Ces deux points méritent chacun leur section, car ce sont les deux endroits où les gens se trompent.

La pile : API du mineur → votre hôte → model local

Voici le mur de la précision, et nous le dirons clairement : le language model s’exécute sur votre propre ordinateur hôte, en lisant l’API et les journaux du mineur sur votre réseau local. Il ne s’exécute pas sur l’ASIC. Il ne le peut pas. Un mineur Bitcoin SHA-256 est du silicium à fonction fixe — une mer de cœurs de hachage avec une carte de contrôle ARM de classe microcontrôleur faible qui n’existe que pour alimenter ces cœurs en travail et communiquer avec le pool. Il n’y a pas de matériel à virgule flottante, pas de moteur de tenseurs, et pas de mémoire libre sur un mineur pour héberger un language model, et aucun firmware ne peut ajouter du matériel qui n’a jamais été fabriqué dans la puce. Nous détaillons exactement pourquoi dans notre analyse approfondie honnête sur la question de savoir si vous pouvez réellement faire tourner de l’IA sur un mineur Bitcoin — la version courte est non, l’IA s’exécute toujours sur un GPU ou un CPU que vous possédez à côté du mineur, jamais sur le silicium de hachage.

L’architecture est donc conceptuellement trois boîtes :

1. Le mineur expose son API et ses journaux sur votre LAN (port 4028, interface web, export de journaux). Il se contente de répondre aux questions sur son propre état.
2. Votre ordinateur hôte — la même machine que vous pourriez déjà faire tourner pour l’IA locale — interroge les mineurs, collecte les journaux et les fournit au model. C’est là que le travail se fait.
3. Le model local s’exécute sur cet hôte via un runtime comme Ollama ou llama.cpp. Un model de 7B–8B paramètres sur un GPU avec 8–12 Go de VRAM suffit amplement pour la synthèse de journaux et les Q&R ; rien d’exotique n’est requis.

Le flux de données est unidirectionnel et contenu : mineur → hôte → model → votre écran. Rien dans cette boucle ne touche Internet. La même machine GPU qui fait tourner votre model privé peut interroger vos rigs, ce qui est tout l’intérêt d’un Hashcenter mixte — l’ASIC hache le Bitcoin et dégage de la chaleur, le GPU exécute l’IA locale, et l’un des travaux que ce GPU peut prendre en charge est de garder un œil sur l’ASIC. Pour aller plus loin du côté self-hosted — choisir un model, dimensionner la VRAM, tout garder sur votre propre matériel — notre hub de calcul souverain en dresse la carte.

La bibliothèque de codes d’erreur de D-Central comme vérité terrain

Un language model à lui seul est un généraliste confiant, et les généralistes confidents hallucinent. La solution pour l’analyse de journaux est la même qu’ailleurs : donner au model du matériel de référence réel pour ancrer ses réponses, plutôt que de le laisser improviser. C’est là qu’une bibliothèque de codes d’erreur soigneusement constituée gagne sa place.

Nous maintenons une bibliothèque de plus de 200 codes d’erreur de mineur documentés — les erreurs asic, les défauts de température, les échecs de détection de chaîne, les déclenchements d’alimentation et de ventilateur — chaque entrée rédigée à partir de l’expérience de réparation pratique et des fiches techniques du silicium, expliquant la cause probable et le chemin diagnostique. Cette bibliothèque est le genre de vérité terrain dont un model local a besoin. Au lieu de demander à un model 7B de deviner ce que signifie un mot d’erreur de puce à partir de ses données d’entraînement, vous le pointez vers l’entrée pertinente de la bibliothèque et lui demandez d’appliquer ce savoir documenté au journal précis devant vous. Le model gère la lecture et l’appariement ; la bibliothèque fournit les faits. Le résultat est une explication ancrée dans les vraies données de réparation de D-Central, pas une fabrication au son plausible.

C’est aussi pourquoi une configuration spécifique aux mineurs Bitcoin bat un chatbot cloud générique pour ce travail. Un assistant général n’a jamais réassis une hashboard ni lu une fiche technique BM1398. L’ancrage est ce qui transforme « une IA qui parle de minage » en « un assistant qui vous aide réellement à réparer le rig devant vous ».

Où s’inscrit la DCENT_Toolbox

Parler à une flotte de mineurs à firmware mixtes sur le réseau est son propre problème d’ingénierie — chaque fabricant parle un dialecte légèrement différent des mêmes idées. C’est le vide que la DCENT_Toolbox est conçue pour combler. C’est un CLI Python open source (GPL-3.0) qui s’adresse à chaque firmware de mineur majeur — Bitmain d’origine, BraiinsOS, VNish, LuxOS, BitAxe, WhatsMiner — via une seule interface. Aujourd’hui, il livre plus de 35 commandes couvrant la découverte, le diagnostic, l’audit de sécurité, la gestion des pools et le réglage : il balaie un sous-réseau, trouve vos mineurs, extrait leur état et exécute des contrôles de sécurité et de diagnostic depuis une seule ligne de commande.

Pour le cas d’usage de surveillance des journaux, la Toolbox est la façon propre et scriptable de collecter les données que vous remettez ensuite à votre model local : un balayage asynchrone normalisé d’une flotte mixte est une bien meilleure entrée que de gratter trois interfaces web différentes à la main. Pour être clair sur la portée — la Toolbox est un CLI de gestion et de diagnostic, et elle est actuellement en bêta publique en juillet 2026. Elle n’intègre pas de language model, et elle ne règle pas vos mineurs de façon autonome. L’idée de réglage agentique piloté par model — où une IA lit les journaux et agit dessus — est quelque chose que nous explorons du côté DCENT_axe de l’établi, et c’est en grande partie planifié plutôt que livré. Nous préférons vous dire ce qui existe aujourd’hui plutôt que de vous vendre une feuille de route. Ce qui existe aujourd’hui, c’est un CLI solide pour extraire l’état des mineurs à travers les firmwares, et c’est exactement la première moitié d’un pipeline de surveillance par LLM.

Rien de tout cela non plus n’est venu de nulle part. La gestion multi-fournisseurs de mineurs en Python a été prouvée pratique par la bibliothèque pyasic, et l’outillage professionnel de flotte a été démontré par Braiins Toolbox avant nous. Nous nous appuyons sur ce travail, avec reconnaissance, et le redonnons sous GPL-3.0.

Limites honnêtes : il conseille, vous décidez

Voici la ligne que nous ne franchirons pas, et nous pensons que vous ne devriez pas non plus : le model conseille ; vous décidez et vous agissez. Un LLM local qui lit vos journaux est un assistant, pas un pilote automatique. Il est en lecture seule par conception dans ce schéma — il regarde les journaux et vous dit ce qu’il voit. Il ne redémarre pas les cartes, ne change pas les tensions, ne bascule pas les pools, ni ne flashe le firmware de son propre chef. Le moment où vous laissez un model de texte probabiliste appuyer sur des boutons du matériel sans surveillance, vous avez échangé un problème de hashrate contre un problème de mineur brique.

Et soyons honnêtes sur le mode de défaillance : un language model peut se tromper avec assurance. Il peut mal lire un compteur, inventer une cause qui sonne juste, ou manquer entièrement la vraie panne. C’est survivable précisément parce qu’un humain reste dans la boucle. Traitez sa sortie comme vous traiteriez la première hypothèse d’un technicien junior brillant — un point de départ utile que vous vérifiez avant de toucher quoi que ce soit. La bibliothèque d’ancrage réduit le taux d’erreur, mais ne l’élimine pas. Votre jugement, et vos mains sur le matériel réel, restent l’autorité. Le model vous amène simplement à la bonne question plus vite.

Confidentialité : rien ne quitte votre réseau

C’est la partie qui fait d’un model local le bon outil plutôt que simplement un outil pratique. Vos journaux de mineur sont du renseignement opérationnel : combien de machines vous faites tourner, quel firmware, à quoi ressemble votre flotte, quand elle faiblit, où elle vit sur votre réseau. Remettez cela à une IA cloud et vous avez remis à un tiers une carte de votre opération, mesurée et journalisée sur leurs serveurs. Pour un Bitcoiner souverain qui fait tourner du matériel précisément pour éviter de demander la permission, c’est le mauvais échange.

Un model local ferme cette porte. Les mineurs parlent à votre hôte sur le LAN, l’hôte exécute le model offline, et la réponse apparaît sur votre écran. Rien ne rappelle la maison, parce que rien n’a où appeler. Vous pouvez tirer entièrement le câble Internet et tout le pipeline fonctionne encore. C’est la même logique qui traverse le reste de la pile : possédez votre argent, possédez votre calcul, possédez vos données d’exploitation. L’IA locale sur votre propre GPU est la sauvegarde de l’intelligence louée de la même façon que le Bitcoin est la sauvegarde du fiat — une couche de plus que vous n’avez pas à confier à quelqu’un d’autre pour qu’il la fasse tourner. Notre hub de souveraineté relie tout cet état d’esprit des « sauvegardes ».

Questions fréquemment posées

L’IA s’exécute-t-elle sur le mineur ASIC lui-même ?

Non. Le language model s’exécute sur un ordinateur hôte que vous possédez — typiquement la même machine GPU que vous utiliseriez pour toute IA locale — en lisant l’API et les journaux du mineur sur votre réseau local. Un ASIC Bitcoin SHA-256 est du silicium à fonction fixe sans matériel à virgule flottante ni matriciel et sans mémoire libre pour héberger un model, et aucun firmware ne peut changer cela. Le mineur se contente de répondre aux questions sur son propre état ; l’IA vit sur votre hôte, à côté du mineur, pas à l’intérieur.

De quel matériel ai-je besoin pour faire tourner un model local pour cela ?

Du matériel modeste. Un GPU avec environ 8–12 Go de VRAM faisant tourner un model de 7B–8B paramètres suffit amplement pour la synthèse de journaux et les Q&R, et des models plus petits tourneront sur des CPU capables ou le silicium Apple. Vous installez un runtime comme Ollama ou llama.cpp sur votre hôte, le pointez vers un model, et lui fournissez les journaux que vos mineurs exposent. C’est le même genre de machine que vous construiriez pour toute configuration de calcul souverain.

L’IA peut-elle réparer mon mineur automatiquement ?

Non, et c’est par conception. Dans ce schéma, le model est en lecture seule : il lit les journaux, les résume et conseille. Il ne redémarre pas les cartes, ne change pas les tensions, ne bascule pas les pools, ni ne flashe le firmware. Il conseille ; vous décidez et vous agissez. Un model de texte probabiliste peut se tromper avec assurance, donc un humain reste dans la boucle et vérifie avant de toucher le matériel. Le réglage autonome et agentique est quelque chose que nous explorons du côté DCENT_axe, mais c’est en grande partie planifié, pas livré.

Comment la bibliothèque de codes d’erreur rend-elle l’IA plus fiable ?

Un language model brut devine à partir de ses données d’entraînement et peut halluciner des causes. En l’ancrant dans la bibliothèque D-Central de plus de 200 codes d’erreur de mineur documentés — chacun rédigé à partir de l’expérience de réparation pratique — le model applique un savoir diagnostique réel et vérifié à votre journal précis au lieu d’improviser. Il fait la lecture et l’appariement ; la bibliothèque fournit les faits. Cet ancrage est ce qui transforme un chatbot générique en un assistant qui aide réellement avec le rig devant vous.

La DCENT_Toolbox inclut-elle ce babysitter IA aujourd’hui ?

Pas en tant que model intégré. La DCENT_Toolbox est un CLI Python open source (GPL-3.0) pour gérer et diagnostiquer les mineurs à travers les firmwares majeurs — elle livre plus de 35 commandes pour la découverte, le diagnostic, l’audit de sécurité, la gestion des pools et le réglage, et elle est maintenant en bêta publique, ouverte depuis le 9 juillet 2026. C’est la façon propre et scriptable de collecter l’état des mineurs sur une flotte mixte, exactement les données que vous fourniriez à un model local. La Toolbox ne livre pas de language model et ne règle pas vos mineurs de façon autonome.

Pourquoi utiliser un model local plutôt qu’une IA cloud ?

Confidentialité et souveraineté. Vos journaux de mineur révèlent combien de machines vous faites tourner, quel firmware, et quand votre flotte faiblit — une carte de votre opération que vous ne devriez pas remettre aux serveurs d’un tiers. Un model local garde cette boucle entièrement sur votre réseau : mineurs vers hôte vers model vers écran, sans rien qui rappelle la maison. Vous pouvez déconnecter Internet et cela fonctionne encore. Possédez votre argent, possédez votre calcul, possédez vos données d’exploitation.