SSD Nodes Learn Hosting plans →
Anleitungen Matt ConnorVon Matt Connor · Aktualisiert 2026-08-13

VPS mit GPU: Wann Sie wirklich eine brauchen

Ein GPU-VPS erhöht Durchsatz und Modellgröße. Für quantisierte Chatmodelle, Embeddings und Whisper small reicht oft CPU. Starten Sie dort und messen Sie.

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 erzeugt werden und wie groß ein Modell überhaupt sein darf, damit es in den Arbeitsspeicher passt. Alles andere bleibt unverändert. Wenn Ihre Arbeitslast aus einem quantisierten Chatmodell mit 7B bis 27B 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. Beginnen Sie mit der CPU, messen Sie die Zahl, die Sie stört, und wechseln Sie dann zu einer leistungsfähigeren Konfiguration.

Der Grund ist die Speicherbandbreite. Wenn ein Sprachmodell ein Token erzeugt, liest es alle benötigten Gewichte aus dem Speicher. Ein auf 4 Bit quantisiertes 8B-Modell benötigt auf der Festplatte ungefähr 4.7 GB und im Arbeitsspeicher etwa genauso viel. Für die Erzeugung eines Tokens müssen daher ungefähr 4.7 GB übertragen 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. Der DDR5-Arbeitsspeicher eines modernen Servers verarbeitet mehrere Dutzend Gigabyte pro Sekunde. Der GPU-Speicher (VRAM, Video-RAM) verarbeitet mehrere Hundert bis über 1.000 Gigabyte pro Sekunde. Das Verhältnis entspricht dem Geschwindigkeitsgewinn. Es ist groß.

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

Batch-Durchsatz. Dieser Punkt wird häufig unterschätzt. Wenn eine GPU für einen Benutzer generiert, bleibt der größte Teil ihrer Rechenleistung ungenutzt, weil sie auf den Speicher wartet. Wenn Sie 20 Anfragen gleichzeitig verarbeiten, wird dasselbe Auslesen der Gewichte für alle 20 Anfragen verwendet. Der aggregierte Durchsatz in Tokens pro Sekunde steigt dadurch um ein Mehrfaches, während die Geschwindigkeit pro Benutzer kaum sinkt. Eine CPU arbeitet nicht auf diese Weise. Zwei gleichzeitige Benutzer teilen sich auf einem CPU-System die Leistung ungefähr zur Hälfte. Wenn Sie eine API für viele Clients bereitstellen, ist Batching das wichtigste Argument für eine GPU und nicht die reine Geschwindigkeit eines einzelnen Datenstroms.

Prompt-Verarbeitung. Das Einlesen eines langen Prompts ist rechengebunden und nicht speichergebunden. Hier sind GPUs mit dem größten Abstand schneller. Einen Kontext mit 30.000 Tokens verarbeitet eine CPU möglicherweise in einer Minute. Eine GPU benötigt dafür einige Sekunden. Bei Retrieval-Setups, die Dokumente in jede Anfrage einfügen, zeigt sich dieser Unterschied ständig.

Grobe Richtwerte und ihre Einordnung

Der folgende Block enthält typische veröffentlichte Werte für einen einzelnen Datenstrom bei einem 8B-Modell mit 4-Bit-Quantisierung, Stand Juli 2026. Sie dienen als Größenordnung, nicht als Zusage. Ihre Quantisierung, die Kontextlänge und die Inference Engine verändern diese Werte.

Chart8B model at 4-bit: typical single-stream generation speed (July 2026)
The data behind this chart
[
  {
    "label": "8 vCPU, DDR4",
    "mem_bandwidth_gbs": 40,
    "tokens_per_sec": 6
  },
  {
    "label": "16 vCPU, DDR5",
    "mem_bandwidth_gbs": 75,
    "tokens_per_sec": 11
  },
  {
    "label": "24GB GPU",
    "mem_bandwidth_gbs": 300,
    "tokens_per_sec": 50
  },
  {
    "label": "40GB data-centre GPU",
    "mem_bandwidth_gbs": 1555,
    "tokens_per_sec": 130
  }
]

