Die Fachbegriffe,
auf Deutsch erklärt.

VRAM (Grafikspeicher)

Der Speicher auf der Grafikkarte. Er entscheidet, wie groß ein Modell sein darf, das komplett auf der Karte läuft.

Ein Sprachmodell muss beim Rechnen vollständig im Speicher liegen. Passt es in den Grafikspeicher, rechnet die Grafikkarte allein und das Modell antwortet flüssig. Passt es nicht, muss ein Teil in den Arbeitsspeicher ausweichen, und dann wird es deutlich langsamer.

Als Faustregel brauchen die Gewichte eines Modells Parameter in Milliarden × Bit je Gewicht ÷ 8 Gigabyte. Ein Modell mit 70 Milliarden Parametern in 4 Bit kommt so auf rund 35 GB, dazu kommen einige Gigabyte für den Kontext. Hängt an der Karte ein Monitor, sind außerdem 1 bis 2 GB schon belegt, bevor das Modell startet.

Siehe auch: Unified Memory (gemeinsamer Speicher), Offloading (Auslagern), Speicherbandbreite

Quelle: llamaperf: VRAM requirements for local LLMs (abgerufen 24.10.2026)

Speicherbandbreite

Wie viele Gigabyte pro Sekunde zwischen Speicher und Rechenwerk fließen. Sie bestimmt vor allem, wie schnell ein Modell Text ausgibt.

Für jedes ausgegebene Token muss die Hardware einen großen Teil der Modellgewichte einmal aus dem Speicher lesen. Deshalb ist beim Schreiben der Antwort meist nicht die Rechenleistung der Engpass, sondern die Bandbreite. Eine grobe Obergrenze ist Bandbreite geteilt durch die Bytes, die je Token gelesen werden.

Das erklärt, warum eine Grafikkarte mit schnellem Speicher ein Modell oft schneller ausgibt als ein Rechner mit mehr, aber langsamerem Speicher. Beim Einlesen langer Eingaben zählt dagegen mehr die Rechenleistung.

Siehe auch: VRAM (Grafikspeicher), Unified Memory (gemeinsamer Speicher)

Quelle: llamaperf: Local model performance (abgerufen 24.10.2026)

Unified Memory (gemeinsamer Speicher)

Prozessor und Grafikeinheit teilen sich einen Speicher, wie bei Apple-Silicon-Macs oder AMDs Strix Halo. So passen große Modelle auf ein Gerät ohne große Grafikkarte.

Bei Macs mit Apple Silicon und bei APUs wie AMD Strix Halo gibt es keinen getrennten Grafikspeicher. Ein Gerät mit 128 GB kann deshalb Modelle laden, für die man sonst mehrere teure Grafikkarten bräuchte. Die Bandbreite liegt meist unter der einer großen Grafikkarte, große Modelle laufen also, aber langsamer.

Auf dem Mac bekommt die Grafikeinheit nicht den ganzen Speicher. Ab Werk sind es etwa zwei Drittel (bis 32 GB) bzw. drei Viertel (ab 36 GB). Bei einem Mac mit 64 GB bleiben so rund 48 GB für das Modell.

Siehe auch: Metal, Speicherbandbreite

Quelle: llamaperf: VRAM requirements for local LLMs (abgerufen 24.10.2026)

CUDA

Die Rechenplattform von NVIDIA. Fast jedes KI-Programm unterstützt sie zuerst, sie läuft aber nur auf NVIDIA-Karten.

Über CUDA greifen Programme auf die Rechenkerne von NVIDIA-Grafikkarten zu. Weil die Plattform seit vielen Jahren verbreitet ist, sind neue Funktionen und schnelle Formate meist zuerst für CUDA verfügbar. Das ist der Hauptgrund, warum NVIDIA-Karten bei lokaler KI die bequemste Wahl sind.

Wer auf AMD, Intel oder Apple setzt, nutzt stattdessen ROCm, SYCL, Vulkan oder Metal. llama.cpp unterstützt alle diese Wege, andere Programme wie ExLlama oder viele Server-Formate nur CUDA.

Siehe auch: ROCm, Vulkan

Quelle: llama.cpp auf GitHub (abgerufen 24.10.2026)

ROCm

AMDs offene Software-Plattform, um auf AMD-Grafikkarten zu rechnen. Das Gegenstück zu NVIDIAs CUDA, voll unterstützt vor allem unter Linux.

ROCm enthält Treiber, Compiler und Bibliotheken, damit KI-Programme AMD-Grafikkarten nutzen können. Die Programmierschnittstelle heißt HIP und ist CUDA bewusst ähnlich, so lassen sich viele CUDA-Programme mit wenig Aufwand übertragen. llama.cpp führt ROCm deshalb als Backend „HIP“.

Wichtig ist die Liste der unterstützten Karten. Unter Linux nennt AMD für ROCm 7.14 unter anderem die RX 7900 XTX, 7900 XT und 7800 XT, die RX 9070 XT und 9060 XT sowie die Radeon AI PRO R9700 und die Instinct-Beschleuniger. Die RX-6000-Reihe für Endkunden steht nicht darauf. Unterstützte Systeme sind unter anderem Ubuntu 24.04 und 22.04, Debian 12 und 13 und RHEL.

