1. 从一次压测翻车说起SGLang HiCache解决的到底是什么难题前阵子我帮朋友搭一套本地大模型服务机器是双卡RTX 4090但没有NVLink桥接。我心想双卡跑个8B模型不是绰绰有余直接上了SGLang的TP2结果一压测多轮对话场景吞吐反而比单卡还慢。查了半天日志最后所有的矛头都指向两件事一是前缀缓存的命中率没有被打满大量重复的system prompt和上下文在反复计算二是没有NVLink时张量并行每一层都要跨卡通信通信开销直接把并行收益吃了大半。这个踩坑过程让我把SGLang的前缀缓存机制、HiCache这类缓存优化实践、以及No-NVLink环境下的部署选型彻底摸了一遍。网上聊SGLang和vLLM对比的文章很多但很少有人把缓存命中率、Cache块调度、无NVLink通信代价这些点串起来讲。这篇就把我自己的实测经验和排障记录整理出来给正在对比vLLM、SGLang、Ollama、LM Studio或者准备离线部署Qwen系列模型的朋友做个参考。1.1 推理引擎混战为什么SGLang值得单独拿出来讲先说个背景判断。现在开源模型推理框架里第一梯队基本是vLLM、SGLang第二梯队是Ollama、LM Studio这类面向端侧的封装产品。vLLM靠PagedAttention解决了KV Cache显存碎片问题生态最成熟企业里用得最多。Ollama把llama.cpp封装成了傻瓜式体验Mac和Windows桌面用户随手就能跑。LM Studio更极致图形界面点一点就能加载模型适合完全不想碰命令行的新手。SGLang的立身之本却不太一样。它最强的不是显存管理而是RadixAttention——一个基于基数树Radix Tree的共享前缀缓存引擎。传统推理框架里每个请求的KV Cache都是独立计算、独立保存的哪怕两个用户发完全一样的system prompt也得各算一遍。SGLang把公共前缀包括角色设定、历史对话、工具调用格式等的KV Cache挂到一棵共享树上后续请求只要算增量部分长上下文场景下收益极其明显。正因如此SGLang在高并发Chat场景、多轮Agent对话、长文档问答这类任务上经常能跑出比同配置vLLM更好的尾延迟和吞吐。这也是我为什么在本地部署Qwen3-8B时首选它来测HiCache相关优化。1.2 HiCache是个独立软件包吗把它当成一套缓存优化实践来看先说结论在我的理解里HiCache并不是一个像transformers那样可以单独pip install的独立库而是围绕SGLang缓存链路的一系列优化思路和配置组合。社区里聊到HiCache基本都指向同一个目标——提高前缀缓存命中率减少KV Cache的重复计算和无效占用。拆开看这套实践至少涉及四个层面。第一Cache块的粒度与组织方式粒度太大会造成尾部空间浪费粒度太小则索引开销高。第二缓存淘汰策略Radix树上的节点该优先保留哪些不能单纯按先来先服务。第三调度层面的重叠感知多个并发请求共享部分前缀时调度器能否把它们合并到同一批计算真正做到一次计算、多处复用。第四KV Cache的层级安置热数据留在显存温数据放在CPU内存冷数据落到磁盘才能支撑超长上下文而不爆显存。这篇文章里我把上述缓存链路相关的部署配置和调优经验统一称为HiCache实践。它不是某个魔法开关而是一连串参数的合理搭配。理解了这一点后面看命令和配置就顺了。2. 从RadixAttention到HiCache前缀缓存原理解剖与优化抓手2.1 先弄懂一个朴素问题为什么重复的上下文非要重复计算为了更好地理解前缀缓存我常用一个图书馆的例子来类比。假设有一本特别厚的教程很多学生都只读前300页如果每个学生来了都复印一遍前300页图书管理员早疯了。合理的做法是准备几本公共样书放在架子上谁需要谁借走没必要人手一本。传统推理引擎的KV Cache就像是每个学生复印一份。每一次新请求进来模型都要重新过一遍整段文本把历史和新增内容全部计算一遍哪怕系统提示一字不差。SGLang的RadixAttention则把KV Cache组织成公共书架请求进来了先在前缀树上找到自己能复用的最长公共前缀只计算新增的那一小段然后挂在树的新节点上。多轮对话是收益最大的场景。第一轮用户说了“你好”第二轮说“帮我写个方案”第二轮请求的输入等于第一轮的完整对话加上第二轮的新问题。如果不加缓存第二轮的prefill阶段要把第一轮的对话又全部算一遍。有了前缀缓存第二轮直接命中第一轮的KV Cache只需要算“帮我写个方案”这几个token的prefill首token延迟能降一个量级。2.2 HiCache优化的关键抓手命中率、块粒度、淘汰策略前缀缓存的原理不难难的是把它做到高命中。我实际调整过程中主要盯几个指标和参数。第一个抓手是命中率观测。SGLang服务启动后日志里会输出类似Cache hit rate: 87.5%或者token数统计。你多轮压测时如果发现命中率只有40%左右基本可以断定前缀没对齐往往是因为请求里混入了时间戳、随机ID这类每次都会变的内容导致公共前缀被截断。这个坑在后面问题排查里非常典型。第二个抓手是Cache块的大小。SGLang的Radix树底层是分块管理的块太大长上下文的尾部碎片浪费多块太小树的节点数量爆炸、索引和引用计数开销上去。我实测下来如果是Qwen3-8B这类85亿参数模型上下文长度控制在8K附近默认的块配置通常就够不一定要硬调。但如果你做的是32K甚至128K超长文本问答就需要重点关注块粒度和总token上限。第三个抓手是淘汰策略。显存是有限的要保证长上下文不OOM旧节点必须被逐出。简单LRU的缺陷在于某个节点虽然被访问过多次但如果它的下一级分支太短、复用价值不高保留它不如保留一个高价值长分支。在实际项目里可以通过观察服务日志里被驱逐的节点数量来反推当前缓存策略是否适合你的业务流量模型。2.3 常用参数速览不是越多越好关键是匹配业务SGLang的启动参数非常多但和HiCache直接相关的核心参数就那么几个。我做了一张速查表版本差异请以python -m sglang.launch_server --help为准参数作用我的建议值--enable-prefix-caching开启前置缓存部分新版本默认开启旧版本需显式加上一直开--chunked-prefill-size把长prefill拆成固定块避免一个长请求独占GPU算力512或1024视显存而定--mem-fraction-static预留给模型权重和KV Cache的静态显存比例0.80~0.88别超过0.9--max-total-token-num服务端允许的KV Cache最大token总数按显存余量换算保守为主--schedule-policy请求调度策略影响合并批次和前缀重叠度默认即可大部分场景不用改提示--mem-fraction-static给高了多并发时容易OOM给低了缓存空间不足命中率上不去。正确做法是先用一个典型请求压一遍观察显存峰值再反向微调。有朋友问我这些参数是不是全部拉满就最好。真不是。SGLang的调度器很聪明只要你开了前缀缓存它会自动把同前缀请求尽量放同一批计算。你把调度参数改激进反而可能导致小批次变多、kernel启动开销变大。我先用默认参数跑出基线再一个个调每次只动一个变量这是最稳妥的。3. 无NVLink到底影响多大多卡部署前必须想清楚的事3.1 没有NVLinkGPU之间靠什么交流NVLink是NVIDIA的GPU高速直连总线消费级卡比如RTX 4090并不会标配很多人的双卡机器其实就是PCIe直连甚至通过主板的PCIe Switch中转。PCIe 4.0 x16单方向带宽约32GB/s双向理论值能到64GB/s左右但NVLink 4.0的单卡互联带宽能到900GB/s的量级差距一个数量级还多而且NVLink延迟更低、CPU不参与数据搬运。这个差距在单卡场景没有任何影响模型权重和KV Cache都留在本卡显存里。但一旦你用TP张量并行把模型切开扔到两张卡上每一个Transformer层的前向计算都涉及跨卡同步AllReduce和AllGather操作会非常频繁这时候互联带宽就变成了实打实的瓶颈。我打个比方TP等于两个店员合抄一本书一个抄前半部分一个抄后半部分但每隔几行就得对一下答案。NVLink是俩人坐隔壁直接递小纸条PCIe是俩人通过前台传话后者当然慢得多而且传话次数一多效率甚至不如一个人从头抄到尾。3.2 哪种并行方式最怕没有NVLinkSGLang支持多种并行但它们对通信的需求差异巨大。TP张量并行最怕无NVLink。因为它是模型层面的矩阵切开每一层都要做跨卡通信8B模型就算只切成2份通信频率也非常高。我的实测结论是无NVLink双卡4090跑Qwen3-8BTP2的decode吞吐不仅没有翻倍反而比单卡低10%到30%具体跌幅取决于上下文长度和并发数。这也是文章开头那次压测翻车的根本原因。DP数据并行几乎不受NVLink影响。它把不同请求分配给不同GPU各算各的彼此之间没什么通信。如果你的并发请求本身很多DP是很稳的扩容方式每加一张卡近似线性增加吞吐。EP专家并行在MoE模型里很常见。Qwen3-8B是稠密模型不是MoE但如果你以后部署类似Qwen1.5-MoE这类模型EP中每个token都要做一次All-to-All把token路由到对应专家所在卡上通信量也不小无NVLink时同样会拖慢。PP流水线并行通信量相对小只在层边界传中间激活。但SGLang对PP的支持成熟度不如TP且它的显存利用效率不如TP均衡。非必要情况下我不太推荐无NVLink用户为了省显存强行上PP。3.3 无NVLink环境的正确选型策略基于这些实测结论我给三类人不同的方案。如果你的模型单卡能放下比如Qwen3-8B在24GB显存上完全够跑那就别折腾TP直接用单卡。最多开DP让多张卡各自处理不同用户请求把吞吐做上去。如果模型确实大比如70B量化后超过单卡显存无NVLink环境下优先考虑降低精度或者减少上下文长度尽量塞进单卡。实在塞不下再考虑TP2但要接受性能不如预期并且把--mem-fraction-static调高一点给KV Cache留足空间避免因为显存不足来回换页。如果未来要考虑更大模型我的建议是直接上带NVLink的专业卡或者干脆用单卡大显存。千万别在无NVLink消费卡集群上迷信“并行翻倍”你翻的可能不是倍是踩坑记录。4. 实操落地SGLang离线部署Qwen3-8B并开足HiCache优化4.1 离线模型准备把权重老老实实放本地既然要离线部署第一步就是准备好模型权重。Qwen3-8B可以从Hugging Face或ModelScope下载生产环境我更推荐ModelScope国内网络稳定下载速度有保障。# 安装ModelScope客户端 pip install modelscope # 下载Qwen3-8B到指定目录 modelscope download --model Qwen/Qwen3-8B --local_dir /data/models/Qwen3-8B下载完成后检查/data/models/Qwen3-8B目录里是否有config.json、model.safetensors、tokenizer.json这几个关键文件。SGLang启动时会根据config.json判断模型结构和参数配置如果没有这个文件后面会直接报错。注意如果目录里还带snapshots/子目录Hugging Face下载器容易生成这种结构启动时一定要指定到包含config.json的那一层不要指定到snapshots/xxx里面否则SGLang可能因为路径层级问题找不到tokenizer文件。4.2 环境安装Python版本和CUDA版本一定要对齐SGLang对环境的依赖主要看PyTorch。我的建议是用conda单独建环境别把系统Python搞乱。conda create -n sglang python3.10 -y conda activate sglang pip install --upgrade pip pip install sglang[all]如果你事先已经有PyTorch且版本匹配也可以指定--extra-index-url来安装。安装完用python -m sglang.launch_server --help验证一下能否正常输出参数列表能输出说明核心模块装好了。安装版本最好直接拉官方最新的稳定版SGLang迭代非常快旧版本和新版本之间参数名有时会变。我之前用0.3.x的文档习惯去跑0.4.x的server发现--enable-prefix-caching在部分版本已经默认开启重复传也不会报错但日志输出格式变了差点以为是bug。4.3 启动服务把HiCache相关优化全部加进去离线部署最关键的一步就是启动服务。下面这条命令是我在无NVLink双卡机器上最终确定的生产级启动方式python -m sglang.launch_server \ --model-path /data/models/Qwen3-8B \ --host 0.0.0.0 \ --port 8000 \ --tp-size 1 \ --mem-fraction-static 0.85 \ --enable-prefix-caching \ --chunked-prefill-size 512 \ --max-total-token-num 32768逐个参数说下意图。--tp-size 1是我踩过坑后才加上的因为没有NVLinkTP2反而更慢单卡部署配合DP才是最优解。--mem-fraction-static 0.85表示给模型权重和KV Cache预留85%的静态显存剩下15%留给激活值和临时张量不容易OOM。--enable-prefix-caching是显式开启Radix前缀缓存这是HiCache实践的基石。--chunked-prefill-size 512把长请求的prefill阶段切成512 token的小块避免一个超长请求独占GPU太久其他请求排队干等。--max-total-token-num 32768是服务端KV Cache的容量上限超过这个量旧的缓存节点会被淘汰。启动成功后终端会打印模型信息、显存占用、以及类似Cache hit rate的初始统计。看到server is running字样说明服务起来了。4.4 客户端测试用OpenAI兼容接口验证SGLang提供OpenAI兼容接口这意味着你之前写的任何基于OpenAI SDK的应用都可以把base_url指过来切换成本极低。先用curl做一个最简单的冒烟测试curl http://localhost:8000/v1/chat/completions \ -H Content-Type: application/json \ -d { model: Qwen3-8B, messages: [{role: user, content: 你好请介绍一下你自己}] }正常会返回一段JSON里面包含choices[0].message.content。如果curl卡住没响应多半是模型加载还没完成等日志稳定后再试。Python侧的测试更接近真实场景from openai import OpenAI client OpenAI( base_urlhttp://localhost:8000/v1, api_keyEMPTY ) system_prompt 你是一个资深AI架构师回答问题时请保持简洁准确。 messages [ {role: system, content: system_prompt}, {role: user, content: 请解释什么是KV Cache} ] resp client.chat.completions.create( modelQwen3-8B, messagesmessages, max_tokens1024, temperature0.3 ) print(resp.choices[0].message.content)注意这里api_key随便填一个就行SGLang不会校验但OpenAI SDK要求这个字段不能为空。模型名不一定要严格匹配SGLang默认会把你传的model字符串映射到已加载的模型。4.5 实测HiCache优化效果同样的请求差距在哪里为了验证缓存是否真的生效我做了一个对照实验。第一轮我用完全相同的system_prompt连续发起20轮对话每次追加一个新问题。开启--enable-prefix-caching后从第二轮开始历史对话的KV Cache全部命中服务日志里的Cache hit rate稳定在90%以上每轮的首token平均延迟明显下降。第二轮我把system_prompt稍微改了一个字比如末尾加个空行命中率直接跌到30%以下。这个实验很有说服力前缀缓存对输入的一致性极其敏感任何动态变化都会把公共前缀截断。5. 常见问题与排障实录把这些坑提前埋掉5.1 高频问题速查表我把实际遇到过的问题整理成了一个速查表方便对照排查症状可能原因解决方案请求全部超时log无响应模型还在加载或模型路径错误等日志出现server is running检查路径层级显存OOM--mem-fraction-static过高降到0.75~0.80或减少--max-total-token-numTP2反而比单卡慢无NVLinkTP通信开销大于收益改为TP1或用DP承载并发前缀缓存命中率极低请求里混入动态字段断开了公共前缀统一固定system prompt不拼时间戳抓请求日志看前缀差异无法连接8000端口服务没起来或防火墙拦截确认host为0.0.0.0检查端口占用加载量化模型报错量化格式与SGLang版本不兼容按官方文档安装对应的量化kernel或改用非量化权重5.2 一个值得展开的排查案例命中率上不去的真凶有一次我把所有参数都调到位了但缓存命中率始终只有50%左右。抓了请求日志仔细看才发现所有用户请求里的system_prompt结尾都被我拼上了一个带时间戳的字符串。这个时间戳每次请求都在变导致Radix树上的公共前缀在最后一个字符处断掉以前积累的缓存全成了孤儿节点。这个问题在真实业务里非常常见很多人开着前缀缓存却没有意识到日志、监控、风控这些中间件会给prompt加动态内容。排查方法很简单把线上真实请求打出来对齐前几十个token的哈希值差异出现的地方就是缓存断裂的位置。修复方式是把动态字段从公共前缀区挪到用户消息区而不是拼在system prompt里。5.3 性能调优清单我每次上线前都会过一遍最后给一份我个人在上线前必查的清单。第一确认前缀缓存开启。旧版本需要显式加--enable-prefix-caching新版本即使默认开启我也会确认日志中有相关配置输出。第二确认并行方式匹配硬件。无NVLink机器一律TP1并发量大时考虑DP。第三确认模型路径没有多嵌套一层否则离线部署时反复加载失败消耗大量时间。第四确认--chunked-prefill-size不要设成0否则一个长prefill会阻塞调度。第五确认观测指标完整至少知道当前Cache hit rate和显存余量这两个指标能帮你判断后续扩容方向。6. 最后分享几点真实体会折腾完这一轮SGLang加HiCache相关的优化我最深的感受是推理框架的性能瓶颈往往不在框架本身而在你有没有搞清楚自己的流量特征和硬件约束。无NVLink的机器就别硬上TP短上下文的场景就不要为超长缓存浪费显存多轮对话多的业务一定要把前缀缓存命中率当成核心指标来盯。HiCache这类的缓存优化不是装上就能躺赢而是需要你用真实流量反复打磨的。如果在部署过程中发现命中率上不去我建议先从请求输入的一致性入手这一步解决了后面很多性能问题会迎刃而解。