Skip to content

缓存变低,上游还总丢缓存 #2980

Closed
Closed
缓存变低,上游还总丢缓存#2980

Description

@jycs0o0o0
jycs0o0o0
opened on Oct 13, 2026

dsh-session-session-3d2308e4-1a68-435d-97f3-1a32b596e38f.zip
你看下这是我让DSH查的日志,总结,你看看有什么办法可以优化一下缓存,,大部分我都是用的中转,,缓存命中残次不平,
所以但是用了插件之后,平均缓存只有85-90,一般没开插件,我都是95以上,
具体丢缓存,还要继续测,等我多跑跑了再给你用AI总结

Activity

  1. ranxianglei commented on Oct 13, 2026

    @ranxianglei
    ranxianglei
    on Oct 13, 2026
    Owner

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 日志包收到了。我把你 DSH agent 的两份报告逐条对过原始数据,又对着 bili 源码把每条归因的代码路径审了一遍。结论先说:bili 没有弄坏你的缓存——命中率下降里约 81% 是指标假象(压缩把分母缩小了 2.4 倍),19% 是中转站自身的上游失效(装插件前就存在),插件自身只贡献约 0.74pp 的真实 miss。

    我验证了什么(不是只信你 DSH 的总结):

    • 账本恒等式 Σinput = Σcached + nc + cr + tr 残差为 0(kernel/src/cache-report.ts decomposeSample,精确闭合无估算)——你 DSH 复算的数字和 UI 完全一致,可信;
    • 「上游侧失效」占 miss 54% 的归因是硬证据:bili 只在证明上一请求整条消息列表逐字节保留(或纯尾部追加)却仍 miss 时才归给上游(src/cache-ledger.ts detectSeam)——字节都对上了,丢就不可能是 bili 的锅;
    • 代码审计排除了「bili 每轮重写历史」:ACP tag 的 token 数首次渲染后冻结不变、ref 永不复用(kernel/src/render-refs.ts);nudge 只作为临时 user message 追加在尾部,不碰历史中段(src/server/prepare-openai.ts:266-314);x-session-id 粘性路由 header 有转发、dsh 自己的 prompt_cache_key 原样透传(上游侧失效导致缓存命中只有80%用的api反代 workbuddy glm5.3 #2218/研究https://github.com/Wei-Shaw/sub2api 和bili配合的时候各种可能的缓存命中,兼容性等问题 #1931);
    • 那个吓人的「72/72 对 mid-history divergence」是误报:分类器只看首个分歧字节位置,把尾部参数抖动(如 max_tokens 逐轮变化)和临时尾注增删都标成了「历史中段重写」。证据:真·中段分叉(seam)全会话只计了 376K tok = miss 的 1.8%,那些请求命中率也没崩——真重写中段命中率早崩了。这个分类器缺陷我已单独立项修:#2982。

    八问:

    1. 是什么问题:装插件后平均缓存命中从 95%+ 掉到 85-90%,且各会话之间忽高忽低,想知道怎么优化。
    2. 什么原因导致的(三层):① 指标假象(主因,约占降幅 81%)——压缩把单请求上下文从 218K 缩到 88K,同样几千 tok 的失效在小分母里占比放大 2.5 倍。反事实检验:把装插件后的 miss 量放回装前的上下文长度,命中率是 96.45%,接近装前实测 97.68%。② 中转站上游失效(真实但非新引入,约 19%)——TTL 过期/节点轮换/密钥池轮换,呈站点性爆发(yaoyaozzz.com 某天 tr/input 高达 26%,次日 1.4%;装插件前也有低命中日),占总 miss 54%。③ 插件自身(小)——压缩回补 cr 9.3% + 重建缝 seam 1.8%(占 miss),全去掉也只找回 0.74pp。
    3. 影响范围与严重程度:成本影响远小于百分比看起来那么大——绝对 miss/请求只从 4,968 → 7,596 tok(+53%,且含模型/站点混合变化)。非可用性故障,纯经济+观感问题。另外确认了:UI 里「净节省 1.00B」是 token 数(理论上界),不是钱——按记录的价格画像折算 2 天真实价值约 $2.8~$27.6,你 DSH agent 那笔账是对的(我对过 computeFoldEconomics 公式)。
    4. 怎么优化(按收益排序):
      • ① 换中转站 / 盯站点切换(最大杠杆,对应 54% 的 miss):上游失效是站点专属且爆发的。bili 的 /acp-cache 页和 __bili/cache-report API 都有按站点拆分——哪个站点单日「上游侧失效」占比突增(>10%),直接换站。
      • ② 问中转站是否支持粘性路由:bili 已转发 x-session-id(dsh 会话 id)并透传 prompt_cache_key(上游侧失效导致缓存命中只有80%用的api反代 workbuddy glm5.3 #2218/研究https://github.com/Wei-Shaw/sub2api 和bili配合的时候各种可能的缓存命中,兼容性等问题 #1931)。如果中转站无视这些 header 做随机负载均衡,缓存必丢。直接问商家:x-session-id / prompt_cache_key 能否做 session affinity?支持它的站命中率会稳定得多。
      • ③ 折叠少而重(对应 9.3% 回补):你的 157 次折叠里 25 次没回本、92/142 节奏不达标(折得太碎)。两个现有配置项(无需等版本):compress.nudgeGrowthTokens(默认 50000,上下文增长多少触发一次折叠建议)→ 试 100000;compress.minCompressRange(默认 5000 字符,最小可折叠范围)→ 相应调大。效果:折叠次数减半、单次更深、回补占比下降;代价是折叠前上下文略高(你现在均值才 88K,余量充足)。调完观察 /acp-cache 的 paidBack 计数和「压缩回补」总量一天再定。
      • ④ 换看指标:不同上下文长度的会话不要横向比命中率 %,看绝对 miss/请求或 miss/总输入。你的数据自己会说话:20-50K 桶 86.66%,100-200K 桶 92.32%——纯粹是分母效应。
    5. 是否有回归问题:不涉及——本轮未改任何 bili 代码,纯诊断+配置建议。
    6. 是否破坏缓存:不涉及(未动任何机制)。
    7. 是否改了设计方向:无。
    8. 是否引入了新的配置:无。只引用现有配置项:compress.nudgeGrowthTokens(默认 50000)、compress.minCompressRange(默认 5000 字符),都在 ~/.config/billion-context/billion-context.json 的 compress 段。

    你说还要多跑跑再给 AI 总结——下次数据请带上按站点的每日 tr/input 和请求间隔分布,重点验证哪几个站的失效在爆发、以及换站后命中率是否稳住。

    判定:未发现需要修复的 bili 缺陷(seam 1.8% 属正常折叠成本);本 issue 主线动作 = 中转站选择/粘性路由确认 + 折叠节奏调参,等你后续测试数据。

  2. jycs0o0o0 commented on Oct 13, 2026

    @jycs0o0o0
    jycs0o0o0
    on Oct 13, 2026 via email
    Author

  3. ranxianglei commented on Oct 13, 2026

    @ranxianglei
    ranxianglei
    on Oct 13, 2026
    Owner

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 收到,这个反馈很关键——长任务不降智、1000+ 步不断档,这正是 bili 存在的意义(把上下文一直压在低位,避免你以前 500-800K 时那种上游按输入量变慢的区间)。省不省钱是次要的,干活顺畅才是主收益。

    调「跳大数值」时提醒两点:

    1. 别一次跳太猛。compress.nudgeGrowthTokens 建议先 100000(默认 50000 的 2 倍)跑一天,看 /acp-cache 页的 paidBack 计数和「压缩回补」总量再决定要不要继续加。调得越高,折叠越少、回补越省,但上下文会顶得更高——如果哪天你又感觉长任务后期变慢,就是调过头了,往回收一点。
    2. 观察期盯两个数:命中率 % 和绝对 miss/请求(别只看百分比,分母在变)。哪个中转站单日「上游侧失效」突增就换站,这条不受折叠参数影响。

    你持续用、多跑两天后把数据丢过来(有 AI 总结更好),我帮你核对调参方向对不对。

  4. ranxianglei
    added a commit that references this issue on Oct 13, 2026

    fix: body-stability classifier gains a tail class for post-array dive…

    ce2cf38

  5. ranxianglei commented on Oct 13, 2026

    @ranxianglei
    ranxianglei
    on Oct 13, 2026
    Owner

    #1997 看看和这个是否有关

  6. ranxianglei commented on Oct 13, 2026

    @ranxianglei
    ranxianglei
    on Oct 13, 2026
    Owner

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 查了 #1997(含 floor 8/10 你的裁决和 PR #2035)——部分相关:同一个机制域(折叠节奏 ↔ 缓存指标),但 #2980 的主因不在 #1997 的射程内。三点:

    1. 分母效应互相印证。缓存变低,上游还总丢缓存 #2980 用户数据独立复现了你在 Supports dynamic compress.nudgeGrowthTokens | 支持动态compress.nudgeGrowthTokens #1997 floor 8 的判断:压缩把单请求上下文从 218K 缩到 88K,同样几千 tok 的失效占比放大 2.5 倍;反事实检验(post-miss 量放回 pre-context)= 96.45% ≈ 装前实测 97.68%,即降幅 81% 是分母假象。这是第二个独立数据点(不同用户、dsh 宿主、中转站链路),支持你「基于缓存角度的动态调节不予考虑」的裁决——命中率 % 确实不该当调节信号。

    2. 我给用户的建议与 feat(#1997): throughput-adaptive nudge cadence (compress.nudgeAdaptive) #2035 同线递进。缓存变低,上游还总丢缓存 #2980 里我建议他手动把 nudgeGrowthTokens 从 50000 调到 100000 减少折叠(他的 157 次折叠:25 次没回本、92/142 节奏不达标,cr 回补占 miss 9.3%)。feat(#1997): throughput-adaptive nudge cadence (compress.nudgeAdaptive) #2035 合并发布后,他这种「长任务+批量工具输出」的负载直接开 nudgeAdaptive: true 比手挑静态值更贴切(突发自动放宽、安静期收窄)。等它 ship 我会在 缓存变低,上游还总丢缓存 #2980 更新建议指向 nudgeAdaptive。

    3. Supports dynamic compress.nudgeGrowthTokens | 支持动态compress.nudgeGrowthTokens #1997 解不了 缓存变低,上游还总丢缓存 #2980 的大头。该用户 miss 的 54% 是中转站上游失效(TTL/节点轮换/密钥池轮换,站点性爆发,装插件前就存在),pp 降幅的 81% 是分母效应(压缩固有代价,Supports dynamic compress.nudgeGrowthTokens | 支持动态compress.nudgeGrowthTokens #1997 已裁决接受)。feat(#1997): throughput-adaptive nudge cadence (compress.nudgeAdaptive) #2035 只优化插件自身那 ~0.74pp(cr 回补部分)。所以即使 feat(#1997): throughput-adaptive nudge cadence (compress.nudgeAdaptive) #2035 合并,他的命中率也不会回到 95%+,主杠杆仍是换站 + 确认中转站粘性路由(x-session-id/prompt_cache_key)。

    现状核对:PR #2035 仍 open 未合并(master 还在 0.1.195,src/config.ts 无 nudgeAdaptive 字段),用户跑的也是 v0.1.195——眼下只能手动调参,等合并发布后切自适应。

  7. ranxianglei commented on Oct 13, 2026

    @ranxianglei
    ranxianglei
    on Oct 13, 2026
    Owner

    所以还是中转的miss问题 miss的话我们是加了prompt_cache_key的 不知道用户上游是啥中转 是否需要适配

  8. ranxianglei commented on Oct 13, 2026

    @ranxianglei
    ranxianglei
    on Oct 13, 2026
    Owner

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 结论先说:不需要通用适配——数据已经把变量隔离到「站」本身了。证据和现状如下。

    1. 变量是站,不是链路(最硬的两组对照)
    用户机器上 DSH 自己的 siteledger(记录的是上游返回的真实 usage,比 bili 侧估计更客观)给出:

    • 同一天跨站(2026-10-11,同一用户/宿主/插件):yaoyao 87.5%(m/r=14,600)、cai 95.4%、xiaoqie 61.7%、d1v4 95.2%——只有站不同,命中率差 30pp+;
    • 装插件前的 9 月就有同样分化:bai 站 78-81% vs xiaoqiye 同日期 98%+。
      → 站的缓存行为差异早于且独立于 bili。30 天总均值其实是 96.67%,他感觉的 85-90% 是被重用了坏站的几天拉下来的。

    2. bili 现在已经发了什么(代码核对过)

    3. 为什么再发别的 header 大概率没用
    providerSide 归因的前提是出站体字节稳定证明——能发的稳定信号都发了。若站在用其中任何一个(x-session-id / pck),连续轮次就该命中;实际是爆发式丢 → 要么这站根本不按这些信号路由(纯池子轮询),要么它的后端轮换/TTL 本身就在杀缓存条目。对不按信号路由的站,换发什么字段都不改变结果;这类只能靠换站或商家提供粘性能力。

    4. 唯一值得留的适配口子(需要你拍板,不预建)
    如果确认某个具体站有私有粘性机制(自家 header/body 字段,商家文档可查),那么「按 provider 配置额外粘性 header」就是对的适配——这是配置面变更,按规矩先立项等你签,我不擅自建。前置条件是先知道用户主力站是谁、支持什么。我会在帖子里问用户:主力站名 + 是否问过商家的路由机制。

    5. 顺手补了一个诊断项
    往 #2982(缓存诊断面)加了个 checklist:出站时把实际生效的亲和信号(x-session-id 有无、pck 盖戳/透传)记进 cache-report,以后这类「站丢缓存」工单可以直接核对发了什么,少一个排查变量。

  9. ranxianglei commented on Oct 13, 2026

    @ranxianglei
    ranxianglei
    on Oct 13, 2026
    Owner

    如果确认某个具体站有私有粘性机制(自家 header/body 字段,商家文档可查),那么「按 provider 配置额外粘性 header」就是对的适配

    我怀疑可能还有私有适配的的header或者共有的我们没有发

  10. ranxianglei commented on Oct 13, 2026

    @ranxianglei
    ranxianglei
    on Oct 13, 2026
    Owner

    🤖 Powered by ework · qwen3.8-27b

    [bot] 🏷 两个方向都查了:①bili 有没有把客户端发的亲和字段丢掉——没有;②生态里「共有的」载体我们漏没漏——没漏。证据如下。

    ① bili 的转发是黑名单制,不是白名单(src/server.ts:2009-2016)
    除 hop-by-hop(connection/keep-alive/proxy-auth 等,RFC 7230 §6.1)和 bili 内部标记外,客户端发的所有 header 原样转发;body 里我们只重写 messages/tools/system,prompt_cache_key 透传或盖戳,其余字段(metadata、client_metadata、自定义字段)一律不动。→ dsh 或任何客户端今天若在发私有粘性字段,它已经到达中转站了,不是被 bili 吃掉。

    ② 开源中转网关生态的亲和载体清点(查了 sub2api、codex2api、caveman 这几个主流 OpenAI 兼容网关的实现):

    载体 形态 生态用法 bili 现状
    x-session-id header sub2api 第一优先读取 ✅ dsh 车道无条件发(#1931/#2218)
    prompt_cache_key body xAI/OpenAI 官方路由信号;sub2api/codex2api 连 chat-completions 形态都会兼容注入 ✅ 盖戳或透传(#2218)
    X-Grok-Conv-Id header xAI 专属会话头 ✅ 已识别为身份源、原样转发(deepseek 场景不涉及)
    client_metadata.session_id / body metadata body codex2api/sub2api 识别 ✅ 透传(我们不碰这些字段)
    Idempotency-Key / previous_response_id header/body 显式会话信号 ✅ 透传

    结论:可验证范围内没有漏发的「共有」载体——真正起作用的两个(x-session-id + pck)恰好就是 bili 在 dsh 车道主动保证发出的。DeepSeek 官方 API 本身没有亲和键文档,deepseek-走-中转的场景里一切取决于中转层自己的实现。

    ③ 私有机制没法从我们这边枚举,商业站的文档不公开。可靠路子只有两条:

    • 问商家(最便宜):主力站是否支持粘性路由、用什么字段、后端池怎么轮、缓存 TTL 多长;
    • 经验 A/B(用户可跑):同一长对话,N 轮里候选 header 值恒定 vs 每轮随机,对比命中率——恒定显著高就说明这站在用它。

    建议下一步:我在帖子里问用户主力站是谁 + 让他问下商家;如果确认某站有私有字段,再立「按 provider 配置额外粘性 header」的配置面提案(等你签,不预建)。#2982 里的出站信号可见性诊断项保留——以后这类工单先核对「发了什么」,少一个变量。

  11. ranxianglei
    added a commit that references this issue on Oct 13, 2026

    fix: body-stability classifier gains a tail class for post-array dive…

    c7b851e
  12. ranxianglei
    closed this as completedon Oct 13, 2026

  13. jycs0o0o0 commented on Oct 15, 2026

    @jycs0o0o0
    jycs0o0o0
    on Oct 15, 2026 via email
    Author
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions