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