I got a DGX Spark.
If you're not familiar, it's NVIDIA's compact AI supercomputer, a Grace Blackwell chip, 128 GB of unified memory, and enough GPU horsepower to make your electricity bill flinch. It showed up in a box that was way too nice for hardware, and I did what any reasonable person would do: I immediately started throwing models at it.
First up: Nemotron Nano. NVIDIA's own small model, practically begging to run on their own hardware. It was fast, surprisingly capable, and made me feel like I was living in the future. Then I loaded Qwen 3.5, the base model, the Next variant, and the Coder variant. All three ran beautifully. Threw in a few more open-source models for good measure. Benchmarks looked great. Inference was snappy. I was having a blast.
For about two days.
Here's the thing about owning a personal AI supercomputer: after you've benchmarked every model on Hugging Face and generated your fifth haiku about Linux kernel panics, a question starts creeping in.
What is this thing actually useful for?
Don't get me wrong, it's a magnificent toy. But \"toy\" was the operative word. I had this incredible machine sitting on my desk, running circles around cloud inference latency, and I was using it to… summarize articles? Write commit messages? The Spark deserved better.
The idea hit me while I was SSH-ing into a server for the nine-hundredth time that week, running the same diagnostic commands I always run, grepping through the same logs I always grep through.
What if I combined a local LLM, running right here on the Spark, fast and private, with a higher-capability cloud model like Claude? And what if the interface between them was something structured and secure, not just raw API calls?
That \"something\" turned out to be MCP, Anthropic's Model Context Protocol. MCP gives AI models a standardized way to call external tools with proper authentication, structured parameters, and full audit trails. It's not a chat API. It's a tool protocol. And it was exactly the missing piece.
The architecture practically designed itself: Claude handles the conversation and intent, understanding what you want to do. The local LLM on your infrastructure handles the execution, figuring out the exact commands to run. MCP sits in the middle, making sure everything is authenticated, authorized, and logged.
Here's the insight that made the whole thing click: you don't need a frontier model to manage a server.
Think about it. What are the actual tasks? Check disk usage. Restart a service. Update packages. Read a log file. Configure a firewall rule. These aren't PhD-level reasoning problems. A capable 8B parameter model running locally can handle them just fine, often faster than a round-trip to a cloud API.
The hard part of AI-powered server management was never the intelligence. It was the plumbing: authentication, authorization, command validation, audit logging, secure transport. The boring stuff that keeps production systems from catching fire.
A local model gives you something no cloud API ever will: your data stays home. Passwords in config files, application logs with customer data, internal hostnames and network topology, none of it leaves your infrastructure. The LLM runs on your hardware, processes your data, and forgets everything the moment the task is done.
Most AI tools treat privacy as a checkbox. \"We don't store your data\" (but it traverses our servers). \"We anonymize your prompts\" (but we still see them). \"Our model doesn't train on your inputs\" (but our logging pipeline does).
With a local LLM, there is no trust problem to engineer around. The model runs in your datacenter. The data never leaves. End of story. No privacy policy needed, just physics.
For anyone managing servers with sensitive data, which is everyone, whether they realize it or not, this changes the equation entirely. You get the power of AI-assisted operations without the compliance headache of sending server internals to a third party.
A local LLM with network access and no guardrails is arguably worse than no AI at all. LLMs hallucinate. They confidently generate commands that look right but aren't. Left unsupervised, a helpful AI assistant is one hallucinated rm -rf / away from a very bad day.
So we built the security stack:
Each layer is simple. Together, they form a security model where the AI is powerful but fundamentally untrusted, it can suggest anything, but only pre-approved commands actually execute.
A DGX Spark, a question, and a few months of building later, ManageLM exists. It lets you manage your entire Linux and Windows infrastructure in natural language, with a local LLM that keeps your data private, a cloud model that understands your intent, and a security stack that makes sure nothing goes sideways.
Is it the most powerful server management tool on the planet? Well, it manages servers using AI, it doesn't leak your data, it cryptographically signs every instruction, and it sandboxes execution at the kernel level. If something more powerful exists, I haven't found it. And I've been looking.
The best part? You don't need a DGX Spark to use it. Any machine that can run Ollama works. The Spark was where the idea was born, but ManageLM runs happily on far more modest hardware. A small VM with 8 GB of RAM and a decent CPU will do just fine.
ManageLM is free for up to 10 agents, every feature, no limits, no credit card. Sign up, install the Claude extension, and start talking to your servers like a human being instead of a shell script.
Your infrastructure will thank you. Probably.
", "fr": "On m'a livré un DGX Spark.
Pour ceux qui ne connaissent pas : le supercalculateur d'IA compact de NVIDIA, une puce Grace Blackwell, 128 Go de mémoire unifiée et assez de puissance GPU pour faire pâlir votre facture d'électricité. La boîte était bien trop soignée pour du matériel informatique, et j'ai fait ce que n'importe qui aurait fait à ma place : j'ai commencé à le bombarder de modèles.
D'abord Nemotron Nano, le petit modèle maison de NVIDIA, qui ne demandait qu'à tourner sur le matériel de NVIDIA. Rapide, étonnamment doué, de quoi se croire déjà dans dix ans. Puis Qwen 3.5 : le modèle de base, la variante Next, la variante Coder. Les trois tournaient à merveille. J'en ai ajouté quelques autres, histoire de voir. Les benchmarks étaient superbes, l'inférence vive. Je m'amusais comme un fou.
Pendant deux jours environ.
Il y a un revers à posséder son propre supercalculateur d'IA : quand vous avez mesuré tous les modèles de Hugging Face et pondu votre cinquième haïku sur les kernel panics, une question s'installe.
À quoi cette machine sert-elle vraiment ?
Entendons-nous bien, c'est un jouet magnifique. Mais le mot qui compte, c'est « jouet ». J'avais sur mon bureau une machine qui pulvérisait la latence de n'importe quelle inférence en ligne, et je m'en servais pour… résumer des articles ? Rédiger des messages de commit ? Le Spark méritait mieux.
L'idée m'est venue en ouvrant une session SSH pour la neuf-centième fois de la semaine, afin de lancer les commandes de diagnostic que je lance toujours et d'éplucher les logs que j'épluche toujours.
Et si j'associais un LLM local, ici même sur le Spark, rapide et privé, à un modèle cloud plus costaud comme Claude ? Et si l'interface entre les deux était structurée et sûre, au lieu d'appels d'API à l'état brut ?
Cette interface existait déjà : MCP, le Model Context Protocol d'Anthropic. MCP offre aux modèles une manière normalisée d'appeler des outils externes, avec une vraie authentification, des paramètres structurés et une traçabilité complète. Ce n'est pas une API de conversation, c'est un protocole d'outils. La pièce qui manquait, exactement.
L'architecture s'est dessinée presque toute seule : Claude tient la conversation et l'intention, il comprend ce que vous voulez faire ; le LLM local, chez vous, se charge de l'exécution et détermine les commandes exactes ; MCP se tient entre les deux et garantit que tout est authentifié, autorisé et tracé.
Voilà l'intuition qui a tout fait tenir debout : on n'a pas besoin d'un modèle de pointe pour administrer un serveur.
Regardez les tâches réelles. Regarder l'occupation disque. Relancer un service. Mettre à jour des paquets. Lire un fichier de logs. Poser une règle de firewall. Rien qui exige un raisonnement de niveau thèse. Un bon modèle de 8 milliards de paramètres, en local, s'en sort très bien, et souvent plus vite qu'un aller-retour vers une API distante.
Le difficile, dans l'administration par IA, n'a jamais été l'intelligence. C'est la plomberie : authentification, autorisation, validation des commandes, traçabilité, transport chiffré. Le travail ingrat qui empêche la production de prendre feu.
Un modèle local apporte ce qu'aucune API distante ne vous donnera : vos données restent à la maison. Mots de passe dans les fichiers de configuration, logs applicatifs pleins de données clients, noms d'hôtes internes, topologie réseau, rien ne sort de chez vous. Le LLM tourne sur votre matériel, traite vos données, et oublie tout dès la tâche terminée.
La plupart des outils d'IA traitent la confidentialité comme une case à cocher. « Nous ne conservons pas vos données » (mais elles transitent par nos serveurs). « Nous anonymisons vos requêtes » (mais nous les voyons quand même). « Notre modèle ne s'entraîne pas sur vos saisies » (notre chaîne de traçage, si).
Avec un LLM local, il n'y a plus de problème de confiance à contourner. Le modèle tourne dans votre salle serveurs. Les données ne sortent pas. Fin de l'histoire. Aucune politique de confidentialité à lire : de la physique.
Pour qui administre des serveurs contenant des données sensibles, c'est-à-dire tout le monde, consciemment ou non, l'équation change du tout au tout. Vous gagnez la puissance de l'IA sans le casse-tête de conformité qui accompagne l'envoi de vos entrailles système chez un tiers.
Un LLM local avec un accès réseau et aucun garde-fou est sans doute pire que pas d'IA du tout. Les LLM hallucinent : ils produisent avec aplomb des commandes qui ont l'air justes et ne le sont pas. Sans surveillance, un assistant serviable n'est qu'à un rm -rf / halluciné d'une très mauvaise journée.
Nous avons donc bâti la pile de sécurité :
Chaque couche est simple. Ensemble, elles donnent un modèle où l'IA est puissante mais fondamentalement non fiable : libre à elle de proposer n'importe quoi, seules les commandes approuvées d'avance s'exécutent.
Un DGX Spark, une question et quelques mois de développement plus tard, ManageLM existe. Vous administrez toute votre infrastructure Linux et Windows en langage courant, avec un LLM local qui garde vos données privées, un modèle cloud qui saisit votre intention et une pile de sécurité qui veille à ce que rien ne parte de travers.
Est-ce l'outil d'administration le plus puissant de la planète ? Disons qu'il pilote des serveurs avec de l'IA, qu'il ne laisse pas fuir vos données, qu'il signe cryptographiquement chaque instruction et qu'il confine l'exécution au niveau du noyau. S'il existe plus puissant, je ne l'ai pas trouvé. Et j'ai cherché.
Le meilleur, dans tout ça ? Nul besoin d'un DGX Spark pour vous en servir. N'importe quelle machine capable de faire tourner Ollama convient. Le Spark a vu naître l'idée, mais ManageLM se contente de bien plus modeste : une petite VM avec 8 Go de RAM et un processeur correct fait parfaitement l'affaire.
ManageLM est gratuit jusqu'à 10 agents : toutes les fonctionnalités, sans limite, sans carte bancaire. Créez votre compte, installez l'extension Claude et parlez à vos serveurs comme un être humain, plus comme un script shell.
Votre infrastructure vous dira merci. Sans doute.
", "de": "Bei mir stand plötzlich ein DGX Spark.
Falls Sie ihn nicht kennen: NVIDIAs kompakter KI-Supercomputer, ein Grace-Blackwell-Chip, 128 GB einheitlicher Speicher und so viel GPU-Leistung, dass die Stromrechnung zusammenzuckt. Die Verpackung war für Hardware viel zu schön, und ich tat, was jeder Vernünftige getan hätte: Ich ließ sofort Modelle darauf los.
Zuerst Nemotron Nano, NVIDIAs eigenes kleines Modell, das geradezu danach verlangte, auf NVIDIAs eigener Hardware zu laufen. Schnell, erstaunlich fähig, ein Gefühl wie zehn Jahre in der Zukunft. Dann Qwen 3.5: das Basismodell, die Next-Variante, die Coder-Variante. Alle drei liefen glänzend. Noch ein paar weitere quelloffene Modelle hinterher, der Neugier wegen. Die Benchmarks sahen prächtig aus, die Inferenz war flott. Ich hatte einen Riesenspaß.
Etwa zwei Tage lang.
Ein eigener KI-Supercomputer hat eine Kehrseite: Wenn Sie jedes Modell auf Hugging Face vermessen und Ihr fünftes Haiku über Kernel-Panics geschrieben haben, meldet sich eine Frage.
Wofür ist dieses Gerät eigentlich gut?
Verstehen Sie mich nicht falsch, es ist ein prächtiges Spielzeug. Aber das entscheidende Wort ist „Spielzeug“. Auf meinem Schreibtisch stand eine Maschine, die jede Cloud-Inferenz bei der Latenz alt aussehen ließ, und ich benutzte sie, um … Artikel zusammenzufassen? Commit-Nachrichten zu formulieren? Der Spark hatte Besseres verdient.
Die Idee kam mir, als ich mich zum neunhundertsten Mal in dieser Woche per SSH anmeldete, um dieselben Diagnosebefehle abzusetzen wie immer und dieselben Logs zu durchforsten wie immer.
Was wäre, wenn ich ein lokales LLM, hier auf dem Spark, schnell und privat, mit einem kräftigeren Cloud-Modell wie Claude zusammenbrächte? Und wenn die Schnittstelle dazwischen strukturiert und sicher wäre statt roher API-Aufrufe?
Diese Schnittstelle gab es schon: MCP, das Model Context Protocol von Anthropic. MCP gibt Modellen einen normierten Weg, externe Werkzeuge aufzurufen, mit echter Authentifizierung, strukturierten Parametern und lückenloser Nachvollziehbarkeit. Keine Chat-API, sondern ein Werkzeugprotokoll. Genau das fehlende Stück.
Die Architektur entwarf sich fast von selbst: Claude führt das Gespräch und erfasst die Absicht, also was Sie tun wollen; das lokale LLM bei Ihnen im Haus übernimmt die Ausführung und ermittelt die genauen Befehle; MCP steht dazwischen und sorgt dafür, dass alles authentifiziert, autorisiert und festgehalten ist.
Das ist die Einsicht, die alles zusammenhielt: Für die Verwaltung eines Servers braucht es kein Spitzenmodell.
Sehen Sie sich die echten Aufgaben an. Festplattenbelegung ansehen. Einen Dienst neu starten. Pakete aktualisieren. Eine Logdatei lesen. Eine Firewall-Regel setzen. Nichts davon verlangt Denkleistung auf Doktorniveau. Ein fähiges Modell mit 8 Milliarden Parametern erledigt das lokal mit Leichtigkeit, oft schneller als der Umweg über eine Cloud-API.
Der schwere Teil KI-gestützter Verwaltung war nie die Intelligenz. Es ist die Installationsarbeit: Authentifizierung, Autorisierung, Befehlsprüfung, Audit, verschlüsselter Transport. Die unspektakuläre Arbeit, die verhindert, dass die Produktion Feuer fängt.
Ein lokales Modell gibt Ihnen etwas, das keine Cloud-API je bietet: Ihre Daten bleiben zu Hause. Passwörter in Konfigurationsdateien, Anwendungs-Logs voller Kundendaten, interne Hostnamen, Netztopologie, nichts davon geht hinaus. Das LLM läuft auf Ihrer Hardware, verarbeitet Ihre Daten und vergisst alles, sobald die Aufgabe erledigt ist.
Die meisten KI-Werkzeuge behandeln Datenschutz als Häkchen. „Wir speichern Ihre Daten nicht“ (sie laufen aber über unsere Server). „Wir anonymisieren Ihre Eingaben“ (sehen sie trotzdem). „Unser Modell trainiert nicht mit Ihren Eingaben“ (unsere Logging-Kette schon).
Mit einem lokalen LLM gibt es kein Vertrauensproblem mehr zu umschiffen. Das Modell läuft in Ihrem Rechenzentrum. Die Daten gehen nicht hinaus. Ende. Dafür braucht es keine Datenschutzerklärung, nur Physik.
Wer Server mit sensiblen Daten betreut, also alle, ob bewusst oder nicht, sieht damit eine völlig andere Rechnung. Sie bekommen die Kraft der KI ohne die Compliance-Kopfschmerzen, die das Verschicken von Systeminterna an Dritte mit sich bringt.
Ein lokales LLM mit Netzzugang und ohne Leitplanken ist womöglich schlimmer als gar keine KI. LLMs halluzinieren: Sie erzeugen mit großer Überzeugung Befehle, die richtig aussehen und es nicht sind. Unbeaufsichtigt trennt einen hilfsbereiten Assistenten nur ein halluziniertes rm -rf / von einem sehr schlechten Tag.
Also haben wir den Sicherheitsunterbau gebaut:
Jede Schicht für sich ist simpel. Zusammen ergeben sie ein Modell, in dem die KI mächtig und zugleich grundsätzlich nicht vertrauenswürdig ist: Vorschlagen darf sie alles, ausgeführt wird nur, was vorher freigegeben war.
Ein DGX Spark, eine Frage und einige Monate Arbeit später gibt es ManageLM. Sie verwalten Ihre gesamte Linux- und Windows-Infrastruktur in natürlicher Sprache, mit einem lokalen LLM, das Ihre Daten privat hält, einem Cloud-Modell, das Ihre Absicht versteht, und einem Sicherheitsunterbau, der dafür sorgt, dass nichts aus dem Ruder läuft.
Ist es das mächtigste Verwaltungswerkzeug der Welt? Sagen wir so: Es steuert Server mit KI, es lässt Ihre Daten nicht abfließen, es signiert jede Anweisung kryptografisch und sperrt die Ausführung auf Kernel-Ebene ein. Gibt es etwas Mächtigeres, habe ich es nicht gefunden. Und ich habe gesucht.
Das Beste daran? Für den Einsatz brauchen Sie keinen DGX Spark. Jede Maschine, die Ollama ausführt, genügt. Auf dem Spark entstand die Idee, doch ManageLM begnügt sich mit weit Bescheidenerem: Eine kleine VM mit 8 GB RAM und einer ordentlichen CPU reicht völlig.
ManageLM ist für bis zu 10 Agenten kostenlos: alle Funktionen, keine Grenzen, keine Kreditkarte. Konto anlegen, die Claude-Erweiterung installieren und mit Ihren Servern reden wie ein Mensch, nicht wie ein Shell-Skript.
Ihre Infrastruktur wird es Ihnen danken. Vermutlich.
" } }