火山引擎的 方舟 Agent Plan Small套餐文本模型用量简单计算评估
计算可能有误，请酌情参考。
快速查看（注意，实际结果会因对话轮次以及实际使用的输入输出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）的任务中。
这里是“一人公司”的成长家园。我们提供从产品曝光、技术变现到法律财税的全栈内容，并连接云服务、办公空间等稀缺资源，助你专注创造，无忧运营。
更多推荐
19
0- 0
已为社区贡献1条内容
所有评论(0)