RWKV-7 (Goose): Por dentro do Pull Request que finalmente o carregaria no Transformers

O modelo RWKV mais baixado no Hugging Face no mês passado não foi o RWKV-7 (Goose), a arquitetura que o projeto lança desde março de 2025, e também não foi o RWKV7-G1, a série de raciocínio treinada sobre ela. Foi o RWKV/rwkv-4-169m-pile: um checkpoint RWKV-4 de 169 milhões de parâmetros de maio de 2023, com 8.824 downloads nos 30 dias até 5 de agosto de 2026, contra 215 para a versão RWKV-7 Goose World-3 de 1,5B e 316 para a de 2,9B. O modelo de 2023 não é melhor. É o que carrega com uma simples chamada from_pretrained e nada mais instalado.

Em 4 de agosto de 2026, um colaborador chamado Hakureirm abriu o pull request #47780 no huggingface/transformers, intitulado "Add RWKV-7 (Goose)". Em 5 de agosto, ele está aberto, sem revisão e sem merge, e é a segunda tentativa — uma proposta anterior, #46984, foi recusada. Nada foi incorporado, e este texto não deve ser lido como um anúncio de lançamento. Mas o diff é público e aborda a coisa mais chata e mais consequente que se interpõe entre a linhagem de LLM sem atenção mais duradoura e as pilhas que a maioria das equipes realmente usa: um carregador.

O que se segue separa três tipos de afirmação, porque a cobertura do RWKV geralmente os mistura. Há o que está verificavelmente no pull request e no Hub, que você pode conferir por conta própria. Há o que o projeto RWKV relata sobre seus próprios modelos, em suas próprias avaliações. E há o grande conjunto de perguntas que ninguém respondeu publicamente, que é onde reside a maior parte do risco interessante.

O que está realmente no pull request

Os fatos mecânicos, lidos na página do PR e na API do GitHub em 5 de agosto de 2026:

• Escopo — três commits, 12 arquivos alterados, 4.423 linhas adicionadas e zero excluídas, do branch add-rwkv7-upstream para huggingface:main. Rotulado como "Novo modelo". Sem responsável, sem marco.

• O que acrescenta — RWKV-7 como duas classes públicas, Rwkv7Model e Rwkv7ForCausalLM, juntamente com um Rwkv7Cache construído sobre a LinearAttentionLayer da biblioteca. O dtype do estado WKV é configurável independentemente do dtype do modelo, o que importa porque o estado recorrente é onde a deriva numérica se acumula nesta família.

• Como executa — PyTorch portátil, sem dependência de runtime de terceiros. O prefill usa uma forma de recorrência paralela por blocos; o decode executa um caminho sequencial de token único. Os nomes dos parâmetros seguem a implementação de referência do RWKV upstream, em vez de serem renomeados para parecerem transformers.

• Postura de teste — além dos mixins de modelo padrão, um teste de integração que corresponde ao runtime do próprio BlinkDL token por token, além de uma implementação de referência em NumPy que não compartilha código com o arquivo de modelagem. O bot de resumo de CI do repositório relata a execução mais recente como bem-sucedida: 16 trabalhos, 179.151 testes, zero falhas, 16 horas e 9 minutos de computação.

• Onde estamos — foi solicitada revisão de ArthurZucker e Rocketknight1; a página afirma que é necessária pelo menos uma revisão aprovadora para fazer o merge, e nenhuma das duas foi dada. A API do GitHub ainda descrevia o estado do merge como "instável" quando a consultamos, e um bot voltado para mantenedores pediu que as suítes de testes lentos (auto e rwkv7) fossem executadas antes do merge. Em outras palavras: verde na CI rápida, mas ainda não aprovado por um humano.

A parte mais interessante da descrição é a concessão. A tentativa anterior, #46984, foi recusada porque os checkpoints publicados do RWKV-7 não seguiam as convenções do Transformers, e o próprio enquadramento do autor é que "essa objeção estava correta". O problema, exposto no PR, é que os pesos do RWKV-7 no Hub vêm em dois formatos inutilizáveis pela biblioteca:

• Os repositórios PTH — arquivos .pth brutos, sem safetensors. Uma implementação de biblioteca não pode carregá-los, e arquivos pickle do PyTorch são exatamente o que uma revisão de segurança em uma grande empresa recusará.

• Os repositórios HF — estes de fato incluem model.safetensors, mas cada um também inclui um modeling_rwkv7.py e um auto_map, então carregar um exige trust_remote_code. Isso é execução remota de código como condição para inferência, e é por isso que tantos checklists empresariais param por aí.

Então, o PR faz dois trabalhos ao mesmo tempo. Ele adiciona um arquivo de modelagem e aponta para um novo conjunto de conversões feitas diretamente dos lançamentos canônicos .pth do BlinkDL que seguem o layout padrão — apenas safetensors, sem pickle, sem código remoto, um config.json normal contendo architectures e model_type — abrangendo de 0.1B a 7.2B. O menor, Hakureirm/rwkv7-168m-pile-hf, tem todos os seus 399 tensores verificados como bit-idênticos em relação ao .pth de origem, em vez de verificação por amostragem. Esse checkpoint é um modelo Pile, então seu tokenizador é o tokenizador rápido comum GPT-NeoX-20B, em vez do vocabulário RWKV World — a mesma razão pela qual a página RWKV existente da biblioteca também documenta um checkpoint Pile.

Por que um checkpoint de 2023 supera a arquitetura atual em downloads

Transformers está na versão 5.14.1, lançada em 16 de julho de 2026. Pesquise por RWKV em sua documentação e você obterá exatamente uma página de modelo, descrevendo "o modelo RWKV (versão 4)", contribuído anos atrás, com RWKV/rwkv-4-169m-pile como exemplo e um vocabulário padrão de 50.277 tokens. Não há páginas para RWKV-5, RWKV-6 ou RWKV-7. Três gerações de arquitetura foram lançadas desde que o suporte a RWKV da biblioteca foi escrito, e nenhuma delas está nele.

Os números de download mostram o que o ecossistema fez a respeito: ele contornou a biblioteca. Ordenados por downloads nos últimos 30 dias, os principais repositórios RWKV-7 são os lançamentos .pth brutos de BlinkDL (rwkv7-g1 com 8.288 e rwkv-7-world com 4.489) e uma espessa camada de quantizações GGUF da comunidade do G1 de 13,3B — vários uploaders separados, cada um movendo de mil a três mil downloads por mês. Os espelhos oficiais no formato transformers ficam duas ordens de magnitude abaixo dos pesos brutos. O espelho flash-linear-attention do G1 de 2,9B alcança 1.843 downloads.

Esse padrão tem uma explicação simples. O llama.cpp incorporou suporte ao RWKV v7 em 17 de março de 2025 — um kernel GGML_OP_RWKV_WKV7 com backends CPU, CUDA, SYCL, Vulkan e Metal — cerca de um dia depois de o artigo ter sido publicado. Se você quisesse executar o RWKV-7 na sua própria máquina, o caminho rápido era o GGUF, e tem sido assim há dezesseis meses. O caminho que não existia era aquele que todo script de fine-tuning, todo adaptador PEFT, todo harness de avaliação e todo wrapper interno de serving assume: AutoModelForCausalLM.from_pretrained, sem flags.

O que RWKV-7 (Goose) realmente é

RWKV-7 é uma rede neural recorrente, não um transformer com um kernel de atenção mais barato, e a nomenclatura confunde as pessoas constantemente. Ela carrega um estado de tamanho fixo adiante pela sequência, em vez de um cache crescente de chaves e valores passados. Concretamente, em comparação com um modelo de atenção padrão:

• Memória à medida que o contexto cresce — o cache KV de um transformer cresce linearmente com o número de tokens em processamento; RWKV-7 mantém um estado cujo tamanho é definido pela arquitetura, não pela conversa. Esse é todo o argumento de eficiência.

• Custo por token — a atenção custa mais por token à medida que o contexto se alonga; o custo de inferência por token do RWKV-7 é constante, e é por isso que ele continua aparecendo em propostas de edge e de streaming sempre ativo.

