1. 快為什么能單獨(dú)拿出來(lái)賣錢做AI應(yīng)用這一年我對(duì)快的認(rèn)知被徹底刷新了。前兩年大家比的是誰(shuí)的模型聰明會(huì)寫復(fù)雜邏輯、能做深度推理。2025年的風(fēng)向明顯變了OpenAI開始把快單獨(dú)拿出來(lái)明碼標(biāo)價(jià)賣——不是參數(shù)上高一檔的聰明而是TTFT更低、吐字更快、同樣任務(wù)花更少錢的快。從GPT-5 mini、Codex CLI到Realtime API速度已經(jīng)變成一條獨(dú)立的產(chǎn)品線。對(duì)做開發(fā)、做集成、做交付的我們來(lái)說(shuō)這套新的定價(jià)邏輯必須重新適應(yīng)。1.1 用戶感受到的快和賬單上的快是兩碼事先說(shuō)一個(gè)很容易被混淆的點(diǎn)用戶說(shuō)的快和服務(wù)商計(jì)費(fèi)系統(tǒng)里的快根本不是一回事。用戶體感里的快通常是兩個(gè)指標(biāo)。一個(gè)是首字延遲也就是TTFTTime To First Token你發(fā)一句話到模型開始吐第一個(gè)字中間隔了多久。另一個(gè)是吐字速度也就是每秒能生成多少個(gè)token很多人叫它TPS或者inter-token latency。聊天場(chǎng)景里第一印象幾乎全看TTFT500毫秒和2秒的差距用戶會(huì)直接覺得這個(gè)AI反應(yīng)快或這個(gè)AI卡死了。但云服務(wù)商眼里的快是單位時(shí)間能處理多少請(qǐng)求、每個(gè)請(qǐng)求占用GPU多久、并發(fā)上來(lái)之后P95延遲會(huì)不會(huì)崩。這就像餐廳經(jīng)營(yíng)顧客感知的是第一道菜多久端上來(lái)而后廚真正決定成本的是翻臺(tái)率和出餐排程。前廳的快要靠后廚的效率支撐但后廚的效率恰恰是最花錢的地方。為什么這個(gè)區(qū)別現(xiàn)在這么重要因?yàn)锳PI按token計(jì)費(fèi)之后速度第一次可以被獨(dú)立定價(jià)。你調(diào)用同一個(gè)模型如果它平均3秒返回和平均30秒返回服務(wù)商為這次請(qǐng)求付出的GPU占用時(shí)長(zhǎng)完全不同。過(guò)去這個(gè)成本差距被功能差異掩蓋了——貴的模型更聰明所以慢一點(diǎn)大家也接受。而OpenAI這一輪的操作是把那些不需要深度推理、只需要快速響應(yīng)的任務(wù)單獨(dú)拆出來(lái)用更快更便宜的模型承接然后明確告訴你這部分快你需要按一個(gè)新的價(jià)格體系來(lái)買。1.2 API按token計(jì)費(fèi)讓速度第一次有了獨(dú)立價(jià)格ChatGPT訂閱用戶不太能感受到快的定價(jià)因?yàn)槟鞘且粋€(gè)月一口價(jià)個(gè)人版、Plus版、Pro版之間的差異更多是模型上限和使用額度。但API是另一套玩法按token計(jì)費(fèi)之后模型的延遲、吞吐、容量都可以量化成SLA速度就有了具體的價(jià)簽。OpenAI這些年陸續(xù)推出的mini、nano模型在官方定位里幾乎都寫著同一個(gè)詞fast。它們不是小一號(hào)的旗艦?zāi)Ｐ瓦@么簡(jiǎn)單而是圍繞低延遲、低成本做了專門的工程優(yōu)化。蒸餾、量化、小參數(shù)推理一系列手段堆下來(lái)單次請(qǐng)求占用的計(jì)算資源大幅下降。最終反映在價(jià)格上就是同一類任務(wù)用快速模型來(lái)處理成本可能只有旗艦?zāi)Ｐ偷膸资种弧Ｎ遗e一個(gè)很典型的例子。你想做一個(gè)客服意圖分類用戶進(jìn)來(lái)一句話你要判斷他是想退貨、想改地址還是想投訴。這個(gè)任務(wù)用最強(qiáng)的推理模型來(lái)做純屬浪費(fèi)它需要的能力是快速理解短句按類別輸出而不是推導(dǎo)多步邏輯。用mini或者nano級(jí)別的模型延遲降到幾百毫秒成本降到可以忽略效果反而因?yàn)閷Ｒ欢€(wěn)定。這就是OpenAI把快單獨(dú)賣的邏輯它不是把同一個(gè)模型降價(jià)而是做了一個(gè)專門的商品并按速度加成本的雙重維度定價(jià)。1.3 速度分層背后的工程邏輯這里必須展開聊聊速度分層是怎么實(shí)現(xiàn)的不然很多人會(huì)以為OpenAI只是簡(jiǎn)單地把模型做小。快速模型通常走的是兩條技術(shù)路線。一條是蒸餾用大模型的輸出去訓(xùn)練小模型讓小模型學(xué)會(huì)在大多數(shù)情況下模仿大模型的判斷。蒸餾之后的模型參數(shù)量小但推理速度能快上好幾倍。另一條是量化與推理優(yōu)化降低權(quán)重精度、優(yōu)化KV Cache、使用更激進(jìn)的批處理策略讓同樣的GPU能塞進(jìn)更多并發(fā)請(qǐng)求。這兩條路線對(duì)用戶的影響很直接。第一快速模型在某些復(fù)雜推理任務(wù)上確實(shí)不如旗艦?zāi)Ｐ瓦@是物理規(guī)律別指望小模型能完全替代大模型。第二快速模型的延遲優(yōu)勢(shì)在大并發(fā)下更明顯因?yàn)閱握?qǐng)求資源占用低排隊(duì)概率小。第三價(jià)格優(yōu)勢(shì)不是線性下降而是數(shù)量級(jí)下降這就導(dǎo)致了一個(gè)新的工程問題你怎么把系統(tǒng)里的雜活精準(zhǔn)分配給快速模型而不是一股腦全丟給旗艦?zāi)Ｐ汀?. OpenAI把快做成了哪些具體產(chǎn)品想把這套快真正用起來(lái)得先認(rèn)清OpenAI這條速度產(chǎn)品線到底包含了哪些東西。它不是單一模型而是從文本到語(yǔ)音到代碼工具的一整套組合。2.1 GPT-5 mini 和 nano專為快速任務(wù)打造的模型我印象最深的是GPT-5系列發(fā)布時(shí)OpenAI很明確地把mini和nano從旗艦?zāi)Ｐ屠锊鹆顺鰜?lái)。mini可以理解為日常任務(wù)的黃金檔能處理多步推理但不需要旗艦?zāi)Ｐ湍欠N深度的場(chǎng)合它都能接住延遲和價(jià)格都?jí)旱煤艿?。nano更進(jìn)一步定位是極低延遲、極低成本適合的是分類、改寫、抽取、格式化這類看一眼就能回答的任務(wù)。實(shí)際使用中我的感受是nano這類模型是真的快在簡(jiǎn)單任務(wù)上經(jīng)?？梢宰龅綆装俸撩敕祷剡@個(gè)體感對(duì)于交互型產(chǎn)品是決定性的。但它的上下文處理和復(fù)雜指令跟隨能力相對(duì)弱千萬(wàn)不要因?yàn)樗阋司桶阉腥蝿?wù)都塞給它。我自己踩過(guò)的坑是在一個(gè)批量數(shù)據(jù)處理腳本里想讓nano直接做一份包含嚴(yán)格格式要求的復(fù)雜文檔抽取結(jié)果它偶爾會(huì)漏字段。后來(lái)我把任務(wù)拆成兩步先用nano做初篩分類再用mini做精細(xì)抽取效果和成本都更理想。選擇建議很直接如果你的任務(wù)用一句話能說(shuō)清楚規(guī)則比如判斷情緒提取日期翻譯成英文優(yōu)先試nano級(jí)別如果規(guī)則有兩三層需要理解一段話并做判斷用mini只有需要多步推理、長(zhǎng)上下文分析、復(fù)雜代碼生成時(shí)才輪到旗艦?zāi)Ｐ统鲴R。2.2 Codex CLI把開發(fā)者的快做成命令行體驗(yàn)OpenAI在開發(fā)者工具上的快是另一套玩法。Codex CLI推出后那句Welcome to Codex幾乎成了AI編程圈的一個(gè)標(biāo)志性瞬間。這玩意兒和普通AI編程助手最大的區(qū)別是它不是在你IDE里劃代碼、給建議而是直接以命令行agent的方式聽你描述需求然后自己讀代碼、改文件、跑命令、看報(bào)錯(cuò)、再修改整個(gè)過(guò)程是連續(xù)的。我試過(guò)幾次之后真實(shí)感受是它省掉的是人肉上下文切換的時(shí)間。以前我想讓AI改一個(gè)接口得先把相關(guān)文件打開、把報(bào)錯(cuò)信息復(fù)制、把上下文貼給它、再把改完的代碼粘回去驗(yàn)證。Codex CLI把這些步驟壓縮成一句自然語(yǔ)言指令它在本地環(huán)境里直接操作看到的結(jié)果和你在終端看到的完全一致。這種快不是模型吐字快而是整個(gè)工作流的節(jié)拍變快了對(duì)于高頻改代碼的開發(fā)者來(lái)說(shuō)這個(gè)價(jià)值甚至比單次響應(yīng)延遲更重要。當(dāng)然它也有邊界。Codex擅長(zhǎng)的是執(zhí)行明確任務(wù)如果你自己都不知道要改成什么指望它替你思考架構(gòu)那它也會(huì)陷入瞎忙。用它的時(shí)候需求描述越接近給一個(gè)實(shí)習(xí)生下指令效果越好。而且它作為命令行agent運(yùn)行本地命令是有風(fēng)險(xiǎn)的建議在臨時(shí)分支或者沙箱環(huán)境里跑別直接懟在生產(chǎn)倉(cāng)庫(kù)的主分支上。2.3 Realtime API語(yǔ)音場(chǎng)景下的毫秒級(jí)戰(zhàn)場(chǎng)快的第三個(gè)戰(zhàn)場(chǎng)是語(yǔ)音。OpenAI的Realtime API走的是語(yǔ)音到語(yǔ)音的端到端路線不經(jīng)過(guò)語(yǔ)音轉(zhuǎn)文字、文字進(jìn)模型、文字轉(zhuǎn)語(yǔ)音的三段式拼接而是直接把音頻流送進(jìn)模型模型直接輸出音頻。配合WebRTC它能把整個(gè)交互延遲壓到人類對(duì)話能接受的范圍。為什么這個(gè)重要因?yàn)檎Z(yǔ)音交互對(duì)延遲的容忍度比文本低得多。文本場(chǎng)景你等2秒沒問題語(yǔ)音場(chǎng)景如果超過(guò)1秒用戶就會(huì)覺得對(duì)方反應(yīng)遲鈍超過(guò)2秒基本就聊不下去了。過(guò)去做語(yǔ)音機(jī)器人中間要串ASR、LLM、TTS三個(gè)環(huán)節(jié)每個(gè)環(huán)節(jié)各花幾百毫秒累計(jì)起來(lái)就超時(shí)了。Realtime API把這三個(gè)環(huán)節(jié)合成一步把延遲縮短了一個(gè)量級(jí)這才能支撐實(shí)時(shí)對(duì)話、語(yǔ)音客服、口語(yǔ)陪練這類產(chǎn)品。另外我明顯感覺到OpenAI Compatible Speech這個(gè)標(biāo)準(zhǔn)正在變成語(yǔ)音供應(yīng)商的標(biāo)配?，F(xiàn)在很多語(yǔ)音服務(wù)都宣稱兼容OpenAI的接口格式背后的原因很簡(jiǎn)單一旦行業(yè)習(xí)慣了一個(gè)低延遲的接口規(guī)范后來(lái)者不兼容這個(gè)格式集成成本就會(huì)很高。對(duì)開發(fā)者來(lái)說(shuō)這其實(shí)是個(gè)好消息——你基于OpenAI語(yǔ)音接口寫出來(lái)的代碼未來(lái)遷移到其他兼容服務(wù)時(shí)改動(dòng)很小。2.4 速度產(chǎn)品線的選型對(duì)照表我自己整理了一張速查表平時(shí)選型就盯著它看分享出來(lái)供參考。特別注意價(jià)格變動(dòng)很快寫這篇文章時(shí)官網(wǎng)標(biāo)價(jià)是這個(gè)邏輯具體數(shù)字還是以官方定價(jià)頁(yè)為準(zhǔn)。方案定位適合任務(wù)延遲特征價(jià)格相對(duì)水平GPT-5 nano極低延遲/極低成本分類、改寫、抽取、情緒判斷極快幾百毫秒級(jí)最低GPT-5 mini日常主力快速模型中等復(fù)雜任務(wù)、客服、結(jié)構(gòu)化輸出快亞秒級(jí)到秒級(jí)很低旗艦?zāi)Ｐ蜕疃韧评黹L(zhǎng)文分析、復(fù)雜代碼、多步推理相對(duì)慢秒級(jí)到十幾秒高Codex CLI自動(dòng)編程agent改代碼、跑測(cè)試、修復(fù)報(bào)錯(cuò)整體工作流快需看Codex額度Realtime API低延遲語(yǔ)音對(duì)話語(yǔ)音客服、實(shí)時(shí)翻譯、語(yǔ)音助手毫秒級(jí)端到端按音頻時(shí)長(zhǎng)計(jì)費(fèi)這張表的核心思路是先看任務(wù)復(fù)雜度再看延遲要求最后才看價(jià)格。把任務(wù)分到正確的模型上你的系統(tǒng)既快又便宜。3. 實(shí)操在自己的項(xiàng)目里真正用上這份快這一節(jié)全是能直接抄作業(yè)的內(nèi)容。我按自己的落地順序來(lái)寫先拆任務(wù)再做傳輸層優(yōu)化然后處理安全和成本。3.1 先給任務(wù)分級(jí)別讓旗艦?zāi)Ｐ透呻s活我在多個(gè)項(xiàng)目里驗(yàn)證過(guò)的經(jīng)驗(yàn)是用快速模型省錢不是靠壓價(jià)而是靠任務(wù)路由。你要在系統(tǒng)里設(shè)計(jì)一層路由邏輯把進(jìn)來(lái)的請(qǐng)求分成幾個(gè)等級(jí)然后決定交給哪個(gè)模型。舉一個(gè)客服系統(tǒng)的例子。用戶消息進(jìn)來(lái)第一步用nano級(jí)別模型做意圖識(shí)別幾十個(gè)token就搞定輸出一個(gè)標(biāo)簽退款、物流、投訴、閑聊、其他。這個(gè)識(shí)別請(qǐng)求單獨(dú)走一路快速模型延遲控制在幾百毫秒。識(shí)別結(jié)果出來(lái)后只有投訴這種需要謹(jǐn)慎處理的復(fù)雜會(huì)話才轉(zhuǎn)給旗艦?zāi)Ｐ蜕苫貜?fù)普通的物流查詢直接走預(yù)設(shè)答案或者mini生成。這套路由下來(lái)旗艦?zāi)Ｐ偷恼{(diào)用量可能只占總流量的10%成本卻省了80%以上。路由邏輯不用寫得很復(fù)雜偽代碼思路大概是intent fast_model.classify(user_message) if intent in [complaint, complex_issue]: reply flagship_model.generate(user_message, history) else: reply fast_model.generate(user_message, history)關(guān)鍵是你要給每個(gè)模型設(shè)置獨(dú)立的預(yù)算和監(jiān)控。一旦路由比例失衡比如旗艦?zāi)Ｐ驼{(diào)用量突然飆升你立刻能在監(jiān)控里看到并針對(duì)性地優(yōu)化分流規(guī)則。3.2 流式響應(yīng)、緩存和超時(shí)把快變成可感知的體驗(yàn)?zāi)Ｐ捅旧砜觳淮砟愕漠a(chǎn)品體驗(yàn)就快。傳輸層如果不做優(yōu)化再快的模型也會(huì)被白白浪費(fèi)。這里有三件事我每次都會(huì)做。第一打開流式輸出。Chat Completion接口的stream參數(shù)一定設(shè)成true讓token邊生成邊返回。用戶看到字在跳心理等待時(shí)間能縮短一大半。哪怕最終完整輸出需要5秒流式下用戶可能在2秒時(shí)就覺得已經(jīng)開始回答了。對(duì)TTFT敏感的場(chǎng)景這個(gè)是必須的。一個(gè)標(biāo)準(zhǔn)的流式調(diào)用長(zhǎng)這樣import time from openai import OpenAI client OpenAI(api_keysk-你的key) t0 time.perf_counter() stream client.chat.completions.create( modelgpt-4o-mini, messages[{role: user, content: 用一句話說(shuō)明什么是流式響應(yīng)}], streamTrue, max_tokens200, ) first_token True for chunk in stream: if first_token: print(fTTFT: {time.perf_counter() - t0:.2f}s) first_token False content chunk.choices[0].delta.content if content: print(content, end)注意model參數(shù)要以官方當(dāng)前模型列表為準(zhǔn)這里只是示例。流式模式下強(qiáng)烈的首字延遲反饋能讓你直觀判斷模型快慢。第二做緩存。OpenAI API有prompt緩存機(jī)制命中緩存的部分會(huì)便宜很多響應(yīng)也更快。實(shí)操中系統(tǒng)提示詞、常用的few-shot示例、固定模板盡量保持前綴不變重復(fù)請(qǐng)求就會(huì)命中緩存。我自己習(xí)慣把所有公共指令拼在消息數(shù)組的前面避免把動(dòng)態(tài)內(nèi)容插在中間打亂前綴。第三設(shè)置合理的超時(shí)和重試。OpenAI的Python SDK支持timeout參數(shù)比如timeout30.0表示等待完整響應(yīng)最多30秒。重試則要帶指數(shù)退避和抖動(dòng)比如第一次等1秒第二次等2秒第三次等4秒并加上隨機(jī)數(shù)防止同時(shí)失敗的任務(wù)在同一個(gè)時(shí)間點(diǎn)集體重試造成雪崩。別用固定間隔重試也別無(wú)限重試。3.3 API Key安全紅線分享與泄露的處理流程這個(gè)部分必須單獨(dú)拿出來(lái)強(qiáng)調(diào)因?yàn)槲以诰W(wǎng)上看到太多人踩坑而且這個(gè)坑一旦踩上輕則被盜刷重則賬號(hào)被清空。先說(shuō)最基礎(chǔ)的一條API Key絕對(duì)不要分享。不管是OpenAI API Key分享這種資源帖還是同事之間圖方便臨時(shí)借一下都不要做。API Key就是你的付款憑證誰(shuí)拿到它誰(shuí)就能用你的賬號(hào)額度調(diào)用模型。我曾經(jīng)見過(guò)一個(gè)案例有人把key貼在自己的GitHub配置示例文件里結(jié)果被爬蟲掃到一晚上被刷掉幾百美元的調(diào)用量賬單直接爆炸。再說(shuō)泄露了OpenAI賬號(hào)會(huì)話JSON怎么辦。這里的session JSON指的是瀏覽器本地存儲(chǔ)里的登錄態(tài)憑證拿到它的人可以在不輸入密碼的情況下以你的身份登錄。如果你的會(huì)話文件已經(jīng)泄露按這個(gè)順序處理立即去賬號(hào)設(shè)置里把所有設(shè)備的會(huì)話全部強(qiáng)制登出讓已泄露的登錄態(tài)失效。修改賬號(hào)密碼并開啟兩步驗(yàn)證。不要再用同樣的密碼注冊(cè)其他網(wǎng)站。去API用量頁(yè)面檢查最近幾天的調(diào)用記錄看有沒有異常請(qǐng)求。有的話把現(xiàn)有的API Key全部吊銷重新生成新Key。如果你是把JSON文件提交到了Git倉(cāng)庫(kù)光刪除文件不夠Git歷史里還留著記錄需要用git filter-repo或者歷史改寫工具把痕跡清掉否則有心人還是能翻出來(lái)。確認(rèn)泄露源頭比如是不是被釣魚、是不是裝了來(lái)路不明的瀏覽器插件把源頭堵上否則還會(huì)再犯。這里還要說(shuō)一句不太好聽但很實(shí)在的話不要用別人分享出來(lái)的Key或者Session文件。你覺得你在薅羊毛其實(shí)是在幫別人承擔(dān)盜刷的法律風(fēng)險(xiǎn)而且這些公開泄露的憑證大概率已經(jīng)被無(wú)數(shù)人用過(guò)了隨時(shí)會(huì)被官方封禁根本不穩(wěn)定。3.4 成本控制的正確姿勢(shì)讓快為你省錢用上了快速模型成本控制還是有講究的我總結(jié)了四個(gè)實(shí)操習(xí)慣。第一給每個(gè)項(xiàng)目設(shè)置單獨(dú)的API Key并在后臺(tái)配置月度預(yù)算上限和告警閾值。OpenAI后臺(tái)支持按Key設(shè)置限額一旦達(dá)到閾值直接熔斷防止失控。第二合理設(shè)置max_tokens。很多人不設(shè)這個(gè)參數(shù)結(jié)果模型一次性生成超長(zhǎng)回復(fù)費(fèi)用翻倍響應(yīng)還慢?？头?chǎng)景里一個(gè)回復(fù)50個(gè)token足夠你給它默認(rèn)的4096它可能真給你寫一篇小作文出來(lái)。第三別讓日志吃錢。很多新手習(xí)慣把完整的API請(qǐng)求和響應(yīng)打印到日志里日志一多每天光日志里存儲(chǔ)的token數(shù)據(jù)就很可觀再配合日志分析工具費(fèi)用會(huì)從意想不到的地方冒出來(lái)。日志里只記錄關(guān)鍵字段比如模型、耗時(shí)、token數(shù)、狀態(tài)碼就夠了。第四用小規(guī)模灰度驗(yàn)證成本模型。在正式全量上線前先用5%的流量跑幾天統(tǒng)計(jì)平均每次請(qǐng)求的token消耗和成本再按日活估算月成本。寧可先算清楚再?zèng)_量也別一上線就大放量。4. 常見問題與避坑實(shí)錄這一節(jié)是我在實(shí)際項(xiàng)目里被反復(fù)折騰出來(lái)的經(jīng)驗(yàn)按問題分類整理遇到同樣情況直接對(duì)照排查。4.1 延遲沒降下來(lái)先查這五處明明用了快速模型接口還是很慢通常不是模型的問題是這幾個(gè)地方在拖后腿。第一網(wǎng)絡(luò)鏈路。測(cè)試的時(shí)候先用簡(jiǎn)單的請(qǐng)求對(duì)比一下如果TTFT始終穩(wěn)定偏高先確認(rèn)是不是網(wǎng)絡(luò)環(huán)境本身延遲大。這種情況可以換更穩(wěn)定的網(wǎng)絡(luò)環(huán)境再試我自己的經(jīng)驗(yàn)是跨地域調(diào)用時(shí)延遲差異可以非常大。第二模型沒選對(duì)。很多項(xiàng)目的慢是因?yàn)榇a里寫死了某一個(gè)大模型名字所有人都在用它。去后臺(tái)看一眼真實(shí)流量分布很可能90%的請(qǐng)求都在用旗艦?zāi)Ｐ团芎?jiǎn)單任務(wù)。這是最常見的慢來(lái)源。第三沒用流式。非流式調(diào)用必須等完整內(nèi)容生成完才返回再快的模型在長(zhǎng)文本任務(wù)里也會(huì)顯得慢。把stream打開TTFT體驗(yàn)立刻不一樣。第四prompt太長(zhǎng)。你塞了5000字的上下文模型光讀題就要讀半天。快速模型最適合短小精悍的指令把無(wú)關(guān)的上下文清掉速度能提升一大截。我見過(guò)有人給分類任務(wù)配了800字的思維鏈?zhǔn)纠儗倮速M(fèi)。第五并發(fā)設(shè)計(jì)不合理。單線程串行調(diào)用多個(gè)模型后面的請(qǐng)求只能排隊(duì)。把獨(dú)立的調(diào)用改成并發(fā)執(zhí)行整體耗時(shí)能壓縮到原來(lái)的一半甚至更少。4.2 429、超時(shí)和限流的排查套路用OpenAI API做應(yīng)用最鬧心的就是碰到HTTP錯(cuò)誤碼。我把常見的幾個(gè)列成一張表方便對(duì)照處理。錯(cuò)誤碼含義常用處理辦法401API Key無(wú)效或未授權(quán)檢查Key是否正確、是否被吊銷403權(quán)限不足確認(rèn)賬號(hào)是否有該模型訪問權(quán)限404請(qǐng)求的資源/模型不存在確認(rèn)模型名拼寫、是否已下線429觸發(fā)限流或額度不足退避重試查用量額度檢查是否超額500服務(wù)端異常等幾秒后重試多次失敗則降級(jí)429是我遇到最多的。它有兩個(gè)可能一個(gè)是賬號(hào)的每分鐘請(qǐng)求次數(shù)RPM或者每分鐘token數(shù)TPM超限另一個(gè)是賬號(hào)余額不足。處理方式不是無(wú)腦重試而是先看錯(cuò)誤返回的具體message再?zèng)Q定是擴(kuò)容還是充值。重試必須用指數(shù)退避加抖動(dòng)程序里設(shè)置最大重試次數(shù)不要無(wú)限循環(huán)。還有一個(gè)容易被忽略的情況同一個(gè)Key在多處并發(fā)使用非常容易觸發(fā)429。把不同項(xiàng)目的Key拆開流量天然隔離互相不擠兌。4.3 成本爆了的三個(gè)常見原因成本失控的原因翻來(lái)覆去就是這幾個(gè)踩坑的人前赴后繼。第一個(gè)是循環(huán)調(diào)用沒設(shè)出口。寫了個(gè)自動(dòng)化腳本邏輯里忘記加停止條件結(jié)果腳本在后臺(tái)跑了一整夜把一個(gè)月的額度全燒完了。任何自動(dòng)調(diào)用必須設(shè)置次數(shù)上限和總金額上限用Python的tenacity庫(kù)給重試加上熔斷也可以關(guān)鍵是要有到此為止的機(jī)制。第二個(gè)是上下文無(wú)限累積。對(duì)話場(chǎng)景里把歷史消息無(wú)限拼進(jìn)請(qǐng)求token消耗隨輪數(shù)增長(zhǎng)越往后越貴還越來(lái)越慢。解決方法是做滑動(dòng)窗口只保留最近N輪對(duì)話或者做長(zhǎng)記憶的摘要壓縮把早期對(duì)話總結(jié)成幾個(gè)要點(diǎn)而不是原樣回傳。第三個(gè)是只算單次價(jià)格不算總量。單次調(diào)用看起來(lái)只要幾分錢但一天上百萬(wàn)次調(diào)用總量就是天文數(shù)字。我建議做一張簡(jiǎn)單的成本計(jì)算公式單次平均token數(shù)乘以調(diào)用量乘以單價(jià)隨時(shí)能做到心里有數(shù)。4.4 團(tuán)隊(duì)落地速度方案時(shí)的建議最后給團(tuán)隊(duì)協(xié)作的場(chǎng)景提幾個(gè)建議。我們?cè)诼涞剡@套速度分層方案時(shí)踩過(guò)不少配合上的坑總結(jié)下來(lái)有三條比較重要。第一把模型選擇收口到網(wǎng)關(guān)層不要散落在業(yè)務(wù)代碼里。各個(gè)業(yè)務(wù)方如果自己在代碼里寫死模型名后面想統(tǒng)一調(diào)整價(jià)格策略、切換模型版本會(huì)發(fā)現(xiàn)改都改不動(dòng)。做一個(gè)統(tǒng)一的路由層業(yè)務(wù)方只需要聲明任務(wù)類型路由層決定用哪個(gè)模型后續(xù)優(yōu)化都在一個(gè)地方改。第二建立延遲和成本的監(jiān)控大盤。你說(shuō)我們要快快不是一個(gè)形容詞要用具體指標(biāo)定義TTFT的P95是多少單次請(qǐng)求平均成本是多少這些指標(biāo)放到監(jiān)控頁(yè)面上每周復(fù)盤。沒有指標(biāo)就沒有改進(jìn)。第三給新人做一次Key安全和成本意識(shí)的培訓(xùn)。不是每個(gè)人都知道API Key泄露的嚴(yán)重性也不是每個(gè)人都會(huì)下意識(shí)地估算成本。花半小時(shí)講一遍真實(shí)盜刷案例比事后追責(zé)有用得多。我個(gè)人在實(shí)際操作中的體會(huì)是把快當(dāng)SLA來(lái)管理而不是當(dāng)默認(rèn)值來(lái)享受整個(gè)系統(tǒng)的穩(wěn)定性和成本會(huì)好很多。每次模型選型都問一句這個(gè)任務(wù)是該用最快的還是該用最聰明的問多了你對(duì)快的駕馭能力自然就上來(lái)了。