Cloudflare Clef: Qwen und Schema-Bewertung

Clef und Clef-flash sind veröffentlichte multimodale Entscheidungsmodelle von Cloudflare, keine reinen Architekturvorschläge aus der Forschung. Seit dem 1. Oktober 2026 lassen sich beide über Workers AI aufrufen. Ihre BF16-Gewichte, Prozessor-Dateien, Gewichte des gemeinsamen Heads und die Python-Referenzimplementierung stehen unter Apache 2.0 bereit. Dieser Artikel beschreibt die am 2. Oktober 2026 geprüften Revisionen 2f3de3d von Clef und 17f0b0a von Clef-flash.[^release][^clef-card][^flash-card]

Es handelt sich nicht um Chatmodelle. Eine Anfrage enthält einen Zustand sowie typisierte Fragen, deren zulässige Antworten vorab feststehen. Ein Forward-Pass liefert ein Logit je zulässiger Option; auf jede Frage wird getrennt ein Softmax angewendet. Es gibt weder Token-für-Token-Generierung der Antwort noch einen Parser für Freitextausgaben.[^clef-card][^implementation]

Die zwei veröffentlichten Varianten

Komponente	Clef	Clef-flash
Post-trainierter Backbone	Qwen3.8-27B	Qwen3.5-9B
Text-Stack	64 Schichten, Breite 5.120	32 Schichten, Breite 4.096
Abfolge des Sequence-Mixing	48 Linear-Attention- und 16 Full-Attention-Schichten	24 Linear-Attention- und acht Full-Attention-Schichten
Aufbau der Full Attention	24 Query-Heads, vier KV-Heads, Head-Dimension 256	16 Query-Heads, vier KV-Heads, Head-Dimension 256
Gemeinsamer Schema-Head	Breite 1.024; 16 Heads; zwei Routing-Schichten; vier Field-Schichten; FFN-Breite 4.096	Gleich, bis auf die Eingangsprojektion vom 4.096 breiten Backbone
Veröffentlichte BF16-Parameter	27,36 Mrd.	9,41 Mrd.
Kontext auf Workers AI	65.536 Token	65.536 Token

Schicht- und Tensorwerte stammen aus den veröffentlichten Checkpoint-Konfigurationen, nicht aus gerundeten Produktnamen; die Parameterzahlen sind die Safetensors-Metadaten der Repositories an den festgehaltenen Revisionen. Beide Qwen-Backbones wiederholen drei Linear-Attention-Schichten und eine Full-Attention-Schicht und behalten ihren Vision-Encoder. Das ist verwandt mit, aber nicht derselbe Checkpoint wie Qwen3.8-Flash-Next. Clef ergänzt nicht dessen N-Gram-Speicher.[^clef-card][^flash-card][^clef-config][^flash-config]

Eingabelayout und der einzelne Backbone-Pass

Der Referenz-Encoder bildet einen Datensatz auf eine kausale Sequenz ab:

text

Systemanweisung | Zustand und optionale Medien | Schema-Felder und Optionen | Assistant-Suffix

Für jedes Feld speichert er die Token-Spanne der Frage und jeder Optionsbeschreibung. JSON-Zustände werden mit sortierten Schlüsseln serialisiert. Bilder und Videoframes laufen durch den Qwen-Prozessor und werden vor dem Zustand eingefügt. Das Schema wird nicht still gekürzt: Überschreiten seine festen Token das konfigurierte Limit, bricht die Kodierung ab. Andernfalls wird das Ende des Zustands abgeschnitten, damit Schema und Suffix erhalten bleiben.[^implementation]

$L$ bezeichne die gültige Eingabelänge, $h$ die Backbone-Breite, $F$ die Anzahl der Felder und $O_f$ die Optionszahl des Felds $f$ . Nach dem Qwen-Prefill besitzt der finale Hidden-Tensor die Form

$H \in \mathbb{R}^{L \times h}, \qquad h \in \{5120,4096\}.$

Der Release-Wrapper ruft das Textmodell mit use_cache=False auf. Er verbraucht die finalen Hidden States sofort und behält keinen KV-Cache für Decode, weil keine autoregressive Decode-Phase folgt. Damit entfällt das Wachstum eines Decode-Caches. Der Prefill wird dadurch aber nicht kostenlos: Jede vierte Backbone-Schicht führt weiterhin vollständige kausale Attention aus. Außerdem wachsen das finale $H$ und ein projizierter Speicher des Heads linear mit $L$ .[^implementation][^clef-config][^flash-config]

Stufe 1: optionsspezifisches Evidence-Routing

Der gemeinsame Head normalisiert zunächst $H$ per LayerNorm und projiziert jedes Token in einen 1.024 breiten Speicher:

$M = W_m\operatorname{LN}(H) \in \mathbb{R}^{L \times 1024}.$

Für jede Frage und Option mittelt die Implementierung mehrere Token-Spannen. Für einen Datensatz entstehen folgende Formen:

Tensor	Form	Ursprung
Fragevektoren $Q$	$[F,h]$	Mittelwert der kontextualisierten Frage-Token
Optionskontext $C$	$[O,h]$ , $O=\sum_f O_f$	Mittelwert jeder kontextualisierten Optionsspanne
Lexikalische Optionsvektoren $E$	$[O,h]$	Mittelwert der Zeilen des Backbone-Output-Embeddings für die Option-Token-IDs
Options-Queries $X$	$[1,O,1024]$	Summe der Projektionen von $C$ , $E$ und der passenden Zeile von $Q$

Zwei EvidenceRoutingLayer aktualisieren $X$ . Jede Schicht nutzt Cross-Attention mit 16 Heads von allen Options-Queries auf $M$ ; damit beträgt ihre Head-Dimension $1024/16=64$ . Darauf folgt ein residuales GELU-Feedforward-Netz mit 1.024→4.096→1.024 Dimensionen. Optionen führen in dieser Stufe keine Self-Attention untereinander aus, sondern rufen unabhängig Evidenz aus dem vollständig kodierten Datensatz ab. Der Attention-Aufwand ist proportional zu $O\,L$ statt $L^2$ , steigt aber weiterhin mit der Anzahl deklarierter Optionen.[^head-config][^implementation]

Stufe 2: gemeinsame Felder und Interaktion zwischen Feldern

Die gerouteten Optionsvektoren werden wieder nach Feldern aufgeteilt. Für jedes Feld erzeugt ein Skalarprodukt zwischen projiziertem Fragevektor und seinen Optionen ein Softmax über die Optionen dieses Felds. Die gewichtete Optionszusammenfassung wird zu vier Termen addiert:

dem projizierten Fragevektor;
der Optionszusammenfassung;
einer Projektion des letzten Sequenz-Tokens;
einem gelernten Embedding für den Typ noul, choice oder score.

So entstehen $F$ Field-Vektoren der Breite 1.024. Vier normale Pre-Norm-TransformerDecoderLayer führen anschließend unmaskierte Self-Attention zwischen den Feldern, Cross-Attention zurück auf den gesamten Speicher $M$ und einen 4.096 breiten Feedforward-Block aus. Der konkrete Unterschied ist wichtig: Stufe 1 routet Evidenz aus dem Zustand in einzelne Optionen. Stufe 2 lässt Felder miteinander interagieren und erneut auf den Zustand zugreifen. Die Field-Self-Attention kostet $O(F^2)$ , die vier Memory-Cross-Attentions jeweils $O(F\,L)$ .[^implementation]

Schemagebundenes Scoring und der lexikalische Prior

Jeder finale Field-Vektor wird ausschließlich gegen seine eigenen gerouteten Optionen bewertet. Die Implementierung kombiniert zwei Pfade:

