@flyer666 谢谢回复和指导。您这个思路很有道理,我这边同时跑着两个 Hermes 本地 AI Agent基本都是发散性任务,所以 fresh prefill 确实很多。
关于您的第一点建议:
我这边实测下来,感觉不只是 7900 XTX 的算力瓶颈。测试时先让 A 完成 64K prefill 并进入正常 decode,单路大约 80 tok/s。5 秒后再让 B 加入一个 64K fresh prefill,结果 A 会连续 47.2 秒完全没有 token 输出,也就是从约 80 tok/s 直接掉到 0,等 B 的 prefill 结束后才恢复正常.
这其实已经意味着,在我的实际 workload 下,长上下文双并发基本失败了:两路虽然都处于 running 状态,但第二路一做长 prefill,第一路几乎被冻结。更关键的是,当时 waiting=0,KV 使用率还不到 50%。后面我又分别关了 MTP、ROCm 7.2→10、chunk 4096→2048,结果 A 还是会停 45–54 秒,所以我更倾向这是 SGLang 的 long prefill / decode starvation,而不只是单纯算力不够。
[image: 0505b4d2-6d9b-463a-b857-bf052bbaa168.png]
关于您的第二点建议:
KV 我后来也调到了 265,950 tokens,C3 峰值才 62%,所以这次看起来也不像是 radix eviction。HiCache 我在5090 128G内存的另一台机器上上试过确实好用,但这台机器只有64G,而且还分了一半跑虚拟机,内存不够了,后面有机会加内存了我再试试。
我的部署基本完全让DSF按照您的帖子和推荐指南来的,但是我自己其实是个纯小白,所以现在也不敢百分之百确定是不是我这边某个配置还有问题。不过至少 SGLang 跑短上下文是真的香。刚开始测试的时候,会话很快,堪比DeepSeek Flash,四路并发也非常丝滑,所以一开始我其实挺惊喜的。只是上下文一长,特别是出现 fresh prefill 以后,实际体验就完全变了。我最近这一两个月学习到的东西比过去一年还多,CUDA,oneAPI,Level Zero,SYCL,OpenVINO,RCOm,Vulkan,llama.cpp, vLLM,SGLang这些遥远的名词居然也都亲自实践测试体验过了,在这个论坛真是大有收获了。
[image: db44ae7f-e56f-48a9-ad9d-2d4e6dea09aa.png]
再次感谢大神的分享和热心回复。以后还要继续抱大神大腿,少走弯路!