VPS mit GPU: Wann Sie wirklich eine brauchen

Benötigen Sie einen VPS mit GPU, oder reicht eine CPU aus?

Ein VPS mit GPU verändert beim eigenen Betrieb eines Modells zwei Dinge: wie schnell Tokens ausgegeben werden und wie groß ein Modell überhaupt in den Speicher passt. Alles andere bleibt unverändert. Wenn Ihre Arbeitslast aus einem quantisierten 7B- bis 27B-Chatmodell besteht, das jeweils einer Person antwortet, aus einem Embedding-Job mit geringem Volumen oder aus der Sprachtranskription mit Whisper small, erledigt ein gewöhnlicher CPU-VPS mit ausreichend RAM diese Aufgaben bereits. Starten Sie mit der CPU, messen Sie den Wert, der Sie stört, und wechseln Sie dann auf eine leistungsfähigere Konfiguration.

Der Grund ist die Speicherbandbreite. Wenn ein Sprachmodell einen Token erzeugt, liest es alle benötigten Gewichte aus dem Speicher. Ein auf 4 Bit quantisiertes 8B-Modell ist auf der Festplatte ungefähr 4.9 GB groß und benötigt im Speicher etwa genauso viel. Für die Erzeugung eines Tokens müssen daher ungefähr 4.9 GB bewegt werden. Teilen Sie die Speicherbandbreite des Systems durch diesen Wert. Das Ergebnis ist die Obergrenze für Tokens pro Sekunde. Diese eine Division erklärt fast jeden Benchmark, den Sie lesen werden.

Was eine GPU tatsächlich bringt

Bandbreite. Server-DDR5 in einem modernen Host verarbeitet mehrere zehn Gigabyte pro Sekunde. GPU-Speicher (VRAM, Video-RAM) verarbeitet mehrere hundert bis über tausend. Dieses Verhältnis bestimmt den Geschwindigkeitszuwachs, und er ist erheblich.

Kapazität bei hoher Geschwindigkeit. Ein CPU-System mit 64 GB RAM kann ein 70B-Modell mit 4 Bit laden. Es läuft dann eher in einem Tempo, das dem Lesen als dem Chatten entspricht. Eine GPU hilft hier nur, wenn das Modell in den VRAM passt, denn sobald Layer in den System-RAM ausgelagert werden, bestimmt wieder der langsame Pfad die Geschwindigkeit.

Batch-Durchsatz. Diesen Punkt unterschätzen viele. Eine GPU, die für einen Benutzer generiert, lässt den Großteil ihrer Rechenleistung ungenutzt, weil sie auf den Speicher wartet. Wenn Sie 20 Anfragen gleichzeitig bedienen, versorgt derselbe Gewichtsabruf alle 20 Anfragen. Der aggregierte Durchsatz in Tokens pro Sekunde steigt dadurch um ein Mehrfaches, während die Geschwindigkeit pro Benutzer kaum abnimmt. CPU-Inference-Engines wie llama.cpp unterstützen ebenfalls Batching. Die Zugewinne hängen von der Hardware und der Arbeitslast ab. Wenn Sie eine API erstellen, die von vielen Clients aufgerufen wird, spricht Batching eher für eine GPU als die reine Geschwindigkeit eines einzelnen Datenstroms.

Prompt-Verarbeitung. Das Lesen eines langen Prompts ist rechengebunden, nicht speichergebunden. In diesem Bereich sind GPUs mit dem größten Abstand überlegen. Einen Kontext mit 30,000 Tokens, den eine CPU in einer Minute verarbeitet, bewältigt eine GPU in wenigen Sekunden. Bei Retrieval-Setups, die Dokumente in jede Anfrage einfügen, macht sich das ständig bemerkbar.

Grobe Zahlen und ihre Einordnung

Der tatsächliche Durchsatz liegt ebenfalls unter dem Quotienten aus Bandbreite und Modellgröße, weil die Attention über einen wachsenden Kontext zusätzliche Arbeit verursacht, die bei der einfachen Division unberücksichtigt bleibt.

Zum Vergleich: Erwachsene lesen englische Texte still im Durchschnitt mit etwa 4.0 bis 4.3 Wörtern pro Sekunde: 238 Wörter pro Minute bei Sachtexten und 260 bei Belletristik. Alles ab 15 Tokens pro Sekunde fühlt sich für einen einzelnen Leser bereits wie normales Tippen an. Deshalb sind viele Setups, die ausschließlich die CPU verwenden, in der Praxis unproblematisch.

VRAM dimensionieren, bevor Sie kaufen

