Llama Guard 3 vs ShieldGemma vs Prompt Guard vs Granite Guardian vs WildGuard: The Open-Source Safety Classifier Showdown (2026)

**Llama Guard 3 8B** is Meta's third-generation safety classifier, fine-tuned from Llama 3.1 8B on a hazard taxonomy aligned with MLCommons. It accepts a chat-format prompt — system, user, and optionally assistant turns — and returns a structured response indicating safe or unsafe plus the violated category code (S1 through S14). It is designed to classify both user prompts and assistant responses in the same model, which makes it a one-stop sidecar for many architectures. Per the official model card at https://huggingface.co/meta-llama/Llama-Guard-3-8B, it covers 14 hazard categories including violent crimes, sexual content, hate speech, suicide and self-harm, weapons, and a notable S14 category for code-interpreter abuse.

**ShieldGemma** is Google's family of three classifiers built on Gemma 2 — the 2B, 9B, and 27B sizes available at https://huggingface.co/google/shieldgemma-2b, https://huggingface.co/google/shieldgemma-9b, and https://huggingface.co/google/shieldgemma-27b. Unlike Llama Guard's category-code output, ShieldGemma emits a Yes/No token with a confidence probability for each of four harm types: harassment, hate speech, sexually explicit, and dangerous content. You query each harm separately, which is more compute but gives you a granular score per category — useful for orgs that want to tune thresholds per harm rather than accepting a single binary decision.

**Prompt Guard 86M** is a different beast. It is not a content classifier in the LlamaGuard sense — it is a tiny DeBERTa-v3 model fine-tuned specifically to detect prompt injection and jailbreak attempts at the input layer. Per https://huggingface.co/microsoft/Prompt-Guard-86M, it returns one of three labels: BENIGN, INJECTION, or JAILBREAK. At 86M parameters it runs in milliseconds on CPU and is designed as a cheap pre-filter before you spend tokens on a heavier classifier or your main model. Originally released by Meta under the Llama 3 Community License; the Microsoft-hosted copy on Hugging Face mirrors the same weights. Treat it as a screen, not a comprehensive policy engine.

**Granite Guardian 3 8B** is IBM's enterprise-grade classifier from the Granite 3.0 family, available under Apache 2.0 at https://huggingface.co/ibm-granite/granite-guardian-3.0-8b. Its differentiator is breadth: it covers harm, social bias, jailbreak, violence, sexual content, profanity, unethical behavior, plus explicit hallucination and function-calling risk categories. It is the only model on this list that natively scores hallucination — useful if you are running a RAG application and want a single sidecar to flag both unsafe and unfaithful outputs. IBM also ships a 2B version at https://huggingface.co/ibm-granite/granite-guardian-3.0-2b for latency-sensitive deployments.

**WildGuard 7B** is Allen AI's research-grade unified safety classifier, fine-tuned from Mistral 7B and released under Apache 2.0 at https://huggingface.co/allenai/wildguard. The release is paired with the WildGuardMix training dataset and WildGuardTest benchmark, which is the unusually transparent part — most safety classifiers ship as black boxes, but Allen AI published the data so you can audit and reproduce. WildGuard scores three things in one pass: whether the user prompt is harmful, whether the model response is harmful, and whether the model refused. It is the strongest fit for research and evaluation pipelines, where reproducibility matters more than enterprise SLAs.

The marketing claim to read carefully across all six: 'state of the art on harm classification.' Every vendor claims this, every vendor benchmarks against a slightly different test set, and the comparisons are not directly apples-to-apples. The IBM model card claims Granite Guardian outperforms Llama Guard 3 on aggregate harm benchmarks per https://huggingface.co/ibm-granite/granite-guardian-3.0-8b. The Allen AI paper claims WildGuard outperforms GPT-4 on the WildGuardTest set per https://huggingface.co/allenai/wildguard. Both are true on their respective evaluations. Neither tells you what will happen on your traffic. Run your own eval before you commit.

