Should you move from Llama Guard 3 to Llama Guard 4?
Move to Llama Guard 4 when you need one classifier for both prompts and responses, and when image inputs matter to your pipeline. Llama Guard 4 is a single 12-billion-parameter multimodal model that replaces both Llama Guard 3-8B and Llama Guard 3-11B-vision, and it classifies prompts and responses against the MLCommons hazards taxonomy. If your team currently runs two Llama Guard 3 models, or routes image content to a text-only classifier, consolidating onto one model removes that split. Staying on Llama Guard 3 can be the right call when your current deployment is stable, your traffic is text-only, and the Llama 3.2 license terms already fit your organization.
The license change belongs in the decision from the start. Llama Guard 3 is covered by the Llama 3.2 Community License, while Llama Guard 4 ships under the Llama 4 Community License Agreement. These are separate license texts with their own terms, so moving means your legal and procurement reviewers must read the Llama 4 terms against your intended use, redistribution and hosting model, not assume the older terms carry over. Check the Llama Guard 4 LICENSE before you commit engineering time, and record the decision and its date so auditors can see which terms governed each deployment.
Before you schedule the cutover, inventory which Llama Guard version runs in production, which stage of the pipeline calls it, and whether it ever receives images. Then confirm what the Llama Guard 4 model card says about multi-image input, hardware requirements and the hazard categories your policies map to, rather than assuming parity with the 3-series. Run both models against a labeled sample of your own prompts and responses to compare false positives and misses on your traffic. Keep the Llama Guard 3 deployment in place until those results and the license review are both signed off. The Llama Guard 4 model card is the natural next read for the technical checks.
What changes in capability between Llama Guard 3 and Llama Guard 4
This table sets Llama Guard 4 against the Llama Guard 3 models in the areas where the supplied facts support a direct comparison. Where a Llama Guard 3 value depends on its model card, the cell says so, so you can confirm it before you plan a migration.
| Capability | Llama Guard 3 (8B or 11B-vision) | Llama Guard 4 (12B) |
|---|---|---|
| Model count | Two separate models: 3-8B and 3-11B-vision | One model replaces both 3-8B and 3-11B-vision |
| Parameter size | 8B for the text model, 11B for the vision model | 12 billion parameters |
| Input modality | Text for 3-8B, text and image for 3-11B-vision. Confirm multi-image support on the 3-11B-vision model card | Multimodal input. Confirm multi-image handling on the Llama Guard 4 model card |
| Classification target | Prompts and responses. Confirm the exact input and output roles on each model card | Classifies both prompts and responses |
| Hazard taxonomy | Confirm the hazard category list on the Llama Guard 3 model card before comparing | Classifies against the MLCommons hazards taxonomy. Check the category IDs in the model card |
| Origin | Built as a Llama 3 family safety classifier. Confirm the base model on its model card | Pruned from Llama 4 Scout |
| License family | Llama 3.2 Community License | Llama 4 Community License Agreement |
Which Llama Guard setup fits your environment
If your application only exchanges text, the main change from Llama Guard 3 is consolidation. Llama Guard 4 classifies both prompts and responses against the MLCommons hazards taxonomy in a single model, so you no longer need to choose between the 8B text model and the 11B vision model for different routes. The decision then rests on whether a 12B classifier fits your serving budget, since it is larger than the 8B model it replaces for text workloads.
- One model for both directions: Run input and output checks through the same classifier instead of maintaining routing logic between two Llama Guard 3 variants.
- Size change: Llama Guard 4 is a 12-billion-parameter model pruned from Llama 4 Scout, so expect higher memory and compute needs than Llama Guard 3-8B for text-only traffic.
- Taxonomy alignment: Both versions use hazard categories, so confirm that the Llama Guard 4 categories match the policy categories your moderation team already uses.
- License change: Llama Guard 4 ships under the Llama 4 Community License Agreement, while Llama Guard 3 used the Llama 3.2 Community License. Have legal review both before upgrading.
Before choosing, measure a 12B classifier on your own hardware against your p95 latency target and confirm the license terms with your counsel.
If users upload images or your pipeline ingests scanned documents, Llama Guard 4 is the version that accepts multimodal input and multiple images in one classification. Llama Guard 3-11B-vision covered images, but it was a separate model from the text-only 8B, so teams running both had two classifiers to deploy, monitor and update. A single multimodal model simplifies the architecture, but image inputs add tokens and memory pressure that text-only routes do not.
- Single multimodal model: One deployment covers text and image prompts and responses, replacing the 8B and 11B-vision pair.
- Multi-image support: Llama Guard 4 can classify more than one image in a request, which matters for document bundles or multi-photo uploads.
- Input volume: Image-heavy traffic raises per-request compute, so the 12B size shows up more in throughput than in text-only routes.
- Hazard coverage for images: Test the hazard categories against your own sample set of images, including edge cases your moderation policy cares about.
Before choosing, build a test set of representative images and documents, run them through the model in your environment and record accuracy, latency and GPU memory use.
In air-gapped networks or on fixed GPU allocations, the question is whether the 12B model can be loaded, served and updated entirely inside your boundary. Model weights, serving software and license records must all be transferred through your approved process, and there is no external API to absorb overload. If your hardware cannot host the 12B model with headroom, you may need to keep Llama Guard 3 running for a period, or evaluate a smaller classifier from the same safeguards family for specific checks.
- Memory footprint: Confirm available GPU memory for the 12B weights plus the KV cache at your expected context and batch sizes.
- Serving stack: Verify that your inference server supports the model format and multimodal inputs you need, and test it offline.
- Update path: Plan how new model versions and license-relevant notices reach the isolated network, since updates are manual transfers.
- Fallback design: Decide what happens when the classifier is unavailable, whether requests are blocked, queued or passed with logging.
Before choosing, ask your platform team to benchmark the model on the exact hardware class, and confirm the serving stack and update process with DeployOpen or your internal change board.
How the license moves from the Llama 3.2 to the Llama 4 Community License
Llama Guard 3 and Llama Guard 4 do not ship under the same license, so a version change is also a legal change. The four cards separate the two license families, the MIT terms that cover Purple Llama's evals and Code Shield, and the questions to settle before production. Read each license text directly before relying on any summary.
Llama Guard 3 license terms
Llama Guard 3 models are covered by the Llama 3.2 Community License, according to the PurpleLlama license table. Teams running Llama Guard 3-8B or 3-11B-vision today should locate that license in their deployment record and confirm which copy they accepted. If you plan to migrate, do not assume the terms carry over unchanged. Compare acceptable use, attribution, redistribution and any user or revenue thresholds in the Llama 3.2 text.
Llama Guard 4 license terms
Llama Guard 4, the 12B multimodal classifier, ships under the Llama 4 Community License Agreement, according to the LICENSE files in the PurpleLlama repository. This is a different document from the Llama 3.2 license, so a migration changes the governing terms along with the model. Read the Llama 4 text for acceptable use, attribution, redistribution and thresholds, and compare each clause against the Llama 3.2 text your team has already accepted.
MIT terms cover the code
MIT terms cover Purple Llama's evals, benchmarks and Code Shield, while its models use the matching Llama Community License. Teams that pull code from the repository and model files from elsewhere should treat them as separate licensing decisions. Confirm the LICENSE file in the folder you deploy, since a repository-level notice does not establish the terms that govern the Llama Guard weights.
Questions for legal counsel
Counsel should review both license texts before go-live. Ask them to confirm acceptable use for your sector and use case, attribution duties, redistribution rights, and any user or revenue thresholds the text sets. Also ask whether hosting the model inside your own cloud account, or giving a implementation partner access to it, creates redistribution questions. Record the answers with the license version and date so the decision can be reviewed at upgrade time.
What a 12B classifier asks of your infrastructure
Moving to Llama Guard 4 changes the hardware question mainly through memory for weights. The model is a single 12-billion-parameter classifier pruned from Llama 4 Scout, and it stands in for both the 8B text model and the 11B vision model. Weights must fit in accelerator memory at the precision you deploy, so the footprint depends on parameter count, numeric format, and whether you keep one guard model resident or two. If your current pipeline loads both Llama Guard 3 variants, consolidating may reduce the number of resident models even though the new one is larger. Ask your platform team to calculate the resident footprint for each option at the precision you intend to serve, and confirm the supported precisions on the Llama Guard 4 model card.
Throughput is the second driver, and it often matters as much as the weight count. Llama Guard runs on every incoming prompt and every outgoing response, so each user turn adds two classification passes to the latency budget. A larger model takes longer per pass, and at peak concurrency the queue of guard calls can grow faster than the chat model's own calls. Measure time to verdict separately for prompts and responses, at the batch sizes and concurrency your gateway will use, and record the 95th percentile rather than relying on averages. Run the same test against your current Llama Guard 3 deployment so the comparison reflects your traffic mix and your serving stack.
Image handling is the third driver and applies only if images are in scope. Llama Guard 4 supports multiple images, so one request can carry more visual input than the 11B vision model was built to classify. Each image is converted into model inputs before the classifier evaluates it, which means preprocessing cost grows with the number and size of images and runs on the same serving path. Decide the maximum image count and resolution your product accepts, then test with the largest inputs it allows. Ask the model card and your platform team for the image handling figures that apply to your configuration, and confirm where your serving framework performs preprocessing.
What moving to Llama Guard 4 costs in compute, licensing review and engineering time
This table lists the cost components of moving from Llama Guard 3 to Llama Guard 4, who is paid for each, whether it is one-time or recurring, and what moves it up or down. No price is published for the model itself, so the compute and labor lines depend on your environment and the scope agreed with any partner. Use the quote checklist below the table to make bids comparable.
| Cost component | Who is paid or who carries it | One-time or recurring | What drives it up or down |
|---|---|---|---|
| Model licensing review | Internal legal and compliance team, possibly outside counsel | One-time per license change, then periodic review | Llama 4 Community License terms differ from the Llama 3.2 Community License used by Llama Guard 3, so counsel must compare obligations for your use case. Fewer downstream products and simpler deployment patterns shorten review. |
| Compute to host the 12B model | Your cloud provider, data center operator or hardware vendor; internal platform team for capacity planning | Recurring (hosting), plus one-time capacity testing | Llama Guard 4 is a 12-billion-parameter multimodal model, so GPU memory and throughput needs differ from the 8B text model and the 11B vision model it replaces. Confirm sizing with the vendor or in a load test against your own traffic and image volume. |
| Re-validation of prompts and labels | Internal safety or trust team; implementation partner if engaged on a fixed scope | One-time per migration, with periodic regression runs | Llama Guard 4 classifies against the MLCommons hazards taxonomy, so existing category mappings, thresholds and policy documents must be checked. Larger numbers of custom policies and multi-image test sets increase effort. |
| Pipeline and integration changes | Internal platform or application engineering; partner for scoped integration work | One-time, with recurring maintenance when model versions change | Changes to input formats for multi-image requests, response parsing and logging all touch the pipeline. Keeping the model behind a stable internal interface reduces the number of services that need edits. |
| Ongoing monitoring of labels and drift | Internal security operations or ML operations team; optional retainer with a partner | Recurring | Volume of prompts and responses reviewed, the number of hazard categories you act on, and whether you sample human review. Alerting and dashboards already in place lower the added effort. |
How to migrate a Llama Guard 3 deployment to Llama Guard 4
This sequence moves a team from Llama Guard 3-8B or 3-11B-vision to the single 12B Llama Guard 4 with a documented inventory, a license review, a tested comparison of decisions and a cutover that can be reversed. Each step produces an artifact that the next one depends on.
Inventory every guard call and the labels it acts on
The application or platform engineering team lists each place where a Llama Guard 3 call runs, including whether it checks user prompts, model responses or both, and which hazard category codes the code branches on, logs or displays. Include any image inputs sent to the 3-11B-vision variant, since Llama Guard 4 is the model that handles both text and images in one classifier. The step is done when the team has a written table of call sites, inputs, outputs and downstream actions that a reviewer has signed off on.
Map current labels to the hazard taxonomy
The security engineer compares the category codes in the inventory against the MLCommons hazards taxonomy that the Llama Guard 4 model card describes, and records any category that has no clear equivalent, is renamed or is split. Confirm the exact category list, label format and any changes to response output directly in the Llama Guard 4 model card before writing mapping rules. The step closes with a mapping document that lists each old label, its new counterpart and any label the team must handle as an exception.
Review the Llama 4 Community License with counsel
Legal and procurement review the Llama 4 Community License Agreement that ships with Llama Guard 4, which differs from the Llama 3.2 Community License that covers Llama Guard 3 and Prompt Guard. Counsel should check the terms against the organization's intended use, redistribution, hosting and any downstream products that embed the model, and record the decision. The step is done when a written approval or a list of open conditions is on file, with the license text version the team relied on.
Stand up Llama Guard 4 in a non-production environment
The platform team deploys Llama Guard 4 in a staging environment that mirrors production networking, identity and logging, using the hardware the team has confirmed against the model card and its own serving stack. Keep the Llama Guard 3 endpoint running alongside it so both models see identical traffic in later steps. The step is done when both classifiers answer a fixed set of smoke-test prompts and the team has recorded the latency, memory use and failure behavior it observed.
Run a labeled evaluation set with text and images
The evaluation owner builds a labeled dataset from real application traffic that has been reviewed for sensitivity, covering prompts and responses in text and, where the application accepts them, image inputs that Llama Guard 3-11B-vision handled before. Each item gets a human label for expected hazard category and block or allow outcome. The step is done when the dataset is versioned, its label guidelines are written down, and the reviewers have agreed the labels on a sample. Illustrative example: a team might find that image-only prompts were never checked in the text-only Llama Guard 3-8B path, which the dataset should surface.
Compare block and allow decisions against Llama Guard 3
The evaluation owner runs the labeled dataset through both models and tabulates agreement, false blocks, missed hazards and category changes, with the results broken down by text, image and mixed inputs. Review every disagreement with the mapping document from the second step so that taxonomy differences are not mistaken for model errors. The step closes with a signed comparison report that states which thresholds are acceptable to the business owner and which cases need a rule change before cutover.
Cut over with a rollback path and monitoring
The platform team switches production traffic to Llama Guard 4 in a controlled change, keeping the Llama Guard 3 endpoint and its configuration available so traffic can return to it without a new deployment. Add dashboards for block rate, category distribution and classifier errors, with alerts agreed with the security operations team before the switch. The step is done when a documented rollback test has passed in staging, the monitoring is live, and the first production review of decisions has been completed and recorded.
How to validate label changes before cutover
A model swap changes application behavior even when the category names stay the same. Llama Guard 3 and Llama Guard 4 both use hazard categories drawn from the MLCommons hazards taxonomy, but two classifiers trained differently will draw the boundary between a borderline request and a violation in different places. Llama Guard 4 also classifies both prompts and responses, so a message that was previously passed through unlabeled may now be flagged, and a response that was previously blocked may now pass. Treat the cutover as a change to a control, not a dependency upgrade. Before you change the model identifier in production, confirm which hazard codes your policy and logging depend on, and map each one to the Llama Guard 3 variant you are replacing (8B or 11B-vision).
Build the validation set from traffic you are permitted to use. Start with a sample of real prompts and responses from your application that your data governance and privacy owners have approved for testing, with personal data removed or tokenized. Add known-bad cases from your own red team exercises and your incident history. Run every item through both the current and the candidate classifier with the same prompt template and settings, then record each disagreement with the input, both labels, both scores where your serving stack exposes them, and the category that changed. Keep the record format identical across runs so later reviews can compare them. A short illustrative sample of a few hundred items will not show rare categories, so ask your evaluation owner to state how coverage was chosen and which categories were under-sampled.
Decide in advance which changes need policy sign-off. A reasonable rule is that any flip from safe to unsafe on a blocking control, any change in a category your policy names explicitly, and any change in how responses are handled require approval from the policy owner before cutover, while cosmetic differences in label wording do not. Keep the approval, the reviewer, the date and the model build in the same record. For audit preparation, retain the test set version, the run logs, the disagreement register and the sign-off decisions together, and say plainly that this evidence supports your own assessment. It does not amount to a certification, and independent auditors decide what they accept. Confirm the license obligations for Llama Guard 4 under the Llama 4 Community License Agreement with your legal team before you deploy it.
Llama Guard 4 migration questions buyers ask before hiring help
What does a Llama Guard 4 migration cost and what drives the price?
The cost depends on the written scope, so no single figure applies to every team. The main components are engineering time to swap the classifier into your serving path, evaluation work to confirm its decisions on your own traffic, and the compute the model runs on. Migration and test setup are one-time costs. Serving infrastructure, license review and any retainer for upgrades recur. Request volume, the number of hazard categories in your policy, and whether you run prompts and responses through the classifier all push the cost up or down. DeployOpen does not publish a price list, and a quote follows from a written scope. Ask any provider to split the quote into migration, validation, handover and ongoing support, and to state which items recur each year.
How long does Llama Guard 4 validation take and what sets that duration?
No validation duration can be stated from the sources available, so confirm it against your own traffic and policy. Validation length is set by how many hazard categories your policy uses, how much labeled traffic you can replay, how many languages your users write in, and how much review your safety owners need. Llama Guard 4 classifies prompts and responses against the MLCommons hazards taxonomy, so your current Llama Guard 3 policy mapping needs a check against those categories before any comparison is meaningful. Because the model is multimodal, image inputs add test cases if your product accepts them. Ask for a timeline tied to a written test plan with named acceptance criteria.
What must our team provide before a Llama Guard 4 migration starts?
Three inputs decide how quickly the work moves: labeled data, policy owners and serving access.
- Labeled data: a representative set of prompts and responses with reviewed labels, ideally including cases your current Llama Guard 3 deployment got wrong.
- Policy owners: named people who decide which hazard categories block, warn or only log, and who sign off on changes.
- Serving access: GPU capacity, network paths from your gateway or application, and permission to deploy and roll back the model.
Missing any of these usually shows up as validation delay. Confirm each item with your provider in writing before the scope is signed.
Can an internal team migrate to Llama Guard 4 without outside help?
Yes, if the team already runs model serving, owns a labeled evaluation set and has someone who can read the license carefully. The model card and license are published in the PurpleLlama repository, so the technical swap is within reach of a capable platform team. The harder parts are designing validation, managing change control for a safety control and keeping the evidence trail. An outside firm helps most when those parts are new to your organization. DeployOpen plans, implements, integrates, hardens and documents self-hosted deployments inside the client's own infrastructure under a fixed scope agreed in writing. Compare internal hours against that scope, and decide who will own the classifier after handover.
What changes in the license when moving from Llama Guard 3 to Llama Guard 4?
Llama Guard 4 ships under the Llama 4 Community License Agreement, while Llama Guard 3 uses the Llama 3.2 Community License. The terms that apply to you come from the license attached to the exact version you deploy, so read both texts rather than relying on a summary. Check acceptable use terms, attribution and naming obligations, redistribution rules and any scale-related terms. This is a question for your legal team. DeployOpen does not give legal advice and does not issue certifications. Confirm the current license file for each model in the PurpleLlama repository, and record which version and license text your approvers reviewed.
Does Llama Guard 4 replace Prompt Guard for prompt injection?
No. Llama Guard 4 classifies prompts and responses against hazard categories, while Prompt Guard 2 labels prompts as benign or malicious to detect injection and jailbreak attempts. Prompt Guard 2 comes in 86M and 22M parameter versions with a 512-token context window. Pipelines that need both content safety and injection screening usually run both, and each sits at a different point in the flow. Migrating to Llama Guard 4 is a change to the hazard classifier only, so keep your injection control in place unless your own testing shows a reason to change it. For sizes, context limits and placement, read the sibling comparison, Llama Guard vs Prompt Guard.
What hardware does Llama Guard 4 need to run in production?
The supplied sources give the parameter count, 12 billion, but no minimum GPU, memory or throughput figure, so confirm sizing against the model card and your own load tests. Parameter count is the starting point because it drives the memory the weights need at serving time. Your actual hardware bill depends on request volume, concurrency, latency targets and whether prompts and responses both pass through the classifier. Llama Guard 4 is pruned from Llama 4 Scout and replaces both Llama Guard 3 models in one deployment, which may simplify operations, but it does not mean one GPU suits every team. Ask your provider for a sizing worksheet with its assumptions written down, and rerun it with your peak load.
How DeployOpen scopes and delivers a Llama Guard migration
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Llama Guard move, we start from the classifier calls your application already makes, then agree in writing what changes in the Llama 4 Community License review, the hardware and the test evidence before any work begins.
How we scope
- Inventory every place your application calls Llama Guard 3-8B or 3-11B-vision, including prompt-side and response-side checks.
- Record which hazard categories your policies rely on and map them to the MLCommons taxonomy used by Llama Guard 4.
- Confirm the target hardware, serving environment and whether any multi-image inputs need coverage in the written scope.
How we build
- Stand up Llama Guard 4 in your own cloud account, data center or air-gapped network, with the model served where your data already lives.
- Update classifier integration, prompt templates and threshold handling so the new model's outputs feed your existing guardrail logic.
- Run a regression suite of your own prompts and responses against Llama Guard 3 and Llama Guard 4 to document where verdicts differ.
How we hand over
- Deliver written documentation of the scoped configuration, deployment steps, rollback path and known verdict differences.
- Provide a record of the license terms that apply to each model version, so your legal and procurement teams review the same text.
- Hand over test results and configuration evidence in a form your compliance assessors and internal reviewers can inspect independently.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope migration closes.
- Re-run the regression suite when Meta releases new safeguard models or when your hazard policies change.
- Confirm with your team which owner signs off on classifier changes, since DeployOpen prepares evidence but does not issue audit reports or certifications.
