RWKV写小说：RNN架构如何用低显存解放长文本生成

简介：面向小说作者与平台运营者的 AI 写作辅助资源，基于类似 GPT-2 的 RWKV 中文预训练生成模型，可生成玄幻、言情等类型网文，并融合在线富文本编辑理念，帮助作者激发灵感、提升效率、管理创作内容。压缩包共 218 个文件，约 200.65MB，以 189 个模型权重 bin 文件为主体，另有 Python 脚本、JSON 配置、HTML 展示页面、bat 启动脚本及说明文档，兼顾模型部署、参数调整与简单界面运行。资源已包含可直接启用的服务启动脚本与关键模型权重，能够快速搭建 AI 写作环境，也适合作为 RWKV 在中文文学生成场景下的二次开发参考——作者可基于权重继续微调，运营者可用于内容质量与版权管理。当前已有 33 人学习下载，适合对中文预训练模型落地创作工具的开发者和小说创作者。

1. RWKV 写小说：用 RNN 骨架把中文网文生成从显存焦虑里解放出来

AI 写小说这事儿，真正卡住人的往往不是模型不会说话，而是怎么用一张消费级显卡把玄幻、言情那种动辄几千字的长文连贯生成出来。我对比过 GPT-2 中文版和几个常见的中文预训练生成模型后，最后把方案停在 RWKV 上：它采用类似 GPT-2 的自回归预训练范式，却用 RNN 的线性内存把长文本生成从显存焦虑里解放出来，正好匹配网文这种“上下文连续但模式固定”的文本。

这篇笔记按实际落地顺序展开：先讲为什么选 RWKV 而不是继续堆 Transformer 的 KV Cache，再给出一套从解压发布包、跑通推理、调参数到微调数据的最小可复现路径。适合手里有小说语料、想让模型出章节草稿的创作者，也适合在本地部署 AI 写作、被显存逼到换方案的开发者。只是先试效果的话，我一般建议从 1.5B 这种小档位跑起，等提示词和参数稳定了再上更大的权重，这样整个链路一个下午就能调通。

2. 为什么是 RWKV：RNN 骨架 + 类似 GPT-2 的预训练范式，把长文生成成本打下来

2.1 网文生成先卡在 Transformer 的上下文和显存上

聊 RWKV 之前，先回到 GPT-2 打开的那条路。GPT-2 是典型的 decoder-only Transformer，预训练目标就是给你前 N 个 token、预测第 N+1 个 token；今天大多数中文预训练生成模型都沿用这套自回归范式。推理的时候，模型要把已生成的 token 不断喂进注意力层，每一步的 KV Cache 都会随序列长度线性膨胀。生成几百字试玩片段感受不到，但写玄幻开篇动辄 2000 字，再挂上 2048 的上下文窗口，一张 8G 显存的卡很快就到上限。

更麻烦的是网文生成不是算一次就完事。每生成一个 token，前面的 KV Cache 都要保留，生成 1 万个 token 就是 1 万次累积。有人用窗口截断来缓解，但窗口一短，前文的情节、人物、法器设定就丢得干净，模型转头开始乱编。这就是为什么市面上很多 AI 小说试玩只能出几百字的“开头杀”，一写长就翻车。这也是我从 Transformer 系模型迁到 RWKV 的最直接动机：结构上就不吃这碗饭。

2.2 RWKV 的 token shift 与 WKV：用一条循环状态换掉整条 KV Cache

RWKV 的解法是把架构换成 RNN，但训练方式保留了 GPT-2 那套“预测下一个 token”的自回归预训练。这意味着它仍然是一个标准的预训练生成模型，可以用常见语言模型工具链加载和微调，只是推理时不再需要保留完整 KV Cache。

