Cost-Analysis on Svtter's Blog

大模型 Coding Plan 年付，到底值不值？

Sun, 22 Mar 2026 16:30:00 +0800

前段时间我写过一篇文章：大模型 Coding Plan 套餐的数学陷阱：并发限制下的承诺量能否兑现？。

那篇文章讨论的是一个偏“供给侧”的问题：厂商宣传的海量额度，在并发、吞吐和 agent 调用膨胀的现实里，到底能不能兑现。

但这还不是全部。

对用户来说，另一个同样重要的问题是：即便套餐的理论承诺很难完全兑现，这种年付制 Coding Plan 到底值不值钱？

我的结论是：对轻度用户，大概率不值得；对重度用户，往往非常值。

问题不仅仅只有一个

“值不值”其实不是一个问题，而是两个问题：

这个套餐的承诺量能不能真的给到你？
这个套餐的价格，和你按量付费相比，划不划算？

上一篇文章主要在算第一个问题。

这一篇，我只算第二个。

因为这两个问题并不矛盾。一个套餐完全可能同时满足下面两点：

它宣传的“海量额度”在工程上很难 100% 打满；
但对某些真实重度用户来说，它依然比按量 API 便宜很多。

以一个供应商的高配年付套餐为例

为了把账算清楚，我还是拿一个具体套餐举例。这里用 GLM-5 Max，只是因为它的价格、按量定价和套餐规则相对明确，方便计算。

更准确地说，这篇文章复用的是分析框架，不是直接复用结论。如果换成别家的 Coding Plan，价格、支持工具、限额窗口和扣减规则都可能不一样，参数必须重新代入。

截至 2026-03-22，我看到的实际价格是：

GLM-5 Max：4800 元 / 年
折合下来：400 元 / 月

官方 API 定价则是：

输入：$1 / 1M tokens
输出：$3.2 / 1M tokens

如果你只是偶尔用一下，这个年费其实不低。

但我最近 30 天的实际 token 用量是：

1

662,106,588 tokens / 30 天

这就不是“偶尔用一下”的问题了。

不过这里也要先说明：这是我的个人重度使用样本，不是平均用户画像。 这组数字更适合回答“像我这种高负载用户会不会回本”，不适合直接外推成所有人的结论。

直接算账

如果这 6.62 亿 tokens 全部走 GLM-5 按量 API，那么成本下限是：

1

662.1 × $1 / 1M = $662

也就是说，哪怕全部按输入 token 计费，一个月也已经是 600 多美元。

而如果考虑更接近真实编码场景的输入输出比例，账单会更高。

输入 / 输出占比	估算单价（每 1M）	月成本（USD）
80% / 20%	`$1.44`	`$953`
70% / 30%	`$1.66`	`$1,099`
50% / 50%	`$2.10`	`$1,390`

如果粗略按 1 USD ≈ 6.9 RMB 来看，大概就是：

极保守下限：约 4,500 元 / 月
常见编码场景：约 6,500 - 9,600 元 / 月

而 GLM-5 Max 的月均成本只有：

1

4800 / 12 = 400 元 / 月

所以从纯价格上看，结论非常直接：

对我这种每月稳定消耗数亿 tokens 的重度样本来说，GLM-5 Max 不是“省一点”，而是“省很多”。

但这句话还有一个隐含前提：这些工作负载必须大部分能落进套餐支持的工具链和额度规则里。 如果你的大量 token 消耗其实发生在通用 API、非支持工具，或者持续撞到 5 小时/周限额，那这笔账就要重算。

但这里有一个前提：省钱，不等于一定够用

这正是上一篇文章想表达的重点。

这类高配年付套餐之所以可能非常省钱，不代表它就没有边界。官方文档里依然写了不少限制：

套餐只能在支持的 coding tools 中使用
有 5 小时 的资源窗口限制
有 每周 的额度限制
GLM-5 会比历史模型消耗更多套餐配额
高峰时段和非高峰时段的扣减效率并不一样

也就是说，省钱和吞吐，是两个维度。

从“账单”角度看，重度用户买订阅非常容易回本；
从“体验”角度看，你还是可能撞到周限额、窗口限额和并发限制。

