Zum Inhalt springen
Kurzer Hinweis: flozi00 TechHub ist ein Solo-Nebenprojekt neben einem Vollzeitjob — persönliche Lernnotizen, keine offiziellen Aussagen. Kritische Schritte selbst prüfen.

Clef Omni: Audio, Video, Sparse Experts und Schema-Entscheidungen

Cloudflares veröffentlichtes Clef Omni im Detail: Qwen3-Omni-Encoder, synchronisiertes Audio und Video, Top-8-MoE-Routing, vollständige Grouped-Query-Attention und ein Schema-Head ohne Decode, mit Formeln und Betriebsgrenzen.

10 Min. Lesezeitflozi00
aiarchitekturcloudflareqwenmultimodalaudiovideomoeattentioninference

Cloudflare veröffentlichte Clef Omni am 9. Oktober 2026 mit Gewichten unter Apache 2.0 und einem gehosteten Workers-AI-Endpunkt. Das Modell verarbeitet einen Zustand, optionale Medien und Fragen mit ausdrücklich erlaubten Antworten. Es gibt für jede Frage eine Wahrscheinlichkeitsverteilung über deren Optionen aus, statt Text zu generieren. Dieser Artikel prüft die Checkpoint-Revision 0db1cd2607d76a7bdb2a382f659e7b313079f84b anhand ihrer Konfiguration und Referenzimplementierung; als Implementierungsreferenz dient Transformers 5.10.2.1234

Der vorhandene Guide zu Clef und Clef-flash erklärt den zweistufigen Entscheidungskopf. Omni verändert den Backbone: Es nutzt den Thinker von Qwen3-Omni-30B-A3B-Instruct mit Audio- und Vision-Encodern, einer dünnbesetzten Mixture of Experts und vollständiger kausaler Attention im gesamten Text-Stack. Die Abfolge aus drei Linear-Attention-Schichten und einer Full-Attention-Schicht der dichten Varianten kommt hier nicht zum Einsatz.54

Was tatsächlich ausgeführt wird

Der Loader setzt enable_audio_output=False und behält den Thinker. Die herunterladbaren Shards enthalten auch die Sprachausgabe-Module des Basismodells, talker und code2wav; dieser Inferenzpfad lädt sie jedoch nicht. Die Kodierung eingehender Audiodaten bleibt aktiv. Das Abschalten der Sprachausgabe macht Omni somit nicht zu einem reinen Textmodell.236

KomponenteVeröffentlichte Konfiguration
Thinker-Text-Stack48 Schichten; Hidden-Breite 2.048; Vokabular 152.064
Kausale GQA je Schicht32 Query-Heads; vier KV-Heads; Head-Dimension 128
Geroutete Experten je Schicht128 Experten; acht je Token ausgewählt; FFN-Zwischenbreite 768; kein gemeinsamer Experte
Vision-Encoder27 Blöcke; Breite 1.152; Ausgabebreite 2.048; räumlicher Patch 16; zeitlicher Patch 2; räumliches Merge 2×2
Audio-Encoder32 Schichten; Breite 1.280; 20 Attention-Heads; 128 Mel-Bänder; Ausgabebreite 2.048
Gemeinsamer Schema-HeadBreite 1.024; 16 Heads; zwei Evidence-Routing-Schichten; vier Field-Schichten; FFN-Breite 4.096

Das sind Werte des Checkpoints, keine aus „30B-A3B“ abgeleiteten Spezifikationen. Die Textkonfiguration erlaubt 65.536 Positionen. Sowohl das standardmäßige Eingabelimit des veröffentlichten Helpers als auch der gehostete Kontext betragen 64.000 Token. Schema, Medien und Text teilen sich dieses Budget.5738

Medien werden zu Embeddings, nicht zu Transkripten

Der Referenz-Encoder platziert Medien vor dem Textzustand; danach folgen das vollständige Schema und ein Assistant-Suffix. Er speichert die Token-Spannen der Frageanweisungen und Optionsbeschreibungen. Überschreiten Medien, Schema und feste Rahmentoken bereits das Tokenbudget, bricht die Kodierung ab. Andernfalls kürzt sie das Ende des Textzustands, bis alles passt. Ein großer Anhang kann somit Textevidenz verdrängen, ohne das Schema zu verkürzen.3

