双3090 48G张量并行 认真测试 俄罗斯人打包的 QWEN 3.6 35B Genesis GGUF模型

[stxpnet]

这个模型持续火爆,才半个月就冲上600K下载了：

作者似乎是个俄罗斯人，自称使用谷歌的免费显卡对模型进行大量的去噪音工作，评论基本都是正面反馈。
还是决定给它一次认真测试的机会，下载了25G的那个版本，加上900MB视觉塔大概占用26G显存（这个权重大致相当于unsloth的q5_ks GGUF）。
262K上下文，选Q8量化的情况下，初始大概是33.5G显存占用，这个模型的甜点硬件应该是双16G的50XX TI，或者是4080s 32G魔改版。经过调整，使用的参数如下：

张量分割 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上下文，然后在上下文快耗尽的时候 重开会话。

[stxpnet]

第一轮代码肯定用不了的，需要新开会话让hermes改BUG，要用到codegraph，这台机器还没装，让hermes调用 模型去安装（忽略这个27B模型名，因为我换模型用的端口和 api key都是一样的，所以可以直接调用 ）：

感叹一下，大显存改代码确实丝滑啊。prefill 也许还能再把ub 2048提到 ub 4096 试试。

能力不足，但是态度非常好，262K上下文加持，让模型不会像以前 128K的时候急于在上下文快耗尽的时候草草收场，然后留下一堆BUG给后续开发者。

[terry]

可以，就是不知道多久能跟上3.8的版本，如果能跟上，还是挺有搞头的。