作者丨郑佳美
编辑丨岑峰
DeepSeek V4 的多模态能力并非横空出世。早在 8 月 21 日接入 API 时，其在 ApexBench、Agents' Last Exam 等多模态基准上的提升已初现端倪。如今，随着权重与参考推理代码的开源，V4 视觉部分的内部机制首次得以完整拆解。
代码分析显示，DeepSeek 并未简单地为 V4 挂载视觉模块，而是将图片深度融入原有架构。视觉编码后的 Token 直接嵌入序列，参与长上下文 Attention、MoE 路由及 Agent 推理，甚至针对性地调整了注意力窗口与专家路由规则。
本次开源的核心价值，在于揭示 DeepSeek 如何将视觉信息无缝塞入原本为长文本和 Agent 设计的 V4 主干。
01 视觉怎样进入 V4
图片转化为 V4 序列 Token 的过程经过精密设计。视觉前端采用 32 层 ViT（隐藏维度 1024，16 个 Attention Head，patch size 14），配合二维 RoPE 位置编码，有效捕捉网页与 GUI 中的空间语义关系。
为解决 ViT 输出维度（1024）与 V4 主干（4096）不匹配及 Token 数量过大的问题，DeepSeek 引入了 Aligner 模块。该模块将相邻 3×3 的视觉特征合并压缩，经两层映射（9216→4096→4096）后输入主干。此举在保留前端高密度细节读取能力的同时，将进入语言主干的视觉网格规模压缩至原来的九分之一。
配置参数vision_max_n_token = 384指单图进入 V4 序列后的 Token 预算，而非 ViT 前端处理的上限。此外，视觉 Token 并非按常规逐行排列，而是通过build_image_block()加入起止标记并进行 4 Token 边界对齐，以适配 V4 主干中压缩比为 4 的处理层，确保视觉序列组织方式与后端计算粒度一致。
综上，图片经历“高密度二维表示→3×3 空间压缩→维度转换→序列重排”的路径，最终被改造为适合长上下文主干处理的序列。
02 进入主干以后
视觉 Token 进入 V4 后，并非完全等同于文字处理。虽然通过merge_image_embeddings()将视觉 Embedding 写入同一 4096 维隐藏空间，实现图文交互，但模型保留了视觉 Token 的特殊身份标识（ID 超出词表范围）。
这种区分主要基于两点考量：
首先是 Attention 机制。V4 普通局部滑窗仅 128 Token，不足以覆盖单张图片（约 384 Token）。代码通过get_image_visible()识别图片起止标记，扩展图片内部的可见范围，确保如网页表头与底部按钮等远距离空间关系的完整性，并要求图片在 prefill 阶段一次性写入。
其次是 MoE 路由策略。视觉 Token 使用独立的bias_vl偏置项影响专家选择，使其在共享专家池的同时，能根据视觉特征动态调整路由路径。Hash-MoE 层则跳过基于 Token ID 的映射，直接根据隐藏状态重新选择专家。这种设计既复用了语言主干的推理能力，又避免了视觉信息强行服从语言序列假设。
03 视觉成本会被一轮轮放大
V4-Flash-Vision-Exp 定位为 Multimodal Agent，支持图文输入与工具调用。在浏览器 Agent 等场景中，模型需频繁读取环境截图、执行操作并接收新状态。与普通聊天不同，视觉 Agent 每轮观察都需重新执行完整的视觉编码与 Prefill 过程，导致计算负载随任务轮次显著增加。
尽管 V4 支持百万级上下文，但重复计算成为瓶颈。Agent 连续操作时，相邻截图往往仅有局部变化，当前路径却仍对整图重新编码。未来的优化方向包括：缓存 ViT 中间结果、实施视觉差分更新，以及采用混合环境表示（DOM 树处理结构化信息，视觉模型处理复杂布局），以降低高频观察的计算开销。
此外，视觉路由可能引发专家负载不均问题。随着视觉 Agent 规模化部署，如何平衡视觉状态管理与计算资源分配，将是决定端到端效率的关键。
04 V4 正在把环境状态变成上下文
DeepSeek V4 的突破不仅在于增加图片输入，更在于重新定义了“上下文”。网页状态、界面变化、图表结构等环境信息，如今直接转化为模型内部的序列状态。视觉模块作为环境接口，使模型形成了“感知 - 行动 - 反馈”的完整闭环。
当图片直接参与 Attention 滑窗、MoE 路由及长上下文推理时，视觉不再是静态编码对象，而是大模型理解物理世界的“原生上下文”。未来多模态模型的竞争焦点，将从单纯的图像识别能力，转向如何在低计算开销下持续、高效地感知与管理动态环境状态。
