先拿证据（不用改源码）：

1. 启动参数加 --log-requests，看每轮请求日志里的 hit len（前缀命中长度）；
2. 或者加 --enable-metrics，盯 sglang:prefix_cache_hit_rate 这个指标；
3. 顺手确认一下启动参数里没有 --disable-radix-cache（0.5.x 前缀缓存默认是开的）。

情况 A：70k 前 hit len ≈ 全部历史，过 70k 后突然掉到 0，之后每轮都全量重算
这是 KV cache 池满了：单用户长对话在 RadixAttention 里是一条超长前缀链，池子装不下时 LRU 淘汰会从链最老的开头踢，下一轮请求的前缀从淘汰点起全部重算。解决（按性价比）：

• --mem-fraction-static 0.88 → 0.90~0.92。单用户并发低，余量足够（TID:1193 里 Che 的配置就是 0.90）；
• 如果现在 KV 是 FP16，加 --kv-cache-dtype fp8_e4m3，池容量直接翻倍；
• 或者反过来把 --context-length 压到池容量以内（比如 96k/128k），让整条对话装得下，不触发淘汰；
• 治标：--chunked-prefill-size 2048 + --enable-mixed-chunk-prefill，真 miss 时 prefill 分块执行，不会整段卡死。

情况 B：hit len 从一开始就只有几百 token（≈ system prompt 长度），跟 70k 无关
这是客户端每次请求的前缀对不上，不是服务端缓存问题：网关（new-api 之类）或客户端做了滚动窗口截断（中间历史删掉只留头尾）、往 system prompt 里注入会变的内容（时间戳/会话变量）、或续写时 continue_final_message/add_generation_prompt 前后不一致。这种要查客户端，服务端怎么调都没用。

另外 0.5.15~0.5.17 都是老版本了，条件允许可以试试 0.6.x，前缀缓存和淘汰策略改进不少；但先按上面定位，大概率一个参数就解决，不用动源码。