Der Prozessor erweitert Medienplatzhalter um die passende Anzahl von Tokenpositionen. Der Thinker ersetzt die Embeddings an diesen Positionen durch Encoder-Ausgaben der Breite 2.048. Er generiert weder ein ASR-Transkript noch eine Bildbeschreibung als Zwischenschritt. Sowohl Sprachinhalte als auch andere akustische Merkmale können diesen Pfad durchlaufen. Diese architektonische Möglichkeit belegt jedoch keine Erkennungsgenauigkeit für ein bestimmtes Geräusch oder Ereignis.94

Audio: von 16 kHz zu ungefähr 13 Positionen pro Sekunde

Kodierte Clips werden dekodiert und auf 16 kHz mono resampelt. Rohe Sample-Arrays übernimmt der Helper unverändert; Aufrufer müssen daher bereits diese Abtastrate und Anordnung liefern. Der Feature-Extractor nutzt 128 Mel-Bänder und eine Schrittweite von 160 Samples: nominell 100 Feature-Frames pro Sekunde. Drei Faltungen mit Stride 2 komprimieren jeden Block aus 100 Frames auf 13 Positionen. Der Audio-Encoder projiziert seine 1.280 breiten Repräsentationen anschließend auf die Breite 2.048.31094

Für eine Mel-Länge ohne Padding M=100q+rM=100q+r mit 0≤r<1000\le r<100 lässt sich die veröffentlichte Funktion zur Ausgabelänge auf folgende Gleichung vereinfachen. Ein zehnsekündiger Clip mit genau 1.000 gültigen Mel-Frames trägt 130 Audiopositionen bei, zuzüglich Rahmentoken. Padding und die Behandlung der Signalränder beeinflussen die genaue Anzahl. Das ist eine hergeleitete Längenrechnung, keine Durchsatzmessung.

Na(M)=13q+⌈r8⌉,M=100q+r.N_a(M)=13q+\left\lceil\frac{r}{8}\right\rceil,\qquad M=100q+r.

Video: Sampling, räumliches Merge und eine gemeinsame Zeitbasis

Der Helper sampelt kodiertes Video mit zwei Frames pro Sekunde, skaliert Frames auf eine ungefähre Obergrenze von 262.144 Pixeln und wiederholt bei Bedarf das letzte Frame, um eine gerade Framezahl zu erhalten. Bereits dekodierte Frame-Arrays müssen dem erwarteten Sampling-Takt entsprechen. Der Vision-Encoder gruppiert jeweils zwei Frames, bildet räumliche Patches von 16×16 Pixeln und führt benachbarte Patches in 2×2-Gruppen zusammen. Für das Prozessorgitter vor dem Merge (Tg,Hg,Wg)(T_g,H_g,W_g) ergibt sich folgende Anzahl visueller Positionen:359

Nv=TgHgWg4.N_v=T_g\frac{H_gW_g}{4}.

Ein skaliertes Frame von 384×384 Pixeln liefert Hg=Wg=24H_g=W_g=24, also 144 zusammengeführte Positionen pro zeitlichem Gitter. Bei zwei Frames pro Sekunde und einem zeitlichen Patch aus zwei Frames entsteht ungefähr ein solches Gitter je Sekunde. Das ist eine Rechnung aus Tensorformen; tatsächliche Skalierung, Clipgrenzen und Markertoken bestimmen die endgültige Tokenzahl der Anfrage.

Bei Video mit Ton verschachtelt der Prozessor Video- und Audioplatzhalter anhand einer gemeinsamen Zeitkoordinate. Beim Standardtakt liegen zeitliche Gitter eine Sekunde auseinander; ihre Zeitpositionen steigen um 13, passend zu ungefähr 13 Audiopositionen pro Sekunde. Die Implementierung führt die beiden Folgen zeitlich geordnet zusammen. Sie transkribiert nicht zunächst Audio, um anschließend Text an Frames anzuhängen.94

Dabei besteht eine konkrete Einschränkung: use_audio_in_video wird nur aktiviert, wenn jedes Video im Datensatz eine dekodierbare Tonspur hat. Ein einziges stummes Video bewirkt, dass der Helper sämtliche Videotonspuren dieses Datensatzes weglässt. Separate Einträge in audio funktionieren weiterhin. Der Collator lehnt außerdem einen Batch ab, der Videodatensätze mit und ohne diesen Audiomodus mischt.3

Synchronisierung bezieht sich hier auf die gesampelten und kodierten Repräsentationen. Sampling mit zwei Frames pro Sekunde kann kurze visuelle Ereignisse verpassen, die Mono-Konvertierung entfernt getrennte Audiokanäle, und der Referenz-Helper dekodiert den vollständigen Clip vor der Inferenz. Dieser Release-Pfad ist keine Streaming-Schnittstelle für Entscheidungen.

Positionskodierung und visuelle Merkmale

Der Thinker verwendet Interleaved Multimodal RoPE. Sein Tensor für Rotary-Positionen enthält Zeit-, Höhen- und Breitenkoordinaten. Von den 64 Rotary-Frequenzen eines 128-dimensionalen Heads nutzen 24 die Zeitkoordinate, 20 die Höhe und 20 die Breite. Höhen- und Breitenfrequenzen sind mit Zeitfrequenzen verschachtelt. Die konfigurierte RoPE-Basis beträgt 10610^6. Textpositionen nutzen auf allen drei Achsen denselben Index; visuelle Positionen behalten ihre Gitterkoordinaten.54

Die Einbindung visueller Merkmale geht über das anfängliche Ersetzen der Embeddings hinaus. Merkmale aus den bei null beginnend gezählten Vision-Blöcken 8, 16 und 24 werden getrennt auf Breite 2.048 zusammengeführt und an den visuellen Tokenpositionen nach den Text-Decoder-Schichten 0, 1 und 2 addiert. Diese DeepStack-Additionen nutzen die bestehenden visuellen Positionen. Sie hängen keine drei weiteren Kopien der visuellen Tokenfolge an.54

Sparse Experts reduzieren FFN-Arbeit, nicht den Gewichtsspeicher auf 3B

Für eine Tokenrepräsentation x∈R2048x\in\mathbb{R}^{2048} erzeugt der Router 128 Logits, berechnet deren Softmax in FP32, wählt die acht höchsten Wahrscheinlichkeiten und normalisiert nur diese Teilmenge erneut. Jeder ausgewählte Experte nutzt ein FFN mit SiLU-Gating und Zwischenbreite 768. Die geroutete Ausgabe ist eine gewichtete Summe:54

r=softmax⁡(Wrx),S=TopK⁡8(r),αe=re∑j∈Srj,y=∑e∈SαeWd,e[SiLU⁡(Wg,ex)⊙(Wu,ex)].\begin{aligned} r&=\operatorname{softmax}(W_rx),\qquad S=\operatorname{TopK}_8(r),\\ \alpha_e&=\frac{r_e}{\sum_{j\in S}r_j},\\ y&=\sum_{e\in S}\alpha_e W_{d,e} \left[\operatorname{SiLU}(W_{g,e}x)\odot(W_{u,e}x)\right]. \end{aligned}

Der kombinierte Gate-/Up-Gewichtstensor besitzt die Form [128,1536,2048][128,1536,2048], die Down-Gewichte die Form [128,2048,768][128,2048,768]. Ohne gemeinsamen Experten und mit einem Sparse-Block in jeder der 48 Schichten enthalten die gerouteten FFNs rechnerisch 28.991.029.248 Parameter. Ein Token wählt über den Stack Expertenmatrizen mit 1.811.939.328 dieser Parameter aus. Attention, Embeddings, Router und Modalitätsencoder sind zusätzliche Komponenten. Dies ist keine Neuberechnung der Gesamtangabe „3B aktiv“ aus dem Modellnamen.

Alle Experten bleiben für den Router verfügbar. Der Standard-Loader platziert das behaltene Modell auf einem Gerät, statt nur acht Experten zu laden. Cloudflare nennt ungefähr 64 GB BF16-Backbone-Speicher und Tests auf einem H200 mit PyTorch 2.11 und Transformers 5.10.2. Das ist die vom Herausgeber angegebene Umgebung, kein gemessener Mindestbedarf und keine lokale Messung dieses Artikels.32

Gegenüber der Ausführung aller 128 Experten reduziert die Auswahl von acht die Expertenarithmetik je Token. Sie verspricht keine 16-fache Beschleunigung der vollständigen Anfrage: Full Attention, Encoder, Dispatch, Matrixauslastung und Speicherverkehr kosten weiterhin Zeit. Der Router weist benannten Experten auch keine festen Rollen für „Audio“ oder „Video“ zu, sondern routet jedes kontextualisierte Token anhand gelernter Bewertungen.

Auch vollständige GQA kostet Prefill-Rechenzeit

Bei Sequenzlänge LL projiziert jede Textschicht [L,2048][L,2048] auf Q:[32,L,128]Q:[32,L,128] sowie K,V:[4,L,128]K,V:[4,L,128]; die Batch-Achse ist hier weggelassen. Q/K erhalten pro Head eine RMS-Normalisierung und Rotary-Kodierung. Je acht Query-Heads teilen sich einen KV-Head. Die zusammengeführte Attention-Ausgabe ist 4.096 breit und wird zurück auf 2.048 projiziert. Die Head-Breite muss nicht dem Quotienten aus Hidden-Breite und Query-Head-Zahl entsprechen.54

Jede Textschicht nutzt vollständige kausale Attention. Prefill benötigt weiterhin quadratisch viele Vergleiche von Tokenpaaren, auch wenn ein auf Speicherzugriffe optimierter Attention-Kernel die vollständige Score-Matrix nicht materialisieren muss. Transformers verwendet das ausgewählte Attention-Backend und erlaubt alternative Expertenimplementierungen. Der Cloudflare-Loader legt keinen bestimmten beschleunigten Kernel fest. Kernelverfügbarkeit und ein tatsächlicher Serving-Benchmark sind von der Checkpoint-Architektur zu unterscheiden.43

Wo Omni tatsächlich Ausgabearbeit und Speicher spart

ClefModel behält die lm_head-Gewichte des Thinkers für lexikalische Options-Lookups und ersetzt dessen Forward-Modul durch Identity. Der Thinker gibt deshalb H:[L,2048]H:[L,2048] im normalerweise logits genannten Feld zurück, statt Vokabular-Logits der Form [L,152064][L,152064] zu berechnen. Außerdem läuft er mit use_cache=False und ruft generate nicht auf. Das feste Suffix mit <think>/</think> rahmt die Eingabe; es ist keine generierte Denkkette.3

Die KV-Cache-Formel liefert einen hilfreichen Vergleich: Würden BF16-K/V für alle 48 Schichten gespeichert, wären das 96 KiB pro Token oder 5,86 GiB bei 64.000 Positionen. Der Release-Wrapper behält diesen Cache nicht. Die Formel berücksichtigt keinen Allocator- oder Laufzeit-Overhead.

BKV(L)=48⋅2⋅4⋅128⋅L⋅2 bytes.B_{\mathrm{KV}}(L)=48\cdot2\cdot4\cdot128\cdot L\cdot2\ \text{bytes}.

Ein weiterer hergeleiteter Vergleich: Ein BF16-Vokabulartensor der Form [64000,152064][64000,152064] allein würde 18,13 GiB belegen. Der Wrapper vermeidet diese Projektion und diesen Tensor. Sein finaler Hidden-Tensor und der projizierte Speicher des Heads mit [64000,1024][64000,1024] belegen bei BF16 zusammen 375 MiB. Das ist kein VRAM-Spitzenwert: normalisierte Kopien, temporäre Q/K/V-Tensoren, Attention- und Experten-Workspaces, Encoder-Merkmale und residente Gewichte kommen hinzu.

