📦 Local Inference Context — 本地推理上下文
v1.0.0用于自托管LLM后端（llama.cpp，Ollama）的上下文管理。防止由于VRAM有限的KV缓存导致的中任务503错误和上下文溢出。使用...
by @joekravelli运行时依赖
安装命令
点击复制技能文档
本地推理上下文 通用上下文技能假设可靠的大型云服务提供商。 本地后端（llama.cpp，Ollama）具有不同的故障特征：KV缓存由VRAM限制，服务器在OpenClaw的压缩逻辑触发之前可能返回503，而压缩模型是相同的过载本地模型。 本技能解决了这一现实。 为什么本地后端以不同的方式失败 云服务提供商 本地llama.cpp / Ollama 上下文限制是一个软API错误，OpenClaw在压缩后重试 KV缓存已满，服务器返回503或上下文长度超过请求中间压缩使用相同的模型，该模型始终可用 压缩使用相同的过载本地模型 — 也可能失败 上下文窗口正是API报告的内容 有效上下文 = min（配置的 --ctx-size，KV缓存的可用VRAM） 没有空闲插槽驱逐 空闲插槽可以被驱逐； 服务器在下一个请求上返回“加载模型”503 实际后果：在GPU受限的设置中（例如，24 GB卡运行27B Q5模型），可用的KV缓存预算大约为5-8 GB。 在32k令牌配置上下文中，它会比配置限制更快地填满。 将50％填充视为黄色，70％视为红色 — 不是60/80％。 校准有效上下文预算 在长时间会话之前，运行一次以了解实际的可用空间： # 检查VRAM可用空间 nvidia-smi --query-gpu=memory.used,memory.free,memory.total \ --format=csv,noheader,nounits # 检查llama.cpp插槽状态 curl -s http://localhost:8081/slots | python3 -m json.tool 如果memory.free小于4 GB，则将会话视为已经是黄色，无论/status报告什么。 将结果记录到内存：VRAM可用空间：X MB — 有效上下文预算：减少 本地后端的阈值 填充级别 状态 操作 < 50％ 绿色 正常继续 50-69％ 黄色 修剪工具输出，刷新关键事实到内存 70-84％ 红色 检查点，提供/compact继续之前 ≥ 85％ 临界 停止扩展。 压缩或/new在下一个工具调用之前 在会话开始和任何工具调用返回超过约200行输出后检查/status。 识别本地后端故障 这些是服务器端错误，而不是OpenClaw压缩事件。 它们需要与正常上下文溢出不同的响应： 信号 含义 HTTP 503带有“加载模型”正文 空闲插槽被驱逐； 模型正在重新加载。 等待10-30秒，然后重试一次。 HTTP 503带有“无可用插槽”正文 所有插槽都忙或KV缓存已满。 不要立即重试 — 先压缩。 错误中上下文长度超过 硬KV缓存溢出。 压缩或启动/new在任何重试之前。 突然非常缓慢的响应然后超时 KV缓存抖动 — 在下一个请求之前减少上下文。 永远不要在首先减少上下文之前重试503“无可用插槽”或上下文溢出。 重试会使问题变得更糟糕，因为它会发送相同的过大有效负载。 长时间操作的预任务清单 在任何预计超过4次的任务之前（文件编辑，调试会话，多步骤设置）： 运行/status — 注意当前填充百分比。 如果填充百分比已经超过40％，请检查nvidia-smi。 估计任务的令牌成本： 每个文件读取≈500-3000个令牌，取决于文件大小 每个exec结果≈200-1500个令牌 每个web_fetch≈1000-4000个令牌 如果估计的总数将超过70％，则将其分成阶段并提前告知用户。 黄色状态（50-69％）：精简工具卫生 将以下习惯应用于黄色状态的每个工具调用： # 代替读取整个文件： sed -n '1,50p' /path/to/file # 前50行 grep -n “error\|warn\|fail” 日志文件 # 有针对性的grep tail -100 /var/log/syslog # 最近的条目 # 代替详细的exec输出： some-command 2>&1 | tail -30 systemctl status服务 --no-pager --lines=20 # 总结大型输出 在每个工具调用后立即将关键值写入内存 — 不要依赖于它们在压缩摘要中幸存。 红色状态（70-84％）：在继续之前创建检查点 现在将检查点写入内存：