仪表盘显示 7 天消耗 4 亿 token,看似吓人——但拆开看,真实成本一个月才几十块。 现象 hermes insights 显示: 输入 477 万 + 输出 92 万 Total 4 亿(对不上?) 真相:Total = 输入 + 输出 + 缓存读 + 缓存写 + 推理 4 亿的真实构成: 项目 数量 占比 缓存读取(cache read) 3.99 亿 98.6% 输入 447 万 1.1% 输出 76 万 0.2% 推理 33 万 0.08% “4 亿"几乎全是缓存读取——不是真的消耗了 4 亿新 token。 为什么有这么多缓存读 长会话场景(如 QQ 单窗口聊天):每轮对话都要把整个会话历史重新发给模型。但历史大部分没变,被**上下文缓存(cache)**命中——服务端只收极低的缓存价,不重新计费。 单轮实测:发一条消息,输入 2,421 token,但缓存读 23 万(整个历史)。 成本换算 按 DeepSeek V4-Flash 价格(涨价前): ...
一次 82 页 PDF 提取烧掉 84 credits(月度免费额度的 8.4%),血的教训。 计费规则(官方确认) 操作 消耗 搜索 2 credits / 10 条结果(向上取整) HTML 提取 1 credit / 页 PDF 提取 按页计费(82 页 ≈ 84 credits) 搜索+自动抓正文 搜索 2 + 每结果 1 credit 免费额度:1000 credits/月。 教训 PDF 绝对不要直接扔给 Firecrawl 提取——按页计费,一个几十页的 PDF 就能烧掉月度额度的百分之几到十几。 正确做法 PDF → curl 下载到本地 → 本地解析(pymupdf/read_file) → 免费 HTML → Firecrawl(1 credit/页) 或 curl 搜索 → DeepSeek 服务端(不耗 Firecrawl 额度) 实测对比: 82 页 PDF 扔 Firecrawl:84 credits 同 PDF curl + 本地解析:0 credits 为什么 Firecrawl 搜索也烧额度 Firecrawl 的搜索默认会抓每个结果的正文(“search + extraction in one call”)——一次搜索 10 条结果 = 2(搜索)+ 10(抓取)= 12 credits。所以搜索密集场景要小心,最好用纯搜索服务(如 DeepSeek web_search)。 ...