RWKV-7 (Goose): Een kijkje in de pull request die het eindelijk in Transformers zou laden

Het meest gedownloade RWKV-model op Hugging Face vorige maand was niet RWKV-7 (Goose), de architectuur die het project sinds maart 2025 uitbrengt, en het was ook niet RWKV7-G1, de redeneringsserie die daarop is getraind. Het was RWKV/rwkv-4-169m-pile: een RWKV-4-checkpoint van 169 miljoen parameters uit mei 2023, met 8.824 downloads in de 30 dagen tot 5 augustus 2026, tegenover 215 voor de 1.5B RWKV-7 Goose World-3-release en 316 voor de 2.9B. Het model uit 2023 is niet beter. Het is het model dat laadt met een gewone from_pretrained-aanroep en zonder dat er iets anders is geïnstalleerd.

Op 4 augustus 2026 opende een bijdrager genaamd Hakureirm pull request #47780 tegen huggingface/transformers, met als titel "Add RWKV-7 (Goose)". Per 5 augustus is het open, onbeoordeeld en niet samengevoegd, en het is de tweede poging — een eerder voorstel, #46984, werd afgewezen. Er is niets binnengekomen, en dit stuk moet niet worden gelezen als een release-aankondiging. Maar de diff is openbaar, en het richt zich op het meest saaie, meest consequente element dat tussen de langstlopende aandachtvrije LLM-afstamming en de stacks die de meeste teams daadwerkelijk gebruiken staat: een loader.

Wat volgt onderscheidt drie soorten beweringen, omdat berichtgeving over RWKV ze meestal door elkaar haalt. Er is wat verifieerbaar in de pull request en op de Hub staat, wat je zelf kunt controleren. Er is wat het RWKV-project over zijn eigen modellen rapporteert, op basis van zijn eigen evaluaties. En er is de grote verzameling vragen waarop niemand publiekelijk antwoord heeft gegeven, en dat is waar het meeste interessante risico ligt.

Wat zit er eigenlijk in de pull request?

De mechanische feiten, gelezen van de PR-pagina en de GitHub-API op 5 augustus 2026:

• Omvang — drie commits, 12 bestanden gewijzigd, 4.423 regels toegevoegd en nul verwijderd, van de branch add-rwkv7-upstream naar huggingface:main. Gelabeld als "Nieuw model". Geen toegewezen persoon, geen mijlpaal.

• Wat het toevoegt — RWKV-7 als twee openbare klassen, Rwkv7Model en Rwkv7ForCausalLM, naast een Rwkv7Cache die is gebaseerd op de LinearAttentionLayer van de bibliotheek. Het dtype van de WKV-toestand kan onafhankelijk van het model-dtype worden geconfigureerd, wat belangrijk is omdat de recurrente toestand de plek is waar numerieke drift zich in deze familie ophoopt.

• Hoe het draait — draagbare PyTorch zonder runtime-afhankelijkheid van derden. Prefill gebruikt een chunk-parallelle vorm van de recursie; decode draait een sequentieel pad van één token. Parameternamen volgen de referentie-implementatie van upstream RWKV in plaats van hernoemd te worden om transformer-achtig te lijken.

• Testaanpak — naast de standaardmodel-mixins, een integratietest die BlinkDL's eigen runtime token-voor-token matcht, plus een NumPy-referentie-implementatie die geen code deelt met het modelleringsbestand. De CI-recapbot van de repo meldt de laatste run als geslaagd: 16 jobs, 179.151 tests, nul fouten, 16 uur en 9 minuten rekentijd.

• Waar het staat — er is een review aangevraagd bij ArthurZucker en Rocketknight1; de pagina vermeldt dat ten minste één goedkeurende review vereist is om te mergen, en die is nog niet gegeven. GitHub's API beschreef de merge-status nog steeds als "instabiel" toen we het lazen, en een bot voor maintainers heeft gevraagd om de langzame testsuites (auto en rwkv7) uit te voeren vóór de merge. Met andere woorden: groen op de snelle CI, maar nog niet gezegend door een mens.

Het meest interessante deel van de beschrijving is de toegeving. De eerdere poging, #46984, werd afgewezen omdat de gepubliceerde RWKV-7-checkpoints niet de Transformers-conventies volgden, en de auteur zelf zegt dat "dat bezwaar terecht was." Het probleem, uiteengezet in de PR, is dat RWKV-7-gewichten op de Hub in twee voor de bibliotheek onbruikbare vormen komen:

• De PTH-repositories — ruwe .pth-bestanden, geen safetensors. Een bibliotheekimplementatie kan ze niet laden, en PyTorch-picklebestanden zijn precies wat een beveiligingsreview bij een groot bedrijf zal weigeren.

• De HF-repositories — deze leveren wel model.safetensors mee, maar elk bevat ook een modeling_rwkv7.py en een auto_map, dus het laden ervan vereist trust_remote_code. Dat is het uitvoeren van externe code als voorwaarde voor inferentie, en daarom stoppen zoveel bedrijfschecklists daar.

De PR doet dus twee dingen tegelijk. Het voegt een modelleringsbestand toe en verwijst naar een nieuwe set conversies die rechtstreeks zijn gemaakt van de canonieke BlinkDL .pth-releases die de standaardindeling volgen — alleen safetensors, geen pickle, geen externe code, een normale config.json met architecturen en model_type — variërend van 0,1B tot 7,2B. De kleinste, Hakureirm/rwkv7-168m-pile-hf, heeft al zijn 399 tensors geverifieerd als bit-identiek aan de bron .pth in plaats van steekproefsgewijs gecontroleerd. Die checkpoint is een Pile-model, dus de tokenizer is de gewone GPT-NeoX-20B snelle tokenizer in plaats van de RWKV World-woordenschat — om dezelfde reden dat de bestaande RWKV-pagina van de bibliotheek ook een Pile-checkpoint documenteert.

Waarom een checkpoint uit 2023 meer downloads krijgt dan de huidige architectuur

Transformers is op versie 5.14.1, uitgebracht op 16 juli 2026. Doorzoek de documentatie op RWKV en je krijgt precies één modelpagina, die "het RWKV-model (versie 4)" beschrijft, jaren geleden bijgedragen, met RWKV/rwkv-4-169m-pile als voorbeeld en een standaardvocabulaire van 50.277 tokens. Er zijn geen pagina's voor RWKV-5, RWKV-6 of RWKV-7. Er zijn drie architecturegeneraties uitgebracht sinds de RWKV-ondersteuning van de bibliotheek werd geschreven, en geen ervan zit erin.

De downloadcijfers laten zien wat het ecosysteem daaraan deed: het omzeilde de bibliotheek. Gesorteerd op downloads in de afgelopen 30 dagen zijn de top-RWKV-7-repositories de ruwe .pth-releases van BlinkDL (rwkv7-g1 op 8.288, rwkv-7-world op 4.489) en een dikke laag community-GGUF-kwantisa ties van de 13.3B G1 — meerdere afzonderlijke uploaders die elk één tot drieduizend downloads per maand halen. De officiële spiegels in transformers-formaat liggen twee ordes van grootte lager dan de ruwe gewichten. De flash-linear-attention-spiegel van de 2.9B G1 haalt 1.843.

Dat patroon heeft een eenvoudige verklaring. llama.cpp voegde op 17 maart 2025 ondersteuning voor RWKV v7 toe — een GGML_OP_RWKV_WKV7-kernel met CPU-, CUDA-, SYCL-, Vulkan- en Metal-backends — ongeveer een dag nadat de paper online kwam. Als je RWKV-7 op je eigen machine wilde draaien, was GGUF het snelle pad, en dat is het al zestien maanden. Het pad dat niet bestond, was het pad dat elk fine-tuning-script, elke PEFT-adapter, elke evaluatie-harness en elke interne serving-wrapper veronderstelt: AutoModelForCausalLM.from_pretrained, zonder vlaggen.

Wat RWKV-7 (Goose) eigenlijk is

RWKV-7 is een recurrent neuraal netwerk, geen transformer met een goedkopere attention-kernel, en de naamgeving verwart mensen voortdurend. Het draagt een state van vaste grootte door de sequentie in plaats van een groeiende cache van eerdere keys en values. Concreet, vergeleken met een standaard attentionmodel:

• Geheugen naarmate de context groeit — de KV-cache van een transformer groeit lineair met het aantal tokens dat in behandeling is; RWKV-7 behoudt een toestand waarvan de grootte wordt bepaald door de architectuur, niet door het gesprek. Dat is het hele efficiëntieargument.

• Kosten per token — aandacht kost meer per token naarmate de context langer wordt; RWKV-7's inferentiekosten per token zijn constant, daarom blijft het opduiken in edge- en always-on-stream-voorstellen.

