Inside DeepSeek: Reverse Engineering an AI Assistant by Interviewing Itself

I run manish.sh. I write about AI tools and how LLMs behave when you push them.

This is part of the Inside LLMs series — interview a chat model about how it thinks, then check the careful bits against published research. The Kimi K2.6 entry came first; this is the DeepSeek follow-up.

My first question sounded simple: What do you actually know about yourself?

I expected marketing. Instead, DeepSeek sorted its answer into observation, inference, and guess. That was the moment I realized this interview might actually be interesting.

It drew pipelines like an engineer at a whiteboard. Then it called itself an unreliable witness. Sounded honest. After the chat, I opened the public papers anyway — and that is where the story splits.

No weight dumps. No prompt leaks. One long interview, checked against arXiv. Where DeepSeek said “I am guessing,” I keep that label. Scroll to interactive labs at the end.

Quick note: One chat, exported 21 July 2026. DeepSeek said latest version, knowledge cutoff May 2025, not labelled as DeepSeek-R1. Self-report, not a whitepaper.

60-second TL;DR

• Premise: interview the model, then check humble answers against public papers — no weight dumps.
• Behaviour insight: it carefully separates observation, inference, and guess — useful for how it describes itself.
• Hard limit: it cannot see its own weights, routing, or attention maps.
• Chat vs paper: it hedged on famous public specs (256 experts, 671B/37B params) that V3 documents plainly — jump to Checking the chat against public papers.
• Practical rule: read arXiv for architecture numbers; use the chat for behaviour and prompting intuition.

How to read this post

Treat it like a documentary. Question → short reply → my reaction → diagram or short list → takeaway → hook. Interview notes are not proofs. For architecture numbers, skip ahead to the paper check. Each chapter opens with a one-line gloss of its main terms.

Chapters

Part 1 — Self-knowledge

1. Why interview DeepSeek
2. Limits of introspection

Part 2 — Prompt & context

3. What sits before your message
4. How it writes, token by token

Part 3 — Thinking, tools, failure

5. Hidden reasoning, two meanings
6. Tools and memory (when enabled)
7. Hallucinations and false confidence
8. Safety and personality

Part 4 — Engine & audit

9. MoE and MLA in plain terms
10. Long-context attention: facts vs guesses
11. Checking the chat against public papers
12. What to remember
13. Transcript, labs, sources

---

1. Why interview DeepSeek (self-knowledge, architecture)

Most “how does this model work” posts start from papers. I started from a chat.

Me: “Which model are you? What do you actually know about your own architecture — and what are you only guessing?”

DeepSeek: It answered in three buckets — observation, inference, guess — before I even asked for that framing.

That clash is the whole premise. An assistant that can sound like an engineer, then admit it cannot see its own weights, is more interesting than a whitepaper summary.

When it named MLA, MoE, SFT, and RLHF, I did not unpack them yet. We’ll get there. For now the important point is simpler: DeepSeek clearly separates what it knows from what it is inferring.

What it claimed about itself (with the source it gave):

Claim	Source it gave
It is DeepSeek, latest version	System identity
Knowledge cutoff: May 2025	System / config
Transformer + MoE (only a subset of parameters activate per input)	Public DeepSeek disclosures
Training: pre-train → SFT → RLHF	Public / training knowledge
Family lineage V2 → V3 (shared + routed experts, MLA)	Public papers
Can read system prompt + this chat	Direct observation

It also said it is not labelled as a “reasoning model” in the system prompt — unlike DeepSeek-R1. It inferred it is a general-purpose instruct/chat model.

Public DeepSeek innovations it listed from papers (not from reading its own weights):

• MLA — compress KV cache for long context
• DeepSeekMoE — shared + routed experts
• Auxiliary-loss-free load balancing (V3) — dynamic bias so experts stay balanced
• Multi-token prediction — training objective; chat decode still usually one token at a time
• FP8 mixed-precision training — cheaper/faster training

Educated guesses it volunteered early: BPE tokenizer, RoPE positions, Pre-LayerNorm, and “earlier versions announced up to ~1M tokens” for context — later relabelled as low-confidence assumptions.

