[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"reazon-page-\u002Fde\u002Fwissen\u002Fvram-modell-gpu-berechnen":3,"reazon-mainnav":30,"reazon-angebot-subnav":40,"reazon-articles-\u002Fde\u002Fwissen":41,"reazon-offering-angebot-zielgruppen":168,"reazon-offering-angebot-leistungen":169,"reazon-footernav":183},{"data":4},{"id":5,"path":6,"slug":7,"published_at":8,"page_type":9,"no_index":12,"fields":13,"blocks":29},1442,"\u002Fde\u002Fwissen\u002Fvram-modell-gpu-berechnen","vram-modell-gpu-berechnen","2026-07-07T12:07:03.771Z",{"identifier":10,"name":11},"article","Blog Post",false,{"title":14,"summary":15,"publication_date":16,"big5_category":17,"primary_service":18,"meta_title":25,"meta_description":26,"body":27,"body_html":28},"Welches Modell passt auf welche GPU? VRAM richtig berechnen","Bevor du GPUs kaufst oder mietest: die Faustformel für Gewichte, KV-Cache und Overhead, damit du weisst, welches Modell wirklich auf deine Hardware passt.","2026-07-07T00:00:00Z","how-to",{"id":19,"slug":20,"path":21,"page_type":22,"published":23,"type":24},675,"bare-metal","\u002Fde\u002Fbare-metal","service",true,"Cms::Page","VRAM richtig berechnen: Modell und GPU passend wählen | Twentyone","So berechnest du den echten VRAM-Bedarf eines LLM: Gewichte, KV-Cache und Overhead. Mit Rechenbeispielen für 7B bis 70B auf 24 bis 128 GB GPUs.","## \"70B läuft doch auf 24 GB\"\n\nIn einem Workshop letzten Monat sagte ein CTO einen Satz, den wir inzwischen fast jede Woche hören: \"Wir haben gelesen, ein 70B-Modell läuft problemlos auf einer 24-GB-Karte, dann kaufen wir halt zwei davon.\" Der Satz stammte aus einem Forumspost, nicht aus einer eigenen Rechnung, und genau das ist das Problem. **Die Aussage stimmt sogar, aber nur unter Bedingungen, die im Forumspost nicht mehr auftauchen**: aggressive 4-Bit-Quantisierung, ein Kontext von vielleicht 2000 Token, ein einziger Nutzer, kein Puffer für irgendetwas anderes. Sobald einer dieser Punkte wegfällt, bricht die Rechnung zusammen, und die GPU meldet \"out of memory\", meist mitten in der Produktivdemo.\n\nWir sehen diesen Fehler so oft, dass wir ihn zum Anlass für diesen Artikel gemacht haben. **Bevor du Hardware kaufst oder mietest, rechnest du den VRAM-Bedarf selbst aus**, nicht anhand eines Blogposts, sondern anhand deines Modells, deiner Kontextlänge und deiner Nutzerzahl. Die Rechnung ist keine Raketenwissenschaft, sie dauert fünf Minuten mit Taschenrechner. Aber sie wird fast nie gemacht, bevor die Bestellung raus ist.\n\n## Die Faustformel für die Modellgewichte\n\nDer erste und grösste Posten sind die reinen Modellgewichte, und dafür gibt es eine simple Faustregel: **Pro Milliarde Parameter brauchst du in fp16 rund 2 GB, in int8 rund 1 GB und in int4 rund 0,5 GB.** Der Grund ist banal: fp16 speichert jeden Parameter mit 16 Bit, also 2 Byte, int8 mit einem Byte, int4 mit einem halben Byte. Ein 8B-Modell wiegt also in fp16 rund 16 GB, in int8 rund 8 GB, in int4 rund 4 GB. Multiplizierst du die Parameterzahl mit dem Bytes-pro-Parameter-Faktor, hast du die Basiszahl, auf der alles Weitere aufbaut.\n\nWichtig dabei: **Quantisierung ist kein Freibrief ohne Kosten.** int4 halbiert den Speicherbedarf gegenüber int8 nochmal, aber die Modellqualität leidet, besonders bei Reasoning-lastigen Aufgaben und bei sehr grossen Modellen, deren Gewichte ohnehin schon \"eng gepackt\" sind. Für viele produktive Anwendungsfälle ist int8 der vernünftige Mittelweg zwischen Speicherersparnis und Qualität, int4 lohnt sich vor allem dort, wo Kapazität die harte Grenze ist und du die Qualitätseinbusse getestet und akzeptiert hast, nicht als automatischer erster Griff.\n\n## Der Posten, den fast jeder vergisst: der KV-Cache\n\nHier liegt der Grund, warum so viele VRAM-Rechnungen in der Praxis scheitern, obwohl die Modellgewichte sauber berechnet waren. Der **KV-Cache** speichert für jedes bereits verarbeitete Token die sogenannten Key- und Value-Vektoren aus jeder Attention-Schicht, damit das Modell sie beim nächsten Token nicht neu berechnen muss. Das ist der Trick, der Inferenz überhaupt schnell macht, aber er hat einen Preis: **Der KV-Cache wächst linear mit Kontextlänge, Batchgrösse, Anzahl der Layer und Hidden-Size des Modells.** Er ist kein fixer Posten wie die Gewichte, er ist ein Posten, der mit jedem zusätzlichen Token und jedem zusätzlichen Nutzer weiterwächst, solange die Session offen bleibt.\n\nBei kurzen Prompts mit wenigen hundert Token fällt das kaum ins Gewicht, ein paar hundert MB, in der Rechnung fast vernachlässigbar. Bei **langen Kontexten ab 32k Token** sieht das anders aus. Grob gerechnet gilt: **KV-Cache-Grösse ≈ 2 (Key und Value) × Anzahl Layer × Hidden-Size × Bytes pro Wert × Anzahl Token**, multipliziert mit der Zahl paralleler Sequenzen. Bei einem grossen Modell mit vielen Layern und breiter Hidden-Size kann der KV-Cache pro Nutzer schon bei einem einzigen langen Kontext in den Bereich von mehreren GB rutschen, bei Modellen ohne speichersparende Attention-Varianten (Grouped-Query-Attention reduziert das deutlich) auch deutlich mehr. Und dann kommt der Faktor, der in den meisten Milchmädchenrechnungen komplett fehlt: **Concurrency.** Bedienst du nicht einen, sondern zehn gleichzeitige Nutzer mit langen Kontexten, multipliziert sich der KV-Cache-Bedarf entsprechend, und aus ein paar GB werden schnell zweistellige GB, die zusätzlich zu den Modellgewichten im Speicher liegen müssen. Genau das ist die Lücke, in der reale Deployments an die Wand fahren, obwohl \"das Modell doch gepasst hat\".\n\nZwei Stellschrauben helfen dagegen, wenn der KV-Cache zum Flaschenhals wird, und beide solltest du kennen, bevor du automatisch zu mehr Hardware greifst. **Grouped-Query-Attention (GQA)**, in praktisch allen aktuellen offenen Modellen wie Llama 3 oder Mistral verbaut, reduziert die Zahl der gespeicherten Key-Value-Köpfe drastisch gegenüber klassischer Multi-Head-Attention, oft um den Faktor 4 bis 8. Und **Quantisierung des KV-Cache selbst**, also int8 statt fp16 für die gespeicherten Key-Value-Vektoren, halbiert den Bedarf nochmal, unabhängig davon, in welcher Präzision die Modellgewichte laufen. Beide Hebel kosten etwas Qualität am Rand, aber deutlich weniger als an den Gewichten selbst zu sparen, weshalb sie in der Praxis oft der bessere erste Griff sind, bevor du eine grössere Karte bestellst.\n\n## Overhead: die letzten 1-2 GB, die trotzdem entscheiden\n\nNach Gewichten und KV-Cache bleibt noch ein dritter Posten, kleiner, aber real: **Aktivierungen während der Forward-Pass-Berechnung, der CUDA-Kontext selbst und der Speicherbedarf des Inferenz-Frameworks.** Grob gerechnet solltest du hierfür **1 bis 2 GB als Grundrauschen** einplanen, unabhängig von der Modellgrösse, plus einen Puffer, wenn du mit variabler Batchgrösse arbeitest oder mehrere Requests gleichzeitig verarbeitest. Frameworks wie vLLM reservieren zudem bewusst zusätzlichen Speicher für PagedAttention-Blöcke und Zwischenergebnisse, das ist kein Bug, sondern Teil davon, warum sie überhaupt performant sind.\n\nDer Grund, warum wir diesen Posten trotz seiner geringen Grösse ausdrücklich erwähnen: **Er ist der Unterschied zwischen \"passt gerade so\" und \"läuft stabil\".** Wer seine GPU bis auf den letzten Gigabyte für Gewichte und KV-Cache ausrechnet und dann live geht, erlebt den ersten Out-of-Memory-Fehler meist innerhalb der ersten Betriebswoche, sobald ein Nutzer zufällig einen längeren Prompt schickt oder zwei Requests gleichzeitig eintreffen. Ein realistischer Sicherheitspuffer ist keine Vorsicht, sondern die Voraussetzung dafür, dass die Rechnung überhaupt in der Praxis hält, was sie auf dem Papier verspricht.\n\n## Die Rechnung durchgespielt: drei Modellgrössen, drei Quantisierungsstufen\n\nAm klarsten wird das Ganze an konkreten Zahlen, deshalb rechnen wir drei typische Modellgrössen jeweils in fp16, int8 und int4 durch, nur für die reinen Gewichte:\n\n- **7B\u002F8B-Modelle** (z. B. Llama 3.1 8B, Mistral 7B): fp16 ≈ 14-16 GB, int8 ≈ 7-8 GB, int4 ≈ 3,5-4 GB.\n- **13B-Modelle**: fp16 ≈ 26 GB, int8 ≈ 13 GB, int4 ≈ 6,5 GB.\n- **70B-Modelle** (z. B. Llama 3.1\u002F3.3 70B): fp16 ≈ 140 GB, int8 ≈ 70 GB, int4 ≈ 35 GB.\n\nLegst du das gegen reale Hardware, wird die Konsequenz sofort greifbar. Auf einer **24-GB-Karte** passt ein 7B\u002F8B-Modell komfortabel in fp16, ein 13B-Modell braucht schon int8 oder int4, und ein 70B-Modell passt nur in int4, und dann bleibt kaum noch Platz für KV-Cache und Overhead, geschweige denn für mehrere Nutzer mit langem Kontext. Auf **48 GB** hast du für 7B\u002F13B in fp16 komfortabel Luft, für 70B brauchst du weiterhin int4 oder knapp int8 mit sehr kleinem Kontext. Eine **80-GB-H100** trägt ein 70B-Modell in int8 mit spürbarem Puffer für Kontext und moderates Batching, in fp16 wird es eng, weil 140 GB Gewichte allein schon nicht draufpassen, ganz ohne KV-Cache. Und eine **DGX Spark mit 128 GB Unified Memory** trägt ein 70B-Modell sogar in fp16 mit Reserve für ordentlichen Kontext, ohne dass du überhaupt quantisieren musst, was insbesondere für Genauigkeit bei anspruchsvollen Aufgaben relevant sein kann. Das ist genau der Rechenweg, den wir im [Erfahrungsbericht zur DGX Spark](\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht) im Praxisbetrieb durchgespielt haben, dort mit echten Ladezeiten und echten Tokens\u002Fs, nicht nur auf Papier.\n\nDer Punkt, an dem die meisten Rechnungen kippen, ist selten die Modellgrösse allein, sondern die Kombination aus Modellgrösse und Concurrency. Ein 8B-Modell für einen einzelnen internen Nutzer mit kurzem Kontext läuft auf praktisch jeder Karte ab 16 GB entspannt, Gewichte und KV-Cache zusammen bleiben deutlich unter 20 GB. Derselbe 8B-Endpoint für fünfzig gleichzeitige Nutzer mit 8k-Kontext sieht komplett anders aus, dann dominiert plötzlich der KV-Cache die Rechnung, nicht mehr die Gewichte. **Genau deshalb reicht es nicht, nur \"welches Modell\" zu fragen, du musst \"welches Modell, für wie viele gleichzeitig, mit wie viel Kontext\" fragen**, sonst rechnest du nur die halbe Gleichung.\n\n## Erst der Use-Case, dann die Hardware\n\nAus all dem folgt eine simple, aber oft ignorierte Reihenfolge: **Du definierst zuerst deinen Use-Case, dann wählst du die Hardware, nicht umgekehrt.** Konkret heisst das, drei Fragen zu beantworten, bevor du auch nur eine Preisliste öffnest. Welche Modellgrösse brauchst du wirklich, reicht ein 8B-Modell für deinen Anwendungsfall oder brauchst du die Qualität eines 70B-Modells? Wie lang werden deine typischen Kontexte, reichen 4k Token oder arbeitest du mit ganzen Dokumenten bei 32k und mehr? Und wie viele Nutzer greifen gleichzeitig zu, ist das ein interner Tool für fünf Personen oder ein Endpoint mit hundert parallelen Sessions?\n\nWer diese Reihenfolge umdreht und zuerst die Hardware kauft, kauft fast immer falsch, entweder zu klein, was zu ständigem Quantisierungs-Downgrade und Kontext-Kürzung führt, oder zu gross, was Kapital bindet, das produktiv nirgends gebraucht wird. **Die günstigste GPU der Welt ist trotzdem zu teuer, wenn sie deinen Use-Case nicht trägt**, und die teuerste ist Verschwendung, wenn ein kleineres Modell für deine Aufgabe längst gereicht hätte. Bei der Modellwahl selbst hilft unser Überblick zur [Auswahl offener Modelle](\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl), bei der Frage Kapazität gegen Bandbreite unser Vergleich [DGX Spark gegen Cloud-GPU](\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu). Als Grobregel gilt: **Brauchst du vor allem Kapazität für grosse Modelle bei stabiler, planbarer Last, ist [DGX Spark](\u002Fde\u002Fdgx-spark) die richtige Wahl. Brauchst du rohen Durchsatz für Training oder sehr viele parallele Nutzer, ist [Bare-Metal H100](\u002Fde\u002Fbare-metal) die richtige Liga.** Und was die einzelnen Optionen am Ende tatsächlich kosten, inklusive der Posten, die in Angeboten gerne verschwiegen werden, steht offen in unserer [Kostenrechnung für Self-Hosted LLMs](\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten).\n\n## Die volle Formel entscheidet, nicht die Gewichte allein\n\n\"70B läuft auf 24 GB\" ist keine Lüge, aber es ist auch keine Aussage, auf der du eine Kaufentscheidung aufbauen solltest, ohne die Bedingungen dahinter selbst nachzurechnen. **Die vollständige Formel ist immer: Gewichte plus KV-Cache plus Overhead, nicht nur die Gewichte allein.** Wer nur die Gewichte rechnet, hat nur die halbe Rechnung gemacht, und der fehlende Teil meldet sich spätestens beim zweiten gleichzeitigen Nutzer mit langem Kontext, meist zur unpassendsten Zeit.\n\nWir rechnen diese Zahlen bei Twentyone für jeden Kunden konkret durch, mit echter Modellgrösse, echter Kontextlänge und echter Nutzerzahl, bevor irgendeine Maschine reserviert wird. Wenn du wissen willst, ob dein Modell auf eine [H100 bare metal](\u002Fde\u002Fbare-metal) passt, oder ob du eigentlich etwas ganz anderes brauchst, rechnen wir es gemeinsam durch, offen und ohne dir vorher etwas verkaufen zu wollen, das du nicht brauchst.","\u003Ch2>\u003Cq>70B läuft doch auf 24 GB\u003C\u002Fq>\u003C\u002Fh2>\n\n\u003Cp>In einem Workshop letzten Monat sagte ein CTO einen Satz, den wir inzwischen fast jede Woche hören: \u003Cq>Wir haben gelesen, ein 70B-Modell läuft problemlos auf einer 24-GB-Karte, dann kaufen wir halt zwei davon.\u003C\u002Fq> Der Satz stammte aus einem Forumspost, nicht aus einer eigenen Rechnung, und genau das ist das Problem. \u003Cstrong>Die Aussage stimmt sogar, aber nur unter Bedingungen, die im Forumspost nicht mehr auftauchen\u003C\u002Fstrong>: aggressive 4-Bit-Quantisierung, ein Kontext von vielleicht 2000 Token, ein einziger Nutzer, kein Puffer für irgendetwas anderes. Sobald einer dieser Punkte wegfällt, bricht die Rechnung zusammen, und die GPU meldet \u003Cq>out of memory\u003C\u002Fq>, meist mitten in der Produktivdemo.\u003C\u002Fp>\n\n\u003Cp>Wir sehen diesen Fehler so oft, dass wir ihn zum Anlass für diesen Artikel gemacht haben. \u003Cstrong>Bevor du Hardware kaufst oder mietest, rechnest du den VRAM-Bedarf selbst aus\u003C\u002Fstrong>, nicht anhand eines Blogposts, sondern anhand deines Modells, deiner Kontextlänge und deiner Nutzerzahl. Die Rechnung ist keine Raketenwissenschaft, sie dauert fünf Minuten mit Taschenrechner. Aber sie wird fast nie gemacht, bevor die Bestellung raus ist.\u003C\u002Fp>\n\n\u003Ch2>Die Faustformel für die Modellgewichte\u003C\u002Fh2>\n\n\u003Cp>Der erste und grösste Posten sind die reinen Modellgewichte, und dafür gibt es eine simple Faustregel: \u003Cstrong>Pro Milliarde Parameter brauchst du in fp16 rund 2 GB, in int8 rund 1 GB und in int4 rund 0,5 GB.\u003C\u002Fstrong> Der Grund ist banal: fp16 speichert jeden Parameter mit 16 Bit, also 2 Byte, int8 mit einem Byte, int4 mit einem halben Byte. Ein 8B-Modell wiegt also in fp16 rund 16 GB, in int8 rund 8 GB, in int4 rund 4 GB. Multiplizierst du die Parameterzahl mit dem Bytes-pro-Parameter-Faktor, hast du die Basiszahl, auf der alles Weitere aufbaut.\u003C\u002Fp>\n\n\u003Cp>Wichtig dabei: \u003Cstrong>Quantisierung ist kein Freibrief ohne Kosten.\u003C\u002Fstrong> int4 halbiert den Speicherbedarf gegenüber int8 nochmal, aber die Modellqualität leidet, besonders bei Reasoning-lastigen Aufgaben und bei sehr grossen Modellen, deren Gewichte ohnehin schon \u003Cq>eng gepackt\u003C\u002Fq> sind. Für viele produktive Anwendungsfälle ist int8 der vernünftige Mittelweg zwischen Speicherersparnis und Qualität, int4 lohnt sich vor allem dort, wo Kapazität die harte Grenze ist und du die Qualitätseinbusse getestet und akzeptiert hast, nicht als automatischer erster Griff.\u003C\u002Fp>\n\n\u003Ch2>Der Posten, den fast jeder vergisst: der KV-Cache\u003C\u002Fh2>\n\n\u003Cp>Hier liegt der Grund, warum so viele VRAM-Rechnungen in der Praxis scheitern, obwohl die Modellgewichte sauber berechnet waren. Der \u003Cstrong>KV-Cache\u003C\u002Fstrong> speichert für jedes bereits verarbeitete Token die sogenannten Key- und Value-Vektoren aus jeder Attention-Schicht, damit das Modell sie beim nächsten Token nicht neu berechnen muss. Das ist der Trick, der Inferenz überhaupt schnell macht, aber er hat einen Preis: \u003Cstrong>Der KV-Cache wächst linear mit Kontextlänge, Batchgrösse, Anzahl der Layer und Hidden-Size des Modells.\u003C\u002Fstrong> Er ist kein fixer Posten wie die Gewichte, er ist ein Posten, der mit jedem zusätzlichen Token und jedem zusätzlichen Nutzer weiterwächst, solange die Session offen bleibt.\u003C\u002Fp>\n\n\u003Cp>Bei kurzen Prompts mit wenigen hundert Token fällt das kaum ins Gewicht, ein paar hundert MB, in der Rechnung fast vernachlässigbar. Bei \u003Cstrong>langen Kontexten ab 32k Token\u003C\u002Fstrong> sieht das anders aus. Grob gerechnet gilt: \u003Cstrong>KV-Cache-Grösse ≈ 2 (Key und Value) × Anzahl Layer × Hidden-Size × Bytes pro Wert × Anzahl Token\u003C\u002Fstrong>, multipliziert mit der Zahl paralleler Sequenzen. Bei einem grossen Modell mit vielen Layern und breiter Hidden-Size kann der KV-Cache pro Nutzer schon bei einem einzigen langen Kontext in den Bereich von mehreren GB rutschen, bei Modellen ohne speichersparende Attention-Varianten (Grouped-Query-Attention reduziert das deutlich) auch deutlich mehr. Und dann kommt der Faktor, der in den meisten Milchmädchenrechnungen komplett fehlt: \u003Cstrong>Concurrency.\u003C\u002Fstrong> Bedienst du nicht einen, sondern zehn gleichzeitige Nutzer mit langen Kontexten, multipliziert sich der KV-Cache-Bedarf entsprechend, und aus ein paar GB werden schnell zweistellige GB, die zusätzlich zu den Modellgewichten im Speicher liegen müssen. Genau das ist die Lücke, in der reale Deployments an die Wand fahren, obwohl \u003Cq>das Modell doch gepasst hat\u003C\u002Fq>.\u003C\u002Fp>\n\n\u003Cp>Zwei Stellschrauben helfen dagegen, wenn der KV-Cache zum Flaschenhals wird, und beide solltest du kennen, bevor du automatisch zu mehr Hardware greifst. \u003Cstrong>Grouped-Query-Attention (GQA)\u003C\u002Fstrong>, in praktisch allen aktuellen offenen Modellen wie Llama 3 oder Mistral verbaut, reduziert die Zahl der gespeicherten Key-Value-Köpfe drastisch gegenüber klassischer Multi-Head-Attention, oft um den Faktor 4 bis 8. Und \u003Cstrong>Quantisierung des KV-Cache selbst\u003C\u002Fstrong>, also int8 statt fp16 für die gespeicherten Key-Value-Vektoren, halbiert den Bedarf nochmal, unabhängig davon, in welcher Präzision die Modellgewichte laufen. Beide Hebel kosten etwas Qualität am Rand, aber deutlich weniger als an den Gewichten selbst zu sparen, weshalb sie in der Praxis oft der bessere erste Griff sind, bevor du eine grössere Karte bestellst.\u003C\u002Fp>\n\n\u003Ch2>Overhead: die letzten 1-2 GB, die trotzdem entscheiden\u003C\u002Fh2>\n\n\u003Cp>Nach Gewichten und KV-Cache bleibt noch ein dritter Posten, kleiner, aber real: \u003Cstrong>Aktivierungen während der Forward-Pass-Berechnung, der CUDA-Kontext selbst und der Speicherbedarf des Inferenz-Frameworks.\u003C\u002Fstrong> Grob gerechnet solltest du hierfür \u003Cstrong>1 bis 2 GB als Grundrauschen\u003C\u002Fstrong> einplanen, unabhängig von der Modellgrösse, plus einen Puffer, wenn du mit variabler Batchgrösse arbeitest oder mehrere Requests gleichzeitig verarbeitest. Frameworks wie vLLM reservieren zudem bewusst zusätzlichen Speicher für PagedAttention-Blöcke und Zwischenergebnisse, das ist kein Bug, sondern Teil davon, warum sie überhaupt performant sind.\u003C\u002Fp>\n\n\u003Cp>Der Grund, warum wir diesen Posten trotz seiner geringen Grösse ausdrücklich erwähnen: \u003Cstrong>Er ist der Unterschied zwischen \u003Cq>passt gerade so\u003C\u002Fq> und \u003Cq>läuft stabil\u003C\u002Fq>.\u003C\u002Fstrong> Wer seine GPU bis auf den letzten Gigabyte für Gewichte und KV-Cache ausrechnet und dann live geht, erlebt den ersten Out-of-Memory-Fehler meist innerhalb der ersten Betriebswoche, sobald ein Nutzer zufällig einen längeren Prompt schickt oder zwei Requests gleichzeitig eintreffen. Ein realistischer Sicherheitspuffer ist keine Vorsicht, sondern die Voraussetzung dafür, dass die Rechnung überhaupt in der Praxis hält, was sie auf dem Papier verspricht.\u003C\u002Fp>\n\n\u003Ch2>Die Rechnung durchgespielt: drei Modellgrössen, drei Quantisierungsstufen\u003C\u002Fh2>\n\n\u003Cp>Am klarsten wird das Ganze an konkreten Zahlen, deshalb rechnen wir drei typische Modellgrössen jeweils in fp16, int8 und int4 durch, nur für die reinen Gewichte:\u003C\u002Fp>\n\n\u003Cul>\n\u003Cli>\u003Cstrong>7B\u002F8B-Modelle\u003C\u002Fstrong> (z. B. Llama 3.1 8B, Mistral 7B): fp16 ≈ 14-16 GB, int8 ≈ 7-8 GB, int4 ≈ 3,5-4 GB.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>13B-Modelle\u003C\u002Fstrong>: fp16 ≈ 26 GB, int8 ≈ 13 GB, int4 ≈ 6,5 GB.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>70B-Modelle\u003C\u002Fstrong> (z. B. Llama 3.1\u002F3.3 70B): fp16 ≈ 140 GB, int8 ≈ 70 GB, int4 ≈ 35 GB.\u003C\u002Fli>\n\u003C\u002Ful>\n\n\u003Cp>Legst du das gegen reale Hardware, wird die Konsequenz sofort greifbar. Auf einer \u003Cstrong>24-GB-Karte\u003C\u002Fstrong> passt ein 7B\u002F8B-Modell komfortabel in fp16, ein 13B-Modell braucht schon int8 oder int4, und ein 70B-Modell passt nur in int4, und dann bleibt kaum noch Platz für KV-Cache und Overhead, geschweige denn für mehrere Nutzer mit langem Kontext. Auf \u003Cstrong>48 GB\u003C\u002Fstrong> hast du für 7B\u002F13B in fp16 komfortabel Luft, für 70B brauchst du weiterhin int4 oder knapp int8 mit sehr kleinem Kontext. Eine \u003Cstrong>80-GB-H100\u003C\u002Fstrong> trägt ein 70B-Modell in int8 mit spürbarem Puffer für Kontext und moderates Batching, in fp16 wird es eng, weil 140 GB Gewichte allein schon nicht draufpassen, ganz ohne KV-Cache. Und eine \u003Cstrong>DGX Spark mit 128 GB Unified Memory\u003C\u002Fstrong> trägt ein 70B-Modell sogar in fp16 mit Reserve für ordentlichen Kontext, ohne dass du überhaupt quantisieren musst, was insbesondere für Genauigkeit bei anspruchsvollen Aufgaben relevant sein kann. Das ist genau der Rechenweg, den wir im \u003Ca href=\"\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht\">Erfahrungsbericht zur DGX Spark\u003C\u002Fa> im Praxisbetrieb durchgespielt haben, dort mit echten Ladezeiten und echten Tokens\u002Fs, nicht nur auf Papier.\u003C\u002Fp>\n\n\u003Cp>Der Punkt, an dem die meisten Rechnungen kippen, ist selten die Modellgrösse allein, sondern die Kombination aus Modellgrösse und Concurrency. Ein 8B-Modell für einen einzelnen internen Nutzer mit kurzem Kontext läuft auf praktisch jeder Karte ab 16 GB entspannt, Gewichte und KV-Cache zusammen bleiben deutlich unter 20 GB. Derselbe 8B-Endpoint für fünfzig gleichzeitige Nutzer mit 8k-Kontext sieht komplett anders aus, dann dominiert plötzlich der KV-Cache die Rechnung, nicht mehr die Gewichte. \u003Cstrong>Genau deshalb reicht es nicht, nur \u003Cq>welches Modell\u003C\u002Fq> zu fragen, du musst \u003Cq>welches Modell, für wie viele gleichzeitig, mit wie viel Kontext\u003C\u002Fq> fragen\u003C\u002Fstrong>, sonst rechnest du nur die halbe Gleichung.\u003C\u002Fp>\n\n\u003Ch2>Erst der Use-Case, dann die Hardware\u003C\u002Fh2>\n\n\u003Cp>Aus all dem folgt eine simple, aber oft ignorierte Reihenfolge: \u003Cstrong>Du definierst zuerst deinen Use-Case, dann wählst du die Hardware, nicht umgekehrt.\u003C\u002Fstrong> Konkret heisst das, drei Fragen zu beantworten, bevor du auch nur eine Preisliste öffnest. Welche Modellgrösse brauchst du wirklich, reicht ein 8B-Modell für deinen Anwendungsfall oder brauchst du die Qualität eines 70B-Modells? Wie lang werden deine typischen Kontexte, reichen 4k Token oder arbeitest du mit ganzen Dokumenten bei 32k und mehr? Und wie viele Nutzer greifen gleichzeitig zu, ist das ein interner Tool für fünf Personen oder ein Endpoint mit hundert parallelen Sessions?\u003C\u002Fp>\n\n\u003Cp>Wer diese Reihenfolge umdreht und zuerst die Hardware kauft, kauft fast immer falsch, entweder zu klein, was zu ständigem Quantisierungs-Downgrade und Kontext-Kürzung führt, oder zu gross, was Kapital bindet, das produktiv nirgends gebraucht wird. \u003Cstrong>Die günstigste GPU der Welt ist trotzdem zu teuer, wenn sie deinen Use-Case nicht trägt\u003C\u002Fstrong>, und die teuerste ist Verschwendung, wenn ein kleineres Modell für deine Aufgabe längst gereicht hätte. Bei der Modellwahl selbst hilft unser Überblick zur \u003Ca href=\"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl\">Auswahl offener Modelle\u003C\u002Fa>, bei der Frage Kapazität gegen Bandbreite unser Vergleich \u003Ca href=\"\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu\">DGX Spark gegen Cloud-GPU\u003C\u002Fa>. Als Grobregel gilt: \u003Cstrong>Brauchst du vor allem Kapazität für grosse Modelle bei stabiler, planbarer Last, ist \u003Ca href=\"\u002Fde\u002Fdgx-spark\">DGX Spark\u003C\u002Fa> die richtige Wahl. Brauchst du rohen Durchsatz für Training oder sehr viele parallele Nutzer, ist \u003Ca href=\"\u002Fde\u002Fbare-metal\">Bare-Metal H100\u003C\u002Fa> die richtige Liga.\u003C\u002Fstrong> Und was die einzelnen Optionen am Ende tatsächlich kosten, inklusive der Posten, die in Angeboten gerne verschwiegen werden, steht offen in unserer \u003Ca href=\"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten\">Kostenrechnung für Self-Hosted LLMs\u003C\u002Fa>.\u003C\u002Fp>\n\n\u003Ch2>Die volle Formel entscheidet, nicht die Gewichte allein\u003C\u002Fh2>\n\n\u003Cp>\u003Cq>70B läuft auf 24 GB\u003C\u002Fq> ist keine Lüge, aber es ist auch keine Aussage, auf der du eine Kaufentscheidung aufbauen solltest, ohne die Bedingungen dahinter selbst nachzurechnen. \u003Cstrong>Die vollständige Formel ist immer: Gewichte plus KV-Cache plus Overhead, nicht nur die Gewichte allein.\u003C\u002Fstrong> Wer nur die Gewichte rechnet, hat nur die halbe Rechnung gemacht, und der fehlende Teil meldet sich spätestens beim zweiten gleichzeitigen Nutzer mit langem Kontext, meist zur unpassendsten Zeit.\u003C\u002Fp>\n\n\u003Cp>Wir rechnen diese Zahlen bei Twentyone für jeden Kunden konkret durch, mit echter Modellgrösse, echter Kontextlänge und echter Nutzerzahl, bevor irgendeine Maschine reserviert wird. Wenn du wissen willst, ob dein Modell auf eine \u003Ca href=\"\u002Fde\u002Fbare-metal\">H100 bare metal\u003C\u002Fa> passt, oder ob du eigentlich etwas ganz anderes brauchst, rechnen wir es gemeinsam durch, offen und ohne dir vorher etwas verkaufen zu wollen, das du nicht brauchst.\u003C\u002Fp>\n",[],[31,34,37],{"title":32,"href":33},"Preise","\u002Fde\u002Fpreise",{"title":35,"href":36},"Wissen","\u002Fde\u002Fwissen",{"title":38,"href":39},"Über Twentyone","\u002Fde\u002Fueber-uns",[],[42,54,66,76,84,92,98,104,110,116,118,125,131,137,143,149,155,162],{"path":43,"slug":44,"title":45,"summary":46,"image":47,"publication_date":48,"big5_category":49,"primary_hub":47,"cluster":47,"pillar":47,"hubs":50},"\u002Fde\u002Fwissen\u002Fazure-openai-bedrock-alternative-schweiz","azure-openai-bedrock-alternative-schweiz","Souveräne Inferenz gegen Azure OpenAI und AWS Bedrock: was sich im Alltag ändert","Azure OpenAI und AWS Bedrock gegen einen souverän betriebenen Endpoint: warum der Schweizer Serverstandort der Hyperscaler das Kernproblem nicht löst und was der Unterschied im Betrieb bedeutet.",null,"2026-07-13T00:00:00Z","comparisons",[51],{"slug":52,"title":53},"managed-inference","Managed Inference",{"path":55,"slug":56,"title":57,"summary":58,"image":47,"publication_date":48,"big5_category":59,"primary_hub":47,"cluster":47,"pillar":47,"hubs":60},"\u002Fde\u002Fwissen\u002Fbeste-gpu-llm-inferenz","beste-gpu-llm-inferenz","Die beste GPU für LLM-Inferenz: DGX Spark, H100, L40S und RTX im Vergleich","Welche GPU für eigene Inferenz? DGX Spark, H100, L40S und RTX 4090 nach dem, was zählt: wie viel Modell hineinpasst, wie viel Durchsatz herauskommt und was der Monat kostet.","bestof",[61,63],{"slug":20,"title":62},"Bare Metal GPU mit Root-Zugriff",{"slug":64,"title":65},"dgx-spark","DGX Spark mieten",{"path":67,"slug":68,"title":69,"summary":70,"image":47,"publication_date":48,"big5_category":71,"primary_hub":47,"cluster":47,"pillar":47,"hubs":72},"\u002Fde\u002Fwissen\u002Fhermes-agent-erfahrungsbericht","hermes-agent-erfahrungsbericht","Hermes-Agent im Realbetrieb: was ein souveräner Agent wirklich leistet","Ein Erfahrungsbericht statt Hochglanzprospekt: wie sich ein souverän betriebener Hermes-Agent im täglichen Einsatz verhält, wo er glänzt und wo die Begleitung anfängt.","reviews",[73],{"slug":74,"title":75},"agents","Hermes Agents as a Service",{"path":77,"slug":78,"title":79,"summary":80,"image":47,"publication_date":48,"big5_category":81,"primary_hub":47,"cluster":47,"pillar":47,"hubs":82},"\u002Fde\u002Fwissen\u002Fki-regulierte-daten-schweiz","ki-regulierte-daten-schweiz","KI mit regulierten Daten: LLMs nutzen, ohne dass die Daten die Schweiz verlassen","Für Branchen, in denen Daten das Land nicht verlassen dürfen: was revDSG, Berufsgeheimnis und der CLOUD Act für KI-Projekte bedeuten, und wie souveräne Inferenz den Rahmen einhält.","problems",[83],{"slug":52,"title":53},{"path":85,"slug":86,"title":87,"summary":88,"image":47,"publication_date":48,"big5_category":89,"primary_hub":47,"cluster":47,"pillar":47,"hubs":90},"\u002Fde\u002Fwissen\u002Fopenai-api-kosten-vs-eigener-endpoint","openai-api-kosten-vs-eigener-endpoint","Ab welchem Volumen sich ein eigener Endpoint gegen die API rechnet","Die Pay-per-Token-API ist günstig, bis sie es nicht mehr ist. Wo genau der Break-even zu einem reservierten Endpoint mit fester Monatspauschale liegt, an einem konkreten Beispiel durchgerechnet.","cost",[91],{"slug":52,"title":53},{"path":93,"slug":94,"title":95,"summary":96,"image":47,"publication_date":16,"big5_category":49,"primary_hub":47,"cluster":47,"pillar":47,"hubs":97},"\u002Fde\u002Fwissen\u002Ffine-tuning-rag-prompt","fine-tuning-rag-prompt","Fine-Tuning, RAG oder besserer Prompt? Die klare Entscheidungsregel","Fine-Tuning ist meistens nicht die Antwort auf „das Modell kennt unsere Daten nicht“. Wann Prompting, RAG oder Fine-Tuning wirklich das richtige Werkzeug sind und wie du die Eskalationsleiter korrekt durchläufst.",[],{"path":99,"slug":100,"title":101,"summary":102,"image":47,"publication_date":16,"big5_category":17,"primary_hub":47,"cluster":47,"pillar":47,"hubs":103},"\u002Fde\u002Fwissen\u002Fopenai-api-migration","openai-api-migration","Von der OpenAI-API zu souveräner Inferenz: die Migration in der Praxis","Der Umstieg von OpenAI oder Anthropic auf ein selbst betriebenes offenes Modell in der Schweiz sieht dank OpenAI-kompatibler Endpoints nach einer Ein-Zeilen-Änderung aus, ist aber doch mehr. Wo Prompts, Tool-Calling und Feature-Lücken zur Stolperfalle werden.",[],{"path":105,"slug":106,"title":107,"summary":108,"image":47,"publication_date":16,"big5_category":81,"primary_hub":47,"cluster":47,"pillar":47,"hubs":109},"\u002Fde\u002Fwissen\u002Fquantisierung-int4-int8-awq-gptq-gguf","quantisierung-int4-int8-awq-gptq-gguf","Quantisierung ohne Qualitätsverlust: int4, int8, AWQ, GPTQ, GGUF entzaubert","int8 ist fast immer verlustfrei, int4 meistens auch, aber nicht bei Reasoning, Code und langen Agenten-Ketten. Wir zeigen dir ungeschönt, was Quantisierung wirklich kostet und wo GPTQ, AWQ, GGUF und bitsandbytes hingehören.",[],{"path":111,"slug":112,"title":113,"summary":114,"image":47,"publication_date":16,"big5_category":81,"primary_hub":47,"cluster":47,"pillar":47,"hubs":115},"\u002Fde\u002Fwissen\u002Frag-schlechte-antworten","rag-schlechte-antworten","RAG richtig gebaut: warum eure Wissensbasis schlechte Antworten gibt","Die meisten RAG-Systeme scheitern nicht am Sprachmodell, sondern am Retrieval davor. Wir zeigen die häufigsten Fehlerquellen bei Chunking, Embeddings und Retrieval-Strategie sowie, wie du Retrieval- und Generationsfehler sauber auseinanderhältst.",[],{"path":6,"slug":7,"title":14,"summary":15,"image":47,"publication_date":16,"big5_category":17,"primary_hub":47,"cluster":47,"pillar":47,"hubs":117},[],{"path":119,"slug":120,"title":121,"summary":122,"image":47,"publication_date":123,"big5_category":81,"primary_hub":47,"cluster":47,"pillar":47,"hubs":124},"\u002Fde\u002Fwissen\u002Fagent-oder-endpoint","agent-oder-endpoint","Braucht ihr wirklich einen Agent oder reicht ein Endpoint?","Agenten sind im Trend, aber oft die teurere und fragilere Lösung für ein Problem, das ein einfacher Endpoint löst. Wann sich der Aufwand lohnt und wann nicht.","2026-06-30T00:00:00Z",[],{"path":126,"slug":127,"title":128,"summary":129,"image":47,"publication_date":123,"big5_category":81,"primary_hub":47,"cluster":47,"pillar":47,"hubs":130},"\u002Fde\u002Fwissen\u002Fdatenhoheit-was-bedeutet-das","datenhoheit-was-bedeutet-das","Was Datenhoheit konkret heisst und wo deine Prompts wirklich landen","Datenhoheit ist mehr als ein Hosting-Standort. Was rechtlich, technisch und vertraglich dahintersteckt, und welche Fragen du jedem AI-Anbieter stellen solltest.",[],{"path":132,"slug":133,"title":134,"summary":135,"image":47,"publication_date":123,"big5_category":71,"primary_hub":47,"cluster":47,"pillar":47,"hubs":136},"\u002Fde\u002Fwissen\u002Fdgx-spark-erfahrungsbericht","dgx-spark-erfahrungsbericht","DGX Spark im Betrieb: was die Maschine nach drei Monaten wirklich kann","Kein Datenblatt, sondern ein Erfahrungsbericht. Wo die DGX Spark im täglichen Betrieb glänzt, wo ihre Grenzen liegen und für wen sich die Maschine lohnt.",[],{"path":138,"slug":139,"title":140,"summary":141,"image":47,"publication_date":123,"big5_category":17,"primary_hub":47,"cluster":47,"pillar":47,"hubs":142},"\u002Fde\u002Fwissen\u002Fllm-endpoint-aufsetzen","llm-endpoint-aufsetzen","Eigenen LLM Endpoint aufsetzen: von der GPU zum ersten Token","Ein realistischer Weg vom blanken Server zum produktiven Inferenz-Endpoint. Die Schritte, die Reihenfolge und die Stolpersteine, die zwischen „läuft lokal“ und „läuft produktiv“ liegen.",[],{"path":144,"slug":145,"title":146,"summary":147,"image":47,"publication_date":123,"big5_category":59,"primary_hub":47,"cluster":47,"pillar":47,"hubs":148},"\u002Fde\u002Fwissen\u002Foffene-modelle-auswahl","offene-modelle-auswahl","Welches offene Modell für welche Aufgabe? Llama, Qwen, Mistral & Co.","Nicht das grösste Modell gewinnt, sondern das passende. Wie du offene Modelle nach Aufgabe, Speicherbedarf und Lizenz auswählst, statt Benchmarks hinterherzulaufen.",[],{"path":150,"slug":151,"title":152,"summary":153,"image":47,"publication_date":123,"big5_category":49,"primary_hub":47,"cluster":47,"pillar":47,"hubs":154},"\u002Fde\u002Fwissen\u002Fvllm-ollama-tgi-vergleich","vllm-ollama-tgi-vergleich","vLLM, Ollama oder TGI: welche Inference Engine für welchen Fall","Die Engine entscheidet über Durchsatz, Latenz und Betriebsaufwand. Ein nüchterner Vergleich der drei verbreitetsten Optionen, inklusive der Fälle, in denen die einfache Lösung gewinnt.",[],{"path":156,"slug":157,"title":158,"summary":159,"image":47,"publication_date":160,"big5_category":49,"primary_hub":47,"cluster":47,"pillar":47,"hubs":161},"\u002Fde\u002Fwissen\u002Fdgx-spark-vs-cloud-gpu","dgx-spark-vs-cloud-gpu","DGX Spark gegen Cloud-GPU: wann sich eigene Hardware lohnt","Unified Memory gegen rohen Durchsatz, Schweizer Hardware gegen Hyperscaler. Ein nüchterner Vergleich, inklusive der Fälle, in denen die Cloud gewinnt.","2026-06-18T00:00:00Z",[],{"path":163,"slug":164,"title":165,"summary":166,"image":47,"publication_date":160,"big5_category":89,"primary_hub":47,"cluster":47,"pillar":47,"hubs":167},"\u002Fde\u002Fwissen\u002Fllm-selbst-betreiben-kosten","llm-selbst-betreiben-kosten","Was kostet es, ein LLM selbst zu betreiben?","Die nüchterne Rechnung hinter eigenen LLM-Endpoints: Hardware, Betrieb und der Punkt, ab dem sich Selbermachen wirklich lohnt.",[],[],[170,173,176,179],{"title":65,"href":171,"description":172},"\u002Fde\u002Fdgx-spark","Der NVIDIA-AI-Supercomputer für den Schreibtisch — on-demand aus der Schweiz, bare metal oder gemanagt.",{"title":174,"href":21,"description":175},"Bare Metal GPU","DGX Spark & H100 als dedizierte Maschine — volle Kontrolle, Root-Zugriff, Schweizer Rechenzentrum.",{"title":53,"href":177,"description":178},"\u002Fde\u002Fmanaged-inference","LLM-Endpoints via vLLM — von uns betrieben, ohne Ops-Aufwand, mit Schweizer Datenhoheit.",{"title":180,"href":181,"description":182},"Hermes Agents","\u002Fde\u002Fagents","Agentische Workloads gemanagt — Hermes-Agents auf souveräner Hardware, von uns betrieben.",[184,191],{"title":185,"links":186},"Leistungen",[187,188,189,190],{"title":65,"href":171},{"title":174,"href":21},{"title":53,"href":177},{"title":180,"href":181},{"title":192,"links":193},"Unternehmen",[194,195,196,197],{"title":38,"href":39},{"title":35,"href":36},{"title":32,"href":33},{"title":198,"href":199},"Kontakt","\u002Fde\u002Fkontakt"]