這兩年做生成式 AI 應(yīng)用落地大家基本都卡在同一個地方Demo 跑通了效果也驚艷但一上生產(chǎn)就被并發(fā)打懵。尤其是企業(yè)內(nèi)部的大模型應(yīng)用表面看是調(diào)用幾個 API實(shí)際背后全是容量規(guī)劃、性能兜底和成本博弈的問題。我這一年幫幾家企業(yè)從原型推到了生產(chǎn)級繞了不少彎路也積累了一些實(shí)打?qū)嵉慕?jīng)驗(yàn)。今天專門聊聊 Amazon Bedrock 這套多層容量策略——它不是簡單的“開個高配額”就完事而是需要你根據(jù)業(yè)務(wù)場景把不同層級的容量手段組合起來用才能真正扛住峰值流量。這篇文章適合正在做生產(chǎn)環(huán)境架構(gòu)設(shè)計、被高并發(fā)折磨過、或者準(zhǔn)備把生成式 AI 應(yīng)用推向大規(guī)模使用的團(tuán)隊(duì)。我會從容量痛點(diǎn)、Bedrock 的容量模型、選型思路到實(shí)際落地時的參數(shù)測算和排障經(jīng)驗(yàn)一層層拆開講保證你能直接照著做而不是看完還是一頭霧水。1. 生產(chǎn)級 AI 應(yīng)用的容量難題到底難在哪1.1 你以為的“調(diào) API”和實(shí)際生產(chǎn)差距有多大很多人第一次接觸大模型 API 時覺得這不就是個 HTTP 調(diào)用嘛POST 一個 prompt 過去拿到 response 就完事了。早期做驗(yàn)證確實(shí)是這樣但在生產(chǎn)環(huán)境里事情完全不是同一個量級。先看一個最常見的場景企業(yè)內(nèi)部的知識庫問答助手。用戶在網(wǎng)頁端輸入問題后端要先把問題做向量化檢索再把檢索結(jié)果塞進(jìn) prompt 里拼好最后調(diào)用大模型生成答案。聽起來邏輯不復(fù)雜但如果這家企業(yè)有 5000 名員工同時使用高峰期每分鐘可能就有幾百上千次請求。再疊加一些批量處理的場景比如凌晨跑批量總結(jié)、自動生成周報、批量分析客服對話QPS 一下子就上去了。在 Bedrock 這類托管服務(wù)上你調(diào)用的是共享的基礎(chǔ)設(shè)施。如果沒有容量規(guī)劃突發(fā)流量來時你會直接撞上服務(wù)的限流閾值返回ThrottlingException。這還不是最頭疼的——真正的問題是大模型響應(yīng)是流式的每次請求要持續(xù)幾秒到幾十秒不等。你的服務(wù)端連接數(shù)、內(nèi)存、超時設(shè)置全都要跟著變。傳統(tǒng)后端那套“加個線程池、擴(kuò)個副本”的思路在這里并不完全適用。1.2 高并發(fā)背后隱藏的三類典型風(fēng)險我自己踩過的坑總結(jié)起來就三類每一類都能讓線上應(yīng)用當(dāng)場翻車。第一類是限流與排隊(duì)。Bedrock 服務(wù)端對不同型號的模型有不同的默認(rèn)配額比如On-Demand模式下Claude 3 Sonnet默認(rèn)的每分鐘請求數(shù)RPM和每分鐘 token 數(shù)TPM都有上限。超出后會先排隊(duì)隊(duì)列滿了直接拒絕。你的應(yīng)用層如果沒有做重試和退避一批請求失敗會連鎖觸發(fā)調(diào)用方超時用戶體驗(yàn)瞬間崩盤。第二類是單點(diǎn)超時與長時間占用。大模型生成是流式的一個長文檔總結(jié)請求可能會持續(xù) 30 秒以上。你的網(wǎng)關(guān)、負(fù)載均衡器、應(yīng)用服務(wù)器的超時時間都是按普通 API 設(shè)置的比如 10 秒。結(jié)果就是模型還沒生成完網(wǎng)關(guān)先把連接斷了前端只拿到半截內(nèi)容。這種問題隱蔽性極高日志里看不到 5xx 錯誤但用戶就是覺得“回答老是中斷”。第三類是成本失控。生產(chǎn)級流量下每次都按 On-Demand 價格計費(fèi)高峰期一沖月底賬單直接爆炸。我有一次給客戶做壓力測試一個下午的流量就跑出了平時一個月的費(fèi)用。容量策略不只是技術(shù)問題更是成本控制的核心手段。2. 拆解 Amazon Bedrock 的多層容量體系2.1 默認(rèn) On-Demand 模式的真實(shí)邊界在哪里對大多數(shù)剛開始上生產(chǎn)的團(tuán)隊(duì)來說第一次接觸 Bedrock 容量相關(guān)功能碰到的就是 On-Demand 模式。這個模式的好處是零前置成本開通就能用按量付費(fèi)適合快速驗(yàn)證和低頻場景。但它的邊界很明確所有請求共享一個區(qū)域的模型池子AWS 根據(jù)整個區(qū)域的負(fù)載動態(tài)調(diào)度。你的應(yīng)用流量如果和其他大客戶的時間段重疊比如都在早 9 點(diǎn)到晚 6 點(diǎn)的業(yè)務(wù)高峰窗口池子的吞吐能力會被分?jǐn)?。默認(rèn)配額一般看起來“夠用”但生產(chǎn)環(huán)境很快就會撞墻。比如默認(rèn)的Claude 3 Haiku配額可能是每分鐘幾百個請求當(dāng)你接入多個業(yè)務(wù)線、服務(wù)多個前端應(yīng)用時單一模型 key 的 RPM/TPM 很快就會被吃干榨凈。這時候你可能想到去提配額工單提升 RPM 和 TPM。但要注意提配額不代表有物理容量它只是告訴你“你最多可以打到這個量”實(shí)際的物理容量能不能支撐取決于區(qū)域資源是否充足。2.2 Provisioned Throughput為關(guān)鍵業(yè)務(wù)鎖定專屬算力如果要承載真正的生產(chǎn)級高并發(fā)Provisioned Throughput才是核心手段。它的本質(zhì)很簡單你預(yù)先購買一定數(shù)量的模型單元每個單元對應(yīng)固定的吞吐量AWS 會為這些單元預(yù)留物理算力保證你隨時能打到這個吞吐上限。這有點(diǎn)像包場和拼桌的差別。On-Demand 是拼桌運(yùn)氣好位置多運(yùn)氣不好就得等Provisioned Throughput 是包場這個位置永遠(yuǎn)給你留著別人再擠也占不了。配置方式上你可以選擇按模型單元購買也可以使用Provisioned Throughput的按量模式在 1 小時或 6 小時的窗口內(nèi)動態(tài)購買容量。前者適合長期穩(wěn)定的生產(chǎn)負(fù)載后者適合有明確時間窗口的短期峰值比如促銷活動、財報季集中分析、年末總結(jié)批量任務(wù)等。這里有幾個關(guān)鍵參數(shù)你得留意一個模型單元包含的token/分鐘吞吐量不同模型差別很大購買數(shù)量決定了你的并發(fā)天花板選擇需要綁定一個或多個可用區(qū)跨 AZ 部署能進(jìn)一步提升可用性。我之前幫客戶做金融場景的合規(guī)項(xiàng)目時甚至需要把容量單獨(dú)放在指定的 AWS 賬號和 VPC 里通過 PrivateLink 訪問這個在合規(guī)審計上是硬性要求。2.3 應(yīng)用層 Auto Scaling動態(tài)應(yīng)對不可預(yù)測的流量波動生產(chǎn)環(huán)境的流量不會永遠(yuǎn)平穩(wěn)尤其是企業(yè)內(nèi)部門戶月初、季初、有活動推廣時流量可能突然翻幾倍。如果買了固定數(shù)量的 Provisioned Throughput流量低谷時算力閑置流量高峰時又不夠用非常尷尬。Bedrock 提供了一組和計算服務(wù)類似的彈性能力可以和 Provisioned Throughput 配合按利用率或請求量自動增減模型單元。你可以配置一個CloudWatch Alarm比如當(dāng) TPUThroughput Processing Unit利用率持續(xù) 5 分鐘超過 70% 時擴(kuò)容一個單元低于 30% 時縮容一個單元。這樣即使流量是“脈沖式”的系統(tǒng)也能自己調(diào)整。但經(jīng)驗(yàn)之談自動伸縮策略需要預(yù)熱時間。模型單元的擴(kuò)容不是秒級生效尤其跨實(shí)例分配時可能需要十幾分鐘才能真正完成。所以如果你的流量是“分鐘級暴漲”的類型單純靠自動伸縮不夠還得配合分層限流、優(yōu)先級隊(duì)列把非關(guān)鍵任務(wù)擋在高峰期之外。3. 容量測算與選型怎么判斷自己需要多少算力3.1 從業(yè)務(wù)指標(biāo)倒推容量需求的完整演算過程很多團(tuán)隊(duì)一上來就問“我應(yīng)該買多少個單元”這是個偽命題。正確的姿勢是從業(yè)務(wù)指標(biāo)倒推假設(shè)你的業(yè)務(wù)場景是客服對話摘要。峰值時段每小時大約有 2000 通對話每通對話平均 50 輪消息但只需要在對話結(jié)束后對整段內(nèi)容總結(jié)一次。同時實(shí)時對話中還有一個人工智能輔助回復(fù)功能每輪消息都要調(diào)用模型生成建議回復(fù)。先算摘要場景每小時 2000 次請求每次請求輸入約 5000 token輸出約 1000 token。換算到每分鐘就是約 33 次請求輸入 165,000 token/分鐘輸出 33,000 token/分鐘。再算輔助回復(fù)每通對話 50 輪每小時就是 100,000 輪消息假設(shè)只有 20% 需要實(shí)時代理解析那就是 20,000 次/小時約 333 次/分鐘。每次輸入 300 token輸出 150 token那就是約 100,000 token/分鐘輸入50,000 token/分鐘輸出。兩項(xiàng)相加每分鐘請求數(shù)約 366輸入 TPM 約 265,000輸出 TPM 約 83,000。這時候你就拿這個數(shù)字去對標(biāo)模型單元規(guī)格。不同模型的單單元吞吐不同以 Sonnet 為例單單元大致能支撐 5,000 token/分鐘的輸出量級具體以官方文檔為準(zhǔn)那輸出側(cè)就需要約 17 個單元。實(shí)際設(shè)計時還要考慮 20%-30% 的峰值 Buffer所以建議起步 20-22 個單元。3.2 On-Demand、Provisioned、Batch 三種模式怎么組合最科學(xué)很多人的第一反應(yīng)是“那我全上 Provisioned 不就行了”。等等別急。三種模式有各自的適用場景合理組合才能既省成本又保穩(wěn)定。On-Demand 適合的是低頻、不可預(yù)測、對延遲不敏感的場景。比如內(nèi)部開發(fā)測試、偶爾一次的數(shù)據(jù)分析調(diào)用、一些周邊小工具集成。這里沒有前置成本用多少付多少。Provisioned Throughput 適合高峰值、穩(wěn)定、延遲敏感的核心鏈路。比如用戶實(shí)時對話、在線客服、實(shí)時翻譯、代碼助手等。這里強(qiáng)調(diào)的是一致性和低延遲每個請求都要在秒級返回。Batch 模式適合離線大規(guī)模數(shù)據(jù)處理。比如把所有歷史工單做一遍摘要、批量生成營銷文案、跑一批數(shù)據(jù)分析報告。Batch 沒有實(shí)時性要求系統(tǒng)會把任務(wù)加入隊(duì)列再以最大吞吐執(zhí)行價格通常比實(shí)時調(diào)用便宜不少。一個穩(wěn)妥的組合策略是核心鏈路用 Provisioned 保底突發(fā)流量用 On-Demand 兜底離線分析用 Batch 省錢。三者不是互斥關(guān)系而是互補(bǔ)關(guān)系。4. 生產(chǎn)落地的架構(gòu)設(shè)計與實(shí)操記錄4.1 一套可復(fù)用的高并發(fā)接入層架構(gòu)參考我現(xiàn)在的標(biāo)準(zhǔn)做法是在 Bedrock 前加一層統(tǒng)一的接入服務(wù)名字叫GenAI Gateway。它承擔(dān)幾個職責(zé)路由轉(zhuǎn)發(fā)、協(xié)議轉(zhuǎn)換、流量控制、密鑰管理、審計日志。接入層收到應(yīng)用請求后先做身份認(rèn)證和權(quán)限校驗(yàn)然后根據(jù)業(yè)務(wù)類型選擇對應(yīng)的模型和容量類型。比如內(nèi)部員工助手走 Provisioned 資源公共問答機(jī)器人走 On-Demand跑批任務(wù)則推到 SQS 隊(duì)列異步調(diào)用 Batch 模式。關(guān)鍵點(diǎn)在流量控制。應(yīng)用層限流用的是令牌桶算法每秒鐘放行一定數(shù)量的請求進(jìn)入 Bedrock。當(dāng)桶里令牌耗盡新的請求直接返回 429由前端做友好提示。這個比把壓力全丟給底層服務(wù)要優(yōu)雅得多。# 偽代碼示意網(wǎng)關(guān)層限流與路由 def handle_request(user_id, biz_type, payload): if not rate_limiter.allow(biz_type): return error(429, Too many requests, slow down) if biz_type realtime_assist: model_id get_model_for_provisioned() response bedrock.invoke_model_with_provisioned(model_id, payload) elif biz_type batch_summary: sqs.send_message(batch-queue, payload) return ok(task accepted) else: response bedrock.invoke_model_on_demand(payload) return response4.2 參數(shù)調(diào)優(yōu)與流式響應(yīng)的處理經(jīng)驗(yàn)流式響應(yīng)是生產(chǎn)環(huán)境最容易出錯的地方。大模型生成答案是一個 token 一個 token 往外蹦的你的應(yīng)用層必須支持流式解析不能等全部生成完才返回。這里有兩個參數(shù)值得反復(fù)調(diào)max_tokens和temperature。建議每個業(yè)務(wù)場景都單獨(dú)設(shè)置而不是全局用一個默認(rèn)值。像代碼生成場景max_tokens往往需要設(shè)置得比較大不然生成到一半就被截斷了代碼無法編譯而像情感分析這種輸出很短的場景max_tokens設(shè)太大不僅是浪費(fèi)還會拖慢首 token 的響應(yīng)時間。我踩過的坑是內(nèi)部某個服務(wù)不管什么請求都設(shè)置了max_tokens 4096結(jié)果 80% 的請求實(shí)際輸出都不超過 200 token。模型端還是按照 4096 的上限預(yù)留資源高峰期吞吐量直接掉了將近一半。后來按場景精細(xì)配置吞吐瞬間提升。另外流式響應(yīng)的超時設(shè)置要放寬。普通 API 的 10 秒超時不能直接套用我一般會在網(wǎng)關(guān)層設(shè)置 120 秒的流式會話超時同時通過心跳機(jī)制判斷鏈路是否存活。4.3 可觀測性建設(shè)只看 CloudWatch 遠(yuǎn)遠(yuǎn)不夠生產(chǎn)環(huán)境不能靠猜。Bedrock 默認(rèn)的指標(biāo)能幫你看到調(diào)用量、延遲、錯誤率但這些遠(yuǎn)遠(yuǎn)不夠。我強(qiáng)烈建議在接入層做全鏈路追蹤從用戶請求進(jìn)入網(wǎng)關(guān)到模型開始輸出到流式返回結(jié)束每一段消耗的時間和狀態(tài)都要有日志記錄。尤其是要區(qū)分“排隊(duì)等待時間”和“模型生成時間”。如果排隊(duì)時間長說明容量不夠如果生成時間長說明模型參數(shù)或 Prompt 設(shè)計可能有問題如果網(wǎng)絡(luò)傳輸慢就要檢查 VPC 和 PrivateLink 的帶寬配置。我還習(xí)慣給每個請求生成一個唯一的request_id從網(wǎng)關(guān)到 Bedrock 再到存儲層全鏈路傳遞。排查問題的時候拿著這個 ID 一查就能定位到是哪個環(huán)節(jié)出問題。CloudWatch Logs Insights 可以按 request_id 檢索非常方便。5. 常見限流與容量問題排查實(shí)錄5.1 遇到 ThrottlingException 應(yīng)該怎么查生產(chǎn)中發(fā)現(xiàn)某個接口頻繁報ThrottlingException第一件事不是加大容量而是要搞清楚瓶頸在哪個層面。先看 Bedrock CloudWatch 指標(biāo)里ThrottledCount和InvocationCount的曲線。如果限流在高峰期穩(wěn)定出現(xiàn)基本就是容量到了瓶頸如果只是偶爾零星出現(xiàn)可能是某次突發(fā)流量觸碰了配額也可能是你某個重試機(jī)制的邏輯問題。再檢查你的調(diào)用代碼是否有合適的重試與退避機(jī)制。很多 SDK 默認(rèn)自帶指數(shù)退避但如果你用了自定義 HTTP 調(diào)用就得自己實(shí)現(xiàn)。我之前見過一個項(xiàng)目重試邏輯寫得不對失敗后立即重試結(jié)果把已經(jīng)過載的服務(wù)打得更滿了產(chǎn)生了“限流雪崩”。5.2 配額已提升但依然限流問題出在哪有客戶來問過我提交了配額提升請求RPM 從 100 提到了 500為什么測試時每分鐘超過 300 還是報錯這類問題要查兩個地方第一配額提升是不是真的在所有區(qū)域都生效了Bedrock 的配額是按區(qū)域設(shè)置的你在 us-east-1 提了如果在 ap-northeast-1 調(diào)用配額還是原來的第二你用的是不是同一個模型平臺 IDBedrock 有多個推理配置文件不同 profile 有獨(dú)立的配額限制。還有一種隱藏比較深的情況你的請求里有大報文。某次請求輸入了一個超長文檔單個請求消耗的 token 數(shù)巨大。此時雖然請求數(shù)沒有超過 RPM 限制但 token 總數(shù)已經(jīng)超過了 TPM 限制一樣會被限流。這種情況下你需要優(yōu)化 Prompt 長度把不必要的歷史信息截斷或者把長文檔切塊后分批處理。5.3 模型單元利用率不均導(dǎo)致局部過載在配置多個模型單元時要注意流量調(diào)度是否均勻。Bedrock 的容量分配機(jī)制會根據(jù)請求的 token 大小智能分發(fā)但如果你的請求模式比較單一——比如全是長輸入短輸出——那某些單元可能承載了更多的 token 處理量整體利用率出現(xiàn)“虛假均衡”某個單元的實(shí)際負(fù)載已經(jīng)接近上限。建議多關(guān)注每個單元的Usage指標(biāo)而不是只看整體平均值。必要時可以把不同類型的業(yè)務(wù)拆分到不同的 Provisioned 資源里比如代碼生成一類、對話總結(jié)一類互不干擾。6. 實(shí)戰(zhàn)中的經(jīng)驗(yàn)教訓(xùn)與成本優(yōu)化建議6.1 項(xiàng)目里踩過的幾個典型坑過去一年我在生產(chǎn)環(huán)境摸爬滾打有幾個教訓(xùn)特別深刻第一不要只依賴默認(rèn)配額。一定要提前根據(jù)業(yè)務(wù)估算流量按節(jié)奏提前至少一周提交配額提升申請。有些區(qū)域的特定模型物理庫存可能不足配額申請未必能立刻批準(zhǔn)預(yù)留時間非常重要。第二壓測不要只在低峰時段做。我們曾有次在晚間做壓測看起來性能非常理想結(jié)果白天業(yè)務(wù)高峰一跑就崩因?yàn)檫@個區(qū)域的白天空閑算力已經(jīng)被其他客戶占用晚間的容量環(huán)境完全不同。壓測必須覆蓋真實(shí)業(yè)務(wù)高峰時段。第三別忘了成本告警。生產(chǎn)環(huán)境上量后成本按小時跳漲。我建議同時設(shè)置預(yù)算告警和實(shí)際賬單異常檢測比如當(dāng)每日消費(fèi)超過預(yù)估的 150% 時自動通知到負(fù)責(zé)人。6.2 成本優(yōu)化的幾種實(shí)用方式容量規(guī)劃的目標(biāo)是快、穩(wěn)、省三者都要兼顧。在使用 Bedrock 時成本優(yōu)化有幾個方向可以挖掘按肢體模型成本梯度做路由簡單分類任務(wù)用 Haiku復(fù)雜推理任務(wù)用 Sonnet 或 Opus在保證效果的同時成本能下降一半以上。利用緩存把常見問題的結(jié)果緩存到 Redis 或 Amazon ElastiCache 中在 Prompt 完全相同或高度相似時直接返回緩存結(jié)果能顯著降低模型調(diào)用量。壓縮 Prompt用摘要壓縮歷史對話只保留關(guān)鍵信息既節(jié)省 token 費(fèi)用又降低延遲。合理利用 Batch 模式對于不緊急的任務(wù)全部改為異步批量處理成本降幅比較可觀。6.3 后續(xù)擴(kuò)展方向多區(qū)域容災(zāi)與模型自動路由如果你的業(yè)務(wù)量繼續(xù)增長單區(qū)域的容量規(guī)劃就不夠了。多區(qū)域部署是下一階段一定要考慮的方向。比如在 us-east-1 和 ap-southeast-1 各部署一套容量通過 Route 53 做基于延遲的 DNS 路由當(dāng)某個區(qū)域負(fù)載過高或出現(xiàn)故障時自動切到另一個區(qū)域。這樣不僅容量翻倍可用性也大幅提升。還有一個值得研究的方向是模型自動路由。生產(chǎn)環(huán)境里不同需求的請求對模型能力的要求差別很大簡單問題用廉價模型復(fù)雜問題用高級模型。通過引入一個輕量級的語義判斷層在請求進(jìn)入模型前先判斷難度再自動選擇最合適的模型和容量資源既節(jié)約成本又能提高整體吞吐。我個人在實(shí)際操作中的體會是Bedrock 的容量策略不是一次性配置就結(jié)束的它更像是一門持續(xù)調(diào)優(yōu)的功課。每個季度業(yè)務(wù)量在變模型版本在變成本預(yù)算也在變?nèi)萘恳?guī)劃也要跟著動態(tài)調(diào)整。希望這篇文章能幫你少走一些彎路把更多精力花在業(yè)務(wù)本身。最后再分享一個小技巧上線前一定要做一次完整的故障演練模擬容量不足時的降級方案真到出問題的時候你會發(fā)現(xiàn)預(yù)案有多重要。