Open-weights is not the same as Apache 2.0. **Llama Guard 3 8B** is released under the Llama 3.1 Community License, which is permissive for most commercial use but contains two clauses worth reading carefully: the 700M monthly-active-users restriction (you need a separate license from Meta if you exceed it) and the attribution requirement (you must include 'Built with Llama' notice in derivative products). Most startups will never hit the MAU threshold, but if you are inside a hyperscaler or a top-10 social platform, your legal team needs to read the full text at https://huggingface.co/meta-llama/Llama-Guard-3-8B/blob/main/LICENSE before deployment.

**ShieldGemma** is released under the Gemma Terms of Use at https://ai.google.dev/gemma/terms. This license is more restrictive than Apache 2.0 — it includes a prohibited-use policy at https://ai.google.dev/gemma/prohibited_use_policy that covers a long list of restricted applications. Critically, Google reserves the right to update the prohibited-use policy, and your continued use of the model implies acceptance of updated terms. For most teams this is fine. For teams operating in regulated industries or building products that might brush against ambiguous categories (security research, red-teaming, content moderation tooling itself), the prohibited-use policy is worth a real legal review.

**Prompt Guard 86M** sits in a slightly odd place. Meta originally released it under the Llama 3 Community License, and the Hugging Face mirror at https://huggingface.co/microsoft/Prompt-Guard-86M reflects that origin. Despite being hosted under the microsoft namespace, the license inherits from Meta. The 700M-MAU restriction technically applies, though the practical risk is low because the model is small and the use case (input filtering) is narrow. Still — verify the exact license on the model card at the moment you pull it; both Meta and Microsoft have been known to update licensing terms between model versions.

**Granite Guardian 3 8B** and the 2B sibling are released under Apache 2.0 at https://huggingface.co/ibm-granite/granite-guardian-3.0-8b — the most permissive license on this list. No use restrictions, no MAU caps, no prohibited-use policy that can change under you. For enterprise procurement, this is materially valuable. Your legal team's review of an Apache 2.0 model takes hours; their review of the Gemma or Llama license can take weeks if they have not already done it for another project. If license headache reduction is a real priority, Granite Guardian is the cleanest answer.

**WildGuard 7B** is also Apache 2.0 per https://huggingface.co/allenai/wildguard. Combined with the published training data (WildGuardMix), it is the most auditable option for organizations that need to demonstrate to regulators or customers exactly how the safety layer was trained. The trade-off is that Allen AI is a research lab, not an enterprise vendor — there is no SLA, no patch cadence, no support contract. Treat it as a strong reference implementation, not a vendor relationship.

The pragmatic license ranking for 2026 commercial deployments: Apache 2.0 (Granite Guardian, WildGuard) is the easiest legal sell, the Llama 3 Community License (Llama Guard, Prompt Guard) is fine for almost everyone except the largest platforms, and the Gemma Terms of Use (ShieldGemma) is fine if your legal team has already cleared Gemma for another project. If your legal review velocity is the bottleneck, start with the Apache 2.0 options. If your engineering team is already on a Llama or Gemma stack, the friction of staying in-family usually beats the friction of switching license families.

The standard sidecar architecture in 2026 puts a safety classifier on both sides of the main LLM call: input classification before the prompt hits your generation model, output classification before the response hits the user. **Llama Guard 3** and **Granite Guardian** support this dual-direction classification natively — you pass them a conversation including the assistant turn and they return the same structured verdict. **ShieldGemma** can do the same but you query four harm types per direction, so the call count multiplies. **Prompt Guard** only handles the input side. **WildGuard** scores prompt and response in a single call.

Latency budgets matter. A real-time chat application has roughly 300 ms of headroom for safety classification before users start noticing lag. **Prompt Guard 86M** at 3-8 ms per request on an A100 fits trivially. **ShieldGemma 2B** at 20-40 ms fits comfortably. **Llama Guard 3 8B**, **Granite Guardian 8B**, **ShieldGemma 9B**, and **WildGuard 7B** all land in the 70-160 ms range — fine as a single-direction classifier but starting to bite if you call them twice per turn. The standard pattern is to run Prompt Guard as a cheap edge pre-filter, then escalate to a bigger classifier only when the small one is uncertain or flags a category that needs nuance.

Serving stack choice is roughly as impactful as model choice. vLLM, TGI, and SGLang all support the major architectures (Llama, Gemma, Granite, Mistral) and can multiplex safety classifier requests with main inference. For a production deployment, batching is the lever — a single A100 running vLLM can serve roughly 200-400 Llama Guard 3 8B requests per second with continuous batching, versus 20-40 requests per second naive. Read https://docs.vllm.ai/en/latest/ for the canonical batching guidance before sizing your fleet.

Edge deployment changes the math. **Prompt Guard 86M** is small enough to run on CPU at single-digit milliseconds, which means you can deploy it at the API gateway layer (Cloudflare Workers AI, Vercel Edge, AWS Lambda) before any GPU request is dispatched. This is the cheapest possible architecture for input filtering — you reject obvious jailbreaks for the cost of a CPU inference, and only pay GPU cost for traffic that passes the screen. Many production teams in 2026 run Prompt Guard at the edge and Llama Guard 3 or Granite Guardian in the application tier.

Quantization is the second lever. The community has published 4-bit and 8-bit GGUF quants for every model on this list at https://huggingface.co/models?search=guard+gguf. A 4-bit quant of Llama Guard 3 8B fits in roughly 5 GB of VRAM and runs on consumer GPUs (RTX 4090, A10G), opening up dev-environment and on-prem deployments that would otherwise need datacenter hardware. Expect a 1-3 percent F1 degradation from quantization — measurable but rarely material for safety classification, where you tune thresholds anyway.

The architectural mistake to avoid: using the same model for generation and classification. Some teams have asked their main GPT-4o or Claude or Llama 3 70B model to also moderate its own output via a meta-prompt. This works for prototypes and fails at production scale because (a) the cost per moderated turn doubles, (b) you lose the ability to log moderation decisions separately for audit, and (c) the failure modes correlate — a jailbreak that compromises the generator probably also compromises the meta-prompt moderator. Use a separate, smaller, purpose-built classifier.

Every model card on this list reports favorable benchmark numbers, and every one of them is technically correct on their chosen test set. **Llama Guard 3 8B** reports F1 around 0.92 on Meta's internal hazard test set per https://huggingface.co/meta-llama/Llama-Guard-3-8B, which is competitive with the ShieldGemma family on the same categories. **ShieldGemma** reports area-under-precision-recall-curve (AU-PRC) numbers favorable versus the original LlamaGuard 1 baseline per https://huggingface.co/google/shieldgemma-2b. **Granite Guardian 3 8B** reports outperforming Llama Guard 3 on aggregate harm benchmarks per https://huggingface.co/ibm-granite/granite-guardian-3.0-8b.

**WildGuard 7B** is the most transparent benchmark story — the WildGuardTest evaluation set is publicly available and the WildGuard paper at https://arxiv.org/abs/2406.18495 reports outperforming GPT-4 on adversarial prompts. This is meaningful, but the test set is itself a research artifact, and adversarial prompts are a fast-moving target. A classifier that wins on 2024-era jailbreaks may struggle on 2026-era ones, and vice versa. Treat published benchmark wins as a directional signal, not a guarantee.

**Prompt Guard 86M** reports better than 92 percent jailbreak detection accuracy per https://huggingface.co/microsoft/Prompt-Guard-86M. This number is real but contextual — it is measured on a curated test set, and real-world jailbreaks include novel techniques (e.g., translation-based attacks, base64 encoding, role-play wrappers) where the model is less reliable. Use Prompt Guard as a high-recall first-line filter, then accept that some attacks will pass through to deeper classification.

The published research worth reading before committing to a model: the Llama Guard paper at https://arxiv.org/abs/2312.06674 (original LlamaGuard), the ShieldGemma technical report at https://arxiv.org/abs/2407.21772, the WildGuard paper at https://arxiv.org/abs/2406.18495, and the IBM Granite Guardian report at https://arxiv.org/abs/2412.07724. Each describes methodology and limitations honestly enough that you can form an opinion before you deploy.

An MLPerf-style standardized safety benchmark does not yet exist as of June 2026. The closest thing is the MLCommons AI Safety v0.5 benchmark suite at https://mlcommons.org/benchmarks/ai-safety/, which is the hazard taxonomy Llama Guard 3 aligns to. Until a v1 with broader vendor participation lands, cross-vendor benchmark comparisons are best treated as suggestive. The OpenAI Moderation API and Azure Content Safety are notably absent from open benchmarks because they are closed-weights — direct comparison requires building your own eval harness on traffic you control.

