NixOS auf dem DGX Spark: Reproduzierbares KI-Homelab

NixOS auf dem DGX Spark: So baust du ein reproduzierbares KI-Homelab

Lesezeit: ca. 10 Minuten

Der NVIDIA DGX Spark ist im Homelab angekommen — ein kompakter KI-Rechner auf Basis des GB10-Superchips, der einen Arm-Prozessor und eine Blackwell-GPU vereint und sich 128 GB LPDDR5X als gemeinsamen Speicher zwischen CPU und GPU teilt.

Genau dieser Unified-Memory-Ansatz macht das Gerät für lokale Inferenz interessant: Große Modelle, die auf einer klassischen Consumer-GPU am VRAM scheitern, passen hier in den geteilten Adressraum. Ausgeliefert wird der Spark mit NVIDIAs eigenem, Ubuntu-basiertem DGX OS. Wer aber ein Homelab betreibt, das nach jedem Reboot und auf jeder zweiten Maschine exakt gleich aussehen soll, stößt mit imperativ konfiguriertem Ubuntu schnell an Grenzen.

Hier setzt NixOS an. Mit dem quelloffenen Community-Projekt nixos-dgx-spark von Graham Bennett — vorgestellt auf Hacker News und in einem Lightning-Talk auf der Planet-Nix-Konferenz — lässt sich NixOS auf der aarch64-Hardware betreiben, laut Projektbeschreibung auch auf dem baugleichen ASUS Ascent GX10.

Dieser Ratgeber für aimageddon.de sortiert den Weg von der ARM64-Installation über die deklarative Treiber-Einrichtung bis zum containerisierten Workload und dem laufenden Betrieb. Wenn du noch bei der Frage stehst, welche Hardware überhaupt ins Homelab gehört, klärt das unser Vergleich Homelab-KI-Server bauen oder kaufen. Hier geht es um die Einrichtung.

Warum NixOS für ein KI-Homelab?

Reproduzierbarkeit statt „läuft bei mir“

Der Kern von NixOS ist die deklarative Konfiguration. Dein gesamtes System — Pakete, Kernel-Module, Dienste, Nutzer, Netzwerk — steht in Nix-Ausdrücken, üblicherweise einer configuration.nix plus zugehöriger Flake. Was nicht im File steht, existiert nicht.

Für ein KI-Homelab ist das mehr als Kosmetik. Ein Treiber-Update, das die CUDA-Umgebung zerlegt, ist bei NixOS ein Rollback per nixos-rebuild –rollback — der vorherige Generationszustand liegt weiterhin im Bootloader-Menü. Und wenn du eine zweite Maschine dazustellst, kopierst du die Konfiguration, statt eine Installationsanleitung abzuarbeiten.

Der Stand: Community-Projekt, kein NVIDIA-Support

Ein Punkt gehört klar gesagt: nixos-dgx-spark ist ein Community-Projekt, kein von NVIDIA unterstützter Pfad. Offiziell supported ist DGX OS. Wenn ein Firmware-Update, ein Kernel-Sprung oder eine neue CUDA-Version die Grace-Blackwell-Plattform verändert, kann es dauern, bis das im Nix-Ökosystem nachgezogen ist.

Für ein Produktivsystem mit Support-Anspruch ist das relevant. Für ein Homelab, in dem Basteln Teil des Zwecks ist, ist es der normale Preis für volle Kontrolle. Wie weit das Projekt zum Zeitpunkt deiner Installation ist, liest du direkt in der Projekt-Dokumentation nach — das ändert sich schneller, als ein Ratgeber es abbilden kann.

NixOS auf ARM64 installieren

Das richtige aarch64-Image

Der GB10-Superchip ist eine Arm-Plattform — du brauchst ein aarch64-linux-Image, kein x86-Image. NixOS liefert offizielle ARM64-Builds; für den Spark kommen die hardwarespezifischen Bausteine aus dem nixos-dgx-spark-Flake dazu, das Kernel-Parameter, Firmware und Boot-Setup mitbringt.

Ein Stolperstein auf solcher Hardware ist regelmäßig der Boot-Pfad: UEFI-Reihenfolge, Secure Boot und die Frage, ob die interne NVMe direkt bootet. Prüf im Firmware-Menü, dass NixOS als Boot-Eintrag auftaucht. Die genauen Schritte hängen an der jeweiligen UEFI-Version und stehen im README des Projekts — arbeite sie in der dort dokumentierten Reihenfolge ab, statt sie aus einer allgemeinen Anleitung zu raten.

Die erste configuration.nix

