Womit ein Modell läuft

Eine Gewichtsdatei enthält Milliarden Zahlen und ein paar Angaben zu ihrem Aufbau. Was genau darin steht, zeigt Kapitel 01. Damit daraus eine Antwort wird, braucht es ein Programm. Es lädt die Datei, rechnet die Eingabe durch die Schichten, wählt das nächste Token und liefert das Ergebnis aus. Dieses Programm heißt hier Inferenz-Engine, kurz Engine.

Die Hersteller sagen dafür auch Laufzeit, auf Englisch runtime. Ollama nennt MLX in seinen Release Notes (externe Seite, github.com) eine solche Laufzeit, LM Studio spricht in seiner Doku (externe Seite, lmstudio.ai) von seiner llama.cpp-Engine. Gemeint ist jedes Mal dasselbe. In Kapitel 04 heißt es Laufzeit, in Grundkurs, Kapitel 01 Laufzeitumgebung.

Was zum Modell gehört und was zum Programm davor, trennt Grundkurs, Kapitel 01. An den Reglern für den Zufall zeigt Grundkurs, Kapitel 12, dass sie Einstellungen des Programms sind. Dieses Kapitel zeigt dieselbe Grenze an Speicher, Tempo und Betrieb. Das Beispiel ist gpt-oss von OpenAI in zwei Größen: gpt-oss-20b für den eigenen Rechner und gpt-oss-120b für den Server.

Das Programm entscheidet über die Zahl der Grafikkarten

OpenAI hat beide Modelle im August 2025 mit offenen Gewichten unter Apache 2.0 und einer eigenen Nut­zungs­richt­linie veröffentlicht (Modellkarte (externe Seite, openai.com)). Die Gewichte der Experten liegen im Format MXFP4, mit 4,25 Bit je Parameter (Bericht (externe Seite, arxiv.org)). Laut README (externe Seite, github.com) des Herstellers läuft gpt-oss-120b damit auf einer einzigen Grafikkarte mit 80 GB, etwa einer H100. gpt-oss-20b kommt mit 16 GB Speicher aus.

Dieselbe README führt eine Referenzfassung in PyTorch. Sie ist ausdrücklich zum Lernen gedacht und nach eigener Angabe nicht optimiert. Diese Fassung wandelt alle Gewichte in BF16 um, ein Format mit 16 Bit, und rechnet darin. Für gpt-oss-120b braucht sie mindestens vier H100, alternativ zwei H200.

Die eigene Rechnung zeigt den Grund. Tabelle 1 des Berichts (externe Seite, arxiv.org) nennt für gpt-oss-120b 116,83 Milliarden Parameter. In BF16 belegt jeder 2 Byte, zusammen 233,7 Gigabyte. Das ist fast das Dreifache einer Karte mit 80 GB.

Im veröffentlichten Format wiegt dasselbe Modell laut derselben Tabelle 60,8 GiB, also 65,3 Gigabyte, gerechnet mit 1 GiB = 1,0737 GB. Das passt auf eine Karte.

Eine zweite Referenz in Triton aus derselben README läuft auf einer Karte mit 80 GB, weil sie die Experten mit einem eigenen Kernel für MXFP4 rechnet. Beide Referenzen sind laut README zum Lernen gedacht. Für den Betrieb nennt die Anleitung von vLLM für gpt-oss (externe Seite, github.com) eine A100 mit 80 GB. Auf einer H100 mit einer einzigen Karte verlangt sie eine angepasste Spei­cher­ein­stel­lung, sonst reicht der Speicher nicht.

Dieselben Gewichte von gpt-oss-120b brauchen also je nach Programm das 3,6-Fache an Speicher. Es kommt darauf an, ob ein Programm das gespeicherte Format direkt rechnet oder es vorher in 16 Bit umwandelt. Die Lehrfassung in PyTorch nimmt den Speicher in Kauf. Wer ein Programm für den Betrieb wählt, prüft deshalb, ob es das Format des Modells direkt rechnet. Die zweite Ebene zeigt das an gpt-oss-20b.

Der Hersteller trennt Einzelplatz und Server

Die README von gpt-oss nennt fünf Wege, das Modell auszuführen: die Bibliothek Transformers, vLLM, die eigene Referenz, Ollama und LM Studio. Für einige davon hat OpenAI eigene Anleitungen geschrieben. Die Anleitung zu Ollama (externe Seite, developers.openai.com) beginnt mit einer Zuordnung. Sie gilt für Geräte wie einen PC oder einen Mac. Für Server mit eigenen Grafikkarten wie der H100 verweist sie auf die Anleitung zu vLLM.

Damit sind die beiden Fälle dieses Kapitels benannt. Am Einzelplatz arbeitet eine Person mit einem Modell. Die Engine soll mit wenig Einrichtung auf dem vorhandenen Gerät laufen. Am Server teilen sich viele gleichzeitige Anfragen dieselbe Hardware. Dort soll die Engine in derselben Zeit möglichst viele davon bedienen. Wie sie das schafft, erklärt die dritte Ebene.