它有两个关键机制需要理解。第一是 token shift：每个 token 在进入时间混合层之前，会按比例混合上一时间步的隐藏状态与当前输入，这相当于用极低成本给循环结构注入短期上下文，让模型知道“上一步说到哪了”。第二是 WKV 注意力：它把 RNN 的隐状态组织成一组可衰减的键值，每个位置对历史位置的贡献由时间距离和衰减系数共同决定，推理时只需维护一条状态向量，复杂度是 O(1)，而不是 Transformer 的 O(n)。

用大白话讲，RWKV 把“记住前文”这件事从“保存所有历史快照”改成了“压缩成一条状态”，长文本生成时显存占用基本固定。这个特性正中网文的下怀：网文不是古诗，不需要精确回溯三千字前的某个词，但需要一个结构稳定、能持续带前情的生成机制。

2.3 玄幻和言情为什么吃这套套路化生成

玄幻网文的卖点是“升级感”：境界、功法、副本、金手指，都是高度模板化的元素；言情网文的核心则是人物关系和情绪节奏：误会、拉扯、救赎，翻来覆去就那么几条弧线。模板化程度越高，自回归模型越容易学。RWKV 的记忆虽然不如 Transformer 的精确注意力，但它擅长抓住最近若干步的局部线索，对网文来说，读者真正在乎的是上一章埋的伏笔能在两三章内回收，而不是三千字前某个标点。

我在实践中体会最深的是：用 RWKV 写玄幻时，只要提示词里明确列出当前境界和下一阶段的“升级目标”，它很少跑偏；言情则需要把双方关系的当前状态写清楚，冷战还是暧昧，生成出来的对话才不串味。所以 RWKV 不是“什么都能写”的万能模型，而是“套路化长文本”这个场景下的高性价比模型。

2.4 中文预训练生成模型里的部署性价比

市面上中文预训练生成模型不少，但 RWKV 对部署者友好。它单卡能跑的中文权重档位多，从零点几 B 到十几 B 都有；同样在 3B 档位，推理显存压力比同参数量 Transformer 小得多，CPU 也能出字。这意味着 AI 写作类的模型部署不用一上来就配 A100，一张中端卡甚至纯 CPU 机器都可以先跑起来。

选型时还要考虑团队熟悉度。如果团队只写过 PyTorch 和 transformers，RWKV 的接入成本比想象中的低：AutoModelForCausalLM 直接认架构，LoRA 也能挂，只是 tokenizer 有些特殊（后面避坑章细说）。如果你已经有一套 GPT-2 的生成代码，换到 RWKV 时真正要改的就两处：加载的权重路径和 tokenizer 初始化，生成循环本身几乎不用动。

3. 跑通第一篇：RWKV fo.zip 解压、最小推理命令与 6 个必调参数

3.1 先跑通再谈调优：从解压发布包到第一次生成出文字

拿到“RWKV fo.zip”这类发布包，先别急着改代码。解压后看一遍目录，常见结构是权重文件、tokenizer 配置、推理脚本和 README 四件套，有的包还会附上微调示例，用来验证发布包是否完整。我一般先用命令行把最小流程跑通，再谈 prompt 和参数，不然很容易陷入“模型加载失败还是我写错了”的排查里。

# 解压并快速确认目录结构，unzip 没有的话用 Python zipfile 也行 unzip rwkv-fo.zip -d ./rwkv-fo cd ./rwkv-fo # 确认 torch 版本和 CUDA 是否可用，不同发布包对 torch 版本很敏感 python -c "import torch; print(torch.__version__, torch.cuda.is_available())" # 常见发布包会带 chat 类脚本，最小调用大致长这样 python chat.py \ --model ./weights/rwkv-4-3b.pth \ --prompt "第一章 少年从悬崖下醒来，周身的灵力正在消散" \ --max-tokens 512

