Skip to content
Request a free consultation
Menu
A glass block filled with a dense lattice of glowing points on an aluminum base with a row of dials.

What Are Parameters in LLM: A Clear Guide to Their Role and Impact

Billions of weights, but which ones count? See why memory tracks total parameters, speed tracks active ones, and why temperature never touches the model itself.

LLM parameters are the learned numerical weights inside a model that encode grammar, meaning and context. In modern large language models they number in the billions, and they are the primary levers that determine what a model can do. Because parameters accumulate statistical regularities from training data, they let the system represent complex dependencies and generate coherent, human-like text.

The word "parameter" is also used loosely for settings that are not learned, such as temperature or the learning rate. This guide separates the learned parameters, the hyperparameters that shape training and the sampling settings that shape each response, and explains what parameter counts mean for capability, memory and compute in 2026, including why mixture-of-experts models report two numbers.

What Are LLM Parameters?

An LLM is a neural network, and most of its arithmetic is multiplying vectors by matrices of numbers. Those matrix entries, plus a smaller set of offsets, are the parameters. They start random; training adjusts them until the network turns a sequence of input tokens into a good prediction of the next token. No single parameter holds a single fact: knowledge and style are spread across how billions of them combine.

Why Parameters Matter in Large Language Models

At inference time, an LLM transforms input tokens into a probability distribution over the next token, and that mapping is governed entirely by its parameters. More parameters typically increase capacity to capture complex patterns, but they also demand more computational resources for training and serving.

The Core Types of Model Parameters

Weights scale information flowing through a network; biases shift activations so the model can fit signals that are not centered. In a transformer, the architecture introduced in Attention Is All You Need, they live in four places:

  • Embeddings: one learned vector per vocabulary entry, used to turn token IDs into vectors (and often to turn the final state back into token scores).
  • Attention weights: query, key, value and output projections that decide which earlier tokens each position draws information from.
  • Feed-forward (MLP) weights: large matrices applied to every token after attention, usually holding most of the parameters.
  • Biases and normalization scales: small vectors that shift or rescale activations; some modern architectures drop most biases.

The feed-forward blocks matter beyond their size: interpretability research such as Locating and Editing Factual Associations in GPT points to mid-layer feed-forward modules as a key site where factual associations are stored. Together, these LLM parameters define how the model generates output token by token.

How Parameters Encode a Probability Distribution

Every forward pass follows the same route. Token IDs become embedding vectors, which flow through a stack of attention and feed-forward layers, each applying its own parameters. The final layer produces a raw score, or logit, for every vocabulary token, and a softmax converts those logits into a probability distribution. The model picks a token, appends it and repeats.

What differs between a coding assistant and a chatbot is the parameter values, and so the shape of that distribution. Small changes after fine tuning can shift it toward compliant phrasing, a house style or domain terminology. For how text becomes token IDs in the first place, see our guide to what a token is in an LLM.

Input tokens become embedding vectors, pass through attention and feed-forward layers, and end as next-token probabilities.
Every layer applies its learned parameters; the output is a probability for each possible next token.

From Data to Parameters: What Training Actually Does

During training, an optimizer adjusts parameters to minimize the loss between predicted and actual next tokens. Backpropagation computes how each parameter contributed to the error, and the optimizer nudges each one to reduce it.

Data Quality and Quantity Considerations

Parameters can only learn what the data contains. Diverse, well-filtered sources tend to produce more reliable behavior than a larger noisy corpus, and poor data leads to brittle behavior regardless of model size. Keep training, validation and test sets separate so estimates reflect unseen data rather than leakage.

Scaling laws: parameters, data and compute

Kaplan et al. (2020) reported that language model loss scales as a power law with model size, dataset size and training compute. Hoffmann et al. (2022), the "Chinchilla" paper, then argued that model size and training tokens should be scaled equally: their 70B Chinchilla, trained on about four times more data than the 280B Gopher with the same compute, outperformed it on a wide range of tasks. Parameter count amplifies learning capacity; data decides how much of it is used.

