KI-Server nach Anwendung dimensionieren statt nach Modellgröße

TL;DR

Dimensionieren Sie nach Anwendung, nicht nach Modellgröße. RAG braucht viel System-RAM und wenig VRAM. Ein Chat-Assistent braucht Parallelität statt Parameter. OCR im Nachtlauf kommt mit einer 16-GB-Karte aus. Code-Assistenz frisst VRAM über den KV-Cache. Sichtprüfung gehört gar nicht auf den zentralen Server. Die drei Zahlen, die wirklich zählen: gleichzeitige Nutzer, Kontextlänge, Latenzziel.

Warum die Modellgröße die falsche Startfrage ist

Fast jeder Hardware-Guide für KI-Server beginnt mit derselben Tabelle: 7B in Q4 braucht rund 4 GB VRAM, 70B in Q4 rund 42 GB. Das ist rechnerisch korrekt und praktisch wertlos, weil es nur die Gewichte zählt und den KV-Cache unterschlägt — und der entscheidet, wie viele Leute die Maschine gleichzeitig bedienen kann.

Denn kein IT-Leiter kommt mit der Frage "Wir brauchen 70B" ins Budgetgespräch. Er kommt mit: "Der Vertrieb will unsere Angebotsdatenbank durchsuchbar machen." Oder: "Die Buchhaltung will Eingangsrechnungen nicht mehr abtippen." Die Modellgröße ist eine abgeleitete Größe, keine Anforderung — und meistens die am wenigsten wichtige.

Was tatsächlich über die Hardware entscheidet, sind drei andere Werte: wie viele Anfragen gleichzeitig laufen, wie lang der Kontext pro Anfrage ist und ob die Antwort in 200 Millisekunden oder in acht Stunden kommen darf. Diese drei stehen in keiner VRAM-Tabelle.

Die folgenden fünf Anwendungen decken ab, was im Mittelstand 2026 tatsächlich gebaut wird — jeweils mit Faustformel und Beispielkonfiguration in Größenordnungen. Das hier ist keine Bestellliste. Wer schon weiß, was er braucht, und einen KI-Server kaufen will, findet die konkreten Konfigurationen, Komponentenlisten und Preise im Hardware-Guide für eigene KI-Server.

Zu den Preisen in diesem Text: Es sind Netto-Größenordnungen für komplette Systeme, Stand Juli 2026. Belastbar sind darin nur die GPU-Preise — die verlinken wir. Der Rest der Maschine schwankt je nach Systemhaus und Servicevertrag um 20 bis 30 Prozent nach oben oder unten.

RAG über die eigene Dokumentenablage

Der häufigste Fall, und der am gründlichsten falsch dimensionierte. Bei Retrieval Augmented Generation laufen zwei völlig verschiedene Lasten:

Die Embedding-Last ist ein Einmalereignis. Sie zerlegen den Dokumentenbestand in Chunks und rechnen jeden einmal durch ein Embedding-Modell. Ein Modell wie BGE-M3 schafft auf einer A100 80 GB im Dauerbetrieb rund 60.000 Token pro Sekunde (gemessen mit Text Embeddings Inference). Rechnen wir das für einen realistischen Bestand durch — Annahmen offengelegt: 50.000 Dokumente à durchschnittlich sechs Seiten, zwei Chunks pro Seite, 400 Token pro Chunk. Das sind 600.000 Chunks und 240 Millionen Token. Bei konservativ angesetzten 30.000 Token pro Sekunde ist der Job nach gut zwei Stunden durch. Einmalig. Danach embedden Sie nur noch neue Dokumente und die Suchanfragen selbst — eine Last, die im Rauschen verschwindet.

Die Generierungs-Last läuft dauerhaft, ist aber niedrig, weil RAG-Antworten kurz sind. Zwei bis drei Absätze, selten mehr.

Und hier kommt der Punkt, den die meisten übersehen: Die Vektordatenbank liegt im System-RAM, nicht im VRAM. HNSW-Indizes sind Graphstrukturen mit wahlfreiem Zugriff — sobald der Index nicht mehr komplett in den Arbeitsspeicher passt, bricht die Suchlatenz ein. Die Faustformel:

Vektor-RAM (GB) ≈ (Chunks × Dimensionen × 4 Byte × 1,5) / 1.000.000.000
                                          │        └─ HNSW-Graph-Overhead
                                          └─ float32 pro Dimension

Für unsere 600.000 Chunks bei 1.024 Dimensionen: 600.000 × 1.024 × 4 Byte = 2,5 GB, mit Overhead rund 3,7 GB. Das ist nichts. Selbst mit Betriebssystem, Reranker und Puffer reichen 64 GB RAM locker. Kritisch wird es erst jenseits von fünf Millionen Chunks — dann landen Sie bei 30 GB und mehr allein für den Index, und 128 GB werden Pflicht.

Faustformel fürs Gesamtsystem: VRAM = Generierungsmodell + 3 GB fürs Embedding-Modell. RAM = 1,5 × Vektordaten + 16 GB Grundlast.

Beispielkonfiguration: Eine 24-GB-Karte, 64 GB RAM, 2 TB NVMe. Größenordnung €4.000 bis €6.000 für das komplette System.

Unsere Position dazu ist unbequem: Wer bei RAG das Budget in eine größere GPU steckt statt in die Chunking-Strategie und einen ordentlichen Reranker, kauft am Problem vorbei. Ein 8B-Modell mit gutem Retrieval liefert bessere Antworten als ein 70B-Modell, das die falschen drei Absätze vorgelegt bekommt.

Interner Chat-Assistent für die Belegschaft

Wie viele Ihrer 300 Mitarbeiter tippen wirklich gleichzeitig eine Frage ein?

Die Antwort lautet fast nie "300" und meistens "vier". Rechnen wir nach. Annahmen: 300 Mitarbeiter, 30 Prozent nutzen den Assistenten regelmäßig, also 90 aktive Nutzer. In der geschäftigsten Stunde stellt jeder zwei Anfragen. Das sind 180 Anfragen pro Stunde. Eine Antwort mit 400 Ausgabe-Token bei 35 Token pro Sekunde belegt die GPU rund zwölf Sekunden.

Mittlere Parallelität = 180 Anfragen × 12 s / 3.600 s = 0,6

Bei Poisson-verteilter Ankunft mit Mittelwert 0,6 laufen in 99,7 Prozent der Zeit null bis drei Anfragen gleichzeitig; vier oder mehr treten in unter 0,4 Prozent der Zeit auf. Für 300 Mitarbeiter. Wer stattdessen "300 Nutzer, also brauchen wir einen dicken Server" rechnet, kauft das Zehnfache.

Bevor Sie das als Rechentrick abtun: Die einzige Zahl, die Sie dafür wirklich brauchen, ist die Anfragen-pro-Stunde-Spitze. Die kennen Sie nach zwei Wochen Pilotbetrieb. Alles davor ist Raten — und Raten fällt in dieser Rechnung immer zugunsten des Verkäufers aus.

Entscheidend ist aber nicht nur wie viele, sondern womit Sie diese Parallelität bedienen. Und hier trennt sich die Software. Ollama kann seit Version 0.2 parallele Anfragen bedienen — über OLLAMA_NUM_PARALLEL, mit eigenem KV-Cache-Slot je Anfrage. Was über die konfigurierten Slots hinausgeht, landet in der Warteschlange, und echtes Continuous Batching wie bei vLLM gibt es nicht: vLLM zieht neu ankommende Anfragen in den laufenden Forward-Pass hinein, statt auf den nächsten freien Slot zu warten.

Die gemessenen Unterschiede sind entsprechend deutlich. Bei zehn parallelen Anfragen auf Llama 3.1 8B liefert vLLM rund 485 Token pro Sekunde aggregiert, Ollama rund 150 — Faktor gut drei. Bei 50 gleichzeitigen Nutzern öffnet sich die Schere auf etwa 920 gegen rund 155 Token pro Sekunde (Benchmarkdaten). Noch unangenehmer als der Durchsatz ist die Schwanzlatenz: Bei 50 parallelen Anfragen liegt Ollamas p99 jenseits von 24 Sekunden, weil Anfragen in der Queue stehen — das ist der Moment, in dem Ihre Nutzer sagen "die KI hängt schon wieder".

Bei einem einzelnen Nutzer nehmen die beiden sich nichts. Genau das führt in die Falle: Der Pilot mit drei Testern läuft prima auf Ollama, und beim Rollout auf die Abteilung fällt die Sache um.

Unsere Empfehlung: Ollama für Pilot und Proof of Concept, vLLM ab dem Moment, wo mehr als eine Handvoll Leute gleichzeitig tippt. Der Umstieg kostet einen Nachmittag, die Anleitung steht im vLLM-Server-Guide. Für den Piloten reicht die Ollama-Installation auf Ubuntu.

Beispielkonfiguration: Eine 48-GB-Karte mit einem 24B-Modell, 128 GB RAM, vLLM als Serving-Layer. Größenordnung €9.000 bis €14.000, je nachdem ob eine gebrauchte A6000 oder eine aktuelle Karte hineinwandert.

Rechnungs- und Dokumenten-OCR im Nachtlauf

8.000 Eingangsrechnungen im Monat, zwei Seiten im Schnitt: 16.000 Seiten monatlich, rund 730 pro Werktag.

Ein VLM-basiertes OCR-Setup — konkret DeepSeek-OCR auf einer L40S — schafft rund 35 Seiten pro Minute, also etwa 2.100 Seiten pro Stunde (Durchsatzmessung). Klassische Pipelines ohne Sprachmodell im Pfad liegen darüber, dafür schlechter bei Tabellen und krummen Scans. Nehmen wir den langsameren Weg: 730 Seiten sind in 21 Minuten durch. Das Nachtfenster hat acht Stunden. Sie nutzen vier Prozent davon.

Das ist die Anwendung, bei der im Mittelstand am meisten Geld verbrannt wird. Weil OCR nach "viel Dokumente, also viel Rechenleistung" klingt, landet regelmäßig eine 48-GB-Karte im Angebot — für einen Job, bei dem eine Verdopplung der Laufzeit von 21 auf 42 Minuten exakt null Auswirkung hat.

Die Faustformel ist entsprechend simpel:

Benötigte GPU-Zeit = Seiten pro Nacht / Durchsatz (Seiten pro Stunde)
Wenn Ergebnis < 30 % des Batch-Fensters → kleinste Karte nehmen,
die das Modell hält.

Was Sie stattdessen brauchen: Storage-Durchsatz und eine saubere Fehlerbehandlung. Ein Nachtlauf, der bei Seite 4.200 an einem korrupten PDF abbricht und niemanden benachrichtigt, kostet Sie mehr als jede GPU.

Beispielkonfiguration: Eine 16- bis 24-GB-Karte, 64 GB RAM, schnelle NVMe mit Platz für die Eingangsdokumente. Größenordnung €3.000 bis €4.500. Wenn OCR Ihr einziger Anwendungsfall ist, lautet unsere Empfehlung klar: nicht kaufen. Bei vier Prozent Auslastung zahlen Sie 96 Prozent der Anschaffung dafür, dass eine Karte nachts wartet — gemietete GPU-Kapazität ist hier die ehrlichere Rechnung. Eigene Hardware lohnt bei OCR erst, wenn ein zweiter Workload tagsüber dieselbe Karte belegt.

Code-Assistenz für ein Entwicklerteam

Hier kippt die Logik. Bei allen anderen Anwendungen ist das Modell der größte Speicherposten. Bei Code-Assistenz ist es der KV-Cache.

Der Grund sind die Agenten-Tools. Wenn ein Entwickler eine Datei öffnet und der Assistent den halben Repository-Kontext mitschickt, sind 32.000 Token pro Session normal. Der KV-Cache wächst linear mit dem Kontext:

KV-Cache pro Token = 2 × Layer × KV-Heads × Head-Dimension × Bytes
Qwen2.5-Coder-32B (64 Layer, 8 KV-Heads, Head-Dim 128, FP16-Cache):
2 × 64 × 8 × 128 × 2 Byte = 262.144 Byte ≈ 0,25 MiB pro Token

Bei 32.000 Token macht das 8 GiB pro aktiver Session. Das Modell selbst belegt in Q4 rund 18 GB. Drei gleichzeitig arbeitende Entwickler kosten Sie also 18 + 24 = 42 GB. Bei zehn wären es fast 100 GB — mehr, als eine einzelne Karte hat.

Zwei Hebel entschärfen das. Erstens KV-Cache-Quantisierung auf FP8, die den Cache halbiert und bei Code-Aufgaben kaum messbare Qualitätsverluste bringt. Zweitens die Realität: Entwickler tippen, lesen, denken nach und diskutieren. Zehn Leute im Team heißen zwei bis drei gleichzeitige Inferenzen, nicht zehn.

Was Sie dagegen nicht sparen dürfen, ist die Latenz. Unsere Abnahmegrenze für Inline-Autocomplete liegt bei 200 Millisekunden Time-to-First-Token — darüber tippen Entwickler schneller selbst, und ein Feature, das langsamer ist als der Mensch, wird abgeschaltet. Setzen Sie diesen Wert als Akzeptanzkriterium in die Ausschreibung, sonst diskutieren Sie hinterher über Gefühle. Deshalb laufen in ernsthaften Setups zwei Modelle parallel: ein kleines 1B- bis 3B-Modell für die Inline-Vervollständigung und das große für Chat und Agentenaufgaben. Beide belegen VRAM.

Beispielkonfiguration: Eine 48-GB-Karte oder zwei 24-GB-Karten, 128 GB RAM, FP8-KV-Cache aktiviert. Größenordnung €10.000 bis €15.000 für zehn Entwickler. Welche Karte in welcher Klasse liegt, steht im GPU-Vergleich für LLM-Inferenz.

Sicht- und Bildprüfung in der Fertigung

Kurze Antwort: Das gehört nicht auf Ihren KI-Server.

Sichtprüfung ist kein LLM-Workload. Die Modelle sind Detektoren und Segmentierungsnetze mit einigen Millionen Parametern statt Milliarden — VRAM-Bedarf zwei bis vier Gigabyte, und damit praktisch irrelevant für die Kaufentscheidung. Was zählt, ist etwas völlig anderes: deterministische Latenz und physische Nähe zur Kamera.

Ein Inline-Prüfsystem an einer Linie mit 800 Millisekunden Takt und drei Kameras hat pro Bild rund 260 Millisekunden Budget — inklusive Bildaufnahme, Übertragung, Inferenz und Rückmeldung an die SPS. Das klingt nach reichlich, und im Mittelwert ist es das auch. Der Haken ist die Streuung. Ein 5-Megapixel-Graustufenbild sind rund 5 MB; über eine dedizierte GigE-Vision-Strecke ist das in etwa 40 Millisekunden übertragen, über einen geteilten Werksswitch unter Last aber auch mal in 200. Diese Schwankung kontrollieren Sie nicht, und sie kommt genau dann, wenn im Werk sonst noch etwas los ist.

Eine Sichtprüfung, die in 95 Prozent der Fälle rechtzeitig antwortet, ist keine Sichtprüfung: Bei 800 Millisekunden Takt sind das 4.500 Teile pro Stunde, also 225 Teile stündlich ohne gültiges Prüfergebnis. Die gehen entweder ungeprüft durch oder lösen einen Linienstopp aus. Beides ist teurer als die Edge-Box.

Auf der Edge fällt der Netzwerkweg weg. Ein kompakter Detektor auf einer Jetson-Orin-Klasse liegt bei zweistelligen Millisekunden — entscheidend ist nicht, dass das schneller ist, sondern dass es immer gleich schnell ist.

Zeitbudget pro Bild = Taktzeit / Anzahl Kameras
Bewerten Sie das 99,9-Perzentil, nicht den Mittelwert.
Wenn das Netz zwischen Linie und Server geteilt wird
oder das Budget unter 100 ms liegt
→ Edge-Box an der Linie, nicht der zentrale Server.

Beispielkonfiguration: Pro Linie eine Industrie-Edge-Box der Jetson-Orin-Klasse oder ein IPC mit kleiner GPU, staubdicht und ohne bewegliche Teile. Größenordnung €3.000 bis €6.000 pro Prüfstation. Der zentrale KI-Server kommt hier nur für Modelltraining und Bildarchivierung ins Spiel — separates Budget. Mehr zum Umfeld im Branchen-Hub Produktion.

Der Fehler, der am meisten Geld kostet

In den Anfragen, die bei uns landen, ist fast immer nach dem größten Modell dimensioniert, das sich jemand vorstellen konnte — und fast nie nach der Zahl gleichzeitiger Nutzer. Das klingt nach Vorsicht und ist das Gegenteil davon. Hier die Rechnung.

Nehmen Sie eine 48-GB-Karte — der Preis ist in beiden Varianten identisch, es geht ausschließlich um die Modellwahl.

Variante A, 70B in Q4: Die Gewichte belegen rund 42 GB. Bleiben etwa 5 GB für den KV-Cache. Ein 70B-Modell der Llama-3.3-Klasse hat 80 Layer, 8 KV-Heads und Head-Dimension 128, in FP16 also 0,3125 MiB pro Token. 5 GiB geteilt durch 0,3125 MiB ergibt 16.384 Token insgesamt. Bei 8.000 Token Kontext pro Anfrage sind das zwei gleichzeitige Sessions. Die dritte wartet.

Variante B, 24B in Q4: Gewichte rund 14 GB, bleiben 34 GB für den Cache. Ein Modell der Mistral-Small-Klasse hat 40 Layer, 8 KV-Heads, Dimension 128 — 0,156 MiB pro Token. 34 GiB ergeben rund 223.000 Token, bei 8.000 Token Kontext also 27 gleichzeitige Sessions.

Faktor 13 bei identischer Hardware. Und der Qualitätsunterschied zwischen einem guten 24B- und einem 70B-Modell ist bei Aufgaben wie Dokumentensuche, Zusammenfassung und interner Auskunft deutlich kleiner, als die Parameterzahl suggeriert. Bei RAG ist er meist gar nicht messbar.

Wer trotzdem auf 70B besteht, zahlt zweimal: einmal für die größere Karte, die er dann doch braucht, und einmal in Wartezeiten.

Die Preislage macht das 2026 besonders schmerzhaft. Eine RTX 5090 startete im Januar 2025 mit einer UVP von €2.329 und liegt im Juli 2026 im deutschen Handel im Schnitt bei rund €3.800, mit Angeboten zwischen €3.400 und €4.600. Die RTX PRO 6000 Blackwell mit 96 GB beginnt bei rund €12.790. Ursache ist die Speicherknappheit — laut IDC entfallen inzwischen über 80 Prozent der Materialkosten einer Grafikkarte auf den VRAM.

Für die Sizing-Entscheidung heißt das: Der Aufpreis für "eine Nummer größer, sicherheitshalber" ist 2026 deutlich teurer als 2024. Die Modellwahl ist der billigere Hebel als der Kartenkauf — und im Zweifel der einzige, den Sie kurzfristig noch drehen können.

Entscheidungstabelle

Zwei Dinge fehlen in dieser Tabelle bewusst. Erstens Strom: Eine Karte im Dauerbetrieb kostet bei €0,30/kWh und 300 W Dauerlast rund €790 im Jahr, die Details stehen in der Stromkosten-Rechnung für KI-Server. Zweitens die Frage, ob Sie überhaupt eigene Hardware brauchen. Unsere Faustregel dazu, und sie ist unbeliebt: Wenn die Karte weniger als ein Fünftel des Tages tatsächlich rechnet, zahlen Sie beim Kauf für Stillstand. Genau der Fall ist der OCR-Nachtlauf oben. Kaufen lohnt erst, wenn mehrere Anwendungen dieselbe Karte über den Tag verteilt auslasten — oder wenn die Daten das Haus rechtlich nicht verlassen dürfen. Das zweite Argument ist im Mittelstand übrigens häufiger das ausschlaggebende als das erste.

FAQ

Wie viel VRAM braucht ein Server für KI-Anwendungen im Mittelstand?

Für die meisten Anwendungen reichen 24 bis 48 GB VRAM. Ein RAG-System über eine Dokumentenablage läuft auf 24 GB, ein interner Chat-Assistent für 100 bis 300 Mitarbeiter auf 48 GB mit einem 24B-Modell. Mehr VRAM brauchen nur Code-Assistenz mit langen Kontextfenstern und Setups, die zwingend 70B-Modelle fahren müssen.

Was kostet ein KI-Server für ein RAG-System?

Ein komplettes System mit 24-GB-Karte, 64 GB RAM und 2 TB NVMe liegt bei €4.000 bis €6.000 (Stand Q3 2026). Dazu kommen rund €500 bis €800 Stromkosten pro Jahr bei durchgehendem Betrieb und deutschen Gewerbestrompreisen. Die Vektordatenbank verursacht keine zusätzlichen Lizenzkosten, wenn Sie eine Open-Source-Lösung einsetzen.

Ollama oder vLLM — was ist besser für mehrere gleichzeitige Nutzer?

vLLM, deutlich. Bei einem einzelnen Nutzer sind beide etwa gleich schnell, aber unter Last trennt sich das: Bei zehn parallelen Anfragen liefert vLLM durch Continuous Batching rund die dreifache Gesamtdurchsatzrate, bei 50 Nutzern das Fünf- bis Sechsfache. Ollama ist einfacher aufzusetzen und deshalb für Pilotprojekte die bessere Wahl.

Braucht die Vektordatenbank eine eigene GPU?

Nein. Der Vektorindex liegt im System-RAM, die Ähnlichkeitssuche läuft auf der CPU. Rechnen Sie mit rund 1,5-fachem Overhead auf die reinen Vektordaten: Eine Million Chunks bei 1.024 Dimensionen belegt etwa 6 GB RAM. Nur die Erzeugung der Embeddings beim Erstindexieren profitiert von einer GPU, und das ist ein einmaliger Job.

Kann ein Server mehrere KI-Anwendungen gleichzeitig bedienen?

Ja, aber nicht beliebig. RAG, Chat und OCR lassen sich auf einer Maschine kombinieren, wenn Sie den OCR-Batch in die Nacht legen und der VRAM für beide Modelle gleichzeitig reicht. Sichtprüfung in der Fertigung gehört dagegen auf eigene Edge-Hardware an der Linie, weil die Latenzanforderung im Millisekundenbereich liegt.

Fazit und nächster Schritt

Fangen Sie bei der Anwendung an, nicht beim Modell. Notieren Sie drei Zahlen: gleichzeitige Nutzer, Kontextlänge pro Anfrage, geforderte Antwortzeit. Die bestimmen Ihre Hardware zuverlässiger als jede VRAM-Tabelle.

Und wenn Sie die drei Zahlen haben: Die Hardware ist selten der größte Posten im Projekt. Was rundherum anfällt — Anbindung, Datenaufbereitung, Betrieb — schätzen Sie im KI-Kosten-Kalkulator ab.