Ripple-65B: Embedding-Value-Residuals und hybride Attention

Ein veröffentlichtes dichtes Modell, kein Benchmark-Argument

Ripple-65B Preview ist Ricursive Intelligences veröffentlichtes dichtes, textbasiertes Modell. Der instruction-getunte Checkpoint besitzt BF16-Gewichte, eine Apache-2.0-Lizenz und eigenen Inferenzcode; zusätzlich bietet der Herausgeber eine separate NVFP4-Variante, einen Basis-Checkpoint und einen DFlash2-Draft an.¹ Dieser Artikel untersucht das BF16-Instruct-Repository mit Revision d91aa65807bcfda98d964135230cd756be291774, geprüft am 6. November 2026.

Das interessante Architekturdetail ist ein aus Eingabe-Embeddings gespeister Value-Residual-Pfad, neben PeriNorm, gegateter Attention und einem lokalen/globalen Attention-Mix. Im veröffentlichten HF-Code werden nicht direkt die V-Tensoren der ersten Schicht wiederverwendet. Auch das Cache-Verhalten hängt von der Implementierung ab, nicht nur vom konfigurierten Fenster.² Hier wurden keine Modellqualitäts-, GPU-Durchsatz- oder Peak-Speicher-Benchmarks ausgeführt.

Breite, Tiefe und Attention-Anordnung

Der Checkpoint hat 80 Schichten, Residualbreite 5.120, dichte FFN-Zwischenbreite 40.960, 80 Query-Heads, acht KV-Heads und Head-Dimension 128. Die Q-/Attention-Ausgabebreite beträgt daher 10.240, doppelt so viel wie die Residualbreite; die Head-Dimension darf nicht aus 5.120/80 abgeleitet werden. Je zehn Query-Heads teilen einen KV-Head. Das Vokabular umfasst 100.352 Tokens; Ein- und Ausgabe-Embeddings teilen ihre Gewichte nicht.³

Vier lokale Schichten gefolgt von einer globalen wiederholen sich sechzehnmal: 64 Sliding-Attention- und 16 Full-Attention-Schichten. Das lokale Fenster umfasst 1.024 Positionen einschließlich der aktuellen Position. Lokale Q/K erhalten headweise RMSNorm und RoPE über die volle Head-Breite mit Basis 10.000. Globale Q/K erhalten RMSNorm, aber kein RoPE; ihre Maske bleibt kausal. NoPE ist keine bidirektionale Attention.³² Zum Vergleich: Beams lokale/globale Positionsaufteilung und der Attention-Walkthrough.

Wo das Value-Residual tatsächlich einsetzt

$e_t$ sei das Token-Embedding nach der konfigurierten Embedding-Skalierung, $h_{\ell,t}$ der aktuelle vor der Attention normalisierte Residualzustand einer Schicht. Die gepinnte Konfiguration setzt den Embedding-Multiplikator auf ungefähr 71,55417528, also $\sqrt{5120}$. Das Modell legt seinen Value-Residual-Ausgangszustand vor der Decoder-Schleife fest und übergibt denselben Ausgangszustand an jede Schicht.³²

Jede Schicht lernt einen skalaren Parameter $\lambda_\ell$. Q und K entstehen aus $h_{\ell,t}$; die Eingabe ihrer eigenen V-Projektion lautet dagegen:

Die Orientierung folgt lerp(seed, current, blend) im Code: Ein kleines $\alpha$ bevorzugt den Embedding-Ausgangszustand, ein großes den aktuellen normalisierten Zustand. Weil $W^V_\ell$ linear ist, entspricht das $(1-\alpha_\ell)W^V_\ell e_t+\alpha_\ell W^V_\ell h_{\ell,t}$. Es entspricht nicht dem Beimischen von $W^V_0 e_t$ aus der ersten Attention-Schicht; jede Schicht hat ihre eigene Projektion.