这不是数学矛盾，而是两个不同的问题。

什么人适合买这类高配年付套餐

我觉得比较适合买这类高配年付 Coding Plan 的，是下面这类用户：

几乎每天都在 IDE 或终端里跑 coding agent
经常做多轮修复、重构、读大仓库、批量改代码
token 用量长期稳定，而不是偶尔冲高
愿意把套餐主要用在受支持的工具链里

如果你符合这些条件，那么这类高配年付套餐更像一个“压低边际成本”的工具。

尤其当你已经进入“每个月稳定烧几亿 tokens”的阶段时，继续按量 API 付费，往往才是更贵的那条路。

什么人不适合买这类高配年付套餐

反过来，如果你属于下面几种情况，那这种 4800 / 年 左右的高配套餐不一定划算：

只是偶尔写代码时让模型帮一下忙
月度用量波动很大，忙的时候很多，不忙的时候几乎不用
主要需求不是 coding tool，而是通用 API 集成
你真正常用的是更便宜的模型，而不是长期打 GLM-5

对这些人来说，Pro 或者干脆按量付费，通常会更稳。

所以，上一篇文章是不是错了？

不是。

上一篇文章的核心观点依然成立：

厂商宣传的“海量额度”，并不等于你在现实工作流里可以无摩擦、无上限地把它全部跑出来。

但这不妨碍这类套餐对重度用户依然有价值。

换句话说：

上一篇文章是在揭穿宣传口径。
这一篇文章是在计算用户回本。

一个东西可以宣传得夸张，但价格依然可能划算。判断它值不值钱，不能只看厂商文案，也不能只看我上一篇的“吞吐上限”分析，还要看你自己的真实用量。

我的结论

如果你每个月的 token 用量只有几百万、几千万，这种高配年付套餐很可能买大了。

但如果你已经到了我这种量级，30 天 6.62 亿 tokens，那 4800 / 年 的高配 Coding Plan 从价格上看是很值的。这里的 GLM-5 Max 只是一个算账样本，而且这个结论成立的前提是：你的主要工作负载确实发生在套餐支持的 coding 工具里，没有被窗口限额严重截断。真正需要担心的，不是它会不会回本，而是：

你会不会先撞到窗口限额和周限额；
你的工作流是不是主要发生在套餐支持的工具里；
你有没有必要全程都用 GLM-5，还是可以让更便宜的模型承担大部分日常任务。

所以我最后的判断很简单：

对轻度用户，这类高配年付套餐更像预付费焦虑。

对重度用户，它更像一张非常便宜、但带限流的通行证。

最后补一个现实问题。

就算这笔账算下来很值，我们最后也未必买得到那个限购的 Coding Plan。

参考

大模型 Coding Plan 套餐的数学陷阱：并发限制下的承诺量能否兑现？

自己部署大模型，真的就能肆无忌惮地用吗？

Thu, 19 Mar 2026 12:30:00 +0800

很多人第一次认真考虑自建大模型，不是因为技术浪漫，而是因为 API 账单、限流，或者数据合规要求已经开始逼近业务现实。

于是，一个很自然的问题就出现了：如果模型已经跑在自己机器上，是不是以后就能“肆无忌惮”地用了？

我的判断是：不能。 自己部署模型，并不等于无限自由，它只是把很多原本由平台承担的限制和成本，转移到了你自己身上。

但这个问题还有后半句，而且更重要：如果使用量足够大，自建到底会不会更划算？

答案是：有可能，但前提比很多人想的要苛刻。

简单说：自己部署大模型，不等于无限自由。

它只是把原本由平台承担的一部分成本和责任，转移到了你自己身上。只有在长期高负载、硬件利用率高、并且你能接受模型能力差异或有能力自己优化时，自建才可能真正划算。

本地部署，不等于无限制

先把最容易出现的误解说清楚。

很多人把“模型跑在自己机器上”理解成“以后想怎么用就怎么用”，但限制并不会消失，它们只是换了一种形式出现。

第一层限制：硬件

模型参数规模、显存容量、量化精度、KV cache、并发数，这些都是真正的物理约束。一个 70B 级模型即便做了量化，也依然会对显存和带宽提出很高要求。能跑，不代表跑得舒服；能输出，不代表延迟和吞吐能接受。

