最近这几天“DS涨价”“全平台DS价目表”这几个词频繁出现在技术群和产品群里。很多依赖大模型 API 做业务的团队第一反应是去查自己的账单随后开始焦虑如果上游价格上调我们这种把大模型当作核心功能的备考类、内容类应用到底该怎么活先说清楚本文的立场。为了避免引战我统一用“DS”来代指大模型 API 服务不特指某一家厂商。文中所有价格数字、模型名称都是示例目的是帮你建立一套可以自己填真实价目表的分析框架。我们要解决的不是“哪家便宜用哪家”的短期问题而是当价目表发生变化时你的技术架构能不能快速响应能不能继续把成本控制在合理范围内。这篇文章适合三类读者一是正在使用大模型 API 做产品的后端开发二是负责 AI 功能成本控制的技术负责人三是被业务方追问“涨价了怎么办”的研发同学。读完你会得到一套可落地的成本治理方案包含统一调用客户端、缓存设计、模型路由、账单统计的完整代码示例以及备考类应用的实际降本思路。1. 背景大模型API价格调整为什么会让下游应用紧张1.1 一个典型的AI原生应用成本结构先来看一个典型的基于大模型 API 的应用是怎么花钱的。假设你做了一个备考学习 App用户输入一道数学题系统把题目和提示词发给大模型大模型返回解析过程再展示给用户。表面上看一次请求只有几百毫秒好像没什么成本。但如果按 Token 计费来算情况完全不同。题目文本、提示词模板、历史对话、模型输出这些全部会转换成 Token。一次普通的题目解答输入可能消耗 500 到 1000 Token输出 800 到 1500 Token。当平台的日活用户达到几万人每人每天发起十几二十次请求时累计的 Token 消耗就非常可观。上游模型服务的价目表一旦调整你的成本不是线性变化而是跟着用量一起放大。更麻烦的是很多团队在早期做功能验证时只关注模型的回答质量根本没有统计单次请求的成本模型于是“涨价冲击”一来大家才发现自己连每类功能赚不赚钱都说不清楚。1.2 谁最受影响教育、内容、客服类应用并不是所有大模型应用都会因为价目表波动而紧张。那些一次调用能带来高客单价转化的业务比如法律文书生成、金融研报摘要成本占比相对较低。真正紧张的是“高调用量、低客单价、强交互”的应用。备考类应用就是典型代表。用户使用题库答疑、英语作文批改、口语对练这类功能时频率高、单次价值感低很多功能还是免费或低价提供给用户的。如果 API 价格上涨而产品又不能立刻收费那每一单都在亏损。标题里提到的“鲸考类”产品本质上就是这类依赖大模型做差异化的学习工具它们的共同问题是功能离不开大模型但订阅价格又无法随便涨。此外内容生成工具、智能客服、营销文案生成器也属于同一类。它们的特点是请求量大、重复度高、对模型的实时推理能力要求不是顶级因此有非常大的优化空间。1.3 本文能帮你做什么面对价目表波动最有效的应对不是立刻更换供应商而是先做三件事第一把成本结构看清楚知道每一笔钱花在哪个场景、哪个模型、哪类 Token 上。第二把可优化项落地缓存、路由、提示词压缩、用量限制全都要有代码层面的支撑。第三建立监控和预案让成本变成可观测、可预警、可回退的指标。下面我们就从价目表分析开始逐步搭建这套体系。2. 看懂价目表计价维度与费用计算框架2.1 按Token计费的基本公式大多数大模型 API 的计费模式是费用 输入 Token 单价 × 输入 Token 数 输出 Token 单价 × 输出 Token 数。输入和输出的单价通常不同输出一般更贵。如果你使用带上下文记忆的对话式接口每一次请求都会把之前的对话历史重新作为输入发送给模型所以输入 Token 会随着对话轮数增长。这也是聊天型应用成本不容易控制的原因之一。这里有一个很容易忽略的细节即使模型返回的内容很短只要你的系统将历史消息全部拼接在请求里输入 Token 就会持续膨胀。比如一个口语评测功能用户连续对话十轮后每次新请求都要把前面十轮的文本重新发送成本自然成倍上升。2.2 容易被忽略的附加计费项除了输入和输出 Token部分服务还有以下计费维度计费项说明对成本的影响缓存 Token命中了服务端 Prompt 缓存的 Token通常单价更低想要优化必须提高命中率否则成本偏高内容安全审核增加敏感词、图片审核接口每次请求额外产生费用按 QPS 或并发收费高并发场景下额外付费突发流量会造成成本波动模型版本切换不同版本模型单价差异很大官方推荐模型不一定是最便宜的这也解释了为什么“光看一条价格表”无法判断最终成本。真正要算的是你的实际用量分布和缓存命中情况。2.3 建立自己的“成本单价配置表”与其每次争论“某平台贵不贵”不如把价目表抽象成配置文件。这样当官方价格调整时你只需要修改配置再结合历史用量重新计算就能量化影响。下面是一个示例配置结构不是真实价格{ providers: { provider_a: { prompt_price_per_million: 2.0, completion_price_per_million: 8.0, cached_prompt_price_per_million: 0.2 }, provider_b: { prompt_price_per_million: 1.0, completion_price_per_million: 3.0, cached_prompt_price_per_million: 0.1 } } }把单价录入配置后你的成本计算模型就独立于任何一家厂商的报告可以随时拿真实账单来校准。3. 环境准备与项目结构3.1 运行环境本文示例使用 Python 3.10 以上版本需要安装以下依赖pip install requests不需要额外安装机器学习框架。我们重点演示如何封装调用、缓存结果、记录用量其中大部分功能只需要 Python 标准库加 requests 就能完成。数据库使用 SQLite方便本地快速验证。版本需要根据你的项目实际情况调整本文示例以常见环境为例重点演示配置思路。3.2 示例项目目录llm_cost_guard/ ├── llm_client.py # 统一大模型客户端 ├── cache.py # SQLite 结果缓存 ├── router.py # 模型路由规则 ├── billing.py # 用量记录与成本估算 ├── pricing_config.json # 价值目表配置 ├── demo.py # 演示主流程 └── logs/ # 日志目录这个结构对应了成本治理的四个核心模块统一入口、缓存、路由、账单统计。你可以把其中的逻辑抽到自己的项目里不需要照搬目录。3.3 准备一个OpenAI兼容的API服务示例代码会调用/chat/completions接口这是目前大多数大模型服务兼容的接口格式。你需要准备API KeyBase URL例如https://api.example.com/v1一个可用的模型名称如果还没有正式开通也可以先用本地兼容服务或模拟数据测试重点跑通流程。4. 实战构建AI调用成本治理四板斧4.1 统一客户端集中管理模型、超时和密钥很多项目最初的代码里每个业务线各自请求大模型 API导致模型名、超时时间、密钥分散在不同文件。一旦价格调整你想全局切换模型只能一个个改非常容易漏。先创建一个统一客户端把公共逻辑收敛到一起# 文件路径llm_cost_guard/llm_client.py import requests class LLMClient: def __init__(self, api_key: str, base_url: str, model: str, timeout: int 30): self.api_key api_key self.base_url base_url.rstrip(/) self.model model self.timeout timeout self.session requests.Session() self.session.headers.update({ Authorization: fBearer {api_key}, Content-Type: application/json }) def chat( self, messages: list, temperature: float 0.3, max_tokens: int 512, scene: str default, ): payload { model: self.model, messages: messages, temperature: temperature, max_tokens: max_tokens, } resp self.session.post( self.base_url /chat/completions, jsonpayload, timeoutself.timeout, ) resp.raise_for_status() data resp.json() usage data.get(usage, {}) content data[choices][0][message][content] return content, usage这里有几个关键点。第一所有请求都使用同一个 Session复用底层连接避免频繁创建连接带来的开销。第二把api_key、base_url、model收敛到构造参数里后续切换配置只需要改实例化代码。第三返回时不仅返回模型回答还返回usage对象这是成本统计的基础。4.2 结果缓存让重复请求不再重复计费对于备考类应用来说用户提问的重复率其实很高。同样是“请解释一下牛顿第二定律”可能几百个用户都在问。如果每次请求都消耗真实 API 费用就会造成巨大浪费。更合理的做法是把第一次请求的结果缓存起来后续相同请求直接读取缓存。下面实现一个基于 SQLite 的缓存缓存键由模型、消息、采样参数共同决定# 文件路径llm_cost_guard/cache.py import hashlib import json import sqlite3 from datetime import datetime, timedelta class SqliteCache: def __init__(self, db_path: str cache.db, expire_days: int 7): self.conn sqlite3.connect(db_path) self.expire_days expire_days self._init_table() def _init_table(self): self.conn.execute( CREATE TABLE IF NOT EXISTS llm_cache ( key TEXT PRIMARY KEY, response TEXT, model TEXT, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ) ) self.conn.commit() staticmethod def make_key(model: str, messages: list, temperature: float, max_tokens: int) - str: raw json.dumps( {model: model, messages: messages, temperature: temperature, max_tokens: max_tokens}, ensure_asciiFalse, sort_keysTrue, ) return hashlib.sha256(raw.encode(utf-8)).hexdigest() def get(self, key: str): row self.conn.execute( SELECT response, created_at FROM llm_cache WHERE key ?, (key,), ).fetchone() if not row: return None response, created_at row created datetime.fromisoformat(created_at) if datetime.now() - created timedelta(daysself.expire_days): self.conn.execute(DELETE FROM llm_cache WHERE key ?, (key,)) self.conn.commit() return None return response def set(self, key: str, response: str): self.conn.execute( INSERT OR REPLACE INTO llm_cache (key, response, created_at) VALUES (?, ?, ?), (key, response, datetime.now().isoformat()), ) self.conn.commit()实际开发中你可以把缓存键设计得更宽松一些。比如去掉temperature因为很多场景下温度对结果影响不大。还可以增加“同一题目的同义改写映射”等业务逻辑但第一版先保证精确命中。需要注意缓存并不适合所有场景。口语对练这种强实时、强个性化交互每个用户的内容都不一样精确缓存的价值不大。这时候应该把优化重点放在减少历史消息轮数上。4.3 模型路由按场景选择不同档位模型同一个大模型服务商通常会提供多个型号不同型号的价格差异很大。比如复杂的逻辑推理题需要高性能模型而普通的名词解释、段落润色用轻量模型即可。路由模块就是把这些规则集中起来避免业务代码到处写if判断。# 文件路径llm_cost_guard/router.py from dataclasses import dataclass dataclass class RouteResult: model: str reason: str class ModelRouter: def __init__(self, strong_model: str, lite_model: str): self.strong_model strong_model self.lite_model lite_model def route(self, scene: str, user_tier: str, complexity: str) - RouteResult: if scene reasoning or complexity in (hard, very_hard): return RouteResult(self.strong_model, 高复杂度推理) if scene in (chat, general): return RouteResult(self.lite_model, 通用对话) if user_tier premium: return RouteResult(self.strong_model, 付费用户优先保障效果) return RouteResult(self.lite_model, 默认使用轻量模型)这里的strong_model和lite_model在配置阶段传入比如router ModelRouter(strong_modelds-pro, lite_modelds-lite)这里再次强调ds-pro和ds-lite只是占位符你需要替换成当前供应商实际可用的模型名。路由规则的粒度可以根据业务调整比如增加“题目类型”“用户会员等级”“请求来源渠道”等维度。路由的核心价值在于不需要所有请求都跑最强模型。对大部分高频低价值请求用低成本模型就能满足用户需求。4.4 用量记录与成本估算账单不再是一笔糊涂账很多团队直到收到月度账单才发现成本超支。原因是每次调用返回的usage没有落地事后无法复盘。下面设计一个简单的用量记录器把每次请求的 Token 信息写入 SQLite并支持按天估算成本# 文件路径llm_cost_guard/billing.py import sqlite3 from datetime import date class BillingRecorder: def __init__(self, db_path: str billing.db): self.conn sqlite3.connect(db_path) self.conn.execute( CREATE TABLE IF NOT EXISTS usage_log ( id INTEGER PRIMARY KEY AUTOINCREMENT, model TEXT, scene TEXT, prompt_tokens INTEGER, completion_tokens INTEGER, cached_tokens INTEGER, created_at TEXT ) ) self.conn.commit() def record( self, model: str, scene: str, prompt_tokens: int, completion_tokens: int, cached_tokens: int 0, ): self.conn.execute( INSERT INTO usage_log (model, scene, prompt_tokens, completion_tokens, cached_tokens, created_at) VALUES (?, ?, ?, ?, ?, ?) , (model, scene, prompt_tokens, completion_tokens, cached_tokens, date.today().isoformat()), ) self.conn.commit() def daily_usage(self, day: str None): day day or date.today().isoformat() rows self.conn.execute( SELECT model, SUM(prompt_tokens) as prompt_tokens, SUM(completion_tokens) as completion_tokens, SUM(cached_tokens) as cached_tokens, COUNT(*) as request_count FROM usage_log WHERE created_at ? GROUP BY model , (day,), ).fetchall() return rows在接入时我们可以在统一客户端里增加一个回调让每次请求成功后自动记录# 文件路径llm_cost_guard/llm_client.py增加记录逻辑 # 这段代码是在原有 LLMClient 基础上补充的调用示例 from billing import BillingRecorder billing BillingRecorder(billing.db) router ModelRouter(strong_modelds-pro, lite_modelds-lite) client LLMClient( api_keyyour-api-key, base_urlhttps://api.example.com/v1, modelds-lite, ) route router.route(sceneqa, user_tierfree, complexityeasy) client.model route.model messages [ {role: system, content: 你是一个备考辅导助手回答要简洁。}, {role: user, content: 什么是牛顿第二定律}, ] content, usage client.chat(messages, sceneqa) cached_tokens usage.get(prompt_tokens_details, {}).get(cached_tokens, 0) billing.record( modelclient.model, sceneqa, prompt_tokensusage.get(prompt_tokens, 0), completion_tokensusage.get(completion_tokens, 0), cached_tokenscached_tokens, )这里需要注意不同厂商返回的prompt_tokens_details结构不完全相同。有的返回cached_tokens有的没有。上面代码已经用get做了默认值兜底避免因为字段缺失崩溃。接入完成后你只需要定期查看billing.db的数据就能知道每天各场景消耗了多少 Token。再结合 2.3 节的价格配置可以很方便地算出成本。这个流程如果搭配 Grafana 或 Prometheus还可以做实时监控不过第一版用 SQLite 已经足够。4.5 完整演示入口最后给一个可运行的演示入口把以上模块串起来# 文件路径llm_cost_guard/demo.py from llm_client import LLMClient from cache import SqliteCache from router import ModelRouter from billing import BillingRecorder def main(): cache SqliteCache(cache.db, expire_days7) billing BillingRecorder(billing.db) router ModelRouter(strong_modelds-pro, lite_modelds-lite) client LLMClient( api_keyyour-api-key, base_urlhttps://api.example.com/v1, modelds-lite, ) messages [ {role: system, content: 你是一个备考辅导助手。}, {role: user, content: 解释一下牛顿第二定律。}, ] cache_key SqliteCache.make_key( modelclient.model, messagesmessages, temperature0.3, max_tokens512, ) cached cache.get(cache_key) if cached: print(命中缓存返回缓存结果) print(cached) return route router.route(sceneqa, user_tierfree, complexityeasy) client.model route.model content, usage client.chat(messages, sceneqa) cache.set(cache_key, content) cached_tokens usage.get(prompt_tokens_details, {}).get(cached_tokens, 0) billing.record( modelclient.model, sceneqa, prompt_tokensusage.get(prompt_tokens, 0), completion_tokensusage.get(completion_tokens, 0), cached_tokenscached_tokens, ) print(模型回答, content) if __name__ __main__: main()这个演示流程完整覆盖了先查缓存再走路由选模型最后调用 API 并记录用量。如果在真实项目中使用你还需要补充日志和异常处理。5. 面向备考类应用的降本方案前面是通用技术方案这一节专门分析“鲸考类”产品在实际业务中的具体降本策略。我们不讨论具体某家平台而是以备考类应用最常见的三个功能场景为例。5.1 题库答疑场景题库答疑的特点是“问题相对固定答案相对标准”。用户问“这个不定积分怎么解”“这句话的语法结构是什么”本质上都是对已有知识点的重复提问。这类场景最适合使用缓存和预生成方案。你可以把高频问题提前用大模型生成答案人工审核后存入知识库。用户命中知识库时直接返回产品自有内容完全不消耗 API 费用。只有当知识库无法命中时才实时调用大模型。从技术角度看你还需要注意提示词中不要携带冗长的默认上下文。很多团队在系统提示词里放了一大段“你是多智能学习助手请用生动语言解释……”这会导致每次请求的输入 Token 增大。对答疑场景建议系统提示词尽量短控制在 200 Token 以内。5.2 作文批改场景作文批改对模型能力要求高不太适合用轻量模型直接降级但可以从用量角度优化。一篇英语作文可能 300 词用户还要选择“语法纠错”“逻辑分析”“得分预测”等多个维度。如果系统一次性把全部维度都请求输出 Token 会非常庞大。更合理的做法是拆分维度用户选什么维度就调用对应功能的接口。另外批改结果中的固定模板文案如开头语、提分建议列表样式可以放在前端拼接不必全部由模型生成。这样既不影响用户体验也能减少每次请求的输出长度。5.3 口语对话场景口语对话是成本消耗较大的场景因为每次交互都要把多轮历史和语音转文本结果一起发送。应对思路是控制上下文长度只保留最近两到三轮对话而不是全部历史。如果需要长期记录用户口语水平可以把总结存到业务数据库下一次请求只携带摘要。这样做的理由是大模型对话接口对历史消息量敏感输入 Token 按全量计算。为了保持对话连贯性把之前内容压缩成一段摘要通常是最划算的方式。5.4 产品层面的成本控制配额、会员、按次付费技术优化解决的是“效率”问题产品策略解决的是“回本”问题。涨价之后如果产品机制不调整技术再优化也难以长期覆盖成本。一个常见做法是把大模型功能分级。免费用户每天只能体验几次实时问答超出后第二天恢复付费会员解锁更多次数和高性能模型。这样做有两个好处一是控制恶意刷量二是让真正有强需求的用户为成本买单。另一个做法是针对“批发型”请求做异步化处理。比如批量生成 1000 道题的解析不要求实时返回可以放在后端队列里用低峰时段慢慢跑配合限流避免触发高并发的额外费用。6. 常见问题与排查思路6.1 缓存命中率一直很低问题现象常见原因解决思路缓存命中率低缓存键精确匹配用户提问多一个字就 miss将缓存键适当模糊化过滤空格、标点缓存命中率低每次温度等采样参数不同对不影响结果的请求固定 temperature缓存命中率低对话消息包含动态时间戳构造 key 时忽略非核心字段另外统计命中率时要注意并不是所有请求都值得缓存。实时性要求高的口语对练命中率低是正常现象不要为此强行改造缓存逻辑。6.2 账单仍然暴涨如果你完成了缓存、限流、路由但账单还是暴涨可以按下面顺序排查。先看billing.db的统计找出消耗 Token 最多的场景和模型。然后检查代码链路确认是否有重试机制导致重复请求。很多官方 SDK 默认会在超时后自动重试如果 API 响应超时但实际上游已经生成结果重试就会产生两次费用。解决办法是把重试次数降到 1并开启幂等键如果服务支持。再看是否存在批量任务把并发打满。部分服务对高并发是额外计费的建议在批量任务中增加速率限制。6.3 模型路由后效果变差轻量模型确实可能在复杂推理上表现不如强模型。路由策略上线后一定要先做小流量对比。建议记录每个请求的route.reason、用户反馈、是否转人工用数据来判断哪些场景可以放心使用低成本模型哪些场景需要调整回强模型。如果某个场景效果波动大可以给该场景单独设置“最低模型档位”避免路由规则把请求降级到不合适的模型。6.4 无法准确统计Token不同厂商、不同接口返回的 token 结构可能不同。有的只在响应里返回prompt_tokens和completion_tokens有的返回按模块细分的字段。不要假设所有服务都一样。建议在统一客户端里增加一个解析函数专门把厂商返回的 usage 转换为内部统一的数据结构。如果厂商某个字段缺失使用默认值并记录日志方便后续校准。7. 最佳实践把成本治理从“救火”变成“日常”7.1 为每个场景设置预算上限从这次涨价的教训来看最实用的经验是不要让调用量无限制增长。你可以在代码里为每个场景设置每日 Token 预算。预算耗尽后返回友好提示或降级到本地规则引擎。以下是一个简单的预算控制伪代码思路# 预算控制核心逻辑需要根据实际项目改造 daily_budget { qa: 5_000_000, writing: 2_000_000, oral: 1_000_000, } used_tokens billing.daily_usage() remaining daily_budget[qa] - used_tokens[0].prompt_tokens - used_tokens[0].completion_tokens预算值需要根据业务数据测算不能拍脑袋。可以先跑一周统计各场景日均消耗再把预算设置为日均消耗的 1.2 到 1.5 倍。7.2 定期复盘价目表和用量价目表调整往往是突发性的但我们可以把“成本复盘”变成固定动作。建议每周查看一次各场景的 Token 消耗重点观察三个指标缓存命中率、平均单次输入 Token、平均单次输出 Token。如果平均输入 Token 持续上涨说明提示词或上下文管理出了问题。如果缓存命中率下降说明有新增的动态内容进入了缓存键。7.3 多供应商与降级预案不要把所有业务都绑定在一个模型服务上至少在架构层保留切换能力。本文的统一客户端已经把base_url和model变成参数这就是第一步。更进一步可以维护多个厂商的 API 配置当主供应商价格上调或服务不可用时自动切换到备用供应商。这里需要注意合规与数据边界。接入新供应商前要确认你的业务数据是否可以发送到对方的服务节点尤其是用户隐私内容需要做脱敏处理并获得必要的授权。7.4 日志与可观测性建设AI 应用的成本治理离不开日志。建议每个请求都输出结构化日志包含场景、模型、prompt_tokens、completion_tokens、缓存是否命中、耗时、用户等级。这样不仅方便排查成本问题也能用来分析用户体验。如果你的团队已经有 ELK 或 Loki可以把日志接入现有体系。没有的话先用 SQLite 记账也能满足大多数中小项目需求。8. 总结与下一步行动这次价格调整事件给了我们一个很好的提醒大模型 API 的价目表不会永远不变依赖单一模型、单一计价方案的应用本质上是在裸奔。通过本文的梳理你应该已经掌握四个核心动作用统一客户端收敛模型调用用结果缓存降低重复计费用模型路由控制单次成本用账单统计看清成本结构。下一步建议你回到自己的项目里做三件事。第一把现有代码中散落的大模型调用全部收敛到一个封装层。第二给高频场景加上缓存和预算上限。第三整理一份真实的价目表配置结合历史用量重新估算成本。只有把成本治理纳入日常开发流程下次再看到“涨价”相关的讨论时你才能从容应对。具体怎么设计缓存命中维度、怎么调整模型路由规则需要结合你的业务数据持续迭代。可以先从最消耗成本的一个功能开始试点跑通后再逐步推广。