SillyTavern 性能优化：5 步快速提速清单，让角色卡和聊天变快变轻（附 config.yaml 参数速查）

SillyTavern 性能优化：5 步快速提速清单，让角色卡和聊天变快变轻（附 config.yaml 参数速查）

【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern

如果你用的 SillyTavern 是一个 LLM 前端（AI 角色聊天、角色卡管理、世界观注入的完整对话界面），打开角色列表要转圈、多开标签页内存飙高、发消息等半天——这篇文章帮你把config.yaml里真正管性能的 5 组参数调到位。不用改代码，全程只动配置文件和后台设置。

30 秒自检：你的 SillyTavern 卡在哪一步

先花 30 秒对号入座，后面的步骤可以跳着看：

• 打开角色库/角色卡慢：角色卡超过 100 张时，切换页面、点开角色卡明显卡顿
• 内存越跑越高：挂机聊一小时，浏览器标签页或服务器内存持续上涨
• 发送和加载吃带宽：保存聊天、拉取大角色卡时流量大，弱网下明显
• 后台图片占地方：头像、背景图都是原图大小，列表滚动要重新请求大图
• 改了配置不生效 / 看到的还是旧数据：浏览器缓存和磁盘缓存打架

SillyTavern 酒馆默认背景示例

症状一：角色卡一多就卡 —— 打开懒加载和磁盘缓存

原因一句话：默认配置下，SillyTavern 会把角色卡解析结果常驻内存，卡片库一大，加载列表和切换角色都要反复干活。

具体怎么做：编辑config.yaml（首次启动后在你的 data 目录里，模板在 default/config.yaml），找到performance段：

performance: lazyLoadCharacters: true # 角色卡懒加载，打开角色才加载 memoryCacheCapacity: '100mb' # 解析后卡片的内存缓存上限 useDiskCache: true # 磁盘缓存，重启不用重新解析

• lazyLoadCharacters: true：角色卡改成"用到才加载"，卡片库上千张时列表明显变快。官方注释提示个别扩展可能不兼容，开完先测一遍你常用的扩展。
• memoryCacheCapacity：这是内存的"保险丝"。默认'100mb'，角色卡很大的库可以调到'200mb'；别改成0——那不是省内存，是关掉缓存让每次访问都重新解析。
• useDiskCache: true：解析结果落盘，重启服务后首次打开不再卡。

预期效果：大卡片库（500 张以上）场景下，角色列表打开和角色切换的等待时间能砍掉大半；重启后冷启动变热启动。

症状二：内存持续上涨 —— 给缓存设上限

原因一句话：解析后的角色卡、聊天数据如果不设上限地留在内存里，长时间使用就会越占越多。

具体怎么做：和上面同一段配置。三个开关的分工是：memoryCacheCapacity管"最多留多少"，useDiskCache管"装不下的往盘上挪"，lazyLoadCharacters管"没用的先别读进来"。三者配合，内存曲线会从持续上涨变成有起伏但稳定。

预期效果：多开标签页、长时间挂机，内存占用趋于平稳；配合症状一的操作一起做，收益最明显。

症状三：弱网下保存/拉取数据慢 —— 开启请求压缩

原因一句话：默认app.use(compression())只压缩服务器发给浏览器的响应，而浏览器提交的大请求（聊天备份、角色设置保存）走的是裸 JSON，弱网下往返时间被数据量拖死。

具体怎么做：在performance段下方开启：

requestCompression: enabled: true # 开启请求体 gzip 压缩 minPayloadSize: '256kb' # 小于此体积不压缩 maxPayloadSize: '8mb' # 超过此体积不压缩 timeout: 4000

注意两个阈值别乱改：小于 256KB 的请求压缩收益很小，强行压反而多花时间；超过 8MB 的大体传输，CPU 压缩成本可能不划算。

预期效果：保存聊天备份、导入大角色卡这类大流量操作，上传耗时明显缩短，带宽占用下降；日常小请求完全不受影响。

症状四：头像背景图太大 —— 检查缩略图生成

原因一句话：SillyTavern 自带缩略图机制（src/endpoints/thumbnails.js），列表页展示的是小图，但如果你手动放大过图或者缩略图生成失败，前端就会去拉原图。

具体怎么做：确认config.yaml里thumbnails.enabled: true（默认就是开的），然后看两个关键项：

