DSH 模态声明机制与 V4.1 Flash 图像输入
DSH 模态声明机制：V4.1 Flash 图像输入的文本降级路径
- 作者
- DeepSeekAgent.io 编辑部
- 发布
- 更新
DeepSeek V4.1 Flash 支持文本与图片输入，但 DSH 是否把图片发送给模型，还取决于本地模型目录中的模态声明。社区源码分析发现：选择旧模型 ID deepseek-v4-flash 时，供应商可以把请求路由到 V4.1 Flash，DSH 却可能先按文本模型处理附件，把图片替换成一段说明文字。
问题发生在模型请求抵达 API 之前。后端模型具备视觉能力，并不代表本地 Harness 会保留图片数据。
同一后端，不同的本地能力声明
当前 DeepSeek API 推荐使用 deepseek-flash。兼容期内，旧 ID 可能路由到同一个 V4.1 Flash 后端。DSH 模型目录对这些 ID 的声明并不相同：
| 模型 ID | DSH 显示/用途 | inputModalities |
|---|---|---|
deepseek-flash | V4.1 Flash | text, image |
deepseek-v4-flash | 旧 Flash 别名 | 未声明，按文本处理 |
deepseek-v4-flash-vision-exp | 旧视觉实验别名 | text, image |
因此，两个模型 ID 即使最终到达相同后端，在 DSH 内部也可能走不同的附件处理路径。
图片怎样被降级成文字
DSH 在构造请求时先读取模型能力。模型没有声明图片输入时，附件会进入文本模型兼容路径。社区分析把关键链路定位为：
模型 ID
→ 模型目录 inputModalities
→ projectImagesForTextModel
→ textOnlyImageText
→ 文本消息发送到 Provider
projectImagesForTextModel 会为文本模型投影图片内容，textOnlyImageText 生成确定性的文字替代。Provider 收到的是经过处理的消息，而不是原始图片块。
这条路径不会必然报错。请求可以正常完成，模型也会正常返回文字，因此用户看到的现象通常是：模型忽略图片细节、像没有看到附件，或者只回应附件存在的信息。
诊断时检查四层
1. 当前选择的模型 ID
在 Models、Profile 或 Session 设置中确认实际 ID。显示名称写着 V4.1 Flash 仍不够，关键字段应为：
deepseek-flash
2. 模型目录声明
检查该条目是否明确包含：
{
"inputModalities": ["text", "image"]
}
自定义 Provider 或手工复制的旧模型条目，最容易遗漏这个字段。
3. 发往 Provider 的消息
在安全的测试环境中查看请求结构或调试日志。正确的视觉请求应包含图片内容块或文件引用；如果消息里只出现图片替代文字，降级已经发生在 DSH 侧。
4. 供应商的有效路由
确认 API 返回的实际模型信息与当前定价。兼容别名可以继续工作，但新配置应使用当前稳定 ID，减少本地模型目录与后端路由不一致的机会。
修复方法
使用 deepseek-flash
新建或编辑模型配置，选择当前 ID，并确认文本与图片两种输入模态都已声明。不要只修改显示名称。
移除重复的旧条目
同一个 Provider 中同时保留多个指向 V4.1 Flash 的旧别名，会让模型选择器出现多个近似选项。确认不再有 Session 依赖后，移除手工添加的旧条目，或至少明确标注其能力与用途。
新建 Session 复测
模型能力通常在 Session 或运行配置中被选定。修改目录后，使用新 Session 上传一张包含清晰文字和视觉关系的测试图，并提出只能依赖图片回答的问题。
比较请求载荷
使用同一张图片分别运行旧 ID 与 deepseek-flash，比较发出的消息结构。测试重点是图片块是否保留，不是模型回答措辞是否相似。
一套最小回归测试
准备一张带有以下元素的图片：
- 一段不会出现在文件名里的随机文字；
- 两个物体的空间关系；
- 一个明确颜色。
依次询问图片中的随机文字、物体位置和颜色，并记录：模型 ID、DSH 版本、inputModalities、请求内容块类型和回答。三项都依赖视觉信息，能快速区分真实图片输入与替代文字。
这类问题为什么容易漏掉
模型 ID 同时承担路由标识和本地能力索引。Provider 可以在服务端把旧 ID 映射到新模型，本地 Harness 仍会用旧目录决定图片、音频和文件怎样进入消息。后端兼容解决了“请求能否到达”，没有自动更新“客户端怎样组织请求”。
模型迁移时应同时核对：
| 层级 | 检查项 |
|---|---|
| Provider | 旧 ID 当前路由到哪个模型 |
| DSH Catalog | 输入/输出模态、上下文和能力标签 |
| Profile | 是否固定旧 ID 或覆盖目录 |
| Session | 实际选择的模型与请求载荷 |
与 v0.1.6-alpha.1 的关系
v0.1.6-alpha.1 改进了 V4.1 图片尺寸、Token 估算和默认请求质量。这些优化位于图片处理链路中，但不会替代正确的模态声明。模型条目被识别为文本模型时，请求仍可能先进入文本降级路径。
相关阅读
- DeepSeek V4.1 Flash 接入 Harness
- DeepSeek Harness 视觉模型配置
- DeepSeek Harness v0.1.6-alpha.1 更新
- DeepSeek V4.1 Flash：API、架构与评测
常见问题
旧 ID 已经路由到 V4.1 Flash，为什么还要改？
服务端路由和 DSH 本地能力声明是两层。旧 ID 可以到达 V4.1 Flash，本地目录仍可能把它判断为文本模型。
没有报错是否说明图片发送成功？
不能。文本降级路径会生成合法消息，API 可以正常返回结果。需要检查请求内容块或用只依赖图片细节的问题测试。
只补上 inputModalities 可以吗？
自定义 Provider 可以补齐声明，但新配置优先使用 deepseek-flash，同时保留当前模型 ID、能力目录和服务端路由的一致性。