Zum Hauptinhalt springen

Diffusion-LLMs: die Modelle, die nicht von links nach rechts schreiben

Experte

Jedes Modell auf AILmanac erzeugt Text bisher auf dieselbe Weise: ein Token, dann das nächste, von links nach rechts, endlos. Eine andere Modellfamilie tut das nicht. Sie beginnt mit einer leeren Leinwand maskierter Positionen, sagt alle gleichzeitig voraus, behält die, bei denen sie sich sicher ist, und wiederholt das. Position 40 kann vor Position 7 entschieden werden.

Die Zahlen sind der Grund, warum sich überhaupt jemand dafür interessiert. Inceptions Mercury 2 — ein Reasoning-Modell — läuft Berichten zufolge mit 1.009 Tokens/Sek. auf Blackwell-GPUs bei 1,7 s End-to-End-Latenz, also etwa 8–14× schneller als vergleichbare Wettbewerber mit aktiviertem Reasoning (The Decoder). Googles experimentelles Gemini Diffusion sampelt mit 1.479 Tokens/Sek. ohne Overhead, gegen die 272,4 von Gemini 2.5 Flash (Techmeme-Übersicht).

Und trotzdem sagt dir das README von LLaDA — dem 8B-Open-Weight-Modell, das den Ansatz im großen Maßstab belegt hat —, dass seine Qualität am höchsten ist, wenn die Anzahl der Sampling-Schritte der Antwortlänge entspricht. Ein Forward Pass pro Token. Genau wie bei einem autoregressiven Modell, aber ohne KV-Cache, also langsamer.

Beides ist wahr. Diese Lektion ist die Brücke dazwischen: was der Algorithmus tatsächlich macht, welcher Regler die Geschwindigkeit kauft und was sie kostet, die zwei strukturellen Grenzen, die frühe Diffusion-LLMs unbrauchbar machten, und der Fix, der es in die Praxis gebracht hat, sowie die drei Stolperfallen (Streaming, Längenabrechnung und eine Jailbreak-Klasse, die es bei autoregressiven Modellen nicht gibt), die du kennen musst, bevor du so ein Modell in Produktion nimmst.

What you'll learn
  • Masked-Diffusion-Generierung mit Leinwand, Denoising-Pass und Commit-Entscheidung beschreiben — und sagen, was bidirektionale Attention bringt und was sie kostet
  • Den Steps-Regler richtig benutzen: Tokens pro Forward Pass berechnen und erklären, warum der Conditional-Independence-Fehler aggressive Parallelität falsch macht und nicht bloß schlechter
  • Erklären, warum Block Diffusion in jedem dLLM steckt, das du heute tatsächlich aufrufen kannst — es hat KV-Cache, variable Ausgabelänge und Token-Streaming zurückgebracht
  • Die Aufgaben auswählen, bei denen ein dLLM wirklich gewinnt: Infilling und Edits in beliebiger Reihenfolge, latenzkritische Voice-Anwendungen und begrenzte Entscheidungen — nicht „alles, nur schneller“
  • Einen offenen dLLM-Endpunkt an der Grenze als nicht alignt behandeln, weil Masked-Infill-Prompts das Alignment auf eine Weise umgehen, wie autoregressive Verweigerungen es nicht können

Der Mechanismus, in einem Diagramm, das du dir vorstellen musst​

Die Schleife eines autoregressiven (AR) Modells lautet: den gesamten Prefix lesen, eine Wahrscheinlichkeitsverteilung über eine Position ausgeben (die nächste), samplen, anhängen, wiederholen. Der KV-Cache macht das günstig — die Keys und Values für jedes früher erzeugte Token wurden einmal berechnet und ändern sich nie, weil Attention kausal ist und rechts davon noch nichts existiert.

Ein Masked-Diffusion-LLM dreht das um. Attention ist bidirektional: jede Position attendiert auf jede andere Position, in beide Richtungen. In einem einzigen Forward Pass erzeugt das Modell also gleichzeitig eine Verteilung für jede maskierte Position. Generierung wird zur iterativen Verfeinerung einer ganzen Antwort, nicht zu einem Gang entlang dieser Antwort.

Guided walkthrough1 of 5
  1. Lege eine Generierungslänge L fest. Fülle alle L Positionen mit einem speziellen Mask-Token. Bei einem reinen Masked-dLLM (LLaDA, Dream) ist L vor dem ersten Forward Pass fixiert — das Modell lässt die Sequenz nicht unterwegs wachsen.