Fünf verbreitete Programme

Fünf Programme stehen in diesem Kapitel im Vordergrund. Drei davon nennt die README von gpt-oss. llama.cpp und MLX sind die Engines, auf denen Ollama und LM Studio aufbauen. Ollama und LM Studio sind Programme mit Engines darunter, die zweite Ebene zeigt das genauer. Die fünf unterscheiden sich darin, wofür sie gebaut sind, worauf sie rechnen und unter welcher Lizenz sie stehen.

llama.cpp erschien am 10.03.2023. Das Ziel war damals, ein Modell in 4 Bit auf einem MacBook laufen zu lassen (erste README (externe Seite, github.com)). Heute nennt die README (externe Seite, github.com) als Ziel, mit wenig Aufwand auf vielen Arten von Hardware zu rechnen, lokal und in der Cloud. Das Programm ist in C und C++ geschrieben und steht unter MIT.

Ollama startete am 08.07.2023 als frühe Vorschau (erste Fassung (externe Seite, github.com)). Es lädt ein Modell mit einem Befehl und steht unter MIT (externe Seite, github.com). Für die Modelle stützte es sich anfangs auf llama.cpp. Im Mai 2025 kündigte es eine eigene Engine an, zunächst für Modelle, die auch Bilder verarbeiten (Ankündigung (externe Seite, ollama.com)).

LM Studio ist eine App mit eigenem Fenster für Mac, Windows und Linux, dazu gibt es eine Fassung ohne Oberfläche für Server. Sie rechnet über llama.cpp, auf Macs mit Apple-Chip wahlweise über MLX (Doku (externe Seite, lmstudio.ai)). Die App steht unter eigenen Bedingungen (externe Seite, lmstudio.ai) des Herstellers. Seit dem 08.07.2025 ist sie auch für die Arbeit kostenlos (Ankündigung (externe Seite, lmstudio.ai)).

MLX ist Apples Framework für maschinelles Lernen auf den eigenen Chips (MLX (externe Seite, github.com)). Darauf baut das Paket mlx-lm (externe Seite, github.com), das mit Sprachmodellen Text erzeugt und sie nachtrainiert. Lizenz MIT.

vLLM entstand im Sky Computing Lab der UC Berkeley und wird heute von einer großen Gemeinschaft gepflegt. Es ist für den Betrieb mit vielen Anfragen gebaut (README (externe Seite, github.com)). Die erste Ankündigung (externe Seite, vllm.ai) erschien am 20.06.2023. Lizenz Apache 2.0.

Für Server gibt es weitere. SGLang (externe Seite, github.com) ist für Agenten und Betrieb in großem Maßstab ausgelegt. Dahinter steht die gemeinnützige Organisation LMSYS. TensorRT-LLM (externe Seite, github.com) ist NVIDIAs Bibliothek für die eigenen Grafikkarten. Text Generation Inference, kurz TGI, von Hugging Face steht laut README (externe Seite, github.com) seit dem 11.12.2025 im Wartungsmodus. Der Hinweis dort empfiehlt als Nachfolger vLLM und SGLang, für den eigenen Rechner llama.cpp und MLX.

Ein Wechsel beginnt bei der Adresse

Alle fünf bringen einen Server mit, der die Form der Schnittstelle von OpenAI spricht. Wie genau, ist verschieden.

Die README von llama.cpp (externe Seite, github.com) nennt ihren Server kompatibel. Ollama unterstützt laut Doku (externe Seite, docs.ollama.com) eine Teilmenge. LM Studio stellt Endpunkte nach dem Vorbild von OpenAI bereit (Doku (externe Seite, lmstudio.ai)). Der Server von mlx-lm soll der Schnittstelle ähneln (Beschreibung (externe Seite, github.com)). vLLM, der Server von llama.cpp und Ollama sprechen zusätzlich die Nachrichten-Schnittstelle von Anthropic (README von vLLM (externe Seite, github.com), Doku des Servers von llama.cpp (externe Seite, github.com)). Für Ollama steht das in Grundkurs, Kapitel 11.

Laufen mehrere davon auf einem Rechner, unterscheiden sie sich am Port. Ollama hört auf 11434, so steht es in der README von gpt-oss (externe Seite, github.com). LM Studio benutzt in den Beispielen seiner Doku (externe Seite, lmstudio.ai) den Port 1234. vLLM nimmt laut Anleitung (externe Seite, github.com) voreingestellt 8000. Der Server von llama.cpp ist laut seiner Doku (externe Seite, github.com) auf 9931 voreingestellt, der von mlx-lm startet im Beispiel seiner Beschreibung (externe Seite, github.com) auf 8080.

