glm-5.2价格

搜「glm-5.2价格」的人，多半是在做国产模型选型：手上有智谱和阶跃两条线，想知道哪家更适合自己这批活。麻烦在于，两家的计价单位、档位划分、限速口径不完全一样，网上流传的数字又经常过期。这篇不给死数字，只给一套查价与比价的动作：先对齐口径，再按任务类型挑线，最后落到一个能自己复算的小预算。

搜「glm-5.2价格」的人，多半是在做国产模型选型：手上同时有智谱和阶跃两条线，想知道哪家更适合自己这批活。真正的麻烦不在于某家贵一点或便宜一点，而在于两家的计价单位、档位划分、限速口径并不一致，网上流传的数字又经常过期。这篇不给死数字，只给一套查价与比价的动作：先对齐口径，再按任务类型挑线，最后落到一个能自己复算的小预算。

先把心态摆正：模型单价是随时会动的东西，把它背下来没有意义。你要建立的是一个「随时能查到当期数字」的路径，加上一套「拿到数字后怎么比」的方法。路径和方法的寿命比数字长得多，换季调价也不会让你前面的工作白做。

价格别背，去这几个页面现查

查价的第一步是分线。智谱一线去官方 API 的智谱页面看按量价格基准，阶跃一线去阶跃页面看按量计费与限速说明，这两页是你比价的起点，两边的口径说明都要完整读一遍，而不是只看价格表那一栏。注意页面上通常会把输入、输出、缓存分成几行，别只抄其中一行。

• 智谱一线：到 /official-api/providers/zhipuai 核对当期按量价格与档位说明
• 阶跃一线：到 /official-api/providers/stepfun 核对当期计费方式与限速口径
• 横向对比：到 /official-api 和 /providers 按厂商翻一遍，国产几家放在一起看，比只看单家页面更容易发现问题
• 变动兜底：任何时候以 /price-watch 的当期记录为准，某家刚调过价，旧截图和二手数字就作废了

比价之前先把两家的口径对齐

直接拿两家价格表上的数字相减，是最常见的错误。因为计价单位可能不同，输入输出可能分开计，低档位往往还捆着更低的 RPM/TPM。你以为是单价差异，实际可能是限速差异或者缓存命中率差异。先把下面这张对照表填满，再谈谁便宜。

这张表不用一次填完，先把「计价单位」和「限速档位」两行填清楚，就能挡掉大部分错误比价。口径对齐的通用方法在 /guides/pricing-alignment-basics 里讲过，比价前先过一遍这一步，比事后返工省事。

有一种情况这套对齐方法不适用：如果你只用一家的一个固定档位、每天请求量很小、从不触碰限速，那口径差异的影响可以忽略，直接看当期数字选就行，不必做全套对齐。

按任务类型选线，而不是按单价选线

单价表只能告诉你单位成本，选线要看你的任务把成本压在哪一侧。长输入的活，钱大多花在输入 token 上；高频短请求的活，钱和体验都卡在限速与输出价上。下面按四类常见任务给判断标准。

1. 长文档、长上下文类任务先估输入 token 的量级，再比两家的长文本档位。单位看似便宜的，在长输入下不一定总价便宜；把一篇典型文档跑一遍，记录输入输出 token 数，再乘当期单价。
2. 高频短请求类任务客服问答、分类打标这类，输入很短、次数很多。重点看限速和输出价，输入价占比很小，别被低输入价带偏；先压测一下稳定 RPM 能不能扛住你的峰值。
3. 编程与工具调用类任务把一轮完整任务的 token 消耗拉出来，而不是只看单次调用。参考 /coding-plans 里国产套餐的额度口径，判断该按量买还是买套餐，两者在低用量和高用量下的结论不一样。
4. 不确定的任务从最便宜的档位起步，跑一周真实用量再换档。用量记录要留字段，方法见 /usage；没有记录就换模型，等于拿感觉做决策。

选线看的是「这批活的成本结构」，不是「哪家价格表上那个数更小」。

给自己做一份能复算的小预算

比价的终点不是得出一个结论，而是你手上有一份别人问起时能当场复算的预算。复算的意义在于：下次调价，你只需要换掉单价那一个因子，其余结构不用重做。

• 先估三个数：日均请求数、平均输入 token、平均输出 token，三者相乘再乘当期单价，得到日均成本
• 把限速、重试、缓存命中这几个系数单独列一行，不要只乘一个理想值
• 用 /tools/token-price-calculator 或 /tools/model-cost-calculator 把单价换算成「一次对话多少钱」，比看百万 token 价直观得多，换算思路参考 /guides/token-price-to-cost
• 跑满一周后对一次账，偏差大就先查是不是限速重试或缓存没命中，而不是直接换模型

有一类情况这份预算不必做：还没确定要不要长期用，只想先试两天手感。那直接按最便宜的档位跑，别花时间建模。预算的价值在中长期用量上，短期试水用不上。