超参数调优

超参数调优#

实现离线批量推理的高吞吐量#

在离线批量推理中，实现大 Batch Size 是获得高吞吐量的关键。当服务器在稳定状态下满负荷运行时，请在日志中查找以下内容：

Decode batch. #running-req: 233, #token: 370959, token usage: 0.82, cuda graph: True, gen throughput (token/s): 4594.01, #queue-req: 317

通过调整请求提交速度来控制 #queue-req#

#queue-req 表示队列中的请求数量。如果您经常看到 #queue-req: 0，说明您的客户端代码提交请求的速度太慢。 #queue-req 的健康范围是 100 - 2000。但是，请避免使 #queue-req 过大，因为这会增加服务器的调度开销。

实现高 token usage#

token usage 表示服务器的 KV 缓存内存利用率。 token usage > 0.9 表示利用率良好。

如果您经常看到 token usage < 0.9 且 #queue-req > 0，说明服务器在接纳新请求方面过于保守。您可以将 --schedule-conservativeness 降低到 0.3 左右。当用户发送大量具有较大 max_new_tokens 的请求，但请求由于 EOS 或停止词而很早就停止时，可能会出现服务器过于保守的情况。

另一方面，如果您看到 token usage 非常高，并且经常看到类似 KV cache pool is full. Retract requests. #retracted_reqs: 1, #new_token_ratio: 0.9998 -> 1.0000 的警告，您可以将 --schedule-conservativeness 增加到 1.3 左右。如果您只是偶尔（约每分钟 1 次）而不是频繁地看到 KV cache pool is full. Retract requests.，这是可以接受的。

调整 --mem-fraction-static 以增加 KV 缓存池容量#

SGLang 的内存分配如下：

总内存消耗 = 模型权重 + KV 缓存池 + CUDA 图缓冲区 + 激活值

--mem-fraction-static 参数决定了前两个部分分配的内存比例。

mem_fraction_static = (模型权重 + KV 缓存池) / GPU 内存容量

为了支持更高的并发量，您应该通过尽可能高地设置 --mem-fraction-static 来最大化 KV 缓存池容量，同时为激活值和 CUDA 图缓冲区预留足够的内存。

SGLang 使用简单的启发式方法来设置 --mem-fraction-static 的默认值，但您可以根据具体的用例进行优化。根据经验，通常预留 5–8 GB 的显存用于激活值就足够了。您可以通过在服务器就绪前检查日志来确认这一点。查找如下所示的日志条目：

[2025-08-11 17:17:03] max_total_num_tokens=665690, chunked_prefill_size=8192, max_prefill_tokens=16384, max_running_requests=4096, context_len=65536, available_gpu_mem=13.50 GB

检查 available_gpu_mem 的值。

  • 如果该值在 5–8 GB 之间，则设置良好。

  • 如果该值过高（例如 10 - 20 GB），请增加 --mem-fraction-static 以向 KV 缓存分配更多内存。

  • 如果该值过低，之后可能会面临显存溢出 (OOM) 的风险，因此请减小 --mem-fraction-static。

另一种直接的方法是以 0.01 为增量增加 --mem-fraction-static，直到您的工作负载遇到 OOM 错误为止。

通过调整 --chunked-prefill-size、--mem-fraction-static 和 --max-running-requests 来避免显存溢出错误#

如果您遇到显存溢出 (OOM) 错误，可以调整以下参数：

  • 如果在 Prefill（预填充）阶段发生 OOM，请尝试将 --chunked-prefill-size 减小到 4096 或 2048。这会节省显存，但会降低长 Prompt 的预填充速度。

  • 如果在 Decoding（解码）阶段发生 OOM，请尝试降低 --max-running-requests。

  • 您也可以将 --mem-fraction-static 减小到更小的值，例如 0.8 或 0.7。这会减少 KV 缓存内存池的占用，有助于防止预填充和解码阶段的 OOM 错误。但是，这会限制最大并发量并降低峰值吞吐量。

调整 --cuda-graph-max-bs#

默认情况下，CUDA 图仅对较小的 Batch Size（例如小于 160 或 256）启用。然而，对于某些模型，特别是在张量并行度（TP size）较大时，CUDA 图在 Batch Size 达到 512 或 768 时仍然有效。因此，将 --cuda-graph-max-bs 增加到更大的值可能会有帮助。请注意，CUDA 图会消耗更多内存，因此您可能需要同时减小 --mem-fraction-static。

调整 --dp-size 和 --tp-size#

数据并行（Data Parallelism）更有利于吞吐量。在 GPU 显存足够时，为了提高吞吐量，应优先考虑数据并行。请参考 sglang router 以获得更好的数据并行方案，而不是仅使用 dp_size 参数。

尝试其他选项#

  • torch.compile 可以在小 Batch Size 下加速小模型。您可以通过 --enable-torch-compile 启用它。

  • 尝试其他量化方式（例如使用 --quantization fp8 进行 FP8 量化）。

  • 尝试其他并行策略（例如 专家并行/Expert Parallelism）或针对 DeepSeek 模型的 DP Attention（使用 --enable-dp-attention --dp-size 8）。

  • 如果工作负载中有很多共享前缀，请尝试 --schedule-policy lpm。这里的 lpm 代表最长前缀匹配（Longest Prefix Match）。它会重新排列请求以提高缓存命中率，但会引入额外的调度开销。

目录