Nach der Installation definierst du das Grundsystem deklarativ. Für den kopflosen Betrieb brauchst du zuerst drei Dinge: feste Netzwerkkonfiguration, SSH-Zugang und Boot-Einstellungen.

Ein SSH-Server wird über services.openssh.enable = true; aktiviert, dein Public Key landet unter users.users.<name>.openssh.authorizedKeys.keys. Passwort-Login schaltest du besser ab. Ab hier arbeitest du remote — jede weitere Änderung ist ein Edit an der Konfiguration plus ein nixos-rebuild switch.

NVIDIA-Treiber und CUDA deklarativ

hardware.nvidia und cudaSupport

NixOS bindet den proprietären NVIDIA-Treiber über das Modul hardware.nvidia ein, während CUDA-fähige Pakete über nixpkgs.config.cudaSupport = true; gebaut werden. Damit wird die CUDA-Toolchain Teil der Systembeschreibung — inklusive der Möglichkeit, die exakte Version über deine Flake-Inputs zu pinnen.

Ein Praxishinweis zum Bauen: Aktivierst du cudaSupport global, werden abhängige Pakete aus dem Quellcode gegen CUDA gebaut, was Zeit und Speicher kostet. Ein Binär-Cache spart erheblich — der offizielle Cache deckt aarch64-CUDA-Pakete allerdings nicht so lückenlos ab wie die x86-Variante. Prüf vor dem ersten großen Rebuild, was dein Cache tatsächlich vorbaut.

Grace-Blackwell: die Fallstricke

Die Kombination aus Arm-CPU und Blackwell-GPU ist neuer als die meisten x86-Setups, für die Nix-Rezepte geschrieben wurden. Zwei Dinge sind erfahrungsgemäß heikel:

• Die Treiberversion muss die Blackwell-Generation kennen — ein zu alter Treiber sieht die GPU schlicht nicht.
• Die aarch64-CUDA-Unterstützung im Nixpkgs-Baum ist jünger und lückenhafter als die x86-Variante; einzelne Pakete brauchen Anpassungen.

Genau solche plattformspezifischen Überschreibungen bündelt das nixos-dgx-spark-Flake — sie abzunehmen ist der eigentliche Mehrwert gegenüber einem Setup von null. Halte dich an die dort gepinnten Versionen, statt eine Treiber-Version von Hand zu wählen.

KI-Workloads containerisiert bereitstellen

Ollama, vLLM und PyTorch

Sobald CUDA läuft, geht es an die Workloads. Zwei Wege haben sich etabliert: Ollama als Dienst, in NixOS direkt über services.ollama mit GPU-Beschleunigung deklarierbar — gut für schnelles Ausprobieren. Und vLLM für hohen Durchsatz und paralleles Serving, meist als Container. PyTorch nutzt du, wenn du selbst trainierst oder feintunst.

Die 128 GB Unified Memory sind der eigentliche Hebel: Sie erlauben Modelle, die auf einer 16- oder 24-GB-Consumer-GPU nicht laden. Diese Maschine kaufst du für Kapazität, nicht für Spitzendurchsatz. Die Bandbreite von LPDDR5X liegt unter der von HBM-Speicher, und das begrenzt die Tokenrate bei großen Modellen. Wie sich das gegen andere Hardware-Klassen rechnet, zeigt unser Vergleich Mini-PC gegen Desktop-GPU.

Konkrete Token-pro-Sekunde-Werte hängen stark von Modell, Quantisierung und Kontextlänge ab — verlässliche Zahlen bekommst du nur aus eigenen Benchmarks, nicht aus Datenblättern.

GPU-Passthrough in Container

Damit ein Container die GPU sieht, brauchst du das nvidia-container-toolkit, in NixOS über hardware.nvidia-container-toolkit.enable = true; aktivierbar. Es reicht GPU-Devices und Treiber-Bibliotheken in die Container-Laufzeit durch — egal ob Docker, Podman oder OCI-Images aus einem Nix-Flake.

Der konsequent reproduzierbare Weg: Das Container-Image selbst mit Nix bauen, sodass auch die Laufzeitumgebung im Container gepinnt ist.

Der Lizenz-Hinweis, der oft fehlt

„Open“ ist bei KI-Modellen kein einheitliches Etikett. Ein Modell, das du über Ollama oder vLLM lädst, kann unter einer Lizenz stehen, die kommerzielle Nutzung, bestimmte Einsatzzwecke oder ganze Regionen ausschließt.

Für ein privates Homelab ist das meist unkritisch — aber wenn aus dem Bastelprojekt ein kommerzieller Dienst wird, lies vorher die Lizenz des jeweiligen Modells. Das ist ein Hinweis, keine Rechtsberatung.