这段命令的逻辑不复杂，重点是路径和 prompt。--model 指向解压出的权重文件，有的发布包用 .pth，有的用 safetensors，以 README 为准；--prompt 是开篇首句，直接影响整章走向；--max-tokens 先给 512，跑通后可以加到 1024 或更高。最容易出问题的是 Python 版本和 torch 版本，如果发布包没锁版本，建议先建一个 Python 3.10 的 conda 环境，能少踩不少坑。

如果你后面想接 peft 做微调，建议直接用 transformers 加载同一份权重，验证它能被标准工具链识别：

from transformers import AutoModelForCausalLM import torch model_dir = "./rwkv-fo/weights-hf" model = AutoModelForCausalLM.from_pretrained( model_dir, torch_dtype=torch.float16, device_map="auto" ) print(model.config.architectures)

这段代码背后的逻辑是：transformers 已经内置 RWKV 架构，AutoModelForCausalLM 能根据 config 识别并加载权重。这里最需要注意的不是架构，而是 tokenizer：RWKV 用的是 trie 分词器，不能像 BERT 那样靠 from_pretrained 自动恢复，后面避坑章节会专门展开。参数说明里，torch_dtype=torch.float16 是为了匹配发布包常见的半精度权重，避免 fp32 和 fp16 混用把数值搞坏；device_map="auto" 会让模型自动分布到可用设备上，比如单卡放 GPU、超出显存的部分自动 offload 到 CPU。

3.2 提示词模板：给玄幻和言情分别打好设定、金手指、冲突三根桩

跑通流程之后，决定生成质量的就不再是“模型强不强”，而是“提示词有没有把该说的信息说完”。我给玄幻和言情各用一套模板，核心都是把“谁、在哪、想要什么、阻碍是什么”写清楚。这个思路和 AI 编程提示词是一个道理：越具体的上下文，输出越可控。

fantasy_prompt = """这是一个东方玄幻世界，境界分为练气、筑基、金丹、元婴。 主角周凡在宗门大比中被打落悬崖，却意外融合上古神兽血脉。 请在下面的开头后继续写正文，要求每段有明确行动和升级铺垫，不要跳境界： 周凡从碎石中抬起头，掌心凝出一缕金色灵光。""" romance_prompt = """现代都市言情。女主沈微是投行分析师，男主陆沉是落魄画家。 两人五年前因误会分手，此刻在拍卖会重逢。请写重逢后第一次正式对话， 用对话和动作表达“还在意对方但都不肯低头”。 沈微站在青花瓷瓶前，听见身后有人叫她的名字。""" # 把上面任意一个字符串传给推理脚本的 --prompt 即可

这套模板的要点是：玄幻里明确给“境界顺序、金手指、开篇动作”三根桩，模型就不会把金丹写成筑基，也不会让主角突然无敌；言情里明确给“人物身份、关系状态、本场事件”三根桩，感情戏才不会冷不丁变成告白现场。实际跑的时候可以把“要求”也放进 prompt，比如“每段结尾留钩子”“禁止提前升级”，模型大多能遵守。

3.3 玄幻和言情都适用的 6 个生成参数

参数决定观感，这里直接给一个我常用的参考表：

这些参数是互相配合的，不是单独调某一个。temperature 高会带来意外转折，但网文需要稳定，玄幻我会开在 0.9，言情压在 0.8；top_k 和 top_p 双截断是为了防止发散；repetition_penalty 是网文场景最值得动的一个参数，调太低模型会复读“他冷冷地看着”，调太高句子会像竹简一样生硬。建议先固定 top_k=40，再小幅动 top_p，最后才是 temperature。context_window 在 RWKV 上是免费的，2048 只是起点，显存够的话开 4096 试试，长文连贯性会明显更好。

4. 微调出自己的文风：从网文语料清洗到 LoRA 训练

4.1 数据准备：把 txt 小说切成干净、稳定、有结尾标签的样本

通用模型生成的内容永远是“平均水平”。想让模型写出你偏好的世界观、节奏或口吻，就得微调。第一步永远是数据清洗，这一步决定微调的天花板。常见做法是把一批同风格小说转成纯文本，然后去掉阅读类 App 的章节广告、压缩连续换行、统一章节标记，最后再切成长度接近的样本。

import re def clean_text(text: str) -> str: # 去掉网址、乱码符号和阅读器噪声 text = re.sub(r"https?://\S+", "", text) text = re.sub(r"[【】《》【本章未完，请继续阅读】]", "", text) # 把各种章节标题统一成 \n\n 开头，方便模型学到“段落边界” text = re.sub(r"第[0-9一二三四五六七八九十百千]+章.*", "\n\n", text) text = re.sub(r"\n{3,}", "\n\n", text) return text.strip() def split_samples(text: str, block_size: int = 512): paragraphs = [p for p in text.split("\n") if p.strip()] samples, cur = [], "" for p in paragraphs: cur += p + "\n" if len(cur) >= block_size * 4: # 按字符粗估，约 2048 字一块 samples.append(cur.strip()) cur = "" if cur.strip(): samples.append(cur.strip()) return samples

逻辑说明：切样本时不要硬按固定长度切，否则一句话被腰斩，模型学到的都是断裂文本。我按“约 2048 字一块”粗切，再交给 tokenizer 截断到 512 token，段落边界是完整的。清洗时把“本章未完”这类阅读器噪声全部删掉，否则模型会学会在章节末尾生成这些平台话术。

4.2 LoRA 微调：单卡也能把 3B 模型调成你的风格

微调方式首选 LoRA。全参微调 3B 模型需要至少 24G 显存，而 LoRA 只训练一小部分注入参数，12G 甚至 8G 卡都能跑，这是 AI 模型部署场景里最稳妥的低成本路线。

from transformers import AutoModelForCausalLM, TrainingArguments from peft import LoraConfig, get_peft_model import torch model = AutoModelForCausalLM.from_pretrained( "./rwkv-fo/weights-hf", torch_dtype=torch.float16, device_map="auto" ) # 关键一步：先打印模型结构，再决定 LoRA 挂到哪 # for name, _ in model.named_modules(): # print(name) lora_cfg = LoraConfig( r=16, lora_alpha=32, lora_dropout=0.05, target_modules=["key", "value"], # 以实际打印出的 Linear 层名为准 bias="none", task_type="CAUSAL_LM", ) model = get_peft_model(model, lora_cfg) print(model.print_trainable_parameters())

逻辑说明：RWKV 在 transformers 里的层名和原生 RNN 脚本不一定一样，网上抄的 target_modules 很可能匹配不到任何模块。我一般先打印模型结构，再挑 attention 里处理 key/value 投影的 Linear 层挂 LoRA；如果你打印出来看到的是 “receptance”“output” 这类名字，就把 target_modules 改成对应那一个。参数说明：r=16 是常用档位，改动幅度已经够微调一层文风；lora_alpha=32 时实际缩放为 alpha/r=2，数值稳定性好；bias="none" 是不让 LoRA 动偏置参数，省显存。

训练数据从 4.1 的 samples 直接构造 Dataset，tokenizer 用发布包自带实现，别接 AutoTokenizer：

from datasets import Dataset dataset = Dataset.from_dict({"text": samples}) dataset = dataset.map( lambda x: tokenizer(x["text"], truncation=True, max_length=512), remove_columns=["text"] )

训练参数我一般这样定：

training_args = TrainingArguments( output_dir="./lora-rwkv-novel", per_device_train_batch_size=2, gradient_accumulation_steps=8, num_train_epochs=1, learning_rate=2e-4, save_steps=500, logging_steps=50, fp16=True, )

参数说明：seq len 512、batch size 2、梯度累积 8，等效 batch 16，1 个 epoch 足以让模型习惯你的文风；学习率 2e-4 是 LoRA 常见起点，5e-4 以上容易把原有中文表达能力冲掉。训练时长以 3B 模型单卡为例，大概几小时到半天，具体看数据量。

