结论
- 批处理运行前必须算成本，因为一次糟糕重试循环会放大花费。
- cache-hit、cache-miss 和 off-peak 假设要用当前 DeepSeek 官方价格。
- 只有验证通过且重试不多时，便宜路线才是真的便宜。
- 准备 Qwen、GLM 或网关 fallback，应对调价、限速或验证失败。
怎么做
- 估算每个 item 的输入 tokens、输出 tokens、cache 命中率、重试率和验证失败率。
- 每次大规模定时运行前，检查 DeepSeek 当前官方 pricing 页面。
- 先跑 100 个 item 样本，测 accepted outputs、无效 JSON、延迟和真实单 item 成本。
- 只对失败 item 比较一条 Qwen 或 GLM fallback。
- 批处理需要路线日志、硬上限和 provider 切换时，用 OpenLLMAPI 或网关。
推荐路径对比
| 平台 | 免费/额度 | 适合 |
|---|---|---|
| DeepSeek | 核验官方价格 | 低价批量推理、抽取和总结 |
| 通义千问 | 注册额度变化 | 中国大陆友好长上下文批处理 fallback |
| 智谱 GLM | 注册 tokens 变化 | 国产结构化输出 fallback |
| LLM 成本计算器 | 免费工具 | 批处理运行前预算估算 |
| OpenLLMAPI | 体验额度变化 | 批处理路线日志、硬上限、fallback 和 provider 切换 |
自有平台承接
批处理靠上限运行，不靠运气
把 DeepSeek、Qwen、GLM 放到一个 endpoint 后，用硬预算、验证感知 fallback 和单 item 成本日志控制批处理。
FAQ
能依赖旧 DeepSeek 价格截图吗？
不能。大批处理前要看官方 pricing 页面，因为 token 单价、cache 规则或 off-peak 条款可能变化。
批处理为什么会变贵？
大输入、长输出、低 cache 命中、结构化输出无效、重试和 fallback 风暴都会放大成本。
什么时候跑 fallback？
只在明确验证失败、超时、限速、JSON 无效或低置信后触发。不要默认每个 item 都 fallback。
应该追踪什么指标？
每个成功 item 成本、无效输出率、fallback 率、重试次数、cache 命中率和总批次预算消耗。