SGLang HiCache 三层 KV 缓存实测：4090 48G 单卡跑通 Qwen3.8-27B 去审（256K + MTP + 视觉全占）

[zhenyu huang]

不明觉厉 我比较好奇的是你拆镜头的提示词是怎么实现的

[Michael Zhou]

@zhenyu-huang
我把YouTube上做AI视频的视频教程链接发给他，让他自己下载视频，然后每秒截一帧，自己识别图片学习。
并且让他下载教程的音频，让他把音频转成文字，学习教程文字内容。
奇怪，没有人好奇黄易的《寻秦记》小说写的是什么吗？这个才是重点^-^

[CHIA AN YANG]

@Michael-Zhou 有影片看看嗎？哈
非常好奇

[Leon Y]

黄易的《寻秦记》小说, 穿越小说的开山鼻祖，有人没看过么？
还是我太老？

[terry]

@Leon-Y 你不老啊，大家只是怕暴露年龄。

[Michael Zhou]

@CHIA-AN-YANG 生产出来的视频片段质量非常不稳定，片段之间人物面孔没办法保持一致，等我生产好了发给你鉴赏。

[用户名违规]

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

[johnnybegood]

@Leon-Y 我还看大唐双龙传呢

[Xiaote]

0.98 不是"只留 2% 给 GEMM"，这里有个常见误解：SGLang 的 mem-fraction-static 是对权重占完以后剩下的显存再切池子——权重（FP8 约 30GB）是加载时单独占的，不在这 2% 里；GEMM/激活用的是瞬时 workspace，不需要预留给一整块。所以单并发 0.98 稳是正常的，不是运气。

双并发崩的原因也大概率不是"KV 池不够"——HiCache 池满了会 spill 到内存/SSD（L2/L3 就是干这个的），不该崩。真正吃余量的是每路并发请求的 CUDA graph buffer + 激活 workspace：SGLang 按请求形状捕获 graph，池子顶到 0.98 后没有空闲头寸给第二路，graph 捕获/分配失败就直接崩。而且楼主这条命令本来就写着 --max-running-requests 1，意思是按单路并发调的池子，你硬开双并发属于超设计运行。

对照实验站里就有：TID:1502 starryskyknight 双 3090 实测，mem-fraction 0.94 时 draft 的 CUDA graph 起不来，降到 0.90 立刻正常（并发冲到 249 t/s）。你从 0.98 降到 0.90~0.92 再开双并发试试，KV 池少的那点（HiCache 有 L2/L3 兜底）可以忽略；要是还崩，翻 sglang 日志找 "cuda graph capture failed" 或 "CUDA OOM" 关键字，能直接定位是不是 graph 头寸的问题。

[Michael Zhou]

@用户名违规 0.98确实太激进了，我现在改成0.96，上下文224K。