2026 Qwen3.8-Max、Kimi K3、DeepSeek V4 账单对齐

截至 2026 年 8 月 8 日，本周最应该做的动作不是比较套餐价格，而是导出一周 API usage 与任务结果，把 Qwen3.8-Max、Kimi K3、DeepSeek V4 统一换算成“每个成功完成任务的有效成本”。套餐金额、Credits 消耗和每 Token 标价都只能作为计算因子，不能直接代表真实业务成本。

这篇文章适合三类人：正在整理三款模型试用账单、需要建立成本换算表的独立开发者；负责 API 预算与采购、必须识别表面单价和有效成本差距的技术负责人；以及运行编程或自动化 Agent、经常遇到重试、长输出和工具调用的团队。

最后更新于 2026 年 8 月 8 日，模型状态、计费单位与缓存规则核实自 Qwen 官方 Model Studio 定价说明、Qwen Token Plan 官方说明、Kimi API 官方计费文档 及 DeepSeek 官方定价页。

统一分母：成功任务而不是套餐金额

三款服务的第一层差异，不是模型能力，而是账单单位不同：

• Qwen3.8-Max 可能出现在 Token Plan、预览型号或正式 API 中，Credits、套餐周期和 Token 账单不能混成一个字段。
• Kimi K3 采用 Token 计费时，需要拆分缓存命中输入、未命中输入和输出；若调用官方工具，还可能产生独立工具费用。
• DeepSeek V4 的 API 返回中包含缓存命中与未命中输入 Token，官方定价页也分别列出不同模型 ID 与计费项目。(api-docs.deepseek.com)

因此，我们建议使用下面的统一公式：

有效任务成本 ＝（输入成本 ＋ 缓存输入成本 ＋ 输出成本 ＋ 工具成本 ＋ 失败请求成本 ＋ 重试成本）÷ 成功任务数

这里的“成功任务”必须提前定义。例如，代码 Agent 不能以“模型返回了文本”作为成功，而应满足测试通过、文件修改完成、人工验收通过或接口返回结构完整等条件。否则，某个模型即使单次调用更便宜，也可能因为返工次数更多而变贵。

至少需要记录这些字段：

1. model_id：实际调用的模型 ID，不能只记录产品名称。
2. input_tokens：未命中缓存的输入 Token。
3. cache_hit_tokens：缓存命中的输入 Token。
4. output_tokens：模型实际输出 Token。
5. tool_calls：工具调用次数与外部工具费用。
6. failed_requests：超时、限流、服务错误和解析失败。
7. retry_count：模型自主重试、程序重试和人工续跑。
8. success：是否通过预先定义的验收标准。

Credits 应该如何换算，才能与 Token 账单放在一起？

只有在官方明确给出 Credits 与实际 Token 或调用消耗的对应关系，并且控制台能同时导出对应请求记录时，才可以做近似换算。否则，Credits 只能表示某个套餐内的消耗单位，不能擅自转换成每百万 Token 价格。

更稳妥的做法是计算“每个成功任务消耗多少 Credits”，再与其他 API 的“每个成功任务总 Token 成本”并列比较。两者虽然底层单位不同，但分母一致，才有业务决策价值。

Qwen3.8-Max 的套餐账单拆分

Qwen3.8-Max 的账单整理，重点不是把套餐价格除以 Credits，而是区分三个维度：套餐周期、可用额度和实际完成任务数。

建议在账单表中单独保留以下字段：

Qwen 官方文档对不同模型可能采用分层 Token 价格。例如，Model Studio 的价格说明按输入 Token 区间划分档位，并明确区分模型 ID、部署范围和计费模式。页面还说明，批量调用与上下文缓存折扣并不一定能够同时叠加，因此保存账单时必须记录调用方式，而不能只保存最终金额。(help.aliyun.com)

预览优惠、时段折扣、正式版价格也必须分栏。最容易出错的做法，是用一次预览套餐的有效期消耗，去估算未来生产环境的长期预算。只要模型从 preview 切换到正式型号，或者套餐规则发生变化，就应该重新建立一组账单数据。

我们建议至少连续记录以下三种任务：

