Deepseek API极限压测：高并发下的稳定性与弹性伸缩探秘

最新推荐文章于 2025-09-05 11:45:46 发布

原创最新推荐文章于 2025-09-05 11:45:46 发布 · 1.3k 阅读

CC 4.0 BY-SA版权

文章标签：

3 篇文章

订阅专栏

项目场景

我在测试中用到了Deepseek的API，虽然用起来调用的十分流程，但心里总有个疑问：这API的性能底线到底在哪？官方文档好像也没明确说并发限制。万一我的用户量突然涨起来，它能不能扛得住（稳定性）？

为了后续大量访问deepseek的API时能吃下“定心丸”，所以我决定用JMeter来测试一下Deepseek API在高并发下能否稳定的运行。

测试环境：Apache JMeter（非GUI模式压测）
测试对象：Deepseek API（https://api.deepseek.com）
测试思路：我采用了最实在的 “分阶段稳态压力测试法”。简单说，就是固定并发用户数，持续跑一段时间。比如，我先用5个用户持续跑，稳定后记录数据；然后再用10个用户跑，再记录；接着是15、20、25...用户。

实验简介：利用JMeter多个线程模拟不同程度的用户介入Deepseek API进行循环测试

总体架构：

1.首先我在整个测试环境中先加入了一个“预热”的线程组，配置为1个用户，在1秒内启动，循环100次。用1个用户慢慢跑，获取最基础的性能数据。

2.配置HTTP请求（发送给Deepseek API），在这里设置了发送给Deepseek API的具体问题1+1=？

在这里设置了发送给Deepseek API的具体问题1+1=？

3.配置HTTP信息头管理器，这是我的请求头配置，里面包含了认证密钥和Content-Type。可以看到我设置了Authorization: Bearer sk-...和Content-Type: application/json，这是调用API的关键。

为了稳定的测试，我并没有选择一次性大量的进行测试，而是先用了一次40线程数的一个小测试，对Deepseek API的大体性能进评估。参数设置如下：

测试结果和我的预期也大相径庭，Deepseek API作为大模型人工智能不管是在数据还是吞吐量方面都具有很强的稳定性，测试结果图如下所示：

为了稳定的进行测试，我分为了两组实验，第一组设置了线程数梯度为5,10,15,20,25；第二组设置了30,35,40,45,50。

虽然梯度都是5的正增长，但是具体的参数设置缺有所不同。

结果我会放在一起进行对比，由于数据表的长度过长（整理在尾页的附录中，有兴趣的可以参考参考），所以我自己整理做成了表格如下：

我模拟的用户数	样本数	平均响应时间(ms)	吞吐量(QPS)	错误率(%)	我的观察
5	124	4896	1.0	0.00%	稳如老狗，一切正常。
10	249	4886	2.0	0.00%	非常稳定，响应时间几乎没变。
15	370	4936	3.0	0.00%	依然坚挺，QPS随并发线性增长。
20	493	~4912	~3.9	0.00%	持续稳定。
25	629	~4846	~5.0	0.00%	表现线性增长，未见瓶颈。
30	2103	4857	5.8	1.43%	首次出现错误！看来碰到初始资源的天花板了。
35	1275	4940	7.41	0.00%	神奇的事情发生了！错误消失，性能不降反升！
40	1465	4911	8.50	0.00%	稳得很，性能还在提升。
45	1658	4888	9.0	0.00%	继续稳。
50	1856	4857	10.78	0.00%	非常稳定！处理能力相比30用户时提升近一倍！