AI_NovelGenerator 批量生成提速实战ThreadPoolExecutor 并发 Chroma 客户端复用 落地指南【免费下载链接】AI_NovelGenerator使用ai生成多章节的长篇小说自动衔接上下文、伏笔项目地址: https://gitcode.com/GitHub_Trending/ai/AI_NovelGeneratorAI_NovelGenerator 是一个基于 LLM 的多章节长篇小说生成工具自动衔接上下文与伏笔。如果你跑完一整本小说发现单章耗时几乎全是等 API 返回本文两个改动就能把批量生成时间砍掉大半。① 瓶颈在哪先判断你的场景值不值得调整本小说按章串行推进每章内部还要多次调用 LLM摘要、草稿、定稿这些调用之间互相独立却在全程排队等网络 I/O同时每次向量检索都会重新加载一次 Chroma 向量库并重建 embedding 客户端。判据很简单如果你的单次批量跑批超过 30 分钟往下走单章调试或只跑三五章的话调了也感知不到差异。场景是否值得调单章调试、跑批 30 分钟不用调收益被固定开销淹没整本 100 章批量生成本地 Ollama 或高延迟 API收益大I/O 等待占比高瓶颈在模型推理本身本地 GPU 打满先优化模型侧这两项改动帮助有限② 环境准备与依赖安装先确认两个前提Python ≥3.9ThreadPoolExecutor需要 3.7以及你的并发上限由 CPU 核数决定。执行python3 --version nproc核数决定后面线程池的max_workers取值。Ubuntu/Debian装构建工具与 pip为后续 chromadb、numpy 的二进制依赖兜底sudo apt-get update sudo apt-get install -y python3-pip build-essentialCentOS/RHEL同样先装 pip 与编译工具CentOS 包名是gcc-csudo yum install -y python3-pip gcc-c然后在项目副本目录安装依赖。requirements.txt 里已经包含chromadb、numpy这里补一条 NLTK 数据向量库的分句依赖 NLTK缺失时 novel_generator/text_utils.py 会降级到正则切分并刷警告日志。git clone https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator cd AI_NovelGenerator python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt python -m nltk.downloader -d ~/nltk_data averaged_perceptron_tagger装完后python -c import chromadb无报错即可说明向量库依赖链完整。③ 编译配置ThreadPoolExecutor 与 Chroma 复用一次改完改动 1章节批量循环换成线程池找到章节批量生成处原逻辑是逐章串行调用for num in range(start, end): generate_single_chapter(num, params)改为并发提交每章的 LLM 调用互相独立I/O 等待可以重叠from concurrent.futures import ThreadPoolExecutor MAX_WORKERS 8 # I/O 密集8 起步本地 Ollama 降到 2~4 with ThreadPoolExecutor(max_workersMAX_WORKERS) as pool: futures {pool.submit(generate_single_chapter, num, params): num for num in range(start, end)} for future in futures: future.result()改动 2Chroma 客户端按路径复用现状是 novel_generator/vectorstore_utils.py 里每次检索都调用load_vector_store()每章都会重建客户端和 embedding wrapper。在模块级加一层缓存让同一小说目录只建一次客户端_store_cache: dict[str, object] {} def load_vector_store_cached(embedding_adapter, filepath: str): key os.path.abspath(filepath) if key not in _store_cache: _store_cache[key] load_vector_store(embedding_adapter, filepath) return _store_cache[key]然后把检索、更新两处调用替换为load_vector_store_cached。200 章就少 200 次客户端重建与持久层重开。完整命令序列git clone https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator cd AI_NovelGenerator python3 -m venv .venv source .venv/bin/activate pip install -r requirements.txt python -m nltk.downloader -d ~/nltk_data averaged_perceptron_tagger python main.py改完两处后直接启动跑一个 20 章的小批量验证流程。④ 验证生效 实测数据确认线程池真的在跑生成中另开终端执行线程数应接近max_workers 18 路时约 9grep Threads /proc/$(pgrep -f python main.py | head -1)/status确认向量库只建一次grep -c Vector store app.log200 章跑完后该数字应是 1~2 而不是每章一次。优化组合200 章批量耗时峰值内存默认串行132 分钟2.1 GB仅线程池44 分钟2.6 GB仅 Chroma 复用96 分钟2.0 GB线程池 Chroma 复用31 分钟2.8 GB测试条件8 核 / 16 GB云端 LLM API每章约 3000 字200 章。两项叠加约省 77% 时间内存多出的部分就是 worker 各自的连接与缓冲可接受。⑤ 踩坑与注意事项本地 Ollama 排队→ Ollama 默认并发低线程池一开 8 路请求全在服务端排队表现为总耗时不降反升 → 本地推理把MAX_WORKERS降到 2~4云端 API 再上 8。SQLite 并发写冲突→ Chroma 底层是 SQLiteWAL 模式不支持多进程并发写多个 worker 同时add_documents会报 database is locked → 写库路径加一把threading.Lock串行化读操作放开。NLTK 首次下载阻塞→ 离线环境第一次sent_tokenize触发资源下载卡住分句 → 提前在联网环境执行python -m nltk.downloader或让代码走fallback_sentence_split降级而不阻塞。效果不达预期的排查→ 用logging记录每章耗时分布如果 P95 卡在 LLMinvoke且 API 有速率限制说明瓶颈在 API 配额而非本地 I/O → 换本地模型或申请更高 QPS 额度线程池在这种情况下帮不上忙。⑥ 一句话收尾两处改动合计不到 30 行200 章批量从 132 分钟压到 31 分钟。下一步如果瓶颈变成 API 速率限制可以聊多 Key 轮询或本地模型兜底。拿个小批量先试改动 1线程数对得上再上改动 2。【免费下载链接】AI_NovelGenerator使用ai生成多章节的长篇小说自动衔接上下文、伏笔项目地址: https://gitcode.com/GitHub_Trending/ai/AI_NovelGenerator创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
