Wie man ein LLM auf einem privaten GPU-Server selbst hostet

Ein Sprachmodell auf gemieteter Hardware laufen zu lassen ist der einzige Weg, sicherzugehen, dass Ihre Prompts von niemandem außer Ihnen protokolliert, gespeichert oder gelesen werden. Jede gehostete API — wie gut ihre Datenschutzrichtlinie auch sein mag — erhält jedes Token, das Sie senden, und diese Richtlinie kann sich ändern, ohne dass Sie etwas davon mitbekommen. Self-Hosting verschiebt die Grenze: Die Gewichte liegen auf einer Festplatte, die Sie kontrollieren, Inferenz läuft in VRAM, das Sie stundenweise gemietet haben, und nichts verlässt die Maschine, außer Sie schicken es irgendwohin. Auf der Software-Seite ist das inzwischen wirklich einfach geworden. Was Leute immer noch stolpern lässt, ist die Karte vor der Bestellung richtig zu dimensionieren — und daran zu denken, dass ein offener Inferenz-Port ein offener Inferenz-Port ist.

Was Self-Hosting tatsächlich bringt — und was nicht

Seien Sie beim Nutzen genau, denn "private KI" wird recht großzügig verkauft. Ein Modell auf der eigenen GPU verändert manche Dinge vollständig — und andere überhaupt nicht.

• Ihre Prompts und Ausgaben bleiben auf der Maschine — keine Protokollierung beim Anbieter, kein Aufbewahrungszeitraum, kein Datensatz, der aus Ihren Anfragen entsteht.
• Kein Konto, kein Rate-Limit pro Key und keine Richtlinien-Ebene zwischen Ihnen und den Gewichten. Das Modell, das Sie bereitgestellt haben, ist das Modell, das Sie bekommen.
• Planbare Kosten bei Volumen. Ab einigen Millionen Tokens pro Tag ist eine gemietete Karte günstiger als Pay-per-Token, und der Preis ändert sich nicht, wenn ein Anbieter seine Liste überarbeitet.
• Es macht ein schwaches Modell nicht stark. Ein Open-Weights-Modell auf eigener Hardware bleibt genau dieses Modell — Self-Hosting kauft Kontrolle, keine Spitzenleistung.
• Es verbirgt nichts vor dem Host. Wer physischen Zugriff auf eine laufende Maschine hat, kann im Prinzip ihren Arbeitsspeicher auslesen — das ist eine Frage des Hosts, nicht des Modells.

VRAM ist das ganze Spiel: ein Modell auf eine Karte dimensionieren

Fast jeder gescheiterte erste Versuch ist ein Rechenfehler bei VRAM. Gewichte, KV-Cache und Arbeitsspielraum müssen alle gleichzeitig auf die Karte passen, und es gibt keine sanfte Degradation — Sie bekommen einen Out-of-Memory-Fehler ein paar Sekunden nach Ladebeginn. Die Faustregel ist brauchbar: Bei 16-bit-Genauigkeit braucht ein Modell etwa 2 GB VRAM pro Milliarde Parameter, etwa 1 GB bei 8-bit und etwa 0,6 GB bei 4-bit. Dazu kommt der KV-Cache, der mit der Kontextlänge und mit gleichzeitigen Anfragen wächst — und der es ist, der Ihnen in der Produktion zusetzt, nicht im Test.

• Ein 7B- bis 8B-Modell: etwa 16 GB bei FP16, oder komfortabel unter 8 GB bei 4-bit. Das ist die Klasse, die auf eine RTX A4000 16 GB passt, mit Reserve.
• Ein 13B- bis 14B-Modell: rund 28 GB bei FP16, etwa 9 GB bei 4-bit. Eine RTX 4090 24 GB betreibt es quantisiert mit reichlich Kontext übrig.
• Ein 30B- bis 34B-Modell: rund 68 GB bei FP16, nahe 20 GB bei 4-bit — der natürliche Platz für eine RTX 5090 32 GB.
• Ein 70B-Modell: etwa 140 GB bei FP16, rund 40 GB bei 4-bit. Das bedeutet einen A100 oder H100 80 GB — und bei voller Genauigkeit mehr als eine Karte.
• Langer Kontext vervielfacht den KV-Cache, nicht die Gewichte. Ein 128k-Token-Fenster kann bei einem großen Modell allein schon Dutzende Gigabyte verlangen — kalkulieren Sie das vor der Bestellung ein, nicht danach.

