DeepSeek V4.1 Flash 1017 is 510 GB under MIT: 16B active, 763B stored, as read on 19 October 2026

510.3 GB of weights, and no single GPU holds them

DeepSeek's Hugging Face repository for V4.1 Flash 1017, created on 17 October 2026, holds 48 weight files that total 510,296,708,312 bytes: 510.3 GB, or 475.3 GiB (derived from the file listing). The repository's own index records 510,286,023,000 bytes of tensor data; the difference is file headers. The same files hold 763,205,315,794 parameters by Hugging Face's count, which this briefing reproduced by reading the tensor headers of all 48 files (derived). That is 5.35 bits per parameter on average (derived), because the expert weights are stored at four bits.

The model is called Flash. DeepSeek's change log describes the 10 September release that this one updates as "the smallest model in our new architecture family". One NVIDIA H200 has 141 GB of memory on NVIDIA's page, which is 27.6 per cent of the weights (derived). Three H200s cannot hold the files; four can, with 53.7 GB to spare (derived).

What that figure does not establish: how fast the model runs on that hardware, how well it answers on any given task, whether it is safe to expose, what it cost to train, or what data it learned from. Every speed in this briefing is an upper bound set by memory bandwidth, not a benchmark. Every figure marked derived is arithmetic on files and datasheets that anyone can repeat; the steps are in the checking notes.

Method. The briefing reads the 1017 model card, configuration, licence and file listing; the headers of all 48 weight files, fetched as small byte ranges so that none of the weights was downloaded; the card for the base V4.1 Flash release and the 51-page technical report it links, which are the only places the architecture is described; DeepSeek's release note, change log, pricing page, Open Platform Terms and privacy policy; NVIDIA's own product pages for every memory and bandwidth figure; Artificial Analysis, Vals AI and the CWE-bench leaderboard for independent numbers; and, for the UK, the AI Security Institute, the Department for Science, Innovation and Technology (DSIT) Code of Practice, the NCSC guidelines, the ICO and the Open Source Initiative. Everything was fetched with plain web requests between 18:58 and 19:40 BST on Monday 19 October 2026, and no form was filled in. Interests. DeepSeek sells API access to this same model under the name deepseek-flash, so its launch post is also a product page. NVIDIA sells the accelerators. Artificial Analysis, Vals AI and Collinear AI, which publishes CWE-bench, publish rankings that vendors cite. The same arithmetic was done for two earlier launches: Meta Muse Spark Open and Reflection Beam.

Four sizes for one name, and the card for these weights states none of them

A deployer is given four different headline figures for the size of this model (16B, 552B, 763B and 510 GB), and the 1017 card gives none of them. That card calls the release "a minor update to DeepSeek-V4.1-Flash", lists eleven benchmark rows and says nothing about parameters, memory or numeric formats. The sizes are in the 10 September card for the base model and in its 51-page technical report, which sit in a different repository.

The size figures for one model, who states each and whether the released files agree. Sources: DeepSeek's base V4.1 Flash card and technical report (10 September 2026), Hugging Face's summary and file listing for the 1017 repository, Artificial Analysis, and this site's reading of the tensor headers (derived).

Figure	What it counts	Stated by	Checked against the files
8B prefill, 16B decode	Parameters used per token. Reading a prompt skips the decoder half	Technical report and base card. Artificial Analysis lists 16B active	Derived 16.1B for decode from the tensor shapes: 6 of 384 experts per layer, the shared expert, attention and the output head. Agrees
552B backbone	The language backbone, without Engram	Technical report. Artificial Analysis lists it as total parameters	Derived 551.6B. Agrees
196B Engram	Lookup tables stored in FP8 and read sparsely	Technical report	Derived 196.6B, or 202.8 GB with scale factors. Agrees
763.2B stored	Every tensor: backbone, Engram, the 14.2B DSpark drafter and the 0.5B vision encoder and aligner	Hugging Face's summary of the 1017 repository	Reproduced exactly from the tensor headers
510.3 GB	Bytes on disk in 48 files	Hugging Face file listing	Equals the repository index total plus file headers

