让车间AI助手不掉线：搞定Bedrock 429/503

生产环境里，最让人抓狂的不是“模型答得不够聪明”，而是它突然不回你。

在汽车制造场景里，AI 语音助手和自动化工作流越来越常见：班组长用语音报修，系统自动生成工单；质检员口述缺陷，AI 把描述结构化并推送到 MES/QMS；供应链同事让助手汇总异常并自动发邮件。只要其中一个环节卡住，现场就会出现一种很熟悉的连锁反应：人开始等系统，节拍开始乱，信任开始下降。

Amazon Bedrock 上最常见的两类“卡住”，基本都能归结为两个错误：429 ThrottlingException（限流）和 503 ServiceUnavailableException（服务暂不可用）。我见过不少团队把它们当成“偶发网络问题”随便重试，结果越忙越错、越错越重试，最后把用户体验拖到不可接受。

下面这篇文章把 RSS 的技术要点转成可落地的生产方法，重点放在：如何让面向一线的 AI 助手在高峰期也稳定，如何让自动化工作流遇到波动也不断链。内容会偏工程实操，但会尽量贴近汽车制造的真实流量与流程。

先分清 429 和 503：错因不同，打法完全不同

**最直接的判断：429 是你用超了配额；503 是服务端或客户端资源短缺导致的暂时不可用。**两者都“看起来像失败”，但处理策略不能混。

• 429 ThrottlingException：常见于请求数（RPM）或 tokens 吞吐（TPM）超过了账户/模型/区域的配额窗口。
• 503 ServiceUnavailableException：常见于服务端容量压力、网络波动、或者你自己的客户端连接池打满（这点很多团队会误判）。

在“人工智能在汽车制造”的系列里，我更愿意把这件事说得直白一点：

稳定性不是“IT 的加分项”，而是制造现场引入 AI 自动化的前提条件。

因为车间并不在乎你用的是哪家大模型，它只在乎“喊一句能不能立刻响应、能不能继续流转”。

429 限流三种形态：RPM、TPM、模型过载

**429 不是一种限流，而是三种。**你得知道自己到底撞上了哪一种，否则优化会南辕北辙。

1) RPM（Requests Per Minute）：多应用共享配额最容易踩坑

结论先给：如果同一模型同一区域被多个应用共享，必须做“预算制”的限流，而不是“谁先抢到算谁的”。

在汽车制造企业里，常见共享模型调用的来源可能包括：

• 产线语音助手（高并发、短请求）
• 质检文本结构化（中等并发、输出较长）
• 研发文档问答/总结（低频但可能大上下文）
• 夜间批处理（集中爆发）

很多团队在申请配额时会做一个“均值叠加”：A 50 rpm + B 50 rpm + C 50 rpm = 150 rpm，然后觉得安全。问题在于制造现场的流量不是平的：换线、故障、盘点、审核、供应链异常，都会在同一分钟内形成尖峰。

工程上更靠谱的做法：

• 给每个调用方设定硬上限（per-app budget），避免“噪音客户端”把别的业务挤死。
• 429 发生时，用指数退避 + 抖动（jitter），并且让重试尽量落在下一个 60 秒配额窗口。
• 用 CloudWatch 看“真实峰值”而不是平均值，然后再去申请更合理的配额。

一句话：你需要的是峰值工程，不是均值工程。

2) TPM（Tokens Per Minute）：车厂最常见的隐形瓶颈

结论先给：制造业一旦把“长文本/长语音转写/批量总结”接入工作流，TPM 比 RPM 更容易先爆。

两个典型场景：

• 质检员把一段长描述或整段对话转写贴进助手，让 AI 生成 8D 报告初稿。
• 供应商异常处理，把一堆邮件线程、会议纪要、来料检验报告一次性丢给模型“总结并给动作清单”。

请求数可能不多，但 tokens 一下子飙升。于是你看到的不是“Too many requests”，而是：Too many tokens。

应对策略更偏“配额会计”：

• 记录每次调用的 InputTokenCount / OutputTokenCount，把它当成成本和稳定性的共同指标。
• 做token-aware 限流：不是只数请求，而是维护一个 60 秒滑动窗口，预算不够就排队。
• 把大任务切块：例如把长报告按章节摘要，再二次汇总；把长对话按时间段处理。
• 需要流式输出（streaming）的地方就用起来：你可以在得到足够信息后提前停止生成，避免无意义的超长输出。

我自己的立场很明确：“无限上下文”对车间不是优势，稳定可控才是。

3) 模型过载（Model-specific throttling）：要把降级设计成产品能力

结论先给：把“模型备选路线”当作产品能力公开，而不是事故时的临时脚本。

如果错误提示类似“model is currently overloaded”，说明你的账户配额可能没问题，是该模型在该时段被大家挤爆了。

这时候最有效的不是疯狂重试，而是：

• 模型回退（fallback）：给每个任务定义“优先模型列表”，例如主模型用于高质量输出，备用模型用于保证响应。
• 跨区域推理（Cross-Region Inference）：在允许的数据驻留边界内，把流量导向更空闲的区域。
• 在观测里显式标注“当前处于降级模式”：别让降级静悄悄发生，否则你会在质量投诉里才知道。

对一线语音助手来说，降级策略尤其重要：

宁可回答变短、变保守，也别让对话断掉。

503 服务不可用：很多时候问题出在你的连接池

503 的第一排查点不是 Bedrock，而是你的客户端并发配置。

在高并发的语音助手或自动化工作流里，一个常见反模式是：

