超参数调优指南

实现峰值吞吐量

实现较大的批次大小是获得高吞吐量的最重要因素。

当服务器满负荷运行时，在日志中查找以下内容：

解码批次。#正在运行的请求：233，#令牌：370959，令牌使用率：0.82，生成吞吐量（令牌/秒）：4594.01，#队列请求：417

调整你的请求提交速度

#队列请求 表示队列中的请求数量。如果你经常看到 #队列请求 == 0，这表明你受到请求提交速度的限制。#队列请求 的健康范围是 50 - 1000。另一方面，不要使 #队列请求 太大，因为它也会增加服务器上的调度开销。

调整 --schedule-conservativeness

令牌使用率 表示服务器的 KV 缓存内存利用率。令牌使用率 > 0.9 表示良好的利用率。如果你经常看到 令牌使用率 < 0.9 且 #队列请求 > 0，这意味着服务器在接收新请求方面过于保守。你可以将 --schedule-conservativeness 降低到 0.3 之类的值。当用户发送许多具有较大 max_new_tokens 的请求，但这些请求由于 EOS 或停止字符串而过早停止时，可能会出现服务过于保守的情况。

另一方面，如果你看到 令牌使用率 非常高，并且你经常看到类似 解码内存不足，#撤回的请求：1，#新令牌比率：0.9998 -> 1.0000 的警告，你可以将 --schedule-conservativeness 增加到 1.3 之类的值。如果你偶尔看到 解码内存不足，但并不频繁，这是可以的。

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

数据并行性更适合吞吐量。当有足够的 GPU 内存时，始终优先考虑数据并行性以获得吞吐量。

通过调整 --chunked-prefill-size、--mem-fraction-static、--max-running-requests 来避免内存不足

如果你遇到内存不足 (OOM) 错误，可以降低这些参数。如果 OOM 发生在预填充期间，尝试将 --chunked-prefill-size 降低到 4096 或 2048。如果 OOM 发生在解码期间，尝试降低 --max-running-requests。你也可以尝试降低 --mem-fraction-static，这将减少 KV 缓存内存池的内存使用量，并有助于预填充和解码。

（次要）调整 --schedule-policy

如果你有很多共享前缀，请使用默认的 --schedule-policy lpm。lpm 代表最长前缀匹配。当你没有任何共享前缀，或者你总是将带有共享前缀的请求一起发送时，你可以尝试使用 --schedule-policy fcfs。fcfs 代表先到先得。