Unter Windows bietet AMD das HIP SDK. Die Liste ist dort schmaler und die Dokumentation läuft getrennt. Wer eine AMD-Karte unter Windows nutzen will, fährt mit dem Vulkan-Backend von llama.cpp oft einfacher. Vor dem Kauf einer AMD-Karte lohnt sich ein Blick in die aktuelle Liste bei AMD.

Siehe auch: CUDA, Vulkan, llama.cpp

Quelle: AMD ROCm: Systemvoraussetzungen Linux (abgerufen 24.10.2026) · AMD HIP SDK für Windows: Systemvoraussetzungen (abgerufen 24.10.2026) · llama.cpp auf GitHub (abgerufen 24.10.2026)

Vulkan

Eine herstellerübergreifende Grafik- und Rechenschnittstelle. llama.cpp nutzt sie, um auf fast jeder Grafikkarte zu laufen, auch ohne CUDA oder ROCm.

Vulkan stammt aus der Spielewelt und wird von AMD, NVIDIA und Intel unterstützt. Für lokale KI ist es der Weg, wenn es für die eigene Karte kein passendes ROCm gibt oder man sich die Einrichtung sparen will. Unter Windows mit AMD-Karte ist es oft die einfachste Lösung.

Ob Vulkan oder das herstellereigene Backend schneller ist, hängt von Karte, Treiber und Modell ab. Das sollte man auf der eigenen Hardware messen, statt sich auf Tabellen zu verlassen.

Siehe auch: ROCm, CUDA, llama.cpp

Quelle: llama.cpp auf GitHub (abgerufen 24.10.2026) · KoboldCpp auf GitHub (abgerufen 24.10.2026)

Metal

Apples Grafik- und Rechenschnittstelle. Darüber nutzen llama.cpp, Ollama und LM Studio die Grafikeinheit von Macs mit Apple Silicon.

Auf einem Mac mit M-Chip greifen KI-Programme über Metal auf die Grafikeinheit zu. Zusammen mit dem gemeinsamen Speicher macht das Macs zu einer beliebten Wahl für größere Modelle an einem einzelnen Arbeitsplatz. Apple hat dafür außerdem das eigene Framework MLX.

Siehe auch: Unified Memory (gemeinsamer Speicher), MLX

Quelle: llama.cpp auf GitHub (abgerufen 24.10.2026)

SYCL und oneAPI

Der Weg für Intel-Grafikkarten wie die Arc-Reihe. SYCL ist ein offener Standard, oneAPI Intels Umsetzung mit Treibern und Bibliotheken.

llama.cpp führt SYCL als Backend für Intel-Grafikkarten. Intels Arc-Karten bieten viel Grafikspeicher für ihren Preis, die Arc Pro B60 etwa 24 GB und die Arc Pro B70 32 GB. Die Software-Unterstützung ist jünger als bei NVIDIA und AMD, darum lohnt ein eigener Test vor einer größeren Anschaffung. Auch Vulkan läuft auf Intel-Karten.

Siehe auch: Vulkan, llama.cpp

Quelle: llama.cpp auf GitHub (abgerufen 24.10.2026) · llamaperf: GPUs (abgerufen 24.10.2026)

NVLink

Eine schnelle Direktverbindung zwischen NVIDIA-Grafikkarten. Für die meisten lokalen Aufbauten mit zwei Karten nicht nötig.

Wer ein Modell auf zwei oder mehr Grafikkarten verteilt, schickt Daten zwischen den Karten hin und her. NVLink macht das schneller als der normale PCIe-Steckplatz. Bei aktuellen Endkunden-Karten gibt es NVLink nicht mehr, bei Profi- und Rechenzentrumskarten schon. Für einen kleinen Server mit zwei Karten reicht PCIe meist aus, weil beim Ausgeben je Token nur wenig zwischen den Karten fließt.

Siehe auch: VRAM (Grafikspeicher)

Offloading (Auslagern)

Passt ein Modell nicht ganz in den Grafikspeicher, rechnet ein Teil im Arbeitsspeicher auf dem Prozessor. Es läuft dann, aber oft 5- bis 10-mal langsamer.

llama.cpp, Ollama und LM Studio können einzelne Schichten eines Modells in den Arbeitsspeicher legen. Das ist praktisch, um ein zu großes Modell überhaupt auszuprobieren. Für den täglichen Einsatz mit Wartezeiten wie bei einem Chat sollte das Modell aber vollständig in den Grafikspeicher passen. Sonst ist ein kleineres Modell oder eine stärkere Quantisierung die bessere Wahl.

Eine Ausnahme sind MoE-Modelle: Dort rechnet je Token nur ein Teil der Gewichte. Manche Programme legen gezielt die selten gebrauchten Teile in den Arbeitsspeicher und bleiben trotzdem brauchbar schnell.

Siehe auch: VRAM (Grafikspeicher), ik_llama.cpp, Strata

Quelle: llamaperf: VRAM requirements for local LLMs (abgerufen 24.10.2026)

llama.cpp

Das Grundlagenprogramm der lokalen KI, geschrieben in C/C++. Es läuft auf fast jeder Hardware und steckt in Ollama, LM Studio und KoboldCpp.

