500并发把DeepSeek API打挂了，我只改了3个地方

上周四下午三点多，我们那个破聊天机器人突然就挂了。

500个并发用户同时发消息，DeepSeek API 直接甩回来一堆 429。老板在群里@我三次，间隔越来越短。那感觉，懂的都懂。

说实话，之前我一直觉得流式输出就是个花活——字一个字往外蹦，看着挺炫，但对性能真有那么大帮助？直到这次翻车，我才认真研究了下 DeepSeek API 在高吞吐场景下的流式输出和 Token 缓冲机制。

坑比我想象的多得多。

先说说我们当时的架构。最开始图省事，用的是非流式调用，等模型吭哧吭哧生成完整回复后，再一次性丢给前端。单个用户用着还行，响应时间大概 2-3 秒，体感上能接受。但并发一上来，直接现原形。

第一个坑：连接超时

我们压测的时候发现，200并发下非流式调用的 P99 延迟能飙到 12 秒，大量请求直接超时。原因其实很简单，非流式要等所有 Token 生成完才返回，这期间 TCP 连接一直占着不放。DeepSeek API 那边也有并发限制，我们的请求排队等推理，前面的没完后面的就得干等着。

改成流式之后情况好多了。首个 Token 的延迟降到了 200ms 以内，用户立马能看到打字效果。但这不是重点，重点是连接释放快，服务端的并发能力直接翻倍。我们同一台 4C8G 的破服务器，之前撑 200 并发就喘得不行，改流式后能稳定跑 500。老服务器焕发第二春。

第二个坑：Token 消费速度不匹配

这是我最想吐槽的地方。DeepSeek API 的生成速度其实挺快的，尤其是 DeepSeek-V3，每秒能吐 50-60 个 Token。但问题来了——前端渲染速度跟不上。

我们最开始的做法是收到一个 Token 就立刻推给前端。结果浏览器卡成狗。每个 Token 都触发一次 DOM 更新，用户看到的是字在抽搐，不是流畅输出。更要命的是，这种频繁的 WebSocket 推送把带宽也打满了，移动端用户直接炸了，流量哗哗的。

后来我参考了某个 V2EX 老哥的帖子（去年11月的，现在找不到了，大意是做了个前端缓冲区），在服务端加了一层 Token 缓冲：

# 伪代码，大概这么个意思
buffer = []
buffer_size = 0
async for chunk in deepseek_stream:
 buffer.append(chunk)
 buffer_size += len(chunk.token)
 if buffer_size >= 4: # 攒够4个字符再推
 await send_to_client(''.join(buffer))
 buffer = []
 buffer_size = 0

等等，这里我要更正一下——上面那个 4 个字符是我后来调出来的值。最开始我设的是 10，结果延迟感又回来了，用户觉得卡。设成 2 的话前端还是有点抖。4 这个数是我拿 Chrome DevTools 的 Performance 面板反复测出来的，不一定适合你们。

这个改动看着简单，效果拔群。前端刷新频率从每秒 50 次降到 10 次左右，CPU 占用直接砍半。用户看到的效果也更自然，像正常打字速度，不是那种开了加速挂的感觉。

第三个坑：长文本生成的 OOM

这个坑踩得我怀疑人生。

我们有个生成报告的功能，单次可能输出 4000+ Token。流式输出跑着跑着，服务端内存就炸了。1月18号晚上10点，我正打游戏呢，PagerDuty 疯狂报警，一看 Pod 被 OOMKilled 了三次。

排查了半天才发现，DeepSeek API 的流式响应在服务端如果处理不当，会产生大量小对象。每个 chunk 都是一个独立的对象，Python 的 GC 来不及回收，内存就飙上去了。我们当时用了个很蠢的做法——把所有 chunk 存到列表里最后再拼，4000 个 chunk 对象直接撑爆内存。现在想想都想抽自己。

改成生成器模式 + 边收边发就好了：

# 别这么干，血的教训
all_chunks = []
async for chunk in stream:
 all_chunks.append(chunk)
return ''.join(all_chunks)

# 应该这样
async for chunk in stream:
 yield chunk # 用完就扔，GC 能及时回收

这个改完之后，内存使用从 2GB 降到了 200MB 左右。稳得很。我们的 K8s 集群终于不用半夜报警了。

一些不成熟的优化经验

1. 并发控制别用信号量。我们最开始用 asyncio.Semaphore 限流，结果发现高并发下信号量的开销比想象中大。后来改成令牌桶，按 DeepSeek API 的实际 TPM（Token Per Minute）限制动态调整。嗯...这个比较复杂，简单说就是别让请求一股脑冲进去，要平滑。效果好了不少。

2. 流式输出的错误处理很重要。流式调用中途断开是常有的事，一定要做好重连和断点续传。我们加了个简单的重试机制，失败后把已生成的文本作为 prompt 前缀传进去继续生成。虽然会浪费一些 Token，但用户体验好很多。据我了解，Anthropic 的 API 也有类似的建议，不过他们文档写得清楚多了。

3. 监控要跟上。强烈建议把首 Token 延迟、Token 生成速度、中断率这些指标监控起来。我们有次模型版本更新后生成速度掉了 30%，靠监控才发现的。用的 Grafana + Prometheus，告警规则设的是一小时内生成速度低于基线 20% 就触发。不然用户投诉都不知道为啥。

说真的，DeepSeek API 的性价比确实高，但在高吞吐场景下，光靠 API 本身的性能是不够的，应用层的优化同样重要。流式输出 + Token 缓冲这套组合拳打好了，能把系统的并发能力提升 2-3 倍。我们现在的架构跑了一个多月，基本没出过问题。

你们在用 DeepSeek API 的时候遇到过什么坑？流式输出这块有没有更好的实践？评论区聊聊呗，我也学习一个。特别是如果有做过 SSE 和 WebSocket 对比的，很想知道你们的结论。

Edit：有老哥问令牌桶的实现，我整理下发评论区。大概周末前能写完。

Edit2：没想到这么多兄弟遇到类似问题，统一回复下——上面提到的缓冲大小 4 个字符是试出来的经验值，你们可以根据自己场景调，别照抄。移动端可能设大一点，桌面端设小一点，具体得看你们前端的渲染性能。

Edit3：好多人问为什么不用 SSE 直接推。其实试过，但我们需要双向通信（用户可能会中断生成），所以最后还是用的 WebSocket。如果你们只是单向推送，SSE 确实更简单，nginx 配置一下就行。

#DeepSeek #API优化 #流式输出 #高并发 #踩坑记录