做 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 定价、上下文窗口和成本估算的内容就完整了。这篇文章不只是一份接口说明书更希望你理解它背后的工程思路把易变的数据抽出来把稳定的计算逻辑沉淀下来。接下来你可以先从最小示例开始接入一个真实的数据源跑通模型列表获取和成本计算再逐步加入缓存、模型路由和预算告警。建议先收藏等真正做成本治理的时候再翻出来对照着实践。