• Trainingsvorm — in tegenstelling tot een klassieke RNN is de recurrentie paralleliseerbaar over een chunk, zodat pretraining niet ontaardt in een sequentiële kruipgang. Dat is wat het chunk-parallel prefill-pad van de PR implementeert.

• Contextplafond — er is geen cache om te overschrijden, dus het project adverteert effectief onbeperkte context. Wat een vaste toestand niet kan doen, is onbeperkte details vasthouden — dat is een echte beperking, geen voetnoot.

De architectonische bewering in het paper, gepubliceerd op 18 maart 2025 door Bo Peng, Yu Zhang, Songlin Yang en Ruichong Zhang onder het RWKV Project bij de LF AI & Data Foundation, is een gegeneraliseerde delta-regel met vectorwaardige gating, in-context leersnelheden en een versoepelde waarde-vervangingsregel, plus een vereenvoudigde MLP (de gating-matrix verwijderd, verborgen dimensie verbreed om dit te compenseren). Het theoretische resultaat dat hieraan gekoppeld is, is de meer provocerende helft: RWKV-7 kan state tracking uitvoeren en alle reguliere talen herkennen terwijl het paralleliseerbaar blijft in training, wat volgens de auteurs verder gaat dan wat transformatoren kunnen doen onder standaard complexiteitsconjecturen.

Alles valt onder Apache 2.0. De familie die je kunt downloaden is er in 0.1B (12 lagen, breedte 768), 0.4B (24 / 1024), 1.5B (24 / 2048), 2.9B (32 / 2560), 7.2B (32 / 4096) en 13.3B (61 lagen, breedte 4096), allemaal met een World-woordenschat van 65.536 tokens en een head-grootte van 64. De basis-Word-serie is getraind op een meertalig corpus van 3,1 biljoen tokens; de G1-serie "GooseOne" zet die training voort op World v3.5, een uitgebreide mix van 5,16 biljoen tokens met meer romans, webtekst, wiskunde, code en redeneerdata. Vanaf G1c voegen G1-checkpoints een redeneermodus met think-tag, JSON-functieaanroepen en fill-in-the-middle toe. De naamgeving is ronduit onhandig: G0 betekent minder dan één epoch, G1 betekent meer dan één, en de suffixletters geven datarevisies aan, waarbij latere letters betere data bevatten.

De cijfers, en van wie de cijfers zijn.

Hier is de eerlijke stand van het bewijs. De belangrijkste benchmarkclaim — dat het 2.9B-model een nieuwe 3B-state of the art vestigde op meertalige taken en de Engelstalige 3B-state of the art evenaarde met drastisch minder trainingstokens — is afkomstig van het paper zelf, gepubliceerd in maart 2025 en geëvalueerd tegen de 3B-modellen van die periode. Het doorliep OpenReview, wat meer controle is dan een blogpost van een leverancier krijgt, en het blijft een zelfgerapporteerd resultaat op een vijftien maanden oude vergelijkingsset.

De andere openbare meting van het project, UncheatableEval, is interessanter dan een rij op een leaderboard en krijgt bijna geen aandacht. In plaats van meerkeuze-benchmarks te scoren die in trainingssets lekken, meet het de compressieratio op gegevens die niet bestonden toen het model werd getraind: nieuwe arXiv-artikelen, verse GitHub-repositories, recent nieuws. Dat ontwerp maakt contaminatie veel moeilijker, en RWKV meldt concurrerend te zijn met transformers van dezelfde grootte op deze test. Het blijft echter een evaluatie die het project op zichzelf uitvoert.

Wat voor zover wij kunnen vinden niet bestaat, is een onafhankelijke indexscore van een derde partij voor welke RWKV-7-checkpoint dan ook — geen neutrale aggregator heeft de 7.2B of 13.3B door de testopstelling gehaald die op frontiermodellen draait. Dus vergelijkingen die je mogelijk ziet met modellen als DeepSeek V4 Flash of Qwen3.8-Max zijn om twee redenen categoriefouten: niemand heeft RWKV-7 op dezelfde evaluatie gedraaid, en een 13.3B dense RNN dingt niet mee naar hetzelfde werk als een frontiermodel. De verdedigbare bewering is smaller en nuttiger: van 1.5B tot 13.3B, met constant geheugen, in ongeveer twaalf talen, met permissieve gewichten.

RWKV-7 vandaag draaien, en wat jou dat kost

