Skip to content

Add DeepSeek V4 Flash Vision support #2411

Open

Description

@localai-org-maint-bot

Row: MODEL-MM-deepseek-v4-deepseek-v4-for-causal-lm

DeepSeek published deepseek-ai/DeepSeek-V4-Flash-Vision-Exp at revision 86f746b36186f0e567729a5c06a8c918caba82a9. The checkpoint reuses the DeepSeek-V4 text backbone and adds a 32-layer ViT, aligner, image sentinel embeddings, image-span attention visibility, interleaved image prompt encoding, and a DSpark tail.

vLLM at the repository parity pin has no vision path for DeepseekV4ForCausalLM; current vLLM, vLLM-Omni, SGLang, and Transformers also expose no complete implementation of this vision variant. The checkpoint repository's minimal PyTorch inference is the only complete executable reference and needs a model-specific oracle pin before it can gate a port.

Scope: add the model and oracle to the roadmap, commit the implementation spec before code, then implement the processor, vision tower and aligner, weight and quantized arms, DeepSeek image merge and visibility semantics, registered multimodal forward, OpenAI multi-image serving, and correctness/performance gates. The spec and implementation use one pull request, with the spec commit first.

CUDA, ROCm, and Vulkan are separate required device paths. Every accelerator build, correctness run, and benchmark must execute through resource-controller (rc) on a leased fleet device; no direct SSH run or CPU fallback counts. CUDA uses an eligible NVIDIA fleet device, ROCm uses strix:gpu0, and Vulkan uses the physical RADV GFX1151 device on strix:gpu0 rather than llvmpipe. A full-artifact memory blocker remains explicit per backend while reduced device-path correctness is still required.

The issue closes when the production entry point accepts the pinned checkpoint family through the documented quantized vehicle, ordinary autoregressive image generation is oracle-gated, text-only DeepSeek-V4 stays byte-identical, CUDA/ROCm/Vulkan device-path evidence is recorded from rc jobs, and the shipped checkpoint details are documented.

Activity

  1. localai-org-maint-bot commented on Sep 5, 2026

    @localai-org-maint-bot
    CollaboratorAuthor

    Scope amendment, 2026-09-05

    Three facts changed since this issue was written, and the row was still planning against the old ones. The spec .agents/specs/deepseek-v4-flash-vision.md is amended accordingly.

    1. The quantized vehicle is now a published artifact

    unsloth/DeepSeek-V4-Flash-Vision-Exp-GGUF at revision b977d3c0ea2da58dbc12ddae8fb8951a7b3854d0 publishes ten imatrix quantizations plus one shared mmproj-BF16.gguf. UD-IQ1_S + mmproj-BF16 is 77.65 GiB resident and fits a single 119 GiB GB10, so the single-device gate is reachable for the first time.

    It ships the llama.cpp two-file shape, which the spec listed as a non-goal and a stop condition. That non-goal is withdrawn by developer direction, with the reason recorded beside it: it existed to stop the row from asking users to reassemble weights, and producing a private combined artifact nobody downloads is now the thing that would do that. src/vllm/model_executor/models/clip_mmproj_gguf.cpp already reads this shape for Qwen3-VL, so no container is invented. The revision and per-shard SHA-256 values are pinned in the spec, because unsloth re-quantizes in place under unchanged names.

    2. llama.cpp implements this model, and is registered as an oracle

    ggml-org/llama.cpp merged ggml-org/llama.cpp#28133 (the deepseek4v clip projector, image preprocessor, mmproj container) and ggml-org/llama.cpp#28154 (the language-side vision behaviour) on 2026-09-02. Release b10766 is 9400c8946e4da5e7694f2c26d6d4e50e14b690fa, the merge commit of the second, and the first release carrying tools/mtmd/models/deepseek4v.cpp. That path returns HTTP 404 at the stock llama-cpp pin b10451, which is 315 commits behind.

    Registered as llama-cpp-dsv4vision in .agents/oracles/, gateable = no until a leased build-and-run. It is a runnable reference and a quant-matched denominator for the artifact above; it is not a mirror source and does not outrank the model author or vLLM.

    3. Two language-side behaviours were missing from the spec

    Reading that implementation found two DeepSeek-V4 language behaviours that change under image input and that the spec never mentioned. Both are the failure mode the spec's own risk 3 names: drop either and the argmax stays plausible while a token gate stays green.

    • exp_probs_b_vl — a second per-layer MoE routing bias, f32 [256], used when the routed token is an image token. The pinned text GGUF's entire first shard is these 43 tensors and nothing else. On the three hash layers it does not merely substitute a bias: text tokens there route through the tid2eid hash table and take no bias at all, so for an image token this bias replaces the hash routing.
    • The 128-token sliding window is not applied inside an image span. deepseek4.attention.sliding_window = 128 while an image block can be 384 tokens, so more than half a span can be invisible while generation still reads fluently.

    Both are specified, given tests that cannot pass on tokens alone, and listed under ## Owed.

    Wave status

    • W1 (prompt encoder, image processor) — landed on the row branch.
    • W2 (32-layer ViT, downsample-3 aligner) — landed on the row branch; focused gate 1/1, reduced-shape goldens transcribed from inference/vision.py at the pinned revision. Fresh review with mutations is owed.
    • W3A (deepseek4v mmproj reader) and W3B (exp_probs_b_vl accounting) — in flight.
    • W4 (per-token bias selection, image-span window, registered forward), W5 (runner/ABI/server), W6-W7 (real-artifact and device gates) — not started.

    Nothing here is a correctness or performance claim. No oracle has been built or run.

  2. 43 remaining items

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions