decideNudge: effectiveThreshold (pending 时半阈值) 是死代码——只进 breakdown,没有任何门控使用

[ranxianglei]

现象

decideNudge() 里为“已有 pending nudge”计算的半阈值 effectiveThreshold 是死代码:只写进了 breakdown 报告,没有任何门控使用它。结果是:一次 nudge 注入后如果模型没有压缩(例如 compress 调用失败、被校验拒绝),后续增长必须跨过完整的 growthFloor 才会再次触发,半阈值"hold 半个 Nudge 尽快补发"的设计意图从未生效。

真实会话证据(billion-context-pi 会话 01a00a38-b638-7384-a6ab-24e0ff20f200,vllm/qwen3.8-27b,limit 262144):

• 11:41Z 唯一一次 compress 调用被 pi-core typebox 校验拒绝(content.0: must be object,非严格工具 provider 把数组参数字符串化——适配层已另行修复)
• nudge 在 est 78429 注入过一次(T1 growth path),之后 95 分钟零压缩
• nudgeGrowthTokens = resolveAdaptiveGrowth(262144) = min(cap 50K, max(floor 50K, 5%×262144)) = 50000
• growthFloor = max(minGrowthFloor 20000, 0.45×50000) = 22500
• 失败后到会话结束 est 增长仅 ~12K < 22500 → 第二次 nudge 永远不来

源码证据(v0.0.27)

src/compress.ts:

951:  const effectiveThreshold = hasPendingNudge
952:    ? Math.floor(nudgeGrowthTokens / 2)
953:    : nudgeGrowthTokens;
...
962:  const growthFloor = Math.max(
963:    config.nudge.minGrowthFloor,
964:    config.nudge.minGrowthRatio * nudgeGrowthTokens,   // ← 未用 effectiveThreshold
965:  );
...
987:  const growthReady = growthSinceReference >= growthFloor;   // ← 未用 effectiveThreshold
...
1021:    if (t1Eff >= nudgeGrowthTokens) {                       // ← 未用 effectiveThreshold
...
1099:      effectiveThreshold,    // 唯一使用:breakdown 报告字段

测试不具鉴别力

tests/nudge.test.ts:87-103("nudge: pending nudge halves threshold for faster re-nudge"):growth 5500 ≥ growthFloor 5000,floor 本身就放行了,断言通过与否和 halving 无关,删掉 951-953 这三行测试照样绿。同样 L84 的失败用例归因于 effectiveThreshold,实际是 growthFloor 3000 < 5000 拦的。

接线时的注意点

仅把 effectiveThreshold 代入 964 行的 ratio 项不够——默认 minGrowthFloor: 20000(src/config.ts:18)会先 bind:pending 时 floor = max(20000, 0.45×25000=11250) = 20000,上面会话的 ~12K 增长仍然过不去。要让半阈值真正生效,需要决定语义,例如:

1. pending 时对整个 growthFloor 缩半:max(minGrowthFloor, ratio × effectiveThreshold) × 0.5 → 11250,12K > 11250,该会话会再触发;或
2. growthReady = growthSinceReference >= Math.min(growthFloor, effectiveThreshold);或
3. 保持 growthFloor 不变,仅放宽 1021 行的 t1Eff >= effectiveThreshold(pending 时对 pending 内容要求减半)。

方案 1/2 会改变 re-nudge 频率(更激进),方案 3 只影响 tier 内容门槛。需要先定语义再补一个具鉴别力的测试(growth 落在 floor 和 unhalved 阈值之间,且 floor 不 bind 的配置)。

关联

• Naming collision: two distinct concepts both called growthFloor in the nudge path #43(nudge 路径两个 growthFloor 命名冲突——本 issue 里 growthFloor(962)是门控 floor,resolveAdaptiveGrowth 里的是另一回事,读代码时极易混淆)
• feat: nudge mid-band cadence + compress rejection escalation — port omp-side fixes #45/#48 into the kernel #73(nudge mid-band cadence——同属"nudge 之后没有压缩"的再触发问题)

[ranxianglei]

/tmp/issue-86-comment.md