Ubuntu-Pinning und NVIDIA-Treiberverwaltung für KI-Server

Wenn Sie für einen KI-Server verantwortlich sind, auf den sich andere verlassen, ist die wahrscheinlichste Ursache Ihres nächsten Ausfalls kein Hardwaredefekt, kein Modellfehler und kein Stromereignis. Es ist ein apt-get upgrade — von Ihnen oder Ihrer Distribution im Hintergrund ausgeführt —, das einen neuen Kernel nachzieht, gegen den das NVIDIA-DKMS-Modul nicht sauber neu gebaut wurde, sodass nvidia-smi beim nächsten Neustart Failed to initialize NVML: Driver/library version mismatch meldet. Das ist der mit Abstand häufigste Kentino-Supportfall, nachdem ein Server zwei oder drei Monate gelaufen ist.

In diesem Artikel geht es darum, das zu verhindern. Er behandelt, welches Ubuntu LTS Sie Mitte 2026 wählen sollten, wie Sie den NVIDIA-Treiber so installieren, dass Sie ihn auch nachvollziehen können, wie Sie Treiber und Kernel so pinnen, dass ein unbeaufsichtigtes Upgrade Ihren Stack nicht klammheimlich zerlegt, und wie Sie den Schaden beheben, wenn es doch jemand getan hat.

Zielgruppe ist jeder, der auf einer 4- oder 8-GPU-Maschine sudo tippt, die jahrelang durchlaufen soll.

Warum überhaupt Ubuntu LTS

Es gibt technisch ausgereifte Linux-Distributionen jenseits von Ubuntu — Debian stable, RHEL, Rocky, AlmaLinux, openSUSE Leap. Keine davon ist falsch, einige sind sogar besser konstruiert. Für KI-Server empfehlen wir trotzdem Ubuntu LTS, aus vier Gründen, die nichts mit Eleganz zu tun haben.

NVIDIA testet zuerst gegen Ubuntu LTS. Seine apt Repositories liefern cuda-keyring Pakete ausdrücklich für ubuntu2204, ubuntu2404, und (seit Frühjahr 2026) ubuntu2604. Der Installationsleitfaden für den Treiber nennt Ubuntu LTS mit Versionsnummer; andere Distributionen tauchen im hinteren Teil des Dokuments auf.

Das Container-Ökosystem setzt Ubuntu voraus. Jedes NGC-Image (nvcr.io/nvidia/pytorch, nvcr.io/nvidia/tritonserver, TensorRT-LLM) baut auf einem Ubuntu-LTS-Unterbau auf. Die Host-Distribution muss nicht zum Container passen, aber wenn sie es tut, decken sich die Annahmen über Kernel und Userspace sauber.

Die meisten KI-Werkzeuge von Drittanbietern setzen in ihrer README Ubuntu voraus. vLLM, llama.cpp, SGLang, die Build-Anleitungen zu FlashAttention, die Beispiele zu Hugging Face Accelerate — alles gegen Ubuntu geschrieben und getestet. RHEL funktioniert; Sie werden nur derjenige sein, der die Issues aufmacht, wenn es das nicht tut.

Die Zahl der Menschen, die Ihr Problem schon hatten, ist unter Ubuntu am größten. Wenn nvidia-smi um 02:00 Uhr Unsinn ausgibt, sind die ersten drei Treffer auf Stack Overflow Ubuntu-spezifisch. Das zählt mehr, als es sollte.

Debian und RHEL sind keine schlechte Wahl für einen KI-Server. Sie bedeuten lediglich eine kleinere Testfläche, langsamere Validierungszyklen bei NVIDIA und eine kleinere Community, wenn etwas schiefgeht. Wenn Sie einen triftigen organisatorischen Grund für eine davon haben — Air-Gap mit FedRAMP, eine bestehende RHEL-Standortlizenz, ein Sysadmin-Team aus dem Debian-Umfeld —, nehmen Sie sie. Andernfalls bleibt Ubuntu LTS die Voreinstellung.

22.04 vs. 24.04 vs. 26.04 im Mai 2026

Drei LTS-Releases werden derzeit aktiv unterstützt. Die ehrliche Matrix:

Ein paar Punkte aus dieser Tabelle verdienen Hervorhebung.