Die Dateigröße des Modells ist die Untergrenze, nicht der tatsächliche Bedarf. Planen Sie die Gewichte, den KV-Cache (Key-Value-Cache, der von Attention pro Token benötigte Speicher) sowie etwa 1 GB Overhead ein.

Berechnen Sie den Cache, statt pauschal einen Prozentsatz hinzuzufügen, weil die Quantisierung der Gewichte den Cache nicht quantisiert. Für jeden Token speichert ein Modell mit vollständiger Attention für jede Schicht und jeden KV-Head einen Key und einen Value, mit 2 Bytes pro Zahl in FP16, dem Standard-Cache-Typ von Ollama. Die Modelldaten von Ollama, geprüft am 2026-10-27, nennen für Llama 3.1 8B 32 Schichten sowie 8 KV-Heads mit jeweils 128 Dimensionen. Das entspricht 128 KiB pro Token: etwa 1.07 GB bei einem 8k-Kontext und 2.15 GB bei 16k. Ein 4.9 GB großes 8B-Modell benötigt daher bei 8k ungefähr 7 GB VRAM und bei 16k ungefähr 8 GB. Ein 27B-Modell mit 4 Bit ist ungefähr 17 GB groß (Gemma 3 27B in Ollamas Bibliothek). Die Metadaten von Gemma 3 nennen ein Sliding Window mit 1,024 Tokens. Dadurch wächst ein großer Teil des Caches nicht weiter. Planen Sie daher 20 GB oder mehr ein. Ein 70B-Modell mit 4 Bit benötigt etwa 43 GB (Llama 3.3 70B). Bei 80 Schichten kommen für den FP16-Cache bei 8k etwa 2.7 GB und bei 16k etwa 5.4 GB hinzu. Dafür benötigen Sie eine 48-GB-Karte mit wenig Reserve oder zwei kleinere Karten. Dieselbe Berechnung funktioniert auch bei deutlich größeren Modellen. Die VRAM-Berechnung für ein Modell wie Kimi K3 mit 2.8 Billionen Parametern zeigt, ab wann die Auswahl einer Karte überhaupt nicht mehr die entscheidende Frage ist.

Bei langen Kontexten ist das besonders wichtig. Bei Modellen mit vollständiger Attention wie Llama 3.1 wächst der KV-Cache linear mit der Kontextlänge. Bei 128k Tokens kann er größer als die Gewichte selbst werden. Modelle mit Sliding-Window- oder Chunked-Attention verhalten sich anders: Die Transformers-Dokumentation von Hugging Face nennt Mistral, Gemma 2 und Llama 4 als Beispiele, bei denen der Cache dieser Schichten nicht weiter wächst, sobald er die Fenster- oder Chunk-Größe erreicht. Dadurch wachsen die Gesamtwerte langsamer. Wenn Sie lange Kontexte verwenden möchten, dimensionieren Sie zuerst den Cache und prüfen Sie, welche Möglichkeiten Ihre Engine für die Cache-Quantisierung bietet. In Ollama benötigt OLLAMA_KV_CACHE_TYPE=q8_0 ungefähr halb so viel Speicher wie das standardmäßige f16. Die Cache-Quantisierung funktioniert jedoch nur, wenn Flash Attention aktiviert ist. Legen Sie außerdem die Kontextlänge ausdrücklich fest. Ollama wählt den Standardwert anhand des VRAM: 4k unter 24 GiB, 32k von 24 bis 48 GiB und 256k ab 48 GiB. Auf einer 48-GB-Karte mit einem 70B-Modell fordert dieser Standardwert deutlich mehr Cache an, als auf die Karte passt.

Prüfen, was auf der Maschine tatsächlich vorhanden ist

Prüfen Sie bei einer GPU-Instanz zuerst, ob der Treiber die Karte erkennt.

nvidia-smi

Die Ausgabe sollte eine Tabelle mit dem Namen der GPU, der Treiberversion und dem verwendeten Speicher im Verhältnis zum Gesamtspeicher enthalten. NVIDIA-SMI has failed because it couldn't communicate with the NVIDIA driver bedeutet, dass NVIDIA-SMI den Treiber nicht erreichen kann. Prüfen Sie, ob der Treiber installiert und sein Kernelmodul geladen ist. Bei einem unveränderten Ubuntu-Image lautet die Lösung normalerweise sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install. Starten Sie anschließend das System neu, damit das neue Modul geladen wird. Für Compute-Maschinen empfiehlt die Ubuntu-Server-Dokumentation sudo ubuntu-drivers install --gpgpu. Damit wird der Server-Treiberzweig ausgewählt.

Für Container reicht der Treiber allein nicht aus. Docker benötigt das NVIDIA Container Toolkit, um das Gerät an den Container weiterzugeben.

