基于SGLang的大模型推理实践——从benchmark方法论到部署方案选型与调优
内容提要
本文系统介绍基于SGLang的大模型推理部署实践，涵盖benchmark方法论、单机/多机Non-PD分离/PD分离等部署方案选型与性能调优。强调测试先行、无万能方案，需case by case验证。通过实验对比指出EP、并行策略、KV传输引擎等选择因场景而异，并提供调试建议与常见问题解决方案。
延伸解读
benchmark结果需人工校验
SGLang bench_serving的统计结果并非完全可信，其成功判定仅基于HTTP 200和output_len大于等于1，不会校验输出长度是否达到请求值。因此，prefill成功但decode中途崩溃或截断的请求可能被误判为成功。建议在测试后人工检查日志，确认请求是否真正完成，避免性能数据虚高。
EP选择因模型而异
EP（专家并行）的设定并非越大越好，需case by case验证。例如，在H200上部署DeepSeek-V3时，EP8方案因显存占用更少且性能优于EP1；但在Kimi2.5 INT4模型上，EP1方案反而性能更优。因此，EP的选择需结合具体模型、显存和性能目标进行实测，不能一概而论。
PD分离并非总是更优
PD分离（Prefill-Decode分离）方案在TPOT上通常有优势，但整体性能不一定优于Non-PD方案。例如，在长输入场景下，Non-PD 4节点方案的吞吐和TTFT均优于2P2D方案；而在短输入长输出场景，1P2D可能更合适。部署方案需根据瓶颈位置（Prefill或Decode）和具体负载特征进行选择。
KV传输引擎选型需实测
在PD分离方案中，KV传输引擎的选择对性能和稳定性影响显著。实验表明，在长输入（100K）场景下，NIXL可保证全部请求成功，而Mooncake TE成功率不足25%。因此，在Amazon EFA环境中，建议优先考虑NIXL libfabric backend，但具体选型仍需结合场景进行对比测试。
Q&A
SGLang推理部署中，为什么需要先进行benchmark测试？
因为大模型推理部署没有万能方案，不同模型、GPU机型、并行策略等都会影响性能，必须通过benchmark测试来验证和选择最优部署方案。测试先行可以明确测试内容、目标、范围和指标，避免盲目部署。
在SGLang中，EP（专家并行）是否总是比不使用EP性能更好？
不一定。EP的效果因模型和场景而异。例如，在H200上部署DeepSeek-V3时，EP8比EP1性能更好；但在部署Kimi2.5时，EP1反而优于EP8。因此，EP的选择需要case by case测试验证。
PD分离和Non-PD分离部署方案哪个更好？
没有绝对优劣。PD分离在TPOT上通常有优势，但Non-PD在吞吐和TTFT上可能更好。例如，在长输入场景下，Non-PD可能吞吐更高；在短输入长输出场景下，PD分离可能更优。必须根据具体场景测试决定。
在SGLang中，如何正确设置warmup请求？
warmup请求需要充分且合理，以触发Prefill路径上的Triton kernel JIT编译。SGLang server启动时只有一个默认warmup请求，不够充分，需要额外发送足够多的warmup请求，且其分布应与后续benchmark请求一致。
SGLang bench_serving统计的请求成功是否可信？
不完全可信。bench_serving将HTTP 200且output_len大于等于1的请求判定为成功，但不会校验output_len是否达到请求指定的数量，导致decode中途截断的请求被误判为成功。因此需要人工检查日志确认。
在SGLang中，如何排查TTFT高的问题？
TTFT高通常表现为queue_reqs堆积，可能原因包括：并行策略不适当、未启用PP或CP、KV cache空间不足、request rate或max concurrency设置过高、KV cache hit rate低、Router未配置prefix cache aware路由、KV transfer latency高等。需要逐一排查。
在SGLang中，如何排查TPOT高的问题？
TPOT高的可能原因包括：KV cache空间不足导致preemption、并行策略不合适（如EP跨节点）、PD分离方案选择不当、投机解码accept length过低、batch size超出CUDA graph capture范围等。可通过SGLang metric retracted_reqs等指标辅助判断。
在SGLang中，如何排查吞吐低于预期的问题？
首先评估预期是否合理，然后从以下方面排查：SGLang中size相关参数（如chunked、max running request）、kv_available_tokens是否低、KV store配置（如HiCache）、是否启用投机解码、部署方案是否合适（如增加prefill或decode节点）、GPU机型选择、推理框架选择等。
在SGLang中，如何选择KV Transfer Engine？
常见的KV Transfer Engine有NIXL和Mooncake TE。在Amazon EFA环境下，优先推荐NIXL libfabric backend。两者在性能和稳定性上各有优劣，需要case by case对比测试。例如，在长输入场景下，NIXL可能比Mooncake TE更稳定。
在SGLang中，如何选择并行策略组合？
并行策略组合（如TP、EP、DP、PP、CP）没有万能公式，需要根据具体场景测试。核心公式为moe_tp_size = tp_size // ep_size // moe_dp_size，且当moe_dp_size大于1时，attn_cp_size必须等于moe_dp_size。建议先单机基线，再多机扩展，并针对瓶颈扩容。
