It uses fewer active parameters, though. (8B or 14B instead of always 13B)
So ... flash indeed.
My attempt at a simplification of this article on it https://sebastianraschka.com/llm-architecture-gallery/per-la... into a couple of sentences is that they are linear embeddings of the input token space projected per layer, which are then gated by the transformer outputs per layer.
This would mean that the only one set of weights for the ple path needs to be pumped across the memory bandwidth as they are the same linear weights for all layers?
Sheit, maybe im trying to simplify something that i need to look at in detail. but id love to leverage others understanding if possible
You can put Qwen 3.8 Flash Next engram on SSD, but prompt processing takes a good hit. On my mac studio, I get 300 pp and 33 tg with SSD offload, versus 550/40 with everything in RAM.
I will be very happy if 300 pp is achievable with this model though.
Original Flash good fit for dual Spark / Strix Halo machines. This one would require third party quants and even then 4 machines.
Edit: Most of added weights/size are Engrams?
> Overall, DeepSeek-V4.1-Flash has 552B backbone parameters and 196B Engram parameters, activating 8B parameters per token during prefill and 16B during decode.
Those can stay on SSD. So I guess / it possible, that non-engram portion is still FP4 of ~same size! Need to read tech report.
552B in ~FP4, 306GB.
196B of FP8 Engrams, another 204GB, not necessary to keep in RAM.
KV cache sees another 4x size reduction, just 900MB for 1M.
can't wait for deepseek v4.1 pro