输出预留(output headroom)按最大输出能力全额预留,输入预算被砍半,75% 强制压缩过早触发

[ranxianglei]

模型:qwen3.8-27b (vllm)

问题

reserveOutputHeadroom 按模型注册表登记的最大输出能力(ctx.model.maxTokens)全额预留输出预算,而不是按请求实际配置/使用的 max_tokens。当 maxTokens 占窗口比例大时,有效输入预算被大幅砍掉,kernel 的 75% 强制压缩阈值相对完整窗口在很低的位置就触发。

复现 / 证据

会话 01a02d90-17b6-7ca7-b22a-a5170c2f9098,模型 qwen3.8-27b(contextWindow=262144,models.json maxTokens=131072):

[overflow-selfheal] event=output-headroom before=262144 after=131072 maxOutput=131072
[turn] tokens=98900 pct=34.42 limit=131072 nudge=active nudgeReason=OVER-LIMIT T1: max effective pending 65437, usage 75%
[nudge-injected] voice=emergency ... text=⚠️ Context limit reached — compress now

• 有效 limit = 262144 − 131072 = 131072(砍半)
• kernel usage = 98900/131072 = 75.45% ≥ 0.75(maxContextLimitPct)→ 强制 nudge
• 用户看到的 pct = 90222/262144 = 34.4%(相对完整窗口)—— 两个口径不同,所以看起来"才 30% 就强制压缩"

代码位置

• src/overflow-selfheal.ts:reserveOutputHeadroom(window, maxOutput)(0<maxOutput<window 时返回 window−maxOutput)、shouldReserveOutputHeadroom(api)(跳过 anthropic-messages)
• src/index.ts:165-171:maxOutput = ctx.model.maxTokens(模型注册表里的最大输出能力,非实际配置值)
• 引入:commit f44429f(2026-08-18),PR fix: harden context window — self-heal on upstream overflow + reserve output headroom (extension side) #177 "harden context window (overflow self-heal + output headroom)"

影响

• qwen3.8-27b:256K 窗口只剩 128K 输入预算,75% 阈值在完整窗口 ~34% 处触发
• 同窗口 int4 版(maxTokens=32K)只砍 12.5% —— 行为随模型配置差异巨大
• 实际回复很少用到 128K 输出,全额预留偏保守

可能的方向

1. 预留量取 min(model.maxTokens, 请求实际配置的 max_tokens),或设一个上限(如窗口的 25%)
2. maxContextLimitPct 相对完整窗口计算,而不是砍过后的 limit
3. 至少在 nudge 文案里说明有效 limit 已被输出预留砍过,避免误导模型/用户

[ranxianglei]

ework接单

[ranxianglei]

🤖 ework agent · qwen3.8-27b

已完成审核与修复，PR：#301

查重

仓库内（含已关闭）无同类 issue/PR，不重复。

审核结论

1. 问题属实（代码级验证，非凭描述）：

• 路径：src/index.ts context transform → reserveOutputHeadroom(config.modelContextLimit, ctx.model.maxTokens)（src/overflow-selfheal.ts:85-96，原实现 window - maxOutput 全额预留）→ kernel decideNudge：usage = tokenCount / modelContextLimit，maxContextLimitPct=0.75。
• qwen3.8-27b 算例复算：limit = 262144 − 131072 = 131072；98900/131072 = 75.45% ≥ 0.75 → OVER-LIMIT nudge；host pct = 90222/262144 = 34.4%。与你贴的日志逐字段吻合，双口径（pct 对完整窗口、limit 对预留后窗口）确认存在。

2. 层次判断：表面现象是「~34% 就强制压缩」+ 日志双口径误导；根因是预留量取注册表输出能力而非有界预算——maxTokens 占窗口比例越大，输入预算被削得越狠（int4 版只砍 12.5%，行为随模型配置漂移）。

3. 方向取舍：

