Kurz gesagt. Ein GPU VPS ist 2026 die Standard-Compute-Einheit für KI-Workloads – egal ob du ein LLM für Nutzer bereitstellst oder auf eigenen Daten feinabstimmst. Inferenz ist ein Burst-Workload, der nach Modellparametern dimensioniert wird. Training hält die GPU stundenlang oder tagelang bei voller Auslastung und braucht ein Vielfaches mehr VRAM. Die richtige GPU-VPS-Größe hängt davon ab, welche dieser beiden Aufgaben du ausführst – und in welcher Modellgröße.
Die Frage nach dem besten GPU VPS für KI und nach der richtigen Dimensionierung laufen letztlich auf dasselbe hinaus, und die Antwort ändert sich komplett, je nachdem ob du Inferenz oder Training betreibst. Dieser Guide behandelt beide Wege: VRAM für jeden Anwendungsfall korrekt auslegen, LLM-Inferenz mit Ollama, vLLM und llama.cpp betreiben, ein Modell mit LoRA und QLoRA feinabstimmen – und warum GPUs diese Workload-Kategorie gegenüber CPUs dominieren.
KI-Training vs. Inferenz: unterschiedliche GPU-Anforderungen
Training und Inferenz belasten eine GPU auf fast entgegengesetzte Weise. Beides gleichzusetzen ist der häufigste Fehler bei der Dimensionierung.
| Dimension | Training | Inferenz |
|---|---|---|
| GPU-Auslastung | Dauerhaft 90–100 % für den gesamten Lauf | Burst-artig, oft idle zwischen Anfragen |
| VRAM-Bedarf | Gewichte, Gradienten und Optimizer-Zustand zusammen | Nur Gewichte plus kleiner KV-Cache |
| Dauer | Stunden bis Wochen pro Lauf | Millisekunden bis Sekunden pro Anfrage |
| Genauigkeit | FP16 oder BF16 Mixed Precision | Oft INT8 oder INT4 quantisiert |
| Kostenmodell | Zeitlich begrenzter Lauf, provisionieren und freigeben | Always-on, für dauerhaften Betrieb dimensioniert |
Eine GPU für KI-Training braucht Headroom für Gradienten und Optimizer-Zustand zusätzlich zu den Modellgewichten – das ist der Grund, warum ein 7B-Trainingslauf ein Vielfaches mehr VRAM benötigt als ein 7B-Inferenz-Deployment. Inferenz wird dagegen von Gewichten und einem vergleichsweise kleinen Request-Cache dominiert, weshalb Quantisierung bei Inferenz-VRAM einen so großen Unterschied macht.
Wie viel VRAM brauchst du wirklich?
VRAM ist die entscheidende Engstelle für Training und Inferenz gleichermaßen – die Rechnung unterscheidet sich jedoch deutlich. VRAM von Anfang an richtig auszulegen vermeidet den häufigsten Fehler: eine Karte zu provisionieren, die mitten im Job den Speicher erschöpft. Für Inferenz bei FP16-Genauigkeit gilt die Faustregel: Parameteranzahl mal 2 Bytes ergibt den minimalen VRAM. Ein 7B-Modell braucht allein zum Laden der Gewichte etwa 14 GB. Training multipliziert das grob mit dem Faktor 4 bis 6, weil die GPU nun Gradienten, Optimizer-Zustand (Adam-Optimizer halten zwei zusätzliche Kopien pro Parameter) und Aktivierungsspeicher neben den Gewichten halten muss.
Quantisierung verändert die Inferenzseite dieser Rechnung erheblich. INT4 reduziert den Speicherbedarf der Gewichte gegenüber FP16 grob um den Faktor 4 – genau deshalb lassen sich mit quantisierten Modellen auf derselben Karte deutlich größere Parameteranzahlen nutzen.
Der VRAM-Bedarf für KI-Workloads skaliert vorhersehbar mit der Modellgröße:
| Modellgröße | Inferenz VRAM (FP16) | Inferenz VRAM (INT4) | Feinabstimmung VRAM | Vollständiges Training VRAM |
|---|---|---|---|---|
| 7B | 14 GB | 5 GB | 16 GB | 56 GB |
| 13B | 26 GB | 9 GB | 28 GB | 104 GB |
| 34B | 68 GB | 20 GB | Multi-GPU | Multi-GPU |
| 70B | 140 GB | 40 GB | Multi-GPU | Multi-GPU |
Der Sprung von 13B auf 34B ist der Punkt, ab dem Single-GPU-VPS-Deployments für vollständiges Training generell aufhören zu funktionieren – allerdings passen INT4-Inferenz und LoRA-basierte Feinabstimmung auch deutlich darüber hinaus noch auf eine einzelne Karte.
LLM-Inferenz auf einem GPU VPS betreiben
Drei Tools decken die meisten GPU-Inferenz-Deployments ab und bieten jeweils unterschiedliche Trade-offs zwischen Einfachheit und Kontrolle.
Ollama ist der einfachste Weg zur lokalen LLM-Inferenz. Im GPU-Modus führt Ollama GGUF-Format-Modelle mit einem einzigen Befehl aus, fällt bei fehlender GPU auf die CPU zurück und übernimmt Quantisierung automatisch. Es ist der richtige Einstiegspunkt für alle, die ein Modell in Minuten statt nach einer Stunde Konfigurationsaufwand zum Laufen bringen wollen.
vLLM ist für Production-Inferenz-Serving gebaut, nicht für schnellen lokalen Einsatz. Die PagedAttention-Speicherverwaltung ermöglicht es, viele gleichzeitige Anfragen effizient zu batchen; außerdem stellt vLLM eine OpenAI-kompatible API bereit, sodass bestehender Client-Code oft nur eine Base-URL-Änderung benötigt.
llama.cpp bietet von den drei Tools die flexibelsten Quantisierungsoptionen – von voll-präzisen Gewichten bis hin zu aggressiver Sub-4-Bit-Quantisierung. Es bildet auch die Grundlage von Ollamas eigenem Inferenz-Engine.
| Tool | Modellformat | Quantisierungsunterstützung | GPU-Auslastung | Am besten für |
|---|---|---|---|---|
| Ollama | GGUF | Automatisch, mehrere Voreinstellungen | Vollständiges oder teilweises GPU-Offloading | Schnelle lokale LLM-Inferenz |
| vLLM | HuggingFace / safetensors | FP16, INT8, AWQ, GPTQ | Vollständige GPU, optimiertes Batching | Production-API-Serving |
| llama.cpp | GGUF | Umfangreich, bis 2-Bit | Vollständig, teilweise oder nur CPU | Maximale Quantisierungsflexibilität |
| TGI | HuggingFace / safetensors | FP16, INT8, bitsandbytes | Vollständige GPU, Continuous Batching | HuggingFace-native Deployments |
Die VRAM-Stufe, die du provisionierst, bestimmt, welche Modellgrößen tatsächlich nutzbar sind: 16 GB laufen ein quantisiertes 13B-Modell komfortabel über Ollama oder llama.cpp, während eine 24-GB-Karte Full-Precision-13B-Inferenz oder quantisierte 34B-Modelle ohne Headroom-Probleme ermöglicht.
GPU-Training: LLM feinabstimmen auf einem GPU VPS mit LoRA und QLoRA
Vollständiges Fine-Tuning eines großen Modells erfordert Multi-GPU-Infrastruktur – aber LoRA und QLoRA machen GPU-Deep-Learning auf einem einzelnen GPU VPS für 7B- bis 13B-Basismodelle praktikabel. Bei dieser Modellgröße hängt die Wahl der richtigen GPU fast immer am VRAM statt an der Rohrechenleistung, da LoRA und QLoRA gezielt so entwickelt wurden, dass sie innerhalb der Speichergrenze einer einzelnen Karte funktionieren. LoRA stimmt eine kleine Menge zusätzlicher Gewichte ab statt des vollständigen Modells; QLoRA ergänzt das um 4-Bit-Quantisierung, was ein 7B-Fine-Tune in 16 GB VRAM ermöglicht.
Das Standard-Tooling für solche Machine-Learning-GPU-Workloads hat sich auf einige Tools eingependelt: HuggingFace PEFT kombiniert mit bitsandbytes übernimmt Quantisierung und Adapter-Mechanik direkt; Axolotl verpackt das in einen konfigurationsgetriebenen Workflow; Unsloth optimiert denselben Prozess für schnelleres Training auf einer einzelnen Karte. Alle drei bauen auf PyTorch auf, das als Standard-Deep-Learning-Framework für diese Arbeit gilt.
Eine praktische Checkliste vor dem Start eines Fine-Tuning-Laufs:
- Datensatzgröße. Mehr als 1.000 Beispiele ist ein sinnvoller Mindestwert, damit ein LoRA-Fine-Tune einen messbaren Effekt zeigt.
- Basismodell-Auswahl. Mistral, Llama 3 und Qwen sind häufige aktuelle Ausgangspunkte mit guter Community-Tooling-Unterstützung.
- QLoRA-Konfiguration. r=16, alpha=32 ist ein vernünftiger Standardwert für Adapter-Rang und Skalierung.
- Batch-Größe. Starte bei 4 und erhöhe, bis ein Out-of-Memory-Fehler auftritt – dann einen Schritt zurück.
- Gradient Checkpointing. Tauscht Trainingsgeschwindigkeit gegen VRAM-Headroom und lohnt sich auf Single-GPU-Setups fast immer.
GPU vs. CPU für KI: Warum GPUs dominieren
CPUs haben hohe Single-Core-Geschwindigkeit, aber selbst bei Server-Hardware nur 8 bis 128 Kerne. Transformer-Modelle laufen über Millionen von parallelen Matrixmultiplikationen pro Forward Pass – genau die Workload, für die GPU-Architektur gebaut ist: Tausende kleinere Kerne, die dieselbe Operation gleichzeitig ausführen statt ein Kern, der sie schnell sequenziell abarbeitet. Das ist der Grund, warum GPU für KI zum Standard geworden ist – wobei der tatsächliche Geschwindigkeitsvorteil weit stärker variiert, als die meisten Guides zugeben: Für ein 7B-Modell zeigen manche Benchmarks, dass eine moderne CPU mit optimierter Inferenz-Engine auf einen Faktor 1,3 bis 2x des GPU-Durchsatzes kommt, während andere einen Faktor 10 bis 30 messen – stark abhängig von CPU, GPU, Quantisierungsstufe und Inferenz-Engine. Der Abstand wächst bei größeren Modellen deutlich, wo die begrenzte Speicherbandbreite der CPU zur Engstelle wird statt die Kernanzahl.
Eine NVIDIA-GPU für KI ist heute praktisch der Standard – zu groß ist der Teil des Ökosystems, der von PyTorch über vLLM bis zum Ollama-GPU-Backend primär auf CUDA ausgerichtet ist. TPUs und NPUs existieren und bieten innerhalb der Hyperscaler, die sie gebaut haben, echte Vorteile – bleiben aber außerhalb dieses Kontexts eine Nische. Nahezu alle selbst gehosteten KI-Infrastrukturen laufen auf GPUs.
GPU VPS für KI auswählen: die wichtigsten Specs
Einige wenige Specs entscheiden darüber, ob ein GPU VPS für KI-Workloads tatsächlich zur Aufgabe passt:
- VRAM. 24 GB sind ein praktischer Sweet Spot: ausreichend für 13B-Inferenz bei FP16 und ein 7B-Fine-Tune auf derselben Karte.
- GPU-Generation. Ampere-Generation oder neuer wird für BF16-Support benötigt, den die meisten aktuellen Training- und Inferenz-Codebasen standardmäßig voraussetzen.
- NVMe-Storage. Modellgewichte reichen von wenigen GB bis weit über 100 GB; NVMe verhindert, dass das Laden von Modellen und das Schreiben von Checkpoints zur Engstelle werden.
- CPU-Arbeitsspeicher. Sollte mindestens dem VRAM entsprechen, damit Datenpräprocessing und Modell-Laden die GPU nicht ausbremsen.
- Netzwerk-Egress. Das wiederholte Pullen von Modellen aus HuggingFace summiert sich; Egress-Konditionen prüfen, wenn du viele Modelle rotierst.
Die Dimensionierung eines GPU VPS für KI folgt auf jeder Stufe demselben Muster: VRAM auf die größte Modell-Task-Kombination abstimmen, dann sicherstellen, dass CPU-Arbeitsspeicher und Storage nicht die eigentliche Engstelle sind, sobald die GPU korrekt dimensioniert ist.
Object Storage für KI-Datensätze und Modell-Checkpoints
Trainingsdatensätze und Modell-Checkpoints häufen sich schnell an – oft auf mehrere Hundert Gigabyte über ein einzelnes Feinabstimmungs-Projekt. Das Staging dieser Daten über S3-kompatiblen Object Storage mit rclone oder s5cmd hält sie zwischen den Läufen vom GPU-VPS-Disk: Datensatz zu Jobstart reinkopieren, Checkpoints nach jeder Epoch rausschieben – die VPS-Disk muss nie mehr als das Working-Set des aktuellen Laufs halten.
Das Streaming des Datensatzes statt des Kopierens ist beim Training ebenfalls eine Option – aber nur wenn es richtig umgesetzt wird: Daten in tar-Dateien sharden und mit einem dafür gebauten Loader lesen, etwa WebDataset oder MosaicML Streaming, die Daten sequenziell in großen Chunks abrufen. Was nicht funktioniert, ist eine Trainingsschleife auf einen FUSE-Mount zeigen zu lassen und viele kleine Dateien per Random Read zu laden – das ist bestenfalls langsam und schlimmstenfalls unzuverlässig. Entweder sequenzielles Streaming mit einem echten Streaming-Loader oder Daten vorab auf lokale Disk stagen. Einen FUSE-Mount nicht wie ein lokales Dateisystem für Random Access behandeln.
Das entkoppelt Compute von Storage. Ein GPU VPS kann zwischen Trainingsläufen komplett heruntergefahren werden, ohne dass Checkpoints oder Datensätze verloren gehen – alles Dauerhafte liegt in Object Storage statt auf dem Server selbst. Das ist einer der praktischen Vorteile von GPU-Server-Hosting gegenüber einer festen lokalen Workstation: Storage und Compute skalieren unabhängig voneinander.
Warum KI-Workloads auf Contabo betreiben
Drei Faktoren entscheiden am stärksten darüber, ob ein GPU-VPS-Anbieter für dauerhaftes KI-Training und Inferenz passt – und hier unterscheidet sich der Ansatz bei Contabo am deutlichsten vom typischen Hyperscaler, beginnend beim Abrechnungsmodell.
Flat-Rate-Abrechnung eliminiert das Risiko überraschend hoher Rechnungen, das per-Sekunde-Hyperscaler-Billing mit sich bringt. Ein langer Trainingslauf oder ein dauerhaft betriebener Inferenz-Endpunkt kostet bei Contabo denselben planbaren Betrag, unabhängig davon, wie viele Stunden er genau läuft – das ist für KI-Workloads viel wichtiger als für typisches Web-Hosting, da ein steckengebliebener Trainingsjob auf per-Sekunde-Billing eine teure Überraschung werden kann.
Arbeitsspeicher ist für KI-Workloads genauso wichtig wie VRAM, weil Datenpräprocessing, Tokenisierung und Dataset-Laden alle im System-RAM passieren, bevor überhaupt etwas die GPU erreicht. GPU-Server-Pläne bei Contabo kombinieren ausreichend CPU-Arbeitsspeicher mit der GPU und vermeiden so eine zweite, leicht zu übersehende Engstelle.
EU-Rechenzentrums-Standorte sind relevant für DSGVO-konforme KI-Inferenz, insbesondere bei jedem Deployment, das nutzereingereichte Texte oder Dokumente verarbeitet und bei dem Datenspeicherort eine echte Compliance-Anforderung ist und keine optionale Verbesserung. Die EU-basierte Infrastruktur bei Contabo deckt das standardmäßig ab, ohne zusätzliche Konfiguration.
FAQ: GPU VPS für KI-Training und Inferenz
Für Ollama-GPU-Inferenz laufen quantisierte 13B-Modelle komfortabel mit 16 GB VRAM; 24 GB bieten Headroom für Full-Precision-13B oder quantisierte 34B-Modelle. Ein GPU VPS, der auf dein Zielmodell ausgelegt ist und CPU-Arbeitsspeicher mindestens in VRAM-Höhe hat, deckt die große Mehrheit lokaler LLM-Anwendungsfälle ohne Multi-GPU-Infrastruktur ab.
Vollständiges Training benötigt grob 4 bis 6 Mal so viel VRAM wie Inferenz bei derselben Modellgröße, weil Gradienten, Optimizer-Zustand und Aktivierungen neben den Gewichten Platz finden müssen. Ein 7B-Modell braucht am unteren Ende dieser Spanne etwa 56 GB – damit ist der Rahmen der meisten Single-GPU-VPS-Stufen überschritten. LoRA und QLoRA reduzieren das drastisch: Ein 7B-Fine-Tune passt in 16 GB.
Ja, für 7B- bis 13B-Modelle mit LoRA oder QLoRA statt vollständigem Fine-Tuning. QLoRAs 4-Bit-Quantisierung macht das auf einer einzelnen Karte erst praktikabel: Ein 7B-Fine-Tune passt in 16 GB VRAM, ein 13B-Fine-Tune in etwa 28 GB. Vollständiges Training derselben Modelle erfordert Multi-GPU-Infrastruktur weit jenseits dessen, was ein einzelner GPU VPS bietet.
GPU-Training hält Modell, Gradienten und Optimizer-Zustand gleichzeitig im VRAM, während es stunden- oder tagelang bei dauerhaft hoher Auslastung läuft. GPU-Inferenz benötigt nur die Modellgewichte plus einen kleinen Request-Cache und läuft in kurzen Bursts statt kontinuierlich. Das ist der Grund, warum ein Modell, das 56 GB zum Trainieren braucht, seine Inferenz komfortabel auf einer 14-GB-Karte laufen lässt.
Einen GPU-Server mit Flat-Rate-Billing zu mieten ist für Workloads, die den Großteil des Tages laufen, typischerweise günstiger als AWS oder andere Hyperscaler-GPU-Instanzen mit Sekundenabrechnung. Für echte Gelegenheits-Workloads, die die meiste Zeit idle sind, kann Hyperscaler-Billing günstiger ausfallen – weil im Idle nichts anfällt. Ab einer täglichen Auslastung von etwa 12 bis 16 Stunden lohnt sich das Mieten eines GPU-Servers.
Transformer-Modelle laufen als Millionen paralleler Matrixmultiplikationen pro Forward Pass, und die Tausenden kleinerer Kerne einer GPU erledigen diese Art paralleler Mathematik weit schneller als die deutlich kleinere Kernanzahl einer CPU. Das ist der Kerngrund, warum GPU für KI der Standard ist: Die Workload-Form passt nahezu exakt zur GPU-Architektur – auf eine Art, die zur auf schnelle sequenzielle Ausführung ausgelegten CPU-Architektur nicht passt.
