先说一个我踩过的真实坑。去年帮一家企业做内部知识库问答应用模型用的是 Claudedemo 阶段一切正常领导很满意于是开始全员推广。推广当天上午十点流量上来我盯着监控面板看先是偶尔冒出一两个 429紧接着错误率像坐电梯一样往上走——从 0.5% 冲到 12%工作群里已经有人在问系统是不是崩了。查了半天模型没换、prompt 没改、代码没动问题只出在一个地方平台容量边界被撞穿了。如果你也在做企业级大模型应用或者正打算把生成式 AI 接进生产系统高并发下的容量规划大概率是绕不过去的一关。这篇围绕 Amazon Bedrock 的多层容量策略聊聊我理解的生成式 AI 平台选型、配额机制、预留容量、跨区域兜底以及一套可以直接复用的压测和估算方法。内容偏实操适合正在做技术选型或刚上线没多久就被并发问题教做人的团队。1. 高并发下的容量问题在生产落地里排第一1.1 生产环境里最常见的三种容量故障先说结论生成式 AI 应用的高并发故障和传统后端服务的高并发故障表现形式完全不一样。传统服务扛不住了通常表现为 CPU 飙升、数据库连接打满、接口超时而大模型应用的故障很多时候是平台主动拒绝服务因为生成式 AI 平台的容量本质上是 GPU 算力池它不可能无限供给。我在实际项目里见过最多的三种容量故障先说清楚后面才好对症下药。第一种是直接抛限流异常。调用 Amazon Bedrock 的 InvokeModel 接口时如果超过了账号在某个区域的配额限制平台会返回 ThrottlingException也就是常见的 429。这个现象在活动推广、业务突增、定时任务集中触发时特别容易出现。症状非常直观错误率曲线突然拉升日志里全是 ThrottlingException客户端表现就是服务不可用。第二种是延迟飙升但不报错。这种比 429 更隐蔽因为从错误率看一切正常但用户的体感是模型变笨了半天不回一句话。原因是高并发下部分请求排队等待 GPU 资源平台在尽力消化单次调用延迟从平时的 2 秒一路涨到 15 秒、20 秒。如果只盯着错误率告警这类问题可能要到用户大量投诉才能被发现。第三种是成本失控。按量计费模式下并发越高、token 消耗越多账单涨得就越快。有一次我们做活动复盘发现当天调用量是平时的 8 倍成本也差不多是 8 倍。如果事前没有容量规划和预算封顶这类成功带来的意外账单会让财务侧非常头疼。这三种故障根因是同一个应用对平台容量的需求超过了账号实际可用的容量边界。1.2 模型能力和平台容量是两件不同的事很多团队初次做生成式 AI 应用时容易把注意力全部放在模型选型上——哪个模型得分高、哪个模型中文好、哪个模型支持长上下文。这些当然重要但说实话模型能力决定的是生成质量的上限而容量策略决定的是服务水平的底线。生产级落地说的从来不是 demo 跑通而是高负载下延迟可控、不报错、成本可预期。一句话类比餐厅后厨手艺再好午市高峰接待能力不够顾客照样排队。模型是那个手艺容量就是那张桌子你光请来名厨不规划餐位高并发一来照样乱套。理解了这个底层逻辑再看各个生成式 AI 平台重点就不是谁的模型跑分高而是谁提供什么样的容量机制、这些机制能不能匹配你的业务峰值。2. 选平台前先看懂三种容量模式的底层逻辑2.1 按需模式最灵活但也有最直接的边界Amazon Bedrock 默认的接入方式是 On-Demand 按需模式不用预付费、不用签承诺合同按实际消耗的 token 量计费。这对开发测试、小规模试运行来说简直不要太方便我在项目前期搭原型基本都靠它零启动成本。但按需模式有一个很容易被忽略的点它并不是无限量供应。每个 AWS 账号在每个区域、对每个基础模型都有预设的服务配额Service Quota常见的有每分钟请求数RPM和每分钟 token 数TPM两类。一旦超出配额请求就会被限流表现就是我开头说的 429。我见过不少团队栽在同一个误区里以为 API 接入就是云上资源、随取随用根本没去控制台看过配额。结果一到稍微像样的并发立刻翻车。所以按需模式适合的场景非常明确开发联调、流量波动大但整体量不大、或者作为突发流量的补充通道。2.2 Provisioned Throughput用时长承诺换容量确定性如果要支撑稳定且高吞吐的核心业务按需模式就不够看了。这时候要引入的是 Provisioned Throughput预留吞吐它的逻辑很直白你按 PTUProvisioned Throughput Units购买某个模型在某区域的专属容量买 1 个月或 6 个月平台就给你预留对应的推理资源。预留容量带来的最大好处是确定性在购买范围内不再受默认 RPM/TPM 配额限制调用延迟也明显更平稳。我们上线生产环境后核心链路全部切到了预留容量p95 延迟立刻从看运气变成可预测。代价是成本结构变了预留容量按小时计费不管你实际用没用费用照收。这就有个经典的规划难题买少了峰值扛不住买多了闲置成本白烧。这个问题后面第四章会讲怎么算。2.3 批量推理异步场景的容量逃生通道第三种模式是 Batch Inference批量推理专治量大但不着急的场景。比如批量生成商品描述、历史数据摘要、报表文案这些任务本身不要求秒级响应用批量推理接口提交任务平台会在后台排队处理通常 24 小时内出结果单位成本比实时调用低也不太占实时调用的配额压力。我个人的经验是很多团队把应该走批量的任务硬塞进实时链路白白占用宝贵的实时容量。比如夜里跑历史工单的总结生成完全可以用批量推理把白天的实时容量留给真正需要交互的场景。2.4 三种模式横向对比维度按需模式预留吞吐批量推理计费方式按 token 计费按 PTU 小时数计费按任务量计费容量保证受默认配额限制购买范围内有保证异步排队无实时保证响应延迟正常情况下秒级稳定延迟可预测小时级最长约 24 小时适合场景开发测试、小流量、突发补充核心业务、稳定高吞吐非实时批量任务选择平台时重点不是看它有没有这些模式而是看这些模式能不能自由组合。Bedrock 这里给到的灵活性是我比较看重的因为生产环境几乎永远不是单一模式打天下。3. Bedrock 多层容量策略的骨架从配额到跨区域兜底3.1 第一层把配额当地基来管理我习惯把容量策略拆成四层第一层是配额Quota管理。每个账号在每个区域对每个模型都有默认配额但注意默认配额通常只够开发测试用离生产要求差一个数量级。好在 AWS 的配额是可以申请提升的在 Service Quotas 控制台操作就行。关键点是配额提升审批需要时间不能等到上线前一天再申请。我一般会在项目启动时就提交生产预估量的配额申请预留三五个工作日的缓冲。还有个很容易踩的坑Bedrock 的配额是账号 x 区域 x 模型三个维度绑定的。同一个模型在不同区域的默认配额不一样你在 us-east-1 提了配额不代表 us-west-2 也生效。多区域规划时要逐个区域确认。3.2 第二层按需与预留混合编排让成本和弹性不再对立第二层是容量模式的选择和混合编排。纯预留容量的问题在于成本刚性买多了很心疼纯按需的问题在于没兜底峰值一来就翻车。实际生产里更合理的做法是稳态 突发混合基础流量用预留吞吐来保证突发流量用按需模式来吸收两者通过客户端路由或 API 层的 failover 逻辑配合。具体怎么做我见过比较干净的模式是主链路调用预留容量的 endpoint代码里捕获 ThrottlingException 后指数退避重试一次如果仍然被限流就降级到按需模式的 endpoint。这样稳态流量享受预留的低延迟突发流量靠按需的弹性兜住。需要注意的是按需兜底的前提是配额申请得足够不然兜底通道自己先被限流了。3.3 第三层Inference Profile 与跨区域路由构建容灾兜底第三层是区域级别的兜底这是很多团队容易忽略的维度。Bedrock 有个实用能力是 Inference Profile推理配置文件它允许你用一个统一的 endpoint让请求自动路由到配置的一组区域。这么做有两个明显好处一是某个区域出现故障或容量紧张时请求可以自动走其他区域二是多个区域的配额加在一起等效于把容量天花板抬高了一截。不过跨区域方案不是免费的午餐。首先区域间网络延迟会略微增加对于互动性极强的对话场景需要先验证是否符合用户体感预期其次要考虑数据驻留要求金融、政务类项目如果对数据出区域有硬约束这个方案得先过合规评估。3.4 第四层应用层的弹性这层成本最低但最容易被低估前三层都在平台侧第四层在应用侧很多人只盯着平台能力忘了应用层自己的弹性设计我觉得这是最可惜的部分因为它的成本最低、见效最快。应用层的弹性至少包含四件事。一是重试策略对限流错误要做带抖动的指数退避防止所有客户端在同一时间点集体重试造成重试风暴。二是有损降级核心模型被限流时备选模型顶上设计一些兜底话术总比直接报错好。三是缓存Prompt Caching 这类能力可以把长上下文的通用前缀缓存下来节省大量重复 token 消耗这等于变相扩容。四是削峰填谷把不适合实时的任务丢到消息队列里慢慢消化别让它挤占实时链路容量。我服务过的一个客户高峰期 60% 的请求都命中了 prompt 缓存实际消耗的 token 量直接砍半这就等于在不买任何新容量的情况下硬生生把系统吞吐能力翻了一倍。4. 峰值承接的容量估算与压测验证4.1 一套可以落地的估算公式容量规划最常被问到的问题就是我到底该买多少预留容量先说结论没人能给你精确答案但有一套估算方法能让误差控制在合理范围。核心是把业务指标换算成平台容量指标也就是把并发用户数换算成每分钟请求数RPM和每分钟 token 数TPM。简化公式是这样的并发请求吞吐量 QPS 活跃并发数 / 平均响应时间秒RPM QPS × 60TPM RPM × 平均单次请求消耗 token 数输入 输出举个例子。假设一个企业知识库问答应用推广期间活跃并发是 300平均响应时间 5 秒平均单次请求消耗 2000 input token 1000 output token也就是 3000 token。那么QPS 300 / 5 60RPM 60 × 60 3600TPM 3600 × 3000 10,800,000约 1080 万 token / 分钟这个数字是什么概念呢绝大多数账号的默认 TPM 配额只有几十万级别离千万级别差了一两个数量级。所以要想扛住这种峰值预留吞吐、跨区域分摊、prompt 缓存三者几乎缺一不可。这里要提醒一句估算结果拿来定数量级和做预算够了但别当成精确值。真实业务的 token 消耗波动非常大长文档问答一个请求可能吃掉几万 token简单闲聊可能只有几百。更靠谱的做法是上线前用真实业务数据做小流量采样拿采样结果修正估算模型。4.2 压测要盯住的四个核心指标容量估算做完必须用压测验证。我在生产项目里主要盯四个指标顺序很重要。第一个是 ThrottledCount限流次数。这个指标能直接告诉你容量边界在哪压测时可以按梯度加压先 50 并发跑 10 分钟再 100、200 往上加每当限流次数开始明显增长说明触及了当前配置的容量边界。第二个是 InvocationLatency看 p50、p95、p99 三个分位数。p50 反映正常体验p95 反映大多数用户的体感上限p99 反映极端情况。生成式 AI 的 token 是流式生成的所以延迟天然比普通 API 高关键是看延迟在压力升高时是否失控。第三个是 TokenCount分输入和输出分别统计。它用来验证成本模型也用来对比缓存命中前后的 token 消耗变化。缓存配置到位的话压测时会看到输入 token 大幅下降。第四个是端到端错误率。注意是端到端不是只看网关层很多错误发生在上游模型调用层会被客户端感知成超时或空响应。错误率要跟限流次数、延迟一起看才能区分是容量不足还是代码 bug。压测工具方面自己写脚本压 InvokeModel 接口完全可行也可以用开源的负载工具包装成 HTTP 压测。我更推荐直接在代码里写好压测脚本配合 AWS CloudWatch 的指标看板一边加压一边盯指标效率高得多。4.3 一次调优实例业务峰值前后的容量变化结合上面这些方法给一个简化但真实的调优过程复盘你会更清楚这套策略怎么落地。项目是一个企业内部运营助手上线前评估峰值大约 200 并发按公式估算需要约 2400 RPM、720 万 TPM。初始配置是全部走按需模式配好默认配额其他啥也没动。压测到 80 并发左右ThrottledCount 开始出现加到 150 并发限流比例超过 5%p95 延迟从 2 秒涨到 9 秒。数据说明默认配置连目标峰值的一半都接不住。调整分四步走。第一步提交配额提升申请把目标区域的核心模型 RPM/TPM 配额提到预估峰值的 1.5 倍给突发留余量。第二步按稳态流量的 60% 购买预留吞吐剩余的 40% 交给按需兜底。第三步开启 prompt 缓存把知识库通用前缀、系统提示词全部走缓存实测输入 token 消耗下降约 40%。第四步配置跨区域 Inference Profile把另一个区域作为容灾和额外容量池。调整完后重新压测200 并发下错误率归零p95 延迟稳定在 3 秒左右p99 在 5 秒以内整体达到预期。成本侧预留容量 缓存把单位请求成本压了下来峰值当天的费用也控制在预算范围里。这四步的先后顺序是有讲究的先抬配额地基再补预留容量再用缓存降低消耗最后用跨区域兜底每一步都在为下一步减压。5. 落地几个月后我总结的几个操作经验5.1 预留容量不是越多越好要学会算利用率很多团队踩过同一个坑预算充足预留容量直接按峰值上限买结果 90% 时间利用率不到 20%大量资金烧在闲置资源上。我的建议是预留容量按稳态流量买不按瞬时峰值买峰值那部分靠按需和跨区域去吸收。另外预留容量通常是按月或半年承诺采购时先用短周期验证业务模型确认流量结构稳定后再签更长的周期单位成本会更划算。这里有个隐形成本容易被忽略预留容量买多了意味着资源利用率低不是一次性的浪费而是每小时都在持续烧钱这才是最疼的。5.2 最后想强调的三个容易被忽略的细节第一个细节是测试环境也会被限流。Bedrock 的配额是按账号维度计算的测试环境跑压测同样消耗生产环境的配额如果不做隔离测试压测可能直接打爆生产容量。有条件的话测试账号和生产账号分开或者压测避开业务高峰时段。第二个细节是监控告警一定要前置。容量告警不能等到业务上线后再补我在上线前就配好了三组告警限流数量超阈值、p95 延迟超阈值、按需模式请求占比异常升高。第三组告警特别有用它能在按需兜底通道开始承载大量请求时提醒你说明预留容量可能不够了。第三个细节是日志里一定要带上模型 ID、区域、请求 ID。峰值出问题时复盘需要精确知道每个请求走了哪个模型、哪个区域、哪条链路没有这些字段问题分析只能靠猜。这个习惯让我在好几次容量事故复盘里少走了大量弯路。对我个人来说做生成式 AI 应用这一年多最大的体会是模型选型决定产品能不能做出来容量策略决定产品能不能活下来。Amazon Bedrock 这套多层容量策略的优势不在某一个单一功能而在它把配额、预留、批量、跨区域、生态可观测性组合成了一个能按业务节奏灵活伸缩的体系。理解这套体系比追逐任何单一的高并发特性都重要。