核心内容摘要
【零基础配置 Claude Code 状态栏 完整教程】
所有的架构设计和代码优化最终都要在压力测试的烈火中接受检验。
对于DeepSeek推理服务我们不能简单地用ab或wrk这种针对静态网页的工具来测因为大模型的请求是长连接且计算负载与Prompt长度高度相关。
Locust是一个基于Python的开源压测工具它允许我们编写Python代码来模拟真实用户的行为非常适合测试复杂的AI接口。
本文将介绍如何使用Locust对DeepSeek服务进行全方位的性能与稳定性验证。
为什么不能用ab/wrkab(Apache Bench) 和wrk是Web服务器压测的神器但在LLM场景下它们有几个致命缺陷无法模拟流式响应它们只关注HTTP状态码和整体耗时无法解析SSE流无法统计TTFT (Time To First Token)这一关键指标。
请求内容静态大模型对输入长度极其敏感。
处理10个Token和1000个Token的负载天差地别。
ab只能发送固定的Payload无法模拟真实世界中长短不一的对话分布。
缺乏思考时间真实用户在发完一句话后会阅读、思考、再发下一句。
wrk是无脑轰炸这会导致并发压力虚高无法反映真实的系统承载能力Capacity。
模拟真实负载Locustfile编写指南我们需要模拟真实的业务流量分布。
根据OpenAI的公开数据典型的对话长度分布服从泊松分布。
10%的用户只发短问题50 Token。
80%的用户进行中等长度对话500 Token。
10%的用户上传长文档5k Token。
创建一个locustfile.pyfromlocustimportHttpUser,task,between,eventsimportjsonimporttimeimportrandomclassDeepSeekUser(HttpUser):# 模拟用户思考时间1到5秒之间wait_timebetween(1,
task(
# 权重10短对话defchat_short(self):self.send_request(prompt_len50,output_len
task(
# 权重1长文档defchat_long(self):self.send_request(prompt_len5000,output_len
defsend_request(self,prompt_len,output_len):# 构造伪数据实际测试中可以使用真实语料库prompttest *prompt_len payload{prompt:prompt,max_new_tokens:output_len,temperature:
7,stream:True# 开启流式}start_timetime.time()first_token_timeNonetoken_count0# 使用catch_response手动处理结果withself.client.post(/generate,jsonpayload,streamTrue,catch_responseTrue)asresponse:ifresponse.status_code!200:response.failure(fStatus code:{response.status_code})return# 模拟接收流式响应try:forlineinresponse.iter_lines():ifnotline:continue# 记录首字时间ifnotfirst_token_time:first_token_timetime.time()ttft(first_token_time-start_time)*1000# 自定义上报TTFT指标events.request.fire(request_typegrpc,nameTTFT,response_timettft,response_length
token_count1total_timetime.time()-start_time# 计算生成速度tpstoken_count/(total_time-(first_token_time-start_time))exceptExceptionase:response.failure(fStream error:{e})
核心指标解读与分析运行压测命令locust -f locustfile.py --host http://localhost:8000 --headless -u 50 -r 1在控制台或Web UI中我们需要重点关注以下指标并学会透过数据看本质
1 RPS vs TPSRPS (Requests Per Second)对于长任务RPS可能很低比如
5。
这不代表性能差因为一个Request可能持续20秒。
TPS (Tokens Per Second)这是衡量LLM服务吞吐量的黄金指标。
需要在服务端统计或者像上面代码那样在Locust端估算。
正常曲线随着并发用户数增加TPS应该线性增长直到达到显存带宽瓶颈然后趋于平稳。
异常曲线如果并发增加TPS反而下降说明发生了严重的资源争抢如Python GIL锁竞争、Cache Thrashing。
2 Latency: P99 vs Average平均延迟毫无意义千万别看。
因为长短任务混杂平均值会被长任务拉高掩盖了短任务的性能问题。
P99 Latency尾部延迟。
如果P99飙升说明系统内部出现了排队Queuing。
排队原因Dynamic Batching的等待队列满了或者是KV Cache显存不足导致Swap。
3 Failure RateTimeoutNginx或客户端设置的超时时间太短。
Connection Reset服务端进程崩溃OOM。
503 Service Unavailable负载均衡器主动拒绝了请求熔断。
稳定性测试Soak Testing除了测极限性能Stress Test还需要测长期稳定性。
让Locust以中等负载比如60%峰值连续运行24小时。
重点观察对象显存泄漏Memory Leak使用npu-smi info监控。
显存占用应该在一定范围内波动。
如果发现显存占用随时间呈现锯齿状上升且低谷越来越高说明有Tensor未释放。
僵尸进程检查ps -ef | grep python。
是否有处理完请求但未退出的孤儿进程。
温度墙Thermal Throttling长时间满载可能导致NPU温度过高80度触发硬件降频。
这会导致推理速度突然变慢。
混沌测试Chaos Testing进阶玩家还可以尝试“搞破坏”验证系统的高可用性HA。
断网演练在压测过程中模拟网络丢包iptables -I INPUT -m statistic --mode random --probability
1 -j DROP看客户端SDK是否能自动重连。
杀节点随机Kill掉一个推理Pod看负载均衡器能否快速3秒剔除故障节点并将流量转移到健康节点。
显存碎片化模拟发送大量长度极其怪异的请求如[1, 8192, 3, 4000]通过极端分布测试PagedAttention的内存碎片整理能力。
6.
总结压测不是为了生成一份漂亮的报告而是为了发现系统的崩溃点Breaking Point。
如果不测TTFT你就不知道用户等待首字的焦虑。
如果不测长文档并发你就不知道显存什么时候会OOM。
如果不做24小时稳定性测试你就不知道内存泄漏会在深夜搞垮服务。
通过基于Locust的全方位实战验证我们不仅能摸清DeepSeek服务的性能边界Capacity Planning还能提前暴露那些只在极端并发下才会出现的Race Condition和资源竞争Bug确保上线即稳如磐石。