REST API獲取LLM定價(jià)、上下文窗口與成本估算實(shí)踐)
做 LLM 應(yīng)用開發(fā)的人大概率在某個(gè)時(shí)刻被同一個(gè)問(wèn)題問(wèn)住過(guò)模型功能已經(jīng)調(diào)通了但老板或者運(yùn)營(yíng)同事突然拋來(lái)一句——“我們每天有一萬(wàn)次請(qǐng)求一個(gè)月花在模型調(diào)用上的錢大概是多少”這時(shí)候你需要的不是一個(gè)只會(huì)數(shù) token 的腳本而是一份準(zhǔn)確、實(shí)時(shí)、機(jī)器可讀的模型價(jià)格表。真正的麻煩在于模型價(jià)格和上下文窗口恰恰是變化最頻繁的信息模型降價(jià)、版本升級(jí)、上下文從 128K 擴(kuò)到 200K都是家常便飯。如果這些數(shù)據(jù)一直靠人手工維護(hù)在代碼里不僅更新慢還容易算錯(cuò)。今天要聊的是 LLM 應(yīng)用工程化中一個(gè)非常實(shí)用的話題免費(fèi)的 REST API專門提供 LLM pricing模型定價(jià)、context windows上下文窗口和 cost estimation成本估算。這篇文章會(huì)從開發(fā)場(chǎng)景切入講清楚這類 API 到底解決什么問(wèn)題、接口通常如何設(shè)計(jì)再給出可以直接運(yùn)行的 Python 接入示例、FastAPI 自建方案以及接入過(guò)程中最常見(jiàn)的坑和工程建議。先給一個(gè)明確判斷在 LLM 應(yīng)用的成本治理里核心難點(diǎn)從來(lái)不是“計(jì)算”而是“數(shù)據(jù)維護(hù)”。誰(shuí)能讓價(jià)格和上下文窗口數(shù)據(jù)保持即時(shí)、結(jié)構(gòu)化、可編程誰(shuí)就能省下大量長(zhǎng)期維護(hù)成本。理解了這一點(diǎn)你就知道為什么值得為這一類 API 單獨(dú)寫一篇文章。1. 為什么需要“機(jī)器可讀”的 LLM 定價(jià)與成本估算 API很多團(tuán)隊(duì)在做 LLM 成本估算時(shí)第一步是打開官網(wǎng)的定價(jià)頁(yè)面然后把價(jià)格抄進(jìn)代碼里的一個(gè)常量表。這種硬編碼方式在模型數(shù)量少、更新頻率低的時(shí)候勉強(qiáng)可用但一旦進(jìn)入真實(shí)業(yè)務(wù)問(wèn)題會(huì)立刻暴露。第一個(gè)問(wèn)題是數(shù)據(jù)過(guò)期。主流模型服務(wù)商調(diào)整價(jià)格、發(fā)布新版本的速度非?？臁＝裉焐暇€時(shí)寫死的價(jià)格可能下個(gè)月就失效了。更麻煩的是這種情況經(jīng)常是靜默發(fā)生的代碼不會(huì)報(bào)錯(cuò)系統(tǒng)也不會(huì)告警只有月底對(duì)賬單的時(shí)候才發(fā)現(xiàn)成本估算偏離了實(shí)際支出。第二個(gè)問(wèn)題是數(shù)據(jù)結(jié)構(gòu)不統(tǒng)一。官網(wǎng)的定價(jià)表格是給人看的不是給程序讀的。有的服務(wù)商用“每 1K tokens”報(bào)價(jià)有的用“每 1M tokens”有的用美元有的用人民幣有的輸入輸出拆分有的只給一個(gè)綜合價(jià)格。每個(gè)模型廠商一套規(guī)則每次接入新模型都要重新讀一遍文檔這對(duì)需要同時(shí)管理多個(gè)模型的應(yīng)用來(lái)說(shuō)非常痛苦。第三個(gè)問(wèn)題是無(wú)法支撐自動(dòng)化決策。當(dāng)你想做模型路由、自動(dòng)預(yù)算告警、按用戶分賬、甚至讓 Agent 在每次任務(wù)前判斷預(yù)算是否充足時(shí)系統(tǒng)必須能實(shí)時(shí)拿到某個(gè)模型的單價(jià)和上下文窗口數(shù)據(jù)而不能依賴一份手工更新的靜態(tài)表。所以這個(gè)領(lǐng)域逐漸出現(xiàn)了一類專門的 REST API它們把“模型定價(jià)”“上下文窗口”“成本估算”做成標(biāo)準(zhǔn)化的接口讓業(yè)務(wù)系統(tǒng)像查詢普通數(shù)據(jù)庫(kù)一樣獲取模型信息。這樣做的好處非常明顯價(jià)格變化由數(shù)據(jù)源統(tǒng)一維護(hù)業(yè)務(wù)代碼只依賴穩(wěn)定的接口契約成本計(jì)算邏輯可以集中封裝、反復(fù)復(fù)用。對(duì)于一個(gè)人數(shù)不多的 LLM 應(yīng)用團(tuán)隊(duì)來(lái)說(shuō)這比自建一套模型信息管理系統(tǒng)要便宜得多。文章接下來(lái)的部分會(huì)圍繞三類讀者展開第一種是只想快速接入一個(gè)免費(fèi)接口、解決成本估算問(wèn)題的應(yīng)用開發(fā)者第二種是希望把模型價(jià)格、上下文窗口數(shù)據(jù)同步到內(nèi)部系統(tǒng)的平臺(tái)工程師第三種是正在設(shè)計(jì)團(tuán)隊(duì)內(nèi)部模型治理方案的架構(gòu)師。2. 基礎(chǔ)概念LLM pricing、context windows 與 cost estimation在進(jìn)入代碼之前有必要把三個(gè)關(guān)鍵詞徹底講清楚。它們彼此獨(dú)立但又共同決定一次模型調(diào)用的實(shí)際成本。遺漏任何一個(gè)成本估算都會(huì)失真。2.1 LLM pricing按 token 計(jì)費(fèi)輸入輸出通常不同價(jià)LLM pricing 指的是模型服務(wù)商對(duì)模型調(diào)用收取的費(fèi)用。絕大多數(shù)主流模型采用按 token 計(jì)費(fèi)的模式也就是按輸入 token 和輸出 token 分別計(jì)價(jià)。這里的“token”是模型處理文本的最小單位一個(gè)英文單詞通常對(duì)應(yīng)一個(gè)或多個(gè) token一個(gè)中文漢字可能對(duì)應(yīng)一到兩個(gè) token具體取決于模型使用的 tokenizer。值得注意的一點(diǎn)是大多數(shù)服務(wù)商的輸出價(jià)格高于輸入價(jià)格。從表面看這只是一個(gè)商業(yè)定價(jià)策略從技術(shù)角度看也有一定合理性輸出階段模型需要自回歸地逐 token 生成每一步都依賴之前的所有狀態(tài)計(jì)算過(guò)程更復(fù)雜。不過(guò)作為使用者我們只需要記住一個(gè)原則成本估算必須輸入、輸出分開算不能用一個(gè)平均價(jià)糊弄過(guò)去。對(duì)于成本估算 API 來(lái)說(shuō)它要解決的關(guān)鍵問(wèn)題是把價(jià)格字段標(biāo)準(zhǔn)化。比如統(tǒng)一使用“每 1M tokens 的價(jià)格”作為字段單位而不是讓調(diào)用方去處理每 1K 還是每 1M 的差異。這樣業(yè)務(wù)代碼可以少踩很多單位坑。2.2 context windows不是越高越好它是成本約束context windows 指的是模型單次請(qǐng)求能夠處理的上下文 token 總數(shù)上限。簡(jiǎn)單說(shuō)就是你把歷史對(duì)話、檢索到的知識(shí)、工具返回結(jié)果全部拼進(jìn) prompt 之后模型最多能“看到”多長(zhǎng)的內(nèi)容。為什么它和成本估算強(qiáng)相關(guān)因?yàn)檩斎?token 數(shù)量是成本公式的第一個(gè)乘數(shù)。上下文越長(zhǎng)輸入 token 越多單次請(qǐng)求成本越高。尤其在使用 RAG 或 Agent 架構(gòu)時(shí)系統(tǒng)往往會(huì)往 prompt 里塞入大量檢索結(jié)果這些內(nèi)容會(huì)快速消耗上下文窗口。實(shí)際開發(fā)中還有一個(gè)容易忽略的細(xì)節(jié)context window 不是都能給輸入的。模型生成輸出也需要占用上下文空間。如果你把 128K 的窗口全部塞滿輸入那么模型可能只剩很少的空間來(lái)生成回復(fù)。因此在做成本估算和參數(shù)校驗(yàn)時(shí)需要同時(shí)檢查“輸入 token 最大輸出 token”是否超過(guò)模型上下文窗口上限。一個(gè)成熟的定價(jià)與成本估算 API通常會(huì)返回每個(gè)模型的 context_window 字段。應(yīng)用層可以借助這個(gè)字段做模型路由任務(wù)需要長(zhǎng)上下文時(shí)優(yōu)先選擇上下文窗口更大的模型短任務(wù)則選擇更便宜、更快的模型。這已經(jīng)不僅是成本估算而是成本優(yōu)化的基礎(chǔ)。2.3 cost estimation核心公式與單位陷阱cost estimation 本質(zhì)上是一個(gè)帶單位的乘法問(wèn)題。假設(shè)某個(gè)模型的輸入價(jià)格為input_price輸出價(jià)格為output_price并且這兩個(gè)價(jià)格都以“每 1M tokens”為基準(zhǔn)那么一次調(diào)用的估算成本可以寫成cost (input_tokens * input_price output_tokens * output_price) / 1_000_000這個(gè)公式本身不復(fù)雜但單位陷阱非常多。我用下面的表格列出幾種常見(jiàn)的情況價(jià)格單位公式中的分母容易出錯(cuò)的地方每 1K tokens1000看到價(jià)格是 0.002 就當(dāng)成每 token 價(jià)格結(jié)果差 1000 倍每 1M tokens1000000輸入和輸出價(jià)格字段混淆美元 vs 人民幣無(wú)但需要匯率換算估算結(jié)果與賬單幣種不一致部分服務(wù)區(qū)分緩存命中價(jià)格視接口而定忽略了緩存命中率成本被高估在使用現(xiàn)成的成本估算 API 時(shí)第一件事就是確認(rèn)它的價(jià)格字段單位。如果接口返回的是“每 1M tokens 的價(jià)格”那么代碼里的分母就是 1_000_000如果接口返回的是“每 1K tokens 的價(jià)格”分母就是 1_000。這個(gè)細(xì)節(jié)直接影響最終結(jié)果也決定著你接的 API 是否真的省心。3. 免費(fèi) REST API 的典型設(shè)計(jì)思路與接口規(guī)范在分析具體代碼之前先建立一種直覺(jué)一個(gè)好的 LLM 定價(jià)與成本估算 REST API在設(shè)計(jì)上應(yīng)該是什么樣的它和普通的業(yè)務(wù) API 有什么區(qū)別3.1 這類 API 解決的核心問(wèn)題從設(shè)計(jì)目標(biāo)看這類 API 要解決三個(gè)問(wèn)題第一提供標(biāo)準(zhǔn)化的模型元數(shù)據(jù)。無(wú)論是開源社區(qū)的免費(fèi)接口還是商業(yè)服務(wù)商的官方接口本質(zhì)上都是把零散的定價(jià)信息整理成統(tǒng)一字段。常見(jiàn)的字段包括模型 ID、上下文窗口大小、輸入價(jià)格、輸出價(jià)格、數(shù)據(jù)截止時(shí)間等。第二把成本計(jì)算邏輯集中化。調(diào)用方不需要在業(yè)務(wù)代碼里重復(fù)寫成本公式而是把輸入 token 數(shù)、輸出 token 數(shù)傳給接口讓接口返回估算金額。這保證了成本計(jì)算口徑的一致性也為后續(xù)調(diào)整計(jì)費(fèi)策略留下了空間。第三支持自動(dòng)化消費(fèi)。REST API 天然適合程序調(diào)用無(wú)論是每天定時(shí)同步到內(nèi)部數(shù)據(jù)庫(kù)還是在每個(gè) Agent 任務(wù)開始前實(shí)時(shí)查詢都很方便。3.2 典型接口端點(diǎn)設(shè)計(jì)雖然不同服務(wù)實(shí)現(xiàn)的細(xì)節(jié)不同但它們通常會(huì)包含下面幾類端點(diǎn)。這里不綁定任何具體項(xiàng)目而是給出一種通用結(jié)構(gòu)方便你快速理解并遷移到真實(shí)服務(wù)上。方法端點(diǎn)作用GET/v1/models獲取所有模型列表包括 ID、context window、價(jià)格字段GET/v1/models/{model_id}獲取單個(gè)模型的詳細(xì)定價(jià)信息POST/v1/cost-estimate傳入模型 ID、輸入 token 數(shù)、輸出 token 數(shù)返回估算成本GET/health健康檢查判斷服務(wù)是否可用資源化、版本化、職責(zé)單一這是 REST API 的標(biāo)準(zhǔn)設(shè)計(jì)語(yǔ)言。以GET /v1/models為例它的響應(yīng)結(jié)構(gòu)可能類似這樣{ items: [ { id: gpt-demo, provider: demo-provider, context_window: 128000, input_price_per_million: 0.50, output_price_per_million: 1.50, updated_at: 2025-06-01T00:00:00Z } ] }這里的input_price_per_million表示每 1M 輸入 token 的價(jià)格單位是美元context_window表示上下文窗口大小。字段名在不同項(xiàng)目里可能有差異但表達(dá)的信息基本一致。接入任何具體 API 之前應(yīng)該先以它的文檔為準(zhǔn)把這幾個(gè)字段的映射關(guān)系確認(rèn)清楚。3.3 關(guān)于“免費(fèi)”的邊界“免費(fèi)”不是沒(méi)有代價(jià)。大多數(shù)免費(fèi) API 會(huì)通過(guò)限流Rate Limit、請(qǐng)求頻率、功能裁剪等方式控制成本。從工程角度看這是合理的。接入免費(fèi)接口時(shí)需要關(guān)注幾個(gè)點(diǎn)一是配額。免費(fèi)接口通常有每分鐘請(qǐng)求數(shù)上限如果應(yīng)用需要高頻查詢就必須在本地做緩存而不是每次請(qǐng)求都打到遠(yuǎn)端。二是數(shù)據(jù)更新頻率。有的接口實(shí)時(shí)同步官方價(jià)格有的可能每天或每周更新一次。對(duì)于成本估算這種場(chǎng)景短時(shí)間內(nèi)的延遲通?？梢越邮艿绻糜谪?cái)務(wù)級(jí)對(duì)賬必須確認(rèn)數(shù)據(jù)源更新策略。三是許可條款。如果是商業(yè)項(xiàng)目建議先閱讀服務(wù)條款確認(rèn)免費(fèi)層是否允許商用。更穩(wěn)妥的做法是把這類免費(fèi)接口作為數(shù)據(jù)源之一在本地維護(hù)緩存減少對(duì)單一服務(wù)的依賴。4. 環(huán)境準(zhǔn)備與前置條件進(jìn)入代碼之前先把環(huán)境準(zhǔn)備好。本文的示例以 Python 為主因?yàn)?Python 在數(shù)據(jù)處理和 LLM 應(yīng)用開發(fā)中是最常見(jiàn)的選擇。下面的環(huán)境要求是通用建議版本號(hào)請(qǐng)以實(shí)際安裝環(huán)境為準(zhǔn)。需要準(zhǔn)備的環(huán)境如下Python 3.9 及以上版本可以正常訪問(wèn)目標(biāo) API 的網(wǎng)絡(luò)環(huán)境如果目標(biāo) API 要求認(rèn)證提前注冊(cè)并獲取 API Keypip包管理工具主要用到的 Python 依賴包括requests發(fā)起 HTTP 請(qǐng)求、fastapi自建成本估算服務(wù)、uvicorn運(yùn)行 FastAPI 應(yīng)用和pydanticFastAPI 的依賴通常會(huì)自動(dòng)安裝。安裝命令如下pip install requests fastapi uvicorn如果你準(zhǔn)備使用環(huán)境變量管理 API Key可以安裝python-dotenv來(lái)讀取本地.env文件pip install python-dotenv安裝完成后建議在項(xiàng)目根目錄新建一個(gè).env文件把你從服務(wù)商那里獲取的 API Key 放進(jìn)去。例如# 文件路徑.env LLM_PRICE_API_TOKENyour_token_here LLM_PRICE_API_BASEhttps://api.example.com/v1注意.env文件不要提交到 Git 倉(cāng)庫(kù)。如果是公開倉(cāng)庫(kù)務(wù)必在.gitignore中加上.env。在實(shí)際調(diào)用任何第三方 API 之前先做一次最小化的連通性驗(yàn)證通常是用瀏覽器訪問(wèn)https://api.example.com/v1/models這樣的地址確認(rèn)網(wǎng)絡(luò)和認(rèn)證都沒(méi)問(wèn)題。這樣可以避免在代碼調(diào)試階段來(lái)回排查網(wǎng)絡(luò)錯(cuò)誤。5. 完整示例Python 接入定價(jià) API 并完成成本估算現(xiàn)在進(jìn)入實(shí)操。假設(shè)你已經(jīng)找到了一個(gè)提供 LLM 定價(jià)信息的免費(fèi) REST API并且拿到了文檔。下面用最小示例演示如何獲取模型列表、查詢單個(gè)模型、以及完成一次成本估算。5.1 獲取模型列表創(chuàng)建一個(gè)文件scripts/get_models.py代碼邏輯非常簡(jiǎn)單發(fā)起一個(gè) GET 請(qǐng)求解析返回的 JSON然后打印模型 ID、上下文窗口和價(jià)格字段。# 文件路徑scripts/get_models.py import os import requests from dotenv import load_dotenv load_dotenv() API_TOKEN os.getenv(LLM_PRICE_API_TOKEN, ) API_BASE_URL os.getenv(LLM_PRICE_API_BASE, https://api.example.com/v1) def fetch_models() - list: headers { Authorization: fBearer {API_TOKEN}, Content-Type: application/json, } resp requests.get(f{API_BASE_URL}/models, headersheaders, timeout10) resp.raise_for_status() data resp.json() # 不同接口返回結(jié)構(gòu)不同這里兼容兩種常見(jiàn)格式 if isinstance(data, list): return data return data.get(items, []) if __name__ __main__: models fetch_models() for model in models: print( f{model.get(id)} | fcontext_window{model.get(context_window)} | finput_usd_per_million{model.get(input_price_per_million)} | foutput_usd_per_million{model.get(output_price_per_million)} )這段代碼有幾點(diǎn)需要說(shuō)明通過(guò)load_dotenv()讀取本地環(huán)境變量避免把 API Key 硬編碼在源碼里。timeout10限制了單個(gè)請(qǐng)求的超時(shí)時(shí)間避免接口卡住時(shí)進(jìn)程一直等待。resp.raise_for_status()可以在響應(yīng)狀態(tài)碼不是 2xx 時(shí)立刻拋出異常方便排查問(wèn)題。運(yùn)行方式cd 項(xiàng)目目錄 python scripts/get_models.py如果一切正常你會(huì)看到類似下面的輸出gpt-demo | context_window128000 | input_usd_per_million0.50 | output_usd_per_million1.50 claude-demo | context_window200000 | input_usd_per_million1.00 | output_usd_per_million2.00這里使用的模型 ID 和價(jià)格都是示意數(shù)據(jù)。真實(shí)項(xiàng)目中的模型 ID 可能是gpt-4o、claude-sonnet-4等形式具體以接口返回為準(zhǔn)。5.2 查詢單個(gè)模型并計(jì)算成本模型列表接口通常還會(huì)包含一個(gè)單模型查詢端點(diǎn)。在實(shí)際業(yè)務(wù)中你一般不會(huì)每次調(diào)用都拉取全部模型而是根據(jù)用戶請(qǐng)求里的模型 ID 查詢一個(gè)模型。下面的示例演示了查詢模型并完成成本估算的完整流程。# 文件路徑scripts/estimate_cost.py import os import requests from dotenv import load_dotenv load_dotenv() API_TOKEN os.getenv(LLM_PRICE_API_TOKEN, ) API_BASE_URL os.getenv(LLM_PRICE_API_BASE, https://api.example.com/v1) # 簡(jiǎn)單內(nèi)存緩存避免同一個(gè)模型的重復(fù)請(qǐng)求 MODEL_CACHE {} def get_model_info(model_id: str) - dict: if model_id in MODEL_CACHE: return MODEL_CACHE[model_id] headers { Authorization: fBearer {API_TOKEN}, Content-Type: application/json, } resp requests.get( f{API_BASE_URL}/models/{model_id}, headersheaders, timeout10, ) resp.raise_for_status() info resp.json() MODEL_CACHE[model_id] info return info def estimate_cost(model_id: str, input_tokens: int, output_tokens: int) - float: info get_model_info(model_id) input_price info[input_price_per_million] output_price info[output_price_per_million] # 單位統(tǒng)一為“每百萬(wàn) token”所以分母是 1_000_000 cost ( input_tokens * input_price output_tokens * output_price ) / 1_000_000 return round(cost, 8) if __name__ __main__: model_id gpt-demo input_tokens 12000 output_tokens 3000 cost estimate_cost(model_id, input_tokens, output_tokens) print(fmodel{model_id}, input{input_tokens}, output{output_tokens}) print(festimated_cost_usd{cost})這里加入了一個(gè)非常簡(jiǎn)單的內(nèi)存緩存MODEL_CACHE。對(duì)于價(jià)格這類變化不頻繁的數(shù)據(jù)緩存可以顯著減少遠(yuǎn)端 API 的請(qǐng)求量。對(duì)于免費(fèi) API 來(lái)說(shuō)這既能降低觸發(fā)限流的概率也能減少對(duì)公共服務(wù)資源的沖擊。運(yùn)行方式和預(yù)期結(jié)果python scripts/estimate_cost.pymodelgpt-demo, input12000, output3000 estimated_cost_usd0.0105計(jì)算過(guò)程是(12000 * 0.50 3000 * 1.50) / 1_000_000 0.0105 USD5.3 一個(gè)更完整的成本估算請(qǐng)求封裝如果你覺(jué)得上面的示例還是偏簡(jiǎn)單可以參考下面這段更接近生產(chǎn)環(huán)境的封裝。它增加了鑒權(quán)、異常處理、輸入?yún)?shù)校驗(yàn)和上下文窗口檢查。# 文件路徑scripts/estimate_cost_v2.py import os import requests from dotenv import load_dotenv load_dotenv() API_TOKEN os.getenv(LLM_PRICE_API_TOKEN, ) API_BASE_URL os.getenv(LLM_PRICE_API_BASE, https://api.example.com/v1) def validate_input(model_info: dict, input_tokens: int, output_tokens: int) - None: context_window model_info.get(context_window) if context_window and input_tokens output_tokens context_window: raise ValueError( finput_tokens output_tokens exceeds context_window: f{input_tokens output_tokens} {context_window} ) if input_tokens 0 or output_tokens 0: raise ValueError(input_tokens and output_tokens must be non-negative) def get_estimate(model_id: str, input_tokens: int, output_tokens: int) - dict: headers {Authorization: fBearer {API_TOKEN}} payload { model_id: model_id, input_tokens: input_tokens, output_tokens: output_tokens, } resp requests.post( f{API_BASE_URL}/cost-estimate, jsonpayload, headersheaders, timeout10, ) resp.raise_for_status() return resp.json() if __name__ __main__: try: result get_estimate(gpt-demo, 12000, 3000) print(result) except Exception as exc: print(festimate failed: {exc})這種做法的好處是把校驗(yàn)邏輯和服務(wù)調(diào)用分離。上線之后如果發(fā)現(xiàn)某個(gè)請(qǐng)求的 token 數(shù)異?？梢灾苯釉?validation 階段攔截而不是等到調(diào)用模型服務(wù)時(shí)才發(fā)現(xiàn)參數(shù)不合理。6. 進(jìn)階示例用 FastAPI 自建內(nèi)部成本估算服務(wù)在很多團(tuán)隊(duì)里內(nèi)部系統(tǒng)并不希望每個(gè)服務(wù)都直接調(diào)用外部的免費(fèi) API。更常見(jiàn)的做法是把模型價(jià)格數(shù)據(jù)緩存到內(nèi)部封裝成一個(gè)統(tǒng)一的成本估算服務(wù)所有業(yè)務(wù)線都走這個(gè)入口。好處是可以統(tǒng)一鑒權(quán)、統(tǒng)一緩存、統(tǒng)一審計(jì)并且可以很方便地疊加公司內(nèi)部的折扣策略。下面用 FastAPI 實(shí)現(xiàn)一個(gè)最小可運(yùn)行的成本估算服務(wù)。重點(diǎn)不是展示 FastAPI 的全部能力而是給出一個(gè)可以擴(kuò)展的內(nèi)部服務(wù)骨架。# 文件路徑app/main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field app FastAPI() # 注意以下價(jià)格數(shù)據(jù)是示意數(shù)據(jù)僅供演示 # 生產(chǎn)環(huán)境應(yīng)從可信數(shù)據(jù)源同步并建立定期刷新機(jī)制 MODEL_PRICE_TABLE { gpt-demo: { input_price_per_million: 0.50, output_price_per_million: 1.50, context_window: 128000, }, claude-demo: { input_price_per_million: 1.00, output_price_per_million: 2.00, context_window: 200000, }, } class EstimateRequest(BaseModel): model_id: str Field(..., description模型唯一標(biāo)識(shí)) input_tokens: int Field(1000, ge0, description輸入 token 數(shù)) output_tokens: int Field(500, ge0, description輸出 token 數(shù)) class EstimateResponse(BaseModel): model_id: str input_tokens: int output_tokens: int estimated_cost_usd: float app.get(/v1/models) def list_models(): return { items: [ {id: model_id, **meta} for model_id, meta in MODEL_PRICE_TABLE.items() ] } app.post(/v1/cost-estimate, response_modelEstimateResponse) def cost_estimate(req: EstimateRequest): model MODEL_PRICE_TABLE.get(req.model_id) if not model: raise HTTPException(status_code404, detailfunknown model: {req.model_id}) cost ( req.input_tokens * model[input_price_per_million] req.output_tokens * model[output_price_per_million] ) / 1_000_000 return EstimateResponse( model_idreq.model_id, input_tokensreq.input_tokens, output_tokensreq.output_tokens, estimated_cost_usdround(cost, 8), )啟動(dòng)服務(wù)uvicorn app.main:app --reload然后通過(guò) curl 驗(yàn)證成本估算接口curl -X POST http://127.0.0.1:8000/v1/cost-estimate \ -H Content-Type: application/json \ -d {model_id: gpt-demo, input_tokens: 12000, output_tokens: 3000}預(yù)期返回{ model_id: gpt-demo, input_tokens: 12000, output_tokens: 3000, estimated_cost_usd: 0.0105 }這個(gè)自建服務(wù)的關(guān)鍵價(jià)值不只是提供一個(gè) HTTP 接口而是為后續(xù)擴(kuò)展留好了位置。比如你可以在接口中加入預(yù)算校驗(yàn)當(dāng)某個(gè)應(yīng)用連續(xù)調(diào)用模型的成本超過(guò)閾值時(shí)返回警告也可以在服務(wù)內(nèi)部增加價(jià)格數(shù)據(jù)刷新任務(wù)每天定時(shí)從外部 API 拉取最新價(jià)格并更新MODEL_PRICE_TABLE。相比每個(gè)業(yè)務(wù)單獨(dú)硬編碼價(jià)格這種集中式服務(wù)要好維護(hù)得多。7. 運(yùn)行結(jié)果與效果驗(yàn)證接入完成后不能只看一次輸出就認(rèn)為萬(wàn)事大吉。成本估算這種功能錯(cuò)誤往往藏在單位、字段映射和邊界條件里。建議按照下面幾個(gè)維度做驗(yàn)證。第一個(gè)維度是計(jì)算正確性。拿一個(gè)已知價(jià)格的模型手動(dòng)用公式算一遍再和接口返回結(jié)果對(duì)比。比如輸入 1000 token、輸出 500 token價(jià)格為每百萬(wàn) 1 美元預(yù)期成本是(1000 * 1 500 * 1) / 1000000 0.0015。如果接口返回的結(jié)果不是這個(gè)值優(yōu)先檢查價(jià)格字段是否被錯(cuò)誤地當(dāng)成了“每 token 價(jià)格”。第二個(gè)維度是邊界處理。傳入 0 token 或用負(fù)數(shù)測(cè)試看看接口是否正常返回錯(cuò)誤。合法的成本估算服務(wù)不應(yīng)該允許負(fù)數(shù) token 輸入。同時(shí)檢查當(dāng)輸入輸出之和超過(guò)模型 context window 時(shí)系統(tǒng)是否能給出明確提示。第三個(gè)維度是網(wǎng)絡(luò)異常。模擬網(wǎng)絡(luò)超時(shí)、API 返回 429 限流等情況確認(rèn)你的代碼有合理的異常處理而不是直接拋出一個(gè)讓人摸不著頭腦的堆棧。建議在關(guān)鍵調(diào)用處加上 try/except并記錄結(jié)構(gòu)化日志。第四個(gè)維度是數(shù)據(jù)同步。如果外部免費(fèi) API 的模型價(jià)格更新了你的系統(tǒng)多久能感知到如果是直接調(diào)用每次請(qǐng)求都拿最新數(shù)據(jù)如果是做了緩存需要明確緩存過(guò)期時(shí)間并確保過(guò)期后能重新拉取最新數(shù)據(jù)。驗(yàn)證的時(shí)候建議把預(yù)期結(jié)果和實(shí)際輸出放在一起對(duì)比用表格記錄。這樣可以快速定位是計(jì)算邏輯的問(wèn)題、單位的問(wèn)題還是接口字段映射的問(wèn)題。8. 常見(jiàn)問(wèn)題與排查思路根據(jù)實(shí)際接入經(jīng)驗(yàn)下面這些問(wèn)題出現(xiàn)的頻率最高。遇到問(wèn)題時(shí)可以先用這張表格快速定位方向。問(wèn)題現(xiàn)象可能原因排查方式解決方案請(qǐng)求返回 404接口路徑或版本號(hào)錯(cuò)誤查看 API 文檔確認(rèn)端點(diǎn)是否帶/v1前綴修正請(qǐng)求路徑請(qǐng)求返回 401API Key 無(wú)效或未傳入檢查環(huán)境變量是否加載請(qǐng)求頭是否正確重新獲取 API Key修正環(huán)境變量請(qǐng)求返回 429觸發(fā)了限流配額查看響應(yīng)頭中的 RateLimit 字段增加本地緩存、降低請(qǐng)求頻率、升級(jí)配額成本計(jì)算結(jié)果為 0價(jià)格字段缺失或?yàn)?0打印模型返回的原始 JSON檢查字段名是否正確成本結(jié)果和預(yù)期差很多價(jià)格單位不一致把每百萬(wàn) token 當(dāng)成每 token核對(duì)接口文檔中的單位說(shuō)明統(tǒng)一按每百萬(wàn) token 計(jì)算模型上下文不夠用輸入 token 超過(guò)了 context window在調(diào)用前統(tǒng)計(jì) prompt 的 token 數(shù)裁剪 prompt、換更大窗口的模型免費(fèi)接口偶爾超時(shí)公共接口負(fù)載高查看服務(wù)狀態(tài)頁(yè)或健康檢查接口在調(diào)用方增加超時(shí)重試機(jī)制在這張表里最容易被忽略的就是單位問(wèn)題。很多團(tuán)隊(duì)在初期接入時(shí)會(huì)因?yàn)?.002這個(gè)數(shù)字太像“每 token 價(jià)格”而犯錯(cuò)。實(shí)際上如果接口寫的是0.002 USD per 1K tokens那么一個(gè) 1000 token 的請(qǐng)求成本是 0.002 美元如果接口寫的是2 USD per 1M tokens同樣 1000 token 的請(qǐng)求成本是 0.002 美元。兩者數(shù)值上可能偶然一致但字段單位完全不同。做成本估算服務(wù)絕不能依賴“看起來(lái)合理”的數(shù)字一定要以文檔為準(zhǔn)。另一個(gè)值得注意的問(wèn)題是 context window 校驗(yàn)。真實(shí)業(yè)務(wù)里prompt 長(zhǎng)度經(jīng)常會(huì)因?yàn)?RAG 檢索結(jié)果增加而快速膨脹。如果系統(tǒng)沒(méi)有在調(diào)用前檢查 token 數(shù)模型服務(wù)會(huì)直接報(bào)錯(cuò)。一個(gè)好的成本估算服務(wù)應(yīng)該提前做這個(gè)檢查并把“超長(zhǎng)”和“超預(yù)算”區(qū)分開處理。9. 最佳實(shí)踐與工程建議到這里接入和自建的流程已經(jīng)講完了。最后這部分我想給一些在真實(shí)項(xiàng)目中更容易踩坑、但很少被教程提到的最佳實(shí)踐。9.1 價(jià)格數(shù)據(jù)必須緩存但不能長(zhǎng)時(shí)間不過(guò)期免費(fèi) REST API 通常有比較嚴(yán)格的限流。如果你寫了一個(gè)定時(shí)任務(wù)每分鐘去拉一次全部模型價(jià)格很容易把配額耗盡。更合理的策略是應(yīng)用啟動(dòng)時(shí)拉取一次寫入本地緩存之后根據(jù)模型數(shù)據(jù)的更新頻率設(shè)置一個(gè)合理的 TTL比如每小時(shí)或每 12 小時(shí)刷新一次。當(dāng)緩存過(guò)期后重新拉取并替換整張價(jià)格表。CACHE_TTL_SECONDS 3600對(duì)于成本估算這種場(chǎng)景輕微的數(shù)據(jù)延遲并不會(huì)造成嚴(yán)重后果。你需要關(guān)注的是“數(shù)據(jù)更新失敗時(shí)怎么辦”而不是“數(shù)據(jù)多新”。9.2 統(tǒng)一封裝成本估算庫(kù)不要讓業(yè)務(wù)代碼重復(fù)寫公式如果團(tuán)隊(duì)里有多個(gè)服務(wù)都在調(diào)用 LLM成本計(jì)算公式最好抽成公共庫(kù)。否則A 服務(wù)按每百萬(wàn) token 算B 服務(wù)按每千 token 算月底對(duì)賬的時(shí)候你會(huì)非常痛苦。公共庫(kù)的輸入是模型 ID、輸入 token 數(shù)、輸出 token 數(shù)輸出是標(biāo)準(zhǔn)化的成本估算結(jié)果內(nèi)部負(fù)責(zé)查詢價(jià)格執(zhí)行計(jì)算。9.3 與模型路由聯(lián)動(dòng)把成本優(yōu)化做成自動(dòng)化當(dāng)你的內(nèi)部系統(tǒng)已經(jīng)有了每款模型的context_window和價(jià)格后可以做一件非常有價(jià)值的事模型路由。比如一個(gè)任務(wù)需要的上下文長(zhǎng)度只有 20K token那就沒(méi)必要使用 200K 窗口的昂貴模型一個(gè)任務(wù)需要 150K 的上下文普通 128K 模型就跑不了必須路由到更大窗口的模型。這種自動(dòng)選擇策略長(zhǎng)期下來(lái)節(jié)省的成本非常可觀。9.4 安全API Key 管理遵循最小權(quán)限無(wú)論調(diào)用免費(fèi)服務(wù)還是自建內(nèi)部服務(wù)API Key 都必須通過(guò)環(huán)境變量或密鑰管理服務(wù)注入不要硬編碼在代碼里。如果使用 Git 倉(cāng)庫(kù)管理代碼建議在提交前檢查是否意外包含了.env文件。公司內(nèi)部團(tuán)隊(duì)可以約定所有模型相關(guān)密鑰統(tǒng)一由平臺(tái)側(cè)管理業(yè)務(wù)方只能拿到計(jì)算后的成本結(jié)果而不是原始價(jià)格表。9.5 設(shè)置預(yù)算告警不要等到賬單出來(lái)才后悔成本估算的根本目標(biāo)不是算出一個(gè)數(shù)字而是控制成本。建議在內(nèi)部系統(tǒng)里設(shè)置兩級(jí)告警第一級(jí)是軟告警比如某應(yīng)用單日模型成本超過(guò)預(yù)算的 70%第二級(jí)是硬限制比如單日成本超過(guò)預(yù)算的 120% 時(shí)暫停該應(yīng)用的模型調(diào)用。讓成本估算 API 不僅回答“花了多少”還能回答“還剩下多少”。9.6 生產(chǎn)環(huán)境注意服務(wù)健康檢查與降級(jí)策略如果內(nèi)部成本估算服務(wù)掛掉了上游業(yè)務(wù)不應(yīng)該因此完全不可用。降級(jí)策略可以考慮本地仍保留一份上次成功的價(jià)格緩存服務(wù)不可用時(shí)使用緩存繼續(xù)估算如果緩存也沒(méi)有至少讓業(yè)務(wù)告警并阻斷高風(fēng)險(xiǎn)調(diào)用。把成本服務(wù)當(dāng)作基礎(chǔ)組件來(lái)建設(shè)它才會(huì)在關(guān)鍵時(shí)刻真正可靠。到這里關(guān)于免費(fèi) REST API 獲取 LLM 定價(jià)、上下文窗口和成本估算的內(nèi)容就完整了。這篇文章不只是一份接口說(shuō)明書更希望你理解它背后的工程思路把易變的數(shù)據(jù)抽出來(lái)把穩(wěn)定的計(jì)算邏輯沉淀下來(lái)。接下來(lái)你可以先從最小示例開始接入一個(gè)真實(shí)的數(shù)據(jù)源跑通模型列表獲取和成本計(jì)算再逐步加入緩存、模型路由和預(yù)算告警。建議先收藏等真正做成本治理的時(shí)候再翻出來(lái)對(duì)照著實(shí)踐。 免費(fèi)REST API獲取LLM定價(jià)、上下文窗口與成本估算實(shí)踐
做 LLM 應(yīng)用開發(fā)的人大概率在某個(gè)時(shí)刻被同一個(gè)問(wèn)題問(wèn)住過(guò)模型功能已經(jīng)調(diào)通了但老板或者運(yùn)營(yíng)同事突然拋來(lái)一句——“我們每天有一萬(wàn)次請(qǐng)求一個(gè)月花在模型調(diào)用上的錢大概是多少”這時(shí)候你需要的不是一個(gè)只會(huì)數(shù) token 的腳本而是一份準(zhǔn)確、實(shí)時(shí)、機(jī)器可讀的模型價(jià)格表。真正的麻煩在于模型價(jià)格和上下文窗口恰恰是變化最頻繁的信息模型降價(jià)、版本升級(jí)、上下文從 128K 擴(kuò)到 200K都是家常便飯。如果這些數(shù)據(jù)一直靠人手工維護(hù)在代碼里不僅更新慢還容易算錯(cuò)。今天要聊的是 LLM 應(yīng)用工程化中一個(gè)非常實(shí)用的話題免費(fèi)的 REST API專門提供 LLM pricing模型定價(jià)、context windows上下文窗口和 cost estimation成本估算。這篇文章會(huì)從開發(fā)場(chǎng)景切入講清楚這類 API 到底解決什么問(wèn)題、接口通常如何設(shè)計(jì)再給出可以直接運(yùn)行的 Python 接入示例、FastAPI 自建方案以及接入過(guò)程中最常見(jiàn)的坑和工程建議。先給一個(gè)明確判斷在 LLM 應(yīng)用的成本治理里核心難點(diǎn)從來(lái)不是“計(jì)算”而是“數(shù)據(jù)維護(hù)”。誰(shuí)能讓價(jià)格和上下文窗口數(shù)據(jù)保持即時(shí)、結(jié)構(gòu)化、可編程誰(shuí)就能省下大量長(zhǎng)期維護(hù)成本。理解了這一點(diǎn)你就知道為什么值得為這一類 API 單獨(dú)寫一篇文章。1. 為什么需要“機(jī)器可讀”的 LLM 定價(jià)與成本估算 API很多團(tuán)隊(duì)在做 LLM 成本估算時(shí)第一步是打開官網(wǎng)的定價(jià)頁(yè)面然后把價(jià)格抄進(jìn)代碼里的一個(gè)常量表。這種硬編碼方式在模型數(shù)量少、更新頻率低的時(shí)候勉強(qiáng)可用但一旦進(jìn)入真實(shí)業(yè)務(wù)問(wèn)題會(huì)立刻暴露。第一個(gè)問(wèn)題是數(shù)據(jù)過(guò)期。主流模型服務(wù)商調(diào)整價(jià)格、發(fā)布新版本的速度非?？臁＝裉焐暇€時(shí)寫死的價(jià)格可能下個(gè)月就失效了。更麻煩的是這種情況經(jīng)常是靜默發(fā)生的代碼不會(huì)報(bào)錯(cuò)系統(tǒng)也不會(huì)告警只有月底對(duì)賬單的時(shí)候才發(fā)現(xiàn)成本估算偏離了實(shí)際支出。第二個(gè)問(wèn)題是數(shù)據(jù)結(jié)構(gòu)不統(tǒng)一。官網(wǎng)的定價(jià)表格是給人看的不是給程序讀的。有的服務(wù)商用“每 1K tokens”報(bào)價(jià)有的用“每 1M tokens”有的用美元有的用人民幣有的輸入輸出拆分有的只給一個(gè)綜合價(jià)格。每個(gè)模型廠商一套規(guī)則每次接入新模型都要重新讀一遍文檔這對(duì)需要同時(shí)管理多個(gè)模型的應(yīng)用來(lái)說(shuō)非常痛苦。第三個(gè)問(wèn)題是無(wú)法支撐自動(dòng)化決策。當(dāng)你想做模型路由、自動(dòng)預(yù)算告警、按用戶分賬、甚至讓 Agent 在每次任務(wù)前判斷預(yù)算是否充足時(shí)系統(tǒng)必須能實(shí)時(shí)拿到某個(gè)模型的單價(jià)和上下文窗口數(shù)據(jù)而不能依賴一份手工更新的靜態(tài)表。所以這個(gè)領(lǐng)域逐漸出現(xiàn)了一類專門的 REST API它們把“模型定價(jià)”“上下文窗口”“成本估算”做成標(biāo)準(zhǔn)化的接口讓業(yè)務(wù)系統(tǒng)像查詢普通數(shù)據(jù)庫(kù)一樣獲取模型信息。這樣做的好處非常明顯價(jià)格變化由數(shù)據(jù)源統(tǒng)一維護(hù)業(yè)務(wù)代碼只依賴穩(wěn)定的接口契約成本計(jì)算邏輯可以集中封裝、反復(fù)復(fù)用。對(duì)于一個(gè)人數(shù)不多的 LLM 應(yīng)用團(tuán)隊(duì)來(lái)說(shuō)這比自建一套模型信息管理系統(tǒng)要便宜得多。文章接下來(lái)的部分會(huì)圍繞三類讀者展開第一種是只想快速接入一個(gè)免費(fèi)接口、解決成本估算問(wèn)題的應(yīng)用開發(fā)者第二種是希望把模型價(jià)格、上下文窗口數(shù)據(jù)同步到內(nèi)部系統(tǒng)的平臺(tái)工程師第三種是正在設(shè)計(jì)團(tuán)隊(duì)內(nèi)部模型治理方案的架構(gòu)師。2. 基礎(chǔ)概念LLM pricing、context windows 與 cost estimation在進(jìn)入代碼之前有必要把三個(gè)關(guān)鍵詞徹底講清楚。它們彼此獨(dú)立但又共同決定一次模型調(diào)用的實(shí)際成本。遺漏任何一個(gè)成本估算都會(huì)失真。2.1 LLM pricing按 token 計(jì)費(fèi)輸入輸出通常不同價(jià)LLM pricing 指的是模型服務(wù)商對(duì)模型調(diào)用收取的費(fèi)用。絕大多數(shù)主流模型采用按 token 計(jì)費(fèi)的模式也就是按輸入 token 和輸出 token 分別計(jì)價(jià)。這里的“token”是模型處理文本的最小單位一個(gè)英文單詞通常對(duì)應(yīng)一個(gè)或多個(gè) token一個(gè)中文漢字可能對(duì)應(yīng)一到兩個(gè) token具體取決于模型使用的 tokenizer。值得注意的一點(diǎn)是大多數(shù)服務(wù)商的輸出價(jià)格高于輸入價(jià)格。從表面看這只是一個(gè)商業(yè)定價(jià)策略從技術(shù)角度看也有一定合理性輸出階段模型需要自回歸地逐 token 生成每一步都依賴之前的所有狀態(tài)計(jì)算過(guò)程更復(fù)雜。不過(guò)作為使用者我們只需要記住一個(gè)原則成本估算必須輸入、輸出分開算不能用一個(gè)平均價(jià)糊弄過(guò)去。對(duì)于成本估算 API 來(lái)說(shuō)它要解決的關(guān)鍵問(wèn)題是把價(jià)格字段標(biāo)準(zhǔn)化。比如統(tǒng)一使用“每 1M tokens 的價(jià)格”作為字段單位而不是讓調(diào)用方去處理每 1K 還是每 1M 的差異。這樣業(yè)務(wù)代碼可以少踩很多單位坑。2.2 context windows不是越高越好它是成本約束context windows 指的是模型單次請(qǐng)求能夠處理的上下文 token 總數(shù)上限。簡(jiǎn)單說(shuō)就是你把歷史對(duì)話、檢索到的知識(shí)、工具返回結(jié)果全部拼進(jìn) prompt 之后模型最多能“看到”多長(zhǎng)的內(nèi)容。為什么它和成本估算強(qiáng)相關(guān)因?yàn)檩斎?token 數(shù)量是成本公式的第一個(gè)乘數(shù)。上下文越長(zhǎng)輸入 token 越多單次請(qǐng)求成本越高。尤其在使用 RAG 或 Agent 架構(gòu)時(shí)系統(tǒng)往往會(huì)往 prompt 里塞入大量檢索結(jié)果這些內(nèi)容會(huì)快速消耗上下文窗口。實(shí)際開發(fā)中還有一個(gè)容易忽略的細(xì)節(jié)context window 不是都能給輸入的。模型生成輸出也需要占用上下文空間。如果你把 128K 的窗口全部塞滿輸入那么模型可能只剩很少的空間來(lái)生成回復(fù)。因此在做成本估算和參數(shù)校驗(yàn)時(shí)需要同時(shí)檢查“輸入 token 最大輸出 token”是否超過(guò)模型上下文窗口上限。一個(gè)成熟的定價(jià)與成本估算 API通常會(huì)返回每個(gè)模型的 context_window 字段。應(yīng)用層可以借助這個(gè)字段做模型路由任務(wù)需要長(zhǎng)上下文時(shí)優(yōu)先選擇上下文窗口更大的模型短任務(wù)則選擇更便宜、更快的模型。這已經(jīng)不僅是成本估算而是成本優(yōu)化的基礎(chǔ)。2.3 cost estimation核心公式與單位陷阱cost estimation 本質(zhì)上是一個(gè)帶單位的乘法問(wèn)題。假設(shè)某個(gè)模型的輸入價(jià)格為input_price輸出價(jià)格為output_price并且這兩個(gè)價(jià)格都以“每 1M tokens”為基準(zhǔn)那么一次調(diào)用的估算成本可以寫成cost (input_tokens * input_price output_tokens * output_price) / 1_000_000這個(gè)公式本身不復(fù)雜但單位陷阱非常多。我用下面的表格列出幾種常見(jiàn)的情況價(jià)格單位公式中的分母容易出錯(cuò)的地方每 1K tokens1000看到價(jià)格是 0.002 就當(dāng)成每 token 價(jià)格結(jié)果差 1000 倍每 1M tokens1000000輸入和輸出價(jià)格字段混淆美元 vs 人民幣無(wú)但需要匯率換算估算結(jié)果與賬單幣種不一致部分服務(wù)區(qū)分緩存命中價(jià)格視接口而定忽略了緩存命中率成本被高估在使用現(xiàn)成的成本估算 API 時(shí)第一件事就是確認(rèn)它的價(jià)格字段單位。如果接口返回的是“每 1M tokens 的價(jià)格”那么代碼里的分母就是 1_000_000如果接口返回的是“每 1K tokens 的價(jià)格”分母就是 1_000。這個(gè)細(xì)節(jié)直接影響最終結(jié)果也決定著你接的 API 是否真的省心。3. 免費(fèi) REST API 的典型設(shè)計(jì)思路與接口規(guī)范在分析具體代碼之前先建立一種直覺(jué)一個(gè)好的 LLM 定價(jià)與成本估算 REST API在設(shè)計(jì)上應(yīng)該是什么樣的它和普通的業(yè)務(wù) API 有什么區(qū)別3.1 這類 API 解決的核心問(wèn)題從設(shè)計(jì)目標(biāo)看這類 API 要解決三個(gè)問(wèn)題第一提供標(biāo)準(zhǔn)化的模型元數(shù)據(jù)。無(wú)論是開源社區(qū)的免費(fèi)接口還是商業(yè)服務(wù)商的官方接口本質(zhì)上都是把零散的定價(jià)信息整理成統(tǒng)一字段。常見(jiàn)的字段包括模型 ID、上下文窗口大小、輸入價(jià)格、輸出價(jià)格、數(shù)據(jù)截止時(shí)間等。第二把成本計(jì)算邏輯集中化。調(diào)用方不需要在業(yè)務(wù)代碼里重復(fù)寫成本公式而是把輸入 token 數(shù)、輸出 token 數(shù)傳給接口讓接口返回估算金額。這保證了成本計(jì)算口徑的一致性也為后續(xù)調(diào)整計(jì)費(fèi)策略留下了空間。第三支持自動(dòng)化消費(fèi)。REST API 天然適合程序調(diào)用無(wú)論是每天定時(shí)同步到內(nèi)部數(shù)據(jù)庫(kù)還是在每個(gè) Agent 任務(wù)開始前實(shí)時(shí)查詢都很方便。3.2 典型接口端點(diǎn)設(shè)計(jì)雖然不同服務(wù)實(shí)現(xiàn)的細(xì)節(jié)不同但它們通常會(huì)包含下面幾類端點(diǎn)。這里不綁定任何具體項(xiàng)目而是給出一種通用結(jié)構(gòu)方便你快速理解并遷移到真實(shí)服務(wù)上。方法端點(diǎn)作用GET/v1/models獲取所有模型列表包括 ID、context window、價(jià)格字段GET/v1/models/{model_id}獲取單個(gè)模型的詳細(xì)定價(jià)信息POST/v1/cost-estimate傳入模型 ID、輸入 token 數(shù)、輸出 token 數(shù)返回估算成本GET/health健康檢查判斷服務(wù)是否可用資源化、版本化、職責(zé)單一這是 REST API 的標(biāo)準(zhǔn)設(shè)計(jì)語(yǔ)言。以GET /v1/models為例它的響應(yīng)結(jié)構(gòu)可能類似這樣{ items: [ { id: gpt-demo, provider: demo-provider, context_window: 128000, input_price_per_million: 0.50, output_price_per_million: 1.50, updated_at: 2025-06-01T00:00:00Z } ] }這里的input_price_per_million表示每 1M 輸入 token 的價(jià)格單位是美元context_window表示上下文窗口大小。字段名在不同項(xiàng)目里可能有差異但表達(dá)的信息基本一致。接入任何具體 API 之前應(yīng)該先以它的文檔為準(zhǔn)把這幾個(gè)字段的映射關(guān)系確認(rèn)清楚。3.3 關(guān)于“免費(fèi)”的邊界“免費(fèi)”不是沒(méi)有代價(jià)。大多數(shù)免費(fèi) API 會(huì)通過(guò)限流Rate Limit、請(qǐng)求頻率、功能裁剪等方式控制成本。從工程角度看這是合理的。接入免費(fèi)接口時(shí)需要關(guān)注幾個(gè)點(diǎn)一是配額。免費(fèi)接口通常有每分鐘請(qǐng)求數(shù)上限如果應(yīng)用需要高頻查詢就必須在本地做緩存而不是每次請(qǐng)求都打到遠(yuǎn)端。二是數(shù)據(jù)更新頻率。有的接口實(shí)時(shí)同步官方價(jià)格有的可能每天或每周更新一次。對(duì)于成本估算這種場(chǎng)景短時(shí)間內(nèi)的延遲通?？梢越邮艿绻糜谪?cái)務(wù)級(jí)對(duì)賬必須確認(rèn)數(shù)據(jù)源更新策略。三是許可條款。如果是商業(yè)項(xiàng)目建議先閱讀服務(wù)條款確認(rèn)免費(fèi)層是否允許商用。更穩(wěn)妥的做法是把這類免費(fèi)接口作為數(shù)據(jù)源之一在本地維護(hù)緩存減少對(duì)單一服務(wù)的依賴。4. 環(huán)境準(zhǔn)備與前置條件進(jìn)入代碼之前先把環(huán)境準(zhǔn)備好。本文的示例以 Python 為主因?yàn)?Python 在數(shù)據(jù)處理和 LLM 應(yīng)用開發(fā)中是最常見(jiàn)的選擇。下面的環(huán)境要求是通用建議版本號(hào)請(qǐng)以實(shí)際安裝環(huán)境為準(zhǔn)。需要準(zhǔn)備的環(huán)境如下Python 3.9 及以上版本可以正常訪問(wèn)目標(biāo) API 的網(wǎng)絡(luò)環(huán)境如果目標(biāo) API 要求認(rèn)證提前注冊(cè)并獲取 API Keypip包管理工具主要用到的 Python 依賴包括requests發(fā)起 HTTP 請(qǐng)求、fastapi自建成本估算服務(wù)、uvicorn運(yùn)行 FastAPI 應(yīng)用和pydanticFastAPI 的依賴通常會(huì)自動(dòng)安裝。安裝命令如下pip install requests fastapi uvicorn如果你準(zhǔn)備使用環(huán)境變量管理 API Key可以安裝python-dotenv來(lái)讀取本地.env文件pip install python-dotenv安裝完成后建議在項(xiàng)目根目錄新建一個(gè).env文件把你從服務(wù)商那里獲取的 API Key 放進(jìn)去。例如# 文件路徑.env LLM_PRICE_API_TOKENyour_token_here LLM_PRICE_API_BASEhttps://api.example.com/v1注意.env文件不要提交到 Git 倉(cāng)庫(kù)。如果是公開倉(cāng)庫(kù)務(wù)必在.gitignore中加上.env。在實(shí)際調(diào)用任何第三方 API 之前先做一次最小化的連通性驗(yàn)證通常是用瀏覽器訪問(wèn)https://api.example.com/v1/models這樣的地址確認(rèn)網(wǎng)絡(luò)和認(rèn)證都沒(méi)問(wèn)題。這樣可以避免在代碼調(diào)試階段來(lái)回排查網(wǎng)絡(luò)錯(cuò)誤。5. 完整示例Python 接入定價(jià) API 并完成成本估算現(xiàn)在進(jìn)入實(shí)操。假設(shè)你已經(jīng)找到了一個(gè)提供 LLM 定價(jià)信息的免費(fèi) REST API并且拿到了文檔。下面用最小示例演示如何獲取模型列表、查詢單個(gè)模型、以及完成一次成本估算。5.1 獲取模型列表創(chuàng)建一個(gè)文件scripts/get_models.py代碼邏輯非常簡(jiǎn)單發(fā)起一個(gè) GET 請(qǐng)求解析返回的 JSON然后打印模型 ID、上下文窗口和價(jià)格字段。# 文件路徑scripts/get_models.py import os import requests from dotenv import load_dotenv load_dotenv() API_TOKEN os.getenv(LLM_PRICE_API_TOKEN, ) API_BASE_URL os.getenv(LLM_PRICE_API_BASE, https://api.example.com/v1) def fetch_models() - list: headers { Authorization: fBearer {API_TOKEN}, Content-Type: application/json, } resp requests.get(f{API_BASE_URL}/models, headersheaders, timeout10) resp.raise_for_status() data resp.json() # 不同接口返回結(jié)構(gòu)不同這里兼容兩種常見(jiàn)格式 if isinstance(data, list): return data return data.get(items, []) if __name__ __main__: models fetch_models() for model in models: print( f{model.get(id)} | fcontext_window{model.get(context_window)} | finput_usd_per_million{model.get(input_price_per_million)} | foutput_usd_per_million{model.get(output_price_per_million)} )這段代碼有幾點(diǎn)需要說(shuō)明通過(guò)load_dotenv()讀取本地環(huán)境變量避免把 API Key 硬編碼在源碼里。timeout10限制了單個(gè)請(qǐng)求的超時(shí)時(shí)間避免接口卡住時(shí)進(jìn)程一直等待。resp.raise_for_status()可以在響應(yīng)狀態(tài)碼不是 2xx 時(shí)立刻拋出異常方便排查問(wèn)題。運(yùn)行方式cd 項(xiàng)目目錄 python scripts/get_models.py如果一切正常你會(huì)看到類似下面的輸出gpt-demo | context_window128000 | input_usd_per_million0.50 | output_usd_per_million1.50 claude-demo | context_window200000 | input_usd_per_million1.00 | output_usd_per_million2.00這里使用的模型 ID 和價(jià)格都是示意數(shù)據(jù)。真實(shí)項(xiàng)目中的模型 ID 可能是gpt-4o、claude-sonnet-4等形式具體以接口返回為準(zhǔn)。5.2 查詢單個(gè)模型并計(jì)算成本模型列表接口通常還會(huì)包含一個(gè)單模型查詢端點(diǎn)。在實(shí)際業(yè)務(wù)中你一般不會(huì)每次調(diào)用都拉取全部模型而是根據(jù)用戶請(qǐng)求里的模型 ID 查詢一個(gè)模型。下面的示例演示了查詢模型并完成成本估算的完整流程。# 文件路徑scripts/estimate_cost.py import os import requests from dotenv import load_dotenv load_dotenv() API_TOKEN os.getenv(LLM_PRICE_API_TOKEN, ) API_BASE_URL os.getenv(LLM_PRICE_API_BASE, https://api.example.com/v1) # 簡(jiǎn)單內(nèi)存緩存避免同一個(gè)模型的重復(fù)請(qǐng)求 MODEL_CACHE {} def get_model_info(model_id: str) - dict: if model_id in MODEL_CACHE: return MODEL_CACHE[model_id] headers { Authorization: fBearer {API_TOKEN}, Content-Type: application/json, } resp requests.get( f{API_BASE_URL}/models/{model_id}, headersheaders, timeout10, ) resp.raise_for_status() info resp.json() MODEL_CACHE[model_id] info return info def estimate_cost(model_id: str, input_tokens: int, output_tokens: int) - float: info get_model_info(model_id) input_price info[input_price_per_million] output_price info[output_price_per_million] # 單位統(tǒng)一為“每百萬(wàn) token”所以分母是 1_000_000 cost ( input_tokens * input_price output_tokens * output_price ) / 1_000_000 return round(cost, 8) if __name__ __main__: model_id gpt-demo input_tokens 12000 output_tokens 3000 cost estimate_cost(model_id, input_tokens, output_tokens) print(fmodel{model_id}, input{input_tokens}, output{output_tokens}) print(festimated_cost_usd{cost})這里加入了一個(gè)非常簡(jiǎn)單的內(nèi)存緩存MODEL_CACHE。對(duì)于價(jià)格這類變化不頻繁的數(shù)據(jù)緩存可以顯著減少遠(yuǎn)端 API 的請(qǐng)求量。對(duì)于免費(fèi) API 來(lái)說(shuō)這既能降低觸發(fā)限流的概率也能減少對(duì)公共服務(wù)資源的沖擊。運(yùn)行方式和預(yù)期結(jié)果python scripts/estimate_cost.pymodelgpt-demo, input12000, output3000 estimated_cost_usd0.0105計(jì)算過(guò)程是(12000 * 0.50 3000 * 1.50) / 1_000_000 0.0105 USD5.3 一個(gè)更完整的成本估算請(qǐng)求封裝如果你覺(jué)得上面的示例還是偏簡(jiǎn)單可以參考下面這段更接近生產(chǎn)環(huán)境的封裝。它增加了鑒權(quán)、異常處理、輸入?yún)?shù)校驗(yàn)和上下文窗口檢查。# 文件路徑scripts/estimate_cost_v2.py import os import requests from dotenv import load_dotenv load_dotenv() API_TOKEN os.getenv(LLM_PRICE_API_TOKEN, ) API_BASE_URL os.getenv(LLM_PRICE_API_BASE, https://api.example.com/v1) def validate_input(model_info: dict, input_tokens: int, output_tokens: int) - None: context_window model_info.get(context_window) if context_window and input_tokens output_tokens context_window: raise ValueError( finput_tokens output_tokens exceeds context_window: f{input_tokens output_tokens} {context_window} ) if input_tokens 0 or output_tokens 0: raise ValueError(input_tokens and output_tokens must be non-negative) def get_estimate(model_id: str, input_tokens: int, output_tokens: int) - dict: headers {Authorization: fBearer {API_TOKEN}} payload { model_id: model_id, input_tokens: input_tokens, output_tokens: output_tokens, } resp requests.post( f{API_BASE_URL}/cost-estimate, jsonpayload, headersheaders, timeout10, ) resp.raise_for_status() return resp.json() if __name__ __main__: try: result get_estimate(gpt-demo, 12000, 3000) print(result) except Exception as exc: print(festimate failed: {exc})這種做法的好處是把校驗(yàn)邏輯和服務(wù)調(diào)用分離。上線之后如果發(fā)現(xiàn)某個(gè)請(qǐng)求的 token 數(shù)異?？梢灾苯釉?validation 階段攔截而不是等到調(diào)用模型服務(wù)時(shí)才發(fā)現(xiàn)參數(shù)不合理。6. 進(jìn)階示例用 FastAPI 自建內(nèi)部成本估算服務(wù)在很多團(tuán)隊(duì)里內(nèi)部系統(tǒng)并不希望每個(gè)服務(wù)都直接調(diào)用外部的免費(fèi) API。更常見(jiàn)的做法是把模型價(jià)格數(shù)據(jù)緩存到內(nèi)部封裝成一個(gè)統(tǒng)一的成本估算服務(wù)所有業(yè)務(wù)線都走這個(gè)入口。好處是可以統(tǒng)一鑒權(quán)、統(tǒng)一緩存、統(tǒng)一審計(jì)并且可以很方便地疊加公司內(nèi)部的折扣策略。下面用 FastAPI 實(shí)現(xiàn)一個(gè)最小可運(yùn)行的成本估算服務(wù)。重點(diǎn)不是展示 FastAPI 的全部能力而是給出一個(gè)可以擴(kuò)展的內(nèi)部服務(wù)骨架。# 文件路徑app/main.py from fastapi import FastAPI, HTTPException from pydantic import BaseModel, Field app FastAPI() # 注意以下價(jià)格數(shù)據(jù)是示意數(shù)據(jù)僅供演示 # 生產(chǎn)環(huán)境應(yīng)從可信數(shù)據(jù)源同步并建立定期刷新機(jī)制 MODEL_PRICE_TABLE { gpt-demo: { input_price_per_million: 0.50, output_price_per_million: 1.50, context_window: 128000, }, claude-demo: { input_price_per_million: 1.00, output_price_per_million: 2.00, context_window: 200000, }, } class EstimateRequest(BaseModel): model_id: str Field(..., description模型唯一標(biāo)識(shí)) input_tokens: int Field(1000, ge0, description輸入 token 數(shù)) output_tokens: int Field(500, ge0, description輸出 token 數(shù)) class EstimateResponse(BaseModel): model_id: str input_tokens: int output_tokens: int estimated_cost_usd: float app.get(/v1/models) def list_models(): return { items: [ {id: model_id, **meta} for model_id, meta in MODEL_PRICE_TABLE.items() ] } app.post(/v1/cost-estimate, response_modelEstimateResponse) def cost_estimate(req: EstimateRequest): model MODEL_PRICE_TABLE.get(req.model_id) if not model: raise HTTPException(status_code404, detailfunknown model: {req.model_id}) cost ( req.input_tokens * model[input_price_per_million] req.output_tokens * model[output_price_per_million] ) / 1_000_000 return EstimateResponse( model_idreq.model_id, input_tokensreq.input_tokens, output_tokensreq.output_tokens, estimated_cost_usdround(cost, 8), )啟動(dòng)服務(wù)uvicorn app.main:app --reload然后通過(guò) curl 驗(yàn)證成本估算接口curl -X POST http://127.0.0.1:8000/v1/cost-estimate \ -H Content-Type: application/json \ -d {model_id: gpt-demo, input_tokens: 12000, output_tokens: 3000}預(yù)期返回{ model_id: gpt-demo, input_tokens: 12000, output_tokens: 3000, estimated_cost_usd: 0.0105 }這個(gè)自建服務(wù)的關(guān)鍵價(jià)值不只是提供一個(gè) HTTP 接口而是為后續(xù)擴(kuò)展留好了位置。比如你可以在接口中加入預(yù)算校驗(yàn)當(dāng)某個(gè)應(yīng)用連續(xù)調(diào)用模型的成本超過(guò)閾值時(shí)返回警告也可以在服務(wù)內(nèi)部增加價(jià)格數(shù)據(jù)刷新任務(wù)每天定時(shí)從外部 API 拉取最新價(jià)格并更新MODEL_PRICE_TABLE。相比每個(gè)業(yè)務(wù)單獨(dú)硬編碼價(jià)格這種集中式服務(wù)要好維護(hù)得多。7. 運(yùn)行結(jié)果與效果驗(yàn)證接入完成后不能只看一次輸出就認(rèn)為萬(wàn)事大吉。成本估算這種功能錯(cuò)誤往往藏在單位、字段映射和邊界條件里。建議按照下面幾個(gè)維度做驗(yàn)證。第一個(gè)維度是計(jì)算正確性。拿一個(gè)已知價(jià)格的模型手動(dòng)用公式算一遍再和接口返回結(jié)果對(duì)比。比如輸入 1000 token、輸出 500 token價(jià)格為每百萬(wàn) 1 美元預(yù)期成本是(1000 * 1 500 * 1) / 1000000 0.0015。如果接口返回的結(jié)果不是這個(gè)值優(yōu)先檢查價(jià)格字段是否被錯(cuò)誤地當(dāng)成了“每 token 價(jià)格”。第二個(gè)維度是邊界處理。傳入 0 token 或用負(fù)數(shù)測(cè)試看看接口是否正常返回錯(cuò)誤。合法的成本估算服務(wù)不應(yīng)該允許負(fù)數(shù) token 輸入。同時(shí)檢查當(dāng)輸入輸出之和超過(guò)模型 context window 時(shí)系統(tǒng)是否能給出明確提示。第三個(gè)維度是網(wǎng)絡(luò)異常。模擬網(wǎng)絡(luò)超時(shí)、API 返回 429 限流等情況確認(rèn)你的代碼有合理的異常處理而不是直接拋出一個(gè)讓人摸不著頭腦的堆棧。建議在關(guān)鍵調(diào)用處加上 try/except并記錄結(jié)構(gòu)化日志。第四個(gè)維度是數(shù)據(jù)同步。如果外部免費(fèi) API 的模型價(jià)格更新了你的系統(tǒng)多久能感知到如果是直接調(diào)用每次請(qǐng)求都拿最新數(shù)據(jù)如果是做了緩存需要明確緩存過(guò)期時(shí)間并確保過(guò)期后能重新拉取最新數(shù)據(jù)。驗(yàn)證的時(shí)候建議把預(yù)期結(jié)果和實(shí)際輸出放在一起對(duì)比用表格記錄。這樣可以快速定位是計(jì)算邏輯的問(wèn)題、單位的問(wèn)題還是接口字段映射的問(wèn)題。8. 常見(jiàn)問(wèn)題與排查思路根據(jù)實(shí)際接入經(jīng)驗(yàn)下面這些問(wèn)題出現(xiàn)的頻率最高。遇到問(wèn)題時(shí)可以先用這張表格快速定位方向。問(wèn)題現(xiàn)象可能原因排查方式解決方案請(qǐng)求返回 404接口路徑或版本號(hào)錯(cuò)誤查看 API 文檔確認(rèn)端點(diǎn)是否帶/v1前綴修正請(qǐng)求路徑請(qǐng)求返回 401API Key 無(wú)效或未傳入檢查環(huán)境變量是否加載請(qǐng)求頭是否正確重新獲取 API Key修正環(huán)境變量請(qǐng)求返回 429觸發(fā)了限流配額查看響應(yīng)頭中的 RateLimit 字段增加本地緩存、降低請(qǐng)求頻率、升級(jí)配額成本計(jì)算結(jié)果為 0價(jià)格字段缺失或?yàn)?0打印模型返回的原始 JSON檢查字段名是否正確成本結(jié)果和預(yù)期差很多價(jià)格單位不一致把每百萬(wàn) token 當(dāng)成每 token核對(duì)接口文檔中的單位說(shuō)明統(tǒng)一按每百萬(wàn) token 計(jì)算模型上下文不夠用輸入 token 超過(guò)了 context window在調(diào)用前統(tǒng)計(jì) prompt 的 token 數(shù)裁剪 prompt、換更大窗口的模型免費(fèi)接口偶爾超時(shí)公共接口負(fù)載高查看服務(wù)狀態(tài)頁(yè)或健康檢查接口在調(diào)用方增加超時(shí)重試機(jī)制在這張表里最容易被忽略的就是單位問(wèn)題。很多團(tuán)隊(duì)在初期接入時(shí)會(huì)因?yàn)?.002這個(gè)數(shù)字太像“每 token 價(jià)格”而犯錯(cuò)。實(shí)際上如果接口寫的是0.002 USD per 1K tokens那么一個(gè) 1000 token 的請(qǐng)求成本是 0.002 美元如果接口寫的是2 USD per 1M tokens同樣 1000 token 的請(qǐng)求成本是 0.002 美元。兩者數(shù)值上可能偶然一致但字段單位完全不同。做成本估算服務(wù)絕不能依賴“看起來(lái)合理”的數(shù)字一定要以文檔為準(zhǔn)。另一個(gè)值得注意的問(wèn)題是 context window 校驗(yàn)。真實(shí)業(yè)務(wù)里prompt 長(zhǎng)度經(jīng)常會(huì)因?yàn)?RAG 檢索結(jié)果增加而快速膨脹。如果系統(tǒng)沒(méi)有在調(diào)用前檢查 token 數(shù)模型服務(wù)會(huì)直接報(bào)錯(cuò)。一個(gè)好的成本估算服務(wù)應(yīng)該提前做這個(gè)檢查并把“超長(zhǎng)”和“超預(yù)算”區(qū)分開處理。9. 最佳實(shí)踐與工程建議到這里接入和自建的流程已經(jīng)講完了。最后這部分我想給一些在真實(shí)項(xiàng)目中更容易踩坑、但很少被教程提到的最佳實(shí)踐。9.1 價(jià)格數(shù)據(jù)必須緩存但不能長(zhǎng)時(shí)間不過(guò)期免費(fèi) REST API 通常有比較嚴(yán)格的限流。如果你寫了一個(gè)定時(shí)任務(wù)每分鐘去拉一次全部模型價(jià)格很容易把配額耗盡。更合理的策略是應(yīng)用啟動(dòng)時(shí)拉取一次寫入本地緩存之后根據(jù)模型數(shù)據(jù)的更新頻率設(shè)置一個(gè)合理的 TTL比如每小時(shí)或每 12 小時(shí)刷新一次。當(dāng)緩存過(guò)期后重新拉取并替換整張價(jià)格表。CACHE_TTL_SECONDS 3600對(duì)于成本估算這種場(chǎng)景輕微的數(shù)據(jù)延遲并不會(huì)造成嚴(yán)重后果。你需要關(guān)注的是“數(shù)據(jù)更新失敗時(shí)怎么辦”而不是“數(shù)據(jù)多新”。9.2 統(tǒng)一封裝成本估算庫(kù)不要讓業(yè)務(wù)代碼重復(fù)寫公式如果團(tuán)隊(duì)里有多個(gè)服務(wù)都在調(diào)用 LLM成本計(jì)算公式最好抽成公共庫(kù)。否則A 服務(wù)按每百萬(wàn) token 算B 服務(wù)按每千 token 算月底對(duì)賬的時(shí)候你會(huì)非常痛苦。公共庫(kù)的輸入是模型 ID、輸入 token 數(shù)、輸出 token 數(shù)輸出是標(biāo)準(zhǔn)化的成本估算結(jié)果內(nèi)部負(fù)責(zé)查詢價(jià)格執(zhí)行計(jì)算。9.3 與模型路由聯(lián)動(dòng)把成本優(yōu)化做成自動(dòng)化當(dāng)你的內(nèi)部系統(tǒng)已經(jīng)有了每款模型的context_window和價(jià)格后可以做一件非常有價(jià)值的事模型路由。比如一個(gè)任務(wù)需要的上下文長(zhǎng)度只有 20K token那就沒(méi)必要使用 200K 窗口的昂貴模型一個(gè)任務(wù)需要 150K 的上下文普通 128K 模型就跑不了必須路由到更大窗口的模型。這種自動(dòng)選擇策略長(zhǎng)期下來(lái)節(jié)省的成本非常可觀。9.4 安全API Key 管理遵循最小權(quán)限無(wú)論調(diào)用免費(fèi)服務(wù)還是自建內(nèi)部服務(wù)API Key 都必須通過(guò)環(huán)境變量或密鑰管理服務(wù)注入不要硬編碼在代碼里。如果使用 Git 倉(cāng)庫(kù)管理代碼建議在提交前檢查是否意外包含了.env文件。公司內(nèi)部團(tuán)隊(duì)可以約定所有模型相關(guān)密鑰統(tǒng)一由平臺(tái)側(cè)管理業(yè)務(wù)方只能拿到計(jì)算后的成本結(jié)果而不是原始價(jià)格表。9.5 設(shè)置預(yù)算告警不要等到賬單出來(lái)才后悔成本估算的根本目標(biāo)不是算出一個(gè)數(shù)字而是控制成本。建議在內(nèi)部系統(tǒng)里設(shè)置兩級(jí)告警第一級(jí)是軟告警比如某應(yīng)用單日模型成本超過(guò)預(yù)算的 70%第二級(jí)是硬限制比如單日成本超過(guò)預(yù)算的 120% 時(shí)暫停該應(yīng)用的模型調(diào)用。讓成本估算 API 不僅回答“花了多少”還能回答“還剩下多少”。9.6 生產(chǎn)環(huán)境注意服務(wù)健康檢查與降級(jí)策略如果內(nèi)部成本估算服務(wù)掛掉了上游業(yè)務(wù)不應(yīng)該因此完全不可用。降級(jí)策略可以考慮本地仍保留一份上次成功的價(jià)格緩存服務(wù)不可用時(shí)使用緩存繼續(xù)估算如果緩存也沒(méi)有至少讓業(yè)務(wù)告警并阻斷高風(fēng)險(xiǎn)調(diào)用。把成本服務(wù)當(dāng)作基礎(chǔ)組件來(lái)建設(shè)它才會(huì)在關(guān)鍵時(shí)刻真正可靠。到這里關(guān)于免費(fèi) REST API 獲取 LLM 定價(jià)、上下文窗口和成本估算的內(nèi)容就完整了。這篇文章不只是一份接口說(shuō)明書更希望你理解它背后的工程思路把易變的數(shù)據(jù)抽出來(lái)把穩(wěn)定的計(jì)算邏輯沉淀下來(lái)。接下來(lái)你可以先從最小示例開始接入一個(gè)真實(shí)的數(shù)據(jù)源跑通模型列表獲取和成本計(jì)算再逐步加入緩存、模型路由和預(yù)算告警。建議先收藏等真正做成本治理的時(shí)候再翻出來(lái)對(duì)照著實(shí)踐。