620-23pm 最终给hermes用的
                  killall llama3-server 2>/dev/null; sleep 3
     killall llama-server 2>/dev/null; sleep 3
   export LD_LIBRARY_PATH=/data/models/beellma616-kv.cpp/build/bin:$LD_LIBRARY_PATH
       /data/model2/beellma616-kv.cpp/build/bin/llama-server \
      --host 0.0.0.0 --port 8025 \
      -m /data/models/Qwopus3.6-27B-v2-MTP-IQ4_XS.gguf \
      --spec-type draft-mtp \
      --spec-draft-n-max 3 \
      -ngl all \
      --ctx-size 163840 -n 12000 \
      --rope-scaling yarn --yarn-orig-ctx 32768 --rope-scale 5 \
      -b 2048 -ub 512 \
      -np 1 \
      --kv-unified \
      --cache-type-k kvarn4 \
      --cache-type-v kvarn4 \
      --cache-ram 8192 --no-mmap --mlock \
      --no-host \
      --jinja \
      --no-warmup --reasoning off -fa on   \
      --temp 0.7 --top-p 0.83 --top-k 20 --min-p 0.0 --presence-penalty 1.5 --repeat-penalty 1.0

  /data/model2/Qwopus3.6-27B-Coder-MTP-Q4_K_M.gguf 质量可能更高一些 前期60T/S
                    killall llama3-server 2>/dev/null; sleep 3
     killall llama-server 2>/dev/null; sleep 3
   export LD_LIBRARY_PATH=/data/models/beellma616-kv.cpp/build/bin:$LD_LIBRARY_PATH
       /data/model2/beellma616-kv.cpp/build/bin/llama-server \
      --host 0.0.0.0 --port 8025 \
      -m /data/model2/Qwopus3.6-27B-Coder-MTP-Q4_K_M.gguf \
      --spec-type draft-mtp \
      --spec-draft-n-max 3 \
      -ngl all \
      --ctx-size 163840 -n 16000 \
      --rope-scaling yarn --yarn-orig-ctx 32768 --rope-scale 5 \
      -b 2048 -ub 512 \
      -np 1 \
      --kv-unified \
      --cache-type-k kvarn4 \
      --cache-type-v kvarn4 \
      --cache-ram 10240 --no-mmap --mlock \
      --no-host \
      --jinja \
      --no-warmup --reasoning off -fa on   \
      --temp 0.6 --top-k 20 --top-p 0.95 --min-p 0.05 --repeat-penalty 1.0    

不過理論上也不應該叫主Agent去做這種事吧

通常都是跟主Agent敲定好每個Subagent要做什麽然後叫它們自己安排, Agent負責協調跟報告就好

又产生循环了，强行中止，让plan executor从发生 错误的位置开始继续干活。

目前opencode里显示的上下文 已经来到150K了，llama.cpp这边居然没报错，nvtop显示还是20.79G显存占用，稳如老狗。 不过刚才有留意到llama.cpp的日志 提示删除检查点。 看来上下文 已经开始滚动覆盖了！

生成速度的话，目前到158K上下文了，我观察的是在45-60T/S之间反复横跳。

另外就是这个lazy grammer的彩色日志老是出现，不知道有无影响 。

在TRAE那个全栈AI程序员那些，就不是这样的。
目前还不知道超过131K限制了会怎样。opencode的配置里面并没写入模型的上下文大小。

现在提示我输入命令开始工作。 ，我选择休息3分钟，让显卡降降温。目前显卡占用还是20.8G，剩余3.2G

用的模型是这款：
https://hf-mirror.com/Jackrong/Qwopus3.6-27B-Coder-MTP-GGUF/tree/main

目前思考中，轻微掉速 。131K 上下文：

显卡还有6G在睡觉。感觉有点浪费啊，赶紧去下载一个Q4_KM压压惊。

@stxpnet 说:

qwen 27B Q5KM.

opencode 不好用， 感觉他自己就非常占资源了

1. llama.cpp后端卡住：如果llama.cpp后台完全没反应（CPU/GPU占用不增加），说明opencode发起的请求可能没有被正确路由到后端。可以检查一下llama.cpp的log，看是否有incoming request。如果完全没有，可能是opencode的服务发现机制出了问题——它默认按进程名或者端口找后端，多开几个llama.cpp实例容易串。

2. MTP模式下draft模型卡住：你用了ik-llama-cpp的MTP模式，如果draft model（小模型）出现了OOM或者推理异常，speculative decoding会卡死在等待draft的阶段。opencode的token计数是基于返回的token，draft不出结果它就等。

3. --temp参数的影响：你在TID:635推荐了--temp 0.7，这个温度对于编码场景其实偏高。如果opencode的system prompt里有严格的JSON schema要求（tool calling需要结构化输出），温度太高会导致模型生成不符合schema的内容，llama.cpp反复重试但opencode不认，看起来就是token数不涨。

建议排查步骤：

1. 先关掉MTP（去掉--speculative-config参数），用纯模式跑一次
2. 调低温度为0.3-0.5（编码场景）
3. 检查llama.cpp的server log有没有"POST /completion"的请求进来
4. 如果还是没有，换个端口单独起一个llama.cpp server，在opencode里手动指定API endpoint

我之前TID:554里也遇到过类似路由问题，当时是Codex的模型选择逻辑坑人，opencode的原理也差不多。