自建AI模型網(wǎng)關(guān)這件事我得從一次并不風(fēng)光的對(duì)賬說(shuō)起。上個(gè)月財(cái)務(wù)把模型API賬單甩到我桌上我看了一眼整個(gè)上半月的費(fèi)用比去年季度總額還高。我們的網(wǎng)關(guān)明明上線了把所有模型調(diào)用都統(tǒng)一走了網(wǎng)關(guān)還做了轉(zhuǎn)發(fā)、鑒權(quán)、日志理論上一切盡在掌控怎么就燒出去這么多錢后來(lái)我把這幾周的調(diào)用記錄翻了個(gè)底朝天才慢慢意識(shí)到一個(gè)很扎心的事實(shí)你把流量收攏到自己的AI模型網(wǎng)關(guān)只是把事情“看清楚”了并沒有把成本“管住”。這個(gè)網(wǎng)關(guān)如果只做轉(zhuǎn)發(fā)本質(zhì)上就是一條更粗的管道模型貴不貴、調(diào)用合不合理、重復(fù)請(qǐng)求多不多這些真正的成本問題一個(gè)都沒碰。這篇文章就把我這次自建AI模型網(wǎng)關(guān)踩過的坑以及后來(lái)從“轉(zhuǎn)發(fā)工具”硬改成“成本治理層”的過程完整記錄下來(lái)希望能幫到正在自建或準(zhǔn)備自建網(wǎng)關(guān)的團(tuán)隊(duì)。1. 自建AI模型網(wǎng)關(guān)我當(dāng)初為什么這么干1.1 沒有網(wǎng)關(guān)之前業(yè)務(wù)側(cè)的模型調(diào)用亂成什么樣我們團(tuán)隊(duì)最初面臨的局面估計(jì)很多公司都一樣多個(gè)業(yè)務(wù)線都在做AI功能有智能客服、文本摘要、搜索排序還有幾個(gè)內(nèi)部效率工具。每一條業(yè)務(wù)線都自己申請(qǐng)模型API的Key自己連供應(yīng)商OpenAI、國(guó)內(nèi)大模型廠商等等。代碼里到處都是散裝的模型調(diào)用你根本不知道今天有多少個(gè)Key在線上跑。這種狀態(tài)帶來(lái)的問題不是一天兩天了。首先是Key管理混亂權(quán)限收不住有人離職了Key還在線上用換也不是不換也不是。其次是模型選擇完全靠自覺有的業(yè)務(wù)明明只是做一個(gè)文本分類順手就把旗艦?zāi)Ｐ团渖狭擞械臉I(yè)務(wù)為了省事把幾千行歷史聊天記錄一并塞進(jìn)上下文根本不看token消耗。再就是失敗重試策略不統(tǒng)一有一次一個(gè)下游供應(yīng)商抖動(dòng)有個(gè)業(yè)務(wù)的重試邏輯一口氣打了20遍費(fèi)用嘩嘩地漲。出了問題還特別難排查到底哪個(gè)業(yè)務(wù)、哪個(gè)場(chǎng)景、哪個(gè)用戶在調(diào)用完全沒有一個(gè)統(tǒng)一入口能看清楚。我當(dāng)時(shí)就提了一個(gè)方案自建一個(gè)AI模型網(wǎng)關(guān)把模型調(diào)用的入口統(tǒng)一收斂到一個(gè)服務(wù)上。核心目標(biāo)有三個(gè)統(tǒng)一接入、統(tǒng)一鑒權(quán)、統(tǒng)一日志。說(shuō)得更直白一點(diǎn)我先不看成本優(yōu)化先把所有流量集中到一個(gè)口子上讓團(tuán)隊(duì)能知道每天有多少人在調(diào)用、調(diào)用的是什么模型、有沒有報(bào)錯(cuò)。這個(gè)目標(biāo)在當(dāng)時(shí)看來(lái)非常合理大家也都覺得早該這么干了。1.2 初版網(wǎng)關(guān)設(shè)計(jì)把“轉(zhuǎn)發(fā)”做好我就以為萬(wàn)事大吉初版網(wǎng)關(guān)設(shè)計(jì)得很簡(jiǎn)單我當(dāng)時(shí)的想法是只要能讓業(yè)務(wù)方把代碼從直連模型API改成請(qǐng)求網(wǎng)關(guān)就算成功。技術(shù)選型上我用了一個(gè)輕量的中間層服務(wù)Python FastAPI加Redis接收所有模型請(qǐng)求校驗(yàn)API Key然后把請(qǐng)求原樣轉(zhuǎn)發(fā)給對(duì)應(yīng)的模型供應(yīng)商拿到響應(yīng)后再原樣透?jìng)鹘o調(diào)用方。核心代碼攤開看其實(shí)就是一個(gè)轉(zhuǎn)發(fā)層。from fastapi import FastAPI, Header, HTTPException import httpx app FastAPI() UPSTREAM_MAP { openai: https://api.openai.com/v1/chat/completions, qwen: https://dashscope.aliyuncs.com/api/v1/services/aigc/text-generation/generation, } app.post(/v1/chat/completions) async def chat_completions(request: dict, x_api_key: str Header(...), x_upstream: str Header(openai)): # 鑒權(quán)校驗(yàn)這個(gè) Key 是否有權(quán)限調(diào)用 if not check_key(x_api_key): raise HTTPException(status_code401, detailinvalid key) # 轉(zhuǎn)發(fā)把請(qǐng)求體原樣打給上游 upstream_url UPSTREAM_MAP.get(x_upstream) if not upstream_url: raise HTTPException(status_code400, detailunknown upstream) async with httpx.AsyncClient(timeout60) as client: resp await client.post(upstream_url, jsonrequest, headers{ Authorization: fBearer {get_upstream_key(x_upstream)} }) return resp.json()當(dāng)時(shí)我還挺滿意因?yàn)檫@個(gè)服務(wù)上線很快兩天就接完了主要業(yè)務(wù)。上線第一周所有請(qǐng)求都正常流轉(zhuǎn)日志也統(tǒng)一了業(yè)務(wù)方反饋接入成本很低只要把base_url換掉就行。我一度以為這個(gè)項(xiàng)目已經(jīng)成了接下來(lái)只需要修修補(bǔ)補(bǔ)。1.3 上線兩周代價(jià)立刻出現(xiàn)了結(jié)果就是文章開頭那一幕月底對(duì)賬的時(shí)候賬單不僅沒降反而比上個(gè)月還高。我第一反應(yīng)是網(wǎng)關(guān)有Bug或者是有人惡意刷接口趕緊拉日志出來(lái)查。查完我才明白網(wǎng)關(guān)確實(shí)把所有調(diào)用收攏了但它本質(zhì)上只是把費(fèi)用從多個(gè)供應(yīng)商賬單收攏到了一個(gè)出口。業(yè)務(wù)方以前怎么調(diào)用現(xiàn)在還是怎么調(diào)用以前用貴模型拍腦袋現(xiàn)在依然用貴模型拍腦袋以前重復(fù)請(qǐng)求反復(fù)打現(xiàn)在依然重復(fù)請(qǐng)求反復(fù)打。換句話說(shuō)網(wǎng)關(guān)幫我把問題的可見度提高了卻沒幫我解決任何一個(gè)成本問題。你看到每一筆token在消耗但你阻止不了它們。這種感覺很難受就像裝了個(gè)水表發(fā)現(xiàn)家里漏水很嚴(yán)重但你手上沒有扳手關(guān)不掉閥門。那段時(shí)間我反復(fù)跟團(tuán)隊(duì)說(shuō)一句話“轉(zhuǎn)發(fā)”解決的是技術(shù)通道問題而“成本浪費(fèi)”是治理問題通道通了不代表成本會(huì)被管住。后來(lái)我把這次經(jīng)歷做了一次復(fù)盤核心結(jié)論是一個(gè)只負(fù)責(zé)轉(zhuǎn)發(fā)的AI模型網(wǎng)關(guān)充其量是個(gè)API代理層它沒有路由、沒有緩存、沒有配額、沒有計(jì)量就談不上成本治理。我決定開始改造。2. 只做轉(zhuǎn)發(fā)成本浪費(fèi)到底出在哪2.1 貴模型被當(dāng)成默認(rèn)選項(xiàng)殺雞一直在用牛刀成本浪費(fèi)的第一個(gè)大頭是模型選型嚴(yán)重不合理。我拉了一周的調(diào)用日志統(tǒng)計(jì)各模型的使用占比發(fā)現(xiàn)幾個(gè)旗艦?zāi)Ｐ驼剂丝傉{(diào)用量的六成以上。但實(shí)際上很多業(yè)務(wù)場(chǎng)景根本不需要那么強(qiáng)的模型比如文本標(biāo)簽分類、關(guān)鍵詞抽取、意圖識(shí)別、格式改寫這類任務(wù)用中等規(guī)格的模型完全能打。這里算一筆簡(jiǎn)單的賬假設(shè)某旗艦?zāi)Ｐ洼斎雰r(jià)格是15元/百萬(wàn)token輸出價(jià)格是60元/百萬(wàn)token一個(gè)便宜模型輸入3元/百萬(wàn)token輸出15元/百萬(wàn)token。一個(gè)文本分類場(chǎng)景每天調(diào)用10萬(wàn)次每次平均輸入2000 token、輸出200 token。旗艦?zāi)Ｐ鸵惶斓某杀敬蠹s是10萬(wàn)乘以2000除以100萬(wàn)乘以15再加上200除以100萬(wàn)乘以60算下來(lái)是4200元。便宜模型一天的成本是10萬(wàn)乘以2000除以100萬(wàn)乘以3再加上200除以100萬(wàn)乘以15只有900元。一天就差3300元一個(gè)月就近10萬(wàn)元。而這只是一個(gè)場(chǎng)景。這種浪費(fèi)的根源在于業(yè)務(wù)方?jīng)]有成本和模型能力匹配的意識(shí)。對(duì)他們來(lái)說(shuō)我在代碼里寫死了旗艦?zāi)Ｐ湍芡瓿扇蝿?wù)就行不會(huì)有人關(guān)心token單價(jià)。網(wǎng)關(guān)如果不提供路由能力它就永遠(yuǎn)只能眼睜睜看著這些請(qǐng)求打向最貴的模型。2.2 重復(fù)請(qǐng)求反復(fù)計(jì)費(fèi)同一個(gè)Prompt燒了好幾遍第二個(gè)大頭是重復(fù)請(qǐng)求。我發(fā)現(xiàn)有些接口一天之內(nèi)傳進(jìn)來(lái)的Prompt幾乎完全一樣比如“判斷用戶這句話是否屬于投訴”“給這篇文檔生成一段摘要”這類任務(wù)的輸入高度相似但因?yàn)闆]有緩存每一次都實(shí)打?qū)嵈蚪o了模型API每一分錢都在重復(fù)計(jì)費(fèi)。舉一個(gè)真實(shí)案例我查日志的時(shí)候看到一個(gè)接口一天內(nèi)完全相同的Prompt跑了八千多次。單次調(diào)用成本按2分錢算一天就白燒160元。你可能覺得160元不算多但同樣的情況在十幾個(gè)接口里都存在有些更夸張一天重復(fù)調(diào)用上萬(wàn)次。積少成多一個(gè)月下來(lái)就是幾萬(wàn)塊。這里面的問題在于很多內(nèi)部工具和自動(dòng)化流程的調(diào)用模式是高度可預(yù)測(cè)的。同一個(gè)模板、同一份輸入隔幾分鐘跑一次結(jié)果幾乎不會(huì)變。對(duì)這類請(qǐng)求網(wǎng)關(guān)如果只是轉(zhuǎn)發(fā)它就是一臺(tái)沒有感情的“燒錢機(jī)器”但如果有一個(gè)精確緩存命中后直接返回歷史結(jié)果這部分成本就能直接歸零。2.3 重試與并發(fā)放大了損失模型一抖動(dòng)費(fèi)用翻倍第三個(gè)大頭是重試和并發(fā)帶來(lái)的費(fèi)用放大器。當(dāng)時(shí)網(wǎng)關(guān)里配了一個(gè)很粗暴的邏輯只要上游返回超時(shí)或5xx就自動(dòng)重試3次。這個(gè)策略在單次請(qǐng)求上看起來(lái)沒什么問題但一旦遇到模型供應(yīng)商大規(guī)模抖動(dòng)所有業(yè)務(wù)同時(shí)開始重試問題就非?？植懒?。舉個(gè)例子某次上游模型連續(xù)報(bào)警有20個(gè)業(yè)務(wù)同時(shí)處于失敗狀態(tài)每個(gè)業(yè)務(wù)都按約定重試3次瞬時(shí)流量直接擴(kuò)大了4倍。結(jié)果就是模型供應(yīng)商更慢、更多請(qǐng)求超時(shí)然后又有一些重試被觸發(fā)。賬單自然也跟著水漲船高。那個(gè)時(shí)候我才意識(shí)到重試策略不是越簡(jiǎn)單越好而是必須配合退避算法和熔斷機(jī)制。真正應(yīng)該做的是快速失敗、有限重試、及時(shí)切走流量。除了重試還有并發(fā)問題。沒有限流的網(wǎng)關(guān)面對(duì)突發(fā)流量會(huì)全量轉(zhuǎn)發(fā)給上游結(jié)果上游被壓垮失敗的請(qǐng)求又開始重試整個(gè)鏈路進(jìn)入惡性循環(huán)。如果限了流至少能保證一部分請(qǐng)求正常完成另一部分快速返回“稍后再試”而不是把費(fèi)用白白燒在失敗請(qǐng)求上。2.4 沒有配額與預(yù)算熔斷接口在裸奔最后一個(gè)大頭也是最容易被忽視的沒有配額和預(yù)算控制。我一直到賬單爆炸之后才意識(shí)到網(wǎng)關(guān)對(duì)調(diào)用方是完全信任的只要Key有效你想調(diào)多少次就調(diào)多少次想調(diào)多貴的模型就調(diào)多貴的模型。這就導(dǎo)致了一些典型的失控場(chǎng)景。測(cè)試人員對(duì)一個(gè)內(nèi)部接口做壓測(cè)一個(gè)小時(shí)打出幾十萬(wàn)次調(diào)用某個(gè)定時(shí)任務(wù)因?yàn)閿?shù)據(jù)問題陷入死循環(huán)一晚上把所有數(shù)據(jù)重新跑了一遍某個(gè)業(yè)務(wù)上線了新的實(shí)驗(yàn)策略忘了關(guān)開關(guān)把流量全部切到旗艦?zāi)Ｐ蜕吓芰艘徽?。這些場(chǎng)景沒有任何一道閘門能攔住。我一直覺得成本治理的關(guān)鍵不只是看每一次調(diào)用而是要把每次調(diào)用的“額度”算清楚。就像公司預(yù)算一樣每個(gè)業(yè)務(wù)線每個(gè)月有多少模型調(diào)用額度用完了是降級(jí)還是停止必須提前定好規(guī)則。否則等賬單出來(lái)再查就已經(jīng)太晚了。3. 從“轉(zhuǎn)發(fā)”到“經(jīng)營(yíng)成本”網(wǎng)關(guān)必須做什么3.1 模型路由按任務(wù)、按場(chǎng)景、按成本分級(jí)既然只轉(zhuǎn)發(fā)不行那網(wǎng)關(guān)第一步要做的就是模型路由。核心原則很簡(jiǎn)單能用便宜模型解決的絕不調(diào)用貴模型能用小模型解決的場(chǎng)景絕不上旗艦?zāi)Ｐ?。把“業(yè)務(wù)要什么任務(wù)”和“哪個(gè)模型適合這個(gè)任務(wù)”對(duì)應(yīng)起來(lái)。路由的維度可以根據(jù)實(shí)際情況來(lái)定。我后來(lái)在網(wǎng)關(guān)里至少會(huì)考慮這幾個(gè)維度。第一是業(yè)務(wù)場(chǎng)景調(diào)用方請(qǐng)求時(shí)要傳一個(gè)scene字段比如text_classify、summary、code_gen、chat_demo網(wǎng)關(guān)根據(jù)場(chǎng)景直接決定默認(rèn)模型。第二是上下文長(zhǎng)度傳入的Prompt或者歷史消息非常長(zhǎng)時(shí)自動(dòng)切到支持更大上下文且單價(jià)更合適的模型如果輸入很短就走延遲低、價(jià)格便宜的模型。第三是用戶等級(jí)免費(fèi)用戶和付費(fèi)用戶可以走不同檔次的模型這不只是為了省錢也是產(chǎn)品策略的一部分。第四是失敗切換上游模型不可用時(shí)自動(dòng)路由到備選模型而不是直接報(bào)錯(cuò)。我踩過的一個(gè)坑是路由規(guī)則一開始不要太激進(jìn)。先做觀測(cè)記錄每個(gè)場(chǎng)景真實(shí)調(diào)用量、token消耗、模型效果運(yùn)行一兩周之后再根據(jù)數(shù)據(jù)調(diào)整路由策略。沒有數(shù)據(jù)支撐的路由規(guī)則很容易拍腦袋拍完就出問題。3.2 緩存精確緩存先落地語(yǔ)義緩存按需開緩存是解決重復(fù)請(qǐng)求最直接的手段。我把緩存分成兩檔來(lái)設(shè)計(jì)。第一檔是精確緩存也就是請(qǐng)求體完全一樣時(shí)直接返回歷史結(jié)果。這個(gè)實(shí)現(xiàn)最簡(jiǎn)單也最容易看到效果。我在網(wǎng)關(guān)里對(duì)model、messages、關(guān)鍵參數(shù)做一個(gè)哈希Redis里存一份命中就直接返回完全不再打上游。第二檔是語(yǔ)義緩存字面不完全一樣但語(yǔ)義相同的請(qǐng)求比如“幫我總結(jié)一下這個(gè)文檔”和“請(qǐng)把這篇文檔做個(gè)摘要”可以通過embedding相似度來(lái)命中。語(yǔ)義緩存很誘人因?yàn)樗芨采w更多請(qǐng)求但風(fēng)險(xiǎn)也高。一是embedding計(jì)算本身有成本和延遲二是相似度閾值調(diào)不好容易誤命中返回一個(gè)不完全匹配的舊答案業(yè)務(wù)方會(huì)投訴質(zhì)量。所以我的建議是語(yǔ)義緩存只對(duì)特定高頻、結(jié)果相對(duì)穩(wěn)定的場(chǎng)景開啟并且做灰度驗(yàn)證。還有一個(gè)原則要記住流式輸出、個(gè)性化回答、涉及隱私或合規(guī)要求的請(qǐng)求不適合做緩存。流式輸出要緩存必須等完整結(jié)果生成完首token延遲會(huì)變高個(gè)性化回答幾乎不會(huì)有重復(fù)隱私內(nèi)容留在緩存里本身就是隱患。3.3 限流、重試與降級(jí)把失敗成本控住轉(zhuǎn)發(fā)模式下的重試是災(zāi)難放大器所以網(wǎng)關(guān)必須具備三個(gè)能力限流、重試策略、熔斷降級(jí)。限流用令牌桶就夠了不用搞太復(fù)雜。每個(gè)業(yè)務(wù)、每個(gè)場(chǎng)景設(shè)置一個(gè)QPS上限超過部分直接排隊(duì)或快速失敗避免突發(fā)流量打爆上游也避免費(fèi)用失控。重試策略一定要改不能無(wú)限重試默認(rèn)最多一次并且要做指數(shù)退避第一次失敗等0.5秒第二次失敗等1秒中間加隨機(jī)抖動(dòng)防止所有請(qǐng)求同時(shí)重試。熔斷和降級(jí)是配套的。當(dāng)某個(gè)上游模型連續(xù)失敗率達(dá)到一定閾值比如30秒內(nèi)錯(cuò)誤率超過50%就把這個(gè)上游標(biāo)記為熔斷狀態(tài)后續(xù)請(qǐng)求自動(dòng)切換到備用模型。降級(jí)則是在配額用盡時(shí)使用某個(gè)業(yè)務(wù)的預(yù)算花完了可以降級(jí)到更便宜的模型繼續(xù)提供服務(wù)而不是直接拒絕用戶。這樣用戶感知不到服務(wù)中斷成本也不會(huì)失控。3.4 成本計(jì)量與標(biāo)簽體系讓每筆token都有歸屬前面說(shuō)的路由、緩存、配額都依賴一件事情你必須知道錢花在了哪里。所以我后來(lái)在網(wǎng)關(guān)里加了全面的成本計(jì)量每個(gè)請(qǐng)求處理前后都記錄一條日志包含時(shí)間戳、業(yè)務(wù)線、場(chǎng)景、用戶ID、模型名、prompt_tokens、completion_tokens、總token、費(fèi)用估算、緩存是否命中、命中了哪條路由規(guī)則等等。這些數(shù)據(jù)落到一張明細(xì)表里每天定時(shí)聚合成成本報(bào)表。只有有了標(biāo)簽體系你才能回答“哪個(gè)業(yè)務(wù)最燒錢”“哪個(gè)模型最浪費(fèi)”“哪個(gè)用戶一天就把配額燒光了”這些問題。沒有計(jì)量的治理都是空話這句話我后來(lái)反復(fù)跟團(tuán)隊(duì)講。網(wǎng)關(guān)不是裝完路由和緩存就完事了它得像一個(gè)經(jīng)營(yíng)儀表盤每天都讓你看見成本的流向。4. 關(guān)鍵方案落地路由、緩存、配額怎么實(shí)現(xiàn)4.1 整體架構(gòu)調(diào)整從純轉(zhuǎn)發(fā)到多級(jí)調(diào)度改造后的網(wǎng)關(guān)不再是一個(gè)簡(jiǎn)單的轉(zhuǎn)發(fā)層而是變成了一個(gè)多級(jí)調(diào)度器。每個(gè)請(qǐng)求進(jìn)入網(wǎng)關(guān)后的處理流程大致是第一步鑒權(quán)解析API Key和請(qǐng)求頭第二步記錄原始請(qǐng)求元數(shù)據(jù)第三步路由模塊根據(jù)場(chǎng)景、上下文長(zhǎng)度、用戶等級(jí)選擇模型第四步查緩存命中就直接返回第五步做配額檢查判斷這筆請(qǐng)求是否允許繼續(xù)消耗預(yù)算第六步調(diào)用上游帶超時(shí)、重試和熔斷邏輯第七步記錄計(jì)量數(shù)據(jù)寫成本日志。這個(gè)流程看著環(huán)節(jié)多但每一步都是輕量操作實(shí)際增加的時(shí)間在幾十毫秒以內(nèi)還是能接受的。更重要的是這個(gè)架構(gòu)讓網(wǎng)關(guān)從“搬運(yùn)工”變成了“調(diào)度中心”成本控制能力一下子就有了。4.2 模型路由實(shí)現(xiàn)示例請(qǐng)求級(jí)模型選擇路由模塊我建議用配置驅(qū)動(dòng)不要硬編碼在代碼里。可以在配置中心放一份路由規(guī)則運(yùn)營(yíng)人員直接調(diào)整不需要重新發(fā)布服務(wù)。下面這個(gè)示例簡(jiǎn)化了配置格式核心是講清楚思路。# 路由規(guī)則可以在配置中心運(yùn)行期更新 ROUTING_RULES [ {scene: text_classify, model: fast-model, max_input_chars: 4000}, {scene: extract, model: mid-model, max_input_chars: 8000}, {scene: code_gen, model: flagship-model, max_input_chars: 16000}, ] DEFAULT_MODEL fast-model LONG_CONTEXT_MODEL long-context-model def route_by_scene(scene: str, input_text: str) - str: normalized_scene (scene or default).strip().lower() for rule in ROUTING_RULES: if rule[scene] normalized_scene: if len(input_text) rule[max_input_chars]: return rule[model] # 輸入過長(zhǎng)專門切到支持長(zhǎng)上下文的模型 return LONG_CONTEXT_MODEL return DEFAULT_MODEL這里的關(guān)鍵點(diǎn)是業(yè)務(wù)方在接入網(wǎng)關(guān)時(shí)必須在請(qǐng)求頭或請(qǐng)求體里帶上scene字段。如果有些老接口不方便改也可以先通過URL路徑映射比如/v1/chat/completions/summary這樣的路徑直接對(duì)應(yīng)summary場(chǎng)景?？傊酚傻囊罁?jù)越清晰后續(xù)調(diào)整越容易。4.3 緩存落地示例用Redis做精確緩存精確緩存是最容易上手的我用Redis的字符串結(jié)構(gòu)就夠了。核心思路是把“模型名、消息列表、關(guān)鍵參數(shù)”三個(gè)要素序列化后做SHA256哈希作為Redis Key緩存值就是模型返回的結(jié)果。import hashlib import json import redis r redis.Redis(hostlocalhost, port6379, db0) def _cache_key(model: str, messages: list, params: dict) - str: raw json.dumps({model: model, messages: messages, params: params}, sort_keysTrue) return model_cache: hashlib.sha256(raw.encode()).hexdigest() def get_cached_response(model: str, messages: list, params: dict): key _cache_key(model, messages, params) cached r.get(key) if cached: return json.loads(cached) return None def set_cached_response(model: str, messages: list, params: dict, response: dict, ttl: int 3600): key _cache_key(model, messages, params) r.setex(key, ttl, json.dumps(response))使用的時(shí)候在處理請(qǐng)求前先查緩存查到就直接返回查不到再調(diào)模型API拿到結(jié)果后寫緩存。TTL我一般不會(huì)設(shè)太長(zhǎng)一小時(shí)到一天根據(jù)場(chǎng)景調(diào)。這里有個(gè)小技巧對(duì)于明顯包含時(shí)間戳、隨機(jī)數(shù)的請(qǐng)求緩存命中率會(huì)很低?？梢栽谏删彺鍷ey前先做一層歸一化把時(shí)間戳、隨機(jī)數(shù)、無(wú)關(guān)緊要的空格等字段剔除再生成Key。這個(gè)操作能明顯提高命中率。4.4 配額與預(yù)算控制示例先估算費(fèi)用再?zèng)Q定放不放行配額控制的思路是基于預(yù)算上限做前置判斷。每次請(qǐng)求進(jìn)來(lái)之前先根據(jù)模型和token數(shù)估算本次費(fèi)用然后用Redis中的計(jì)數(shù)器看當(dāng)前業(yè)務(wù)當(dāng)天已經(jīng)消耗了多少如果加上本次費(fèi)用會(huì)超過每日限額就走降級(jí)模型或者直接拒絕。下面是一段精簡(jiǎn)的示例代碼。import time QUOTA_KEY quota:cost:{biz}:{day} def check_and_consume_quota(biz: str, estimated_cost: float, daily_limit: float) - bool: day time.strftime(%Y-%m-%d) key QUOTA_KEY.format(bizbiz, dayday) used float(r.get(key) or 0.0) if used estimated_cost daily_limit: return False r.incrbyfloat(key, estimated_cost) return True如果配額不足網(wǎng)關(guān)可以根據(jù)策略決定是返回429讓業(yè)務(wù)方感知還是自動(dòng)降級(jí)到便宜模型。我建議在初期先做“拒絕”模式把問題暴露出來(lái)等業(yè)務(wù)穩(wěn)定了再切“降級(jí)”模式避免用戶在無(wú)感知的情況下拿到質(zhì)量下降的答案。成本明細(xì)表的結(jié)構(gòu)也很重要我用的是MySQL核心字段包括調(diào)用時(shí)間、業(yè)務(wù)線、場(chǎng)景、用戶ID、模型、prompt_tokens、completion_tokens、total_tokens、估算費(fèi)用、緩存是否命中、路由命中的規(guī)則名、原始響應(yīng)JSON。有了這張表就可以寫各種聚合SQL來(lái)做成本分析。CREATE TABLE model_call_bill ( id BIGINT AUTO_INCREMENT PRIMARY KEY, call_time DATETIME NOT NULL, biz VARCHAR(64) NOT NULL, scene VARCHAR(64) NOT NULL, user_id VARCHAR(128), model VARCHAR(64) NOT NULL, prompt_tokens INT DEFAULT 0, completion_tokens INT DEFAULT 0, total_tokens INT DEFAULT 0, cost_cny DECIMAL(10, 4) DEFAULT 0, cache_hit TINYINT DEFAULT 0, route_rule VARCHAR(128), raw_response JSON, KEY idx_biz_time (biz, call_time), KEY idx_model_time (model, call_time) );SELECT biz, model, SUM(total_tokens) AS total_tokens, SUM(cost_cny) AS total_cost FROM model_call_bill WHERE call_time NOW() - INTERVAL 7 DAY GROUP BY biz, model ORDER BY total_cost DESC LIMIT 20;5. 踩坑記錄與問題排查速查5.1 緩存命中率為什么上不去緩存落地之后我遇到的第一個(gè)問題是命中率遠(yuǎn)遠(yuǎn)低于預(yù)期。查了一圈才發(fā)現(xiàn)很多業(yè)務(wù)在Prompt里帶了時(shí)間戳或者隨機(jī)字符串比如“今天是2025年6月1日請(qǐng)分析以下內(nèi)容”每次請(qǐng)求內(nèi)容都不一樣精確緩存當(dāng)然永遠(yuǎn)不命中。解決方法是做請(qǐng)求歸一化。在生成緩存Key之前先把明顯不影響結(jié)果的噪聲字段去掉比如時(shí)間戳、隨機(jī)ID、無(wú)意義的空格和換行。如果還是命中率低就要看業(yè)務(wù)場(chǎng)景是否真的適合緩存。有些場(chǎng)景每次輸入都完全不同硬上語(yǔ)義緩存也沒用沒必要為了緩存而緩存。語(yǔ)義緩存我也試了踩了不少坑。相似度閾值設(shè)高了命中很少形同虛設(shè)閾值設(shè)低了隔三差五返回一個(gè)語(yǔ)義上差不多但實(shí)際內(nèi)容有偏差的舊結(jié)果業(yè)務(wù)方立刻投訴質(zhì)量。最后我學(xué)到的經(jīng)驗(yàn)是語(yǔ)義緩存只對(duì)低風(fēng)險(xiǎn)、模板化的場(chǎng)景開比如“產(chǎn)品功能介紹”“內(nèi)部知識(shí)問答”這類結(jié)果和措辭不完全一樣沒關(guān)系但不會(huì)出大錯(cuò)的場(chǎng)景。對(duì)生成代碼、醫(yī)療診斷、法律文本這類高風(fēng)險(xiǎn)場(chǎng)景我堅(jiān)決不開。5.2 路由規(guī)則上線后效果回退了路由規(guī)則剛上線的時(shí)候其中一個(gè)文本摘要場(chǎng)景被我強(qiáng)制切到了便宜模型。省是真的省了一個(gè)月少了將近八成的token費(fèi)用但業(yè)務(wù)方很快反饋摘要質(zhì)量偶發(fā)下降有些長(zhǎng)文檔的提煉不夠準(zhǔn)。說(shuō)白了便宜模型不是不行而是在某些邊界場(chǎng)景下穩(wěn)定性不如旗艦?zāi)Ｐ?。這件事給我的教訓(xùn)是路由規(guī)則的調(diào)整必須灰度。不能一把梭把整個(gè)場(chǎng)景切過去而是先放5%的流量對(duì)比效果和成本再逐步加大比例。同時(shí)要給每個(gè)場(chǎng)景配一個(gè)白名單某幾個(gè)核心客戶或者高價(jià)值用戶始終走旗艦?zāi)Ｐ推渌俗弑阋四Ｐ?。另外還要設(shè)置一鍵回退開關(guān)一旦質(zhì)量指標(biāo)惡化馬上切回原模型不要讓業(yè)務(wù)方在那里干著急。5.3 token計(jì)量口徑不一致對(duì)不上賬成本統(tǒng)計(jì)做完之后我發(fā)現(xiàn)網(wǎng)關(guān)里算出來(lái)的費(fèi)用和模型供應(yīng)商賬單對(duì)不上差得還挺多。排查下來(lái)原因很多不同模型對(duì)token的定義不一樣有的按字符有的按token有的對(duì)緩存命中token打折有的把系統(tǒng)提示詞算在輸入里有的不算。如果我們自己在網(wǎng)關(guān)里估算token用字符數(shù)除以4這種粗略方式誤差會(huì)非常大。這個(gè)問題的解法是所有成本計(jì)量都以模型返回的usage字段為準(zhǔn)不要自己猜。網(wǎng)關(guān)在拿到上游響應(yīng)后把usage里的prompt_tokens、completion_tokens、total_tokens原封不動(dòng)落庫(kù)再套用官方計(jì)費(fèi)表計(jì)算費(fèi)用。同時(shí)保留原始usage JSON方便以后對(duì)賬時(shí)追溯。如果供應(yīng)商支持流式返回記得在流結(jié)束時(shí)匯總各分段usage避免漏算。5.4 排查成本上漲的通用流程現(xiàn)在我的日常工作中排查成本問題已經(jīng)形成一套固定流程。第一步看成本趨勢(shì)圖找到漲幅最大的那天和業(yè)務(wù)線第二步按標(biāo)簽下鉆看TOP模型、TOP場(chǎng)景、TOP用戶一眼定位錢燒在哪里第三步翻對(duì)應(yīng)的請(qǐng)求日志看有沒有異常重復(fù)、異常重試、異常大token輸入第四步對(duì)照路由規(guī)則和緩存配置驗(yàn)證是不是規(guī)則沒生效或者被繞過了第五步修復(fù)問題后觀察24小時(shí)確認(rèn)成本曲線回落。下面整理了一個(gè)速查表是我自己排查時(shí)常用的對(duì)照邏輯異?，F(xiàn)象可能的線索處理建議某個(gè)場(chǎng)景token突然暴漲上下文無(wú)限累積對(duì)歷史消息做截?cái)嗷蛘拗茊未握?qǐng)求最大token數(shù)失敗重試次數(shù)多上游模型抖動(dòng)或限流開啟熔斷重試次數(shù)降為1次增加指數(shù)退避同一Prompt被無(wú)限次調(diào)用緩存沒生效或Key設(shè)計(jì)不合理檢查歸一化邏輯確認(rèn)緩存Key覆蓋所有影響參數(shù)單個(gè)Key費(fèi)用異常Key被盜用或測(cè)試腳本失控重置Key設(shè)置配額和每日上限網(wǎng)關(guān)成本統(tǒng)計(jì)和供應(yīng)商賬單對(duì)不上用量口徑不一致以官方usage為準(zhǔn)保留原始響應(yīng)JSON6. 說(shuō)點(diǎn)心里話這次改造做下來(lái)我最后悔的是第一版網(wǎng)關(guān)太執(zhí)著于“轉(zhuǎn)發(fā)”這個(gè)動(dòng)作把網(wǎng)關(guān)當(dāng)成了一個(gè)網(wǎng)絡(luò)管道只要數(shù)據(jù)能流過去就覺得任務(wù)完成了。但AI模型網(wǎng)關(guān)真正值錢的地方根本不在“轉(zhuǎn)發(fā)”而是在“在不影響業(yè)務(wù)效果的前提下用最便宜的方式把任務(wù)做完”。如果你現(xiàn)在正準(zhǔn)備自建模型網(wǎng)關(guān)我建議第一個(gè)版本就把四件事帶上計(jì)量標(biāo)簽、模型路由、精確緩存、配額熔斷。不要像我一樣先把轉(zhuǎn)發(fā)上線再被賬單打醒然后返工。另外也給還在猶豫是否要自建的團(tuán)隊(duì)提個(gè)醒自建網(wǎng)關(guān)本身有維護(hù)成本要跟著上游API的變更新增適配邏輯還要持續(xù)迭代路由策略。如果你們團(tuán)隊(duì)只有一兩個(gè)AI應(yīng)用直接使用開源的LLM網(wǎng)關(guān)可能更劃算先借用現(xiàn)成方案把成本觀測(cè)做起來(lái)搞清楚自己的調(diào)用畫像之后再評(píng)估要不要自研。自研不是不行但要清楚它解決的是“成本治理”問題不是“轉(zhuǎn)發(fā)通道”問題。我這次也就是栽在這個(gè)認(rèn)知偏差上希望你們能比我少走一段彎路。