本地大模型新基准 ctx-cliff：定位 VRAM 与上下文极限
Reddit 用户发布名为 ctx-cliff 的本地 LLM 压测脚本，可在指定配置下扫描模型在不同上下文长度下的表现…
本地部署大模型的玩家经常遇到一个棘手问题：当上下文长度不断拉长时，VRAM 在某个临界点会突然耗尽，模型表现随之断崖式下跌，而这一拐点往往难以提前预测。Reddit 用户 cHunter789 在 r/LocalLLaMA 板块发布了一个名为 ctx-cliff 的开源压测脚本，专门用来在指定 llama-server 配置下扫描模型从 2k 到 109k 上下文长度的表现，从而精确定位 VRAM 瓶颈与速度衰减点。
工具原理
ctx-cliff 通过逐步递增 prompt 长度，反复触发预填（prefill）与解码（decode），并实时测量两个关键指标：
- 吞吐量（ctx、prefill、decode 的 tokens/s）；
- 端到端 wall time（单次请求总耗时）。
当 VRAM 用尽时，wall time 会急剧攀升，吞吐量断崖下跌，脚本同时记录每一次输出是否为正常截断、提前 STOP 或异常（>1000 t/s）。如果异常或 STOP 频繁出现，意味着当前模型与量化在该上下文区间内已不可用。
GGML_CUDA_ENABLE_UNIFIED_MEMORY 的关键作用
文章重点强调了一个常被忽略的环境变量 GGML_CUDA_ENABLE_UNIFIED_MEMORY=1。开启后，CUDA 分配会改走 cudaMallocManaged，由 NVIDIA 驱动的 MMU 接管显存调度：
- 以 4 KB / 2 MB 的细粒度物理页替代 llama.cpp 默认的 VMM Pool 大块分配，显著减少显存碎片；
- 在显存不足时允许把部分张量卸载到系统内存，避免直接 OOM。
代价是同时开启了 offload，因此必须配合 ctx-cliff 实测，才能确定当前硬件实际可用的上下文窗口。该环境变量对应的源码位于 ggml-cuda.cu 的 181 行附近。
参考模型实测表现
以 cHunter789/Qwen3.8-27B-i1-IQ4_KS_KT-GGUF 为例，配合 context 110000、cache q4_0、batch 512、ubatch 128、flash-attn on 等参数启动 llama-server，脚本在 2k–109k 区间以步长 2k 扫描，结果显示：
- 在 2k–24k 区间 decode 速度稳定在 46–38 t/s，wall time 维持在 11–20 s；
- 进入 30k 后 wall time 逐渐上行，46k–90k 区间出现多次 STOP@316/STOP@463，说明模型在长上下文下已开始失效；
- 90k 之后 wall time 出现 44–54 s 的离群值，decode 跌至 24 t/s 附近，呈现典型的「VRAM 悬崖」。
文章还对比了用 Thireus GGUF-Tool-Suite 生成的同参数量化版本，结果中出现了大量 STOP 和一次异常（模型完全失败），说明该量化在该上下文区间不可用。
适用人群与局限
ctx-cliff 主要面向在 NVIDIA 单卡或多卡环境下手动调参 llama-server 的进阶用户，需要自行准备代码型长 prompt（如 tests/code_4M.py）。脚本目前基于 Python 3 运行，输出为纯文本表格，便于二次处理。对于使用其他推理后端（如 vLLM、SGLang）或非 NVIDIA 硬件的用户，文章给出的 GGML_CUDA_ENABLE_UNIFIED_MEMORY 经验并不直接适用，仍需自行寻找等价方案。