Die GPU wählen: von der A4000 bis zum H100 — und wann sich stündlich mehr lohnt als monatlich

Jeder Plan der GPU-Server-Reihe ist eine ganze physische Karte mit ihrem gesamten VRAM — keine MIG-Partitionierung, kein Time-Sharing —, sodass die Zahl im Datenblatt auch die Zahl ist, die Sie tatsächlich ausschöpfen können. Wählen Sie die Karte passend zum Modell, das Sie tatsächlich bedienen wollen, nicht zu dem, das Sie vielleicht irgendwann einmal ausprobieren.

• RTX A4000 16 GB für $89/mo — 8 vCPU und 64 GB RAM. Genug für einen quantisierten 7B- bis 13B-Assistenten, einen Embedding-Dienst oder eine Klassifikationspipeline, die den ganzen Tag läuft.
• RTX 4090 24 GB für $189/mo — 16 vCPU, 128 GB und 2 TB NVMe. Das beste Preis-Leistungs-Verhältnis pro Token für 13B- bis 34B-Modelle bei 4-bit, und die übliche Wahl für einen kleinen Produktions-Endpunkt.
• RTX 5090 32 GB für $279/mo — 24 vCPU und 192 GB. Diese zusätzlichen 8 GB machen oft den Unterschied zwischen einem 34B-Modell, das mit echtem Kontext passt, und einem, das es nicht tut.
• A100 80 GB für $690/mo — 32 vCPU, 256 GB und 4 TB NVMe. HBM2e-Bandbreite und genug Speicher für ein 70B bei 4-bit mit langem Fenster, oder für stark gebündeltes Serving.
• H100 80 GB für $1190/mo — 48 vCPU, 384 GB, 8 TB NVMe und ein Port mit 10 Gbps. FP8-Unterstützung und HBM3-Bandbreite machen es zur einzig sinnvollen Wahl für ernsthaften Durchsatz oder für Training.

Abgerechnet wird stündlich oder monatlich aus demselben Prepaid-Guthaben, und das verändert die Rechnung mehr, als man denkt. Eine Auswertung, die zwei Nachmittage auf einem H100 braucht, kostet die gelaufenen Stunden, nicht einen Monat. Ein Chat-Endpunkt, der um drei Uhr morgens antworten muss, will dagegen eine monatliche Box. Wenn Sie mehrere Karten in einer Maschine brauchen, oder eine GPU neben viel lokalem Speicher, ist ein dedizierter Server die bessere Form — und der allgemeine Fall des Bezahlens mit Krypto wird in GPU-Server mit Krypto mieten behandelt.

Schritt für Schritt: von der Krypto-Aufladung zum laufenden Endpunkt

1. 01Konto mit einer Wegwerf-E-Mail-Adresse anlegenEine E-Mail-Adresse und ein Passwort. Kein Name, keine Telefonnummer, kein Ausweis — auf unserer Seite verknüpft nichts das Modell, das Sie betreiben, mit Ihnen.
2. 02Guthaben in Krypto aufladenLaden Sie ein Prepaid-Guthaben mit Bitcoin, Monero oder einem von 8 Coins auf. Es verfällt nie und wird nie eingefroren.
3. 03Eine GPU-Instanz auf einem CUDA-Image bereitstellenWählen Sie die Karte, eine Region und ein CUDA-fertiges Image mit aktuellen Treibern und PyTorch. Die Box ist in wenigen Minuten bereit.
4. 04Prüfen, dass die Karte sichtbar ist, bevor Sie irgendetwas ladenEin einzelner nvidia-smi-Aufruf zeigt die GPU, die Treiberversion und den freien VRAM. Das ist eine Zehn-Sekunden-Prüfung, die eine Stunde Verwirrung erspart.
5. 05Die Gewichte auf lokales NVMe ladenHolen Sie das Modell auf die eigene Festplatte der Instanz statt auf ein Netzlaufwerk. Gewichte kommen auf Dutzende Gigabyte, und Sie werden sie mehr als einmal laden.
6. 06Den Server an localhost gebunden startenStarten Sie vLLM oder Ollama auf 127.0.0.1, bestätigen Sie eine Completion lokal, und entscheiden Sie erst danach, wie Sie von außen darauf zugreifen.