Damit erhält der Value-Inhaltspfad direkten Zugriff auf eine über die Tiefe unveränderte lexikalische Darstellung, während Queries und Keys weiterhin vom kontextualisierten Zustand abhängen. Das erklärt den Datenfluss, beweist aber weder besseren Recall noch bessere Gradienten. Der Skalar ist schichtspezifisch, nicht token- oder headspezifisch. Seine Nullinitialisierung bedeutet 0,5 bei der Initialisierung, nicht einen gemessenen Mischkoeffizienten der veröffentlichten Gewichte.²

Bei Batch $B$ und aktueller Query-Länge $T$ hat der wiederverwendbare Ausgangszustand die Form [B,T,5120]. Projiziertes Q hat [B,T,80,128]; K und gemischtes V jeweils [B,T,8,128] vor der Transposition. Der schichtspezifische Cache speichert die resultierenden K/V früherer Positionen. Der gemeinsame Ausgangszustand über die Tiefe bedeutet keine gemeinsamen projizierten V-Caches zwischen Schichten. Beim Decode umfasst der Ausgangszustand das aktuelle Eingabetoken, nicht eine zusätzliche vollständige Kopie aller früheren Embeddings.²

Die Embedding-Skalierung beeinflusst deshalb sowohl den Haupt-Residualstrom als auch den Value-Ausgangszustand. Ein Engine-Port muss die Konvention erhalten: Den Multiplikator entweder zur Laufzeit anwenden oder in die Embedding-Gewichte einrechnen, nicht beides. Die Referenz behandelt beide Formen explizit; diese BF16-Konfiguration enthält den Laufzeitmultiplikator.²

Zwei unterschiedliche Gates, vier Blocknormen

Ripples Ausgabegate ist von $\alpha_\ell$ getrennt. Es projiziert die normalisierte Attention-Eingabe auf 10.240 Koordinaten, berechnet ein Sigmoid – in dieser Konfiguration in FP32 –, multipliziert das zusammengefügte Attention-Ergebnis und projiziert dann zurück auf Breite 5.120. Es ist eingabeabhängig und koordinatenweise; der Value-Mix ist ein einzelner gelernter Schichtskalar.³²

Der Block verwendet PeriNorm, mit separater Pre-/Post-RMSNorm um Attention und FFN:

Das sind vier Normen auf Residualbreite, zusätzlich zu den headweisen Q-/K-Normen. Das FFN bleibt ein dichtes SiLU-gegatetes MLP. Vor der Multiplikation wird die Gate-Projektion nur nach oben bei 20 abgeschnitten, die Up-Projektion dagegen auf [-20,20] begrenzt. Das ist weder symmetrisches Clipping beider Projektionen noch eine SiTU-GLU-Definition.² Alle dichten Schichten laufen für jedes Token; ein MoE-Budget aktiver Experts ersetzt hier nicht das vollständige Gewichtsbudget.

Eine Fenstermaske ist keine Cache-Eviction

In einer lokalen Schicht erlaubt die Referenzmaske einer Query an Position $p$ nur Keys mit $p-1023\leq j\leq p$. Das K/V-Update erfolgt aber vor dieser Maske. Benötigt die Referenz einen neuen Cache, erzeugt sie DynamicCache() ohne Modellkonfiguration.²

Transformers v4.57.6, die in diesem Checkpoint genannte Version, lässt diesen unkonfigurierten Cache mit vollständigen DynamicLayer-Tensoren wachsen und hängt K/V an. Aus der Maske leitet die Bibliothek keine lokale Fensteraufbewahrung ab. Konfigurationsabhängige Sliding-Caches sind dort ein anderer Pfad.⁴ Das ist eine statische Analyse des eigenen Cache-Konstruktionszweigs der Referenz, keine Behauptung, dass jede Engine oder jeder Aufrufer ihn verwendet.

Das sollte man nicht blind durch einen beschnittenen Cache ersetzen: Die Referenzmaske zählt Key-Positionen ab null und vergleicht sie mit absoluten Cache-Positionen. Eine kompakte Implementierung muss auch Fenster-Offsets und kausale Semantik erhalten. Hier wird kein Backend-Patch vorgeschlagen.

Für eine Anfrage in BF16 sei $S$ die behaltene Kontextlänge. Eine ideal kompakte Implementierung mit vollständiger globaler und begrenzter lokaler Historie besitzt folgende nominelle K/V-Nutzdaten:

Die führenden Faktoren stehen für K und V, acht KV-Heads, 128 Dimensionen und zwei Bytes pro Wert. Bei 1.048.576 Positionen ergibt das 64 GiB globale K/V + 256 MiB lokale Kapazität = 64,25 GiB. Werden dagegen alle Positionen in allen 80 Schichten behalten, sind es 320 GiB. Beide Zahlen schließen Gewichte, Allokator-Padding, temporäre GQA-Expansion, Masken, Logits, Draft-Zustände und Workspace aus. Es sind hergeleitete Nutzdaten, keine gemessenen Allokationen; eine gefensterte Laufzeit kann das aktuelle Token separat halten oder eine andere Seitengranularität nutzen.

Der globale Anteil wächst weiterhin linear mit $S$. Vier lokale Schichten pro globaler Schicht machen Inferenz über eine Million Tokens nicht zu einem Verfahren mit konstantem Speicherbedarf. Siehe die allgemeine KV-Cache-Dimensionierung.

Kontext- und Serving-Grenzen

Die Model Card nennt bis zu 1Mi Tokens; in den Konfigurationsmetadaten steht max_position_embeddings = 2.097.152. Das mitgelieferte B200-Serving-Rezept verwendet standardmäßig 1.048.576 Tokens insgesamt für Prompt und Ausgabe. Diese Angaben getrennt halten, statt einen Konfigurationswert stillschweigend als getestete Deployment-Grenze zu übernehmen.¹³⁵

Dieses Rezept zielt auf SGLang 0.5.19 auf zwei B200-GPUs, mit vollständigen BF16-Target- und passenden DFlash2-Checkpoints. Target-Kontext und Draft-Fenster unterscheiden sich: 16 Draft-Vorschläge sind konfiguriert, das Attention-Fenster des Drafts umfasst aber 16.384 Tokens. Keines davon garantiert 16-fachen Durchsatz. Das Rezept ist keine Anleitung, das separate NVFP4-Target unverändert einzusetzen.⁵

Die HF-Referenz verwendet PyTorch SDPA und wiederholt KV-Gruppen für die Attention explizit. Ihr lokaler Pfad erzeugt eine boolesche Query-mal-Key-Maske; der LM-Head projiziert außerdem alle zurückgegebenen Hidden-Positionen auf Vokabular-Logits. Diese temporären Allokationen können bei langem Prefill relevant sein, selbst wenn eine andere Serving-Engine einen kompakten hybriden Cache speichert. Ein Framework-Name belegt weder einen bestimmten fusionierten Kernel noch den Peak-Speicher.²

Was praktisch evaluiert werden sollte

Das dichte Modell und der Embedding-basierte Value-Pfad sind interessante Evaluationskandidaten für codeorientierte Deployments. Aus den Architekturgleichungen folgt aber kein kausaler Qualitätsvorteil. BF16-Target, mögliche quantisierte Targets und spekulative Konfigurationen getrennt mit denselben Prompts, derselben Parallelität, denselben Ausgabelimits und Korrektheitskriterien vergleichen. End-to-End-Latenz, Prefill-Peak-Speicher, stationäres Cache-Wachstum und akzeptierte Draft-Länge erfassen; Tool-Call-Parsing und Langkontext-Retrieval prüfen.

Die Erkenntnis ist präzise: Ein Embedding-Ausgangszustand kann verschiedene schichtspezifische V-Projektionen speisen, ohne KV-Caches zu teilen, und ein begrenztes Attention-Lesefenster braucht einen passenden Allokator, um gespeicherte lokale Historie zu begrenzen. Weder ein Benchmarkrang noch ein Fenstergrößenfeld belegt diese Implementierungseigenschaften.

Primärquellen