DeepSeek V2: May 2024 Mixture-of-Experts Architecture and Historical Checkpoints. This reference distinguishes the original release from hosted endpoints, downloadable weights and subsequent version changes. It is written for people deciding whether an exact model or checkpoint is suitable for a real application, not for leaderboard marketing.
What the sources actually establish
The DeepSeek-V2 repository dates the main release to May 6, 2024 and the Lite release to May 16. It describes a 236-billion-total-parameter mixture-of-experts model activating 21 billion parameters per token, with 128K context for the larger V2 models. Those numbers refer to specific published model cards and should never be transferred to later DeepSeek V3, V4 or provider API aliases.
A useful application and evaluation scenario
A researcher reproducing a 2024 retrieval result should save the repository commit, Base versus Chat checkpoint, tokenizer and inference framework. A knowledge-search service can measure retrieval-grounded factuality separately from model-only question answering. Because MoE routing changes runtime needs, test the intended batch size on actual memory hardware rather than estimating only from active parameters.
Limits, risks and uncertainties
The publisher reports notable KV-cache and throughput improvements versus its earlier model, but these are self-reported comparisons subject to hardware and evaluation design. The published code and weights are not equivalent to a guarantee that a hosted `deepseek-chat` identifier still executes V2. Check licensing at the exact repository or checkpoint and never infer an on-prem commercial grant from GitHub discoverability.
Alternatives and the decision rule
Use V2 to explain the transition to large sparse models or maintain historically pinned systems. For new API builds, choose an independently verified, supported endpoint and set up canary evaluation; later DeepSeek aliases may route to different underlying weights. Ensure a reproducible fallback and preserve original release metadata in logs.
A reproducible test before adoption
Prepare a small held-out set from data the organization is authorized to process. Include simple, ambiguous and deliberately unanswerable requests; specify the expected answer or evidence and a human-reviewed scoring rule. Record model identifier, endpoint and region, tokenizer or SDK version, prompt, tool settings, output budget and whether external retrieval was allowed. Do not present a provider-supplied benchmark as an independently measured result. Separate model mistakes from retrieval, OCR and application validation failures.
Operational checklist and dated evidence
A production transition must test 429 responses, timeouts, refusals, invalid structured output and model-unavailable errors. Keep a reversible rollout or safe fallback instead of silently substituting a model behind an old identifier. Measure latency and usage on the actual workload before planning budgets; join dated token quantities to the AI 10 price ledger. Verify enterprise residency, region, support entitlement and data retention with the actual contract, not a public release story.
Sources & Further Reading
- github.com — documentation/reference (supplier-provided reference; not independently checked in this pass)
- DeepSeek API changelog (retrieved from first-party public documentation on 2026-10-25; this is not a deployment test)
Source documentation establishes vendor-published facts, not independently measured model quality, tenant access, contractual rights or current prices. Use a dated pricing ledger and an account-specific entitlement check for deployment decisions.