流式输出和嵌入模型怎么影响账单：两个容易被忽略的成本项

流式输出不改变输出 token 计费逻辑

流式输出是指模型逐 token 产生、按 SSE（Server-Sent Events）分块返回给客户端。DeepSeek 的 API 文档写明：开启 stream 参数后，增量片段会以 data: 事件流式下发，最后一片携带 usage 字段，里面的 total_tokens 覆盖整个请求的 prompt 与 completion 之和。这意味着：无论是否流式，计费依据始终是完整请求的输入 token 与输出 token 总量。流式只改变返回方式，不改变计费口径。

在估算台里，输出 token 一栏直接填写单次请求的完整输出总量即可。默认值已包含流式与非流式两种情况的输出总量，无需因流式而单独调整。复核时，对照供应商返回的 usage 字段中的 completion tokens 与工具填入的输出 token 是否一致即可。

嵌入与多模态模型走独立单价表

嵌入、重排序、向量检索等模型不属于对话生成类。阿里云百炼的模型大全把「向量与重排序」单独列为一类，与「文本生成」并列。Cohere 的价目同样把 Command（对话）、Embed（向量）、Rerank（重排序）分成三套独立单价，Rerank 甚至按「搜索单元」而非 token 计费。这些模型的输入输出定义、计费单位与单价均与对话模型不同，不能把它们的用量塞进同一组单价里做平均。

因此，估算时必须把不同模型类型拆成独立的估算任务：对话模型走对话模型的输入、缓存、输出单价；嵌入模型走嵌入模型的输入单价（通常只有输入、无输出）；重排序模型走其自身的计费单位。把两类请求合并到一组平均单价，结果必然偏低，且无法复核。

为什么估算台必须分模型类型填写

工具的八个输入框——输入 token、缓存 token、输出 token、每月调用、输入价 / 1M、缓存价 / 1M、输出价 / 1M、重试率 %——对应的是单一模型、单一计费口径的一组参数。单次成本算式为 ((输入 - 缓存)*输入价 + 缓存*缓存价 + 输出*输出价) / 1e6 * (1 + 重试率/100)。这个公式假设输入、缓存、输出共用同一套单价体系。

当同一应用同时调用对话模型与嵌入模型时，两者的单价体系互不兼容：对话模型有输入、缓存、输出三档单价；嵌入模型通常只有输入单价，且数量级往往不同。若强行用一组「平均单价」覆盖两类请求，缓存命中比例、输出占比、重试影响都会被错误稀释，导致单次与月度估算双双偏低。唯一可复核的做法是：为每类模型单独开一张估算表，分别填入对应单价与用量，最后把月度成本相加。

在工具里怎么分开填

• 对话/生成类模型：八个框全填。例如用默认值——输入 12000、缓存 6000、输出 1800、每月 1000 次、输入价 1.00、缓存价 0.50、输出价 4.00、重试 5%——单次约 $0.0170、月度约 $17.01。复核时核对供应商账单中的 prompt tokens、cached tokens、completion tokens 与三个 token 框是否对应。
• 嵌入类模型：仅填输入 token 与输入价 / 1M，缓存 token 与缓存价按 0 填（若供应商无缓存机制），输出 token 与输出价按 0 填，重试率按实际重试情况填。月度成本 = 输入 token * 输入价 / 1e6 * (1 + 重试率/100) * 每月调用。
• 重排序/检索类模型：若按「搜索单元」计费，把「每月调用」改为月度搜索单元数，「输入价 / 1M」改为单价/搜索单元，其余框置 0。若供应商改为 token 计费，则按 token 口径填写对应单价。

把上述三类估算表的月度结果相加，即得到应用层面的总估算成本。每张表的单价均以该模型供应商最新官方文档为准；本站只做估算，不构成报价、采购或财务建议。