Llama is often described as open source, but the practical product is an open-weight model family under Meta’s own community licence. That distinction matters less as a slogan than as an operating fact: the licence governs redistribution and branding, while the deployer still has to choose a checkpoint, prompt format, tool parser, precision, hardware and serving framework.[1][2]
A company can therefore run the same named Llama checkpoint and produce a materially different system from another provider. One route may use Meta’s official prompt format, another may translate OpenAI-style tool schemas through vLLM, and a third may quantise the model or shorten the available context. The weight file is common; the behaviour presented to users is not.
What the Llama 4 licence requires
| Situation | Published obligation | Why it matters |
|---|---|---|
| Distributing or making available Llama materials, derivatives, or a product/service containing them | Include the licence and prominently display “Built with Llama” | The model cannot be treated like an unbranded public-domain component.Source 1 |
| Distributing an AI model trained or improved using Llama materials or outputs | Begin the distributed model’s name with “Llama” | The naming rule follows the downstream model, not only the original checkpoint.Source 1 |
| Distributing copies of the materials | Retain the specified attribution notice in a Notice file | Packaging and compliance become part of release engineering.Source 1 |
| Licensee or affiliate products/services exceeding 700 million monthly active users in the month before the Llama 4 release | Request a separate licence from Meta | The community licence does not grant automatic rights at that scale.Source 1 |
| Using the model in a product | Follow applicable law and the incorporated acceptable-use policy | Possessing weights does not remove deployment and policy duties.Source 1 |
The model family itself is not one runtime target
Meta’s repository lists Llama 4 Scout with a ten-million-token context window and Maverick with one million. Those values describe model-family configurations, not the context that every host will expose economically or reliably. A provider may impose a lower maximum, charge more for long input, disable modalities or use a different quantisation and serving stack.[2]
The same repository says Llama 4 requires at least four GPUs for full-precision BF16 inference in Meta’s reference scripts. That is a concrete reminder that “downloadable” is not the same as “runs on the machine already in the office”. Production concurrency, long contexts and multimodal requests raise the resource requirement beyond a one-user demonstration.[2]
Tool use depends on a grammar around the model
A tool-using model must turn a natural-language decision into a structured function name and arguments that the application can execute. vLLM therefore requires model-specific parsers and chat templates. Its current documentation recommends the llama4_pythonic parser and a Llama 4-specific template for Llama 4 models rather than assuming generic JSON will always be interpreted correctly.[3]
The documentation also records known failure modes: Llama can emit an array as a string instead of an array, and smaller Llama models can struggle to produce tool calls in the expected format. Parallel calls are not supported for Llama 3 under the documented parser but are supported for Llama 4. Those are product-level differences created at the boundary between model output and executable software.[3]
Layers between a checkpoint and a dependable agent
| Measure | Value | Context |
|---|---|---|
| Checkpoint | Exact model and revision | Scout and Maverick have different context and scale characteristics.Source 2 |
| Licence | Llama 4 Community License | Redistribution, attribution, naming and very-large-platform terms apply.Source 1 |
| Prompt format | Model-specific chat template | Messages and prior tool results must be serialised in the expected structure.Source 2Source 3 |
| Tool parser | For example llama4_pythonic in vLLM | Extracts structured calls from generated text and can affect reliability.Source 3 |
| Schema enforcement | Strict versus free-form argument generation | Without the appropriate constraint path, arguments can violate the tool schema.Source 3 |
| Serving system | Hardware, precision, batching and context policy | These determine latency, cost, concurrency and the context users actually receive.Source 2 |
Hosted Llama products need their own evaluation
A cloud endpoint, local vLLM server and consumer assistant can all advertise Llama while differing in system prompts, moderation, retrieval, tools, context, update timing and observability. The model family establishes an important common component; it does not make those products interchangeable.
A useful comparison should therefore name the complete route: model revision, context exposed, precision, prompt template, tool parser, tool schema, provider policy and hardware class. For an agent, test the exact tools and invalid-argument cases that matter. A text benchmark cannot establish whether the parser will safely call a payment, database or deployment function.
Llama’s open-weight ecosystem creates real choice: organisations can self-host, modify and integrate a frontier model family rather than depend on one API. The corresponding limitation is fragmentation. Freedom moves consequential decisions into the deployment stack, where they must be made explicitly and tested as part of the product rather than treated as invisible plumbing.
Sources & further reading
- Llama 4 Community License Agreement Meta Llama on GitHub · 5 Apr 2025 · Accessed 10 Oct 2026
- Llama models repository, downloads and runtime guidance Meta Llama on GitHub · Accessed 10 Oct 2026
- Tool calling in vLLM vLLM documentation · Accessed 10 Oct 2026