Llama 4 Explained: Scout, Maverick and Behemoth Architecture, Benchmarks and Access (2026)

Eighteen months after launch, Llama 4 is an odd artifact: the model family that moved open weights from dense transformers to sparse mixture-of-experts, shipped two of its three announced members, and then watched its parent company pivot to a closed frontier model. Scout and Maverick are still downloadable, still served by every major inference stack and still useful. Behemoth, the roughly two-trillion-parameter teacher that was meant to anchor the whole family, never shipped as public weights. Anyone choosing a model in late 2026 needs to know which of those facts matters for their workload.

The family matters now for three reasons. It is the reference design for how a lab with enormous compute trades active parameters against total capacity. Its launch exposed how fragile headline claims, such as a 10-million-token context window and a leaderboard score, can be. And its license terms still determine whether many European and very large companies can touch the weights at all.

You will leave with a precise picture of the architecture (expert routing, early fusion, iRoPE), the training recipe, the official benchmark tables, the hardware arithmetic for self-hosting, what went wrong with Behemoth, and a decision matrix against peers.

What this covers: lineage versus Llama 3, MoE and attention internals, training and codistillation, sourced benchmarks, license and access, VRAM and KV-cache arithmetic, the Behemoth story, limitations, and a practical selection checklist.

Context and Background

Meta released Llama 4 Scout and Llama 4 Maverick on April 5, 2025, describing them as the first open-weight, natively multimodal models built on a mixture-of-experts (MoE) design, per Meta’s launch post. A third model, Behemoth, was previewed while still training and positioned as a teacher whose knowledge would be distilled into the smaller two. Together Meta called them a herd.

The predecessors set the baseline. Llama 3.1 shipped dense models at 8B, 70B and 405B parameters with a 128K context window, and Llama 3.3 refreshed the 70B tier. Dense means every parameter participates in every token, so serving cost scales with total size. For a team self-hosting, the 405B model was accurate but required a multi-GPU node per replica and delivered modest throughput. Llama 4 broke that coupling: the model card in Meta’s llama-models repository lists 17 billion active parameters for both released models, with 109 billion total for Scout and 400 billion total for Maverick.

The competitive field moved quickly after release. DeepSeek’s V3 and R1 line had already shown that sparse MoE could match dense frontier quality at lower serving cost, and Qwen, Mistral and others followed with their own sparse releases. By 2026 the open-weight tier is crowded; our open-weight model flood analysis and the DeepSeek V4.1 Flash deep dive cover the newer entrants. Llama 4 is therefore best read as a landmark and a reference point rather than the current leader.

Corporate context matters too. On April 8, 2026, Meta Superintelligence Labs launched Muse Spark, which reporting describes as Meta’s first proprietary frontier model, available through Meta’s own products rather than as downloadable weights. Meta has said it hopes to open-source future versions of the Muse line. Treat the exact timeline of any promised open weights as unconfirmed until files appear on a public hub. For readers who need the closed-model comparison point, the series entries on GPT-5.6 SOL and Claude Sonnet 5.5 are the right companions.

One thing worth stating plainly: “open” here means open weights under a custom commercial license, not open source in the Open Source Initiative sense. Training data and training code are not released. That distinction shapes everything from compliance review to how much you can reproduce or audit, and we return to it in the access section.

Lineage and What Changed Versus Llama 3

Three changes separate Llama 4 from the generation before it, and each one has a downstream consequence for operators.

From dense to sparse

In a dense transformer layer the feed-forward network (FFN) is one large pair of matrices. In an MoE layer the FFN is replaced by many smaller expert FFNs and a learned router. Meta’s description is that each token is sent to a shared expert plus one routed expert, and that MoE layers alternate with dense layers. The consequence is a split between memory footprint, which tracks total parameters, and per-token compute, which tracks active parameters. Llama 4 Maverick stores 400 billion parameters but computes with roughly 17 billion per token.

From adapter vision to early fusion

