Dieses Glossar erklärt die wichtigsten Begriffe rund um lokale Sprachmodelle in einfacher Sprache, jeweils der englische und der deutsche Begriff, mit einem praktischen Bezug statt einer Lexikon-Definition. Roter Faden ist eine kleine Geschichte: Ein Modell entsteht (Training), du stellst ihm eine Frage (Inferenz), daraus wird ein Agent, der selbstständig arbeitet, und am Ende ein Team aus mehreren Agenten. Fast jede Tempo- oder Speicher-Frage bei lokalen LLMs wird an einer dieser Stufen sichtbar.
Bevor ein Modell auch nur ein Wort beantworten kann, muss es lernen. Beim Training arbeitet es sich durch gewaltige Textmengen und justiert dabei seine Milliarden Parameter immer wieder nach, bis es die Muster von Sprache abbildet. Das ist extrem rechenintensiv, Wochen auf tausenden Hochleistungs-GPUs, und passiert beim Hersteller im Rechenzentrum (Meta für Llama, Alibaba für Qwen, …), nicht bei dir. Training macht man einmal; das Ergebnis sind die fertigen Modellgewichte, also die Datei, die du anschließend herunterlädst. Für deine lokale Performance zählt Training nur indirekt: Es legt fest, wie gut und wie groß das Modell ist, beeinflusst aber nicht, wie schnell es bei dir antwortet.
Nach dem Training ist das Modell "eingefroren": Es lernt nicht mehr dazu, es wendet an, was es gelernt hat. Genau dieser Anwendungs-Vorgang heißt Inferenz, das Modell nimmt deine Eingabe und erzeugt daraus Wort für Wort eine Antwort. Der entscheidende Unterschied zum Training: Inferenz passiert jedes Mal neu, wenn du etwas fragst, und läuft auf deiner Hardware. Training war einmalig und beim Hersteller; Inferenz ist alltäglich und bei dir. Deshalb dreht sich dieses ganze Glossar um die Inferenz, sie ist das, was auf deinem Rechner Zeit, Speicher und Strom kostet.
Die optionale Zwischenstufe: Man nimmt ein fertig trainiertes Modell und trainiert es mit einer kleinen, gezielten Datenmenge ein Stück weiter. Wichtig: Feintuning verändert die Parameter des Modells dauerhaft, das neu Gelernte steckt danach fest im Modell selbst. Es ist ein echter Trainings-Lauf und kann in der Cloud (auf gemieteten GPUs) oder lokal auf starker Hardware (z.B. einer DGX Spark) laufen. Praktische Beispiele: dem Modell einen festen Tonfall/Stil antrainieren, ein verlässliches Ausgabeformat beibringen, Branchen-Jargon oder eine eng umrissene Spezialaufgabe. Faustregel: Feintuning ändert Verhalten/Stil dauerhaft (aufwändig), für Wissen und aktuelle Fakten nimmt man dagegen fast immer den Kontext (siehe Akt 2), nicht Feintuning.
Das im Training gelernte Wissen ist auf den Stichtag eingefroren, an dem die Trainingsdaten zusammengestellt wurden. Ein Modell mit Cutoff Januar 2026 weiß von sich aus nichts über März 2026, egal wie schlau es ist. Wichtig zu verstehen: Ein Modell "recherchiert" beim Training nicht live im Internet; es saugt Muster aus einem festen Datenberg. Alles Neuere muss ihm zur Laufzeit hingelegt werden (siehe Websuche, RAG).
Das "Recherchieren im Internet", das du bei ChatGPT/Claude siehst, passiert nicht im Training, sondern zur Laufzeit über Werkzeuge: Das Modell ruft eine Websuche auf, bekommt die Treffer als frischen Text zurück, und der landet als ganz normale Eingabe-Tokens in seinem Kontextfenster. Das Modell "weiß" das Neue also nicht, es bekommt es vorgelegt. Modernes Training bringt dem Modell nur bei, wie man solche Werkzeuge bedient; das Suchen selbst ist Laufzeit.
Dasselbe Prinzip wie die Websuche, nur dass statt dem offenen Web eine eigene Dokumenten-Datenbank durchsucht wird (Handbücher, Firmen-Wiki, deine PDFs). Das Passende wird herausgesucht und in den Kontext geschoben, bevor das Modell antwortet. So beantwortet ein lokales Modell Fragen zu Daten, die es nie im Training gesehen hat, ohne Feintuning.
Es gibt zwei grundverschiedene Wege, ein Modell "anzupassen". Feintuning ändert das Modell selbst (siehe Akt 1), schwer, teuer, dauerhaft. Der Kontext-Weg ändert nichts am Modell: Eine Memory-Funktion (wie bei ChatGPT/Claude), RAG und der System-Prompt schieben nur Text als Eingabe-Tokens in den Kontext, das Modell bleibt unverändert, es wird bei jeder Frage neu "erinnert". Faustregel: Verhalten/Stil dauerhaft ändern → Feintuning. Wissen, aktuelle Fakten, eigene Dokumente flexibel zufüttern → Kontext/Memory/RAG. Für fast alles im Alltag ist es der Kontext-Weg.
Die kleinste Einheit, in der ein LLM Text verarbeitet, grob ein Wortteil. "Buchungssystem" können zwei oder drei Tokens sein, "und" ist eins. Faustregel Deutsch/Englisch: etwa 0,75 Wörter pro Token. Wichtig, weil alle Tempo-, Längen- und Speicherangaben in Tokens rechnen, nicht in Wörtern. Und es zählt beides: deine Frage (Eingabe) und die Antwort (Ausgabe). Eine 20-Token-Frage mit 300-Token-Antwort sind zusammen 320 Tokens. Auch jedes angehängte Dokument wird komplett zu Eingabe-Tokens (ein 2.000-Wörter-PDF ≈ ~2.700 Tokens), und zählt erneut, solange es im Kontextfenster liegt.
Reasoning-Modelle schreiben sich vor der eigentlichen Antwort eine oft lange interne Gedankenkette (der "Denk-Block", den man aufklappen kann). Das sind ganz normale Ausgabe-Tokens: Sie verbrauchen Zeit (das Modell muss sie Wort für Wort erzeugen), Geld und Platz im Kontextfenster. Eine kurze Antwort mit langem Vordenken kann mehr Tokens fressen als eine lange Antwort ohne.
Ein Bild wird nicht "gelesen", sondern in eine feste Menge Tokens nach Fläche/Auflösung umgerechnet, unabhängig davon, was draufzusehen ist. Lokale Bild-Modelle zerschneiden den Screenshot in Kacheln und geben pro Kachel einen festen Block visueller Tokens. Größenordnung: ein Desktop-Screenshot grob 1.700–2.400 Tokens, ein hochauflösender bis über 4.000. Konsequenz: Ein Screenshot voller Text kostet nach Pixeln, nicht nach Textmenge, oft ist es token-günstiger, den Text direkt zu kopieren (außer das Layout selbst ist die Information).
Das kleine Programm, das deinen Text in Tokens zerschneidet, bevor das Modell ihn sieht, und am Ende die Tokens wieder zu lesbarem Text zusammensetzt. Verschiedene Modelle benutzen verschiedene Tokenizer; deshalb ist "dieselbe" Frage bei Modell A 18 Tokens lang und bei Modell B 22.
Wie viel Text das Modell gleichzeitig "im Kopf" behalten kann, deine Frage, der bisherige Verlauf, angehängte Dokumente, alles zusammen, in Tokens. Zur Einordnung: 128.000 Tokens ≈ ~96.000 Wörter ≈ ein 300-Seiten-Buch; 1 Million Tokens ≈ mehrere dicke Bücher. Typische lokale Modelle haben 8.000–32.000, stärkere bis 128.000; Cloud-Spitzenmodelle bis zu ~1.000.000. Passt mehr nicht hinein, fällt das Älteste hinten raus und das Modell "vergisst" es. Aber Vorsicht: Das Fenster ist nur die erlaubte Obergrenze, ob du sie nutzen kannst, entscheidet der Speicher, denn jeder Token braucht Platz im KV-Cache. Ein riesiges Fenster nützt nichts, wenn der (V)RAM für den Cache fehlt.
Bevor auch nur ein Wort Antwort kommt, muss das Modell die komplette Eingabe einmal durchlesen und verarbeiten, und das ist alles, was im Kontext liegt: deine Frage, der System-Prompt, angehängte Dokumente, geladene Memory-/Regel-Dateien, der bisherige Verlauf, sogar die Werkzeug-Definitionen. Diese Phase ist eher rechenlastig (siehe Compute). Je mehr Kontext geladen ist, ein langes PDF, eine große Anleitungsdatei, desto länger das Prefill und desto später das erste Wort.
Die Phase danach, in der das Modell Wort für Wort die Antwort erzeugt, jedes neue Token braucht einen kompletten Durchlauf durchs Modell. Diese Phase ist speicherlastig (siehe Speicherbandbreite), nicht rechenlastig. Das ist der wichtigste Unterschied im ganzen Thema: Eingabe lesen ≠ Antwort schreiben, und beide werden von verschiedener Hardware ausgebremst.
Wie lange es dauert, bis das erste Wort der Antwort erscheint, gefühlt die "Reaktionsschnelligkeit". Hängt fast vollständig vom Prefill ab: kurze Frage → fast sofort; langes Dokument davorgehängt → spürbare Pause, bevor es losgeht.
Wie lange zwischen zwei aufeinanderfolgenden Antwort-Wörtern vergeht, das "Tipptempo", das du beim tokenweisen Erscheinen der Antwort siehst. Niedrig = flüssig, hoch = stockend.
Die wichtigste Alltagszahl: wie viele Tokens das Modell pro Sekunde ausspuckt. Etwa 15–20 t/s fühlen sich flüssig an (schneller als die meisten lesen), unter ~5 t/s wird es zäh. Achtung: Es gibt zwei Durchsatz-Werte, wie schnell die Eingabe gelesen wird (Prefill) und wie schnell die Antwort entsteht (Decode). Benchmarks meinen meist Letzteres.
Oberbegriff für "wie lange dauert's, bis etwas passiert". Gegenstück zum Durchsatz: Durchsatz misst die Menge pro Zeit, Latenz die Wartezeit bis zur Reaktion. TTFT und TPOT sind die zwei konkreten Latenz-Maße, die du im Alltag spürst.
Die internen Stellschrauben, die beim Training gelernt wurden, angegeben in Milliarden, z.B. 7B, 14B, 70B. Mehr Parameter = potenziell klüger, aber langsamer und speicherhungriger. Die Parameterzahl bestimmt grob, ob ein Modell überhaupt auf deine Maschine passt.
Die Zahl vor dem "B" ist die Parameterzahl in Milliarden (engl. billion), gelegentlich "M" für Millionen bei Mini-Modellen. Grobe Alltags-Einordnung (mit Quantisierung Q4):
gut für einfache Zusammenfassungen, Klassifizierung, Autovervollständigung.
Rechnern. Die ideale Balance für einen brauchbaren Assistenten auf normaler Hardware.
Mac mit genug Speicher.
Reasoning), verlangt schon viel VRAM oder viel vereinheitlichten Speicher.
starker Hardware (Mac Studio, DGX Spark, mehrere GPUs) sinnvoll lokal zu betreiben.
Faustregel: Mehr Milliarden = klüger, aber jede Stufe vervielfacht Speicherbedarf und senkt die Tokens pro Sekunde. Die ehrliche Frage ist nie "welches ist das beste Modell", sondern "welche Größe läuft auf meiner Hardware noch zügig".
Ein Modellname wie Llama 3.1 8B nennt drei Dinge: Familie (Llama), Version (3.1) und Größe (8B). Die Familie sagt, wer es gebaut und unter welcher Lizenz veröffentlicht hat. Die wichtigsten für lokale Nutzung:
2026 oft die lokale Top-Wahl.
Reasoning-Linie Magistral (nicht verwechseln).
Welche Familie "richtig" ist, hängt vom Zweck ab, alle laufen über dieselben Inferenz-Maschinen.
Die Parameter, wie sie als Datei auf der Platte liegen und in den Speicher geladen werden. "Gewichte herunterladen" heißt: die mehrere Gigabyte große Datei eines Modells holen. Ein 7B-Modell in mittlerer Komprimierung sind grob 4–5 GB, ein 70B-Modell schnell 40 GB+.
Der sehr schnelle Speicher direkt auf der Grafikkarte. Die zentrale Faustregel lautet: Passt das ganze Modell in den VRAM, läuft es schnell. Passt es nicht und muss in den normalen Arbeitsspeicher ausweichen, bricht die Geschwindigkeit drastisch ein, oft um ein Vielfaches. Wie viel VRAM du hast, entscheidet faktisch, welche Modellgröße für dich sinnvoll ist.
Der Hauptspeicher des Rechners. Größer und billiger als VRAM, aber bei klassischen PCs mit extra Grafikkarte deutlich langsamer angebunden. Ein Modell, das nicht in den VRAM passt, landet teilweise hier, mit dem genannten Tempoeinbruch.
Bei Apple-M-Chips (und ähnlichen Architekturen) teilen sich Prozessor und Grafikeinheit einen großen, schnellen Speicher, die Trennung VRAM/RAM entfällt. Deshalb kann ein Mac mit viel vereinheitlichtem Speicher große Modelle laufen lassen, die auf einer Consumer-Grafikkarte mit wenig VRAM gar nicht erst hineinpassen. Einer der Gründe, warum Macs für lokale LLMs beliebt sind.
Wie schnell Daten zwischen Speicher und Rechenkern fließen, in GB/s. Das ist bei lokalen LLMs fast immer der entscheidende Flaschenhals, nicht die rohe Rechenleistung. Der Grund: Für jedes einzelne Antwort-Token muss das gesamte Modell einmal komplett durch den Speicher gelesen werden. Eine schnelle Rechen-GPU mit langsamem Speicher bringt wenig; eine breite Speicheranbindung (Apple M-Pro/Max/Ultra, Server-GPUs) bringt direkt mehr Tokens pro Sekunde.
Wie viele Rechenoperationen die Hardware pro Sekunde schafft. Wichtig vor allem fürs Prefill (das Einlesen langer Eingaben). Bei der eigentlichen Antwort-Erzeugung ist Compute meist nicht der Begrenzer, da gewinnt die Speicherbandbreite. Deshalb kann ein langes PDF langsam eingelesen (compute-limitiert), die Antwort danach aber zügig geschrieben werden (bandbreiten-limitiert).
Die Kernunterscheidung: Eine Aufgabe ist speichergebunden, wenn sie auf Daten aus dem Speicher wartet (typisch: Antwort schreiben), und rechengebunden, wenn sie auf die Recheneinheit wartet (typisch: langes Prefill, viele parallele Anfragen). Wer weiß, welcher Fall vorliegt, weiß auch, welche Hardware-Aufrüstung etwas bringt, und welche verpufft.
Jede der Milliarden Zahlen im Modell wird mit einer bestimmten Anzahl Bits abgelegt, und genau das bestimmt Größe und Tempo. Von genau/groß nach grob/klein:
Präzision. "FP" = floating point (Fließkomma).
(moderne Nvidia-Blackwell-GPUs) nativ schnell gerechnet. Aktueller Liebling für effiziente Server-Inferenz.
beliebt als "sicherer" Kompromiss.
8 Bit knapp nicht in den Speicher passt.
geringer Qualitätsverlust (bei guten Verfahren nur wenige Prozent).
Faustregel: Halbierst du die Bit-Tiefe, halbierst du grob den Speicherbedarf. Weniger Bits = kleiner und schneller, aber irgendwann sichtbar dümmer.
Das Modell wird verkleinert, indem seine Zahlen gröber gespeichert werden, etwa von 16 auf 4 Bit (siehe Rechengenauigkeit). Resultat: deutlich kleiner und schneller, bei meist nur geringem Qualitätsverlust (ein gutes 4-Bit-Format liegt grob 3–5 % über dem Perplexität-Wert von FP16). Die Kürzel Q4 / Q5 / Q6 / Q8 ("Quant 4", "Quant 8" …) geben den Grad an, niedriger = kleiner/schneller, höher = genauer; Q4–Q5 ist der übliche beste Kompromiss für Privatrechner. Zusätze wie Q4_K_M (GGUF), AWQ oder GPTQ bezeichnen die genaue Methode. Quantisierung ist oft das, was ein Modell überhaupt erst auf deine Hardware bringt.
Die CPU (Hauptprozessor) ist der Allrounder des Rechners, flexibel, aber für die massiv parallele Mathematik eines LLM zu langsam. Die GPU (Grafikprozessor) rechnet tausende Operationen gleichzeitig und ist deshalb die natürliche Heimat der Inferenz. Lokale LLMs laufen zwar zur Not rein auf der CPU (langsam), entfalten ihr Tempo aber erst auf der GPU, bzw. auf Apples M-Chips, wo CPU, GPU und vereinheitlichter Speicher eng verzahnt auf einem Chip sitzen. Das GPU-Offloading verteilt das Modell zwischen beiden.
Während das Modell die Antwort schreibt, merkt es sich das bereits Gelesene/Geschriebene in einem Zwischenspeicher, damit es nicht bei jedem neuen Token alles neu berechnen muss. Dieser Cache wächst mit der Länge von Eingabe + Antwort und belegt zusätzlichen (V)RAM, zusätzlich zu den Gewichten. Grobe Formel: 2 × Schichten × Köpfe × Kopf-Dimension × Tokens × Bytes. Bei der kurzen Frage ist er winzig; bei einem Agenten mit langem Verlauf oder vielen visuellen Tokens kann er den Speicher sprengen.
Ein Agent ruft das Modell nicht einmal, sondern dutzende Male auf, und schleppt dabei den bisherigen Verlauf mit. Mit jedem Schritt wächst der Kontext: mehr Tokens einzulesen (längeres Prefill, spätere Reaktion), größerer KV-Cache (mehr Speicher). Deshalb wird ein Agent im Verlauf oft langsamer, nicht schneller, und stößt irgendwann an die Grenze des Kontextfensters.
Wenn viele Aufrufe denselben Anfang haben (etwa eine lange Arbeitsanweisung, die jeder Agenten-Schritt mitschickt), kann das System diesen Teil einmal verarbeiten und das Ergebnis wiederverwenden, statt ihn jedes Mal neu einzulesen. Spart Prefill-Zeit massiv, gerade bei Agenten mit langer, gleichbleibender Systemanweisung.
Bevor das Modell antworten kann, müssen die mehrere Gigabyte großen Modellgewichte erst von der SSD in den Speicher geladen werden. Das passiert einmal beim Start und kann je nach Modellgröße und Platten-Tempo Sekunden bis über eine Minute dauern. Danach bleibt das Modell idealerweise "warm". Relevant für Agenten, die zwischendurch das Modell wechseln.
Moderne Modelle werben mit riesigen Kontextfenstern (128.000 Tokens und mehr). Technisch machbar, aber jeder zusätzliche Token kostet Prefill-Zeit und KV-Cache-Speicher, und die Qualität der Nutzung des ganz langen Kontexts ist nicht garantiert (das Modell "verliert" Infos in der Mitte). Für Agenten heißt das: nicht alles in den Kontext kippen, sondern gezielt das Relevante.
Wie viele Anfragen das System gleichzeitig bearbeitet. Für dich allein an der Frage = 1. Sobald dein Team aus fünf Agenten parallel läuft, teilen sich fünf Aufgaben dieselbe Hardware. Mehr Nebenläufigkeit erhöht den Gesamt-Durchsatz, macht aber die einzelne Antwort langsamer und braucht mehr Speicher (jeder Agent hat seinen eigenen KV-Cache).
Die wichtigste Klarstellung fürs Team: Jeder Agent hat sein eigenes, voll getrenntes Kontextfenster, es wird nicht zu einem großen Fenster zusammengezählt. Was sich unterschiedlich verhält: Laufen alle Agenten auf demselben Modell, werden die Modellgewichte nur einmal in den Speicher geladen (nicht fünfmal!), nur der KV-Cache summiert sich pro Agent. Lokal ist also der Speicher die geteilte Ressource; in der Cloud summieren sich Kosten und Durchsatz (fünf Agenten = fünffacher Token-Verbrauch). Gute Architektur gibt deshalb jedem Agenten ein frisches, kleines Fenster und reicht nur Zusammenfassungen weiter, statt alles in ein Riesenfenster zu stopfen, so bleibt das Eltern-Fenster schlank.
Der Trick, der Nebenläufigkeit effizient macht: Statt fünf Anfragen nacheinander abzuarbeiten, rechnet das System sie gemeinsam in einem Stapel. Weil das Modell beim Schreiben sowieso speichergebunden ist (es wird ohnehin einmal komplett durch den Speicher gelesen), kostet es kaum mehr, dabei gleich fünf Antworten parallel voranzutreiben. "Continuous" heißt: fertige Anfragen verlassen den Stapel, neue rücken nach, ohne Leerlauf. Hauptgrund, warum ein gutes Server-Setup ein Vielfaches an Gesamt-Durchsatz schafft.
Wenn es nicht mehr um ein Token, sondern um ganze Anfragen geht: Wie viele komplette Aufgaben das System pro Sekunde (oder Minute) abschließt. Die relevante Zahl, sobald aus dem einen Agenten ein Team oder ein Dienst für mehrere Nutzer wird.
Die zentrale Stellschraube beim Team-Betrieb: Du kannst den Gesamt-Durchsatz hochfahren (viele parallel, große Stapel), dann wartet aber jede einzelne Anfrage länger. Oder du optimierst auf schnelle einzelne Antworten, dann liegt die Hardware zwischendurch brach. Beides gleichzeitig geht nicht; man wählt je nach Zweck (interaktiver Chat vs. Massen-Verarbeitung im Hintergrund).
Die Software, die die Gewichte lädt und die Inferenz ausführt. Bekannte Vertreter:
Die Wahl der Engine entscheidet oft mehr über das Tempo als das Modell selbst.
Das Dateiformat der Gewichte. GGUF ist das verbreitete Format für lokale Nutzung (llama.cpp/Ollama), enthält das quantisierte Modell in einer Datei. safetensors ist das gängige Format im GPU-/Forschungsumfeld. Mischen geht nicht beliebig, Engine und Format müssen zusammenpassen.
Die Schicht, über die die Engine mit der Hardware spricht: CUDA (Nvidia-GPUs), Metal (Apple), ROCm (AMD), Vulkan (herstellerübergreifend). Welches Backend sauber unterstützt wird, entscheidet mit, ob deine Hardware ihr volles Tempo abruft.
Eine Bauart, bei der das Modell aus vielen "Experten" besteht, von denen pro Token nur wenige aktiv sind. Folge: Ein Modell kann insgesamt riesig sein (viel Speicher nötig), aber pro Token nur einen Bruchteil rechnen (schnell). Deshalb die wichtige Unterscheidung Gesamt-Parameter (was in den Speicher muss) vs. aktive Parameter (was das Tempo bestimmt), ein Modell mit 35B gesamt, aber nur 3B aktiv, braucht den Speicher eines großen Modells, läuft aber fast so schnell wie ein kleines.
Eine clevere Umsetzung des rechenintensivsten Modell-Bausteins ("Attention"), die den Speicher schonender und schneller nutzt, besonders spürbar bei langem Kontext. Meist einfach ein Schalter, den man aktiviert.
Ein kleines, schnelles Modell schlägt mehrere nächste Tokens "auf Verdacht" vor, das große Modell prüft sie in einem Rutsch und übernimmt die richtigen. Resultat: spürbar mehr Tokens pro Sekunde, ohne Qualitätsverlust, solange das kleine Modell oft richtig rät.
Eine Technik (bekannt aus vLLM), die den KV-Cache in kleine Blöcke aufteilt und wie Arbeitsspeicher-Seiten verwaltet, statt für jede Anfrage einen großen Block zu reservieren. So passen mehr parallele Anfragen in denselben Speicher, direkt relevant für hohe Nebenläufigkeit im Team-Betrieb.
Apples Top-Desktop mit M3-Ultra-Chip, 819 GB/s Speicherbandbreite (die höchste der Einzelmaschinen) und bis zu 256 GB vereinheitlichtem Speicher. Weil der große, schnelle Speicher nicht zwischen CPU und GPU geteilt werden muss, laufen hier Modellgrößen, die auf einer Consumer-GPU gar nicht hineinpassen. Hinweis: Die früher mögliche 512-GB-Option wurde Anfang 2026 (DRAM-Knappheit) gestrichen, 256 GB sind aktuell das Maximum.
Ein kleiner Desktop von Nvidia speziell für lokale KI (Grace-Blackwell-Chip GB10, 128 GB vereinheitlicht). Punktet weniger über pure Tokens pro Sekunde, die Speicherbandbreite liegt mit ~200 GB/s deutlich unter dem Mac, als über Kapazität und schnelles Prefill; gut zum lokalen Entwickeln und Feintunen. Lässt sich zu 2–4 Geräten koppeln. Preis um ~4.700 $.
Ein 4,5-Liter-Mini-PC mit Ryzen-AI-Max-Chip, 128 GB vereinheitlichtem Speicher und 256 GB/s Bandbreite, ab ~1.999 $ rund halb so teuer wie die DGX Spark. Stark für 7B–70B-Modelle, leise, Backend über ROCm/Vulkan. Software-Ökosystem etwas dünner als bei Nvidia/Apple, aber brauchbar.
Sehr hohe Speicherbandbreite und damit Spitzen-Durchsatz, aber begrenzt durch ihren VRAM (grob 24 bzw. 32 GB). Blitzschnell bei Modellen, die hineinpassen; alles darüber muss ausgelagert werden und wird langsam. Top für 7B–14B, eng ab ~30B.
Mehrere DGX Sparks (über ConnectX) oder mehrere Mac Studios (über Thunderbolt 5) lassen sich koppeln, um ihren Speicher zu bündeln. Aber: Die Verbindung zwischen den Geräten ist viel langsamer als der Speicher innerhalb eines Geräts, die Skalierung ist sublinear (zweite Maschine bringt grob +30 %, nicht +100 %). Faustregel: Ein großes System schlägt zwei kleine bei Latenz, Kosten und Einfachheit; clustern lohnt nur, wenn ein Modell partout nicht in eine einzelne Maschine passt.
Eine Messzahl dafür, wie "überrascht" ein Modell vom korrekten nächsten Wort ist, niedriger = besser. Wird vor allem benutzt, um zu prüfen, wie viel Qualität die Quantisierung kostet (z.B. Q4 vs. Q8). Keine Performance-Zahl im engeren Sinn, aber der Gegenspieler, gegen den man Tempo-Gewinne abwägt.
Ein verbreiteter Test, bei dem ein Modell echte Fehler in echten Software-Projekten beheben muss. Gibt einen groben Vergleichswert für "Coding-Stärke". Zur Einordnung Mitte 2026: das beste lokal lauffähige Modell liegt grob bei ~73 %, ein Frontier-Cloud-Modell bei ~95 %, die Lücke ist real, aber für viele Alltagsaufgaben kleiner als sie klingt.
Steuert, wie deterministisch oder variabel die Antwort ausfällt, niedrig = vorhersehbar/faktisch, hoch = vielfältiger/kreativer. Beeinflusst die Antwortqualität und -art, nicht das Tempo, wird aber oft im selben Atemzug genannt.