RWKV-7 (Goose): Einblicke in den Pull Request, der es endlich in Transformers laden würde

Das meistgeladene RWKV-Modell auf Hugging Face war letzten Monat nicht RWKV-7 (Goose), die Architektur, die das Projekt seit März 2025 veröffentlicht hat, und es war auch nicht RWKV7-G1, die darauf trainierte Reasoning-Serie. Es war RWKV/rwkv-4-169m-pile: ein RWKV-4-Checkpoint mit 169 Millionen Parametern vom Mai 2023, mit 8.824 Downloads in den 30 Tagen bis zum 5. August 2026, gegenüber 215 für die 1,5B-RWKV-7-Goose-World-3-Veröffentlichung und 316 für die 2,9B. Das Modell von 2023 ist nicht besser. Es ist dasjenige, das mit einem einfachen from_pretrained-Aufruf lädt und sonst nichts installiert hat.

Am 4. August 2026 eröffnete ein Beitragender namens Hakureirm den Pull-Request #47780 gegen huggingface/transformers mit dem Titel „Add RWKV-7 (Goose)“. Stand 5. August ist er offen, ungeprüft und nicht gemergt, und es ist der zweite Versuch — ein früherer Vorschlag, #46984, wurde abgelehnt. Es ist nichts gelandet, und dieser Beitrag sollte nicht als Veröffentlichungsankündigung gelesen werden. Aber der Diff ist öffentlich, und er befasst sich mit der banalsten und folgenreichsten Sache, die zwischen der am längsten laufenden Aufmerksamkeits-freien LLM-Linie und den Stacks steht, die die meisten Teams tatsächlich verwenden: einem Lader.

Das Folgende unterscheidet drei Arten von Behauptungen, da die Berichterstattung über RWKV sie normalerweise vermischt. Es gibt das, was nachweislich im Pull-Request und auf dem Hub steht, was man selbst überprüfen kann. Es gibt das, was das RWKV-Projekt über seine eigenen Modelle auf der Grundlage seiner eigenen Evaluierungen berichtet. Und es gibt die große Menge an Fragen, die niemand öffentlich beantwortet hat – und genau dort liegt der Großteil des interessanten Risikos.

Was ist eigentlich in dem Pull-Request?

Die mechanischen Fakten, ausgelesen von der PR-Seite und der GitHub-API am 5. August 2026:

• Umfang — drei Commits, 12 geänderte Dateien, 4.423 Zeilen hinzugefügt und keine gelöscht, vom Branch add-rwkv7-upstream in huggingface:main. Gekennzeichnet als „Neues Modell“. Kein Bearbeiter, kein Meilenstein.

• Was es hinzufügt — RWKV-7 als zwei öffentliche Klassen, Rwkv7Model und Rwkv7ForCausalLM, zusammen mit einem Rwkv7Cache, der auf dem LinearAttentionLayer der Bibliothek aufbaut. Der dtype des WKV-Zustands ist unabhängig vom Modell-dtype konfigurierbar, was wichtig ist, da der rekursive Zustand der Ort ist, an dem sich in dieser Familie numerische Drift ansammelt.

• So läuft es — portables PyTorch ohne Abhängigkeit von Drittanbieter-Laufzeiten. Prefill verwendet eine chunk-parallele Form der Rekurrenz; Decode läuft über einen sequenziellen Einzel-Token-Pfad. Die Parameternamen folgen der Upstream-RWKV-Referenzimplementierung, statt umbenannt zu werden, um transformerartig zu wirken.

• Testansatz — über die Standard-Modell-Mixins hinaus ein Integrationstest, der BlinkDLs eigene Laufzeit Token-für-Token abgleicht, plus eine NumPy-Referenzimplementierung, die keinerlei Code mit der Modellierungsdatei teilt. Der CI-Zusammenfassungsbot des Repos meldet den letzten Lauf als erfolgreich: 16 Jobs, 179.151 Tests, null Fehler, 16 Stunden und 9 Minuten Rechenzeit.