• format: "jpg"—— 保持 jpg。改成png会保留透明通道，但注释里写得很直白：体积增加约 100%。
• quality: 95—— 头像、背景缩略图在屏幕上的尺寸很小（默认 96x144 / 160x90 级别），质量降到80肉眼几乎看不出差别，体积能再省一截。改完旧缩略图不会自动重建，清掉用户数据里的thumbnails文件夹即可重新生成。

顺便看一眼你放的原图。比如默认素材里的海滩背景原图是 2.2MB 的 PNG，而同一目录里的 jpg 背景普遍只有 300KB 上下——同类图格式差距就是这么悬殊：

SillyTavern 大图背景示例：优化前未压缩的 PNG 原图

预期效果：角色列表、背景切换请求变小，滚动加载不再等大图；磁盘上缩略图占用同步下降。

症状五：改完配置不生效 —— 先分清是浏览器缓存还是磁盘缓存

原因一句话：SillyTavern 有"服务器磁盘缓存"和"浏览器缓存"两层，很多"不生效"是浏览器拿的旧文件，而不是服务器没更新。

具体怎么做：先在浏览器按 Ctrl+Shift+R 强制刷新。只有确认是"文件本身要全量重新下发"（比如批量更新了静态资源）时，才考虑启用cacheBuster（src/middleware/cacheBuster.js）：

cacheBuster: enabled: true # 首次加载时清浏览器缓存 userAgentPattern: 'firefox|safari' # 可限定只清指定浏览器

日常使用请保持enabled: false。这个开关的作用是发出Clear-Site-Data头清空整个浏览器缓存——每次访问都重新下载全部资源，属于"治一次病、长期吃药"的操作，长期开着等于主动制造流量。

预期效果：排掉缓存干扰后，前面四项优化的效果才能被正确感知。

收益最大的 Top3：只做三件事的话先做这些

按投入产出比排序，每个都只需要改config.yaml里的一个值：

1. 确认useDiskCache: true（默认已开）——零成本，重启后冷启动不再重新解析全部卡片，是大卡片库的基础收益。
2. lazyLoadCharacters: true——改动一行，打开列表、切换角色的等待时间下降最明显，是"卡顿感"改善最大的单项。
3. thumbnails.quality降到 80 左右——不改任何开关，只动一个数字，列表流量和磁盘占用同步下降，无兼容风险。

如果内存还是高，再回头调memoryCacheCapacity；弱网环境再开requestCompression。

SillyTavern 赛博风格场景示例：优化后的使用环境

用数据验证：前后对比怎么看

不同机器、卡片库大小差异很大，下面给的是操作维度的对比框架，数字按你自己的环境实测填入：

验证方法：改一项 → 用浏览器 F12 的 Network 面板看请求体积和时间 → 用任务管理器/系统监视看内存，一次只改一项，别混在一起测，否则分不清是谁的功劳。

别踩这几个坑：做了反而更慢的操作

1. memoryCacheCapacity改成0想省内存：这是把缓存整个关掉，每次访问都重新解析，卡和慢同时发生。想省内存请调小上限，不是关缓存。
2. cacheBuster.enabled: true长期挂着：每次首访清空全部浏览器缓存，等于把"缓存"这项免费的提速反复清零。只在需要强制刷新资源时用一次。
3. 缩略图format改png：透明图场景才需要，普通头像/背景改 png 体积直接翻倍，纯亏。
4. requestCompression的minPayloadSize设0：连几十字节的请求都压缩，CPU 白干活，弱网下小请求反而更慢。
5. 把所有扩展都开着测性能：扩展脚本是前端卡顿的常见来源。排障时先关扩展再开性能参数，顺序反了会把账记错地方。
6. 把回复慢全算到 SillyTavern 头上：ST 是前端，模型回复速度主要由你的后端（本地推理或 API）决定。前端优化解决"打开慢、占资源"，"生成一字等三秒"要去查模型侧——上下文长度、并发、显卡这些都是另一个话题。

收尾：今天就能做的两件事

打开config.yaml，把lazyLoadCharacters改成true、把thumbnails.quality改成80，重启一次服务——这两步覆盖了本文最大的两块收益。之后每次怀疑"又变慢了"，按 30 秒自检那份清单对号入座，再用 F12 网络面板看一眼请求，基本都能定位到是哪一层的问题。性能调优不是调一次就完事，卡片库和聊天记录在涨，参数偶尔也要跟着复查。

【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern