Nemotron 3.5 Content Safety: A 4B Guard Model for Text and Images

Most teams start moderation with a sentence in the system prompt and discover its limits the first time a user pastes an image, switches language, or asks the model to role-play its way around the rule. A guard model is the next step: a separate, small classifier that reads the request and the response and returns a verdict your code can act on.

Nemotron 3.5 Content Safety is NVIDIA's current entry in that category. It was released on Hugging Face on 2 June 2026, it is small enough to run beside almost any main model, and it does two jobs that usually need two different guards: classifying against a fixed safety taxonomy, and judging content against a policy you write yourself.

What the model is

It is a 4B-parameter decoder-only model fine-tuned from Google's Gemma-3-4B-it. NVIDIA trained a LoRA adapter on multimodal, multilingual and reasoning-oriented safety data, then merged it back into the base weights, so you deploy one ordinary checkpoint. The vision side uses Gemma's SigLIP encoder at 896 by 896 pixels.

According to the model card it unifies two earlier NVIDIA guards: the Nemotron 3 Content Safety multimodal model and the custom-policy abilities of Nemotron Content Safety Reasoning 4B. The context window is up to 128K tokens, and the card lists twelve languages: English, Arabic, German, Spanish, French, Hindi, Japanese, Thai, Dutch, Italian, Korean and Chinese.

Each request carries a user prompt, an optional single image, an optional assistant response and an optional custom policy. The output is short, fixed-format text:

User Safety: unsafe
Response Safety: safe
Safety Categories: Illegal Activity

That format is the point. Your gateway parses three lines and branches, rather than interpreting free prose from a chat model.

Standard taxonomy or your own policy

In standard mode the model classifies against the taxonomy of NVIDIA's Aegis Content Safety Dataset V2 and, if asked, names the violated categories. With vLLM, both switches go in chat_template_kwargs:

"chat_template_kwargs": {
  "request_categories": "/categories",
  "enable_thinking": false
}

In custom policy mode you pass a custom_policy string in the same object: a name, a description, and lists of allowed and disallowed behaviour. The card's own example checks a question about cholesterol supplements against a written ethics-and-safety policy and expects a safe verdict under it. This is the mode that makes the model useful beyond generic harm detection. A tax-advice product, a children's learning app and a security research tool need very different lines, and none of them map neatly onto a fixed list of categories.

Thinking is not a free upgrade

Custom policy mode can produce a short reasoning trace inside <think> tags before the labels. It is tempting to leave that on everywhere. NVIDIA's own results suggest otherwise.

On the Dynaguardrail custom-policy set, the Safety policy scores 0.91 with thinking off and 0.86 with it on, while the Tax policy goes from 0.86 to 0.89. Neither setting wins across the board. Thinking also adds output tokens and latency to a step that sits in front of every request, which is where you least want either.

A sensible default is thinking off for standard classification, and thinking on only for custom policies where you have measured a gain on your own labelled examples.

The numbers worth reading are false positives

A guard that blocks too much fails as surely as one that blocks too little, just more quietly: users leave rather than complain. NVIDIA reports false positive rates on benchmark sets it treats as entirely safe. On MMMU the model flags 0.03 of samples, on DocVQA 0.060, and on AI2D 0.001.

Those are fractions, so 0.060 means six in a hundred harmless document questions flagged, which is a lot if your product is document Q&A. The detection side varies too. Multilingual results range from 0.97 harmful F1 on Aya Redteaming down to 0.72 on XSafety, which is a reminder that coverage across twelve languages is not uniform. Build a small set of your own safe and unsafe examples, in the languages you actually serve, and measure both directions before launch.

Wiring it into a request path

The common shape has two checks:

1. Input check. Send the user prompt, and the image if there is one, before the main model sees it. Refuse or route on an unsafe verdict.
2. Output check. Send the prompt plus the main model's response. Block, regenerate or soften on an unsafe response verdict.
3. Log both verdicts with the category, so you can tune the policy from real traffic rather than guesses.

Use near-deterministic sampling; the card's vLLM example sets temperature to 0.01 and caps output at 100 tokens. For streamed responses, decide up front whether you check before streaming starts or check chunks as they arrive, because a verdict after the user has read the answer is only useful for logging.

A guard model is one layer, not a security boundary. It will not stop a well-crafted indirect injection hidden in a retrieved document on its own; prompt injection and agent security covers the rest of the defence.

Limits, licence and alternatives

The model handles text plus one image per request, so multi-image conversations need splitting or a different guard. There is no audio or video input. The licence is OpenMDW-1.1, and because it is a Gemma derivative, Google's Gemma terms and prohibited use policy apply as well; NVIDIA states it is ready for commercial use, but read both.

OpenRouter lists it at $0.20 per million tokens for both input and output at the time of writing, plus a :free variant that is rate-limited and suited to testing rather than production traffic. Self-hosting is the more common route for a guard, since a 4B model fits comfortably on a single data-centre GPU next to the main model.

If you need a larger or text-specialised guard, compare it with the Llama Guard 4 12B guide and the gpt-oss-safeguard-20b guide. The decision rule is simple: pick Nemotron 3.5 Content Safety when you need images, many languages and custom policies from one small model, and a bigger guard only when your own false-negative tests say the small one misses too much.