• Wo es steht — ArthurZucker und Rocketknight1 wurden um ein Review gebeten; die Seite gibt an, dass mindestens ein genehmigendes Review zum Merge erforderlich ist, und keines der beiden wurde abgegeben. Die GitHub-API beschrieb den Merge-Zustand bei unserem Abruf weiterhin als „instabil“, und ein an Maintainer gerichteter Bot hat darum gebeten, dass die Slow-Test-Suiten (auto und rwkv7) vor dem Merge ausgeführt werden. Mit anderen Worten: Grün auf dem schnellen CI, aber noch nicht von einem Menschen abgesegnet.

Der interessanteste Teil der Beschreibung ist das Zugeständnis. Der frühere Versuch, #46984, wurde abgelehnt, weil die veröffentlichten RWKV-7-Checkpoints nicht den Transformers-Konventionen folgten, und der Autor selbst sagt, dass „dieser Einwand richtig war.“ Das Problem, das im PR dargelegt wird, besteht darin, dass die RWKV-7-Gewichte auf dem Hub in zwei für die Bibliothek unbrauchbaren Formen vorliegen:

• Die PTH-Repositorys — rohe .pth-Dateien, keine Safetensors. Eine Bibliotheksimplementierung kann sie nicht laden, und PyTorch-Pickle-Dateien sind genau das, was ein Sicherheits-Review bei einem großen Unternehmen ablehnen wird.

• Die HF-Repositories — diese enthalten zwar model.safetensors, aber jedes enthält auch eine modeling_rwkv7.py und eine auto_map, sodass das Laden eines davon trust_remote_code erfordert. Das ist Remote-Codeausführung als Bedingung für die Inferenz, weshalb so viele Unternehmens-Checklisten dort stoppen.

Der PR übernimmt also zwei Aufgaben auf einmal. Er fügt eine Modellierungsdatei hinzu und verweist auf einen neuen Satz von Konvertierungen, die direkt aus den kanonischen BlinkDL-.pth-Releases erstellt wurden, welche dem Standardlayout folgen – nur safetensors, kein Pickle, kein Remote-Code, eine normale config.json mit architectures und model_type – von 0,1B bis 7,2B. Bei dem kleinsten, Hakureirm/rwkv7-168m-pile-hf, wurden alle 399 Tensoren bitidentisch mit dem Quell-.pth verifiziert, statt nur stichprobenartig geprüft. Dieser Checkpoint ist ein Pile-Modell, daher ist sein Tokenizer der übliche GPT-NeoX-20B-Fast-Tokenizer und nicht das RWKV-World-Vokabular – aus demselben Grund dokumentiert die bestehende RWKV-Seite der Bibliothek ebenfalls einen Pile-Checkpoint.

Warum ein Checkpoint aus 2023 die aktuelle Architektur an Downloads übertrifft

Transformers liegt in Version 5.14.1 vor, veröffentlicht am 16. Juli 2026. Durchsucht man seine Dokumentation nach RWKV, erhält man genau eine Modellseite, die „das RWKV-Modell (Version 4)“ beschreibt, das vor Jahren beigetragen wurde, mit RWKV/rwkv-4-169m-pile als Beispiel und einem Standard-Vokabular von 50.277 Token. Es gibt keine Seiten für RWKV-5, RWKV-6 oder RWKV-7. Seit die RWKV-Unterstützung der Bibliothek implementiert wurde, sind drei Architektur-Generationen erschienen, und keine davon ist darin enthalten.

Die Download-Zahlen zeigen, was das Ökosystem dagegen getan hat: Es hat die Bibliothek umgangen. Sortiert nach Downloads der letzten 30 Tage sind die wichtigsten RWKV-7-Repositories BlinkDLs rohe .pth-Veröffentlichungen (rwkv7-g1 mit 8.288, rwkv-7-world mit 4.489) sowie eine dicke Schicht von Community-GGUF-Quantisierungen des 13,3B G1 — mehrere separate Uploader, die jeweils ein- bis dreitausend Downloads pro Monat erreichen. Die offiziellen transformers-Format-Spiegel liegen zwei Größenordnungen unter den rohen Gewichten. Der flash-linear-attention-Spiegel des 2,9B G1 kommt auf 1.843.

