DeepSeek V4 开放权重与参考推理代码后，其视觉处理链路首次完整公开。此前，V4 已于 8 月 21 日接入 API，支持图片输入，并在 ApexBench、Agents' Last Exam、Chartography 等多模态 Agent 基准上整体提升。如今，随着权重公开，外界得以拆解其视觉模块的详细实现：图片并非简单编码后附加，而是被直接融入 V4 原有的 Token 序列，参与长上下文 Attention、MoE 路由及后续 Agent 推理。
视觉前端采用 32 层 ViT，隐藏维度 1024，16 个 Attention Head，patch size 为 14。图片先被切分为 14×14 的 patch，每个 patch 映射为 1024 维向量，并使用二维 RoPE 进行位置编码，以保留网页、GUI 等界面中的空间关系。ViT 之后，一个 Aligner 模块将相邻 3×3 的视觉特征合并，形成 9216 维输入，再经两层映射（9216→4096→4096）进入 V4 主干（隐藏维度 4096）。这一设计将视觉网格规模压缩至约九分之一，同时保留前端较高的观察密度。配置中的 vision_max_n_token = 384 表示进入 V4 序列后的单图 Token 预算，而非 ViT 处理的 patch 数量。
视觉 Token 进入序列时，并非按普通逐行顺序排列。代码通过 build_image_block() 添加 IMAGE_START、换行、Padding 和 IMAGE_END，并将相邻两行视觉网格交织，同时使用 COMPRESS_PAD_TO = 4 使视觉序列与 4 Token 边界对齐，与 V4 主干中 compress_ratio = 4 的压缩层粒度一致。这显示视觉序列的组织方式考虑了后续压缩主干的处理需求。
进入主干后，视觉 Token 并未完全按文字处理。V4 先正常生成文本 embedding，再通过 merge_image_embeddings() 将视觉 embedding 写入图片占位区域。文字与图片在隐藏层进入同一 4096 维空间，但视觉 Token 保留了特殊身份——图像特殊 Token 位于词表（大小 129280）之外，主干可通过检查 input_ids 判断当前位置来自图片。
在 Attention 层面，V4 的普通局部滑窗仅 128 Token，而一张图片可占近 384 个语言侧 Token。为保持图片内部远距离区域的联系，代码加入 get_image_visible()，识别 IMAGE_START 与 IMAGE_END，扩展图片内部的可见范围，并要求整段图片在 prefill 阶段一次写入。
MoE 方面，V4 拥有 256 个路由专家，每个 Token 激活 6 个专家。视觉 Router 增加了独立的 bias_vl，用于调整视觉 Token 的专家选择顺序，而路由权重仍来自原始 scores。Hash-MoE 层对视觉 Token 跳过基于 Token ID 的映射，直接根据隐藏状态重新选择专家。这种设计使视觉与文字共享主干和专家池，但允许视觉走不同的可见关系和专家分配路径。
官方发布时强调 Multimodal Agent，Responses API 支持图文输入和工具使用。浏览器 Agent 是典型场景：模型读取网页截图，执行点击等操作，再读取新截图，循环往复。每轮观察都需要重新执行图片缩放、patch 化、ViT、Aligner 及 prefill，导致任务运行时间越长，视觉编码和反复 prefill 的占比越高。V4 支持超过 100 万 Token 上下文，可容纳长任务轨迹，但连续几十轮观察后，历史中会积累大量视觉 Token，带来重复计算问题——相邻截图可能仅局部变化，却仍被整体重新编码。
后续优化方向可能包括缓存 ViT 中间结果、视觉差分（仅更新变化区域）、混合环境表示（DOM 或 Accessibility Tree 与视觉模型结合）等。MoE 部署也面临挑战：视觉 Token 的独立 bias_vl 可能导致不同视觉输入形成不同专家负载，需通过真实推理数据评估。
DeepSeek V4-Flash-Vision-Exp 的开放，将视觉从“编码死物”转变为参与 Attention、MoE 与长上下文推理的“原生上下文”。这重新定义了上下文——不仅包含文字，还包括网页状态、界面变化和图表结构。当视觉模块成为环境接口，模型得以形成“读取环境-产生行动-工具改变环境-继续推理”的完整循环。开放权重后，研究者可从视觉压缩、Attention 可见范围、专家路由和多轮推理效率等层面深入分析。行业竞争的门槛已从“能否看懂图片”提升至“能否以足够低的计算开销持续理解环境”，这将成为视觉 Agent 底座成熟度的关键。