从像素到 Agent 上下文：拆解 DeepSeek V4 Flash Vision 的 32 层 ViT、3×3 Aligner、视觉可见窗口与专用 MoE 路由
核心结论：DeepSeek-V4-Flash-Vision-Exp 并不是在语言模型外面外挂一个“看图插件”。图像经过视觉编码和压缩后，会作为原生视觉 Token 写入 V4 的 4096 维序列，并继续参与 DFlash Attention、MoE 专家路由和多轮 Agent 推理。
先明确定位：它是实验模型，不是简单的 V4 加图片输入
DeepSeek 官方将 DeepSeek-V4-Flash-Vision-Exp 定义为 V4 家族首个实验性多模态模型。它基于 DeepSeek-V4-Flash 主干增加视觉模块，并继续训练以获得视觉理解能力。模型权重、Tokenizer、图文提示编码和最小 PyTorch 推理实现均已开放，采用 MIT 许可证。
相比早期只能通过 API 观察结果，现在开发者可以直接查看 Vision Encoder、Aligner、DFlash、MoE、Hyper-Connections 与 DSpark 前向链路。真正值得研究的问题也从“模型能不能看图”，转向“视觉怎样进入原本面向超长上下文和 Agent 的语言主干”。
如果想先了解模型发布、官方基准和访问方式，可阅读站内的 DeepSeek-V4-Flash-Vision-Exp 开源概览；模型入口则使用 DeepSeek-V4-Flash-Vision-Exp 导航页。
官方基准：视觉 Agent 提升，但测试条件必须一起看
官方模型卡给出的结果显示，Vision-Exp 在多模态 Agent 测试中明显优于会忽略图片输入的 V4-Flash-0731，同时文本 Agent 成绩大体保持。以下数字来自 DeepSeek 官方评测，不能直接与不同 Harness、提示词或推理预算下的第三方结果混用。
| 基准 | Vision-Exp | V4-Flash-0731 | Opus-4.8 |
|---|---|---|---|
| Terminal Bench 2.1 | 83.9 | 82.7 | 85.0 |
| DeepSWE | 59.3 | 54.4 | 58.0 |
| ApexBench Pass@1 | 36.5 | 26.2 | 39.4 |
| Agents’ Last Exam | 27.3 | 25.2 | 25.7 |
| Chartography | 64.3 | — | 65.0 |
| ZeroBench Pass@5 | 35.0 | — | 34.0 |
这些数据说明它的目标不是取代所有通用多模态模型，而是把视觉理解接入 V4 已有的编程、工具调用和长上下文 Agent 能力。
第一步：32 层 ViT 把图片变成二维视觉表示
公开配置显示，视觉前端是一套 32 层 Vision Transformer：隐藏维度 1024、16 个 Attention Head、Patch Size 为 14。图片经过尺寸调整后被切分成 14×14 像素 Patch，每个 Patch 转换成一个 1024 维视觉向量。
视觉位置编码采用二维 RoPE。横向坐标和纵向坐标分别写入注意力计算，使模型能保留页面布局、图表坐标、弹窗覆盖关系和按钮位置等空间信息。对 GUI Agent 来说，文字识别只是基础；更重要的是理解“谁位于谁旁边、谁覆盖了谁、表头对应哪一列”。
第二步：3×3 Aligner 同时完成压缩与维度对齐
ViT 输出是 1024 维，而 V4 主干隐藏维度是 4096；同时，直接把所有图像 Patch 送入 43 层主干会带来很高计算成本。DeepSeek 在中间加入 Aligner，一次解决两个问题。
Aligner 会组合相邻的 3×3 视觉特征：9 个 1024 维向量拼成 9216 维输入，再经过 9216 → 4096 → 4096 的映射进入 V4。横向和纵向都缩小 3 倍，因此语言侧视觉网格规模大约下降到原来的九分之一。
这是一种“先看清、后压缩”的路线。ViT 仍以较密 Patch 读取细节，等到进入计算更昂贵的语言主干前再减少视觉 Token。
384 Token 代表什么？不是 ViT 只看 384 个 Patch
配置中的 vision_max_n_token = 384 容易被误读。它更接近单张图片进入 V4 序列后的预算上限，不是说视觉编码器只处理 384 个原始 Patch。前端会观察更多视觉单元，经过 3×3 Aligner 后才压缩为几百个语言侧视觉 Token。
对普通图片问答，这是速度与细节之间的折中；对 Agent，它决定每次观察环境会向上下文新增多少状态。浏览器 Agent 连续看 20 次页面，理论上可能累计数千个视觉 Token，还不包括任务指令、工具结果和文字历史。
第三步：视觉 Token 不是按普通文字顺序直接排队
图片会被包装在 IMAGE_START 与 IMAGE_END 之间，同时加入换行和 Padding。公开编码代码还会重排相邻视觉网格行，并将序列对齐到特定粒度。这样做的目的，是让二维网格转换成一维 Token 序列时尽量保留局部空间关系，并适配后续压缩主干。
V4 主干配置交替出现压缩比例 4 与 128 的层。公开代码能确认视觉序列进行了特定排列和对齐，但仅凭当前实现仍不宜断言每个布局细节都专门服务于某一种压缩层。更稳妥的理解是：视觉 Token 在进入 V4 前已经针对后续长上下文计算做过结构化处理。
第四步：图像 Embedding 被原地写入文本序列
模型先生成普通文本 Embedding，再由 merge_image_embeddings() 找到图像占位区域，把 ViT 与 Aligner 的输出原地写入同一条隐藏序列。从这一刻开始，用户指令、工具结果和当前截图都位于统一的 4096 维空间。
这使自然语言任务与页面状态可以直接相互注意。例如“找到图表中增长最快的地区并点击对应筛选项”这类任务，文字目标和视觉环境不再分属两个松散模块，而是在同一推理链路中交互。
统一空间不等于抹掉身份：视觉 Token 仍被单独标记
V4 普通词表大小为 129280，图像特殊 Token 位于词表范围之外。主干可以通过 input_ids ≥ vocab_size 判断当前位置是否来自图片。保留这一身份很重要，因为二维图像与文字序列需要不同的可见关系和专家选择策略。
如果把视觉完全伪装成普通文字，模型就无法针对一张完整截图扩展注意力范围，也很难在 MoE 中为视觉输入调整专家路由。
Attention 的关键改动：一张图片不能被 128 Token 滑窗切碎
V4 的普通局部滑动窗口为 128 Token，而单张图像可接近 384 个语言侧视觉 Token。如果完全按文字规则处理，页面顶部的表头和底部按钮可能被分到不同窗口，同一张截图内部的远距离区域无法直接建立联系。
get_image_visible() 会识别 IMAGE_START 与 IMAGE_END，计算每个位置在当前图像范围内左右还有多少视觉内容，再让注意力在普通窗口之外扩展图片内部可见范围。代码还要求一整段图像在 Prefill 阶段一次写入，不能在后续 Decode 时把同一张图拆成多段追加。
MoE 的关键改动：共享专家池，但视觉有专用路由偏置
V4 配置包含 256 个路由专家，每个 Token 激活 6 个专家。Vision-Exp 在 Router 中加入 bias_vl：文字 Token 使用常规偏置，视觉 Token 则使用视觉专用偏置影响 Top-K 专家选择。
需要注意，bias_vl 调整的是哪些专家被选中，真正用于加权输出的路由权重仍来自原始分数。前面的 Hash-MoE 层也对视觉位置单独处理：普通文字可根据 Token ID 使用既有映射，图像没有正常语义 ID，因此视觉位置会根据隐藏状态重新选专家。
这套设计为什么适合视觉 Agent？
视觉与语言共享主干，意味着 V4 已积累的代码、推理、知识和工具调用能力可以直接复用；视觉身份又被保留，使 Attention 与 MoE 不必强迫图片完全服从文字序列的计算假设。
它由此形成闭环：读取当前界面 → 理解任务 → 生成点击或输入动作 → 工具改变环境 → 获取新截图 → 继续推理。视觉在这里不是一次性附件，而是 Agent 不断更新的环境状态。
真正的成本压力：Agent 每一步都可能重新看一遍页面
普通聊天常是一轮较长 Prefill，随后连续 Decode；视觉 Agent 每产生一次新观察，都要再次执行缩放、Patch 化、32 层 ViT、Aligner 和主干 Prefill。一个动作可能只生成几个文字 Token，但在生成前却需要处理整张新截图。
V4 支持最高 1,048,576 Token 的位置长度，这提供了容量，却不会消除计算。连续数十轮后，上下文里会同时存在指令、工具返回、文字页面、历史截图和当前截图，KV Cache 与 Prefill 压力都会增加。
最大浪费可能是重复像素：页面只变一点，ViT 却重算整张图
浏览器连续操作时，相邻截图往往只有一个按钮、弹窗或结果区域发生变化，大部分像素保持不变。当前参考路径仍会把新图重新送入视觉编码器，因此重复计算可能成为端到端效率瓶颈。
这为推理系统留下了几条优化方向：
- 视觉特征缓存：保存 ViT 中间结果，只更新发生变化的 Patch。
- 视觉差分：先检测两帧的变化区域，再决定哪些内容写入上下文。
- 混合环境表示：正文、表单和按钮优先使用 DOM 或 Accessibility Tree，图表、Canvas 与复杂布局交给视觉模型。
- 历史状态压缩：让旧截图退出活跃上下文，只保留关键变化和可追踪摘要。
部署时还要关注专家负载，而不只是显存
由于视觉 Token 使用专用 bias_vl，网页截图、图表、自然图像和 IDE 界面可能形成不同的专家分布。大量 GUI Agent 请求集中到服务时，部分专家是否出现负载热点，需要依靠真实流量观测。
官方 Hugging Face 页面列出的模型规模约 305B 参数，参考实现包含 FP4 专家、FP8 量化和张量并行转换脚本。它是可读的参考推理实现，不等于开箱即用的生产服务引擎。自行部署前应核对运行时支持、显存、张量并行、图像预处理和多模态调度能力。
开源代码提供了哪些可研究入口？
权重和参考实现开放后，开发者可以围绕以下问题做实证研究：
- 不同图像类型分别激活哪些 MoE 专家，随着层数加深，视觉与文字路由是否逐渐融合；
- 384 Token 预算对小字网页、复杂图表和超长截图的精度影响；
- 图像可见窗口在 GUI、文档与多图输入中的收益；
- 缓存视觉特征、差分截图和混合 DOM 表示能减少多少延迟与 Prefill 成本；
- 长任务中应如何淘汰旧截图，同时保留足够的可审计状态。
如何开始体验或研究？
普通用户可通过已接入该模型的服务进行图文输入和视觉 Agent 测试。研究与部署用户可以从官方 Hugging Face 仓库下载权重、编码示例和参考推理代码。模型支持 OpenAI 风格的图文消息块，也支持紧凑的图片路径标记形式。
官方参考目录提供权重转换、张量并行和交互式推理命令，但明确说明这是“可读参考实现”，不是生产级 Serving Engine。建议先从少量图片和短上下文验证，再逐步测试多图、长轨迹与工具调用。
限制与判断：能看懂只是入场券
Vision-Exp 名称中的“Exp”意味着它仍是实验版本。官方基准有明确的 Agent Harness、推理强度和采样设置；本地环境是否获得相同结果，取决于推理框架、图像预处理、上下文长度与硬件配置。模型也可能在细小文字、密集图表、多轮状态追踪和工具执行中出错。
因此，视觉 Agent 的成熟度不能只看静态图片问答分数。更关键的指标包括：连续观察的成本、动作成功率、错误恢复能力、权限边界、状态压缩与人工复核机制。
总结：DeepSeek 正在重新定义“上下文”
DeepSeek-V4-Flash-Vision-Exp 最值得关注的不是“V4 终于能看图”，而是它让图片直接参与主干计算：ViT 建立二维表示，Aligner 压缩并投影，统一 Embedding 连接文字与视觉，图像可见机制保护空间完整性，bias_vl 则让 MoE 为视觉 Token 选择不同专家。
当这些机制与长上下文和工具调用组合后，网页、软件界面和图表不再只是外部附件，而成为 Agent 持续更新的环境状态。下一阶段的关键也很清楚：模型不仅要看懂环境，还要以足够低的成本持续看、持续行动，并让每一步都可验证、可回滚。
