SillyTavern性能优化:如何降低启动编译与接口延迟

SillyTavern性能优化:如何降低启动编译与接口延迟【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavernSillyTavern 性能优化要先明确延迟从哪来:这是一个单进程 Node.js 服务,主要延迟源有三处——前端 bundle 的冷启动编译、角色卡数据的重复解析、以及 LLM 后端调用的连接建立开销。本文基于仓库源码梳理对应的内置机制与配置项,并说明如何定位实际瓶颈。启动链路与请求中间件链:延迟在哪里服务器启动时按序执行:用户存储初始化、数据迁移、preSetupTasks,其中包含一次强制的 webpack 编译(runWebpackCompiler),编译完成前/lib.js不可用,页面自然要等。也就是说,冷启动时间里有相当一部分是前端库编译而非业务逻辑。请求侧的固定开销在 src/server-main.js(服务主入口)中可见:helmet、compression、response-time、bodyParser(上限 500MB)、cookie-session、CSRF 同步令牌,之后才进入静态资源与 API 路由。每个接口都要穿过这条链,大体积请求(如聊天存档)还会完整走一遍 JSON 解析。指标当前量级 / 行为前端 bundle 冷编译数秒到数十秒,取决于硬件;版本变更触发一次全量重编角色列表接口(大卡库、缓存未命中)秒级,随卡数量增长单请求服务端处理时间响应头X-Response-Time可直接读出静态资源(CSS/图片)原始文件 浏览器 ETag 再验证,未配置长 maxAgeSillyTavern 性能优化:服务端分发的静态背景资源示例前端构建缓存与静态资源分发Webpack 持久化编译缓存webpack.config.js(前端构建配置)把lib.js的编译产物与缓存都落在磁盘上,缓存目录以应用版本、git 修订号与 webpack 版本的哈希命名,并会自动清理过期缓存目录:cache: { type: filesystem, cacheDirectory: cacheDirectory, // DATA_ROOT/_webpack/hash/cache store: pack, compression: gzip, },含义是:版本变更后第一次启动做全量重编,之后每次重启都走温缓存,启动等待时间通常可缩短到秒级(视硬件而定)。排查为什么这次启动特别慢时,先确认是否恰好跨了版本或 webpack 升级。响应压缩与静态文件策略app.use(compression())对所有响应启用 gzip,静态文件经express.static分发,依赖默认 ETag/Last-Modified 再验证。另外注意mode: production已内置 minify,再手动叠加一轮 Terser 属于重复劳动。Cache-busting 中间件src/middleware/cacheBuster.js(浏览器缓存清除中间件)默认关闭,开启后会对匹配 User-Agent 的访问首请求下发Clear-Site-Data。它是排查页面用了旧资源的开关,方向上会增加首屏加载时间,不要把它当作加速手段。角色卡数据加载:懒加载与两级缓存角色数据以 JSON 数据块形式嵌在 PNG 里,每次解析都要读文件、拆 PNG 块、反序列化。src/endpoints/characters.js(角色卡解析与缓存读写)中的readCharacterData按内存缓存 → 磁盘缓存 → 实际解析的顺序取数据:内存层是 src/util.js(公共工具,MemoryLimitedMap 实现)中的MemoryLimitedMap,默认容量 100MB,超限按插入顺序淘汰;磁盘层基于 node-persist,存于_cache/characters,键含文件 mtime,文件改动后自动失效,每 5 分钟同步一次。角色列表的默认行为是逐卡返回完整数据,卡库上千家时,首次打开列表的接口耗时主要来自这里的串行解析。lazyLoadCharacters 浅数据模式开启后列表接口只返回展示所需字段(名称、头像、标签子集等,见toShallow),完整解析推迟到实际打开聊天时。这是大卡库场景下最直接的收益点,官方注释也提示可能与部分扩展存在兼容问题。缓存容量与磁盘缓存配置三项开关集中在 default/config.yaml(默认配置,performance 段):performance: lazyLoadCharacters: false memoryCacheCapacity: 100mb useDiskCache: truememoryCacheCapacity设为0可禁用内存缓存(Android 平台会自动跳过内存缓存);useDiskCache关闭后重启即需重新全量解析。与带宽相关的另一处机制是缩略图:头像与背景展示走预生成的小图(jpg、质量 95,背景 160x90、头像 96x144),而不是直接传输 1920x1080 原图。SillyTavern 性能优化:背景原图与缩略图机制对应的资源外部 LLM 后端连接复用全局 Agent 的 keep-alive服务端对 Ollama、KoboldAI 等后端的每次调用默认走http/https.globalAgent。src/server-main.js(全局 Agent 设置)在启动时按配置注入:http.globalAgent new http.Agent({ keepAlive: cliArgs.enableKeepAlive }); https.globalAgent new https.Agent({ keepAlive: cliArgs.enableKeepAlive });配置项enableKeepAlive默认 false。开启后同目标后端的请求复用 TCP/TLS 连接,省去每次握手与连接排队;若启用了请求代理,src/request-proxy.js(代理 Agent 初始化)会把同一开关传给 ProxyAgent。大请求体压缩客户端到服务端的大载荷(聊天存档、设置保存)默认不压缩。performance.requestCompression控制方向相反的压缩,即请求体 gzip,带 256KB 触发阈值与 8MB 上限:performance: requestCompression: enabled: false minPayloadSize: 256kb maxPayloadSize: 8mb弱网或跨机房部署时,该项对保存设置/导出聊天这类大请求的耗时改善通常比较明显;本机部署收益有限。瓶颈定位与优化效果验证内置观察点每个响应的X-Response-Time头(response-time 中间件):服务端处理耗时的最小观测单位;数据目录下的access.log(仅listen监听模式写入):连接级分析;启动日志中的 webpack 编译耗时(stats 配置了timings: true):区分冷编译与温缓存。推荐测量流程与预期区间建议按固定条件复现:同一数据目录、同一硬件、冷启动前清掉_cache与 webpack 缓存目录。流程为:冷启动计时 → 重启计时(温缓存)→ DevTools 瀑布图核对静态资源 → 对比enableKeepAlive前后同一接口(如/api/characters)的X-Response-Time。预期量级(非承诺值,视环境而定):冷编译 → 温编译:通常从数十秒降到数秒,约 50%~80% 的启动等待缩短;大卡库(数百卡以上)列表接口:开启懒加载 缓存后,首次之后重复打开通常有 50%~80% 改善;keep-alive:跨机部署改善可见,前后端同机时差异较小。SillyTavern 性能优化:接口响应时间观察示例场景常见误区在构建配置上继续叠压缩mode: production已包含 minify,构建环节的瓶颈是编译耗时,靠持久化缓存消化即可。往 webpack.config.js 里手工添加 drop_console、额外插件,收益趋近于零且增加维护成本。把 cacheBuster 当加速开关如前所述,它强制浏览器清缓存,方向与加速相反,仅在排查旧资源问题时临时启用。把所有延迟都归因于前端X-Response-Time只覆盖服务端处理时间。对话接口的主体耗时通常在 LLM 后端的推理环节,SillyTavern 侧优化只能削减连接、解析与传输开销,后端慢时前端无解。以上机制针对单实例、小团队规模部署;多用户高并发场景需另行评估反向代理层的静态资源缓存与 HTTP/2 支持。更多配置项可查 default/config.yaml 的 performance 段与 src/middleware/(全部请求侧中间件)。【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考