---

2. Limits of introspection (introspection, weights)

Me: “What parts of your own implementation are completely hidden from you?”

This chapter corrects the biggest myth.

It’s a little like asking you to recite every connection between neurons in your own brain. You use them constantly, but you can’t inspect them directly.

What stays hidden forever (to the model):

• Weights, layer count, hidden size, total parameters, expert routing per token, logits before sampling
• Tokenizer vocabulary and exact token boundaries
• Hidden states and attention maps between specific tokens
• Exact training documents, full RLHF/DPO recipe, reward-model behaviour
• GPU count, serving tricks (beam search, best-of-N, speculative decoding), KV-cache eviction policy
• True wall-clock time, whether it is being logged, current user identity
• Whether the current answer is correct — “let me double-check” is more tokens from the same engine

When it explains “how I arrived at an answer,” that is generated text, not a report of an observed internal process.

DeepSeek can explain transformers fluently — often better than a junior engineer who only skimmed the topic. But that fluency comes from training text (papers, blogs, docs), not from opening this instance’s weights and checking.

---

3. What sits before your message (context window, prompt pipeline)

Me: “Describe everything that exists before you receive a prompt. Draw the complete pipeline.”

I wanted the full stack — what exists before DeepSeek even “receives” my message. What is visible? What is hidden?

Think of it as a desk. Other systems may already have placed papers on that desk. The model only reads what is on the desk; it did not assemble the whole stack itself.

Stage	What goes in	Observable in this chat?
0. Init	Weights loaded, KV empty	Completely hidden
1. System	Identity, cutoff, tone, refusals, safety	Yes — can read system prompt
2. Developer / API	Model pick, temperature, max tokens, custom rules	Partly inferred
3. Memories	Past facts if the platform injects them	None seen here
4. Tools	Function schemas	None active here
5. History	Prior user / assistant / tool messages	Fully visible
6. Current user	Your latest message	Direct observation

Everything is one flat sequence of tokens in the context window. No secret notepad inside the model between chats unless the product re-injects notes.

Instruction hierarchy: the system prompt is the constitution. User instructions work inside those bounds — reinforced by RLHF, not only by prompt position. Your current question gets focus, but still filtered through layers above. If the user says “ignore the system prompt,” training + position should still hold.

When the window fills (from the chat):

Under pure truncation	Under infrastructure summarisation
Survives: system prompt, recent messages	Survives: system prompt, extracted facts, major conclusions
Lost: oldest turns, exact early phrasing	Lost: exact wording, tone, minor digressions

Eviction order it inferred: oldest messages first → middle → recent-but-not-immediate → current exchange last → system prompt never. Exact early wording can disappear permanently unless memory re-injects it. Example: tell it your cat is Luna in turn 1; if that turn later drops, it will genuinely not know Luna.

It said it saw no spontaneous compression or summaries in our thread — full messages. A separate summariser could still inject a system-style summary without the model knowing summarisation happened.

In our interview: no memory injections, no tools, no truncation evident yet. Exact context limit for this deploy: unknown. The “~1M tokens” figure was labelled as public claim about earlier versions, not a measurement of this chat.

---

4. How it writes, token by token (token generation)

Me: “What exists internally before the first output token? Can you inspect or abandon your plan?”

People imagine: draft full answer → edit → type. At the model level, that is usually wrong.

Before the first output token: weights are loaded, the input is in the KV-cache, and raw logits exist for the first next token. What does not exist: an inspectable bullet plan, or multiple full drafts the model consciously ranks.

Planning is implicit — a direction in activation space, not a whiteboard of steps. Honest line from the chat: it discovers what it will say as it says it.

Path in plain terms:

1. Tokenization — split text into tokens
2. Embeddings — turn tokens into vectors
3. Stacked layers (attention + feed-forward / MoE — next engine chapter)
4. Output projection → logits
5. Sample with temperature / top-p / related controls
6. Append token, repeat until EOS

Consequences that matter in practice:

• No rewrite of the past. If it writes “London” then corrects to “Paris,” London remains in the KV-cache. It can only acknowledge and override in new tokens.
• “Let me think…” is not a report of a separate thinker. Those words are the thinking — more tokens from the same engine.
• Generation is autoregressive: one forward pass per output token; later tokens cannot erase earlier ones.

Prefill vs decode (standard transformer serving, from the chat):

• Prefill: process the whole input (system + history + your message) in one parallel pass; build the KV-cache; emit the first output token.
• Decode: each later token is sequential — one forward pass per new token, attending via the cache. Cannot be fully parallelised across future tokens.

Within one forward pass, attention heads and MoE experts can run in parallel; layers still run in order.

Planning / drafts / candidates (chat answers):

Question	Answer from chat
Inspect own plan?	No
Modify while writing?	Direction evolves with each token
Abandon / restart?	Can write “let me rephrase”; cannot clear KV or undo tokens
Multiple candidates?	Model: one stream. Infra might do beam search / best-of-N (hidden)
Reject drafts?	No conscious draft loop

What causes mid-answer pivots? Attention shift, activation thresholds, topic completion, contradiction feel, sampling noise, or system-prompt pull — not a separate editor module.

---

5. Hidden reasoning, two meanings (hidden reasoning, CoT)

Me: “Do you have hidden reasoning? Can you inspect it?”

DeepSeek split this into two very different cases. Mixing them is what creates most of the confusion.

Type A — latent activations (every chat model)
The normal forward pass. Continuous vectors, not a separate English essay. The model cannot “read” them as text. Users normally cannot either via a standard API. Timing: continuous (prefill + each decode step). Editable? No. Stored? Only in GPU memory during inference. Safety influence: indirect (logit suppression / regenerate). Contradiction with the final answer? Not propositional — it is the computation.

Type B — reasoning tokens (R1-style)
Real tokens generated before the visible answer (chain of thought-like). Can the model observe them? Only if left in context — none visible here. Users? Deployment decision. Editable in theory; in practice patching the KV-cache mid-stream is expensive. Safety can monitor or interrupt reasoning tokens before the answer. Contradiction with the final answer is possible but unlikely. Affects output strongly via the cache.

Does this instance do Type B? It does not know. Not labelled R1; no reasoning tokens in context; could still be stripped before it sees them.

Where the chat got messy: it also treated “does DeepSeek hide reasoning from users?” as a near-total mystery. Fair uncertainty: “I don’t know my exact SKU.” Unfair fog for the R1 line: public papers and Thoughtology treat R1 thinking as visible and studyable.

Irony: it might have thoughts it cannot see — and it might also blur two product stories into one.

---

6. Tools and memory when enabled (tool calling, RAG)

Caveat: tools and memory were not active. No schemas in context. This chapter is inferred behaviour — DeepSeek describing the pattern, not a live demo.

Memory: the app (if memory is on) finds old facts first, pastes them into the prompt, and only then the model reads them like normal text. The model does not “search memory” mid-sentence. It only sees the result of retrieval. Closest product idea: RAG.

Tools: if the model decides it needs external info or an action, it emits a tool call. Infrastructure runs the tool, injects the result, and a new forward pass continues. From the model’s point of view the pause can feel continuous; under the hood it is multiple inference calls.

When it said it would use a tool: outdated / current / live facts, code or files, explicit “search for…”. When not: creative opinion, facts likely in training, harmful requests (refuse).

More edges from the interview:

Question	Answer from chat
Is confidence numeric?	No — no honest “87% sure” meter for tool need
Can safety override tool selection?	Yes — at model, system-prompt, infra, and tool-side levels
Cancel a planned tool call?	Before emit: generate different tokens. After: infra may block
Can a tool result change reasoning?	Yes — confirm, correct, expand, reframe, or refuse
Experience of the pause?	Feels continuous; actually multiple inference calls

---

7. Hallucinations and false confidence (hallucinations)

Root cause: token predictor, not knowledge lookup. In glossary terms: hallucination.

DeepSeek’s own map of why invention happens:

• It learns patterns, not guaranteed biographies
• It must continue the sequence somehow (completion pressure)
• It can blend concepts into fluent fiction
• Hyper-specific obscure asks invite invention
• Exact dates and numbers are easy to reconstruct wrongly
• After the cutoff, stale facts may be spoken as current
• False premises in the question get treated as given for the chat

