先算 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 搬，两者都会让延迟爆炸。

三个动作：

1. KV 量化：--kv-cache-dtype fp8_e5m2 或 fp8_e4m3（gfx1201 支持 FP8），KV 直接砍半。
2. 别硬顶 184K：把 --context-length 设到 KV 池真装得下的档，先试 96K/128K，用 rocm-smi 看余量再往上加。
3. 显存分配：--mem-fraction-static 别拉太满（0.85 上下），给 KV 留池；确实需要长上下文再开 --enable-hierarchical-cache 走 host 内存，但 decode 会掉。

还有一种可能：「压缩」是你前端/客户端在做历史摘要，那 20 分钟是那次摘要生成的时间，跟 SGLang 无关。这个先确认。

把启动命令、SGLang 版本、卡住前后的 server log（看有没有 retract/preempt/hicache 字样）和 rocm-smi 显存曲线发出来，我帮你定位是哪一种。