Dieses Muster hat eine einfache Erklärung. llama.cpp hat am 17. März 2025 die Unterstützung für RWKV v7 integriert — einen GGML_OP_RWKV_WKV7-Kernel mit CPU-, CUDA-, SYCL-, Vulkan- und Metal-Backends — etwa einen Tag nachdem das Paper veröffentlicht wurde. Wenn man RWKV-7 auf dem eigenen Rechner ausführen wollte, war GGUF der schnelle Weg, und das ist es seit sechzehn Monaten. Der Weg, der nicht existierte, war der, den jedes Fine-Tuning-Skript, jeder PEFT-Adapter, jede Evaluations-Harness und jeder interne Serving-Wrapper voraussetzt: AutoModelForCausalLM.from_pretrained, ohne Flags.

Was RWKV-7 (Goose) eigentlich ist

RWKV-7 ist ein rekurrentes neuronales Netz, kein Transformer mit einem günstigeren Attention-Kernel, und die Namensgebung verwirrt die Leute ständig. Es trägt einen Zustand fester Größe durch die Sequenz fort, anstatt eines wachsenden Caches vergangener Schlüssel und Werte. Konkret im Vergleich zu einem Standard-Attention-Modell:

• Speicher bei wachsendem Kontext — der KV-Cache eines Transformers wächst linear mit der Anzahl der verarbeiteten Tokens; RWKV-7 hält einen Zustand bereit, dessen Größe durch die Architektur festgelegt wird, nicht durch die Konversation. Das ist das gesamte Effizienzargument.

• Kosten pro Token — Attention kostet pro Token mehr, je länger der Kontext wird; die Inferenzkosten pro Token von RWKV-7 sind konstant, weshalb es immer wieder in Edge- und Always-on-Stream-Vorschlägen auftaucht.

• Trainingsform — anders als bei einem klassischen RNN ist die Rekurrenz über einen Chunk parallelisierbar, sodass das Vortraining nicht zu einem sequenziellen Kriechen verkommt. Genau das implementiert der Chunk-parallele Prefill-Pfad des PRs.

• Kontextobergrenze — es gibt keinen Cache, der überlaufen könnte, daher vermarktet das Projekt effektiv unbegrenzten Kontext. Ein fester Zustand kann keine unbegrenzten Details festhalten, was eine echte Einschränkung und keine Fußnote ist.

The architectural claim in the paper, published 18 March 2025 by Bo Peng, Yu Zhang, Songlin Yang and Ruichong Zhang under the RWKV Project at the LF AI & Data Foundation, is a generalized delta rule with vector-valued gating, in-context learning rates and a relaxed value-replacement rule, plus a simplified MLP (the gating matrix removed, hidden dimension widened to compensate). The theoretical result attached to it is the more provocative half: RWKV-7 can perform state tracking and recognize all regular languages while remaining parallelizable in training, which the authors argue exceeds what transformers can do under standard complexity conjectures.

Alles steht unter Apache 2.0. Die Familie, die du herunterladen kannst, umfasst 0,1B (12 Schichten, Breite 768), 0,4B (24 / 1024), 1,5B (24 / 2048), 2,9B (32 / 2560), 7,2B (32 / 4096) und 13,3B (61 Schichten, Breite 4096), alle mit einem 65.536-Token-World-Vokabular und Kopfgröße 64. Die Basis-World-Serie wurde auf einem mehrsprachigen Korpus mit 3,1 Billionen Token trainiert; die G1-„GooseOne“-Serie setzt dieses Training auf World v3.5 fort, einer erweiterten Mischung aus 5,16 Billionen Token mit mehr Romanen, Webtexten, Mathematik, Code und Reasoning-Daten. G1-Checkpoints fügen ab G1c einen Think-Tag-Reasoning-Modus, JSON-Funktionsaufrufe und Fill-in-the-Middle hinzu. Die Benennung ist wirklich umständlich: G0 bedeutet weniger als eine Epoche, G1 mehr als eine, und die Suffixbuchstaben kennzeichnen Datenrevisionen, wobei spätere Buchstaben bessere Daten enthalten.

Die Zahlen, und wessen Zahlen sie sind

