Lokale LLMs auf 48 GB VRAM: Welche Modelle wirklich schnell laufen

Ein praktischer llama.cpp-Benchmark auf zwei GPUs — mit reproduzierbarer Methodik, Messwerten und einer vorsichtigen Einordnung für lokale KI-Agenten.

Wie schnell laufen aktuelle lokale LLMs auf einem System mit 48 GB VRAM — und wie stark verändert sich das Ergebnis, wenn nur eine einzelne 32-GB-GPU zur Verfügung steht?

Für diesen Test habe ich drei Modelle mit llama.cpp vermessen: ein dichtes 27B-Modell, ein dichtes 30B-Modell und ein MoE-Modell mit nominell 35B Parametern. Ein viertes Modell, NVIDIA Nemotron 3.5 Lightning 30B-A3B, war während des Tests noch im Download und ist deshalb nicht in die Messwerte eingeflossen.

Die zentrale Erkenntnis lautet: Die Architektur ist für den Durchsatz wichtiger als die nominelle Modellgröße. Das getestete MoE-Modell erreichte rund 130 Tokens/s auf zwei GPUs und noch etwa 94 Tokens/s auf einer einzelnen 32-GB-Karte. Bei dichten Modellen entscheiden dagegen Quantisierung und verfügbarer Speicher darüber, ob ein Modell überhaupt sinnvoll läuft.

Die wichtigsten Ergebnisse

• MoE liefert den höchsten Durchsatz: Qwen3.6-35B-A3B erreichte 129,5 Tokens/s auf zwei GPUs und etwa 94 Tokens/s auf einer 32-GB-Karte.
• Q4 ist auf 32 GB oft der praktikable Kompromiss: Das dichte 27B-Modell lief in Q4 mit etwa 46–48 Tokens/s, in Q8 dagegen nur mit rund 4,3 Tokens/s.
• Warmup ist für faire Messungen notwendig: Kaltstartwerte lagen beim getesteten Muse-Glimmer deutlich unter den Steady-State-Werten.
• Für Agenten zählt nicht nur Geschwindigkeit: Kontextlänge, Tool-Nutzung, Stabilität und Modellqualität können wichtiger sein als maximale Tokens/s.
• Die Wirtschaftlichkeit hängt stark von der Auslastung ab: Stromkosten sind relativ gut berechenbar; Hardware-Abschreibung, Wiederverkaufswert und Vergleichsmodell bleiben unsicherer.

Testsystem und Szenarien

Getestet wurde auf meinem Rechner „Cachy“:

• GPU 0: NVIDIA RTX PRO 4500 Blackwell — 32 GB VRAM
• GPU 1: NVIDIA GeForce RTX 5070 Ti — 16 GB VRAM
• Gesamt: etwa 48 GB VRAM
• CPU: AMD Ryzen 7 8700G
• Arbeitsspeicher: 30 GB RAM
• Engine: llama.cpp mit llama-server
• CUDA: 13.3
• Treiber: 610.43

Ich habe zwei Szenarien verglichen:

• Szenario A: Beide GPUs werden mit --split-mode layer verwendet.
• Szenario B: Nur die 32-GB-GPU wird mit --split-mode none verwendet.

Damit lässt sich sowohl ein ungewöhnliches Dual-GPU-Setup als auch ein praxisnahes Einzelkarten-Setup betrachten. Die Ergebnisse sind allerdings nicht als allgemeingültige Leistungswerte für jede Hardware zu verstehen. Treiberversion, llama.cpp-Build, Speicheraufteilung, Kontextgröße und Serverkonfiguration können das Resultat verändern.

Was kostet die Hardware?

Die folgende Tabelle zeigt eine grobe Momentaufnahme der angesetzten Händlerpreise im Jahr 2026. Es handelt sich nicht um eine langfristig stabile Preisempfehlung; insbesondere GPU-Preise können sich kurzfristig verändern.

Die beiden GPUs bilden dabei den mit Abstand größten Kostenblock. Wer ausschließlich das getestete MoE-Modell betreiben möchte, benötigt nicht zwingend beide Karten: Im Einzelkarten-Szenario erreichte es bereits etwa 94 Tokens/s.

Wiederverkaufswert und Anschaffungskosten

Die vollständigen Anschaffungskosten sind nicht automatisch identisch mit den langfristigen Nutzungskosten. Für eine Wirtschaftlichkeitsrechnung muss man zwischen drei Größen unterscheiden:

1. Anschaffungskosten: Was beim Kauf tatsächlich bezahlt wurde.
2. Restwert: Welcher Betrag beim späteren Verkauf realistisch erzielt werden kann.
3. Betriebskosten: Vor allem Strom, gegebenenfalls Kühlung und weitere laufende Kosten.

In meinem Fall wurden die GPUs günstiger gekauft als die in der obigen Momentaufnahme angesetzten aktuellen Werte:

Das ist eine Momentaufnahme und kein sicherer Gewinn. Ein höherer aktueller Angebotspreis bedeutet nicht automatisch, dass sich beim Verkauf derselbe Betrag erzielen lässt. Verkaufsgebühren, Garantie, Zustand, Nachfrage und Preisentwicklung müssen berücksichtigt werden.

Für eine konservative Rechnung würde ich deshalb nicht einfach den aktuellen Listen- oder Händlerpreis als sicheren Restwert ansetzen. Sinnvoller sind mindestens zwei Varianten:

• Vorsichtige Rechnung: Die Hardware wird vollständig als Kosten betrachtet.
• Restwert-Szenario: Nur die angenommene Wertminderung wird amortisiert; der spätere Verkaufserlös bleibt aber eine Schätzung.

Stromkosten und Break-even

Der Vergleich mit Cloud-Modellen ist nur unter klaren Annahmen sinnvoll. Ein lokales System verursacht Kosten unabhängig davon, ob es gerade genutzt wird. Bei einer API wird dagegen pro Input- und Output-Token abgerechnet; ein Abo hat wiederum Nutzungsgrenzen und lässt sich nicht ohne Weiteres in einen Tokenpreis umrechnen.

Deshalb vergleiche ich hier ausschließlich:

• den lokalen Betrieb mit Stromkosten und angenommener Hardware-Amortisation,
• mit API-Preisen pro 1 Million Token.

Das ist kein direkter Vergleich mit einem Abo. Ein Abo kann bei geringer oder moderater Nutzung günstiger sein, während eine stark ausgelastete API oder ein teures Modell deutlich höhere laufende Kosten verursachen kann.

Lokale Stromkosten

Bei einer angenommenen Systemlast von etwa 450 W und einem Durchsatz von rund 94 Tokens/s ergibt sich bei einem Strompreis von 0,35 €/kWh ungefähr folgende Größenordnung:

• 450 W entsprechen 0,45 kWh pro Betriebsstunde.
• Bei 0,35 €/kWh kostet eine Betriebsstunde etwa 0,16 €.
• Bei 94 Tokens/s werden in einer Stunde etwa 338.400 Tokens erzeugt.
• Daraus ergeben sich grob 0,47 € pro 1 Million Tokens beziehungsweise — abhängig vom Wechselkurs — ungefähr 0,5–0,6 $ pro 1 Million Tokens.

Das ist eine Näherung. Sie berücksichtigt weder Leerlaufverbrauch noch zusätzliche Kühlung, Netzteilverluste, Hardware-Abschreibung oder die Tatsache, dass reale Agenten-Workloads nicht ausschließlich aus kontinuierlicher Ausgabe bestehen. Bei langen Pausen oder niedriger Auslastung steigen die effektiven Kosten pro tatsächlich genutztem Token deutlich.

API-Referenzpreise

Als grobe Vergleichswerte wurden folgende OpenRouter-Preise angesetzt. Die Angaben sind eine Momentaufnahme und sollten vor einer konkreten Kaufentscheidung erneut geprüft werden.

Die Spalte „Gemischt 75/25“ verwendet ein Verhältnis von 75 % Input- und 25 % Output-Tokens. Das ist eine Modellannahme für einen Agenten-Chat, kein universeller Durchschnitt. Tool-Use, wiederholte Kontextübertragung und lange Prompts können den tatsächlichen Input-Anteil deutlich erhöhen.

Grobe Amortisationsszenarien

Unter den oben genannten Annahmen ergibt sich für eine Hardware-Amortisation über zwölf Monate ungefähr folgende Größenordnung. Die Zahlen sind keine Prognose, sondern zeigen, wie stark das Ergebnis von der täglichen Auslastung abhängt.

Szenario 1 — vollständige Anschaffungskosten: angesetzte Hardwarekosten von etwa 4.134 € für die betrachtete Konfiguration.

Szenario 2 — angenommene Abschreibung nach Wiederverkauf: etwa 1.894 € an zu amortisierenden GPU-Kosten.

• Claude Sonnet 5: ca. 1,8 Mio Tokens/Tag beziehungsweise etwa 5,3 h Generierung.
• Claude Opus 5: ca. 0,7 Mio Tokens/Tag beziehungsweise etwa 2,0 h Generierung.

