先從一起賬單異常說起。有一個(gè)功能上線兩周日活用戶幾乎沒有波動(dòng)可費(fèi)用賬單莫名其妙翻了快一倍。我最初的直覺是哪里出現(xiàn)了調(diào)用泄露或者有人掃了接口地址在做批量請(qǐng)求結(jié)果查了一圈日志發(fā)現(xiàn)調(diào)用量只漲了百分之十幾。真正的問題出在我自己寫的 Prompt 上——前一天下午我把系統(tǒng)提示詞從原來的三百多個(gè)字“優(yōu)化”成了滿滿兩頁(yè)的結(jié)構(gòu)化模板還隨手加了十幾條 few-shot 例子。然后整晚沒合眼反復(fù)盯著計(jì)費(fèi)后臺(tái)確認(rèn)了一個(gè)讓所有 AI 應(yīng)用開發(fā)者都需要警惕的事實(shí)Prompt 越長(zhǎng)越要按每次調(diào)用重復(fù)付費(fèi)這個(gè)錢比你想象中燒得快得多。這篇文章不聊宏大的技術(shù)趨勢(shì)只聊和賬單直接相關(guān)的 Token 計(jì)費(fèi)機(jī)制、隱形開銷和優(yōu)化手段。適合正在做大模型 API 集成、做聊天機(jī)器人、做內(nèi)容生成工具或者單純想把 API 成本壓下來的人。看完之后你至少能回答三個(gè)問題為什么 Prompt 會(huì)越寫越貴貴的部分到底貴在哪里以及改怎么把不必要的“字?jǐn)?shù)成本”降到最低。1. 從一次讓賬單翻倍的排查開始1.1 一次 API 調(diào)用到底按什么收費(fèi)所有主流大模型 API 都不是按“字?jǐn)?shù)”計(jì)費(fèi)而是按Token收費(fèi)。你可以把 Token 粗略理解為模型處理文本時(shí)的最小顆粒度它可能是半個(gè)詞、一個(gè)詞也可能是一小段標(biāo)點(diǎn)。每次請(qǐng)求的賬單由三部分組成單次調(diào)用費(fèi)用 輸入 Token 數(shù) × 輸入單價(jià) 輸出 Token 數(shù) × 輸出單價(jià)輸入單價(jià)和輸出單價(jià)不一樣通常是輸出比輸入貴兩到三倍。比如某模型定價(jià)是輸入 $1/百萬 Token、輸出 $2/百萬 Token那么一次請(qǐng)求輸出了 5000 Token光輸出部分就要花一美分左右——聽起來不多但如果每秒有幾十次調(diào)用一天就是幾十上百美元的量級(jí)。我在排查那次賬單翻倍時(shí)算了一筆賬系統(tǒng)提示詞從 350 字?jǐn)U到 2200 字對(duì)應(yīng)的 Token 增量大約是 3500 到 4000 個(gè)。平臺(tái)每分鐘平均有大約 2000 次調(diào)用每天近 300 萬次。多出來的 4000 Token × 300萬次 額外計(jì)費(fèi) 120億 Token。哪怕按輸入單價(jià)很低算也足以讓月度費(fèi)用直接翻倍。很多團(tuán)隊(duì)的誤區(qū)是只看 Prompt 的“最終效果”把 Prompt 當(dāng)作文檔來維護(hù)卻忘了它每一次都會(huì)被完整計(jì)費(fèi)。1.2 一個(gè)中文字符不等于一個(gè) Token字?jǐn)?shù)錯(cuò)覺帶來的成本誤判絕大多數(shù)人在預(yù)估 Prompt 長(zhǎng)度時(shí)都是拿“字?jǐn)?shù)”去衡量的這在英文場(chǎng)景里還湊合在中文場(chǎng)景里特別容易踩坑。主流平臺(tái)的 Tokenizer 對(duì)英文文本大致是 4 個(gè)字符對(duì)應(yīng) 1 個(gè) Token中文則往往是一個(gè)漢字對(duì)應(yīng) 1 到 2 個(gè) Token具體取決于分詞器實(shí)現(xiàn)和上下文窗口類型。這意味著同樣長(zhǎng)度的一段中英文混合文本實(shí)際 Token 數(shù)差別很大。我做過一個(gè)小實(shí)驗(yàn)同一句話分別用中英文表達(dá)統(tǒng)計(jì)出來的 Token 數(shù)常常差一倍以上內(nèi)容大致文本長(zhǎng)度大概 Token 數(shù)英文“Please write a Python function to sort a list”約 46 字符約 10中文“請(qǐng)寫一個(gè)Python函數(shù)來給列表排序”約 18 個(gè)字符約 14結(jié)構(gòu)化模板中文為主約 800 字約 1200結(jié)構(gòu)化模板中英混合、含代碼塊約 800 字約 1600注意上面只是示意數(shù)據(jù)不同模型的實(shí)際切分結(jié)果會(huì)有差異但規(guī)律是明確的不要用“字?jǐn)?shù)”去估 Prompt 成本要用 Tokenizer 跑一遍真實(shí) Token 數(shù)。平臺(tái)的控制臺(tái)或者本地 SDK 基本都提供了可視化 Token 統(tǒng)計(jì)接口展示一次請(qǐng)求消耗了多少輸入 Token 和輸出 Token排查費(fèi)用問題時(shí)第一件事就是把這些數(shù)值拉出來看而不是對(duì)著 Prompt 文本猜。實(shí)操提醒給團(tuán)隊(duì)定一個(gè)規(guī)矩任何 Promot 改動(dòng)上線前都必須記錄修改前后的 Token 總量并用一天高峰期調(diào)用量做一次費(fèi)用預(yù)估。這個(gè)習(xí)慣至少能避免一半以上的“Prompt 優(yōu)化導(dǎo)致成本激增”事故。2. 每次調(diào)用都在重復(fù)付費(fèi)的“固定開銷”系統(tǒng)提示詞、few-shot 與歷史消息很多人以為 Prompt 只是用戶輸入的那句話但真正燒錢的往往是你看不見的那部分。2.1 靜態(tài) Prompt 部分如何被反復(fù)計(jì)費(fèi)一個(gè)典型的 API 聊天請(qǐng)求傳進(jìn)去的是一個(gè)消息數(shù)組大致長(zhǎng)這樣{ model: chat-model, messages: [ {role: system, content: 你是一個(gè)專業(yè)的寫作助手……此處省略大量字?jǐn)?shù)}, {role: system, content: 使用以下格式輸出標(biāo)題/正文/摘要}, {role: user, content: 今天想寫一篇關(guān)于AI計(jì)費(fèi)的文章}, {role: assistant, content: 好的我來幫你寫} ] }問題的關(guān)鍵在于system里的所有內(nèi)容每當(dāng)用戶發(fā)起一次新請(qǐng)求都會(huì)原封不動(dòng)地發(fā)送給模型并完整計(jì)費(fèi)。它不會(huì)因?yàn)槟闵弦淮我呀?jīng)告訴過模型就被“記住”API 本身是無狀態(tài)的。除非你主動(dòng)把這份靜態(tài)內(nèi)容放進(jìn)緩存、或者用平臺(tái)提供的前綴緩存機(jī)制命中折扣否則這個(gè)代價(jià)是剛性支出。我見過不少團(tuán)隊(duì)把企業(yè)文化、產(chǎn)品說明、安全規(guī)范、語(yǔ)氣風(fēng)格指南、行業(yè)知識(shí)庫(kù)摘要、甚至幾十條實(shí)體抽取規(guī)則全部塞進(jìn) system 提示詞里一條 Prompt 輕松超過 10000 Token。這類 Prompt 在單次調(diào)用時(shí)看著不貴但一旦業(yè)務(wù)進(jìn)入穩(wěn)定期每天幾萬次調(diào)用Prompt 固定開銷 靜態(tài) Token 數(shù) × 調(diào)用次數(shù)就是一個(gè)不斷放大的乘法公式。要注意同一份靜態(tài) Prompt 并不會(huì)因?yàn)閮?nèi)容完全相同而自動(dòng)打折。不少平臺(tái)推出的“提示詞緩存”也需要符合條件的完整前綴匹配并不只是“內(nèi)容沒變就行”。2.2 多輪對(duì)話歷史成本像滾雪球一樣增長(zhǎng)多輪對(duì)話是成本增長(zhǎng)的第二大來源。每次新請(qǐng)求都會(huì)把之前的對(duì)話歷史重新拼在 messages 數(shù)組里發(fā)出去。對(duì)話持續(xù)輪次越多攜帶的歷史越長(zhǎng)。假設(shè)每輪用戶消息加助手回復(fù)平均 500 Token第 20 次請(qǐng)求時(shí)僅歷史部分就有大約 9500 Token這還沒算新的用戶輸入和系統(tǒng)提示詞。模型在理解上下文時(shí)也確實(shí)需要看到之前的對(duì)話但這個(gè)機(jī)制有一個(gè)很隱蔽的成本遞增規(guī)律每一次請(qǐng)求的輸入 Token 數(shù)量都是當(dāng)前全部歷史的累計(jì)值。從第 1 輪到第 N 輪輸入側(cè)總費(fèi)用近似與對(duì)話輪數(shù)的平方相關(guān)。也就是說如果一個(gè)用戶跟你聊了 30 輪他在后面幾輪里每一句話所牽動(dòng)的“背景開銷”都遠(yuǎn)大于前面幾輪。這還沒完Assistant 在歷史里生成的內(nèi)容通常偏長(zhǎng)二次或多次生成后累計(jì)歷史會(huì)迅速膨脹。實(shí)測(cè)經(jīng)驗(yàn)是10 輪以內(nèi)對(duì)話還算可控一旦超過 20 輪輸入部分的 Token 會(huì)增長(zhǎng)到讓人肉疼的程度——尤其是這些歷史還經(jīng)常包含大量重復(fù)說明性的內(nèi)容。2.3 函數(shù)定義、工具描述和 few-shot 也占輸入 Token除了系統(tǒng)提示詞和對(duì)話歷史凡是走 Function Calling 或 Tool Use 方案的函數(shù)聲明也會(huì)完整出現(xiàn)在每次請(qǐng)求的輸入里。函數(shù)簽名、參數(shù)描述、字段類型說明一個(gè)都沒法省。有些接口一次同時(shí)傳 20 個(gè)工具定義輸入 Token 瞬間多個(gè)幾千。few-shot 示例同理。你給每條示例都可能被完整換算成輸入 Token。有些做法是把一整套“高質(zhì)量輸出范例”全量塞進(jìn) Prompt美其名曰讓模型參考實(shí)際上一句話的信息增量只有幾十 Token卻讓整個(gè) Prompt 多出 3000 Token。這類“示范型”靜態(tài)內(nèi)容是 Prompt 變貴最常見的隱性原因。3. 同一個(gè)任務(wù)兩種 Prompt 寫法費(fèi)用差多少一次實(shí)測(cè)對(duì)比只看理論夠不著痛處下面我用實(shí)際可復(fù)現(xiàn)的對(duì)比來說話。3.1 詳細(xì)版 Prompt 與精簡(jiǎn)版 Prompt 的差異假設(shè)任務(wù)很簡(jiǎn)單從用戶評(píng)論里抽取情感傾向并輸出 JSON。我分別寫了兩個(gè)版本。詳細(xì)版約 1200 字純中文系統(tǒng) 你是一個(gè)具備深度情感分析能力的專業(yè)客服輿情分析助手你的任務(wù)是分析用戶評(píng)論的情感傾向。 請(qǐng)嚴(yán)格遵循以下要求 1. 首先仔細(xì)閱讀用戶評(píng)論內(nèi)容 2. 判斷該評(píng)論的情感極性可選值是positive、negative、neutral 3. 如果評(píng)論屬于正面輸出positive 4. 如果評(píng)論屬于負(fù)面輸出negative 5. 如果無法判斷輸出neutral 6. 不要輸出任何多余內(nèi)容 7. 以下是幾個(gè)例子 用戶評(píng)論這個(gè)app太好用了強(qiáng)烈推薦 情感傾向positive 用戶評(píng)論垃圾產(chǎn)品再也不用了 情感傾向negative 此處省略更多示例 現(xiàn)在請(qǐng)分析以下評(píng)論精簡(jiǎn)版約 60 字系統(tǒng) 你是情感分析器。僅輸出JSON{sentiment:positive|negative|neutral} 用戶 這個(gè)app太好用了強(qiáng)烈推薦Token 數(shù)估算如下版本用戶輸入 Token 數(shù)輸出 Token 數(shù)詳細(xì)版約 300約 25精簡(jiǎn)版約 45約 25單次調(diào)用差不了幾厘錢但乘上調(diào)用量就完全不一樣了。3.2 放大到真實(shí)業(yè)務(wù)量費(fèi)用差距有多大假設(shè)輸入單價(jià) $1/百萬 Token輸出單價(jià) $2/百萬 Token每天調(diào)用 100 萬次版本單次輸入費(fèi)用單次輸出費(fèi)用每天費(fèi)用詳細(xì)版300 × 1 ÷ 1000000 $0.000325 × 2 ÷ 1000000 $0.00005約 $350精簡(jiǎn)版45 × 1 ÷ 1000000 $0.00004525 × 2 ÷ 1000000 $0.00005約 $95同樣一個(gè)任務(wù)只是把 Prompt 寫短寫干凈每天能省約 70% 的輸入成本。再疊加多輪對(duì)話歷史差距還會(huì)拉大因?yàn)樵敿?xì)版經(jīng)過幾輪之后歷史中的“靜態(tài)廢話”會(huì)不斷增加每一次后續(xù)請(qǐng)求的 Token 數(shù)。3.3 詳細(xì)版容易誘導(dǎo)模型輸出更多內(nèi)容這才是賬單爆炸的真正推手上面對(duì)比里輸出端暫時(shí)一致但現(xiàn)實(shí)中詳細(xì)版 Prompt 往往會(huì)導(dǎo)致輸出更長(zhǎng)。比如詳細(xì)版里寫了“請(qǐng)逐步分析”“先思考再回答”這類引導(dǎo)詞模型輸出時(shí)就會(huì)按照思維鏈的形式生成大段推理內(nèi)容。如果最終產(chǎn)品只要求一個(gè) JSON 字段這部分“思考過程”就完全是額外費(fèi)用。有一次我在調(diào)試一個(gè)分類功能輸入 Prompt 加了一句“讓我們一步一步來分析”某模型的輸出 Token 直接從 80 漲到 1200效果還沒有任何提升。后來把推理過程關(guān)掉、改成要求只輸出結(jié)構(gòu)化 JSON輸出端成本立刻降到原來的十分之一。把 Prompt 寫長(zhǎng)并不等于把效果寫好它經(jīng)常只是把“公共場(chǎng)合說話”時(shí)的解釋性內(nèi)容無限放大同時(shí)給額外扣費(fèi)。4. 把 Prompt 做“薄”的五種實(shí)操手段聊完問題根源下面是我實(shí)際落地過的優(yōu)化方法按收益從高到低排列。4.1 善用平臺(tái)自帶的前綴緩存把靜態(tài)內(nèi)容放前面現(xiàn)在不少模型服務(wù)商提供自動(dòng)或手動(dòng)的 Prompt 前綴緩存命中后輸入價(jià)格會(huì)大幅降低某些平臺(tái)的緩存命中價(jià)格只有原價(jià)的十分之一左右。關(guān)鍵在于緩存的匹配通常是基于前綴完全一致的所以必須把穩(wěn)定不變的內(nèi)容放在 messages 數(shù)組最前面。我現(xiàn)在的做法是系統(tǒng)提示詞固定放在第一段最少量的靜態(tài)示例緊隨其后然后把動(dòng)態(tài)變化的用戶消息、工具結(jié)果放在末尾。這樣每次請(qǐng)求的公網(wǎng)前綴都能命中緩存長(zhǎng)期下來靜態(tài)那一大段花的錢就幾乎可以忽略。注意如果系統(tǒng)提示詞每次都在變比如塞了當(dāng)前時(shí)間、隨機(jī)數(shù)字、每次都會(huì)變化的動(dòng)態(tài)指令緩存就會(huì)頻繁失效費(fèi)用立刻飆升。不建議為了湊緩存故意把 Prompt 順序調(diào)得很別扭。先保證邏輯順序再考慮緩存。4.2 精簡(jiǎn)系統(tǒng)提示詞只留“必須做什么”刪掉“解釋為什么”我復(fù)盤之前那版膨脹的系統(tǒng)提示詞時(shí)發(fā)現(xiàn)大量?jī)?nèi)容屬于“解釋性文字”“本工具旨在提升客服團(tuán)隊(duì)的響應(yīng)效率因此你要……”“考慮到不同用戶的表達(dá)習(xí)慣存在差異……”“你的回答應(yīng)當(dāng)體現(xiàn)專業(yè)、耐心的服務(wù)態(tài)度……”模型不需要知道業(yè)務(wù)背景它只需要明確的指令。那些說明背景的句子占用的是你每次調(diào)用的輸入 Token。把它直接刪掉用更短的祈使句替代通常不會(huì)降低效果。一個(gè)通用的精簡(jiǎn)公式是角色 任務(wù) 輸出格式約束 邊界條件而不是大段背景介紹 角色設(shè)定 開放式要求 冗余例子 補(bǔ)充說明4.3 控制 few-shot 數(shù)量從二十條壓到兩三條few-shot 是消耗輸入 Token 的大戶。每加一條示例輸入 Token 就固定增加幾百效果收益卻往往邊際遞減。我的經(jīng)驗(yàn)是90% 的任務(wù)里3 條以內(nèi)高質(zhì)量、覆蓋邊界的示例效果等同于 20 條示例。真正需要模型參考的往往不是“通用例子”而是“邊界情況”。比如做情感分類與其貼“這個(gè)很好”和“這個(gè)很壞”不如貼一個(gè)“這個(gè)產(chǎn)品價(jià)格便宜但質(zhì)量一般有一點(diǎn)失望”這種模糊案例。把一個(gè)有信息量的邊界示例放進(jìn)去比十個(gè)明晃晃的正例有用得多。多出來的邊界描述也只用一條示例就夠了。4.4 給歷史消息做摘要壓縮而不是無限堆積多輪對(duì)話場(chǎng)景里最有效的手段不是每條歷史都全量帶回而是把早期歷史以摘要形式存儲(chǔ)并在合適的時(shí)機(jī)替換掉原文。我在實(shí)際項(xiàng)目中常用兩層策略最近 5 輪對(duì)話保留全文保證模型對(duì)近期用戶意圖的精確理解更早的對(duì)話由另一個(gè)輕量模型定期生成一段 50 到 100 Token 的摘要或者直接用規(guī)則抽取關(guān)鍵信息然后替換掉完整原文。這樣做的好處是用戶聊到 50 輪時(shí)輸入 Token 不會(huì)從 5 輪時(shí)的 2500 Token 線性漲到 20000 Token而是基本穩(wěn)定在 5000 Token 左右。如果產(chǎn)品形態(tài)允許也可以直接限制單次會(huì)話的最長(zhǎng)輪數(shù)比如 20 輪后提示用戶開啟新會(huì)話。雖然體驗(yàn)上有點(diǎn)“硬”但對(duì)成本控制特別有效。4.5 用結(jié)構(gòu)化輸出與參數(shù)卡住輸出長(zhǎng)度每次調(diào)用時(shí)設(shè)置合理的max_tokens上限并盡量要求模型以 JSON 或其他結(jié)構(gòu)化格式輸出可以從源頭壓低輸出端費(fèi)用。比如做信息抽取輸出格式{summary: 不超過50字, keywords: [最多3個(gè)]}再配合 API 參數(shù)里的溫度調(diào)低、開啟 JSON 模式模型就不太會(huì)在回答里加無關(guān)的“好的我來處理”之類的客套話和解釋。輸出 Token 少了費(fèi)用自然就降。寫一個(gè)小工具做日常審計(jì)可以預(yù)判改動(dòng)后的成本def estimate_cost(prompt_token, output_token, input_price, output_price, daily_calls): daily_input_cost prompt_token * daily_calls * input_price daily_output_cost output_token * daily_calls * output_price return daily_input_cost daily_output_cost # 修改 Prompt 后運(yùn)行一次即可看到費(fèi)用預(yù)估 print(estimate_cost(300, 25, 1/1_000_000, 2/1_000_000, 1_000_000))5. 計(jì)費(fèi)文檔不會(huì)主動(dòng)提醒你的三個(gè)細(xì)節(jié)結(jié)合我個(gè)人的排查經(jīng)驗(yàn)和讀過的計(jì)費(fèi)文檔還有幾個(gè)容易忽略的細(xì)節(jié)需要單獨(dú)列出來。5.1 報(bào)錯(cuò)與中斷也可能照樣扣費(fèi)請(qǐng)求如果已經(jīng)進(jìn)入模型推理階段即使網(wǎng)絡(luò)中斷、客戶端主動(dòng)取消、或者模型在中途觸發(fā)了某個(gè)審核規(guī)則已生成并計(jì)費(fèi)的部分可能仍然會(huì)出現(xiàn)在賬單里。不同平臺(tái)的結(jié)算規(guī)則不一樣但不少是按“已處理 Token”計(jì)費(fèi)的而不是按“最終正常返回”計(jì)費(fèi)。我在某個(gè)項(xiàng)目里做過一次對(duì)比對(duì)同一個(gè)請(qǐng)求重試 5 次其中有 3 次中斷最終賬單里多扣的正是中斷那一刻已生成的 Token。解決辦法是非關(guān)鍵路徑上盡可能使用超時(shí)重試策略不要無限重試對(duì)實(shí)時(shí)性要求不高的任務(wù)盡量走異步接口或批量接口通常這類接口在失敗時(shí)更容易拿到明確不計(jì)費(fèi)的保障。5.2 緩存命中和未命中的價(jià)格差“必須完全一致”的前綴規(guī)則前面提過緩存這里補(bǔ)充一個(gè)關(guān)鍵細(xì)節(jié)不同平臺(tái)的緩存粒度差異很大。有的平臺(tái)只要前 1024 個(gè) Token 完全一致就能命中有的平臺(tái)要求整個(gè)輸入完全相同才能命中。最實(shí)用的判斷方法是查看計(jì)費(fèi)日志里的緩存命中標(biāo)記如果沒有這個(gè)標(biāo)記就手動(dòng)對(duì)照線上實(shí)際每輪請(qǐng)求的清單一查便知。需要特別小心的是開場(chǎng)白或模板里的動(dòng)態(tài)變量比如“今天是 2026 年 5 月 12 日”這種如果放在系統(tǒng)提示詞的固定前綴中每次都會(huì)破壞緩存命中。把這類動(dòng)態(tài)內(nèi)容挪到消息末尾或者干脆不放比讓模型知道“今天是哪天”更重要——除非這個(gè)日期對(duì)輸出有實(shí)質(zhì)影響。5.3 max_tokens 不是省錢開關(guān)理解生成停止條件把 max_tokens 從 4096 改到 128確實(shí)能限制輸出長(zhǎng)度但它的副作用是如果任務(wù)本身的正確輸出就超過這個(gè)長(zhǎng)度模型會(huì)在截?cái)嗵幫Ｖ狗祷匾粋€(gè)不完整的結(jié)果甚至產(chǎn)生格式損壞、JSON 截?cái)嗟葐栴}反而增加下一次糾錯(cuò)請(qǐng)求的成本。所以正確用法是先摸清每個(gè)任務(wù)的實(shí)際輸出 Token 分布再設(shè)置一個(gè)“略高于正常值”的 max_tokens而不是為了省錢而壓得太狠。我一般取正常輸出 Token 分布的 95 分位再乘以 1.2 作為上限。5.4 貴模型做難事便宜模型做雜事如果項(xiàng)目里同時(shí)依賴不同檔位的模型建議按任務(wù)拆分配置而不是讓所有請(qǐng)求都走向最貴的大模型。我接觸過的一個(gè)內(nèi)容審核系統(tǒng)原來統(tǒng)一用最貴模型跑全文審核流量一到高峰期賬單直線上升。后來改成先用便宜的小模型做粗篩把明顯安全的評(píng)論直接通過只有置信度較低的評(píng)論才送進(jìn)貴模型做二次判斷總費(fèi)用降了接近一半準(zhǔn)確率甚至還有小幅提升。這套思路同樣適用于 Prompt讓“長(zhǎng)任務(wù)”走需要深度推理的模型讓“短任務(wù)、強(qiáng)約束、格式固定”的請(qǐng)求走便宜模型。很多平臺(tái)不同檔位間的價(jià)格差能到幾倍甚至十倍選型帶來的成本差異遠(yuǎn)超 Prompt 微調(diào)。6. 每次改完 Prompt 之后我還會(huì)做的一道審計(jì)這節(jié)其實(shí)是我自己的一個(gè)習(xí)慣也算給本文一個(gè)自然的落點(diǎn)。在每次修改 Prompt、上線新功能、或者調(diào)整模型參數(shù)之前我會(huì)打開一個(gè)簡(jiǎn)單的清單用 Tokenizer 統(tǒng)計(jì)當(dāng)前完整 messages 的輸入 Token 數(shù)統(tǒng)計(jì)其中靜態(tài)系統(tǒng)提示詞 靜態(tài) few-shot 的 Token 占比再統(tǒng)計(jì)歷史消息的平均 Token 數(shù)和最大對(duì)話輪數(shù)按昨日有效調(diào)用量估算一次單日成本檢查動(dòng)態(tài)變量是否破壞前綴緩存確認(rèn) max_tokens 是否合理、是否允許結(jié)構(gòu)化輸出。這套動(dòng)作花不了五分鐘但已經(jīng)幫我攔住過三次差點(diǎn)上線的成本事故。尤其是第一和第二條只要靜態(tài)部分在整體輸入里的占比超過 30%我就會(huì)重新考慮拆分任務(wù)、縮精提示詞或者換更便宜模型。實(shí)際上最深刻的體會(huì)是Prompt 越寫越貴通常不是因?yàn)樗娴男枰覀兏顿M(fèi)那么多而是因?yàn)槲覀儼选案嬖V模型一句有用的話”和“把一本書塞進(jìn)模型腦子里”混為一談。大模型 API 的計(jì)費(fèi)本質(zhì)是按計(jì)算資源消耗來收取只要模型還在處理那堆不會(huì)產(chǎn)生增量應(yīng)該的冗余文字賬單就會(huì)繼續(xù)增長(zhǎng)。與其糾結(jié)一個(gè)詞一個(gè)詞的措辭不如定期回到 Token 數(shù)和調(diào)用量這兩項(xiàng)基礎(chǔ)指標(biāo)上做體檢。希望這次的解構(gòu)對(duì)你手上的項(xiàng)目也有幫助。如果你也在為 API 賬單上的陡增曲線頭疼可以試著從靜態(tài) Prompt 開始減重多數(shù)情況下效果會(huì)來得比想象中更快。