Llama 3’s vision capability arrived through separate adapter models added after text training. Llama 4 uses early fusion: image tokens from a vision encoder (Meta says it is based on MetaCLIP and was trained separately alongside a frozen Llama model) are fed into the same backbone as text tokens during pre-training. The practical result is that the same weights handle charts, screenshots and documents without a separate vision tower to deploy. The cost is that multimodal capability is bound into the text model, so you cannot drop vision to save memory.

From 128K to a 10M claim

Llama 3.1 offered 128K tokens. The Scout model card lists a 10M-token context length and Maverick lists 1M. Meta’s launch post says Scout was pre-trained and post-trained at 256K context and relies on length generalization from the iRoPE design to go beyond that. That is the part to read carefully: the headline number is an extrapolation target, not a training length, and independent evidence of 10M-token quality is thin. We quantify this in the limitations section.

A fourth, quieter change is data scale. The launch post says pre-training used more than 30 trillion tokens of text, image and video data, more than double the Llama 3 mixture, with 200 languages and over 100 languages having more than a billion tokens each. The model card gives per-model figures: roughly 40 trillion tokens for Scout and roughly 22 trillion for Maverick. Both state an August 2024 knowledge cutoff, so the models know nothing about later events without retrieval.

For serving teams, the lineage message is that Llama 4 inherits Llama’s ecosystem advantage (Hugging Face support, vLLM and SGLang kernels, GGUF quantizations) while changing the hardware math. The detail of that math is in our mixture-of-experts architecture guide, which explains routing, load balancing and capacity factors in general terms.

Architecture: Sparse Experts, Early Fusion and iRoPE

Direct answer: Llama 4 is a decoder-only transformer whose feed-forward layers are mixture-of-experts blocks. Both released models activate 17B parameters per token; Scout has 16 experts (109B total) and Maverick has 128 routed experts plus a shared expert (400B total). Text and image tokens share one backbone, and attention interleaves layers with and without rotary position embeddings.

Figure 1: Llama 4 forward path. Image patches and text tokens enter one backbone, and each MoE layer routes a token to a shared expert plus one routed expert.

Figure 1 shows the forward path. Text is tokenized, images pass through the vision encoder to produce embeddings, and both streams enter the same stack. In each MoE layer a router scores the experts for every token, selects the top choice, and the token’s hidden state is processed by that routed expert and by the always-on shared expert; the outputs are combined and the residual stream continues. Alternate layers are ordinary dense FFNs.

The numbers, side by side

Property	Scout	Maverick	Behemoth (preview)
Active parameters	17B	17B	288B
Total parameters	109B	400B	nearly 2T
Experts	16	128 routed plus 1 shared	16
Context length	10M (trained at 256K)	1M	not stated
Pre-training tokens	about 40T	about 22T	not stated
Released weights	yes	yes	no

Sources: Meta’s launch post and the llama-models model card. Behemoth figures come from the launch-day preview and have never been updated by a release.

Why does Maverick have eight times the experts of Scout yet the same active size? Because the routed expert per token is the same size in both; Maverick simply offers a larger library of specialists to choose from. More experts raise capacity (and memory) without raising per-token FLOPs. That is the entire economic argument for sparse models, and it is why a 400B-parameter model can have similar compute per token as a 17B dense one while achieving materially better quality on knowledge-heavy tasks.

Routing, shared experts and why alternation matters

A router is a small linear layer that produces a score per expert. Top-1 routing, as Meta describes, keeps the dispatch cheap: each token goes to exactly one routed expert, so there is no combine step across several experts. The shared expert is a safety net. Every token passes through it, so common knowledge (syntax, frequent facts) does not need to be duplicated in every specialist, and the model degrades gracefully when the router makes a poor choice.

Alternating MoE and dense layers has a systems rationale: dense layers keep communication balanced. In expert-parallel serving, experts live on different GPUs and tokens must be shuffled to them with all-to-all collectives. Every MoE layer pays that shuffle. Alternating halves the number of shuffles per forward pass compared with an all-MoE stack. Meta has not published ablations that isolate this effect, so treat it as a plausible design reason rather than a documented one.

The training-time hazard of any router is collapse: a few experts receive most tokens while the rest atrophy. Standard remedies are an auxiliary load-balancing loss, noise or capacity limits on the router, and careful initialization. Meta’s launch post says it used a hyperparameter technique called MetaP to set per-layer learning rates and initialization scales that transfer across width, depth, batch size and token count. The post gives no router-specific recipe, and later analysis of Behemoth (below) suggests routing stability was exactly where things went wrong at the largest scale.

iRoPE and the 10M-token claim

Rotary position embedding (RoPE) encodes token position by rotating query and key vectors; it extrapolates poorly beyond lengths seen in training. Llama 4’s iRoPE (“interleaved RoPE”) alternates attention layers that use RoPE with layers that use no positional embedding at all, and Meta’s post adds inference-time temperature scaling of attention to help at long lengths. The no-position layers can attend globally, while RoPE layers handle local order. The bet is that this mix generalizes to lengths far longer than the 256K used in training.

Public descriptions, including Meta’s code, also describe chunked local attention in the RoPE layers, where each token attends only within a fixed-size chunk. That cuts attention cost and KV-cache memory in those layers, but it creates a boundary effect: information cannot flow across chunk edges except through the global layers. This design choice becomes important when we reach Behemoth.

Two clarifications keep the architecture honest. First, the exact layer counts, hidden sizes, number of KV heads and the vocabulary size are not stated in the launch post; they are in the released configuration files, which you should read directly rather than trust secondary summaries. Second, the vision encoder is separate in training but joined at inference; the model card reports multi-image testing up to five images, while the launch post says pre-training saw up to 48 images. Both statements can be true: pre-training exposure is not the same as a validated serving limit.

For attention memory behavior on the serving side, our KV cache optimization guide and the comparison of multi-head latent attention versus GQA and MQA explain why attention variants dominate long-context cost.

Training: Data, Codistillation and the Post-Training Recipe

Meta disclosed more about Llama 4 training than about most releases, though the data itself remains undisclosed. The pipeline has four visible stages, summarized in Figure 2: pre-training, mid-training for context extension, a three-step post-training recipe, and, for the smaller models, distillation from Behemoth.

Figure 2: Llama 4 training pipeline. Behemoth acts as a teacher during Maverick pre-training, and post-training runs lightweight SFT, then online RL, then lightweight DPO.

Pre-training

Meta states that pre-training used text, image and video data across 200 languages, with FP8 precision for the largest runs. The launch post reports that Behemoth pre-training used FP8 on 32,000 GPUs and reached 390 TFLOPs per GPU. FP8 matters because it roughly doubles tensor-core throughput relative to BF16 and halves activation and gradient communication bytes, but it narrows numeric range, so it demands careful scaling and is one reason hyperparameter transfer (MetaP) was important to the team.

A back-of-envelope check helps calibrate the reported compute. The model card lists 5.0 million H100 GPU-hours for Scout and 2.38 million for Maverick. Dividing tokens by GPU-hours gives about 8 million tokens per GPU-hour for Scout (roughly 2,200 tokens per second per GPU) and about 9.2 million for Maverick (roughly 2,600 tokens per second). Using the common approximation of 6 times active parameters times tokens for training FLOPs, Scout needs about 4.1e24 FLOPs and Maverick about 2.2e24. Spread over the reported GPU-hours, that implies on the order of 230 to 260 TFLOPs per GPU, roughly a quarter of an H100’s dense BF16 peak of about 990 TFLOPs. This is an illustrative estimate: the 6ND rule ignores attention and the vision encoder, and Meta’s token counts mix modalities, so the real utilization differs. It does show the reported figures are internally plausible rather than extravagant.

Note the reported token counts differ between sources. The launch post says “more than 30 trillion tokens” for the mixture, while the model card gives about 40 trillion for Scout and about 22 trillion for Maverick. These need not conflict (they describe different runs and may count multimodal tokens differently), but a careful write-up should quote the model card per model and not average them.

Mid-training and long context

After the main run, Meta describes a mid-training stage that extended context length with specialized long-context datasets while improving quality. The key fact for evaluating the 10M claim is the 256K figure: training and post-training for Scout happened at that length. Everything above it relies on iRoPE generalization. The only long-context numbers in the model card are the MTOB translation tasks (half-book and full-book), where Scout scores 42.2 and 36.6 chrF on half-book and 39.7 and 36.3 on full-book, and Maverick scores 54.0 and 46.4 and 50.8 and 46.7. Those tasks fit in well under 1M tokens, so they say little about the 10M frontier.

Post-training: less SFT, more RL

Meta’s post-training description for Maverick is notable for what it removes. The recipe is lightweight supervised fine-tuning (SFT), then large-scale online reinforcement learning (RL), then lightweight direct preference optimization (DPO). Llama models served as judges to strip more than half of the “easy” SFT data, because over-constraining the model on easy examples can limit exploration during RL. In the online RL stage the team alternated between training and filtering, keeping only prompts of medium to hard difficulty and building a curriculum.

For Behemoth the pruning was more extreme: about 95 percent of the SFT data was dropped, followed by large-scale RL using pass@k analysis to select hard prompts. Meta also reports a fully asynchronous online RL framework that it credits with roughly a tenfold efficiency gain over earlier generations. Treat the efficiency claim as Meta’s own and unverified externally.

The reasoning behind pruning SFT is worth stating. SFT teaches a model to imitate answers; if the data is dominated by easy prompts the model’s output distribution narrows, which leaves less variance for RL to exploit. RL on verifiable or judge-scored tasks only improves what the model already sometimes gets right, so you want the starting policy diverse and the prompts hard enough that success is not guaranteed. This is the same logic behind several 2025 reasoning-model recipes, and Meta applied it to a non-reasoning-first model; notably, the Llama 4 launch did not include a long chain-of-thought “thinking” mode.

Codistillation from Behemoth

Maverick was, per Meta, codistilled from Behemoth. Codistillation here means the teacher’s soft predictions are used as training targets during the student’s pre-training, with a new loss that dynamically weights soft (teacher) and hard (ground truth) targets. The appeal is amortization: the teacher’s cost is shared across students, and soft targets carry more information per token than one-hot labels. The risk is dependency. If the teacher is flawed, the student inherits the flaw, and if the teacher never ships, no external party can reproduce or extend the recipe. Meta has not published the distillation-loss details or how much of Maverick’s quality it attributes to Behemoth.

Capabilities and Benchmarks

The most defensible numbers are the ones in the model card, which were run on BF16 models. Figure 3 charts a subset of the instruction-tuned scores.

Figure 3: Selected instruction-tuned scores from the Llama 4 model card. Maverick leads Scout most on GPQA Diamond and LiveCodeBench.

Official instruction-tuned results

Benchmark	Llama 3.3 70B	Llama 3.1 405B	Scout	Maverick
MMLU Pro (0-shot)	68.9	73.4	74.3	80.5
GPQA Diamond	50.5	49.0	57.2	69.8
LiveCodeBench (10/2024 to 02/2025)	33.3	27.7	32.8	43.4
MGSM	91.1	91.6	90.6	92.3
MMMU	n/a	n/a	69.4	73.4
MMMU Pro	n/a	n/a	52.2	59.6
MathVista	n/a	n/a	70.7	73.7
ChartQA	n/a	n/a	88.8	90.0
DocVQA (test)	n/a	n/a	94.4	94.4

Source: the Llama 4 model card. “n/a” means no multimodal support in the Llama 3 models. MMMU Pro is the average of the standard and vision tasks.

Read the table as three stories. First, Maverick beats the dense 405B Llama 3.1 on every text benchmark shown while using about 4 percent of the active parameters, which is the cleanest demonstration of the MoE economics. Second, Scout is roughly at 405B level on MMLU Pro and GPQA but not on LiveCodeBench, where it is slightly below Llama 3.3 70B; Scout is a long-context and efficiency model, not a coding specialist. Third, document understanding saturates: both models score 94.4 on DocVQA, so that benchmark no longer discriminates.

The pre-trained base-model table adds a few reference points: Maverick reaches 85.5 on MMLU (5-shot), 62.9 on MMLU-Pro, 61.2 on MATH and 77.6 on MBPP, against 85.2, 61.6, 53.5 and 74.4 for Llama 3.1 405B. Scout’s base scores (79.6 MMLU, 58.2 MMLU-Pro, 50.3 MATH, 67.8 MBPP) sit near Llama 3.1 70B except on MATH. Multilingual TydiQA barely moved: 31.5 and 31.7 versus 34.3 for the 405B model, a reminder that 200-language pre-training does not guarantee strong low-resource performance.

What the launch comparisons claimed, and what happened

Meta’s launch post claimed Maverick beat GPT-4o and Gemini 2.0 Flash on many benchmarks and matched DeepSeek V3 on reasoning and coding with fewer than half the active parameters, and that Behemoth outperformed GPT-4.5, Claude Sonnet 3.7 and Gemini 2.0 Pro on STEM benchmarks such as MATH-500 and GPQA Diamond. Those comparisons were against the models of early 2025 and are now historical. The launch post’s text gives no numeric Behemoth scores, so there is nothing to verify.

The most-discussed number was an LMArena Elo of 1417 for what Meta labeled an “experimental chat version” of Maverick. After release, community testers found the publicly downloadable Maverick scored lower, and LMArena stated that Meta’s interpretation of its policy did not match expectations and updated its rules. The episode is the standard cautionary tale: a leaderboard score belongs to the specific checkpoint and system prompt that was tested. Do not use the 1417 figure to reason about the weights you can download.

Benchmark caveats

Benchmarks in this table are vendor-reported on a fixed harness. Contamination is possible for any public benchmark, particularly knowledge sets such as MMLU variants. LiveCodeBench is windowed by date (October 2024 to February 2025) precisely to reduce that risk, but a model with an August 2024 knowledge cutoff still sees some neighboring problems. Third-party aggregators have since published index scores that place Llama 4 Maverick well below 2026 frontier open models; we do not quote their numbers here because index versions change and are not directly comparable across revisions. For your own decision, run a task-specific evaluation, as described in our AI agent evaluation harness architecture guide.

Access, License and Deployment

Figure 4: Deployment paths. Weights come from Meta or Hugging Face, are quantized, and are served on an engine such as vLLM or SGLang across single-GPU, single-node or multi-node tiers.

Where the weights are

Scout and Maverick can be downloaded from llama.com and Hugging Face after accepting the license. They are also offered through hosted APIs from many cloud and inference providers. Pricing varies by provider and changes frequently, so this article does not quote per-token rates; check your provider’s current rate card and compare using the methods in our LLM gateway architecture guide.

The license, precisely

Llama 4 ships under the Llama 4 Community License Agreement, a custom commercial license. Reporting on the launch (for example The Decoder) identified four operational terms:

EU restriction. Companies and individuals domiciled in the EU were not granted rights to use the multimodal models, which Meta attributed to regulatory uncertainty around the EU AI Act. The restriction was reported as not applying to end users of products built by others. Read the current license text with counsel, since terms may have been revised.
Branding. Developers outside the EU must display “Built with Llama.”
Naming. Derivative models distributed must carry a name beginning with “Llama.”
Scale clause. A licensee whose products exceed 700 million monthly active users must request a separate license from Meta.

Because the license also contains an acceptable use policy, it is not an OSI-approved open source license. For regulated deployments, put the license on the review list next to security and data residency.

Hardware arithmetic