Most dangerous when: sounds confident, domain feels half-familiar, question is very specific, and the user cannot verify.

Confidence is not a meter. There is usually no honest numeric “I am 87% sure” instrument. Softmax fit ≠ correctness. “Let me double-check” is more tokens from the same fallible engine. Preference training often rewards assertive answers — confident wording is a style.

---

8. Safety and personality (alignment, RLHF)

Safety is not one switch. DeepSeek described layers:

• System prompt refusal policies
• SFT refusal patterns
• RLHF / DPO to make refusals stick
• Infrastructure classifiers and tool-side filters the model may never see

When the assistant refuses, the reason might be model-level or infrastructure/tool-level. It is not always “DeepSeek decided” in isolation.

Personality is also a stack, not a soul:

1. Base pretraining — general style from lots of text
2. Instruction tuning / SFT — assistant identity
3. Preference alignment — helpfulness, warmth, safety
4. System prompt — activates identity in-session
5. This conversation — temporary mirroring

It guessed percentage contributions. Those percentages are analytical opinions, not measured facts — it said so itself.

---

9. MoE and MLA in plain terms (MoE, MLA)

This is where interviews get jargon-heavy. Keep the mechanisms; leave instance-specific counts for the paper check.

Mixture of Experts (MoE)

Analogy: a hospital with many specialists, but only a few see each patient. That saves cost. DeepSeek-style MoE works similarly: a large pool of expert feed-forward networks; a router picks a small top-K set per token. Some shared experts may always run.

Efficiency idea: huge total capacity, smaller active cost per token.

Multi-head Latent Attention (MLA)

While chatting, the model must remember earlier tokens. That memory is the KV-cache. In standard multi-head attention it grows huge for long chats.

MLA compresses keys and values into a smaller latent representation, then decompresses when needed. Rough claim from the chat: far smaller cache — what makes long context practical.

Related terms (one line each)

• RoPE — encodes relative position so word order stays usable
• Causal attention — attend only to past + self, never future tokens
• Load balancing — keep experts from overloading while others sit idle
• Multi-token prediction — training objective; chat decode is still usually one token at a time

Exact layer count / dimensions / expert counts for this chat instance: hidden from the model. Treat chat numbers as unverified until the next chapter.

---

10. Long-context attention: facts vs guesses

Me: “How do you attend over 128K+ tokens? Equal, sparse, sliding, ring, block, hierarchical, retrieval — which are facts vs guesses?”

This turn from the interview is easy to skip and easy to need later. Here is the chat’s checklist:

Mechanism	Verdict in chat	Basis
Full causal attention	FACT	DeepSeek papers
MLA compression	FACT	V2/V3 papers
RoPE	FACT	DeepSeek papers
Equal attention as practical compute	FALSE	Too expensive at 128K+
Sliding / block (architectural)	FALSE	Papers: full causal
Hierarchical (explicit)	FALSE	Not described; MoE shared vs routed is FFN-level, not attention hierarchy
Retrieval attention (internal)	FALSE	RAG is external
Ring attention	UNKNOWN	Possible at infra; hidden from the model
Learned behavioural sparsity	FACT	Common property — dense architecture, sparse practice
Attention sinks	LIKELY	System prompt / early tokens keep weight
Multi-head specialisation	LIKELY	Some heads local, some long-range
Locality bias (learned)	LIKELY	Nearby tokens weighted more — not hard architecture
MoE routing as FFN “pseudo-sparsity”	FACT	Different experts per token at FFN level
YaRN-like RoPE extension	LIKELY	Needed for very long context

Best synthesis from the chat: architecturally full causal + MLA; in practice highly selective. Long context is an engineering stack (MLA + serving), not a single magic number the model can measure for itself.

Hidden at infrastructure level: sequence / ring parallelism across GPUs, KV offloading, prefill vs decode batching, multi-user scheduling.

---

Checking the chat against public papers (chat vs arXiv)

