DeepSeek 的 Vision 能力要来了吗?

DeepSeek 的 Vision 能力要来了吗?

DeepSeek V4 系列的发布在 AI 社区掀起了不小的波澜。V4-Pro-Preview 以 1.6T 参数的规模、出色的推理能力和极具竞争力的成本,让不少开发者开始重新评估自己的模型选择。然而,在文本能力之外,一个更受关注的问题悬而未决:DeepSeek 的多模态能力何时到来?

最近,一则来自 DeepSeek 团队成员小康 Chen(Xiaokang Chen)的推文,似乎给出了某种信号。

一条被删除的推文

在 Reddit 的 r/LocalLLaMA 社区,用户 u/Nunki08 分享了一个链接:小康 Chen 在 X 平台上发布了一条关于 "DeepSeek Vision Coming" 的消息。

这条帖子很快获得了 305 个赞和 98% 的支持率------直到原推文被删除。

帖子的评论区里,有人问:"这是好消息还是坏消息?" 另一位用户回复:"一般来说,是这两者之一。"

推文删除的原因不得而知。可能是时机未到、信息有误,也可能是其他战略考量。但这一举动本身,已经足够引发社区的广泛讨论。

DeepSeek 的视觉基因

如果你了解 DeepSeek 的技术积累,就会发现 "视觉能力" 对他们来说并非从零开始。

早在 DeepSeek-VL 系列之前,DeepSeek 就曾推出过 deepseek-ocr 模型------一个在文档理解和文字识别领域表现优异的视觉模型。当时的社区反馈表明,它在 OCR 任务上的表现甚至超越了不少同期模型。

这意味着 DeepSeek 团队并非 "视觉门外汉"。他们在视觉编码器、图文对齐、OCR 领域已有相当的技术沉淀。如果要将这些能力整合进 V4 系列的基础模型中,基础设施层面的工作早已铺垫。

多模态:后训练 vs 原生融合

社区讨论中最核心的技术分歧在于:多模态能力应该在后训练阶段 "嫁接",还是从一开始就原生融合?

后训练融合(Post-hoc Multimodality)

这是目前大多数模型采用的方式:先训练一个纯文本的基础模型,然后在其上添加视觉编码器(如 CLIP、SigLIP 等),通过多模态指令微调让模型获得图像理解能力。

优点:

  • 模块化设计,训练流程清晰
  • 可以复用已有的强大文本模型
  • 视觉部分出问题时可以单独调试或替换

缺点:

  • 视觉和文本的联合理解可能不够深入
  • 在需要复杂图文推理的任务上表现受限

Reddit 用户 Few_Painter_5588 指出,大多数多模态模型确实采用这种方式,"在预训练阶段加入多模态数据没有明显收益"。

原生多模态(Native Multimodality)

另一种方式是从预训练阶段就将图像和文本混合,让模型从一开始就学习多模态表征。Kimi K2.5 就是采用这种方式的代表之一。

优点:

  • 视觉和文本表征更加统一
  • 理论上在复杂多模态推理任务上表现更好
  • 图像数据本身就是高密度信息源,"一张图胜过千言万语"

缺点:

  • 训练成本更高
  • 需要更大规模的图文配对数据
  • 模型架构设计更复杂

一位用户引用了 Kimi 团队的论文数据:

视觉注入时机 视觉-文本比例 视觉知识 视觉推理 OCR 文本知识 文本推理 代码
早期 10%:90% 25.8 43.8 65.7 45.5 58.5 24.8
中期 20%:80% 25.0 40.7 64.1 43.9 58.6 24.0
后期 50%:50% 24.2 39.0 61.5 43.1 57.8 24.0

数据表明,早期融合(Early Fusion)在视觉任务上确实有优势------但代价是需要从预训练阶段就投入视觉数据。

V4 的 "欠烤" 猜测

一个有趣的社区观点是:V4-Pro-Preview 可能是 "欠烤" 的(underbaked)。

有用户指出,V4-Flash-Preview 的训练看起来是充分的,但 V4-Pro-Preview 可能在训练迭代上还未达到最优状态。如果这个猜测属实,那么:

  1. V4-Pro 还有很大的性能提升空间
  2. 多模态能力可能作为后续版本(如 V4.1)的增量更新加入

如果 DeepSeek 选择在 V4 的基础上 "嫁接" 视觉能力,那很可能会先在 V4-Lite 或 V4-Flash 这样的轻量模型上进行实验。

视觉能力的实际价值

为什么要关心多模态?Reddit 用户分享了几个真实使用场景:

1. 从截图构建应用