vLLM, Ollama oder llama.cpp: den Serving-Stack wählen

Drei Stacks decken fast jeden Fall ab, und der richtige hängt davon ab, wie viele Anfragen der Endpunkt sehen wird — nicht davon, welcher technisch am beeindruckendsten ist.

• Ollama — der kürzeste Weg von null zu einem funktionierenden Endpunkt. Ein einziger Befehl lädt ein quantisiertes Modell und stellt es hinter einer OpenAI-kompatiblen API bereit. Ideal für einen einzelnen Nutzer, einen Prototyp oder einen privaten Assistenten.
• vLLM — die Antwort für die Produktion. Continuous Batching und PagedAttention lassen eine einzelne Karte viele gleichzeitige Anfragen bedienen, mit einem Vielfachen des Durchsatzes einer naiven Schleife. Das ist der Unterschied zwischen einem Endpunkt für Sie und einem Endpunkt für eine Anwendung.
• llama.cpp — der Pragmatiker. GGUF-Quantisierungen bis 4-bit und darunter, CPU-Offload für Layer, die nicht mehr passen, und der niedrigste Speicherbedarf der drei. Es ist das, was ein überdimensioniertes Modell überhaupt erst auf einer zu kleinen Karte zum Laufen bringt.
• TGI, SGLang und TensorRT-LLM sind in bestimmten Szenarien noch schneller. Greifen Sie darauf zurück, sobald Sie einen Engpass gemessen haben — nicht davor.

Alle drei bieten eine OpenAI-kompatible Chat-Completions-Route, sodass Anwendungscode, der gegen eine kommerzielle API geschrieben wurde, meist nur eine geänderte Basis-URL braucht und sonst nichts. Diese Kompatibilität ist der praktische Grund, warum Self-Hosting aufgehört hat, ein Projekt zu sein, und zu einer Konfigurationsentscheidung geworden ist.

Den Endpunkt privat halten: den Inferenz-Port niemals exponieren

Ein Inferenz-Server ohne Authentifizierung ist das moderne Äquivalent einer offenen Datenbank. Scanner finden neue IPs innerhalb von Stunden, und ein exponierter Endpunkt bedeutet, dass jemand anders Ihre GPU-Stunden verbraucht — oder mitliest, was Ihre Anwendung auch immer darüber sendet.

Wenn der Endpunkt wirklich öffentlich sein muss — ein Produkt statt eines privaten Assistenten —, terminieren Sie TLS an einem Reverse-Proxy, verlangen Sie einen Bearer-Token, den Sie rotieren, und begrenzen Sie die Anfragerate pro Key. Diesen Proxy auf einem separaten kleinen VPS zu platzieren und die GPU-Box nur über den Tunnel erreichbar zu lassen, ist die sauberere Lösung. Das folgt derselben Logik wie beim Hosten einer Website ohne KYC: Die Maschine, die dem Internet zugewandt ist, sollte so wenig wie möglich vorhalten.

Fine-Tuning: wenn ein Nachmittag auf einer gemieteten Karte eine Monatsrechnung schlägt

Fine-Tuning ist das stärkste Argument fürs Mieten statt Abonnieren. Ein LoRA- oder QLoRA-Lauf auf einem 7B- bis 13B-Modell — ein paar Tausend Beispiele, eine Handvoll Epochen — ist auf einer 4090 in wenigen Stunden fertig und kostet genau die gelaufenen Stunden. Der dabei entstehende Adapter ist nur ein paar Hundert Megabyte groß, sodass Sie den Checkpoint behalten, die Instanz zerstören und den Adapter später für die Inferenz auf eine kleinere Karte laden können. Vollständige Fine-Tunes eines 70B-Modells sind ein anderes Budget und brauchen einen A100 oder H100 mit Platz für den Optimizer-Zustand, aber auch sie werden noch in Tagen gemessen, nicht in einem Vertrag.

