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