用 model=auto 控成本：不点名模型，改成设成本上限
本文介绍在 LLM API 聚合站中使用 model=auto 的实践思路：当你不想为每次请求手动挑选模型时，可以用成本上限来控制花费。文章解释适用场景、auto 在便宜与贵档间的取舍逻辑，以及如何通过账单记录核对 1.3 倍扣费。
什么时候用 model=auto 而不是点名模型
点名模型适合你已经知道要用哪个模型、并且任务对模型能力有明确要求的场景。但很多时候你其实不关心具体是哪个模型，你只关心两件事：这个任务能不能做好，以及别花太多钱。
在这些情况下，model=auto 比手动挑模型更省心：
- 批量任务：一次提交几百条内容做分类、抽取或改写，逐条挑模型不现实。
- 任务难度不确定：你无法预先判断某条输入是简单还是复杂，固定用贵模型会浪费，固定用便宜模型可能出错。
- 快速原型：还在验证产品逻辑，不想在模型选择上花时间。
- 成本敏感的长尾流量：用户请求量波动大，希望整体花费有可控的上限。
auto 在便宜档与贵档之间怎么表现
model=auto 的核心不是“永远用最便宜的”，而是“在你可以接受的成本范围内，尽量选一个能完成任务的模型”。
你可以把它理解成一个带预算约束的选择逻辑：
- 如果任务特征看起来简单，auto 倾向于走向便宜档的模型
- 如果任务特征更复杂，auto 会倾向选择能力更强、单价更高的模型
- 你设置的预算上限会成为一个约束：超过这个上限的模型不会被选中
这样做的结果是：简单请求省钱，复杂请求不硬省，整体花费更平滑。
便宜档的典型表现
适合结构化输出、短文本分类、简单摘要、关键词提取这类任务。响应通常更快，单次成本明显更低。
贵档的典型表现
适合需要多步推理、长上下文理解、复杂指令遵循、代码生成与调试这类任务。单次成本更高，但一次做对的概率更大，反而可能减少重试带来的额外花费。
如何设置成本上限
成本上限的表达方式通常是“单次请求最多花多少”。你可以根据任务类型设不同档位：
- 对成本极敏感：设一个偏低的上限，auto 基本只在便宜档里选
- 对质量有要求：把上限放宽，给 auto 留出选贵档模型的空间
- 混合场景：对同一批任务按优先级分组，重要请求给更高的上限
需要注意的是，成本上限是约束而不是目标。设得太低，复杂任务可能被塞进便宜模型，导致输出质量下降或需要人工返工。
事后如何对上 1.3 倍扣费
本站的计费规则是：按对应模型的官方价 ×1.3 扣费。使用 auto 时，日志里会记录本次实际调用的模型，你可以据此对账。
推荐的核对流程：
- 查看请求日志：确认每条 auto 请求实际落在了哪个模型上
- 按该模型的官方价计算基准成本：输入与输出 token 分开算
- 乘以 1.3：得到本站应扣金额
- 与账单实际扣费比对：检查是否有异常
如果你发现某些 auto 请求频繁落到贵档模型，可以调低上限，或者在调用时改回点名便宜模型。
auto 与手动选择如何配合
一个实用的思路是分层：
- 对明确知道用哪个模型的任务，直接点名，避免 auto 的额外不确定性
- 对不确定的任务，用 auto + 成本上限，让系统在预算内自己选
- 对成本极敏感的任务，用 auto + 很低的上限，把选择范围压到便宜档
这样既保留了 auto 的省心，又不会让整体花费失控。
常见误区
- 以为 auto 一定最便宜：auto 只是在你给定的预算内做选择，如果上限设得高，它也可能选贵模型。
- 以为 auto 一定质量最好：如果上限设得低，复杂任务可能被降档处理，质量会受影响。
- 不看日志：auto 的实际选择只有在日志里才能确认，定期查看有助于调整上限。
本文提到的计费倍率为本站通用规则（用户 ×1.3，贡献 Key 返 ×1.1/×1.2），具体金额以账单为准。