How Many Parameters Do LLMs Have?

The table lists counts stated by developers in papers or official model cards. Closed frontier models are different: the GPT-4 technical report explicitly withholds model size, and counts circulating online for closed models are generally estimates.

ModelArchitectureTotal parametersActive per token
GPT-3 (2020)Dense175B175B
Llama 3 family (2024)Dense8B, 70B, 405BSame as total
Mixtral 8x7B (2024)Mixture of experts47B13B
DeepSeek-V3 (2024)Mixture of experts671B37B
Qwen3-235B-A22B (2025)Mixture of experts235B22B
gpt-oss-120b (2025)Mixture of experts117B5.1B
gpt-oss-20b (2025)Mixture of experts21B3.6B

Sources: GPT-3 paper, The Llama 3 Herd of Models, Mixtral of Experts, DeepSeek-V3 Technical Report, the Qwen3-235B-A22B model card and the gpt-oss-120b model card.

Architecture Parameters: Size, Depth, and Context Window

The count follows from architectural choices: layers, hidden size, attention heads, feed-forward width and vocabulary size. Qwen3-235B-A22B, for instance, lists 94 layers and 128 experts with 8 active per token. The context window does not add parameters, but it sets how many tokens the model can attend to: Llama 3 supports up to 128K tokens, and Qwen3-235B-A22B lists 32,768 natively and 131,072 with YaRN scaling. Longer contexts raise memory use and latency when serving.

When Larger Models (Really) Help

Larger models tend to help with broad knowledge, multi-step reasoning, code synthesis and robust instruction following. For narrow jobs such as classification or extraction, a smaller model with retrieval or light fine tuning is often good enough and far cheaper.

Dense vs. Mixture-of-Experts: Total vs. Active Parameters

In a dense model, every parameter takes part in processing every token, so one number is a fair proxy for both memory and compute. Mixture-of-experts (MoE) models break that link. They replace feed-forward blocks with several parallel "experts" and add a router that sends each token to only a few. The Mixtral paper describes a router selecting two of eight experts per token at each layer, so each token has access to 47B parameters but uses only 13B during inference. DeepSeek-V3 activates 37B of 671B, and gpt-oss-120b 5.1B of 117B.

The rule is simple: memory follows total parameters, because every expert must be loaded, and compute per token follows active parameters, because only selected experts do work. MoE models offer large-model capacity at a smaller model's per-token cost, but still need large-model memory. Compare total parameters for hardware sizing and active parameters for speed and cost per token.

In a dense model every weight is used for each token; in a mixture-of-experts model a router sends each token to a few active experts.
Dense models use all their parameters per token; MoE models load every expert but activate only a few.

Resource Planning: Memory, Throughput, and Cost

LLM parameters dominate memory. A first estimate is the parameter count times bytes per parameter: two bytes at 16-bit precision, so about 140 GB for a 70B dense model's weights, about 70 GB at 8 bits and about 35 GB at 4 bits. Serving also needs room for the key-value cache, which grows with context length and concurrency, plus activations and overhead.

Training is far heavier. The ZeRO paper calculates that mixed-precision training with Adam needs 16 bytes per parameter for weights, gradients and optimizer states before activations, more than a terabyte for a 70B model. For compute, Kaplan et al. estimate a forward pass at roughly 2N floating-point operations per token, with N the non-embedding parameters, and training at about 6N per token. For MoE models, the per-token figure tracks active parameters.

Quantization

Quantization stores parameters at lower precision to cut memory. The gpt-oss model card states that the MoE weights were quantized to MXFP4 after training, which lets gpt-oss-120b fit on a single 80 GB GPU and gpt-oss-20b run within 16 GB of memory. Lower precision can affect quality, so validate on your own tasks. Sizing that hardware and serving stack is the focus of our AI infrastructure services.

Parameters vs. Hyperparameters vs. Sampling Settings

