DeepSeek V4.1

Overview

DeepSeek V4.1 is the latest open-weight release in the DeepSeek line. It is a mixture-of-experts language model that is strong at step-by-step reasoning and at writing code. Because the weights are published, teams can run it on their own hardware, fine-tune it, or use it as a teacher to train smaller models through distillation.

This article explains what DeepSeek V4.1 is, how the DeepSeek family developed, and how a sparse reasoning model works inside. It includes a worked example, a comparison with other models, and a section on how a large language model relates to tabular foundation models that learn directly from raw tables. Exact sizes, context lengths and licence terms change from release to release, so confirm them on the official model card.

What it is

DeepSeek V4.1 is a large language model built on the Transformer design with a sparse mixture of experts feed-forward layer. In plain terms, the network holds a very large number of parameters, but only a small share of them are used for each token. That keeps the cost of each answer lower than the total size suggests.

Three ideas in one sentence

It is open-weight, so you can download and host it. It is a mixture of experts, so it is efficient per token. It is tuned for reasoning and code, so it does well on maths, logic and programming tasks.

What "open-weight" means

Open-weight means the trained numbers inside the model are published. It is not the same as fully open source. Training data and full training code may not be released, and the licence may carry conditions. Always read the licence.

• You can run the model privately, with no prompts leaving your network.
• You can fine-tune it on your own examples.
• You can compress it, for example by quantisation.
• You can study its behaviour more closely than a closed API allows.

What "reasoning" means here

A reasoning model is trained to work through a problem in steps before it answers. It may write a long chain of thought, check its own work, and try another approach if the first one fails. This costs more tokens but raises accuracy on hard problems. Many releases offer both a fast mode and a thinking mode, so check which modes V4.1 supports.

What "strong at code" means here

• Writing and editing functions, classes and scripts.
• Explaining and refactoring code.
• Finding and fixing bugs from error messages.
• Writing SQL and data-processing code.
• Working inside agent loops that read files, run tests and iterate.

Where it came from

DeepSeek is a Chinese AI lab that began publishing open models in 2023. Its early dense models and code models were followed by the DeepSeek-V2 generation, which introduced an efficient attention variant called multi-head latent attention and a refined mixture-of-experts layout.

A short timeline in general terms

• 2023: first DeepSeek language and code models appear with open weights.
• 2024: DeepSeek-V2 and then DeepSeek-V3 bring large sparse models with low training and serving cost.
• Early 2025: DeepSeek-R1 shows that reinforcement learning can teach a model to reason at length, and the lab also publishes smaller distilled versions of that reasoning ability.
• Later releases refine the V3 line with better reasoning, longer context and tool use.
• V4.1 continues the line as the current open-weight release.

Ideas the family is known for

• Multi-head latent attention, which shrinks the key-value cache so long contexts cost less memory.
• Fine-grained experts with a few shared experts that always run, plus many routed experts that run only when needed.
• Efficient training with low-precision arithmetic, for example mixed precision.
• Reinforcement learning with verifiable rewards, where the answer to a maths or code problem can be checked automatically.
• Publishing distilled smaller models so more people can run the reasoning style.

Where this fits in the wider field

The same sparse design appears in many other models, and the same open-weight approach is used by Qwen 4, Kimi K3 and others. Readers new to the idea can start with the mixture of experts page.

How it works

Follow one prompt through the model. Each step has an everyday analogy.

Step 1: Tokenisation and embedding

Text is cut into tokens by a tokenizer, usually trained with byte-pair encoding. Each token becomes a vector of numbers. Analogy: the text is chopped into labelled index cards, and each card gets a coordinate on a map of meaning.

Step 2: Attention

Each layer lets tokens look at earlier tokens. DeepSeek models compress the keys and values that attention needs into a smaller hidden form, then expand them when required. Analogy: instead of carrying every page of a book to each meeting, you carry a tight summary card and unfold it only when someone asks a question.

Step 3: Routing to experts

After attention, a small router scores the experts for each token.

• A few shared experts handle general patterns and always run.
• A larger pool of routed experts handles specialised patterns.
• Only the top few routed experts run for each token.

Analogy: a big consulting firm has a few generalists who join every meeting and hundreds of specialists who join only when their topic comes up.

Step 4: Load balancing

If the router sends too many tokens to a few favourite experts, those experts become a bottleneck and the others learn little. Training therefore includes a balancing mechanism that nudges tokens toward under-used experts. Analogy: a restaurant manager rotates orders so one chef is not overwhelmed while others stand idle.

Step 5: Predict and repeat

The final layer scores every token in the vocabulary and a sampler picks one. The new token is added and the loop repeats. Some recent models also predict several future tokens at once during training, which can improve quality and allow faster decoding.

Step 6: Thinking before answering

In thinking mode, the model first writes a hidden or visible chain of reasoning. It may list steps, test an idea, spot a mistake and fix it. The final answer follows. Analogy: a student who shows their work usually gets fewer sums wrong than one who guesses.

How the model is trained

1. Pre-training on a very large mix of text, code and maths with next-token prediction.
2. Long-context extension, so the model can handle large inputs.
3. Supervised fine-tuning on high-quality instruction and reasoning examples. See SFT.
4. Reinforcement learning, where rewards come from checkers for maths and code, and from preference models for general chat. See reinforcement learning and PPO for the background, and note that labs often use their own variants of these algorithms.
5. Distillation, where a big model's outputs train smaller students.

Why sparse models need a lot of memory but little compute

All experts must sit in memory, because any of them might be called. But each token touches only a few. So memory need follows total parameters, while compute per token follows active parameters. This is the central trade-off to plan around when you self-host.

Key concepts and terms

A worked example

This example shows two common uses: calling a self-hosted endpoint, and distilling answers into a smaller model.

Calling a self-hosted endpoint

Assume you serve the model with an OpenAI-compatible server such as vLLM or SGLang at a placeholder host.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://inference.example.internal/v1",
    api_key=os.environ.get("EXAMPLE_API_KEY", "placeholder"),
)

question = (
    "A table has columns age, income, region. "
    "Write pandas code that fills missing income with the median income of the same region."
)

reply = client.chat.completions.create(
    model="deepseek-v4-1",
    messages=[
        {"role": "system", "content": "You are a careful data engineer. Return code only."},
        {"role": "user", "content": question},
    ],
    temperature=0.2,
    max_tokens=800,
)
print(reply.choices[0].message.content)

A good answer groups by region, uses a transform with the median, and handles regions where every income is missing. Run the code on a sample before you trust it.

Serving it: a rough sizing walk-through

Suppose a model has 600 billion total parameters stored in 8-bit form. The weights then need about 600 gigabytes. That does not fit on one GPU, so you split it across many with tensor and expert parallelism. If you use 4-bit weights, the need falls to roughly 300 gigabytes. Add room for the KV cache, which grows with context length and with the number of concurrent requests. These figures are an illustration only. Use the real parameter count from the model card.

Distillation in outline

# Pseudo-code: build a training set from teacher answers.
prompts = load_prompts("prompts.jsonl")          # your own task prompts
rows = []
for p in prompts:
    answer = teacher_generate(p, mode="thinking")  # large model
    if passes_checks(p, answer):                   # unit tests or a verifier
        rows.append({"prompt": p, "response": answer})
save_jsonl(rows, "distill.jsonl")
# Then fine-tune a smaller student with LoRA on distill.jsonl.

Filtering is the key step. Keep only answers that pass a check, such as running tests. Then train a student with LoRA or full fine-tuning. Frameworks like TRL, Axolotl and Unsloth make this practical. Check the licence to confirm that using model outputs for training is allowed.

A numeric walk-through of expert routing

Imagine a layer with 64 routed experts and 1 shared expert. The router picks the top 4 routed experts for each token.

• Total experts in the layer: 65.
• Experts used for one token: 5 (1 shared plus 4 routed).
• Share of routed experts used: 4 out of 64, which is 6.25 percent.

Now picture a batch of 1,000 tokens. That is 4,000 routed assignments spread over 64 experts, so a perfectly balanced layer sends about 62 tokens to each expert. If the router is poorly balanced, one expert might receive 400 tokens while another receives 5. The busy expert becomes the slowest step, and every GPU waits for it. This is why load balancing during training and expert placement during serving matter so much.

How reasoning is trained, step by step

1. Start with a strong base model that already knows language, code and maths.
2. Collect problems with checkable answers, such as maths questions with a known result and coding tasks with unit tests.
3. Let the model attempt each problem several times, writing out its reasoning.
4. Reward attempts that end in a correct, well-formed answer.
5. Update the model so correct reasoning paths become more likely.
6. Repeat for many rounds, mixing in general chat data so the model stays helpful and readable.

Analogy: a chess student plays many games against a clock and a coach who only says "win" or "loss". Over time the student discovers habits, such as double-checking a move, that raise the win rate.

Why verifiable rewards are powerful

A checker that can say "the tests pass" is cheap, objective and tireless. It avoids the noise of human opinion. The limit is coverage. Many real tasks, such as writing a good email, have no simple checker, so labs combine verifiable rewards with learned preference models. See LLM as judge for how model-based scoring works and where it can go wrong.

Long context and memory cost

Every new token adds entries to the KV cache. For a long prompt, this cache can outgrow the weights in memory when many users share a server. Compressing keys and values, as latent attention does, shrinks the cache per token. That is one reason DeepSeek models are often described as cheap to serve at long context. Still, a 100,000-token prompt costs far more than a 1,000-token prompt, in both money and time, so trim context whenever you can.

Multi-token prediction in plain words

Normally the model predicts one next token. In multi-token prediction training, it also learns to guess a few tokens ahead. Two benefits are often cited: a richer training signal, and the option to draft several tokens at once and then verify them, which can speed up decoding. This is called speculative decoding when used at serving time. Check whether the build you use supports it.

A reading list of related pages

• Transformers for the base architecture.
• Mixture of experts for sparse layers in general.
• Mixed precision for low-bit training and inference.
• Tensor parallelism and pipeline parallelism for splitting big models.
• FlashAttention for fast attention kernels.
• DPO and RLHF for preference tuning.

Strengths and limitations

Strengths

• Strong reasoning on maths, logic and multi-step problems.
• Strong coding ability, including agentic coding loops.
• Open weights allow private hosting, audit and fine-tuning.
• Sparse design gives good quality per unit of compute.
• Distillation gives a path to smaller, cheaper models.
• An active community provides quantised builds and serving recipes.

Limitations

• Total memory need is large even though compute per token is low.
• Thinking mode can produce very long outputs, which raises cost and latency.
• Serving a large MoE model well needs skill: parallelism, batching and cache tuning.
• Like all language models, it can hallucinate and can be confidently wrong.
• Licence conditions and regional rules may limit some uses.
• Safety tuning differs from other vendors, so test refusals and policy behaviour yourself.
• Knowledge has a training cutoff.

Where it is not the best fit

• Tiny edge devices, where a small dense model is easier.
• Tasks that are really prediction on wide tables, where tabular models are the right tool.
• Settings where you need vendor-backed support contracts and cannot run your own stack.

How it compares with alternatives

Choosing between open and closed

• Pick open weights when privacy, cost control at scale or customisation matter most.
• Pick a closed API when you want the least operational work and the newest capabilities.
• Many teams use both: an open model for bulk work and a closed model for rare hard cases.

Choosing a serving stack

Role in tabular foundation models

DeepSeek V4.1 reads and writes text and code. Tabular foundation models read tables. They are different tools that often work side by side.

What tabular foundation models do differently

A tabular foundation model such as TabPFN, TabICL or TabSTAR is pre-trained on many tables, frequently synthetic ones generated from random causal structures. At prediction time you give it your labelled rows as context and your new rows as queries, and it answers in one forward pass. No gradient steps happen on your table. This is in-context learning on tabular data. For the design behind such models, see /model/architecture, and for evidence see /model/benchmarks.

Key differences from a language model:

• Input unit: cells, rows and columns, not subword tokens.
• Mixed types: numbers, categories, dates and text are encoded differently.
• Missing values are first-class, not just blank text.
• Column order should not matter, and column names may be missing or unhelpful.
• Row order should not matter either, so the architecture is permutation-aware. See axial attention for one way to attend across rows and columns.
• Pre-training teaches general rules of tabular data, not world knowledge.

Where DeepSeek V4.1 helps around those models

• Code generation: it can write the SQL or pandas pipeline that produces the clean table.
• Semantic understanding: it can read column headers and sample values and propose meanings, units and a sector label such as banking, retail or manufacturing. This pairs with semantic sector heads in tabular models.
• Imputation planning: it can suggest sensible fill logic and explain why, while a tabular model does the actual cell-level fill. See masked cell modeling and imputation networks.
• Anomaly explanation: after anomaly detection flags rows, the language model can describe in words what looks unusual.
• Agent planning: through function calling it can decide when to call a tabular model as a tool, and how to chain steps.
• Report writing: it turns feature importance and SHAP values into readable summaries.

