超参数调优

超参数调优#

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

在离线批量推理中，实现大批量大小是实现高吞吐量的最重要的事情。 当服务器在稳态下满负载运行时，请在日志中查找以下内容：

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 这样的值。 如果您偶尔看到 KV cache pool is full. Retract requests.（大约每分钟一次），则是可以接受的。

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

SGLang 如下分配内存：

总内存使用量 = 模型权重 + KV 缓存池 + CUDA 图缓冲区 + 激活值

--mem-fraction-static 参数决定分配给前两个组件的内存量：

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

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

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）错误，可以调整以下参数：

  • 如果 OOM 发生在预填充阶段，请尝试将 --chunked-prefill-size 降低到 4096 或 2048。这可以节省内存但会降低长提示的预填充速度。

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

  • 您还可以将 --mem-fraction-static 减小到更小的值，如 0.8 或 0.7。这减少了 KV 缓存内存池的内存使用，并有助于防止在预填充和解码过程中发生 OOM 错误。但是，这限制了最大并发性并降低了峰值吞吐量。

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

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

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

数据并行性对吞吐量更好。当有足够的 GPU 内存时，始终优先选择数据并行性来提高吞吐量。请参考 sglang router 以获得更好的数据并行性，而不是使用 dp_size 参数。

尝试其他选项#

  • torch.compile 可以加速小批量大小的小型模型。您可以使用 --enable-torch-compile 启用它。

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

  • 尝试其他并行策略（例如 expert parallelism）或针对 deepseek 模型的 DP 注意力（使用 --enable-dp-attention --dp-size 8）。

  • 如果工作负载有许多共享前缀，请尝试 --schedule-policy lpm。这里 lpm 代表最长前缀匹配。它重新排序请求以鼓励更多缓存命中，但会引入更多调度开销。

目录