sudo apt-get update && sudo apt-get install -y --no-install-recommends ca-certificates curl gnupg2
curl -fsSL https://nvidia.github.io/libnvidia-container/gpgkey | sudo gpg --dearmor -o /usr/share/keyrings/nvidia-container-toolkit-keyring.gpg
curl -s -L https://nvidia.github.io/libnvidia-container/stable/deb/nvidia-container-toolkit.list | sed 's#deb https://#deb [signed-by=/usr/share/keyrings/nvidia-container-toolkit-keyring.gpg] https://#g' | sudo tee /etc/apt/sources.list.d/nvidia-container-toolkit.list
sudo apt-get update && sudo apt-get install -y nvidia-container-toolkit
sudo nvidia-ctk runtime configure --runtime=docker
sudo systemctl restart docker

Beweisen Sie anschließend, dass die Weitergabe innerhalb eines Containers funktioniert:

sudo docker run --rm --gpus all ubuntu:24.04 nvidia-smi

Dieselbe Tabelle sollte angezeigt werden. Eine Zeile mit docker: Error response from daemon: could not select device driver, in der eine GPU-Fähigkeit genannt wird, die nicht erfüllt werden kann, bedeutet, dass Docker keinen passenden Gerätetreiber für die Anforderung gefunden hat. Prüfen Sie, ob das Toolkit installiert ist. Führen Sie anschließend die Zeile nvidia-ctk und den Neustart erneut aus. In Compose entspricht dies einem Eintrag deploy.resources.reservations.devices, dessen driver den Wert nvidia hat und dessen Capabilities-Liste gpu enthält. Dieser Eintrag lässt sich in die üblichen Service-Definitionen aus Docker Compose auf einem VPS integrieren.

Vor dem Upgrade messen

Führen Sie das Modell, das Sie tatsächlich verwenden möchten, auf dem vorhandenen CPU-Server aus und protokollieren Sie die Werte. Beim Self-Hosting eines LLM mit Ollama auf einem VPS ist dafür nur ein Flag erforderlich:

ollama run llama3.1:8b --verbose "Summarise the causes of the 1929 crash in 200 words."

Die Ausgabe endet mit Zeitmessungen. eval rate ist Ihre Generierungsgeschwindigkeit in Tokens pro Sekunde. prompt eval rate gibt an, wie schnell der Rechner Ihre Eingabe gelesen hat. Diese beiden Werte zeigen, welches Upgrade hilft: Ein niedriger Wert bei eval rate weist auf ein Problem mit der Speicherbandbreite hin. Ein niedriger Wert bei prompt eval rate bei langen Eingaben weist auf ein Rechenproblem hin.

Prüfen Sie auf einem Rechner mit GPU, ob das Modell tatsächlich auf der GPU geladen wurde:

ollama ps

In der Spalte PROCESSOR steht 100% GPU, wenn das Modell vollständig auf die GPU passt, oder ein Wert wie 43%/57% CPU/GPU, wenn dies nicht der Fall ist. Eine teilweise Aufteilung ist meist schlechter als erwartet, weil jedes Token weiterhin auf die langsamere Hälfte warten muss.

Die Kostenfrage

GPU-Instanzen werden nach bereitgestellter Rechenzeit und nicht nach Tokens abgerechnet. Die Tarife und Kosten für gestoppte Instanzen legt der Anbieter fest. Eine dauerhaft laufende GPU, die täglich nur wenige Anfragen verarbeitet, verbringt den größten Teil der bezahlten Zeit im Leerlauf. Der entscheidende Faktor ist die Auslastung: Eine ausgelastete GPU ist pro Token günstig, eine ungenutzte GPU verursacht reine Verschwendung.

Drei sinnvolle Modelle haben sich bewährt. Verarbeiten Sie dauerhaft anfallende Aufgaben mit geringem Volumen auf einem CPU-VPS. Senden Sie gelegentlich schwierige Anfragen an eine gehostete API und bezahlen Sie pro Token. Mieten Sie für Batch-Jobs, Fine-Tuning oder einen umfangreichen Embedding-Lauf eine GPU stundenweise und löschen Sie die Instanz anschließend. Eine Kombination dieser Modelle ist üblich. Die im Abschnitt Kostenkontrolle für AI-Agenten auf einem dauerhaft laufenden VPS beschriebene Budgetdisziplin gilt auch hier. Der Unterschied besteht darin, dass ungenutzte Zeit statt der Tokenzahl die Kosten verursacht.

Was auch ohne GPU zuverlässig läuft

