[成本不可审计] web_search 默认走 DeepSeek 服务端检索：主模型是 MiniMax，2,717 次搜索却产生 2877 万 token（¥68.30），session 日志里没有任何 usage 记录

[TooXu]

摘要

📌 2026-10-23 更新：初版的搜索次数只统计了 GUI 导出包（1,833），已用本地归档复核更正为 2,717，并补充了与官方价目的对账。

我特意把会话主模型换成了 minimax1/MiniMax-M3.1-Flash，但 web_search 工具每次调用都在调 DeepSeek 自己的模型（deepseek-v4-flash，服务端 web_search_20250305 工具），而 UI 上没有任何地方提示这件事。更糟的是，这些调用的 token 用量在导出的 session 日志里一条都没有——因为它在代码层就被丢弃了。

结果是：用户在自己的会话里看不到、归因不了、审计不了这笔开销；账单只能到 DeepSeek 控制台看，而控制台按 deepseek-flash 归集，无法与任何具体会话对应。

另外附带一个可能影响更广的发现：DeepSeek 一方接口的每次搜索，注入量约为第三方网关的 5.2 倍（下方数据），也就是说社区里流传的"一次搜索约 2,000 token"这个量级，对一方接口是不成立的。

环境

项	值
DSH 版本	0.2.1-rc.2（桌面版，macOS arm64）
profile	desktop
会话主模型	minimax1 / MiniMax-M3.1-Flash（request/context 事件确认，contextWindow 262144）
搜索 provider	dsh-web-search-deepseek（ctx.web 未配置 searchProvider，"恰好一个可用提供方"自动选中）
搜索模型	deepseek-v4-flash @ https://api.deepseek.com/anthropic/v1/messages，max_tokens: 4096、max_uses: 5、thinking: disabled
凭据归属	会话 provider 是 minimax1，故走 DEEPSEEK_API_KEY，记在 API Key 账上，不是账号额度

现象

两个会话（同一调研任务的两次运行），主模型都是 MiniMax：

会话	web_search 工具调用	拆出的 DeepSeek API 请求	session 日志里的 DeepSeek usage
session-df66b404	77	231	无
session-75de343e	518	1602	无
合计	595	1833	0 条

但这两个父会话的 GUI 导出包并不覆盖全部会话。改用本地归档 ~/.dsh/sessions/**/*.session.v4.jsonl.zstd（含全部父会话与子 Agent 会话，2026-09-22 ~ 2026-10-21 共 57 个会话文件）重新统计：

口径	搜索次数
期间合计（2026-09-22 ~ 2026-10-21）	2,717
其中 2026-10-21 单日	2,470
上述两个父会话的 GUI 导出包	1,833

去重按 (time, 查询文本) 指纹比对，2,717 条零重复。

上表 1,833 是这两个父会话自身发出的次数；全量 2,717 次里有相当一部分来自同期的其它会话。

DeepSeek 控制台 2026-10-21 的计费：

28,769,009 token  →  命中缓存 1,164,544 / 未命中缓存 25,430,209 / 输出 2,174,256
费用 ¥68.30，全部归在 deepseek-flash 名下

摊到单次搜索（按 10-21 当天 2,470 次）：

未命中缓存输入  25,430,209 / 2470 ≈ 10,296 token/次
命中缓存输入     1,164,544 / 2470 ≈    471 token/次
输出            2,174,256 / 2470 ≈    880 token/次
合计                          ≈ 11,647 token/次

为什么能断定这 28,769,009 token 全部来自搜索通道：当天 41 个 request/context 事件的 provider 全部是 minimax1，零个 DeepSeek 主模型会话——也就是说我自己一次 DeepSeek 主模型都没调用，这笔账只可能来自搜索。

与官方价目对账（DeepSeek 价目表，峰时：输入未命中 ¥2/M、输入命中 ¥0.02/M、输出 ¥8/M）：

命中缓存 1,164,544 / 1e6 × ¥0.02 =  ¥0.023
未命中  25,430,209 / 1e6 × ¥2    = ¥50.860
输出     2,174,256 / 1e6 × ¥8    = ¥17.394
                                    ────────
                                    ¥68.28   vs  账单实际 ¥68.30

偏差 0.03%——账单可以被搜索通道 100% 解释。峰时窗口为北京时间工作日 9:00–12:00 / 14:00–18:00，而 10-21 这两次运行正落在 14:58–16:47（= 06:58–08:47 UTC），与峰时吻合。

另：第三方网关对同族模型 deepseek-v4-flash-0731 的服务端 web_search 实测为 2,059 input / 169 output（约 2,000 token 注入结果）。DeepSeek 一方接口摊出的是它的 5.2×——一方接口注入的检索结果体量明显更大（应为整页正文而非摘要）。按"每次搜索约 2,000 token"做成本预估，对一方接口会低估 5 倍。

根因

1. 用量在代码层就被丢弃了，不是"日志没记"：

   packages/web/web-search-deepseek/src/index.ts

   return mapAnthropicResponse(await response.json());

   function mapAnthropicResponse(response) {
     const blocks = response.content ?? [];
     ...
     return { sources, truncated: false };   // ← 从不读 response.usage
   }

   事件侧只有 recordRequest，只记请求体三键（endpoint / apiVersion / body），没有 recordUsage。于是 web/deepseek-search-llm-request 事件的 data 里永远没有 usage。

2. UI 不暴露搜索 provider。模型选择器只反映主模型，ctx.web 的 provider 选择对用户不可见；dsh-web 的 README 写明"未设置时仅在恰好一个可用时自动选择"，而发行版只随包发布了一个搜索提供方（README 示例里的 dsh-web-search-exa 并未随包发布），所以等价于"强制走 DeepSeek"。

