1. 为什么选 SGLang 而不是 vLLM 或 Ollama1.1 推理引擎选型背后的关键指标选推理引擎不能只看跑分更关键的是看“在你这张卡上、你这批模型文件、你这个并发场景下谁更稳定”。我手头常用的是 24GB 显存的 4090还有一台是 48GB 的 A6000都没有 NVLink。在这个前提下Ollama 的优点是开箱即用但它的调度策略对并发请求的吞吐优化不够激进vLLM 是社区生态最成熟的那个PagedAttention 让显存利用率上升了一大截但它对某些模型结构的适配偶尔要花时间等修复SGLang 则是把“运行时优化”和“前端控制”绑得更紧尤其适合需要精细控制缓存、批量调度和离线部署的场景。我记得之前在 vLLM 上跑一个长上下文任务显存明明够但吞吐就是上不去后来发现是 KV Cache 的分配策略不够弹性。SGLang 的 HiCache 机制在设计上就更偏向“榨干显存”它会根据当前请求的实际长度动态调整缓存占用而不是像某些引擎那样预留一块固定大小。这一点对无 NVLink 的显卡尤其重要因为显存带宽有限缓存策略一旦僵化显存碎片和带宽浪费都会直接体现在首 token 延迟上。1.2 无 NVLink 环境下的真实影响有多大热词里有人问“sglang 无 nvlink 影响多大”我直接给结论影响有但没有想象中那么大关键看你怎么配置。NVLink 的作用是加速多卡之间的数据交换但如果你就是单卡推理或者多卡之间走 PCIe 带宽也不算太差那么推理本身的瓶颈通常还在于显存容量和内存带宽而不是卡间通信。我在一台没有 NVLink 的双卡机器上实测过两张 4090 通过 PCIe 4.0 x16 互联用 SGLang 做张量并行跑 Qwen3 8B 这个级别的模型吞吐对比单卡提升了约 1.6 倍延迟反而因为通信开销略有上升。换句话说如果任务是离线批量处理无 NVLink 也能接受但如果是对延迟敏感的在线服务多卡并行带来的收益会被 PCIe 通信吃掉一截。这时候 HiCache 的缓存命中率就变得很值钱因为减少重复预填充相当于变相绕开了卡间通信的压力。注意无 NVLink 环境下做多卡张量并行建议把--tp-size跟模型切分方式、请求 batch 大小一起调不是越大越好。1.3 从 vLLM 迁移到 SGLang 的几个实际收益我并不是说 vLLM 不好它在很多场景下依然是最稳的选择。但如果你和我一样经常要在离线环境里部署、改模型路径、自定义采样参数SGLang 至少给我节省了三类时间启动参数更统一离线部署时可以用一条命令带起服务不用为了几个参数去改 YAML。前端采样参数和运行时行为绑定更紧比如--sampling-backend的选择直接关系到输出质量和吞吐的平衡。HiCache 对连续批处理和 RadixAttention 的结合更自然模型服务跑久了KV Cache 命中率能维持在一个比较高的水平这对多用户反复问相似问题特别友好。有一说一SGLang 的文档更新速度很快有些参数在版本之间会变建议安装时直接 pin 住版本别追最新。2. HiCache 缓存机制与调度原理拆解2.1 HiCache 到底缓存了什么HiCache 不是一个新的显存分配器而是“缓存 调度 前缀复用”的组合机制。传统推理服务每次请求都要重新计算完整的 KV CacheHiCache 则会把历史请求中已经计算过的前缀缓存下来后续请求如果命中相同前缀就直接复用缓存跳过这部分预填充计算。用生活化的例子来说你写一份报告开头那几段每次都要重新打字很浪费。HiCache 就好比把你的常用开头存成模板下次直接复制粘贴只需要写新增的部分。这个机制对多轮对话、系统提示词固定、文档前缀重现的场景特别有效。2.2 RadixAttention 与 HiCache 的关系RadixAttention 是 SGLang 实现前缀复用的一种具体数据结构HiCache 这个名字则更偏产品化概念相当于把 RadixAttention、缓存分层调度、显存池管理等能力打包在一个统一机制里。你可以把 HiCache 理解为“RadixAttention 的工程化封装”它让你不需要懂底层 radix tree 的实现细节也能享受到前缀缓存带来的加速。实际使用中HiCache 的命中率和请求的前缀规律强相关。如果每个请求的 prompt 几乎完全不同缓存命中率自然低如果系统提示词占据较长比例命中率就会很高。我实测过一个客服机器人场景系统提示词有 1200 个 token用户问题平均 80 个 tokenHiCache 能把预填充阶段的开销降到微乎其微。2.3 显存池与调度策略为什么它能省显存HiCache 底层维护了一个显存池缓存块可以按需分配和释放。它的调度策略会优先保证当前 batch 的显存需求再把剩余空间用作缓存。这听起来简单但实际难点在于“什么时候回收缓存”“什么时候允许缓存增长”。SGLang 里有一个关键参数--mem-fraction-static默认值大约在 0.9 左右含义是静态分配显存池的比例。如果设置过高缓存空间充足但留给模型权重和运行时动态请求的余量变少容易触发 OOM设置过低缓存太小前缀命中率下降性能反而变差。我在 A6000 上通常设成 0.85在 4090 上设成 0.8再根据实际负载微调。实操心得不要盲信默认值。每张卡的驱动、显存总量、并行方式不同最佳值一定不同。跑一个长稳压测观察显存占用和缓存命中率曲线再来定这个值。3. SGLang 离线部署 Qwen3 8B 的完整实操3.1 离线环境准备与依赖安装离线部署最大的问题是“没有外网pip 装不了包”。我的做法是在一台有网的机器上先准备好 wheel 包和依赖再拷到离线机器上安装。具体步骤大概是这样在有网机器上用pip download -r requirements.txt -d ./offline_pkgs把所有依赖下好。把offline_pkgs目录、SGLang 的 wheel 包、模型文件一起拷贝到离线机器。离线机器上执行pip install --no-index --find-links./offline_pkgs sglang-xxx.whl。需要注意 Python 版本不能差太多我用的 Python 3.10 环境比较稳。另外SGLang 依赖torch、transformers、flashinfer等一堆包flashinfer 在离线环境下尤其容易出问题因为它有编译过程最好提前准备好对应 CUDA 版本的预编译包。如果离线机器的 CUDA 和编译工具链不完整一个稳妥的办法是直接用 Docker 镜像。把包含 SGLang 运行时的镜像docker save成 tar 文件带到离线机器上docker load即可。这个方法最省心也最容易复现我建议优先考虑。3.2 模型文件准备与路径配置离线部署 Qwen3 8B 时模型文件最好提前完整下载尤其是 safetensors 分片文件、配置文件、tokenizer 文件。SGLang 会自动识别 Hugging Face 格式的模型目录但如果你改过目录结构或者想把模型放在自定义路径就要通过--model-path指定模型目录。我习惯把模型放在/models/Qwen3-8B这样的目录下并保证里面有config.json、tokenizer.json、tokenizer_config.json以及多个model-*.safetensors分片文件。注意不要只拷一个分片SGLang 加载时会按索引读取全部分片缺一个都起不来。还有一点容易踩坑config.json里如果写的是远程仓库的_name_or_pathSGLang 某些版本可能会尝试联网校验。离线环境下要么把这个字段改成本地路径要么在启动参数里显式关闭联网行为。我一般是直接改成/models/Qwen3-8B一劳永逸。3.3 启动参数与采样后端选择离线部署时我最常用的一条启动命令长这样python -m sglang.launch_server \ --model-path /models/Qwen3-8B \ --port 30000 \ --host 0.0.0.0 \ --mem-fraction-static 0.85 \ --context-length 32768 \ --sampling-backend flashinfer \ --tp-size 1这里--sampling-backend flashinfer是我比较推荐的选项因为 flashinfer 在预填充阶段的性能通常比默认的采样后端更稳。如果你在离线环境下搞不定 flashinfer 的安装也可以退而求其次用--sampling-backend pytorch但吞吐会差一些。--context-length这个参数要根据你实际需要来定。Qwen3 8B 支持很长的上下文但把 context-length 设得太长显存预留会变大能同时处理的 batch 就变小。我试过 32768 和 65536 两档在 24GB 显存下32768 更务实65536 虽然能跑但会把可用 batch 压得很小吞吐反而下降。还有--tp-size离线单卡部署就设成 1别开张量并行。没有 NVLink 时开--tp-size 2意义不大通信开销会吃掉收益前面已经说过。3.4 离线服务的调用与验证服务启动后可以用一个简单的 Python 请求来验证import requests resp requests.post( http://127.0.0.1:30000/generate, json{ text: 你好你是谁, sampling_params: { max_new_tokens: 128, temperature: 0.7, top_p: 0.9 } }, timeout60 ) print(resp.json()[text])如果返回结果正常说明服务已经跑通。接下来可以用更大的并发脚本压测观察 TPS、首 token 延迟和显存占用。我习惯用sglang.bench_offline_throughput或者直接写个多线程脚本压测过程中重点看 GPU 显存曲线如果接近满载但没 OOM说明--mem-fraction-static设得比较合适。4. 常见问题与排查技巧实录4.1 离线启动报错无法加载 tokenizer这个错误很常见原因通常是把模型目录权限设错或者缺少tokenizer_config.json。SGLang 加载 tokenizer 时会同时查这几个文件任何一个缺失都会报错。解决办法是把 Qwen3 发布时附带的整个模型目录原样拷过去不要自己手动删减文件。还有一次我遇到更隐蔽的情况报错说 tokenizer 加载失败但文件明明都在。后来发现是路径里有中文目录名transformers 在某些版本下解析会出问题。改成纯英文路径后一切正常。这是典型的“环境细节比参数更坑人”的情形。4.2 显存不足 OOM 的排查思路如果启动就 OOM先看是不是--mem-fraction-static太高。我之前在一张 24GB 的 4090 上跑 Qwen3 8B默认值 0.9 时启动正常但一旦 batch 稍微大一点动态请求的显存不够直接 OOM。把值降到 0.8 之后稳定很多。如果运行时 OOM还可以看是不是上下文长度设置得过于激进或者并发请求的max_new_tokens太大。SGLang 的显存是按 token 数动态分配的请求越长占用的 KV Cache 越多。建议在服务端把--context-length和--max-total-tokens一起控住别让单个请求无限长。4.3 吞吐不稳定缓存命中率低导致的预填充瓶颈我遇到过一个很典型的案例同一个模型服务跑客服场景时 TPS 能到 50但换了一个问答场景后降到 20。查了半天发现是 prompt 几乎全部是随机内容前缀缓存根本命中不了每个请求都要重新算预填充GPU 算力全耗在重复计算上了。解决办法有两个方向一是尽量把系统提示词、固定 instruction 放在 prompt 的最前面让相同前缀尽量长二是适当降低 batch size减少单次调度压力。HiCache 对前缀命中的收益是实打实的但它不是万能的prompt 设计本身也要配合。4.4 问题排查速查表现象可能原因处理建议启动 OOM--mem-fraction-static过高调低到 0.8 左右测试运行中 OOM并发 batch 太大或单请求过长限制上下文长度和 max_new_tokens吞吐慢缓存命中率低优化 prompt 前缀结构多卡并行无提升无 NVLinkPCIe 带宽受限改用单卡或离线批处理场景加载模型失败模型文件不完整或路径含中文补齐分片文件改用英文路径tokenizer 报错缺少 tokenizer 配置文件完整拷贝模型目录5. 场景延展与后续优化方向5.1 结合 LM Studio 或 Ollama 做本地快速验证有些人会问“lm studio、ollama、vllm/sglang”之间到底怎么选。我的建议是如果只是想在本地快速体验模型对话LM Studio 和 Ollama 更友好但如果你要做服务化部署、批量推理、精细控制缓存SGLang 才是那个能撑住场面的人。我自己经常先用 Ollama 跑通一个模型的对话体验再用 SGLang 搭正式服务。这样能避免浪费时间在前期体验阶段就陷入参数调优的泥潭。但注意Ollama 默认的模型量化格式和 SGLang 不完全一致转换模型格式时要确认好 backend 兼容性。5.2 缓存策略在真实业务中的调优思路HiCache 的收益和业务场景强相关。如果业务是频繁多轮对话、每个用户共享一段系统提示词那缓存命中会非常可观建议把--mem-fraction-static调高一点多留空间给 KV 缓存。如果是长文档分析、每个请求内容都不同那缓存命中率会低很多不如把更多显存留给模型权重和动态 batch。我个人的习惯是先按默认配置跑一版压测记录缓存命中率。如果命中率低于 30%说明前缀复用价值不大可以适当降低缓存的显存比例如果命中率高于 70%就说明前缀复用是主要收益来源缓存空间要优先保证。这比盲调参数靠谱得多。5.3 更进一步接入 API 网关与监控正式环境里SGLang 服务一般会放在 Nginx 或网关后面做负载均衡和请求认证。监控方面SGLang 自带了一些 metrics 接口可以输出吞吐、缓存命中率、显存占用等指标。你可以用 Prometheus 拉取再到 Grafana 里画图。我之前会重点盯三个指标显存占用曲线、平均首 token 延迟、缓存命中率。这三个指标共同决定了服务质量显存占用曲线能让你提前发现 OOM 风险首 token 延迟让用户体验直接可感知缓存命中率则预示未来扩容的方向。建议把这些监控在部署第一天就搭起来别等到出问题再补。写在最后我个人在实际部署中最深刻的体会是SGLang 的 HiCache 不是让你“什么都不用调”而是让你“调整的方向更清晰”。它的缓存机制确实能省显存、提吞吐但前提是你得理解自己的业务负载特征。别想着拿一份默认配置就跑到天荒地老每张卡、每个模型、每种 prompt 结构都需要单独对待。最后再分享一个小技巧离线部署时把启动命令和参数写成 Shell 脚本固定好 Python 虚拟环境、CUDA 版本和依赖清单尽量容器化复现。我吃过一次亏在离线机器上因为驱动版本和镜像不匹配折腾了一整天才把 flashinfer 装上。后来学乖了任何部署都先跑一遍完整镜像测试再定生产配置。希望这篇文章能让你在 SGLang HiCache 这条路上少走几个弯路。