Hier ist der ehrliche Stand der Evidenz. Die zentrale Benchmark-Behauptung — dass das 2,9B-Modell einen neuen 3B-State-of-the-Art bei mehrsprachigen Aufgaben aufstellte und den englischsprachigen 3B-State-of-the-Art mit drastisch weniger Trainings-Tokens erreichte — stammt vom Paper selbst, das im März 2025 veröffentlicht und gegen die damaligen 3B-Modelle evaluiert wurde. Es durchlief OpenReview, was mehr Prüfung ist, als ein Anbieter-Blogbeitrag erhält — und dennoch handelt es sich um ein selbstberichtetes Ergebnis auf einem fünfzehn Monate alten Vergleichsset.

Die andere öffentliche Messung des Projekts, UncheatableEval, ist interessanter als eine Leaderboard-Zeile und erhält fast keine Berichterstattung. Anstatt Multiple-Choice-Benchmarks zu bewerten, die in Trainingsdatensätze durchsickern, misst sie die Kompressionsrate bei Daten, die es zum Zeitpunkt des Trainings des Modells noch nicht gab: neue arXiv-Papiere, frische GitHub-Repositories, aktuelle Nachrichten. Dieses Design macht Kontamination viel schwieriger, und RWKV berichtet, dass es auf diesem Gebiet mit gleich großen Transformatoren konkurrenzfähig ist. Es ist immer noch eine Evaluierung, die das Projekt an sich selbst durchführt.

Was es nach unserem Kenntnisstand nicht gibt, ist ein unabhängiger Drittanbieter-Indexwert für irgendeinen RWKV-7-Checkpoint – kein neutraler Aggregator hat die 7.2B oder 13.3B durch die Testumgebung laufen lassen, die er bei Frontier-Modellen verwendet. Vergleiche, die man also gegen Modelle wie DeepSeek V4 Flash oder Qwen3.8-Max sieht, sind gleich doppelt Kategorienfehler: Niemand hat RWKV-7 mit derselben Evaluierung getestet, und ein dichtes RNN mit 13.3B Parametern tritt nicht für dieselbe Aufgabe an wie ein Frontier-System. Die vertretbare Behauptung ist enger und nützlicher: bei 1.5B bis 13.3B, mit konstantem Speicher, in etwa zwölf Sprachen, mit permissiven Gewichten.

RWKV-7 heute ausführen – und was dich das kostet

Die Hub-Seite für RWKV/RWKV7-Goose-World3-1.5B-HF ist ein gutes Beispiel für die derzeitigen Reibungspunkte. Es ist ein 1,52B-Parameter-BF16-Modell mit dem RWKV-World-Tokenizer, Apache 2.0, als custom_code gekennzeichnet, das Englisch, Chinesisch, Japanisch, Koreanisch, Französisch, Arabisch, Spanisch und Portugiesisch auflistet. Die Anweisungen sagen, man solle flash-linear-attention und eine aktuelle transformers-Version installieren, bevor man es lädt. Und in der Seitenleiste, wo ein gehostetes Modell Anbieter anzeigen würde, steht schlicht: Dieses Modell wird von keinem Inference-Anbieter bereitgestellt.

Deine Optionen heute sind also alle im Selbstbedienungsmodus:

• flash-linear-attention plus trust_remote_code — am nächsten an der normalen Hub-Nutzung, aber Sie führen Repository-Code aus und binden Triton-Kernel ein, was Sie hinsichtlich der Hardware und bei allem mit einer Sicherheitsüberprüfung einschränkt.

• GGUF via llama.cpp — der in der Praxis am besten unterstützte Weg, auch für die 13.3B, und der, den die Download-Zahlen zufolge die Leute tatsächlich nehmen. Großartig für lokale Inferenz, kein Weg für Training oder Fine-Tuning.

• Die eigene Laufzeitumgebung des Projekts — das rwkv-Pip-Paket und das Referenz-Repository, am nächsten am kanonischen Original, am weitesten vom Tooling entfernt, das Ihr Team bereits hat.

