事情本身不复杂，线索都在日志里。知识库 42 万份文档，按每份 0.0001 元估 embedding 成本，预算 42 元，实际账单 118 元；文档平均 1800 字，切块后变成 3.2 块，按条数估完全漏掉了切块。
第一反应是「中文字符与 token 的比例不是 1 比 1」，验证下来不成立。
把日志和配置对完，能解释这个现象的基本就这几处。计费按 token 不按文档条数。也可能是切块后每块单独计费，重叠部分还要再算一次。
不容易想到的是，重建索引时重复调用了两次。
先用 tiktoken 统计真实 token 数
python -c "import tiktoken;e=tiktoken.get_encoding('cl100k_base');print(len(e.encode('退款流程需要几个工作日')))"然后按切块后的块数重新估算总量
python count_chunks.py --input corpus/ --size 512 --overlap 50接着对比账单里的 usage 与本地统计
python -c "print({'local_tokens':185000000,'billed_tokens':262000000})"末了在入库前去重并记录重建次数
python dedupe_docs.py --input corpus/ --report dedupe.json恢复的判定其实很直接。本地统计的 token 与账单 usage 误差小于 3%，预算按 token 重算后与实际支出一致，重建索引不再重复计费。
补一句。embedding 的计费单位是 token，切块和重叠都会放大总量；估算时先算块数再乘平均 token，按文档数估通常差三到四成。这类问题最好一次改到位，反复小改反而容易把原因搅混。