DeepSeek V4 多模态开源，我们把它的视觉链路拆了一遍

这不是一个全新的模型突然出现。早在 8 月 21 日，DeepSeek 就已经把它接入 API，当时外界只能看到结果：V4 开始能处理图片，而且在 ApexBench、Agents' Last Exam、Chartography 等多模态 Agent 基准上整体提升。

现在不一样了。

随着权重和参考推理代码公开，V4 的视觉部分第一次可以直接拆开看。Vision Encoder 怎么处理图片，Aligner 怎么把视觉特征压进语言空间，视觉 Token 怎么进入 DFlash，MoE 又怎么给图片选择专家，这些东西都已经暴露出来。

拆完代码会发现，DeepSeek 做的并不是简单给 V4 接一个看图模块。

图片经过视觉编码以后，会被直接塞进 V4 原有的 Token 序列，继续参与长上下文 Attention、MoE 路由和后面的 Agent 推理。甚至连注意力窗口和专家路由，都专门为视觉 Token 改了规则。

所以这次开放权重之后，更值得研究的问题已经从 V4 会不会看图，变成了另一件事：

DeepSeek 到底是怎么把视觉塞进一个原本为长上下文和 Agent 设计的 V4 主干里的？

01

视觉怎样进入 V4

先看一张图片怎样变成 V4 序列中的 Token。

视觉前端是一套 32 层 ViT，隐藏维度 1024，拥有 16 个 Attention Head，patch size 为 14。图片先经过尺寸调整，再被切成 14 × 14 的 patch，每个 patch 映射成一个 1024 维向量。

视觉位置编码使用二维 RoPE。代码会分别建立图像网格的横向和纵向坐标，再将两组位置写入 Attention。

对于网页和 GUI，这种设计很关键，因为界面语义大量存在于空间关系里：按钮位于哪个区域，表头和数据怎样对应，弹窗覆盖了什么内容，图例和图表之间是什么位置关系。ViT 在这里负责先把二维结构建出来。

问题出现在 ViT 后面。雷峰网

V4 主干隐藏维度是 4096，视觉侧只有 1024，而且 ViT 产生的 patch 数量仍然偏大。DeepSeek 在两者中间放了一个 Aligner，同时解决维度转换和 Token 压缩。

它会把相邻 3 × 3 个视觉特征放到一起，9 个 1024 维向量合并以后形成 9216 维输入，再经过 9216 → 4096 → 4096 的两层映射进入 V4。

打个比方，这个 Aligner就相当于向“老板”V4汇报的秘书，先将老板要处理的文件进行精炼汇总：横向缩小 3 倍，纵向缩小 3 倍，所以进入语言主干的视觉网格规模大致下降到原来的九分之一。

这一步非常关键。DeepSeek 没有直接降低 ViT 的观察密度，而是在视觉编码完成以后再压缩序列。前端仍然可以利用较密的 patch 读取页面细节，到了计算量更大的 V4 主干之前，再削减视觉 Token 数。

配置里的 vision_max_n_token = 384 也应该放在这里理解。

384 指的是进入 V4 序列后的单图预算，并非 ViT 只看 384 个 patch。ViT 前端实际处理的视觉单元更多，经过 3 × 3 Aligner 后，才被压缩成几百个语言侧视觉 Token。DeepSeek API 同样规定单张图片转换后的输入不超过 384 Token。雷峰网

对于单轮图像问答，这种限制可能只是一次计算取舍；对于 Agent，它直接决定每观察一次环境，需要往长上下文里新增多少内容。

随后还有一个很容易被忽略的细节：视觉 Token 并没有按照普通的逐行顺序进入 V4。

build_image_block() 会给图片加入 IMAGE_START、换行、Padding 和 IMAGE_END，然后把相邻两行视觉网格重新交织。代码还通过 COMPRESS_PAD_TO = 4，让视觉序列的位置与 4 Token 边界对齐。

V4 主干内部恰好大量存在 compress_ratio = 4 的压缩层，同时还交替使用 ratio 为 128 的层。仅凭公开代码还不能断言 N-layout 就是专门为 CSA 的 4 Token 压缩设计。

但两者的粒度明显一致：图像进入模型前已经主动改变二维网格的线性排列，并进行 4 Token 对齐，说明视觉序列的组织方式考虑了后面压缩主干的处理方式。

所以从像素到 V4，并非简单经历 ViT 加一个投影层。

