RWKV-7 (Goose)：深入解析最终将其加载到 Transformers 的 Pull Request

上个月在 Hugging Face 上被下载次数最多的 RWKV 模型并不是 RWKV-7 (Goose)——这个自 2025 年 3 月以来项目一直发布的架构——也不是 RWKV7-G1，即在其之上训练的推理系列。它是 RWKV/rwkv-4-169m-pile：一个来自 2023 年 5 月的 1.69 亿参数 RWKV-4 检查点，在截至 2026 年 8 月 5 日的 30 天内有 8,824 次下载，而 1.5B 的 RWKV-7 Goose World-3 版本只有 215 次，2.9B 版本只有 316 次。2023 年的模型并不更好。它只需一个普通的 from_pretrained 调用即可加载，无需安装其他任何东西。

2026年8月4日，一位名为Hakureirm的贡献者针对huggingface/transformers仓库提交了拉取请求#47780，标题为"Add RWKV-7 (Goose)"。截至8月5日，该请求仍处于开启状态，未获评审，也未合并。这是第二次尝试——此前的提案#46984已被否决。目前尚无任何代码合入，因此本文不应被当作发布公告来读。但diff是公开的，它解决的正是横亘在历史最悠久的免注意力LLM谱系与大多数团队实际使用的技术栈之间最无趣却最重要的一件事：一个加载器。

以下内容区分三类主张，因为关于RWKV的报道通常会把它们混为一谈。第一类是可以在Pull Request和Hub上得到验证的内容，你可以自行核查。第二类是RWKV项目在其自身的评估中，关于自家模型所报告的内容。第三类则是大量尚未有人公开回答的问题，而大多数有趣的风险正集中在此。

拉取请求中到底有什么？

2026年8月5日从 PR 页面和 GitHub API 读取的基本事实：

• 范围——三次提交，12 个文件更改，新增 4,423 行，删除 0 行，从分支 add-rwkv7-upstream 合并到 huggingface:main。标注为“新模型”。无指派人员，无里程碑。

• 新增内容以两个公共类（Rwkv7Model 和 Rwkv7ForCausalLM）的形式提供 RWKV-7，并附带一个基于该库 LinearAttentionLayer 构建的 Rwkv7Cache。WKV 状态的 dtype 可独立于模型 dtype 进行配置，这一点很重要，因为循环状态正是此类模型中数值漂移累积之处。

• 运行方式——可移植的 PyTorch，无第三方运行时依赖。预填充采用循环的分块并行形式；解码沿顺序的单 token 路径运行。参数名称遵循上游 RWKV 参考实现，而非为了看起来像 transformer 而重命名。

• 测试姿态——除了标准模型 mixin 之外，还有一个与 BlinkDL 自身运行时逐 token 匹配的集成测试，以及一个与建模文件不共享任何代码的 NumPy 参考实现。该仓库的 CI 汇总机器人报告最新一次运行为成功：16 个作业，179,151 个测试，零失败，16 小时 9 分钟的计算时长。

• 现状 —— 已向 ArthurZucker 和 Rocketknight1 请求评审；页面说明合并至少需要一名批准评审，但两人都尚未给出。GitHub 的 API 在我们读取时仍将合并状态描述为“unstable”，面向维护者的机器人也要求在合并前运行慢速测试套件（auto 和 rwkv7）。换句话说：快速 CI 已通过，但尚未获得人工认可。

描述中最有趣的部分是其中的让步。此前的尝试 #46984 被拒绝，因为已发布的 RWKV-7 检查点不符合 Transformers 的约定，而作者自己的表述是"那个反对意见是正确的"。PR 中阐述的问题是，Hub 上的 RWKV-7 权重以两种该库无法使用的形态存在：

• PTH 仓库——原始的 .pth 文件，不包含 safetensors。库实现无法加载它们，而 PyTorch pickle 文件正是大型公司安全审查会拒绝的内容。

• HF 仓库——这些确实随附 model.safetensors，但每个仓库还随附 modeling_rwkv7.py 和 auto_map，因此加载它们需要 trust_remote_code。这意味着将远程代码执行作为推理的前提条件，这也是如此多企业检查清单止步于此的原因。