+ \sigma(g)\left[s_j\,\cos(R_o,F_f)+\operatorname{MLP}(F_f,R_o,F_f\odot R_o,|F_f-R_o|)\right].$$ $R_o$ ist der geroutete Optionsvektor, $F_f$ der finale Field-Vektor, $E_o$ der lexikalische Optionsvektor. $s_p$ und $s_j$ sind gelernte positive Skalare, die bei 100 begrenzt werden. Das Residual-MLP erhält vier je 1.024 breite Feature-Blöcke. Am Ende wird Softmax getrennt auf den variabel langen Logit-Vektor jedes Felds angewendet.[^implementation] Der lexikalische Pfad lässt sich leicht falsch benennen. Er liest die vorhandenen Zeilen des Qwen-Output-Embeddings für die Token einer Option und mittelt sie. Das ist **keine** gehashte N-Gram-Tabelle wie Engram, keine Vektordatenbank und kein neuer persistenter Speicher. Es ist ein anfragebezogener semantischer Prior über die vom Nutzer vorgegebenen Antwortlabels. ## Was trainiert und was veröffentlicht wurde Cloudflare gibt an, die Qwen-Backbones eingefroren und den Schema-Head gemeinsam mit Low-Rank-Adaptern vom Rang 256 trainiert zu haben. Die Trainingsziele kombinierten Label-smoothed Cross-Entropy mit einem Brier Loss. Ein späteres RLCD-Ziel vergab Teilpunkte für benachbarte ordinale Antworten und bestrafte Abweichungen von einer Referenz-Policy. Das sind Trainingsbeschreibungen des Anbieters. Der Release enthält weder ein vollständiges Trainingsrezept noch Datensätze, mit denen sich die berichteten Verbesserungen unabhängig reproduzieren ließen.[^release] Der herunterladbare Release lässt sich eindeutiger beschreiben. `load_release_model` bezeichnet den Checkpoint als **merged backbone**, lädt ihn als gewöhnliche `Qwen3_5ForConditionalGeneration`-Gewichte und hängt danach die getrennte Datei `joint_head.safetensors` an. Zur Inferenz muss keine LoRA-Adapterdatei geladen werden. Aus der veröffentlichten Head-Konfiguration ergeben sich ungefähr 128,1 Millionen Parameter für Clef und 121,8 Millionen für Clef-flash. Das sind abgeleitete Parameterzahlen, keine Messwerte des Anbieters.[^head-config][^implementation] ## Betriebsgrenzen Cloudflares gehosteter Endpunkt ist derzeit der produktionsfertige Pfad. Er akzeptiert bis zu 64 Fragen, unterstützt bis zu vier eingebettete PNG-, JPEG- oder WebP-Bilder innerhalb dokumentierter Body- und Bildlimits und stellt 65.536 Token Kontext bereit. Cloudflare testete die Open-Weight-Referenz mit PyTorch 2.11 und Transformers 5.10.2 auf einer H200. Das ist eine angegebene Testumgebung, keine Aussage über minimale Hardware.[^workers][^clef-card] Zwischen lokalem und gehostetem Pfad gibt es eine wichtige Abweichung. Die veröffentlichten Helfer begrenzen `encode_record` und `systemone` standardmäßig auf **16.384 Token**, obwohl die Checkpoint-Konfiguration 262.144 Positionen erlaubt und Workers AI 65.536 bereitstellt. Ein lokaler Aufrufer muss `max_length` bewusst erhöhen und den längeren Prefill anschließend unter realer Last vermessen. Der Custom Head verarbeitet Datensätze außerdem in einer Python-Schleife und gibt verschachtelte Tensorlisten variabler Länge zurück. Das ist eine klare Referenzimplementierung, aber kein Nachweis für optimiertes Continuous Batching in einer allgemeinen Serving-Engine.[^implementation][^clef-config][^workers] Cloudflare veröffentlicht Latenz- und Qualitätstabellen. Es bleiben jedoch Messungen des Anbieters auf dessen Suite und Infrastruktur. Die architektonische Aussage hängt nicht davon ab: Clef tauscht offene Generierung gegen einen schemagebundenen Prefill und einen begrenzten Decision Head. Ob das für eine Produktionslast schneller oder besser ist, hängt von Eingabelänge, Zahl der Fragen und Optionen, Kalibrierungsanforderungen, GPU und Runtime sowie den Kosten eines generativen Fallbacks bei unvollständigem Schema ab. ## Quellen [^release]: [Cloudflare, *Introducing Clef: our open-source decision models*, 1. Oktober 2026](https://blog.cloudflare.com/clef-decision-models/). [^workers]: [Cloudflare Workers AI, offizielle Clef-Modelldokumentation und Request-Grenzen](https://developers.cloudflare.com/workers-ai/models/clef/). [^clef-card]: [Cloudflare, Clef-Model-Card und veröffentlichte Gewichte, Revision `2f3de3d`](https://huggingface.co/Cloudflare/clef/tree/2f3de3dd85f379784083b0814d997ab627200f0c). [^flash-card]: [Cloudflare, Clef-flash-Model-Card und veröffentlichte Gewichte, Revision `17f0b0a`](https://huggingface.co/Cloudflare/clef-flash/tree/17f0b0ad64efb65d273590632833508766b2aae6). [^clef-config]: [Cloudflare, veröffentlichte Clef-`config.json`](https://huggingface.co/Cloudflare/clef/blob/2f3de3dd85f379784083b0814d997ab627200f0c/config.json). [^flash-config]: [Cloudflare, veröffentlichte Clef-flash-`config.json`](https://huggingface.co/Cloudflare/clef-flash/blob/17f0b0ad64efb65d273590632833508766b2aae6/config.json). [^head-config]: [Cloudflare, veröffentlichte Konfigurationen des gemeinsamen Heads für Clef](https://huggingface.co/Cloudflare/clef/blob/2f3de3dd85f379784083b0814d997ab627200f0c/joint_head_config.json) [und Clef-flash](https://huggingface.co/Cloudflare/clef-flash/blob/17f0b0ad64efb65d273590632833508766b2aae6/joint_head_config.json). [^implementation]: [Cloudflare, veröffentlichte Datei `joint_schema_model.py`, Revision `2f3de3d`](https://huggingface.co/Cloudflare/clef/blob/2f3de3dd85f379784083b0814d997ab627200f0c/joint_schema_model.py).