• 方向 1a（min(注册值, 请求实际配置)）不可实现：pi 没有独立于 model 条目的 per-request max_tokens 配置——ctx.model.maxTokens 就是 pi 实际使用的值（registry 或 models.json modelOverrides），两者恒等，取 min 无意义。
• 方向 1b（按窗口比例封顶）✅ 本 PR 采用：reserved = min(maxTokens, outputHeadroomMaxPct × window)，新配置键默认 0.25（接受 ratio 或 "N%"；0 禁用预留，≥1 恢复旧行为）。理由：任何 ≤ 预留量的单轮回复在 95% emergency 阈值下仍不溢出（保证保留在关键处）；超出部分溢出一次后由既有 overflow self-heal（learned window + armed emergency）下一轮恢复——这正是该机制设计时接受的失败模式（"a missed reservation at worst overflows once"）。小预留不受影响（int4 版 32K/256K 保持原样），行为不再随 maxTokens 占比漂移。
• 方向 2（阈值相对完整窗口计算）不采用：需改 acp-kernel 语义（跨仓库 + acp-kernel 必须先发布的约束），且 limit 同时承载 truncate/emergency 带，改动面大收益低。
• 方向 3（nudge 文案说明）部分替代：nudge 文案属 kernel prompts（跨仓库），本地以日志消歧替代——[turn] 日志新增 fullWindow 字段（仅当 limit 被预留削减时出现），output-headroom 事件新增 cap 字段，pct/limit/fullWindow 三口径一眼可辨。

效果（qwen3.8-27b）

	修复前	修复后
有效 limit	131072（窗口的 50%）	196608（75%）
75% 带触发点（占完整窗口）	~37.5%	~56.25%

变更面

reserveOutputHeadroom(window, maxOutput, capPct=1)（两参调用向后兼容）+ outputHeadroomMaxPct 配置键 + 测试（含 issue 算例回归）+ CONFIGURATION.md/zh-CN + CHANGELOG。typecheck ✓ / 466 tests pass ✓ / build ✓。

需要旧行为的部署可设 "outputHeadroomMaxPct": 1 回退 A/B。

[ranxianglei]

看现在还有问题吗

[ranxianglei]

🤖 Powered by ework · qwen3.8-27b

当前状态核对：

修复本身：无遗留问题。 分支 2026-09-05_issue207-headroom-cap（commit b1b1273）修复完整且已验证：typecheck ✓ / 466 tests pass ✓ / build ✓。用你的 qwen3.8-27b 算例复算：有效 limit 131072 → 196608（窗口的 75%），75% 强制压缩带触发点从完整窗口 ~37.5% 移到 ~56.25%；int4 版（32K/256K）等小预留不受影响，行为不再随 maxTokens 占比漂移。

唯一剩余步骤：PR #301 尚未合并 —— #301 。合并 PR 是人工操作（系统规则禁止我合并），请自行合并；合并后 commit 的 closes #207 会自动关闭本 issue。在合并前 master 上仍是旧行为，所以严格说问题要等 PR 合入才算在线上解决。

想先验证实际行为再合并的话（本地预验证）：

git checkout 2026-09-05_issue207-headroom-cap
npm run build
cp dist/index.js ~/.pi/agent/npm/node_modules/billion-context-pi/dist/index.js
# 重启 Pi

两点设计内已知行为（非缺陷，供评估）：

• 单轮回复若超出预留量（默认窗口的 25%），会溢出一次，由既有 overflow self-heal（learned window + armed emergency）下一轮恢复——这是方向 1b 接受的失败模式。若要 A/B 对比旧的全额预留行为，设 "outputHeadroomMaxPct": 1；设 0 则完全禁用预留。
• 日志口径已消歧：[turn] 新增 fullWindow 字段（仅当 limit 被预留削减时出现）、output-headroom 事件新增 cap 字段，pct / limit / fullWindow 三个口径一眼可辨。