1. 為什么2026年還要重提AI API接口安全這兩年跟不少做AI應(yīng)用的朋友聊發(fā)現(xiàn)一個(gè)挺普遍的現(xiàn)象模型能力越強(qiáng)大家越容易把注意力全放在效果調(diào)優(yōu)上接口安全反而成了“上線前隨便加個(gè)key”的附屬品。但真跑起來(lái)之后賬單暴漲、接口被刷、密鑰泄露這三件事幾乎每個(gè)團(tuán)隊(duì)都會(huì)撞上至少一件。我自己經(jīng)手過(guò)的項(xiàng)目里有半夜被異常流量打爆配額導(dǎo)致業(yè)務(wù)停擺的也有因?yàn)槊荑€硬編碼在前端被扒出來(lái)、一夜之間燒掉大幾千的。所以這篇不聊虛的就把成本控制、限流、密鑰管理這三塊拆開(kāi)講透都是能直接落地的東西。先說(shuō)清楚這篇適合誰(shuí)看。如果你正在做AI應(yīng)用的后端接入或者負(fù)責(zé)API網(wǎng)關(guān)、計(jì)費(fèi)、風(fēng)控這類模塊再或者你只是個(gè)小團(tuán)隊(duì)里那個(gè)“什么都得管一點(diǎn)”的人那這篇基本就是給你寫(xiě)的。不需要你有多深的分布式系統(tǒng)背景但至少得知道API調(diào)用是怎么回事、密鑰是干嘛用的。我會(huì)盡量把每個(gè)決策背后的“為什么”講明白而不是甩一堆配置讓你抄。核心關(guān)鍵詞就五個(gè)AI API、接口安全、成本控制、限流、密鑰。這五個(gè)詞看著簡(jiǎn)單但每一個(gè)背后都有一堆坑。成本控制不是單純省錢(qián)而是讓每一分錢(qián)花得可解釋、可預(yù)測(cè)限流不是加個(gè)閾值就完事得區(qū)分正常突發(fā)和惡意刷量密鑰管理更不是“別提交到Git”這么一句話能概括的。下面按我的實(shí)際經(jīng)驗(yàn)一塊一塊拆。2. 成本控制先搞清楚錢(qián)花在哪再談怎么省2.1 AI API的成本結(jié)構(gòu)和傳統(tǒng)接口有什么不同傳統(tǒng)后端接口的成本大頭在服務(wù)器和帶寬基本是固定成本加線性增長(zhǎng)。AI API完全不是這個(gè)邏輯。它的計(jì)費(fèi)維度通常是輸入token數(shù)、輸出token數(shù)、調(diào)用次數(shù)有些還按模型版本、是否流式返回、是否帶緩存來(lái)差異化定價(jià)。這就導(dǎo)致一個(gè)很尷尬的局面你很難在寫(xiě)代碼的時(shí)候直觀感受到“這一行會(huì)花多少錢(qián)”。我見(jiàn)過(guò)最典型的翻車(chē)場(chǎng)景是開(kāi)發(fā)環(huán)境用大模型跑測(cè)試忘了切回小模型結(jié)果一個(gè)下午的調(diào)試燒掉了生產(chǎn)環(huán)境一周的預(yù)算。還有一種是提示詞里塞了大量上下文每次調(diào)用都帶著幾千token的歷史記錄單次成本看著不高但QPS一上來(lái)就是指數(shù)級(jí)放大。所以成本控制的第一步不是“省”而是可觀測(cè)。你得先能回答三個(gè)問(wèn)題誰(shuí)在調(diào)、調(diào)了什么、花了多少。這三個(gè)問(wèn)題答不上來(lái)后面所有優(yōu)化都是瞎猜。2.2 按調(diào)用維度做成本歸因的實(shí)操方法我的做法是在網(wǎng)關(guān)層給每次請(qǐng)求打上標(biāo)簽至少包含這幾個(gè)維度調(diào)用方標(biāo)識(shí)用戶ID或服務(wù)名、模型名稱、輸入token數(shù)、輸出token數(shù)、時(shí)間戳。這些數(shù)據(jù)落到日志或者時(shí)序數(shù)據(jù)庫(kù)里后面不管是做賬單分?jǐn)傔€是異常檢測(cè)都有依據(jù)。具體實(shí)現(xiàn)上如果你用的是主流云廠商的AI服務(wù)響應(yīng)體里一般會(huì)帶token用量字段直接解析出來(lái)存就行。如果是自部署模型就得在推理層自己統(tǒng)計(jì)。這里有個(gè)細(xì)節(jié)流式返回的場(chǎng)景下token統(tǒng)計(jì)要等流結(jié)束才能拿到完整數(shù)據(jù)所以別在第一個(gè)chunk就急著記賬否則會(huì)少算。有了歸因數(shù)據(jù)之后你會(huì)發(fā)現(xiàn)成本分布往往很不均勻。我統(tǒng)計(jì)過(guò)的一個(gè)項(xiàng)目里5%的調(diào)用方貢獻(xiàn)了60%的成本其中大部分是測(cè)試賬號(hào)和內(nèi)部工具。這種時(shí)候優(yōu)化方向就很明確了給測(cè)試賬號(hào)設(shè)獨(dú)立配額、內(nèi)部工具走小模型、生產(chǎn)環(huán)境才允許調(diào)大模型。2.3 緩存和降級(jí)兩個(gè)最容易被忽視的省錢(qián)手段緩存這件事在AI場(chǎng)景下經(jīng)常被低估。很多請(qǐng)求其實(shí)是重復(fù)的或者高度相似的比如FAQ類問(wèn)答、固定格式的摘要生成。如果每次都用大模型重新算一遍純屬浪費(fèi)。我的做法是在網(wǎng)關(guān)層加一層語(yǔ)義緩存對(duì)輸入做歸一化處理后算哈希命中就直接返回緩存結(jié)果。命中率不用追求太高20%到30%就能明顯拉低整體成本。降級(jí)策略則是另一個(gè)維度。當(dāng)預(yù)算消耗達(dá)到某個(gè)閾值時(shí)自動(dòng)把部分非核心請(qǐng)求切到更便宜的模型或者更短的輸出長(zhǎng)度。這個(gè)閾值怎么定我的經(jīng)驗(yàn)是按天或者按小時(shí)設(shè)預(yù)算上限達(dá)到80%時(shí)觸發(fā)告警并開(kāi)始降級(jí)達(dá)到100%時(shí)直接拒絕非白名單請(qǐng)求。這樣至少保證不會(huì)出現(xiàn)“一覺(jué)醒來(lái)賬單爆炸”的情況。注意降級(jí)策略一定要有白名單機(jī)制核心業(yè)務(wù)請(qǐng)求不能被降級(jí)誤傷。白名單的判定邏輯建議放在配置中心支持熱更新別硬編碼在代碼里。2.4 成本控制的常見(jiàn)誤區(qū)與避坑清單第一個(gè)誤區(qū)是“只看單價(jià)不看總量”。小模型單價(jià)低但如果因?yàn)樾Ч缓脤?dǎo)致重試率飆升總成本可能反而更高。第二個(gè)誤區(qū)是“所有請(qǐng)求一視同仁”實(shí)際上不同業(yè)務(wù)線對(duì)延遲和質(zhì)量的敏感度完全不同一刀切的策略必然導(dǎo)致要么浪費(fèi)要么體驗(yàn)差。我整理了一個(gè)簡(jiǎn)單的自查清單上線前過(guò)一遍能避開(kāi)大部分坑檢查項(xiàng)合格標(biāo)準(zhǔn)常見(jiàn)問(wèn)題調(diào)用歸因每次請(qǐng)求可追溯到調(diào)用方和模型日志里只有時(shí)間戳沒(méi)有調(diào)用方預(yù)算告警按天/小時(shí)設(shè)閾值達(dá)到80%告警只在月底看賬單緩存策略至少對(duì)高頻重復(fù)請(qǐng)求做緩存全部請(qǐng)求都走實(shí)時(shí)推理降級(jí)預(yù)案有白名單和自動(dòng)降級(jí)邏輯降級(jí)靠人工手動(dòng)切測(cè)試隔離測(cè)試環(huán)境獨(dú)立配額和模型測(cè)試和生產(chǎn)共用密鑰3. 限流不是加個(gè)閾值就完事3.1 為什么AI API的限流比普通接口更復(fù)雜普通接口的限流相對(duì)簡(jiǎn)單按QPS或者并發(fā)數(shù)卡就行。AI API不行因?yàn)樗馁Y源消耗和請(qǐng)求內(nèi)容強(qiáng)相關(guān)。一個(gè)請(qǐng)求可能只花幾毫秒和幾十token另一個(gè)請(qǐng)求可能跑十幾秒和幾千token。如果只按請(qǐng)求數(shù)限流攻擊者可以用大量輕量請(qǐng)求繞過(guò)限制如果只按token限流又沒(méi)法應(yīng)對(duì)高頻短請(qǐng)求的沖擊。所以AI API的限流至少得是多維度的請(qǐng)求頻率、并發(fā)數(shù)、token消耗速率這三個(gè)維度得同時(shí)管。我一般會(huì)在網(wǎng)關(guān)層做請(qǐng)求頻率和并發(fā)控制在推理層做token速率控制兩層配合才能既防刷又保穩(wěn)。3.2 令牌桶和漏桶在AI場(chǎng)景下的選型對(duì)比令牌桶和漏桶是兩種經(jīng)典限流算法但在AI場(chǎng)景下表現(xiàn)差異挺大。令牌桶允許一定程度的突發(fā)適合那種“平時(shí)量不大但偶爾有峰值”的業(yè)務(wù)漏桶則強(qiáng)制勻速適合對(duì)穩(wěn)定性要求極高的場(chǎng)景。我的經(jīng)驗(yàn)是對(duì)外部開(kāi)放接口用漏桶對(duì)內(nèi)部服務(wù)調(diào)用用令牌桶。外部接口你沒(méi)法預(yù)測(cè)調(diào)用方行為勻速處理最安全內(nèi)部服務(wù)你知道調(diào)用模式給點(diǎn)突發(fā)余量能提升整體吞吐。具體參數(shù)上漏桶的速率建議按歷史P95流量來(lái)設(shè)令牌桶的桶容量建議設(shè)為速率的2到3倍。如果你用的是Sentinel這類現(xiàn)成的限流組件它同時(shí)支持這兩種模式而且有熔斷降級(jí)功能。配置的時(shí)候注意一點(diǎn)熔斷閾值不要設(shè)得太敏感AI接口本身延遲就高偶爾的超時(shí)是正常的如果一超時(shí)就熔斷會(huì)導(dǎo)致大量誤殺。我一般把熔斷的慢調(diào)用比例閾值設(shè)在50%以上統(tǒng)計(jì)窗口至少10秒。3.3 分級(jí)限流策略按用戶等級(jí)和業(yè)務(wù)重要性區(qū)別對(duì)待一刀切的限流策略在實(shí)際業(yè)務(wù)里往往行不通。付費(fèi)用戶和免費(fèi)用戶、核心業(yè)務(wù)和邊緣業(yè)務(wù)能給的配額肯定不一樣。我的做法是設(shè)三到四個(gè)等級(jí)每個(gè)等級(jí)對(duì)應(yīng)不同的限流參數(shù)。比如免費(fèi)用戶每分鐘10次請(qǐng)求、并發(fā)2普通付費(fèi)用戶每分鐘100次、并發(fā)10高級(jí)用戶每分鐘1000次、并發(fā)50內(nèi)部服務(wù)走獨(dú)立通道不參與限流。這些參數(shù)不是拍腦袋定的而是根據(jù)歷史用量和成本預(yù)算反推出來(lái)的。具體算法是先算每個(gè)等級(jí)愿意承擔(dān)的最大成本再除以單次調(diào)用的平均成本得到請(qǐng)求數(shù)上限最后按峰值系數(shù)打個(gè)折。分級(jí)限流的另一個(gè)好處是便于排查問(wèn)題。當(dāng)某個(gè)等級(jí)觸發(fā)限流時(shí)你能快速定位到是這類用戶整體用量上漲還是個(gè)別用戶在刷量。如果是后者可以單獨(dú)對(duì)該用戶做臨時(shí)封禁或者降級(jí)處理。3.4 限流觸發(fā)后的處理邏輯和用戶體驗(yàn)限流觸發(fā)后怎么處理這件事經(jīng)常被忽略。直接返回429當(dāng)然可以但用戶體驗(yàn)很差。我的做法是分情況如果是突發(fā)流量返回429并帶上Retry-After頭告訴調(diào)用方多久后重試如果是持續(xù)超限則降級(jí)到隊(duì)列模式把請(qǐng)求排隊(duì)處理同時(shí)返回一個(gè)“處理中”的狀態(tài)讓調(diào)用方輪詢。這里有個(gè)細(xì)節(jié)隊(duì)列長(zhǎng)度要設(shè)上限否則隊(duì)列積壓會(huì)導(dǎo)致內(nèi)存暴漲。上限的設(shè)定參考系統(tǒng)的最大處理能力和可接受延遲比如每秒處理100個(gè)請(qǐng)求、可接受延遲10秒那隊(duì)列長(zhǎng)度就設(shè)1000左右。超過(guò)上限的請(qǐng)求直接拒絕別猶豫。提示限流返回的錯(cuò)誤信息里不要暴露具體的限流參數(shù)比如“你的配額是每分鐘100次”這種話盡量別寫(xiě)。攻擊者拿到這些信息后可以更精準(zhǔn)地繞過(guò)限制。統(tǒng)一返回“請(qǐng)求過(guò)于頻繁請(qǐng)稍后重試”就夠了。4. 密鑰管理最基礎(chǔ)也最容易翻車(chē)的一環(huán)4.1 密鑰泄露的常見(jiàn)途徑和真實(shí)案例密鑰泄露這件事說(shuō)起來(lái)都是老生常談但每年還是有大量團(tuán)隊(duì)栽在上面。我見(jiàn)過(guò)的泄露途徑主要有這么幾種硬編碼在前端代碼里、提交到公開(kāi)的代碼倉(cāng)庫(kù)、寫(xiě)在客戶端的配置文件里、通過(guò)日志打印出來(lái)、在聊天工具里明文傳輸。最離譜的一次是看到一個(gè)團(tuán)隊(duì)把生產(chǎn)環(huán)境的密鑰寫(xiě)在了移動(dòng)端App的本地存儲(chǔ)里任何人反編譯一下就能拿到。還有一個(gè)常見(jiàn)的是在CI/CD的日志里打印了完整的請(qǐng)求頭里面帶著Authorization字段。這些問(wèn)題的共同點(diǎn)是開(kāi)發(fā)階段圖方便上線時(shí)忘了清理。所以密鑰管理的第一原則是永遠(yuǎn)假設(shè)密鑰會(huì)泄露提前做好泄露后的應(yīng)對(duì)預(yù)案。具體來(lái)說(shuō)就是密鑰要能快速輪換、要有使用范圍限制、要有異常檢測(cè)。4.2 密鑰分級(jí)不同場(chǎng)景用不同權(quán)限的密鑰不要把一把密鑰用得到處都是。我的做法是按場(chǎng)景分三級(jí)管理密鑰、服務(wù)密鑰、臨時(shí)密鑰。管理密鑰權(quán)限最大能創(chuàng)建和刪除其他密鑰只放在密鑰管理服務(wù)里平時(shí)不用服務(wù)密鑰給后端服務(wù)用有固定的調(diào)用權(quán)限和配額臨時(shí)密鑰給前端或者第三方用有效期很短通常幾分鐘到幾小時(shí)。臨時(shí)密鑰的發(fā)放流程一般是前端先用自己的身份憑證比如登錄token找后端換一個(gè)臨時(shí)密鑰后端驗(yàn)證身份后生成一個(gè)有時(shí)效的密鑰返回。這樣即使臨時(shí)密鑰泄露影響范圍也有限而且過(guò)期后自動(dòng)失效。服務(wù)密鑰的管理要點(diǎn)是定期輪換。輪換周期看業(yè)務(wù)敏感度我一般設(shè)30到90天。輪換的時(shí)候要注意平滑過(guò)渡先生成新密鑰讓服務(wù)同時(shí)接受新舊密鑰一段時(shí)間等所有調(diào)用方都切換過(guò)來(lái)后再禁用舊密鑰。這個(gè)過(guò)渡期至少留一周避免有些調(diào)用方?jīng)]及時(shí)更新導(dǎo)致服務(wù)中斷。4.3 密鑰存儲(chǔ)和傳輸?shù)膶?shí)操規(guī)范存儲(chǔ)方面絕對(duì)不要明文存在代碼倉(cāng)庫(kù)或者配置文件里。正確的做法是用密鑰管理服務(wù)比如云廠商提供的KMS或者Vault這類工具。服務(wù)啟動(dòng)時(shí)從密鑰管理服務(wù)拉取密鑰加載到內(nèi)存里使用不落盤(pán)。如果條件有限用不了專業(yè)工具至少也要用環(huán)境變量注入并且確保環(huán)境變量不會(huì)被日志打印出來(lái)。傳輸方面所有涉及密鑰的通信必須走加密通道。這個(gè)不用多說(shuō)但有個(gè)細(xì)節(jié)容易忽略密鑰在日志里要脫敏。我見(jiàn)過(guò)不少團(tuán)隊(duì)在調(diào)試的時(shí)候把完整請(qǐng)求頭打出來(lái)結(jié)果密鑰就留在日志系統(tǒng)里了。正確的做法是在日志中間件里對(duì)Authorization、X-Api-Key這類字段做掩碼處理只保留前幾位和后幾位。還有一個(gè)實(shí)操技巧給每個(gè)密鑰打上標(biāo)簽記錄用途、負(fù)責(zé)人、創(chuàng)建時(shí)間、上次輪換時(shí)間。這樣出問(wèn)題的時(shí)候能快速定位到是誰(shuí)的密鑰、用在哪、該找誰(shuí)處理。標(biāo)簽信息可以存在密鑰管理服務(wù)的元數(shù)據(jù)里也可以單獨(dú)維護(hù)一張表。4.4 密鑰泄露后的應(yīng)急響應(yīng)流程萬(wàn)一密鑰真的泄露了別慌按流程走。第一步是立即禁用泄露的密鑰這一步要快別想著先調(diào)查再處理先止血再說(shuō)。第二步是評(píng)估影響范圍看這個(gè)密鑰的調(diào)用記錄有沒(méi)有異常調(diào)用、有沒(méi)有數(shù)據(jù)泄露。第三步是通知相關(guān)方如果是客戶密鑰泄露得及時(shí)告知并協(xié)助輪換。第四步是復(fù)盤(pán)和改進(jìn)搞清楚是怎么泄露的補(bǔ)上流程漏洞。我建議每個(gè)團(tuán)隊(duì)都提前寫(xiě)好應(yīng)急響應(yīng)文檔把這幾步固化下來(lái)并且定期演練。真出事的時(shí)候人是慌的有文檔照著做能少犯很多錯(cuò)。5. 三塊怎么配合一個(gè)可落地的整體方案5.1 網(wǎng)關(guān)層、服務(wù)層、密鑰層的職責(zé)劃分這三塊不是孤立的得配合起來(lái)才能形成完整的防護(hù)體系。我的架構(gòu)一般是這樣的網(wǎng)關(guān)層負(fù)責(zé)限流和密鑰校驗(yàn)服務(wù)層負(fù)責(zé)成本歸因和業(yè)務(wù)邏輯密鑰層負(fù)責(zé)密鑰的生成、分發(fā)和輪換。網(wǎng)關(guān)層是流量的入口所有請(qǐng)求先經(jīng)過(guò)這里。它做三件事驗(yàn)證密鑰有效性、檢查限流配額、打上調(diào)用方標(biāo)簽。驗(yàn)證密鑰的時(shí)候順便把調(diào)用方信息查出來(lái)后面限流和成本歸因都要用。限流檢查如果通過(guò)就放行不通過(guò)就按前面說(shuō)的策略處理。服務(wù)層拿到請(qǐng)求后根據(jù)業(yè)務(wù)邏輯決定調(diào)哪個(gè)模型、用什么參數(shù)。調(diào)用完成后把token用量和調(diào)用方信息一起寫(xiě)到成本歸因的日志里。如果發(fā)現(xiàn)某個(gè)調(diào)用方的成本異?？梢杂|發(fā)告警或者自動(dòng)降級(jí)。密鑰層獨(dú)立于業(yè)務(wù)邏輯提供密鑰的CRUD接口和輪換能力。服務(wù)啟動(dòng)時(shí)從密鑰層拉取密鑰運(yùn)行過(guò)程中定期檢查密鑰是否即將過(guò)期過(guò)期前自動(dòng)輪換。5.2 監(jiān)控告警怎么知道系統(tǒng)正在被攻擊或?yàn)E用沒(méi)有監(jiān)控的防護(hù)等于沒(méi)有防護(hù)。我一般會(huì)盯這幾個(gè)指標(biāo)請(qǐng)求量突增、token消耗速率異常、密鑰調(diào)用來(lái)源異常、限流觸發(fā)頻率。這幾個(gè)指標(biāo)里任何一個(gè)出現(xiàn)異常波動(dòng)都可能是攻擊或者濫用的信號(hào)。具體閾值怎么設(shè)請(qǐng)求量可以按歷史同期的3倍作為告警線token消耗速率按預(yù)算的80%作為告警線密鑰調(diào)用來(lái)源如果出現(xiàn)新的IP段或者地區(qū)就告警限流觸發(fā)頻率如果持續(xù)高于正常水平就告警。告警渠道建議用即時(shí)通訊工具加郵件雙通道確保能及時(shí)看到。告警之后要有處理動(dòng)作不能只告警不處理。簡(jiǎn)單的處理可以是自動(dòng)限流或者降級(jí)復(fù)雜的處理需要人工介入。我建議至少做到自動(dòng)限流把異常流量先擋住再慢慢排查。5.3 從零搭建的步驟清單和優(yōu)先級(jí)如果你現(xiàn)在要從零開(kāi)始搭這套體系我建議按這個(gè)優(yōu)先級(jí)來(lái)先做密鑰管理再做限流最后做成本控制。為什么是這個(gè)順序因?yàn)槊荑€是基礎(chǔ)密鑰管不好后面都是白搭限流是防線能擋住大部分低級(jí)攻擊成本控制是優(yōu)化在前兩者到位之后做才有意義。具體步驟上第一周先把密鑰管理規(guī)范定下來(lái)包括密鑰分級(jí)、存儲(chǔ)方式、輪換周期、應(yīng)急流程。第二周在網(wǎng)關(guān)層加上密鑰校驗(yàn)和基礎(chǔ)限流。第三周加上成本歸因和監(jiān)控告警。第四周做分級(jí)限流和降級(jí)策略。一個(gè)月下來(lái)基本能形成一個(gè)可用的體系后面再根據(jù)實(shí)際運(yùn)行情況慢慢調(diào)優(yōu)。注意不要一開(kāi)始就追求大而全的方案先把核心鏈路跑通再逐步完善。我見(jiàn)過(guò)不少團(tuán)隊(duì)花幾個(gè)月設(shè)計(jì)了一套完美的架構(gòu)結(jié)果上線后發(fā)現(xiàn)跟實(shí)際業(yè)務(wù)不匹配又推倒重來(lái)。6. 幾個(gè)我踩過(guò)的坑和對(duì)應(yīng)的解法6.1 限流參數(shù)設(shè)得太緊導(dǎo)致正常業(yè)務(wù)被誤傷早期做限流的時(shí)候我按理論峰值設(shè)了參數(shù)結(jié)果上線第一天就收到大量投訴。原因是理論峰值和實(shí)際峰值差距很大而且業(yè)務(wù)有周期性波動(dòng)固定閾值根本適應(yīng)不了。后來(lái)改成動(dòng)態(tài)閾值根據(jù)歷史同期數(shù)據(jù)自動(dòng)調(diào)整誤傷率才降下來(lái)。動(dòng)態(tài)閾值的實(shí)現(xiàn)思路是每天凌晨統(tǒng)計(jì)前一天同時(shí)段的請(qǐng)求量取P95作為當(dāng)天的基準(zhǔn)閾值再乘以一個(gè)安全系數(shù)。安全系數(shù)根據(jù)業(yè)務(wù)重要程度設(shè)核心業(yè)務(wù)設(shè)1.5非核心設(shè)1.2。這樣既能應(yīng)對(duì)周期性波動(dòng)又不會(huì)因?yàn)殚撝堤蓪?dǎo)致防護(hù)失效。6.2 密鑰輪換時(shí)忘了通知調(diào)用方導(dǎo)致服務(wù)中斷有一次做密鑰輪換我按流程生成了新密鑰、設(shè)置了過(guò)渡期但忘了通知一個(gè)內(nèi)部調(diào)用方。結(jié)果過(guò)渡期結(jié)束后舊密鑰被禁用那個(gè)服務(wù)直接掛了。從那以后我加了一條規(guī)矩密鑰輪換前必須確認(rèn)所有調(diào)用方都已知曉并完成切換。確認(rèn)方式可以是郵件回執(zhí)也可以是在密鑰管理服務(wù)里標(biāo)記調(diào)用方狀態(tài)沒(méi)確認(rèn)的不允許禁用舊密鑰。6.3 成本歸因數(shù)據(jù)不準(zhǔn)導(dǎo)致預(yù)算判斷失誤成本歸因的數(shù)據(jù)來(lái)源是API響應(yīng)里的token用量字段但有些廠商的流式接口在異常中斷時(shí)不會(huì)返回完整的用量數(shù)據(jù)。這就導(dǎo)致統(tǒng)計(jì)出來(lái)的成本比實(shí)際低預(yù)算判斷跟著出錯(cuò)。解法是在網(wǎng)關(guān)層做補(bǔ)償統(tǒng)計(jì)如果響應(yīng)異常中斷按請(qǐng)求時(shí)的輸入token數(shù)加上一個(gè)估算的輸出token數(shù)來(lái)記賬。估算值可以按歷史平均輸出長(zhǎng)度來(lái)定雖然不精確但比漏記強(qiáng)。6.4 監(jiān)控告警太多導(dǎo)致麻木剛開(kāi)始做監(jiān)控的時(shí)候我把能設(shè)的告警都設(shè)了結(jié)果每天收到幾十條告警慢慢就麻木了真正重要的告警反而被忽略。后來(lái)做了告警分級(jí)P0級(jí)必須立即處理P1級(jí)當(dāng)天處理P2級(jí)每周review。P0級(jí)只保留最核心的幾個(gè)指標(biāo)比如密鑰泄露、預(yù)算超支、服務(wù)不可用。這樣告警數(shù)量降下來(lái)了響應(yīng)速度反而上去了。7. 關(guān)于這套方案的擴(kuò)展思路這套方案目前覆蓋的是最核心的三塊但實(shí)際生產(chǎn)中還有很多可以擴(kuò)展的地方。比如多模型路由根據(jù)請(qǐng)求的內(nèi)容和預(yù)算自動(dòng)選擇最合適的模型這個(gè)可以在服務(wù)層做跟成本控制配合。再比如請(qǐng)求內(nèi)容審計(jì)檢測(cè)有沒(méi)有敏感信息或者惡意提示詞這個(gè)可以在網(wǎng)關(guān)層加一層過(guò)濾。還有一個(gè)方向是自動(dòng)化調(diào)優(yōu)根據(jù)歷史數(shù)據(jù)自動(dòng)調(diào)整限流參數(shù)和降級(jí)閾值減少人工干預(yù)。這個(gè)實(shí)現(xiàn)起來(lái)復(fù)雜一些但長(zhǎng)期來(lái)看能省不少運(yùn)維精力。我目前還在摸索階段等有成熟經(jīng)驗(yàn)了再單獨(dú)寫(xiě)一篇。最后分享一個(gè)小技巧定期做壓力測(cè)試和故障演練。限流和降級(jí)策略平時(shí)看不出來(lái)效果只有真正遇到流量沖擊或者密鑰泄露時(shí)才知道管不管用。我一般每季度做一次演練模擬密鑰泄露和流量突增的場(chǎng)景看看系統(tǒng)能不能按預(yù)期響應(yīng)。演練之后根據(jù)結(jié)果調(diào)整策略比拍腦袋設(shè)參數(shù)靠譜得多。