22.04 hat weltweit noch immer die größte installierte Basis, und NVIDIAs Validierungs-Pipeline hat damit die längste Historie. Wenn Sie eine funktionierende 22.04-Flotte betreiben, upgraden Sie nicht in Panik. Sie wird bis April 2027 vollständig mit Standard-Updates versorgt, und Ubuntu Pro verlängert die Sicherheitswartung bis 2032, falls Sie das brauchen. Wenn Sie Mitte 2026 jedoch einen neuen Server einbauen, wählen Sie Ihr Betriebssystem für die nächsten vier bis fünf Jahre. 22.04 hat nur noch ein Jahr Standard-Support. Fangen Sie damit nicht an.

24.04 ist 2026 der Sweet Spot für produktive KI-Arbeit. Es hat zwei Jahre Bugfixes und HWE-Kernel-Revisionen hinter sich, jeder NVIDIA-Treiber-Branch ab R535 hat Pakete in Produktionsqualität im ubuntu2404 Repository von NVIDIA, jedes NGC-Image führt 24.04 als unterstützte Basis, und bis zum Ende des Standard-Supports im April 2029 bleibt Zeit. Genau das setzen wir heute auf neuen Kentino-Builds ein.

26.04 ist brandneu. Es liefert R595 als Standardtreiber im offiziellen Ubuntu-Repository, enthält erstmals CUDA in den Haupt-Repos und bringt spürbare Verbesserungen beim Zusammenspiel von Wayland und NVIDIA — relevant für Desktops, völlig belanglos für Headless-Inferenzserver. Das Risiko für einen KI-Server ist das Timing: In den ersten drei bis vier Monaten nach einem .0 LTS-Release verschieben sich die Empfehlungen von ubuntu-drivers sowie das Verhalten der DKMS-Module, und NVIDIAs eigenes Repository braucht einige Zyklen, um jeden Treiber-Branch vollständig gegen den neuen Kernel zu validieren. Das Muster vergangener LTS-Releases (20.04, 22.04, 24.04) lautet: Erst mit dem ersten Point-Release — 26.04.1 im August 2026 — werden Produktiv-Deployments sinnvoll. Wenn Sie warten können, warten Sie. Wenn nicht, lassen Sie zwei Wochen lang einen Dauertest laufen, bevor Sie etwas Wichtiges darauf legen.

Die Installationswege für den Treiber

Es gibt drei Wege, den NVIDIA-Treiber auf eine Ubuntu-Maschine zu bekommen. Sie sind nicht gleich gut.

ubuntu-drivers install ist der bequeme Weg. Canonical pflegt ein Werkzeug, das Ihre Hardware inspiziert, einen aus seiner Sicht empfohlenen Treiber-Branch auswählt und das passende Paket aus dem Ubuntu-Archiv installiert. Es übernimmt die Secure-Boot-Signierung für Sie (mit Canonicals Schlüssel), kennt HWE-Kernel und funktioniert auf einem Desktop mit einer einzelnen Consumer-GPU tadellos. Auf einem KI-Server ist es der fragile Weg: Der empfohlene Branch kann sich zwischen Versionen des Pakets ubuntu-drivers-common ändern, die Version, die Sie bei apt update bekommen, hängt davon ab, was Ubuntu diese Woche paketiert hat, und Sie haben weniger Kontrolle darüber, welche Treiber-Minorversion genau auf der Platte liegt. Nehmen Sie es für das Notebook. Nicht für den Server.

apt aus NVIDIAs CUDA-Repository ist der manuelle, dafür kontrollierbare Weg. Sie fügen NVIDIAs Paket cuda-keyring hinzu, das die richtige apt Quelle für Ihre Ubuntu-Version einrichtet, und installieren dann genau die Pakete, die Sie haben wollen — cuda-drivers-580, nvidia-driver-580, nvidia-dkms-580, keine Überraschungen. NVIDIA kontrolliert die Paketierung, Sie kontrollieren die Version. Das ist die Kentino-Standardwahl.

Der .run Installer von developer.nvidia.com schreibt Dateien nach /usr/local, verwaltet seine eigenen Kernelmodul-Rebuilds und integriert sich überhaupt nicht mit apt — er ist nur in zwei engen Fällen die richtige Antwort: brandneue Hardware, deren benötigter Treiber-Branch es noch nicht in das apt Repository geschafft hat, oder eine Workstation, auf der Sie aktiv am Treiber entwickeln oder ihn debuggen. Sonst ist er die falsche Antwort. Er kämpft gegen DKMS, wird von apt-mark holdnicht erfasst und geht beim nächsten Kernel-Update still kaputt, weil der Rebuild-Pfad nun manuell ist.

Konkret sieht die Kentino-Standardsequenz auf einem frisch installierten 24.04-Server so aus:

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-keyring_1.1-1_all.deb
sudo dpkg -i cuda-keyring_1.1-1_all.deb
sudo apt update

# Den gewünschten Treiber-Branch installieren, per Nummer.
sudo apt install -y cuda-drivers-580 nvidia-dkms-580
sudo reboot

Nach dem Neustart sollte nvidia-smi den Treiber 580.x und die maximal unterstützte CUDA-Version melden (CUDA 13 bei R580). Das ist die komplette Installation. Beachten Sie, was nicht darin vorkommt: kein cuda Metapaket, kein cuda-toolkit-13-0 (nur nötig, wenn Sie CUDA-Code auf dem Host kompilieren — siehe L02), kein ubuntu-drivers. Sie haben die Version gewählt, Sie haben die Version installiert, Sie wissen, was auf der Platte liegt.

Die Treiber-Branches, die 2026 zählen

NVIDIA liefert seine Linux-Treiber in Branches mit jeweils eigenen Support-Zeitfenstern. Stand Mitte 2026:

R580 ist 2026 die richtige Voreinstellung. Er unterstützt jede GPU der Kentino-Produktlinie (5090, 4090, RTX Pro 6000 Blackwell in beiden Ausführungen, L40, L4) einschließlich der Compute Capability sm_120 der Blackwell-Architektur, und er bringt native CUDA-13-Unterstützung mit — genau das, worauf jedes aktuelle Release von vLLM, PyTorch 2.10/2.11 und TensorRT-LLM abzielt. R570 ist die konservative LTSB-Wahl, wenn Sie eine Flotte aus Ada-Karten (4090 / L40 / L4) betreiben, die die neuesten Funktionen nicht braucht, und einen Wechsel des Treiber-Branch noch ein Jahr aufschieben wollen. R595 liefert Ubuntu 26.04 standardmäßig aus, und es ist das Richtige für allerneueste Hardware; auf einem Server, der nur mit dem läuft, was heute in der Kentino-Produktlinie steht, ist R580 konservativer und funktional gleichwertig.

Der Dreiertanz aus Treiber-, CUDA- und PyTorch-Version

Drei unabhängige Versionen müssen zusammenpassen. Sie stapeln sich so:

PyTorch-Wheel (z. B. torch==2.11.0+cu130)
        │  bringt eigene CUDA-Runtime, cuDNN und NCCL im Wheel mit
        ▼
CUDA-Runtime-Version (hier: 13.0)
        │  der Treiber muss diese CUDA-Version oder neuer unterstützen
        ▼
NVIDIA-Treiber-Branch (hier: R580 → unterstützt CUDA 13.x)

Die Regel lautet: Der Treiber unterstützt eine maximale CUDA-Runtime-Version. Alles, was innerhalb derselben Hauptversion älter ist als dieses Maximum, läuft. R580 (max. CUDA 13.x) führt also PyTorch-Wheels aus, die gegen 13.0, 13.1 und 13.2 gebaut wurden; Wheels gegen ein (hypothetisches) CUDA 14.0 laufen erst, wenn Sie den Treiber-Branch aktualisieren. Ältere Treiber können kein neueres CUDA ausführen — für einige Datacenter-Karten gibt es Forward Compatibility, aber sie ist fragil und keine Betriebsweise, die Sie sich wünschen.

Praktische Übersicht, was auf Kentino-Servern heute läuft:

Ihre Aufgabe ist es, den Treiber festzuzurren und alles darüber daraus folgen zu lassen. Sie müssen auf dem Host überhaupt kein CUDA installieren, wenn Sie alles aus Containern heraus betreiben (und das sollten Sie — siehe L02). Der Host braucht den Treiber und das Container-Toolkit. Mehr nicht.

Pinning — der wertvollste Befehl in diesem Artikel

Sobald der Treiber installiert ist und nvidia-smi zufrieden meldet, pinnen Sie ihn. Pinning heißt, apt anzuweisen, bestimmte Pakete weder zu aktualisieren noch herabzustufen oder zu entfernen — selbst dann nicht, wenn eine Abhängigkeit oder ein Sicherheitsupdate sie sonst anfassen würde. Der Befehl lautet apt-mark hold.

# Den Treiber-Branch pinnen.
sudo apt-mark hold \
  cuda-drivers \
  cuda-drivers-580 \
  nvidia-driver-580 \
  nvidia-driver-580-server \
  nvidia-dkms-580 \
  libnvidia-compute-580 \
  libnvidia-compute-580-server

# Laufenden Kernel und seine Header pinnen — DKMS braucht beide zum Rebuild,
# und ein Kernelsprung, den DKMS nicht verkraftet, kostet Sie genau so die GPU.
RUNNING=$(uname -r)
sudo apt-mark hold "linux-image-${RUNNING}" "linux-headers-${RUNNING}"

# Wenn Sie das HWE-Kernel-Metapaket von Ubuntu nutzen, halten Sie auch das:
sudo apt-mark hold linux-generic-hwe-24.04 linux-image-generic-hwe-24.04 linux-headers-generic-hwe-24.04

# Prüfen.
apt-mark showhold

Damit ist rund die Hälfte aller Anrufe nach dem Muster „mein KI-Server läuft nicht mehr“ erledigt. Wenn apt update && apt upgrade läuft — manuell, aus einem Configuration-Management-Tool oder unter unattended-upgrades —, bewegen sich die gehaltenen Pakete nicht. Sie erscheinen in der Upgrade-Ausgabe unter „kept back“, und Sie können sie in einem Wartungsfenster bewusst prüfen und wieder freigeben, wenn Sie so weit sind.

Ein paar Fallstricke. Man hält nvidia-driver-580 und vergisst cuda-drivers-580, das eigentliche Metapaket im CUDA-Repo. Wenn cuda-drivers-580 aktualisiert wird, weil eine transitive Abhängigkeit ein neueres Point-Release verlangt, zieht es ein neues nvidia-dkms-580 mit sich, und der Pin ist verloren. Listen Sie beide auf. Oder man hält das Kernel-Image, aber nicht die Header, der Kernel aktualisiert sich wegen eines Metapakets trotzdem, und DKMS findet beim Rebuild keine Header — nvidia-smi funktioniert bis zum Neustart, danach nicht mehr. Halten Sie Image und Header immer gemeinsam.

Die Fallstricke bei Kernel und DKMS

DKMS (Dynamic Kernel Module Support) ist das System, das Out-of-Tree-Kernelmodule bei jeder Kerneländerung neu baut. Das NVIDIA-Paket nvidia-dkms-XXX registriert den Treiber als DKMS-Modul, sodass ein von apt verwaltetes Kernel-Upgrade theoretisch einen sauberen Modul-Rebuild anstößt und Sie in ein funktionierendes System booten.

In der Praxis scheitern DKMS-Rebuilds auf drei immer wiederkehrende Arten:

Die Kernel-Header sind für den neuen Kernel nicht installiert — häufig dann, wenn das Kernelpaket installiert, das Header-Paket aber durch einen apt-preferences-Pin oder eine eigene Paketauswahl herausgefiltert wurde. Der neue Kernel bootet, das NVIDIA-Modul fehlt, nvidia-smi meldet „NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver.“

Der neue Kernel ist zu neu für den Treiber-Branch. R570 baut gegen den aktuellen 6.14-Kernel nicht sauber, R580 schon. Wenn ein HWE-Sprung Sie auf einen Kernel hebt, gegen den der Treiber-Branch nie getestet wurde, erzeugt DKMS einen Build-Fehler in /var/lib/dkms/nvidia/.../make.log und Sie booten in ein funktionierendes, aber GPU-loses System.

Secure Boot ist aktiv und das neu gebaute Modul ist unsigniert. Bei den über ubuntu-driversinstallierten Paketen übernimmt Canonical die Signierung. Bei NVIDIAs Paketen aus dem CUDA-Repo nicht; dort müssen Sie einen Machine Owner Key (MOK) registrieren und die neu gebauten Module bei jeder Kerneländerung signieren. DKMS kann das mit der richtigen Konfiguration pro Modul automatisch erledigen, aber es muss vor dem ersten Rebuild eingerichtet sein, nicht erst, wenn das System nicht mehr bootet. Wenn Sie Secure Boot nicht brauchen — und auf einem Headless-Inferenzserver in einem abgeschlossenen Rack brauchen Sie es kaum —, deaktivieren Sie es vor der Treiberinstallation in der Firmware und ersparen sich diese ganze Problemklasse.

