如果你经常在应用里接入大模型大概率会遇到三件很烦的事模型价格变化快、上下文窗口参数各不相同、每次估算一次调用成本要翻好几个文档。免费的 LLM 定价与成本估算 REST API 就是来解决这个问题的。它把模型名称、输入价格、输出价格、上下文窗口这几个关键字段统一成 JSON通过 HTTP 请求返回你不需要自己维护一份东拼西凑的价格表。这篇文章适合做模型选型、成本预测、AI Agent 开发、内部工具集成的场景也适合想自己搭建一个轻量级模型价格服务的开发者。这类 API 最值得关注的不是功能列表而是能不能在普通环境里稳定跑起来、返回的数据是否可解释、成本估算逻辑是否清晰。下面按我自己实际落地时比较关心的顺序把接口设计、调用方式、估算公式、批量处理、自建细节和排查思路拆开讲。1. 先确认它到底解决的是“查价格”还是“算成本”问题1.1 查价格和算成本是两件事很多人在选模型时第一反应是打开各家官网价格页把每百万 tokens 的价格抄下来。这种方式有两个问题一是官网表格多、单位不统一有的按每百万 tokens有的按每千 tokens还有的按字符或图片数量计价二是就算你把价格都抄对了也未必能算出一次实际调用要花多少钱因为还要考虑输入 tokens 和输出 tokens 的占比、缓存命中、上下文长度等因素。所以这个 API 的价值应该分成两层第一层是查询给出模型名称返回它的输入价格、输出价格、上下文窗口、最大输出长度等基础信息。第二层是估算给出模型名称和这次请求的 input tokens、output tokens返回预估费用。对于普通开发来说第二层更有用。因为你在写代码时真正关心的是“我这次请求大概花多少钱”“换一个模型能省多少”“这个提示词会不会超出上下文窗口”。至于底层价格数据是不是实时同步其实可以交给 API 端去维护。1.2 上下文窗口在成本估算里是硬约束只看价格不看上下文窗口很容易踩坑。比如一个模型单次调用价格很低但上下文窗口只有 4K你的业务提示词加日志内容动不动就 20K那这个模型根本跑不了。强行调用要么直接报错要么需要你做截断、分块反而增加调用次数和成本。所以便宜模型不一定省钱能满足上下文约束的模型才值得比较。成本估算 API 最好同时返回context_window和max_output_tokens这样你在估算之前就能先做一次可用性过滤。1.3 给 AI Agent 和内部系统提供标准接口我之前在做一个 AI Agent 的时候遇到过更实际的问题Agent 内部会动态选择模型不同任务走不同模型但预算有限。如果不在代码里写死模型就需要有一个统一接口来查“当前任务适合用哪个模型”。这时候 REST API 就比直接查数据库方便得多。你可以在 Agent 的调度逻辑里加一步先调用这个 API 获取候选模型的价格和上下文再结合任务预估 tokens 数选择预算内且上下文足够的模型。整个过程对外暴露的就是一个 HTTP 接口团队其他服务也能复用。2. 先弄清接口设计、请求参数和返回字段2.1 常见的端点设计一个标准的模型价格与成本估算 API通常至少包含三个端点方法路径作用GET/v1/models获取支持的全部模型列表GET/v1/models/{model}获取单个模型的定价和上下文信息POST/v1/estimate提交 tokens 数返回成本估算这里路径是通用设计不同服务可能有不同前缀比如/api/v1/prices。如果用的是免费公共服务可能会要求你在 Header 里带一个 API Key如果是自己部署则可以不用。我的建议是先把GET /v1/models调通确认返回结构再查单个模型最后才用POST /v1/estimate做估算。按这个顺序走能减少很多不必要的困惑。2.2 请求参数有哪些以POST /v1/estimate为例核心参数一般不复杂参数类型说明modelstring模型标识例如gpt-4o-miniinput_tokensinteger输入文本折算的 token 数量output_tokensinteger预期生成的 token 数量currencystring可选币种默认 USD有些 API 还会支持cache_read_tokens和cache_write_tokens用来区分缓存命中后的输入价格。如果接口支持尽量使用如果不支持就先按普通输入价格估算后面再手动校正。还有一点要特别注意input_tokens和output_tokens不是你肉眼看到的字符数而是模型分词器实际切出来的 token 数。中文、代码、数字和空格都会影响 token 数所以估算前最好先用对应模型的分词器做一次转换或者至少要留出 10% 到 20% 的余量。2.3 返回 JSON 怎么理解假设返回结构长这样{ model: gpt-4o-mini, context_window: 128000, max_output_tokens: 16384, input_price_per_1k: 0.00015, output_price_per_1k: 0.0006, currency: USD, updated_at: 2025-06-01T00:00:00Z }这几个字段是核心context_window模型最大上下文总长度单位是 token。注意是输入加输出的总和不是单独输入上限。max_output_tokens单次输出最大 token 数。input_price_per_1k每 1000 个输入 token 的价格。output_price_per_1k每 1000 个输出 token 的价格。updated_at价格数据的更新时间。很多免费 API 的价格数据不是实时抓取的可能一周更新一次。所以看到价格时先看updated_at是否太旧。如果相差超过一个月最好再和官方价格页核对一下。3. 本地调用与最小验证流程3.1 先用 curl 跑通第一步别写代码先用 curl 验证接口是否可用。假设你的 API 服务地址是https://api.example.comcurl -X GET https://api.example.com/v1/models \ -H Accept: application/json如果接口需要 API Key加上curl -X GET https://api.example.com/v1/models \ -H Authorization: Bearer YOUR_API_KEY正常返回会是一个模型列表数组。如果返回 401说明 Key 没带对如果返回 404说明路径不对。再测试单个模型curl -X GET https://api.example.com/v1/models/gpt-4o-mini \ -H Authorization: Bearer YOUR_API_KEY这里的关键是先用一条最简单、最稳定的请求确认网络、鉴权和路径都正常再继续后面的估算调用。不要一上来就传复杂参数否则没法判断问题到底出在哪一层。3.2 用 Python 接入能用 curl 跑通之后再用 Python 封装会比较可靠。Python 里我一般用requests没有的话先安装pip install requests示例代码import requests BASE_URL https://api.example.com API_KEY your-api-key headers { Authorization: fBearer {API_KEY}, Content-Type: application/json } def estimate_cost(model, input_tokens, output_tokens): url f{BASE_URL}/v1/estimate payload { model: model, input_tokens: input_tokens, output_tokens: output_tokens } resp requests.post(url, jsonpayload, headersheaders, timeout10) resp.raise_for_status() return resp.json() result estimate_cost(gpt-4o-mini, 12000, 2000) print(result)这里把超时时间设为 10 秒是避免外部服务卡住导致主流程阻塞。如果服务比较慢可以根据自己情况加大到 30 秒但一定要有超时不能无限等。3.3 判断结果是否正常拿到返回结果后不要只看有没有estimated_cost_usd还要做一次简单复算。比如返回{ model: gpt-4o-mini, input_cost: 0.0018, output_cost: 0.0012, estimated_cost_usd: 0.003, within_context: true }你可以手动验算12000 / 1000 * 0.00015 0.00182000 / 1000 * 0.0006 0.0012合计 0.003。如果手动算出来不一致说明要么接口单位不是每 1k tokens要么返回字段语义和你理解的不一样。这时候先看文档别急着改业务代码。另外还要看within_context字段。如果它是 false说明input_tokens output_tokens已经超过context_window即使价格估算出来很便宜也不能直接用这个模型跑。4. 成本估算的核心公式与边界4.1 输入输出分开计价绝大多数 LLM 的定价都是输入和输出分开的输出通常比输入贵好几倍。所以成本估算不能只算总 token 数乘以一个平均价格一定要拆开算。基本公式cost input_tokens / 1000 * input_price_per_1k output_tokens / 1000 * output_price_per_1k如果 API 返回的价格单位是每百万 tokens那公式里的 1000 就要换成 1000000。这也是最容易搞混的地方。我会在接入代码里先写一个单元测试固定传 1000 个输入 token 和 1000 个输出 token看返回结果是否符合预期。4.2 上下文窗口是限制不是成本项很多人在估算时会把context_window当作成本计算因子这是不对的。上下文窗口只决定“这次请求能不能被模型接受”不直接参与价格计算。正确的处理逻辑是先判断input_tokens output_tokens context_window。再判断output_tokens max_output_tokens。两个条件都满足才计算成本。如果超了优先考虑截断输入、减少输出长度或者换一个上下文更大的模型。这个顺序很重要。否则你算出一个很便宜的成本结果真正调用时因为上下文超限直接报错重试一次反而更贵。4.3 估算误差的来源成本估算结果只是一个近似值不是账单金额。主要误差来源有token 数估计不准确用字符数乘系数或者用不同分词器算出的 token 数都会和实际值有偏差。缓存命中部分模型有 prompt 缓存输入命中缓存后价格更低。如果 API 不支持缓存价格参数估算值会偏高。自动重试请求失败后重试会产生额外成本。输出长度变化你预估输出 1000 token实际模型可能生成 1500 token账单就变了。所以我更建议把估算结果当成一个“预算水位线”而不是精确账单。比如预算上限是 100 美元估算到 80 美元时就要开始关注。5. 批量估算和 Agent 集成思路5.1 一次对比多个模型做模型选型时通常不是只看一个模型而是拿多个候选模型对比。你可以这样分批请求models [model-a, model-b, model-c] input_tokens 15000 output_tokens 3000 for model in models: try: info estimate_cost(model, input_tokens, output_tokens) print(model, info[estimated_cost_usd], info[within_context]) except Exception as e: print(model, failed, e)这里不建议一次性并发请求几十个模型。免费 API 通常有速率限制并发太高容易被限流。我一般会把并发控制在 3 到 5 个或者直接串行请求。跑完一批看结果再决定要不要提高并发。5.2 在 Agent 里按预算选择模型如果你的 Agent 需要根据任务动态选择模型可以把这个 API 当成一个决策前置服务。比如有一个日志分析任务预估输入 tokens 是 20000输出 tokens 是 2000。Agent 先向这个 API 查询几个候选模型过滤掉超出上下文窗口的再在剩下模型里选择成本最低或成本低于某个阈值的模型。代码逻辑大致是def select_model(input_tokens, output_tokens): candidates [model-a, model-b, model-c] available [] for model in candidates: info get_model_info(model) if input_tokens output_tokens info[context_window]: cost estimate_cost(model, input_tokens, output_tokens) available.append((model, cost)) if not available: return None return min(available, keylambda x: x[1])这种做法的好处是模型价格变化时不需要改动 Agent 代码因为价格数据集中在 API 端维护。坏处是多了一次网络请求所以缓存很重要。5.3 缓存与限流策略模型价格不是每秒钟都在变的因此没必要每次调用都请求外部 API。我一般会在本地做一层缓存模型列表缓存 6 小时。单个模型价格缓存 6 小时。成本估算结果缓存 1 小时key 用model input_tokens output_tokens。缓存能显著降低 API 调用量也能避免免费服务因为频率过高把你限制掉。如果 API 返回的响应头里有Retry-After或限流信息要按它的要求退避。6. 自建一个免费的同类 API 时要注意什么6.1 价格数据维护是重点如果你不想依赖外部公共服务也可以自己搭一个类似的 API。技术上不复杂一个 FastAPI 或 Flask 应用一个 JSON 文件或 SQLite 存储价格数据就够了。难的是价格数据的维护。不同模型的定价更新节奏不一样有的几个月不变有的会突然调整。我建议把价格数据单独放在一个 JSON 文件里方便人工更新和版本控制。结构大致这样{ models: [ { model: model-a, context_window: 8000, max_output_tokens: 2048, input_price_per_1k: 0.001, output_price_per_1k: 0.002, currency: USD, updated_at: 2025-06-01 } ] }你可以写一个脚本定期从官方价格页抓取也可以直接手动更新。对于个人项目来说手动更新更稳妥因为抓取逻辑很容易因为页面结构改版而失效。6.2 部署环境的资源要求这类 API 本身不涉及模型推理不需要 GPU。一个 1 核 CPU、512MB 内存的云主机就能跑起来。如果你用 Docker 部署镜像也可以做到很小。不过要注意如果服务面向公网最好加一层鉴权。最简单的做法是配置一个静态 API Key请求时校验Authorization头。不要完全裸奔否则会被别人恶意调用产生不必要的流量。6.3 日志、监控和配额自建服务也要看日志。我会在代码里记录每个请求的模型、输入参数、返回耗时和状态码。这样排查问题时能知道是参数问题、数据问题还是服务问题。配额方面如果只是内部使用不做严格限流问题不大。如果要开放给很多人用建议按 IP 或 API Key 做限流。实现方式可以是内存计数也可以用 Redis。对于小规模使用内存计数就够了。7. 常见问题与排查顺序7.1 返回的价格和自己查到的对不上这是最常遇到的问题。先别怀疑 API 坏了按这个顺序排查看updated_at判断数据更新时间是不是太旧。确认价格单位是每 1k tokens 还是每百万 tokens。确认币种是美元、人民币还是其他货币。确认是否包含缓存价格有些 API 默认返回标准价格不区分缓存命中。确认模型名称是否完全一致比如gpt-4o和gpt-4o-2024-11-20可能价格不同。如果这些都检查过还是不对那就需要去看 API 服务方的数据源说明。7.2 请求超时或一直返回 429、500请求超时可能原因网络问题本地到 API 服务不通先用curl测试。免费服务限流降低请求频率加缓存。请求体太大如果传了很长的文本而不是 tokens 数先改为只传 tokens 数。返回 429 说明触发限流这时不要一直重试等一段时间再请求。返回 500 一般是服务端问题可能是服务没起来、数据库连接失败、代码异常。如果是自建服务去看服务日志大多数问题都能在日志里找到。7.3 上下文窗口判断不准确有些 API 返回的context_window是模型最大总上下文但实际调用时输入过长会被系统自动截断或者报错。所以判断时要注意input_tokens output_tokens要小于context_window。如果 API 还返回max_input_tokens也要单独检查。预留 buffer比如实际使用不超过上限的 90%因为你估算的 token 数不一定精确。如果发现很多请求被判定为within_context: false建议先检查是不是把output_tokens设置得太大比如设成context_window的半量。对于普通问答输出 2000 到 4000 token 通常够用。7.4 成本估算结果波动大同一个模型、同样的输入输出估算结果不应该波动。如果波动大优先检查是不是 API 端价格数据被更新了或者你传的参数混用了不同的计数单位。还有一点有些估算接口会要求传百分比、温度、top_p 等生成参数这些其实不影响 token 数只影响实际输出长度。成本估算里这些参数可以忽略。8. 我个人的落地建议这类免费的 LLM 定价与成本估算 REST API真正落地时最值得花时间的不是第一个版本而是数据更新和容错逻辑。如果是个人项目先用现成的免费公共服务验证流程能跑通再考虑自建。如果是团队内部使用我更建议自建一个轻量服务把价格数据放在自己的代码仓库里可控性更强。但不管用哪种方式都要做缓存、超时和日志。我个人习惯是先跑通单条查询再做成本估算最后才接入 Agent 调度。不要让外部 API 成为主链路里的单点故障。如果服务不可用至少要有一套降级方案比如本地缓存上一次的价格数据。踩过几次坑之后我发现很多问题不是工具能力不够而是你自己没有把“查价格”和“算成本”这两件事分开也没有给上下文窗口留出余量。把这两点想清楚这个 API 用起来会顺手很多。