DeepSeek's Vision Lineage: From DeepSeek-VL to Vision-Exp

DeepSeek's release of deepseek-v4-flash-vision-exp marks the culmination of a long research lineage in vision-language understanding, according to an independent analysis by zipflow.xyz. The analysis traces DeepSeek's progression from DeepSeek-VL, which focused on practical inputs like OCR and charts, to DeepSeek-VL2 with dynamic tiling and Mixture-of-Experts, and Janus for unified understanding and generation. The report highlights key design choices such as hybrid encoders and modality warm-up to preserve language model capabilities.

By zipflow.xyzThis is an independent technical analysis of DeepSeek's public research and documentation. It is not an official DeepSeek statement, and it does not claim that the current Vision-Exp API is available through our upstream channel. When DeepSeek released deepseek-v4-flash-vision-exp , the obvious story was that a text-focused model had finally gained native image input. The more useful story is longer: DeepSeek had already spent years exploring visual data, vision-language alignment, OCR, charts, documents, and unified visual understanding and generation. This article reconstructs that public research lineage and separates three things that are often mixed together: DeepSeek-VL's 2024 paper, Towards Real-World Vision-Language Understanding , did not frame vision as only a captioning problem. It explicitly targeted practical inputs such as web screenshots, PDFs, OCR, charts, and knowledge-oriented visual content. The project also described a taxonomy derived from real user scenarios. That taxonomy was used to build instruction-tuning data for tasks including recognition, transcription, conversion, analysis, commonsense reasoning, logical reasoning, multi-image comparison, and safety-related prompts. The model family combined three major pieces: The hybrid encoder paired a lower-resolution semantic branch based on SigLIP-L with a higher-resolution branch derived from a SAM-B-style encoder. The design goal was practical: global semantic understanding is not enough for small text, dense documents, OCR, and visual grounding. The paper described a staged approach: A particularly important detail is the balance between modalities. The final pretraining mixture retained roughly 70% text data and 30% multimodal data. DeepSeek also described a modality warm-up strategy that gradually introduces multimodal data instead of switching the model abruptly from text to images. This is a general lesson for visual agents: adding an image encoder is not enough. The training process has to preserve the language model's existing reasoning and instruction-following behavior. DeepSeek-VL released approximately 1.3B and 7B variants, along with project code and model weights. That made the early research line more inspectable than a closed API model, although inspectable does not mean every training sample was publicly traceable. DeepSeek-VL2 extended the vision-language direction with two major changes. First, it introduced dynamic tiling for images with different aspect ratios and higher resolutions. This matters because a fixed resize can erase precisely the details a document or screenshot task needs. Second, it used a Mixture-of-Experts language component with DeepSeek's efficient attention design. The goal was to increase multimodal capability without making every parameter active for every token. The paper evaluated tasks including: DeepSeek-VL2 was released as a family of Tiny, Small, and larger variants. In the public research record, this is the point where the visual stack becomes more explicitly engineered around high-resolution inputs, structured documents, and efficient inference rather than only general image conversation. DeepSeek's Janus paper explored a related but distinct problem: can one autoregressive framework handle both visual understanding and image generation? The key idea was to decouple visual encoding into separate pathways: Both paths could still connect to a unified autoregressive transformer. The motivation was that understanding and generation need different visual granularities. A representation that is excellent for recognizing a chart is not automatically the best representation for generating pixels. Janus-Pro later scaled the model and refined its training and data strategy. Its research line is relevant to DeepSeek's broader visual ambitions, but it should not be conflated with the current API vision model: The shared lineage is the research investment in visual representations. The products and interfaces are different. DeepSeek's current documentation lists deepseek-v4-flash-vision-exp as an experimental model that accepts image input. It supports JPEG, PNG, GIF, and WebP images through: The model is available through DeepSeek's OpenAI-compatible Chat Completions and Responses APIs, as well as an Anthropic-compatible Messages endpoint. The documentation also describes a maximum of 384 tokens per image after resizing, up to 600 images per request, and different limits for external/base64 inputs versus Files API references. These are API contract details, not evidence that the model's internal training data is fully documented. At the time of writing, our upstream channel does not expose this model. The API examples in this article are therefore documentation-based and should not be read as ZipFlow production tests. The public papers provide a useful form of research-level provenance . They tell us about: But that is different from a complete source-level provenance ledger. Public material does not establish a complete list of every image used for the current Vision-Exp model, a full licensing chain for every source, a complete deduplication and contamination report, or a one-to-one mapping from current model behavior to a named training example. The careful conclusion is: DeepSeek has a long-running and partially documented visual-data research program. The research lineage is visible; the complete training-data provenance of the newest API model is not. That distinction matters for developers performing technical, legal, or procurement due diligence. Architecture documentation answers "how can I call the model?" It does not automatically answer "where did every training example come from?" The history explains several design choices visible in the current API. The early DeepSeek-VL work explicitly targeted screenshots, PDFs, OCR, and charts. That makes the current API's image-input support relevant to real application workflows rather than only photo captioning. The research path moves from visual understanding toward tool-using workflows. A model that can read a screenshot is useful; a model that can read a screenshot, identify the next operation, and return structured evidence is more useful for agents. High-resolution images carry more detail but consume more compute and context. The progression from hybrid encoders and dynamic tiling to an API-level image token budget reflects the same trade-off: preserve enough detail while keeping inference predictable. DeepSeek-VL and DeepSeek-VL2 exposed papers, code, and model artifacts. The newer API model exposes an interface and usage documentation. These are valuable in different ways, but they do not provide the same level of inspectability. Before putting a visual model into a production agent, ask: The new DeepSeek vision API is best understood as the latest public-facing point in a longer research trajectory. DeepSeek-VL established a focus on real-world visual data. DeepSeek-VL2 pushed toward higher-resolution understanding and efficient MoE inference. Janus explored separate visual pathways for understanding and generation. Vision-Exp brings image input into a current API workflow. The lineage is meaningful, but it should not be overstated. We can trace the research direction, architecture ideas, task categories, and selected data strategies. We cannot responsibly claim that the complete training-data provenance of the newest API model has been published. For developers, that is still useful information: use the public papers to understand the design trajectory, use the API documentation to build integrations, and keep provenance and licensing questions separate from capability claims.