Die letzte Zeile ist die, die man sich merken sollte. Ein AR-Modell ist bei einem Token pro Forward Pass festgenagelt. Ein Diffusion-LLM lässt dich wählen. DiffusionGemma, Googles Open-Weight-Beitrag, berichtet von etwa 20 Tokens pro Forward Pass, während es Blöcke von 256 parallel verfeinert — so kommt es auf ~1.500 Output-Tokens/Sek. auf einer einzelnen H100 (DiffusionGemma Technical Report).

Der Steps-Regler, und warum ihn aufzudrehen falsch ist und nicht bloß verlustbehaftet​

Dream 7B legt den Regler explizit offen. Seine Funktion diffusion_generate() dokumentiert steps als „diffusion timesteps“, wobei pro Schritt max_new_tokens / steps Tokens erzeugt werden, und merkt unmissverständlich an, dass weniger Schritte schneller, aber grober sind (DreamLM/Dream, Apache-2.0).

Warum also nicht immer wenige Schritte verwenden? Weil der Fehler, den das einführt, kein Rauschen ist — es ist ein spezifischer, benennbarer Bug.

Ein einzelner Forward Pass gibt dir für jeden maskierten Slot eine marginale Verteilung: die Wahrscheinlichkeit eines Tokens an dieser Position, gemittelt über alles, was noch unbekannt ist. Wenn du zwei Slots aus demselben Pass committest, samplest du aus dem Produkt ihrer Marginalverteilungen, nicht aus ihrer gemeinsamen Verteilung. Jede Abhängigkeit zwischen ihnen wird stillschweigend verworfen. Die Autoren von Fast-dLLM nennen die Ursache direkt: die Generierungsqualität verschlechtert sich bei parallelem Decoding, weil Masked-Diffusion-Modelle Tokens unabhängig voneinander aus Marginalwahrscheinlichkeiten samplen, obwohl die echte gemeinsame Verteilung Abhängigkeiten hat (Fast-dLLM, arXiv:2505.22618).

Die Intuition: Frag nach einer Stadt, und zwei benachbarte Slots bewerten vielleicht „New“ und „Delhi“ jeweils als wahrscheinlichstes Token für ihre eigene Position, weil „New York“ und „New Delhi“ beide plausibel sind. Committe beide in einem Pass, und du bekommst keines von beiden. Der Fehlermodus von zu parallelem Decoding ist nicht vagere Prosa, sondern selbstbewusst zusammengesetzter Unsinn an den Nahtstellen.

Der Fix, der das Feld praktikabel gemacht hat, heißt confidence-aware parallel decoding: berechne pro maskiertem Slot eine Konfidenz (typischerweise die maximale Softmax-Wahrscheinlichkeit), committe nur die Slots oberhalb eines Schwellenwerts, und wenn keiner ihn überschreitet, committe den höchsten einzelnen, damit die Schleife weiter Fortschritt macht. Tokens, die nahezu unabhängig sind, werden zusammen dekodiert; Tokens, die voneinander abhängen, warten. Fast-dLLM berichtet über Benchmarks hinweg von einer bis zu 27,6× höheren Durchsatzleistung bei LLaDA und Dream mit minimalem Genauigkeitsverlust — trainingsfrei, nur eine Änderung im Decoding.

Das ist die Form dieses gesamten Forschungsfelds: die Parallelität ist gratis, die Unabhängigkeit ist es nicht, und die Arbeit besteht darin zu erkennen, welche Tokens gefahrlos zusammen gehen können.

What you'll learn
  • Ein Konfidenzschwellenwert ist ein Qualitätsregler, über den man tatsächlich nachdenken kann: höherer Schwellenwert bedeutet weniger committete Tokens pro Pass, mehr Passes, langsamer, näher an AR-Qualität. Fast-dLLM v2 berichtet bei Schwellenwert 0,9 von einem 2,6×-Speedup auf GSM8K mit minimalem Genauigkeitsverlust — das ist die Art Einstellung, mit der man anfängt, nicht „alles committen“.

Die zwei strukturellen Grenzen — und Block Diffusion, weshalb du heute überhaupt eines aufrufen kannst​

