我们和酒馆同台对测，第一个被钉在案板上的是自己

7 月下旬，我们把自家 App 和 SillyTavern（中文圈叫「酒馆」）摆上了同一张实验台。规则定得偏执：同一个模型（deepseek-v4-flash）、同一把 API key、同三张角色卡、每一轮用户消息逐字节相同，两边的全部 AI 调用都从我们自建的同一个计量代理过账， 谁也没法在数字上动手脚。参赛四方：裸装酒馆（出厂配置）、满配酒馆（按社区流行玩法装满预设和插件）、 我们的普通模式、我们的智能演绎模式。每个组合独立跑三遍。

搭这个台子本来是想系统性回答「我们和酒馆到底差在哪」。第一个被钉在案板上的，是我们自己。

被打脸的那个数字

侦察轮用同一张聊斋卡《聂小倩》、同样的 15 轮对话：裸装酒馆的缓存命中率 88.9%，我们 27.7%。

先说这个数字为什么等于钱。DeepSeek 会缓存「和之前请求逐字相同的开头部分」，命中的部分按 $0.0028/百万 token 计费，没命中按 $0.14/百万，命中价是全价的 2%。角色聊天每一轮都要把系统提示、角色卡、全部历史原样重发， 理论上是最吃缓存红利的场景。命中率差成这样，落到账单上就是：全量矩阵里同样的九场 15 轮对话，裸酒馆总共 $0.0241，我们 $0.0664，2.8 倍。

绝对值看着都是几分钱，因为 15 轮很短、v4-flash 很便宜。但倍数不挑场景：会话越长、模型越贵， 这个 2.8 倍就越疼。尤其我们的用户里有一大批自带 key，多花的钱直接走他们自己的账单。

全量矩阵（3 张卡 × 4 方 × 3 遍，36 格）把侦察轮的结论坐实：裸酒馆 91.5%，满配酒馆 74.6%，我们普通模式 46.5%，智能演绎 42.3%。全量轮还按官方最佳实践关掉了酒馆的自动摘要副调用，它的成绩比侦察轮更好看， 这是应该的。

三张卡把病根钉死

46.5% 是个平均数，拆开看更难堪，也更有信息量。同一个安装包、同一条链路，三张卡的命中率分别是 22.6%、27.7%、74.3%。

三张卡唯一的结构差异在世界书。前两张（一张世界观完全自创的深设定卡，加那张《聂小倩》）的词条全部是触发式的， 聊到关键词才注入；第三张现代生活流卡带两条「常驻」词条，每轮固定在场。常驻卡 74.3%，全触发卡 22.6%。 病根不用猜了：触发式词条随剧情进进出出，每次进出都改写提示词开头的字节，而 DeepSeek 的缓存严格从第 0 个 token 开始做前缀匹配，开头变一个字，后面全部按全价算。

最惨的是那张深设定卡：15 轮里有 8 到 10 轮整条提示词从头 miss，一个字的折扣都没拿到。 逐轮命中率像心电图。第 1、2 轮 0%，第 3 轮 91%，第 4 轮摔回 14%，之后八轮趴在 11% 到 15% 之间， 第 13 轮诈尸一次 94%，跟着又跌回 8%。词条进来，缓存归零；词条出去，再归零。

修复的一半，是向酒馆抄作业

病根定位之后，我们去读了酒馆的实现（SillyTavern 是开源的，我们测的 v1.18.0）。修复一共三处对齐， 加一味自创的药。对齐的三处，说白了都是酒馆出厂就做对了的事。

最先对齐的是递归扫描： 世界书词条可以互相引用，酒馆出厂默认开递归，第一轮就把互相引用的词条一次拉齐，之后提示词开头保持稳定。 我们的默认值是关，词条只能随剧情一条条挤进来，每进一条破一次缓存。

另一处是「0 等于不限制」：递归层数设 0，在酒馆语义里是不限层数，我们旧实现把 0 读成了「不递归」。 语义写反，纯属我们的错。

第三处和缓存无关，但更狠。酒馆判定「整词匹配」的边界规则对中文是能命中的；我们旧实现用的边界判定 在纯中文语境永远不成立。落到用户头上就是：开了整词匹配的中文卡，整本世界书静默失活，一个词条都触发不了。 这个兼容性 bug 是评测顺手挖出来的，比缓存那个更该修。

自创的那味药叫「设定驻留」：触发过的词条，这一局不再退场。酒馆没有这个机制，它治的正是两边都存在的病： 词条随剧情进进出出，提示词开头跟着抖。只是酒馆的出厂结构让这份抖动没那么致命。 有意思的是账面结果：驻留让词条只进不出，提示词理论上会变长， 同一张卡同样 15 轮实测反而变短了——修复后整场发送 68,051 个 prompt token，修复前 71,715 个。 滚动反复 miss，比让词条常驻更费 token。

