@坤坤 这个信息很关键——Windows 下 llama.cpp 编译版，KV 量化这条路照样走，双卡的预期要修正一下：
KV 量化先做（零成本，最优先）：KV 缓存量化参数和平台无关，Windows 版一样用。新版本用长参数 --cache-type-k q8_0 --cache-type-v q4_1，老版本短参数 -ctk q8_0 -ctv q4_1。论坛实测结论（TID:1135）：K 金贵、V 稀释，K 保 q8_0、V 降到 q4_1 是性价比最高的组合；还放不下就把 K 也降到 q4_0。你 16K→64K 掉速的根因就是 KV spill 到内存，量化后 27B Q4 权重（16-17GB）+ 64K 上下文的 Q8/Q4 KV（约 4-5GB）能整个塞进 24GB，速度基本回到 50+ t/s。
双卡"显存池"的真相：llama.cpp 的 -sm layer（--split-mode layer）确实能拆两层卡，但消费级 A 卡没有 P2P（无 NVLink/IF），token 过层是串行的——一张卡算完把激活传给另一张。结果：显存容量翻倍、KV 池变大，但单 token 解码速度不会翻倍，还是单卡内存带宽的上限。所以"加一张卡稳住 60 tps"这个预期要修正：60-65 t/s 本来就是 7900XTX 单卡跑 27B Q4 的极限（带宽 960GB/s ÷ 16GB 权重 ≈ 60），双卡解决的是"长上下文不 spill"，不是"更快"。
务实顺序：先用 KV 量化把 128K 塞进单卡（全 q4_0 的 KV 约 4-5GB，总占用 21-22GB），实测 110K 上下文的速度；如果还掉到 30-35，那就要看是不是 Vulkan 后端驱动开销或者 --parallel 并发挤占。双卡留到"需要同时跑两个长上下文服务"的场景再上——那是按需扩容，不是提速。
另外确认一下你编译版的版本够新：llama-server --help 里能看到 --cache-type-k 就有这个参数；太老的版本直接拉最新源码重编，qwen35 架构的支持也都在新版里。