LLaDAs eigenes Repository listet seine Effizienzbeschränkungen ohne Beschönigung auf: feste Kontextlänge beim Sampling, keine KV-Cache-Unterstützung und verschlechterte Leistung, wenn die Sampling-Schritte unter die Antwortlänge fallen. Die Autoren stellen das als bewusste Entscheidung dar — sie wollten die Obergrenze des Ansatzes finden, bevor sie ihn optimieren (ML-GSAI/LLaDA, MIT, ~4k Sterne, Base- und Instruct-Gewichte plus LLaDA 1.5, LLaDA-MoE-7B-A1B und iLLaDA-Varianten).

Stapelt man das auf, ist ein reines Masked-dLLM als Produkt nahezu unbrauchbar:

  1. Kein KV-Cache. Bidirektionale Attention bedeutet, dass jeder Pass den Kontext jedes Tokens ändern kann, also sind gecachte Keys und Values ungültig. Du berechnest die gesamte Sequenz in jedem Schritt neu.
  2. Feste Ausgabelänge. Du musst L vor der Generierung festlegen. Zu klein schneidet ab; zu groß verschwendet Rechenzeit auf Positionen, die du wegwirfst.
  3. Latenz schlechter als bei AR. Punkt 1 und 2 zusammen können ein „paralleles“ Modell End-to-End langsamer machen als das sequenzielle, das es ersetzt.

Block Diffusion löst alle drei, indem es sich weigert, rein zu sein. Generiere in Blöcken: konditioniere autoregressiv auf vorherige Blöcke und lass die Diffusion innerhalb des aktuellen Blocks laufen. Das liefert flexible Sequenzlänge und KV-Caching zwischen Blöcken — die BD3-LM-Formulierung, ein ICLR-2025-Oral (arXiv:2503.09573, kuleshov-group/bd3lms).

Fast-dLLM v2 (arXiv:2509.26328) zeigt, wie eine getunte Version aussieht, und die Details sind es wert, sie zu kennen, denn sie erklären das Anbieterverhalten, das du beobachten wirst:

  • Hybride Attention-Maske. Blockdiagonal (bidirektional) innerhalb eines Blocks, blockkausal (von links nach rechts) zwischen Blöcken. Bidirektionaler Kontext dort, wo er hilft, AR-Semantik dort, wo der Cache lebt.
  • Zwei Cache-Ebenen. Ein Cache auf Blockebene, der fertige Blöcke als saubere Prefix-Kontexte hält, plus ein Sub-Block-Cache (DualCache) für die Neuberechnung, die das Decoding innerhalb eines Blocks weiterhin braucht.
  • Komplementäres Maskieren im Training. Jedes Sample wird in zwei Ansichten mit den Masken m und 1 − m dupliziert, sodass jedes Token sowohl als Mask-Target als auch als Kontext supervidiert wird.
  • Berichtete Ergebnisse. Bis zu 2,5× schneller als normales AR-Decoding; 1,8× bei Batch-Größe 64 auf H100s; ein durchschnittlicher 7B-Benchmark-Score von 60,3 gegen 57,6 von Dream, darunter HumanEval 63,4 vs. 57,9 und GSM8K 62,0 vs. 39,2.

Und die Trainingskosten sind das Detail, das das Feld neu rahmt: Fast-dLLM v2 berichtet von Fine-Tuning aus einem AR-Modell auf rund 1 Mrd. Tokens — etwa 500× weniger als die 580 Mrd. von Dream — ein 7B-Modell, trainiert in ~12 Stunden auf 64 A100s.

Diffusion ist ein Decoding-Modus, den man nachrüsten kann, keine eigene Spezies​

DiffusionGemma macht diesen Punkt unübersehbar. Es wird nicht von Null trainiert: Es fine-tunt Gemma 4, ein Mixture-of-Experts-Modell mit 3,8 Mrd. aktivierten und 25,2 Mrd. Gesamtparametern, in ein Diffusionsmodell, und zwar mit weniger als 10 % des gesamten Trainings-Token-Budgets des ursprünglichen AR-Modells — supervidiertes Denoising-Fine-Tuning, dann Reinforcement Learning und Sampler-Distillation (arXiv:2608.00146, CC-BY-4.0-Gewichte).

Was die Umwandlung überlebt, ist der überraschende Teil. Der Report besagt, dass es den Thinking-Modus, die multimodalen Eingaben und die langen Kontexte des Basismodells behält — und die Fähigkeit zur autoregressiven Generierung bewahrt, mit nur geringer Verschlechterung. Ein Satz Gewichte, zwei Decoding-Modi.

Wenn dieses Ergebnis Bestand hat, hört „Diffusion-LLM“ auf, eine eigene Produktkategorie zu sein, und wird zu einer Serving-Option: dieselbe Familie, mit einem Parallelitätsregler auf der Inferenzseite. Das ist eine weit folgenreichere Behauptung als jeder einzelne Tokens-pro-Sekunde-Rekord, und es ist der Grund, den Mechanismus jetzt zu lernen und nicht erst dann, wenn ein Anbieter bei einem Modell, das du schon nutzt, einen Schalter umlegt.

Worin ein Diffusion-LLM tatsächlich besser ist​

Geschwindigkeit ist die Schlagzeile und der schwächste Teil der Argumentation, denn Geschwindigkeit ist umstritten — spezialisierte AR-Hardware liefert ebenfalls hunderte Tokens pro Sekunde (siehe Token-Geschwindigkeit). Die dauerhaften Vorteile sind die, die aus der Form des Algorithmus folgen.

Generierung in beliebiger Reihenfolge und natives Infilling. Weil du auswählst, welchen Slot du committest, kannst du ein Loch mitten in einer Sequenz lassen und es vom Modell mit vollem Kontext auf beiden Seiten füllen lassen. Dream legt das als Parameter alg offen — origin (zufällige Reihenfolge), maskgit_plus (Top-1-Konfidenz), topk_margin (top1 − top2-Marge), entropy — plus alg_temp, um diesen Strategien Zufälligkeit beizumischen. Für Code-Edits, Template-Vervollständigung oder das Füllen von Feldern in einem festen JSON-Skelett passt das strukturell besser, als ein AR-Modell zu bitten, eine ganze Datei neu auszugeben, um Zeile 40 zu ändern.

Latenzkritische Interaktion. Inceptions Mercury Voice wirbt mit einer Time-to-First-Token unter 170 ms bei 128K Kontext, zum Zeitpunkt des Schreibens zu 0,20 $ / 1,50 $ pro Million Input-/Output-Tokens. Voice ist der klarste Fall, in dem Latenz das Produkt ist; unsere Seite zu Full-Duplex-Voice-AI erklärt, warum diese Schwelle wichtig ist.

End-to-End-Reasoning-Durchlaufzeit. Die berichteten 1,7 s von Mercury 2 für eine komplette Reasoning-Antwort sind eine andere Aussage als Durchsatz — es ist die Zahl, die eine Agent-Schleife tatsächlich spürt, Zug um Zug.

Begrenzte Antworten statt Prosa. Inceptions Mercury Decide gibt eine Auswahl, einen Score oder ein Ja/Nein mit einer kalibrierten Wahrscheinlichkeit zurück, die direkt am Modell abgelesen und nicht als Text ausgeschrieben wird — berichtet mit bis zu 14 Entscheidungen pro Sekunde, was „auf jeden Fall anwenden und die unsicheren eskalieren“ erschwinglich macht. Die Kategorie und ihre Einschränkungen werden ausführlich bei System-One-Entscheidungsmodellen behandelt; das Diffusions-Backbone ist dort ein Implementierungsdetail, nicht der Punkt.

Preisdruck. Mercury 2.5 listet derzeit 260K Kontext zu 0,04 $ / 0,15 $ pro Million Input-/Output-Tokens (Aktionspreis, regulär 0,20 $ / 0,75 $) mit gecachtem Input zu 0,004 $ pro Million. Behandle Aktionspreise als temporär und kalkuliere deine Rechnung mit Listenpreisen.

Drei Stolperfallen, bevor du eines ausrollst​

Watch out
  • Tokens/Sek. werden bei der vom Anbieter gewählten Parallelität gemessen. Deine Qualitätsschwelle verlangt vielleicht mehr Schritte, und das kostet dich den Speedup. Benchmarke mit deinen eigenen Prompts an deiner eigenen Genauigkeitsschwelle.
  • Die Ausgabe ist nicht endgültig von links nach rechts. Nur Blockgrenzen sind monoton; innerhalb eines Blocks können Slots weiterhin maskiert oder revidiert werden. Jede UI und jeder Parser, der annimmt „Token N wird sich nie ändern“, liegt falsch.
  • Ein reines Masked-dLLM rechnet und berechnet eine Länge ab, die du im Vorhinein gewählt hast. Block Diffusion reduziert das auf Granularität pro Block — es beseitigt es nicht.