Embeddings mit geringem Durchsatz. Ein kleines Embedding-Modell verarbeitet auf wenigen CPU-Kernen mehrere hundert kurze Dokumente pro Minute. Ein Index, den Sie nur einmal erstellen, muss nicht schnell aufgebaut werden.

Whisper small und base für die Transkription. Faster-whisper transkribiert auf der CPU mit dem Modell small annähernd in Echtzeit. Das reicht für eine Pipeline, die über Nacht läuft.

Quantisierte Chat-Modelle bis etwa 27B für einen oder zwei Benutzer. Langsam, lesbar und nutzbar.

Alles, was Sie als Batch-Auftrag ausführen würden. Wenn niemand den Bildschirm beobachtet, ist die verstrichene Zeit eine Frage der Zeitplanung und keine zwingende Anforderung.

Eine GPU benötigen Sie tatsächlich für das Training oder Fine-Tuning über einen kleinen Adapter hinaus, die Bereitstellung für viele gleichzeitig aktive Benutzer, die Erzeugung von Bildern und Videos sowie die Sprachverarbeitung in Echtzeit, bei der die Latenz entscheidend ist.

FAQ

Wie viel VRAM benötige ich für ein 7B- oder 8B-Modell?

Etwa 7 GB für ein 4-Bit-quantisiertes 8B-Modell bei einem 8k-Kontext und etwa 8 GB bei 16k mit Ollamas standardmäßigem FP16-Cache. Die Gewichte belegen ungefähr 4.9 GB, der KV-Cache benötigt bei 8k etwa 1.07 GB und bei 16k etwa 2.15 GB. Für den verbleibenden Overhead sollten Sie ungefähr 1 GB einplanen. Eine 8-GB-Karte reicht bei 8k aus, ist bei 16k jedoch knapp bemessen. Eine 12-GB-Karte bietet komfortablen Spielraum für längere Kontexte. Wenn Sie den Cache auf q8_0 umstellen, halbiert sich sein Anteil ungefähr. Wenn Sie einen 128k-Kontext verwenden möchten, sollten Sie den Cache separat dimensionieren, da er größer als die Gewichte werden kann.

Kann ich Ollama ohne GPU ausführen?

Ja. Ollama wechselt automatisch auf die CPU und benötigt nur genügend RAM, um das Modell aufzunehmen. Bei einem 4-Bit-quantisierten 8B-Modell sind je nach Speichergeschwindigkeit ungefähr 5 bis 12 Tokens pro Sekunde zu erwarten. Das entspricht für einen Benutzer etwa dem Lesetempo. Lange Prompts sind auf der CPU das eigentliche Problem, weil das Lesen eines Kontexts mit 30,000 Tokens rechenintensiv ist und deutlich länger dauert als die Antwortgenerierung.

Warum ist meine GPU kaum schneller als die CPU?

Die häufigste Ursache ist, dass das Modell nicht vollständig in den VRAM passt. Dann laufen einige Layer auf der CPU, und jedes Token wartet auf die langsamere Hälfte. Führen Sie ollama ps aus und prüfen Sie, ob die Spalte PROCESSOR den Wert 100% GPU enthält. Wenn dort eine Aufteilung angezeigt wird, verwenden Sie eine kleinere Quantisierung oder ein kleineres Modell. Eine weitere häufige Ursache ist ein kurzer Benchmark, bei dem die Ladezeit des Modells die Messung dominiert.

Lohnt sich ein GPU-VPS für einen einzelnen Benutzer?

In der Regel nicht. Erwachsene lesen still auf Englisch durchschnittlich etwa 4.0 bis 4.3 Wörter pro Sekunde. Tokens pro Sekunde müssen zunächst in Wörter pro Sekunde umgerechnet werden, bevor Sie einen CPU-Server mit diesem Tempo vergleichen. Für einen einzelnen Benutzer können lange Prompts, Bildgenerierung und Fine-Tuning die Kosten rechtfertigen. Die stärkste Begründung ist der gleichzeitige Betrieb für viele Benutzer, weil Batching die Gewichtsdaten bei mehreren Anfragen gemeinsam nutzen kann.

Sollte ich eine GPU stundenweise mieten oder dauerhaft betreiben?

Mieten Sie sie stundenweise, wenn die Auslastung unregelmäßig ist, etwa für Fine-Tuning, einen umfangreichen Embedding-Lauf oder eine Batch-Transkription. Betreiben Sie sie nur dauerhaft, wenn die Karte ausgelastet bleibt, da bereitgestellte GPU-Rechenleistung nach Zeit und nicht nach erzeugten Tokens abgerechnet wird. Ein Assistent mit geringem Datenverkehr ist auf einem CPU-VPS oder über eine gehostete API mit Token-Abrechnung günstiger als auf einer ungenutzten GPU.