张量分割 8-14 测试 genesis V7 64G内存 48G显存 视觉塔放在第2张卡 实际参数只使用top-k 20之前的，hermes自己会处理循环     
  sudo nvidia-smi -i 0,1 -pl 260 
  sudo prlimit --memlock=unlimited:unlimited --pid $$
killall llama-server 2>/dev/null; sleep 3
export GGML_CUDA_GRAPH_OPT=1
export MTMD_BACKEND_DEVICE=CUDA1 
export LD_LIBRARY_PATH=/s1/llama.cpp/buun-llama722/build/bin/:$LD_LIBRARY_PATH
/s1/llama.cpp/buun-llama722/build/bin/llama-server \
  --device CUDA0,CUDA1  --split-mode tensor   -ngl 999 \
  --api-key 'sk-明天会发8888880' \
  -m /s1/Qwen3.6-35B-A3B-Uncensored-Genesis-Hermes-V7.gguf \
  --mmproj /n1/mmproj-Hermes3.6-35B-A3B-Uncensored-Genesis-F16.gguf \
  --image-min-tokens 1024 --image-max-tokens 4096 \
  --props --ctx-checkpoints 64 \
  -fa on --metrics --fit off -c 262144 -n 10240 \
  -ct vbr --vbr-floor t8 --kv-unified -t 6 -tb 8 \
  --jinja --no-mmap --mlock -np 2 -b 8192 -ub 2048 \
  --chat-template-file /s1/qwen3.6-27b-gguf/apex-qwen-chat-template.jinja \
  --host 0.0.0.0 --port 8025 --reasoning-preserve \
  --reasoning off --cache-ram 26384 \
  --chat-template-kwargs '{"preserve_thinking":true}' \
  --reasoning-format deepseek --reasoning-budget 1024 \
  --temp 0.6 --top-p 0.95 --top-k 20 
--min-p 0.05  --repeat-penalty 1.08   --repeat-last-n 64
--min-p 0.05及之后的参数加了个人觉得会变慢，测试时就没有使用。

两张卡都限制260W功率，再高没意义，计算核心跑不起来。
K V CACHE试了turbo8 q8_0 都不理想，那只能用 buun特有的vbr了，它的大概思路 是k v cache 先用F16，如果显存不足再降低量化等级
用--vbr-floor t8开关将最低K V CACHE限制在q8级别。
（实际上，我的配置在跑起来的时候只用了33G左右的显存，理论上F16管饱） 。

以下测试复刻超级玛丽HTML5游戏（只写3关）：
hermes花了40分钟，写出来的是废品，画面拉胯，无法操作。改用trae

用trae 10分钟就完成初版了,耗费70多K token：

修BUG：

最后是tooleval 跑分，加回去审查导致的安全扣2分，至少应该得90分，单从它这个跑分来看的话，和我之前单卡常用的iq4_nl_xl GGUF（历史最高96分,150k上下文）还有一定的距离。

但实际今天测试hermes的话，体感也没有差别。而且双卡配置的上下文占据绝对优势。

总结与反思：目前配置超过131K上下文，会出现checkpoint耗尽（64个X62MB= 4GB内存，该分支只支持 64 个checkpoint，耗尽之后，旧的片段需要重算，浪费算力与时间）,对话里面看起来就是反应迟钝,目前的解决方案是将hermes的压缩阈值配置为0.49（大约129K），压缩目标配置为0.2。 反思一下： 与其设置一个不实用的262K上下文，不如尝试设置3-4个152K上下文，然后在上下文快耗尽的时候 重开会话。