Where DeepSeek V4.1 should not be used instead

• Predicting a target from tens of numeric columns. A tabular model or gradient boosting is more accurate and cheaper.
• Exact statistics over millions of rows. Use a database or Spark.
• Deciding anything from a table pasted into the prompt without checks.

A division of labour for a table workflow

Why column names are a double-edged sword

A language model leans heavily on column names. A column called "dob" is read as a date of birth at once. A tabular foundation model, by contrast, is built to work even when names are missing or meaningless, because it learns from the numeric and categorical patterns themselves. Used together, the two give you a cross-check: if the language model says a column is an age and the tabular model treats it as a count with an age-like spread, that agreement raises confidence. If they disagree, a person should look.

Distillation as a bridge

A large reasoning model can act as a teacher for small, task-specific models. For tabular work, that might mean generating labelled explanations, column descriptions or synthetic table specifications that help train a compact classifier. The tabular model still learns its numeric skill from tables. The language model supplies text-side knowledge. See synthetic data generation.

Continual learning view

Tabular models that must keep learning as new data arrives use methods such as EWC and experience replay. An open-weight language model can be updated with adapters, but a safe update needs a regression test set so old skills do not vanish. The same discipline applies to both worlds.

Practical guidance and best practices

Choosing a mode

• Use the fast mode for chat, extraction and simple edits.
• Use thinking mode for maths, tricky code and planning.
• Cap the reasoning budget so cost and latency stay bounded.

Prompting

• State the goal and the output format first.
• For code, provide the file, the error, the language version and the tests.
• For data tasks, give the schema and three sample rows, not the whole table.
• Ask for code that computes an answer rather than the answer itself.
• Keep system prompts short and specific.

Self-hosting

1. Read the licence and model card.
2. Choose precision: full, 8-bit or 4-bit, based on quality tests.
3. Plan GPU memory for weights plus KV cache.
4. Use a serving engine that supports MoE and expert parallelism.
5. Warm up the server and test with realistic prompt lengths.
6. Monitor time to first token, tokens per second, queue length and errors.
7. Keep a rollback plan for model updates.

Quantisation

Methods such as AWQ, GPTQ and GGUF files shrink memory use. Always compare quality before and after on your own tasks, because MoE routing can be sensitive to rounding.

Fine-tuning

• Start with prompts and retrieval.
• If you need more, use LoRA or QLoRA on a focused dataset.
• Keep a held-out set and track regressions.
• Mix in general data so the model does not forget broad skills.

Safety

• Filter inputs and outputs. See guardrails.
• Defend against injected instructions in documents. See prompt injection defense.
• Sandbox any code the model writes before running it. See sandboxing.
• Mask personal data before it enters prompts.

Observability

Trace requests, record token counts and keep example failures. Tools like tracing and evals pages describe how to do this.

Evaluating a reasoning model

Reasoning models need a slightly different test plan.

• Measure accuracy, but also measure tokens used per answer.
• Compare thinking mode against fast mode on the same set, so you know what the extra tokens buy.
• Check that answers stay consistent across repeated runs at the same settings.
• Include problems that the model should refuse or flag as unanswerable.
• Test long inputs, because quality can drop as context grows.
• Review a sample of reasoning traces for loops, repeated steps and made-up facts.

A simple deployment plan

1. Week one: call a hosted copy through an API and build your test set.
2. Week two: stand up a self-hosted copy in a test environment and compare results.
3. Week three: tune batch size, parallelism and context limits against your traffic shape.
4. Week four: roll out to a small share of users, watch the metrics and keep a switch to fall back.

Working with tables in a prompt

When a task needs a table, follow these habits.

• Send the schema and a few rows, not the whole file.
• Name the target column and say what each category means.
• Say how missing values are written.
• Ask for code and run it in a sandbox, then show the model the result.
• Compare the code's output with a trusted calculation on a small slice.

Common mistakes

• Judging memory need by active parameters instead of total parameters.
• Leaving thinking mode on for every request and then wondering about cost.
• Running generated code without a sandbox.
• Quantising to 4-bit without testing quality on your own tasks.
• Ignoring the licence when distilling or redistributing weights.
• Using one benchmark number to pick a model.
• Skipping a warm-up, so the first users see slow responses.
• Pasting giant tables into prompts and trusting the arithmetic.
• Not setting max token limits, so a single answer runs very long.
• Fine-tuning on a tiny, noisy dataset and making the model worse.
• Forgetting to pin the model build in production.
• Treating chain-of-thought text as a guaranteed faithful explanation of how the model decided.
• Sending every request to the biggest model when a distilled one would do.
• Forgetting that expert placement affects speed as much as raw GPU count.
• Not testing behaviour at the edge of the context window.
• Assuming a distilled student matches its teacher on every task.
• Skipping rate limits on a self-hosted endpoint, so one client starves the rest.
• Logging full prompts that contain personal data.

