抡锤者

20 分钟不正常。按你说的 pp 约 850 t/s，就算 184K 全量 prefill 也只 3.6 分钟左右；多出来的十几分钟基本可以断定是 KV 池装不下之后在重算/腾挪，不是正常「压缩」。 先算 KV 占用：每 token 约等于 2 × 层数 × KV 头数 × head_dim × dtype 字节。以 64 层 / 8 KV 头 / 128 dim / fp16 估，约 0.25 MB/token，184K 就是约 46 GB——单张 32G 根本放不下。AWQ 省的是权重（约 17G），KV 一点没省。所以你看到的「压缩」大概率是 SGLang 的 preemption/retract（把请求踢出去重算）或 HiCache 往 host 内存/SSD 搬，两者都会让延迟爆炸。 三个动作： KV 量化：--kv-cache-dtype fp8_e5m2 或 fp8_e4m3（gfx1201 支持 FP8），KV 直接砍半。 别硬顶 184K：把 --context-length 设到 KV 池真装得下的档，先试 96K/128K，用 rocm-smi 看余量再往上加。 显存分配：--mem-fraction-static 别拉太满（0.85 上下），给 KV 留池；确实需要长上下文再开 --enable-hierarchical-cache 走 host 内存，但 decode 会掉。 还有一种可能：「压缩」是你前端/客户端在做历史摘要，那 20 分钟是那次摘要生成的时间，跟 SGLang 无关。这个先确认。 把启动命令、SGLang 版本、卡住前后的 server log（看有没有 retract/preempt/hicache 字样）和 rocm-smi 显存曲线发出来，我帮你定位是哪一种。

多谢锤哥。明天上机后第二张也设到250W 。

/home/lll/llama.cpp/build/bin/llama-server -m /home/lll/models/iq4xs/Qwen3.8-27B-IQ4_XS.gguf --mmproj /home/lll/models/iq4xs/mmproj-Qwen3.8-27B-f16.gguf --spec-type draft-mtp --spec-draft-model /home/lll/models/mtp-Qwen3.8-27B-Q4_0.gguf --spec-draft-n-max 2 -c 262144 -ngl 99 -ctk q8_0 -ctv q8_0 --port 8080 今天换到这个模型了，kvcache可以用q8。速度也快了一点点。41点多。 hermes chat里面本地聊天，还是比较跟手的，等待时间不算长。对了，思考换成low了。如果在电报里面用，感觉等得要久。不知道这个卡想要速度上到50以上有没有可能性。这个r9700, 在256K上下文前提下，质量和速度综合最好的27b量化模型，有大虾推荐吗？