ChatGPT 如何降低成本｜附配置文件

在很多团队里，ChatGPT 或大模型 API 刚接入时，成本往往并不明显：每天几百次调用、每次几千 Token，看起来只是小钱。但随着业务规模扩大，客服、内容生成、知识库问答、代码辅助、数据分析等场景逐渐上线，账单会迅速增长。尤其是当系统没有做模型分层、上下文裁剪、缓存、限流和日志分析时，大量费用其实都花在了“没有必要的 Token”和“过度使用高规格模型”上。

本文将从实际工程角度，系统讲解如何降低 ChatGPT 使用成本，并附上一份可直接参考的配置文件，帮助你在保证效果的前提下，把大模型调用成本控制在合理范围内。

一、ChatGPT 成本主要来自哪里？

在谈降低成本之前，必须先搞清楚成本构成。无论你使用的是 OpenAI、Azure OpenAI，还是其他兼容 OpenAI API 的模型服务，费用通常都和以下因素有关：

1. 输入 Token 数量
2. 输出 Token 数量
3. 所选模型价格
4. 请求调用次数
5. 是否使用多轮上下文
6. 是否开启工具调用、检索增强或函数调用
7. 是否存在重复请求或无效请求

简单来说，大模型不是按“问题数量”收费，而是主要按 Token 收费。一个中文汉字通常会被编码成一个或多个 Token，英文、标点、代码、JSON 配置等也会占用 Token。你的 Prompt 越长、上下文越长、模型输出越长，成本就越高。

很多成本失控的问题，本质上都不是模型太贵，而是系统设计不够精细。例如：

• 每次用户提问都把完整历史对话传给模型；
• 简单分类任务也调用最高级模型；
• 提示词写得非常冗长，包含大量重复说明；
• 没有限制模型最大输出长度；
• 同一个问题被重复请求多次；
• 没有缓存常见答案；
• 知识库检索返回过多无关内容；
• 失败重试策略不合理，导致重复消费。

因此，降本的核心不是单纯换便宜模型，而是建立一套完整的“模型成本治理体系”。

二、优先使用模型分层策略

降低成本最有效的方法之一，就是不要所有任务都使用同一个高规格模型。

在真实业务中，并不是所有任务都需要最强模型。例如：

一个成熟的系统通常会采用“路由器模式”：先用低成本模型判断用户请求的类型和难度，再决定是否升级到更强模型。

例如：

• 用户问“订单怎么退款？”：普通模型即可；
• 用户让模型总结一段 300 字文本：小模型即可；
• 用户要求分析复杂合同风险：高端模型更合适；
• 用户要求生成一篇高质量商业方案：可使用中高端模型；
• 用户要求多步骤数学推理或复杂代码调试：建议使用高端模型。

这种策略可以显著减少高价模型的调用比例。很多团队在引入模型分层后，成本可以下降 30% 到 70%。

三、压缩 Prompt，减少无效 Token

Prompt 是大模型应用的核心，但很多 Prompt 写得过长、重复、无结构，导致每次请求都携带大量不必要内容。

例如，有些系统提示词会写成这样：

你是一个非常专业、非常认真、非常负责、非常有耐心的客服助手，你需要根据用户的问题认真分析、谨慎回答、保持礼貌、保持客观、保持积极……

这种写法可读性不错，但不够经济。如果业务量很大，每次请求都传入这类冗长提示词，会持续增加成本。更好的写法是压缩为结构化要求：

你是客服助手。
要求：
1. 简洁、准确、礼貌；
2. 只回答与产品相关的问题；
3. 不确定时提示转人工；
4. 禁止编造政策。

同样的约束可以用更少 Token 表达。对于系统提示词，建议遵循以下原则：

1. 删除情绪化、重复性描述
2. 把长句改为短句
3. 使用编号列表
4. 只保留模型必须遵守的规则
5. 把不常用规则放到业务代码中处理
6. 不要在每次请求中传入静态大段说明

如果某些规则可以通过程序实现，例如敏感词过滤、长度限制、格式校验，就不要全部交给模型完成。模型适合处理语义任务，但不适合承担所有工程逻辑。

四、控制上下文长度，不要无限传历史消息

多轮对话是 ChatGPT 的优势，但也是成本黑洞。

很多产品为了让模型“记住上下文”，会把用户从第一轮开始的全部对话都传给模型。刚开始成本不高，但随着对话轮数增加，每次请求都会重复支付前面所有历史消息的费用。

举个例子：

