账户只剩 5 USDC 时怎么选模型：先算再选

账户里只剩几 USDC 的时候，选模型这件事会突然变得具体起来。以前可能随手就选最贵的那个，现在得先想想这笔钱够跑多少次请求。这篇文章提供一个简单的决策顺序：先估算 token 量，再按 1.3 倍规则算清各模型的成本，最后才决定用哪个模型。

第一步：估算你的任务需要多少 token

在比较模型之前，先搞清楚一次典型请求大概会消耗多少 token。你不需要精确到个位数，但要对量级有个概念。

• 输入 token：你发送的提示词、上下文、示例、历史对话，全部计入输入。如果每次都带一段长系统提示或几轮对话历史，输入量会明显上升。
• 输出 token：模型生成的回复长度。总结、翻译、代码生成、长文写作，输出量差异很大。
• 调用次数：你是只跑一次，还是要批量处理几十上百条？总成本是单次成本乘以调用次数。

一个实用的做法是：拿一条最有代表性的输入，手动数一下大概字数（中文按字、英文按词粗略折算成 token），再乘以你预期的调用次数。这样你就得到了一个粗略的 token 总量区间，而不是一个拍脑袋的数字。

第二步：按 1.3 倍规则换算实际单价

本站的计费方式是：按模型官方价格乘以 1.3 扣费。这意味着你在比较模型时，不能只看官方标价，而要把每个候选模型的官方单价都乘以 1.3，得到你实际支付的单价。

具体做法：

1. 列出你考虑的几款模型（比如 Claude、GPT、DeepSeek、Qwen、GLM、Kimi 中的几个）。
2. 找到它们各自的官方输入/输出单价。
3. 分别乘以 1.3，得到实际单价。
4. 用第一步估算的输入/输出 token 量，分别乘以实际单价，得到单次请求的估算成本。
5. 再乘以调用次数，得到总成本。

注意输入和输出通常单价不同，要分开算。很多模型输出比输入贵，如果你的任务输出很长，输出单价的影响会更大。

第三步：把候选模型按成本排队

算完之后，你手里应该有一张表：每个模型对应一个总成本估算。把它们从低到高排一下。

这时候你会发现，有些模型虽然单价看起来不低，但因为你的输出很短，实际总成本并不高；有些模型单价便宜，但你需要跑很多次，累计起来反而更多。成本排序和单价排序不总是一致，这就是为什么要先算总量再比价。

第四步：结合任务类型做最终选择

成本不是唯一因素。在预算允许的范围内，还要看任务对模型能力的要求。

• 简单、重复性任务（分类、抽取、格式转换、简单问答）：优先选成本低的模型，把预算留给更难的任务。
• 需要推理或代码的任务：如果低成本模型反复出错，重试和人工修正的代价可能超过直接用好一点的模型。
• 长上下文任务：输入 token 会很大，要特别关注输入单价，而不是只看输出。
• 创意或长文写作：输出 token 多，输出单价是关键。

一个稳妥的策略是：先用低成本模型跑通流程，确认提示词和输出格式没问题，再决定是否切换到更强的模型。这样即使预算少，也不会因为反复调试而烧掉太多余额。

第五步：留出余量，避免中途断供

账户只剩几 USDC 时，最怕的是跑到一半余额不够。建议在估算总成本后，留出一定比例的余量（比如 20%–30%），用来应对重试、输出比预期长、或者临时多跑几条的情况。

如果发现预算不够覆盖整个任务，可以考虑：

• 缩小单次请求的范围，分批处理。
• 换用更便宜的模型完成大部分工作，只把关键部分交给更强的模型。
• 精简提示词，减少不必要的上下文，直接降低输入 token。

一个可复用的检查清单

下次余额紧张时，按这个顺序过一遍：

1. 这个任务大概要发多少 token、收多少 token、跑多少次？
2. 候选模型的官方单价是多少？乘以 1.3 后是多少？
3. 每个候选模型的总成本估算分别是多少？
4. 按成本排序后，哪些模型在预算内？
5. 任务对能力的要求是什么？低成本模型能不能胜任？
6. 留了多少余量？

先算再选，不是为了抠每一分钱，而是为了让有限的余额覆盖尽可能多的有效工作。