如果你正在用Claude Platform的API做點實際項目比如給團隊搭一個客服機器人或者批量跑一批文檔分類那你大概率已經(jīng)被月底賬單教育過了輸入Token、輸出Token、模型的階梯價差、上下文越拖越長……每一項都在悄悄燒錢。最近Anthropic官方做了一次很實在的技術(shù)分享核心就是講Claude Platform上降低成本并提升性能的三個方法我照著改完自己的一個內(nèi)部工單系統(tǒng)之后費用掉了快80%接口響應也明顯變快了。這篇文章就把這三個方法徹底拆開提示詞緩存Prompt Caching、批量處理Batch API、模型與輸出精細控制。不繞彎子直接進正題。1. 先搞懂錢花在哪Claude Platform的成本構(gòu)成1.1 輸入Token和輸出Token為什么價格不一樣很多人剛接觸API時都有個疑問為什么同樣是一個Token輸入和輸出的單價差那么多Claude Platform的計費方式是典型的“雙向計費”但輸出端的成本遠高于輸入端。原因不復雜自回歸模型每生成一個新Token都要把前面的所有Token重新過一遍生成越長的內(nèi)容計算量越大所以輸出側(cè)的單位成本通常比輸入側(cè)貴好幾倍。以Anthropic主流API價格為例我當時用的Sonnet級別模型輸入大概是每百萬Token三美金上下輸出就要十五美金左右而頂級的Opus模型輸出價格更是高出一大截。也就是說一個請求里哪怕只是讓模型多輸出幾百個不痛不癢的“廢話”賬單上的數(shù)字也會肉眼可見地跳。這個成本結(jié)構(gòu)帶來了兩個直接影響第一反復往請求里塞重復的大段背景資料是在用“輸入Token”的錢做無用功第二讓模型“少說廢話”這件事本身就是最直接的降本手段。后面講到的方法三會專門圍繞輸出側(cè)做文章。1.2 每次請求都在為“重復勞動”買單我最早踩的坑是給每個請求都帶上完整的產(chǎn)品說明文檔。比如做客服工單分類系統(tǒng)提示詞里固定放了兩千Token的規(guī)則和歷史案例每個用戶請求后面再加一千多Token的工單描述最后輸出一個工單標簽。單看一條請求不多但一天跑一萬條這三千多個Token就被重復發(fā)送了一萬次。這相當于你每天雇了一群人在同一張復印機上把同一頁資料復印一萬遍每印一遍還要付一次錢。除了重復輸入還有一個隱性浪費是“多輪對話”。如果業(yè)務邏輯像聊天一樣需要Claude連續(xù)理解好幾輪上下文那么每輪會把之前所有的對話歷史重新作為輸入發(fā)給模型。對話越長單條請求的輸入Token越大費用呈線性上漲。Anthropic官方在分享里給出的解法并不是讓我們少調(diào)用API而是把“重復發(fā)送的內(nèi)容”用平臺功能緩存起來、把“不要求實時響應的任務”移到更便宜的通道上、把“模型的選擇和輸出長度”像調(diào)參數(shù)一樣精打細算。這三招正好對應了Claude Platform上三個真實落地的方法下面逐個來講。2. 方法一把重復的項目背景緩存起來提示詞緩存實戰(zhàn)2.1 提示詞緩存的原理給Claude貼一張便利貼提示詞緩存最直白的理解是你不需要每次都把一份一萬字的公司規(guī)范原樣發(fā)給Claude而是讓Claude Platform在短時間內(nèi)“記住”這一段內(nèi)容。再次請求時API會直接讀取緩存而不是重新處理這一整段文本因此費用更低、響應也更快。它解決的就是我在前面說的“重復勞動”問題。比如固定的系統(tǒng)提示詞、長文檔、工具定義、多輪對話中一直沒有變化的歷史消息這些內(nèi)容完全可以只讓Claude“讀一遍”后續(xù)直接命中緩存。這個功能在官方上叫Prompt Caching它能緩存的內(nèi)容長度有最低門檻太短的文本不會觸發(fā)緩存。緩存有TTL控制官方常見的是5分鐘和1小時兩級只要TTL內(nèi)再次請求就會按“緩存讀取”計費這個價格比正常的輸入Token要低得多通常能省下接近90%的輸入處理費用。第一次寫入緩存會按正常或者略高的寫入價格計費但只要后續(xù)請求密集這筆錢很快就能賺回來。2.2 在Claude Platform上開啟緩存的具體配置開啟緩存不需要額外申請直接用API的cache_control參數(shù)。當時我用Python SDK做測試核心邏輯就是在system字段里給需要緩存的那段文本加上cache_control。from anthropic import Anthropic client Anthropic() response client.messages.create( modelclaude-sonnet-4-20250514, max_tokens1024, system[ { type: text, text: ( 你是公司內(nèi)部的工單分類助手。\n 分類規(guī)則\n 1. 網(wǎng)絡問題涉及網(wǎng)絡無法連接、登錄失敗、卡頓\n 2. 賬號問題涉及密碼、權(quán)限、認證\n 3. 計費問題涉及訂單、發(fā)票、扣款。\n 請只返回一個分類標簽和一句100字以內(nèi)的解釋。 ), cache_control: {type: ephemeral} } ], messages[ {role: user, content: 用戶反饋登錄時提示密碼錯誤但我確認密碼沒有錯。} ] ) print(response.content[0].text)這里有兩個關(guān)鍵點第一cache_control必須放在你希望緩存的那段文本上通常就是system字段里比較長的規(guī)則說明第二緩存的命中條件是前綴一致也就是說每次請求時系統(tǒng)提示詞的前半部分必須完全一模一樣不能在其中間插一段變化的信息。實操中我見過很多人在system里動態(tài)拼當前時間、動態(tài)拼用戶名這類內(nèi)容導致緩存前綴不穩(wěn)定結(jié)果永遠命中不了。正確的做法是把固定規(guī)則放在前面把每次變化的變量放到messages消息體里或者放在system的末尾單獨一段不加cache_control。這樣才能最大化命中率。2.3 緩存命中前后的成本對比貼一個我當時自己項目里的簡化計算。假設每條請求的輸入包含固定規(guī)則兩千Token動態(tài)工單內(nèi)容一千五百Token輸出平均兩百Token。按Sonnet約$3/百萬輸入Token、$15/百萬輸出Token來算計費項不使用緩存使用緩存固定規(guī)則2000 Token輸入$0.006首次寫入約$0.0075后續(xù)命中的緩存讀取約$0.0006動態(tài)工單1500 Token輸入$0.0045$0.0045輸出200 Token$0.003$0.003單次估算$0.0135$0.0081不含首次寫入攤薄這個表格是“每條請求”的理想對比實際還要考慮緩存寫入成本。如果你一天處理一萬條工單每五分鐘有一波請求也就是十分鐘內(nèi)能命中多次寫入成本會被攤得很薄。實測下來如果業(yè)務場景是“固定長文檔高頻請求”整體輸入成本往往能省70%到90%。除了便宜緩存命中后的接口延遲也明顯下降因為模型不需要重新編碼那段長文本體感時間能縮短幾百毫秒。注意提示詞緩存只適用于短時間內(nèi)重復請求的業(yè)務。如果你一天只調(diào)十次API每次間隔兩個小時那緩存基本不會命中不要為了用而用反而增加復雜度。3. 方法二把不著急的任務攢起來Batch API批量處理3.1 為什么Batch API能打五折Claude Platform上的第二個方法是Batch API。官方給了一個非常“簡單粗暴”的優(yōu)惠你允許我不立刻返回結(jié)果我就在價格上給你五折。Batch API就是異步批量處理提交一批請求后Anthropic會在后臺統(tǒng)一處理通常24小時內(nèi)出結(jié)果。對于“人先睡一覺第二天早上拿到結(jié)果就行”的任務來說這幾乎就是白撿的折扣。它的技術(shù)原理是削峰填谷。平臺把大量不緊急的任務攢在一起在算力空閑的時段統(tǒng)一執(zhí)行所以能給出更低單價。這個模式的適用場景特別清晰離線分類、批量摘要、凌晨跑數(shù)據(jù)、日志分析、Embedding生成諸如此類。只要你的業(yè)務不要求用戶盯著等結(jié)果Batch API基本是閉眼換。原本我用同步請求跑一萬條工單分類需要不停循環(huán)、等待、處理限流耗時很長。切換到Batch API之后把一萬條請求寫進一個JSONL文件提交后去睡覺第二天醒來結(jié)果已經(jīng)躺在那里了價格還便宜了一半怎么看都劃算。3.2 提交批量任務的標準姿勢Batch API的使用分三步準備JSONL文件、提交任務、輪詢結(jié)果。所謂JSONL就是每一行都是一個獨立的請求對象。格式大致如下{custom_id: ticket-0001, params: {model: claude-3-5-haiku-20241022, max_tokens: 256, messages: [{role: user, content: 用戶反饋無法登錄提示密碼錯誤請分類。}]}} {custom_id: ticket-0002, params: {model: claude-3-5-haiku-20241022, max_tokens: 256, messages: [{role: user, content: 用戶反饋下載發(fā)票時頁面一直轉(zhuǎn)圈請分類。}]}}注意每一行的custom_id必須唯一否則任務可能報錯params里的參數(shù)和普通Messages API請求基本一致可以包含system、temperature等字段。文件準備好之后用SDK提交import anthropic client anthropic.Anthropic() # 假設你已經(jīng)寫好了 requests.jsonl 文件 with open(requests.jsonl, rb) as f: batch client.beta.messages.batches.create( filef, descriptiondaily ticket classification ) print(batch.id)拿到batch.id之后去輪詢狀態(tài)import time batch_id batch.id while True: batch_status client.beta.messages.batches.retrieve(batch_id) print(batch_status.processing_status, batch_status.request_counts) if batch_status.processing_status ended: break time.sleep(60)當狀態(tài)變成ended就可以下載結(jié)果文件。結(jié)果文件也是一個JSONL每一行對應你提交時的custom_id和模型輸出。這里有個容易踩的坑Batch API的結(jié)果文件在平臺側(cè)只保留24小時超時后可能就找不到了所以拿到結(jié)果后一定要趕緊下載到本地。3.3 什么場景適合用Batch API我用下來覺得Batch API最適合的是那些“量大、單一、不要求實時”的業(yè)務。舉例來說歷史工單補分類把過去兩個月積壓的幾萬條工單一次性丟給Batch。評論情感分析電商評論每天定時跑一次凌晨出報表。合同或長文檔摘要一次性輸入幾十份合同由模型生成結(jié)構(gòu)化摘要。內(nèi)容審核預篩選批量判斷一批用戶UGC是否有風險再交給人工細看。這些任務如果走實時API不僅費錢還會因為并發(fā)太高被限流必須自己寫重試邏輯。Batch API天然把“并發(fā)”問題繞過去了你只需要提交文件、等結(jié)果。它和提示詞緩存還能疊加Batch里的請求如果也復用相同的system前綴同樣能命中緩存進一步降低成本。當時我測試過一個批量場景把緩存和Batch疊加之后單條請求的成本甚至壓到了原來的四分之一。注意Batch API不適合需要用戶親眼看著“正在輸入”的聊天機器人場景。凡是用戶交互鏈路里的請求都不要走Batch老老實實走實時API。4. 方法三按任務難度分配合適的模型和輸出策略4.1 別用Opus跑所有活兒三個模型怎么選Claude Platform上通常提供不同尺寸的模型從快到慢、從便宜到貴分別適合不同難度的任務。很多人習慣在一開始選定一個“最聰明”的模型然后就再也不換了這是最大的成本黑洞。官方工程師在分享里反復強調(diào)模型選型本身就是性能優(yōu)化的一部分。以我常用的兩個級別為例Haiku級別模型單次調(diào)用價格便宜響應也快適合分類、命名實體識別、簡單信息抽取Sonnet級別模型綜合素質(zhì)均衡適合客服問答、內(nèi)容改寫、工具調(diào)用Opus級別模型適合復雜推理、長鏈路規(guī)劃、高難度代碼生成。如果你的任務只是“判斷這句話是好評還是差評”完全沒必要調(diào)用最強模型這就像開著一輛越野車上街買菜油耗高還要忍受更長的啟動時間。我后來在工單系統(tǒng)里做了個簡單的分級路由先讓Haiku根據(jù)工單標題和關(guān)鍵詞判斷是否需要人工介入簡單的直接給分類標簽復雜的再升級到Sonnet做詳細分析。實測下來90%的工單都在Haiku這一層解決模型調(diào)用成本直接降了一個數(shù)量級復雜工單的響應質(zhì)量也沒有下降。4.2 用結(jié)構(gòu)化輸出和max_tokens控制“隱性成本”除了選模型輸出策略同樣重要。Claude Platform的API支持max_tokens參數(shù)用來限制模型單次回復的最大長度。很多開發(fā)者在調(diào)用時習慣性寫1024、2048但業(yè)務根本用不了那么多輸出。模型并不一定會把max_tokens全部用完但這個參數(shù)會影響它的“生成預算”給得越多模型越容易在回復里繞圈子。更穩(wěn)妥的做法是估算真實需要比如分類任務給64或128摘要任務給256或512。還有一個很容易被忽略的點結(jié)構(gòu)化輸出。如果要求模型“返回一個JSON”但提示詞沒有給清楚的格式模板模型可能會在JSON前后追加解釋性文字或者用不同的字段名導致你不得不再寫解析邏輯甚至重試一次。重試就是雙倍成本。后來我發(fā)現(xiàn)與其讓模型自由發(fā)揮不如在提示詞里給出一個固定的JSON模板并配合response_format這類參數(shù)如果可用的話讓模型嚴格只輸出可解析的JSON。response client.messages.create( modelclaude-3-5-haiku-20241022, max_tokens128, temperature0, system你是一個工單分類器。請只輸出JSON不要輸出任何解釋。, messages[ {role: user, content: 工單內(nèi)容用戶說賬單被重復扣款了。輸出格式{\category\: \...\, \priority\: \...\}} ] )給temperature設成0也能提升可重復性降低模型亂發(fā)揮的概率。不要小看這些細節(jié)當請求量達到日均幾萬條時每條省下來的輸出Token都會變成真金白銀。4.3 讓Claude少說廢話給輸出加約束的實操技巧我經(jīng)常看到有人在正式環(huán)境里這么寫系統(tǒng)提示詞“請幫我分類一下。”然后模型輸出一大段“好的根據(jù)您的工單內(nèi)容我會按照以下步驟分析……”這種禮貌性回應。在API上這完全就是浪費輸出Token還拖慢了接口響應時間。正確的做法是給輸出立規(guī)矩。拿工單分類來說我會在系統(tǒng)提示詞里直接寫只返回一個Json包含category和priority兩個字段如果信息不足返回{category: unknown, priority: low}。同時告訴模型不要解釋原因、不要問候用戶、不要輸出任何Markdown代碼塊標記。這一步不會降低模型能力反而會讓結(jié)果更穩(wěn)定。人的注意力會被“無關(guān)的客套話”分散模型也一樣。輸出越聚焦生成速度越快費用越低。5. 把三個方法組合起來一個真實場景的降本增效復盤5.1 場景描述一個客服工單分類系統(tǒng)怎么改我在一個內(nèi)部項目里負責搭建客服工單分類系統(tǒng)每天新增一萬條左右工單來自郵件、客服聊天記錄和用戶填寫的表單。原來實現(xiàn)的方式很直接拿到工單內(nèi)容后拼上兩千Token的產(chǎn)品規(guī)則調(diào)用Sonnet實時分類然后把結(jié)果寫回數(shù)據(jù)庫。這個方案最大的問題有三個第一每條請求的固定規(guī)則都在重復計費第二實時快照式調(diào)用沒有充分利用離線時段第三所有工單都在用Sonnet哪怕是“密碼錯誤”這種一句話就能判斷的工單也在用貴模型。這三點正好對應前面三個方法。改造時我的順序是這樣的第一步把系統(tǒng)提示詞和產(chǎn)品規(guī)則全部整理成固定前綴加上cache_control讓頻繁的實時請求命中緩存第二步把“非實時”的工單全部改用Batch API在凌晨批量跑不再實時請求第三步在Batch API的請求里使用Haiku模型只單獨抽出一部分復雜工單走Sonnet。5.2 改造前后的成本與性能對比假設每天一萬條工單每條工單正文平均一千五百Token固定規(guī)則兩千Token輸出一百五十Token。用Sonnet實時調(diào)用價格按輸入$3/M、輸出$15/M估算單條請求成本3500 Token輸入 / 1000000 × $3 $0.0105150 Token輸出 / 1000000 × $15 $0.00225合計約$0.01275。日成本$127.5月成本約$3825。改造后90%的簡單工單走Batch API的Haiku價格按輸入$0.8/M、輸出$4/M再乘Batch五折估算同時因為固定規(guī)則有緩存輸入成本進一步降低。假設緩存命中后固定規(guī)則折算約$0.0006/條動態(tài)內(nèi)容1500 Token走Haiku輸入是1500 / 1000000 × $0.4 $0.0006輸出150 Token是150 / 1000000 × $2 $0.0003合計約$0.0015。另外10%復雜工單還是走Sonnet緩存處理成本也不會像以前那樣高。粗略算下來日成本從$127.5降到約$25左右月成本控制在$800以內(nèi)。再加上凌晨批量處理讓白天接口壓力更小限流情況基本消失整體體驗提升非常明顯。5.3 組合使用時要避開的“邊界”三個方法能疊加但疊加不等于無腦套用。提示詞緩存要求“短時間重復請求”Batch API要求“任務不實時”模型選型要求“難度匹配”三者都有各自的邊界。如果業(yè)務本身就是低并發(fā)的實時對話那Batch API注定不適合如果固定內(nèi)容每天只發(fā)送幾次緩存也起不了作用如果任務全是高難度推理硬要用Haiku省成本最后只會因為重試和返工花更多錢。組合的關(guān)鍵是先拆解你的業(yè)務形態(tài)哪些內(nèi)容是固定的哪些任務可以等哪些請求可以被更小的模型解決拆完之后每個方法放在適合它的位置上才能發(fā)揮真實效果。6. 常見問題與排查技巧實錄6.1 提示詞緩存不生效或命中率低怎么辦最常見的原因是前綴不穩(wěn)定。我排查過一次發(fā)現(xiàn)代碼里在system末尾拼了一個時間戳導致每次請求的完整輸入都不一樣緩存自然永不命中。解決方法是把時間戳放到messages中而不是system前綴里。另一個原因是緩存體不夠長。官方對可緩存內(nèi)容有最低長度要求太短的提示詞不會觸發(fā)緩存。這時就不要強行緩存可以通過把更多固定說明文加進系統(tǒng)提示詞來滿足長度但前提是這些內(nèi)容確實對任務有幫助不要為了緩存而灌水。還有如果一次會話的間隔超過了TTL比如五分鐘或一小時緩存也會失效需要重新寫入。6.2 Batch API任務失敗或結(jié)果丟失怎么處理用Batch API最容易遇到的問題包括JSONL格式非法、custom_id重復、結(jié)果下載超時。格式非法可以通過先拿少量請求試跑來解決不要一次性提交幾萬條custom_id重復會在提交時直接報錯所以生成ID時建議加上業(yè)務主鍵或時間戳保證唯一。結(jié)果文件保留時間有限這一點特別容易踩坑。官方通常只保留24小時所以下載任務不要等應該把成功結(jié)束和下載結(jié)果寫成同一個自動化流程一發(fā)現(xiàn)狀態(tài)變成ended立刻下載并歸檔。我自己的做法是提交任務后直接用系統(tǒng)定時任務每小時檢查一次狀態(tài)發(fā)現(xiàn)結(jié)束就下載到本地對象存儲防止結(jié)果過期。6.3 關(guān)于Claude Platform賬號與計費的幾個提醒很多新手在接入Claude Platform時會忽略設置預算和用量告警。建議在控制臺里把計費提醒打開或者自己寫一個腳本定時統(tǒng)計Token消耗在日消耗超過閾值時通知團隊。不要等到月底賬單出來才發(fā)現(xiàn)超支。另外模型名稱和價格會調(diào)整寫代碼時不要把模型ID硬編碼得過于剛性。我的經(jīng)驗是把模型ID放到配置中心方便隨時切換。比如A/B測試時在Haiku和Sonnet之間切換只要改配置不需要重發(fā)布服務。對于API Key的管理也要認真對待不要把Key寫在客戶端代碼里更不要提交到公開倉庫一旦泄露別人可以用你的Key跑大量請求賬單瞬間爆炸。還有一個容易被忽略的點響應失敗時的重試策略。網(wǎng)絡抖動或平臺限流都會導致瞬時錯誤很多人直接把錯誤拋出去然后人工重跑這既影響效率也浪費時間。比較好的做法是設置指數(shù)退避重試第一次失敗等幾秒第二次失敗等更久最多重試三到五次。這樣可以在不增加人工干預的情況下把一些臨時性失敗消化掉。我做了這個項目之后最大的體會是Claude Platform本身的能力很強但如果你不會控制調(diào)用方式它也真的能燒掉你一大筆預算。這三個方法看起來都不復雜難點在于把緩存的一致性、Batch的離線場景、模型的分級策略組合到一起從整個系統(tǒng)視角去壓縮成本。最后再分享一個小技巧如果你有每天固定跑批的任務可以在任務啟動前先主動發(fā)一條“預熱”請求把系統(tǒng)提示詞寫入緩存這樣后續(xù)大批量請求就能直接命中緩存讓Batch任務跑得更快更便宜。這個操作很簡單但實際效果相當明顯。