火山引擎的 方舟 Agent Plan Small套餐文本模型用量简单计算评估
火山方舟AgentPlan个人版套餐token换算分析摘要 本文基于火山方舟AgentPlan个人版套餐（Small套餐40元/月）的AFP燃料值体系，计算了不同使用场景下的token换算量。核心发现： 不同模型类别（极速/标准/进阶）和上下文长度（0-32k/32k-128k/128k-256k）的token换算量差异显著 编程开发场景（输入输出比9:1）下，极速模型最高可换算568.99M t
计算可能有误，请酌情参考。
快速查看（注意，实际结果会因对话轮次以及实际使用的输入输出token比例而产生变化）
|
模型类别 |
输入：输出 |
参考场景 |
上下文长度 |
token量约值 |
换算为M |
|
文本生成（进阶1） |
文本生成（进阶1）可用模型：doubao-seed-2.0-code doubao-seed-2.0-pro deepseek-v3.2 minimax-m2.7 |
||||
|
文本生成（进阶1） |
9：1 |
编程开发 |
0-32k |
56899000 |
56.90M |
|
文本生成（进阶1） |
9：1 |
编程开发 |
32k-128k |
40298000 |
40.30M |
|
文本生成（进阶1） |
9：1 |
编程开发 |
128k-256k |
22270520 |
22.27M |
|
文本生成（进阶2） |
文本生成（进阶2）可用模型：glm-5.1 kimi-k2.6 |
||||
|
文本生成（进阶2） |
9：1 |
编程开发 |
0-32k |
31610550 |
31.61M |
|
文本生成（进阶2） |
9：1 |
编程开发 |
32k-128k |
22520000 |
22.52M |
|
文本生成（进阶2） |
9：1 |
编程开发 |
128k-256k |
12913910 |
12.91M |
正文
火山方舟 推出的 Agent Plan 个人版，这是面向个人用户的大模型套餐，其采用Agent 燃料值（Agent Fuel Point，后简称 AFP）作为统一用量单位，本文简单计算其中 Small 套餐换算为 token 的大概值。（只是简单估算，实际会受到不同的使用情况而有所差别）
官方文档地址：https://www.volcengine.com/docs/82379/2366394?lang=zh#c90d28c2
首先，先查看其套餐额度：
|
套餐 |
价格 |
月额度（AFP） |
周额度（AFP） |
五小时额度（AFP） |
视觉模型日额度（AFP） |
|
Small |
40 元/月 |
20,000 |
7,000 |
2,000 |
10,000 |
|
Medium |
200 元/月 |
100,000 |
35,000 |
10,000 |
50,000 |
|
Large |
500 元/月 |
250,000 |
87,500 |
25,000 |
125,000 |
|
Max |
1000 元/月 |
500,000 |
175,000 |
50,000 |
250,000 |
可以看到 Small 套餐价格是 40元/月，其月额度是 20000 Agent 燃料值。
接下来查看其计算规则，单次请求 AFP 消耗：
- 文本生成模型、向量化模型：(输入 token * 输入抵扣系数 + 输出 token * 输出抵扣系数) / 10,000
- 视频生成模型：消耗的原始 token / 10,000 * 抵扣系数
- 图片生成模型：成功生成的图片张数 * 抵扣系数
其计算的核心在于两个点，其一是抵扣系数，其二是输入输出token比例。
查看其不同模型类别的抵扣系数：
|
模型类别 |
模型 |
输入长度 |
输入抵扣系数 (模型抵扣系数 × 输入分段系数 ) AFP/万 token |
输出抵扣系数 (模型抵扣系数 × 输出分段系数) AFP/万 token |
|
文本生成 （极速） |
doubao-seed-2.0-mini |
[0, 32k] |
0.335 0.5 × 0.67 |
0.5 0.5 × 1 |
|
[32k, 128k] |
0.5 0.5 × 1 |
0.5 0.5 × 1 |
||
|
[128k, 256k] |
1 0.5 × 2 |
0.5 0.5 × 1 |
||
|
文本生成 （标准） |
doubao-seed-2.0-lite |
[0, 32k] |
0.67 1 × 0.67 |
1 1 × 1 |
|
[32k, 128k] |
1 1 × 1 |
1 1 × 1 |
||
|
[128k, 256k] |
2 1 × 2 |
1 1 × 1 |
||
|
文本生成 （进阶） |
doubao-seed-2.0-code doubao-seed-2.0-pro deepseek-v3.2 minimax-m2.7 |
[0, 32k] |
3.35 5 × 0.67 |
5 5 × 1 |
|
[32k, 128k] |
5 5 × 1 |
5 5 × 1 |
||
|
[128k, 256k] |
10 5 × 2 |
5 5 × 1 |
||
|
文本生成 （进阶） |
glm-5.1 kimi-k2.6 |
[0, 32k] |
6.03 9 × 0.67 |
9 9 × 1 |
|
[32k, 128k] |
9 9 × 1 |
9 9 × 1 |
||
|
[128k, 256k] |
18 9 × 2 |
9 9 × 1 |
||
|
向量化 |
doubao-embedding-vision |
[0, 32k] |
0.67 1 × 0.67 |
1 1 × 1 |
|
[32k, 128k] |
1 1 × 1 |
1 1 × 1 |
||
|
[128k, 256k] |
2 1 × 2 |
1 1 × 1 |
参考其计算案例：
接下来便可以进行计算了。
这里根据不同使用场景，简单分为三种场景，编程开发（vibe coding）、文本生成（长文本、小说输出）、普通对话。其输入输出token比例分别简单设定为：9：1、1：9、1：3。
核心思路是这样的：
计算公式
(输入抵扣系数 * 输入比例系数 * 变量n + 输出抵扣系数 * 输出比例系统 * 变量n)/10000 = 20000
知道输入、输出的抵扣系数和比例系数，求取变量n的值，最终的token换算值 = 输入输出比例之和 * 变量n
当然这里没有考虑不同上下文长度的影响，考虑上下文长度，则需要先计算前面阶段消耗的 Agent燃料值，粗略的计算过程是这样的：
（输入比例系数 + 输出比例系数）* 变量n = 32000
(阶段一输入抵扣系数 * 输入比例系数 * 变量n + 阶段一输出抵扣系数 * 输出比例系统 * 变量n)/10000
即：（阶段一输入抵扣系数 * 输入比例系数 *（32000/（输入比例系数 + 输出比例系数））+ 阶段一输出抵扣系数 * 输出比例系统 *（32000/（输入比例系数 + 输出比例系数）））/10000
计算结果表格
最终计算出来的结果如下：
|
模型类别 |
输入：输出 |
参考场景 |
上下文长度 |
token量约值 |
换算为M |
|
文本生成（极速） |
doubao-seed-2.0-mini |
||||
|
文本生成（极速） |
9：1 |
编程开发 |
0-32k |
568990040 |
568.99M |
|
文本生成（极速） |
9：1 |
编程开发 |
32k-128k |
400300000 |
400.30M |
|
文本生成（极速） |
9：1 |
编程开发 |
128k-256k |
211753680 |
211.75M |
|
文本生成（极速） |
1：9 |
文本生成 |
0-32k |
413650460 |
413.65M |
|
文本生成（极速） |
1：9 |
文本生成 |
32k-128k |
400300000 |
400.30M |
|
文本生成（极速） |
1：9 |
文本生成 |
128k-256k |
364825450 |
364.83M |
|
文本生成（极速） |
1：3 |
普通对话 |
0-32k |
435967300 |
435.97M |
|
文本生成（极速） |
1：3 |
普通对话 |
32k-128k |
400108000 |
400.11M |
|
文本生成（极速） |
1：3 |
普通对话 |
128k-256k |
320432000 |
320.43M |
|
文本生成（标准） |
doubao-seed-2.0-lite |
||||
|
文本生成（标准） |
9：1 |
编程开发 |
0-32k |
284495020 |
284.50M |
|
文本生成（标准） |
9：1 |
编程开发 |
32k-128k |
200300000 |
200.30M |
|
文本生成（标准） |
9：1 |
编程开发 |
128k-256k |
106485260 |
106.49M |
|
文本生成（标准） |
1：9 |
文本生成 |
0-32k |
206825230 |
206.83M |
|
文本生成（标准） |
1：9 |
文本生成 |
32k-128k |
200290000 |
200.29M |
|
文本生成（标准） |
1：9 |
文本生成 |
128k-256k |
182989090 |
182.99M |
|
文本生成（标准） |
1：3 |
普通对话 |
0-32k |
217983648 |
217.98M |
|
文本生成（标准） |
1：3 |
普通对话 |
32k-128k |
200108000 |
200.11M |
|
文本生成（标准） |
1：3 |
普通对话 |
128k-256k |
160424000 |
160.42M |
|
文本生成（进阶1） |
doubao-seed-2.0-code doubao-seed-2.0-pro deepseek-v3.2 minimax-m2.7 |
||||
|
文本生成（进阶1） |
9：1 |
编程开发 |
0-32k |
56899000 |
56.90M |
|
文本生成（进阶1） |
9：1 |
编程开发 |
32k-128k |
40298000 |
40.30M |
|
文本生成（进阶1） |
9：1 |
编程开发 |
128k-256k |
22270520 |
22.27M |
|
文本生成（进阶1） |
1：9 |
文本生成 |
0-32k |
41365040 |
41.37M |
|
文本生成（进阶1） |
1：9 |
文本生成 |
32k-128k |
40290000 |
40.29M |
|
文本生成（进阶1） |
1：9 |
文本生成 |
128k-256k |
37529090 |
37.53M |
|
文本生成（进阶1） |
1：3 |
普通对话 |
0-32k |
43596728 |
43.60M |
|
文本生成（进阶1） |
1：3 |
普通对话 |
32k-128k |
40100000 |
40.10M |
|
文本生成（进阶1） |
1：3 |
普通对话 |
128k-256k |
32412800 |
32.41M |
|
文本生成（进阶2） |
glm-5.1 kimi-k2.6 |
||||
|
文本生成（进阶2） |
9：1 |
编程开发 |
0-32k |
31610550 |
31.61M |
|
文本生成（进阶2） |
9：1 |
编程开发 |
32k-128k |
22520000 |
22.52M |
|
文本生成（进阶2） |
9：1 |
编程开发 |
128k-256k |
12913910 |
12.91M |
|
文本生成（进阶2） |
1：9 |
文本生成 |
0-32k |
22980580 |
22.98M |
|
文本生成（进阶2） |
1：9 |
文本生成 |
32k-128k |
22512220 |
22.51M |
|
文本生成（进阶2） |
1：9 |
文本生成 |
128k-256k |
21367870 |
21.37M |
|
文本生成（进阶2） |
1：3 |
普通对话 |
0-32k |
24220404 |
24.22M |
|
文本生成（进阶2） |
1：3 |
普通对话 |
32k-128k |
22321332 |
22.32M |
|
文本生成（进阶2） |
1：3 |
普通对话 |
128k-256k |
18190220 |
18.19M |
|
向量化 |
doubao-embedding-vision |
||||
|
向量化 |
9：1 |
编程开发 |
0-32k |
284495020 |
284.50M |
|
向量化 |
9：1 |
编程开发 |
32k-128k |
200300000 |
200.30M |
|
向量化 |
9：1 |
编程开发 |
128k-256k |
106485260 |
106.49M |
|
向量化 |
1：9 |
文本生成 |
0-32k |
206825230 |
206.83M |
|
向量化 |
1：9 |
文本生成 |
32k-128k |
200290000 |
200.29M |
|
向量化 |
1：9 |
文本生成 |
128k-256k |
182989090 |
182.99M |
|
向量化 |
1：3 |
普通对话 |
0-32k |
217983648 |
217.98M |
|
向量化 |
1：3 |
普通对话 |
32k-128k |
200108000 |
200.11M |
|
向量化 |
1：3 |
普通对话 |
128k-256k |
160424000 |
160.42M |
说明
由于这个计算在超过128K时是直接将全部燃料值用于一轮对话所计算出来的值，因此实际上可使用的token会更多。
假设新开三轮对话，每轮对话的上下文长度不超过32K，此时消耗的燃料值其实是较少的，而非计算中的以上下文长度达到128K以上的情况。
因此，根据你对话的轮次和上下文长度的不同，实际的token使用量会变化巨大。
同时输入输出的token比例也会严重影响换算后的token值。
示例
以使用 glm-5.1 为例，根据计算的结果，按编程场景，输入输出比例为9：1的情况下，其换算出的 token 量大概在 31.61M - 12.91M 之间。说明：计算结果受对话轮次以及实际的输入输出token比例不同而有所不同，数据仅供参考。
总结
上文计算的结果是在设定了输入输出token比例之后计算的结果，如果输入输出比例改变，那么其实际结果也会有所改变。
总体而言，根据其输入输出抵扣系数可知：
|
上下文长度 |
系数大小 |
等量token下价格 |
|
上下文长度 < 32K |
输入系数 < 输出系数 |
同样的token总数下，输入占比高便宜 |
|
32K<=上下文长度<=128K |
输入系数 = 输出系数 |
同样的token总数下，无所谓输入输出 |
|
128K<=上下文长度<=256K |
输入系数 > 输出系数 |
同样的token总数下，输出占比高便宜 |
不推荐用于需要长上下文（超128K）的任务中。
有“AI”的1024 = 2048，欢迎大家加入2048 AI社区
更多推荐
8
0- 0
已为社区贡献1条内容
所有评论(0)