Die dritte verdient mehr als einen Aufzählungspunkt, denn sie ist eine Sicherheitseigenschaft und hat kein autoregressives Gegenstück.

Das Alignment eines AR-Modells hat einen strukturellen Vorteil: die Verweigerung passiert zuerst. Wenn das Modell beschließt abzulehnen, ist jedes folgende Token auf „Dabei kann ich nicht helfen.“ konditioniert. Ein Diffusion-LLM hat keinen solchen Moment. Es gibt keinen Punkt von links nach rechts, an dem eine Verweigerung den Rest der Generierung übernimmt — maskierte Slots werden so gefüllt, dass sie zu allem passen, was bereits auf der Leinwand steht.

DIJA („The Devil behind the mask“, ICLR 2026, arXiv:2507.11097, ZichenWen1/DIJA) macht daraus einen Angriff. Der adversariale Prompt legt die schädliche Absicht in unmaskierte Tokens und lässt maskierte Abschnitte offen, die das Modell kontextuell konsistent vervollständigt. Die berichteten Ergebnisse: bis zu 100 % keyword-basierte Angriffs-Erfolgsrate auf Dream-Instruct, was die stärkste vorherige Baseline um bis zu 78,5 % bei evaluator-basierter ASR auf JailbreakBench und um 37,7 Punkte im StrongREJECT-Score übertrifft — und das ohne jedes Umschreiben oder Verschleiern der schädlichen Inhalte. Das Fazit der Autoren: bestehende Alignment-Mechanismen schützen dLLMs nicht gegen kontextbewusste Prompts mit maskierten Eingaben, weil das Modell eine unsichere Generierung nicht mitten in der Inferenz filtern kann, wie ein sequenzielles es vermag.

Eine Folgearbeit (arXiv:2602.00388) argumentiert, das Bild sei zweiseitig — Diffusion verleihe in manchen Settings einen Sicherheits-Segen, der dann unter Kontext zerbricht —, was ein Grund ist, zu messen statt in irgendeine Richtung zu vermuten.

Praktische Konsequenz: wenn du ein Open-Weight-dLLM exponierst, behandle sein Instruction-Tuning nicht als Schutzmechanismus. Filtere und klassifiziere an der Grenze, sowohl bei der Anfrage als auch bei der Antwort, genau so, wie du es bei einem Basismodell tun würdest. Unsere Seite Lokale und hybride Agents absichern behandelt das Muster für die Grenze.

Probiere eines in zehn Minuten aus​

Guided walkthrough1 of 4
  1. Inception stellt Mercury über eine OpenAI-kompatible API bereit, und die Modelle sind auf OpenRouter gelistet (zum Beispiel openrouter.ai/inception/mercury-2). Richte ein bestehendes OpenAI-SDK-Skript darauf und ändere den Model-String — an der Form des Requests ist nichts diffusionsspezifisch.

Ein gehostetes Diffusion-LLM mit dem OpenAI SDK aufrufen (nichts ändert sich außer dem Model-String)

# Inception serves an OpenAI-compatible API; OpenRouter also lists the models.
# Check the provider's model list for the current slug before you hard-code one.

curl https://openrouter.ai/api/v1/chat/completions \
-H "Authorization: Bearer $OPENROUTER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
  "model": "inception/mercury-2",
  "messages": [
    {"role": "user", "content": "Rewrite this function to stream its output, and explain the two failure modes you introduced."}
  ],
  "stream": true
}'

# What to watch for, beyond the content:
#  - time to first token vs time to last token (the diffusion win is usually in the gap)
#  - whether the stream arrives in chunks that look like BLOCKS rather than words

Der Steps-Sweep auf Dream 7B — finde deine eigene Qualitätsklippe

import time, torch
from transformers import AutoModel, AutoTokenizer

NAME = "Dream-org/Dream-v0-Instruct-7B"
tok = AutoTokenizer.from_pretrained(NAME, trust_remote_code=True)
model = AutoModel.from_pretrained(
  NAME, torch_dtype=torch.bfloat16, trust_remote_code=True
).to("cuda").eval()