\*Die Zeitangaben basieren auf rund 94 Tokens/s und beziehen sich auf kontinuierliche Generierung. Sie bilden keinen typischen Arbeitstag mit Wartezeiten, Eingaben, Tool-Aufrufen und Leerlauf ab.

Die Aussage daraus ist nicht, dass sich ein lokales System ab einer bestimmten Tokenzahl garantiert „rechnet“. Sie lautet vorsichtiger: Bei hoher und regelmäßiger Auslastung kann lokale Hardware gegenüber teuren API-Modellen wirtschaftlich interessant werden. Bei geringer Nutzung oder günstigen APIs spricht die reine Kostenrechnung dagegen eher für die Cloud.

Ein extremes Beispiel ist ein sehr günstiges API-Modell wie DeepSeek V4 Flash mit den im Testzeitpunkt angesetzten Preisen von 0,08 $/1M Input- und 0,18 $/1M Output-Tokens. Bei einem gemischten Preis von ungefähr 0,10 $/1M liegt es unter den geschätzten lokalen Stromkosten. Gegen solche Preise lässt sich eigene Hardware aus reiner Tokenkostenperspektive kaum amortisieren.

Dabei bleiben wichtige Faktoren außerhalb der Rechnung: Datenschutz, Offline-Fähigkeit, konstante Verfügbarkeit, Antwortlatenz, Modellqualität, API-Limits und der Wiederverkaufswert der Hardware. Für viele lokale Nutzer sind diese Punkte mindestens so wichtig wie die Kosten pro Token.

Getestete Modelle

Benchmark-Ergebnisse

Alle Werte stammen aus Streaming über /v1/completions. Vor den eigentlichen Messungen wurde jeweils ein Warmup-Request ausgeführt.

Szenario A: zwei GPUs, etwa 48 GB

Szenario B: eine RTX 4500, 32 GB

Messbedingungen: Durchschnitt aus drei Läufen mit jeweils 800 Tokens nach einem Warmup-Request. Angegeben ist tps_total über den gesamten Lauf. Verwendet wurden vier parallele Slots und aktiviertes KV-Unified.

Reproduzierbare Konfiguration

Szenario A: zwei GPUs mit MTP-Draft

llama-server \
  --model Qwen3.6-27B-Fable-Fus-711-UnHeretic-NM-DAU-NEO-MAX-NEO-MTP-Q8_0.gguf \
  --host 0.0.0.0 --port 8080 \
  --temp 1.0 --top-p 0.8 --top-k 20 --presence-penalty 1.5 --min-p 0.00 \
  --ctx-size 131072 --split-mode layer --main-gpu 0 \
  --spec-type draft-mtp --spec-draft-n-max 2 \
  --gpu-layers 99 --fit on

Szenario B: eine 32-GB-GPU mit Q4

llama-server \
  --model Qwen3.6-27B-Fable-Fus-711-UnHeretic-NM-DAU-NEO-MAX-NEO-MTP-Q4_K_M.gguf \
  --host 0.0.0.0 --port 8080 \
  --temp 1.0 --top-p 0.8 --top-k 20 --presence-penalty 1.5 --min-p 0.00 \
  --ctx-size 131072 --split-mode none --main-gpu 0 \
  --gpu-layers 99 --fit on

Die wichtigsten Flags:

• --split-mode layer verteilt Layer über mehrere GPUs; none verwendet nur eine Karte.
• --fit on passt Parameter wie den Kontext an den verfügbaren VRAM an.
• --gpu-layers 99 versucht, die Gewichte vollständig auf der GPU zu platzieren.
• --spec-type draft-mtp --spec-draft-n-max 2 aktiviert die verwendete MTP-Spekulation.
• --ctx-size 131072 entspricht nominell 128k Kontext pro Slot.

Was die Ergebnisse erklären

MoE gegen dichte Modelle

Ein MoE-Modell besitzt nominell viele Parameter, aktiviert aber pro Token nur einen Teil davon. Beim getesteten Qwen3.6-35B-A3B sind es ungefähr 3B aktive Parameter. Dadurch muss pro Token weniger Rechenarbeit ausgeführt werden, während das Modell trotzdem eine größere Gesamtkapazität besitzen kann.

Das erklärt den hohen Durchsatz von etwa 130 Tokens/s auf zwei GPUs und 94 Tokens/s auf einer GPU. Die Zahlen gelten allerdings für genau diese Modell-, Quantisierungs- und Serverkonfiguration. Sie sind kein allgemeiner Beweis dafür, dass jedes MoE-Modell schneller als jedes dichte Modell ist.