3. 存在不烧模型 token 的替代后端，但开关默认关闭。dsh-web-deepseek-api 提供专用 Search/Fetch API（https://api.deepseek.com/v1/tools/search），"每次操作只发起一次直接请求，无需辅助模型请求"。UI 路径是 插件 → 官方分组 → 网页搜索 → 「启用新版 Web 搜索 API」，默认关闭（关闭时 = Messages 模式 = 每次搜索烧一次模型轮次）。

影响

• 选了 MiniMax 做主模型的用户，实际在为 DeepSeek 的搜索通道付费，且没有任何界面或日志能告诉他这件事。
• 账单只能到 DeepSeek 控制台去看，而控制台只按 deepseek-flash 归集，无法与具体会话对应——这次我是靠 session 日志里的 web/deepseek-search-llm-request 事件反推才定位到的。
• 研究型任务搜索密度极高（本例 1,076 个推理回合伴随 2,717 次搜索），这块隐藏成本很容易超过主模型本身。
• 更直接的对比：10-21 当天主模型的非缓存 token 只有 12,810,409，而搜索通道是 28,769,009 —— 隐藏的搜索开销是主模型非缓存用量的 2.25 倍。

建议

1. 把用量记进 session：让 mapAnthropicResponse 透传 response.usage，事件侧补 recordUsage（或扩展 web/deepseek-search-llm-request 带上响应 usage）。这样导出的 session 就能自证成本。
2. 在 UI 上暴露搜索 provider 与其累计消耗：至少在模型选择器旁标明"网页搜索由 <provider> 提供"，并显示该 provider 的 token 累计值，让"设了主模型"不再等于"只会用到主模型"。
3. 评估把「启用新版 Web 搜索 API」改为默认开启，或在检测到当前是 Messages 模式时明确提示"每次搜索将额外消耗一次模型调用"。

复现步骤

1. 会话主模型选 minimax1/MiniMax-M3.1-Flash，~/.dsh/profiles/desktop/cordis.patch.yml 中 web 插件不设 searchProvider。
2. 触发任意 web_search 工具调用。
3. 导出 session，检索 web/deepseek-search-llm-request 事件：能看到 body.model = "deepseek-v4-flash" 和完整请求体，但 data 里没有 usage。
4. 对照 DeepSeek 控制台同一时段的 deepseek-flash 计费行——对得上，但 session 里没有任何线索指向它。
5. 用本地归档 ~/.dsh/sessions/** 复核全量搜索次数（本次 2,717 次），确认 GUI 导出包只覆盖其中一部分。

---

English summary

web_search silently routes to DeepSeek's own model (deepseek-v4-flash) via the server-side web_search_20250305 tool, while the session's main model is MiniMax. Worse, the token usage of those calls is discarded in code (mapAnthropicResponse() returns only {sources, truncated} and never reads response.usage; the event side has recordRequest but no recordUsage), so the exported session.v4.jsonl contains no usage for any of them.

Correction to the first version of this post: the initial 1,833 count came only from the two parent sessions in the GUI export. Re-counting over the full local archive (~/.dsh/sessions/**, 57 session files) gives 2,717 searches for 2026-09-22 ~ 2026-10-21, of which 2,470 fall on 2026-10-21 — the day DeepSeek's console shows 28,769,009 tokens / ¥68.30 charged to deepseek-flash. Deduplicated by (time, query text); zero duplicates.

That attribution is exact rather than inferred: all 41 request/context events that day carry provider minimax1 — zero DeepSeek main-model sessions — so the entire bill can only come from the search channel. Priced at DeepSeek's own peak rates (input cache miss ¥2/M, input cache hit ¥0.02/M, output ¥8/M) the same 28,769,009 tokens come to ¥68.28 vs the ¥68.30 actually billed — a 0.03% deviation. Amortized, that is ~11,647 tokens per search, about 5.2× the 2,059 measured for the same model family through a third-party gateway, so DeepSeek's first-party endpoint appears to inject substantially more page content per search. For scale: the main model's non-cached usage that day was 12,810,409 tokens — the hidden search channel was 2.25× that.

Asks: (1) record response.usage in the session event so search cost is auditable; (2) surface the active search provider and its cumulative spend in the UI, since picking a main model does not mean only that model is used; (3) consider defaulting the dedicated Search API on, which needs no auxiliary model request, or at least warn that Messages mode costs one model call per search.

[WhAIthere]

我也遇到这个问题了，我的dsh调查结果，似乎search会被认为是工具，而不会记录usage字段，dsh检查了底层程序，工具在调用api之后把返回的总结后的文本收下，把usage之类的东西全丢掉了_ (°ω°｣∠) _

所以我让dsh写了个插件，截取search的工具过程，从中获取了usage单独记账了什么的，这个search大量使用的开销绝对非常大，所以现在只能让dsh暂时减少web_search使用了，相对比之下它只是可以减少上下文占用什么的，但是会出现坏账，目前好像只能靠额外插件解决，而且似乎按照现在的记录模式的话，似乎甚至没办法往里面记这个账的样子，因为现在的session文件结构根本没给工具留存usage的位置_(:з」∠)_

话说GitHub的评论怎么对颜文字这么不友好，我的颜文字预览效果都好丑😭

[drscrewdriver]

啊这 欢迎用https://github.com/drscrewdriver/dsh-union-search 走bing不要钱

[drscrewdriver]

顺便带html dom markdown解析

[aaronlei]

当初为了给deepseek web_search单独配置key方便观察，写了个插件，https://github.com/aaronlei/dsh-web-search-diy

[WhAIthere]

哦？谢谢，我现在用的好像就是这个诶_(°ω°｣∠)_ Graphienerg ***@***.***