抡锤者

48G有问题呀，0.98 ，留给GEMM只有2%不会触发OOM？这都能稳定？唯一这里是单并发，我开双并发就用以崩。。难受。

我买的京东自营的，2年后卡坏了，。退钱。从新又买最新的卡。。。你看48G魔改其实算是一种福利。你这样想就不难过了。我是不是很会安慰人，你快夸夸我。。

hermes有自主学习的能力，后台会review导致 prefill 频繁，关掉就好了，或者有个小模型处理。

搜一下qwen fix 或者看我发的贴子

@applejuice 看日志啊，因为hermes 会10轮工具调用后，就要提取，就会抢占kvcache就出现了prefill的情况。因为慢。。所以会变慢，我是256K，200K做压缩，时间就比较长，就特别明显。。所以就曲线救国了，压缩就交给其他模型做了，丝滑得很。

@Wang-Wei 说:

namespace

你干啥了？我这边用的deepseek harness ，hermes ，codex，claude 都没问题。

Qwen3.8 模板问题，LLM 有模板的链接去看看，我发的。换个模板就没这么毛病了，qwen3.8的坑，没有适配其他前端框架，可能就他们自家的框架适配没问题吧。

问题解决。问题解决。问题解决。问题解决。

@terry ，不过找到原因了，hermes 会自动总结技能就会打断sglang的 kvcache缓存。。

@Che 二级缓存我已经开了，但是从来不落盘到 RAM，我都 emo 了。

你打开之后会正常落盘吗？我这边直接就是全量 Prefill，十分难受。

目前的 Docker Compose 配置如下：

services:
  sglang:
    image: lmsysorg/sglang:dev
    container_name: sglang-server
    restart: unless-stopped
    runtime: nvidia

    cap_add:
      - SYS_NICE
      - SYS_PTRACE

    environment:
      - NVIDIA_VISIBLE_DEVICES=0
      - CUDA_DEVICE_ORDER=PCI_BUS_ID
      - SGLANG_USE_IPC_POOL_HANDLE_CACHE=0
      - PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True
      - TZ=Asia/Shanghai

    volumes:
      - /mnt/x8/Qmodels:/models:ro
      - /mnt/480/docker/sglang/cache/torch_compile:/root/.cache/torch_compile
      - /mnt/480/docker/sglang/cache/flash_attn_cute_cache:/root/.cache/flash_attn_cute_cache

    command: >
      sglang serve
      --model-path /models/Qwen3.8-27B
      --host 0.0.0.0
      --port 30000
      --trust-remote-code
      --attention-backend flashinfer
      --mamba-backend flashinfer
      --max-mamba-cache-size 15
      --mamba-max-states-per-path 8
      --kv-cache-dtype fp8_e4m3
      --mem-fraction-static 0.94
      --max-running-requests 3
      --cuda-graph-bs-decode 1 2 3
      --num-continuous-decode-steps 4
      --prefill-max-requests 1
      --schedule-policy lpm
      --enable-session-radix-cache
      --tool-call-parser qwen3_coder
      --reasoning-parser qwen3
      --chunked-prefill-size 2048
      --max-prefill-tokens 2048
      --disable-prefill-cuda-graph
      --enable-fused-qk-norm-rope
      --enable-cudagraph-gc
      --log-level info
      --uvicorn-access-log-exclude-prefixes /
      --decode-log-interval 120
      --allow-auto-truncate
      --enable-cache-report

    # 删除 --linear-attn-backend triton
    # 其他参数保持不变

    shm_size: '16gb'
    network_mode: host

    logging:
      driver: json-file
      options:
        max-size: "100m"
        max-file: "3"

    # --enable-cache-report
    # --enable-hierarchical-cache
    # --hicache-ratio 2
    # --hicache-io-backend kernel
    # --hicache-mem-layout page_first
    # --hicache-write-policy write_through

之前尝试的二级缓存相关参数是：

--enable-hierarchical-cache
--hicache-ratio 2
--hicache-io-backend kernel
--hicache-mem-layout page_first
--hicache-write-policy write_through

但是实际运行时，二级缓存始终没有正常落到 RAM。再次请求时依然会进行全量 Prefill。

我看了一遍这些参数，暂时也没发现明显的问题。不知道是当前 sglang:dev 的问题，还是 Qwen3.8-27B、Mamba/FlashInfer 这套组合存在兼容性问题。

有正常使用 SGLang Hierarchical Cache 的朋友可以帮忙看看吗？尤其是开启之后，RAM 二级缓存是否能够正常命中？

@Che 明白人。弱弱问一下prefill在单用户容易全量prefill 这个咋解决呢？

你的卡全量prefill频繁吗？

Qwen开源的内容，并没有对所有客户端进行适配。。客户端的适配要靠各位自己，不是开箱即用。。Qwen团队可能专门留下的坑。。还是社区能人多。

社区里面有一个作者改进的模板实测有效。
https://huggingface.co/froggeric/Qwen-Fixed-Chat-Templates

4090D-48G-QWEN3.8-27B-SGLANG从0.5.15-0.5.17,速度是真快，显存占用也是真高。
唯独有一个问题，一个客户端，一个客户的情况下，超过70k后就容易prefill。
后面提一个问题就全量prefill。一次。。。默认是开启的缓存的。
这个问题一直没得到解决，甚至都去修改了prefill触发代码，想着改源码来解决这个频繁prefill的问题。。
结果很明显，没解决，所以想问问用sglang大家伙儿。你们是咋解决频繁prefill的？

根因：hermes 会后台运行，打断sglang kvcache前缀。导致前缀失效造成频繁prefill。
解决方法及其简单。

现在sglang最大的问题prefill很严重，一个用户对话，sglang最大上下文256k时候，超过70k后就开始频繁prefill。特别浪费时间，你有这个问题吗？解决没有？

deepseek harness+sglang+qwen3.8 他妈就是中国之光！没有之一。。。

最强的地方，居然是缓存命中率，做到99%的命中，太JB夸张了。
claude code ，codex，hermes，open code，Qwen这些智能体框架，最大的缺点就是在system+tools+ass的时候回破坏前缀。导致缓存失效。deepseek harness 感觉就是专门给sglang做适配的。缓存命中绝了。。基本是，没有prefill，只有要满200k上下文的时候prefill一下。。爽的批爆！！！工具也要干啥claude code啦！
如图

@wwcd2016 服务不鸟哦，这玩意儿有个毛病，可能是我还没找到解决办法，容易perfill。不知道是不是hermes 没命中到，导致的perfill 这个问题还不好排查

@terry 已经发布了呀，基本上调优了。docker拉最新的就行。启动参数要调整一下。