Llama Guard vs Prompt Guard: when each one fits
Choose Llama Guard 4 when the question is what content is in a prompt or a response. It is a 12-billion-parameter multimodal safety classifier pruned from Llama 4 Scout, and it labels both prompts and responses against the MLCommons hazards taxonomy. It replaces Llama Guard 3-8B and 3-11B-vision in one model, so a team already running those models has a single successor to evaluate. Choose Prompt Guard 2 when the question is whether input is trying to subvert the model. The 86M and 22M versions label a prompt as benign or malicious to flag prompt injection and jailbreak attempts, and both use a 512-token context window. The 22M version is built on DeBERTa-xsmall and is the lighter option, where the model card says it cuts latency and compute by 75% with minimal performance trade-offs. The 86M version is multilingual.
Start with the threat model. If your main exposure is users producing harmful or policy-violating content, Llama Guard 4 addresses that directly. If your main exposure is untrusted text from documents, web pages or tools steering the model, Prompt Guard 2 is the closer match, and it is often placed on inputs before they reach the main model. Confirm the context window your real inputs will hit, since long retrieved documents may exceed 512 tokens and need chunking or a different design.
Then weigh latency, hardware and whether you need both. Prompt Guard 2 is the smaller model, so it is the easier fit for a tight latency budget or modest GPU capacity. Llama Guard 4 is a 12B model and needs more hardware, which you should size against your own traffic. Both ship under Llama 4 Community License terms, so confirm those terms with your legal team before deployment. Many pipelines run both: a small injection screen on input and a hazard classifier on output. Decide that after testing both against your own prompts.
Which scenario favors which classifier
This table maps common deployment scenarios to the classifier that fits best, with the reason for each choice. Llama Guard 4 classifies hazard categories in prompts and responses, while Prompt Guard 2 flags injection and jailbreak attempts, so many scenarios need both.
| Scenario | Better fit | Why |
|---|---|---|
| Public chatbot with a content policy | Llama Guard 4 | It labels both user prompts and model responses against hazard categories, which is what a content policy needs to enforce. |
| RAG over untrusted documents | Prompt Guard 2 | Retrieved text can carry embedded instructions, and Prompt Guard 2 screens that content for injection before it reaches the model. |
| Agent with tool calls | Both, Prompt Guard 2 first | Injected instructions can trigger tool misuse, so screen inputs with Prompt Guard 2 and check outputs and actions with a hazard classifier. |
| Multilingual user base | Prompt Guard 2 (86M) | The 86M version is described as multilingual, while the 22M version is the smaller, lower-latency option. Confirm language coverage for your locales before relying on either. |
| Tight latency budget | Prompt Guard 2 (22M) | The model card says the 22M version cuts latency and compute by 75% with minimal performance trade-offs. Benchmark both sizes on your own hardware. |
| Multimodal inputs such as images | Llama Guard 4 | It is a multimodal classifier that covers both prompts and responses. Prompt Guard 2 is a text classifier. |
| Long prompts or documents | Test both against your inputs | Prompt Guard 2 has a 512-token context window, so long inputs need chunking or a scoring strategy. Confirm Llama Guard 4 limits in its model card. |
| Single classifier is enough | Depends on the threat | A pure moderation use case may need only Llama Guard 4, and a pure injection risk in a narrow input path may need only Prompt Guard 2. Most production pipelines combine both. |
How each classifier is built and where it sits
Llama Guard and Prompt Guard solve different problems, so they sit at different points in a request path. The cards below cover what each model is built on, how large it is, the context limit that shapes what it can see, and where it fits when you add it to a pipeline.
Llama Guard 4 design
Llama Guard 4 is a 12-billion-parameter multimodal classifier pruned from Llama 4 Scout. It scores both prompts and responses against the MLCommons hazards taxonomy and replaces the earlier Llama Guard 3-8B and 3-11B-vision models in a single model. Because it is multimodal, check that your input pipeline sends images through the classifier and not only text, and confirm how your serving stack handles image inputs before you count on that coverage.
Llama Guard placement on input and output
Llama Guard is a content safety gate. Run it on the user prompt before the application model sees it, and again on the model's response before the user does. Because it judges hazard categories, a flagged message needs a defined outcome, such as refusal, redaction or human review. Decide who owns that policy and how each category maps to your own acceptable use rules.
Prompt Guard 2 22M variant
The 22M variant is built on DeBERTa-xsmall and the model card says it cuts latency and compute costs by 75% with minimal performance trade-offs. It is the better fit when the classifier runs on every request in a latency-sensitive path, or on CPU-bound hosts. Test its detection rate on your own injection samples, since a smaller model is more likely to miss unusual phrasing.
Prompt Guard 2 86M variant
The 86M variant is the multilingual option, so choose it when user input or retrieved documents arrive in several languages. It also needs more memory and compute than the 22M variant. Run a benchmark on your own traffic mix to confirm the latency budget holds at your peak request rate before you commit to it.
Shared 512-token context window
Both Prompt Guard 2 variants use a 512-token context window, so long prompts, pasted documents or large retrieved passages must be split into chunks before scanning. Chunking changes what the classifier sees, so an injection that spans two chunks can be missed. Decide how you will overlap chunks and aggregate verdicts, and test that logic with attacks placed at chunk boundaries.
Prompt Guard before the model and on retrieved content
Prompt Guard targets injected instructions, so it belongs before the model receives user input and on retrieved content such as web pages, emails and documents used in retrieval-augmented generation. Indirect injections often arrive through those sources, not the chat box. Confirm which data paths in your application feed the model, and scan each one, since a check on the chat input alone leaves retrieved content unscanned.
Capability, size and context limits compared
This table compares Llama Guard 4 and Prompt Guard 2 on size, primary task, labels, input type, context limits, languages, license and pipeline placement. Read it as two different jobs: Llama Guard 4 classifies hazards in both prompts and responses, while Prompt Guard 2 flags injection and jailbreak attempts in incoming prompts. The main takeaway is that Llama Guard 4's context window and language coverage need confirmation before you size a deployment.
| Capability | Llama Guard 4 | Prompt Guard 2 |
|---|---|---|
| Parameter count | 12 billion parameters | Two versions: 86M and 22M parameters |
| Primary task | Content safety classification of prompts and responses | Detecting prompt injection and jailbreak attempts |
| Taxonomy or labels | MLCommons hazards taxonomy | Benign or malicious labels |
| Input type | Multimodal, covering prompts and model responses | Prompts only, with no response classification |
| Context window | Confirm the limit in the model card before sizing inputs | 512-token context window |
| Multilingual support | Confirm supported languages in the model card | 86M version is multilingual; 22M is the smaller option |
| License | Llama 4 Community License Agreement | Llama 4 Community License Agreement |
| Pipeline placement | Input and output checks on user prompts and model replies | Input check on incoming prompts, often run inside LlamaFirewall |
| Compute trade-off | Largest footprint of the two; confirm hardware needs with Meta | The 22M model cuts latency and compute by 75% with minimal trade-offs, per its model card |
Licensing: what the Llama 4 Community License means for each
Llama Guard 4 and Llama Prompt Guard 2 both ship under the Llama 4 Community License Agreement. For a team choosing between them, this means the two models share one license text, so a single legal review can cover both if you deploy them together. The agreement governs the model files you download and use, not the code you write around them.
- Shared license text: Llama Guard 4 (12B) and Prompt Guard 2 (22M and 86M) are both covered by the Llama 4 Community License Agreement.
- Model files are the licensed item: The agreement attaches to the weights you obtain, so check how your deployment packages and distributes them.
- Version changes the license: Llama Guard 4 replaces Llama Guard 3-8B and 3-11B-vision, so moving to it changes the governing terms.
- Read the license with the model card: Acceptable use and attribution expectations appear in the agreement and the model card, so review both.
Check the LICENSE file in the Llama Guard 4 folder of the PurpleLlama repository for the exact text you are accepting.
Purple Llama licenses its evals, benchmarks and Code Shield under the MIT license, and LlamaFirewall is also MIT licensed. MIT terms cover the code you copy, modify and redistribute. They do not change the terms on the models that the code calls, so teams that combine these components carry two licenses in one stack.
- Code Shield: MIT licensed, it statically analyzes LLM-generated code in 8 languages using Semgrep and regex rules.
- LlamaFirewall: The MIT-licensed framework can call PromptGuard 2 for direct prompt injection, but the Llama 4 terms still apply to the Prompt Guard 2 model.
- CyberSecEval: MIT licensed evals and benchmarks, which your team can use for internal testing without the model license terms applying to the benchmark code.
- Attribution in redistribution: MIT requires you to keep the copyright and license notice in copies of the code you distribute.
Confirm which package and which model files each component pulls in before you record the approval in your internal register.
Models released before the Llama 4 series use the Llama 3.2 Community License. Purple Llama's license table gives Llama Guard 3 and the original Prompt Guard as examples of models under that license. If your existing deployment uses Llama Guard 3-8B or 3-11B-vision, those copies remain under the Llama 3.2 terms until you migrate, so do not assume a newer license applies to a model you already downloaded.
- Llama Guard 3 models: Governed by the Llama 3.2 Community License according to the PurpleLlama license table.
- Original Prompt Guard: Also listed under the Llama 3.2 Community License, which differs from Prompt Guard 2.
- Migration changes the terms: Moving to Llama Guard 4 or Prompt Guard 2 means accepting the Llama 4 Community License Agreement.
- Inventory every copy: Record the model name, size and license for each running instance, including staging and evaluation copies.
Ask your legal team to map each deployed model version to its license before migration planning begins.
This page is not legal advice. The points below help your legal team focus its review on the terms that most often affect how a self-hosted safety classifier is used. Each deployment context can raise different questions, so the review should start from your actual use case and the version you intend to run.
- Use case scope: Confirm that the agreement's acceptable use terms cover your product, including customer-facing and internal deployments.
- Redistribution: If you ship model files inside a product, appliance or container image, confirm the redistribution and attribution duties.
- Derivatives: If you fine-tune, prune or quantize a model, check how the agreement treats derivative works.
- Commercial terms: This page does not cover paid editions, so ask Meta whether any commercial terms apply to your use.
- Records: Keep the accepted license text with your deployment record and tie it to the model version and hash.
Have counsel sign off on this list before your architecture review, and repeat the check whenever you change model versions.
What drives the running cost of each classifier
Both classifiers are self-hosted, so the running cost is your own compute, not a per-call fee to Meta. Llama Guard 4 is a 12-billion-parameter model, while Prompt Guard 2 comes in 22M and 86M parameter versions. The gap in model size drives the gap in hardware. Llama Guard 4 needs GPU or sizable CPU capacity to meet a latency target, and that capacity must be sized for peak traffic, not average traffic. Prompt Guard 2 is small enough that teams often run it on the same hosts as the application, but you should confirm the throughput your own hardware reaches with your prompt lengths before committing to that layout. Ask whether the vendor or your integrator has benchmarked both models on hardware that matches your target environment.
The Prompt Guard 2 model card states that the 22M version, based on DeBERTa-xsmall, cuts latency and compute costs by 75% with minimal performance trade-offs. The figure comes from Meta's model card, so treat it as the vendor's claim and test it against your own traffic and attack corpus. Two checks matter here. First, measure latency and detection rate on your real prompts, including any multilingual traffic that may justify the 86M multilingual version. Second, count the cost of false positives that block legitimate users, because a cheaper model that misclassifies more requests can raise support and review costs. Llama Guard 4 has a different cost profile: it classifies both prompts and responses, so every request and response in scope adds inference work, and the 512-token context window on Prompt Guard 2 means long inputs need chunking, which adds engineering and compute.
Separate one-time costs from recurring ones when you request a quote. One-time costs include planning, integrating the classifier into your pipeline, building an evaluation set, tuning thresholds, and documenting the controls. Recurring costs include GPU or CPU hours, hosting, log storage for flagged events, monitoring, model updates, and periodic re-evaluation when you change prompts, models or the Llama Community License terms that apply to each model. Ask for the written scope to name which models are covered, the hardware assumed, the traffic volume used for sizing, who operates the endpoints, and whether re-tuning after a model change is included. DeployOpen does not publish prices, so request a quote built from that written scope.
Adding the second classifier to an existing pipeline
This sequence shows how to move from one classifier to running Llama Guard and Prompt Guard together, or from Llama Guard 3 to Llama Guard 4, without losing the policy work, logs and tests you already have. The output is a pipeline where each classifier has a defined job, a tested threshold and a documented place in the request path.
Inventory what the current pipeline already holds
The team that owns the application lists every policy definition, hazard category mapping, log schema, stored test prompt and alert rule in the existing setup. Security or compliance staff confirm which of these represent decisions the organization has already made and must keep. The step is done when the inventory has an owner for each item and each item is marked as transfers, needs rebuilding or needs review.
Decide the role of each classifier
Architecture and security leads decide whether Prompt Guard screens inbound prompts for injection and jailbreak attempts, whether Llama Guard screens prompts and responses for content hazards, or whether both run at different points. Llama Guard 4 is a single model that classifies both prompts and responses, so the choice also covers whether it replaces the existing Llama Guard model or runs beside Prompt Guard. The step is done when a written placement diagram names each classifier, its input and its output action.
Map the existing taxonomy to the new model
Engineers compare the hazard categories used in the current policy with the categories the target Llama Guard version uses, which follow the MLCommons hazards taxonomy referenced in the model card. Where a category lacks a clean match, compliance staff decide whether to merge it, keep a local rule or accept the gap. The step is done when a mapping table lists every legacy category with its new counterpart or documented exception.
Run the stored test set against the new classifier
The team runs the test prompts and responses collected from earlier work against the new classifier in a staging environment, keeping the original expected labels. Differences are sorted into false positives, false negatives and label changes caused by the taxonomy shift. The step is done when every difference has a recorded disposition and the test set includes new cases for injection and jailbreak attempts if Prompt Guard is added.
Recalibrate thresholds and actions
Engineers set the score or label thresholds that trigger blocking, logging or human review for each classifier, starting from the values used in staging rather than from defaults. Because the two classifiers answer different questions, their thresholds and fallback actions are set separately. The step is done when each threshold has a documented rationale and a named approver, and the values are stored in version-controlled configuration.
Confirm license and runtime requirements
Legal or procurement staff check the license that applies to each model version, since Llama Guard 4 and Prompt Guard 2 both ship under the Llama 4 Community License Agreement while older Llama Guard 3 models used the Llama 3.2 Community License. Platform engineers confirm that the host has capacity for the parameter count and context limit of each model. The step is done when a sign-off records the license terms accepted and the hardware or service plan that will run each classifier.
Roll out in shadow mode, then enforce
The new classifiers first run alongside the existing path in shadow mode, logging their decisions without changing user-facing results. Operators review the disagreements over a period agreed in advance, then move the enforcing action to the new classifiers one route at a time. The step is done when the shadow logs show the agreed disagreement rate has been reviewed and each route has a recorded switch-over decision.
Retire the old path and document the result
Once enforcement has moved, the team removes the old classifier from the request path while keeping its logs and test cases for audit history. The runbook, data flow diagram and control evidence are updated to match the new placement. The step is done when the runbook and diagram reflect the live pipeline and an independent reviewer has checked that retained logs can still be read.
Where implementation projects usually run long
Most of the schedule risk in a Llama Guard and Prompt Guard deployment sits outside the model download. The typical work runs in a fixed sequence: hosting the classifiers inside your own cloud account, data center or air-gapped network, calibrating thresholds against your own traffic, mapping the MLCommons hazard categories that Llama Guard 4 emits onto your written content policy, wiring the verdicts into the application and its logs, and then red team testing the result with tools such as garak or promptfoo. Each step depends on decisions that someone in your organization has to own, so confirm early who approves the policy mapping and who signs off on the thresholds.
The longest stretches usually come from three places. The first is labeled evaluation data: tuning a Prompt Guard 2 threshold or checking Llama Guard 4 verdicts requires a set of your own prompts and responses labeled benign or malicious (or assigned a hazard category), and building that set takes time that no vendor can estimate for you. The second is false positive tuning, since a classifier that is correct on public benchmarks can still block legitimate customer requests in your domain, and each adjustment needs a new round of review. The third is multilingual coverage: the 86M Prompt Guard 2 model is the multilingual variant according to its model card, so if your users write in several languages, test each one with your own samples rather than assuming the 22M model behaves the same way.
If you plan to layer controls, LlamaFirewall adds Prompt Guard 2 alongside other scanners, including AlignmentCheck for auditing agent reasoning, CodeShield for insecure generated code, and regex or custom scanners. Its README states that AlignmentCheck requires a Together API key, so confirm that an external service and its data handling are acceptable to your security and compliance teams before you scope that component. Ask your implementation partner to put the key handling, the logging design and the threshold review schedule into the written scope so that they are not discovered during the testing phase.
Questions buyers ask before choosing or hiring help
Which one should my team start with, Llama Guard or Prompt Guard?
Start with the risk you can least tolerate. Prompt Guard 2 targets prompt injection and jailbreak attempts in incoming text, so it is usually the first control for applications that accept untrusted user or document input and call tools. Llama Guard 4 classifies both prompts and responses against hazard categories, so it fits teams whose main exposure is harmful or policy-violating content in what the model says. Map your threat model first, then add the second classifier only where the first leaves a gap. Confirm the placement and thresholds in your own test environment before relying on either one.
Do we need both Llama Guard 4 and Prompt Guard 2 in production?
Not always. The two models answer different questions. Prompt Guard 2 labels input as benign or malicious for injection and jailbreak patterns. Llama Guard 4 assigns hazard categories from the MLCommons taxonomy to prompts and responses. A customer-facing assistant that only answers from a fixed knowledge base may need less than an agent that reads email, browses the web and calls internal APIs. Many teams run both, with the smaller Prompt Guard 2 model on every input and Llama Guard 4 on outputs where content policy matters. Test the combined latency and false positive rate against your own traffic.
What does the Llama 4 Community License require before we deploy?
Llama Guard 4 and Prompt Guard 2 both ship under the Llama 4 Community License Agreement, according to the LICENSE files in the PurpleLlama repository. Read the full text with your legal team before deployment, since model licenses carry use restrictions, attribution duties and conditions that differ from Apache-2.0 or MIT code licenses. The LlamaFirewall framework is MIT licensed, but the models it loads are governed by their own terms. Ask counsel to confirm what applies to your organization, your products and any redistribution of the model weights.
What hardware drives the cost of running these classifiers?
The main drivers are model size, context length and how many requests you classify. The Prompt Guard 2 model card lists two sizes, 86M and 22M parameters, with a 512-token context window. The 22M version, based on DeBERTa-xsmall, is described on the model card as cutting latency and compute costs by 75% with minimal performance trade-offs, which makes it a common choice for high-volume input screening. Llama Guard 4 is a 12-billion-parameter multimodal model, so it needs substantially more GPU memory and throughput planning. Benchmark both on your own instance types and traffic profile before sizing any capacity.
How long does integration take, and what does it depend on?
No duration is published for these classifiers, so the honest answer depends on your architecture. Integration effort rises with the number of entry points (chat, API, retrieval, tool calls), the amount of logging and alerting you need, and how many policies you must map to hazard categories or blocking rules. Teams with an existing inference gateway usually have less work than teams adding serving infrastructure from scratch. Ask any implementation partner for a written work breakdown that lists each integration point, test set and handover item.
Can our own engineers do this work without outside help?
Yes, if you have engineers who can deploy model servers, write evaluation datasets and tune thresholds. The models are open and the LlamaFirewall package installs with pip install llamafirewall on Python 3.10 or later, so a capable platform team can start quickly. The harder work is ongoing: building a labeled test set for your domain, measuring false positives, handling model updates and documenting the controls for auditors. If those skills are thin, a fixed-scope engagement can cover planning, integration, testing and documentation while your team keeps ownership of the running system.
What should we ask for in a fixed-scope quote?
Ask for a written scope that names each model version, each application and endpoint covered, the serving environment inside your infrastructure and the test cases used for acceptance. Request the deliverables in writing: configuration, integration code, evaluation results, runbooks, handover sessions and any documentation for compliance assessments. Confirm what is excluded, such as GPU procurement, licensing review, model retraining or ongoing monitoring. Ask how changes to scope are priced and whether ongoing support is offered as a separate retainer. DeployOpen does not publish a price list, so a quote follows from the written scope.
Primary sources for both classifiers
Start with the Purple Llama repository and the model-specific pages it links to, because these are the only references that define what each classifier does, which hazard categories or injection classes it targets, and which license governs its weights. Before you put either model in a pipeline, open the Llama Guard 4 model card and the Llama Guard 4 LICENSE together. Confirm the hazard taxonomy the card references, the input and output formats it accepts, and the context limits it documents, then have legal review the license terms against your intended use, since the license is the Llama 4 Community License Agreement and not the MIT license that covers Purple Llama's evals and Code Shield.
The Prompt Guard 2 model card is the reference for the injection and jailbreak side of the comparison. Read the Llama Prompt Guard 2 model card for the 86M version and check the 512-token context window, the benign and malicious labels it outputs, and the multilingual claim for the 86M version. The 22M variant is described in the same family of documentation, so confirm its specifics in the repository's Prompt Guard 2 directory rather than assuming they match the 86M card. Your security team should also decide who owns the threshold tuning for these labels, because the card defines the labels but not the cutoff your application should act on.
If you plan to combine these classifiers with other scanners, read the LlamaFirewall README and the LlamaFirewall LICENSE. The README explains how PromptGuard 2 is wired in as one scanner beside AlignmentCheck and CodeShield, and the LICENSE confirms that the framework itself is MIT licensed while the models it loads carry their own terms. Record the version you test against, since the README and PyPI release can move independently of the model cards, and treat any behavior not written in these pages as something to confirm with Meta's repository before you rely on it.
How DeployOpen helps choose, implement and test
DeployOpen helps teams decide between Llama Guard and Prompt Guard by first mapping which risk sits in their pipeline, then implementing the chosen safeguard inside the client's own infrastructure. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we scope
- Map where content safety and prompt attack checks would sit in your request and response path
- Define in writing which hazard categories, languages and input types the safeguard must cover
- Record the hardware, context limit and latency constraints that decide the model size
- Agree deliverables, timelines and the Llama 4 Community License review before work starts
How we build
- Deploy the chosen Llama Guard or Prompt Guard model in your cloud, data center or air-gapped network
- Wire the classifier into input and output checks, with defined block, log and escalate behavior
- Test against your own injection and jailbreak cases plus the categories your policy requires
- Document thresholds, failure handling and the runtime path so your team can operate it
How we hand over
- Deliver configuration, runbooks and test results written for your security and platform teams
- Provide evidence of each control for your compliance assessors, without issuing any audit opinion
- Walk your engineers through upgrade steps and what to re-test after a model or license change
- Confirm in writing which items remain with your team after the fixed-scope work closes
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer when your team wants it
- Re-run the test suite when you change models, such as moving between Prompt Guard sizes
- Review licensing and version changes so the deployed safeguard stays within agreed terms
- Agree the retainer scope in writing, with the quote following from the defined support needs