• 每次请求都新建一个 boto3 client
• 默认连接池太小（常见默认值约 10）
• 并发上来后，连接池先被打满，于是出现“Too many connections”一类的 503

这类问题的特点是：你扩容应用实例反而更糟，因为连接数涨得更快。

正确姿势：

• 进程/容器内复用同一个 client
• 把 max_pool_connections 提升到与并发匹配的量级（例如 50 起步，按压测调整）
• 将重试次数设成合理范围，避免长尾阻塞

而当 503 真的是服务端短期容量压力时（例如某时段需求激增），你需要：

• 更“慢”的指数退避（别和服务端硬碰硬）
• 配合熔断（circuit breaker）快速失败，保护整体工作流
• 必要时启用跨区域策略或备用模型

把“重试、限流、熔断”做成可复用组件（别散落在业务代码里）

**稳定性最怕“每个团队各写一套”。**最有效的方式是把调用 Bedrock 的韧性逻辑封装成 SDK wrapper 或内部网关层，让所有应用共享同一套策略。

指数退避 + 抖动：处理 429/503 的基本功

一个实用原则：

• 429：重试要跟着 60 秒配额窗口节奏走，避免在同一分钟里重复撞墙。
• 503：重试更像“等服务恢复”，退避可以更长，重试上限更保守。

如果你的语音助手是实时交互，建议再加一条：超过用户可感知阈值就别硬等。例如：

• 1.5 秒内没拿到结果就切到备用模型
• 或者先返回“已收到，我在处理”，再异步推送结果到工单/看板

Token-aware 限流：让“长任务”不把“短对话”挤死

制造现场的交互通常是短平快（报修、查询、确认），而后台总结类任务可能超长。两者混在同一个 TPM 预算里，很容易出现“夜间批处理把白天交互拖死”。

我建议的做法是把预算分层：

• 实时对话：预留固定 TPM/RPM 预算，不允许被批处理占用
• 批处理：有自己的队列与速率，必要时延后

你可以用两条队列或两套 limiter，成本不高，但稳定性提升非常明显。

熔断器：让故障变小，而不是扩散

熔断的目标不是“让调用成功”，而是“让系统不被失败拖垮”。

当 503 连续发生，继续发请求只会：

• 增加排队与超时
• 占满线程/连接
• 让上游（例如工单系统、语音网关）一起变慢

熔断器的价值在制造业尤其大，因为车间系统经常是“一个慢，全线慢”。你希望在服务不可用时：

• 快速返回可解释的降级结果（例如只创建工单骨架，稍后补全）
• 保持核心流程可用

监控与告警：把 429/503 变成“可管理的指标”

你要监控的不只是错误数，而是“错误发生时业务正在做什么”。

在 CloudWatch 的指标设计上，建议把这些作为基础盘：

• InvocationThrottles：429 的直接计数
• InvocationClientErrors / InvocationServerErrors：4xx/5xx 总体趋势
• InvocationLatency：延迟对用户体验更敏感
• InputTokenCount / OutputTokenCount：TPM 诊断必备

更关键的是维度：按 ModelId、Region、以及你的“业务调用方”标签做拆分（例如 app_name、workflow_name）。否则你永远只能看到“系统在报错”，看不到“谁在制造尖峰”。

告警我建议做成三层：

• Warning：5 分钟内出现连续 429，提示“配额接近上限”
• Critical：成功率低于 95% 持续 10 分钟（直接对齐 SLO）
• Info：token 使用率超过 80% 的趋势性提示，方便提前扩容/调度

另外，日志一定要“能查出模式”。例如用 Logs Insights 拉出 5 分钟粒度的 429/503 曲线，再和并发、tokens 叠在一起，排障速度会快很多。

把稳定性落到汽车制造的自动化工作流里：一个可复制的架构

**一个靠谱的车间 AI 助手/自动化工作流，通常会把“生成式 AI 调用”放在一个可治理的层里。**你可以参考这个组合：

1. 入口层（语音网关/业务 API）：设置超时预算（例如 2 秒内必须有可用响应）
2. Bedrock 调用层（统一 SDK 或服务）：实现 429/503 分类重试、token-aware 限流、连接池复用
3. 降级层（fallback models + cross-region）：定义清晰的“降级输出标准”
4. 队列层（批处理/异步）：把长任务移出实时链路
5. 观测层（指标+日志+告警）：按业务维度拆分，能定位到具体工作流

这样设计的好处很现实：当你从一个车间推广到三座工厂，或者从“报修助手”扩展到“质量分析+供应链协同”，你不会重新经历一遍“高峰期全掉线”的学费。

下一步：用可量化的 SLO 驱动配额与架构调整

要把这套东西真正跑顺，我建议用一个简单的目标来驱动：

• 实时语音助手：P95 响应 < 2 秒，10 分钟成功率 ≥ 99%（你可以按现场容忍度调整）
• 自动化工作流：端到端成功率 ≥ 99.5%，失败必须可重放、可追踪

然后把 429/503 的处理策略变成“达标手段”：

• 429 上升：先看是否 RPM/TPM 预算分配不合理，再看是否需要申请配额
• 503 上升：先查连接池与客户端复用，再看是否需要跨区域或备用模型

如果你正在推进“AI 语音助手与自动化工作流”落地到汽车制造，我的建议是：**把韧性当成产品需求写进 PRD，而不是上线后的运维任务。**当 AI 真正进入车间，稳定性会直接决定采用率。

你现在的 AI 助手链路里，最可能先遇到的瓶颈是 RPM、TPM，还是连接池？把这个问题搞清楚，后面的扩展会轻松很多。