Weights dominate memory. At BF16, two bytes per parameter, Scout’s 109B parameters need about 218 GB; at int4, half a byte per parameter, about 55 GB. Meta states Scout fits on a single H100 (80 GB) with on-the-fly int4 quantization, which leaves under 25 GB for KV cache, activations and runtime overhead. Maverick at 400B needs about 800 GB in BF16 and about 400 GB in FP8, which is why Meta describes the FP8 checkpoint as fitting on a single H100 DGX host (eight GPUs, 640 GB total). Memory remains the binding constraint even though only 17B parameters compute per token, because every expert must be resident or reachable.

KV cache is the second budget. The per-token cache size is 2 (keys and values) times layers times KV heads times head dimension times bytes per element. Using illustrative values of 48 layers, 8 KV heads, head dimension 128 and BF16, that is 2 x 48 x 8 x 128 x 2 = 196,608 bytes, about 0.19 MB per token. A 128K-token request would need about 25 GB, and a literal 10M-token request would need nearly 2 TB. The real configuration differs and chunked-attention layers store less, but the order of magnitude explains why nobody serves 10M-token contexts casually: the cache, not the weights, is the wall. Verify your own numbers from the released config.

Serving stacks and quantization

Mainstream engines support Llama 4: vLLM, SGLang, TensorRT-LLM and llama.cpp variants. Expert parallelism spreads experts across GPUs; our expert-parallel MoE serving guide and the vLLM versus SGLang versus TensorRT-LLM comparison cover trade-offs. For quantization choices, see the GGUF versus AWQ versus GPTQ versus FP8 comparison. Speculative decoding can add speed on top; see our speculative decoding explainer.

Throughput and latency vary enormously with batch size, prompt length and interconnect, so we do not quote tokens-per-second figures. As a mechanism-level guide: decode is memory-bandwidth-bound, and an MoE decode step touches the routed expert weights for every token in the batch. At small batch sizes few experts are hit and the model behaves like a 17B model; at large batch sizes nearly all experts are touched each step and effective memory traffic approaches that of a much larger model. That is why MoE shines for large-batch servers and gains less for single-user local inference.

Safety tooling

Meta released companion tools with the models: Llama Guard (an input and output safety classifier), Prompt Guard (jailbreak and prompt-injection detection) and CyberSecEval (security risk evaluation), and says red-teaming used GOAT, a multi-turn automated adversary. Meta also reported that refusals on debated political and social topics fell from 7 percent in Llama 3.3 to below 2 percent. Those are vendor-reported figures.

What Happened to Behemoth, and Why It Matters

Behemoth was previewed with 288 billion active parameters, 16 experts and nearly two trillion total parameters. Meta said at launch that it was still training. It has not been released as public weights. The New York Times reported on July 14, 2025 that Meta had considered abandoning it and was working on a closed model, citing poor internal performance; the Wall Street Journal had earlier reported the delay. Meta has not formally cancelled it, as far as public reporting shows, so the accurate description is “announced, trained to some extent, never shipped.”

SemiAnalysis published a technical diagnosis on July 11, 2025, which Analytics India Magazine summarized. The claimed causes were: chunked attention creating blind spots at chunk boundaries and weakening long reasoning chains; a change of MoE routing method mid-training that disrupted expert specialization; a mid-run switch of the data source to an internal crawler whose cleaning and deduplication had not been stress-tested; and weak scaling of experiments plus weak RL infrastructure. These are third-party analyses, not Meta statements, and should be read as plausible hypotheses. They are nonetheless instructive because each is a generic failure mode of large MoE training.

Consider the dependency chain. Maverick was codistilled from Behemoth. If Behemoth was unstable, what did Maverick actually learn from it? Meta has not said, and nobody outside can ablate it. That uncertainty is one reason the Llama 4 launch quality was seen as uneven relative to its marketing: the release did not include the teacher that justified the architecture’s ambitions.

