DeepSeek R1 Parameters: Model Size, Generation Settings, and API Status

The short answer

“DeepSeek R1 parameters” can mean two different things: the model’s weights or the settings for generating a response. For model size, DeepSeek’s V3 architecture specification gives 671 billion total parameters, with 37 billion activated per token. DeepSeek’s R1 model card identifies R1 as using the DeepSeek-V3 architecture, so this is the commonly cited architecture-level figure—not an API setting. (github.com)

For generation settings, don’t assume a published benchmark configuration is a production default. More importantly, DeepSeek’s current API documentation lists deepseek-flash and deepseek-v4-pro, not a current R1 model ID. The legacy deepseek-reasoner name was marked for discontinuation by July 24, 2026. For a new integration, use the current model list and API documentation; if you specifically need R1 weights, confirm that a provider still serves the exact R1 checkpoint you intend to use. (api-docs.deepseek.com)

DeepSeek-R1 model parameters: total versus active

What the number describes	Figure	How to interpret it
Total model parameters	671B	The full parameter count reported for the DeepSeek-V3 architecture underlying R1.
Activated parameters	37B per token	The portion activated for each token in the MoE architecture; it is not the model’s total stored weights.
Hugging Face model-page metadata	684B	The current hosted model listing displays this figure, which differs from the 671B architecture figure. Don’t silently combine the two counts; check which checkpoint and counting convention a hardware or serving estimate uses.

DeepSeek describes V3 as a mixture-of-experts model with 671B total parameters and 37B activated for each token. Its R1 model card identifies the model architecture as DeepseekV3ForCausalLM; the Hugging Face listing separately labels the R1 model as 684B. The available official pages do not explain that metadata discrepancy, so 671B total / 37B active is the architecture figure, while 684B is the hosted page’s displayed count. (github.com)

The practical point: activated parameters are not a shortcut to a complete hardware estimate. Model weights, precision or quantization, runtime, context length, and serving configuration all matter. Don’t estimate memory by treating 37B active parameters as if the full 671B-parameter checkpoint did not need to be stored or served.

Generation settings are not model-size parameters

Temperature, top_p, thinking effort, and output-token limits control inference behavior; they do not change the number of model weights. For DeepSeek’s current API, the documented general temperature default is 1.0, but the current Thinking Mode guide says temperature has no effect in thinking mode. It also gives model-specific top_p behavior, so a copied sampling value may be ignored or adjusted rather than applied as expected. (api-docs.deepseek.com)

The current Chat Completions documentation describes max_tokens as the maximum generated tokens for a response: from 1 to 393,216, with defaults that depend on thinking mode and reasoning effort. That is an output-generation limit, not a model’s total parameter count or necessarily its context window. The total input-plus-output length must still fit the selected model’s context capacity. (api-docs.deepseek.com)

A secondary benchmark article reports temperature 0.6, top_p 0.95, and a 32,768-token maximum generation length for its benchmark setup. Those are evaluation settings reported for that comparison—not verified DeepSeek production defaults, API field recommendations, or universal model limits.

Which R1 version should you choose?

• You specifically need the original R1 open weights: select and test the exact checkpoint through a serving provider that documents support for it. DeepSeek’s R1 release made the model and its distilled models available as open weights, but that is separate from whether DeepSeek’s hosted API currently offers R1. (deepseek.com)
• Your R1 workflow needs function calling: DeepSeek’s R1-0528 release announcement says that version supports function calling and JSON output. Verify that the provider serving your chosen R1-0528 checkpoint exposes those features in its API; release notes alone do not establish a provider’s current request format. (api-docs.deepseek.com)
• You need DeepSeek’s hosted API for a new production integration: use a model ID in the current model list. The current quick start names deepseek-flash and deepseek-v4-pro; it does not give an R1 endpoint identifier. A current model with thinking enabled may be a practical alternative, but it is not the same checkpoint as DeepSeek-R1. (api-docs.deepseek.com)

There is no evidence here for a universal “best” variant by quality, latency, or cost. Benchmark your target tasks on the exact checkpoint and serving provider, especially if tool calling or long outputs are essential.

Production API example: current DeepSeek model, not R1

DeepSeek’s current API quick start uses an OpenAI-compatible Chat Completions request. This example uses deepseek-flash with thinking enabled; it is not an R1 request and does not call the original R1 weights. (api-docs.deepseek.com)

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEEPSEEK_API_KEY"],
    base_url="https://api.deepseek.com",
)

response = client.chat.completions.create(
    model="deepseek-flash",
    messages=[{"role": "user", "content": "Solve this step by step: 17 × 23."}],
    reasoning_effort="high",
    extra_body={"thinking": {"type": "enabled"}},
    max_tokens=8192,
)

print(response.choices[0].message.content)

The documented API endpoint is Chat Completions. In thinking mode, DeepSeek says temperature is unsupported and has no effect; it documents reasoning_effort and the thinking toggle separately. The max_tokens value in the example is a chosen output cap, not a recommended R1 setting. (api-docs.deepseek.com)

Before deploying an R1 integration, verify these details

1. Exact checkpoint and model ID: confirm whether the endpoint serves original R1, R1-0528, a distill, or a different model behind a legacy alias.
2. Supported request fields: check the provider’s documentation for sampling fields, thinking controls, tool calling, and accepted values. Don’t infer R1 support from an example written for another model.
3. Token-limit meanings: distinguish the context window (input plus output), the request’s maximum generated tokens, and any provider-specific input ceiling.
4. Checkpoint and serving configuration: use the actual checkpoint’s parameter-count convention and deployment format when estimating capacity. A total parameter count or active-per-token count alone does not give a reliable memory or throughput estimate.

DeepSeek’s model-list API documents machine-readable model IDs, context windows, output limits, supported modalities, and effort levels. That is a better starting point for validating a current hosted integration than an old R1 API example. (api-docs.deepseek.com)

Sources

DeepSeek-V3 — official model repository

DeepSeek-R1 — official Hugging Face model page

DeepSeek-R1 configuration

DeepSeek API — current quick start

DeepSeek API — temperature parameter

DeepSeek API — thinking mode

DeepSeek API — Chat Completions

DeepSeek API — list models

DeepSeek API — change log

DeepSeek-R1-0528 release announcement

PromptHub — DeepSeek R-1 benchmark setup