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