Qwen3.5-OCR DashScope routing：OpenAI 兼容文档 AI 与协议取舍

Qwen3.5-OCR DashScope routing 正在成为文档 AI 团队的新运营问题：它不只是一次文字识别模型更新，而是把扫描件、票据、证照、表格和 PDF 抽取放进可路由、可治理的生产 API 体系。阿里云百炼 / Model Studio 的模型上下架页面将 qwen3.5-ocr 列为 6 月 16 日上线模型；官方 Qwen-OCR 文档也把它描述为面向文档解析、文字定位、关键信息提取、表格、公式、多语言 OCR 和 PDF 工作流的升级路径。真正影响工程团队的是：同一个模型可以通过 OpenAI 兼容 Chat Completions、OpenAI 兼容 Responses 和原生 DashScope SDK 调用，但这些路径暴露的控制能力并不相同。

发生了什么

阿里云百炼将 Qwen-OCR 定位为专门从扫描文档、表单、票据、卡证、表格和多语言图像中提取文本与结构化数据的视觉模型系列。官方指南说明，qwen3.5-ocr 基于 Qwen3.5 架构，在文档解析、文字定位和信息抽取方面升级，支持多轮对话，也支持 PDF 文档解析；同时，它被建议作为早期 Qwen-VL-OCR 快照之后的迁移方向。

这页文档对 routing 设计尤其关键，因为它同时列出三种 API surface：

• OpenAI 兼容 Chat Completions：使用 model: "qwen3.5-ocr" 和多模态 image_url 内容。
• OpenAI 兼容 Responses：使用 model: "qwen3.5-ocr"、图片 / PDF 输入和 input_text prompt。
• 原生 DashScope SDK / HTTP：通过 MultiModalConversation 调用，并暴露图像旋转处理、内置 OCR task 等更专用的控制项。

阿里云也明确指出了限制：使用 OpenAI SDK 的团队迁移最快，但图像旋转矫正、内置 OCR task 等高级功能不能直接用普通 OpenAI 兼容参数调用，往往需要用 prompt 模拟或在后处理中解析。这就是 operator 必须写进策略的分界线。

为什么对 AI 工程团队重要

OCR 工作负载经常在出事故之前都显得很低调。收据、身份证、合同扫描件或银行流水进入抽取模型；下游业务逻辑假设输出是结构化且准确的；然后一个地域 endpoint 配错、输出 token 上限不足、图片旋转未处理，或弱能力 fallback 被悄悄触发，就会污染后续流程。Qwen3.5-OCR DashScope routing 给了团队更多选择，也要求 AI gateway 具备更细的 capability awareness。

最大的变化是，文档 AI 越来越像模型 routing，而不是离线 ETL。请求里包含模态、图像像素预算、PDF eligibility、预期 JSON 结构、最大输出长度、地域，以及调用方是否需要内置 OCR task metadata。一个普通 /v1/chat/completions proxy 可以转发简单截图，但未必能保留生产文档 Pipeline 需要的 DashScope 专有控制项。

地域策略同样重要。阿里云 OCR API 参考将北京、新加坡、弗吉尼亚等 endpoint 分开，部分地域还使用 workspace 级 hostname。能在北京兼容 endpoint 使用的 provider key，不代表可以直接打到新加坡 workspace endpoint。对受监管的文档工作流来说，这不是部署细节，而是数据驻留和审计能力的一部分。

路由与运维视角

Qwen3.5-OCR DashScope routing 给 router 的启示是：把文档抽取拆成能力车道，而不是把 OCR 当成一个模型 ID。安全策略至少应区分四种情况。

1. 简单图片转文本。 当输入是普通图片、调用方只需要纯文本或 prompt 约束的 JSON，并且现有 SDK 兼容性比原生 task 控制更重要时，使用 OpenAI 兼容 Chat Completions。
2. PDF 与 Responses-native agent。 当应用已经标准化在 responses.create、需要把图片 / PDF 放进 agent workflow，并且可以接受较简单的 OCR 控制面时，使用 Responses surface。
3. 高精度文档解析。 当工作负载需要 ocr_options、图像旋转处理、文字定位、表格 / 公式解析，或不能只靠 prompt 模拟的内置 OCR task 输出时，优先使用原生 DashScope。
4. Fallback 与异常处理。 除非调用方明确标记为 best-effort，不要从原生 OCR 静默 fallback 到普通视觉聊天模型。丢失旋转矫正、PDF 支持或结构化 OCR 字段，有时比返回一个类型化失败更危险。

日志中也应该能看到这些运营 metadata：API surface、region、model alias、pixel budget、PDF usage、requested task type、fallback outcome，以及输出来自原生 OCR task 还是 prompt-only workaround。TheRouter AI routing documentation 可以作为把这些字段纳入 route policy 的基线；当文档摄取演变成带重试和可观测状态的队列 Pipeline 时，async media job guide 也能提供 job lifecycle 的参考。

TheRouter 用户应关注或尝试什么

在把生产文档送进模型之前，先建立一张 Qwen3.5-OCR DashScope routing matrix。对每类工作负载记录文档类型、是否允许 PDF、期望输出格式、必需地域、对旋转图像的容忍度、最大输出长度，以及是否需要原生 OCR task metadata。然后把每一行映射到 Chat Completions、Responses 或原生 DashScope，而不是让应用临时选择。

接下来，增加能保留语义的 fallback 规则。旋转的证件扫描件不应 fallback 到无法矫正方向的便宜模型。PDF 抽取请求不应在没有可见错误的情况下 fallback 到 image-only 路径。JSON 抽取工作流应该在下游系统接受结果之前做 schema validation。

最后，分开测试 pinned alias 和 floating alias。qwen3.5-ocr 方便持续获得更新，但文档抽取对细微行为变化非常敏感。如果工作流会把发票、合规表单或身份证件送入自动化，尽量使用已验证的 model snapshot，并保留一组真实文档回归集。Qwen3.5-OCR DashScope routing 可以降低接入摩擦，但前提是 gateway 保留让这个模型在生产中真正有用的协议、地域和 OCR 专用控制项。