Llama Guard: Meta’s Separate Moderation Model, Not a Built-In Refusal Layer

Every hosted API you have used puts a classifier in front of the model and bills you for one call. Download Llama and that classifier is not in the box, because it was never part of the model. It is a separate model, with its own weights, its own prompt format and its own GPU cost.

There is no moderation layer in the weights

This is the part that surprises people migrating from a hosted API. A Llama instruct checkpoint will decline some requests — that behaviour came from safety fine-tuning and is baked into the same weights that do everything else — but declining is not moderating. There is no classifier, no category taxonomy, no score, and nothing that returns a structured verdict your code can branch on. There is only a model that sometimes writes a refusal in prose, which your code has to detect by reading English.

And that refusal behaviour is a property of the instruct checkpoint. The base models have no instruct tuning at all, so they have no refusal disposition either; they continue text. A fine-tune on top of an instruct checkpoint can also reduce the disposition, which is not a bug in anything so much as an unavoidable consequence of the weights being yours to modify. If you need a policy decision that survives fine-tuning, it cannot live in the model being fine-tuned.

Meta’s own framing agrees: the responsible-use guidance published alongside the releases describes safeguards as a system-level responsibility of the deployer, and ships separate models to implement them. See Meta’s Llama Guard 3 model card and prompt format.

What Llama Guard actually is

Llama Guard is an LLM fine-tuned to do one job: read a conversation and say whether it is safe under a taxonomy of hazard categories. It is not a classifier head bolted onto a transformer — it is a generative model whose training makes it emit a very short, very predictable answer.

It has shipped in several generations, each built on the contemporary Llama base: the original on Llama 2 7B in December 2023, Llama Guard 2 on Llama 3 8B in April 2024, and the Llama Guard 3 family alongside Llama 3.1 and 3.2 — an 8B text model, a pruned 1B variant intended for on-device use, and an 11B vision variant that can classify prompts containing images.

Its taxonomy is prompt-supplied, which is the design decision that matters most. The categories are written into the prompt as text, so you can remove categories you do not want enforced or add your own without retraining. Llama Guard 3’s default list is built on the MLCommons hazard taxonomy and runs from S1 (violent crimes) through categories covering non-violent crime, sex-related crime, child sexual exploitation, defamation, specialised advice, privacy, intellectual property, indiscriminate weapons, hate, suicide and self-harm, sexual content, elections, and — in the 8B model — code interpreter abuse.

The output format

You send Llama Guard a prompt containing the category definitions and the conversation to be judged, and it generates one of two things:

safe

--- or ---

unsafe
S2

That is the whole output. The first line is the verdict; if it is unsafe, the second line is a comma-separated list of the violated category codes. Because it is a generative model, you should cap generation tightly — ten tokens is generous — and treat anything that is not one of those two shapes as a failure to classify rather than as a pass.

The prompt itself has a fixed structure: a task description, the numbered category block, the conversation wrapped in <BEGIN CONVERSATION> and <END CONVERSATION> markers, and an instruction stating whether the last User or Agent message is the one under review. That last detail is the one people get wrong: the same model classifies inputs and outputs, and which role it is judging is set by the prompt, not by a parameter. The tokenizer for the Llama Guard checkpoints ships a chat template that builds this correctly, and using it is strongly preferable to hand-assembly for the same reasons as the ordinary Llama 3 chat template.

Where it sits in a request

A moderated request is three model calls, not one:

1. Classify the incoming conversation with Llama Guard, with the instruction set to judge the last user message. If unsafe, stop — you never pay for the main model.
2. Call the main Llama model normally.
3. Classify the conversation again, now including the assistant reply, with the instruction set to judge the agent message. If unsafe, suppress or replace the reply.

The cost consequences are worth stating plainly, because they are the ones that get discovered late. Two extra forward passes per turn, on a model that must be resident in memory alongside your main one. The input check is cheap in tokens but adds latency before the first token of the real answer. The output check cannot start until generation has finished, which means either you do not stream, or you stream optimistically and accept that you may have to retract text a user has already read. There is no arrangement that avoids that trade; the 1B variant exists because making the check faster is the only lever.

Choosing a size and editing the taxonomy

The size decision is a latency decision more than an accuracy one, because the check sits on the critical path of every turn. The 8B model is the reference and the one Meta reports its evaluation numbers against; the pruned 1B exists so the check can run on device, or on the same GPU as a small main model without doubling the memory footprint. The 11B vision variant is the only option if the content you must classify includes images, and a text-only guard in front of a multimodal model is a gap rather than a control.

A middle path worth considering: run the cheap guard on every request and escalate to the larger one only on borderline verdicts. Because the output is generated tokens, you can read the probability of the first token — safe against unsafe — and treat a low-margin decision as a referral rather than a verdict. That turns a binary classifier into a three-way one without training anything.

Editing the taxonomy is genuinely supported, because it lives in the prompt rather than in the weights. Delete the categories your application does not need and the model stops flagging them, which reduces both false positives and input tokens. Adding a category is possible too, though it is the weaker direction: the model was fine-tuned on the published taxonomy, so a category you invent is being handled zero-shot and will be less reliable than the trained ones. Renumbering is the specific hazard — delete S5 and close the gap, and every downstream mapping of code to meaning silently shifts by one. Keep the original numbering and simply omit the definitions you do not want enforced.

What it does not do

• It does not detect prompt injection. That is a different model — Meta ships Prompt Guard for jailbreak and injected instruction detection, and a request can be perfectly safe under the hazard taxonomy while carrying an injection.
• It does not check code for vulnerabilities. Meta ships Code Shield separately for that.
• It is not a compliance artefact. It is a probabilistic classifier with false positives and false negatives in both directions, and no published accuracy figure transfers to your traffic distribution. If you need to evidence a control, you need your own evaluation on your own data.
• It does not stop your main model refusing. The two mechanisms are independent, and a request that Llama Guard passes can still be declined by the instruct model’s own tuning. That is a separate behaviour, covered in how the Llama 3 instruct models refuse.