Raspberry Pi 5 et openLight : pourquoi les agents IA classiques surchargent le petit matériel

La plupart des agents IA populaires s'adaptent mal au Raspberry Pi 5, non pas parce que le modèle est trop faible, mais parce que toute la pile qui l'entoure a été conçue dès le départ pour des serveurs. L'auteur de l'article a étudié ce problème en pratique et a créé son propre runtime léger, openLight, qui supprime les couches superflues et ne garde que ce dont les tâches courantes ont réellement besoin.

Pourquoi tout s'alourdit

Sur un serveur classique, un framework d'agents semble un compromis pratique : runtime Python, services d'arrière-plan distincts, couche d'orchestration, parfois une base de données vectorielle et un lot de dépendances supplémentaires par-dessus. Mais sur un Raspberry Pi 5, chacune de ces couches se fait sentir presque physiquement : le système démarre plus lentement, consomme plus de mémoire, et une action simple exige soudain une infrastructure comparable à une petite plateforme.

Le problème est particulièrement visible quand les scénarios sont en réalité très simples. L'auteur n'avait pas besoin d'un « employé numérique » universel doté d'une longue chaîne de raisonnement. Il voulait résoudre des tâches d'administration de base : consulter la charge du CPU, vérifier l'espace disque libre, lire des logs ou redémarrer un service. Monter une pile d'agents lourde pour cela revient à dépenser des ressources non pas pour le résultat, mais pour l'entretien de l'outil lui-même.

Ce que propose openLight

Plutôt qu'un énième framework généraliste, l'auteur a créé openLight, un runtime minimaliste pour l'infrastructure personnelle. L'idée centrale est simple : l'agent ne doit pas devenir un LLM pour tout. Si une commande peut être traitée de façon déterministe, elle doit l'être. Le modèle n'intervient que là où s'en passer est réellement malcommode : pour classer une requête, interpréter le texte de l'utilisateur ou associer un message au bon skill.

• Un seul binaire, sans couches complexes
• Implémentation en Go plutôt qu'une lourde pile Python
• SQLite pour le stockage plutôt qu'un service de base de données distinct
• Un minimum de dépendances et un démarrage rapide
• Validation du skill avant l'exécution de la commande

Cette approche fait gagner non seulement des ressources, mais aussi du temps. Dans l'exemple de l'auteur, le chemin passant par le modèle local Ollama avec qwen2.5:0.5b a pris 42,55 secondes, contre 3,28 secondes pour le même scénario via OpenAI gpt-4o-mini. Mais l'enseignement principal n'est pas la comparaison des modèles : les commandes les plus fréquentes ne devraient pas passer à chaque fois par le circuit complet du LLM si le système peut les reconnaître à l'avance.

Le parcours d'une requête

Le trajet du message est linéaire et transparent : la requête arrive de Telegram, passe par l'autorisation et l'enregistrement, puis le système cherche d'abord une correspondance directe avec un skill connu. S'il en trouve une, la commande s'exécute immédiatement. Sinon, un classificateur LLM entre en jeu et décide de la suite : poursuivre la conversation ou choisir un skill adapté. Avant son lancement, le skill subit une vérification supplémentaire afin de garder la maîtrise de l'exécution.

L'idée était que l'agent ne devienne pas un « LLM pour tout ».

Telegram n'a pas été choisi ici comme un pis-aller provisoire, mais comme une interface tout à fait viable. Pas besoin de client web distinct, les notifications arrivent instantanément, l'accès se fait depuis le téléphone et l'autorisation est déjà intégrée au canal de communication. L'utilisateur peut écrire quelque chose comme « où en est l'état du système », et le runtime renvoie une réponse claire avec le nom d'hôte, la charge du CPU, la mémoire utilisée, l'espace disque libre, le temps de fonctionnement et la température. Les métriques elles-mêmes sont collectées de façon déterministe, sans génération superflue.

Ce que cela signifie

L'histoire d'openLight montre bien où les agents IA peuvent réellement aller en dehors des centres de données et des scénarios de démonstration. Sur les petits appareils, ce n'est pas la pile la plus « intelligente » qui l'emporte, mais celle qui sait ne pas appeler le modèle au bon moment. Pour le Raspberry Pi et l'infrastructure domestique, c'est un changement important : un agent utile peut n'être pas une plateforme gigantesque, mais une petite couche exécutable aux règles claires, qui ne recourt au LLM que de façon ciblée.