Sie können ein Modell auf Ihrem eigenen GPU-Server betreiben und mit einer Anwendung verbinden. Eine API ist die Schnittstelle, über die ein Programm eine Anfrage sendet und eine Antwort erhält. Dieser Ratgeber zeigt ein funktionsfähiges Beispiel mit Qwen3-8B und llama.cpp, der Software zur Modellausführung.
Die Anleitung führt Sie von geprüften Downloads bis zur ersten Antwort. Separat maßen wir die Geschwindigkeit von Qwen3-8B und prüften 24 kurze polnische und englische Aufgaben anhand unserer gemeinsamen Benchmark-Methodik. Das trennt zwei Fragen: Funktioniert der Dienst und eignet er sich für Ihre geplante Aufgabe?
Was haben Sie am Ende?
Das Modell läuft auf dem Server; Ihr Rechner greift über einen verschlüsselten SSH-Tunnel darauf zu. Ihre Anwendung sendet darüber eine Anfrage, der Server berechnet die Antwort und liefert sie über dieselbe Verbindung zurück. Dafür muss kein öffentlicher API-Port geöffnet werden.
Dies kann ein Ausgangspunkt für einen internen Assistentenprototyp, ein Werkzeug für Beschreibungsentwürfe oder die Extraktion ausgewählter Textfelder sein. Beim eigenen Betrieb wählen Sie Modell, Version und Anbindung an die Anwendung. Eine Chatoberfläche oder Zugriff auf Unternehmensdokumente kommen nicht automatisch hinzu; sie benötigen ein eigenes Konzept.
Wie schnell antwortet dieses Modell?
In einer kontrollierten Messung schloss Qwen3-8B seine Antwort ab in 1.5 s bei kürzerer und 2.3 s bei längerer Eingabe. Beide Fälle erzeugten dieselbe Ausgabemenge: 256 Tokens, die Bausteine, in die ein Modell Wörter und Zeichen zerlegt. Wir maßen jeden Fall nach dem Aufwärmen fünfmal; die Tabelle zeigt den mittleren Wert dieser fünf Messungen.
| Eingabelänge | Erstes Token | Vollständige Antwort |
|---|---|---|
| 2048 Tokens | 0.2 s | 1.5 s |
| 8192 Tokens | 0.8 s | 2.3 s |
Das sind 10 abgeschlossene Antworten mit jeweils einer Anfrage, lokal auf dem Server gemessen. Diese Konfiguration reserviert einen Slot; der Parallelitäts-Benchmark vergleicht eine und vier aktive Anfragen mit vier reservierten Slots. Die Tabelle zeigt den Einfluss der Eingabelänge bei fester Ausgabelänge. Sie ist kein Versprechen für jedes Gespräch: Aufgabe, Antwortlänge, Serverlast und Internetverbindung können die Wartezeit verändern. Die kurze Anfrage mit 32 Tokens in der folgenden Anleitung prüft nur den Start; sie reproduziert diese Messung nicht.
Die erste Zeitspalte zeigt, wann der Messclient das erste generierte Token empfing. Das ist nicht immer der erste für den Nutzer sichtbare Teil der endgültigen Antwort.
Eine schnelle Antwort ist nur die halbe Aufgabe
In einer separaten Prüfung erhielt das Modell 24 einfache Aufgaben: Rechnen, Extraktion von Textfeldern, Kategoriezuweisung nach vorgegebener Regel und Antworten aus einer kurzen Beschreibung. Jede Aufgabe hatte einen Versuch. Alle 24 Antworten verwendeten das geforderte JSON-Format: benannte Felder, die eine Anwendung direkt lesen kann. 17 Antworten stimmten exakt mit der festgehaltenen Referenzantwort überein.
Das Modell beantwortete alle sechs regelbasierten Klassifikationsaufgaben und alle sechs Fragen zur bereitgestellten Beschreibung korrekt. Dieser Ansatz kann bei der ersten Sortierung von Anfragen helfen: Die Anwendung liefert eine Regel, das Modell gibt ein Kategoriefeld zurück. Das sind geprüfte kleine Beispiele, keine Bewertung sämtlicher Dokumente oder Unternehmensabläufe.
Vier Abweichungen betrafen Berechnungen. Eine Aufgabe mit Beginn um 09:45 und 95 Minuten Dauer müsste beispielsweise um 11:20 enden; das Modell gab 11:15 zurück. Die anderen drei betrafen die exakte Schreibweise eines extrahierten Namens, darunter ein zusätzlicher Punkt oder das Wort „Team“. Wir behalten die ursprüngliche strenge Bewertung bei: 17/24 bedeutet Übereinstimmung mit einer bestimmten Referenz, keine allgemeine „Modellgenauigkeit“. Legen Sie in einer Anwendung fest, wie Namen zurückgegeben werden sollen, und nutzen Sie Programmcode für Berechnungen, die ein verlässliches Ergebnis erfordern.
Was geschieht in jedem Einrichtungsschritt?
Sie benötigen ein Serverkonto, SSH-Zugriff und einen funktionierenden GPU-Treiber. Die Befehle stehen im aufklappbaren technischen Abschnitt. Zunächst hilft es, jede Phase zu verstehen:
- Karte prüfen. Das System sollte die vorgesehene GPU und ihren Treiber erkennen. Das trennt Hardware- oder Treiberprobleme von späteren Problemen mit dem Modell selbst.
- Dateien herunterladen und prüfen. Sie benötigen das Programm, seine Bibliotheken und die Modellgewichte: die bei der Berechnung verwendeten Dateien. Festgelegte Versionen und Prüfsummen helfen, dieselbe Umgebung zu reproduzieren. Fahren Sie bei einer abweichenden Prüfsumme nicht fort.
- Modell auf dem Server starten. Der Prozess lädt seine Daten und stellt eine lokale API bereit. Lassen Sie sein Terminal geöffnet, um Bereitschaft oder Fehler zu sehen. Zugewiesener GPU-Speicher und die Prozessliste helfen zu bestätigen, dass die Karte verwendet wird.
- Tunnel auf Ihrem Rechner öffnen. Verwenden Sie ein separates Terminal. Der Tunnel verbindet die lokale Adresse Ihres Rechners mit der lokalen Dienstadresse auf dem Server; er startet keine weitere Modellkopie.
- Bereitschaft prüfen und Testanfrage senden. Prüfen Sie in einem weiteren lokalen Terminal den Dienststatus, bevor Sie eine kurze Anfrage senden. Streaming zeigt Antwortteile während ihrer Entstehung, statt auf den vollständigen Text zu warten.
- Versuch beenden. Stoppen Sie Modellprozess und Tunnel in ihren Terminals. Ein Serverneustart ist nicht nötig; die geprüften Dateien bleiben für den nächsten Lauf verfügbar.
Woran erkennen Sie, dass die erste Phase funktioniert?
Trennen Sie drei Prüfungen: Der Prozess läuft auf der GPU, die API ist bereit und eine Antwort erreicht den Client. Ein laufendes Programm allein bestätigt nicht alle drei. Die Anleitung prüft Gerät, Dienstbereitschaft und einen kurzen Stream getrennt und bietet Hinweise zu häufigen Fehlern.
Die erste Anfrage prüft die Generierung über /completion. Sie ist weder ein vollständiges Chatgespräch noch ein Test der Antwortkorrektheit. Eine Chatanwendung benötigt eine passende Gesprächsvorlage und eine Verarbeitung ihrer Ausgaben. HTTP 200 bedeutet eine erfolgreiche Anfrage, nicht automatisch richtigen Inhalt.
Von einer funktionierenden API zur nützlichen Anwendung
Wählen Sie nach dem Start einen kleinen Aufgabensatz mit erwarteten Antworten. Prüfen Sie Inhalte und gefordertes Format: etwa, ob die Anwendung tatsächlich nur die verlangten JSON-Felder erhält. Messen Sie danach Zeiten mit typischen Dokumentlängen und der erwarteten Zahl gleichzeitiger Anfragen. Unsere API-Tests helfen, die Wartezeit einer Person vom Gesamtdurchsatz des Servers zu unterscheiden.
Verwenden Sie im Versuch Testdaten. Ein Tunnel begrenzt den Netzwerkzugriff, doch ein dauerhafter Dienst benötigt weiterhin Benutzerauthentifizierung, Anfragelimits, Regeln zur Datenaufbewahrung und Aktualisierungen. Ihr eigener Server gibt Ihnen Kontrolle über diese Entscheidungen; er macht sie nicht überflüssig.
Wenn diese Begriffe neu sind, beginnen Sie mit unserem KI- und GPU-Glossar. Serverkonfiguration ansehen oder uns Ihre geplante Anwendung beschreiben.
Technische Details
Die frühere Prüfung der Anleitung verwendete einen Slot: lokal lieferten /health und /completion HTTP 200, und der Stream schloss die Generierung von 32 Tokens ab. Wir bestätigten den Prozess auf der vorgesehenen GPU und sämtliche 37/37 auf sie ausgelagerten Schichten. Diese Bereitschaftsprüfung bleibt getrennt von den neuen Leistungsmessungen und Aufgaben oben. Die Internetverbindung des Clients wurde nicht gemessen.
Umfang der CORE-1.1-Messung
Die neue gsh-llm-core/1.1-Reihe verwendete Qwen3-8B Q4_K_M, einen Client, einen Slot und 8704 Tokens Kontext. Jede Eingabelänge — 2048 und 8192 Tokens — hatte eine vollständige Aufwärmrunde und danach fünf Messrunden. Die synthetische Ausgabe umfasste stets 256 Tokens; Prompt-Caching und automatische Parameteranpassung waren deaktiviert. Die Antwortlatenz endet mit dem Ereignis der abgeschlossenen Generierung, nicht dem späteren Verbindungsende.
Die praktische Prüfung verwendete /v1/chat/completions, eine festgelegte Gesprächsvorlage, deaktiviertes Thinking und höchstens 1024 Ausgabe-Tokens. Nach separatem Aufwärmen der Übertragung erhielt jede der 24 Aufgaben eine Anfrage: 12 polnische und 12 englische Aufgaben. Formatkonformität verlangte ein JSON-Objekt mit exakten Feldnamen und Typen; Wertkonformität zusätzlich exakte Referenzübereinstimmung. Wir entfernten keine Markdown-Codezäune, korrigierten keine Namen und wiederholten keine Antworten zur Verbesserung der Bewertung. Alle Antworten endeten vor dem Ausgabelimit.
Die Ergebnisse betrugen 24/24 für das Format und 17/24 für exakte Werte: 9/12 auf Polnisch und 8/12 auf Englisch. Dieser kleine selbst erstellte Satz trägt weder eine Rangfolge der Sprachqualität noch eine Bewertung des Allgemeinwissens. Bei den Namensextraktionsaufgaben deckte die strenge Referenz nicht jede mögliche Lesart des Ausgangstextes ab; wir behalten das Ergebnis bei und erläutern seine Bedeutung, statt nach der Messung Bewertungen zu ändern.
Die Anhänge core-v1-results.json und core-v1-results.csv enthalten geprüfte Daten der neuen Reihe. Die Befehle des Ratgebers bleiben eine einfache Startanleitung, kein vollständiges Programm zur Reproduktion der CORE-Aufwärmläufe, Messungen und Aufgaben.
Umgebung und Umfang
| Komponente | Konfiguration unserer Testreihe |
|---|---|
| GPU | NVIDIA RTX PRO 6000 Blackwell Max-Q Workstation Edition, 96GB VRAM |
| Betriebssystem | Rocky Linux 10.2, x86-64 |
| NVIDIA-Treiber | 595.91.07 |
| System-RAM | 96GB |
| Engine | llama.cpp 0.5.0-dev, Build b11146, CUDA 12.8 |
| Modell | Qwen3-8B-GGUF, Q4_K_M, Datei mit 5,027,783,488 Bytes |
Unsere Benchmark-Methodik erklärt das Messverfahren.
Wir legen llama.cpp auf folgenden Commit fest: 7fe450e19305b828c199d602c23a8337aaa1f03b. Das Projekt kennzeichnet Build b11146 als Vorabversion. Er wurde zur Reproduktion dieser Reihe gewählt und wird nicht als neueste stabile Produktivversion dargestellt. Obwohl die Archive Ubuntu im Namen tragen, liefen genau diese Binärdateien und Bibliotheken in der angegebenen Rocky-Umgebung. Das belegt keine Kompatibilität zwischen jedem Ubuntu-Paket und jeder Distribution.
Vor dem Modelldownload
Sie benötigen einen funktionierenden GPU-Treiber, ein unprivilegiertes Konto, Bash, curl, tar, sha256sum und SSH-Zugriff. Führen Sie die Vorbereitungsbefehle in derselben Bash-Sitzung auf dem Server aus. Planen Sie Platz für heruntergeladene Archive, ihre entpackten Inhalte und das Modell ein.
Prüfen Sie zuerst die GPU:
nvidia-smi --query-gpu=name,driver_version,memory.total,power.limit --format=csv
Schlägt dies fehl oder erscheint nicht die vorgesehene Karte, beheben Sie zuerst die Treiberinstallation. Der Download von CUDA-Bibliotheken ersetzt nicht den Kerneltreiber. Das Feld „CUDA Version“ in nvidia-smi belegt auch nicht, dass dieselbe Toolkit-Version installiert ist: Es beschreibt die Treiberunterstützung. Siehe NVIDIA-SMI-Dokumentation und CUDA-Kompatibilitätsregeln.
Die folgenden Schritte installieren keine Systempakete und ändern weder Treiber, Firmware noch SSH-Konfiguration. LD_LIBRARY_PATH stellt die entpackten Bibliotheken nur dem gestarteten Prozess zur Verfügung.
Festgelegte Versionen herunterladen und Prüfsummen prüfen
Erstellen Sie ein neues privates Arbeitsverzeichnis. Erneutes Ausführen dieses Befehls erstellt ein weiteres Verzeichnis, statt die vorige Umgebung zu überschreiben.
set -euo pipefail
umask 077
llm_dir="$(mktemp -d "$HOME/qwen3-api.XXXXXX")"
cd "$llm_dir"
mkdir downloads engine cuda models
Laden Sie die beiden offiziellen Veröffentlichungsarchive herunter: die Anwendung und ihre CUDA-Bibliotheken. Die --proto-Optionen beschränken Downloads und Weiterleitungen auf HTTPS.
llm_release='https://github.com/ggml-org/llama.cpp/releases/download/b11146'
curl --fail --location --proto '=https' --proto-redir '=https' \
"$llm_release/llama-b11146-bin-ubuntu-cuda-12.8-x64.tar.gz" \
--output downloads/llama.tar.gz
curl --fail --location --proto '=https' --proto-redir '=https' \
"$llm_release/cudart-llama-b11146-bin-ubuntu-cuda-12.8-x64.tar.gz" \
--output downloads/cudart.tar.gz
printf '%s %s\n' \
'c2ab9e19838513ff69d1af8d999ad717dd3c7ee4714ac04c7ed5ab9077c50e4e' downloads/llama.tar.gz \
'1466daea60aad1144819e151b2bae19d54556cf1da6c129c4f55a5ded2637c25' downloads/cudart.tar.gz \
| sha256sum --check
Beide Einträge müssen melden: OK. Entpacken Sie nach einem Download- oder Prüfsummenfehler keine Datei und fahren Sie nicht fort. Eine Prüfsumme belegt die Übereinstimmung mit dem festgelegten Artefakt; sie ersetzt nicht das Vertrauen in den Herausgeber.
Laden Sie das Modell aus dem Repository seines Herausgebers in der Revision 7c41481f57cb95916b40956ab2f0b139b296d974 herunter, statt aus dem veränderlichen main-Branch:
llm_model_source='https://huggingface.co/Qwen/Qwen3-8B-GGUF/resolve/7c41481f57cb95916b40956ab2f0b139b296d974'
curl --fail --location --proto '=https' --proto-redir '=https' \
"$llm_model_source/Qwen3-8B-Q4_K_M.gguf" \
--output models/Qwen3-8B-Q4_K_M.gguf
printf '%s %s\n' \
'd98cdcbd03e17ce47681435b5150e34c1417f50b5c0019dd560e4882c5745785' \
models/Qwen3-8B-Q4_K_M.gguf | sha256sum --check
curl --fail --location --proto '=https' --proto-redir '=https' \
"$llm_model_source/LICENSE" --output models/LICENSE
curl --fail --location --proto '=https' --proto-redir '=https' \
"$llm_model_source/README.md" --output models/README.md
Verlangen Sie erneut OK, bevor Sie das Modell laden. Bewahren Sie Lizenz und Modellkarte auf. Q4_K_M bezeichnet die gewählte Gewichtsvariante; es bedeutet nicht dieselbe Qualität oder Größe wie bei anderen Quantisierungen.
Laufzeit entpacken und CUDA-Zugriff bestätigen
Entpacken Sie ausschließlich die geprüften Archive in die zuvor erstellten leeren Verzeichnisse:
tar --extract --gzip --file downloads/llama.tar.gz \
--directory engine --no-same-owner --no-same-permissions
tar --extract --gzip --file downloads/cudart.tar.gz \
--directory cuda --no-same-owner --no-same-permissions
llm_server="$llm_dir/engine/llama-b11146/llama-server"
llm_libraries="$llm_dir/engine/llama-b11146:$llm_dir/cuda/cudart-llama-b11146-bin-ubuntu-cuda-12.8-x64"
env LD_LIBRARY_PATH="$llm_libraries" CUDA_VISIBLE_DEVICES=0 \
"$llm_server" --list-devices
Die Ausgabe sollte ein CUDA-Gerät und die vorgesehene GPU nennen. Der bloße Start eines CPU-Prozesses bestätigt keinen GPU-Betrieb. Fehlt eine Bibliothek, prüfen Sie beide Archive und die Pfade, statt unpassende .so-Dateien in Systemverzeichnisse zu kopieren.
API ausschließlich an Server-Localhost binden
Starten Sie den Prozess in derselben Sitzung auf der ersten GPU. Wir verwenden einen Slot und 8704 Tokens Kontext bei deaktivierter automatischer Parameteranpassung. Dies ist eine Ausgangskonfiguration für Integrationsprüfungen, keine für jede Anwendung optimierte Einstellung.
env LD_LIBRARY_PATH="$llm_libraries" CUDA_VISIBLE_DEVICES=0 \
"$llm_server" \
-m "$llm_dir/models/Qwen3-8B-Q4_K_M.gguf" \
--host 127.0.0.1 --port 8080 \
-ngl 999 --fit off --load-mode mmap --lazy-mode off -fa on \
-t 16 -b 2048 -ub 512 -ctk f16 -ctv f16 \
-np 1 -c 8704 \
--cache-ram 0 --no-cache-idle-slots --no-context-shift
Lassen Sie dieses Terminal geöffnet. Führen Sie nach der vorherigen CUDA-Geräteprüfung nvidia-smi in einer separaten SSH-Sitzung aus: Sie sollten den llama-server-Prozess und belegten GPU-Speicher sehen, mit GPU-Aktivität während einer Anfrage. Die Standardprotokollierung dieses Builds kann die Anzahl der auf die GPU ausgelagerten Schichten auslassen; allein das Fehlen dieser Zeile bedeutet keine reine CPU-Ausführung. --host 127.0.0.1 ist hier wichtig: Ersetzen Sie es nicht durch 0.0.0.0 und öffnen Sie Port 8080 nicht am Router. Optionen und Endpunkte beschreibt die llama-server-Dokumentation dieser Revision.
Von Ihrem Rechner verbinden
In einem zweiten Terminal auf Ihrem eigenen Rechner starten Sie einen Tunnel. Ersetzen Sie gpu-server.example, Benutzername, Schlüsselpfad und Port 22 durch Ihre Serverangaben. Verwenden Sie den bei der Installation gewählten SSH-Port, gegebenenfalls 3414 oder einen zufälligen Port. Kopieren Sie Ihren privaten Schlüssel nicht auf den Server.
ssh -N -T -a \
-i "$HOME/.ssh/gpu-server" -p 22 \
-o ExitOnForwardFailure=yes \
-o ServerAliveInterval=30 -o ServerAliveCountMax=3 \
-L 127.0.0.1:18080:127.0.0.1:8080 \
gpu@gpu-server.example
Prüfen Sie den Hostschlüssel bei der ersten Verbindung über einen bekannten vertrauenswürdigen Kanal. Deaktivieren Sie die Prüfung der Hostidentität nicht. Der Tunnel bindet Port 18080 nur an den Localhost Ihres Rechners und leitet ihn an Port 8080 aus Sicht des Servers weiter. Siehe die OpenSSH-Dokumentation zu -L und -N.
In einem dritten Terminal, ebenfalls auf Ihrem eigenen Rechner, prüfen Sie die Bereitschaft:
curl --fail --show-error http://127.0.0.1:18080/health
Bereitschaft bedeutet HTTP 200 mit {"status":"ok"}. HTTP 503 kann während des Modellladens auftreten. Senden Sie anschließend eine kurze Streaming-Anfrage:
curl --fail --show-error --no-buffer \
http://127.0.0.1:18080/completion \
-H 'Content-Type: application/json' \
--data '{"prompt":"Write one sentence about GPU memory.","n_predict":32,"stream":true,"cache_prompt":false,"temperature":0}'
Hier prüft /completion die lokale Generierung und Antwortübertragung. Es ist weder eine vollständige Chatvorlage noch eine Bewertung der Modellqualität. Die Parameter dieser kurzen Prüfung sind keine empfohlenen Qwen-Einstellungen für jedes Gespräch. Wählen Sie Chatintegration, Vorlage und Generierungseinstellungen Ihrer Anwendung anhand der Qwen-Modellkarte und der Serverdokumentation.
Fehlerbehebung
| Symptom | Nächste Prüfung |
|---|---|
| SHA-256-Abweichung | Datei nicht ausführen; vollständigen Download und URL der genauen Version prüfen. |
| CUDA-Bibliothek oder -Gerät fehlt | Treiber, beide Archive und LD_LIBRARY_PATHprüfen; CPU-Ausführung ist keine GPU-Validierung. |
| Tunnel meldet belegten Port | Einen anderen lokalen Port als 18080 wählen und in curl. |
| SSH verweigert Weiterleitung | Die Weiterleitungsrichtlinie des Kontos mit dem Administrator prüfen; nicht durch öffentliche Freigabe der API umgehen. |
| HTTP 503 | Modellladeprotokoll prüfen; wenn der Prozess beendet wurde, den Fehler lesen statt unbegrenzt zu warten. |
| Nicht genügend Speicher | Andere GPU-Prozesse, Kontext und Slotanzahl prüfen; jeweils nur eine Einstellung ändern. |
Zum Beenden des Versuchs drücken Sie Ctrl+C im Serverterminal und danach im Tunnelterminal. Ein Neustart der Maschine ist nicht nötig. Downloads bleiben im separaten Verzeichnis für einen späteren Lauf erhalten.
Sicherheits- und Lizenzgrenzen
Loopback plus Tunnel begrenzt den Netzwerkzugriff, authentifiziert aber keine anderen lokalen Prozesse oder Personen mit Kontozugriff. Nutzen Sie in dieser Phase Testdaten. Ein dauerhafter Dienst benötigt ein separates Konzept für Authentifizierung, Anfragelimits, Aktualisierungen und Protokollaufbewahrung. Eine API für Kunden bereitzustellen ist eine weitere Bereitstellungsphase, kein bloßer Adresswechsel per Schalter.
Qwen3-8B-GGUF verwendet Apache-2.0 in der festgelegten Revision, llama.cpp dagegen die MIT-Lizenz. NVIDIA-Bibliotheken unterliegen separaten CUDA-Bedingungen. Nehmen Sie nicht an, dass die Lizenz dieses Modells auch andere Qwen-Varianten oder Umgebungskomponenten abdeckt. Gewichte werden direkt vom Herausgeber geladen; GPU Server Hub verteilt sie über diesen Ratgeber nicht weiter.
Für den Schritt vom Versuch zur eigenen Anwendung prüfen Sie die Serverkonfiguration oder beschreiben Sie uns Modell, Kontext und erwartete Last. Unsere Tests und Ratgeber unterscheiden eine funktionierende Installation von einer Leistungsmessung.