[Install]
WantedBy=multi-user.target

 | 阶段            | 速度                    |                              
 |-----------------|-------------------------|                              
 | prompt 处理前期 | 1319 tok/s (16K tokens) |                              
 | prompt 处理中期 | 909 tok/s (49K tokens)  |                              
 | prompt 处理后期 | 577 tok/s (71K tokens)  |                              
 | 总 prompt 时间  | 123.87s / 71,419 tokens |                              
 | 生成速度        | 17.4 tok/s (稳定)       |

当前运行状态

 | 指标       | GPU 0          | GPU 1          |                           
 |------------|----------------|----------------|                           
 | 温度       | 64°C           | 66°C           |                           
 | 功耗       | 205W / 300W    | 193W / 300W    |                           
 | VRAM       | 27.67 GB (80%) | 27.04 GB (79%) |                           
 | GPU 利用率 | 100%           | 100%           |                           
 | SCLK       | 3366 MHz       | 2973 MHz       |                           
                                                                            
 - 进程 PID: 1016915，已运行 ~4h                                            
 - 模型文件: /home/gaopy/models/Qwen3.6-27B-Q4_K_M.gguf (约 16 GB)          
 - 生成速度: 实测 ~17-22 tok/s (当前 71K context 时 17.4 tok/s)

 | 项目     | 值                                         |                  
 |----------|--------------------------------------------|                  
 | GPU      | 2× AMD R9700 32GB (gfx1201, device 0x7551) |                  
 | 总显存   | 64 GB                                      |                  
 | ROCm     | 7.2.4 (AMD 官方 repo)                      |                  
 | PyTorch  | 2.10.0 + HIP 7.2.53211                     |                  
 | 系统内存 | 62 GB                                      |                  
 | OS       | Ubuntu, Linux 6.17.0-35                    |

1. KV cache量化是关键 — 27B Q4_K_M本身的模型权重约15GB（双R9700 32G刚好放下），但256K上下文的KV cache会吃掉大量显存。你可以在llama.cpp启动参数里加 --cache-type-k q4_0 和 --cache-type-v q4_0，把KV cache从默认的FP16压缩到Q4，KV cache显存占用直接降到1/4。配合 --no-kv-offload 把KV cache放到系统内存，模型权重独占显存，速度损失没有想象中那么大。

2. 双卡配置确认 — R9700实际就是W7900的变体，建议确认 --tensor-split 参数是否正确分配了负载。可以用 --verbose 启动看显存分配是否均衡。

3. 关于laobenxiong提到的关掉压缩 — 他说的有道理，Hermes的压缩用的是DeepSeek做摘要，确实会丢失细节。但关了压缩后，每次请求都要重新prefill完整的256K上下文，这是速度瓶颈的主要来源。你可以试试开prompt caching（llama.cpp的 --no-prompt-cache 默认是关闭kv缓存复用的）。

4. Batch size微调 — 试试 --ubatch-size 512 配合 --batch-size 2048，对长上下文场景的吞吐有帮助。

5. 另外双R9700跑27B 256K，速度不可能太快，这是物理限制——大概4-6 tok/s是正常的。如果追求响应速度，可以缩减到128K上下文，速度会翻倍。

@Brian 说:

即使是模型和hermes都设置256k上下文，herems还会触发压缩，最终效果还是很够用的

我现在把压缩关闭了. 首先压缩效果不一定好(我让hermes调deepseek v4 flash做压缩, 发现压缩以后好多信息都丢了), 另外, 压缩以后所有 prefill 要重建, 既花时间, 有没有啥信息含量. 所以干脆disable it. context 快到头了就 /new 一个, hermes自己记住所有的对话, 在新对话里提一下"我们以前/刚刚聊过xxx", 它自己就会从数据库里去找. 我赶脚这个比压缩还靠谱.