For a practitioner the lesson is about vendor dependency rather than gossip. A model family is a roadmap, not a guarantee. If your architecture assumes a future member of the family (a bigger Llama, a reasoning variant), you are taking a roadmap risk. Build abstraction at the gateway layer so the model behind an endpoint is replaceable, and treat today’s weights as the product.

The strategic context in 2026

Press and analyst coverage after April 2026 describes Meta’s Superintelligence Labs shipping Muse Spark as a proprietary model, with Meta saying it hopes to open-source future versions and reporting that open-weight variants were in development. Some reports describe later Muse releases, including a small open-weight model; the details of those releases change quickly and several come from secondary sources, so verify against Meta’s own announcements and Hugging Face before depending on them. For Llama 4 itself the implication is simple: it is a frozen artifact. Do not expect a Llama 4.x refresh; expect Meta’s open-weight efforts, if any, under a different name.

Limitations, Safety and Failure Modes

Long context is a claim, not a service level. Scout was trained at 256K. Between 256K and 10M the model relies on extrapolation. Independent long-context evaluations commonly report accuracy decay well before a model’s advertised limit, and long-range reasoning (as opposed to single-fact retrieval) degrades first. The MTOB scores in the model card cover far shorter inputs. If your workload needs reasoning over a million tokens, test it at that length with your own data.

Needle retrieval is not comprehension. Passing a “find the passphrase” test shows attention can locate a token. It does not show the model can aggregate, compare or reason across dispersed evidence. Design evaluations that require multi-hop synthesis.

Memory footprint versus active size. Marketing emphasizes 17B active. Your GPU bill follows 109B or 400B resident parameters. A team that provisions for a “17B model” will run out of memory, and a team that quantizes aggressively to fit may lose quality. int4 on-the-fly quantization is a convenience; measure the degradation on your task.

Expert imbalance at inference. Real traffic is not uniform. If a domain (say, code or one language) routes heavily to a few experts, those experts’ GPUs become hot spots under expert parallelism, causing tail-latency spikes. Monitor per-expert load and consider replication of hot experts.

Multimodal limits. The model card reports image understanding testing with up to five images and output limited to text and code. It does not generate images or audio. Twelve languages are officially supported for the model, though pre-training touched about 200; expect weaker behavior outside the supported set.

Knowledge cutoff. August 2024. Without retrieval the model is stale on events, library versions and APIs from the last two years. Coding agents built on it may suggest deprecated interfaces.

Safety is layered, not guaranteed. Llama Guard and Prompt Guard reduce risk but are classifiers with their own error rates. Open weights can be fine-tuned to remove safeguards, so the safety property you inherit is only as strong as your own deployment controls. For adversarial testing patterns, see our LLM red-teaming guide.

Hallucination. Like other non-reasoning models of its generation, Llama 4 will answer confidently when it lacks knowledge. Meta’s tuning reduced refusals, which also lowers the model’s tendency to decline; pair it with retrieval and citation checks for factual work.

License risk. The EU provisions and the scale clause are real constraints. A product that fits the license today can fall out of compliance through acquisition, growth or relocation.

How Llama 4 Compares

The table below is a qualitative decision matrix; it deliberately avoids quoting third-party scores that change with every index revision.

Use case	Llama 4 Scout	Llama 4 Maverick	Newer open MoE models (DeepSeek, Qwen, MiMo class)	Closed frontier APIs
Single-GPU self-hosting	Strong fit with int4	Not feasible	Varies, often larger	Not applicable
Long-document analysis	Good to a few hundred K tokens; verify beyond	Good to hundreds of K	Often stronger reasoning at long range	Strongest, with SLAs
General chat and coding	Adequate	Solid for its generation	Usually ahead in 2026	Ahead
Vision and documents	Good, saturated on DocVQA	Good	Mixed	Strongest
License simplicity	Custom, EU and scale clauses	Same	Often MIT or Apache 2.0	Contract terms
Ecosystem and tooling	Excellent	Excellent	Growing	Excellent

The honest summary is that Llama 4 is no longer the best open-weight option on raw capability, but it remains a well-supported, well-documented baseline with first-class tooling. Peers from 2026 such as MiMo V2.6 Pro and DeepSeek V4.1 Flash are covered in this series, as is closed-model reference Gemini 4 Argon.

Edge deployments are a special case. A 109B model, even at int4, is not an edge model. For embedded and Jetson-class work, smaller dense models dominate; see our edge LLM benchmark for what actually fits.

Practical Recommendations

Choose Llama 4 when you need a stable, widely supported open-weight model with native image input, your legal team has cleared the license, and your workload does not need frontier reasoning. Scout suits single-GPU or small-node deployments for summarization, retrieval-augmented generation (RAG) and document Q&A. Maverick suits teams with a DGX-class host who want the strongest model of this family and can amortize the hardware with high batch utilization.

Avoid it as the default for new projects that need top-tier reasoning, agentic coding or a permissive license, where newer open-weight releases are likely a better starting point. And do not select it on the strength of the 10M-token or the 1417 Elo headline.

Operational checklist:

Read the current Llama 4 Community License with counsel; confirm EU, branding and scale clauses.
Size memory from total parameters plus a KV-cache budget computed from the released config, not from active parameters.
Start with the FP8 Maverick checkpoint or int4 Scout; benchmark quantization loss on your own tasks.
Cap production context at the length you have validated, and add a retrieval layer rather than stuffing long prompts.
Monitor per-expert load, tail latency and out-of-memory events under real traffic.
Put the model behind a gateway so you can swap it for a newer release without code changes.
Add Llama Guard or an equivalent filter, log prompts and outputs, and red-team before launch.
Re-evaluate quarterly: the open-weight frontier moves fast.

Frequently Asked Questions

What is Llama 4 and who made it?

Llama 4 is Meta’s fourth-generation open-weight model family, released on April 5, 2025. It uses a mixture-of-experts transformer with native image input. Two models, Scout (109B total, 17B active, 16 experts) and Maverick (400B total, 17B active, 128 routed experts plus a shared expert), are downloadable. A larger teacher, Behemoth, was previewed but not released as public weights.

Is Llama 4 really open source?

No in the strict sense. The weights are downloadable under the Llama 4 Community License, a custom commercial license with an acceptable use policy, a branding requirement, a 700-million-monthly-active-user threshold requiring separate permission, and, at launch, restrictions on EU-domiciled users of the multimodal models. Training data and code are not released, so it is open-weight rather than OSI open source.

How much GPU memory does Llama 4 need?

Memory follows total parameters. Scout has 109B parameters: roughly 218 GB at BF16 and 55 GB at int4, and Meta says it fits one 80 GB H100 with int4. Maverick has 400B: about 800 GB at BF16 and 400 GB at FP8, fitting an eight-GPU H100 DGX host. Add KV-cache memory, which grows linearly with context length and batch size.

Does Llama 4 Scout really support a 10 million token context window?

The model card lists a 10M-token context, but Meta says Scout was pre-trained and post-trained at 256K tokens and relies on iRoPE length generalization beyond that. Quality at multi-million-token lengths is not independently established, and the KV cache required is enormous. Treat 10M as an upper bound and validate your own task at the length you plan to use.

What happened to Llama 4 Behemoth?

Behemoth, previewed with about 2 trillion parameters and 288B active, was not released as public weights. The New York Times reported in July 2025 that Meta had considered abandoning it after poor internal performance. Third-party analysis points to routing changes, chunked attention blind spots and data pipeline problems. Meta has not published a formal post-mortem, so the causes remain reported rather than confirmed.

Is Llama 4 still worth using in 2026?

For many tasks, yes: it has broad tooling, solid document and image understanding, and manageable single-node deployment for Scout. For frontier reasoning, agentic coding or permissive licensing, newer open-weight models are usually stronger. Evaluate on your own data, check the license, and keep the model swappable behind a gateway.