这是当前视觉模型最热门的应用之一。在 Cursor、Windsurf 等 AI IDE 中,用户可以直接截图 UI 设计或网页原型,让模型生成对应的代码。这种方式比用文字描述 UI 要快得多。

2. 文档 OCR 与结构化提取

处理 PDF、扫描件、票据等非结构化文档,视觉模型 + 文本理解的组合几乎是刚需。DeepSeek 在 OCR 领域已有积累,如果能在 V4 中整合,将覆盖这一重要场景。

3. 视觉调试

当代码出错时,直接截图控制台的错误信息发给模型,比复制粘贴文本要直观得多------尤其是当错误涉及布局、图表等视觉元素时。

4. 图像/视频数据集标注

对于机器学习从业者,视觉模型是自动标注和清洗数据集的重要工具。

简而言之,没有视觉能力的模型,在现代 AI 工作流中是 "残缺" 的。这也是为什么社区对 DeepSeek Vision 的期待如此之高。

独立模型还是原生融合?

社区讨论中还有一个关键分歧:DeepSeek 会推出独立的 "DeepSeek-VL" 模型,还是直接在 V4 系列中原生支持多模态?

用户 dampflokfreund 的观点代表了很多人的期望:

"希望不是单独的模型,而是带有多模态能力的 V4.1。如果他们现在发布专门的视觉模型,那就没有理解人们为什么要求原生多模态了。"

独立视觉模型的问题在于:

  • 需要额外部署、额外调用
  • 文本模型和视觉模型之间难以无缝协作
  • 用户体验割裂

原生多模态 V4.1 则更符合未来趋势:

  • 一个模型同时处理文本和图像
  • 更低的部署成本
  • 更好的跨模态推理能力

我的判断

综合目前的信息,我对 DeepSeek 的视觉路线有以下猜测:

短期(1-3 个月):

DeepSeek 可能会先发布独立的视觉模型(类似 DeepSeek-VL2),复用 V4 的文本能力。这样做的好处是:

  • 快速响应市场需求
  • 视觉和文本可以独立迭代
  • 降低技术风险

中期(3-6 个月):

如果 V4-Pro 确实如社区猜测那样 "欠烤",DeepSeek 可能会在后续版本中:

  • 强化 V4-Pro 的训练
  • 将视觉能力原生集成进 V4.1 或 V5
  • 可能先在 V4-Flash 这样的轻量模型上实验原生多模态

长期趋势:

原生多模态是不可避免的方向。DeepSeek 团队对视觉领域并非陌生,他们的 OCR 模型已经证明了技术实力。关键在于他们如何平衡:

  • 发布速度 vs 模型质量
  • 独立产品 vs 统一体验
  • 技术理想 vs 商业现实

结语

小康 Chen 的推文删除了,但社区的期待没有消失。

DeepSeek V4 已经证明了他们在文本领域的竞争力------出色的推理能力、极低的 API 价格、开源的权重发布。如果视觉能力能够以原生多模态的形式整合进来,DeepSeek 将有机会成为少数几个同时具备顶级文本和视觉能力的开源模型家族之一。

至于那条被删除的推文------也许它只是一个过早的预告,也许是一次战略性的信息释放。无论如何,DeepSeek Vision 的脚步声,已经越来越近了。


参考来源:

相关推荐
xjxijd1 小时前
无风扇 AI 服务器成主流:英伟达 NVL72 系统引领静音算力革命
大数据·服务器·人工智能
龙智DevSecOps解决方案1 小时前
深度:Perforce P4 MCP 服务器开源解析——当版本控制遇见 AI Agent
运维·服务器·人工智能
ACCELERATOR_LLC1 小时前
【DataWhale组队学习】DIY-LLM Task5 大模型的基本训练流程
人工智能·深度学习·大模型·强化学习·模型训练
QYR_Jodie1 小时前
2025-2032全球感压纸市场:8.7%年复合增长率下的行业前景与竞争格局深度剖析
人工智能·市场报告
GEO_NEWS1 小时前
2026年GEO选型全景透视:技术路径、适配场景与决策逻辑深度解析
人工智能·microsoft
147API1 小时前
Claude 工具调用场景梳理:从 MCP 到企业落地链路
人工智能·架构·api·claude
七夜zippoe1 小时前
OpenClaw 节点管理:设备与远程控制
人工智能·远程控制·设备·openclaw·节点管理
MaxCode-11 小时前
Chapter 9:企业实战案例与架构沉淀
人工智能·spring·架构
用户622475758461 小时前
面试官问我:"如何实现你项目中的这块代码."我说:"看好了."
后端