Die Zeile für die 24-GB-GPU zeigt 50 Tokens pro Sekunde gegenüber 11 bei einem CPU-System mit DDR5. Das entspricht ungefähr dem Fünffachen und folgt eher dem Verhältnis der Speicherbandbreite als einem Unterschied bei der reinen Rechenleistung. Der tatsächliche Durchsatz liegt außerdem unter dem Ergebnis aus Speicherbandbreite geteilt durch Modellgröße, weil die Attention über einen wachsenden Kontext zusätzliche Arbeit verursacht, die bei dieser einfachen Division nicht berücksichtigt wird.

Zum Vergleich: Ein Mensch liest ungefähr 5 bis 10 Wörter pro Sekunde. Ab etwa 15 Tokens pro Sekunde fühlt sich die Ausgabe für einen einzelnen Leser bereits wie normales Tippen an. Deshalb sind viele Setups ohne GPU im Alltag problemlos ausreichend.

VRAM-Bedarf vor dem Kauf berechnen

Die Größe der Modelldatei ist die Untergrenze, nicht der tatsächliche Bedarf. Planen Sie die Gewichte, den KV-Cache (Key-Value-Cache, also den pro Token benötigten Speicher für die Attention) und etwa 1 GB zusätzlichen Overhead ein.

Als praktische Faustregel im Juli 2026 gilt: Nehmen Sie die Größe der Modelldatei in Gigabyte und addieren Sie 20 Prozent für einen normalen Kontext von 8k bis 16k. Ein 4,7-GB-Modell mit 8B Parametern benötigt etwa 6 GB VRAM. Ein 27B-Modell mit 4 Bit belegt etwa 16 GB und benötigt ungefähr 20 GB. Ein 70B-Modell mit 4 Bit belegt etwa 40 GB und benötigt eine Karte mit 48 GB oder zwei kleinere Karten. Dieselbe Rechnung funktioniert auch bei deutlich größeren Modellen. Die VRAM-Berechnung für ein Modell mit 2,8 Billionen Parametern wie Kimi K3 zeigt, ab wann die Auswahl einer Grafikkarte nicht mehr die entscheidende Frage ist.

Lange Kontexte durchbrechen diese Faustregel. Der KV-Cache wächst linear mit der Kontextlänge und kann bei 128k Token größer als die Gewichte selbst werden. Wenn Sie lange Kontexte verwenden möchten, dimensionieren Sie zuerst den Cache und prüfen Sie, welche Optionen zur Cache-Quantisierung Ihre Engine bietet.

Prüfen, welche Hardware tatsächlich vorhanden ist

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

nvidia-smi

Die Ausgabe sollte eine Tabelle mit dem GPU-Namen, 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 der Treiber fehlt oder das Kernelmodul nach einem Kernel-Upgrade nicht neu erstellt wurde. Bei einem unveränderten Ubuntu-Image lautet die übliche Lösung sudo apt install -y ubuntu-drivers-common && sudo ubuntu-drivers install. Starten Sie das System anschließend neu, damit das neue Modul geladen wird.

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

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

Prüfen Sie anschließend aus einem Container, ob das Durchreichen funktioniert:

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

