PENG Bo 2025-08-27 14:31 广东
本文旨在说明，实际上，RNN真正适合的是大bsz。
💡Tips转自知乎用户 PENG Bo，原文链接：
一种常见误解是：RNN的速度&显存优势只在长ctx才明显，但纯RNN又难以精确记忆长ctx，因此RNN似乎意义不明？
本文旨在说明，实际上，RNN真正适合的是大bsz。
我们考虑典型的L40-D5120的13B模型。不妨令权重和kv/state都是8bit，方便说明。
首先，LLM的解码是memory-bound，速度几乎完全由存储读取量决定：
存储读取量 = 模型参数量 + KV cache（对于RNN是state）
模型参数量是固定的，所有13B模型都是13B。
那么，各种架构在各种bsz+ctx组合下的存储读取量，如图：
在bsz=1时，面对MLA这种省显存attention，纯RNN需ctx很长才有优势，但此时纯RNN的长文本性能堪忧，的确意义不明。
而且此时RWKV-7这种headsz=64的设计，和Mamba2这类靠headsz=256补性能的设计，也没有区别。
但随着bsz升高，事情就变得有趣了。在现实硬件和现实场景（ctx=10k），同样参数量，RWKV-7和7s的总生成速度（throughput）会是典型MLA（例如DeepSeek）的5-10倍，会是典型GQA（例如Qwen3）的15-30倍。
这时state越小越好，于是RWKV-7的小state优势得以体现。目前社区已逐渐发现RWKV-7在大bsz的throughput极强，一张卡可以serve特别多用户。
同理，在RWKV-7s混合模型的DEA中（见 RWKV-8 系列之 DeepEmbedAttention：精简 KV 缓存，尤其适合混合模型（RWKV-7s）），我设计了尽可能小的KV cache，是MLA的九分之一。
因此，RWKV-7和RWKV-7s对于大bsz云端部署非常适合。
但我认为，未来的端侧也有大bsz，因为多agent并行工作的总效率高太多，可以并行做各种任务，并行处理各种数据，并行扮演不同角色，并行使用不同state，等等。
而且，大bsz还适合大test-time scaling，适合各种并行解码方法。由于RNN的state大小固定，也很容易做dynamic batching。
所以，端侧RNN的正确用法是开bsz=1000扫荡（这是现实的，此时RWKV-7 13B即使在fp16的权重+state也只占52G显存，解码算术强度约400，适合单H100；若bsz=100则算术强度约90），使用1000个worker，动态拆解任务，动态合并结果，就像在博弈树同时展开1000个节点，同时做1000个rollout。
举例，怎么一键生成多文件的大型代码项目？快速拆成多个大模块，并行将所有大模块同时拆成多个小模块，并行给多个小模块同时写多个函数，再并行开一堆worker搜索和阅读资料，检查和修正代码等等。这比现在的所谓扩散LLM更快更合理。后续如何让模型自行学会各种拆解和合并，会是值得研究的课题。
