How do I calculate the VRAM a self-hosted LLM needs?

Three terms. Model weights are parameters multiplied by bytes per parameter — a 70B model at FP16 is about 140GB, at INT8 about 70GB, at INT4 about 35GB. The KV cache is 2 (one key, one value) x layers x KV heads x head dimension x bytes per element, per token, and that whole figure is multiplied again by your context length and by the number of sequences in flight. Then subtract 10-20% for CUDA context, activations, fragmentation and the runtime itself. Weights are a fixed cost you pay once; the KV cache is the term that scales with traffic, and it is the one that decides your concurrency ceiling.

Why does grouped-query attention matter so much for concurrency?

Because the KV cache scales with the number of KV heads, not attention heads. A model with 64 attention heads but only 8 KV heads — standard grouped-query attention in current open-weight models — has an eight-times smaller KV cache than the equivalent multi-head model, which translates almost one-for-one into eight times the concurrent sequences on identical hardware. This is why a modern 70B model can serve more simultaneous users than an older 13B model in some configurations. If you are sizing hardware from a parameter count alone you will get the answer badly wrong; enter the KV head count from the model's config file.

When is self-hosting actually cheaper than paying per token?

Only at high, sustained utilisation. A rented GPU bills every hour whether or not a request arrives, so your effective cost per million tokens is the hourly rate divided by the tokens you actually generate in that hour. At full saturation the economics are often excellent; at 20% duty cycle your real cost per million tokens is five times the headline figure and almost always loses to an API. The break-even throughput shown by this calculator is the number of tokens per second you must sustain, on average and not at peak, for self-hosting to beat the API rate you entered. If your traffic is bursty, compare against that average rather than your peak.

LLM VRAM- und Parallelitätsrechner | KV-Cache-Größe auf $/1 Mio. Tokens

LLM VRAM- und Parallelitätsrechner

✓ Zuletzt überprüft: 23.07.2026· Quelle: veröffentlichte Modellkonfigurationen + öffentliche GPU-Mietpreise· Änderung melden →

Jede Selbsthosting-Entscheidung beginnt mit der gleichen Frage, und fast niemand beantwortet sie richtig: Wie viele Personen kann diese GPU tatsächlich gleichzeitig bedienen und was kostet eine Million Token wirklich, wenn die Hardware stundenweise abgerechnet wird, unabhängig davon, ob Sie sie verwenden oder nicht.

Gewichte sind der einfache Teil. Die Anpassung des Modells ist eine einzeilige Berechnung und sagt fast nichts aus. Was darüber entscheidet, ob Sie acht oder achtzig Benutzer bedienen können, ist der KV-Cache – Speicher, der mit der Kontextlänge skaliert Und mit jeder gleichzeitigen Sequenz im Flug. Dieses Tool misst beides und wandelt dann die resultierende Kapazität in Kosten pro Million Token um, die Sie gegen eine API-Rechnung halten können.

Das Modell anzupassen ist nicht dasselbe wie ihm zu dienen

Der überall zu findende Hinweis lautet, dass ein 70B-Modell bei INT4 etwa 35 GB benötigt, sodass es auf eine einzelne 80-GB-Karte passt und noch Platz übrig bleibt. Das ist wahr und fast nutzlos, weil es ein untätiges Modell beschreibt. Sobald Anfragen eintreffen, weist jede Sequenz im Flug ihren eigenen KV-Cache zu: zwei Tensoren pro Schicht, deren Größe sich aus KV-Köpfen mal Kopfdimension ergibt und für jeden Token im Kontext dieser Sequenz gehalten werden. Bei 80 Schichten, 8 KV-Köpfen, 128 Dimensionen und FP16 sind das 327.680 Bytes pro Token – ein Drittel eines Megabytes – was bei einem 8K-Kontext etwa 2,7 GB entspricht pro gleichzeitiger Anfrage. Die 45 GB Speicherkapazität, die so komfortabel aussahen, reichen für etwa ein Dutzend Benutzer, und der dreizehnte landet in der Warteschlange. Die Kapazitätsplanung für die Inferenz ist die KV-Cache-Planung. Die Gewichte legen lediglich das Startgeld fest.

Die KV-Kopfzahl ist die Zahl, die sich tatsächlich bewegt

Die Aufmerksamkeit bei gruppierten Abfragen ist der Grund dafür, dass moderne Modelle mit offener Gewichtung überhaupt bedient werden können, und sie wird routinemäßig von jedem übersehen, der die Hardware anhand einer Parameteranzahl dimensioniert. Ein Modell mit 64 Aufmerksamkeitsköpfen und 8 KV-Köpfen speichert ein Achtel des Caches eines äquivalenten Mehrkopfdesigns, was sich fast linear in die achtfache Parallelität auf derselben Karte umwandelt. Probieren Sie die 13B-Mehrkopfvoreinstellung oben mit der 70B-Voreinstellung aus: Das kleinere Modell ist oft dasjenige, dem zuerst der Speicher ausgeht, was nicht intuitiv ist, bis Sie sehen, wohin die Bytes gehen. Durch die Halbierung der KV-Präzision auf FP8 wird die Parallelität bei moderaten Genauigkeitskosten erneut verdoppelt. Diese beiden Switches verschieben die Kapazität weitaus stärker als der Kauf einer größeren Karte, und sie kosten nichts.

