LLM VRAM-Rechner für Selbsthosting
Einen LLM selbst zu hosten bedeutet, die Inferenz auf Hardware auszuführen, die der Betreiber kontrolliert, anstatt über eine API eines Drittanbieters, was die Kosten, die Datenkontrolle und das Datenschutzprofil verändert. Ob ein Modell überhaupt läuft, hängt vom Speicher ab.
LLM Kompatibilitätsrechner
Der Rechner schätzt den benötigten VRAM oder vereinheitlichten Speicher, um ein Modell lokal auszuführen, basierend auf dem Modell, seiner Genauigkeit, der Kontextlänge und der Zielhardware. Er gibt an, ob eine Konfiguration passt, die Speicheraufteilung auf Gewichte, KV-Cache und Overhead sowie die Modelle, die eine bestimmte GPU oder ein Mac ausführen kann. Die Quantisierungsformate und Präzisionsbreiten entsprechen der Hugging Face Transformers-Dokumentation. 1
Siehe unsere Methodik zur VRAM-Berechnung für selbstgehostete LLMs für die vollständige mathematische Grundlage dieser Schätzungen.
Hardware für das Selbsthosting: GPUs und Apple Silicon
Zwei Zahlen entscheiden über die Hardware. Die Kapazität ist das Tor zur Eignung, und die Dekodierung ist speicherbandbreitenbegrenzt, sodass Tokens pro Sekunde etwa mit der GB/s einer Karte skalieren.
Die obigen Zeilen zeigen Stichproben aus jeder Stufe. Der Rechner umfasst insgesamt 34 Karten und ergänzt die A100, L40S, RTX A6000, AMD Radeon RX 7900 XTX und die AMD Instinct-Reihe. Mit 24 bis 32 GB benötigt ein 70B-Modell starke Quantisierung plus kurzen Kontext oder zwei Karten. Ein 671B-Modell benötigt 640 GB (8×80 GB) als Standardminimum. Die RTX PRO 6000 ist die stärkste Workstation-Einzelkarte, und ihr Straßenpreis stieg bis Mitte 2026 auf etwa $13.000 bei einem UVP von $8.565.2
Apple Silicon und vereinheitlichter Speicher: Auf Apple Silicon teilen sich CPU und GPU einen gemeinsamen Speicherpool, und die GPU adressiert standardmäßig etwa 75% des gesamten RAM über Metal’s recommendedMaxWorkingSetSize, bei kleineren Macs etwas weniger. Die Obergrenze kann mit sudo sysctl iogpu.wired_limit_mb= erhöht werden, wobei 8 bis 16 GB für macOS reserviert bleiben. 3 4 Ein Mac mit 128 GB stellt der GPU etwa 96 GB zur Verfügung. Der M3 Ultra mit bis zu 512 GB stellt etwa 384 GB bereit, genug für ein Modell der 400B-Klasse mit 4-Bit und KV-Spielraum auf einem einzigen Gerät ohne die Steuer der Multi-GPU-Replikation. 5 Dieser Weg auf einem einzigen Gerät für große Modelle ist der Vorteil von Apple, obwohl AMD Strix Halo (128 GB) und NVIDIA DGX Spark (128 GB) jetzt ebenfalls günstige große vereinheitlichte Speicher bieten. 6
LLM-Serving-Engines
Die Wahl der Serving-Engine richtet sich nach der Arbeitslast und nicht nach einem einzigen besten Werkzeug. Produktions-Serving-Engines verwenden Paged Attention und kontinuierliches Batching für viele gleichzeitige Nutzer auf Rechenzentrums-GPUs, während lokal ausgezeichnete Laufzeitumgebungen auf einzelne Nutzer auf einem Desktop, Laptop oder einer einzelnen GPU abzielen. Der Unterschied zeigt sich unter Last. Bei 64 gleichzeitigen Anfragen lieferte vLLM etwa 44-mal mehr Tokens pro Sekunde als llama.cpp, dessen Time-to-First-Token auf über 3 Minuten anstieg. Für einen einzelnen Nutzer sind die beiden vergleichbar. 7
Der Rechner modelliert acht Engines in den beiden Lagern:
Innerhalb der Produktionsstufe verwendet SGLangs RadixAttention anfragenübergreifende Präfixe wieder, TensorRT-LLM friert sein Aktivierungsbudget beim Bauen der Engine ein, und LMDeploy bedient W4A16 und MXFP4 kosteneffizient für InternLM, Qwen und DeepSeek. 8 Auf der lokalen Seite wählt ExLlamaV2 mit TabbyAPI eine fraktionale durchschnittliche Bit-Breite, um eine Karte genau zu füllen, und MLX nutzt den vereinheitlichten Speicher von Apple, sodass der gesamte RAM das Budget ist. Hugging Face TGI ist der einzige Aussteiger. Es wurde im Dezember 2025 in den Wartungsmodus versetzt und sein GitHub-Repository am 21. März 2026 archiviert (schreibgeschützt), wobei Nutzer auf vLLM, SGLang und llama.cpp verwiesen wurden. 9 10
Die meisten Menschen begegnen diesen Engines über Endbenutzer-Apps, die sie einbinden. Ollama, LM Studio und AnythingLLM laufen alle auf llama.cpp (LM Studio auch auf MLX) und bieten Modelle mit einem Befehl, eine zu OpenAI kompatible localhost-API und, im Fall von AnythingLLM, Dokumenten-RAG über PDFs und Codebasen. Als grober Adoptionsindikator anhand der GitHub-Sterne am 07.11.2026 hatte Ollama 175.925 und vLLM 85.979, beide Open Source, und AnythingLLM 63.120. Die 5.053 von LM Studio stammen aus dem Open-Source-CLI-Repo (lmstudio-ai/lms) und nicht aus der proprietären App, sodass sie die tatsächliche Desktop-Nutzung untertreiben. 11 12 13 14
Eine interaktive Landschaftskomponente ordnet diese Werkzeuge den Anwendungsfällen zu. Integrationen und breite Kompatibilität gehen an Ollama, Entwickler und hohe Leistung an vLLM, lokale RAG-Anwendungen an AnythingLLM und einsteigerfreundliches Experimentieren an LM Studio.
Open-Source-Modelle für große Sprachmodelle
Open-Weight-Modelle veröffentlichen ihre Architektur und Gewichtungsdateien, sodass jeder sie herunterladen, modifizieren und ausführen kann, normalerweise von Hugging Face. Die selbst hostbare Grenze hat sich Mitte 2026 weit über die Ära von Qwen2.5 und Llama-3 hinausbewegt:
Die Spalten „Gesamt“ und „Aktiv“ sind die tragende Unterscheidung. Die Gesamtparameter bestimmen den Speicher und die Anzahl der GPUs, und die aktiven Parameter bestimmen die Rechenlast. DeepSeek-V4-Flash und GLM-5.2 kamen 2026 als Open Weights heraus, Gemma 4 lizenzierte die Familie unter Apache 2.0 neu, und GPT-OSS liefert MoE-Experten in nativem MXFP4. 15 16 17 18 19
Proprietäre Flaggschiffmodelle (OpenAIs GPT-5.6, Googles Gemini 3.1 Pro, Anthropics Claude Opus 4.8, xAIs Grok 4.5) können nicht heruntergeladen oder selbst gehostet werden; sie sind nur über APIs verfügbar, normalerweise hinter einem zu OpenAI kompatiblen Endpunkt. Eine reine lokale Bereitstellung verzichtet auf das, was diese Modelle bei einer bestimmten Aufgabe besser machen. 20 21 22
Quantisierung und MoE-Dimensionierung
Quantisierung bedeutet 2026 weniger das Runden von Gewichten nach dem Training als vielmehr Checkpoints, die standardmäßig mit niedriger Bit-Breite ausgeliefert werden, zusammen mit Architekturentscheidungen, die den Cache bereits vor der Quantisierung verkleinern.
Native Checkpoints mit niedriger Bit-Breite: Führende offene Modelle werden zunehmend quantisierungsbewusst ausgeliefert. GPT-OSS liefert seine MoE-Experten in MXFP4 (E2M1 mit gemeinsamem 8-Bit-Skalierungsfaktor, 4.25 Bits pro Parameter), sodass das 120B-Modell in etwa 63 GB passt, eine 80 GB GPU, während eine naive BF16-Schätzung etwa 234 GB auf drei GPUs erfordern würde. DeepSeek-V3 und R1 werden nativ in FP8 mit etwa 1 Byte pro Parameter ausgeliefert. Die Gewichte sollten anhand des tatsächlichen Dtyps des Checkpoints bemessen werden, nicht anhand der Parameteranzahl. 23 24
Die GGUF-Falle mit effektiven Bits: GGUF-Dateien mischen Präzisionen, mit FP16-Skalierungsfaktoren pro Block und unquantisierten Einbettungs- und Ausgabe-Tensoren, sodass der Name eine Untergrenze und nicht die tatsächliche Größe darstellt. Q4_K_M entspricht etwa 4.9 effektiven Bits (0.61 Bytes pro Parameter), nicht 4.0. Q8_0 sind 8.5 Bits (1.06 Bytes pro Parameter), nicht 8.0. Ein Rechner, der auf der Bit-Anzahl basiert, unterschätzt die Gewichte bei Q4 um etwa 20% und bei Q8 um etwa 6%. IQ-Quants wie IQ4_XS (etwa 4.25 Bits) erreichen jetzt die Qualität von Q4_K_M bei geringerer Größe. 25
KV-Cache-Quantisierung: Die Reduzierung des KV-Dtyps skaliert den gesamten Cache linear und ist unabhängig von der Gewichtspräzision. FP8 (e4m3) halbiert ihn (Llama-3-8B bei 128k, Batch 1, von 16.0 GiB BF16 auf 8.0 GiB FP8) bei weitgehend kostenloser Qualität. INT4 viertelt ihn, erfordert jedoch eine Evaluierung. In vLLM ist es ein Flag (--kv-cache-dtype fp8). 26
Attention als Speichersparer: Multi-head Latent Attention (MLA, verwendet von DeepSeek) speichert einen einzigen gemeinsam genutzten niedrigrangigen latenten Vektor (etwa 576 Elemente pro Token und Schicht) anstelle von Schlüsseln und Werten pro Kopf, ungefähr 30-mal kleiner als die nominale Leseoperation mit 128 Köpfen. Das ermöglicht es einem 671B-Modell, einen 128k-Kontext mit etwa 8.6 GiB KV zu bedienen. Sliding-Window- und Local-Global-Attention (Gemma 2 und 3, GPT-OSS, Llama 4) begrenzen die meisten Schichten auf ein festes Fenster anstelle des vollen Kontexts und reduzieren den KV bei langen Kontexten um das 10- bis 40-fache gegenüber einer naiven Schätzung mit globaler Attention. Diese sind pro Architekturfamilie festgelegt und keine einstellbaren Parameter. 27
Auslagerung und Sharding: Wenn die Gewichte den GPU-Speicher übersteigen, verschiebt das Auslagern inaktive Teile, wie ungenutzte MoE-Experten, zwischen GPU-Speicher und langsameren System-RAM, wobei Tokens pro Sekunde gegen die Fähigkeit, überhaupt laufen zu können, eingetauscht werden. 28 Sharding teilt ein Modell auf mehrere Geräte oder Speicherstufen auf, wodurch ein 671B-Modell über einen 8-GPU-Knoten verteilt werden kann. Beide erweitern die Reichweite fester Hardware auf Kosten der Bandbreite.
Vorteile und Abwägungen des Selbsthostings
Die Argumente für Selbsthosting sind Datenkontrolle, Kosten bei hohem Volumen und Konfigurationsfreiheit. Die Argumente dagegen sind Hardwarekosten, Betriebsaufwand und die Lücke zu proprietären Modellen.
Datenresidenz und Compliance: Grenzüberschreitende Datenübertragung ist der Compliance-Treiber. Nach der DSGVO kann das Senden personenbezogener Daten außerhalb der EU rechtliche Sicherungsmaßnahmen, vertragliche Verpflichtungen oder Einschränkungen auslösen. Der EU KI Act fügt eine zweite Ebene hinzu, befindet sich jedoch eher in der Einführungsphase als vollständig in Kraft. Mitte 2026 gelten bereits die Verbote (anwendbar seit dem 2. Februar 2025) und die Verpflichtungen für Allzweck-KI-Modelle (GPAI) (seit dem 2. August 2025), während die Hochrisikoanforderungen rund um Risikomanagement, Prüfbarkeit und Governance verschoben sind, und zwar auf den 2. Dezember 2027 für eigenständige Hochrisikosysteme nach Anhang III und den 2. August 2028 für eingebettete Systeme nach Anhang I im Rahmen des Digital-Omnibus-Pakets 2025-26. 29 30 31 Die Ausführung von Inferenz im eigenen Rechtsraum, in einem kontrollierten Netzwerk, hält sensible Daten aus den Händen Dritter, was das Argument der souveränen KI für Finanzwesen, Gesundheitswesen und den öffentlichen Sektor darstellt.
Kosten und Kontrolle: Selbsthosting beginnt teuer, mit Consumer-GPUs oder einem kleinen Server, aber lokale Inferenz kann wiederkehrende API-Gebühren für Teams mit hohem Anfragevolumen unterbieten. Es beseitigt auch die Abhängigkeit von Anbietern und auferlegte Beschränkungen für das Kontextfenster, Inferenzeinstellungen und die Integration und ermöglicht den direkten Zugriff auf die Gewichte für das Feintuning mit privaten Daten.
Die Kompromisse: GPU-Speicher ist die begrenzende Größe, und einige Arbeitslasten benötigen weiterhin 16 bis 48 GB VRAM, was für kleinere Teams unerreichbar ist. Die Bereitstellung bringt Abhängigkeitsmanagement, CUDA- und Kernel-Fehlerbehebung, Überwachung und Aktualisierungen mit sich, die sonst ein Cloud-Anbieter übernehmen würde. Die Leistung liegt in der Verantwortung des Betreibers, vom Batching und Sharding bis zur Hardwareauslastung. Und die stärksten proprietären Modelle bleiben nur über die API verfügbar, sodass eine lokale Bereitstellung eine Leistungslücke bei den Aufgaben akzeptiert, bei denen sie führend sind.
Als bevorzugte Quelle hinzufügenMethodik zur VRAM-Berechnung für selbstgehostete LLMs
Der Speicherbedarf eines Modells ist die Summe von vier Termen, die unabhängig voneinander berechnet und addiert werden, und nicht ein einzelner Wert, der anhand der Parameteranzahl skaliert wird:
VRAM_total = Weights + KV cache + Activations + Overhead
Der häufigste Schätzfehler fasst die letzten drei Terme zu einem pauschalen 20%-Aufschlag auf die Gewichte zusammen. Das ist bei einer Modellgröße annähernd richtig und bei den anderen falsch, da die drei Terme unterschiedlich skalieren. 32
Gewichte: Der Gewichtsspeicher entspricht Parameter mal Bytes pro Parameter. BF16 und FP16 speichern 2.0 Bytes pro Parameter, FP8 und INT8 etwa 1.0. Die Falle ist 4-Bit, was nicht 0.5 Bytes pro Parameter entspricht. Echtes gruppiertes INT4 (GPTQ, AWQ) liegt bei 0.52 bis 0.55, und GGUF Q4_K_M bei etwa 0.61 Bytes pro Parameter (4.9 effektive Bits, nicht 4.0). GGUF Q8_0 hat 8.5 Bits (1.06 Bytes pro Parameter), nicht 8.0. Die Annahme von 0.5 unterschätzt ein 70B-Modell um etwa 8 GB, was das Urteil über die Passung umkehrt. 33
Mixture-of-Experts bemisst jeden Experten, nicht die aktiven: Alle Expertengewichte bleiben im VRAM, auch wenn nur wenige pro Token aktiviert werden. Mixtral-8x7B benötigt etwa 28 GB bei Q4 für die gesamten 46.7B Parameter, nicht für die 13B aktiven. Die Gesamtparameter bestimmen den Speicher und die Anzahl der GPUs, die aktiven Parameter die Rechenlast. Ein Rechner, der auf aktiven Parametern basiert, lässt große MoE-Modelle fälschlicherweise passen.
KV-Cache: Der Key-Value-Cache ist 2 x n_layers x n_kv_heads x head_dim x seq_len x batch x bytes_per_element. Die meisten aktuellen Modelle verwenden Grouped-Query-Attention (GQA), bei der viele Query-Köpfe wenige KV-Köpfe teilen, sodass n_kv_heads-Paare zwischengespeichert werden, was den Cache um das 4-Fache (Llama-3-8B) bis 8-Fache (Llama-3-70B) im Vergleich zur vollen Multi-Head-Attention schrumpft. Sowohl head_dim als auch n_kv_heads werden aus der config.json jedes Modells gelesen und nicht aus der Hidden-Size und Head-Anzahl abgeleitet, da Familien wie Gemma (head_dim 256) und Qwen3 (128) sonst etwa um den Faktor 2 falsch bemessen würden. Der Cache wächst linear mit der Kontextlänge und der Batch-Größe und konkurriert bei langen Kontexten mit den Gewichten oder übersteigt sie. Llama-3-8B speichert 128 KiB pro Token zwischen, sodass bei 128k Kontext und Batch 1 der FP16-KV-Cache 16.0 GiB beträgt, was den 16 GB BF16-Gewichten entspricht. Ein FP8-KV-Cache halbiert das. 34
Overhead ist eine Grundgebühr, kein Prozentsatz: Der Framework-Overhead ist ein fester Sockel pro GPU (CUDA-Kontext und Kernel, etwa 1 bis 2 GB pro GPU) plus einen kleinen begrenzten Bruchteil, nicht ein Anteil der Gewichte. Ein pauschaler Wert von 20% unterschätzt kleine Modelle, bei denen allein der CUDA-Kontext 20% eines 6-GB-Modells übersteigen kann, und überschätzt große, bei denen ein 140-GB-Modell nicht 28 GB Kontext benötigt. Der stückweise Sockel ist das akkurate Modell, und pauschale 20% funktionieren als schnelle Schätzung. 35
Aktivierungen und die Serving-Engine: Der Aktivierungsterm ist transient. Während der Dekodierung, ein Token nach dem anderen, ist er klein und geht in den Overhead-Sockel ein, aber das Prefill verarbeitet den gesamten Prompt auf einmal, sodass seine Aktivierungsspitze mit der Batch-Größe und der Prompt-Länge skaliert. Der Sockel selbst hängt von der Engine ab. Paged-Server (vLLM, SGLang) reservieren einen festen Anteil jeder Karte über eine Speicherauslastungseinstellung, etwa 10% beim Standardwert von 0.90, und passen die Gewichte und den KV-Cache in den Rest. Nicht-paginierte Laufzeitumgebungen (llama.cpp, Ollama) halten stattdessen einen festen Rechenpuffer von etwa 1 bis 2 GB vor. Beide gleich zu bemessen, liegt um einige GB daneben.
Mehrere GPUs teilen sich nicht sauber auf: Zwei 24-GB-Karten sind nicht 48 GB nutzbarer Speicher. Unter Tensorparallelität werden die Gewichte und der KV-Cache auf die N Karten aufgeteilt (W/N und KV/N), aber die Aktivierungen, der CUDA-Kontext und die NCCL-Kommunikationspuffer werden auf jeder Karte repliziert, sodass der summierte Footprint größer ist als eine Einzelgeräteschätzung derselben Summe. Dieser Replikationssteuer ist der Grund, warum ein 70B-Modell, das 43 GB Gewichte benötigt, auf zwei 24-GB-Karten mit kurzem Kontext passt, und warum der sichere Check die pro-GPU-Summe ist und nicht die Gesamtsumme geteilt durch die GPU-Anzahl.
Die vier Terme interagieren an der Passgenauigkeitsgrenze. Eine Konfiguration wird als „Passt“ bewertet, wenn der benötigte Speicher bei oder unter 90% des Nutzbaren liegt, „Knapp“ in den oberen 10% der Kapazität und „Passt nicht“ über dem Nutzbaren. Paged-Server halten diese 10% bereits über die Auslastungseinstellung zurück. Die folgenden Beispiele verwenden Llama-3 auf gängiger Hardware, mit llama.cpp auf den Consumer-Karten:
Bei 128k Kontext entspricht der KV-Cache den Gewichten, sodass die Kontextlänge und nicht die Parameteranzahl über die Passung entscheidet. Die letzte Zeile passt, weil die Q4-Gewichte (~405 GB) bei 8k Kontext unter 640 GB liegen. Der Vorteil von MLA liegt bei langem Kontext, wo es den KV-Cache eines 671B-Modells klein genug hält, um 128k zu bedienen.
Weiterführende Literatur
- LLM-Quantisierung: BF16 vs FP8 vs INT4
- LLM-Inferenz-Engines: vLLM vs LMDeploy vs SGLang
- GPU-Parallelitäts-Benchmark: H100 vs H200 vs B200 vs MI300X
- Multi-GPU-Benchmark: B200 vs H200 vs H100 vs MI300X
- Top 60+ Cloud-GPU-Anbieter
- Cloud-LLM vs lokale LLMs
- LLM-Preisgestaltung: Top 15+ Anbieter im Vergleich
- LLM-Feintuning-Leitfaden für Unternehmen
FAQs
Ein selbstgehosteter LLM ist ein großes Sprachmodell, das für LLM-Anwendungen verwendet wird und vollständig auf von Ihnen kontrollierter Hardware (z. B. Ihrem PC oder privaten Server) läuft, anstatt auf einen Cloud-Dienst eines Drittanbieters angewiesen zu sein.
Zu den Techniken gehören Frameworks wie llama.cpp, Bibliotheken wie Hugging Face Transformers, benutzerfreundliche Apps (Ollama, LM Studio), Modellquantisierung (z. B. GGUF, GPTQ) zur Reduzierung des Ressourcenbedarfs, Modellparallelität zur Verteilung großer Modelle auf mehrere Geräte und optimierte Inferenz-Engines (wie vLLM).
Ja, Tools wie vLLM, Ollama und LM Studio können lokale Server betreiben, die mehrere (oft gleichzeitige) Anfragen verarbeiten können. Dies ähnelt dem Betrieb von Cloud-APIs, die häufig Batching zur Effizienzsteigerung verwenden.
Nein, Sie benötigen keine externe Zugriffsberechtigung oder API-Schlüssel eines Anbieters für selbstgehostete LLMs. Da Sie es selbst hosten, haben Sie direkten Zugriff; optional können Sie bei Bedarf eine eigene Authentifizierung für Ihren lokalen Server einrichten.
Diese Forschung zitieren
Wählen Sie das Format, das zu Ihrem Veröffentlichungsort passt. Wenn Sie die Link-Version in Ihr CMS einfügen, bleibt der Backlink erhalten.
@misc{sari2026,
author = {Sarı, Ekrem},
title = {{LLM VRAM-Rechner für Selbsthosting}},
year = {2026},
month = jul,
howpublished = {\url{https://aimultiple.com/self-hosted-llm}},
note = {AIMultiple. Abgerufen am 12. Juli 2026}
}Referenzlinks
Seien Sie der Erste, der kommentiert
Ihre E-Mail-Adresse wird nicht veröffentlicht. Alle Felder sind erforderlich. Kommentare werden in ihrer Originalsprache belassen.