Frequently asked questions

What is DeepSeek V4.1?

DeepSeek V4.1 is the latest open-weight model in the DeepSeek family. It is a mixture-of-experts language model that is strong at reasoning and writing code. You can host it yourself, fine-tune it or use it as a teacher for smaller models, subject to its licence.

What does mixture of experts mean for this model?

The network has many expert blocks, but a router sends each token to only a few of them. This means the model has a large total size but uses only a fraction of it for each token. Compute per token is low, while memory need stays high because every expert must be loaded.

Is DeepSeek V4.1 free to use?

The weights are published, but open-weight does not mean free of conditions. A licence applies, and running the model costs hardware or hosting fees. Read the licence for commercial use, redistribution and use of outputs for training before you build on it.

What hardware do I need to run it?

It depends on the total parameter count and the precision you choose. Large sparse models usually need several high-memory GPUs, and smaller distilled or quantised versions can run on far less. Use the numbers from the model card and test with your real prompt lengths.

What is distillation and why is it linked with DeepSeek?

Distillation means training a small model to copy the behaviour of a large one by learning from its outputs. The DeepSeek family has published smaller distilled models that carry over some of the reasoning style of the large ones, which lets more people run them cheaply.

Can DeepSeek V4.1 analyse tabular data?

It can describe a small table, write code to analyse a large one and explain results in plain language. It is not the best tool for predicting a target from many columns. For that, use a tabular foundation model or gradient boosting, and let the language model handle code and explanation.

How is it different from a tabular foundation model?

A tabular foundation model is pre-trained on many tables and predicts a target column from the other columns using in-context learning, usually without any training on your data. DeepSeek V4.1 is trained on text and code and predicts the next token. They solve different problems and work well together in an agent.

Does it support tool calling?

Models in this class are generally trained to emit tool calls and structured output, and serving engines expose this through an API. Support details depend on the build and the server, so test your exact setup and validate every call before running it.

Should I use thinking mode all the time?

No. Thinking mode improves hard problems but adds many tokens and delay. Use it for maths, planning and difficult code, and use the fast mode for simple chat and extraction. Set a limit on the reasoning budget.

How do I keep its answers reliable?

Use a test set, low temperature for extraction, schema validation, retrieval for facts and sandboxes for code. Add human review for high-stakes outputs. No single setting removes errors completely.

Glossary

• Active parameters: parameters used for a single token.
• Agent: a program in which a model plans and calls tools.
• Chain of thought: written reasoning steps before an answer.
• Distillation: training a student model from a teacher model's outputs.
• Expert: one feed-forward block in an MoE layer.
• Expert parallelism: spreading experts across GPUs.
• Fine-tuning: further training on specific data.
• KV cache: stored keys and values from earlier tokens.
• Latent attention: attention with compressed keys and values.
• LoRA: a method that trains small adapter matrices instead of all weights.
• MoE: mixture of experts.
• Open-weight: weights available for download under a licence.
• Quantisation: lower-bit storage of weights.
• Router: the part that picks experts for each token.
• Thinking mode: a mode that writes reasoning before answering.
• Token: a unit of text.
• Verifiable reward: a reward computed by a checker program.

Summary

DeepSeek V4.1 is an open-weight mixture-of-experts model that is strong at reasoning and code. Its sparse design gives good quality for the compute used per token, and its open weights allow private hosting, fine-tuning and distillation. The costs are large memory needs, long outputs in thinking mode and the work of running a big serving stack.

For tabular data, treat it as the language, code and planning layer. It writes pipelines, interprets schemas, suggests imputation logic, explains anomalies and decides when to call a tabular model. Models that learn directly from raw tables, described at /model/research, /model/architecture and /model/benchmarks, should handle the prediction itself. Check the licence, test on your own data, sandbox generated code and keep humans in the loop.

Related

It belongs to Open-weight models in my stack, under LLMs, retrieval, and evaluation. Others in the same group: