ADMIN

2025

05

2025-04-29T12:00:00

Künstliche Intelligenz

SCHWERPUNKT

064

Künstliche Intelligenz

KI

Aufbau einer lokalen KI

Hand anlegen

von Konstantin Agouros

Veröffentlicht in Ausgabe 05/2025 - SCHWERPUNKT

Künstliche Intelligenz ist momentan in aller Munde. Viele Anwender und Entwickler benutzen dabei vorgefertigte Dienste in der Cloud. Wer seine Daten jedoch nicht der Public Cloud anvertrauen möchte, kann KIs auch auf eigener Hardware betreiben. In diesem Artikel zeigen wir die Installationsschritte, um lauffähige Umgebungen auf Basis von Nvidia-GPUs bereitzustellen.

Für IT-Administratoren bedeutet der Aufbau einer lokalen KI zunächst einmal das Beschaffen der entsprechenden Hardware samt Installation derselben, um eine Ablaufumgebung im eigenen Rechenzentrum bereitzustellen. Dabei gibt es einiges zu beachten, damit diese Umgebungen längerfristig stabil laufen können. Denn um die passende Hardware für die Aufgabe zu finden, sollte im ersten Schritt klar sein, was überhaupt mit "KI" gemeint ist. Klassifizierungsaufgaben wie Objekterkennung etwa unterscheiden sich in Trainings- und Anwendungsphasen (beim Anwenden des Modells ist auch von Inferenz die Rede).
Dabei ist das Trainieren sehr rechenintensiv, profitiert also von entsprechender Hardwareunterstützung durch Karten von Nvidia oder AMD, die Inferenz lässt sich aber gegebenenfalls auch von normalen CPUs erledigen. Auch hier gibt es bei Bedarf Zusatzboards wie etwa von Hailo.ai, die den Vorgang effizienter gestalten. Beim Einsatz von Generativer KI (also etwa Sprachmodellen) ist eine Hardwarebeschleunigung auch bei der reinen Anwendung der Modelle zu empfehlen.
Hardware planen
Das komplette Neutrainieren eines solchen Modells dürfte die Rechenzentren der meisten Firmen eher überfordern. In der Planung ist auch dringend der Stromverbrauch zu betrachten – sowohl im eigentlichen Rechner als auch für die zugehörige Kühlung. Eine H100-GPU von Nvidia etwa benötigt unter Volllast bis zu 700 Watt. Dies ist je nach Modell das Doppelte des restlichen Servers. Sind größere Mengen an GPUs angedacht, spielt unter Umständen sogar die Gesamtkapazität des Rechenzentrums eine Rolle. Auch müssen die Lieferanten der Server darauf achten, dass die mitgelieferten Netzteile der Belastung standhalten, jedoch sind bei den meisten professionellen Herstellern inzwischen entsprechende Geräte im Angebot. Lediglich bei einer neuen Generation der Beschleunigerhardware kann sich die Beschaffung etwas verzögern.
Für IT-Administratoren bedeutet der Aufbau einer lokalen KI zunächst einmal das Beschaffen der entsprechenden Hardware samt Installation derselben, um eine Ablaufumgebung im eigenen Rechenzentrum bereitzustellen. Dabei gibt es einiges zu beachten, damit diese Umgebungen längerfristig stabil laufen können. Denn um die passende Hardware für die Aufgabe zu finden, sollte im ersten Schritt klar sein, was überhaupt mit "KI" gemeint ist. Klassifizierungsaufgaben wie Objekterkennung etwa unterscheiden sich in Trainings- und Anwendungsphasen (beim Anwenden des Modells ist auch von Inferenz die Rede).
Dabei ist das Trainieren sehr rechenintensiv, profitiert also von entsprechender Hardwareunterstützung durch Karten von Nvidia oder AMD, die Inferenz lässt sich aber gegebenenfalls auch von normalen CPUs erledigen. Auch hier gibt es bei Bedarf Zusatzboards wie etwa von Hailo.ai, die den Vorgang effizienter gestalten. Beim Einsatz von Generativer KI (also etwa Sprachmodellen) ist eine Hardwarebeschleunigung auch bei der reinen Anwendung der Modelle zu empfehlen.
Hardware planen
Das komplette Neutrainieren eines solchen Modells dürfte die Rechenzentren der meisten Firmen eher überfordern. In der Planung ist auch dringend der Stromverbrauch zu betrachten – sowohl im eigentlichen Rechner als auch für die zugehörige Kühlung. Eine H100-GPU von Nvidia etwa benötigt unter Volllast bis zu 700 Watt. Dies ist je nach Modell das Doppelte des restlichen Servers. Sind größere Mengen an GPUs angedacht, spielt unter Umständen sogar die Gesamtkapazität des Rechenzentrums eine Rolle. Auch müssen die Lieferanten der Server darauf achten, dass die mitgelieferten Netzteile der Belastung standhalten, jedoch sind bei den meisten professionellen Herstellern inzwischen entsprechende Geräte im Angebot. Lediglich bei einer neuen Generation der Beschleunigerhardware kann sich die Beschaffung etwas verzögern.
Bei der Auswahl der Beschleunigerkarte spielt auch die geplante Zielarchitektur eine Rolle. Soll ein einzelner Dienst auf einem Server laufen, genügt unter Umständen schon eine Grafikkarte, die eigentlich für den Spielebereich gedacht ist. Beim Einsatz von generativer KI muss es aber schon die Oberklasse sein, da die Karten das Video-RAM zum Speichern der Modelle verwenden und hier in der Regel bei 24 GByte Schluss ist. Sollen die Karten in einer virtualisierten Umgebung zum Einsatz kommen, müssen es die Enterprise-Modelle sein, die sich dann auch in Form von vGPUs aufteilen lassen.
Erste Hersteller wie Apple haben in ihre CPUs direkt Hardwarebeschleunigung in Form spezieller Units auf der CPU implementiert oder den Schritt zumindest angekündigt. Diese Einheiten arbeiten dann meist energieeffizienter als die GPU-Hardware. Auch Spezialanbieter wie Hailo bieten hier Produkte an, die sich durch im Verhältnis sehr geringen Stromverbrauch auszeichnen.
Als letzte Anmerkung zum Thema Hardwareplanung sei schließlich noch angemerkt, dass sowohl die Software als auch die eigentlichen Modelle sehr speicherhungrig sind. Das bedeutet, dass der Storage der Server lieber eine Nummer größer dimensioniert werden sollte. Container-Images sind gerne 20 oder 30 GByte groß und auch das Anlegen von Virtual Environments für Python benötigt pro Umgebung mehrere GByte. Bei Servern ist dies heute meist kein entscheidender Kostenfaktor, sollte aber im Hinterkopf bleiben.
Passende Treiber aufspielen
Für unseren Beispielserver unter Ubuntu 24.04 LTS verwenden wir einen Acht-Kern-Server mit 32 GByte RAM und 250 GByte Storage. Als GPU kommt eine Nvidia T4 mit 16 GByte Video-RAM zum Einsatz. Der erste Arbeitsschritt besteht in der Installation der Kernel-Treiber, damit die Hardware überhaupt ansprechbar ist. Wie üblich ist dazu ein neues Repository erforderlich. Nvidia stellt diese für viele gängige Linux-Distributionen bereit. Für unseren Ubuntu Server erfolgt die Installation mit den folgenden Schritten:
# wget https://developer.download. nvidia.com/compute/cuda/repos/ ubuntu2404/x86_64/cuda-keyring_1. 1-1_all.deb
# dpkg -i cuda-keyring_1.1-1_all.deb
Dieses Paket fügt die gpg-Schlüssel und die Repository-Informationen zum System hinzu, sodass danach die Pakete für Treiber, Bibliotheken und Tools direkt zur Installation bereitstehen. Hier stellt sich als Erstes die Frage, ob die proprietären oder die von Nvidia neu bereitgestellten offenen Treiber zum Einsatz kommen. Nvidia schreibt dazu in seinem Technical-Blog, dass die (neueren) offenen Treiber für alle Architekturen wie Turing, Ada Lovelace oder Ampere empfohlen ist. Bei älteren sollten proprietären Treiber verwendet werden. In unserem Testaufbau kommen die Open-Module zum Einsatz, die sich mit dem Kommando
# apt-get install nvidia-open
installieren lassen. Neben den Treibern sollten zur Kontrolle des Betriebs auch die Werkzeuge von Nvidia ihren Weg ins System finden. Diese Pakete enthalten eine Versionsnummer. Durch die Installation des Metapakets nvidia-open haben wir bei unserem Testaufbau den Treiber in der Version 570 eingespielt. Das Paket, das das Werkzeug nvidia-smi enthält, heißt "nvidia-utils". Zum Installieren der passenden Version dient das folgende Kommando:
# apt-get install nvidia-utils-570
Im Metapaket "nvidia-open" sind unter anderem die Pakete "nvidia-dkms-570-open" sowie "nvidia-driver-570-open" enthalten. In der Struktur der Pakete ist eine eventuell später erscheinende Version 575 kein Upgrade, sondern aktiv zu installieren. Dabei findet immerhin eine Überprüfung der Abhängigkeiten zu den anderen Paketen der 570er-Version statt, damit diese vollständig aktualisiert werden. Der normale Zyklus apt update; apt (dist-)upgrade  erfasst diese Pakete jedoch nur zum Teil in der Praxis. Hier ist also Aufmerksamkeit bei den Upgrades des Systems gefragt, um am Ende einen konsistenten Zustand zu erreichen.
Das Werkzeug nvidia-smi zeigt bei Aufruf ohne Argumente eine Statusübersicht über die GPU samt Treiberversionen, Name des erkannten Geräts, Temperatur, Speicherauslastung sowie Angaben, ob und welche Prozesse die GPU nutzen. In Bild 1 sehen Sie die Ausgabe auf unserem Beispielrechner. Das Programm versteht zahlreiche Kommandozeilenoptionen, um Details über den Status der installierten Grafikkarten auszugeben oder Einfluss auf die Karte zu nehmen, etwa die GPU zurückzusetzen. Dabei stehen nicht immer alle Optionen auf allen Modellen zur Verfügung.
Bild 1: Die Ausgabe von nvidia-smi informiert über die technischen Details der GPU.
Mit dem bis hierhin erreichten Zustand der Installation ist es möglich, das Werkzeug Ollama laufen zu lassen, um Large Language Models zu starten. Die beiden Kommandos
# curl -fsSL https://ollama.com/ install.sh | sh
# ollama run mistral
führen zu einem Prompt des LLMs, der mit Hardwarebeschleunigung einen Dialog anbietet.
Python-Umgebung einrichten
Entwickler, die eigene Modelle aufbauen und trainieren möchten oder auch das Ausführen von Modellen etwa zur Bildverarbeitung, setzen häufig eine funktionierende Python-Umgebung voraus, die meistens eines der beiden Frameworks Pytorch oder Tensorflow beinhaltet. Beide stehen nicht ohne weitere Repositories als Pakete zur Verfügung, sodass zur Installation der Python-Paketmanager pip zum Einsatz kommt.
Um die Pakete nicht zu mischen, kommen Python Virtual Environments zum Einsatz. Das Werkzeug zu deren Verwaltung heißt virtualenv und gehört zum Paket "python3-virtualenv". Die folgenden beiden Kommandos legen jeweils eine Umgebung für Pytorch und einen für Tensorflow an:
$ virtualenv pytorch
$ virtualenv tensorflow
Um nun Pakete in eine der Umgebungen zu installieren und dann auch Python-Code ausführen zu können, der diese verwendet, müssen Sie die Umgebung aktivieren:
$ . pytorch/bin/activate
Der nächste Schritt ist die Installation der Pakete. Der Befehl
(pytorch) $ pip install torch numpy
installiert die notwendigen Pakete und löst dabei alle Abhängigkeiten auf. Sollte Bildverarbeitung das Ziel sein, gehört noch das Paket "torchvision" dazu. Zur Überprüfung, ob alles funktioniert hat, führen Sie das folgende Python-Skript aus:
import torch
device = torch.device('cuda' if torch.cuda.is_available() else 'cpu')
print(f"{device} {torch.cuda.get_ device_name()}")
Die Ausgabe sollte das Wort "cuda" sowie den Namen der GPU anzeigen. Auf unserem Testserver erschien als Ergebnis "cuda Tesla T4". Zum finalen Test ließen wir ein selbst entwickeltes Skript zum Training eines neuronalen Netzes zur Bilderkennung laufen. Gleichzeitig lief dabei nvidia-smi als Loop, sodass alle paar Sekunden Speicherverbrauch und Last auf der GPU angezeigt wurden. Bild 2 zeigt die Ausgabe während der Trainingsphase des Netzes. Zu sehen ist, dass das Netz gut 7,5 GByte RAM belegt und der Stromverbrauch der Karte bei 25 Watt liegt. Das Vorgehen für Tensorflow ist ähnlich. Als Erstes aktivieren wir die Umgebung für Tensorflow mit
$ . tensorflow/bin/activate
Nun kommt wieder pip zum Einsatz. Das Paket torchvision würde allerdings mittels pip install torchvision  ohne Hardwarebeschleunigung installiert. Für die Version mit Hardwarebeschleunigung müssen wir an den Paketnamen noch etwas anhängen, und das korrekte Kommando lautet
$ pip install tensorflow[and-cuda]
Zur Prüfung, ob auch hier Tensorflow mit Hardwarebeschleunigung arbeitet, dient das folgende Kommando:
import tensorflow as tf
print(f"{tf.test.gpu_device_name()}")
Dies Ausgabe gestaltet sich etwas ausführlicher als bei pytorch, da Tensorflow bereits beim Laden des Moduls sehr gesprächig ist. Die Ausgabe auf dem Testserver sieht aus wie im Listing-Kasten dargestellt. Pip unterstützt über einen Suffix auch das Installieren bestimmter Versionen der Pakete. Sollen die Python-Programme anderer Entwickler zum Einsatz kommen, kann es sein, dass diese eine bestimmte Version von Pytorch oder Tensorflow voraussetzen.
Listing: Ausgabe des Tensorflow-Skripts
$ python tensortest.py
2025-02-02 19:09:10.150919: I tensorflow/core/util/port.cc:153] oneDNN custom operations are on. You may see slightly different numerical results due to floating-point round-off errors from different computation orders. To turn them off, set the environment variable `TF_ENABLE_ONEDNN_OPTS=0`.
2025-02-02 19:09:10.167049: E external/local_xla/xla/stream_executor/cuda/cuda_fft.cc:477] Unable to register cuFFT factory: Attempting to register factory for plugin cuFFT when one has already been registered
  WARNING: All log messages before absl::InitializeLog() is called are written to STDERR
E0000 00:00:1738523350.187211 24527 cuda_dnn.cc:8310] Unable to register cuDNN factory: Attempting to register factory for plugin cuDNN when one has already been registered
E0000 00:00:1738523350.193338 24527 cuda_blas.cc:1418] Unable to register cuBLAS factory: Attempting to register factory for plugin cuBLAS when one has already been registered
2025-02-02 19:09:10.213487: I tensorflow/core/platform/cpu_feature_guard.cc:210] This TensorFlow binary is optimized to use available CPU instructions in performance-critical operations.
To enable the following instructions: AVX2 AVX512F AVX512_VNNI FMA, in other operations, rebuild TensorFlow with the appropriate compiler flags.
I0000 00:00:1738523352.205662 24527 gpu_device.cc:2022] Created device /device:GPU:0 with 13760 MB memory: -> device: 0, name: Tesla T4, pci bus id: 0000:00:1e.0, compute capability: 7.5
/device:GPU:0
Die nächste Stelle mit Konfliktpotenzial ist dann allerdings die Python-Version, die der virtuellen Umgebung zugrunde liegt. Nicht alle Versionen von Python (und das bezieht sich auf die Minor-Releases) passen nämlich mit der gewünschten Version von einem der Pakete zusammen. Das Update von Paketen auf die letztmögliche Version findet prinzipiell mit pip install <paketname> --upgrade  statt. Gegebenenfalls muss ein selbst gebautes Python zum Einsatz kommen (wenn etwa Python 3.9 im Repository nicht zur Verfügung steht) oder ein entsprechendes Repository eingebunden werden. Eine Alternative für den Aufbau ganz gezielter Umgebungen bietet der Paketmanager Conda, auf den wir im nächsten Abschnitt eingehen.
Abschließend sei zum Thema Python noch erwähnt, dass dadurch, dass pip wheel Pakete installiert, auch jeweils alle Bibliotheken nochmals eingespielt werden. Dies hat zwar den Vorteil, dass alles zusammenpasst, aber eben auch den Nachteil, dass dies den verbrauchten Festplattenplatz für die Umgebung erhöht. So schlugen auf unserem Testserver die Pytorch-Umgebung mit 5,3 und die Tensorflow-Umgebung mit 4,7 GByte zu Buche. Dies mag bei den heutigen Preisen für Storage nicht sonderlich tragisch sein, bei der Provisionierung von VMs sollten Sie jedoch darauf achten, genügend virtuellen Festplattenplatz zuzuweisen.
Bild 2: Die Ausgabe von nvidia-smi während des Trainings.
Einheitliche Pakete mit Conda
Conda [1] ist ein eigenständiger Paketmanager, der es erlaubt, mit einheitlichen Paketen auf diversen Linux-Distributionen zu arbeiten und dabei mehrere geschlossene Umgebungen auf einem System zu verwalten, wie dies mit virtualenv für Python auch möglich ist. Conda unterstützt nicht nur Linux, sondern auch Windows und macOS. Die Einrichtung und Verwendung würde einen eigenen Artikel rechtfertigen, daher beschränken wir uns hier auf die notwendigen Kommandos, um mit Conda eine Pytorch- beziehungsweise eine Tensorflow-Umgebung zum Laufen zu bekommen. Um Conda zu installieren, sind die ersten Arbeitsschritte der Download und das Ausführen des Installationsskripts:
$ wget https://repo.anaconda.com/ archive/Anaconda3-2024.10-1-Linux-x86_64.sh
$ bash Anaconda3-2024.10-1-Linux-x86_64.sh
Die aktuelle Versionsnummer (im Beispiel 2024.10-1) findet sich auf der Homepage in der Installationsanleitung. Danach existiert im aktuellen Verzeichnis der Ordner "anaconda3". Mittels
$ anaconda3/bin/conda init
entsteht die erste Conda-Umgebung (Environment). Der Aufruf modifiziert auch die Datei ".bashrc", um den Pfad "anaconda3/bin" zum Suchpfad für ausführbare Programme hinzuzufügen, sodass dies nach dem nächsten Login bereitsteht. Um ein Environment zu aktivieren, dient das Kommando conda activate <environmentname>. Da wir getrennte Umgebungen für die beiden Frameworks erzeugen wollen, müssen wir die Environments aber zuerst anlegen. Dies geschieht mit den Befehlen
$ conda create -n pytorch
$ conda create -n tensorflow
Die nächsten Schritte sind das Aktivieren der Umgebung und die Installation der Pakete. Dies erledigen die folgenden Kommandos für die Pytorch-Umgebung:
$ conda activate pytorch
(pytorch)
$ conda install pytorch torchvision cudatoolkit pytorch-cuda -c pytorch -c nvidia
Nach dem activate-Befehl ändert Conda den Prompt ab; damit klar ist, dass wir uns jetzt im aktivierten Environment befinden. Die beiden Optionen "-c" am Ende geben dem Conda-Kommando mit, aus welchen "Channels" (dies sind in Conda das Gegenstück zu Repositories bei apt oder yum) die Pakete zu holen sind. Nachdem dies durchgelaufen ist, können Sie die Python-Skripte, die pytorch verwenden, ausführen. Das Paket torchvision ist nicht unbedingt notwendig, da unser Testprogramm aber dem Bereich der Bildverarbeitung entstammt, kam es hinzu.
Das Kommando conda deactivate dient dazu, die Arbeit in einem Conda-Environment zu beenden. Nachdem dieses ausgeführt wurde, lässt sich in einer zweiten Umgebung die Tensorflow-Umgebung aufbauen:
$ conda activate tensorflow
(tensorflow)
$ conda install tensorflow-gpu
Nach diesen Arbeitsschritten steht ein Environment für Skripte bereit, die Tensorflow benötigen. Es ist selbstverständlich auch möglich, beide Frameworks in einer Umgebung bereitzustellen. Conda erlaubt es ferner, spezifische Versionen eines Pakets zu installieren, indem Sie die Version hinter dem Namen des Pakets mit dem Gleichheitszeichen angeben, also etwa
$ conda install paket=5.1
Dementsprechend werden dann auch Abhängigkeiten aufgelöst. Dies kann bei den beiden Frameworks durchaus notwendig sein, wenn fertige Skripte zum Einsatz kommen sollen, die schon älter sind. Ein wichtiger Aspekt für Administratoren ist auch die Pflege eines Environments, also das Patchen. Mit Conda geschieht dies mit dem Kommando "conda update --all" nach Aktivierung der Umgebung. Conda sucht dann nach Updates und gibt eine Liste der Pakete aus, für die eine Aktualisierung bereitsteht. Ein Prompt fragt ab, ob Sie diese installieren möchten.
Unterschätzen Sie auch hier nicht den verwendeten Festplattenplatz. Nach den zuvor gezeigten Schritten belegt der "anaconda3"-Ordner etwa 35 GByte. Da Conda es jedem Benutzer individuell erlaubt, Environments aufzubauen, kann dies bei der entsprechenden Anzahl an Anwendern schnell durch Multiplikation der Umgebungen zu Speicherengpässen führen. Das Kommando conda clean  dient zum Aufräumen alter Versionen, muss aber auch in den Betriebsprozess integriert werden.
Vorgefertigte Container nutzen
Wer sich die Arbeit ersparen möchte, entsprechende Umgebungen aufzubauen, verwendet Container. Diese gibt es auch für die Kombinationen Pytorch/Tensorflow plus Nvidia-Umgebung. Der Speicherverbrauch spielt dabei natürlich ebenfalls eine Rolle, denn das pytorch-Container-Image belegt 22,3 GByte. Die Kernel-Treiber müssen zudem für den Betrieb der Container installiert sein, da ja auch der Container über die Device-Dateien auf die GPU zugreift.
Um der Container-Engine die Nvidia-Karte mitzugegeben, sind einige vorbereitende Maßnahmen notwendig. Der erste Schritt ist die Installation des Pakets "nvidia-container-toolkit". Dieses Paket enthält das Werkzeug "nvidia-ctk", das die Datei "/etc/cdi/nvidia.yaml" erzeugt. Dazu dient das folgende Kommando, das Sie als root-Benutzer aufrufen:
# nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml
Danach sind die verfügbaren GPU-Devices auflistbar:
# nvidia-ctk cdi list
Damit Sie einen Container starten können, muss im Device-Ordner "/dev" der Eintrag "nvidia-modeset" existieren. Dieser ist allerdings nur verfügbar, wenn der Dienst nvidia-persistenced läuft. Um ihn zu aktivieren und starten, verwenden Sie den Befehl
# systemctl enable nvidia-persistenced
# systemctl start nvidia-persistenced
Nun lässt sich der Container starten. In unserem Beispiel verwenden wir den pytorch-Container von Nvidia. Der ganze Aufruf für eine interaktive Session mit podman als Container-Runtime sieht folgendermaßen aus:
# podman run -it --rm --device nvidia.com/gpu=all --security-opt=label=disable nvcr.io/nvidia/pytorch:24.01-py3
Das Argument der Option "--device nvidia.com/gpu=all" gibt an, alle vorhandenen GPUs dem Container zuzuweisen. Auf einer Hardware mit mehreren GPUs können Sie so eine Auswahl treffen, um Ressourcen sinnvoll zu verteilen. Verwenden Sie Docker anstelle von Podman, sehen die vorbereitenden Arbeiten etwas anders aus. Es kommt wieder nvidia-ctk zum Einsatz, jedoch ist der folgende Aufruf erforderlich:
# nvidia-ctk runtime configure --runtime=docker
# systemctl restart docker
Der Aufruf zum Start des Containers unterscheidet sich auch leicht in den Parametern und entspricht den Empfehlungen von Nvidia. Dabei sind die ulimit- Angaben je nach Netz, das in pytorch aufgespannt wird, unter Umständen nicht notwendig:
# docker run -it --gpus all --ipc=host --ulimit memlock=-1 --ulimit stack=67108864 nvcr.io/nvidia/pytorch:24.01-py3
Container-Cluster managen
In größeren Umgebungen kommen statt einzelner Container-Nodes Kubernetes-Cluster zum Einsatz. Wie in der normalen Infrastruktur auch, wird es im K8s-Cluster so sein, dass nicht alle Compute-Nodes mit GPUs ausgestattet sind. Damit bei der Verteilung der Container ein Compute-Node mit GPU zum Zug kommt, müssen Sie diese im Deployment des Containers als Ressource anfordern. Dies geschieht für Nvidia mit einer Ressourcenanforderung wie dieser:
  containers:
    - name: cuda-container
      image: nvcr.io/nvidia/pytorch:24.01-py3
      resources:
        limits:
        nvidia.com/gpu: 1
Bevor dies im Cluster funktionieren kann, müssen die Compute Nodes mit GPU und der Cluster aber erst vorbereitet werden. Im Github-Repository von Nvidia [2] findet sich die Anleitung dazu. Kubernetes verwendet in der Regel seit einigen Versionen nicht mehr Docker als Container-Engine, sondern den darunterliegenden containerd. Um die Container-Engine umzukonfigurieren, kommt wieder nvidia-ctk zum Einsatz:
# nvidia-ctk runtime configure -runtime=containerd
# systemctl restart containerd
Nun bringen Sie dem Cluster noch bei, dass er die GPUs in den angepassten Nodes auch erkennt. Eine Möglichkeit dazu ist die Anwendung des Deployments unter [3], das Sie mit kubetctl apply -f  importieren. Für Produktivumgebungen empfiehlt Nvidia – eine Helm- Installation vorausgesetzt – den Rollout über Helm mit
$ helm repo add nvdp https://nvidia.github.io/k8s-device-plugin
$ helm repo update
Über helm search repo nvdp --devel  findet sich der Helmchart namens "nvdp/nvidia-device-plugin". Dessen Rollout besorgt dann das Kommando
$ helm upgrade -i nvdp nvdp/nvidia-device-plugin \
  --namespace nvidia-device-plugin \
  --create-namespace \
  --version 0.17.0
Die Version sollte derjenigen entsprechen, die beim search-Kommando gefunden wurde. Die Zuordnung der GPUs erfolgt dabei absolut. Das bedeutet, dass es die Nvidia T4 aus unserem Beispiel erlaubt, einen Container laufen zu lassen, den Sie mit "nvidia.com/gpu: 1" spezifiziert haben. Sollten mehr Container nötig sein, muss die entsprechende Hardware zum Einsatz kommen, die dies gestattet. Daher ist bei eigenem Aufbau eine gute Kapazitätsplanung vonnöten – gerade da es sich um nicht gerade billige Hardware handelt.
Fazit
Die Voraussetzungen dafür, KI-Anwendungen auf eigener Hardware und im eigenen Rechenzentrum laufen zu lassen sind kein Hexenwerk, aber es gibt beim Einsatz von Nvidia-Hardware einige Dinge zu beachten. Was beim Einsatz im Rechenzentrum ebenfalls zu berücksichtigen ist, ist der deutlich höhere Stromverbrauch, der sich im Bau der Hardware, aber auch in der bereitzustellenden Kühlung äußert.
Wie erwähnt ist es ratsam, den Storage großzügig zu planen, da sowohl Modelle als auch zu installierende Softwarepakete größeren Platz auf dem bereitgestellten Speichermedium belegen. Auf der Softwareseite sollten die Versionen von Treibern und Bibliotheken nicht zu weit auseinanderlaufen, da es dabei durchaus vorkommen kann, dass eine Inkompatibilität entsteht.
Für den Erfolg von KI-Anwendungen im eigenen Rechenzentrum sind nicht zuletzt eine gute Dokumentation und ein strukturiertes Vorgehen ein Muss. Die vielen Abhängigkeiten zwischen Hardware, Treibern, Frameworks und Anwendungen machen eine sorgfältige Planung der Updates und Testphasen nötig.
(dr)
Link-Codes
[2] GitHub-Repository von Nvidia: https://github.com/NVIDIA/k8s-device-plugin