• 第 1 轮：输入 500 Token；
• 第 5 轮：输入可能变成 3000 Token；
• 第 20 轮：输入可能超过 10000 Token。

这意味着用户问一句很简单的话，系统也可能携带大量历史内容，造成成本浪费。

更合理的做法是：

1. 保留最近几轮对话

通常只保留最近 3 到 6 轮对话即可。对于客服、问答、普通助手类应用，大部分上下文依赖都发生在最近几轮。

2. 对旧对话做摘要

当历史消息过长时，可以把早期对话压缩成一段摘要，只保留关键信息，例如用户身份、偏好、已确认事实、未解决问题等。

示例：

历史摘要：
用户正在咨询企业版套餐，关注价格、数据安全和私有化部署。
已说明：支持年付发票；不支持免费私有化部署。
待回答：用户想了解是否支持 SSO。

这样比传入完整十几轮对话便宜得多。

3. 删除无意义消息

类似“好的”“谢谢”“继续”“嗯嗯”这类消息，在很多场景下可以不进入长期上下文。

4. 按任务重置上下文

当用户从“咨询退款”切换到“写一篇文章”时，旧上下文未必有价值。系统可以识别任务变化，自动开启新会话或减少历史上下文引用。

五、限制最大输出长度

输出 Token 也是收费的，而且很多时候输出比输入更容易失控。

如果你没有设置 max_tokens 或类似参数，模型可能输出比预期更长的内容。例如用户只是问“怎么退款”，模型却回答了 1000 字；用户只想要一个标题，模型却给出完整营销方案。

因此，必须根据业务场景设置合理的最大输出长度：

同时，在 Prompt 中明确输出要求：

请用不超过 150 字回答。
只输出 JSON，不要解释。
只返回一个分类标签。
请列出 3 点即可。

这类约束不仅能降成本，还能提高系统稳定性。

六、使用缓存减少重复调用

缓存是降本中最容易被忽视、但效果非常明显的手段。

在很多业务里，用户的问题高度重复，例如：

• “怎么退款？”
• “发票怎么开？”
• “支持哪些支付方式？”
• “如何联系客服？”
• “产品价格是多少？”
• “忘记密码怎么办？”

这些问题完全没必要每次都调用模型。可以使用缓存、FAQ、知识库或规则优先返回。

常见缓存策略

1. 精确匹配缓存

用户问题完全相同，直接返回历史答案。

2. 语义缓存

将用户问题转为向量，如果和历史问题语义相似度很高，则复用答案。

例如：

• “怎么申请退款？”
• “退款流程是什么？”
• “我想退钱怎么办？”

这几个问题语义相近，可以命中同一答案。

3. 模板缓存

对于固定业务流程问题，使用模板回答即可。

4. 模型结果缓存

对摘要、翻译、分类、关键词提取等确定性任务，可缓存输入文本哈希对应的输出。

缓存注意事项

缓存并不适合所有场景。例如价格、政策、库存、活动规则等变化频繁的信息，需要设置较短过期时间，或者与业务数据库实时查询结合。

七、优化知识库检索，避免塞入过多资料

很多企业会使用 RAG，也就是检索增强生成。流程通常是：

1. 用户提问；
2. 从知识库检索相关文档；
3. 把检索结果和问题一起传给模型；
4. 模型基于资料回答。

RAG 可以减少幻觉，提高准确性，但如果检索结果过多，也会导致输入 Token 飙升。

常见问题包括：

• 每次传入 10 篇文档；
• 每篇文档长度过大；
• 文档切分粒度不合理；
• 检索结果相关性差；
• 没有重排序；
• 没有去重；
• 把整篇制度文档直接塞进 Prompt。

优化建议如下：

1. 控制 Top K

一般先从 top_k=3 或 top_k=5 开始，不要动辄返回 20 条文档。

2. 控制每段长度

知识库切片建议控制在 300 到 800 中文字左右。太短会丢上下文，太长会浪费 Token。

3. 增加重排序

先用向量检索召回，再用 reranker 对结果排序，只把最相关的片段传给模型。

4. 去除无关字段

不要把文档 ID、创建人、更新时间、冗余标题、HTML 标签等无关内容全部传入模型。

5. 提前摘要长文档

对于很长的制度、合同、说明书，可以先做离线摘要或结构化抽取，减少在线请求负担。

八、用规则和程序替代部分模型能力

不是所有事情都应该交给 ChatGPT。

例如以下任务，用传统程序更便宜、更稳定：

• 判断字符串是否为空；
• 判断手机号格式；
• 判断订单状态；
• 查询物流信息；
• 判断用户是否登录；
• 敏感词基础过滤；
• 固定 FAQ；
• 根据数据库字段拼接回答；
• 简单数学计算；
• 固定表单校验；
• 权限判断。

模型应该被用在“语义理解、生成、总结、推理、改写”等任务上，而不是替代后端业务逻辑。很多成本高的系统，本质上是把本来几行代码能解决的问题，都交给模型处理了。

合理架构应该是：

用户请求
  ↓
规则判断 / 权限校验 / 缓存命中
  ↓
必要时调用小模型
  ↓
复杂任务再调用大模型
  ↓
结果校验 / 格式修复 / 安全过滤
  ↓
返回用户

这比“用户一说话就调用最强模型”要经济得多。

九、设置限流、预算和告警

降本不仅是技术优化，也需要运营治理。

建议从第一天开始就建立以下机制：

1. 用户级限流

例如：

• 免费用户每天最多调用 20 次；
• 普通用户每天最多调用 100 次；
• 高级用户根据套餐提升额度。

2. 接口级限流

防止某个接口异常循环调用模型。

3. 成本预算

按天、周、月设置预算上限。例如：

每日预算：100 美元
月度预算：2000 美元
超过 80% 告警
超过 100% 自动降级

4. 异常告警

需要监控：

• 请求量突然上升；
• 平均输入 Token 变长；
• 平均输出 Token 变长；
• 高价模型调用比例异常；
• 重试次数异常；
• 单用户消耗异常；
• 某个接口消耗异常。

5. 自动降级

当预算快用完时，可以自动执行：

• 高端模型切换为中端模型；
• 减少上下文轮数；
• 降低 max_tokens；
• 关闭非核心功能；
• 优先返回缓存答案；
• 对免费用户限制高成本任务。

十、降低失败重试造成的浪费

很多系统为了提升稳定性，会设置失败自动重试。但如果重试策略设计不当，也会带来额外成本。

例如，一次请求超时后立即重试 3 次，而模型实际上已经处理了请求，只是客户端没有及时收到响应。这样可能造成重复扣费和重复生成。

建议：

1. 设置合理超时时间；
2. 区分网络错误、限流错误、服务错误和业务错误；
3. 对可重试错误使用指数退避；
4. 避免大请求频繁重试；
5. 对幂等任务使用请求 ID；
6. 对流式输出做中断处理；
7. 记录每次重试的成本。

示例重试策略：

第 1 次失败：等待 1 秒
第 2 次失败：等待 3 秒
第 3 次失败：等待 8 秒
仍失败：返回降级提示或转人工

十一、使用流式输出改善体验，但不一定降低成本

流式输出可以让用户更快看到结果，提升体验。但要注意，流式输出本身并不必然降低 Token 成本，因为模型最终生成多少 Token，通常仍然会计费多少。

不过，流式输出有一个间接降本价值：如果用户发现回答方向不对，可以提前停止生成，从而减少后续输出 Token。对于长文生成、代码生成、报告生成等场景，这一点很有用。

建议在产品上提供“停止生成”按钮，并在后端支持中断请求。

十二、对模型输出做结构化约束

结构化输出不仅能提升系统可用性，也能降低重复调用成本。

如果模型输出格式不稳定，后端解析失败后可能再次调用模型修复，这会产生额外费用。比如你要求模型返回 JSON，但模型返回了说明文字加 JSON，系统解析失败，然后又请求一次“请修复 JSON 格式”，这就是浪费。

建议在 Prompt 中明确：

只输出合法 JSON。
不要输出 Markdown。
不要添加解释。
字段必须包含：intent、confidence、answer。

也可以使用 JSON Schema、函数调用或结构化输出能力，让模型直接返回更可靠的数据结构。

十三、记录 Token 日志，找到真正的成本来源

没有日志，就无法降本。

至少应该记录以下字段：

有了这些数据，就可以分析：

• 哪个功能最花钱；
• 哪类用户消耗最多；
• 哪些 Prompt 太长；
• 哪些接口输出过长；
• 缓存命中率是否足够；
• 高价模型是否被滥用；
• 哪些失败请求造成浪费。

很多团队做完日志分析后会发现，真正消耗预算的不是主业务，而是某个测试接口、某个后台定时任务、某个没有限制的长文本处理功能。

十四、附：成本优化配置文件示例

下面是一份可参考的 YAML 配置文件。你可以根据自己的业务改造，用于模型路由、限流、缓存、上下文控制、预算告警等。