LLM parameters (weights and biases) are learned by optimization. Hyperparameters such as learning rate, batch size and weight decay are set before training; they shape the training process but are not learned. Sampling settings such as temperature and top-p are applied at inference time to choose tokens from the distribution the parameters produce. A simple test: if a value changes when you train, it is a parameter; if you set it to control training, it is a hyperparameter; if you can change it on every API call, it is a sampling setting.

Training Parameters That Matter Most

The learning rate controls how far each update moves the weights: too high is unstable, too low is slow, and warmup with cosine decay often stabilizes it. Larger batches smooth gradients; smaller ones fit single GPUs. Gradient clipping, dropout and weight decay add robustness. For hyperparameter optimization, run small ablations to find stable regions, use Bayesian search after a rough grid when compute allows, and use early stopping on a validation set to avoid overfitting.

Inference-Time "Parameters" That Shape Outputs

Decoding settings do not change weights, but they strongly affect output. The Hugging Face GenerationConfig documentation lists the common ones:

  • Temperature: scales logits before softmax; low values are more deterministic, high values more diverse (library default 1.0).
  • Top-k: keeps the k most likely tokens (library default 50).
  • Top-p (nucleus sampling): keeps the smallest set of tokens whose probabilities add up to p.
  • Min-p: drops tokens below a fraction of the top token's probability.
  • Repetition, frequency and presence penalties: discourage reusing tokens already produced.
  • Max tokens: caps response length, latency and cost.

Top-p comes from Holtzman et al., who proposed sampling from the "nucleus" of the distribution to cut its unreliable tail. Temperature interacts with every other setting; our guide to LLM temperature covers its math and use cases in depth.

Frequency and Presence Penalties in Practice

A frequency penalty lowers a token's score in proportion to how often it has appeared, curbing repeated phrases. A presence penalty applies once to any token that has appeared, nudging the model toward new topics. Open-weight libraries often use a multiplicative repetition penalty where 1.0 means none. Penalties can also push a model away from terms it must repeat, such as product names or code identifiers, so validate them against quality.

The Role of Context Window and Max Tokens

The context window is fixed by the model; max tokens is set per request. A longer context lets the model use more evidence, and a sensible max-tokens value avoids truncation while containing cost. If outputs trail off, raise the limit or ask for a shorter style. Both limits count tokens, not words, so the same text can use a different budget on different models.

Three parallel columns: learned weights and biases, training hyperparameters such as learning rate, and sampling settings such as temperature.
Only weights and biases are learned and stored in the model; hyperparameters steer training and sampling settings steer each response.

Fine Tuning: Making a Pre-Trained Model Yours

Fine tuning continues training a pre-trained checkpoint on your own examples. It can improve formatting and tone for support, legal or medical tasks, raise accuracy on niche intents with modest data and reduce unsupported answers when paired with retrieval.

Parameter-Efficient vs. Full Fine Tuning

Full fine tuning updates every parameter and carries the full training memory cost. Parameter-efficient fine tuning freezes the base weights and trains a few new ones. LoRA adds small low-rank matrices beside existing weights; compared with fully fine-tuning GPT-3 175B with Adam, its authors report that LoRA can reduce trainable parameters by 10,000 times and GPU memory by three times. QLoRA trains adapters on a 4-bit quantized base, enough to fine-tune a 65B model on a single 48 GB GPU.

Small adapters let one base model serve several behaviors by swapping adapters per task. Start parameter-efficient and escalate to full fine tuning only if metrics stall. For ranks, configuration and variants, read our explainer on what LoRA is in LLMs.

Frozen base weights are combined with small LoRA adapters trained on your data to produce an adapted model.
LoRA keeps the base parameters frozen and trains only small adapter matrices.

Best Practices for Parameter Tuning

For training hyperparameters and sampling settings alike: change one thing at a time, keep a baseline, prefer small sweeps over single heroic runs and re-check on fresh data when the domain shifts.

Practical Defaults by Task

There is no universal best setting, and a provider's recommended values should take precedence. As starting points to test, not proven optima: classification and extraction usually suit temperature at or near zero, a small max-tokens limit and a strict schema; customer support favors low temperature with mild penalties; drafting and brainstorming tolerate higher temperature with nucleus sampling.

Monitoring and Performance Metrics

Track task-appropriate scores, such as exact match or F1 for extraction and rubrics for generated text, plus human ratings where quality is subjective. In production, monitor latency, errors, cost per request and safety incidents, and tie metric changes to specific weight, adapter or decoding changes.

How LLM Parameters Affect Model Behavior

Changing learned parameters through fine tuning or an upgrade can alter which facts a model recalls and whether it hedges or asserts; changing sampling settings alters how it chooses among the options those parameters produce. Guardrails such as policy checks, schema validators and a changelog linking each change to its safety outcome keep that behavior aligned. Machine learning engineers version these settings like code and gate releases on guardrail and business metrics. Teams building that production layer around a model can explore our LLM solutions.

Putting It All Together: A Minimal Playbook

  1. Choose a base model with adequate size, context window and license.
  2. Estimate memory from total parameters and precision, plus key-value cache.
  3. Clean and balance your training or evaluation data.
  4. Try prompting and retrieval first; add parameter-efficient fine tuning only if needed.
  5. Tune temperature, top-p, top-k, penalties and max tokens.
  6. Log, monitor and iterate against a fixed baseline.

Common Pitfalls (and Fixes)

  • Equating size with quality: compare models on your own tasks.
  • Sizing MoE hardware by active parameters: memory must hold every expert.
  • Over-searching decoding settings: lock a baseline and compare properly.
  • Ignoring token limits: raise max tokens or ask for a compact style.
  • Undersized batches: accumulate or clip gradients.
  • Unclear ownership: review parameter changes like code and keep rollback paths.

Glossary: Quick Parameter Reference

  • LLM parameters: learned weights and biases in the checkpoint.
  • Total vs. active parameters: all parameters vs. those used for one token.
  • Training hyperparameters: optimizer and run settings, such as learning rate and batch size.
  • Sampling parameters: temperature, top-p, top-k, min-p, penalties and max tokens.
  • Context window: tokens the model can attend to at once.
  • Quantization: storing parameters at lower precision to save memory.

Frequently Asked Questions

What does 7B or 70B mean in an LLM name?

It is the approximate number of parameters, in billions. MoE model names sometimes show both numbers, as in Qwen3-235B-A22B: 235B total and 22B active.

Do more parameters always mean a better model?

No. Data, compute, architecture and fine tuning matter too. In the Chinchilla research, a 70B model trained on more data outperformed a 280B model trained with the same compute.

Is temperature a parameter of the model?

Not a learned one. It is a sampling setting applied at inference time and can change on every request without modifying the weights.

How much memory do LLM parameters need?

Roughly parameter count times bytes per parameter: 2 bytes at 16-bit, 1 at 8-bit, half a byte at 4-bit. A 70B model needs about 140 GB for 16-bit weights, plus key-value cache.

What is the difference between total and active parameters?

Total counts every weight; active counts those used for one token. They match in dense models and differ in MoE models, where a router activates a few experts per token.

Can I change a model's parameters myself?

With open-weight models, yes, through fine tuning. LoRA and QLoRA train small adapters while the base parameters stay frozen, keeping memory manageable.

Conclusion: Why LLM Parameters Matter

LLM parameters determine a model's capabilities, costs and personality. Knowing which values are learned (weights and biases) and which are configured (training hyperparameters and sampling settings) lets you shape behavior with intent rather than by trial and error.

In 2026, reading a parameter count also means asking whether the model is dense or mixture-of-experts and at what precision it will run. Total parameters set the memory bill, active parameters set per-token compute, and data quality, fine tuning and careful decoding decide how much of that capacity becomes useful output.

If you are choosing, sizing or adapting a model for your product or operations, talk to Cognativ about your AI project.

Never miss a post

Practical Cognativ articles on AI, software delivery, cybersecurity, ecommerce, and RAPID transformation.