SillyTavern 提速指南：5 步改配置，约 30 分钟完成-平芜编程栈

SillyTavern 提速指南：5 步改配置，约 30 分钟完成

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

SillyTavern 是一个常见的 LLM 聊天前端，负责连接各家模型 API 完成角色扮演对话。它的性能问题大多不用改源码：绝大多数"慢"来自 config.yaml 里的几个开关，按下面 5 步做完，首屏等待和消息往返通常能降到明显舒服的范围，力气花销在 30 分钟内；具体提升多少取决于你的部署环境。

先自检：你卡在哪一类

动手前先勾这 5 条，勾中的项决定你要做哪几步：

角色库大时，角色列表要几秒到几十秒才出来 → 角色卡加载问题，做第 1、2 步
页面加载很快，但发消息后很久才有回复 → 模型端问题，先做第 3 步（可能什么都不用改）
同一套服务，远程访问明显比本地慢 → 网络与传输问题，做第 4 步
图多、库大，滚动和加载吃力 → 图片与缩略图问题，做第 5 步
只有第一次慢、第二次就快了 → 这是缓存正常工作，不用改

如果只能勾一条，先勾第一条。大库首屏慢是最常见、也最容易验证的一类。

按优先级做这几步

第 1 步：打开角色卡懒加载

为什么排第一：打开角色库时，SillyTavern 默认会把全部角色卡一次性解析完，卡越多首屏越久，这是"慢"反馈里占比最高的一类。官方专门提供了开关，不需要动代码。

怎么改：把数据目录下 config.yaml 里performance.lazyLoadCharacters从 false 改为 true，然后重启服务。

什么时候做 / 不做：几百张卡的库，效果明显；只有十几张卡就不用动。官方注释里写明它可能与部分扩展有兼容问题，开了之后若某个扩展行为异常，先关回去排查扩展，别在配置上死磕。

什么算对：大库的角色列表、进入第一个角色，能在 2~3 秒内出现。

第 2 步：缓存两项保持默认，内存有余量再调

performance.useDiskCache默认就是 true（解析结果落盘缓存），不要关它。performance.memoryCacheCapacity默认 100mb，是已解析角色卡占用的内存上限。

# 你的 config.yaml（数据目录下） performance: memoryCacheCapacity: '256mb' # 默认 100mb，服务器内存有 8GB 以上余量时可调大 useDiskCache: true # 保持默认，勿关

什么时候做 / 不做：库大且服务器内存宽裕才需要调大；内存紧张就保持默认，别为了"看起来更快"把容量拉到内存极限。

什么算对：同一个角色的第二次进入，比第一次明显更快。

第 3 步：回复慢，先确认慢在模型而不是 SillyTavern

这步可能什么都不改，但它能帮你少走弯路：一条消息的生成时间绝大部分花在模型推理上，SillyTavern 侧没有任何配置能让模型推得更快。判断方法：

服务端响应带 X-Response-Time 响应头（src/server-main.js里通过 response-time 中间件挂上）。这个值只有几百毫秒以内、而体验上"慢"，时间就是花在模型生成上。
服务端的访问日志（logging.enableAccessLog默认开启）记录了每次请求的耗时，可以和上面的头对照。
后端是本地 Ollama 时，第一次请求慢、后面快，是模型加载所致。config.yaml 里ollama.keepAlive默认 -1（常驻内存），保持默认即可；如果你手动把它设成了 0 或很小的秒数，请改回去。

什么时候做 / 不做：后端是商用 API 且网络不稳定时，这步只能帮你确认"不是 SillyTavern 的锅"，解法是换离你更近的节点，不是改配置。

第 4 步：大请求压缩（走网络才开）

保存聊天和配置时上传的是大体积 JSON。performance.requestCompression.enabled默认关闭，开启后对超过 256kb 的请求体做 gzip 压缩，8mb 上限。

# 你的 config.yaml performance: requestCompression: enabled: true # 对大请求体启用压缩 minPayloadSize: '256kb' # 小于此值不压，避免小请求白耗 CPU

什么时候做 / 不做：远程、带宽有限的访问场景值得开；本机或局域网访问别开，带宽本来就不是瓶颈，开了纯耗 CPU。

什么算对：浏览器 Network 面板里，保存类请求的传输体积（size 一栏）比文件体积明显小。

第 5 步：有空再做，图片和缩略图

界面默认展示缩略图而不是原图（thumbnails.enabled开启，头像缩到 96x144）。如果你导入了大量 4K 原图，原图仍然占空间，点开原图时也会慢。两个思路：

导入前把原图压到 1920 宽左右，或者交给内置缩略图流程，别指望"先传大的以后再说"。
thumbnails.format默认 jpg；配置文件的注释里写明换 png 会让文件大约大一倍，quality默认 95，库大时降到 85 视觉上基本无差。注意：这两项只影响新生成的缩略图，旧的要把 thumbnails 目录清空后重新生成。

什么时候跳过：图片不多、本机访问，这步可以整段跳过。

改完怎么验证

别靠"感觉变快了"。用浏览器开发者工具的 Network 面板加服务端 access.log，对照下面四个数：

看什么	怎么看	通过线
角色列表首屏（大库、冷启动）	重启后打开计时	从数十秒降到 2~3 秒内
二次进入的静态资源	Network 面板来源列	大部分资源来自缓存，总耗时低于首次
单请求服务端往返	X-Response-Time 头或访问日志	改前改后对比有明显下降即可，取决于部署环境，别追求绝对值
大体积保存/上传	Network 面板 size 列	开压缩后传输体积通常降到原来的 1/2 到 1/3

做法：改配置前先记一轮这四个数，每做完一步再记一轮。哪一步起了作用一目了然，出了问题也知道回退到哪一步。

这些坑别踩

关磁盘缓存来解决角色卡加载慢：useDiskCache: false意味着每次都要重新读盘解析，比开着更慢。慢就去查第 1、2 步，不是砍缓存。
把模型生成时间当成服务端响应时间：X-Response-Time 很小但回复依旧慢，那是模型在慢慢生成，改 SillyTavern 的配置不会有任何帮助，该调的是模型参数或换更快的模型。
手改构建配置去"压榨"前端：前端已经是生产构建（webpack production 模式、gzip 缓存），自行往里加压缩插件、重写构建链，通常拿不到多少收益，还可能把页面弄坏。默认构建够用，这层不用自己动手。
把 cacheBuster 当性能开关：它是用 Clear-Site-Data 主动清浏览器缓存的，只在 localhost 或 HTTPS 域名下生效，用途是排查缓存坏掉的问题。平时开着它，等于每次访问都强制重新加载，页面会比不开更慢。