Where the released files can be checked against the report, they agree. The decode figure, the backbone, the Engram tables and the cache size (in its own section below) all reproduce from the tensor shapes and the configuration. That deserves saying plainly: the report's sizes are not marketing arithmetic. What they do not do is tell a buyer what to buy. Active parameters set the compute for each token. The 16 billion are 2.1 per cent of the stored parameters, and the 13.0 GB they occupy at batch size 1 is 2.6 per cent of the files (derived). Neither number says how much memory to buy, because every one of the 384 experts in each of 40 layers must sit where a GPU can reach it.

The friendly name. "Flash" names a tier inside DeepSeek's range. By the report's tables the 552B backbone is 1.94 times the 284B of V4 Flash and about a third of the 1.6T of V4 Pro (derived). Against its own family it is small. Against one GPU it is 3.6 times too large (derived). Hugging Face's registry lists the experts as 557 billion "I8" parameters although the tensors are 278.6 GB, because each byte holds two 4-bit values; an asset register that copies that line will record eight-bit weights that do not exist.

What changed on 17 October. The 1017 repository has the same shape as the one it updates. Its configuration and licence file are identical to the base repository's, its index maps the same 96,085 tensor names to the same files, and all 48 weight files have the same sizes as in the 10 September repository. Yet every one of the 48 files has a different content identifier on the Hub (derived from the two file listings). The architecture is unchanged and every weight file is new: a new version for anyone who pinned a hash. On the API, DeepSeek says deepseek-flash now serves 1017 and that the legacy names deepseek-v4-flash and deepseek-v4-flash-vision-exp, "still accepted", are served by it and "billed at the Flash price".

Weights by format: one mixed recipe, and the biggest table is the least read

DeepSeek ships one numeric recipe, not a ladder of BF16, FP8 and 4-bit copies. The configuration says the dense layers are FP8 and the experts are FP4. The table sums the 96,085 tensors in the 48 files by storage type.

Weight files of DeepSeek-V4.1-Flash-1017 by storage type, from the tensor headers of all 48 files read on 19 October 2026. GB is decimal. Sizes are derived by multiplying each tensor's shape by its element size; the total equals the repository index.

Stored as	Size	Share of the files	What it holds
FP4, two values per byte (Hugging Face lists it as I8)	278.6 GB	54.6%	Routed experts of the 40 layers (271.8 GB) and of the DSpark drafter (6.8 GB)
FP8 (E4M3)	204.0 GB	40.0%	Engram tables (196.6 GB); attention, shared experts and Engram projections, about 7.4 GB
Scale factors (E8M0)	23.6 GB	4.6%	One byte per block of values: experts 17.0 GB, Engram tables 6.1 GB, drafter 0.4 GB
BF16	4.0 GB	0.8%	Embedding and output head (2.6 GB), vision encoder and aligner (1.0 GB), routers and the rest
FP32	0.17 GB	0.03%	Small mixing and bias tensors
Total	510.3 GB	100%	475.2 GiB. The same 763.2 billion parameters in BF16 would be 1,526.4 GB; the release is 33.4 per cent of that (derived)

Read by role instead of by type, the picture changes. The routed experts are the bulk of the stored parameters and are read sparsely. The Engram tables are the second-largest part and the least read.

Where the bytes sit, and how much of each is read to produce one token at batch size 1. Sizes include scale factors. Parameters are derived from tensor shapes, counting each FP4 byte as two values. Read-per-token figures are derived from the configuration and the technical report's description of Engram.

Part	Size	Parameters (derived)	Read for each token
Routed experts, 40 layers of 384	288.8 GB	543.6B	6 of 384 per layer: 4.5 GB (1.6%)
Engram tables, 2 layers	202.8 GB	196.6B	24 rows of 256 bytes per layer per token, about 12 KB in all (orders 2, 3 and 4, eight hash heads)
Attention, shared experts, Engram projections	7.2 GB	7.0B	All of it
Embedding and output head	2.6 GB	1.3B	The head only: 1.3 GB
DSpark drafter, 3 blocks	7.9 GB	14.2B	Only when speculative decoding is on
Vision encoder and aligner	1.0 GB	0.5B	Only when images are sent

The Engram tables are 39.7 per cent of the bytes (derived) and the least read. The technical report says that in inference the embeddings can be prefetched from host memory over RDMA. The reference code that ships with the weights does something different: it gives each GPU its share of the table rows. So the memory a deployer needs depends on which stack runs. With the reference code it is the whole 510.3 GB on GPUs, 63.8 GB for each of eight (derived, assuming an even split and ignoring the conversion step). With a stack that keeps the tables in host memory it is 307.5 GB on GPUs plus 202.8 GB of host memory (derived). No such stack is released with the weights.

Which hardware holds it, and the speed ceiling memory sets

The diagram draws the weights, and the same parameters at 8 and 16 bits for contrast, against the memory of five NVIDIA configurations to one scale. Memory and bandwidth are NVIDIA's own, as printed on its product pages on 19 October 2026: 141 GB and 4.8 TB/s for an H200, with HGX H200 systems offered with 4 or 8 GPUs; 1,440 GB and 64 TB/s for a DGX B200 of 8 GPUs; 13.4 TB and 576 TB/s for a GB200 NVL72 rack of 72.

The table adds the room left after the weights, and two ceilings on decode speed. A ceiling is aggregate memory bandwidth divided by the bytes read to produce one step. At batch size 1 a step reads 13.0 GB: the always-on layers, the output head and 6 of 384 experts in each layer (derived). If every routed expert is touched, as happens at larger batches, a step reads 297.3 GB (derived). The real figure at any batch lies between them.

Which hardware holds the weights, and decode ceilings in steps per second, each step yielding one token per stream. Memory and bandwidth are from NVIDIA's pages. Ceilings are derived upper bounds, weights only, empty cache, not benchmarks.

Hardware, memory and bandwidth	Room left after weights	Ceiling at batch 1	Ceiling if every expert is read
One H200: 141 GB, 4.8 TB/s	None: does not hold the files	Not applicable	Not applicable
Four H200: 564 GB, 19.2 TB/s	53.7 GB	1,473	65
Eight H200: 1,128 GB, 38.4 TB/s	617.7 GB	2,946	129
DGX B200: 1,440 GB, 64 TB/s	929.7 GB	4,910	215
GB200 NVL72: 13,400 GB, 576 TB/s	12,889.7 GB	44,189	1,937

Two limits sit behind the table. The H200 page lists FP8 and INT8 tensor-core rates and no FP4 row, while the DGX B200 page lists FP4. The experts are FP4, and the inference README does not say which GPU generations its kernels support, so whether four H200s can run the released code at all is not stated. The README's examples use eight-way model parallelism, and its reference code is described as "a readable reference implementation rather than a production serving engine".

The first row of the next table is the one the "16B active" headline suggests, and the last is what a busy server looks like. The share of experts read assumes tokens route uniformly across the 384 experts, which is an inference; real routing is uneven and so real figures differ.

Bytes read per decode step on eight H200s (38.4 TB/s) as the number of concurrent streams grows, derived under a uniform-routing assumption. Ceilings are upper bounds for all streams together.

Concurrent streams	Share of experts read in a layer	Bytes read per step	Ceiling, tokens per second, all streams
1	1.6%	13.0 GB	2,946
8	11.8%	42.7 GB	7,193
64	63.5%	191.9 GB	12,807
256	98.2%	292.2 GB	33,645

At one stream the model reads about 13 GB per step. At 64 streams it reads about 192 GB and at 256 about 292 GB, so the cheap-per-token story holds for a single user and fades on a shared server. That is the memory case against reading "16B active" as "a 16B model".

The cache: 890 bytes per token, but only in DeepSeek's own serving stack

The technical report states that the base model reduces its "global KV cache footprint (always in HBM)" to "890 bytes per token", roughly a quarter of DeepSeek's previous Flash. The configuration lets that be checked. Four layers (2, 8, 14 and 20) produce the shared main cache; the first three compress two tokens into one entry and the fourth keeps one entry per token, so 2.5 entries per token (derived). Each entry holds 512 channels at 4 bits with one 8-bit scale per 16 channels, 288 bytes, plus an indexer key of 128 channels at 4 bits with one 8-bit scale per 32, 68 bytes (derived; the scale sizes are stated in the report and in the code's comments). That is 2.5 times 356 bytes: 890 bytes, exactly the stated figure (derived).

At 1,048,576 tokens that is 933,232,640 bytes, 0.93 GB or 0.87 GiB, for one sequence (derived). The sliding-window part adds a constant 2.6 MB (40 layers, 128 positions, 512 channels, one byte, derived). The saving is real and the architecture is the reason the context length costs so little memory.

It is not what the released code allocates. The inference README calls the code a reference implementation. In it the cache tensors take torch's default data type, which the launch script sets to 16-bit, and the 4-bit step writes the rounded values back in place instead of packing them (the kernel's own comment says it "writes the dequantized values back"). Read that way the reference code holds 3,200 bytes per token, 3.6 times the stated figure (derived by reading the code, not by running it). The 890 bytes belong to the serving system the report describes, with its encoder, prefill and decode separation and persistent cache on SSD, none of which is in the repository.

Global cache for one sequence by context length. The 890-byte column is the report's figure, reproduced from the configuration. The reference-code column is derived by reading the released code. Both exclude the constant 2.6 MB window cache.

Context	At 890 bytes per token (stated, checked)	Reference code, 16-bit caches (derived)
32,768 tokens	29.2 MB	104.9 MB
131,072 tokens	116.7 MB	419.4 MB
262,144 tokens	233.3 MB	838.9 MB
1,048,576 tokens	933.2 MB	3,355.4 MB

The cache is not what sizes the machine. On eight H200s the 617.7 GB left after the weights would hold the global cache of 660 sequences of 1,048,576 tokens at 890 bytes per token, or 184 with the reference code's caches (derived; cache only, ignoring activations, the drafter and engine overhead). On four H200s, with 53.7 GB left, the figures are 57 and 16. The weights, not the cache, set the size of the server.

The report is candid about what the compression does not yet show. It says the new design creates "robustness boundaries that have yet to be fully characterized" and that selection errors in the sparse attention and approximate state reconstruction "may still cause capability degradation in untested boundary cases". The card recommends a 1M-token context window and at least 256K of output. Neither says how the model behaves at the edges of that range.

Independent numbers two days after release: two sources list the model, one does not

Artificial Analysis lists the 1017 weights, and so does Vals AI. CWE-bench does not. The table sets each number beside who ran it and what it cost, as read at about 19:05 BST on 19 October; rankings and prices on these pages can change within hours. Artificial Analysis says its performance figures come from the model's first-party API, and both it and Vals price tokens at $0.30 per million in and $1.20 out, which DeepSeek's pricing page gives as the peak rate; the off-peak rate is half. OpenRouter, a marketplace, lists the same time-of-day schedule for its record of the model, created at 08:27 UTC on 17 October, about six hours after the Hub repository.

Measurements of DeepSeek V4.1 Flash 1017 read on 19 October 2026 from Artificial Analysis, Vals AI, the CWE-bench leaderboard and DeepSeek's release chart. Cost is beside each score. The Artificial Analysis rows are the max-effort variant.

Measure and who ran it	Score	Cost beside it	Note
Artificial Analysis Intelligence Index v4.3.2, Artificial Analysis	45.1, second of 121 open-weights models in its class	$0.26 per task; $444.60 for the run; 210.9M output tokens	Page text: "very verbose" against the median
Terminal-Bench 4.0 inside that index, Artificial Analysis	33.8%	$0.88 per task, 218,213 output tokens	DeepSeek's card says 42.3 with the Claude Code harness
Humanity's Last Exam inside that index, Artificial Analysis	43.3%	$0.05 per task	DeepSeek's card says 42.6 without tools
AA-Omniscience, Artificial Analysis	42.85% accuracy; 66.75% hallucination rate as reported	$0.002 per task	Base release: 46.4% and 96.46%. The rate's definition was not read
Vals Index v2.1, Vals AI, updated 18 October	56.58%, rank 14 of the 22 models shown	$0.64 per test	Top model 68.90% at $15.68 per test
CWE-bench, Collinear AI	Not listed. The 10 September base model is: 55% programmatic Pass@1, 74% Pass@4	$0.09 per rollout, opencode harness	Defensive audit-and-patch tasks; a different model version
DeepSWE v1.1 Pass@1, DeepSeek's release chart	77.0%, max effort, mini_swe_v2 harness	About $0.19 per task, read off a log axis	Approximate; other vendors' points are from public leaderboards and charts

The cost beside the score is the point. Within Vals's own table the top model scores 68.90% at $15.68 per test and this one 56.58% at $0.64, a cost ratio of about 24.5 to 1 for a gap of 12.3 points (derived). That is a statement about this model's price, which DeepSeek sets. The hosted API's price tells a self-hosting deployer nothing about the cost of the machine in the previous section.

Does the update do what the card says? The card claims "substantial improvements across reasoning, coding, agentic tasks, and visual benchmarks" and a model that "reduces task execution time and output length". Artificial Analysis lists both versions on the same index, so the comparison is like for like. It supports the direction on score and cost and splits on length.

DeepSeek's claims for 1017 against Artificial Analysis's measurements of the 10 September base and the 1017 weights, both max effort, read on 19 October 2026. Changes are derived.

Claim on the card	Artificial Analysis, base then 1017	Change
Substantial improvement across benchmarks	Intelligence Index 39.5 then 45.1	+5.6 points
Lower cost	Cost per task $0.486 then $0.262	-46%
Shorter outputs	Output tokens in the run 253.1M then 210.9M. Weighted output per task 88,574 then 89,495	-16.7% in the run total; +1.0% per task. The two measures disagree
Less task time	Time per task 293 s then 289 s	-1.5%
Terminal-Bench 4.0 gain	DeepSeek's card: 31.2 then 42.3. Artificial Analysis: 26.8% then 33.8%	+11.1 points claimed; +7.1 measured

The Terminal-Bench gap deserves a closer look. The card's footnote says the Claude Code harness is used for Terminal-Bench 4.0. The 31.2 in its base column equals the figure in the 10 September release, where DeepSeek says code-agent benchmarks used the minimal mode of its own harness. The card does not say the base column was re-run under the new harness. The base report's scaffold table shows how much the harness alone can move a score: 65.5 to 74.2 on DeepSWE v1.1 and 84.1 to 90.6 on Terminal-Bench 2.1 across the eight harnesses, spreads of 8.7 and 6.5 points (derived). The direction of the improvement is independently supported. Its size, as printed on the card, mixes harnesses.

The card's table also shows where 1017 trails the strongest comparator in it. Against the Opus 5 column, DeepSeek reports 42.6 against 56.3 on Humanity's Last Exam without tools, 42.3 against 51.8 on Terminal-Bench 4.0, 29.1 against 37.0 on ProgramBench and 68.2 against 75.3 on NL2Repo-Bench, and leads on DeepSWE v1.1 (77.0 against 74.0), Automation-Bench (60.5 against 50.3) and Agents' Last Exam (35.4 against 28.6). The card does not say who ran the comparator numbers, which harness each used or what each cost.

What the launch establishes, and what it does not

The vendor pages are claims. The table sets each item against what the record states and what it leaves out. "Not stated" means not found in the pages named, read in full or searched; it does not mean the information does not exist.

Stated and not stated, by item. Sources: the 1017 card, configuration and licence; the base card and technical report; DeepSeek's release note and change log; the repository file listings; the README for the reference code.

Item	Stated	Not stated
Size of the 1017 weights	Nothing on the 1017 card. The base card and report give 552B backbone, 196B Engram, 8B and 16B active	Any size statement for the weights you download; the 510 GB or the 763B
Training data	45T tokens of multimodal data, a 7 to 1 ratio of text to multimodal tokens, and descriptions of how data was filtered and scored	Which datasets, their sources, their licences or any list a skilled person could rebuild from
Training hardware, compute and cost	Nothing found in the 51 pages: no accelerator, no GPU hours, no cost	All three
Safety evaluation	One sentence in the report: given "the dual-use nature" of cyber capabilities, the community is encouraged "to apply them responsibly"	Any safety report, red-team result, refusal rate or system card. The repository holds no such document
Cyber capability	For the base release only: CyberGym 88.1, SEC-Bench Pro 62.8, ExploitGym 15.3, run by DeepSeek, "a new state of the art among open-source models"	Whether 1017 moved those numbers. The 1017 card lists no cyber benchmark
Real throughput	Decode FLOPs and cache size in the report; prices on the API	Tokens per second on any named hardware, or the hardware behind the API
Reproducibility	The base repository has an evaluation folder for DeepSWE v1.1	Any such folder or harness settings for 1017. The 1017 repository has encoding and inference folders only
Prompt format	No chat template in the Jinja format. A reference encoder and a separate library are offered	Whether common serving engines apply the format correctly without them
Use rules	MIT licence for "this repository and the model weights"	Any acceptable-use policy, user cap, naming rule, field or geographic limit. None is in the licence file or the card

One item deserves its own line. The report is more open about limits than the card is. It says "a performance gap remains on the most challenging tasks" against the leading closed systems and that benchmark parity "does not imply" frontier capability. A deployer reading only the 1017 card sees eleven rows of gains and none of that.

"Open": what the licence covers, and what is not in the box

DeepSeek's release note headlines the weights as an "Open-source release". Artificial Analysis labels the model "open weights" and classes the licence "permissive". The licence file is the standard MIT text, headed "Copyright (c) 2023 DeepSeek". It grants permission "free of charge" to use, copy, modify, merge, publish, distribute, sublicense and sell, on one condition: the copyright and permission notice must go with copies. The model card adds the sentence that matters for weights: "This repository and the model weights are licensed under the MIT License." The file is identical to the base repository's.

The same file says the software is provided "AS IS" without warranty, and that the authors are not liable for any claim. So the licence gives no warranty of fitness, no indemnity and no statement about the rights DeepSeek held in the training data. That is silence, not a finding; whether the training data raises any issue is something the record neither says nor rules out. This is a description of the text, not legal advice.

The Open Source Initiative's Open Source AI Definition 1.0 says what it asks of "Open Source weights": that they come with the "data information" and the code used to derive them. It is used here only to say what a definition requires, not to accuse. The table sets its three elements against the repository.

The Open Source AI Definition 1.0's required elements against the 1017 and base repositories and the technical report, as read on 19 October 2026.

Element the Definition names	What it asks for	In the release	Not in the release
Parameters	The model parameters, under OSI-approved terms	48 weight files under MIT	Intermediate checkpoints or optimiser state
Code	The complete source code used to train and run the system	A reference inference implementation, an encoder for prompts, a weight converter	Training code, data-processing code, the production serving stack and the agent sandbox platform the report describes
Data information	A complete description of the training data, with provenance and a listing of public and third-party data	A category-level description in the technical report	A listing of datasets or where to obtain them

The hosted service is a different contract. The weights are MIT. The API runs under DeepSeek's Open Platform Terms, effective 29 April 2026, which are governed by "the laws of the People's Republic of China in the mainland" and cap DeepSeek's liability at the fees consumed in the previous twelve months. A team that tests on the API and then self-hosts changes both the legal terms and the place where its prompts are processed.

What open weights change. Once downloaded, the weights cannot be withdrawn, and the lab's usage rules bind only through the licence, which here contains none. The UK AI Security Institute puts the wider point this way: once open-weight models are released, safeguards "can be removed, and copies can be downloaded, redistributed, and run on private systems beyond monitoring". That is the Institute's statement about open-weight release in general, not a finding about this model.

Self-hosting against the hosted API: where the prompts go

The same model is available two ways, and the answer to "where does my data go" differs. DeepSeek's privacy policy, last updated 10 February 2026, names the controller as Hangzhou DeepSeek Artificial Intelligence Co., Ltd., "with its registered address in China", and says "we directly collect, process and store your Personal Data in People's Republic of China". It lists, among purposes, "to train and improve our technology", and gives a right to opt out of training use. It also says the Services are not designed to process sensitive personal data, and that users should not provide it.

That policy covers DeepSeek's apps, websites and software. For the API it says something narrower. It states that the rules for end-user data in applications built on the open platform "are not covered by this privacy policy", and the Open Platform Terms make the developer the controller of that processing, who must obtain a legal basis for "delegation of personal information processing" to DeepSeek. The pages read do not say where API inputs are stored, how long they are kept or whether they are used for training. The policy names Prighter Group as DeepSeek's representative for UK data subject requests.

What the ICO says applies. The ICO's brief guide to international transfers, last updated 15 January 2026, says UK GDPR transfer rules apply when the UK GDPR covers the processing, you initiate the transfer and the recipient is a separate legal entity outside the UK, and that "every restricted transfer" must be covered by adequacy regulations, appropriate safeguards or an exception. Whether UK adequacy regulations cover the People's Republic of China was not confirmed from a primary list for this briefing, so a team sending personal data to the hosted API should ask its data protection officer to confirm the mechanism and the transfer risk assessment before the first prompt, not after.

Self-hosting removes the transfer and adds the work. Open weights, in the AI Security Institute's words, "can be hosted privately, with no data returning to the model providers". That is the case for the weights. It is not a case for the code: the reference inference code and the separate prompt-encoding library were not audited for outbound connections, and the inference nodes should be treated as untrusted until they have been tested with egress blocked. Third-party hosts of the weights, such as aggregators, are a third route whose processing locations were not read.

UK context: nothing UK-specific on this model, and a voluntary Code that already asks the right questions

AI Security Institute. The Institute's home page and its 17 July 2026 post "How Far Behind the Frontier are Leading Open Weight Models on Cyber?" were read in full, and its blog index was searched for DeepSeek. The post tests GLM-5.2 and DeepSeek V4-Pro, not V4.1 Flash or 1017, and finds the two perform "similarly to frontier closed models released 4 to 7 months before them". Of V4-Pro it says it "occasionally refused" narrow cyber tasks, which the Institute "circumvented simply via a small number of repeat attempts". It warns its result "is not predictive" of whether later open models will repeat the recent jumps by closed ones. Nothing on the pages read evaluates V4.1 Flash. The V4-Pro findings cannot be assumed to carry over to a different architecture and weights, and DeepSeek's own cyber scores for V4.1 Flash are higher than for V4-Pro on its tables (88.1 against 83.3 on CyberGym, a vendor comparison).

DSIT Code of Practice for the Cyber Security of AI (31 January 2025), voluntary and the basis of a planned ETSI standard. It applies to System Operators, defined as anyone who embeds or deploys a model, "including proprietary and open-source models". It notes that "some provisions for Developers" are "less applicable" to open-source models; it does not qualify the operator provisions in that way. The provisions below are quoted from the Code's own page.

