超参数调优指南#
实现峰值吞吐量#
实现大批量是获得高吞吐量的最重要的事情。
当服务器满负荷运行时,请在日志中查找以下内容:
Decode batch. #running-req: 233, #token: 370959, token usage: 0.82, gen throughput (token/s): 4594.01, #queue-req: 317
调整您的请求提交速度#
#queue-req 表示队列中的请求数量。如果你经常看到 #queue-req == 0,这表明你的请求提交速度成为了瓶颈。
#queue-req 的健康范围是 50 - 500。
另一方面,不要让 #queue-req 太大,因为它也会增加服务器上的调度开销,特别是在使用默认的最长前缀匹配调度策略时(--schedule-policy lpm)。
调整 --schedule-conservativeness#
token usage 表示服务器的KV缓存内存利用率。token usage > 0.9 表示利用率良好。
如果你经常看到 token usage < 0.9 和 #queue-req > 0,这意味着服务器在接收新请求时过于保守。你可以将 --schedule-conservativeness 减少到像0.3这样的值。
当用户发送许多带有较大 max_new_tokens 的请求但由于EOS或停止字符串而非常早地停止时,可能会出现服务器过于保守的情况。
另一方面,如果你看到token usage非常高,并且经常看到类似decode out of memory happened, #retracted_reqs: 1, #new_token_ratio: 0.9998 -> 1.0000的警告,你可以将--schedule-conservativeness增加到1.3这样的值。如果你偶尔看到decode out of memory happened但不频繁,那是没问题的。
调整 --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缓存内存池的内存使用,有助于预填充和解码。
尝试高级选项#
要启用torch.compile加速,请添加
--enable-torch-compile。它可以在小批量大小下加速小型模型。目前这不适用于FP8。
调整 --schedule-policy#
如果工作负载有许多共享前缀,请使用默认的--schedule-policy lpm。lpm代表最长前缀匹配。
当你完全没有共享前缀或者你总是将带有共享前缀的请求一起发送时,你可以尝试--schedule-policy fcfs。fcfs代表先到先服务。fcfs具有较低的调度开销。