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 前会先做一次性 prefilltoken 数越多这一瞬的激活值越大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都达到预期再上线。 关键参数速查表参数推荐取值一句话作用--quantization fp8仅高精度原始权重时用加载时在线量化权重省显存--kv-cache-dtype fp8_e4m3长上下文场景开KV 缓存体积减半换更高并发--chunked-prefill-size4096OOM 时降到 2048把长 prefill 切块削平显存峰值--mem-fraction-static0.85 起步日志余量 5~8 GB 为准权重 KV 池的显存占比上限--max-running-requests按 decode 阶段余量下调限同时在跑的请求数--schedule-conservativeness0.3~1.3默认 1.0调度器收/放请求的松紧程度--tp单卡装不下才用张量并行拆分模型--dp单卡装得下时优先数据并行提吞吐--ep-sizeMoE 模型卡数整除专家并行分摊专家计算--attention-backend不指定由 SGLang 自动选选 FA3/FlashInfer/Triton 等注意力内核--enable-metrics生产环境必开暴露 Prometheus 指标注意力后端不用死记不指定时 SGLang 会按硬件和模型结构自动挑最快的。需要 MLA 或滑窗注意力时再按 docs/docs/advanced_features/attention_backend.mdx 的支持矩阵显式指定。️ 高频报错与处置现象处理动作OSError: CUDA_HOME environment variable is not set导出CUDA_HOME/usr/local/cuda-你的版本后重启prefill 阶段 OOM--chunked-prefill-size降到 4096/2048--mem-fraction-static降到 0.8decode 阶段 OOM降--max-running-requests再考虑降--mem-fraction-static加载量化检查点时报 quantization 冲突去掉--quantization预量化模型不需要在线量化KV cache pool is full. Retract requests.刷屏--schedule-conservativeness升到 1.3端口被占用30000/9090/3000换端口或lsof -i :30000找出占用进程 落地建议个人开发机小模型 全默认参数跑通即可别过早调参要省显存就加--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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
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 前会先做一次性 prefilltoken 数越多这一瞬的激活值越大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都达到预期再上线。 关键参数速查表参数推荐取值一句话作用--quantization fp8仅高精度原始权重时用加载时在线量化权重省显存--kv-cache-dtype fp8_e4m3长上下文场景开KV 缓存体积减半换更高并发--chunked-prefill-size4096OOM 时降到 2048把长 prefill 切块削平显存峰值--mem-fraction-static0.85 起步日志余量 5~8 GB 为准权重 KV 池的显存占比上限--max-running-requests按 decode 阶段余量下调限同时在跑的请求数--schedule-conservativeness0.3~1.3默认 1.0调度器收/放请求的松紧程度--tp单卡装不下才用张量并行拆分模型--dp单卡装得下时优先数据并行提吞吐--ep-sizeMoE 模型卡数整除专家并行分摊专家计算--attention-backend不指定由 SGLang 自动选选 FA3/FlashInfer/Triton 等注意力内核--enable-metrics生产环境必开暴露 Prometheus 指标注意力后端不用死记不指定时 SGLang 会按硬件和模型结构自动挑最快的。需要 MLA 或滑窗注意力时再按 docs/docs/advanced_features/attention_backend.mdx 的支持矩阵显式指定。️ 高频报错与处置现象处理动作OSError: CUDA_HOME environment variable is not set导出CUDA_HOME/usr/local/cuda-你的版本后重启prefill 阶段 OOM--chunked-prefill-size降到 4096/2048--mem-fraction-static降到 0.8decode 阶段 OOM降--max-running-requests再考虑降--mem-fraction-static加载量化检查点时报 quantization 冲突去掉--quantization预量化模型不需要在线量化KV cache pool is full. Retract requests.刷屏--schedule-conservativeness升到 1.3端口被占用30000/9090/3000换端口或lsof -i :30000找出占用进程 落地建议个人开发机小模型 全默认参数跑通即可别过早调参要省显存就加--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创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