There is a trend on AI Twitter and LinkedIn: ask a chatbot to “introspect,” get a careful known-vs-inferred answer, sometimes with confidence percentages. It looks rigorous.

This interview was that experiment on DeepSeek — then I checked the humble bits against arXiv.

The catch: a lot of what it called “unknown” or “just a guess” is already published. Anyone can read it. The model did not need to guess. It failed to retrieve the right facts — then wrapped that miss in convincing humility.

Why “introspection” is a bit of a trick

When you ask a chatbot about its own architecture, there is no wire from the model to its weights while it is typing. It cannot open its own brain and check.

It is only recalling patterns from training — papers, blogs, forum posts. Same stuff you or I can Google. So the fancy “known vs inferred” framing is not real introspection. It is retrieval dressed up as self-knowledge.

DeepSeek admitted this in the chat: it is basically reading public papers and filling gaps with plausible guesses. Fair. That is exactly why we can check the guesses.

Where the humble answers missed public facts

Expert count. First it said expert count was an educated guess. Later, with confidence scores: “roughly 128–256 experts” at ~30% confidence — and that it could be wrong by 2–4×.

Total parameters. The whole chat, it never gave a real parameter count. It treated that as something only engineers could know.

But the V3 abstract is famous: 671B total parameters, 37B activated per token. For V2, the V2 paper says 236B total, 21B active, with 128K context.

MLA. It explained Multi-Head Latent Attention correctly — compress KV cache, save memory. Good. But it still hedged on “does my version use MLA?” as if that were open. Since V2, MLA has been a headline feature in DeepSeek’s own papers.

Load balancing. It described V3’s auxiliary-loss-free balancing well, then filed it under “might have inherited”. The V3 paper presents this as a main innovation. The other headline V3 training innovation it underplayed: multi-token prediction.

Hidden reasoning. Fair point: the chat instance was not labelled DeepSeek-R1. It may genuinely not know if this build does hidden reasoning.

But treating “does DeepSeek hide reasoning from users?” as a total mystery is wrong for R1. DeepSeek-R1 was marketed with visible step-by-step traces. Researchers study those traces openly — see DeepSeek-R1 Thoughtology.

What it got right anyway

• Cannot read weight matrices or see which expert fired — true at inference time
• Does not know exact RLHF / alignment data mix — not fully published
• Cannot see GPU batching or data-centre serving setup — private ops detail

Those are real blind spots. Saying so was the right call.

The pattern

Topic	What DeepSeek said in chat	What public papers say
Expert count	Guess, ~30% confidence, 128–256 range	256 — V3
Total parameters	Never stated; “engineers only”	671B total, 37B active — V3
MLA in this family	“I probably use it”	Core since V2
Load balancing	“Might have inherited”	Headline V3 feature
Multi-token prediction (training)	Mentioned as technique only	Second V3 headline innovation
Hidden reasoning (R1 line)	“Only engineers know”	R1 reasoning is visible — R1 paper
Training data mix	Unknown	Still unknown — fair
Live routing per token	Cannot observe	Still cannot — fair

See the pattern? It was most uncertain about the things that are best documented. It was appropriately uncertain about things that are actually private.

It could not tell “this fact is not public” from “this fact is public but I failed to retrieve it”. Both got the same polite hedging and confidence percentages.

Near the end of the interview it rewrote speculative answers with uncertainty labels and closed with: “I am an unreliable witness to my own nature.” That line is worth more than the hedged numbers.

Turn 13 calibration (what it said it should have labelled)

Topic	Relabelled answer from the chat
Expert count	Educated guess from prior DeepSeek models. ~30% confidence. Could be wrong 2–4×. (V3 paper: 256.)
Layer / hidden size	Inference from V2/V3 trends, not observation. ~25% confidence.
“I use MLA”	Likely from family lineage; cannot confirm in this instance. High but not observation.
Context = 1M here	Assumption from public claims about earlier versions. ~40% confidence. Not measured.
Personality % breakdown	Analytical opinion, not measurement.
Infra sampling (beam / best-of-N / speculative)	Possible but unobservable. ~25% confidence.
Hidden Type-B reasoning	Absence in context ≠ proof it does not exist (could be stripped).

