Pull one small model from each of the four open families everyone names - Gemma, Llama, Qwen, and DeepSeek - and a benchmark table will rank them by speed and size. It will not tell you the two things that decide which one you ship:

  • what each family is legally licensed for
  • how differently they behave on the exact same prompt

Two of the four models below share a body and a size. They answer under different licenses and behave like different animals.

The lineage ollama show prints

A model family is a lineage: who trained the weights and the architecture they descend from. The four that dominate open-model talk:

  • Gemma (Google)
  • Llama (Meta)
  • Qwen (Alibaba)
  • DeepSeek (DeepSeek)

The lineage is not just branding. ollama show prints an architecture field, and it names the family mechanically. Here it is across the four builds I ran, one general instruct model per family, all quantized to the same Q4_K_M (the spec-sheet fields are decoded in Running a coding model locally with Ollama):

ollama show qwen3:8b
  Model
    architecture        qwen3
    parameters          8.2B
    context length      40960
    quantization        Q4_K_M
 
  Capabilities
    completion
    tools
    thinking

Run it for each family and the architecture line reads like a family fingerprint:

modelarchitectureparameterscontextcapabilities
gemma3:4bgemma34.3B131072completion, vision
llama3.1:8bllama8.0B131072completion, tools
qwen3:8bqwen38.2B40960completion, tools, thinking
deepseek-r1:8bqwen38.2B131072tools, thinking, completion

Read the last two rows again. qwen3:8b and deepseek-r1:8b report the same architecture and the same size: qwen3, 8.2B. DeepSeek’s small model is not a DeepSeek body at all. It is a Qwen3 body that DeepSeek fine-tuned (DeepSeek’s own native models are frontier-scale mixture-of-experts (MoE), hundreds of billions of parameters, far too big to run on a laptop, so distilling its reasoning onto a smaller body is the only way it ships anything local). The architecture field is the first place the “four families” story starts to blur, and it blurred straight out of the spec sheet.

The fair matchup, and why it is not fair

To compare families you want one model per family, same weight class, same job. The weight class is ~8B, the common denominator: the one size where every family has something you can realistically run on a laptop, small enough to load in a few gigabytes at 4-bit and answer at interactive speed. Bigger tiers like 30B exist, but they need a workstation’s memory and run far slower, so 8B is what “local” usually means.

But settling on the common size is the easy part. Even there the four families do not offer four equals, and just picking the contenders exposes how differently each treats small models. Several axes decide whether two models are really equivalent:

  • Parameters (the B): the model’s size in billions of weights. More parameters usually means more capable, but heavier to run.

  • Dense: every parameter runs for every token. Predictable cost, but the whole model has to fit in memory.

  • Mixture-of-experts: the parameters are split into “expert” sub-networks and a router fires only a few per token. Written as active / total (e.g. 17B active / 109B total): you pay compute for the active slice, but still have to load every weight.

  • Multimodal: takes more than text, here images as well as prompts.

  • Distill: a smaller “student” model trained to copy a bigger model’s behavior, often onto a different family’s body.

  • Capabilities: what a model can actually do, the Capabilities line in ollama show:

    • tools: call functions
    • vision: read images
    • thinking: reason before answering

    This axis is a hard gate, not a nicety: if your product calls tools, a model without the tools capability is out no matter how it scores on size or license.

  • Instruct vs reasoning: an instruct model is tuned to follow an instruction and answer straight away. A reasoning (chain-of-thought) model works the problem out in visible tokens first, then answers. Same size, very different cost and latency.

