Open Source · 2026-11-12

Llama 4 and Meta's open-weights strategy

Illustration for Llama 4 and Meta's open-weights strategy

Meta's bet is simple to state and brutally hard to pull off: give away the model, own the ecosystem. Llama 4 was supposed to be the clearest proof yet that a frontier lab could win by opening up. The launch was messier than the slide deck promised, and the fallout tells you more about open weights than any keynote ever will. This is what actually happened, what the license really says, and where Llama 4 belongs in your stack today.

What actually shipped

Llama 4 arrived in April 2025 with two open-weights models and a third held back. Scout, a smaller mixture-of-experts model aimed at long-context work, and Maverick, the bigger sibling pitched as a general-purpose frontier competitor. The headline monster, Behemoth, a roughly 2-trillion-parameter MoE teacher, was announced but not released. Meta positioned it as the training-stack proof rather than something you'd ever download, which is its own tell: they wanted credit for the class of model without the hosting bill or the scrutiny that comes with shipping it.

Maverick reportedly tops out around 400B total parameters with roughly 17B active per token, across dozens of experts. Scout is smaller and cheaper to serve, with a context window Meta advertised at a headline-grabbing 10 million tokens. Numbers like that deserve a raised eyebrow. Long context in a benchmark harness and long context in production are different sports, and anyone who has actually tried to stuff millions of tokens into a prompt knows retrieval quality falls off a cliff well before the theoretical limit. We've seen Scout perform respectably on genuine needle-in-haystack tasks up to a few hundred thousand tokens, then get wobbly beyond that — which is useful, just not the number on the box.

Both models are natively multimodal, handling text and images, and both are architected as mixture-of-experts rather than dense transformers. That's a sensible cost decision at this scale, but it also means hosting them is a different beast from running a dense 70B. You need more GPUs of lower utilization, fast interconnect, and serving software that understands expert routing — which is to say vLLM, TensorRT-LLM or SGLang, run by someone who has done it before.

The benchmark drama, briefly

You can't talk about Llama 4 without mentioning the elephant in the room. Comparisons on LMArena surfaced around launch showing Maverick posting strong numbers, then it emerged those results came from a specially tuned conversational variant rather than the raw open-weights checkpoint people could download. Meta pushed back, researchers pushed harder, and the whole episode left a sour taste. Benchmark researchers and independent evaluators noted that the gap between "Llama 4 as demoed" and "Llama 4 as downloadable" was real enough to matter for procurement decisions.

The lesson isn't that Llama 4 is bad. It's that "open weights" and "the model we demoed" are not always the same artifact. If you're evaluating on someone else's screenshots, you're evaluating their marketing. Pull the actual checkpoint from Hugging Face, quantify it the way your production nodes would, and judge that. This discipline sounds obvious until you've sat through three vendor evaluations that all turned out to be running a specially instrumented fork of something.

The license is open-ish, not open source

This is the part that trips people up. Llama 4 ships under the Llama Community License, not MIT or Apache 2.0. Practically speaking, commercial use is fine for almost everyone. The catch: if your product crosses a very large monthly-active-user threshold — 700 million is the number in the license, inherited from the Llama 3 era — you need a separate agreement with Meta. The license also includes acceptable-use restrictions, naming requirements for derivative models (Llama derivatives must carry "Llama" in the name), and carve-outs that have shifted over time around EU users and multimodal variants.

Is that open source? Not by the OSI definition, and open-source advocates have been loud about it — rightly. Calling Llama "open source" in a keynote is marketing wearing engineering's clothes. Is it open weights that most companies can build on commercially without paying Meta a cent? Yes, and for the vast majority of teams that's the part that matters. Just don't let legal skip the read because the word "open" is in the headline. Ten minutes with the actual text is cheaper than one copyright question later.

Why Meta keeps doing this

Meta doesn't sell API tokens. It sells ads and reality-labs dreams, and it benefits from open weights because they commoditize the layer above the model, not the model itself. Every Llama deployment that runs on someone else's GPUs, in someone else's product, weakens the pricing power of the closed labs. It also pulls developer mindshare away from OpenAI and Anthropic toward an ecosystem Meta can influence through the Llama toolchain, partnerships with cloud providers and, increasingly, infrastructure deals that make Llama the default-open-model on managed platforms.

There's a recruiting and research dividend too. Open releases attract talent and surface failure modes before they become headline incidents. An open release is a distributed red team with reputation incentives, and no amount of internal QA replicates that. And open weights are a geopolitical instrument: a US-origin counterweight to the flood of strong Chinese open releases. That last point matters more in 2026 than it did in 2024, and Meta's lobbying and positioning make clear they see it that way.

There's also an unglamorous internal logic: Meta's infrastructure team gets better by serving enormous MoEs in-house, Llama 4 is partly a flex of that muscle, and shipping weights forces the serving stack to mature for everyone.

Where Llama 4 actually fits

Maverick was never going to beat the best closed models at everything. What it is, is a good, fast, cheap generalist with solid coding and tool-use performance, and it runs anywhere you can host a large MoE. Served well with vLLM or TensorRT-LLM, with FP8 quantization, it's a very reasonable default for high-volume internal workloads: classification, summarization, RAG over internal corpora, agent scaffolding where the task graph is well understood. We've seen teams drop their aggregate inference spend 40 to 60 percent migrating such workloads from a frontier API to a self-hosted Maverick.

Scout, with its long context, is more interesting on paper than in practice for most teams, but if you're doing whole-repo analysis, long contract review or multi-document litigation work, it's worth a serious look — with your own retrieval evals, not the marketing numbers. For genuinely long-context dependence, though, a good retrieval pipeline on top of a smaller model often wins on both cost and accuracy.

What Llama 4 is not is a drop-in replacement for a frontier reasoning model. On hard multi-step reasoning, the closed labs still lead, and DeepSeek R1-class open reasoners often beat Maverick at math and code per dollar spent anyway. If your workload is "think hard about one thing," test R1-distills before you assume Maverick is enough.

Fine-tuning and derivative work

One thing people overlook until legal asks: fine-tuning Llama 4 is explicitly allowed, and the license even anticipates it. Derivative models must carry "Llama" in the name, which is awkward if you were hoping to brand your in-house assistant after your company's mascot, and attribution notices have to ship with the weights you redistribute. None of this blocks internal use in the slightest — it only matters if you ship a derivative model onward to customers or partners.

Practically, Llama 4 is a fine base for LoRA adapters on narrow tasks, though our experience echoes what we see elsewhere with MoEs: adapter updates interact with expert routing in ways dense models don't, so validate on your full task suite, not just the target slice. Start from the smallest Scout configuration that holds up on your evals, keep the adapter narrow, and re-run your regression set after every base-model or driver bump. It's unglamorous, but that's most of what "running open weights in production" actually is.

Hosting reality: what it actually takes

Two things surprise teams moving from 8B dense models to Llama 4. First, memory: even quantized, Maverick needs multiple high-memory GPUs to serve usefully. You're in multi-H100 or multi-MI325 territory, or you're renting. Second, throughput economics: MoE models shine at high batch sizes, so Llama 4 is happiest in high-traffic services, not in low-concurrency internal tools. If you have ten users a day, an API is cheaper; if you have ten thousand requests an hour, self-hosting starts to sing. Run the arithmetic before you order the GPUs.

What to watch next

  • Whether Meta releases Behemoth at all, or keeps it purely as a teacher model behind closed doors.
  • How quickly the community fine-tunes and merges Llama 4 into competitive variants on Hugging Face — that's where the real value lands, weeks after any launch.
  • Whether the EU licensing situation settles down or stays a headache for European operators and their legal teams.
  • If Meta keeps the cadence, expect another major drop soon, likely aimed squarely at the DeepSeek and Qwen cost-performance curve.
  • Distillation quality: community R1-style distills of Llama 4 would change the reasoning calculus for open self-hosters overnight.

How teams are actually deploying it

A pattern we keep seeing: Llama 4 as the default completion engine behind internal tools — ticket triage, doc summarization, PR descriptions, meeting notes cleanup — with a frontier API kept warm for the genuinely hard 10 percent. One fintech we talked to runs Maverick quantized on two rented 8×H100 nodes for all Tier-1 support automation and only escalates to a frontier endpoint when confidence scores dip. Their measured cost per resolved ticket dropped by more than half, and their p95 latency fell under a second.

Smaller shops take a different route: they skip Maverick entirely and run Scout or even Llama 3.x-class models via Ollama on developer machines for coding assistance, keeping real workloads on APIs. Both patterns are legitimate. The wrong move is cargo-culting a 400B MoE onto a problem that a 8B model solves before lunch.

The honest take

Meta deserves credit for making open weights a boardroom strategy rather than a research footnote. That genuinely shifted the industry's center of gravity, and every closed lab now prices its API with one eye on what you could run locally for free. But the Llama 4 cycle showed the seams: launch benchmarks that outran the downloadable artifact, a license that's permissive but not free, and an architecture built for Meta's scale more than yours.

If you run models in production, treat Llama 4 as a solid, commercially usable workhorse with sharp edges, not as charity or a silver bullet. Test it on your own data, read the license, quantinize before you scale, and keep a Chinese open model in the bake-off. That last part would have sounded absurd eighteen months ago. It's just good procurement now.