同一批评测还揪出两处和缓存无关的钱线问题，一并修了：「开新一局」的表单在没有现成摘要时默认勾着付费生成摘要， 用户不留神点确认就白扣一次调用，现在付费动作必须显式勾选；DeepSeek 的思考输出一直没有关闭通道，补了开关。

复验：89.9%，以及一次作废的实验

修复包先在被打脸的《聂小倩》上复测：27.7% 到 89.9%，逐轮曲线从心电图变成一条直线，稳定在 92% 到 98%。 唯一的低谷在第 6 轮，19%。那一轮的探针问题把一个新词条第一次拉进设定区，首次进场必然 miss， 这是设计内的代价；驻留随即把它锁住，第 7 轮回到 93%。我们还把相邻轮次的请求体逐字节比对过： 从第 2 轮起，每一轮请求都是上一轮的严格前缀加追加。这就是缓存友好该有的样子。

复测里有一轮作废了，值得记下来。我们想测「老用户升级后」的形态，往测试机里预写了一份旧配置， 格式错了一层包装，被程序静默忽略，那一轮实际跑的还是全新安装形态。发现之后没有把它当成「又一次 89.9%」混进去，如实改记为新装形态的独立重复轮（89.3%，顺带证明 89.9% 不是单次侥幸）， 老用户形态重新造数据重跑。评测最值钱的就是这点较真。

然后是全量复测，18 格各跑三遍：普通模式 46.5% 到 89.9%，智能演绎 42.3% 到 88.3%，成本分别降 58% 和 63%；三张卡的命中率极差从 51.7 个百分点收敛到 5.8 个，深设定卡的整轮 miss 清零，上游首字延迟顺带降了 5 到 65 毫秒。

对照两边。裸酒馆 91.5% 仍然微高，剩下的 1.6 个百分点有具体解释：我们的脚本里有探针问题在故意绕开触发词提问， 我们这侧会把对应词条检索进场（检索是另一篇的故事），每次首进都是一轮设计内 miss；酒馆那侧词条压根不进场， 缓存好看，答案付出了代价。满配酒馆 74.6%，被修复后的两个模式反超了 14 到 15 个百分点：那套大型预设加插件 把提示词体量推到裸酒馆的 2.46 倍，命中率掉了 17 个百分点。这不是嘲讽——那套组合的设计目标本来就是文风和玩法， 不是省钱，只是「插件税」确实存在，装之前值得知道。

防一句「跑分特供包」的质疑：修复前基线和修复后的包都钉死了版本号和安装包哈希，修复后的包从干净源码快照构建， 就是发给用户的那份代码。

诚实账

最要紧的一笔：老用户升级后拿到的不是 89.9%。递归默认值的翻转只到达全新安装，老设备上旧默认值已经写进配置文件， 升级后吃到的是「只有驻留」的形态，实测 73.1%。是修复前的 2.6 倍，但离新装形态还差 17 个百分点， 差距全部来自互相引用的词条没法在第一轮拉齐。要不要动老用户的存量配置，是另一个产品决策，我们还没拍板。

成本数字按官方牌价机械折算，只用于组间相对比较，别拿去预测你的账单。每格三次独立重复；36 格基线矩阵被独立复算过一遍，零偏差，修复后的 18 格走同一套审计工具三层对账全绿。

修复自己也踩出过一个回归，被同一场评测的「不回退核对」抓住：驻留把智能演绎的设定检索候选池抽干了， 深设定卡的 12 道设定题从全对掉到 9 对。机理查明，当晚修复，复测检索恢复、缓存水位保住。 评测台搭起来之后，它就是回归网。

最后，我们不会说「Foreverse 比酒馆省钱」。裸酒馆 91.5% 仍是这场评测的缓存标杆，这是它出厂结构干净换来的， 应得的。我们能说的是：同题同价条件下，从落后 45 个百分点修到追平；这套「稳定内容在前、进场词条锁住」的纪律， 现在默认对所有新装用户生效。

设置页里现在有一个「设定驻留」开关，默认开。你可以自己验证这篇文章：拿一张触发式词条多的中文卡聊 15 轮， 打开 API 请求记录看逐轮的缓存命中字段，它应该稳定在 90% 上下，只在新词条第一次进场的那轮塌一次。 哪天它连着塌，那就是一种我们还没见过的进出场形态。实验台没拆，欢迎报给我们。