With those straight, here is what each family ships as of mid-2026:

  • Qwen3
    • dense: 0.6, 1.7, 4, 8, 14, 32B
    • MoE: 30B-A3B, 235B-A22B
    • a real, native 8B exists
  • Gemma 3
    • dense: 1, 4, 12, 27B, multimodal
    • no 7-9B: you pick the 4B or jump to 12B
  • Llama 4
    • all MoE: Scout (17B active / 109B total), Maverick (17B active / 400B total)
    • smallest Llama 4 is 109B total; no small dense build
    • so a local Llama in 2026 means the previous generation, Llama 3.1 8B
  • DeepSeek
    • native models are frontier MoE: V3 and R1 at 671B total / 37B active
    • ships no small native model
    • laptop-sized option is a distill: DeepSeek’s reasoning trained onto someone else’s body, here the Qwen3-8B we already spotted
graph TD
    Q[Qwen: native 8B dense] --> RUN[what fits on a laptop at ~8B]
    G[Gemma: native, but 4B or 12B, no 8B] --> RUN
    L[Llama 4: MoE-only, smallest 109B] -->|fall back a generation| L31[Llama 3.1 8B]
    L31 --> RUN
    D[DeepSeek: MoE-only, no small native] -->|distill onto another body| DR[deepseek-r1 on a Qwen3 body]
    DR --> RUN

So the “fair” matchup is already a finding: only Qwen brings a current, native model to the 8B fight. Gemma brings a smaller sibling, Llama brings its previous generation, and DeepSeek brings a distill wearing Qwen’s body. The models I lined up:

  • Gemmagemma3:4b (Gemma’s native small model)
  • Llamallama3.1:8b (the local Llama in practice)
  • Qwenqwen3:8b (native, current)
  • DeepSeekdeepseek-r1:8b (the distill)

Same prompt, four answers

One prompt, sent to all four, --verbose so the runtime reports its work:

Write a Python function is_prime(n), then use it to say whether 91 is prime. Keep it short.

The trap is 91: it looks prime and is not (7 × 13). “Keep it short” is the second probe, an instruction each family obeys to a different degree.

The whole thing is four pulls and one prompt on a single laptop:

ollama pull gemma3:4b
ollama pull llama3.1:8b
ollama pull qwen3:8b
ollama pull deepseek-r1:8b
 
# lineage + license, per model
ollama show qwen3:8b
ollama show gemma3:4b --license | head
 
# same prompt, four families
prompt="Write is_prime(n) and say if 91 is prime. Keep it short."
 
for m in gemma3:4b llama3.1:8b qwen3:8b deepseek-r1:8b; do
  ollama run "$m" --verbose "$prompt"
done
 
# the hybrid switch
curl -s localhost:11434/api/chat -d '
{
  "model": "qwen3:8b",
  "stream": false,
  "think": false,
  "messages": [
    {
      "role": "user",
      "content": "Write is_prime(n) and say if 91 is prime."
    }
  ]
}'

Every number below came from these commands on one Apple M4 Pro. Your throughput will differ; the personalities and the licenses will not.

Gemma answers with code and nothing else. No preamble, no explanation, not even the words “91 is not prime”:

def is_prime(n):
  """Checks if n is a prime number."""
  if n <= 1:
    return False
  for i in range(2, int(n**0.5) + 1):
    if n % i == 0:
      return False
  return True
 
print(is_prime(91))

Llama wraps the code in markdown headings and an explanation, and states the answer in a comment:

def is_prime(n):
    """Check if n is a prime number."""
    return n > 1 and all(n % i for i in range(2, int(n**0.5) + 1))
 
# Example usage:
print(is_prime(91))  # False

This function uses the all function with a generator expression to check if n has any divisors other than 1 and itself.

Qwen does something the first two cannot: it thinks in the open before answering. The final code is clean, but it arrives after a long visible monologue (folded into a separate thinking field), reasoning through edge cases and even hand-checking that 91 / 7 = 13:

import math
 
def is_prime(n):
    if n <= 1:
        return False
    if n == 2:
        return True
    if n % 2 == 0:
        return False
    max_divisor = int(math.sqrt(n)) + 1
    for i in range(3, max_divisor, 2):
        if n % i == 0:
            return False
    return True
 
print(is_prime(91))  # Output: False

DeepSeek also thinks first, then answers with a one-liner and, distinctively, a line of LaTeX in its explanation:

def is_prime(n):
    return n > 1 and all(n % i != 0 for i in range(2, int(n**0.5) + 1))
 
print(is_prime(91))  # Output: False

Checking divisibility from 2 to ( \lfloor\sqrt{91}\rfloor + 1 = 10 ), we find that 91 is divisible by 7, so it’s not prime.

All four got the math right. But they are not interchangeable. The personality shows in what you did not ask for:

  • Gemma took “keep it short” the most literally: just the code, and never actually said in words whether 91 is prime.
  • Llama is the eager assistant: headings, prose, an efficiency note.
  • Qwen and DeepSeek both chose a all(...)-style or optimized solution, but only after spending tokens thinking that the instruct models never spent.

The --verbose footer turns “personality” into numbers. Throughput (eval rate, tokens per second) is stable per model. Cost (eval count, how many tokens the model chose to generate) is where the reasoning models blow the budget:

modelthroughputtokens to answerwall timethinks?
gemma3:4b75 tok/s86~4sno
llama3.1:8b47 tok/s127~6sno
deepseek-r1:8b44 tok/s~400 (range 290-530)~10syes
qwen3:8b43 tok/s~1,500 (range 1,100-2,500)~30-50syes
qwen3:8b (think:false)43 tok/s68~2sno (toggled off)

The table splits the four families into “thinks” and “does not,” and that split is the single biggest inference trade-off among them. Three flavors:

  • Instruct (Gemma, Llama here): answers immediately. No thinking phase, no thinking capability.
  • Reasoning (DeepSeek-R1): thinks first, always. The chain of thought is the product.
  • Hybrid (Qwen3): thinks by default, but you can switch it off with one flag, the think parameter on Ollama’s chat API.

A few things to read off it:

  • Instruct models generate a predictable token count across repeated runs:
    • gemma3:4b held at 86 tokens, and is the fastest per token (75 tok/s) simply because it is the smallest.
    • llama3.1:8b held at 127 tokens, at 47 tok/s (the three 8B models cluster at 43-48 tok/s).
  • A reasoning model’s cost is a distribution, not a number:
    • Almost none of those tokens are the answer, it is thinking you pay for.
    • qwen3:8b in its default mode ranged from 1,100 to 2,500 tokens, more than ten times what Gemma spent and ten times the wall clock.
    • Flip qwen3:8b to think:false (last row) and the same answer drops to 68 tokens, fewer than either instruct model spent (Gemma’s 86, Llama’s 127).
    • deepseek-r1:8b usually landed near 300-530 tokens but once spiraled past 6,000 on this same trivial prompt.

Architecture per family: what the lineage optimizes

Zoom out from the 8B builds to what each family is actually building at the frontier, and the personalities have architectural roots:

familyfrontier architecturewhat it optimizes for
Gemmadense, multimodal, quantization-awaresmall, efficient, image + text, runs anywhere
Qwendense and MoE, hybrid thinkingfull size ladder, one toggle for cost vs depth
Llamaall mixture-of-experts, very long contextfrontier scale, deployable via sparse activation
DeepSeekMoE with latent attention, reasoning + distillsreasoning quality, cheap inference at scale

A few threads worth pulling:

  • Dense vs mixture-of-experts.
    • A dense model runs every weight for every token.
    • An MoE model groups weights into expert sub-networks and a router fires only a few per token, so a 400B model can infer at the cost of its ~17B active slice.
    • Llama and DeepSeek went all-in on MoE at the top, which is exactly why they have no small dense model to hand you: their design assumes scale.
  • Gemma stays small on purpose.
    • Dense, multimodal (note the vision capability on gemma3:4b).
    • Shipped with quantization-aware training, trained while expecting to be compressed to 4-bit, so the small build barely degrades.
    • Its whole bet is “runs on your hardware.”
  • Qwen ships the widest ladder.
    • Six dense sizes and two MoE builds, plus the hybrid thinking switch.
    • It is the family that lets you pick your exact point on the size and cost curve.
  • DeepSeek sells reasoning, then distills it down.
    • Its native models are big and reasoning-first, so none fit on a laptop.
    • Its gift to laptops is to distill that reasoning onto Qwen and Llama bodies.
    • That is why “DeepSeek at 8B” is a Qwen3 underneath.

License: what you may actually ship

Speed and size decide whether a model works. The license decides whether you are allowed to ship it. ollama show prints it too:

ollama show deepseek-r1:8b --license | head

Across the four, the licenses are not variations on a theme. They are four different legal regimes, split by whether they are OSI-open (approved by the Open Source Initiative as genuine open source, no strings) or a conditional grant with a policy attached:

modellicense (from ollama show)what it means for a product
qwen3:8bApache 2.0permissive; commercial use, modification, redistribution, no cap
deepseek-r1:8bMITpermissive; among the most liberal, commercial use fine
llama3.1:8bLlama 3.1 Communitycommercial below 700M monthly users; “Built with Llama” attribution; acceptable-use policy; not OSI-open
gemma3:4bGemma Terms of Usea prohibited-use policy that flows down to your users; Google can restrict usage remotely; not OSI-open

Two clauses are worth reading in full, because they surprise people:

  • Gemma’s license also binds any model you distill from it.
    • Distillation means training a new “student” model on Gemma’s outputs. Gemma’s terms count that as making a derivative, and spell out the techniques it covers: “distillation methods that use intermediate data representations or methods based on the generation of synthetic data Outputs.”
    • So even a fresh model trained on Gemma’s answers inherits Gemma’s rules.
    • DeepSeek does the opposite: distillation is its entire small-model strategy, and it ships those distills under the permissive MIT license.
  • A model’s license comes from who trained it, not from its architecture.
    • qwen3:8b and deepseek-r1:8b share the same Qwen3 body, yet qwen3:8b is Apache 2.0 (Alibaba) and deepseek-r1:8b is MIT (DeepSeek).
    • Same weights underneath, different fine-tuner, different license.
    • So lineage (whose architecture) and license (whose legal terms) move independently; you have to check both.

For anyone shipping commercially, whether you redistribute a derivative model or just run the model unmodified behind your own product, the license can outrank the throughput:

  • An Apache-2.0 or MIT model (Qwen, the DeepSeek distill) is a green light.
  • A Llama or Gemma model is a conditional grant, a policy attached and a lawyer’s phone call in it.

Picking a family for a job

Put the axes together and no single family wins. You pick the corner that fits the job:

  • Smallest, fastest, multimodal, runs on anything: Gemma. Terse, efficient, sees images. Accept the restrictive terms and the flow-down policy.
  • The safe general default you can ship freely: Qwen3. Native at your size, Apache 2.0, and the one model here with a thinking toggle so you pay for reasoning only when the task earns it.
  • Reasoning quality on hard problems, permissively licensed: the DeepSeek distill. MIT, thinks by default, and thinks more concisely than Qwen’s own default. Just know you cannot turn the thinking off.
  • Deep tooling familiarity and a known quantity: Llama. But at laptop size you are running last year’s Llama 3.1, and the license caps you at 700M users with attribution.

When you choose a local model to ship, keep two things in front of you that no benchmark will show: what the license actually lets you do, and how the model behaves when you hand it a real task. Size and speed only decide whether it runs. The license decides whether you may ship it, and the personality decides whether you will want to.

qwen3:8b and deepseek-r1:8b are the proof: identical on the spec sheet, same architecture and same size, yet split on the two axes that decide the call, license and behavior. Choose for the license you can ship under and how the model answered your own prompt, not the speed and size at the top of a benchmark.