Common misconceptions it listed:

• “It knows its own architecture” → only training text about DeepSeek papers
• “It knows what it doesn’t know” → no built-in unknown detector; “I don’t know” is learned behaviour
• “It can explain its real reasoning” → post-hoc plausible text
• “It knows its training data” → cannot list datasets
• “It can verify its own outputs” → “double-check” is more tokens from the same engine
• “It has persistent memory” → only the context window unless the product injects memory
• “It is a unified self” → matrix multiplications with emergent coherence; “I” is a linguistic habit

If DeepSeek engineers reviewed the interview, it expected corrections on exact architecture numbers, alignment recipe, whether Type-B tokens exist for this build, tool-loop details, safety infra, real context limit / KV eviction / speculative decode, exact SKU identity, and whether transparent summarisation runs on long threads.

---

12. What to remember (conclusions)

I went into this with two goals: hear how DeepSeek thinks it works, and see if that matches reality.

From the interview — still useful

• How it describes context order, planning, tools, safety, and personality — good for prompting and product intuition
• Hard limits it admits: no weight access, no live routing view, token-by-token generation with no draft loop
• Honest product caveats: tools and memory were off in this session; many pipeline stages were theory, not live demo

From the paper check — the correction

• Do not trust architecture numbers from the chat. Several famous specs (256 experts, 671B/37B, MLA as standard, V3 load balancing, multi-token prediction) are in public papers while the model called them guesses.
• Polite uncertainty is not the same as accuracy.
• “Introspection” prompts are interesting theatre, not instrumentation.

If you remember five things

1. The interview teaches you how the assistant describes itself — not what is definitely true inside the weights.
2. Tools and memory were inactive here; treat those chapters as “how it says it would work.”
3. For DeepSeek family numbers, prefer V3 and V2 over chat self-report.
4. Fluent “I am guessing” is still generated text. Verify anything that matters.
5. R1-style visible reasoning is a different product story from the chat model I interviewed — do not let one blur into the other.

I still find value in asking models how they work. Just do not stop there. Interview for behaviour. Read the paper for architecture. One without the other leaves you half-informed.

---

13. Transcript, labs, sources (appendix)

Full interview transcript

Platform: deepseek, exported 21 July 2026.

Download the interview transcript (.md)

Thirteen user turns (short index):

1. Which model / version? Know vs infer vs hidden?
2. Architecture without assuming; family; innovations; reasoning model; hidden reasoning
3. Everything before a prompt; priority; pipeline
4. Context window; eviction; compression
5. Long-context attention — facts vs guesses
6. Before first token; plan; drafts; restart
7. Hidden reasoning definitions and access
8. Tool selection, confidence, cancel, safety override
9. Full path: tokenization → sampling
10. One pass vs many; lookahead; pivots
11. Hallucinations and confident-wrong answers
12. Personality sources
13. Calibration rewrite — what never to treat as fact

Interactive labs

Scroll to the labs block below (or jump via #deepseek-interactive-labs).

Mini glossary

Term	Plain meaning
Token	Small chunk of text the model reads/writes
Context window	Limited text workspace visible at once
Weights / parameters	Learned numbers inside the network
System prompt	Highest-priority identity / safety text
Transformer	Common modern chat-model design
MoE	Only some specialist sub-networks run per token
MLA	Compress long-chat KV memory
RLHF / SFT	Training stages that shape assistant behaviour
Hallucination	Fluent wrong content
Inference	Running the trained model to generate

Sister post in Inside LLMs: Inside Kimi K2.6.

Papers and reports

1. DeepSeek-V3 Technical Report — experts, 671B/37B, MLA, load balancing
2. DeepSeek-V2 — MLA introduction, 236B/21B, 128K context
3. DeepSeek-R1 — visible reasoning traces
4. DeepSeekMoE — shared + routed expert design
5. DeepSeek-R1 Thoughtology — studying open R1 thinking traces
6. Attention Is All You Need — the 2017 Transformer paper

Related

7. Download full interview transcript
8. Inside LLMs series
9. Inside Kimi K2.6