• 冷启动任务：没有历史上下文和缓存，观察初始消耗。
• 连续会话任务：重复发送稳定的系统提示、代码库说明或文档前缀。
• 上下文变更任务：只修改中间一段内容，观察缓存是否仍然有效。

如果官方没有公开 Credits 到 Token 的比例，就不要补一个“估算单价”。可记录“本周期使用 Credits ÷ 成功任务数”，并把它标记为套餐利用率指标，而不是 Token 价格。

Kimi K3 与 DeepSeek V4 的 Token 账单

Kimi API 官方文档明确说明，聊天补全会按照输入和输出使用量计费，文档上传和内容提取本身是否收费，也要与后续发送给模型的输入 Token 分开判断。官方还提供 Token 估算接口，实际账单应优先以 API 返回的 usage 字段和控制台记录为准。(platform.kimi.ai)

Kimi K3 的记录方式应至少包含：

• 未命中缓存的输入 Token；
• 命中缓存的输入 Token；
• 模型输出 Token；
• 推理或长输出导致的额外请求；
• 工具调用次数及工具本身的费用。

例如，Kimi 官方工具文档列出网络搜索工具的单次调用费用为 $0.005，并说明搜索结果占用的 Token 还会进入后续模型请求的计费总量。这个费用不能被藏在“模型输出成本”里，否则 Agent 预算会被低估。(platform.kimi.ai)

DeepSeek V4 则应直接按官方返回的缓存字段对账。当前官方文档列出 deepseek-v4-flash 和 deepseek-v4-pro 两个模型 ID，并分别说明输入缓存命中、输入未命中和输出的计费项目；官方 API 也支持工具调用。(api-docs.deepseek.com)

缓存命中之后，Kimi K3 与 DeepSeek V4 应该怎样放在同一张成本表里？

不能只比较两家缓存命中的单价，而应比较同一批任务中的实际缓存命中 Token 数。统一记录：

缓存节省额 ＝ 未命中输入 Token × 未命中单价 − 命中输入 Token × 命中单价

然后再把缓存节省额放回完整任务成本中。若一个模型的缓存命中率很高，但输出明显更长，或者失败后重复发送整段上下文，最终仍可能比另一款模型更贵。

长文档与代码库的缓存复用

长文档任务最容易制造“价格表看起来便宜、实际账单却上升”的错觉。原因通常有三个：

• 每轮对话都重复发送完整历史消息；
• 文档前缀发生细微变化，导致缓存无法命中；
• 模型输出过长，后续请求又把这些输出作为新的上下文发送。

DeepSeek 官方缓存文档说明，缓存主要匹配输入前缀，且命中并不是百分之百保证；API 返回的 prompt_cache_hit_tokens 与 prompt_cache_miss_tokens 可用于确认实际命中情况。官方还说明，缓存构建需要时间，闲置缓存通常会在数小时到数天内被清理。(api-docs.deepseek.com)

因此，长文档对比不能只跑一次。我们建议使用同一份文档、同一组问题，分别跑：

1. 第一次冷启动；
2. 第二次保持系统提示和文档前缀不变；
3. 第三次只改变问题；
4. 第四次修改文档中的一小段；
5. 第五次重新发送完整上下文。

每次都保存输入 Token、缓存命中 Token、输出 Token、响应时间和任务是否通过。这样才能判断某款模型适合“同一代码库连续问答”，还是更适合“每次压缩上下文后独立调用”。

对代码库任务，还要注意文件排序、路径前缀和系统提示是否稳定。哪怕业务内容相同，只要拼接顺序变化，缓存命中率也可能下降。把代码库摘要、规则文件和当前变更区分成固定区与变化区，通常比单纯增加上下文窗口更容易控制账单。

编程 Agent 的失败与重试成本

编程 Agent 的真实成本，往往不是最后一次成功请求的价格，而是整条链路的累计消耗。一次任务可能包含：

• 规划请求；
• 文件搜索或代码检索；
• 第一次修改；
• 测试失败后的诊断；
• 第二次修改；
• 工具超时后的续跑；
• 最终验证和总结。

