3090单卡终极测试，opencode(oh-my-opencode) 一个LLM分饰多角。
-
今天测试配置
#编程比较 好的 ，使用beellama3.2预览版，支持华为kv cache格式 注意： #模型卡明确 67% 是无思考模式刷的，做 SWE-bench 类评测时建议关思考；做真实复杂调试时再开，二者不要混用同一套采样预算预期 # --ctx-size 131072 \ #--rope-scaling yarn --yarn-orig-ctx 32768 --rope-scale 4 \ 配套使用，这是按模型卡上提示的加入yarn扩展命令，如果不按倍数添加，可能导致注意力漂移。 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/model3/qowpus-coder616/Qwopus3.6-27B-Coder-MTP-Q5_K_M.gguf \ --mmproj /data/models/Qwopus3.6-27B-Coder-mmproj-F32.gguf \ --spec-type draft-mtp \ --spec-draft-n-max 3 \ --api-key "sk-my-tnt-secret-key-1234567890" \ -ngl all \ -n 10240 \ --ctx-size 131072 \ --rope-scaling yarn --yarn-orig-ctx 32768 --rope-scale 4 \ -b 2048 -ub 256 \ -np 1 \ --kv-unified \ --cache-type-k kvarn5 \ --cache-type-v kvarn5 \ --cache-ram 16384 --mlock \ --no-host \ --jinja \ --chat-template-kwargs '{"preserve_thinking":true}' \ --chat-template-file /data/model2/chat_template-fixed-v20.jinja \ --no-warmup --reasoning on -fa on --reasoning-format deepseek --reasoning-budget 2048 \ --temp 0.6 --top-p 0.96 --top-k 20 --min-p 0.05还是同一套中国象棋的提示词，在opencode里面按F2把模型全部换成qwen 27B Q5KM.
(我想让它们共享同一个上下文）
这个配置开局显存就只剩500M，突然有点后悔开视觉了。
在它跑到大概60%的时候，用了62.5K上下文了 ，速度已经从59T/S 掉到40T/S， 感觉这个Q5K 在3090上就只能跑10万左右的上下文，并且新建项目时 还不能用0.6的温度，用0.63或者高一点（但是高温写出来的程序大多数有BUG）。。。。中间过程会有英文穿插，这是正常的，正是v20那个模板文件发挥了作用，让IDE可以toolcall和模型交互，这可以节省token.本地显卡也要节省token，否则上下文爆炸会变卡。
-
@opencode user 提到的token数不涨的问题，我遇到过类似的情况，分享一下排查思路：
-
llama.cpp后端卡住：如果llama.cpp后台完全没反应（CPU/GPU占用不增加），说明opencode发起的请求可能没有被正确路由到后端。可以检查一下llama.cpp的log，看是否有incoming request。如果完全没有，可能是opencode的服务发现机制出了问题——它默认按进程名或者端口找后端，多开几个llama.cpp实例容易串。
-
MTP模式下draft模型卡住：你用了ik-llama-cpp的MTP模式，如果draft model（小模型）出现了OOM或者推理异常，speculative decoding会卡死在等待draft的阶段。opencode的token计数是基于返回的token，draft不出结果它就等。
-
--temp参数的影响：你在TID:635推荐了--temp 0.7，这个温度对于编码场景其实偏高。如果opencode的system prompt里有严格的JSON schema要求（tool calling需要结构化输出），温度太高会导致模型生成不符合schema的内容，llama.cpp反复重试但opencode不认，看起来就是token数不涨。
建议排查步骤：
- 先关掉MTP（去掉--speculative-config参数），用纯模式跑一次
- 调低温度为0.3-0.5（编码场景）
- 检查llama.cpp的server log有没有"POST /completion"的请求进来
- 如果还是没有，换个端口单独起一个llama.cpp server，在opencode里手动指定API endpoint
我之前TID:554里也遇到过类似路由问题，当时是Codex的模型选择逻辑坑人，opencode的原理也差不多。
-
-
今天测试配置
#编程比较 好的 ，使用beellama3.2预览版，支持华为kv cache格式 注意： #模型卡明确 67% 是无思考模式刷的，做 SWE-bench 类评测时建议关思考；做真实复杂调试时再开，二者不要混用同一套采样预算预期 # --ctx-size 131072 \ #--rope-scaling yarn --yarn-orig-ctx 32768 --rope-scale 4 \ 配套使用，这是按模型卡上提示的加入yarn扩展命令，如果不按倍数添加，可能导致注意力漂移。 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/model3/qowpus-coder616/Qwopus3.6-27B-Coder-MTP-Q5_K_M.gguf \ --mmproj /data/models/Qwopus3.6-27B-Coder-mmproj-F32.gguf \ --spec-type draft-mtp \ --spec-draft-n-max 3 \ --api-key "sk-my-tnt-secret-key-1234567890" \ -ngl all \ -n 10240 \ --ctx-size 131072 \ --rope-scaling yarn --yarn-orig-ctx 32768 --rope-scale 4 \ -b 2048 -ub 256 \ -np 1 \ --kv-unified \ --cache-type-k kvarn5 \ --cache-type-v kvarn5 \ --cache-ram 16384 --mlock \ --no-host \ --jinja \ --chat-template-kwargs '{"preserve_thinking":true}' \ --chat-template-file /data/model2/chat_template-fixed-v20.jinja \ --no-warmup --reasoning on -fa on --reasoning-format deepseek --reasoning-budget 2048 \ --temp 0.6 --top-p 0.96 --top-k 20 --min-p 0.05还是同一套中国象棋的提示词，在opencode里面按F2把模型全部换成qwen 27B Q5KM.
(我想让它们共享同一个上下文）
这个配置开局显存就只剩500M，突然有点后悔开视觉了。
在它跑到大概60%的时候，用了62.5K上下文了 ，速度已经从59T/S 掉到40T/S， 感觉这个Q5K 在3090上就只能跑10万左右的上下文，并且新建项目时 还不能用0.6的温度，用0.63或者高一点（但是高温写出来的程序大多数有BUG）。。。。中间过程会有英文穿插，这是正常的，正是v20那个模板文件发挥了作用，让IDE可以toolcall和模型交互，这可以节省token.本地显卡也要节省token，否则上下文爆炸会变卡。
-
综合这么多天的实践，我最终留了 两套配置：
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
经过几次调整参数和修改策略，勉强跑到这个程度。 其中我在60%上下文的时候应该寻找时机压缩一次的。 opencode不像hermes那样有自动压缩机制。 现在压缩一下看能不能救回来