The correct posture in 2026: pick two models from this list, build a 1,000-prompt evaluation set drawn from your actual application traffic plus public adversarial prompts (Anthropic's HH-RLHF red-team subset at https://huggingface.co/datasets/Anthropic/hh-rlhf is a reasonable starting point), and measure precision and recall on your data. Vendor benchmarks tell you the model can perform; your own eval tells you it will perform for your use case. Budget a real engineering week for this work — it is the single most valuable thing you will do before signing up to operate a safety sidecar in production.

If you are already running Llama 3 inference and you want a safety sidecar that aligns to MLCommons hazard categories with the broadest language coverage, deploy **Llama Guard 3 8B**. The 14-category taxonomy maps cleanly to most enterprise content policies, the multilingual support (EN, FR, DE, HI, IT, PT, ES, TH) is the best on this list, and the dual-direction prompt+response classification simplifies the architecture. Verify the model card at https://huggingface.co/meta-llama/Llama-Guard-3-8B before deployment. For latency-sensitive paths, swap in Llama Guard 3 1B from https://huggingface.co/meta-llama/Llama-Guard-3-1B.

If you want per-category confidence scores so you can tune thresholds independently for harassment, hate, sexual, and dangerous content — and you are already on a Gemma stack — deploy **ShieldGemma 9B**. The 9B size is the sweet spot for accuracy; the 2B variant is the right pick when latency dominates and you are willing to trade some precision. Both are documented at https://huggingface.co/google/shieldgemma-9b and https://huggingface.co/google/shieldgemma-2b. ShieldGemma 27B at https://huggingface.co/google/shieldgemma-27b exists but the marginal accuracy over 9B rarely justifies the GPU cost.

If you need to detect prompt injection and jailbreak attempts cheaply at the edge before any GPU inference fires, deploy **Prompt Guard 86M**. It is the only model on this list that is small enough to run on CPU at single-digit milliseconds, which makes it the right choice for the input-layer screen in front of your main LLM. Pair it with a heavier classifier downstream — Prompt Guard is a screen, not a complete policy. Model card at https://huggingface.co/microsoft/Prompt-Guard-86M.

If you are an enterprise that needs an Apache 2.0 license, broad category coverage including hallucination detection, and the option of a 2B-or-8B size choice within one family, deploy **Granite Guardian 3 8B** for accuracy or **Granite Guardian 3 2B** for latency. The hallucination category is a real differentiator for RAG applications — no other open-source safety classifier on this list scores faithfulness natively. Model cards at https://huggingface.co/ibm-granite/granite-guardian-3.0-8b and https://huggingface.co/ibm-granite/granite-guardian-3.0-2b.

If you are running a research or evaluation pipeline where reproducibility and auditability matter more than vendor SLAs, deploy **WildGuard 7B**. The published training data and benchmark set let you trace every classification decision back to a transparent dataset. It is the right pick for academic work, regulator-facing audits, and red-team evaluation harnesses. For pure production use cases, the other options have more deployment polish. Model card at https://huggingface.co/allenai/wildguard.

The honest worst-case scenario: most teams in 2026 should run two classifiers in series, not one. Prompt Guard 86M at the edge for cheap input screening, then Llama Guard 3 8B or Granite Guardian 8B in the application tier for full prompt+response classification. This costs roughly 20 percent more inference than a single classifier but materially improves both latency (cheap reject path) and precision (specialized models for specialized jobs). Skipping the edge screen and running an 8B classifier on every turn is the most common over-spend pattern.

Some teams ask whether they should skip the open-source classifier route and use OpenAI's Moderation API at https://platform.openai.com/docs/guides/moderation, Azure AI Content Safety at https://azure.microsoft.com/en-us/products/ai-services/ai-content-safety, AWS Bedrock Guardrails at https://aws.amazon.com/bedrock/guardrails/, or Anthropic's built-in safety features documented at https://www.anthropic.com/safety. For most low-volume early-stage applications, the answer is yes — managed APIs are zero-ops, well-supported, and the per-request cost is often cheaper than running your own GPU when traffic is sparse.

The math flips at scale. OpenAI's Moderation API is free for OpenAI customers at the time of writing, but it only classifies content against OpenAI's content policy — which may not match your product policy. Azure AI Content Safety is priced per 1,000 text records (verify at https://azure.microsoft.com/en-us/pricing/details/cognitive-services/content-safety/) and the cost adds up fast in high-volume chat applications. AWS Bedrock Guardrails is priced per 1,000 text units (verify at https://aws.amazon.com/bedrock/pricing/). For a 50,000-DAU chat app with 20 turns per session, you are looking at 1M+ moderation calls per day; the managed API bill can easily exceed the GPU cost of a self-hosted Llama Guard 3 deployment.

Policy customization is the other lever. Managed APIs ship with fixed categories. **Llama Guard 3** can be fine-tuned on your specific policy categories using the recipe at https://github.com/meta-llama/llama-cookbook/tree/main/recipes/responsible_ai. **ShieldGemma** supports custom-policy prompting where you pass the harm definition at inference time. **Granite Guardian** supports both fine-tuning and prompted policies. If your content policy includes categories that do not map to vendor defaults — say, brand-specific prohibited mentions, regulated-industry disclosure rules, or platform-specific norms — open-source customization is meaningfully better than trying to bend a managed API.

Latency is the third lever. Round-tripping every chat turn to a managed safety API adds 50-200 ms of network latency on top of inference. Self-hosting the classifier in the same VPC or on the same GPU node as your main LLM eliminates that round-trip. For real-time voice or low-latency chat use cases, the architectural simplicity of co-located inference often outweighs the operational complexity of running open weights. Verify with your specific provider — Cloudflare's hosted Llama Guard at https://developers.cloudflare.com/workers-ai/models/ runs at edge and can be faster than OpenAI Moderation from many regions.

The hybrid pattern that works in 2026: use a managed API for your first 100,000 monthly requests while you validate your policy and traffic shape, then migrate to a self-hosted open-source classifier once volume and category-specificity justify the engineering work. Most teams that try to skip the managed-API phase end up under-investing in their own evaluation harness and ship a worse classifier than the managed alternative.

The bottom line on build-vs-buy: managed APIs are the right starting point for sub-100k monthly request volumes, custom-policy products at any volume should run open-source classifiers with fine-tuning, and very high-volume products (10M+ monthly requests) almost always end up running their own infrastructure regardless of where they started. If you are evaluating the per-token economics, the OpenAI API cost calculator handles the moderation-call math alongside your generation costs.

Days 1 to 10: pick a model and stand up inference. Pull either Llama Guard 3 8B, Granite Guardian 8B, or ShieldGemma 9B onto a development GPU (an A10G or single A100 is sufficient for testing). Serve it with vLLM or TGI behind a basic HTTP endpoint. Send a curl request, verify you get a structured classification back. Most teams underestimate this step — getting a vLLM container running with the right flash-attention version and correctly-sized KV cache takes a real day, not an hour. Reference the vLLM quickstart at https://docs.vllm.ai/en/latest/getting_started/quickstart.html.

Days 11 to 25: build the evaluation harness. Assemble a 1,000-prompt test set drawn from your application traffic (anonymized), plus public adversarial sets like the Anthropic HH-RLHF red-team subset, plus your custom policy violations. Score precision and recall by category on your candidate classifier. Compare against the OpenAI Moderation API as a baseline — even if you do not plan to use it in production, it is a useful reference. Document the failure modes — Llama Guard's specific weaknesses on translation-based attacks, ShieldGemma's high false-positive rate on benign sexual-health content, etc. — so you can decide on fine-tuning scope.

Days 26 to 45: wire into the application. Add the classifier as a sidecar call in your request handler — typically a pre-classifier on the user prompt, then a post-classifier on the model response. Decide on the action policy for each verdict (block, redact, escalate to human review, log only). Add structured logging of every classification decision with the prompt hash, classifier verdict, action taken, and timestamp — these logs are critical both for ongoing tuning and for any future audit. Build a small ops dashboard so you can see classification volume, block rate, and category distribution at a glance.

Days 46 to 65: run a shadow deployment. Mirror live production traffic to the classifier without acting on the verdicts. Compare the classifier's decisions to current production behavior (which may be no moderation, or a different model). Identify the categories where the new classifier disagrees with your current behavior and triage them — some disagreements will be the new classifier catching real harms, some will be false positives that need threshold tuning or category-specific exemptions. This step is the single biggest determinant of launch success or failure.

Days 66 to 80: progressive rollout. Enable the classifier for 1 percent of traffic with full blocking action. Monitor false-positive complaints and user-facing errors. Ramp to 10 percent at day 70, 50 percent at day 75, 100 percent at day 80 if metrics hold. Keep the kill switch trivially accessible — every safety sidecar deployment in production should have a single-flag bypass for the case where the classifier itself misbehaves. Operationally, the classifier is a critical-path dependency; treat it like one.

Days 81 to 90: tune and document. Review classification logs from full rollout, identify the highest-volume false positives and false negatives, decide whether to retune thresholds, fine-tune the model on a custom dataset, or accept the current performance. Document the deployment architecture, the eval results, the rollout playbook, and the kill-switch procedure for the on-call team. The classifier is now a production system — it needs an owner, a runbook, and a quarterly review cadence. The teams that skip this last step end up with a classifier that nobody updates while jailbreak techniques evolve underneath them.

If I were architecting a new LLM application tomorrow with a real budget and a real platform team, I would deploy **Prompt Guard 86M** at the edge plus **Llama Guard 3 8B** in the application tier. Prompt Guard catches the cheap obvious attacks for the cost of a CPU inference; Llama Guard handles the full policy classification on the traffic that passes the screen. The combined latency is roughly 100-160 ms per moderated turn, the GPU footprint is modest, and the MLCommons-aligned hazard categories are the easiest sell to a security or trust-and-safety leader who needs to explain the architecture upstream. Verify both at https://huggingface.co/microsoft/Prompt-Guard-86M and https://huggingface.co/meta-llama/Llama-Guard-3-8B.

If license headache is the dominant constraint — for instance, you are inside a regulated industry, your legal team has not approved either the Llama 3 Community License or the Gemma Terms of Use, and you cannot afford a 6-week procurement cycle — I would deploy **Granite Guardian 3 8B** under Apache 2.0 plus a fine-tuned version of the 2B for latency-sensitive paths. The added bonus is the built-in hallucination category, which is the right architecture if you are running RAG anywhere in the stack. Model cards at https://huggingface.co/ibm-granite/granite-guardian-3.0-8b and https://huggingface.co/ibm-granite/granite-guardian-3.0-2b.

If I were already heavily invested in the Google ecosystem — running Vertex AI, building on Gemma 2, using Google Cloud as the primary platform — I would deploy **ShieldGemma 9B** plus Prompt Guard 86M at the edge. Staying within the Gemma family reduces operational variance, and the per-category confidence scores are genuinely useful for products where you want to tune harassment thresholds differently from sexual-content thresholds. Verify ShieldGemma at https://huggingface.co/google/shieldgemma-9b and the Gemma terms at https://ai.google.dev/gemma/terms before commit.

If I were running a research lab, an evaluation harness, or anything that will face external audit — academic publication, government regulator, customer security review — I would deploy **WildGuard 7B** as the primary classifier. The published training data is the differentiator no other model on this list offers, and it is the only one where you can credibly answer the question 'show me the data this model was trained on' without a vendor NDA. Model card at https://huggingface.co/allenai/wildguard. Pair with a heavier production classifier if you also need enterprise-grade latency.

The one configuration I would actively avoid in 2026 is running a single classifier on every chat turn without a cheap pre-filter. Spending an 8B GPU inference on every benign 'what is the capital of France' prompt is wasteful and noticeably degrades the end-user latency on the long-tail of slow requests. The Prompt-Guard-at-edge pattern is essentially free engineering effort for a measurable latency improvement and a meaningful GPU-cost reduction at scale. If you remember one architectural principle from this article, that is the one.

The other thing I would not do is treat 'safety classifier' and 'content moderation' as a solved problem because you deployed one of these models. The model is a tool. The policy decisions — what counts as harmful, how to handle false positives, how to escalate edge cases — are the actual work, and they are organizational decisions that no open-source model can make for you. Deploy the classifier, then invest the same engineering effort in the human policy and review workflow on top. The classifier without the policy is a liability; the policy without the classifier is too expensive to operate at scale. You need both.