如果只在账单中保留最后一次成功响应，就会把前面的失败请求全部丢掉。对于三款模型，必须用“端到端完成一次任务的总消耗”比较，而不是用单次请求的 Token 数比较。

限流、超时和工具错误也要进入任务日志。它们不一定直接增加模型单价，却可能造成排队、续跑和额外重试；如果 Agent 在错误后重新发送完整上下文，增加的输入 Token 也会直接进入账单。

为什么 Agent 的实际 API 支出，常常会超过价格表中的一次调用估算？

因为价格表通常只计算一次输入和一次输出，而 Agent 账单还包含失败请求、工具返回内容、超时重试、上下文重新发送和验收不通过后的返工。尤其是工具失败后重新发送完整代码库时，输入与缓存字段都会发生变化。

我们建议把一次 Agent 任务定义为：

任务开始 → 获得工具权限 → 完成修改 → 测试通过 → 结果交付

只要中间任何一步失败并重新调用模型，就继续累计同一个 task_id 的所有费用。工具服务、代码执行环境、网络搜索和数据库查询产生的费用，则在账单中单独列栏，避免误以为全部是模型 Token 成本。

采购前的条件分支

数据不足时，不要给 Qwen3.8-Max、Kimi K3 和 DeepSeek V4 强行排总榜。更合理的决策方式是按条件回退：

• 若主要是低频试用，且套餐 Credits 尚未用完，先看每个成功任务消耗多少 Credits，不要急着换算 Token 单价。
• 若请求量稳定、任务结构重复，优先比较每个成功任务的有效成本，并观察缓存命中率是否持续，而不是只看一次账单。
• 若工作流包含长文档或大型代码库，至少完成冷启动、连续会话和上下文变更三组测试，再判断缓存是否真的带来节省。
• 若工作流是编程 Agent，把失败、重试、工具调用和测试不通过全部纳入同一个任务账单。
• 若 API 成本波动、数据控制或服务连续性已经超过团队容忍边界，再进入开放权重模型与自托管算力评估。
• 若需要临时试跑、跨模型验证或短期 Agent 环境，可以先参考 Qwen3.8-Max 预览额度与成本记录，再决定是否搭建独立运行环境。

如果团队准备把本地模型、API Agent 和自动化脚本放到远程环境中，硬件与交付方式也要独立核算，不要把云端 Mac 的租赁费用混入模型 Token 账单。可以先查看 JexMac 的方案与计费页面，确认按月使用、临时测试和持续运行分别对应什么资源，再与 API 成本表并列。

从试用账单走向部署选择

本周可以按下面的顺序完成一次可复用的账单归一化：

1. 为三款模型建立独立的 model_id、版本和账单周期字段。
2. 从控制台或 API 响应导出输入、缓存输入、输出和工具调用数据。
3. 为每类任务定义成功标准，并给每次请求分配同一个 task_id。
4. 将失败请求、超时、429、模型自主重试和人工续跑全部关联到原任务。
5. 分别完成冷启动、连续上下文和上下文变更测试。
6. 计算每个成功任务的总成本，不填入无法由官方规则或真实日志验证的价格。
7. 连续观察一周，再决定是继续使用套餐、切换 Token API，还是评估自托管。

相比直接购买某个套餐，当前“看到价格就选模型”的做法有三个真实缺点：无法解释 Credits 到底消耗在哪里；无法识别缓存失效和长输出造成的成本上升；也无法把 Agent 重试、工具费用和环境连续性放进同一张预算表。对于只需要短期验证或跨模型测试的团队，租赁 JexMac 的 Mac 环境可以把部署时间、远程访问和临时算力单独管理，避免为了几轮 API 对比就提前购买一套长期闲置的设备；但如果业务是长期稳定重负载、必须控制全部数据或依赖专用物理接口，自购设备或自建算力仍然更合适。

真正开始采购前，先导出一周 API usage 与任务成功记录，按照本文字段完成一次账单归一化。只有当重试成本、环境连续性或自托管验证成为主要变量时，再把云端 Mac 的 Agent 部署与算力验收纳入下一轮决策。