探秘 AgentRun｜流量一大就瘫痪？用 LiteLLM 与函数计算拆解 AI 模型调用之痛

1. AgentRun 流量一上来就瘫痪问题到底出在哪AgentRun 场景下 AI 模型调用高并发崩溃是很多团队上线后第一个撞上的墙。单机调试时一切正常QPS 一过阈值接口开始大面积超时日志里刷满 429 和 timeout前端用户看到的就是转圈和报错。AgentRun 这类 Agent 应用的特点是调用链长、单次请求可能触发多轮模型交互流量放大效应比普通 API 更明显一个用户请求背后可能是三到五次模型调用。核心检索词先摆清楚AgentRun 是承载 Agent 运行的基础设施AI 模型调用是它最频繁也最脆弱的一环LiteLLM 是开源的多模型代理层函数计算提供弹性算力模型治理则是把限流、重试、降级、熔断这些动作系统化。适合谁看正在做 Agent 应用、被模型调用稳定性折磨的后端和平台工程师。我试过的典型崩溃链路是这样的AgentRun 里每个 Agent 直接硬编码调用某一家模型 API没有中间层。流量一涨单账号触发厂商限流返回 429代码里没有重试直接抛错没有备用模型整个 Agent 挂掉没有熔断失败请求继续打把配额耗光。四个问题叠加就是流量一大就瘫痪。这篇要交付的是可复制的 LiteLLM 配置骨架、函数计算触发配置、压测验证动作让你能亲手复现限流、重试与降级链路。技术部分占大头拿 Key 只是前置动作。2. 前置准备TaoToken 接入与 LiteLLM 部署位置LiteLLM 本身是一个 Python 写的统一模型代理对外暴露 OpenAI 兼容接口对内可以路由到不同厂商。它天然适合放在 AgentRun 和真实模型之间做治理层。部署位置有两个选择一是跑在函数计算上按量付费、自动扩缩容二是跑在常驻容器里适合流量平稳的场景。高并发场景推荐函数计算因为突发流量下弹性伸缩比手动扩容快得多。模型来源这边我用 TaoToken 作为统一接入点它提供 OpenAI 兼容的 APILiteLLM 配置里只需要改 base_url 和 api_key 就能接上。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数。先去控制台创建 API Key路径是 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite Key 管理页在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 。拿到 Key 后先别急着写 LiteLLM 配置用模型对话页 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 手动发一条请求确认 Key 可用、模型名正确。这一步能省掉后面大量配置没错但就是 401的排查时间。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面写了请求格式和可用模型列表。如果你后面要做长期编码或 Agent 任务可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite ClaudeCode 相关接入在 https://taotoken.net/claudecode?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite 。注意API Key 只放在服务端环境变量里不要写进前端代码或提交到仓库。LiteLLM 的配置文件里用 os.environ 读取不要明文。3. 可复制的 LiteLLM 配置骨架LiteLLM 的配置核心是一个 YAML 文件定义模型列表、路由策略、重试和降级。下面这份骨架可以直接改 Key 后使用覆盖了主备切换、负载均衡、重试、熔断四类治理动作。model_list: - model_name: gpt-4-primary litellm_params: model: openai/gpt-4 api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY timeout: 30 - model_name: gpt-4-backup litellm_params: model: openai/gpt-4 api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY_BACKUP timeout: 30 - model_name: qwen-fallback litellm_params: model: openai/qwen-max api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY timeout: 20 router_settings: routing_strategy: simple-shuffle num_retries: 3 retry_after: 1 allowed_fails: 2 cooldown_time: 30 fallbacks: [{gpt-4-primary: [gpt-4-backup, qwen-fallback]}] context_window_fallbacks: [{gpt-4-primary: [qwen-fallback]}] litellm_settings: request_timeout: 30 drop_params: true set_verbose: false逐段解释。model_list 里同一个 model_name 可以挂多个实例LiteLLM 会把它们当成一个逻辑模型做负载均衡。这里 gpt-4-primary 和 gpt-4-backup 用不同的 Key模拟多账号分流规避单账号限流。qwen-fallback 是降级目标超时设短一点快速失败。router_settings 是治理核心。routing_strategy 用 simple-shuffle 做轮询你也可以换成 least-busy 或 usage-based-routing。num_retries 设 3配合 retry_after 做基础重试。allowed_fails 和 cooldown_time 是熔断参数某个实例连续失败 2 次就冷却 30 秒期间不再打它。fallbacks 定义降级链主模型失败自动切备用备用再失败切 qwen。litellm_settings 里 request_timeout 是全局超时drop_params 让 LiteLLM 自动丢弃目标模型不支持的参数避免因为参数不兼容报错。启动命令export TAOTOKEN_API_KEY你的主Key export TAOTOKEN_API_KEY_BACKUP你的备用Key litellm --config ./litellm_config.yaml --port 4000 --num_workers 4--num_workers 根据函数计算实例的 vCPU 调整一般设成 vCPU 数的 2 倍。启动后 LiteLLM 在 4000 端口暴露 OpenAI 兼容接口AgentRun 里的模型调用地址改成 http://127.0.0.1:4000 即可。4. 函数计算触发配置与弹性策略LiteLLM 跑在函数计算上关键是触发器和并发配置。函数计算支持 HTTP 触发器和自定义域名LiteLLM 作为常驻进程更适合用容器镜像部署配合 HTTP 触发器对外服务。部署时几个参数要盯紧。实例并发度Instance Concurrency决定单个实例能同时处理多少请求LiteLLM 是 IO 密集型单实例并发可以设到 20 到 50具体看压测结果。预留实例Provisioned Instance用来扛基线流量避免冷启动弹性实例负责突发上限设高一点比如 100。# 函数计算触发器配置示例serverless-devs 风格 triggers: - type: http config: authType: function methods: [POST, GET] path: /v1/chat/completions弹性策略上函数计算默认按请求量自动扩缩。你要做的是设置合理的最大实例数防止流量洪峰把配额打爆。同时给 LiteLLM 配好上游限流让它在接近厂商限额时主动降速而不是等厂商返回 429。一个容易踩的坑函数计算实例是无状态的LiteLLM 的熔断状态存在内存里实例重启后冷却计数会丢。如果对熔断精度要求高可以把状态外置到 RedisLiteLLM 支持 Redis 作为缓存后端配置里加 redis_host 和 redis_port 即可。5. 压测验证复现限流、重试与降级配置写完不压测等于没配。用 locust 或 wrk 打 LiteLLM 的 4000 端口观察三件事限流是否触发、重试是否生效、降级是否切换。# locustfile.py from locust import HttpUser, task, between class ModelUser(HttpUser): wait_time between(0.1, 0.5) task def chat(self): self.client.post(/v1/chat/completions, json{ model: gpt-4-primary, messages: [{role: user, content: 你好}], max_tokens: 50 }, headers{Authorization: Bearer sk-anything})启动压测locust -f locustfile.py --host http://127.0.0.1:4000 --users 200 --spawn-rate 20200 并发、每秒新增 20 用户持续打。观察 LiteLLM 日志正常情况你会看到部分请求命中主模型部分被 shuffle 到备用当某个 Key 触发 429LiteLLM 自动重试并切换到另一个实例如果主模型整体不可用fallbacks 生效切到 qwen。验证降级是否真的生效可以手动把主模型的 api_base 改成一个不存在的地址重启 LiteLLM再压测。如果请求仍然成功返回说明降级链工作正常。这一步是很多团队漏掉的配置写了但没验证真出事时才发现 fallback 没生效。成功结果长这样压测期间错误率低于 1%P99 延迟稳定在 2 秒内日志里能看到 fallback 触发记录但没有请求彻底失败。如果错误率飙升回到第 6 节排查。6. 本篇常见错排查401 UnauthorizedKey 没读到。检查环境变量名和配置里的 os.environ 引用是否一致函数计算里环境变量要在函数配置里显式设置不是本地 export 就完事。429 频繁出现且不重试num_retries 没生效。确认 router_settings 层级正确num_retries 在 router_settings 下而不是 litellm_settings 下。另外 retry_after 太短会导致重试打在同一限流窗口适当调大。fallback 不触发fallbacks 的 key 必须和 model_list 里的 model_name 完全一致大小写敏感。另外只有可重试的错误429、500、timeout才触发 fallback400 类参数错误不会。函数计算冷启动导致首请求超时配预留实例或者把 LiteLLM 的 request_timeout 调大给冷启动留时间。熔断状态丢失实例重启后冷却计数清零高精度场景接 Redis 外置状态。压测时 LiteLLM 进程 OOMnum_workers 设太大每个 worker 占内存。降 workers 或升实例规格。排查顺序建议从 Key 到配置层级到网络逐层缩小。日志里 LiteLLM 会打印每次路由决策善用 set_verbose 临时打开详细日志。7. 下一步把治理链路接进你的 AgentRun配置跑通后把 AgentRun 里的模型调用地址从厂商直连改成 LiteLLM 的地址治理链路就接上了。后续要做的三件事把熔断状态外置到 Redis、给 LiteLLM 加监控埋点、按业务优先级配置不同的路由策略。需要长期跑编码或 Agent 任务的可以看 Coding Plan https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 。接入过程中遇到报错先查接入文档 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 再对照 API Keys 页 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 确认 Key 状态。模型对话页 https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 可以快速验证某个模型是否可用省去写测试代码的时间。压测通过后别急着下线测试环境把限流阈值和降级策略记下来作为生产环境的基线。流量增长时先看 LiteLLM 日志里的路由分布再决定是加实例还是调策略。