By zipflow.xyz
This 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:
- What DeepSeek's papers actually disclose
- What the current API documentation says
- What we still cannot verify about the newest model's training data
1. DeepSeek-VL: starting from real-world visual data
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:
- A hybrid vision encoder
- A vision-language adaptor
- A DeepSeek language model
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 three-stage training recipe
The paper described a staged approach:
- Adaptor warm-up: train the vision-language adaptor while the primary vision and language components remain frozen.
- Joint pretraining: train the language model and adaptor with both text-only and multimodal data while keeping the main vision encoder frozen.
- Supervised fine-tuning: train on multimodal instructions and text conversations for interactive use.
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.
2. DeepSeek-VL2: more visual detail, more efficient inference
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:
- Visual question answering
- OCR
- Document understanding
- Table and chart understanding
- Visual grounding
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.
3. Janus: separating visual understanding from visual generation
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:
- A semantic visual path for understanding
- A discrete visual-token path for generation
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:
- Janus / Janus-Pro: unified visual understanding and image generation research
- DeepSeek-Vision-Exp: an API model that accepts image input alongside text
The shared lineage is the research investment in visual representations. The products and interfaces are different.
4. What the current Vision-Exp API adds
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:
- Base64 data URLs
- Public image URLs
- Files API references
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.
5. What is actually traceable about the data?
The public papers provide a useful form of research-level provenance. They tell us about:
- The categories of visual tasks DeepSeek targeted
- Broad data mixtures and selected public datasets
- The use of screenshots, PDFs, OCR, charts, documents, and code
- Internal scenario taxonomies for instruction tuning
- The stages used to align visual features with language models
- The architecture and evaluation goals
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?"
6. Why the lineage matters for developers
The history explains several design choices visible in the current API.
Screenshots and documents are first-class inputs
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.
Vision is being connected to agents
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.
Efficient visual tokens remain important
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.
Open research and closed service are different transparency levels
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.
7. Practical checklist before adoption
Before putting a visual model into a production agent, ask:
- Can the model process the image types your workflow actually receives?
- What happens when OCR is small, rotated, handwritten, or low contrast?
- How are image tokens counted in your cost model?
- Can repeated images use a file reference instead of repeated uploads?
- What is the fallback when the experimental model is unavailable?
- Which claims come from official documentation, and which come from third-party testing?
- Does your compliance review require stronger training-data provenance than the provider publishes?
- Are irreversible actions gated by a human confirmation step?
Conclusion
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.