第二层限制：模型能力本身

幻觉、知识截止、长上下文退化、复杂推理不稳定，这些问题不会因为你把模型搬到本地就自动消失。部署位置改变不了模型上限。更现实的一点是：大多数人所谓的“自建”，通常部署的是开源权重模型，而不是 Claude 或 GPT 这类闭源模型本体。

第三层限制：责任转移

用 API 的时候，内容安全、服务稳定性、限流和大部分基础设施问题，平台已经帮你扛了一部分。自己部署之后，这些事情不会消失，只会变成你的运维、监控、审核和应急预案。

所以，自建不是“肆无忌惮”，而是“边界自己扛”。

真正该算的，不是一张显卡多少钱

如果我们要判断自建是否划算，真正该比较的不是“买卡贵不贵”，而是下面两笔总账。

自建的年成本，大致可以写成：

1

自建年成本 = 硬件折旧 + 电费 + 网络/机房 + 运维人力 + 故障冗余

API 的年成本则更直接：

1

API 年成本 = 日均 token 消耗 * 每百万 token 单价 * 365

看起来很简单，但这里有三个特别容易被忽略的点。

自建不是只花一次硬件钱。 电费、备件、机房环境、监控告警、升级维护，这些都会持续发生。
API 价格不是一个固定数字。 不同模型、输入输出比例、缓存命中、是否带工具调用，都会明显改变最后的账单。
利用率经常被低估。 如果你的机器大部分时间都在空转，那么再便宜的单次推理成本也没有意义；反过来，如果业务负载足够稳定，硬件被长期打满，自建的财务优势才会真正体现出来。

所以，下面的数字只能当作一个粗略量级判断，而不是采购报价单。

一个粗略但有用的盈亏平衡表

为了方便讨论，我先做一个非常粗糙的假设：

API 成本按每百万 token 约 50 元人民币估算
token 口径按输入和输出合计计算
自建硬件按 3 年折旧计算
自建成本里计入基础运维和电力开销
本地方案默认以开源模型推理为主，不追求与闭源旗舰严格等效
不计模型训练、微调和专职平台团队的人力成本

在这个假设下，大致会得到下面这样的量级判断：

使用场景	日均 token 消耗	可能的本地方案	自建年成本	API 年成本	粗略结论
轻度使用	50 万	单卡高端消费级工作站	2 万 - 4 万元	约 0.9 万元	API 更省钱
中度使用	500 万	双卡或小型推理工作站	6 万 - 12 万元	约 9 万元	接近平衡点
重度使用	5000 万	多卡服务器或集群	40 万 - 80 万元	约 91 万元	自建可能更划算

如果你希望本地效果尽量逼近顶级闭源模型，那么这张表往往还会继续上修，因为更强的模型、更大的显存、更高的可用性目标，都会把硬件和运维成本继续往上推。

这张表大概能说明三件事：

个人和小团队通常很难靠自建省钱。 如果你的调用量只有几十万 token/天，API 通常依然是更经济的选择。你少花了硬件钱，也少背了运维负担。
真正接近平衡点的，往往是“稳定高用量”场景。 不是偶尔一天冲到很高，而是每天都很高，而且业务负载相对稳定。只有利用率足够高，硬件成本才摊得下来。
用量越大，自建的财务吸引力才越明显。 这也是为什么大型公司会认真建设自己的推理平台：不是因为他们喜欢折腾，而是因为当规模上来之后，这笔账真的会反过来。

但这里有一个很关键的前提：你不一定在比较同一个东西

很多“自建比 API 便宜”的讨论，最大的问题不是数学，而是比较对象不一致。

你在 API 侧，可能买的是当前最强的一线闭源模型；你在本地侧，跑的却是一个量化后的开源模型。两者当然都叫“大模型”，但它们并不是严格等价的商品。

这意味着，至少有三件事要先说清楚：

如果你能接受开源模型的效果，自建的确有机会省很多钱。
如果你的业务质量门槛很高，必须依赖顶级闭源模型，自建空间就会小很多。
如果你只是把“更便宜的模型”拿来和“更贵的模型”比，那得到的不是部署结论，而是模型选择结论。

