图片不只被编码，还直接参与Attention、MoE与Agent推理。
这不是一个全新的模型突然出现。早在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。
热门跟贴