Anfang April hat Vitalik Buterin einen Blogpost veröffentlicht, der in technischen Kreisen Wellen geschlagen hat: "My self-sovereign / local / private / secure LLM setup, April 2026". Kein Manifest, kein Marketing, sondern ein nüchterner Werkstattbericht, wie er privat KI einsetzt — und warum er das konsequent lokal, gesandboxt und ohne Cloud-Anbindung tut.
Der Text ist für uns bei Freshlab aus einem bestimmten Grund bemerkenswert. Buterin argumentiert in denselben Koordinaten, in denen wir seit Jahren Infrastruktur bauen: Datensouveränität zuerst, Inferenz auf eigener Hardware, minimale Angriffsfläche. Er kommt dabei aus der Krypto-/Systemsicherheits-Ecke, wir kommen aus der europäischen KMU-Beratung. Die Schlussfolgerungen fallen überraschend ähnlich aus. Der Original-Post ist hier nachzulesen: vitalik.eth.limo — securellms.html.
Für deutsche KMU, die heute darüber nachdenken, wie GmbH-Compliance, DSGVO und EU AI Act sich mit einem produktiven KI-Einsatz vereinbaren lassen, liefert Buterins Post eine unabhängige Bestätigung einer technischen Richtung, die wir selbst seit über einem Jahr umsetzen.
Die Kern-These
Buterin öffnet mit einer Bestandsaufnahme, die er als Alarmzeichen versteht. Sein Beispiel ist "OpenClaw" — stellvertretend für die neue Generation von Agent-Systemen, die im Browser, auf dem Desktop oder direkt am Betriebssystem agieren. Diese Agents ändern kritische Einstellungen ohne Rückfrage. Manipulierte Webseiten können ausreichen, um beliebigen Code auszulösen. Prompt Injection ist kein Rand-Phänomen, sondern Standardverhalten.
Seine Diagnose fällt deutlich aus: Das gesamte Ökosystem geht lässig mit Sicherheit und Privatsphäre um. Bequemlichkeit dominiert, Telemetrie-by-default ist akzeptiert, "wir speichern nichts ausser zu Trainingszwecken" ist zur Standardausrede geworden.
Dem stellt Buterin drei nicht-verhandelbare Anforderungen gegenüber:
- Privatsphäre — keine Daten verlassen das Gerät, ausser der Nutzer will es explizit.
- Sicherheit — dangerous operations sind per Default gesandboxt, nicht per opt-in.
- Selbstsouveränität — kein Vendor-Lock, kein Kill-Switch, kein verpflichtendes Cloud-Konto.
Das ist keine ideologische Position, sondern eine Engineering-Anforderung. Sie beschreibt die Bedingungen, unter denen ein KI-System überhaupt als Teil einer ernstzunehmenden Infrastruktur gelten kann — sei es für einen Einzelnen oder für eine GmbH mit Geheimhaltungspflichten.
Was er empfiehlt
Der praktische Teil des Posts ist ein detaillierter Werkzeugkasten. Buterin führt die Hardware-Optionen auf, die er selbst getestet hat:
- NVIDIA RTX 5090 Laptop — rund 90 Tokens/s, die mobile High-End-Option.
- AMD Ryzen AI Max mit 128 GB Unified Memory — rund 51 Tokens/s, interessant wegen des grossen Speichers.
- NVIDIA DGX Spark — enttäuschend für den Preis, wird nicht empfohlen.
- Hardware-Pooling — er empfiehlt explizit, sich mit vertrauten Personen an einer statischen IP zusammenzuschliessen, wenn die Einzelinvestition zu hoch ist.
Softwareseitig läuft bei ihm NixOS als reproduzierbares, deklaratives Betriebssystem. Für die Inferenz nutzt er llama-server hinter llama-swap, um verschiedene Modelle on-demand zu laden. Für Multimodales kommt ComfyUI zum Einsatz, getestet mit Qwen-Image und Hunyuan Video 1.5. Sein Arbeitspferd-Modell: Qwen 3.5:35B, weil es in seiner Praxis die beste Balance zwischen Geschwindigkeit und Fähigkeiten liefert.
Vier Mechanismen ziehen sich durch seine Architektur:
- Local-first — Inferenz bleibt auf eigener Hardware.
- Umfassendes Sandboxing — gefährliche Operationen isoliert, damit manipulierte Inhalte den Host nicht kompromittieren können.
- Substitution von Abhängigkeiten — lokale KI ersetzt Third-Party-Bibliotheken, wo möglich, und reduziert so die Angriffsfläche.
- Air-gapped fähig — Betrieb ohne Netzverbindung ist vorgesehen.
Buterin selbst fasst das nüchtern zusammen: "a starting point for a space that desperately needs to exist, not a description of a finished product."
Wo Freshlabs Ansatz sich unterscheidet
Wir bauen seit 2024 dasselbe Grundprinzip auf anderer Hardware. Unsere Standardkonfiguration für KMU ist der Mac Studio M3 Ultra, nicht die RTX 5090. Als Inferenz-Runtime nutzen wir Ollama (und punktuell MLX direkt), nicht llama-server/llama-swap. Als Betriebssystem läuft macOS, nicht NixOS.
Das sind echte Unterschiede, keine Kosmetik — und sie haben Gründe:
- Eine Box statt Rack — der Mac Studio ist ein einziges Gerät. Kein ATX-Gehäuse, kein Tower, kein separates Netzteil mit 1000 W. Für ein Büro in München oder Palma ist das ein Unterschied, der über Akzeptanz entscheidet.
- Geräusch und Wärme — die Kühlung im Mac Studio ist praktisch lautlos. Ein RTX-5090-System unter Last ist hörbar, und es heizt den Raum.
- Weniger Treiber-Fragilität — Apples Toolchain für Apple Silicon ist eng integriert. CUDA-Stack plus NixOS-Konfiguration plus Kernel-Modul-Updates ist ein fähigkeitsabhängiges Umfeld, das bei vielen KMU-Kunden schlicht nicht vorhanden ist.
- Unified Memory bis 192 GB — der Mac Studio M3 Ultra lässt sich bis 192 GB konfigurieren, zu einem Preis von rund 5.800 Euro für die Hardware allein. Das ist genug Kopfraum, um Modelle in der 70B–120B-Klasse lokal zu betreiben, ohne die Komplexität von Multi-GPU-Setups.
- Lebenszyklus — Apples 5–7-Jahres-Horizont für Sicherheitsupdates und die geschlossene Firmware-Kette sind für GmbH-Compliance-Audits einfacher zu dokumentieren als ein selbstgerollter NixOS-Build.
Wir halten Buterins Stack für technisch exzellent — aber er ist gebaut für jemanden, der NixOS liest wie andere Leute Zeitung. Unser Stack ist gebaut für den Geschäftsführer einer 40-Personen-Firma, der ein Gerät ins Rack schiebt und will, dass es läuft.
Die eigentliche Übereinstimmung
Die Detailunterschiede — RTX gegen M3 Ultra, NixOS gegen macOS, llama-server gegen Ollama — verdecken leicht, worin die beiden Architekturen wirklich übereinstimmen. Und das ist das Wichtige:
- Inferenz bleibt lokal. Keine Prompts, keine Dokumente, keine Embeddings verlassen das Gerät.
- Sandboxing ist Pflicht, nicht Kür. Agent-Tätigkeiten laufen in isolierten Umgebungen, nicht mit vollen Rechten am Host.
- Keine Cloud-Exfiltration. Weder während des Betriebs noch "für Trainingszwecke später".
- Compliance-ready by design. DSGVO, EU AI Act, branchenspezifische Aufsichten — alle diese Regime werden einfacher, wenn die Daten nie den Hoheitsbereich des Unternehmens verlassen.
Für deutsche KMU bedeutet das konkret: Die KI-Infrastruktur sitzt im eigenen Serverraum oder in einem lokalen Rechenzentrum des Vertrauens. Die Auftragsverarbeitungsverträge werden kürzer. Die Antwort auf "wo wird mein Input verarbeitet?" lautet: hier, im Gebäude. Förderprogramme wie der BAFA-Digitalbonus oder KfW-Digitalisierungskredite lassen sich auf diese Art von Investition sauberer anwenden, weil es eine echte Capex-Position gibt — Hardware, Einrichtung, Schulung — und keinen laufenden Cloud-Abfluss.
Buterins Post ist aus unserer Sicht deshalb wertvoll, weil er eine zweite, unabhängige Stimme ist. Jemand, der aus einer völlig anderen Richtung kommt — Ethereum, Kryptographie, Systems Research — landet bei derselben Architektur. Das ist Konvergenz, nicht Zufall. Lokale Inferenz, Sandboxing und Trust-Minimierung sind keine Nische mehr, sondern der vernünftige Default für ernsthafte KI-Nutzung.
Mehr zum Thema Datensouveränität im Detail haben wir unter /data-sovereignty.html gesammelt. Eine technische Übersicht zu lokalen Modellen findet sich unter /local-ai.html.
Nächster Schritt
Wenn Sie Buterins Post gelesen haben und fragen, wie sich dieselbe Architektur in einer deutschen GmbH mit 20 bis 200 Mitarbeitern umsetzen lässt — inklusive Hardware, Einrichtung, Schulung und Compliance-Dokumentation — starten Sie mit unserem Pilotprojekt-Paket: Pilotprojekt anfragen.