# chatgpt-cost-config.yaml
# ChatGPT / LLM 成本优化配置示例

app:
  name: "ai-assistant"
  environment: "production"
  default_language: "zh-CN"

models:
  default: "gpt-4o-mini"
  fallback: "gpt-4o-mini"
  premium: "gpt-4o"
  cheap: "gpt-4o-mini"

  routing:
    intent_detection:
      model: "gpt-4o-mini"
      max_tokens: 80
      temperature: 0
    classification:
      model: "gpt-4o-mini"
      max_tokens: 50
      temperature: 0
    faq_answer:
      model: "gpt-4o-mini"
      max_tokens: 400
      temperature: 0.2
    summarization:
      model: "gpt-4o-mini"
      max_tokens: 800
      temperature: 0.3
    writing:
      model: "gpt-4o"
      max_tokens: 2500
      temperature: 0.7
    code_generation:
      model: "gpt-4o"
      max_tokens: 3000
      temperature: 0.2
    complex_reasoning:
      model: "gpt-4o"
      max_tokens: 2000
      temperature: 0.2

prompt:
  system_prompt_max_chars: 1200
  user_prompt_max_chars: 6000
  compress_static_prompt: true
  remove_redundant_instructions: true

  default_system_prompt: |
    你是企业智能助手。
    要求：
    1. 回答准确、简洁、礼貌；
    2. 不确定时说明无法确认；
    3. 禁止编造政策、价格和承诺；
    4. 涉及账号、订单、隐私问题时提示用户通过官方渠道处理。

context:
  max_history_messages: 8
  max_context_tokens: 6000
  summarize_when_exceed_tokens: 4000
  summary_model: "gpt-4o-mini"
  summary_max_tokens: 500
  ignore_short_messages:
    enabled: true
    min_chars: 4
    examples:
      - "好的"
      - "谢谢"
      - "继续"
      - "嗯"
      - "OK"

output:
  default_max_tokens: 800
  hard_max_tokens: 4000
  enforce_short_answer: true
  short_answer_max_chars: 300

cache:
  enabled: true
  type: "redis"
  ttl_seconds: 86400
  semantic_cache:
    enabled: true
    embedding_model: "text-embedding-3-small"
    similarity_threshold: 0.92
    ttl_seconds: 604800
  cache_features:
    faq_answer: true
    classification: true
    summarization: true
    writing: false
    code_generation: false

rag:
  enabled: true
  vector_store: "milvus"
  embedding_model: "text-embedding-3-small"
  top_k: 5
  rerank_enabled: true
  rerank_top_k: 3
  max_chunk_chars: 800
  max_context_chunks: 3
  remove_html_tags: true
  remove_duplicate_chunks: true
  include_metadata: false

rate_limit:
  enabled: true
  by_user:
    free:
      requests_per_day: 20
      max_tokens_per_day: 30000
    standard:
      requests_per_day: 200
      max_tokens_per_day: 300000
    premium:
      requests_per_day: 1000
      max_tokens_per_day: 2000000
  by_ip:
    requests_per_minute: 30
  by_api:
    requests_per_minute: 300

budget:
  enabled: true
  currency: "USD"
  daily_limit: 100
  monthly_limit: 2000
  alert_thresholds:
    - 0.5
    - 0.8
    - 0.95
  actions:
    when_daily_over_80_percent:
      reduce_max_tokens_percent: 30
      disable_long_writing_for_free_users: true
    when_daily_over_100_percent:
      downgrade_premium_model: true
      premium_model_to: "gpt-4o-mini"
      cache_only_for_faq: true

retry:
  enabled: true
  max_attempts: 3
  backoff_strategy: "exponential"
  initial_delay_ms: 1000
  max_delay_ms: 8000
  retry_on:
    - "timeout"
    - "rate_limit"
    - "server_error"
  do_not_retry_on:
    - "invalid_request"
    - "context_length_exceeded"
    - "authentication_error"

logging:
  enabled: true
  log_prompt: false
  log_response: false
  log_token_usage: true
  log_estimated_cost: true
  fields:
    - "request_id"
    - "user_id"
    - "feature"
    - "model"
    - "input_tokens"
    - "output_tokens"
    - "total_tokens"
    - "latency_ms"
    - "cache_hit"
    - "retry_count"
    - "estimated_cost"
    - "created_at"

safety:
  pii_masking: true
  content_filter: true
  manual_review_for_high_risk: true

十五、配置文件如何落地使用？