Eine Anwendung, die für eine dieser Adressen geschrieben ist, erreicht die anderen meist mit einer geänderten Zeile. Was dabei fehlen kann, beschreibt Grundkurs, Kapitel 11 am Wort Teilmenge.

Vier Fragen entscheiden die Wahl

1. Wie viele Anfragen kommen gleichzeitig? Eine Person am eigenen Gerät braucht ein Programm für den Einzelplatz. Viele Nutzer an einem Server brauchen eines, das ihre Anfragen stapelt. Woran man das an den Voreinstellungen erkennt, zeigt die zweite Ebene.
2. Welche Hardware steht bereit? MLX ist für Apple-Chips gebaut, TensorRT-LLM für Grafikkarten von NVIDIA. llama.cpp rechnet auf beiden und auf vielen weiteren.
3. Unter welcher Lizenz steht das Programm? Das Modell hat eine Lizenz, das Programm eine eigene. LM Studio erlaubt den Einsatz für private und interne geschäftliche Zwecke. Die Software als Dienst für andere anzubieten, schließen seine Bedingungen (externe Seite, lmstudio.ai) aus. llama.cpp und Ollama stehen unter MIT, vLLM unter Apache 2.0.
4. Wird es noch gepflegt? TGI zeigt, dass auch ein verbreiteter Server in den Wartungsmodus gehen kann. Dort kommen laut README (externe Seite, github.com) nur noch kleine Fehlerbehebungen und Pflegearbeiten hinzu.

Jedes Programm hat dabei einen eigenen Vorzug. LM Studio vereint zwei Engines in einer Oberfläche. Ollama holt ein Modell mit einem Befehl. Der Server vLLM bedient viele Anfragen zugleich, und llama.cpp läuft auf vielen Arten von Hardware. Über MLX rechnet ein Modell auf dem Mac im gemeinsamen Speicher von Prozessor und Grafikeinheit, nach einer eigenen Messung bitgenau wiederholbar.

Die Modellkarte nennt den Speicher, den die Gewichte brauchen. Zu Programm, Lizenz des Programms und Pflege sagt sie nichts. Wo ein Modell überhaupt betrieben werden soll, entscheidet Beurteilen und Einordnen, Kapitel 01.

Der Überblick hat die fünf verbreiteten Engines vorgestellt. Diese Ebene geht die Schritte durch, die eine Engine zwischen Datei und Antwort ausführt. Danach geht es um die Dateien, in denen ein Modell vorliegt, und um die Frage, welche Engine welches Format liest. Am Ende stehen Voreinstellungen und Lizenzen. Das Beispiel ist gpt-oss-20b.

Fünf Schritte zwischen Datei und Antwort

Laden. Die Engine liest die Gewichte aus einer Datei und legt sie in den Speicher, auf dem sie rechnet. Welche Formate sie dabei versteht, ist von Programm zu Programm verschieden, wie ein Abschnitt weiter unten zeigt.

Vorlage. Vor dem Rechnen setzt die Engine das Gespräch in einen einzigen Text mit Sonderzeichen für Rollen und Grenzen. gpt-oss ist mit dem Format harmony trainiert. Laut README (externe Seite, github.com) soll es nur damit benutzt werden, sonst arbeite es nicht richtig. Die Vorlage liegt meist den Modelldateien bei, und die Engine wendet sie an. Der Server von llama.cpp nimmt voreingestellt die Vorlage aus der Datei und lässt sich eine eigene geben (Doku (externe Seite, github.com)). Ollama bringt für gpt-oss laut der Anleitung von OpenAI (externe Seite, developers.openai.com) eine eigene mit, die harmony nachbildet. Mit einer falschen Vorlage arbeitet auch ein richtiges Modell schlecht.

Rechnen. Die Engine schickt die Zahlen durch die Schichten. Dafür braucht sie Rechenroutinen für die jeweilige Hardware, sogenannte Kernels. llama.cpp bringt eigene für Grafikkarten von NVIDIA mit und rechnet auf Apple-Chips über Metal (README (externe Seite, github.com)). Wie viel Speicher und Bandbreite dabei gebraucht werden, rechnet Kapitel 04 vor.

Ziehen. Aus den Wahr­schein­lich­keiten für das nächste Token wählt die Engine eines aus. Die Regler dafür sind Einstellungen des Programms. Sie stehen in Grundkurs, Kapitel 12.

Ausliefern. Die Engine gibt das Ergebnis über ihre Schnittstelle zurück, bei allen fünf in der Form von OpenAI. Hier entscheidet sich auch, was mit einem Toolaufruf geschieht.

Wer einen Toolaufruf ausführt, ist eine Einstellung

Will ein Modell ein Werkzeug benutzen, schreibt es einen Aufruf in fester Form. Der Server vLLM erkennt ihn in der Ausgabe und gibt ihn als Daten an den Aufrufer zurück. Ausführen muss ihn laut Doku (externe Seite, docs.vllm.ai) die Anwendung, die vLLM gefragt hat.

Bei einem Anbieter gibt es einen zweiten Weg. Anthropic unterscheidet in seiner Doku (externe Seite, platform.claude.com) Aufrufe, die die eigene Anwendung ausführt, von solchen, die Anthropic selbst ausführt. Beide Wege erklärt Grundkurs, Kapitel 09.

Auch eine Engine kann diese Rolle übernehmen, wenn man sie lässt. Der Server von llama.cpp bringt eingebaute Werkzeuge mit, darunter Lesen und Schreiben von Dateien und Befehle in der Shell. Sie sind als experimentell gekennzeichnet und voreingestellt aus. Die Doku (externe Seite, github.com) warnt davor, sie in einer Umgebung einzuschalten, der man nicht vertraut.

Dasselbe gilt für vLLM mit gpt-oss. Mit einem Schalter für einen Werkzeugserver führt vLLM über seine Responses-Schnittstelle selbst Werkzeuge aus, etwa Browser, Python und MCP. Für den Betrieb kann es dabei laut seiner Anleitung für gpt-oss (externe Seite, github.com) als MCP-Client mehrerer Dienste auftreten.

Voreingestellt gilt also für vLLM wie für llama.cpp: Die Engine liefert den Aufruf als Daten, und die Anwendung führt ihn aus. Das Programm, das Werkzeuge ausführt, die Schleife dreht und Grenzen setzt, heißt Harness. Es ist Thema von Agenten und Harness, Kapitel 01.

Ein Modell liegt in mehreren Dateien vor

Von gpt-oss-20b liegen bei Hugging Face mehrere Fassungen derselben Gewichte, alle unter Apache 2.0 und ohne Zugangsschranke. Gezählt wurden die Dateien am 20.10.2026 über die Schnittstelle des Portals (Zählung (externe Seite, huggingface.co)). Ein Gigabyte sind hier eine Milliarde Byte.

Ollama führt gpt-oss-20b in seiner Bibliothek (externe Seite, ollama.com) mit 14 GB, als eigene Fassung für das eigene Programm.

Drei Formate stehen in der Tabelle. Eine GGUF-Datei enthält neben den Gewichten einen Kopf mit Angaben zum Modell. safetensors-Dateien liegen in einem Ordner neben einer Kon­fi­gu­ra­ti­ons­datei, so wie der Hersteller sie veröffentlicht. Auch ein MLX-Ordner besteht aus safetensors-Dateien, deren Gewichte so abgelegt sind, wie MLX sie rechnet.

Die Fassung mit 8 Bit wiegt 22,2 Gigabyte, gut 60 Prozent mehr als die des Herstellers. Laut ihrer Konfiguration liegen dort alle Gewichte in 8 Bit, auch die Experten. OpenAI hat die Experten in MXFP4 nachtrainiert und nur so veröffentlicht. Die Umwandlung in 8 Bit macht die Datei größer. Mehr, als im Original steckt, kann sie den Experten nicht hinzufügen.

Die GGUF-Ablage liefert außerdem ein Entwurfsmodell für EAGLE-3 mit, ein Verfahren des Speculative Decoding, in zwei Genauigkeiten. Für ein Verfahren der Engine liegt dort also ein zweites, eigens trainiertes Modell bei. Die dritte Ebene ordnet das Verfahren ein. Wer eine solche Datei gebaut hat und was bei der Umwandlung verloren gehen kann, steht in Kapitel 02.

Welche Engine welches Format liest

GGUF ist das Format von llama.cpp. Die Spezifikation (externe Seite, github.com) beschreibt es als Format für Programme, die auf der Bibliothek GGML aufbauen. Entwickelt werden Modelle meist in PyTorch und für GGML in GGUF umgewandelt.

LM Studio rechnet GGUF über llama.cpp (Doku (externe Seite, lmstudio.ai)). Auf dem Mac kommen MLX-Ordner hinzu, über eine eigene MLX-Engine (externe Seite, github.com), die auf mlx-lm aufbaut. Sie liegt der App für den Mac seit Version 0.3.4 bei.

Ollama übernimmt eigene Dateien über ein Modelfile und den Befehl ollama create. Die Importanleitung (externe Seite, docs.ollama.com) nennt zwei Wege: einen Ordner mit safetensors und eine GGUF-Datei. Eine GGUF-Datei quantisiert Ollama dabei nicht neu.

vLLM liest Modelle im Aufbau von Hugging Face (README (externe Seite, github.com)). GGUF gilt dort als sehr experimentell, noch nicht optimiert und womöglich unverträglich mit anderen Funktionen, so steht es in der Doku (externe Seite, docs.vllm.ai) zu Fassung 0.32.0. Das Paket mlx-lm lädt Modelle direkt vom Hugging Face Hub und kann sie umwandeln und quantisieren (README (externe Seite, github.com)).

„Keine Angabe“ heißt: Die Doku des Programms nennt das Format nicht. Ob es trotzdem geht, ist damit offen. Für Ollama auf dem Mac sagen die Release Notes zu Version 0.40.0, dass unterstützte Bauformen über MLX laufen. Welche Dateien Ollama dafür lädt, sagen sie nicht.

Für GGUF stimmt also, was Beurteilen und Einordnen, Kapitel 01 über Ollama und LM Studio sagt: Beide führen dieselben Dateien aus. Darüber hinaus liest LM Studio auf dem Mac MLX-Ordner, und Ollama übernimmt safetensors über den Import.

Ob ein Format direkt läuft, entscheidet über den Speicher

Die Experten von gpt-oss liegen in MXFP4: zwei Werte je Byte und ein gemeinsamer Skalierungsfaktor je 32 Werte. Wie das in der Datei aussieht und wie man die Parameter darin richtig zählt, zeigt Kapitel 01. Hier zählt eine Frage. Rechnet die Engine dieses Format direkt, oder wandelt sie es vor dem Rechnen in 16 Bit um?

Ollama rechnet MXFP4 laut seiner Bibliothek (externe Seite, ollama.com) direkt, ohne weitere Quantisierung oder Umwandlung. Dafür hat es eigene Kernels für seine neue Engine geschrieben. OpenAI schreibt in der README (externe Seite, github.com), die Modelle seien von Haus aus quantisiert veröffentlicht.

Eigene Rechnung, Parameter aus Tabelle 1 des Berichts (externe Seite, arxiv.org), 2 Byte je Parameter in BF16, 1 GiB = 1,0737 GB:

Die gespeicherte Größe lässt sich nachrechnen. Beim kleinen Modell ergeben 19,12 Milliarden Parameter zu 4,25 Bit 10,2 Gigabyte. Für die übrigen 1,80 Milliarden in Aufmerksamkeit, Ein- und Ausgang sei BF16 angenommen, also 3,6 Gigabyte. Zusammen sind das 13,76 Gigabyte, also 12,8 GiB wie im Bericht. Weil beim kleinen Modell ein größerer Teil außerhalb der Experten liegt, spart es weniger: Faktor 3,0 statt 3,6. Ollama nennt 14 und 65 GB, passend zu den gespeicherten Größen.

Daraus folgt eine Bedingung. Auf einem Gerät mit 16 GB braucht gpt-oss-20b eine Engine, die die Gewichte etwa in der gespeicherten Größe hält. Am einfachsten gelingt das, wenn sie MXFP4 direkt rechnet. In BF16 bräuchte es 41,8 Gigabyte allein für die Gewichte. Reicht der Grafikspeicher nicht, lässt sich laut Anleitung von OpenAI (externe Seite, developers.openai.com) ein Teil auf den Prozessor auslagern, dann läuft das Modell langsamer.

Den KV-Cache dazu rechnet Kapitel 04 vor, Den KV-Cache dazu rechnet Kapitel 04 vor, die Quantisierung im Allgemeinen beschreibt Beurteilen und Einordnen, Kapitel 01.

Ein Programmname, mehrere Engines darunter

Ollama hat sich für die Unterstützung neuer Modelle lange auf llama.cpp gestützt. Am 15.05.2025 kündigte es eine eigene Engine an, zunächst für Modelle, die auch Bilder verarbeiten. Sie baut weiter auf der Rechenbibliothek GGML auf (Ankündigung (externe Seite, ollama.com)). Seit Version 0.40.0 laufen auf Apple-Chips die Bauformen, die MLX unterstützt, automatisch über MLX (Release Notes (externe Seite, github.com)).

llama.cpp bleibt dabei im Einsatz. In der Messung von Kapitel 04 meldete Ollama 0.40.6 für Qwen3-30B-A3B als Laufzeit llama.cpp. Welche Engine rechnet, hängt bei Ollama also an Version, Gerät und Bauform des Modells. LM Studio hat zwei Engines nebeneinander, llama.cpp und die MLX-Engine auf Grundlage von mlx-lm.

Ein Update kann deshalb die Engine tauschen, ohne dass sich der Name des Programms oder die Modelldatei ändern. Wie verschieden zwei Engines dasselbe Modell rechnen, misst der Bericht Elf Wege, ein lokales Modell schneller zu machen. Dasselbe Modell lief dort über MLX langsamer als über llama.cpp. Zwischen zwei Fassungen von llama.cpp verschob sich das Tempo je Bauform in verschiedene Richtungen. Wer Engines vergleicht, notiert deshalb Programm und Fassung.

Voreinstellungen zeigen, wofür ein Programm gebaut ist

Ollama bearbeitet je Modell voreingestellt eine Anfrage zur Zeit (FAQ (externe Seite, docs.ollama.com)). Mehr gleichzeitige Anfragen lassen sich einstellen, und jede vergrößert den reservierten Kontext. Was das für den Speicher heißt, rechnet Kapitel 04 vor.

LM Studio fasst gleichzeitige Anfragen zu einem Stapel zusammen, voreingestellt sind vier (Doku (externe Seite, lmstudio.ai)). Das gilt für die Engine llama.cpp, für MLX ist es angekündigt.

Der Server von llama.cpp bedient mehrere Nutzer parallel und stapelt voreingestellt (Doku (externe Seite, github.com)). Der Server von mlx-lm wird für den Produktivbetrieb nicht empfohlen, weil er nur grundlegende Sicher­heits­prü­fungen enthält (Beschreibung (externe Seite, github.com)).

vLLM führt das Stapeln eingehender Anfragen unter seinen Merkmalen (README (externe Seite, github.com)). Voreingestellt lässt der Server laut seiner Anleitung für gpt-oss (externe Seite, github.com) auf Karten mit viel Speicher eine große Zahl gleichzeitiger Folgen zu, etwa 1.024.

Auch llama.cpp stapelt also, sobald es als Server läuft. Wie viele Plätze der Server anlegt, wählt er voreingestellt selbst. Den Speicher für Schlüssel und Werte teilen sich dann alle Plätze in einem gemeinsamen Puffer (Doku (externe Seite, github.com)). Wie vLLM diesen Speicher in Blöcken vergibt, erklärt die dritte Ebene.

Das Programm hat eine eigene Lizenz

Das Modell gpt-oss steht unter Apache 2.0. Für das Programm, das es ausführt, gilt eine eigene Lizenz. Bei den Repositories steht sie jeweils in der Datei LICENSE beim selben Commit, die Quelle führt das in ihrer Beschreibung.

Für Entscheider ist das die Zeile, die in der Modellkarte von gpt-oss fehlt. Apache 2.0 erlaubt, gpt-oss in einem Dienst für Kunden einzusetzen, dazu kommt die Nut­zungs­richt­linie von OpenAI (Modellkarte (externe Seite, openai.com)). Mit LM Studio darunter schließen die Bedingungen der App einen solchen Dienst aus. Für den Einsatz im eigenen Haus reicht LM Studio, und kostenlos ist es dort auch.

Was die drei Programme aus der README von gpt-oss jeweils besser können, ergibt sich aus dieser Ebene. LM Studio hat zwei Engines in einer Oberfläche und liest auf dem Mac GGUF und MLX. Ollama holt fertige Fassungen mit einem Befehl und steht unter MIT. Der Server vLLM ist für viele gleichzeitige Anfragen gebaut und liest Modelle im Aufbau von Hugging Face ohne Umweg.

Die zweite Ebene hat gezeigt, dass auch Programme für den Einzelplatz Anfragen stapeln, sobald sie als Server laufen. Diese Ebene erklärt, warum sich das lohnt, woher das Verfahren kommt und wie vLLM den Speicher dafür verwaltet. Danach folgen drei bekannte Faktoren mit drei verschiedenen Vergleichsbasen, die Abwägung zwischen Durchsatz und Latenz und die Frage, wann Speculative Decoding im Server hilft.

Stapeln lohnt, weil die Gewichte einmal gelesen werden

Beim Erzeugen liest ein Modell für jedes Token seine Gewichte aus dem Speicher. Dabei wartet der Rechner mehr, als er rechnet. Die langfristige Entwicklung dahinter beschreibt Beurteilen und Einordnen, Kapitel 05, die Obergrenze für ein Gerät rechnet Kapitel 04 vor. Die Arbeit zu vLLM (externe Seite, arxiv.org) nennt den Betrieb deshalb speichergebunden: Die Rechenleistung der Grafikkarte bleibt zum Teil ungenutzt, und der Durchsatz ist begrenzt.

Der Ausweg ist der Stapel. Rechnen mehrere Anfragen im selben Durchgang, teilen sie sich dieselben Gewichte. Der Aufwand, die Gewichte zu bewegen, verteilt sich dann auf alle Anfragen im Stapel, so beschreibt es Abschnitt 2.3 der Arbeit. Das Abstract beginnt mit der Folgerung: Wer viel Durchsatz will, muss genügend Anfragen auf einmal stapeln.

Am Einzelplatz läuft meist eine Anfrage. Ein Server mit vielen Nutzern hat viele zugleich, und für diesen Fall sind vLLM und die anderen Server gebaut.

Der Stapel ändert sich nach jedem Schritt

Ein einfacher Stapel läuft, bis seine längste Antwort fertig ist. Kurze Antworten warten so lange im Stapel, neue Anfragen warten auf den nächsten. Für Transformer-Modelle hat das die Arbeit zu Orca (externe Seite, usenix.org) von Yu und anderen geändert, vorgestellt auf der OSDI im Juli 2022. Ihr Planer lässt das Modell jeweils einen einzigen Schritt über den Stapel rechnen. Danach wird der Stapel neu zusammengestellt. Orca nennt das iteration-level scheduling.

An GPT-3 mit 175 Milliarden Parametern meldet die Arbeit gegenüber FasterTransformer von NVIDIA den 36,9-fachen Durchsatz, an einem Messpunkt mit gleicher Latenz. Die Arbeit zu vLLM fasst das Verfahren in einem Satz zusammen: Nach jedem Schritt verlassen fertige Anfragen den Stapel, und neue kommen hinzu. Sie nennt neben Orca einen Vorläufer für rekurrente Netze, das Cellular Batching von 2018.

Heute heißt das Verfahren Continuous Batching. Der Server vLLM nennt es unter seinen Merkmalen (README (externe Seite, github.com)), beim Server von llama.cpp ist es voreingestellt an und heißt dort auch dynamic batching (Doku (externe Seite, github.com)). LM Studio nutzt es für gleichzeitige Anfragen an seine Engine llama.cpp, ab deren Laufzeit v2.0.0 (Doku (externe Seite, lmstudio.ai)).

Der KV-Cache begrenzt den Stapel

Jede Anfrage im Stapel braucht ihren eigenen KV-Cache. Wie viel Platz er je Token belegt, rechnet Kapitel 04 vor. Wie viele Anfragen gleichzeitig in den Speicher passen, hängt deshalb daran, wie die Engine diesen Platz vergibt.

Die älteren Systeme legten den Cache einer Anfrage in einen zusammenhängenden Block, reserviert für die größtmögliche Länge, im Beispiel der Arbeit 2.048 Token. Nach der Messung der Arbeit zu vLLM (externe Seite, arxiv.org) hielten dort nur 20,4 bis 38,2 Prozent des Cache-Speichers tatsächlich Werte von Token. Der Rest, 61,8 bis 79,6 Prozent, war reserviert oder zerstückelt. Die Ankündigung (externe Seite, vllm.ai) vom Juni 2023 nennt 60 bis 80 Prozent Verschwendung, beide Angaben passen zueinander.

PagedAttention legt den Cache in kleine Blöcke fester Größe, die nach Bedarf vergeben werden und an beliebiger Stelle im Speicher liegen dürfen. Die Arbeit vergleicht das mit der Spei­cher­ver­wal­tung eines Betriebssystems: Blöcke entsprechen Seiten, Token entsprechen Bytes, Anfragen entsprechen Prozessen. vLLM kommt damit nach eigener Angabe fast ohne Verschwendung im Cache aus. Anfragen mit gleichem Anfang können sich Einträge teilen.

Ollama 0.40.6 reservierte den Cache mit der Laufzeit llama.cpp beim Laden für die volle Länge, so hat es Kapitel 04 gemessen. Laut FAQ (externe Seite, docs.ollama.com) wächst der Kontext mit jeder gleichzeitigen Anfrage. Für einen Nutzer kostet die Reservierung wenig. Bei vielen gleichzeitigen Nutzern entscheidet die Vergabe, wie viele in den Speicher passen.

Drei Faktoren messen gegen drei Basen

Für das Stapeln kursieren drei Faktoren. Jeder stimmt, und jeder vergleicht mit etwas anderem.

• 36,9-fach: Orca gegen FasterTransformer, an GPT-3 mit 175 Milliarden Parametern, bei gleicher Latenz (Orca (externe Seite, usenix.org), Juli 2022).
• 14- bis 24-fach: vLLM gegen die Bibliothek Transformers von Hugging Face, gegen den Server TGI 2,2- bis 2,5-fach, mit einer Antwort je Anfrage. Bei drei Antworten je Anfrage sind es 8,5 bis 15 und 3,3 bis 3,5. Gemessen an LLaMA-7B auf einer A10G und an LLaMA-13B auf einer A100 mit 40 GB (Ankündigung (externe Seite, vllm.ai), Juni 2023).
• 2- bis 4-fach: vLLM gegen FasterTransformer und Orca, bei gleicher Latenz (Arbeit zu vLLM (externe Seite, arxiv.org), September 2023).

Wer die 36,9 neben die 2 bis 4 legt, könnte vLLM für langsamer halten als Orca. Die Arbeit zu vLLM misst gegen einen eigenen Nachbau von Orca, denn Orca war nicht öffentlich verfügbar. Den Nachbau gibt es in drei Fassungen mit verschieden großer Reserve. Gegen FasterTransformer hält vLLM in derselben Arbeit eine bis zu 22-fach höhere Anfragerate bei ähnlicher Latenz.

Die größte Zahl der drei misst also ein neues Verfahren gegen ein älteres System ohne Stapel je Schritt. Die mittlere misst gegen eine Bibliothek und einen Server von Hugging Face, an zwei Modellen. Die kleinste misst gegen einen Nachbau von Orca, der den Stapel je Schritt schon beherrscht.

Durchsatz und Latenz ziehen in zwei Richtungen

Der Stapel hebt den Durchsatz, und der einzelne Nutzer wartet dafür länger. Die Anleitung von vLLM für gpt-oss (externe Seite, github.com) sagt das ausdrücklich: Für mehr Durchsatz müssen Token mehrerer Anfragen zusammen verarbeitet werden, und das erhöht die Latenz.

Dieselbe Anleitung übersetzt das in die Zahl der Grafikkarten je Instanz. Eine Karte bringt den besten Durchsatz je Karte. Zwei, vier oder acht bringen eine bessere Latenz je Nutzer. Gemeint ist die Zahl der Karten, auf die Tensor Parallelism das Modell verteilt. gpt-oss-120b passt auf eine A100 mit 80 GB, und mehr Karten können dem Durchsatz helfen. Wie ein Modell sich auf mehrere Karten verteilt, steht in Kapitel 04.

Weitere Karten dienen im Server also dem Tempo, sobald das Modell auf eine passt. Welches Ziel gilt, hängt am Einsatz. Ein Dienst mit vielen Nutzern zählt Token je Karte. Ein Assistent für wenige zählt die Wartezeit des Einzelnen.

Speculative Decoding hilft am meisten bei geringer Last

Das Verfahren erklärt Grundkurs, Kapitel 12: Ein kleiner Entwurf schlägt Token vor, und das große Modell prüft sie in einem Durchgang.

vLLM nennt in seiner Doku (externe Seite, docs.vllm.ai) zu Fassung 0.32.0 den Einsatzbereich. Es soll die Zeit zwischen zwei Token senken, vor allem bei geringer bis mittlerer Last und spei­cher­ge­bun­denem Betrieb. Die Übersicht derselben Seite führt eine Spalte für hohe Last. Dort bringen die Verfahren mit Entwurfsmodell, etwa EAGLE, noch einen mittleren bis hohen Gewinn, die einfachen wie n-gram einen mittleren. Die Anleitung für gpt-oss (externe Seite, github.com) enthält fertige Einstellungen für Server mit EAGLE-3.

Ein Grund für den Vorrang geringer Last liegt nahe: Stapeln und Spekulation nutzen dieselbe Reserve, die Rechenzeit, die beim Warten auf den Speicher frei bleibt. Das ist eine eigene Folgerung, die Doku begründet ihre Übersicht nicht. Am Einzelplatz läuft meist nur eine Anfrage, und die Reserve ist groß.

Die Programme stellen dabei verschiedene Bedingungen. vLLM verlangt voreingestellt, dass Entwurf und Hauptmodell dasselbe Vokabular haben. Eine Einstellung hebt das für Entwurfsmodelle auf. LM Studio verlangt dasselbe Vokabular (Doku (externe Seite, lmstudio.ai)). vLLM führt mehrere Verfahren, darunter n-gram und EAGLE (README (externe Seite, github.com)). Für gpt-oss-20b liegt ein Entwurf für EAGLE-3 als Datei bereit, die zweite Ebene nennt ihn.

Auch die Prüfung beschreiben beide verschieden. LM Studio nimmt laut seiner Doku nur Token an, die das Hauptmodell selbst gewählt hätte. Der Server vLLM nennt das Ziehen theoretisch verlustfrei, bis an die Grenze der Rechengenauigkeit. Dieselbe Einschränkung steht in der Arbeit von DeepMind (externe Seite, arxiv.org) zum Verfahren. Wie LM Studio bei einer Temperatur über 0 prüft, sagt seine Seite nicht.

Die Regel für das Annehmen beim Ziehen erklärt Grundkurs, Kapitel 12. Was das Verfahren auf einem Arbeitsrechner bringt, misst der Bericht Elf Wege, ein lokales Modell schneller zu machen.

Fremde Anfragen ändern die eigene Antwort

Im Server bestimmen die fremden Anfragen, wie groß der Stapel gerade ist. Nach einer Untersuchung von Thinking Machines (externe Seite, thinkingmachines.ai) hängt die Ausgabe einer Anfrage an genau dieser Größe. Dieselbe Frage kann deshalb bei gleicher Einstellung verschieden ausfallen, je nachdem, wer gleichzeitig fragt. Die Messung dazu und den Ausweg beschreibt Grundkurs, Kapitel 12.

Ein gemeinsamer Anfang wird einmal gerechnet

Viele Anfragen beginnen gleich, etwa mit derselben Systemanweisung. vLLM speichert den Cache solcher Anfänge und verwendet ihn wieder (README (externe Seite, github.com)). SGLang hat dafür ein eigenes Verfahren namens RadixAttention, das den Cache über mehrere Aufrufe hinweg automatisch wiederverwendet (Arbeit zu SGLang (externe Seite, arxiv.org)). Bei einem Anbieter wirkt ein solcher Zwischenspeicher bis in die Grenzen für Eingabe-Token, wie Grundkurs, Kapitel 11 zeigt.