Die Nutzung entscheidet über die Wirtschaftlichkeit, nicht die Hardware

Der Abschlusstisch ist derjenige, der die meisten Selbsthosting-Projekte ehrlich beendet. Ein gemieteter H100 kostet um 3 Uhr morgens ohne Verkehr die gleichen 2,50 US-Dollar pro Stunde wie zu Spitzenzeiten. Ihre tatsächlichen Kosten pro Million Token sind also die Gesamtzahl dividiert durch Ihren durchschnittlichen Arbeitszyklus. Bei einer Auslastung von 20 % zahlen Sie das Fünffache dessen, was der optimistische Wert des Rechners vermuten lässt – und im Vergleich zu Standard-API-Raten für ein kleines Modell ist das nicht annähernd so hoch. Selbsthosting gewinnt bei anhaltendem, gesättigtem und vorhersehbarem Volumen, bei Workloads mit Datenresidenz- oder Latenzbeschränkungen, die eine API nicht erfüllen kann, und bei Modellen, bei denen niemand pro Token verkauft. Es verliert bei starkem Datenverkehr, und zwar leise, weil die Rechnung pauschal ist und die verschwendete Kapazität nie als Einzelposten erscheint. Überprüfen Sie die Schlussfolgerung mit dem Selbstgehosteter LLM vs. API-Rechner, Preis der Hardware selbst mit dem GPU-Inferenzkostenrechner, und wenn die Antwort marginal ist, schauen Sie sich a an destilliertes kleineres Modell oder sofortiges Caching bevor Sie ein Rack kaufen.

So funktioniert dieser Rechner

Gewichte sind Parameter × Bytes pro Parameter. Der KV-Cache pro Token beträgt 2 × Schichten × KV-Köpfe × Kopfdimension × KV-Bytes; multipliziert mit der Kontextlänge, die den Speicher ergibt, den jede gleichzeitige Sequenz enthält. Der nutzbare Speicher ist der gesamte VRAM auf Ihren GPUs abzüglich eines Prozentsatzes des Laufzeit-Overheads und das, was nach der Division der Gewichtungen durch die Zahl pro Sequenz übrig bleibt, um die Obergrenze für die Parallelität zu ermitteln. Die Kosten pro Million Token sind die stündliche GPU-Rechnung geteilt durch die Token, die Sie tatsächlich in einer Stunde generieren, weshalb die Auslastungstabelle genauso wichtig ist wie die Speichertabelle.

Häufig gestellte Fragen

Wie berechne ich den VRAM, den ein selbstgehostetes LLM benötigt?

Drei Begriffe: Modellgewichte (Parameter × Bytes pro Parameter), der KV-Cache (2 × Schichten × KV-Köpfe × Kopfdimension × Bytes, pro Token, mal Kontextlänge, mal gleichzeitige Sequenzen) und 10–20 % Overhead für CUDA-Kontext, Aktivierungen und Fragmentierung. Gewichte sind eine feste Startgebühr; Der KV-Cache ist der Begriff, der mit dem Datenverkehr skaliert und Ihre Parallelitätsobergrenze festlegt.

Warum ist die Aufmerksamkeit bei gruppierten Abfragen so wichtig für die Parallelität?

Weil der KV-Cache mit KV-Köpfen skaliert, nicht mit Aufmerksamkeitsköpfen. Ein Modell mit 64 Aufmerksamkeitsköpfen, aber 8 KV-Köpfen hat einen achtmal kleineren Cache als das Multi-Kopf-Äquivalent, das fast eins zu eins in achtmal mehr gleichzeitige Sequenzen auf derselben Karte umwandelt. Größe aus der Konfigurationsdatei des Modells, nicht aus seiner Parameteranzahl.

Wann ist Selbsthosting tatsächlich günstiger als die Bezahlung pro Token?

Nur bei hoher, anhaltender Auslastung. Eine gemietete GPU rechnet jede Stunde ab, unabhängig davon, ob eine Anfrage eintrifft oder nicht. Bei einem Arbeitszyklus von 20 % sind Ihre tatsächlichen Kosten pro Million Token also fünfmal so hoch wie der Gesamtwert. Der oben genannte Break-Even-Durchsatz ist der Token pro Sekunde, den Sie im Durchschnitt – nicht in Spitzenzeiten – aufrechterhalten müssen, damit Self-Hosting die von Ihnen eingegebene API-Rate übertrifft.