两个模型都便宜，但便宜的地方不一样：有的场景吃输入长度，有的场景吃输出长度，有的场景明显更适合其中一家。这篇不报具体数字，而是给你一套对齐口径的方法和按场景选型的判断顺序，价格随时会变，口径和动作不会。
两家都属于国产大模型里单价压得很低的那一档，但便宜的地方不一样。有的任务吃输入长度，有的吃输出长度，有的贵在来回调用好几轮，所以没法一句话说清谁更划算，只能按你手上的活去算。
这篇不报具体数字，反正价格隔一阵就动一次。给你的是对齐口径的方法、按场景挑的判断顺序，以及能自己动手验证的动作。数字去站内页面核对当时的，方法不用改。
先对齐口径，再谈谁便宜
很多人比价的方式是去官网抄两个单价放一起看，这基本没用。两家都可能把输入、输出、缓存命中、缓存写入拆成不同计价项，你要先确认自己这个任务到底落在哪一项上，否则比的是两个不相干的数。
- 输入价
- 你送进去的提示词、上下文、文档按这个算，长文档场景主要看它
- 输出价
- 模型生成的内容按这个算，写文案、写代码这类任务主要看它
- 缓存命中
- 同一段内容重复送入时可能打折，长会话和反复问答里差别明显
- 缓存写入
- 把内容存进缓存这一步有时也计费，别只看命中价忘了写入口
还有个容易漏的点：同一个任务在两家消耗的 token 数并不一样。中文断句、代码缩进、长文档切分方式都有差异，同一段材料送进去，两家算出来的长度可能差一截。所以别拿单价直接乘，要拿实际 token 数乘。
核对数字走两个官方资料页：到 /official-api/providers/zhipuai 和 /official-api/providers/deepseek 看当时的计费项，再用 /tools/model-cost-calculator 把输入输出分别填进去算一遍。别凭记忆写价格，那一栏变化频率比你想的高。
短对话与问答类：看输出占比
客服问答、意图分类、信息抽取这类任务，输入短、输出也短，胜负基本由输出单价和单次 token 数决定。差别在于输出占比：写回复、写文案输出多，输出价影响大；分类、打标签输出就几个字，输入价反而更关键。
- 先估你真实的平均对话长度，别拿最长的那次当样本
- 算清一次问答的输入输出各占多少 token
- 按日均调用次数乘出月用量，再套两家的口径
- 两边差距很小的时候，优先看稳定性和响应速度，别为省钱牺牲可用性
- 真实用量分布可以去 /usage 翻一翻，分布比平均数更能说明问题
这类场景最容易犯的错是拿单次价格比大小，结果忽略了调用频次。一天几千次的短问答，单次差一丁点，一个月下来就不是一丁点。反过来，一天几十次的内部工具，两家选谁都行，别在这上面耗时间。
长文档、长上下文：看输入与缓存
做文档总结、合同审阅、知识库问答，输入量往往远大于输出量，这时候重点看输入单价和缓存机制。同一份资料反复问同一个话题，有没有缓存命中，成本能拉开一个档，具体做法可以去看站内讲缓存的那几篇。
但更值得先想的是：这份文档真的需要整篇塞进去吗。很多长输入场景，先做切分、摘要、检索，再送一小段进去，省下来的比换个便宜模型多得多。换模型是最后一步，不是第一步。
| 任务特征 | 主要成本项 | 优先核对什么 |
|---|---|---|
| 一份长文档只问一次 | 输入价 | 输入单价与单次 token 量 |
| 同一份资料反复问 | 缓存命中 | 有没有缓存、命中怎么打折 |
| 文档很长且要引用原文 | 输入价 + 输出价 | 切分后总 token 是否下降 |
| 只问文档里某个点 | 输入价 | 能否检索出片段而不是全量送 |
算的时候到 /tools/token-price-calculator 把输入和输出分开填，别混成一个总数。混着算的结果没法判断到底是哪一项在花钱，也就没法优化。
写代码、跑 Agent：看调用轮次
这类任务单次请求都不贵，贵在轮次多。一次会话里模型要读代码、调工具、看返回、再改一版，上下文一轮轮累积，账单是滚雪球式的。所以要比的不是单次请求价格，是完成一个任务总共花多少。
还有两处常被忽略的开销：失败的请求要不要重试，重试就得多付一次；工具返回的内容体积有多大，日志、网页、报错堆栈全塞进上下文里，token 涨得很快。
- 定一个可复现的任务挑一个真实的小需求，比如改一个函数并跑通测试，别用玩具例子
- 记录全过程 token把整个会话的输入输出加起来，包括每一次工具调用往返
- 算上重试与失败按你实际的失败率乘一个系数，别用理想值
- 两边各跑一遍对比同样的任务分别在两家跑，比的是总消耗和完成质量，不是单次价格
如果两边算下来差不多，就选那个在长会话里更稳、不容易中途跑偏的。Agent 场景里返工一次的成本，比单价那点差距大得多。
选型判断顺序与验证动作
前面几节是按场景分开说的，落到你自己身上，按下面这个顺序走一遍就行。核心思路是先分类、再实测、最后算总账，不要上来就比单价。
- 分类把手上任务分成短问答、长输入、代码 Agent 三类，每类挑一个真实样本
- 实测同一份样本分别在两家跑，记录输入输出 token 数和完成质量
- 算账把 token 数填进 /tools/model-cost-calculator，得到单次成本再乘月频次
- 留退路去 /ai-nav/category/ai-model-platform 找能同时接两家的入口，别被单一渠道绑住
- 定期复核价格会变，隔一段时间回到官方资料页重新核一遍，别用半年前的数字做决策
比价的正确单位是「跑完这个任务花多少」，不是「每百万 token 多少钱」。
最后提醒一句：两家都在持续调价和加计费项，今天算出来的结论过一阵可能就不成立。把上面这套动作存下来，数字变了就重跑一遍，比记结论有用。
下一步把两家官方资料页的数字和计算器放在一起过一遍，用你自己的真实样本算一次，比看十篇对比文都准。→常见问题
GLM 和 DeepSeek 哪个更便宜？
没有统一答案，取决于你的任务以输入为主还是输出为主、有没有缓存命中。同样的活，两家的 token 消耗口径也不一样。正确做法是拿一个真实样本各跑一遍，把数字填进站内成本计算器，得到单次成本再按月频次放大，而不是看单价谁低。
我该按单价选还是按总成本选？
按总成本。单价只反映每百万 token 的价格，真正花钱的是任务完成度、调用轮次和重试次数。写代码、跑 Agent 这类多轮任务，单次价格再低，轮次翻倍也一样贵。先算一次任务的完整成本，再看哪个划算。
选好之后能不能随时换回来？
可以，但要提前铺路。两家协议兼容度不同，如果代码里写死了请求格式，换的时候要改的地方不少。建议把模型调用封装成一层，用环境变量或配置切换，具体接入方式参考站内客户端配置与 Base URL 相关文章。
