DeepSeek image-token estimator on the v41 calculator
DeepSeek 图片 token 估算器改用 v41 计算器
`deepSeekImageTokens()` in `llm-deepseek` ported the provider's published image-token calculator in its `v4` configuration: a 384×384 scale-up floor, a 384-token cap, an 8:1 width clamp, a grid layout that adds a row for odd row counts and parity corrections, and a pad-to-4 alignment charged at its worst case. The provider's Vision guide now documents a different projection for the current Flash model: images below r
English
Problem
deepSeekImageTokens() in llm-deepseek ported the provider's published image-token calculator in its v4 configuration: a 384×384 scale-up floor, a 384-token cap, an 8:1 width clamp, a grid layout that adds a row for odd row counts and parity corrections, and a pad-to-4 alignment charged at its worst case. The provider's Vision guide now documents a different projection for the current Flash model: images below roughly 544×544 total pixels scale up, larger images scale down to roughly 1300×1300 total pixels, and one image costs at most 1024 tokens. The published calculator carries this as a v41 configuration and the docs page instantiates that one. The old port underprices an 800×800 request image by 73 tokens, which can delay automatic compaction in sessions containing these images. The error depends on dimensions: a 640×480 image is overestimated by 3 tokens.
Decision
image-tokens.ts is rewritten as a verbatim port of the v41 configuration. The constants are a 14px patch, 3:1 per-axis downsampling, a 544×544 total-pixel floor, and a 1024-token cap. The grid formula is rows × (cols + 1) + 2 with no odd-row extra row, no parity correction, and no even-row trimming in the solver. There is no alignment pad, so the estimate is exact rather than a worst-case upper bound, and there is no aspect-ratio clamp, so extreme aspect ratios reach the cap through the solver's one-row and one-column branches. The over-budget path is a single closed-form solve followed by the published assertion; the decrementing retry loop existed only for the odd-row layout. The provider's fixpoint iteration over the projected dimensions is unchanged.
The test vectors are re-pinned from the published calculator. The request-pricing tests, package README, and this note carry the new numbers. This change left the 640,000 total-pixel projection the harness applied before pricing and the catalog model ids as they were; the successor later replaced that projection with the same grid, so omitting imagePixelBudget now projects onto the token grid while a positive integer or low keeps a total-pixel budget.
Alternatives considered
Keep both configurations and select by model id. The provider states that requests to the retired deepseek-v4-flash-vision-exp id are served by the current Flash model, so no reachable route prices under the old configuration. Two configurations would keep dead branches and their tests alive.
Keep the generic class with the isNLayout, pad, and ratio-clamp switches. A one-configuration port has fewer unreachable branches to exclude from coverage and states the shipped rule directly; a future provider revision changes this one module and its pinned vectors either way.
Raise the harness pixel budget in the same change. The provider now accepts roughly 1300×1300 total pixels per image, so the harness's 640,000-pixel projection discards detail the model could use. That is a request-content change with its own snapshot impact, separate from pricing what is actually sent.
Consequences
An 800×800 request image costs 422 tokens instead of 349, while a 640×480 image costs 206 instead of 209 and a low-budget 512×512 image costs 184 instead of 201. Compaction pressure changes with the retained image dimensions. The request projection later moved onto the same grid (successor), so the 640,000-pixel budget that made a square request image cost 422 tokens no longer applies. The estimate no longer carries a three-token conservative margin; provider usage remains the authoritative anchor once a request completes. Sessions replayed through llm-replay use their fixture's imageRequestTokens and are unaffected.
中文
问题
llm-deepseek 中的 deepSeekImageTokens() 移植的是提供方公开图片 token 计算器的 v4 配置：384×384 放大下限、384 token 上限、8:1 宽度钳制、奇数行数额外加一行并做奇偶校正的网格布局，以及按最坏情况计价的 pad-to-4 对齐。提供方的图像理解指南现在为当前 Flash 模型记录了另一套投影规则：总像素小于约 544×544 的图片放大，更大的图片缩小到约 1300×1300 总像素，单张图片最多 1024 token。公开计算器以 v41 配置承载这套规则，文档页实例化的也是它。旧移植对一张 800×800 的请求图片低估 73 token，可能使包含这类图片的会话延迟触发自动压缩。误差取决于尺寸：一张 640×480 的图片会被高估 3 token。
决策
image-tokens.ts 重写为 v41 配置的逐句移植。常量为 14px patch、每轴 3:1 降采样、544×544 总像素下限、1024 token 上限。网格公式为 rows × (cols + 1) + 2，没有奇数行额外行、没有奇偶校正、求解器也不再把行数截成偶数。没有对齐 pad，所以估算值是精确值而非最坏情况上界；没有宽高比钳制，所以极端长宽比会经求解器的单行和单列分支到达上限。超预算路径是一次闭式求解加上公开的断言；逐步递减的重试循环只服务于奇数行布局。提供方对投影尺寸的定点迭代保持不变。
测试向量按公开计算器重新固定。request-pricing 测试、包 README 和本 note 使用新数字。本次改动保留了 harness 在定价前应用的 640,000 总像素投影和 catalog 模型 id；后续决策把该投影换成了同一套网格，现在省略 imagePixelBudget 走 token 网格，正整数或 low 仍走总像素预算。
备选方案
保留两套配置并按模型 id 选择。 提供方说明发往已下线的 deepseek-v4-flash-vision-exp 的请求由当前 Flash 模型承接，所以没有可达路由会按旧配置计价。两套配置会保留死分支及其测试。
保留带 isNLayout、pad 和宽高比钳制开关的通用类。 单配置移植需要从覆盖率中排除的不可达分支更少，并直接陈述已上线的规则；提供方未来再修订时，两种写法都只改这一个模块和它固定的向量。
在同一改动中提高 harness 像素预算。 提供方现在每张图接受约 1300×1300 总像素，harness 的 640,000 像素投影会丢弃模型本可利用的细节。那是请求内容的改动，有自己的快照影响，与为实际发送内容计价是两件事。
后果
800×800 请求图片的计价从 349 变为 422 token，640×480 图片从 209 变为 206，低预算下的 512×512 图片从 201 变为 184。压缩压力随保留图片的尺寸变化。请求投影后来改为同一套网格（后续决策），让正方形请求图片计 422 token 的 640,000 像素预算已不再适用。估算值不再带 3 token 的保守余量；请求完成后，提供方 usage 仍是权威锚点。经 llm-replay 回放的会话使用各自 fixture 的 imageRequestTokens，不受影响。