Reproduzierbarkeit sichern: Flakes und Deployment

Gepinnte Dependencies

Der Schritt von „läuft“ zu „läuft überall gleich“ sind Flakes. Eine flake.lock pinnt jede Eingabe — Nixpkgs, das dgx-spark-Flake, deine Overlays — auf einen exakten Commit-Hash. Dieselbe flake.lock ergibt dasselbe System, heute wie in einem Jahr. Updates sind ein bewusster Akt (nix flake update), kein schleichender Drift.

Konkret verwaltest du die Systemkonfiguration als nixosConfigurations-Attribut und wendest sie mit nixos-rebuild switch –flake .#hostname an. Steht die Flake im Git-Repository, ist deine komplette Infrastruktur versioniert.

Rollout über mehrere Maschinen

Bei mehr als einer Maschine lohnt ein Deployment-Werkzeug. deploy-rs rollt Flake-basierte Konfigurationen auf entfernte Hosts aus und macht automatisch einen Rollback, wenn der neue Zustand nicht erreichbar ist — ein sinnvolles Sicherheitsnetz bei kopflosem Betrieb.

Betrieb: Monitoring und Fernzugriff

GPU-Auslastung im Blick

Ein KI-Homelab ohne Monitoring läuft blind. Für NVIDIA-Hardware ist der dcgm-exporter der Standard: Er stellt GPU-Metriken — Auslastung, Speicher, Temperatur, Leistungsaufnahme — im Prometheus-Format bereit.

Gerade beim Unified Memory des GB10 ist die Speicherauslastung die Kennzahl, die du im Auge behalten solltest — sie entscheidet, welche Modellgröße noch passt.

Sicherer Zugriff von außen

Kein KI-Homelab gehört ungeschützt ins offene Internet. Ein bewährter Weg ist Tailscale (über services.tailscale.enable), das die Maschine in ein privates WireGuard-basiertes Mesh hängt — du erreichst den Spark von unterwegs, ohne einen Port nach außen zu öffnen.

Brauchst du Web-Oberflächen, setz einen Reverse Proxy davor und exponiere ihn ausschließlich im Tailnet. Zugangsdaten und Tokens gehören verschlüsselt verwaltet — etwa über sops-nix oder agenix — und nicht im Klartext in eine Flake, die womöglich in einem öffentlichen Repo landet.

Häufige Fehler vermeiden

Praktische Handlungsempfehlungen August 2026

• Projekt-README und Discourse-Thread vor der Installation lesen. Beides ändert sich schneller als jede Anleitung – dort steht der aktuelle Stand.
• Mit SSH und Netzwerk anfangen, dann remote weiterarbeiten. Die erste Konfiguration braucht nur drei Dinge.
• Die im Flake gepinnten Treiber- und CUDA-Versionen übernehmen, statt eigene zu wählen.
• Vor dem ersten großen Rebuild den Binär-Cache prüfen – das entscheidet über Minuten oder Stunden.
• Secrets von Anfang an über sops-nix oder agenix verwalten, nicht später nachrüsten.
• Tailscale einrichten, bevor du Dienste startest – nicht danach.
• dcgm-exporter und Prometheus mit aufsetzen. Ohne Speicher-Metrik tappst du beim Unified Memory im Dunkeln.
• Eigene Benchmarks fahren, statt Datenblattwerte zu übernehmen.

Fazit

Der DGX Spark und NixOS passen aus einem Grund gut zusammen: Beide zielen auf Kontrolle statt Bequemlichkeit. Die Flake beschreibt das komplette System, der Rollback liegt im Bootloader, und die zweite Maschine ist ein Kopiervorgang statt einer Installationsnacht.

Der Preis dafür steht am Anfang: Du verlässt den offiziell unterstützten Pfad. Wenn NVIDIA an Firmware oder CUDA schraubt, wartest du auf die Community — und für ein Produktivsystem mit Support-Anspruch ist das das falsche Setup.

Und eine Erwartung sollte stimmen: Die 128 GB Unified Memory sind eine Kapazitäts-, keine Geschwindigkeitsansage. Modelle, die anderswo am VRAM scheitern, laufen hier — nur eben nicht mit der Tokenrate einer Rechenzentrums-GPU.

Quellen und weiterführende Informationen

