Anthropic 80 倍增长把服务器打爆：宕机、限流、降性能到底怎么回事

你可能也遇到过这种瞬间血压拉满的场景：

• Claude/某个大模型 API 白天好好的，晚上突然开始 429 Too Many Requests
• 之前 2 秒出结果，现在卡成 20 秒
• 明明没改代码，却被通知“为了稳定性我们临时降配/降速”

有人会吐槽：“你们是不是服务器不行？”

但有时候，真不是。

Anthropic 的 CEO Dario 就提过一件很真实的事：团队原本只按 10 倍增长做准备，结果实际迎来 80 倍增长的冲击。内部甚至给它取名叫：“成功灾难”（success disaster）。更扎心的是，他们的算力预估偏差达到 8 倍或更多。

看到这里，你再回想宕机、限流、性能削减，是不是突然合理了？😂

这类“成功灾难”到底是什么

一句话解释：

不是产品失败，而是产品太成功，成功到把自己的系统压垮。

大模型服务有个特点：每一次请求都很“重”。

你在聊天框里多打几句话，对后端来说可能是：

• 更长的上下文（token 变多）
• 更高的推理成本（算力时间更长）
• 更长的排队等待（并发被占住）

所以用户增长不是线性压力，而是常常带着“隐藏倍增器”。

为什么 10 倍计划会被 80 倍打穿

别把这理解成“拍脑袋”。很多团队都会掉进同一类坑。

1）增长不是只看“用户数”，而是看“算力消耗”

你以为增长 10 倍，就是请求数 10 倍。

现实可能是：

• 用户数 10 倍
• 平均上下文长度从 2k 涨到 8k
• 大家开始用更大的模型
• RAG/工具调用带来更多轮对话

最后算力直接变成 80 倍。

2）爆款场景会改变使用方式

没火之前：大家随便试试。

火了之后：

• 开始进公司业务流
• 开始做自动化批处理
• 开始被各种 Copilot、Agent 套娃调用

请求从“偶尔聊两句”，变成“24 小时流水线”。

3）基础设施扩容没你想的快

算力不是买几台机器就完事。

你要排期：

• GPU 采购/租用
• 集群调度
• 网络、存储
• 模型部署与验证
• 成本控制（不然财务先炸）

扩容永远比增长慢半拍。

宕机、限流、降性能：它们分别在救什么

当增长把系统顶满，工程团队会用一些“止血手段”。你看到的现象，其实是他们在保命。

宕机：真的扛不住了

• 队列堆到爆
• 关键组件超时
• 重试风暴（客户端一直重试，雪上加霜）

这时候不是“慢”，是“死”。

限流：不让系统被拖死

常见表现：

• 429
• 某些地区/某些 key 直接被限
• 免费用户更容易被挡

限流本质是：宁愿拒一部分请求，也别让全部请求都失败。

降性能：用体验换稳定

常见操作：

• 降低并发
• 降低最大上下文
• 触发更激进的缓存策略
• 选择更便宜/更快的推理路径

你会觉得“变笨/变慢/更容易断”，但整体可用率上来了。

你是开发者/产品方：怎么应对这种“服务端抽风”

别指望大厂永远稳。你要让自己的业务稳。

1）把重试写得像个人，而不是像打桩机

很多项目一报错就疯狂重试，结果把对方和自己一起拖死。

建议策略：

• 指数退避（1s、2s、4s、8s…）
• 加随机抖动（避免大家同一秒冲上去）
• 429/503 才重试，400 这种就别硬扛

伪代码（看懂就能抄）：

import random, time

for i in range(6):
    try:
        return call_llm()
    except RateLimitError:
        sleep = (2 ** i) + random.random()
        time.sleep(sleep)
raise Exception("still rate-limited")

2）做“降级方案”，别让业务裸奔

你可以准备几种降级方式：

• 模型降级：大模型 → 小模型（比如 Claude 3 Opus → Sonnet）
• 功能降级：长文总结改成“要点版”
• 体验降级：提示用户排队、异步通知结果

你会发现，用户能接受“慢一点”。用户接受不了“直接没了”。

3）把 token 当钱花

很多限流和变慢，根源是 token 太大。

实用做法：

• 系统提示词别写成论文
• 上下文只保留关键轮次
• RAG 召回别一股脑塞 20 段进 prompt
• 输出长度设上限

你省下 token，就等于给自己每天早下班一点点 😅

4）监控要盯“延迟分位数”，别只看平均值

平均延迟很会骗人。

建议至少看：

• P50：正常用户啥感觉
• P95：高峰期是不是开始卡
• P99：是不是已经有人想砸键盘

再配上：

• 429 比例
• 超时比例
• 单次请求 token 分布

你会更早发现“服务端要炸了”。

给团队的容量规划提醒（别再 10 倍计划翻车）

如果你也在做模型服务，下面这几条基本能救命：

• 用“token/s”做容量单位，别用“QPS”自我安慰
• 压测要模拟真实流量：长上下文、工具调用、多轮对话都要有
• 预留“爆款缓冲区”：突然来一波活动/媒体曝光，别直接跪
• 给限流策略写清楚：哪些用户优先、哪些请求先挡

你不需要预测未来，只要允许未来出意外。

避坑清单（看到就改）

• 把“无限重试”当可靠性方案
• 不做降级，还指望供应商 100% 在线
• 上线前只测短 prompt，没测长上下文
• 业务指标只看“成功率”，不看“延迟尾部”
• 把 token 成本当空气，直到账单把你叫醒

结尾：这真是幸福的烦恼吗？

对 Anthropic 来说，80 倍增长当然是幸福。

对用户来说，半夜接口崩掉、速率限制、性能被砍，幸福个鬼。

现实是：大模型服务越火，越容易遇到这种“成功灾难”。

你能做的，是把自己的系统写得更像老司机：

• 能等
• 能绕路
• 能降级
• 能活着把活干完

需要更多计算资源？当然需要。

但在算力到位前，工程手段才是救命药。🤣