4.3 合并导出：把微调结果塞回 RWKV 发布包的目录结构

LoRA 训练完，peft 保存出来的是一个很小的适配器目录，这个目录不能直接丢给原生 chat 脚本。所以需要把 LoRA 权重合并回基础模型，再导出。

from peft import PeftModel from transformers import AutoModelForCausalLM import torch base_model = AutoModelForCausalLM.from_pretrained( "./rwkv-fo/weights-hf", torch_dtype=torch.float16 ) merged = PeftModel.from_pretrained( base_model, "./lora-rwkv-novel/checkpoint-500" ).merge_and_unload() merged.save_pretrained("./weights-merged")

逻辑说明：merge_and_unload() 会把 LoRA 增量写进主权重并卸载适配器结构，之后保存的模型就是一份独立权重。参数说明：checkpoint 编号按你训练日志里的实际保存点改；save_pretrained 输出的是 transformers 目录格式，和原生 RWKV 发布包的 .pth 可能不一致，常见做法是再用发布包自带的转换脚本转一次，或者直接把 transformers 格式目录作为新的分发包，推理端能认就行。

5. 写小说部署避坑指南：Tokenizer、复读和停不下来三类高频问题

这一章不是概念说明，是直接把我在部署 RWKV 写小说时反复踩的坑摆出来。每一节按“现象、原因、解决”三段写，对照你自己的报错和生成日志来排查。

5.1 AutoTokenizer 加载失败：RWKV 的 trie 分词器不吃标准配置

现象：用 transformers 的 AutoTokenizer.from_pretrained(model_dir)，直接抛 ValueError，提示找不到 tokenizer_class 或 vocab_file；随后整个加载流程中断，连模型权重都没法读。

原因：RWKV 用的是 trie 结构分词器，发布包一般只带词表文件或原生 tokenizer 实现，没有标准 tokenizer_config.json。transformers 的自动加载机制只能识别预设格式，没法凭空猜出 trie 的构建方式。这不是模型坏，是接口不认。

解决：别绕开，直接用发布包自带的 tokenizer 加载函数。如果那套代码耦合在 chat 脚本里，就把它独立成模块：读入词表文件，构建 trie，暴露 encode 和 decode 两个方法。非要接 transformers 微调时，把 tokenizer 实例通过 save_pretrained 导出成 transformers 能读的目录，一次性成本大概半小时到一小时。我一般会在项目里留一个 tz_rwkv.py，之后所有脚本都从里面拿 tokenizer。

5.2 复读机问题：一个句子反复出现，不是单参数能救的

现象：生成到 100~200 token 后开始循环输出同一句话，例如“他冷冷地看着他”，后续所有内容都在重复这个片段，文本进入死循环。

原因：repetition_penalty 单独调可能不够。网文场景里高频词本来多，模型要同时满足 top_k 的候选范围和温度约束，如果 top_k 开太大、temperature 太低，模型容易选择概率最高的老路，复读就成了局部最优解。

解决：把 repetition_penalty 提到 1.3 以上，同时 top_k 降到 40、temperature 提到 0.8 以上，三个参数一起改。如果已经生成了一堆重复文本，先截短 prompt 清掉上下文里的“历史垃圾”，因为 RWKV 是循环记忆结构，会被自己的输出带偏，直接重生成比调参快。

5.3 生成“停不下来”：长篇变口水文，结尾全靠截断

现象：模型写到 max_new_tokens 还在继续，输出像流水账；即使达到上限，文本也没有收束感，像是被硬砍断了章节。

原因：网文语料大量是连载体，模型学到的是“永远有下一段”，而推理端的停止策略通常只认 max_new_tokens，不认语义边界。本质上是训练数据和推理目标错位。