De Hub-pagina voor RWKV/RWKV7-Goose-World3-1.5B-HF is een goede momentopname van de huidige frictie. Het is een 1,52B-parameter BF16-model met de RWKV World-tokenizer, Apache 2.0, getagd met custom_code, en ondersteunt Engels, Chinees, Japans, Koreaans, Frans, Arabisch, Spaans en Portugees. De instructies vertellen je om flash-linear-attention en een recente versie van transformers te installeren voordat je het model laadt. En in de zijbalk, waar een gehost model providers zou tonen, staat er simpelweg: dit model wordt door geen enkele Inference Provider aangeboden.

Dus je opties vandaag zijn allemaal self-service:

• flash-linear-attention plus trust_remote_code — het dichtst bij normaal Hub-gebruik, maar je voert repositorycode uit en haalt Triton-kernels binnen, wat je beperkt op hardware en op alles wat een beveiligingsreview ondergaat.

• GGUF via llama.cpp — de best ondersteunde route in de praktijk, ook voor de 13.3B, en degene die mensen volgens de downloadcijfers daadwerkelijk nemen. Geweldig voor lokale inferentie, geen trainings- of fine-tuningpad.

• De eigen runtime van het project — het rwkv pip-pakket en de referentierepository, het dichtst bij canoniek, het verst verwijderd van de tooling die uw team al heeft.

Geen van die is een API die je kunt aanroepen, en het is de moeite waard om direct te zijn over de implicatie: RWKV-7 staat niet op OrcaRouter, omdat het nergens een gehost endpoint is dat we kunnen vinden. Als je RWKV-7 wilt, draai je RWKV-7. Wat we eerlijk kunnen zeggen is waar dat de rest van de stack laat. Het evalueren van een onbewezen architectuur is alleen goedkoop als je productiepad niet afhangt van de uitkomst, en de goedkoopste manier om dat zo te houden is om geen per-leverancier-integratie te hebben voor iets anders — één OpenAI-compatibele sleutel voor meer dan 200 modellen, leveranciersprijs rechtstreeks doorberekend met 0% opslag, en automatische failover wanneer een provider degradeert. Dan is een self-hosted RWKV-7-experiment op de twee workloads waar constant geheugen echt loont — een langlopende stream, een on-device-assistent, een summarizer die nooit stopt — een experiment, geen migratie. Dat is de vorm die de meeste teams hier zouden moeten willen: een gerouteerde standaard, en een statusgebaseerd model dat zich op een specifieke taak bewijst.

Wat zou deze landing nog kunnen stoppen?

Neem het precedent serieus: een voorstel om deze exacte architectuur toe te voegen werd al eerder afgewezen, op gronden die de auteur als geldig accepteert. Het nieuwe voorstel is beter beargumenteerd en beter getest, en het blijft een community-PR tegen een repository dat bewust conservatief is over het toelaten van architecturen die het vervolgens voor altijd zal onderhouden.

De specifieke openstaande vragen die we beantwoord zouden willen hebben voordat we dit als afgerond beschouwen:

• Review, niet CI — de geautomatiseerde suites zijn groen; er zijn twee maintainers gevraagd en geen van beiden heeft goedgekeurd. Transformers vereist één goedkeurende review, en de langzame tests zijn niet uitgevoerd.

• De snelheid van het dependency-vrije pad — puur PyTorch met een sequentiële single-token decode is draagbaar, en draagbaar is precies het punt, maar de PR publiceert geen throughput tegen de Triton-kernels in flash-linear-attention. Als native decode wezenlijk langzamer is, wordt de bibliotheek het compatibiliteitspad terwijl serieuze serving elders blijft.

• Welke checkpoints arriveren — de conventieconforme conversies bestrijken 0.1B tot 7.2B. De 13.3B G1, het model dat mensen eigenlijk willen, zit niet in die set, en het gedocumenteerde voorbeeld is een Pile-model met een GPT-NeoX-tokenizer in plaats van een chatmodel met een World-vocabulaire. Een samengevoegde loader zonder vlaggenschip-checkpoint erachter verandert minder dan het lijkt te doen.

• Het bewegende doelwit — het project staat niet stil. De G1-repository van BlinkDL is in dezelfde week bijgewerkt waarin deze PR werd geopend, community-kwantificaties zijn opgeschoven naar latere datarevisies dan G1c, en RWKV-8 'Heron' is publiekelijk voorvertoond met een suffix-automaatmechanisme genaamd ROSA. Heron is niet uitgebracht en niet gebenchmarkt; we noemen het alleen omdat een bibliotheekintegratie die laat in het leven van een generatie arriveert, een korte houdbaarheid heeft.

Vier vragen die het specificatieblad niet beantwoordt

Kan ik RWKV-7 nu in Transformers gebruiken, of niet?

Beide, irritant genoeg, en dat onderscheid is het hele verhaal. Je kunt vandaag al een RWKV-7-checkpoint laden via de transformers-API, als je flash-linear-attention installeert en trust_remote_code doorgeeft, zodat het eigen modeling-bestand van de repository draait. Wat je niet kunt doen, is het laden vanuit de bibliotheek zelf — en dat is wat het standaard laat werken in de tools die op de bibliotheek zijn gebouwd: trainings- en alignment-scripts, adapters, evaluatie-harnesses, exportpaden — en wat het laat voldoen aan een beleid dat externe code verbiedt. Dat tweede is waar #47780 voor dient.

{{1}}Maakt samenvoegen het model beter?{{/1}}

Niet met een enkel punt op welke benchmark dan ook. Het verandert de distributie, niet de kwaliteit — en voor een architectuur waarvan het probleem nooit kwaliteit is geweest, is distributie de bindende beperking. De vergelijking is die bovenaan dit artikel: een 169M-model uit 2023 wordt veertig tegen één meer gedownload dan de gewichten van de huidige generatie, geheel dankzij het laden zonder vlaggen.

Als er geen KV-cache is, krijg ik dan onbeperkte context gratis?

Je krijgt onbeperkte contextlengte zonder geheugenexplosie, maar dat is niet hetzelfde als onbeperkte terugvinding. Een toestand van vaste omvang heeft een vaste informatiecapaciteit; voer er een miljoen tokens aan toe en het kan geen miljoen tokens aan terugvindbare details bevatten. Attention met een volledige cache kan dat wel, tegen kosten die onderweg blijven groeien. Behandel het lange-contextverhaal van RWKV-7 als 'stroomt voor altijd goedkoop, comprimeert al doende' en test de specifieke terugvinding die je nodig hebt in plaats van het woord oneindig te vertrouwen.

Is het bij 13,3B de moeite waard om je er zorgen over te maken als frontiermodellen honderden miljarden parameters hebben?

Het hangt er volledig van af of een constant geheugengebruik voor jou iets waard is. Als je een gehoste API aanroept en per token betaalt, is dat vrijwel zeker niet het geval — de modernste modellen lopen ver voorop qua mogelijkheden en je betaalt niet direct voor de KV-cache. Als je inferentie draait op hardware die je niet beheert, of een continue stream draait waarbij een groeiende cache uiteindelijk het proces doet crashen, dan is een architectuur met een constant geheugengebruik een ander soort antwoord op een andere vraag. Dat zijn de workloads waarin een 2.9B RWKV-7 stilletjes concurrerend is geweest, en het zijn de workloads waarin een native loader het meest van belang zou zijn.

Wat we hierna zouden kijken

Vier concrete signalen, in ruwe volgorde van hoeveel ze onze inschatting zouden veranderen. {{1}}Een goedkeurende review van ArthurZucker of Rocketknight1, die dit verandert van een hoopgevende diff naar een geplande feature.{{/1}} {{2}}Een conventieconforme conversie van de 13.3B G1 met de World-tokenizer, dat is wat de loader de moeite waard maakt.{{/2}} {{3}}Gepubliceerde doorvoercijfers voor het afhankelijkheidsvrije decodeerpad tegenover de Triton-kernels, die bepalen of native ondersteuning een serveringsoptie is of een compatibiliteits-shim.{{/3}} {{4}}En enig teken van RWKV-8, dat je zou vertellen of deze integratie aankomt aan het begin van een generatie of aan het einde ervan.{{/4}}

Tot ten minste de eerste daarvan is de juiste samenvatting de ongeglamoureerde: RWKV-7 (Goose) is echt, heeft een permissieve licentie, is downloadbaar tot 13.3B, en is nog steeds niet native te laden in de bibliotheek waar het grootste deel van het ecosysteem op is gebouwd. Een pull request die op 4 augustus 2026 werd geopend, stelt voor om dat op te lossen. Het is niet gemerged, en pull requests om architecturen aan transformers toe te voegen worden ook gesloten.