SGLang HiCache 三层 KV 缓存实测：4090 48G 单卡跑通 Qwen3.8-27B 去审（256K + MTP + 视觉全占）
-
SGLang HiCache 三层 KV 缓存实测：4090 48G 单卡跑通 Qwen3.8-27B 去审（256K + MTP + 视觉全占）
看到坛里 32G Blackwell 用三层 KV 缓存跑 Qwen3.8-27B 的帖子，分享下我这边 4090 48G 的实测。48G 的余量正好把 MTP 投机 + HiCache 多会话复用 + 满 256K 上下文 + 去审 四样同时占全，不用二选一。已稳定跑生产十来天。
用途 / 工作流
这台 4090 上的去审大模型是整条视频生产线的大脑：
- 输入：黄易武侠小说《寻秦记》原文
- 4090（本机）：去审 Qwen3.8-27B 作为 agent，读小说→按叙述句细拆分镜→生成每段画面的提示词与音画同步脚本
- 4080 32G：跑 ComfyUI 的 MiniMax H3 去审工作流，按 4090 给的分镜逐段出视频
- 简言之：4090 指挥、4080 出片，全流程去审、长上下文（整部小说 + 分镜历史）常驻
正因为反复处理同一部小说的长上下文（大量共享前缀），HiCache 的前缀复用命中率才高得离谱（见下）。
硬件 & 模型
- GPU：RTX 4090 48GB（Ada 魔改，1008 GB/s）
- 主机：Ubuntu，系统内存 62GB
- 模型：Qwen3.8-27B-HERETIC 去审版 · FP8（compressed-tensors，~30GB）
- HuggingFace：https://huggingface.co/OptimizeLLM/Qwen3.8-27B-heretic-MTP-FP8
- 架构：Dense 稠密（非 MoE）+ 混合注意力（48 linear/GDN + 16 full）+ 原生视觉 VL
- 引擎：SGLang 0.5.17
HiCache 三层 KV 缓存
层 内容 容量 L1 GPU（热） fp8 KV，显存 270,278 token（~8.6G） L2 主机内存（温） --hicache-size 24504,447 token（24G） L3 NVMe（冷） 未启用（纯内存，足够用） — - 上下文窗口：256K（
--context-length 262144），KV 池 270K 保满 262K 有余 - 写策略：
write_through；io-backendkernel+ mem-layoutpage_first
性能实测
- 吞吐：thinking-off ~63–76 tok/s（峰 76）；thinking-on ~35–47 tok/s
- MTP 投机：链式 NEXTN 工作正常，accept len 3.8–4.2（no_think）
- 前缀缓存命中率：~88.5%（累计 prompt 3000 万+ token，命中占八九成）
- L2 内存池：503,430 / 504,447 ≈ 99.8% 满（小说前缀被反复复用，LRU 淘汰）
- 前缀复用提速：命中时首 token 冷 2.6s → 暖 0.67s（快 ~75%），17 万 token 长前缀单次直接命中免重算
稳定性 / 运行时长
- 当前配置（去审 FP8 + hicache 24G）：连续 ~20 小时零崩溃，已服务 3000 万+ token
- 去审 Qwen3.8 生产线：~11 天，端点对各 agent 一直在线
- 主机连续开机：2 周 4 天
启动参数
python -m sglang.launch_server \ --model-path /data/qwen3.8-27b-heretic-fp8 --served-model-name 4090 --host 0.0.0.0 --port 8001 \ --context-length 262144 --max-running-requests 1 --mem-fraction-static 0.98 \ --kv-cache-dtype fp8_e4m3 \ --speculative-algorithm NEXTN --speculative-eagle-topk 1 --speculative-num-steps 5 --speculative-num-draft-tokens 6 \ --enable-hierarchical-cache --hicache-size 24 --hicache-write-policy write_through \ --reasoning-parser qwen3 --tool-call-parser qwen3_coder --trust-remote-code --sleep-on-idle几个踩坑 / 权衡
- HiCache 的真正价值是「多会话 KV 复用免 prefill」，不是跑更大上下文——我这种「反复喂同一部小说」的场景命中率 88.5%，省掉八九成重复 prefill，指挥出片的节奏快很多。
- FP8 权重大（30G）→ 树形投机与满 256K 不可兼得：所以用链式 NEXTN（
topk1/steps5/draft6），保满 262K；想上树形投机就得牺牲上下文。 --page-size必须为 1：page-size 64 与混合 mamba 模型 + hicache 不兼容，会 Segmentation fault 崩溃，别踩。- 内存成本：hicache 24G 常驻内存，多卡各开一份会把内存吃紧（我这边 4090 指挥 + 4080 出片同时跑，62G 内存 + swap 就满了），按机器内存量力而行。
小结
一台 4090 48G 当「导演」（去审长上下文 agent 读小说、拆分镜），一台 4080 32G 当「摄制组」（ComfyUI MiniMax H3 去审工作流出片）。4090 相比 32G 卡的最大不同：不用在速度（MTP）和会话持久（HiCache）之间二选一，还能同时保满 256K + 去审。三层 KV 缓存实测命中 ~88.5%，稳定跑生产已 ~11 天。同样搞长篇小说转视频的欢迎交流。
-
不明觉厉 我比较好奇的是你拆镜头的提示词是怎么实现的
-
不明觉厉 我比较好奇的是你拆镜头的提示词是怎么实现的
@zhenyu-huang
我把YouTube上做AI视频的视频教程链接发给他，让他自己下载视频，然后每秒截一帧，自己识别图片学习。
并且让他下载教程的音频，让他把音频转成文字，学习教程文字内容。
奇怪，没有人好奇黄易的《寻秦记》小说写的是什么吗？这个才是重点^-^ -
@zhenyu-huang
我把YouTube上做AI视频的视频教程链接发给他，让他自己下载视频，然后每秒截一帧，自己识别图片学习。
并且让他下载教程的音频，让他把音频转成文字，学习教程文字内容。
奇怪，没有人好奇黄易的《寻秦记》小说写的是什么吗？这个才是重点^-^@Michael-Zhou 有影片看看嗎？哈
非常好奇 -
@Michael-Zhou 有影片看看嗎？哈
非常好奇@CHIA-AN-YANG 生产出来的视频片段质量非常不稳定，片段之间人物面孔没办法保持一致，等我生产好了发给你鉴赏。
-
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 头寸的问题。
