大模型上下文窗口超限：从 32K 到 48K 的改造实录
问题
模型运行一段时间后突然报错：
Error: Model context length exceeded.
Reason: request (35550 tokens) exceeds the available context size (32768 tokens)35550 个 token 超过了 32768 的上下文窗口限制。
原因分析
根本原因
- 初始配置的
--ctx-size 32768（32K）无法满足长对话需求 - 随着多轮对话积累，token 数持续增长最终超限
- 问题不是模型能力不够，而是上下文窗口不够大
影响范围
- Agent9B 的
max_input_length是 131072（128K），但模型端只有 32K - 模型端和 Agent 端的配置不同步，Agent 以为能发 128K，模型只能接收 32K
解决方案
第一步：扩大模型上下文窗口
将 --ctx-size 从 32768 改为 49152（48K）：
--ctx-size 49152为什么是 48K 不是 64K？
- Q3_K 量化下，每个 token 约需 200-400KB 显存
- 48K 上下文估算约 19.2GB，20GB 显存勉强有余
- 64K 会超显存导致 OOM
第二步：调整 Agent 端配置对齐
| 参数 | 旧值 | 新值 | 说明 |
|---|---|---|---|
max_input_length | 131072 | 49152 | 与模型 48K 对齐 |
compact_threshold_ratio | 0.8 | 0.7 | 更早触发压缩 |
reserve_threshold_ratio | 0.1 | 0.3 | 压缩后保留更多 |
history_max_length | 10000 | 5000 | 减少历史堆积 |
pruning_old_msg_max_bytes | 3000 | 5000 | 保留更多旧消息 |
pruning_recent_n | 2 | 3 | 多保留几轮最新消息 |
第三步：同步重启
修改完模型端和 Agent 端配置后，必须两端一起重启才能生效。
经验总结
- 模型端和 Agent 端上下文必须对齐：不一致会导致”我以为你能收，实际你收不了”的问题
- 48K 是 20GB 显存的极限：35B Q3_K + 48K ≈ 19.2GB，留了 800MB 余量
- 压缩策略要精细调优：
- 宽松的保留比例（30%）防止关键信息丢失
- 早一点触发压缩（70%）避免堆积到超限
- 建议监控 token 使用量，接近阈值时主动触发压缩