llama.cpp lädt Modelle im Format GGUF und rechnet auf Prozessor, NVIDIA (CUDA), AMD (HIP), Apple (Metal), Intel (SYCL) oder über Vulkan auf fast jeder Grafikkarte. Es bringt einen Server mit, der dieselbe Schnittstelle anbietet wie die OpenAI-API, sodass vorhandene Anwendungen ohne Umbau darauf zugreifen können. Lizenz: MIT.

Wer die volle Kontrolle über Einstellungen will oder ein neues Modell am ersten Tag ausprobieren möchte, nimmt llama.cpp direkt. Wer es bequem will, nimmt Ollama oder LM Studio, die auf llama.cpp aufbauen.

Siehe auch: Ollama, LM Studio, ik_llama.cpp, Vulkan

Quelle: llama.cpp auf GitHub (abgerufen 24.10.2026) · llamaperf: Engines (abgerufen 24.10.2026)

Ollama

Der einfachste Einstieg: installieren, ein Modell mit einem Befehl laden, fertig. Baut auf llama.cpp auf.

Ollama bringt ein eigenes Modellverzeichnis mit, aus dem man Modelle mit einem Befehl holt, und eine Schnittstelle für andere Programme. Zusammen mit einer Oberfläche wie Open WebUI entsteht so in kurzer Zeit ein Chat für ein kleines Team. Wir haben Ollama auf einem gewöhnlichen Server ohne Grafikkarte nachgemessen.

Für viele gleichzeitige Nutzer ist Ollama nicht gebaut. Dafür sind vLLM oder SGLang da.

Siehe auch: llama.cpp, vLLM

Quelle: llamaperf: Engines (abgerufen 24.10.2026)

LM Studio

Ein Desktop-Programm mit Chatfenster, Modellsuche und lokalem Server. Für einzelne Arbeitsplätze ohne Kommandozeile.

LM Studio richtet sich an Menschen, die keine Befehle tippen wollen: Modell suchen, herunterladen, chatten. Auf Macs nutzt es auch MLX. Für den Einsatz in der Firma sollte man vorher die Lizenzbedingungen für gewerbliche Nutzung lesen und festlegen, welche Modelle erlaubt sind.

Siehe auch: Ollama, MLX

Quelle: llamaperf: Engines (abgerufen 24.10.2026)

vLLM

Ein Server für viele gleichzeitige Anfragen. Die Wahl, wenn eine ganze Abteilung oder eine Anwendung ein Modell gemeinsam nutzt.

vLLM verwaltet den Speicher für den Kontext vieler Anfragen gleichzeitig sehr effizient (PagedAttention) und bündelt Anfragen laufend zu Stapeln. Dadurch schafft es auf derselben Grafikkarte ein Vielfaches an Gesamtdurchsatz gegenüber einem Programm, das Anfragen nacheinander abarbeitet. Es nutzt vor allem Formate wie AWQ, GPTQ, FP8 und die Originalgewichte, weniger GGUF.

Für einen einzelnen Nutzer ist vLLM meist mehr Aufwand als nötig. Ab etwa einer Handvoll gleichzeitiger Nutzer lohnt der Blick.

Siehe auch: SGLang, Ollama

Quelle: llamaperf: Engines (abgerufen 24.10.2026)

SGLang

Ein Server wie vLLM, ausgelegt auf viele Anfragen und auf Agenten, die oft dieselben Anfänge wiederholen. Offen unter Apache-2.0.

SGLang ist ein Open-Source-Framework für den Betrieb von Sprach-, Bild-Sprach- und Bildmodellen. Die Entwickler zielen ausdrücklich auf Agenten-Anwendungen und den Betrieb im großen Maßstab. Unterstützt werden unter anderem NVIDIA-Grafikkarten, AMD Instinct, Intel, Apple Silicon und Googles TPU. Getragen wird das Projekt von der gemeinnützigen Organisation LMSYS.

Ob vLLM oder SGLang schneller ist, hängt vom Modell und vom Anfragemuster ab. Wer einen Server für viele Nutzer plant, sollte beide mit den eigenen Anfragen testen.

Siehe auch: vLLM

Quelle: SGLang auf GitHub (abgerufen 24.10.2026) · llamaperf: Engines (abgerufen 24.10.2026)

MLX

Apples eigenes Framework für maschinelles Lernen auf Apple Silicon. Auf dem Mac oft die schnellste Wahl.

MLX nutzt den gemeinsamen Speicher und die Grafikeinheit von M-Chips direkt. Modelle liegen dafür in einem eigenen MLX-Format vor. Rund um MLX gibt es weitere Programme, etwa mlx-lm zum Ausführen von Sprachmodellen oder mlx-vlm für Modelle, die auch Bilder verstehen.

Siehe auch: Metal, Unified Memory (gemeinsamer Speicher)

Quelle: llamaperf: Engines (abgerufen 24.10.2026)

KoboldCpp

Eine einzelne Programmdatei auf Basis von llama.cpp, mit Weboberfläche und vielen kompatiblen Schnittstellen. Keine Installation nötig.

