token_counter charges 85 tokens for images priced with the default auto detail

快速结论：当 LiteLLM 对未显式传入 detail 的图片（默认即为 auto）做 token 估算时，会把大图按 low 档计费，只返回 base_tokens，导致高分辨率图片被严重低估；优先检查 litellm/litellm_core_utils/token_counter.py 中 calculate_img_tokens 的 auto 分支是否仍被当成 low 处理。

适用环境：LiteLLM 主分支（验证于 commit ebf829c2）、Python 3.11、使用内置 tiktoken encoding；图片格式为 PNG data URL；模型为 gpt-4o；验证过程未发起网络请求。

最快修复方案：升级到包含 PR #48526 的 LiteLLM 版本。该 PR 已合并并关闭本 Issue，是 Issue 中确认的修复来源。

注意事项：Issue 未给出具体发布版本号，升级前请确认所用版本已包含 #48526 的改动。该问题只影响大于单个高分辨率 tile 的图片；256×256 这类小图在 auto 与 low 下结果一致，属于正常表现。

问题场景

使用 LiteLLM 对包含图片的 GPT-4o 消息做 token 估算（例如调用 token_counter 相关逻辑为请求预估计费）时，如果图片没有显式传入 detail，也就是走默认的 auto 路径，即使图片尺寸为 1024×1024，消息 token 数也远低于实际应按分块计算的值。调用方传入 detail: high 时结果正常，传入 low 或省略 detail 时结果几乎相同。

报错原文

token_counter charges 85 tokens for images priced with the default auto detail

gpt-4o, 1024x1024 png as a data url
detail missing (auto): 92 tokens for the message
detail high:          772 tokens
detail low:            92 tokens

原因分析

根据 Issue 描述，calculate_img_tokens 对 low 和 auto 都直接返回 base_tokens，因此默认路径从不叠加 tile 成本。也就是说，auto 没有像预期那样按图片尺寸走分块计价，而是退化成了 low 的行为。256×256 图片在 auto 与 low 下均为 92 token 且结果正确，说明问题只出现在大于一个高分辨率 tile 的图片上。

环境排查

确认 LiteLLM 版本或 commit，是否已包含 PR #48526 的修复；Issue 验证基线为 ebf829c2。
确认 Python 版本为 3.11（Issue 验证环境）。
确认是否使用内置 tiktoken encoding，而非自定义编码或离线缓存。
确认测试图片的尺寸：大于单个高分辨率 tile 的图片才会暴露该问题。
确认调用时是否显式传入 detail；省略 detail 即走 auto 路径。

解决步骤

确认当前安装的 LiteLLM 是否早于 PR #48526 合并的版本。
将 LiteLLM 升级到包含 #48526 的版本；Issue 未给出具体版本号，请以该 PR 的合并记录为准。
升级后，在相同环境下用 1024×1024 PNG data URL、gpt-4o、省略 detail 的场景重新做 token 估算。
如果无法升级，可优先尝试的临时规避方式是在调用时显式传入 detail: high，让图片走分块计价路径；但这是推测性规避，Issue 未验证其作为修复方案。

验证方法

在与 Issue 相同的条件下重新估算：省略 detail（auto）时，1024×1024 图片的消息 token 数应与 detail: high 的结果一致（Issue 中为 772 tokens），而不再等于 low 的 92 tokens。同时确认 256×256 图片的结果仍与 low 一致，以避免引入回归。