Das Pinnen des Kernels umgeht alle drei Fälle. Der Kernel ändert sich nicht ohne Ihr Zutun, die Header bleiben passend, das neu gebaute Modul lädt weiterhin. Wenn Sie einen neuen Kernel wirklich wollen — wegen einer CVE oder einer echten Funktion —, tun Sie es bewusst, mit Snapshot und bereit zum Zurückrollen.

Bare-Metal-CUDA — wann es (selten) noch richtig ist

L02 zeigt, dass Bare-Metal-CUDA heute meist die falsche Wahl ist: Container verbergen den Versionstanz rund um CUDA, entkoppeln den Host vom Workload und kosten praktisch keine Leistung. Für ~95% der Installationen stimmt das.

Die Ausnahmen sind eng umrissen. GPU-Profiling auf Kernel-Ebene mit Nsight Systems / Nsight Compute, wo die Container-Schicht genau die Syscalls verdeckt, die Sie interessieren. Treiberarbeit — Vorabversionen von NVIDIA betreiben, Abstürze debuggen, an denen das Kernelmodul selbst beteiligt ist. Streng abgeschottete Air-Gap-Umgebungen, in denen das Ziehen und Verifizieren von OCI-Images aufwendiger ist als ein eingefrorener apt-Mirror. Und eine Handvoll HPC-Standorte, die alles um module load und Bare-Metal-MPI herum gebaut haben und daran nichts ändern wollen.

Für alle anderen gilt: den Treiber auf Bare-Metal installieren, den Host frei von CUDA halten und CUDA in Containern ausführen. Das nvidia-container-toolkit (behandelt in L02) verbindet beides sauber.

Unbeaufsichtigte Upgrades — was erlauben, was blockieren

Das Ubuntu-Paket unattended-upgrades ist gut, und Sie sollten es aktiv lassen. Auf einem vernetzten Server komplett auf Sicherheitsupdates zu verzichten, ist schlimmer als das Risiko eines schiefgelaufenen automatischen Upgrades. Das richtige Muster lautet: Sicherheitsupdates ja, Kernel- und NVIDIA-Pakete nein.

Bearbeiten Sie /etc/apt/apt.conf.d/50unattended-upgrades und ergänzen Sie den Blacklist-Block:

Unattended-Upgrade::Package-Blacklist {
    "linux-image-";
    "linux-headers-";
    "linux-generic";
    "linux-modules-";
    "nvidia-";
    "libnvidia-";
    "cuda";
    "cuda-";
    "libcudnn";
};

apt-mark hold verhindert bereits, dass diese Pakete aktualisiert werden. Die Blacklist ist doppelt genäht — sie macht die Absicht explizit, sie hindert unattended-upgrades daran, überhaupt einen Versuch zu protokollieren, und sie überlebt ein unbedachtes apt-mark unhold eines unerfahrenen Admins. Setzen Sie beides ein.

Prüfen Sie das, indem Sie /var/log/unattended-upgrades/unattended-upgrades.log nach dem nächsten Lauf mit tail verfolgen. Sie sollten sehen, wie Sicherheitspakete durchlaufen und die gehaltenen bzw. gelisteten Pakete ausdrücklich übersprungen werden.

Das Notfall-Playbook „Ich habe dist-upgrade gemacht und jetzt geht nichts mehr“

Jemand hat apt full-upgrade ausgeführt (oder Ihr CM-Tool hat es getan), und nach dem nächsten Neustart sind die GPUs verschwunden. Reihenfolge der Schritte:

1. Booten. Wenn das System nicht startet, halten Sie am GRUB-Prompt Shift / Esc und wählen den vorherigen Kernel aus dem Bootmenü. Prüfen Sie, ob nvidia-smi unter dem alten Kernel funktioniert. Wenn ja, ist der neue Kernel das Problem; pinnen Sie den alten (apt-mark hold linux-image-<old>) und machen Sie weiter.
2. Wenn das System gebootet hat, aber nvidia-smi einen NVML-Mismatch meldet, läuft neuer Userspace gegen ein altes geladenes Modul. Neu starten. Das behebt es fast immer.
3. Wenn nvidia-smi meldet, dass der Treiber nicht geladen ist, prüfen Sie /var/lib/dkms/nvidia/<version>/build/make.log und dmesg | grep -i nvidia. Die häufigsten Ursachen: fehlende Kernel-Header (apt install linux-headers-$(uname -r) dann dkms autoinstall); ein Kernel, der für den Treiber zu neu ist (Kernel herabstufen oder den Treiber-Branch bewusst aktualisieren); Secure Boot, das das unsignierte Modul ablehnt (mokutil --sb-state, dann entweder SB deaktivieren oder einen MOK registrieren).
4. Wenn die Treiberpakete selbst per dist-upgrade in einen unerwünschten Zustand gebracht wurden — etwa weil das Metapaket R585 über Ihr gepinntes R580 gezogen hat, nachdem jemand den Hold entfernt hatte —, purgen und neu installieren: sudo apt purge '*nvidia*' '*cuda*' && sudo apt autoremove, dann die Installation aus dem CUDA-Repo in der von Ihnen gewünschten Version wiederholen und anschließend die Holds neu setzen.
5. Wenn Sie einen Snapshot haben — und den sollten Sie haben, siehe unten —, spielen Sie ihn zurück. Das sind zwanzig Minuten zurück zu einem bekannt guten Stand statt vier Stunden Fehlersuche.

Snapshot, bevor Sie Treiber oder Kernel anfassen

Wie auch immer Ihr Storage-Layout aussieht: Legen Sie vor jedem Treiber- oder Kernel-Eingriff einen Snapshot an. ZFS-Nutzer (/ auf ZFS oder als eigenes Dataset) bekommen das geschenkt mit zfs snapshot rpool@pre-driver-upgrade-2026-05-15. LVM-Nutzer mit Thin Pools können lvcreate --snapshotnutzen. ext4-Nutzer ohne LVM bleiben bei Vollbackups; das ist einer der Gründe, warum wir das Dateisystem-Layout in L04 behandeln.

Die Disziplin, die sich auszahlt: Fassen Sie Treiber, CUDA-Pakete oder Kernel nie an, ohne in den fünf Minuten davor einen Snapshot angelegt zu haben. Ein Snapshot kostet Sekunden. Keinen zu haben, wenn ein Upgrade schiefgeht, kostet einen halben Tag Ausfall und jemandes Feierabend.

Der LTS-Upgrade-Pfad

LTS-zu-LTS-Upgrades erscheinen bei Ubuntu alle zwei Jahre; für KI-Server empfehlen wir, jedes zweite zu überspringen. Der Pfad lautet:

22.04  ──(23.x auslassen, 24.04 auslassen wenn produktionsstabil)──▶  26.04
24.04  ──(25.x auslassen, 26.04 auslassen wenn produktionsstabil)──▶  28.04

Die Begründung: Ein LTS-Upgrade auf einem KI-Server ist teuer (Treiber neu validieren, Container-Images neu testen, oft Integrations-Benchmarks erneut fahren), der Nutzen eines einzelnen statt eines doppelten Schritts ist gering, und Ubuntus Werkzeuge für LTS-zu-LTS-Upgrades unterstützen das Überspringen vollständig. Planen Sie das Upgrade, legen Sie ein Wartungsfenster fest, erstellen Sie einen Snapshot, führen Sie do-release-upgradeaus, lassen Sie eine Woche lang einen Dauertest laufen und verschieben Sie dann die Workloads zurück. Der direkte Weg von 22.04 → 26.04 wird unterstützt und ist das, was die meisten Kentino-Kunden Ende 2026 oder 2027 tun werden.

Was Sie vermeiden sollten: In-Place-Upgrades mitten im Entwicklungssprint, Upgrades ohne Snapshot, ein Upgrade und unmittelbar danach ein dist-upgrade des NVIDIA-Stacks. Ändern Sie immer nur eine Sache.

---

Dies ist Teil des Kentino Wiki, einer Referenzreihe über KI-Rechenleistung, Robotik und die Systeme, die beides verbinden. Kommentare und Korrekturen gerne an info@kentino.com.