Ohne Generierung entfallen Decode-Schritte und die dauerhafte Speicherung eines Decode-Caches. Die multimodalen Encoder und der lange Prefill mit Full Attention bleiben bestehen. Der Guide zur Inferenzmathematik erklärt, warum kürzere Ausgaben und kleinere aktive FFNs allein die Anfragelatenz nicht bestimmen können.

Von Hidden States zu begrenzten Entscheidungen

Für einen Datensatz mit FF Feldern und O=∑fOfO=\sum_f O_f Optionen normalisiert der Head HH per LayerNorm und projiziert ihn auf den Speicher M:[1,L,1024]M:[1,L,1024]. Aus den normalisierten Frage- und Optionsspannen bildet er Mittelwerte als 2.048 breite Vektoren. Außerdem mittelt er die behaltenen Output-Embedding-Zeilen für die Token jeder Option. Gelernte Projektionen daraus ergeben Options-Queries der Form [1,O,1024][1,O,1024].73

Zwei Cross-Attention-Schichten mit 16 Heads lassen jede Option Evidenz aus dem vollständigen Speicher abrufen. Jeder Head ist 64 breit. Die gerouteten Optionen werden innerhalb jedes Felds zusammengefasst. Ihre Zusammenfassungen ergänzen die projizierte Frage, den letzten Sequenzzustand und ein Typ-Embedding. Vier Decoder-Schichten wenden dann unmaskierte Self-Attention zwischen Feldern, Memory-Cross-Attention und ein FFN auf [1,F,1024][1,F,1024] an. Der Backbone ist kausal, aber dieser Entscheidungskopf kann erneut auf die gesamte fertig kodierte Eingabe zugreifen.

eoe_o bezeichne den lexikalischen Optionsvektor, qfq_f die gemittelte Frage und gg den letzten normalisierten Sequenzzustand. ufu_f und vov_o seien die finalen normalisierten Feld- und gerouteten Optionsvektoren. Der Head kombiniert einen 2.048-dimensionalen lexikalischen Prior mit einer gemeinsamen Bewertung in 1.024 Dimensionen:

ℓo=spcos⁡(eo,qf+g)+σ(γ)[sjcos⁡(uf,vo)+MLP⁡([uf;vo;uf⊙vo;∣uf−vo∣])].\ell_o=s_p\cos(e_o,q_f+g)+\sigma(\gamma)\left[ s_j\cos(u_f,v_o)+\operatorname{MLP}\bigl([u_f;v_o;u_f\odot v_o;|u_f-v_o|]\bigr) \right]. pf(o)=exp⁡(ℓo)∑j∈Ofexp⁡(ℓj).p_f(o)=\frac{\exp(\ell_o)}{\sum_{j\in\mathcal{O}_f}\exp(\ell_j)}.

Die positiven gelernten Skalen sps_p und sjs_j sind auf 100 begrenzt; das Residual-MLP verarbeitet 4.096 Merkmale. Der lexikalische Pfad nutzt normale Vokabularzeilen. Er ist weder ein Engram-N-Gram-Speicher noch externes Retrieval. Die Anzahl der Attention-Paare im Head wächst je Head mit 2OL+4(FL+F2)2OL+4(FL+F^2), ohne Projektions- und FFN-Arbeit. Mehr deklarierte Felder oder Optionen erhöhen daher weiterhin die Kosten.3

Die Felder teilen Repräsentationen, aber die API liefert getrennte Verteilungen je Feld, keine normalisierte Verteilung über sämtliche Antwortkombinationen. Gemeinsame Attention garantiert keine logisch konsistenten Feldentscheidungen. Ein choice wählt die größte Wahrscheinlichkeit, noul gibt p(true)p(\text{true}) aus, und score liefert ∑ii p(i)\sum_i i\,p(i) über die bei null beginnenden geordneten Stufen. Letzteres ist ein erwarteter Index, keine gemessene physikalische Größe.

Betriebsgrenzen und Beleglage