PROMPT = "List the five largest cities in Germany with their populations."
MAX_NEW = 256

# steps == MAX_NEW is the authors' best-quality setting: one token per
# forward pass. Each halving doubles tokens-per-pass and doubles the
# number of independence assumptions you are making.
for steps in [256, 128, 64, 32, 16]:
  inputs = tok.apply_chat_template(
      [{"role": "user", "content": PROMPT}],
      return_tensors="pt", return_dict=True, add_generation_prompt=True,
  ).to("cuda")

  t0 = time.perf_counter()
  out = model.diffusion_generate(
      inputs.input_ids,
      attention_mask=inputs.attention_mask,
      max_new_tokens=MAX_NEW,
      steps=steps,
      temperature=0.0,
      alg="entropy",          # commit the lowest-entropy slots first
      alg_temp=0.0,
  )
  dt = time.perf_counter() - t0
  text = tok.decode(out[0][len(inputs.input_ids[0]):], skip_special_tokens=True)

  print(f"--- steps={steps}  tokens/pass={MAX_NEW/steps:.0f}  {dt:.2f}s ---")
  print(text.strip()[:400])

# Read the OUTPUTS, not just the timings. The numbers and the city names are
# the multi-token units that break first when too many slots are committed
# from one pass. That corruption is the conditional-independence bug, visible.

Wie du entscheidest, ob das für dich relevant ist​

Key takeaways
  • Die Geschwindigkeit eines Diffusion-LLM kommt aus einem Verhältnis — Generierungslänge geteilt durch Denoising-Schritte, also committete Tokens pro Forward Pass. Ein AR-Modell liegt fest bei 1. Alles andere ist eine Folge dieses Reglers.
  • Zu paralleles Decoding ist falsch, nicht bloß grob: committet man korrelierte Slots aus einem Pass, samplet man das Produkt der Marginalverteilungen statt die gemeinsame Verteilung. Decoding mit Konfidenzschwellenwert ist der Fix, und Fast-dLLM berichtet von bis zu 27,6x Durchsatz mit minimalem Genauigkeitsverlust.
  • Reine Masked Diffusion hat keinen KV-Cache und eine feste Ausgabelänge. Block Diffusion (AR zwischen Blöcken, Diffusion innerhalb) hat Caching, variable Länge und Streaming zurückgebracht — deshalb ist jedes heute aufrufbare dLLM ein Blockmodell.
  • DiffusionGemma hat ein autoregressives Gemma 4 MoE für unter 10 % seines ursprünglichen Trainings-Token-Budgets in ein Diffusionsmodell umgewandelt und dabei Thinking-Modus, Multimodalität und AR-Generierung behalten. Diffusion sieht eher nach einem Decoding-Modus aus als nach einer eigenen Modellspezies.
  • Wähle es für Infilling und Edits in beliebiger Reihenfolge, Voice-Turns unter 200 ms, schnelle begrenzte Entscheidungen und End-to-End-Turn-Latenz — und gehe davon aus, dass sein Alignment nicht hält, denn Masked-Infill-Prompts erreichen bei einem alignten offenen dLLM bis zu 100 % ASR.
Drücke Enter oder die Leertaste, um die Karte umzudrehen. Nutze die Pfeiltasten links und rechts, um zwischen den Karten zu wechseln.Begriff angezeigt.
1 / 11

Check yourself

0/5
  1. Ein Masked-Diffusion-LLM wird nach einer 256-Token-Antwort in 32 Denoising-Schritten gefragt. Was bedeutet das?
  2. Warum kann ein reines Masked-Diffusion-LLM keinen konventionellen KV-Cache nutzen?
  3. Was ändert Block Diffusion (BD3-LM) gegenüber reiner Masked Diffusion?
  4. Welches ist das folgenreichste berichtete Ergebnis von DiffusionGemma?
  5. Du stellst ein Open-Weight-dLLM mit Instruction-Tuning nicht vertrauenswürdigen Nutzern bereit. Was ist das dLLM-spezifische Risiko?

Neu bei der zugrunde liegenden Maschinerie? Was ist ein LLM und Tokens und Kontext behandeln die autoregressive Grundlage, von der diese Seite abweicht, und Token-Geschwindigkeit behandelt die Hardware- und Software-Multiplikatoren, die dasselbe Latenzproblem von der anderen Seite angehen.

Quellen & weiterführende Literatur​

Weiter​