• Formato de treinamento — ao contrário de um RNN clássico, a recorrência é paralelizável ao longo de um chunk, de modo que o pré-treinamento não degenera em um processo sequencial lento. É isso que o caminho de prefill paralelo por chunk do PR implementa.

• Teto de contexto — não há cache para estourar, então o projeto oferece contexto efetivamente ilimitado. O que um estado fixo não pode fazer é manter detalhes ilimitados, o que é uma limitação real e não uma nota de rodapé.

A alegação arquitetural do artigo, publicado em 18 de março de 2025 por Bo Peng, Yu Zhang, Songlin Yang e Ruichong Zhang sob o Projeto RWKV na LF AI & Data Foundation, é uma regra delta generalizada com gating vetorial, taxas de aprendizado em contexto e uma regra relaxada de substituição de valores, além de um MLP simplificado (a matriz de gating removida, a dimensão oculta alargada para compensar). O resultado teórico associado a ela é a metade mais provocadora: o RWKV-7 consegue realizar rastreamento de estado e reconhecer todas as linguagens regulares enquanto permanece paralelizável no treinamento, o que os autores argumentam superar o que os transformers conseguem fazer sob conjecturas de complexidade padrão.

Tudo é Apache 2.0. A família disponível para download inclui 0.1B (12 camadas, largura 768), 0.4B (24 / 1024), 1.5B (24 / 2048), 2.9B (32 / 2560), 7.2B (32 / 4096) e 13.3B (61 camadas, largura 4096), todos com vocabulário World de 65.536 tokens e tamanho de head 64. A série World base foi treinada em um corpus multilíngue de 3,1 trilhões de tokens; a série G1 "GooseOne" continua esse treinamento no World v3.5, uma mistura expandida de 5,16 trilhões de tokens com mais romances, texto da web, matemática, código e dados de raciocínio. Os checkpoints G1 adicionam um modo de raciocínio com a tag think, chamada de funções JSON e fill-in-the-middle a partir do G1c. A nomenclatura é realmente estranha: G0 significa menos de uma época, G1 significa mais de uma, e as letras de sufixo marcam revisões de dados, com letras posteriores trazendo dados melhores.

Os números, e de quem são os números

Aqui está o estado honesto das evidências. A afirmação principal do benchmark — de que o modelo de 2.9B estabeleceu um novo estado da arte de 3B em tarefas multilíngues e igualou o estado da arte de 3B em inglês com dramaticamente menos tokens de treinamento — é do próprio artigo, publicado em março de 2025 e avaliado contra os modelos de 3B daquele período. Passou pelo OpenReview, que é uma análise mais rigorosa do que um post de blog de fornecedor recebe, e ainda é um resultado autorrelatado em um conjunto de comparação com quinze meses.

A outra medição pública do projeto, UncheatableEval, é mais interessante do que uma linha de leaderboard e recebe quase nenhuma cobertura. Em vez de pontuar benchmarks de múltipla escolha que vazam para os conjuntos de treinamento, ela mede a taxa de compressão em dados que não existiam quando o modelo foi treinado: novos artigos do arXiv, repositórios recentes do GitHub, notícias recentes. Esse design torna a contaminação muito mais difícil, e a RWKV relata ser competitiva com transformers do mesmo tamanho nessa métrica. Ainda assim, é uma avaliação que o projeto executa sobre si mesmo.

O que não existe, até onde conseguimos apurar, é uma pontuação independente de índice de terceiros para qualquer checkpoint do RWKV-7 — nenhum agregador neutro submeteu o 7.2B ou o 13.3B ao harness que aplica em modelos de fronteira. Portanto, comparações que você possa ver com modelos como DeepSeek V4 Flash ou Qwen3.8-Max são erros de categoria duplamente: ninguém executou o RWKV-7 na mesma avaliação, e um RNN denso de 13.3B não está competindo pelo mesmo trabalho que um sistema de fronteira. A afirmação defensável é mais restrita e mais útil: de 1.5B a 13.3B, com memória constante, em cerca de doze idiomas, com pesos permissivos.

Executando RWKV-7 hoje, e o que isso custa para você

A página do Hub para RWKV/RWKV7-Goose-World3-1.5B-HF é um bom retrato do atrito atual. É um modelo BF16 de 1,52B de parâmetros com o tokenizer RWKV World, Apache 2.0, marcado como custom_code, listando inglês, chinês, japonês, coreano, francês, árabe, espanhol e português. As instruções dizem para instalar flash-linear-attention e uma versão recente do transformers antes de carregar. E na barra lateral, onde um modelo hospedado mostraria provedores, está escrito claramente: este modelo não é implantado por nenhum Inference Provider.

Então suas opções hoje são todas de autoatendimento:

• flash-linear-attention mais trust_remote_code — o mais próximo do uso normal do Hub, mas você está executando código do repositório e carregando kernels do Triton, o que limita você em hardware e em qualquer coisa com revisão de segurança.

• GGUF via llama.cpp — o caminho mais bem suportado na prática, inclusive para a 13.3B, e o que os números de downloads mostram que as pessoas realmente usam. Ótimo para inferência local, não é um caminho para treinamento ou fine-tuning.

• O runtime próprio do projeto — o pacote pip rwkv e o repositório de referência, o mais próximo do canônico, o mais distante das ferramentas que sua equipe já possui.

{{1}}Nenhuma dessas é uma API que você possa chamar, e vale a pena ser direto sobre a implicação:{{/1}} {{2}}RWKV-7 não está no OrcaRouter, porque não é um endpoint hospedado em nenhum lugar que possamos encontrar.{{/2}} {{3}}Se você quer RWKV-7, você roda o RWKV-7.{{/3}} {{4}}O que podemos dizer honestamente é onde isso deixa o restante da stack.{{/4}} {{5}}Avaliar uma arquitetura não comprovada só é barato se o seu caminho de produção não depender do resultado, e a maneira mais barata de manter isso verdadeiro é não ter uma integração por fornecedor para mais nada — uma chave compatível com OpenAI para mais de 200 modelos, preço de tabela do provedor repassado diretamente com margem de 0%, e failover automático quando um provedor degrada.{{/5}} {{6}}Então, um experimento com RWKV-7 auto-hospedado nas duas cargas de trabalho onde a memória constante realmente compensa — um stream de longa duração, um assistente no dispositivo, um sumarizador que nunca para — é um experimento, não uma migração.{{/6}} {{7}}Essa é a forma que a maioria dos times deveria querer aqui: um default roteado, e um modelo baseado em estado conquistando seu espaço em uma tarefa específica.{{/7}}

O que ainda poderia impedir este pouso?

Leve o precedente a sério: uma proposta para adicionar exatamente esta arquitetura já foi recusada uma vez, por motivos que o autor reconhece serem válidos. A nova é melhor fundamentada e melhor testada, e continua sendo um PR da comunidade contra um repositório que é deliberadamente conservador em admitir arquiteturas que terá que manter para sempre.

As perguntas específicas em aberto que gostaríamos de ver respondidas antes de considerar isso concluído:

• Revisão, não CI — as suítes automatizadas estão verdes; dois mantenedores foram consultados e nenhum aprovou. Transformers exige uma revisão de aprovação, e os testes lentos não foram executados.

• A velocidade do caminho sem dependências — PyTorch puro com decodificação sequencial de token único é portátil, e portátil é exatamente o ponto, mas o PR não publica throughput contra os kernels Triton em flash-linear-attention. Se a decodificação nativa for significativamente mais lenta, a biblioteca se torna o caminho de compatibilidade enquanto o serving sério permanece em outro lugar.

• Quais checkpoints chegam — as conversões em conformidade com a convenção cobrem de 0,1B a 7,2B. O G1 de 13,3B, que é o que as pessoas realmente querem, não está nesse conjunto, e o exemplo documentado é um modelo Pile com um tokenizador GPT-NeoX, em vez de um modelo de chat com vocabulário World. Um carregador mesclado sem um checkpoint carro-chefe por trás muda menos do que parece.