KoboldCpp startet aus einer Datei unter Windows, Linux oder macOS und bringt eine eigene Oberfläche mit. Es spricht unter anderem die Schnittstellen von OpenAI und Ollama. Für NVIDIA gibt es CUDA, für AMD empfehlen die Entwickler zunächst Vulkan. Lizenz: AGPL v3, das ist bei einer Weitergabe an Kunden zu beachten.

Siehe auch: llama.cpp, Vulkan

Quelle: KoboldCpp auf GitHub (abgerufen 24.10.2026)

text-generation-webui

Eine Weboberfläche, die mehrere Programme im Hintergrund nutzen kann. Beliebt zum Ausprobieren und Vergleichen.

Die Oberfläche bündelt verschiedene Ladeprogramme unter einem Dach, sodass man Modelle in unterschiedlichen Formaten an einer Stelle testen kann. Für den festen Betrieb in einer Firma sind Ollama mit Open WebUI oder ein Server wie vLLM meist übersichtlicher.

Siehe auch: llama.cpp, ExLlamaV2, ExLlamaV3 und TabbyAPI

ExLlamaV2, ExLlamaV3 und TabbyAPI

Programme nur für NVIDIA-Karten, auf hohe Geschwindigkeit für einen Nutzer auf einer Grafikkarte ausgelegt. TabbyAPI macht daraus einen Server.

ExLlama nutzt eigene Formate (EXL2 bzw. EXL3), die Modelle sehr fein auf den vorhandenen Grafikspeicher zuschneiden. Das bringt auf NVIDIA-Karten oft die höchste Geschwindigkeit für einen einzelnen Nutzer. TabbyAPI stellt ExLlama als Server mit OpenAI-kompatibler Schnittstelle bereit. Auf AMD, Intel und Mac läuft das nicht.

Siehe auch: CUDA, vLLM

Quelle: llamaperf: Engines (abgerufen 24.10.2026)

Transformers (Hugging Face)

Die Python-Bibliothek, mit der die meisten Modelle veröffentlicht werden. Zum Entwickeln und Forschen, nicht für den schnellen Betrieb.

Fast jedes offene Modell erscheint zuerst als Transformers-Modell auf Hugging Face. Die Bibliothek ist der Maßstab dafür, wie ein Modell richtig rechnet, aber nicht auf Tempo im Betrieb optimiert. Für den Einsatz nimmt man das Modell in einem passenden Format und eines der Programme oben.

Siehe auch: vLLM, llama.cpp

ik_llama.cpp

Eine Abspaltung von llama.cpp mit zusätzlichen Quantisierungsarten und schnellerem Rechnen auf dem Prozessor, nur für CPU und NVIDIA.

ik_llama.cpp hat sich 2024 von llama.cpp abgespalten und eigene Wege genommen: weitere Quantisierungsarten und mehr Tempo auf dem Prozessor, auch für die Mischung aus Grafikkarte und Prozessor bei MoE-Modellen. ROCm, Vulkan und Metal unterstützt das Projekt nach eigener Aussage nicht. Lizenz: MIT.

Siehe auch: llama.cpp, Offloading (Auslagern)

Quelle: ik_llama.cpp auf GitHub (abgerufen 24.10.2026)

Strata

Ein junges Spezialprogramm für ein einzelnes Modell (Qwen3.8-Flash-Next), das die Arbeit auf Grafikkarte, Arbeitsspeicher und Datenträger verteilt.

Strata liegt auf einem privaten GitHub-Konto, mit Installationsanleitungen für Windows und Linux und einer Abspaltung für ältere NVIDIA-V100-Karten. Es verteilt ein Modell so geschickt auf Grafikkarte, Arbeitsspeicher und Datenträger, dass auch sehr große Varianten auf einzelnen Karten laufen. In der Community-Datenbank llamaperf.com stehen über hundert Berichte, etwa ein 125-Milliarden-Modell mit rund 166 Tokens pro Sekunde auf einer RTX 5090, teils im Arbeitsspeicher.

Für den Einsatz in einer Firma ist Vorsicht angebracht. Es gibt laut llamaperf noch keinen sauberen Vergleich mit anderen Programmen unter gleichen Bedingungen, die Ergebnisse hängen stark von den Einstellungen ab, und eine Lizenz nennt die Seite nicht. Zum Ausprobieren interessant, für den festen Betrieb würden wir auf etablierte Programme setzen.

Siehe auch: Offloading (Auslagern), llama.cpp

Quelle: llamaperf: Strata (Quellenprüfung dort 13.10.2026, abgerufen 24.10.2026)

Quantisierung

Modellgewichte mit weniger Bit speichern, etwa 4 statt 16. Das Modell wird zwei- bis viermal kleiner und schneller, verliert aber etwas Qualität.

Offene Modelle erscheinen meist in 16 Bit je Gewicht (BF16 oder FP16), also 2 Byte je Parameter. Ein Modell mit 70 Milliarden Parametern braucht so rund 140 GB. In 4 Bit ist es nur noch ein Viertel so groß und passt auf eine Grafikkarte mit 48 GB oder einen Mac mit 64 GB.

Moderne 4-Bit-Verfahren behalten in üblichen Tests rund 95 bis 98 Prozent der ursprünglichen Qualität, im Gespräch fällt der Unterschied meist nicht auf. Ab 3 Bit und darunter wird der Verlust spürbar. Eine bewährte Regel: lieber das größere Modell in 4 Bit als das kleinere in 8 Bit. Wer mit Fachtexten, Zahlen oder Programmcode arbeitet, sollte die eigene Aufgabe in zwei Stufen vergleichen.

Siehe auch: Q4_K_M, Q5_K_M und die anderen K-Stufen, GGUF, VRAM (Grafikspeicher)

Quelle: llamaperf: Quantization for local LLMs (abgerufen 24.10.2026)

GGUF

Das Dateiformat von llama.cpp, Ollama, LM Studio und KoboldCpp. Eine Datei enthält Gewichte, Beschreibung und Tokenizer des Modells.

GGUF ist der Nachfolger der älteren Formate GGML und GGJT. In der Datei stehen neben den Gewichten auch Angaben zu Aufbau, Lizenz und Quantisierung sowie der Tokenizer, oft auch die Gesprächsvorlage. Ein Modell ist damit eine einzige Datei, die sich schnell laden lässt. GGUF läuft auf Prozessor, CUDA, ROCm, Metal und Vulkan und ist damit das beweglichste Format.

Auf Hugging Face erkennt man GGUF-Fassungen meist an der Endung im Namen, etwa „…-GGUF“, mit mehreren Dateien in verschiedenen Quantisierungsstufen zur Auswahl.

Siehe auch: Q4_K_M, Q5_K_M und die anderen K-Stufen, llama.cpp

Quelle: GGUF-Spezifikation im ggml-Repository (abgerufen 24.10.2026)

Q4_K_M, Q5_K_M und die anderen K-Stufen

Die Namen der Quantisierungsstufen in GGUF. Die Zahl nennt die Bit je Gewicht, K das moderne Verfahren, S, M und L die Variante. Q4_K_M ist der übliche Kompromiss.

Die Zahl ist ein Mittelwert: Wichtige Teile des Modells bekommen mehr Bit, weniger wichtige weniger. Q4_K_M liegt im Mittel bei etwa 4,5 Bit und braucht rund 28 Prozent des Speichers der 16-Bit-Fassung, Q5_K_M etwa 5,5 Bit und 34 Prozent, Q6_K etwa 6,5 Bit, Q8_0 8 Bit und die Hälfte. Q3 und Q2 sparen weiter, kosten aber spürbar Qualität.

S, M und L stehen für klein, mittel und groß. Jede Stufe nach oben braucht etwa zehn Prozent mehr Speicher für etwas mehr Qualität. Stufen mit _0 oder _1 am Ende sind ältere Verfahren, die von den K-Stufen abgelöst wurden.

Siehe auch: IQ-Stufen und imatrix, Quantisierung

Quelle: llamaperf: Quantization for local LLMs (abgerufen 24.10.2026)

IQ-Stufen und imatrix

Quantisierung mit einer Wichtigkeitstabelle (imatrix), die vorher an Beispieltexten gemessen wird. IQ4_XS ist kleiner als Q4_K_M bei ähnlicher Qualität.

Für die IQ-Stufen läuft das Modell vorab über einen Beispieltext, und es wird gemessen, welche Gewichte das Ergebnis am stärksten beeinflussen. Diese bekommen mehr Genauigkeit. Das hilft vor allem bei sehr kleinen Stufen unter 4 Bit. Weil die Beispieltexte das Ergebnis prägen, lohnt bei deutschen Aufgaben ein eigener Test.

Häufig sieht man auch Namen wie UD-Q4_K_XL. Das sind dynamische Mischungen eines Anbieters, bei denen einzelne Schichten unterschiedlich stark verkleinert werden.

Siehe auch: Q4_K_M, Q5_K_M und die anderen K-Stufen, GGUF

Quelle: llamaperf: Quantization for local LLMs (abgerufen 24.10.2026)

AWQ und GPTQ

Zwei 4-Bit-Verfahren für Server-Programme wie vLLM. Sie zielen auf NVIDIA-Karten und viele gleichzeitige Anfragen.

Beide verkleinern ein Modell nach dem Training auf meist 4 Bit, rechnen dabei aber anhand von Beispieldaten nach, wie der Fehler klein bleibt. AWQ achtet dafür besonders auf die Gewichte, die bei typischen Eingaben stark angesprochen werden. Solche Modelle laden vLLM, SGLang und ähnliche Server. In llama.cpp oder Ollama lassen sie sich nicht einfach verwenden, die Formate sind nicht austauschbar.

Siehe auch: vLLM, FP8, NVFP4 und MXFP4

Quelle: llamaperf: Quantization for local LLMs (abgerufen 24.10.2026)

EXL2 und EXL3

Die Formate von ExLlama. Sie lassen sich auf beliebige mittlere Bitzahlen zuschneiden, damit ein Modell genau in den vorhandenen Grafikspeicher passt. Nur NVIDIA.

Statt fester Stufen wählt man bei EXL2 und EXL3 eine Zielgröße in Bit je Gewicht (bpw), etwa 4,65. So nutzt man den Grafikspeicher bis auf den letzten Rest. Gelesen werden die Formate von ExLlamaV2, ExLlamaV3 und TabbyAPI auf NVIDIA-Karten.

Siehe auch: ExLlamaV2, ExLlamaV3 und TabbyAPI, bpw (Bit je Gewicht)

bpw (Bit je Gewicht)

Wie viele Bit ein Modellgewicht im Mittel belegt. Damit lässt sich der Speicherbedarf direkt ausrechnen.

Speicher der Gewichte in Gigabyte ≈ Parameter in Milliarden × bpw ÷ 8. Ein Modell mit 30 Milliarden Parametern in 4,5 bpw braucht so rund 17 GB, dazu kommt der Platz für den Kontext.

Siehe auch: VRAM (Grafikspeicher), Q4_K_M, Q5_K_M und die anderen K-Stufen

Quelle: llamaperf: VRAM requirements for local LLMs (abgerufen 24.10.2026)

BF16 und FP16

Die 16-Bit-Zahlenformate, in denen Modelle veröffentlicht werden. Sie gelten als volle Qualität, brauchen aber den meisten Speicher.

Beide speichern eine Zahl in 16 Bit, teilen die Bit aber unterschiedlich auf: BF16 hat einen größeren Wertebereich und weniger Nachkommastellen, FP16 umgekehrt. Für den Betrieb spielt der Unterschied kaum eine Rolle. Wichtig ist: 16 Bit heißt 2 Byte je Parameter, ein 8-Milliarden-Modell braucht also rund 16 GB nur für die Gewichte.

Siehe auch: Quantisierung, FP8, NVFP4 und MXFP4

FP8, NVFP4 und MXFP4

Kleine Gleitkommaformate, die neue Grafikkarten direkt in Hardware rechnen. Sehr schnell, aber nur auf passender Hardware.

FP8 speichert eine Zahl in 8 Bit und wird von neueren Karten in Hardware gerechnet, bei NVIDIA etwa ab der Generation Ada (RTX 40) und Hopper, bei AMD von den Instinct-Beschleunigern der MI300-Reihe. Die 4-Bit-Formate fassen jeweils einen kleinen Block von Werten mit einem gemeinsamen Faktor zusammen: Bei NVFP4 (NVIDIA Blackwell) sind es 16 Werte mit einem FP8-Faktor, bei MXFP4 nach dem offenen Microscaling-Standard 32 Werte mit einem Faktor, der nur Zweierpotenzen kennt. MXFP4 kommt so auf etwa 4,25 Bit je Wert.

Gelesen werden diese Formate vor allem von Server-Programmen wie vLLM und TensorRT-LLM. Auf älteren Karten bringen sie keinen Vorteil oder laufen gar nicht.

Siehe auch: AWQ und GPTQ, vLLM

Quelle: NVIDIA: Introducing NVFP4 for Efficient and Accurate Low-Precision Inference (abgerufen 24.10.2026) · Wikipedia: Block floating point (abgerufen 24.10.2026) · llamaperf: Quantization for local LLMs (abgerufen 24.10.2026)

Parameter

Die gelernten Zahlen eines Modells. Ihre Anzahl, etwa 8, 30 oder 70 Milliarden, bestimmt Speicherbedarf und grob die Fähigkeiten.

Wenn ein Modell „14B“ heißt, hat es 14 Milliarden Parameter. Mehr Parameter bedeuten meist mehr Wissen und besseres Schlussfolgern, aber auch mehr Speicher und weniger Tempo. Die Qualität hängt stärker von der Zahl der Parameter ab als von der Quantisierungsstufe.

Siehe auch: MoE (Mixture of Experts) und aktive Parameter, bpw (Bit je Gewicht)

Quelle: llamaperf: Quantization for local LLMs (abgerufen 24.10.2026)

MoE (Mixture of Experts) und aktive Parameter

Ein Modell aus vielen Teilnetzen, von denen je Token nur wenige rechnen. Es braucht Speicher für alle Parameter, rechnet aber nur mit den aktiven.

Ein MoE-Modell mit 120 Milliarden Parametern, von denen je Token etwa 6 Milliarden aktiv sind, muss vollständig in den Speicher passen, antwortet aber fast so schnell wie ein kleines Modell. Darum laufen solche Modelle gut auf Geräten mit viel, aber nicht ganz so schnellem Speicher, etwa Macs oder Strix Halo.

Im Gegensatz dazu rechnet bei einem dichten Modell (englisch dense) jedes Token mit allen Parametern.

Siehe auch: Parameter, Offloading (Auslagern), Unified Memory (gemeinsamer Speicher)

Quelle: llamaperf: Local model performance (abgerufen 24.10.2026) · llamaperf: VRAM requirements for local LLMs (abgerufen 24.10.2026)

Kontextlänge

Wie viel Text ein Modell auf einmal sieht, gemessen in Tokens. Mehr Kontext heißt längere Dokumente, aber auch mehr Speicher und langsameres Einlesen.

Ein Token ist ein Wortstück; im Deutschen kommen auf ein Wort grob ein bis zwei Tokens. 8.000 Tokens fassen also einige Seiten Text. Die vom Hersteller genannte Höchstlänge heißt nicht, dass der eigene Rechner sie schafft: Jedes zusätzliche Token belegt Platz im KV-Cache. Man sollte die Länge einstellen, die die Aufgabe wirklich braucht.

Siehe auch: KV-Cache, Prompt-Verarbeitung (Prefill)

Quelle: llamaperf: Local model performance (abgerufen 24.10.2026)

KV-Cache

Der Zwischenspeicher, in dem das Modell sich den bisherigen Text merkt. Er wächst mit der Kontextlänge und kann mehr Platz brauchen als gedacht.

Bei einem 70-Milliarden-Modell belegt der KV-Cache für 4.000 Tokens etwa 3 GB, für 32.000 Tokens rund achtmal so viel. Programme wie llama.cpp können ihn quantisieren, etwa auf 8 Bit (q8_0), und sparen so die Hälfte bis drei Viertel. Wer lange Dokumente verarbeiten will, plant diesen Speicher von Anfang an ein.

Siehe auch: Kontextlänge, VRAM (Grafikspeicher)

Quelle: llamaperf: VRAM requirements for local LLMs (abgerufen 24.10.2026)

Spekulatives Dekodieren

Ein kleines Hilfsmodell schlägt mehrere Tokens vor, das große Modell prüft sie in einem Schritt. Bei gleicher Antwort geht es oft deutlich schneller.

Weil die Ausgabe meist durch die Speicherbandbreite begrenzt ist, kann das große Modell mehrere vorgeschlagene Tokens fast so schnell prüfen wie eines erzeugen. Stimmen die Vorschläge oft, steigt das Tempo. Wie viel es bringt, hängt von der Aufgabe ab: Bei vorhersehbarem Text wie Code oft viel, bei freiem Text weniger. Bei Vergleichen von Messwerten muss man darauf achten, ob es eingeschaltet war.

Verwandt ist MTP (Multi-Token-Vorhersage): Hier hat das Modell selbst eingebaute Köpfe, die mehrere Tokens auf einmal vorhersagen.

Siehe auch: Speicherbandbreite, Tokens pro Sekunde (t/s)

Quelle: llamaperf: Local model performance (abgerufen 24.10.2026)

Offene Gewichte (Open Weights)

Modelle, deren Gewichte man herunterladen und selbst betreiben darf. Das ist nicht dasselbe wie Open Source, und die Lizenz kann Einschränkungen enthalten.

Lokal betreiben lassen sich nur Modelle mit herunterladbaren Gewichten. Ob man sie gewerblich nutzen darf, regelt die Lizenz des einzelnen Modells: Manche sind frei, andere schränken die Nutzung ab einer Firmengröße oder in bestimmten Regionen ein. Das gehört vor der Auswahl geprüft.

Siehe auch: Parameter

Tokens pro Sekunde (t/s)

Wie schnell ein Modell Text ausgibt, gezählt in Tokens (Wortstücken) pro Sekunde. Die wichtigste Zahl für das Gefühl beim Chatten.

Die Zahl sagt aber nicht alles. Wichtig ist, ob sie für eine einzelne Anfrage gilt oder als Summe über viele gleichzeitige Anfragen, wie bei Servern üblich. Und sie sagt nichts über die Wartezeit vor dem ersten Wort, die bei langen Eingaben überwiegen kann.

Siehe auch: Prompt-Verarbeitung (Prefill), Zeit bis zum ersten Token

Quelle: llamaperf: Local model performance (abgerufen 24.10.2026)

Prompt-Verarbeitung (Prefill)

Wie schnell ein Modell die Eingabe einliest, ebenfalls in Tokens pro Sekunde. Bei langen Dokumenten und RAG oft der eigentliche Engpass.

Bevor das Modell antwortet, liest es die gesamte Eingabe ein. Das geht viel schneller als die Ausgabe, hängt aber stärker an der Rechenleistung. Bei einem Dokument mit 20.000 Tokens und 500 t/s Prefill wartet man 40 Sekunden, bevor das erste Wort erscheint. Programme können wiederholte Anfänge zwischenspeichern, das verfälscht Messungen, wenn man es nicht weiß.

Siehe auch: Zeit bis zum ersten Token, Kontextlänge

Quelle: llamaperf: Local model performance (abgerufen 24.10.2026)

Zeit bis zum ersten Token

Die Wartezeit, bis die Antwort sichtbar beginnt. Sie entsteht aus Laden, Warteschlange und Einlesen der Eingabe.

Für Nutzer fühlt sich diese Zeit oft wichtiger an als das Ausgabetempo. Wer misst, sollte den ersten Start mit dem Laden des Modells getrennt von warmen Läufen betrachten.

Siehe auch: Prompt-Verarbeitung (Prefill), Tokens pro Sekunde (t/s)

Quelle: llamaperf: Local model performance (abgerufen 24.10.2026)

Perplexity und KL-Divergenz

Zwei Maße dafür, wie stark eine Quantisierung ein Modell verändert. Kleiner ist besser.

Die Perplexity misst, wie gut ein Modell einen bekannten Text vorhersagt, oft an einem englischen Wikipedia-Ausschnitt. Die KL-Divergenz vergleicht direkt die Ausgaben der verkleinerten mit denen der Originalfassung. Beide eignen sich, um Quantisierungsstufen desselben Modells zu vergleichen, aber nicht, um verschiedene Modelle oder deutsche Fachaufgaben zu beurteilen.

Siehe auch: Quantisierung, Benchmarks (MMLU-Pro, IFEval und andere)

Benchmarks (MMLU-Pro, IFEval und andere)

Standardisierte Aufgabensammlungen, mit denen Modelle verglichen werden. Nützlich zur Vorauswahl, kein Ersatz für einen Test mit den eigenen Aufgaben.

MMLU-Pro prüft Fachwissen über viele Gebiete, IFEval, ob ein Modell Anweisungen genau befolgt. Die meisten Sammlungen sind englisch. Für den Einsatz in einer deutschen Firma zählt am Ende, wie das Modell mit euren Texten, Formularen und Fragen umgeht. Dafür reichen oft zwanzig typische Beispiele, die man mit jedem Kandidaten durchspielt.

Siehe auch: Perplexity und KL-Divergenz

OpenAI-kompatible Schnittstelle

Fast alle lokalen Programme bieten dieselbe Programmierschnittstelle wie OpenAI an. So laufen vorhandene Anwendungen ohne Umbau gegen das eigene Modell.

llama.cpp, Ollama, LM Studio, vLLM, SGLang und KoboldCpp stellen eine Schnittstelle bereit, die sich wie die von OpenAI verhält. Eine Anwendung, die bisher ChatGPT angesprochen hat, braucht oft nur eine andere Adresse. Das hält den Wechsel zwischen Cloud und lokal offen und verhindert Abhängigkeit von einem Anbieter.

Siehe auch: llama.cpp, vLLM

Quelle: llama.cpp auf GitHub (abgerufen 24.10.2026) · KoboldCpp auf GitHub (abgerufen 24.10.2026)

Open WebUI

Eine Weboberfläche wie ChatGPT für das eigene Modell, mit Benutzerkonten und Dokumentensammlungen. Läuft vor Ollama oder jedem Server mit OpenAI-Schnittstelle.

Open WebUI ist selbst kein Programm zum Rechnen, sondern die Oberfläche davor. Es bringt Anmeldung, Rechte, Gesprächsverlauf und eine einfache Dokumentensuche mit. Für ein kleines Team ist Ollama mit Open WebUI der schnellste Weg zu einem internen KI-Chat.

Siehe auch: Ollama, RAG (Retrieval-Augmented Generation)

Continuous Batching

Der Server nimmt laufend neue Anfragen in den Rechenstapel auf, statt sie nacheinander abzuarbeiten. So bedient eine Karte viele Nutzer gleichzeitig.

Weil die Ausgabe eines einzelnen Nutzers die Rechenwerke kaum auslastet, kann die Karte viele Anfragen zugleich bearbeiten, fast ohne dass die einzelne langsamer wird. Server wie vLLM und SGLang tun das von Haus aus. Für eine Abteilung ist das der Grund, auf einen solchen Server zu wechseln.

Siehe auch: vLLM, SGLang

Quelle: llamaperf: Engines (abgerufen 24.10.2026)

Tensor-Parallelität

Ein Modell wird auf mehrere Grafikkarten aufgeteilt, die gleichzeitig an jedem Rechenschritt arbeiten. So passen größere Modelle und es wird schneller.

Mit zwei 24-GB-Karten lässt sich ein Modell betreiben, das auf keiner allein Platz hätte. Bei der Tensor-Parallelität rechnen beide Karten an jedem Schritt mit und tauschen Zwischenergebnisse aus. Die einfachere Alternative ist, die Schichten auf die Karten zu verteilen (Pipeline). Das spart Speicher, macht aber eine einzelne Anfrage nicht schneller.

Siehe auch: NVLink, VRAM (Grafikspeicher)

Embedding

Ein Text wird in eine Zahlenreihe übersetzt, die seine Bedeutung beschreibt. Damit findet man passende Textstellen, auch wenn andere Wörter benutzt werden.

Embeddings erzeugt ein eigenes, kleines Modell. Sie sind die Grundlage für die Suche in Firmendokumenten: Frage und Dokumente werden in Zahlen übersetzt, und die ähnlichsten Abschnitte gehen an das Sprachmodell. Auch das Embedding-Modell kann lokal laufen, damit die Dokumente das Haus nicht verlassen.

Siehe auch: RAG (Retrieval-Augmented Generation)

RAG (Retrieval-Augmented Generation)

Das Modell bekommt zu jeder Frage passende Abschnitte aus den eigenen Dokumenten mitgeliefert und antwortet daraus. Der übliche Weg zu Firmenwissen, ohne nachzutrainieren.

Bei RAG sucht ein System zuerst die passenden Textstellen und gibt sie dem Modell zusammen mit der Frage. Das Modell bleibt unverändert, neue Dokumente sind sofort verfügbar, und die Antwort kann auf ihre Quelle verweisen. Wie gut es funktioniert, hängt mehr an der Aufbereitung der Dokumente als am Modell.

Siehe auch: Embedding, Open WebUI, Prompt-Verarbeitung (Prefill)