很多人选智谱是在「按量付一点不心疼」和「包月看着更划算」之间摇摆，真到掏钱时又拿不准。这篇不讲模型本身，只讲一件事：先把自己的用量摊成一个月，再拿官方两边的口径对齐，用一张折算表把结论算出来。算不出来的情况也给判断线。
准备上智谱的个人开发者，常见纠结点就一个：按量付一点不心疼，包月看着又更划算，真要掏钱时反而拿不准。这篇不讲模型能力，只讲怎么把自己的用量摊成一个月，再拿官方两边的口径对齐，用一张折算表把结论算出来。算不出来的情况，也给你一条判断线。
先把预期放正：没有任何一种付费方式对所有用法都更省，省不省取决于你的用量结构和波动幅度，而不只是月总量。所以下面四步不是给你一个标准答案，而是给你一套自己算出答案的流程。
第一步：把两种口径对齐，别拿错尺子
- 按量口径
- 按实际消耗的输入、输出、缓存三档分别计价，用多少结多少，账单随用量浮动
- 订阅口径
- 固定周期付一笔费用，换一个周期内的额度，超出后按套餐规则处理
- 对齐方式
- 把两边都换算成「我这一个月大概花多少」，而不是比较单价数字本身
到 /official-api/providers/zhipuai 看当前按量价格基准，到 /coding-plans/zhipu-coding-plan-pro 看个人套餐的额度口径。两页的计量单位不同，直接把单价和月费放一起比是没有意义的，必须先各自乘以你的用量。动笔前顺带看一眼 /price-watch，确认价格近期有没有调整。
- 额度是否包含缓存命中部分，含与不含对折算结果影响很大
- 额度是否覆盖输入输出全部档位，只覆盖一档的话另一档还是要按量掏钱
- 订阅常带限速、并发上限、可调模型范围这类附加约束，按量一般没有；这两项不写进表里，便宜的一方可能根本用不了
- 如果连自己一个月用多少 token 都没概念，先到 /tools/token-price-calculator 把单次任务换算出来再回来
第二步：先估自己的月用量，再谈哪边便宜
用量估算比价格对比更容易出错，也更容易被忽略。建议按任务类型分开估：日常问答、翻译这类输入多输出少；写代码、写长文这类输出占比高。两种结构的每千 token 折算成本不同，最后哪边省可能正好相反。估算方法可以参考 /token-estimate-quick-guide。
| 用法类型 | 用量特征 | 估算时注意 |
|---|---|---|
| 偶尔问答翻译 | 总量小、不固定 | 按周记录乘四，别按峰值估 |
| 日常写代码 | 输出占比高 | 输出档单价权重要放大 |
| 批量跑任务 | 总量大、时间集中 | 看的是峰值月，不是平均月 |
| 多个项目混用 | 波动大、难预测 | 留两三倍波动空间再对比 |
- 记一周真实数据把每天的调用次数、平均输入长度、平均输出长度记下来，不要凭印象，记完乘以四得到月度基线
- 按结构分类把记录按问答、写代码、批量任务分开，看看哪一类占了大头，占比最高的那一类决定结论方向
- 加上波动系数项目冲刺月的用量可能是平时的两三倍，用一个高值月和一个低值月分别算一遍，看结论会不会翻转
- 低估用量的后果不对称：包月买小了频繁超额，买大了白交钱；按量则只是账单变高
- 如果你只在个别项目上偶尔调用，用量基线本身就不可靠，这时讨论包月通常没有意义
- 记录周期别太短，只记一两天容易把偶然高峰当成常态
第三步：折算对比，找自己的盈亏平衡点
把按量月支出和订阅月费放进同一张表，按月用量从低到高扫一遍，两条线相交的地方就是你的盈亏平衡点。低于交点按量省，高于交点订阅省。注意所有数字都要用当时的官方值，去 /official-api/providers/zhipuai 和 /coding-plans/zhipu-coding-plan-pro 现查现算，别用记忆里的旧数。
| 月用量档位 | 按量月支出 | 订阅月费 | 结论方向 |
|---|---|---|---|
| 低档（偶尔用） | 按用量线性增长 | 固定不变 | 交点以下，按量通常更省 |
| 中档（接近交点） | 开始接近月费 | 固定不变 | 差距一两成内，优先按量 |
| 高档（稳定跑批） | 明显高于月费 | 固定不变 | 交点以上，订阅通常更省 |
| 极端波动档 | 峰值月远超均值 | 固定不变 | 看峰值月能否被额度接住 |
- 交点附近不要急着定：两边差距在一两成以内，优先选按量，因为少了额度限制和迁移成本
- 什么情况下不适用：用量小且不固定，或只在个别项目偶尔用，订阅基本不划算
- 反过来的情形：每天固定跑批、长期挂编程助手，用量平稳且偏高，包月通常更稳
- 价格和额度都会变，动笔前到 /price-watch 看有没有调整，老文章里的数字不能直接用
落地清单：选完还要确认这几件事
决定买哪种只是第一步，下面这几项不确认，省下来的钱可能从别处漏走。个人开发者也别跳过，条款类的东西出事才看就晚了，相关判断线可以参考 /refund-withdrawal-terms。
- 确认付费方式、发票开具条件与退款条款，尤其是年付和自动续费
- 确认额度重置周期与重置时点，跨月用量的习惯要跟着调整，别在重置前一天把额度跑空
- 确认套餐能调的模型范围是否覆盖你实际要用的那几个，别为省钱换来一个用不上的档
- 确认超出额度后的处理方式：是直接拒绝、降级，还是按量叠加计费，这三种对你账单的影响完全不同
- 小额验证按量先充一小笔跑几天看真实账单；订阅先看有没有短期档或月付档，别一上来按年付
- 设用量提醒在自己的调用脚本或控制台里设一个用量阈值提醒，包月和按量都建议设，避免月底才发现超了
- 一个月后复盘一个月后拿实际账单和当初的估算对比，偏差超过预期就重新折算一次，别把一次选择当永久结论
折算的意义不是找出永远更便宜的那一边，而是让你知道自己的用量落在哪个区间、这个区间该选谁。下一步把按量基准和套餐额度两个页面的当前数字抄下来，填进上面的折算表，算出你自己的交点；顺便去价格追踪页确认近期有没有调价，避免用旧数做错决定。→
常见问题
我用量不大，是不是直接按量就行？
多数情况下是。用量小且波动大的个人开发者，按量的总支出通常低于包月，还不用被额度周期绑住。例外是你每天都有固定量的调用、且集中在输出较多的任务上，这时包月可能开始划算，具体看你在官方价页折算出的交点位置。
包月是不是一定比按量便宜？
不一定。包月只在用量超过某个水平后才便宜，低于这个水平就是你替没用完的额度买单。另外包月常带并发、限速或模型范围限制，如果你的用法本来就在这些限制之外，便宜也没意义。先算交点，再看约束。
折算的时候最容易算错哪里？
一是把输入和输出混成一个价，二是漏了缓存命中那部分，三是拿单次任务的估算直接乘次数却没考虑重试和失败。想少出错，用一两周的真实调用记录来乘，比用估算公式稳。具体单价以官方价页当时数字为准。
