摘要：本文面向已经把 AI 功能接入业务系统的开发者，围绕大模型调用成本治理展开：如何按用户、功能、模型和时间拆账；如何设置 Token 预算；如何用缓存、限流、超时、降级降低浪费；如何设计日志字段，让费用问题可以被定位和复盘。

开篇：成本失控通常不是模型太贵，而是调用不可见

很多 AI 应用刚上线时，团队最关心回答效果。等用户量上来，账单开始变高，大家才发现一个更现实的问题：到底是谁花掉了这些钱？

如果只能看到平台总账单，优化空间非常有限。你不知道哪个功能最贵，不知道哪个用户调用异常，不知道哪个 Prompt 输出过长，也不知道某次代码改动是否让费用突然上升。

所以成本治理的第一步不是立刻换便宜模型，而是把调用变得可观测。看清楚钱花在哪里，才知道该优化哪里。

一、先定义成本维度，不要只记总 Token

最少要记录四个维度：用户、功能、模型、时间。用户维度用于分账和风控，功能维度用于产品优化，模型维度用于比较性价比，时间维度用于发现异常峰值。

如果是企业内部系统，还可以增加部门、项目、环境、调用来源。如果是 SaaS 产品，还要记录套餐、客户 ID、请求 ID 和业务订单号。

这些字段看起来琐碎，但后面排查费用时非常关键。没有维度的总账单，只能让团队知道“花多了”，不能告诉团队“为什么花多”。

二、每个功能都应该有 Token 预算

很多成本问题来自没有预算。比如一个摘要功能，本来预期输入 3000 token、输出 500 token，结果用户上传超长文档，模型输出又没有限制，一次请求可能变成预期的十几倍。

我的做法是给每类功能设置预算：最大输入长度、最大输出长度、最大重试次数、是否允许高价模型、是否允许长上下文。

预算不是为了限制体验，而是为了让系统行为可预期。超过预算时，可以提示用户拆分文档，或者进入异步任务，而不是直接把超长内容丢给模型。

三、缓存是最容易被忽略的省钱手段

很多 AI 请求并不是每次都需要重新生成。比如固定 FAQ、同一份文档的摘要、相同参数的分类任务、重复的翻译片段，都可以做缓存。

缓存的关键是确定缓存键。只用用户输入做 key 可能不够，还要考虑模型、Prompt 版本、知识库版本、语言、输出格式等因素。否则 Prompt 改了，旧答案还被拿出来用，会造成隐性错误。

缓存命中率不用一开始很高，只要把高频、低变化的任务缓存起来，就能明显降低费用和延迟。

四、限流不是只防攻击，也是在保护账单

限流经常被理解成防刷，但在 AI 应用里，它还有一个很实际的作用：保护成本。

比如用户连续点击“重新生成”、前端轮询写错、队列任务重复提交、第三方回调异常重试，都可能造成短时间大量调用。没有限流，这些问题会直接反映到账单上。

建议至少做三层限制：用户级每日额度，功能级频率限制，系统级并发上限。这样即使某一层出问题，也不至于影响全局。

五、重试要克制，失败也有成本

很多人写接口时习惯失败自动重试三次。普通接口这样做问题不大，但大模型调用的重试可能意味着重复消耗 Token 和时间。

重试策略应该区分错误类型：网络抖动可以短暂重试，参数错误不应该重试，内容过长应该截断或提示，限流错误应该退避等待。

更重要的是记录重试次数。否则账单高了以后，你可能查不到到底是正常用户请求多，还是失败重试把成本放大了。

六、日志字段要为排查账单服务

一条可用的调用日志，至少应该包含 request_id、user_id、feature、model、prompt_tokens、completion_tokens、latency_ms、status、error_type、retry_count、created_at。

如果有多模型路由，还要记录 route_reason 和 provider/channel。这样才能知道某个时间段是不是因为路由切换到了高成本模型。

隐私方面要注意：不建议默认保存完整用户输入。可以保存摘要、哈希、脱敏后的关键字段，或者只在排障窗口临时开启更详细日志。

七、报表要服务决策，而不是堆图表

成本报表不需要一开始很复杂，先回答几个问题就够了：今天花了多少钱？哪个功能花得最多？哪个用户异常？哪个模型单次平均费用最高？缓存命中率是多少？失败重试占比是多少？

这些指标能直接指导动作：是否调整模型，是否压缩 Prompt，是否增加缓存，是否给某个功能设置异步任务，是否需要给客户调整套餐。

报表的价值不是展示数据，而是让团队知道下一步该改什么。

一个最小调用日志表设计

下面是一个简化版表结构。实际项目可以根据业务扩展，但核心字段建议保留。

CREATE TABLE llm_call_log (
    id BIGINT PRIMARY KEY,
    request_id VARCHAR(64) NOT NULL,
    user_id VARCHAR(64),
    feature VARCHAR(64) NOT NULL,
    model VARCHAR(128) NOT NULL,
    provider VARCHAR(64),
    prompt_tokens INT DEFAULT 0,
    completion_tokens INT DEFAULT 0,
    total_tokens INT DEFAULT 0,
    latency_ms INT DEFAULT 0,
    status VARCHAR(32) NOT NULL,
    error_type VARCHAR(64),
    retry_count INT DEFAULT 0,
    cache_hit BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP NOT NULL
);

CREATE INDEX idx_llm_cost_feature_time
ON llm_call_log(feature, created_at);

CREATE INDEX idx_llm_cost_user_time
ON llm_call_log(user_id, created_at);

我的实践记录

我在整理这套成本治理思路时，也把部分实践记录放在留言回复中。这里仍然只作为观察样例：当一个系统开始管理多模型调用时，渠道、令牌、额度、日志、价格和监控这些维度会自然出现。

关键不是选择哪种实现方式，而是让成本能够被拆解、被定位、被优化。否则 AI 功能越受欢迎，团队越可能被账单反噬。

结尾：成本控制是 AI 产品化的一部分

大模型应用上线后，成本不是财务问题，而是工程问题。输入多长、输出多长、失败怎么处理、缓存怎么命中、日志怎么记录，都会影响最终账单。

如果你正在做 AI 应用，可以在评论区说说：你现在最想优化的是 Token 消耗、缓存命中率、模型路由，还是用户额度？这篇文章有帮助的话，可以点赞、收藏，后面我继续整理更细的成本报表模板和限流策略。