SGLang GPU 利用率优化：量化、批处理与多卡并行的 6 个实战场景

SGLang GPU 利用率优化：量化、批处理与多卡并行的 6 个实战场景

【免费下载链接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.项目地址: https://gitcode.com/GitHub_Trending/sg/sglang

用 SGLang 部署 LLM 推理服务时，GPU 经常"半闲置"：利用率上不去，请求排队，KV 缓存占着显存却被反复回收。本文给出一条最短的跑通路径，再按单卡、多卡、长文本、高并发四个场景逐个拆解该动哪些参数，最后附参数速查表和常见报错的处置方法。

🚀 5 分钟跑通一个推理服务

先建立信心：一条命令起服务，一条命令发请求。

pip install --upgrade pip pip install -e "python" # 在仓库根目录执行；或 pip install sglang python3 -m sglang.launch_server --model-path qwen/qwen2.5-0.5b-instruct --host 0.0.0.0 --port 30000

执行后应看到终端打印The server is fired up and ready to roll!，表示服务就绪。另开终端向http://127.0.0.1:30000/generate发一条 POST 请求（body 里放一个text字段），返回包含生成内容的 JSON 就算验证通过。

小模型、低负载时利用率数据没什么参考价值，真正的优化空间在下面的四个场景里。

💾 单卡省显存：把权重和 KV 缓存都压小

单卡场景的核心矛盾是显存不够分：模型权重、KV 缓存、激活值要共用一块显存。两件事最有用。

权重量化。优先选离线量化好的现成权重（GPTQ、AWQ、FP8 检查点），加载时 SGLang 会自动读取模型配置里的量化信息，不需要额外参数：

python3 -m sglang.launch_server \ --model-path <你的AWQ或FP8检查点> \ --port 30000

只有当你手里只有高精度原始权重时，才用--quantization fp8做在线量化，让 SGLang 在加载时动态计算缩放因子。注意：已经量化的检查点不要再加--quantization，两者叠加会出错。

KV 缓存量化。给--kv-cache-dtype fp8_e4m3加一个参数，KV 缓存体积直接减半，同显存下能多跑一倍长度的上下文。代价是精度有轻微损失，长文本任务建议先对比几组输出再决定是否开启。

验证方法：启动日志里找max_total_num_tokens这一行，它代表 KV 缓存池能容纳的 token 总量。量化前后对比这个数字，涨了多少就说明并发能力多了多少。

🖥️ 多卡并行怎么配

先分清两种并行：TP（张量并行）是把一个模型拆到多张卡上算，解决"单卡装不下"；DP（数据并行）是每个 worker 各跑一份完整模型，解决"单卡装得下但吞吐不够"。

• 模型显存超过单卡容量 → 上 TP，--tp 2、--tp 4逐档往上加；
• 模型能装进单卡 → 优先 DP，内存充裕时吞吐明显更好；
• MoE 模型 → 再加专家并行--ep-size，让不同卡承载不同专家，配合--moe-runner-backend triton使用。

# 装不下：张量并行 python3 -m sglang.launch_server --model-path <模型> --tp 4 --port 30000 # 装得下：数据并行，配合网关做负载均衡 python3 -m sglang_router.launch_server --model-path <模型> --dp 4 --port 30000

执行后应看到每卡显存占用大致均衡。验证方法：nvidia-smi里各卡利用率差值小于 20%，说明切分合理；某张卡明显偏低，通常说明 TP 切法或路由有问题。

📄 长文本：别让一次 prefill 把显存打爆

长 prompt 的请求在进入 decode 前会先做一次性 prefill，token 数越多，这一瞬的激活值越大，OOM 最常发生在这里。

对策是把 prefill 切成小块：

python3 -m sglang.launch_server --model-path <模型> \ --chunked-prefill-size 4096 --mem-fraction-static 0.85 --port 30000

--chunked-prefill-size限制单个 prefill 块的 token 数，OOM 时从 8192 往 4096、2048 降。代价是长 prompt 的首 token 延迟略升，但换来的是稳定。

--mem-fraction-static决定"权重 + KV 缓存池"占显存的比例（公式：(权重+KV池)/显存总量）。官方调法：看启动日志里available_gpu_mem——落在 5~8 GB 区间说明分配合适；剩 10 GB 以上就往上加 0.01；剩得太少则往下调，防止后面 OOM。

⚡ 高并发：让调度器别"留手"

请求密集到达时，有两个参数直接决定吞吐。

--schedule-conservativeness（默认 1.0）控制调度器敢不敢继续收新请求：

• 日志里token usage长期低于 0.9、且#queue-req > 0→ 调度器太保守，降到 0.3；
• 反复出现KV cache pool is full. Retract requests.→ 太激进，升到 1.3。偶尔出现（约每分钟一次）属正常。

--max-running-requests是同时在跑的请求上限。decode 阶段 OOM 时优先降它，比降mem-fraction-static损失小。

调参结束后建议压测一轮，确认gen throughput (token/s)和token usage都达到预期再上线。

📊 关键参数速查表

注意力后端不用死记：不指定时 SGLang 会按硬件和模型结构自动挑最快的。需要 MLA 或滑窗注意力时再按 docs/docs/advanced_features/attention_backend.mdx 的支持矩阵显式指定。

🛠️ 高频报错与处置

🎯 落地建议

个人开发机：小模型 + 全默认参数跑通即可，别过早调参；要省显存就加--kv-cache-dtype fp8_e4m3。

小团队：固定一条基线命令（模型路径 +--mem-fraction-static 0.85+--enable-metrics），之后只允许一次动一个参数并记录吞吐变化，避免多人同时改配置互相干扰。

生产环境：必开--enable-metrics，接上 examples/monitoring 里现成的 Prometheus + Grafana 栈（cd examples/monitoring && docker compose up即可），盯住 token usage、队列长度和 GPU 利用率三条曲线，按上表的阈值做增减。

延伸阅读：量化方法全表见 docs/docs/advanced_features/quantization.mdx，调参判断依据（日志怎么看）见 docs/docs/advanced_features/hyperparameter_tuning.mdx。

今天就先做一件事：把你当前服务启动命令里加上--enable-metrics，用curl http://127.0.0.1:30000/metrics拉一次指标，对照上表把token usage和#queue-req两个数字记下来，这就是你下一步调参的起点。

【免费下载链接】sglangSGLang is a high-performance serving framework for large language models and multimodal models.项目地址: https://gitcode.com/GitHub_Trending/sg/sglang