关于大模型调用预热问题

[qq1270131361]

Error code: 429 - {'error': {'message': 'Request rate increased too quickly. To ensure system stability, please adjust your client logic to scale requests more smoothly over time.', 'type': 'limit_burst_rate', 'param': None, 'code': 'limit_burst_rate'}, 'id': '111111', 'request_id': '11111'}

每天早上8.30开始上班，系统高峰期，请求大模型提示上涨速率太快，导致失败，虽然有重试，但是短时间重试还会有加剧异常分享
当前考虑的想法有2种
1.LLMErrorHandlingMiddleware策略调整，重试次数增加，延迟时间和最大时间增加
2.业务上做一些请求流控

还有什么其他现成的好办法解决这问题吗?

[willem-bd]

先定性：limit_burst_rate 不是"额度超限"，是"速率上涨过快"

这个错误来自火山方舟（Ark / 豆包）侧，关键在错误码 limit_burst_rate 和那句 "Request rate increased too quickly … scale requests more smoothly over time"。它和普通的 429（RPM/TPM 配额打满）不是一回事：

• 配额型 429：单位时间内请求总量超了 → 解法是排队 / 降并发 / 等 Retry-After。
• burst 型 429：请求速率的导数（斜率）太陡 → 早上 8:30 从近乎 0 瞬间拉到峰值，provider 直接判定"爬坡太猛"。

所以你说的"短时间重试还会加剧异常"完全正确——重试本身就是往这个正在告警的突刺里继续加请求。这点决定了方案取舍。

关于你的两个想法

想法 1（调 LLMErrorHandlingMiddleware：加次数、加延迟、加封顶）——对 burst 型大概率帮倒忙。

看了 backend/packages/harness/deerflow/agents/middlewares/llm_error_handling_middleware.py：

• 当前 retry_max_attempts=3、retry_base_delay_ms=1000、retry_cap_delay_ms=8000，退避是确定性的 base * 2^(attempt-1)（1s / 2s / 4s / 8s）。
• 429 已在 _RETRIABLE_STATUS_CODES 里，已经会重试；并且已经会读 Retry-After / retry-after-ms 头。
• 这三个 retry 参数是类属性硬编码，没接到 config.yaml（目前只有 circuit_breaker.failure_threshold / recovery_timeout_sec 可配，默认 5 次失败 / 熔断 60s）。所以要调它得改代码，不是改配置。

在 burst 场景下加次数 / 加延迟的副作用：

1. 8:30 一批请求同时失败 → 同时在 1s / 2s / 4s 这个相同时间点集体重试，形成"惊群"，反而再次触发 burst 限制（退避是确定性的，没有 jitter）。
2. 重试越多，突刺窗口里塞的请求越多，provider 只会更紧。
3. 唯一可能"救"你的是熔断器：连续 5 次失败后开 60s，等于强制冷却——但那是"整 run 直接失败"的钝器，不是平滑限流，体验很差。

想法 2（业务层做请求流控）——方向是对的，provider 自己也在让你这么干。

现成可用的办法（按落地成本排序）

1. 在 Nginx 入口做 limit_req（零代码，今天就能上）。
backend/docs/API.md 的 Rate Limiting 章节已经给了模板，默认没开：

limit_req_zone $binary_remote_addr zone=api:10m rate=10r/s;
location /api/ {
    limit_req zone=api burst=20 nodelay;   # 突发用 delay= 替代 nodelay 更平滑
    proxy_pass http://backend;
}

把 rate 调到低于 provider 的 burst 容忍线，并把 nodelay 换成 delay= 让超量请求排队而非立即放行。这是在请求碰到 LLM 之前就把它"漏桶化"，8:30 的洪峰被匀速放出，斜率自然下来。对 burst 型限流这是最直接有效的一招。

2. 给 LLM 调用加全局并发上限（小改代码）。
现在仓库里只有两处并发约束：ChannelManager 用 asyncio.Semaphore(max_concurrency=5) 限 IM 渠道的在途 run（app/channels/manager.py），以及 scheduled task 用 count_active_runs() 限制跨任务并发。但交互式 / API 路径上，跨 thread 的并发 LLM 调用没有全局上限，lead-agent + subagent 扇出会把并发顶上去。

在模型调用层（最自然是包在 LLMErrorHandlingMiddleware.wrap_model_call / awrap_model_call 里，或更靠下在 model client）套一个进程级 asyncio.Semaphore，把同时在飞的请求数钉死在一个上限。并发被钉住，爬坡斜率就有天花板，这是对 "rate increased too quickly" 最根本的治理。

3. 给退避加 jitter，并对 limit_burst_rate 单独分类。
如果你确实要动中间件，真正有用的不是"加次数"，而是：

• 给退避加去相关抖动（decorrelated jitter），打散惊群——这是当前确定性退避最大的缺陷。
• _classify_error 现在把所有 429 都归到 "transient" 同一个预算。可以读 error code（_extract_error_code 已经能取到 limit_burst_rate），对 burst 型走更长 base delay + 更少次数的策略，本质是"与其重试进突刺，不如多等一会再放行"。
• 保持总次数克制（别堆），优先信 provider 的 Retry-After。

4. 把 8:30 的尖峰主动摊平（治本，针对你描述的时间规律）。
失败是时间强相关的上班高峰，那就别让系统 0 → 峰值瞬间切换：

• 定时任务别全压在 08:30:00。scheduler/schedules.py 用 croniter，没有内置 jitter，但可以手动给不同任务的 cron 错开几十秒到几分钟，让需求爬坡而非跳变。
• 预热连接：高峰前用少量真实 / 探针请求把 HTTP 连接池、SDK 客户端、鉴权 token 都热起来，避免冷启动叠加。
• 交互流量你控不了到达时间，但配合上面的 nginx 限流 + 全局信号量，尖峰会被削平。

优先级建议

优先级	动作	成本	对 burst 型效果
立刻	Nginx limit_req（delay= 平滑）+ 错峰 cron	零代码 / 配置	直接削峰
短期	LLM 调用全局 Semaphore + 退避加 jitter	小改代码	治本
可选	limit_burst_rate 单独分类、更长 base / 更少次数	小改代码	减少惊群
不建议	单纯加 retry_max_attempts / 加大 cap	改代码	多半更糟

一句话总结：burst 限流的解法是"削峰填谷 + 控并发"，不是"更努力地重试"。 想法 2 是对的；想法 1 单独用会让 8:30 的突刺更严重，除非顺带把退避改成带 jitter、并把次数压低而不是调高。

[WillemJiang]

I just created a new feature request #4290 for this issue.