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