所以这个 PR 一箭双雕。它添加了一个建模文件，并指向一组全新的转换结果，这些转换直接来自遵循标准布局的规范 BlinkDL .pth 发布版本——仅 safetensors，无 pickle，无远程代码，一个携带 architectures 和 model_type 的正常 config.json——覆盖 0.1B 到 7.2B。最小的 Hakureirm/rwkv7-168m-pile-hf 的全部 399 个张量都已与源 .pth 逐位验证一致，而非抽查。该 checkpoint 是一个 Pile 模型，因此其 tokenizer 是普通的 GPT-NeoX-20B fast tokenizer，而不是 RWKV World 词表——这与库中现有 RWKV 页面也记录 Pile checkpoint 的原因相同。

为什么2023年的检查点比当前架构的下载量更高

Transformers 目前版本为 5.14.1，于 2026 年 7 月 16 日发布。在其文档中搜索 RWKV，只会得到一个模型页面，其中描述的是“RWKV 模型（第 4 版）”，这是多年前贡献的，示例模型为 RWKV/rwkv-4-169m-pile，默认词汇表大小为 50,277 个 token。没有 RWKV-5、RWKV-6 或 RWKV-7 的页面。自该库的 RWKV 支持编写以来，已经推出了三代架构，但它们都没有被包含在内。

下载数据展示了生态系统对此的应对方式：它绕开了这个库。按最近30天的下载量排序，排名靠前的RWKV-7仓库是BlinkDL的原始.pth发布（rwkv7-g1为8,288次，rwkv-7-world为4,489次），以及社区对13.3B G1的大量GGUF量化版本——几个独立上传者各自每月带来一千到三千次下载。官方的transformers格式镜像比原始权重低两个数量级。2.9B G1的flash-linear-attention镜像则有1,843次下载。

这个模式有个简单的解释。llama.cpp 于 2025 年 3 月 17 日合并了对 RWKV v7 的支持——一个带有 CPU、CUDA、SYCL、Vulkan 和 Metal 后端的 GGML_OP_RWKV_WKV7 内核——大约在该论文发布后一天。如果你想在自己机器上运行 RWKV-7，快速路径就是 GGUF，而且已经持续了十六个月。那条不存在的路径，正是每一个微调脚本、每一个 PEFT 适配器、每一个评估框架以及每一个内部服务包装器所默认的路径：AutoModelForCausalLM.from_pretrained，不带任何标志。

RWKV-7（Goose）实际上是什么

RWKV-7 是一种循环神经网络，而非使用更廉价注意力内核的 Transformer，这种命名时常让人困惑。它沿序列携带固定大小的状态，而不是不断增长的过去键值缓存。具体而言，与标准注意力模型相比：

• 记忆随上下文增长——Transformer 的 KV 缓存随处理中的 token 数量线性增长；RWKV-7 则维持一个状态，其大小由架构设定，而非由对话决定。这就是效率论证的全部。

• 每令牌成本 — 随着上下文变长，注意力机制的每令牌成本会增加，而 RWKV-7 的每令牌推理成本恒定不变，这正是它频繁出现在边缘计算和常驻流式方案中的原因。

• 训练形态——与经典 RNN 不同，这种循环可在 chunk 上并行化，因此预训练不会退化为顺序爬行。这正是该 PR 的 chunk 并行预填充路径所实现的功能。

• 上下文上限 — 没有缓存会被耗尽，因此该项目以实际上无上限的上下文为卖点。固定状态无法容纳无限多的细节，这是一个真正的限制，而非无关紧要的脚注。

论文中的架构主张由Bo Peng、Yu Zhang、Songlin Yang和Ruichong Zhang于2025年3月18日发表，隶属于LF AI & Data Foundation下的RWKV项目，其核心是一种带有向量值门控的广义delta规则、上下文学习率以及放宽的值替换规则，外加一个简化后的MLP（移除了门控矩阵，并加宽隐藏维度以作补偿）。与之相伴的理论成果则更具争议性：RWKV-7能够在保持训练可并行化的同时，执行状态追踪并识别所有正则语言——作者认为，在标准复杂度猜想下，这一点超越了Transformer所能达到的能力。

全部采用 Apache 2.0 许可证。你可以下载的模型系列包括：0.1B（12 层，宽度 768）、0.4B（24 / 1024）、1.5B（24 / 2048）、2.9B（32 / 2560）、7.2B（32 / 4096）和 13.3B（61 层，宽度 4096），全部使用 65,536 token 的 World 词表，头大小为 64。基础 World 系列在 3.1 万亿 token 的多语种语料上完成训练；G1“GooseOne”系列则在此基础上继续训练，使用 World v3.5——一个扩展后的 5.16 万亿 token 混合语料，包含更多小说、网页文本、数学、代码和推理数据。G1 检查点新增了 think 标签推理模式、JSON 函数调用，并且从 G1c 起支持填充中间（fill-in-the-middle）。命名确实有些别扭：G0 表示不到一个 epoch，G1 表示超过一个，后缀字母表示数据修订版本，字母越靠后数据越好。