Q4 gegen Q8

Beim dichten 27B-Modell ist der Unterschied auf der 32-GB-Karte besonders deutlich. In Q8 beanspruchen die Gewichte bereits einen großen Teil des Speichers. Für KV-Cache und Laufzeitpuffer bleibt dadurch wenig Reserve; in diesem Lauf fiel der Durchsatz auf etwa 4,3 Tokens/s.

Die Q4-Version benötigte weniger VRAM und erreichte etwa 46–48 Tokens/s. Der Unterschied von mehr als dem Zehnfachen ist deshalb vor allem ein Speicher- und Auslagerungseffekt, nicht nur ein Qualitätsunterschied zwischen den Quantisierungen.

Bei zu großen Modellen oder Kontexten kam es außerdem zu cudaMalloc: out of memory. Die Tabellen enthalten nur erfolgreiche Läufe. Fehlgeschlagene Konfigurationen wurden nicht als Messwerte interpretiert.

MTP und Warmup

Beim dichten Qwen3.6-27B-Fable-Fus-711 stieg der Durchsatz durch die verwendete MTP-Konfiguration von 25,6 auf 41,6 Tokens/s — ein Zuwachs von rund 62 % in diesem Vergleich. Das Ergebnis ist abhängig von Modell, Draft-Konfiguration und Hardware und sollte daher nicht als garantierter Faktor verstanden werden.

Auch der erste Request nach dem Laden ist kein fairer Vergleichswert. Beim Muse-Glimmer lagen Time-to-First-Token und Durchsatz im Kaltstart bei etwa 17 Sekunden beziehungsweise 12,8 Tokens/s. Nach dem Warmup wurden etwa 0,1 Sekunden und 29,5 Tokens/s gemessen.

Bedeutung für lokale Agenten

Für lokale Agenten wie Hermes ergibt sich aus diesem Test ein differenziertes Bild:

• Für hohen Durchsatz: Das getestete MoE-Modell ist die praktikabelste Wahl. Es läuft auch auf einer einzelnen 32-GB-Karte schnell.
• Für spezialisierte Agenten-Workloads: Muse-Glimmer ist langsamer, wurde aber ausdrücklich für agentische Anwendungsfälle entwickelt. Tool-Use und Coding-Qualität müssen separat bewertet werden; Tokens/s allein reichen dafür nicht aus.
• Für knappen VRAM: Bei dichten Modellen ist Q4 auf einer 32-GB-Karte deutlich realistischer als Q8.
• Für lange Kontexte: 128k oder 200k Kontext kann die praktische Nutzbarkeit erhöhen, kostet aber VRAM. Die tatsächlich nutzbare Länge hängt außerdem vom Workload und der Serverkonfiguration ab.
• Für belastbare Entscheidungen: Ein eigener Agenten-Test mit realen Tool-Aufrufen ist aussagekräftiger als ein synthetischer 800-Token-Lauf.

Fazit

Das getestete MoE-Modell war beim reinen Generierungsdurchsatz der klare Gewinner: etwa 129,5 Tokens/s auf zwei GPUs und rund 94 Tokens/s auf einer einzelnen 32-GB-Karte. Dichte Modelle können ebenfalls sinnvoll laufen, benötigen auf 32 GB aber eine passende Quantisierung und ausreichend Reserve für den KV-Cache.

Die wirtschaftliche Bewertung fällt weniger eindeutig aus. Bei hoher, regelmäßiger Auslastung kann lokale Hardware gegenüber teuren APIs interessant werden. Bei geringer Nutzung, günstigen API-Modellen oder einem Abo mit ausreichendem Kontingent ist die Cloud wahrscheinlich einfacher und oft günstiger. Der Wiederverkaufswert kann die effektive Hardware-Abschreibung reduzieren, sollte aber nicht als sicherer Gewinn in die Rechnung eingehen.

Für die Praxis würde ich deshalb so entscheiden:

• Maximale Geschwindigkeit: MoE-Modell.
• Eine einzelne 32-GB-GPU: MoE oder dichtes Modell in Q4.
• Agentische Qualität: Geschwindigkeit mit Tool-Use- und Coding-Tests kombinieren.
• Wirtschaftlichkeit: tatsächliche Auslastung, Strom, Restwert und API-Preise gemeinsam betrachten.

Als Nächstes teste ich NVIDIA Nemotron 3.5 Lightning im direkten Vergleich und führe einen vollständigen Agenten-Durchlauf auf einem der lokalen Modelle durch.