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 開啟了 pull request #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。標記為「新模型」。無指派對象，無里程碑。

• 新增內容 — RWKV-7 以兩個公開類別提供：Rwkv7Model 與 Rwkv7ForCausalLM，以及建置於函式庫 LinearAttentionLayer 之上的 Rwkv7Cache。WKV 狀態的 dtype 可獨立於模型 dtype 設定；這點很重要，因為在這一系中，數值漂移會累積在遞迴狀態中。

• 運作方式 — 可移植的 PyTorch，無需任何第三方執行期依賴。預填充階段使用區塊並行的遞迴形式；解碼階段則執行循序的單一 token 路徑。參數名稱沿用上游 RWKV 參考實作，而非重新命名成看似 Transformer 的名稱。

• 測試姿態——除了標準的模型 mixin 之外，還有一個與 BlinkDL 自身的 runtime 逐 token 匹配的整合測試，加上一個與建模檔案不共用任何程式碼的 NumPy 參考實作。該儲存庫的 CI 摘要機器人回報最新一次執行成功：16 個工作、179,151 個測試、零失敗、16 小時 9 分鐘的運算時間。

• 目前狀況 — 已向 ArthurZucker 和 Rocketknight1 請求審查；頁面說明合併需要至少一項批准的審查，但兩者都尚未給出。我們讀取時，GitHub 的 API 仍將合併狀態描述為「不穩定」，且一個面向維護者的機器人已要求在合併前執行慢速測試套件（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 逐位元一致，而非僅抽樣檢查。該檢查點是 Pile 模型，因此其 tokenizer 是普通的 GPT-NeoX-20B 快速 tokenizer，而非 RWKV World 詞彙表——這也正是程式庫現有 RWKV 頁面同樣記載 Pile 檢查點的原因。

為什麼2023年的checkpoint下載量比當前架構更高？

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 保持的狀態大小由架構決定，而非由對話長度決定。這就是效率論證的全部重點。

• 每個 token 的成本當上下文變長時，注意力每個 token 的成本會更高；RWKV-7 每個 token 的推論成本則是恆定的，這就是為什麼它不斷出現在邊緣與常駐串流提案中。

• 訓練形態 — 與經典 RNN 不同，遞歸可在單一 chunk 上並行化，因此預訓練不會退化為循序進行的緩慢過程。這就是該 PR 的 chunk-parallel prefill 路徑所實現的。

• 上下文上限——沒有會爆掉的快取，因此這個專案實際上以無上限的上下文為賣點。固定狀態無法做到的是容納無上限的細節，這是一個實實在在的限制，而非附註。

這篇論文中的架構主張，由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 檢查點從 G1c 開始加入了 think-tag 推理模式、JSON 函式呼叫與 fill-in-the-middle 功能。命名方式確實有點彆扭：G0 代表少於一個 epoch，G1 代表多於一個 epoch，而後綴字母則標示資料修訂版本，越後面的字母代表資料品質越好。

這些數字，以及這些數字屬於誰

這就是證據的真實狀況。那項頭條基準宣稱——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 tokenizer，採用 Apache 2.0 授權，標記為 custom_code，列出的語言有英文、中文、日文、韓文、法文、阿拉伯文、西班牙文和葡萄牙文。其說明要求你在載入之前安裝 flash-linear-attention 和較新版本的 transformers。而且在側邊欄中，原本託管模型會顯示提供者的位置，它清楚地寫著：此模型並未由任何 Inference Provider 部署。

所以你今天可用的選項都是自助式的：

• flash-linear-attention 加上 trust_remote_code — 最接近一般 Hub 的使用方式，但你正在執行儲存庫程式碼並引入 Triton kernels，這會讓你在硬體以及任何需要安全審查的地方受到限制。

• 透過 llama.cpp 的 GGUF —— 實務上支援最完善的做法，包括 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 kernel 相比的吞吐量。若原生解碼顯著較慢，此函式庫就會變成相容性路徑，而正式服務仍會留在別處。

• 哪些檢查點會到位——符合慣例的轉換版本涵蓋 0.1B 到 7.2B。13.3B G1——也就是大家真正想要的那個——並不在這組範圍內，而且文件中的範例是採用 GPT-NeoX tokenizer 的 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 模型，下載量是當前世代權重的四十比一，完全靠的是無需旗標即可載入。

如果沒有 KV 快取，我就能免費獲得無限的上下文嗎？

你獲得無限的上下文長度，不會造成記憶體爆炸，但這並不等於無限的檢索能力。固定大小的狀態具有固定的資訊容量；餵給它一百萬個 token，它無法容納相當於一百萬個 token 的可檢索細節。帶有完整快取的注意力機制可以做到，只是代價會一路增長。把 RWKV-7 的長上下文說法當作「永遠低成本地串流，邊進行邊壓縮」，並測試你需要的具體檢索能力，而不是輕信「無限」這個詞。

當前沿模型有數千億參數時，13.3B的模型還值得關注嗎？

這完全取決於恆定記憶體對你來說是否有價值。如果你呼叫的是託管 API，並按 token 付費，答案幾乎肯定是否定的——前沿模型在能力上遙遙領先，而且你並不會直接為 KV 快取付費。如果你要將推論部署到自己無法掌控的硬體上，或是執行持續性的串流，而日漸增長的快取最終會拖垮整個程序，那麼記憶體佔用不會隨之膨脹的架構，就是針對不同問題所給出的另一種解答。這些正是 2.9B RWKV-7 一直低調地保有競爭力的工作負載，也正是原生載入器最能發揮關鍵作用的地方。

我們接下來會看的

四個具體訊號，依它們對我們判斷的影響程度粗略排序。{{1}}來自ArthurZucker或Rocketknight1的認可審查，這會把它從一個有前景的diff變成已排入時程的功能。{{/1}}{{2}}使用World tokenizer對13.3B G1進行符合慣例的轉換，這正是讓載入器值得擁有的原因。{{/2}}{{3}}針對無依賴解碼路徑與Triton kernels相比的已發布吞吐量數據，這決定了原生支援是伺服選項還是相容性墊片。{{/3}}{{4}}以及任何RWKV-8的跡象，這會告訴你這次整合是出現在世代的開端還是尾聲。{{/4}}

至少在第一項達成之前，正確的總結是樸實無華的那個：RWKV-7 (Goose) 是真實存在的，採用寬鬆授權，可下載高達 13.3B 的版本，但仍然無法在大部分生態系所依賴的函式庫中原生載入。2026 年 8 月 4 日開啟的一個 pull request 提議修正此問題。該請求尚未被合併，而向 transformers 添加架構的 pull request 確實會被關閉。