Small language models under 100B

Small language model, or SLM, has no single parameter cutoff. We use three bands here: tiny below 10B, small from 10B through 40B, and larger models above 40B but below 100B. They let you compare models within a size budget without implying that everything on this page fits a laptop.

Start in the smallest band your application can use, and compare its answers with a larger candidate on the same prompts. For a short extraction task, the smaller checkpoint can be enough even when its general score is lower. For a coding agent that must recover from errors across many steps, a broader capability gap can matter more.

The starting points above are the highest overall ranked checkpoints in each band of this source-checked index. They are benchmark candidates to evaluate, not winners from a local hardware test. A tiny-band leader can still lose when your task needs knowledge, document understanding, or reliable tool use that its score does not establish.

A dense model uses its main network for each token. A mixture-of-experts model, or MoE, selects part of its expert network for a token. That produces two useful numbers: total parameters describe the full checkpoint, while active parameters describe the portion used for a token.

We apply the strict cutoff to total parameters. A 120B MoE with 12B active parameters is outside this index. Its active count does not turn it into a 12B download or establish a 12B memory requirement. The runtime still has to store and manage the other experts, whether they reside on a GPU, in system RAM, or elsewhere.

Read the parameter note beside the source link when a name uses an effective count, a rounded size, or a language-only count. Embeddings and multimodal components can make the full checkpoint larger than the number in its name. The documented count and its scope are more useful than the marketing label.

Use the weight-access filter to separate downloadable weights from proprietary weights. A provider can offer a closed-weight model through an API, a private deployment, or a VPC without making its parameters publicly downloadable. Closed-weight models enter this index only when a publisher documents a model size below the 100B limit.

The license filter separates MIT or Apache 2.0 from community or custom terms. This describes the recorded license, not the openness of the entire AI system. Downloadable weights and a permissive license do not, by themselves, establish access to the training code and data information needed to reproduce the system. Check the publisher terms for the use you intend.

Pokee-Isaac 28B uses the original v0 report's rounded 28B dense size. Its size is provider-reported rather than counted from a public checkpoint. The index does not estimate downloadable weight storage for closed-weight models, and their private-deployment availability does not establish public access.

See the Open Source AI Definition for requirements beyond weight access.

At exactly four bits per parameter, weight storage is total parameters multiplied by 0.5GB per billion parameters, using decimal GB. That gives 4GB for 8B, 13.5GB for 27B, and 35GB for 70B. The index computes this arithmetic for each downloadable checkpoint; these are theoretical weights-only figures.

A real quantized artifact also contains metadata and tensors that may use other precision. Runtime buffers, KV cache, context length, parallel requests, and any extra encoders add memory. Some checkpoint formats use mixed precision. The estimate therefore is not a measured file size, a minimum RAM specification, or a guarantee that a model fits a GPU.

Reserve memory for the operating system and your other applications on a shared-memory machine. On a discrete GPU, check VRAM separately from system RAM. CPU offload can make a configuration possible, but it changes the speed you need to measure. Increasing context or concurrency can break a configuration that worked for one short prompt.

For a configuration estimate, use the VRAM calculator, then verify the result in your runtime.

The overall and task scores come from the same current public ranking used by the main leaderboards. We filter that ranking by the source-checked parameter registry and retain its order. We do not rescore a checkpoint for being smaller, borrow a sibling model's results, or replace missing scores with zero.

Supported means the public rank has enough independent evidence to stand behind it. Estimated means the position is visible with greater uncertainty. Not ranked means this checkpoint has no published overall position in the current ranking. A missing task score remains marked Not measured, even when the checkpoint has an overall score.

Published evaluations can use a different reasoning budget, precision, harness, or runtime from your local deployment. A score does not measure quantized answer quality, tokens per second, time to first token, or performance at the context length you plan to serve. Model pages carry the individual benchmark results and their sources so you can inspect what a score rests on.

This is a maintained index of documented checkpoints in our catalog, not every language model ever released. Models without a checked total count stay outside the index. Open weights also do not imply identical license terms: read the official model card and license before commercial use, redistribution, or fine-tuning.

Choose two candidates within your memory budget and one larger reference if you can run it. Keep the prompt, output limit, context, and scoring criteria the same. Record the exact checkpoint, quantization, runtime version, hardware, and reasoning settings so a later change can be compared with the first run.

Use examples from the work you actually need done. For extraction, check exact fields and unsupported values. For coding, run the tests and inspect the patch. For retrieval, include questions the supplied documents cannot answer and check whether the model invents an answer. Count successful tasks as well as retries; a fast failed answer does not finish the job.

Measure peak memory and latency with the context and concurrency you intend to use. Move to a larger checkpoint when it solves failures that matter enough to justify the extra memory or waiting time. Keep the smaller one when it meets the same acceptance criteria on your workload.