• O alvo móvel — o projeto não está parado. O repositório G1 da BlinkDL foi atualizado na mesma semana em que este PR foi aberto, as quantizações da comunidade avançaram para revisões de dados posteriores ao G1c, e o RWKV-8 "Heron" foi pré-visualizado publicamente com um mecanismo de autômato de sufixos chamado ROSA. Heron não foi lançado nem submetido a benchmarks; nós o mencionamos apenas porque uma integração de biblioteca que chega tarde na vida de uma geração tem uma vida útil curta.

Quatro perguntas que a ficha técnica não responde

Posso usar RWKV-7 no Transformers agora, ou não?

Ambos, irritantemente, e a distinção é toda a história. Você pode carregar um checkpoint do RWKV-7 pela API do transformers hoje, se você instalar o flash-linear-attention e passar trust_remote_code, para que o arquivo de modelagem do próprio repositório seja executado. O que você não pode fazer é carregá-lo da própria biblioteca, que é o que o faz funcionar por padrão nas ferramentas construídas sobre a biblioteca — scripts de treinamento e alinhamento, adaptadores, estruturas de avaliação, caminhos de exportação — e o que o torna compatível com uma política que proíbe código remoto. É para isso que serve o #47780.

Fazer merge torna o modelo melhor?

Não por um único ponto em nenhum benchmark. Isso muda a distribuição, não a qualidade — e, para uma arquitetura cujo problema nunca foi a qualidade, a distribuição é a restrição limitante. A comparação é a que está no topo deste artigo: um modelo de 169M de 2023 com quarenta vezes mais downloads do que os pesos da geração atual, inteiramente por poder ser carregado sem flags.

Se não houver cache KV, obtenho contexto ilimitado de graça?

Você obtém comprimento de contexto ilimitado sem o aumento de memória, o que não é o mesmo que recuperação ilimitada. Um estado de tamanho fixo tem capacidade de informação fixa; alimente-o com um milhão de tokens e ele não consegue conter um milhão de tokens de detalhes recuperáveis. Atenção com cache completo consegue, a um custo que cresce o tempo todo. Trate a história de contexto longo do RWKV-7 como "transmite para sempre a baixo custo, comprime conforme avança" e teste a recuperação específica que você precisa, em vez de confiar na palavra infinito.

Vale a pena se importar com 13.3B quando os modelos de fronteira têm centenas de bilhões?

Depende inteiramente de se memória constante tem algum valor para você. Se você está chamando uma API hospedada e pagando por token, quase certamente não — os modelos de fronteira estão muito à frente em capacidade e você não está pagando diretamente pelo cache KV. Se você está implantando inferência em hardware que você não controla, ou executando um fluxo persistente onde um cache crescente é o que eventualmente mata o processo, uma arquitetura cuja pegada de memória não muda é um tipo diferente de resposta para uma pergunta diferente. Essas são as cargas de trabalho onde um RWKV-7 de 2.9B tem sido silenciosamente competitivo, e são aquelas onde um carregador nativo seria mais importante.

O que assistiríamos a seguir

Quatro sinais concretos, em ordem aproximada de quanto mudariam nossa leitura. Uma resenha aprovadora de ArthurZucker ou Rocketknight1, que transformaria isto de um diff promissor em um recurso planejado. Uma conversão compatível com a convenção do G1 de 13,3B com o tokenizer World, que é o que torna o carregador digno de existir. Números de throughput publicados para o caminho de decodificação sem dependências em relação aos kernels Triton, o que decide se o suporte nativo é uma opção de servir ou um shim de compatibilidade. E qualquer sinal do RWKV-8, que indicaria se esta integração chega no início de uma geração ou no fim de uma.

Até pelo menos o primeiro desses, o resumo correto é o pouco glamoroso: RWKV-7 (Goose) é real, com licença permissiva, baixável até 13.3B, e ainda não carregável nativamente na biblioteca sobre a qual a maior parte do ecossistema é construída. Um pull request aberto em 4 de agosto de 2026 propõe corrigir isso. Ele não foi mesclado, e pull requests para adicionar arquiteturas ao transformers realmente são fechados.