换句话说，很多人以为自己在算部署成本，其实先做的是能力降级。

这件事本身没有问题，但要承认它。

除了省钱，自建还有哪些真正的收益

如果一家公司最后还是决定自建，通常不只是为了省 API 钱。

数据主权：某些业务天然不愿意把原始数据长期交给第三方服务商，这时本地部署会让合规和审计路径更清晰。
可定制性：你可以围绕自己的任务去做量化、路由、蒸馏、微调，甚至把推理链条和业务系统绑得更紧。这些事情在通用 API 上往往不够自由。
成本上限更可控：API 模式是典型的按量付费，业务一涨，账单也跟着涨。自建虽然前期投入大，但在高负载、稳定负载下，成本曲线通常更可预测。
离线与可用性：如果你的场景要求内网运行，或者无法接受关键流程完全依赖外部服务，那么本地部署会更符合工程要求。

一个更实用的判断方法

如果你不想一上来就算太细，可以先用下面三个问题做快速筛选。

你的负载是不是长期稳定地高？ 如果只是偶尔出现一波高峰，而不是每天稳定消耗大量 token，那么 API 往往更划算，因为你不需要为闲置硬件买单。
你能不能接受本地模型和闭源旗舰之间的差距？ 如果你的业务必须依赖最强模型效果，那么很多所谓的自建节省，其实是靠降低模型能力换来的，不是纯粹的部署优化。
你有没有能力长期维护推理服务？ 显卡坏了怎么办，驱动冲突怎么办，服务抖动怎么办，模型版本怎么升级，监控和限流谁来做？这些问题如果没人接，就不是成本问题，而是交付问题。

我的结论

回到开头那个问题：自己部署大模型，真的就能“肆无忌惮”地用吗？

我的答案是：不能。

它不会消灭硬件瓶颈，不会抹平模型能力差距，也不会替你自动解决审核、稳定性和运维问题。它带来的不是绝对自由，而是更高的控制权，以及与之对应的责任。

但另一方面，自建也绝不是伪命题。 当你满足下面几个条件时，它就会越来越合理：

业务 token 消耗长期处在高位
负载稳定，硬件利用率高
能接受开源模型，或已经有能力做定制优化
对数据主权、内网部署或成本上限有明确要求

换句话说，自建更像是一种工程与财务上的取舍，而不是一张“无限使用”的门票。

如果你是个人用户、小团队，或者只是偶尔重度使用，API 往往还是更现实的解法：省心、省事、试错成本也低。

如果你已经进入“每天都在稳定烧 token”的阶段，那就别再只盯着 API 单价了，认真把整笔账算一遍。很多时候，答案不会是“肆无忌惮”，而是一个更朴素也更重要的判断：这件事到底值不值得自己养。

编码性能与模型性价比分析

Sat, 03 Jan 2026 00:00:00 +0000

这是我对几个模型的编码性能与性价比分析报告，用于对比不同模型在编码任务上的表现和成本效益，以便选择最合适的模型。

中文显然使用 GLM 4.7 是比较划算的。 2000 人民币的价格，基本上包年处理了。缺点是高峰期使用，即便是企业 MAX 版本也会很慢。

从我的实际体验上看，minimax m2.1 的能力是要远远超过 GLM 4.7 的。

Cost-Analysis on Svtter's Blog

大模型 Coding Plan 年付，到底值不值？

问题不仅仅只有一个

以一个供应商的高配年付套餐为例

直接算账

但这里有一个前提：省钱，不等于一定够用

什么人适合买这类高配年付套餐

什么人不适合买这类高配年付套餐

所以，上一篇文章是不是错了？

我的结论

参考

相关文章

自己部署大模型，真的就能肆无忌惮地用吗？

本地部署，不等于无限制

第一层限制：硬件

第二层限制：模型能力本身

第三层限制：责任转移

真正该算的，不是一张显卡多少钱

一个粗略但有用的盈亏平衡表

但这里有一个很关键的前提：你不一定在比较同一个东西

除了省钱，自建还有哪些真正的收益

一个更实用的判断方法

我的结论

编码性能与模型性价比分析