92 lines
6.3 KiB
Markdown
92 lines
6.3 KiB
Markdown
# 长上下文测试：64K / 128K 通过，接近 262K 存在主机 OOM
|
||
|
||
> 历史实验记录：保留当时的配置和恢复状态。当前部署已改为 128K eager 基线，见 [当前状态](README.md)。
|
||
|
||
2026-09-17 开始测试，2026-09-18 完成恢复。方案见 [测试方案](context262k-plan.md)。
|
||
|
||
**不能将当前配置的 262144 上限视为稳定可用容量。**
|
||
64K、128K 的 eager 和 CUDA Graph 两组均通过本轮单请求合成检索。
|
||
接近 260K 时，eager 虽然完成全部检索并答对，主机已发生 OOM、杀掉音频服务；
|
||
CUDA Graph 在第一份 260K 文档的首次请求中进一步触发 OOM，vLLM 被杀，请求未完成。
|
||
本轮已停止后续 260K 请求，不调整参数继续追测。
|
||
|
||
## 方法与实际长度
|
||
|
||
- 两组都启用前缀缓存、相同 Mamba 修正；MTP=2、BF16 KV、GPU memory=0.80。
|
||
- 每档两份不同合成项目预算档案，在约 5%、50%、95% token 位置放入唯一项目记录。
|
||
- 每份查询前、中、后位置，再重复前部问题。共计划每组 24 次主请求；串行执行。
|
||
- 输出预算 2048，temperature=0、seed=42、reasoning_effort=low；思考与正文共用预算。
|
||
- 固定输入在两组间复用，记录文档及完整问题哈希；新的文档前缀避免与预检请求复用。
|
||
- 使用服务端 `/tokenize`，显式 `chat_template_kwargs.reasoning_effort=low`，
|
||
正式完成请求的 usage 与预检逐条一致。
|
||
- 实际输入分别为 65508–65510、131038–131040、259963–259965 tokens。
|
||
最大输入加预留输出为 262013，低于 262144；不是发送 262144 输入后再额外申请输出。
|
||
- 资源采样约每 5 秒一次；不清 OS 页缓存，两种模式按 eager → graph 执行，顺序不随机化。
|
||
|
||
## 请求结果
|
||
|
||
| 输入档位 | eager 首试检索 | CUDA Graph 首试检索 | 稳定性结论 |
|
||
|---|---|---|---|
|
||
| 约 64K | 8/8 正确 | 8/8 正确 | 本轮通过 |
|
||
| 约 128K | 8/8 正确 | 8/8 正确 | 本轮通过 |
|
||
| 约 260K | 8/8 正确，但主机 OOM | 首个请求 OOM 中断，后续未执行 | 两组都不通过 |
|
||
|
||
完成的 40 次主请求均正常 stop，没有答案重试或预算截断；图版本第 41 个主请求未完成。
|
||
已完成请求中未记录 KV 缓存抢占。这不排除主机内存不足，二者不是同一判据。
|
||
|
||
## 延迟
|
||
|
||
首 token 包含思考。首次读入列保留两份文档的实测值；复用列取 6 次后续查询的中位数。
|
||
|
||
| 输入档位 | eager 首次首 token（秒） | graph 首次首 token（秒） | eager / graph 复用首 token（秒） |
|
||
|---|---:|---:|---:|
|
||
| 约 64K | 30.66 / 31.04 | 31.38 / 31.20 | 1.64 / 1.63 |
|
||
| 约 128K | 64.90 / 63.08 | 64.67 / 63.28 | 1.77 / 1.77 |
|
||
| 约 260K | 168.29 / 137.20 | 未完成 | 1.82 / 无结果 |
|
||
|
||
eager 的 260K 首次完整回答耗时约 170.50 / 139.25 秒；复用后中位数约 3.82 秒。
|
||
该耗时记录来自发生过主机 OOM 的阶段，不能作为稳定性能承诺。
|
||
260K 后续请求每次实际 prefix hit 为 257600 tokens。
|
||
CUDA Graph 对本轮 64K/128K 预填充未显示明显加速，不能把此前短回答约 4.4% 的收益外推到超长输入。
|
||
|
||
## 主机 OOM 证据与影响
|
||
|
||
- eager 阶段采样最低 MemAvailable 约 0.139 GiB；23:28:31 的内核日志记录杀掉 4 个
|
||
`wireplumber` / `pipewire` 进程。模型继续回答不代表系统没有受影响。
|
||
- graph 阶段采样最低 MemAvailable 约 0.077 GiB；23:50:12 的内核日志记录杀掉 21 个进程，
|
||
包括 vLLM、用户管理、D-Bus、桌面门户和音频进程。容器监控记录 `OOMKilled=true`。
|
||
- 图请求输出流中断，测试客户端报 `Incomplete response or missing usage`，并触发恢复。
|
||
- 两阶段 swap 存量最高都仅约 0.40 GiB；swap 不大量增长不能证明没有内存风险。
|
||
- 以上是主机内存耗尽证据，不是已定位到具体 CUDA 内核的缺陷，也不是输出 2048 tokens 太小。
|
||
|
||
原保护条件要求“低于 4 GiB 持续约 30 秒且同期换页超过 512 MiB”，并检查容器 OOM。
|
||
它遗漏了主机进程先被杀的情况，导致 eager 的资源风险未被及时判失败。
|
||
该监控覆盖不足已记录；最终稳定性判定以内核日志为准，不能只看 Docker 健康或答案正确率。
|
||
|
||
改进版监控位于 `experiments/context262k/monitor.py`：加入 `/proc/vmstat` 的主机 OOM 计数，
|
||
并在低于 2 GiB 持续约 5 秒时停止测试容器，不再依赖显著 swap 增长。
|
||
这是本次事故后的改进，仅做语法检查；没有为验证保护而再次制造低内存场景。
|
||
原监控保存在 `monitor-original.py`，两者均是尽力保护，不能保证拦截采样间发生的瞬时 OOM。
|
||
|
||
## 复现记录与限制
|
||
|
||
- `scripts/context-benchmark.py`：确定性生成、服务端计数预检、流式检索测试。
|
||
- `scripts/summarize-context.py`：按档位汇总，首试和重试分开；请求完成不等于主机稳定。
|
||
- `docs/results/context262k/`：正式输入清单、请求结果、资源采样、内核 OOM 事件提取。
|
||
- 初次脚本预检曾误用 Transformers 的 BatchEncoding 长度，已改成 `return_dict=False`；
|
||
另一次预检请求答对但发现思考模板导致 12-token 计数差异，已修正。两者不混入正式对照。
|
||
- 本轮只测试简短合成检索；未验证长答案生成、真实复杂推理、并发满长、长期运行或多模态。
|
||
|
||
当前证据支持优先在 128K 以内使用和继续验证。要争取接近 262K 的稳定容量，需另行留出更多主机内存并复测，
|
||
例如评估降低 KV 缓存预算；本轮没有以调整配置后的结果替代原配置的失败。
|
||
|
||
## 恢复状态（2026-09-18 00:02，Asia/Shanghai）
|
||
|
||
- 已恢复 `local/qwen38-flash-spark:prefix-eager-0bfc7a15`，容器 healthy，重启策略 `unless-stopped`。
|
||
- 恢复后的算术、中文与工具调用 smoke test 全部通过，可用内存约 18 GiB。
|
||
- 已重新启动被 OOM 杀掉的用户管理服务，并确认 D-Bus、音频和用户桌面门户服务 active。
|
||
系统及当前用户的 failed units 均为 0；这不等于核验过远程桌面应用的会话内容。
|
||
- 默认 Compose 与测试前完全一致，仍配置 262144 上限；本轮没有擅自缩短服务上限。
|
||
该上限在当前资源设置下不代表稳定容量，建议业务侧优先限制在 128K 范围内。
|
||
- 所有长上下文测试已停止；没有继续使用失败图配置，也没有再次制造内存压力验证新监控。
|