解决：两条路同时走。推理时在 prompt 里写明“写到这里结束本章，输出【本章完】”，生成后按【本章完】截断；更根本的办法是微调时在每章样本末尾加统一结束符，例如【本章完】，让模型把“收尾”当成生成目标的一部分。这两个办法加一起，章节结尾基本能自然收住。

5.4 fp16 半精度加载乱码：输出里冒出生僻字和替换符

现象：权重加载没报错，但生成几轮后出现夹杂“�”和叠字的乱码，越往后越严重，甚至整段变成无效文本。

原因：RWKV 权重多为 fp16 存储，可推理脚本没有统一精度。fp32 加载或 device_map 混放会让部分数值溢出；另一个常见原因是 logits 用 fp16 采样，概率分布被精度拉平。

解决：加载时固定 torch_dtype=torch.float16，在生成循环里把 logits 显式转成 fp32 再做 argmax 或采样。这两处都改过后，我基本没再见到乱码。检查方法是在前 50 个 token 阶段打印一次 repr，乱码会在早期就露出苗头。

5.5 CPU 推理慢到没法用：量化和小档位是唯一正解

现象：模型能跑，但生成速度只有每秒几个 token，生成一章要等二十分钟，完全没法形成工作流。

原因：RWKV 在 CPU 上推理不是不行，但权重尺寸和 tokenizer 开销摆在那，纯 fp32 更慢。很多人以为“模型小就快”，其实 tokenizer 和重复惩罚也在消耗时间。

解决：优先开发布包自带的 int8 量化选项；没有量化支持就把权重档位降到 1.5B 级。只要提示词结构不变，小档位生成玄幻、言情时风格差异不大，速度却快得多。CPU 跑不是不能接受，但一定要关掉 fp32 默认值。

这些坑我基本都在不同项目里踩过，特别是 trie tokenizer 和章节收束这两条，属于“不翻开发布包源码就永远猜不到”的典型。最后建议把整个生成链路当成一个可回归的 AI 测试开发任务：每次改权重或参数，固定同一个开篇 prompt 跑一遍，输出 diff 就能看出改动方向，这是排查隐性问题最省力的方法。

6. 进阶玩法：大纲先行 + 多 AI 协作，保证长篇不跑偏

单轮生成能写五百字，但小说需要的是五十章。真正让 RWKV 从“能写”变成“能写完一个故事”的做法，是先让它生成章节大纲，再按大纲逐段填充正文，最后用一个独立的检查环节保证前后一致。

我这里用一个小框架说明思路：

def generate_chapters(plot, generator): chapters = [] summaries = [] for i, outline in enumerate(plot["chapters"]): # 每次只带最近 3 章的摘要，避免上下文被历史正文塞满 context = "\n".join(summaries[-3:]) prompt = f"{plot['setting']}\n本章大纲：{outline}\n前情摘要：\n{context}\n正文：" chapter = generator.generate(prompt, max_tokens=1024) chapters.append(chapter) # 让另一个模型把正文压缩成一句摘要存入 summaries summaries.append(generator.summarize(chapter)) return chapters

这个写法的好处是：大纲稳定了故事走向，摘要控制了上下文长度，每章内部由 RWKV 自由发挥。我一般会让一个模型专门跑大纲，另一个模型跑正文，第三个做一致性检查，这种多 AI 协作的架构比单模型一个 prompt 写到尾稳定得多。

一致性检查可以很轻量：把前文摘要和刚生成的章节一起丢回模型，问它“这段里面谁做了什么事，和上一章有没有冲突”，把回答里的矛盾点抽出来人工处理。你也可以用一个固定的规则脚本检查法器名、人名是否变化，纯规则也能拦住一半跑偏问题。

我现在每次开工，都会先花十几分钟把“人物状态表和章节走向图”写进一个大纲文件，再让模型照着生成，草稿返工率能降一半。这个习惯是从几十万字的试错里攒出来的，希望帮到你。

本文还有配套的精品资源，点击获取