Provisions of the DSIT Code of Practice for the Cyber Security of AI (published 31 January 2025), read on 19 October 2026, and what each asks of someone deploying these weights.

Provision	Exact wording, shortened	What it asks here
2.4	A Developer or System Operator who uses an external component "shall conduct an AI security risk assessment and due diligence process"	A documented assessment of this model before use
3.1, 3.1.2	Operators "shall analyse threats and manage security risks"; Developers manage "superfluous functionalities", for example a multi-modal model used for one modality	This model accepts images; if only text is used, threat-model the unused vision path
5.1, 5.2	Keep an inventory of assets and "track, authenticate, manage version control"	Record the repository, revision and the 48 files; 1017 is a new version
7.2	Models "not well-documented or secured" need a documented justification and mitigating controls	The 1017 card is thin; the size, safety and data gaps above are the ones to document
7.3	"re-run evaluations on released models that they intend on using"	Run your own tasks; the vendor's numbers and Artificial Analysis's differ
7.4, 11.2	Operators tell end-users before a model is updated; Developers treat major updates "as though a new version of a model has been developed"	Test 1017 as a new version; do not follow the deepseek-flash name automatically
8.1.2	Developers "shall release cryptographic hashes for model components"	The Hub lists a SHA-256 identifier per file; no signed release or separate checksum file was found in the listing. A match shows the copy equals what the Hub lists, not who built it
10.1	Tell users "where and how their data will be used, accessed and stored"	DeepSeek's policy puts its storage of personal data in the PRC and its terms do not say where API inputs are stored; tell users what is known and what is not
12.1	System Operators "shall log system and user actions"	Log prompts, outputs and tool calls on every route

NCSC. The Guidelines for secure AI system development (27 November 2023) tell providers to acquire "well-secured and well-documented" components, with models named, from "verified" developers, and to document "cryptographic hashes or signatures" and model cards. The pages read do not mention DeepSeek. A search of NCSC and ICO pages for statements naming DeepSeek was not made beyond the pages above.

What was looked for and not found. An AI Security Institute evaluation of V4.1 Flash; a published NCSC or ICO view on the model; a safety document from DeepSeek; a signed release. None was found on the pages named.

What to do, in the order worth doing

The order follows the evidence above: know exactly which copy you hold, decide where the data goes, size the machine, test it yourself, then expose it.

Nothing in the list needs a benchmark to justify it. Each item answers a gap this briefing found in the record.

What could not be verified

• Speed and capacity on real hardware. Nothing was run. Every speed is an upper bound from datasheet bandwidth, and the uniform-routing share of experts is an assumption.
• The cache in practice. The 890 bytes per token reproduce from the configuration, but the serving stack that achieves it is not released. The reference code's figure comes from reading it, not running it.
• Vendor benchmark scores. None was re-run. The comparator columns have no stated provenance, and the cost figure for the DeepSWE chart is read off a logarithmic axis.
• Artificial Analysis details. Its harness for Terminal-Bench 4.0 and its definition of hallucination rate were not read. Its hardware for speed is DeepSeek's own API.
• Training data, compute, safety testing. Not stated anywhere read, so nothing could be checked.
• Whether 1017 changed the cyber scores the base release reported. The 1017 card lists none.
• UK adequacy for the People's Republic of China. Not confirmed from a primary list.
• Whether FP4 kernels run on Hopper GPUs. The README does not say.
• A US procurement ban. A news report on 19 October of a US federal ban on DeepSeek products was seen and not used: the notice it describes was not yet published and it is US policy.
• Anything after 19:40 BST on 19 October 2026. Benchmark pages and the API's pricing and routing can change within hours.

The question that exposes the gap

When a team says it runs "a small Flash model", can it say how many gigabytes of weights it holds, which revision they are and where each prompt is processed? If the answer is "16 billion parameters", the name has done the work of a control.

Key facts