近段時間關(guān)于 Claude 這類商用大模型 API 成本過高的討論越來越多。標題里出現(xiàn)的“180萬刀”不一定能對應到一份可考證的真實賬單但它反映的焦慮是真實的大模型能力越強單次調(diào)用的成本越高當業(yè)務(wù)量起來以后模型 API 費用會在沒有充分預警的情況下快速膨脹。很多團隊在試點階段只關(guān)心回答質(zhì)量到了生產(chǎn)環(huán)境才發(fā)現(xiàn)大模型 API 已經(jīng)成為每月云成本里最不可控的一項。對于開發(fā)者和技術(shù)決策者來說真正要解決的問題不是爭論某個數(shù)字是否真實而是理解大模型成本的結(jié)構(gòu)、估算方法和控制手段避免自己的賬單在某個月底徹底失控。1. 大模型成本焦慮背后真正要算清的賬是什么1.1 為什么“調(diào)用一次”的成本不是一個固定值很多團隊第一次接入大模型 API 時會下意識把它類比成短信接口發(fā)送一個請求計一次費。但大模型 API 的計費單位不是“次”而是 token。token 是模型處理文本的基本單位可以理解成模型眼中的“單詞碎片”。在英文場景中一個 token 大約對應 0.7 到 1 個單詞在中文場景中一個漢字大約對應 1 到 2 個 token。因此一次請求的成本由四個部分共同決定輸入 token 數(shù)量包括系統(tǒng)提示詞、用戶消息、歷史對話、檢索到的資料。輸出 token 數(shù)量模型生成回答的長度。是否命中緩存同樣的輸入前綴是否在其他請求里出現(xiàn)過。調(diào)用方式實時接口、批量接口、流式輸出價格和計費規(guī)則不同。同樣是“調(diào)用一次”讓模型回答“你好”和讓模型分析一份 5000 字的財務(wù)報表成本可能相差幾十倍。這就是大模型成本難控的第一個原因成本不是由調(diào)用次數(shù)決定而是由每次調(diào)用攜帶的文本量決定。1.2 訓練成本和推理成本要分開看標題里的“燒不起”在不同語境下指的是兩筆完全不同的錢。訓練成本是一次性投入。訓練一個大規(guī)模模型需要數(shù)千張高性能 GPU 連續(xù)運行數(shù)周甚至數(shù)月電費、硬件折舊、網(wǎng)絡(luò)帶寬、人工調(diào)參成本全部疊加最終分攤到模型發(fā)布方的資產(chǎn)負債表上。對于普通業(yè)務(wù)團隊來說訓練成本與自身沒有直接關(guān)系因為你買的是 API不是 GPU 集群。推理成本則是持續(xù)運營成本。每次用戶請求模型生成內(nèi)容時模型服務(wù)商都要占用 GPU 資源做前向計算。為了讓線上 API 穩(wěn)定響應服務(wù)商需要長期維護一批 GPU 集群這些成本最終會以 token 單價的形式傳導給調(diào)用方。這兩筆賬不能混淆。如果團隊內(nèi)部討論“成本太高”要先明確說的是哪一筆是自研模型的訓練預算超了還是線上 API 月度賬單漲了。兩者對應的優(yōu)化手段完全不同。前者要考慮數(shù)據(jù)質(zhì)量、并行策略、算力調(diào)度后者要考慮 prompt 壓縮、緩存、模型分級和調(diào)用量治理。成本類型產(chǎn)生階段發(fā)生頻率主要承擔方優(yōu)化方向訓練成本模型開發(fā)期一次性或按版本周期模型廠商、自研團隊數(shù)據(jù)質(zhì)量、算力調(diào)度、訓練效率推理成本模型上線后每次請求持續(xù)發(fā)生模型廠商與業(yè)務(wù)調(diào)用方prompt、緩存、模型分級、調(diào)用治理2. 用 Token 計價公式拆解一次 API 調(diào)用的成本2.1 輸入輸出分開計費價格差異為什么這么大商用模型 API 的價格表里通常至少有三列輸入價格、輸出價格、緩存輸入價格。以常見模型的計價區(qū)間為例輸入價格可能在每百萬 token 幾美元輸出價格往往是輸入價格的 3 到 5 倍緩存輸入價格則可能是完整輸入價格的十分之一甚至更低。輸出 token 更貴不是服務(wù)商隨意定價而是受計算方式影響。模型生成回答時必須逐個 token 采樣每一步都依賴前一步的結(jié)果這個過程無法并行。輸入 token 的處理卻可以在大規(guī)模并行計算中高效完成。所以同樣數(shù)量 token模型“寫”比“讀”占用 GPU 時間長成本自然更高。理解這個結(jié)構(gòu)后可以得到兩個直接結(jié)論讓模型少說話就減少了最貴的部分。讓模型的常見回答盡量短比壓縮用戶輸入更能省錢。2.2 一個客服場景的成本估算示例假設(shè)一個智能客服系統(tǒng)每次請求包含 800 個輸入 token其中 200 token 是固定系統(tǒng)提示600 token 是用戶問題和檢索到的知識片段。模型平均輸出 350 token。日調(diào)用量 10 萬次一個月按 30 天計算。月輸入 token 總量800 × 100000 × 30 2400000000即 24 億 token折算 2400 百萬 token。月輸出 token 總量350 × 100000 × 30 1050000000即 10.5 億 token折算 1050 百萬 token。按一個接近常見商用模型的價格區(qū)間計算輸入每百萬 token 3 美元輸出每百萬 token 15 美元月輸入成本2400 × 3 7200 美元。月輸出成本1050 × 15 15750 美元。月總成本22950 美元。這只是日調(diào)用 10 萬次的中等規(guī)模場景。如果業(yè)務(wù)增長到日調(diào)用 100 萬次月成本會接近 23 萬美元一年就是 276 萬美元。這個量級和標題里的“180萬刀”處在同一個區(qū)間。可見大模型 API 賬單快速膨脹并不需要什么異常配置只要業(yè)務(wù)量漲 10 倍成本就會同比例漲 10 倍而團隊很容易低估這個增長速度。2.3 上下文越長隱藏成本越高很多團隊會把大量固定資料拼進 prompt比如產(chǎn)品文檔、客服話術(shù)、知識庫片段結(jié)果發(fā)現(xiàn)每次請求都攜帶很大體積的上下文。這里有一個容易忽略的問題如果每次請求都是全新對話沒有復用公共前綴那么所有輸入 token 都會按完整價格計費。上下文長度翻倍單次輸入成本基本翻倍。同時模型需要處理的輸入變長首字延遲也會上升。更麻煩的是有些場景為了讓模型記住長對話會不斷把歷史消息累加進上下文導致請求越往后越貴。對話進行 10 輪時輸入可能從最初的 500 token 漲到 5000 token成本上漲是線性的但用戶并不覺得模型變強了。要控制隱藏成本第一步是觀察每次請求返回結(jié)果里的 usage 字段。幾乎主流模型 API 都會在響應中返回 prompt_tokens、completion_tokens、total_tokens把這些字段記入日志才能知道成本到底花在哪里。3. 高成本來自哪里從并發(fā)、緩存到錯誤重試3.1 并發(fā)不會讓單價變便宜但會放大浪費有些團隊認為提高并發(fā)就能攤薄成本這是誤解。并發(fā)只是同時發(fā)出更多請求每個請求仍然按 token 獨立計費。真正的成本問題是并發(fā)請求中是否存在大量重復內(nèi)容。典型場景是內(nèi)容改寫。業(yè)務(wù)方一次性對 100 條商品文案調(diào)用模型做調(diào)整每條請求都帶著同一份 2000 token 的說明文檔。表面上看是 100 次調(diào)用實際上說明文檔被完整計費了 100 次。類似的還有批量審核、批量摘要、批量翻譯。如果前置一步將公共說明文檔抽離出來或者把多條短文本合并成一個請求就能顯著減少重復 token 消耗。并發(fā)還會放大超時重試的問題。當客戶端設(shè)置了較短的超時時間而模型響應稍微變慢客戶端就會重發(fā)請求。高并發(fā)場景下一次服務(wù)抖動可能觸發(fā)大量重試賬單在幾分鐘內(nèi)翻倍。3.2 緩存命中率決定成本曲線緩存是控制大模型成本最有效的手段之一但要區(qū)分兩種緩存。服務(wù)端 prompt 緩存部分模型服務(wù)商會對固定前綴的輸入 token 提供折扣價。只要請求的 input 前綴相同重復部分按緩存價計費。適合系統(tǒng)提示詞固定、業(yè)務(wù)參數(shù)放在后面的場景。使用前提是請求必須保持前綴一致不能每次調(diào)整提示詞格式。業(yè)務(wù)側(cè)語義緩存把完全相同或語義相近的問題結(jié)果緩存到 Redis 或數(shù)據(jù)庫中。當用戶問一個已經(jīng)被回答過的問題時直接返回緩存結(jié)果不調(diào)用模型。這種緩存對高頻重復問題效果極好成本可能下降 50% 以上。緩存類型適用場景命中條件成本效果注意點服務(wù)端 prompt 緩存固定系統(tǒng)提示詞、長文檔前綴輸入前綴完全一致命中部分按優(yōu)惠價計費提示詞結(jié)構(gòu)必須穩(wěn)定業(yè)務(wù)側(cè)語義緩存高頻問題、重復任務(wù)語義相似度超過閾值完全省去一次模型調(diào)用需要維護向量索引和緩存策略3.3 重試、超時和錯誤處理容易造成成本翻倍網(wǎng)絡(luò)請求失敗后重試是開發(fā)者的直覺動作。但在大模型 API 場景里盲目重試可能造成重復計費。假設(shè)客戶端設(shè)置 30 秒超時。模型實際已經(jīng)處理完請求并生成了回答只是響應在網(wǎng)絡(luò)上多花了 2 秒客戶端判斷超時后立刻重發(fā)。第一筆請求的費用已經(jīng)產(chǎn)生第二次請求又會新增一筆費用。如果這種超時大量出現(xiàn)賬單會異常增長。正確做法是給請求設(shè)置合理的超時時間并且對重試請求做冪等控制。如果 API 支持請求 ID可以在重試時帶上相同的 ID如果不支持至少要把原始請求對應的 request_id 記錄在日志里用于對賬排查。import time import requests def call_model_with_idempotency(payload, timeout60, max_retries2): # 為每次業(yè)務(wù)操作生成一個穩(wěn)定請求ID request_id payload.get(business_id) or str(int(time.time() * 1000)) for attempt in range(max_retries): try: response requests.post( https://api.example.com/v1/chat/completions, jsonpayload, headers{X-Request-Id: request_id}, timeouttimeout, ) # 服務(wù)端可能返回重復請求標識 if response.status_code 429: # 限流等待后重試 time.sleep(2 ** attempt) continue if response.status_code 500: time.sleep(2 ** attempt) continue return response.json() except requests.Timeout: # 超時不代表請求沒有到達服務(wù)端重試前確認業(yè)務(wù)冪等 time.sleep(2 ** attempt) return None這段示例的關(guān)鍵點在于超時后重新發(fā)起請求但每次請求都攜帶業(yè)務(wù)側(cè)生成的 request_id。只有當模型服務(wù)商支持請求去重時這種重試才真正安全如果服務(wù)商不支持團隊必須在日志層面將重復請求識別出來。4. 控制大模型 API 成本的具體手段4.1 Prompt 壓縮先去掉重復和無效 token成本治理的第一步不是改代碼而是審視 prompt。一份 2000 token 的 prompt 壓到 600 token成本直接降低 70%。壓縮方式包括刪掉冗余背景說明、把長段落改成要點列表、用更短的指令描述目標、把動態(tài)內(nèi)容與固定內(nèi)容分離。下面是一個壓縮前后的對比示例。壓縮前你是一個專業(yè)的電商客服助手你需要幫助用戶解決在購買商品過程中遇到的各種問題。請根據(jù)下面提供的商品退換貨政策結(jié)合用戶的描述給出詳細、友好、專業(yè)、易于理解的回答。商品退換貨政策如下消費者在收到商品之日起七日內(nèi)如果商品存在質(zhì)量問題可以選擇退貨、換貨或者修理如果商品無質(zhì)量問題但消費者不想要了在商品保持完好且不影響二次銷售的情況下也可以在七日內(nèi)申請無理由退貨……壓縮后你是電商客服助手。退貨政策質(zhì)量問題7日內(nèi)可退換修無理由退貨需商品完好。用戶問題{user_question}壓縮后信息沒有減少但 token 大幅減少。實際項目中建議把固定系統(tǒng)提示詞和動態(tài)用戶輸入徹底分開固定部分放前面動態(tài)部分放后面保持結(jié)構(gòu)穩(wěn)定。4.2 模型分級貴模型只處理復雜任務(wù)所有請求都使用最強大模型是最常見的浪費。實際業(yè)務(wù)里大量請求只需要簡單分類、關(guān)鍵詞抽取、格式化輸出用參數(shù)較小的模型就能完成?？梢栽O(shè)計一個請求路由層先根據(jù)任務(wù)類型或輸入復雜度判斷應使用哪個模型。簡單問題走輕量模型復雜推理走重量模型。def route_model(message: str, message_length: int) - str: # 簡單指令或短文本使用輕量模型 if message_length 200 and not requires_reasoning(message): return light-model # 需要復雜推理、長上下文、代碼生成使用重量模型 return heavy-model這個路由函數(shù)只是一個示例。生產(chǎn)環(huán)境中建議把路由邏輯做成可配置規(guī)則而不是硬編碼。例如長度小于某個閾值、包含明確動作詞、可以匹配到標準問法的問題都優(yōu)先走輕量模型只有需要深度分析、多步推理、長文生成的內(nèi)容才調(diào)用重量模型。4.3 緩存、批量、流式三種方式對比在真實的成本治理中緩存、批量、流式是三個不同維度的優(yōu)化手段可以組合使用。優(yōu)化方式解決什么問題成本效果使用前提服務(wù)端 prompt 緩存重復輸入前綴重復部分按優(yōu)惠價計費提示詞前綴穩(wěn)定業(yè)務(wù)側(cè)語義緩存完全相同或相似請求完全省去模型調(diào)用高頻重復場景需要向量檢索能力批量 API非實時場景通常比實時接口有折扣可以接受分鐘級延遲流式輸出控制首字延遲與超時不直接降 token 成本但減少重試浪費客戶端需要支持流式解析這里要特別提醒流式輸出并不會降低 token 總數(shù)它只是讓模型邊生成邊返回用戶等待時間變短。它的成本價值在于當響應時間變短后客戶端超時重試的概率會下降間接減少重復計費。4.4 預算告警與配額控制從被動看賬單到主動熔斷只看月底賬單等于事后補救。正確的做法是在代碼層面對成本做實時統(tǒng)計和控制。可以用 Redis 記錄每日 token 消耗每次請求后累加 usage當消耗超過閾值時觸發(fā)告警或熔斷。import redis import time r redis.Redis(hostlocalhost, port6379, db0) DAILY_BUDGET 1000000 # 每日允許的token總上限 def record_usage(prompt_tokens: int, completion_tokens: int) - bool: today time.strftime(%Y-%m-%d) key ftoken_usage:{today} total prompt_tokens completion_tokens new_total r.incrby(key, total) # 設(shè)置key過期時間避免長期占用內(nèi)存 r.expire(key, 86400) if new_total DAILY_BUDGET: # 觸發(fā)告警可以接入釘釘、企業(yè)微信、郵件等渠道 send_alert(f今日token消耗已達 {new_total}超過預算 {DAILY_BUDGET}) return False return True這是一個最小示例。生產(chǎn)環(huán)境還需要考慮多個服務(wù)實例并發(fā)累加時的原子性、Redis 故障時的降級策略、預算閾值應該按賬號或按業(yè)務(wù)線拆分。配額控制的目的是讓系統(tǒng)在成本失控前先停下來而不是等賬單出來再去追責。5. 排查成本異常賬單暴漲怎么定位5.1 先描述現(xiàn)象再定排查順序成本異常的典型現(xiàn)象是月度賬單從幾百美元突然漲到幾千美元或者沒有任何業(yè)務(wù)發(fā)布卻出現(xiàn)明顯的費用尖峰。排查順序建議如下先看調(diào)用量統(tǒng)計每天的調(diào)用次數(shù)找出增長起點。再看單次請求用量檢查 usage 字段中的 prompt_tokens 和 completion_tokens 是否異常。然后看重復請求確認是否存在超時重試、客戶端循環(huán)調(diào)用、定時任務(wù)失控。最后看 prompt 大小是否有人把大段文檔作為 prompt 發(fā)送或歷史消息無限累加。5.2 用日志和指標定位費用尖峰成本治理的前提是把每次請求的 token 用量記錄成結(jié)構(gòu)化日志。建議至少記錄以下字段時間、業(yè)務(wù)場景、模型名稱、prompt_tokens、completion_tokens、total_tokens、請求 ID、是否命中緩存。將日志寫入 ClickHouse、Elasticsearch 或普通數(shù)據(jù)庫后可以按小時聚合 total_tokens。SELECT date_trunc(hour, request_time) AS hour, model_name, SUM(prompt_tokens) AS total_prompt, SUM(completion_tokens) AS total_completion, COUNT(*) AS request_count FROM model_api_logs WHERE request_time now() - INTERVAL 7 DAY GROUP BY hour, model_name ORDER BY hour DESC;如果某個小時的總 token 明顯高于其他小時再往前查那一小時的請求明細看是不是某個業(yè)務(wù)線在跑定時任務(wù)還是某臺服務(wù)器發(fā)生了循環(huán)調(diào)用。5.3 常見根因?qū)φ毡韱栴}現(xiàn)象常見原因檢查方式處理建議單日費用突增定時任務(wù)未加開關(guān)批量補跑歷史數(shù)據(jù)查看指定時段的請求數(shù)量為批量任務(wù)加限流和人工確認請求次數(shù)不高但費用高每次請求輸出過長或 prompt 攜帶大量文檔查看 average completion_tokens限制 max_tokens壓縮輸入拆分長任務(wù)半夜費用異常重試循環(huán)未加退避查看相同業(yè)務(wù) ID 的重復請求重試加指數(shù)退避和最大次數(shù)緩存不生效提示詞每次都拼接相同內(nèi)容但前后順序不一致檢查前綴是否穩(wěn)定固定系統(tǒng)提示詞順序不要動態(tài)插入前置內(nèi)容輸出 token 超預期沒有設(shè)置 max_tokens模型自由發(fā)揮檢查請求參數(shù)根據(jù)業(yè)務(wù)場景設(shè)置輸出長度上限6. 從“燒不起”到“用得起”的成本治理清單6.1 成本治理應該落在五個層次單靠省 prompt 或換模型解決不了系統(tǒng)性的成本問題。大模型 API 成本治理需要分層次推進路由層任務(wù)分級簡單任務(wù)不調(diào)用重量級模型。請求層壓縮 prompt、限制輸出長度、設(shè)置超時與重試策略。數(shù)據(jù)層建立服務(wù)端緩存、業(yè)務(wù)側(cè)緩存避免重復計算。監(jiān)控層記錄每次請求的 token 用量按小時聚合設(shè)置預算告警。組織層在代碼評審中檢查模型調(diào)用定期復盤各業(yè)務(wù)線的 token 成本。這五個層次缺一不可。只有監(jiān)控沒有路由成本會繼續(xù)漲只有路由沒有緩存重復請求仍然花錢只有代碼治理沒有組織約束新功能上線時可能重新引入高成本寫法。6.2 成本治理可復用檢查清單在接入新的大模型功能或上線前建議逐項核對這份清單是否記錄了每次請求的 prompt_tokens 與 completion_tokens。是否為核心業(yè)務(wù)設(shè)置了每日 token 預算和告警。是否區(qū)分了簡單任務(wù)和復雜任務(wù)并配置了不同模型。是否對固定提示詞啟用了服務(wù)端緩存或保持前綴穩(wěn)定。是否對高頻重復問題配置了業(yè)務(wù)側(cè)緩存。是否設(shè)置了 max_tokens 輸出上限。是否對超時重試做了冪等處理并加了退避。是否排除了定時任務(wù)在無人工確認情況下批量調(diào)用。是否按業(yè)務(wù)線拆分成本統(tǒng)計方便定位費用突增來源。是否定期review prompt刪除無用上下文。6.3 對團隊最實用的建議大模型 API 成本控制不需要一開始就做得很復雜。第一步先把每次請求的 usage 字段落日志讓成本可觀測第二步給最核心的業(yè)務(wù)場景設(shè)置預算閾值第三步把固定提示詞和動態(tài)內(nèi)容分開保持前綴穩(wěn)定以利用緩存。這三件事做完大部分成本失控問題都能被提前發(fā)現(xiàn)。標題里的“180萬刀”更像是一個提醒大模型能力強但使用它的代價必須被準確評估。對團隊來說真正的護城河不是無限制地調(diào)用最強模型而是在效果和成本之間設(shè)計出可控的調(diào)用策略。先把成本結(jié)構(gòu)算明白再把治理手段落到代碼里大模型 API 才能從“技術(shù)嘗鮮”變成“可持續(xù)的生產(chǎn)能力”。