Die Hardware-Dimensionierung für On-Premises-Inferenz ist der Punkt, an dem Programme für private KI am häufigsten auf eine Weise danebengreifen, deren Korrektur teuer wird. Der Fehler ist selten, zu wenig zu kaufen. Er besteht darin, eine Konfiguration nach einer Benchmark-Schlagzeile statt nach dem Workload zu wählen und dann festzustellen, dass der Durchsatz bei produktiven Kontextlängen einbricht oder dass eine Karte mit beeindruckenden Rechenwerten von der Speicherbandbreite ausgehungert wird.
Die Dimensionierungslogik ist einfacher, als der GPU-Markt sie aussehen lässt. Zuerst müssen die Gewichte in den VRAM passen. Dann reservieren Sie zusätzlichen VRAM für KV-Cache, Aktivierungen und Runtime-Overhead. Eine brauchbare Schätzung sind Parameter mal Bytes je Parameter, plus 30 bis 50 Prozent für das Serving. INT4 sind grob 0,5 Bytes je Parameter, FP8 grob 1 Byte, FP16 grob 2. Alles Weitere in der Dimensionierungsdiskussion ist eine Verfeinerung dieser Rechnung.
Das zweite Prinzip wiegt genauso schwer und bekommt weniger Aufmerksamkeit: Die beste Karte ist nicht die mit der höchsten Rechenzahl, sondern die mit genug Speicherbandbreite und genug VRAM, um Ihr Modell und seinen KV-Cache bei Ihrer Nebenläufigkeit zu halten. Inferenz-Serving ist weit häufiger bandbreiten- als rechengebunden.
Die VRAM-Rechnung
Wenden Sie die Formel an, und das Bild wird schnell konkret.
| Modellgröße | FP8-Gewichte | INT4-Gewichte | Praktischer VRAM inkl. Serving-Overhead |
|---|---|---|---|
| 7B | ~7 GB | ~3,5 GB | 5–10 GB bei leichtem Serving, mehr bei langem Kontext |
| 13B | ~13 GB | ~6,5 GB | 9–20 GB |
| 34B | ~34 GB | ~17 GB | 25–50 GB |
| 70B | ~70 GB | ~35 GB | 45–100+ GB |
In der Praxis kommen zwei Korrekturen hinzu. Quantisierungsverfahren tragen je nach Ansatz rund 10 Prozent Metadaten-Overhead, betrachten Sie die Gewichtswerte also als Untergrenzen und nicht als Zielwerte. Und der KV-Cache wächst mit Kontextlänge und Batch-Größe, weshalb eine Konfiguration, die bei 4K Kontext sauber benchmarkt, bei 64K mit einem Dutzend gleichzeitiger Nutzer auseinanderfallen kann. Wenn Ihr Anwendungsfall Retrieval über lange Dokumente ist, dimensionieren Sie den KV-Cache bewusst, statt ihn den verbliebenen Spielraum aufsaugen zu lassen.
Eine GPU-Klasse wählen
Der Markt teilt sich in vier Bänder, und die meisten Unternehmen brauchen nur zwei davon.
- H200 und B200. Die Frontier-Klasse: große Modelle, hoher Durchsatz, Multi-GPU-Serving mit NVLink. Berichtete Werte nennen für 8-GPU-H200-Systeme rund 12.400 Token pro Sekunde auf Llama 4 Scout und 2.864 Token pro Sekunde auf DeepSeek V3 bei FP8, und ein Vergleich vom April 2026 sah den B200-Durchsatz bei bis zum 4,9-Fachen einer RTX PRO 6000. Diese Klasse rechtfertigt sich über Nebenläufigkeit und Modellgröße, nicht über Prestige.
- L40S, RTX 6000 Ada und RTX PRO 6000 Blackwell. Die ernsthafte Produktivklasse für einen Knoten. L40S und RTX 6000 Ada sind 48-GB-Karten mit starker Bandbreite und ohne NVLink, was ihre Skalierung innerhalb einer Maschine begrenzt, sie aber gut für Serving der 34B-Klasse und quantisierte größere Modelle geeignet macht. Die RTX PRO 6000 Blackwell ist inzwischen eine übliche Produktivwahl für einzelne GPUs. Für einen großen Teil interner Unternehmens-Workloads ist dieses Band die richtige Antwort, und die Frontier-Klasse wäre Überkauf.
- AMD MI325X und die weitere MI300-Familie. Die Alternative mit viel Speicher, wenn Sie AMDs Rechenökonomie wollen und die Softwarereife von ROCm gegenüber CUDA akzeptieren können. Der Tausch ist real: vLLM, TensorRT-LLM und FlashAttention sind auf NVIDIA am stärksten, kalkulieren Sie also Engineering-Zeit für Tuning und einen schmaleren Satz erprobter Pfade ein.
- Consumer-Karten, RTX 4090 und 5090. Wirklich nützlich für Entwicklungsumgebungen, Deployments kleiner Teams und quantisierte Modelle. Keine geteilte Produktivklasse, denn Kapazität und Bandbreite setzen der Nebenläufigkeit eine harte Grenze, lange bevor die Rechenleistung das tut.
Quantisierung ist der wichtigste Hebel
Quantisierung bewirkt für Ihr Hardwarebudget mehr als jede andere Einzelentscheidung. Ein 70B-Modell von FP16 auf INT4 zu bringen, senkt die Gewichte von rund 140 GB auf rund 35 GB, und das ist der Unterschied zwischen einem Multi-GPU-Knoten und einer einzelnen 80-GB-Karte mit Platz für den KV-Cache. Das ist kein marginaler Effizienzgewinn, es ändert, welche Bestellung Sie schreiben.
Der Trade-off muss gemessen und nicht unterstellt werden. FP8 erhält die Qualität meist gut und läuft schnell auf Hardware mit nativer Unterstützung, bei doppeltem Speicherbedarf gegenüber INT4. INT4 bringt den größten Spielraum, und dort wird der Qualitätsverlust aufgabenabhängig: Retrievalgestützte Antworten, Extraktion und Klassifizierung vertragen ihn im Allgemeinen gut, während mehrstufiges Reasoning und Codegenerierung empfindlicher reagieren. Bauen Sie ein kleines Evaluationsset aus Ihrem echten Workload, fahren Sie es in jeder Präzision, und lassen Sie die Ergebnisse entscheiden. Das ist ein halber Arbeitstag, der regelmäßig sechsstellige Hardwarebeträge spart.
Durchsatz schätzen, bevor Sie kaufen
Den Durchsatz treiben Speicherbandbreite, Batching, Kontextlänge und die Frage, ob das Modell vollständig in schnellen Speicher passt. Drei Faustregeln decken die meiste Planung ab.
- Passt das Modell bequem in den VRAM und ist der Kontext moderat, erwarten Sie Durchsatz nahe den veröffentlichten Werten der Kartenklasse.
- Liegen Sie nahe am Speicherlimit, bricht der Durchsatz stark ein, weil KV-Cache-Druck zu kleineren Batches oder Auslagerung zwingt, und der Einbruch verläuft nicht linear.
- Brauchen Sie hohe Nebenläufigkeit, priorisieren Sie Rechenzentrums-Karten mit HBM. Kapazität und Bandbreite dominieren die Serving-Performance, sobald sich mehrere Nutzer eine Karte teilen.
Die Planungszahl sind nicht die Spitzen-Token pro Sekunde. Es sind Token pro Sekunde bei Ihrer p95-Kontextlänge und Ihrer erwarteten Nebenläufigkeit, und das ist meist ein Bruchteil der Schlagzeile. Verlangen Sie von Anbietern Werte für Ihre Kontextlänge, und wenn Sie sie nicht bekommen, fahren Sie den Benchmark selbst auf gemieteter Kapazität, bevor Sie sich auf Hardware festlegen.
Klasse und Workload zusammenbringen
| Workload | Praktische Hardwareklasse |
|---|---|
| Prototyping, Edge, kleine Assistenten | Nur CPU oder Einsteiger-GPU, ausschließlich kleine Modelle und geringer Durchsatz |
| Interne Werkzeuge mit 7B–13B | GPUs mit 16–24 GB, besonders mit Quantisierung |
| Serving der 34B-Klasse | 48-GB-Karten wie L40S oder RTX 6000 Ada als komfortable Untergrenze |
| Serving der 70B-Klasse auf einem Knoten | Rechenzentrums-GPUs ab 80 GB, oder aggressive Quantisierung auf speicherstarken Karten |
| Frontier und Produktion mit vielen Nutzern | Klasse H200 oder B200, meist Multi-GPU mit NVLink |
CPU-Inferenz verdient in dieser Tabelle ihren Platz statt einer Abfuhr. Ollama und LM Studio unterstützen reine CPU-Ausführung, und Modelle wie Qwen3 0.6B oder Llama 3.2 1B laufen auf einem Laptop mit 8 GB RAM. Bei rund 2 bis 10 Token pro Sekunde ist das für interaktive Mehrbenutzerarbeit unbrauchbar und für nächtliche Batch-Klassifizierung von Dokumenten vollkommen angemessen, was einen größeren Anteil der echten Unternehmens-KI ausmacht, als die Rahmung als interaktiver Assistent nahelegt.
Wo Sie anfangen
Dimensionieren Sie aus gemessener Nachfrage, nicht aus dem größten Modell, das Sie eines Tages betreiben möchten. Nehmen Sie den vorgesehenen Workload, ermitteln Sie p95-Kontextlänge und Spitzen-Nebenläufigkeit, wählen Sie das kleinste Modell, das Ihre Qualitätsschwelle auf Ihrem eigenen Evaluationsset besteht, und wenden Sie dann die VRAM-Formel mit 40 Prozent Serving-Reserve an. Das ergibt eine Kartenklasse. Validieren Sie sie eine Woche lang auf gemieteter GPU-Kapazität vor dem Kauf, denn eine Woche Cloud-GPU-Zeit ist billig gegen ein falsch spezifiziertes Cluster.
Zwei praktische Anmerkungen zum Kauf selbst. Budgetieren Sie die umgebende Infrastruktur, denn GPU-Knoten brauchen passende Netzwerk- und Storage-Pfade, und eine unterversorgte Karte ist eine verschwendete Karte. Und lassen Sie Reserve für den Modellwechsel: Open-Weight-Releases bewegen sich schneller als Abschreibungspläne, und die gekaufte Konfiguration wird binnen eines Jahres ein anderes Modell bedienen. Karten mit mehr Speicher, als das heutige Modell braucht, altern erheblich besser als Karten, die exakt darauf zugeschnitten wurden.
Häufige Fragen
Wie viel VRAM brauchen wir für ein 70B-Modell?
In FP16 belegen allein die Gewichte rund 140 GB, das bedeutet mehrere 80-GB-GPUs. Bei INT4 sinken die Gewichte auf etwa 35 GB, womit auf einer einzelnen 80-GB-Karte nutzbarer Spielraum für KV-Cache und Runtime-Overhead bei moderaten Kontextlängen bleibt. Auf 48-GB-Karten ist ein 70B-Modell in INT4 knapp und nur machbar, wenn Sie Kontext, Batch-Größe oder ausgelagerten State begrenzen, was Durchsatz kostet. Kalkulieren Sie 30 bis 50 Prozent über der Gewichtsgröße für das Serving, und mehr, wenn lange Kontexte oder hohe Nebenläufigkeit geplant sind.
Schadet Quantisierung der Qualität so sehr, dass es zählt?
Das hängt von der Aufgabe ab, weshalb die Frage an Ihrem eigenen Workload beantwortet werden muss und nicht an einer Tabelle. FP8 erhält die Qualität in der Regel gut auf Hardware mit nativer Unterstützung und kostet etwa ein Byte je Parameter. INT4 halbiert das noch einmal und ist der Hebel, der ein Modell der 70B-Klasse auf eine einzelne Karte bringt; der Qualitätsverlust ist für Extraktion, Klassifizierung und retrievalgestützte Antworten meist akzeptabel und bei mehrstufigem Reasoning deutlicher sichtbar. Fahren Sie Ihr eigenes Evaluationsset in beiden Präzisionen, bevor Sie sich auf Hardware festlegen.
Wann reicht reine CPU-Inferenz tatsächlich?
Wenn das Modell klein ist, der Durchsatzbedarf gering und Latenz kein Teil des Nutzererlebnisses. Kleine Modelle im Bereich 0,6B bis 3B laufen auf einem modernen Laptop mit 8 GB RAM, und CPU-Inferenz liefert typischerweise etwa 2 bis 10 Token pro Sekunde gegenüber 30 bis 60 und mehr auf einer leistungsfähigen GPU. Das trägt für nächtliche Batch-Dokumentenverarbeitung, für ein internes Werkzeug mit geringem Volumen oder für Edge-Deployments, bei denen eine GPU nicht praktikabel ist. Es trägt nicht für irgendetwas Interaktives mit mehr als einer Handvoll gleichzeitiger Nutzer.