数字，以及这些数字属于谁

以下是证据的真实状况。头条基准声明——2.9B模型在多语言任务上创下了3B规模的新最先进水平，并在训练token数量大幅减少的情况下追平了英语3B规模的最先进水平——是论文作者自己的说法，该论文于2025年3月发表，评估对象是当时的3B模型。该结果经过了OpenReview评审，这比厂商博客文章所受的审查更为严格，但它仍然是针对一套十五个月前的对比集所作的自报结果。

该项目的另一项公开评估指标 UncheatableEval 比排行榜上的一行更有意思，却几乎无人关注。它不是对会泄漏到训练集中的多选题基准进行评分，而是测量模型在训练时尚未存在的数据上的压缩率：新的 arXiv 论文、新鲜的 GitHub 仓库、近期新闻。这种设计大大增加了数据污染的难度，而 RWKV 报告称在此项指标上与同等规模的 Transformer 模型竞争力相当。这仍然是该项目自行开展的一项评估。

据我们所知，并不存在任何 RWKV-7 检查点的独立第三方指数评分——没有中立的聚合机构让 7.2B 或 13.3B 版本跑过它在前沿模型上运行的测试框架。因此，你可能会看到的与 DeepSeek V4 Flash 或 Qwen3.8-Max 等模型的比较，是双重的范畴错误：没有人让 RWKV-7 跑过相同的评测，而且一个 13.3B 的稠密 RNN 并不是在与前沿系统争夺同样的任务。站得住脚的说法更窄，也更有用：1.5B 到 13.3B 规模、恒定内存、约十二种语言、宽松权重。

今日运行RWKV-7，及其代价

RWKV/RWKV7-Goose-World3-1.5B-HF 的 Hub 页面很好地反映了当前的摩擦点。这是一个 1.52B 参数的 BF16 模型，使用 RWKV World 分词器，采用 Apache 2.0 许可证，标记为 custom_code，支持的语言包括英语、中文、日语、韩语、法语、阿拉伯语、西班牙语和葡萄牙语。它的说明要求你在加载之前安装 flash-linear-attention 和较新版本的 transformers。而在侧边栏中，托管模型原本会显示供应商的位置，它却直白地写道：此模型未由任何推理提供商部署。

所以，你今天的选择全都是自助式的：

• flash-linear-attention 加上 trust_remote_code——最接近正常的 Hub 用法，但你正在执行仓库代码并引入 Triton 内核，这会在硬件方面以及任何需要安全审查的场景中限制你。

• GGUF via llama.cpp——实际上是支持最完善的路线，包括对13.3B模型，而且下载数据表明这是人们真正采用的方式。非常适合本地推理，但不是训练或微调的途径。

• 项目自身的运行时——rwkv pip 包和参考仓库，最接近规范实现，也最远离你团队已有的工具链。

那些都不是你可以调用的 API，而且有必要直言不讳地点明其中的含义：RWKV-7 不在 OrcaRouter 上，因为在我们能找到的任何地方，它都不是托管的端点。如果你想用 RWKV-7，你就自己运行 RWKV-7。至于这会让技术栈的其余部分处于什么位置，我们可以坦诚相告。评估一个未经证实的架构，只有在你的生产路径不依赖其结果时，才算是划算的；而让这一点成立的最划算方式，就是不对任何其他模型做逐供应商的集成——一个兼容 OpenAI 的密钥覆盖 200 多个模型，供应商标价以 0% 加价直接透传，当某个供应商服务下滑时自动故障转移。这样一来，在恒定内存确实能带来回报的两个工作负载上——长期运行的流、设备端助手、永不停歇的摘要器——自托管 RWKV-7 的实验只是一场实验，而不是一次迁移。这应该是大多数团队想要的格局：默认走路由，而基于状态的模型则在特定任务上凭实力赢得一席之地。

还有什么仍可能阻止这次着陆？

认真对待这个先例：添加这种确切架构的提案曾被拒绝过一次，拒绝理由连作者也承认是合理的。新提案论证更充分、测试也更完善，但它仍然是一个针对某个仓库的社区PR，而该仓库在接纳架构方面刻意保守，因为一旦接纳就必须永久维护。

在宣布完成之前，我们希望得到解答的具体未决问题：

• 评审，而非 CI——自动化测试套件全部通过；已询问两位维护者，但均未批准。Transformers 需要一次批准的评审，且慢速测试尚未运行。

• 无依赖路径的速度——纯 PyTorch 配合顺序单 token 解码具有可移植性，而可移植性正是全部意义所在，但该 PR 并未发布与 flash-linear-attention 中 Triton 内核对比的吞吐量数据。如果原生解码明显更慢，该库就会沦为兼容性路径，而严肃的推理服务仍会留在别处。

• 哪些检查点会到来——符合规范的转换覆盖 0.1B 到 7.2B。人们真正想要的 13.3B G1 并不在此集合中；文档中的示例也是使用 GPT-NeoX 分词器的 Pile 模型，而非采用 World 词表的聊天模型。一个背后没有旗舰检查点的合并加载器，实际带来的改变比表面看上去要小。

• 移动的目标——项目并非止步不前。BlinkDL 的 G1 仓库在本 PR 开启的同一周内就进行了更新，社区量化已推进到比 G1c 更新的数据修订版，RWKV-8“Heron”也已公开预览，其采用了一种名为 ROSA 的后缀自动机机制。Heron 尚未发布，也未经基准测试；我们提及它，仅仅是因为在一代模型生命周期的后期才实现的库集成，其有效寿命会很短暂。

规格说明书未回答的四个问题

我现在可以在 Transformers 中使用 RWKV-7 吗，还是不行？

烦人的是，两者都是，而区别正是整个故事的关键。如今，你可以通过 transformers API 加载 RWKV-7 检查点，前提是安装 flash-linear-attention 并传入 trust_remote_code，这样仓库自带的建模文件才能运行。你无法做到的是直接从库本身加载它，而正是从库本身加载这一点，使其在基于该库构建的工具中默认就能工作——训练和对齐脚本、适配器、评估框架、导出路径——也使其能够通过禁止远程代码的策略。而这第二件事正是 #47780 要解决的。

合并会让模型变得更好吗？

在任何基准测试上都不是差一分的事。它改变的是分布，而非质量——对于一个架构而言，问题从来不在质量，分布才是真正的制约。这个对比就是本文开头那个：一个2023年的169M模型，下载量以四十比一碾压当前一代权重，完全凭的是无需任何flags即可加载。

如果没有KV缓存，我就能免费获得无限的上下文吗？

你可以获得无限的上下文长度，且不会出现内存激增，但这并不等同于无限的召回能力。固定大小的状态具有固定的信息容量；即便喂给它一百万个 token，它也无法容纳一百万个 token 的可检索细节。带有完整缓存的注意力机制可以做到这一点，只是代价会一路增长。请把 RWKV-7 的长上下文特性理解为“廉价地无限流式处理，边处理边压缩”，并测试你所需的具体检索能力，而不要轻信“无限”这个词。

当前沿模型达到数千亿参数时，13.3B的模型还值得在意吗？

这完全取决于恒定内存对你来说是否有价值。如果你调用托管API并按token付费，那几乎可以肯定不值得——前沿模型在能力上遥遥领先，而你并没有直接为KV缓存付费。如果你要把推理部署到不受自己控制的硬件上，或者运行一个持久流，其中不断增长的缓存最终会拖垮进程，那么一种内存占用保持不变的架构，就是针对不同问题的另一种答案。这些正是2.9B RWKV-7一直悄然具备竞争力的工作负载，也是原生加载器最要紧的场景。

我们接下来会看什么

四个具体信号，按它们会多大程度改变我们判断的粗略顺序排列。来自ArthurZucker或Rocketknight1的认可评审，会把这从一个有希望的补丁变成一项已排期的功能。一个符合规范的13.3B G1与World分词器的转换，这才是加载器值得拥有的原因。针对Triton内核发布无依赖解码路径的吞吐量数据，这决定了原生支持是服务选项还是兼容性垫片。以及任何RWKV-8的迹象，这会告诉你这次集成是在一代的开始还是结束时到来。

至少在头一件事实现之前，正确的总结依然是那个平淡无奇的说法：RWKV-7 (Goose) 是真实存在的，采用宽松许可证，可下载最大 13.3B 参数版本，但仍然无法在支撑了大多数生态系统的那个库中原生加载。2026年8月4日提交的一个 pull request 提议修复这一问题。它尚未被合并，而向 transformers 添加架构的 pull request 确实会被关闭。