• nixos-dgx-spark (github.com) — Quellcode, README und aktuelle Installationsanleitung des Community-Projekts von Graham Bennett; maßgeblich für Boot-Schritte und gepinnte Treiberversionen.
• Hacker News (news.ycombinator.com) — „Show HN“-Ankündigung des Projekts mit Diskussion und dem Hinweis auf den ASUS Ascent GX10.
• NixOS Discourse (discourse.nixos.org) — laufender Erfahrungsaustausch zur NixOS-Installation auf dem DGX Spark.
• NixOS-Handbuch und Nixpkgs-Dokumentation (nixos.org) — Referenz zu hardware.nvidia, cudaSupport, Flakes und dem Container-Toolkit.
• NVIDIA (nvidia.com) — offizielle Spezifikationen zu GB10, DGX Spark und DGX OS sowie zum Data Center GPU Manager.
• Hardwareluxx (hardwareluxx.de) und heise online / c’t (heise.de) — deutschsprachige Praxisberichte und Einordnung zum DGX Spark.
• Tailscale (tailscale.com), deploy-rs, sops-nix und agenix — Projektdokumentationen der eingesetzten Werkzeuge.

Haftungsausschluss

Allgemeiner Hinweis: Dieser Artikel auf aimageddon.de dient der allgemeinen Information rund um den Aufbau eines reproduzierbaren KI-Homelabs und ersetzt keine individuelle technische oder rechtliche Beratung; jede Systemumgebung bringt eigene Voraussetzungen mit. Da sich Treiber, Firmware-Stände, NixOS-Pakete und die Kompatibilität einzelner Komponenten im KI-Hardware-Umfeld fortlaufend weiterentwickeln, spiegelt der Beitrag den Kenntnisstand zum Zeitpunkt der Veröffentlichung wider — einzelne Konfigurationsschritte oder Versionsangaben können später überholt sein. Prüf vor eigenen Umsetzungsschritten die aktuelle Projekt- und Herstellerdokumentation.

Zum Community-Status und zu Herstellervorgaben: Das beschriebene Projekt ist eine Community-Arbeit ohne Herstellersupport; offiziell unterstützt wird das mitgelieferte Betriebssystem. Der Austausch des vorinstallierten Systems kann Support-Ansprüche und Garantiezusagen des Herstellers berühren — kläre das vorab, wenn dir Support wichtig ist. Alle beschriebenen Schritte erfolgen auf eigene Verantwortung; Eingriffe in Firmware-Einstellungen, Bootloader und Treiberkonfiguration können zu einem nicht mehr startfähigen System führen. Sichere Daten und dokumentiere den Ausgangszustand, bevor du beginnst.

Sicherheit und Modell-Lizenzen: Ein selbst betriebener Inferenz-Dienst sollte nicht ungeschützt aus dem Internet erreichbar sein; Netzwerktrennung, Rechte-Minimierung und verschlüsselte Verwaltung von Zugangsdaten sind Voraussetzung, keine Kür. Für Modelle, die du lokal betreibst, gelten die Lizenzbedingungen des jeweiligen Anbieters — sie können kommerzielle Nutzung, bestimmte Einsatzzwecke oder Regionen ausschließen; prüf den Lizenztext im Original. Werden personenbezogene Daten verarbeitet, bleiben DSGVO und Bundesdatenschutzgesetz anwendbar, auch wenn die Verarbeitung lokal erfolgt.

Verbraucherrechte und Affiliate: Erwirbst du Hardware im Fernabsatz, steht dir nach § 312g BGB ein vierzehntägiges Widerrufsrecht zu; seit dem 19. Juni 2026 müssen Unternehmen dafür nach § 356a BGB eine elektronische Widerrufsfunktion bereitstellen. § 312k BGB verpflichtet Anbieter laufender Verträge — etwa Cloud-, Support- oder Wartungsabonnements — zu einem gut sichtbaren Kündigungsbutton. Bei Sachmängeln greifen §§ 437 und 438 BGB mit zweijähriger Frist, § 477 BGB kehrt in den ersten zwölf Monaten die Beweislast zugunsten der Käuferseite um; unionsrechtliche Grundlage ist die Verbrauchsgüterkauf-Richtlinie (EU) 2019/771. Einzelne Verlinkungen können Affiliate-Links über das Amazon-Partnerprogramm oder das Awin-Netzwerk sein; kaufst du darüber ein, erhält aimageddon.de gegebenenfalls eine Provision, ohne dass sich der Preis für dich ändert. Alle genannten Markennamen sind eingetragene Warenzeichen der jeweiligen Inhaber.

👉 NVIDIA DGX OS auf Amazon ansehen

* Produktlinks sind Affiliate-Links. Bei einem Kauf über diese Links erhalten wir eine kleine Provision – für dich entstehen keine Mehrkosten.