Nach Prüfung vom 10. Oktober bietet Workers AI @cf/cloudflare/clef-omni mit den folgenden gehosteten Grenzen an. Es handelt sich um API-Beschränkungen, die der Python-Helper nicht identisch durchsetzt.8

Gehostete EingabeGrenze
Kontext / Fragen64.000 Token / 1–64 Fragen
BilderVier; je 4 MiB und 16 Megapixel; zusammen 8 MiB
AudioclipsVier; je 8 MiB und 300 Sekunden
VideosZwei; je 16 MiB und 60 Sekunden
Audio/Video insgesamt16 MiB dekodiert; eingebettete Medien, keine entfernten URLs

Der lokale Code akzeptiert auch Pfade, URLs, Bytes und bereits dekodierte Arrays. Für Bilder benötigt er Pillow, für kodiertes Audio/Video PyAV. Checkpoint, Prozessor, eigener Modellcode und Laufzeit sollten gemeinsam auf feste Versionen gesetzt werden: Einstellungen wie Audio-Abtastrate oder Videotakt bestimmen die tatsächlich in das Netz eingehenden Daten. Die Referenzmethode forward bildet für jeden Datensatz erneut einen Einzelbatch und führt ihn sequenziell ohne Padding aus, selbst wenn sie einen Batch erhält. Das belegt weder Continuous Batching noch parallele Batch-Ausführung.32

Die festgehaltene Model Card kündigt SGLang-Unterstützung mit „coming soon“ an. Cloudflares begleitende Veröffentlichung beschreibt SGLang-Arbeit für Clef. Daraus folgt keine bereits veröffentlichte Omni-Serving-Integration. Der gehostete Endpunkt und die veröffentlichte lokale Referenz sind die hier geprüften Pfade.21

Cloudflare beschreibt Post-Training mit eingefrorenem Backbone, LoRA und einer Kombination aus Label-Smoothed Cross-Entropy und Brier Loss. Diese Ziele trainieren Optionsauswahl und Wahrscheinlichkeitsschätzungen; sie garantieren keine Kalibrierung für unbekannte Eingaben. Die veröffentlichten Qualitäts- und Latenzergebnisse sind Messungen des Anbieters, die dieser Artikel nicht reproduziert. Insbesondere validieren Textentscheidungs-Benchmarks weder Audioerkennung noch synchronisierte audiovisuelle Entscheidungen für sich allein.12

Omnis konkreter Vorteil gegenüber den dichten Clef-Varianten ist ein direkter Pfad für Audio und Video mit Ton zum Schema-Head. Seine dünnbesetzten FFNs reduzieren die Expertenrechenarbeit je Token. Der Verzicht auf Ausgabegenerierung beseitigt einen anderen Kostenanteil. Ob diese Mechanismen ein Deployment verbessern, hängt von Medienqualität, Eingabelänge, Schemagröße, Kalibrierung und Serving-Implementierung ab. Mehr Modalitäten allein belegen keine besseren Entscheidungen bei Text oder Bildern.

Primärquellen

Footnotes

  1. Cloudflare, Clef Omni release announcement, 9 October 2026. ↩ ↩2 ↩3

  2. Cloudflare, Clef Omni model card, revision 0db1cd2. ↩ ↩2 ↩3 ↩4 ↩5 ↩6

  3. Cloudflare, released encoder, decision head and loader in joint_schema_model.py. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10 ↩11 ↩12 ↩13

  4. Hugging Face Transformers 5.10.2, Qwen3-Omni model implementation, commit 0dad7b8. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8 ↩9 ↩10

  5. Cloudflare, released config.json, revision 0db1cd2. ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7

  6. Cloudflare, released weight index showing Thinker, Talker and Code2Wav tensors. ↩

  7. Cloudflare, released joint_head_config.json. ↩ ↩2

  8. Cloudflare, official Clef Omni API documentation, checked 10 October 2026. ↩ ↩2

  9. Hugging Face Transformers 5.10.2, Qwen3-Omni processor and audio/video interleaving. ↩ ↩2 ↩3 ↩4

  10. Cloudflare, released processor_config.json. ↩