SillyTavern 网络性能优化指南5 步配置让聊天界面从卡顿到秒开【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern凌晨一点和 AI 角色聊到关键情节界面却卡住不刷新等了三秒才蹦出一句回复——你的 SillyTavern 是不是也这样SillyTavern 是 LLM 角色的聊天前端慢的根源往往不在模型而在本地这一侧。本文按 5 个阶段把配置逐项打开读完你可以把首屏加载压到 1 秒内、接口响应降七成全程不改一行代码。 先花 2 分钟记录 4 项基线数据优化前先记账不然改完你根本说不清快了多少。下面 4 个数字用你手边的浏览器就能量指标测量方法当前值示例角色列表首屏时间角色数量约 100 张时从点击到列表可滚动3.2 秒单个接口响应耗时响应头里的 X-Response-Time 字段38 ms一张背景图传输体积开发者工具 Network 面板的传输大小620 KB一次会话的 TCP 连接数开发者工具 Network 面板里同一会话的连接 ID 数12 个服务端内置了 response-time 中间件每个响应都会自动带上耗时字段直接 curl 就能看# 服务端已内置 response-time 中间件响应头自带耗时 curl -sI http://127.0.0.1:8000/ | grep -i x-response-time卡顿的 4 个真实来源逐个对号入座对照你的安装下面每一类都能在代码里找到出处。角色卡每次启动都重新解析原理一句角色卡是内嵌 JSON 数据的 PNG 文件服务器每次启动都要把整本卡库读出来再解析一遍就像每开一次店都把全部库存清点一遍。项目里 characters.js 已经内置了解析结果落盘的磁盘缓存但如果你改过配置或缓存被清掉就会退回到每次现算。1920x1080 原图直接发给浏览器原理一句聊天列表里只显示小缩略图你却把 300~700 KB 的原图整个下载了相当于看菜单照片时把整桌菜都端上来。项目自带的 thumbnails.js 会生成 160x90 的小图并缓存到磁盘默认开启但格式和画质参数值得你过一眼。转发模型请求时每条连接都重新握手原理一句SillyTavern 把每次对话转发给模型 API 时默认每次都要新建 TCP 连接像每发一句话都重新拨一次电话。config.yaml 里enableKeepAlive默认是 false这就是开关所在。首次启动要现场编译前端原理一句前端入口 public/lib.js 在启动时被 webpack 打包成单文件首次运行相当于现场做一锅面之后吃预制菜。启动脚本 start.sh 会先装依赖再拉起服务打包完成的日志会先于SillyTavern is listening出现。 5 个阶段完成优化每步 3 分钟阶段 1打开 config.yaml 的 performance 四件套原理解析结果和大体积请求不该每次都走慢路。编辑数据目录旁的 config.yaml改成下面这样# 角色库超过 50 张时重点调这一段 performance: lazyLoadCharacters: true # 列表先上屏卡片数据按需解析 useDiskCache: true # 解析结果落盘重启不必重算 memoryCacheCapacity: 100mb # 内存缓存上限按机器内存调 requestCompression: enabled: true # 聊天存档等大请求走 gzip thumbnails: format: jpg # 缩略图用 jpg比 png 小约一半 quality: 95重启服务后数据目录会出现_cache/characters文件夹。预期变化第二次打开角色列表明显变快首屏从 3 秒级掉到 1 秒级。阶段 2一条开关让连接保活原理连接复用后后续请求省掉握手时间。在 config.yaml 顶层加一行enableKeepAlive: true然后重启。预期变化连续发送多轮对话时Network 面板里重复出现的连接 ID 数量减半以上。阶段 3别删 Webpack 缓存目录原理缓存版本号和你的版本号绑定版本不变时二次启动直接读缓存省掉整个编译过程。操作只有一条纪律——不要手动删数据目录下的_webpack文件夹。预期变化同一版本的第二次启动从等编译变成 2~3 秒直接就绪升级后首启会多等一轮编译属于正常现象。阶段 4缩略图再压一档原理头像网格一张图只需几十 KB。如果内存紧张或卡库极大把阶段 1 里的quality从 95 降到 80 即可肉眼几乎无差别。预期变化角色列表滚动时的总传输量再降一截。注意格式改动只对新生成的缩略图生效想让旧图也变小清掉用户数据里的 thumbnails 文件夹让它重建。阶段 5本地模型常驻内存原理模型从磁盘加载进显存需要几秒卸载后下次调用又要重来。如果你接的是 Ollamaconfig.yaml 里ollama.keepAlive: -1表示模型常驻保持默认不要改成 0改成 0 会即答即走每句话都多付一次加载时间。⚡ 验证4 项指标逐项对比改完重启用阶段 1 之前的同一套方法重新测量指标优化前优化后提升角色列表首屏时间3.2 秒0.9 秒72%单个接口响应耗时38 ms12 ms68%背景图传输体积620 KB48 KB92%一次会话 TCP 连接数12 个1 个92%示例数据以实际环境为准。核对口径前后两次都在角色数量约 100 张、同一浏览器、同一网络下测只改配置不改环境。进阶两个可选开关 一条复查纪律老浏览器缓存清不干净config.yaml 里cacheBuster.enabled: true会在首次加载时让浏览器自清缓存注意它要求 localhost 或 HTTPS 环境才生效。升级后突然变慢别慌webpack 缓存键含版本号升级后首启必付一次编译成本第二次启动就恢复。长期维护只需一条纪律每月重跑一次开头的 curl 命令把 X-Response-Time 记在一个小表格里服务端默认把访问记录写入数据目录的 access.loglogging.enableAccessLog: true发现某类请求耗时持续上涨时顺着它定位是哪个后端在拖后腿。把收益记下来角色列表首屏 3.2 秒 → 0.9 秒快 72%单接口响应 38 ms → 12 ms降 68%背景图传输 620 KB → 48 KB省 92%全程只改 config.yaml 四五行零代码改动配置已经就位的话现在就重启一次服务量一量你的第一组数据。【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
SillyTavern 网络性能优化指南：5 步配置让聊天界面从卡顿到秒开
SillyTavern 网络性能优化指南5 步配置让聊天界面从卡顿到秒开【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern凌晨一点和 AI 角色聊到关键情节界面却卡住不刷新等了三秒才蹦出一句回复——你的 SillyTavern 是不是也这样SillyTavern 是 LLM 角色的聊天前端慢的根源往往不在模型而在本地这一侧。本文按 5 个阶段把配置逐项打开读完你可以把首屏加载压到 1 秒内、接口响应降七成全程不改一行代码。 先花 2 分钟记录 4 项基线数据优化前先记账不然改完你根本说不清快了多少。下面 4 个数字用你手边的浏览器就能量指标测量方法当前值示例角色列表首屏时间角色数量约 100 张时从点击到列表可滚动3.2 秒单个接口响应耗时响应头里的 X-Response-Time 字段38 ms一张背景图传输体积开发者工具 Network 面板的传输大小620 KB一次会话的 TCP 连接数开发者工具 Network 面板里同一会话的连接 ID 数12 个服务端内置了 response-time 中间件每个响应都会自动带上耗时字段直接 curl 就能看# 服务端已内置 response-time 中间件响应头自带耗时 curl -sI http://127.0.0.1:8000/ | grep -i x-response-time卡顿的 4 个真实来源逐个对号入座对照你的安装下面每一类都能在代码里找到出处。角色卡每次启动都重新解析原理一句角色卡是内嵌 JSON 数据的 PNG 文件服务器每次启动都要把整本卡库读出来再解析一遍就像每开一次店都把全部库存清点一遍。项目里 characters.js 已经内置了解析结果落盘的磁盘缓存但如果你改过配置或缓存被清掉就会退回到每次现算。1920x1080 原图直接发给浏览器原理一句聊天列表里只显示小缩略图你却把 300~700 KB 的原图整个下载了相当于看菜单照片时把整桌菜都端上来。项目自带的 thumbnails.js 会生成 160x90 的小图并缓存到磁盘默认开启但格式和画质参数值得你过一眼。转发模型请求时每条连接都重新握手原理一句SillyTavern 把每次对话转发给模型 API 时默认每次都要新建 TCP 连接像每发一句话都重新拨一次电话。config.yaml 里enableKeepAlive默认是 false这就是开关所在。首次启动要现场编译前端原理一句前端入口 public/lib.js 在启动时被 webpack 打包成单文件首次运行相当于现场做一锅面之后吃预制菜。启动脚本 start.sh 会先装依赖再拉起服务打包完成的日志会先于SillyTavern is listening出现。 5 个阶段完成优化每步 3 分钟阶段 1打开 config.yaml 的 performance 四件套原理解析结果和大体积请求不该每次都走慢路。编辑数据目录旁的 config.yaml改成下面这样# 角色库超过 50 张时重点调这一段 performance: lazyLoadCharacters: true # 列表先上屏卡片数据按需解析 useDiskCache: true # 解析结果落盘重启不必重算 memoryCacheCapacity: 100mb # 内存缓存上限按机器内存调 requestCompression: enabled: true # 聊天存档等大请求走 gzip thumbnails: format: jpg # 缩略图用 jpg比 png 小约一半 quality: 95重启服务后数据目录会出现_cache/characters文件夹。预期变化第二次打开角色列表明显变快首屏从 3 秒级掉到 1 秒级。阶段 2一条开关让连接保活原理连接复用后后续请求省掉握手时间。在 config.yaml 顶层加一行enableKeepAlive: true然后重启。预期变化连续发送多轮对话时Network 面板里重复出现的连接 ID 数量减半以上。阶段 3别删 Webpack 缓存目录原理缓存版本号和你的版本号绑定版本不变时二次启动直接读缓存省掉整个编译过程。操作只有一条纪律——不要手动删数据目录下的_webpack文件夹。预期变化同一版本的第二次启动从等编译变成 2~3 秒直接就绪升级后首启会多等一轮编译属于正常现象。阶段 4缩略图再压一档原理头像网格一张图只需几十 KB。如果内存紧张或卡库极大把阶段 1 里的quality从 95 降到 80 即可肉眼几乎无差别。预期变化角色列表滚动时的总传输量再降一截。注意格式改动只对新生成的缩略图生效想让旧图也变小清掉用户数据里的 thumbnails 文件夹让它重建。阶段 5本地模型常驻内存原理模型从磁盘加载进显存需要几秒卸载后下次调用又要重来。如果你接的是 Ollamaconfig.yaml 里ollama.keepAlive: -1表示模型常驻保持默认不要改成 0改成 0 会即答即走每句话都多付一次加载时间。⚡ 验证4 项指标逐项对比改完重启用阶段 1 之前的同一套方法重新测量指标优化前优化后提升角色列表首屏时间3.2 秒0.9 秒72%单个接口响应耗时38 ms12 ms68%背景图传输体积620 KB48 KB92%一次会话 TCP 连接数12 个1 个92%示例数据以实际环境为准。核对口径前后两次都在角色数量约 100 张、同一浏览器、同一网络下测只改配置不改环境。进阶两个可选开关 一条复查纪律老浏览器缓存清不干净config.yaml 里cacheBuster.enabled: true会在首次加载时让浏览器自清缓存注意它要求 localhost 或 HTTPS 环境才生效。升级后突然变慢别慌webpack 缓存键含版本号升级后首启必付一次编译成本第二次启动就恢复。长期维护只需一条纪律每月重跑一次开头的 curl 命令把 X-Response-Time 记在一个小表格里服务端默认把访问记录写入数据目录的 access.loglogging.enableAccessLog: true发现某类请求耗时持续上涨时顺着它定位是哪个后端在拖后腿。把收益记下来角色列表首屏 3.2 秒 → 0.9 秒快 72%单接口响应 38 ms → 12 ms降 68%背景图传输 620 KB → 48 KB省 92%全程只改 config.yaml 四五行零代码改动配置已经就位的话现在就重启一次服务量一量你的第一组数据。【免费下载链接】SillyTavernLLM Frontend for Power Users.项目地址: https://gitcode.com/GitHub_Trending/si/SillyTavern创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考