Beginnen Sie mit der Anwendung und ihrer Betreuung und wählen Sie danach eine Linux-Distribution. Das System muss zu Ihrer Software, dem GPU-Treiber und den Werkzeugen Ihres Teams passen. Der Name Ubuntu, Debian oder Rocky Linux allein bestimmt nicht, wie schnell ein Modell antwortet.
Unsere veröffentlichten llama.cpp-Messungen liefen unter Rocky Linux 10.2. Sie belegen die genannte Kombination, nicht die relative Leistung dreier Distributionen. Unsere gemeinsame LLM-Benchmark-Methodik erklärt, welche Versionen und Bedingungen für aussagekräftige Vergleiche beibehalten werden müssen.
Entscheiden Sie zuerst, was Sie betreiben möchten
Ein „KI-Server“ kann ein einfaches Programm für ein Modell oder eine umfangreichere Anwendung mit Dokumentensuche, Benutzerkonten und Datenbank sein. Diese Komponenten bestimmen die Systemanforderungen. Prüfen Sie vor der Installation in der Dokumentation der konkreten Anwendung unterstützte Versionen, GPU-Zugriff und den vorgesehenen Installationsweg.
Wenn zunächst ein funktionierendes Modell das Ziel ist, kann ein vorkompiliertes Programm samt Bibliotheken einen bequemen Einstieg bieten. Unser Ratgeber zur privaten API mit Qwen3 und llama.cpp folgt diesem Ansatz. Die Nutzung einer GPU erfordert nicht automatisch, die gesamte Umgebung selbst zu kompilieren.
Verpackt Ihr Team die Anwendung bereits in einem Container — also das Programm samt Abhängigkeiten —, bleibt das Hostsystem relevant. Ein Container organisiert die Anwendungsumgebung, ersetzt aber weder den Kartentreiber noch korrekt eingerichteten GPU-Zugriff. Das sind getrennte Teile der Installation.
Wann kommen Ubuntu, Debian oder Rocky Linux infrage?
- Ubuntu LTS: wenn Ihr Team Ubuntu kennt oder die Anwendung diesen Installationsweg dokumentiert. LTS bezeichnet eine länger gepflegte Version, keine automatische Kompatibilität mit jedem Treiber und Programm.
- Debian: wenn Sie die Administrationsweise Ihrer anderen Server beibehalten möchten. Vertraute Aktualisierungsverfahren und Dienstkonfigurationen können die Betreuung erleichtern; die GPU-Software muss die konkrete Version trotzdem unterstützen.
- Rocky Linux: wenn Sie Enterprise-Linux-Werkzeuge und -Verfahren einsetzen oder die hier beschriebene Testumgebung reproduzieren möchten. Unsere funktionierende Kombination ersetzt nicht die Prüfung der Anforderungen einer anderen Anwendung.
Ein Unternehmen, das bereits Debian-Dienste betreut, muss beispielsweise nicht seinen gesamten Arbeitsablauf ändern, nur weil eine GPU hinzukommt. Prüfen Sie zuerst, ob es für Programm und Treiber einen kompatiblen Installationsweg gibt. Ein Team, das mit der Ubuntu-Anleitung einer Anwendung beginnt, kann Unsicherheit durch die dokumentierte Umgebung reduzieren. Dies sind Beispiele betrieblicher Entscheidungen, keine gemessenen Leistungsvorteile.
Treiber und Anwendungsbibliotheken sind unterschiedliche Dinge
Der Treiber ermöglicht dem Betriebssystem die Nutzung der Karte. Die Anwendung benötigt zusätzlich Bibliotheken für die Ausführung. Werkzeuge zum Bauen von Software aus Quellcode, häufig Toolkit genannt, bilden eine weitere Komponente. Eine vorkompilierte Anwendung benötigt nicht immer das gesamte Entwicklungspaket.
Eine Meldung über eine fehlende Bibliothek bedeutet daher nicht automatisch, dass Betriebssystem oder Treiber ersetzt werden müssen. Klären Sie zuerst, welche Komponente fehlt und welche Versionen die Anwendungsanleitung erwartet. Die technischen Details unterscheiden unsere funktionierende Kombination von offiziellen Unterstützungslisten, statt einen erfolgreichen Lauf auf alle Kombinationen zu verallgemeinern.
Wie prüfen Sie eine vorbereitete Umgebung?
Durchlaufen Sie den vollständigen kurzen Ablauf: Das System erkennt die richtige Karte, das Programm lädt das gewählte Modell, eine Anfrage erreicht es und eine vollständige Antwort kommt zurück. Prüfen Sie, ob die Berechnung tatsächlich die GPU nutzt — nicht nur, ob der Prozess startet. Prüfen Sie anschließend den Dienstneustart und den Zugriff auf Modelldateien im lokalen Speicher.
Dokumentieren Sie Betriebssystem-, Treiber-, Anwendungs- und Modellversionen zusammen mit den Startparametern. Das hilft, eine funktionierende Kombination wiederherzustellen und das Verhalten nach Aktualisierungen zu vergleichen. Ändern Sie System, Modell und Einstellungen gleichzeitig, verrät eine schnellere Antwort nicht, welche Änderung geholfen hat.
Binden Sie schließlich die übrigen Teile des geplanten Services ein: Authentifizierung, Clientanwendung und gegebenenfalls Dokumentensuche. Ein funktionierendes Modell ist ein wichtiger Meilenstein, aber noch keine vollständig vorbereitete Anwendung. Öffentlicher Zugriff benötigt zudem ein eigenes Konzept für Berechtigungen und Dienstschutz.
Fazit: Wählen Sie eine Umgebung, die mit Ihrer Anwendung kompatibel und den zuständigen Personen vertraut ist. Halten Sie die funktionierende Kombination fest, prüfen Sie den tatsächlichen Ablauf und messen Sie die Geschwindigkeit Ihrer Aufgaben. Unsere Rocky-Messungen bieten keine Grundlage, Ubuntu, Debian und Rocky in eine Rangfolge zu bringen.
Serverangebot ansehen oder uns mitteilen, welches Modell und welche Umgebung Sie betreiben möchten. Das KI- und GPU-Glossar erklärt die Grundbegriffe.
Technische Details
Wählen Sie zunächst, wie das Modell ausgeführt wird
Es gibt drei praktische Ansätze:
- Eine vorkompilierte Anwendung mit Bibliotheken. Wählen Sie einen konkreten Build, prüfen Sie die Anforderungen und führen Sie ihn mit einem kompatiblen Treiber aus. Unser Ratgeber zur privaten llama.cpp-API nutzt diesen Ansatz.
- Ein Container. Verpacken Sie die User-Space-Abhängigkeiten zusammen mit der Anwendung. Der Host benötigt weiterhin einen funktionierenden Treiber und korrekt konfigurierten GPU-Zugriff.
- Ein Build aus dem Quellcode. Wählen Sie zusätzlich CUDA Toolkit, Compiler und Entwicklungsbibliotheken. Das gibt Kontrolle über den Build, erfordert aber mehr zu dokumentierende und reproduzierende Komponenten.
Diese Unterscheidung ist oft hilfreicher als „Ubuntu oder Debian“. Eine vorkompilierte CUDA-Anwendung erfordert nicht automatisch die Installation des gesamten Entwicklungs-Toolkits.
Wann welche Distribution infrage kommt
| System | Ein praktischer Ausgangspunkt | Vor der Installation prüfen |
|---|---|---|
| Ubuntu LTS | Ihr Team nutzt bereits Ubuntu oder die Anwendung dokumentiert diese Umgebung | die genaue LTS-Version, Anwendungsanforderungen und einen kompatiblen Weg zur Treiberinstallation |
| Debian stable | Sie möchten die Administrationsweise Ihrer anderen Debian-Server beibehalten | die von der gewählten NVIDIA-Software unterstützte Debian-Version, nicht nur die Bezeichnung „stable“ |
| Rocky Linux | Sie nutzen bereits RPM/DNF-Werkzeuge und Enterprise-Linux-Verfahren | die genaue Rocky-Version, Kernel, Treiber und Anwendungsbibliotheken |
Dies sind betriebliche Kriterien, keine Leistungsrangfolge. Ubuntu dokumentiert seinen LTS-Veröffentlichungszyklus, Debian empfiehlt stable für den Produktivbetrieb und Rocky dokumentiert die RPM/DNF-Paketverwaltung. Eine gepflegte Umgebung, die Ihr Team versteht, ist ein besserer Ausgangspunkt als ein Betriebssystemwechsel allein wegen des Namens.
Treiber, Laufzeitbibliotheken und Toolkit sind getrennte Komponenten
Der Treiber verbindet das Betriebssystem mit der Karte. Laufzeitbibliotheken werden von der Anwendung verwendet; das Toolkit enthält zusätzlich Entwicklungswerkzeuge. Dokumentieren Sie die Version jeder Komponente separat.
NVIDIA veröffentlicht eine Unterstützungsmatrix der Distributionen für jede CUDA-Version. Übertragen Sie Kompatibilitätsaussagen nicht automatisch zwischen Versionen. Beispielsweise nennt der CUDA-12.8.1-Leitfaden konkrete Ubuntu-, Debian- und Rocky-8/9-Versionen; Rocky 10 wird nicht aufgeführt. Eine neuere Matrix kann einen anderen Umfang haben.
Unsere veröffentlichten llama.cpp-Tests liefen unter Rocky Linux 10.2 mit NVIDIA-Treiber 595.91.07 und CUDA-12.8-Bibliotheken, die mit dem festgelegten Anwendungsbuild geliefert wurden. Das bestätigt diese Kombination in den beschriebenen Durchläufen. Wenn Sie Ihre eigene Anwendung kompilieren, wählen Sie das vollständige Toolkit und den Compiler anhand der einschlägigen Dokumentation.
Das Feld „CUDA Version“ in nvidia-smi beschreibt die Fähigkeiten des Treibers, nicht sämtliche installierten Bibliotheken. Beachten Sie bei Versionswechseln die Kompatibilitätsregeln für CUDA und Treiber.
Löst ein Container die Kompatibilitätsfrage?
Ein Container hilft, Anwendung und Abhängigkeiten konsistent zu halten. Er ersetzt weder den Hosttreiber noch korrekt eingerichteten GPU-Zugriff. Die auf eine konkrete Version bezogene llama.cpp-Containerdokumentation beschreibt eine CUDA-Variante; NVIDIA führt die Plattformunterstützung des Container Toolkits auf.
Um eine Umgebung zu reproduzieren, dokumentieren Sie die genaue Image-Version oder den Digest, das Modell samt Prüfsumme und die Startparameter. Ein veränderliches latest-Tag ist für Experimente praktisch, identifiziert jedoch nicht das Image einer früheren Messung.
So prüfen Sie Ihre Wahl
Führen Sie vor dem Umzug einer Anwendung einen kurzen Test durch: Laden Sie dasselbe Modell, prüfen Sie die vorgesehene GPU, senden Sie eine repräsentative Anfrage und erfassen Sie die Zeit bis zum ersten Token sowie den Antwortdurchsatz. Prüfen Sie anschließend den Dienstneustart und die Verfügbarkeit des Modells im lokalen Speicher.
Halten Sie für einen Leistungsvergleich von Distributionen Hardware, Modell, Anwendungsbuild, Treiber, Kontext und Parallelität gleich. Werden alle gleichzeitig geändert, misst dies den Unterschied zweier Umgebungen und nicht allein den Einfluss des Betriebssystems.
Die praktische Wahl: Wählen Sie eine Distribution, die zu Ihrer Anwendung und Ihrem Arbeitsablauf passt, und halten Sie die funktionierende Umgebung fest. Beurteilen Sie die Geschwindigkeit anhand von LLM-Engine-Messungen und API-Antworttests, nicht anhand der Popularität des Betriebssystems.
Serverkonfiguration ansehen oder uns mitteilen, welches Modell und welche Umgebung Sie betreiben möchten.