Downloads · 30 days
168
55% of all-time downloads
LibertAIDAI/DeepSeek-V4.1-Flash-REAP-272E
DeepSeek-V4.1-Flash-REAP-272E is a image-text-to-text model from LibertAIDAI. Use it for the image-text-to-text task on the model card, and read the license before you ship it in a product. It is set up for transformers. The card lists the license as mit.
deepseek-ai/DeepSeek-V4.1-Flash with its routed-expert pool pruned 384 → 272 per layer (−29.2%) by REAP — router-weighted expert activation pruning — calibrated on text and images.
Downloads · 30 days
168
55% of all-time downloads
All-time downloads
307
Public
Repo size
223 GB
Likes
1
Public
Click a slice to open those files.
.safetensors223 GB · 100%
From the Hugging Face model README
deepseek-ai/DeepSeek-V4.1-Flash with its routed-expert pool pruned 384 → 272 per
layer (−29.2%) by REAP — router-weighted expert activation pruning — calibrated on
text and images.
475.2 GiB → 396.8 GiB. Nothing is re-quantized: experts stay MXFP4 (E2M1 + E8M0,
block 32), dense layers stay FP8 block 32×32, the Engram tables are untouched. The only
change is that 112 of 384 experts per layer are gone, along with their rows of
gate.weight, gate.bias and gate.bias_vl.
Recipe, calibration scripts and every measurement behind this card: github.com/Libertai/deepseek-v41-flash-reap
V4.1-Flash already ships in 4-bit — "expert_dtype": "fp4", and routed experts are
56.6% of the checkpoint. Converting them to NVFP4 makes the file bigger (4.5 bits/weight
against MXFP4's 4.25). With precision already spent, the remaining lever on this
architecture is the expert count.
| size | experts/layer | |
|---|---|---|
deepseek-ai/DeepSeek-V4.1-Flash | 475.2 GiB | 384 |
| this repo | 396.8 GiB (207.7 GiB here + 189.1 GiB Engram from the base repo) | 272 |
-REAP-256E | 385.5 GiB | 256 |
Backbone parameters fall from ~552B to ~393B. Active parameters are unchanged (6 routed + 1 shared per token) — pruning buys memory, not decode speed.
Held-out text perplexity, 65,504 tokens, verified zero overlap with the calibration corpus:
| experts kept | perplexity | vs unpruned |
|---|---|---|
| 384 (unpruned) | 3.6552 | — |
| 272 (this repo) | 3.8060 | +4.13% |
| 256 | 3.8557 | +5.49% |
| 192 | 4.1910 | +14.66% |
Caption perplexity conditioned on held-out images, loss over caption tokens only (2,048 caption tokens), at 272 kept, by ranking:
| ranked by | caption ppl | vs unpruned |
|---|---|---|
| (unpruned) | 24.307 | — |
| text + image saliency (this repo) | 24.769 | +1.9% |
| random | 26.066 | +7.2% |
| text-only saliency | 28.173 | +15.9% |
No downstream task benchmarks were run. Perplexity is not a benchmark.
The model carries two router biases — gate.bias and gate.bias_vl — and their
correlation is −0.05 (min −0.45 across layers). Expert specialisation here is
modality-dependent.
Rank experts by text saliency alone and you discard 267 experts that a combined ranking keeps, including cases like layer 0 expert 235: 376th of 384 on text, 21st on images. The resulting checkpoint is worse than randomly pruning the same number of experts on vision — and its text perplexity looks fine, marginally better than the combined ranking. Only an image-conditioned evaluation catches it.
If you prune this model yourself, calibrate on both modalities.
{1,2,4,8,16,32,64,128,192,256,320,384,448,512,576}. 272 is not in it, and
the engine refuses to start with Unsupported expert number: 272. If you are serving
under vLLM, take 256E.--mode balanced, see the recipe repo). Straight mean
saliency collapses the vision path below 272 — caption perplexity 30.959 at 256 —
because the calibration corpus has 5× more text tokens than image tokens and the mean
score inherits that ratio. Balanced ranking brings it back to 26.479, but pays for
it on text: 4.1723 against mean-saliency's 3.8557 at the same 256 experts. There is no
setting at 256 that gets both. 272E needs no such trade — it is the better checkpoint
on every axis measured, and the only reason to prefer 256E is that an engine will load it.This checkpoint does not load under vLLM (272 is not in the fused router's expert-count table). The numbers below are from its sibling 256E on the same hardware, and every kernel-level note applies to any DSV4.1 checkpoint on sm_120/121.
Verified on 2× GB10 (sm_121, 120 GB unified each) under vLLM TP=2 over RoCE, with the Engram tables read from NVMe rather than resident:
| decode, c=1 | 13.7 tok/s (median of 5 warm) |
| KV cache | 1,437,437 tokens @ 64K ctx — 21.9× concurrency |
| weights | ~94 GiB/rank; Engram 47.2 GiB/rank left on disk |
--gpu-memory-utilization | 0.90 (0.80 leaves no room for KV; above ~0.91 the free-memory check trips) |
Four things this needs that are not obvious:
--enforce-eager is mandatory. With CUDA graphs on, the model loads, serves, and
returns fluent-looking bytes that are NaN all the way down — logprobs fails with
Out of range float values are not JSON compliant: nan. Eager costs ~7% here (14.5 →
13.7 tok/s), which on this hardware is the right trade; GB10 is bandwidth-bound, so
graphs buy little anyway.
FlashInfer has no sparse-MLA kernel for this model's index widths. DSV4.1 mixes
compress ratios, giving topk 1152 and 640, and the instantiation list is keyed
on (num_heads, topk) — so the entries you need depend on your TP degree
(TP=2 → 32 heads, TP=4 → 16). Without them the engine dies at profiling with
"SM120 sparse-MLA has no decode kernel for this shape".
Patching the .cu alone does nothing. The wheel ships a prebuilt AOT
sparse_mla_sm120.so and is_aot short-circuits the JIT path, so your edit is never
compiled. Mask the AOT directory, prebuild into a persistent cache, and mount that
cache at serve time.
Wire the reasoning parser, or the chain-of-thought lands in content. Thinking is
on by default and the chat template supplies the opening <think>, so with no parser
you get raw reasoning followed by a bare </think> inside content, and a reasoning
field sitting null. The parser ships and is registered as deepseek_v41 — the
same name serves both kinds:
--reasoning-parser deepseek_v41 --enable-auto-tool-choice --tool-call-parser deepseek_v41.
The field is reasoning, not reasoning_content.
The patch and both launch scripts are in the recipe repo.
This repo carries shards 1–46 only (208 GiB): the pruned weights, the config, the tokenizer, and the checkpoint's bundled reference implementation.
Shards 47–48 are the two Engram tables and are NOT in this repo. Pruning does not touch them — they are byte-identical to the base model, 189.1 GiB, and re-uploading them would cost every user a second copy of data they may already have. Fetch them from the base model and drop them in:
hf download LibertAIDAI/DeepSeek-V4.1-Flash-REAP-272E --local-dir dsv41-reap272
hf download deepseek-ai/DeepSeek-V4.1-Flash --local-dir dsv41-reap272 \
--include "model-00047-of-00048.safetensors" "model-00048-of-00048.safetensors"
model.safetensors.index.json already references them, so the model loads once both
files are present.
The Engram lookup is a hashed n-gram gather — 48 rows per token, ~12.4 KB — not a matmul. It never needs to be resident, which is why it can be served from disk or host RAM rather than accelerator memory, and why leaving it out of this repo costs nothing architecturally.
The FP4 Engram tables from
LibertAIDAI/DeepSeek-V4.1-Flash-NVFP4
(97.6 GiB instead of 189.1, cosine 0.9934) are a size-for-accuracy alternative —
lossy and untested under any serving engine, offered as-is.
config.json records the provenance:
"pruned_from": {"n_routed_experts": 384, "method": "REAP",
"calibration": "262,144 text tokens + 256 images, saliency combined"}
Model: inherits the base model's license. Tooling: MIT.