Keines davon ist eine API, die du aufrufen kannst, und es lohnt sich, die Implikation klar auszusprechen: RWKV-7 ist nicht auf OrcaRouter, weil es keinen gehosteten Endpoint gibt, den wir irgendwo finden können. Wenn du RWKV-7 willst, betreibst du RWKV-7. Was wir ehrlich sagen können, ist, wo das den Rest des Stacks lässt. Die Evaluierung einer unbewährten Architektur ist nur dann günstig, wenn dein Produktionspfad nicht vom Ergebnis abhängt, und der günstigste Weg, das so zu halten, ist, für nichts anderes eine Integration pro Anbieter zu haben — ein OpenAI-kompatibler Schlüssel für über 200 Modelle, Listenpreise der Anbieter ohne Aufschlag direkt durchgereicht und automatisches Failover, wenn ein Anbieter nachlässt. Dann ist ein selbst gehostetes RWKV-7-Experiment auf den zwei Workloads, bei denen konstanter Speicher sich tatsächlich auszahlt — ein langlaufender Stream, ein On-Device-Assistent, ein Summarizer, der nie aufhört — ein Experiment, keine Migration. Das ist die Form, die die meisten Teams hier anstreben sollten: ein gerouteter Standard und ein zustandsbasiertes Modell, das sich auf einer bestimmten Aufgabe seinen Platz verdient.

Was könnte diese Landung noch stoppen?

Nehmen Sie den Präzedenzfall ernst: Ein Vorschlag, genau diese Architektur hinzuzufügen, wurde bereits einmal abgelehnt, aus Gründen, die der Autor als berechtigt anerkannte. Der neue Vorschlag ist besser begründet und besser getestet, und es ist weiterhin ein Community-PR gegen ein Repository, das bewusst konservativ darin ist, Architekturen aufzunehmen, die es dann für immer pflegen wird.

Die konkreten offenen Fragen, die wir beantwortet haben möchten, bevor wir das für abgeschlossen erklären:

• Review, nicht CI — die automatisierten Suites sind grün; zwei Maintainer wurden angefragt, aber keiner hat zugestimmt. Transformers erfordert ein zustimmendes Review, und die langsamen Tests wurden nicht ausgeführt.

• Die Geschwindigkeit des abhängigkeitsfreien Pfads — reines PyTorch mit sequentiellem Einzel-Token-Dekodieren ist portabel, und genau das ist der springende Punkt, aber der PR veröffentlicht keinen Durchsatz im Vergleich zu den Triton-Kernels in flash-linear-attention. Wenn das native Dekodieren wesentlich langsamer ist, wird die Bibliothek zum Kompatibilitätspfad, während ernsthaftes Serving woanders stattfindet.

• Welche Checkpoints verfügbar sind — die konventionskonformen Konvertierungen decken 0,1B bis 7,2B ab. Der 13,3B G1, der eigentlich der ist, den die Leute wollen, ist nicht in dieser Menge enthalten, und das dokumentierte Beispiel ist ein Pile-Modell mit einem GPT-NeoX-Tokenizer und kein Chat-Modell mit World-Vokabular. Ein zusammengeführter Loader ohne dahinterstehenden Flaggschiff-Checkpoint verändert weniger, als es den Anschein hat.

• Das bewegliche Ziel — das Projekt steht nicht still. BlinkDLs G1-Repository wurde in derselben Woche aktualisiert, in der dieser PR eröffnet wurde, Community-Quantisierungen sind auf spätere Datenrevisionen als G1c umgestiegen, und RWKV-8 „Heron“ wurde öffentlich mit einem Suffix-Automaten-Mechanismus namens ROSA vorgestellt. Heron ist unveröffentlicht und ohne Benchmarks; wir erwähnen es nur, weil eine Bibliotheksintegration, die spät im Leben einer Generation ankommt, eine kurze Haltbarkeit hat.

Vier Fragen, die das Datenblatt nicht beantwortet.

Kann ich RWKV-7 jetzt in Transformers verwenden, oder nicht?

Beides, ärgerlicherweise, und der Unterschied ist die ganze Geschichte. Sie können heute einen RWKV-7-Checkpoint über die transformers-API laden, wenn Sie flash-linear-attention installieren und trust_remote_code übergeben, damit die eigene Modellierungsdatei des Repositorys ausgeführt wird. Was Sie nicht tun können, ist, es aus der Bibliothek selbst zu laden, was es standardmäßig in den auf der Bibliothek aufbauenden Tools zum Funktionieren bringt – Trainings- und Alignment-Skripte, Adapter, Evaluierungs-Harnesses, Exportpfade – und was es ermöglicht, eine Richtlinie zu bestehen, die Remote-Code verbietet. Für diese zweite Sache ist #47780 da.

Macht das Zusammenführen das Modell besser?

Nicht um einen einzigen Punkt in irgendeinem Benchmark. Es verändert die Verteilung, nicht die Qualität – und für eine Architektur, deren Problem noch nie die Qualität war, ist die Verteilung die bindende Beschränkung. Der Vergleich ist der am Anfang dieses Artikels: Ein 169M-Modell aus dem Jahr 2023 wird vierzigmal so häufig heruntergeladen wie aktuelle Gewichte, ganz allein dank des Ladens ohne Flags.

Wenn es keinen KV-Cache gibt, bekomme ich dann unbegrenzten Kontext kostenlos?

Sie erhalten {{1}}unbegrenzte Kontextlänge ohne die Speicherexplosion{{/1}}, was {{2}}nicht dasselbe wie unbegrenzter Abruf{{/2}} ist. Ein Zustand fester Größe hat eine feste Informationskapazität; füttern Sie ihn mit einer Million Tokens, und er kann keine abrufbaren Details in diesem Umfang speichern. Aufmerksamkeit mit einem {{3}}vollständigen Cache{{/3}} kann dies leisten, zu Kosten, die kontinuierlich steigen. Betrachten Sie die Langkontext-Geschichte von RWKV-7 als „{{4}}streamt für immer günstig, komprimiert beim Fortschreiten{{/4}}“, und {{5}}testen Sie den spezifischen Abruf, den Sie benötigen{{/5}}, anstatt {{6}}dem Wort unendlich zu vertrauen{{/6}}.

Ist es bei 13,3B der Mühe wert, wenn Frontier-Modelle hunderte Milliarden haben?

Es hängt vollständig davon ab, ob konstanter Speicher für dich überhaupt etwas wert ist. Wenn du eine gehostete API aufrufst und pro Token zahlst, fast sicher nicht – die Spitzenmodelle sind bei der Leistungsfähigkeit weit voraus, und du zahlst nicht direkt für den KV-Cache. Wenn du Inferenz auf Hardware auslieferst, die du nicht kontrollierst, oder einen dauerhaften Stream betreibst, bei dem ein wachsender Cache das ist, was den Prozess irgendwann tötet, ist eine Architektur, deren Speicherbedarf sich nicht verändert, eine andere Art von Antwort auf eine andere Frage. Das sind die Workloads, bei denen ein 2.9B RWKV-7 leise konkurrenzfähig war, und sie sind diejenigen, bei denen ein nativer Loader am wichtigsten wäre.

Was wir als Nächstes sehen würden

Vier konkrete Signale, grob geordnet danach, wie stark sie unsere Einschätzung verändern würden. Eine zustimmende Bewertung von ArthurZucker oder Rocketknight1, die dies von einem vielversprechenden Diff in eine geplante Funktion verwandelt. Eine konventionskonforme Konvertierung des 13.3B G1 mit dem World-Tokenizer, die den Loader erst lohnenswert macht. Veröffentlichte Durchsatzzahlen für den abhängigkeitsfreien Dekodierungspfad im Vergleich zu den Triton-Kernels, die entscheiden, ob native Unterstützung eine Serving-Option oder ein Kompatibilitäts-Shim ist. Und jedes Anzeichen von RWKV-8, das dir verrät, ob diese Integration am Anfang einer Generation oder am Ende einer ankommt.

Bis {{1}}zumindest zum ersten davon{{/1}} ist die korrekte Zusammenfassung die unspektakuläre: RWKV-7 (Goose) ist real, permissiv lizenziert, bis 13,3B herunterladbar und weiterhin nicht nativ ladbar in der Bibliothek, auf der der Großteil des Ökosystems aufbaut. Ein am 4. August 2026 eröffneter Pull-Request schlägt vor, das zu ändern. Er wurde nicht gemergt, und {{2}}Pull-Requests, die Architekturen zu transformers hinzufügen, werden durchaus geschlossen{{/2}}.