上面的配置文件不是简单摆设，而应该接入到你的服务端调用链中。

推荐落地流程如下：

读取配置文件
  ↓
接收用户请求
  ↓
判断用户套餐和限额
  ↓
检查缓存
  ↓
识别任务类型
  ↓
根据 routing 选择模型
  ↓
裁剪上下文
  ↓
检索知识库并控制片段数量
  ↓
调用模型
  ↓
记录 Token 和成本日志
  ↓
写入缓存
  ↓
返回结果

在工程实现上，可以把配置拆分为几个模块：

1. model_router：负责模型选择；
2. context_manager：负责上下文裁剪和摘要；
3. cache_manager：负责精确缓存和语义缓存；
4. budget_guard：负责预算控制和自动降级；
5. token_logger：负责记录 Token 消耗；
6. rag_retriever：负责知识库检索和重排序；
7. rate_limiter：负责用户和接口限流。

这样做的好处是，后续即使模型价格变化、业务功能增加，也可以通过修改配置快速调整，而不需要频繁改代码。

十六、一个简单的调用策略示例

假设用户问：

“我想申请退款，应该怎么操作？”

系统可以按如下逻辑处理：

1. 判断这是 FAQ 类型问题；
2. 查询缓存，发现有相似问题；
3. 如果缓存命中，直接返回退款流程；
4. 如果缓存未命中，从知识库检索退款规则；
5. 只取最相关的 3 个片段；
6. 使用低成本模型生成简短回答；
7. 设置 max_tokens=400；
8. 记录本次 Token 消耗；
9. 将答案写入缓存。

在这个流程里，根本不需要调用高端模型，也不需要传入完整历史对话。成本自然会低很多。

再看另一个问题：

“请帮我分析这份 20 页合同里有哪些风险点，并按严重程度排序。”

这类任务明显复杂，需要更强模型，也可能需要长上下文或分段处理。此时可以使用高级模型，但仍然要做成本控制：

• 分段读取合同；
• 先用小模型提取条款摘要；
• 再用高端模型综合分析；
• 控制输出结构；
• 限制最大输出长度；
• 对结果进行人工复核。

这就是“该省的省，该花的花”。

十七、常见误区

误区一：只要换便宜模型就能降本

便宜模型可以降低单次调用价格，但如果 Prompt 很长、上下文不裁剪、调用次数过多，成本仍然会很高。模型分层只是降本的一部分。

误区二：上下文越长效果越好

上下文太长不一定更好，反而可能引入噪音，让模型抓不住重点。高质量、短而准的上下文通常优于大量无关历史。

误区三：所有问题都要实时生成

很多标准问题完全可以用缓存或模板回答。实时生成适合个性化、开放式、复杂语义任务。

误区四：不记录 Token 也能优化成本

没有数据就只能凭感觉优化。真正有效的降本，一定依赖日志、监控和分析。

误区五：降本一定会牺牲效果

不一定。很多降本措施反而会提升效果，例如清理 Prompt、优化知识库、结构化输出、减少无关上下文。这些操作不仅省钱，也能让回答更稳定。

十八、建议的降本优先级

如果你现在已经上线了 ChatGPT 应用，但成本偏高，可以按下面顺序处理：

1. 先记录 Token 和成本日志
2. 找出最贵的功能和接口
3. 限制 max_tokens
4. 裁剪历史上下文
5. 加入缓存
6. 用小模型处理分类、意图识别、摘要等简单任务
7. 优化知识库检索 Top K 和切片长度
8. 设置用户限流和预算告警
9. 优化 Prompt
10. 建立自动降级策略

通常前五项就能带来明显效果。

十九、总结

ChatGPT 降低成本不是单点优化，而是一套系统工程。真正有效的方案，需要同时关注模型选择、Prompt 长度、上下文管理、输出控制、缓存机制、知识库检索、限流预算、失败重试和日志分析。

最核心的原则可以概括为四句话：

1. 简单任务不用贵模型。
2. 无关内容不要传给模型。
3. 重复问题不要重复调用。
4. 没有监控就没有优化。

对于企业应用来说，大模型成本控制并不是为了一味压缩开支，而是为了让 AI 能够稳定、长期、可规模化地运行。该使用高级模型的复杂场景要大胆使用，该用缓存、规则、小模型解决的场景也不要浪费预算。

如果你能把本文中的配置文件和策略落地到实际系统中，通常可以在不明显牺牲体验的情况下，大幅降低 ChatGPT 使用成本，并让整个 AI 应用更加可控、可靠和可持续。