處理幾十條指令時(shí)一個(gè)循環(huán)往往就能完成任務(wù)。但當(dāng)數(shù)據(jù)量增加到幾千條、幾萬(wàn)條接口限流、長(zhǎng)文本超時(shí)、結(jié)果錯(cuò)位和失敗重跑的問(wèn)題就會(huì)逐漸顯現(xiàn)任務(wù)看似一直在執(zhí)行真正完成并通過(guò)校驗(yàn)的結(jié)果卻沒(méi)有同步增加。串行處理容易把時(shí)間消耗在等待上無(wú)限制地增加并發(fā)又可能擠滿(mǎn)連接池和任務(wù)隊(duì)列。對(duì)于數(shù)據(jù)清洗、內(nèi)容生成和邏輯推理任務(wù)更實(shí)用的目標(biāo)是在質(zhì)量要求不變的前提下讓任務(wù)持續(xù)完成、失敗可以恢復(fù)、成本能夠追蹤。要做到這一點(diǎn)需要把批次大小、并發(fā)上限、質(zhì)量評(píng)估和異常處理放在同一套流程中考慮。下面沿著從參數(shù)設(shè)置到生產(chǎn)選型的順序拆解批量處理中的關(guān)鍵問(wèn)題。文中的延遲表格為示例數(shù)據(jù)用于說(shuō)明分析方法不代表具體產(chǎn)品的實(shí)測(cè)表現(xiàn)。① 核心參數(shù)解析與批量吞吐能力初探開(kāi)始調(diào)參前先區(qū)分三個(gè)容易混淆的概念批次大小batch_size一次從任務(wù)集合中取出多少條數(shù)據(jù)。并發(fā)上限concurrency_limit同一時(shí)刻最多有多少個(gè)請(qǐng)求正在執(zhí)行。吞吐量 QPS單位時(shí)間內(nèi)處理的請(qǐng)求數(shù)評(píng)估有效產(chǎn)出時(shí)還應(yīng)單獨(dú)統(tǒng)計(jì)成功完成的任務(wù)數(shù)。例如一次取出 100 條任務(wù)不代表必須同時(shí)發(fā)出 100 個(gè)請(qǐng)求。完全可以讓 5 個(gè) worker 逐條消費(fèi)這批任務(wù)以較低的資源占用完成處理。批次大小與并發(fā)上限需要分別設(shè)置。另外客戶(hù)端分批調(diào)度、服務(wù)商提供的異步批處理接口以及自部署推理引擎中的動(dòng)態(tài) batching屬于不同層面的機(jī)制。把多條指令拼進(jìn)同一個(gè)提示詞也不能直接等同于這些批處理方式。對(duì)于客戶(hù)端任務(wù)分組可以先使用一個(gè)按需讀取的分批函數(shù)。以下示例適用于 Python 3.10 及以上版本僅使用標(biāo)準(zhǔn)庫(kù)fromitertoolsimportislicedefiter_batches(items,batch_size20):iftype(batch_size)isnotintorbatch_size1:raiseValueError(batch_size 必須是正整數(shù))iteratoriter(items)whileTrue:batchlist(islice(iterator,batch_size))ifnotbatch:returnyieldbatchforbatchiniter_batches(range(53),batch_size20):print(len(batch))# 依次輸出 20、20、13這個(gè)函數(shù)只負(fù)責(zé)分組不控制并發(fā)也不調(diào)用模型。如果輸入來(lái)自生成器它會(huì)逐批讀取避免為了分組再把全部數(shù)據(jù)復(fù)制到內(nèi)存中。調(diào)參時(shí)建議先固定批次大小逐檔調(diào)整并發(fā)上限找到可用范圍后再比較不同批次的表現(xiàn)。每輪使用相近的輸入長(zhǎng)度、輸出要求和任務(wù)類(lèi)型否則很難判斷性能變化到底來(lái)自參數(shù)還是樣本差異。timeout和retry_policy也應(yīng)一并記錄。尤其要區(qū)分連接超時(shí)、響應(yīng)等待超時(shí)和整個(gè)任務(wù)的截止時(shí)間避免單次請(qǐng)求有超時(shí)限制整個(gè)任務(wù)卻因?yàn)橹貜?fù)重試遲遲無(wú)法結(jié)束。② 高并發(fā)場(chǎng)景下的響應(yīng)延遲與壓測(cè)數(shù)據(jù)解讀高并發(fā)測(cè)試不能只看平均響應(yīng)時(shí)間。P50 反映典型請(qǐng)求的耗時(shí)P95 和 P99 則幫助觀察較慢請(qǐng)求的表現(xiàn)。對(duì)于生成類(lèi)任務(wù)還要區(qū)分首次返回內(nèi)容的時(shí)間與完整結(jié)果生成時(shí)間。下面是一組用于說(shuō)明分析方法的示例數(shù)據(jù)延遲統(tǒng)計(jì)對(duì)象為成功請(qǐng)求錯(cuò)誤請(qǐng)求另計(jì)。表中的 QPS 指施加的請(qǐng)求速率不是并發(fā)請(qǐng)求數(shù)也不代表實(shí)際完成的吞吐量。請(qǐng)求速率QPSP50 延遲msP95 延遲msP99 延遲ms錯(cuò)誤率%501802102500.01001952403100.02002303505200.13003106008500.550045092015002.3如果測(cè)試目標(biāo)是 P95 不超過(guò) 700ms、錯(cuò)誤率不超過(guò) 1%那么表中的 500 QPS 檔位已經(jīng)不達(dá)標(biāo)。300 QPS 雖然滿(mǎn)足這兩個(gè)示例條件仍需結(jié)合長(zhǎng)時(shí)間運(yùn)行、突發(fā)流量以及故障恢復(fù)測(cè)試才能決定是否作為生產(chǎn)配置。讀這類(lèi)數(shù)據(jù)時(shí)最需要關(guān)注的是增加請(qǐng)求后成功完成的任務(wù)是否繼續(xù)增加隊(duì)列等待時(shí)間是否持續(xù)變長(zhǎng)。如果隊(duì)列一直增長(zhǎng)短時(shí)間內(nèi)沒(méi)有報(bào)錯(cuò)也不代表系統(tǒng)能夠穩(wěn)定承受該負(fù)載。異步非阻塞 I/O 可以減少部分等待開(kāi)銷(xiāo)但不會(huì)自動(dòng)增加服務(wù)端容量。客戶(hù)端仍需結(jié)合并發(fā)限制、請(qǐng)求速率限制和有界隊(duì)列控制任務(wù)進(jìn)入系統(tǒng)的速度。不同請(qǐng)求的資源需求可能相差很大僅憑 QPS 判斷容量也不夠。[1]生產(chǎn)余量應(yīng)由具體壓測(cè)結(jié)果決定不宜把“保持在 70%”或“保持在 80%”當(dāng)成所有系統(tǒng)通用的安全線。③ 千條指令并行處理的準(zhǔn)確率對(duì)比分析批量處理是否影響質(zhì)量需要用同一批任務(wù)做對(duì)照。僅僅確認(rèn)“底層模型相同”不足以保證輸出一致請(qǐng)求上下文、采樣參數(shù)、模型版本和結(jié)果關(guān)聯(lián)方式都可能影響最終表現(xiàn)?？梢詼?zhǔn)備 1000 條覆蓋實(shí)際業(yè)務(wù)的測(cè)試指令分別使用串行調(diào)度和受控并發(fā)運(yùn)行。兩組保持輸入、提示詞、模型配置、輸出限制和評(píng)分標(biāo)準(zhǔn)一致同時(shí)保存每條任務(wù)的原始結(jié)果。不同任務(wù)應(yīng)使用不同評(píng)價(jià)方式事實(shí)查詢(xún)檢查答案是否正確來(lái)源是否支持結(jié)論。結(jié)構(gòu)化提取檢查字段完整性、取值準(zhǔn)確性和格式合法性。邏輯判斷檢查結(jié)論及關(guān)鍵約束是否成立。創(chuàng)意寫(xiě)作檢查是否滿(mǎn)足要求并單獨(dú)評(píng)價(jià)重復(fù)度和表達(dá)多樣性。質(zhì)量報(bào)告還應(yīng)區(qū)分“請(qǐng)求成功率”和“內(nèi)容合格率”。接口返回成功只能說(shuō)明拿到了響應(yīng)不等于內(nèi)容已經(jīng)符合業(yè)務(wù)要求失敗任務(wù)也不能直接從統(tǒng)計(jì)中刪除。如果并發(fā)后出現(xiàn)答案混雜、遺漏或錯(cuò)配優(yōu)先檢查任務(wù) ID 與結(jié)果的關(guān)聯(lián)。請(qǐng)求完成順序可能與提交順序不同不能根據(jù)結(jié)果返回的位置推斷它對(duì)應(yīng)哪條輸入。對(duì)于輸出風(fēng)格趨同的問(wèn)題應(yīng)先檢查提示詞是否過(guò)于模板化以及多條任務(wù)是否被不必要地合并進(jìn)同一上下文。temperature和隨機(jī)種子的作用、支持情況需要以具體接口為準(zhǔn)不能把調(diào)整它們當(dāng)成通用修復(fù)方案。最終是否接受并發(fā)方案應(yīng)依據(jù)配對(duì)評(píng)估和重復(fù)測(cè)試而不是預(yù)設(shè)“準(zhǔn)確率差異必須小于 0.5%”之類(lèi)缺少業(yè)務(wù)依據(jù)的結(jié)論。④ 復(fù)雜邏輯任務(wù)在批量模式下的質(zhì)量表現(xiàn)復(fù)雜任務(wù)的難點(diǎn)往往在步驟依賴(lài)。例如“提取實(shí)體—關(guān)聯(lián)知識(shí)庫(kù)—生成報(bào)告”這條鏈路中后一階段需要使用前一階段的結(jié)果不能把有依賴(lài)的步驟當(dāng)成互不相關(guān)的請(qǐng)求同時(shí)執(zhí)行。更清晰的做法是按階段調(diào)度實(shí)體提取完成并通過(guò)格式校驗(yàn)后再進(jìn)入知識(shí)庫(kù)查詢(xún)查詢(xún)結(jié)果滿(mǎn)足要求后再生成報(bào)告。不同文檔之間可以并行同一文檔內(nèi)部仍需遵守依賴(lài)關(guān)系。階段結(jié)果可以存入數(shù)據(jù)庫(kù)需要緩存時(shí)也可以使用 Redis但應(yīng)明確持久化與恢復(fù)策略。每條記錄至少保存任務(wù) ID、處理階段、輸入版本、執(zhí)行狀態(tài)和結(jié)果位置。這樣報(bào)告生成失敗時(shí)可以從已完成的查詢(xún)結(jié)果繼續(xù)而不是重新執(zhí)行全部步驟。拆分階段也有代價(jià)調(diào)用次數(shù)、狀態(tài)管理和中間 I/O 都可能增加。因此需要比較端到端通過(guò)率、總耗時(shí)和單任務(wù)成本再?zèng)Q定是否拆分。不能僅憑流程更細(xì)就認(rèn)定質(zhì)量一定提升。對(duì)于帶有條件分支的任務(wù)可以根據(jù)上一階段的結(jié)果動(dòng)態(tài)路由字段缺失則補(bǔ)充提取證據(jù)不足則進(jìn)入人工復(fù)核已完成任務(wù)則跳過(guò)。單條任務(wù)失敗后應(yīng)保留可重試或待處理狀態(tài)避免因?yàn)橐粭l異常數(shù)據(jù)重跑整個(gè)批次。⑤ 典型行業(yè)應(yīng)用案例的端到端方案展示以下以?xún)深?lèi)常見(jiàn)業(yè)務(wù)說(shuō)明落地方式重點(diǎn)看處理鏈路和驗(yàn)收指標(biāo)不把假設(shè)場(chǎng)景寫(xiě)成已經(jīng)發(fā)生的客戶(hù)案例。在電商評(píng)論分析中可以先完成去重、脫敏和長(zhǎng)度檢查再批量執(zhí)行情感分類(lèi)與問(wèn)題歸因。每條結(jié)果綁定評(píng)論 ID便于追溯低置信度、標(biāo)簽沖突或格式異常的結(jié)果進(jìn)入復(fù)核隊(duì)列。如果業(yè)務(wù)還需要及時(shí)發(fā)現(xiàn)負(fù)面反饋應(yīng)讓新增評(píng)論進(jìn)入獨(dú)立的處理隊(duì)列避免被歷史數(shù)據(jù)回填占滿(mǎn)資源。歷史評(píng)論負(fù)責(zé)離線分析新增評(píng)論根據(jù)時(shí)效要求優(yōu)先處理不能因?yàn)橐淮闻蝿?wù)完成得更快就直接把系統(tǒng)稱(chēng)為實(shí)時(shí)服務(wù)。驗(yàn)收時(shí)可以關(guān)注評(píng)論處理耗時(shí)、重點(diǎn)問(wèn)題漏檢率、結(jié)果可追溯比例以及失敗后是否能夠補(bǔ)跑。這些指標(biāo)比單獨(dú)比較任務(wù)運(yùn)行時(shí)間更貼近運(yùn)營(yíng)需求。在合同條款初篩中流程可以拆為文本提取、章節(jié)切分、條款識(shí)別、證據(jù)定位和人工復(fù)核。對(duì)長(zhǎng)文檔應(yīng)保留原始頁(yè)碼或段落位置讓審核人員能夠回到原文核對(duì)而不是只拿到一段脫離上下文的風(fēng)險(xiǎn)描述。衡量這類(lèi)方案應(yīng)關(guān)注關(guān)鍵條款漏檢情況、證據(jù)定位是否正確以及每份文檔實(shí)際節(jié)省了多少?gòu)?fù)核時(shí)間。未經(jīng)真實(shí)業(yè)務(wù)驗(yàn)證不應(yīng)直接宣稱(chēng)“減少 70% 人工工作量”初篩結(jié)果也需要保留人工審核環(huán)節(jié)。⑥ 長(zhǎng)文本上下文在批處理中的邊界測(cè)試長(zhǎng)文本任務(wù)進(jìn)入批次前應(yīng)分別檢查單條請(qǐng)求的上下文限制以及提交接口對(duì)請(qǐng)求體、文件或任務(wù)數(shù)量的限制。這兩類(lèi)邊界不是一回事一個(gè)批次能提交多少條任務(wù)不代表每條任務(wù)都能使用同樣大的輸入。上下文預(yù)算通常需要考慮系統(tǒng)提示、歷史消息、文檔內(nèi)容、工具信息及預(yù)留輸出具體計(jì)算方式以接口說(shuō)明為準(zhǔn)。字符數(shù)只能用于粗略篩選正式校驗(yàn)應(yīng)盡量使用與模型匹配的 token 計(jì)算方式。按長(zhǎng)度預(yù)分組有助于安排不同任務(wù)的超時(shí)預(yù)算和調(diào)度優(yōu)先級(jí)。對(duì)于部分采用 padding 的自部署推理實(shí)現(xiàn)長(zhǎng)度分組還可能減少填充開(kāi)銷(xiāo)但托管接口內(nèi)部如何調(diào)度不能僅憑客戶(hù)端的分組方式推斷。因此長(zhǎng)短文本混合處理時(shí)可以先把短任務(wù)與超長(zhǎng)任務(wù)分開(kāi)排隊(duì)避免一批結(jié)果必須全部完成后才能進(jìn)入下一階段導(dǎo)致短任務(wù)也被慢請(qǐng)求拖住。超出上下文限制的文檔可以按章節(jié)切分必要時(shí)保留相鄰段落的重疊內(nèi)容。涉及跨章節(jié)依賴(lài)時(shí)再增加匯總步驟并讓結(jié)果附帶來(lái)源位置。摘要預(yù)處理可能丟失細(xì)節(jié)不能默認(rèn)認(rèn)為壓縮后準(zhǔn)確率不變。邊界測(cè)試不僅要檢查“是否報(bào)錯(cuò)”還應(yīng)抽查文檔開(kāi)頭、中間和結(jié)尾的信息是否被正確使用。請(qǐng)求能夠成功返回和長(zhǎng)文本內(nèi)容被完整理解是兩個(gè)需要分別驗(yàn)證的問(wèn)題。⑦ 常見(jiàn)報(bào)錯(cuò)類(lèi)型分析與避坑實(shí)操指南批量任務(wù)遇到錯(cuò)誤時(shí)先判斷它屬于暫時(shí)故障、輸入問(wèn)題還是業(yè)務(wù)狀態(tài)異常再?zèng)Q定是否重試。TimeoutError、RateLimitExceeded和PayloadTooLarge可以幫助理解錯(cuò)誤類(lèi)別但具體異常名稱(chēng)與返回結(jié)構(gòu)會(huì)因 SDK 或服務(wù)而變化。超時(shí)錯(cuò)誤檢查連接、響應(yīng)和整體執(zhí)行時(shí)間?？蛻?hù)端等待超時(shí)不代表服務(wù)端一定沒(méi)有完成任務(wù)有寫(xiě)入或提交動(dòng)作時(shí)需要核對(duì)狀態(tài)或使用冪等機(jī)制。速率限制降低發(fā)送速率并遵循接口返回的等待指示。持續(xù)配額不足與短暫限流應(yīng)分別處理不能一直盲目重試。負(fù)載過(guò)大或上下文超限先減少、切分或修正輸入原樣重發(fā)通常不會(huì)解決問(wèn)題。鑒權(quán)與參數(shù)錯(cuò)誤修復(fù)憑證、權(quán)限或請(qǐng)求字段再重新執(zhí)行。對(duì)確定可以安全重試的暫時(shí)故障可使用有次數(shù)上限的指數(shù)退避并加入隨機(jī)抖動(dòng)減少大量任務(wù)同時(shí)重試造成的壓力。[2]下面是同步任務(wù)的最小示例。RetryableError是本地定義的異常實(shí)際接入時(shí)需要將服務(wù)中適合重試的錯(cuò)誤映射到這一類(lèi)型。importrandomimporttimeclassRetryableError(Exception):僅用于已經(jīng)確認(rèn)可以安全重試的暫時(shí)故障。defexecute_with_retry(func,max_attempts3):iftype(max_attempts)isnotintormax_attempts1:raiseValueError(max_attempts 必須是正整數(shù))delay_cap0.5forattemptinrange(1,max_attempts1):try:returnfunc()exceptRetryableError:ifattemptmax_attempts:raisetime.sleep(random.uniform(0.0,delay_cap))delay_capmin(8.0,delay_cap*2)print(execute_with_retry(lambda:任務(wù)完成))這里的max_attempts3表示總共最多執(zhí)行 3 次包含第一次調(diào)用最后一次失敗會(huì)直接拋出原異常不再額外等待。非重試類(lèi)異常則立即向上傳遞。示例只展示退避邏輯沒(méi)有代替網(wǎng)絡(luò)客戶(hù)端的超時(shí)設(shè)置。實(shí)際使用時(shí)還應(yīng)處理Retry-After、任務(wù)截止時(shí)間及 SDK 自帶重試避免不同層重復(fù)重試。異步流程中則需要使用對(duì)應(yīng)的異步調(diào)用和等待方式。日志建議同時(shí)記錄批次 ID、單條任務(wù) ID、執(zhí)行次數(shù)和錯(cuò)誤類(lèi)別。Trace ID 用于追蹤調(diào)用鏈業(yè)務(wù)任務(wù) ID 用于恢復(fù)與去重兩者職責(zé)不同。重試已經(jīng)執(zhí)行過(guò)的寫(xiě)入操作時(shí)是否能夠防止重復(fù)副作用取決于服務(wù)端冪等能力和業(yè)務(wù)去重設(shè)計(jì)。[2]⑧ 成本效益核算與資源消耗分析處理速度提高不代表單條任務(wù)一定更便宜。如果使用按 token 計(jì)費(fèi)的托管接口單純把串行請(qǐng)求改成并發(fā)請(qǐng)求并不會(huì)自動(dòng)改變計(jì)費(fèi)單價(jià)如果使用專(zhuān)門(mén)的異步批處理服務(wù)則需要另行確認(rèn)它的價(jià)格、完成時(shí)限和適用接口。自部署場(chǎng)景中合理 batching 可能提高硬件利用率但收益取決于模型、輸入輸出長(zhǎng)度和推理實(shí)現(xiàn)不能直接套用“成本降低 30%—40%”這樣的固定比例。更有用的核算方式是單位合格任務(wù)成本 統(tǒng)計(jì)周期內(nèi)的總成本 ÷ 去重后通過(guò)業(yè)務(wù)驗(yàn)收的任務(wù)數(shù)?？偝杀緫?yīng)統(tǒng)一口徑包含接口或算力費(fèi)用、存儲(chǔ)與調(diào)度費(fèi)用以及需要納入核算的人工復(fù)核成本失敗、重試和重復(fù)執(zhí)行已經(jīng)產(chǎn)生的費(fèi)用也應(yīng)計(jì)入。避免把更換統(tǒng)計(jì)口徑帶來(lái)的變化誤認(rèn)為優(yōu)化效果。除了成本可以同步記錄有效產(chǎn)出速度單位時(shí)間內(nèi)究竟新增了多少條不需要返工的合格結(jié)果。如果并發(fā)翻倍但錯(cuò)誤、重復(fù)結(jié)果和復(fù)核量明顯增加整體收益可能反而下降。優(yōu)化時(shí)可優(yōu)先減少重復(fù)任務(wù)、復(fù)用穩(wěn)定的處理結(jié)果、縮短不必要的提示上下文并僅對(duì)失敗階段補(bǔ)跑。彈性擴(kuò)縮容適合負(fù)載有明顯波動(dòng)的業(yè)務(wù)但還需考慮實(shí)例啟動(dòng)時(shí)間和擴(kuò)容速度避免積壓出現(xiàn)后才開(kāi)始準(zhǔn)備資源。⑨ 不同業(yè)務(wù)規(guī)模下的適用場(chǎng)景匹配選型時(shí)數(shù)據(jù)量需要與時(shí)效要求一起看。每天幾千條長(zhǎng)文檔與每分鐘幾千條短請(qǐng)求即使總?cè)蝿?wù)數(shù)相近所需的調(diào)度方式也可能完全不同。業(yè)務(wù)場(chǎng)景優(yōu)先考慮的實(shí)現(xiàn)重點(diǎn)觀察的指標(biāo)小規(guī)模原型、偶發(fā)批任務(wù)簡(jiǎn)單分批、少量 worker、結(jié)果持久化能否恢復(fù)、格式是否合格、實(shí)際成本持續(xù)產(chǎn)生的中等規(guī)模任務(wù)有界隊(duì)列、失敗重試隊(duì)列、任務(wù)狀態(tài)管理排隊(duì)時(shí)長(zhǎng)、有效吞吐、重復(fù)執(zhí)行數(shù)據(jù)量大且有明顯峰谷按需采用托管隊(duì)列或分布式 worker、資源隔離積壓增長(zhǎng)、擴(kuò)容速度、故障恢復(fù)在線交互與即時(shí)響應(yīng)受控并發(fā)、明確超時(shí)、按需使用流式返回首次響應(yīng)時(shí)間、完整響應(yīng)時(shí)間、超時(shí)率實(shí)時(shí)交互并不意味著所有用戶(hù)的請(qǐng)求都應(yīng)串行執(zhí)行。需要避免的是為了湊滿(mǎn)一個(gè)大批次讓原本可以立即處理的請(qǐng)求額外等待。能否使用微批處理應(yīng)由實(shí)際延遲預(yù)算和部署能力決定。原型階段也可以借助 AI 工具檢查腳本、整理提示詞和設(shè)計(jì)測(cè)試樣本。有會(huì)員訂閱需求時(shí)可參考 gpt68.com 這一第三方 AI 會(huì)員充值平臺(tái)它并非相關(guān)產(chǎn)品的官方網(wǎng)站或授權(quán)合作方會(huì)員訂閱也不等于生產(chǎn)系統(tǒng)的 API 調(diào)用額度。無(wú)論使用什么輔助工具生產(chǎn)任務(wù)的容量、計(jì)費(fèi)和可恢復(fù)性仍需在實(shí)際運(yùn)行環(huán)境中驗(yàn)證。對(duì)于小團(tuán)隊(duì)先把任務(wù)狀態(tài)與失敗處理做清楚通常比過(guò)早引入復(fù)雜集群更容易獲得可維護(hù)的結(jié)果。⑩ 綜合價(jià)值判斷與最終選型建議批量處理方案是否值得采用可以用四個(gè)問(wèn)題來(lái)判斷相同質(zhì)量要求下是否完成得更快負(fù)載增加后是否仍能穩(wěn)定運(yùn)行單條任務(wù)失敗后是否能夠恢復(fù)每條合格結(jié)果的成本是否處于可接受范圍。落地時(shí)可以先建立一組具有代表性的樣本跑通低并發(fā)基線。隨后逐檔增加并發(fā)觀察延遲、隊(duì)列、錯(cuò)誤率和內(nèi)容合格率只有調(diào)度和任務(wù)恢復(fù)已經(jīng)可靠再擴(kuò)大數(shù)據(jù)量與覆蓋范圍。上線配置應(yīng)選擇經(jīng)過(guò)持續(xù)壓測(cè)、留有容量余量的檔位而不是某次短測(cè)試中出現(xiàn)的最高 QPS。生產(chǎn)運(yùn)行后還應(yīng)持續(xù)抽檢質(zhì)量并在模型、提示詞或任務(wù)結(jié)構(gòu)發(fā)生變化時(shí)重新評(píng)估容量。對(duì)開(kāi)發(fā)者而言一個(gè)可用的批處理系統(tǒng)應(yīng)該能說(shuō)清楚每條任務(wù)執(zhí)行到了哪里、結(jié)果是否合格、失敗后如何繼續(xù)。把這些基礎(chǔ)能力做好規(guī)模擴(kuò)大時(shí)才有依據(jù)判斷該增加資源、調(diào)整參數(shù)還是重新設(shè)計(jì)處理鏈路。參考資料Google SREHandling OverloadAmazon Builders’ LibraryTimeouts, retries, and backoff with jitterPython 官方文檔itertoolsOpenAI 幫助中心訂閱與 API 計(jì)費(fèi)說(shuō)明