快速结论:通过 LiteLLM 的 Anthropic 路由向 Claude 发送 HTTPS PDF 链接(放在 image_url 字段中)时,请求被翻译成 image block 而不是 document block,Anthropic 因文件格式无效或不支持返回 HTTP 400。优先排查 LiteLLM 版本是否已包含 #49708 修复,以及 URL 实际返回的内容类型。
适用环境:LiteLLM;Anthropic 直连路由(anthropic/claude-haiku-5-5);复现基线为 main 分支 373f1752d3,源码检查版本为 main 分支 704e73d6fe27ed299b733d1c39e1ae7757c8fc5e。Issue 未提供操作系统、Python、CUDA、显卡等环境信息。
最快修复方案:升级到已合入 #49708 的 LiteLLM 版本。该 PR 已合并,修复后 HTTPS PDF 的 image_url 会以 document block 发送给 Anthropic。
注意事项:修复必须保留对真实图片 URL 的 image 处理逻辑,包括路径以 .pdf 结尾但实际返回图片的 CDN URL,不能仅凭路径后缀判断类型。Issue 仅记录直连 Anthropic 路由;流式 chat 和 POST /v1/responses 的 PDF input_image 场景也在 #49708 中有记录,升级前建议一并回归。内联 PDF 与 Vertex PDF 路径由 #46984 修复,属于另一条代码路径。
问题场景
用户通过 LiteLLM Proxy 的 /v1/chat/completions 端点,向模型组 c1-anthropic(anthropic/claude-haiku-5-5)发送一条包含 type: "image_url" 的消息,URL 指向一个 HTTPS 托管的 PDF 文件。预期是 Claude 将 PDF 作为文档读取并回答其内容,实际请求失败并返回 400。同一问题在流式 chat 和 POST /v1/responses 使用 PDF input_image 时也被记录。
报错原文
litellm.BadRequestError: AnthropicException - {"type":"error","error":{"type":"invalid_request_error","message":"messages.0.content.1.image.source.base64.data: The file format is invalid or unsupported"},"request_id":"req_011CgejbvAQ42dXt2wZcbUHt"}
LiteLLM: model group 'c1-anthropic' failed with the error above. No fallback was attempted.
HTTP_STATUS:400
原因分析
问题位于 LiteLLM 的 Anthropic 请求翻译层。在 Issue 记录的源码快照中,create_anthropic_image_param(litellm/litellm_core_utils/prompt_templates/factory.py 第 914 行附近)对直连 HTTPS URL 直接返回 type="image",未检查 URL 实际提供的是否为 PDF。因此 PDF 内容被当作图片数据传给 Anthropic,Anthropic 判定格式无效或不支持,返回 invalid_request_error。此前 #46984 只修复了内联 PDF 和 Vertex PDF 路径,未覆盖直连 Anthropic 路由上的 HTTPS PDF URL,这也解释了为什么该场景仍然失败。
环境排查
- 确认 LiteLLM 版本是否包含 #49708。可在源码中查看
create_anthropic_image_param是否仍对 HTTPS URL 无条件返回type="image"。 - 确认所用路由:问题出现在直连 Anthropic 路由,而非 Vertex 路由;单独测试直连路由时不要混用已修复的路径判断。
- 确认请求体结构:PDF 链接是否放在
image_url字段中,并检查是否同时触发流式 chat 或/v1/responses的另一条入口。 - 确认模型组配置中的
model指向 Anthropic 提供商,且api_key由os.environ/ANTHROPIC_API_KEY正确注入。 - 确认测试 URL 实际返回的 Content-Type,尤其是路径以
.pdf结尾的 CDN 链接,避免修复后被误判为图片或文档。
解决步骤
- 记录当前 LiteLLM 版本,可使用 Issue 中的基线(main 373f1752d3)作为对照,先确认问题可稳定复现。
- 使用 Issue 提供的 curl 请求发送 PDF 链接,预期得到上述 HTTP 400 报错,以此确认命中的是 Anthropic 直连路由的翻译问题。
- 升级 LiteLLM 到已合入 #49708 的版本,或合并该 PR 对应的修复提交。
- 重新发送同一请求,确认翻译层将 HTTPS PDF 生成为 document block;图片 URL 仍应走 image block。
- 分别用流式 chat 和
POST /v1/responses的 PDFinput_image做补充验证,确认两类入口行为一致。 - 如有 guardrail 文档回写相关需求,属于 #36524 跟踪的独立入口,不应期待 #49708 一并解决。
验证方法
用 Issue 中的 curl 命令再次请求,若返回 HTTP 200 且模型能正确读出 PDF 文本内容,则修复生效。同时分别发送一个真实图片 URL 和一个路径以 .pdf 结尾但实际返回图片的 CDN URL,确认前者作为 image 处理、后者不被误判为文档。流式 chat 与 /v1/responses 场景也应返回 200 而非 400。
参考来源
AI 工具推荐
想把多个 AI 模型放在一个入口?
GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。
推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。
这个方案解决了吗?
可以继续搜索完整报错,或查看同一工具的其他排查指南。

![[bug]: Windows model import crashes in torch_cpu.dll after repeated Safetensors mmap loads; pread avoids the crash](https://www.chat-gpts.plus/wp-content/uploads/2026/11/9957-ca8cc217-768x403.jpg)
![[Bug]: Go: auto/semi_auto meta_data_filter reports "no match" for an empty filter, and callers handle it in opposite ways](https://www.chat-gpts.plus/wp-content/uploads/2026/11/20533-5bd3ae8d-768x403.jpg)