更准确的路径是：图片先以较高密度建立二维表示，随后进行 3 × 3 空间压缩，再转换到 4096 维隐藏空间，接着重新组织视觉 Token 的排列，最后才进入 V4。

做到这一步，图片已经被改造成一种适合长上下文主干处理的序列。

新的问题随之出现：进入序列以后，V4 能不能直接把这些视觉 Token 当成文字处理？

02

进入主干以后

答案从代码里看得很清楚：不能完全按照文字处理。

V4 会先正常生成文本 embedding，然后 merge_image_embeddings() 找到图片占位区域，把经过 ViT 和 Aligner 得到的视觉 embedding 原地写进去。

从隐藏层角度看，文字和图片此时已经进入同一个 4096 维空间。后面的 Transformer 可以让页面内容和自然语言指令直接发生交互，例如任务要求在文字 Token 中，当前网页状态位于视觉 Token 中，两者进入同一条推理序列。

不过 DeepSeek 特意保留了视觉 Token 的身份。

普通词表大小是 129280，而图像特殊 Token 被放在词表范围之外。主干只需要检查 input_ids >= vocab_size，就能判断当前位置来自图片。

为什么进入统一隐藏空间以后，还要留下这个标记？因为二维图片和文字序列的计算需求并不一样。

先看 Attention。V4 的普通局部滑窗只有 128 Token，而一张图片可以占接近 384 个语言侧 Token。如果完全按照文字的局部规则处理，一张完整截图可能被切成数段。

比如一个网页的表头在顶部，操作按钮位于页面下方。二维空间中它们属于同一张界面，但转换成一维视觉序列后，两者距离可能超过 128 Token。普通滑窗会削弱同一张图片内部远距离区域的直接联系。

代码因此加入了 get_image_visible()。它会识别 IMAGE_START 与 IMAGE_END，计算一个 Token 在当前图片范围内向左和向右还有多少视觉内容。V4 随后可以在普通局部窗口之外，扩展图片内部的可见范围。

代码甚至要求一整段图片必须在 prefill 阶段一次写入，不能在后续 decode 中把同一张图拆成几块追加。

这解决的是视觉的空间完整性。MoE 处理的是另一个问题：视觉 Token 应该调用哪些参数。

V4 拥有 256 个路由专家，每个 Token 会激活 6 个专家。视觉版本的 Router 中增加了单独的 bias_vl。

普通文字 Token 使用常规 expert bias，图片 Token 则换成视觉专用的 bias_vl 来影响 top-k 专家选择。这个 bias 负责调整专家被选中的顺序，真正用于计算输出的路由权重仍然来自原始 scores。

前面的 Hash-MoE 层处理得更加直接。文字 Token 可以利用 Token ID 对应已有专家映射，但图片没有正常词表中的语义 ID，所以视觉位置会跳过这套路由，根据当前隐藏状态重新选择专家。

这形成了一种很有意思的结构：视觉和文字共享同一个 V4 主干，也共享专家池；进入内部计算时，模型仍然允许视觉走不同的可见关系和专家分配路径。

这种做法比把视觉彻底变成伪文字更灵活。语言主干积累下来的代码、推理、工具调用和知识能力可以继续复用；视觉 Token 又不需要强行服从语言序列的全部假设。

开放权重以后，bias_vl 也提供了一个很直接的研究入口。可以统计网页截图、图表、自然图像、IDE 界面分别激活哪些专家，再观察视觉和文本进入深层以后，专家分布是否逐渐融合。

到这里，V4 已经解决了两件事：视觉怎样进入长上下文，以及主干怎样识别视觉。

剩下的问题开始转向系统层面。如果图片只出现一次，这些设计的代价还比较容易控制；Agent 会让模型一轮又一轮地重新看环境，计算模式就完全变了。

03

视觉成本会被一轮轮放大

DeepSeek 给 V4-Flash-Vision-Exp 加视觉，并没有把重点停留在图片描述。

官方发布时专门强调 Multimodal Agent，并且 Responses API 支持图文输入和工具使用。这意味着图片可以和工具执行流程放在一起：模型读取环境，生成行动，工具执行，然后新的环境状态再次返回模型。

浏览器 Agent 就是一个典型例子。模型先看到网页截图，根据任务决定点击按钮；点击完成以后页面改变，Agent 再截一张图；模型读取新页面，决定是否输入、滚动或者执行下一项操作。

普通聊天经常经历一次较长的 prefill，随后连续 decode。

视觉 Agent 的工作负载不一样。每产生一次新的环境观察，就需要重新执行图片缩放、patch 化、32 层 ViT、Aligner，再把新增加的视觉 Token 送进 V4 做 prefill。一个动作可能只生成几个 Token，但在生成之前却要处理一整张新截图。

于是任务运行时间越长，视觉编码和反复 prefill 的占比就越高。

V4 支持超过 100 万 Token 上下文，这能容纳很长的任务轨迹；容量大并不等于计算可以忽略。每张图片有 384 Token 的语言侧预算，同时主干还运行 43 层 Transformer、256 个专家和稀疏 Attention。连续几十轮环境观察以后，历史中会同时存在任务指令、工具结果、文字页面内容和多轮视觉状态。

这里会出现一个比上下文长度更麻烦的问题：重复计算。

Agent 连续操作网页时，相邻两张截图可能只有一个按钮、一个弹窗或者某块结果区域发生变化，页面的大部分像素保持原样。目前这种视觉输入路径仍然会把新截图重新送进 ViT。

换句话说，视觉 Agent 很容易反复计算没有变化的环境。

这可能成为后续推理优化中非常大的空间。一种方向是缓存 ViT 中间结果。页面只改变局部区域时，只更新发生变化的 patch。

另一种方向是做视觉差分。系统先判断前后两帧哪些区域发生变化，再决定哪些视觉内容值得重新写进上下文。

还可以采用混合环境表示。网页正文和表单信息交给 DOM 或 Accessibility Tree，canvas、图表、复杂布局以及程序接口难以表达的界面状态交给视觉模型。这样无需每一步把整个页面重新当作像素处理。

这类优化和提升单张图片理解能力属于完全不同的问题。Agent 看图的核心压力在频率。

模型需要持续观察、持续更新状态，而且每一轮观察必须足够便宜，才能让任务执行几十步后仍然保持可用速度。

MoE 又会增加一层部署变量。既然视觉 Token 存在独立的 bias_vl，不同视觉输入可能形成不同专家负载。

如果大量 GUI Agent 请求集中进入服务，视觉路由会不会让部分专家承受更高流量，需要通过真实推理数据才能判断。

因此，V4-Flash-Vision-Exp 后续真正难做的地方，很可能逐渐从视觉识别转向视觉状态管理。

如何减少重复编码，如何控制历史截图进入 KV Cache 的方式，如何让旧画面退出活跃上下文，以及如何在视觉信息和结构化工具信息之间分配计算资源，这些问题直接决定视觉 Agent 的端到端效率。

04

V4 正在把环境状态变成上下文

V4 -Flash-Vision-Exp 开放权重后，可以看到 DeepSeek 这次做的事情已经超出给语言模型增加图片输入。

它正在修改 V4 对上下文的定义。过去，上下文主要来自文字：用户要求、代码、工具返回值以及任务历史。

现在，网页当前长什么样，软件执行之后界面发生了什么变化，图表呈现出怎样的结构，也可以直接成为 V4 内部的序列状态。

视觉模块在这里承担的是环境接口。这也解释了 DeepSeek 为什么没有让图片停留在模型外围。视觉信息被压进 V4 的隐藏空间以后，DFlash 需要理解图片边界，MoE 需要知道它面对的是视觉 Token，长上下文则需要容纳连续的环境变化。

当这套链路接上 Agent，模型获得的就不只是多一种输入模态。

它开始形成一个完整循环：读取环境状态，产生行动，让工具改变环境，再根据新的状态继续推理。

开放权重之后，外部已经可以从视觉压缩、Attention 可见范围、专家路由和多轮推理效率几个层面直接研究这条链路。

过去，我们评价一个多模态模型，通常会问：“它能不能认出这张图中包含了什么梗？”

但 DeepSeek V4 开放权重的这一刻，把行业的及格线彻底拉高了。当图片不再只是被编码的死物，而是直接参与到大模型的 Attention 滑窗、MoE 专家路由甚至整个长上下文的推理闭环中时，视觉就变成了大模型理解复杂物理世界的“原生上下文”。

在未来的多模态模型竞争中，能看懂图片只是入场券。当整个行业开始卷起来，V4 后续能不能成为更成熟的视觉 Agent 底座，很大程度上会取决于另一个问题：模型不仅要看懂环境，还要用足够低的计算开销持续看下去。

可独家畅览：

专家演讲PPT

大会报告全文

热门论文解读

学术新星访谈

扫描上方二维码

或点击「阅读原文」关注专区。