Die gleiche Tabelle sollte angezeigt werden. Eine Zeile docker: Error response from daemon: could not select device driver, die eine GPU-Fähigkeit nennt, die nicht erfüllt werden kann, bedeutet, dass das Toolkit installiert ist, Docker aber nicht neu konfiguriert oder neu gestartet wurde. Führen Sie daher die Zeile nvidia-ctk und den Neustart erneut aus. In Compose entspricht dies einem Eintrag deploy.resources.reservations.devices, dessen driver auf nvidia gesetzt ist und dessen Liste der Fähigkeiten gpu enthält. Dieser Eintrag wird in die gewöhnlichen Servicedefinitionen aus Docker Compose auf einem VPS eingefügt.

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 kosten ein Mehrfaches einer vergleichbaren CPU-Instanz. Sie werden für jede Stunde abgerechnet, in der sie existieren, nicht für die von ihnen erzeugten Tokens. Eine ständig laufende GPU, die nur wenige Anfragen pro Tag verarbeitet, ist die teuerste Art, Inferenz zu betreiben. 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. Betreiben Sie kontinuierliche Aufgaben mit geringem Volumen auf einem CPU-VPS. Senden Sie gelegentliche anspruchsvolle Anfragen an eine gehostete API und bezahlen Sie pro Token. Mieten Sie für Batch-Jobs, Fine-Tuning oder eine umfangreiche Embedding-Ausführung eine GPU stundenweise und löschen Sie sie anschließend. Eine Kombination dieser Modelle ist üblich. Die im Abschnitt Kostenkontrolle für AI-Agenten auf einem ständig laufenden VPS beschriebene Budgetdisziplin gilt auch hier. Der Unterschied besteht darin, dass Leerlaufzeit statt der Token-Anzahl 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?

Für ein 4-Bit-quantisiertes 8B-Modell bei einem normalen Kontext von 8k bis 16k benötigen Sie etwa 6 GB. Die Gewichte belegen ungefähr 4.7 GB. Der restliche Speicher entfällt auf den KV-Cache und etwa 1 GB Overhead. Eine Karte mit 12 GB bietet ausreichend Reserve für längere Kontexte. Wenn Sie einen Kontext von 128k verwenden möchten, müssen Sie den Cache separat dimensionieren, weil er größer als die Gewichte werden kann.

Kann ich Ollama ohne GPU ausführen?

Ja. Ollama wechselt automatisch auf die CPU. Es wird nur genügend RAM benötigt, um das Modell zu laden. Bei einem 4-Bit-quantisierten 8B-Modell können Sie je nach Speichergeschwindigkeit ungefähr 5 bis 12 Tokens pro Sekunde erwarten. Für einen einzelnen Benutzer entspricht das annähernd der Lesegeschwindigkeit. Lange Prompts sind auf der CPU das eigentliche Problem. Das Lesen von 30,000 Kontext-Tokens ist rechenintensiv und dauert deutlich länger als die Generierung der Antwort.

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 den langsameren Teil. Führen Sie ollama ps aus und prüfen Sie, ob in der Spalte PROCESSOR der Wert 100% GPU steht. Wenn 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 den Messwert dominiert.

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

In der Regel nicht. Eine Person liest mit 5 bis 10 Wörtern pro Sekunde. Ein CPU-System erzeugt bei Modellen bis etwa 13B bereits schneller Tokens, als eine Person sie lesen kann. Lange Prompts, Bildgenerierung und Fine-Tuning können die Kosten für einen einzelnen Benutzer rechtfertigen. Die stärkste Begründung ist der gleichzeitige Betrieb für viele Benutzer. Durch Batching kann eine GPU zwanzig Anfragen zu annähernd den Kosten einer einzelnen Anfrage beantworten.

Sollte ich eine GPU stundenweise mieten oder dauerhaft betreiben?

Mieten Sie die GPU stundenweise, wenn die Auslastung stoßweise anfällt, etwa beim Fine-Tuning, bei einer umfangreichen Embedding-Erstellung oder bei einem Batch-Transkriptionsauftrag. Betreiben Sie sie nur dann dauerhaft, wenn die Karte kontinuierlich ausgelastet ist. Eine GPU-Instanz wird nach ihrer Laufzeit abgerechnet, nicht nach der Anzahl erzeugter Tokens. Ein Assistent mit geringem Datenverkehr ist auf einem CPU-VPS oder über eine gehostete, pro Token abgerechnete API günstiger als auf einer ungenutzten GPU.