Der Workflow, den stündliche Abrechnung ermöglicht, ist einfach: bereitstellen, trainieren, den Adapter von der Box kopieren, sie zerstören. Sie zahlen für die genutzte Rechenleistung, und dazwischen liegt keine untätige Karte. Halten Sie den Datensatz während der Arbeit auf dem NVMe der Instanz und ziehen Sie ihn danach wieder heraus — nichts, was Sie auf einer gemieteten Maschine liegen lassen, sollte je die einzige Kopie sein.

Der ehrliche Privatsphäre-Kompromiss bei einer GPU, die Ihnen nicht gehört

Self-Hosting beseitigt das größte und konkreteste Leck: einen Dritten, der jeden Prompt erhält, ihn für einen gewissen Aufbewahrungszeitraum speichert und selbst entscheidet, was damit geschieht. Auf einer gemieteten Karte leben das Modell und Ihre Daten in einer Maschine, die nur Ihrem Key gehorcht. Was das Mieten nicht beseitigen kann, ist der Host selbst. Wer physischen Zugriff auf einen laufenden Server hat, kann im Prinzip seinen Arbeitsspeicher auslesen, und Festplattenverschlüsselung auf einer entfernten Maschine schützt Sie vor einer gestohlenen Festplatte, nicht vor einer laufenden.

Die nützliche Frage lautet also nicht "kann der Host es sehen", sondern "weiß der Host, wer ich bin". No-KYC-Hosting beantwortet genau das: eine E-Mail-Adresse und ein Passwort, keine Verifizierung, nichts in den Akten, das geleakt oder per Vorladung herausgegeben werden könnte. Die Zahlung aus einem Krypto-Guthaben entfernt die Bank. Wie weit Sie das bei der Zahlung treiben, ist eine Frage des Threat-Modells — Bitcoin ist pseudonym, nicht anonym, sodass Coins, die zu einer verifizierten Börse zurückverfolgt werden, immer noch irgendwohin führen, während das Aufladen in Monero diese Lücke auf Protokollebene schließt.

Fehler, die still und leise GPU-Stunden verschwenden

• Nur nach den Gewichten dimensionieren und den KV-Cache vergessen, sodass das Modell brav lädt und dann bei der ersten langen Anfrage abstürzt.
• Ein Modell bei FP16 betreiben, obwohl dieselbe Karte es bei 4-bit mit dreifachem Kontext laufen lassen würde — wegen einer Qualitätssorge, die nie tatsächlich gemessen wurde.
• Vierzig Gigabyte an Gewichten auf ein Netzlaufwerk herunterladen und sich dann wundern, warum jeder Neustart zwanzig Minuten dauert.
• Den Server "nur zum Testen vom eigenen Laptop aus" an 0.0.0.0 gebunden lassen, was auf einer öffentlichen IP noch am selben Tag gefunden wird.
• Monatlich für eine Karte zahlen, die zwanzig Stunden am Tag untätig ist, obwohl die Workload eigentlich immer ein Batch-Job war.
• Mit jeweils nur einer Anfrage gleichzeitig benchmarken, daraus schließen, dass sich vLLM nicht lohnt, und dabei übersehen, dass sein ganzer Vorteil erst unter Nebenläufigkeit zum Tragen kommt.

Keiner dieser Fehler ist exotisch. Sie passieren, wenn die Karte gewählt wird, bevor das Modell feststeht. Legen Sie zuerst Modell und Quantisierung fest, rechnen Sie den VRAM-Bedarf ehrlich durch, halten Sie den Port geschlossen — und ein selbstgehostetes LLM gehört zu den anspruchslosesten Dingen, die Sie dauerhaft laufen lassen können.