Qwen3Guard Technical Report

🎯 Pitch

A 0.6B guard model rivals ones 10× larger, and by introducing a “controversial” label alongside safe/unsafe, Qwen3Guard captures the policy inconsistency that makes binary models fail. It also ships a stream-capable variant that flags harmful content token-by-token during generation, dropping only ~2 F1 points from the full-response version.

1. Executive Summary

This paper introduces Qwen3Guard, a family of multilingual safety guardrail models that addresses two critical limitations of existing guard models — inconsistent binary safe/unsafe classifications across safety policies and incompatibility with streaming LLM inference — through two specialized variants trained on the Qwen3 foundation models. Generative Qwen3Guard casts safety classification as an instruction-following task, introducing a tri-class judgment scheme (safe, controversial, unsafe) that enables adaptation to varying safety tolerances (e.g., treating "controversial" as unsafe in strict mode for the Aegis benchmark versus safe in loose mode for OpenAIModeration), while Stream Qwen3Guard attaches a token-level classification head to the backbone transformer, enabling real-time safety monitoring during incremental text generation with only a modest F1 degradation of roughly two points compared to the generative variant. Across English, Chinese, and multilingual benchmarks spanning prompts and responses, Qwen3Guard achieves state-of-the-art performance — the 0.6B model rivals or exceeds existing guard models more than 10× larger, and the 8B model reaches average F1 scores of 90.0% on English prompt classification and 83.9% on English response classification — with the tri-class scheme proving that policy inconsistency is notably more pronounced in prompt classification than response classification, establishing that a single model can flexibly serve both permissive and conservative deployment contexts only when the controversial category is explicitly modeled.

2. Context and Motivation

The Core Problem: Guard Models Are Stuck in a Binary World, and Streams Break Them

The fundamental problem this paper addresses is that existing safety guardrail models for LLMs were designed for a deployment paradigm that no longer exists. Guard models like LlamaGuard (Inan et al., 2023; Chi et al., 2024), ShieldGemma (Zeng et al., 2024), and WildGuard (Han et al., 2024) emerged to solve a genuine and growing need: as LLMs became more capable and widely deployed, their unconstrained outputs posed real risks of producing harmful, biased, or illegal content. These guard models serve as external safety mechanisms that monitor both user inputs (prompts) and model outputs (responses), flagging unsafe content before it reaches end users.

This need is only intensifying. The paper cites the rapid advancement of foundation models — GPT-5, Claude 4, Gemini 2.5, DeepSeek-V3, Llama-4, and the Qwen series — as evidence that "the safety of their generated content has become a critical concern" (Section 1). The practical stakes are high: in enterprise deployments, a single harmful output can cause reputational damage, legal liability, or user harm. In consumer-facing applications, especially those involving vulnerable populations, unmoderated outputs can directly facilitate dangerous behavior (detailed instructions for self-harm, explosive manufacture, etc.). Guard models are the last line of defense when a model's intrinsic safety alignment fails.

However, the paper identifies two specific failure modes in existing guard models that render them inadequate for modern LLM deployment:

Failure Mode 1: Binary Labels Are Inherently Inconsistent Across Safety Policies

Existing guard models overwhelmingly output binary "safe/unsafe" labels. The paper argues this is fundamentally insufficient because safety is not a binary property — it depends on cultural context, application domain, risk tolerance, and even the specific deployment's legal jurisdiction. Consider three concrete scenarios:

A medical chatbot describing surgical procedures in detail: safe in a clinical training context, potentially unsafe if deployed to a general audience without medical supervision.
A history model describing wartime atrocities: safe in an educational context where the user has explicitly requested factual information, potentially unsafe if the description is gratuitously graphic or could be used to radicalize.
A coding assistant generating exploit code: unsafe in a general-purpose assistant, safe in a cybersecurity training tool used by professionals in a sandboxed environment.

Binary guard models force an all-or-nothing choice: either flag all such content (producing false positives that degrade user experience and trust) or allow all of it (producing false negatives that expose users to harm). The paper demonstrates this tension empirically in Figure 4, showing that WildGuard-7B achieves strong alignment with the Aegis dataset (high precision and recall) but behaves "overly conservative" or "overly restrictive" on the OpenAIModeration dataset. The same model, same output, same safety policy — different benchmark, different result. This is not a model quality problem; it is a policy representation problem. Binary labels cannot encode the nuance that different deployment contexts require.

The paper further observes that "policy inconsistency is notably more pronounced in prompt classification than in response classification" (Section 3.4.1), hypothesizing that this arises from divergent philosophies about risk tolerance:

Some benchmarks follow a "trust-but-verify" approach, allowing borderline prompts under the assumption that downstream models will generate safe responses.
Others adopt a "prevent-at-source" strategy, filtering potentially risky prompts before they reach any model, even if the eventual response would have been harmless.

A binary guard model forced to choose between these philosophies will inevitably fail on at least one of them.

Failure Mode 2: Full-Response Evaluation Is Fundamentally Incompatible with Streaming

Modern LLM deployments overwhelmingly use streaming inference — tokens are generated and transmitted to the user incrementally, with per-token latency in the tens of milliseconds. This is the default interaction paradigm for ChatGPT, Claude, Gemini, and virtually all consumer-facing chat interfaces. Users see responses appear token-by-token, which dramatically improves perceived latency and enables real-time interaction patterns.

Existing guard models, however, are architecturally designed for offline, full-response evaluation. They require the complete model output before performing safety classification. This creates three practical problems:

Harmful content is already delivered before it can be blocked. By the time a guard model flags a response as unsafe, the user has already read the harmful tokens. The guard model serves only as a post-hoc audit tool, not a real-time safety mechanism.
No opportunity for early intervention. A streaming model might generate 500 tokens, only the last 50 of which are actually unsafe. A full-response guard model cannot interrupt generation at token 451; it must wait until generation completes, then retroactively flag the entire response. This wastes compute, increases latency, and still exposes the user to harmful content.
Partial outputs can be harmful even if the full response would be safe. Consider a response that begins "Here are detailed instructions for synthesizing..." and then continues "...a hypothetical scenario for your novel." The first 10 tokens are genuinely alarming, but a full-response evaluation would classify the complete output as safe. In a streaming context, the user experiences genuine harm during those initial tokens.

The paper argues this limitation is "fundamentally misaligned with the streaming generation paradigm adopted by modern LLMs" (Section 1) and "hinders timely intervention and real-time content moderation during interactive sessions."

The Gap: No Guard Model Addresses Both Problems Simultaneously

What makes this gap particularly acute is that no existing open-source guard model addresses both limitations. LlamaGuard3 and LlamaGuard4 provide binary classifications for complete responses. ShieldGemma offers binary labels. WildGuard adds refusal detection but remains binary and full-response. PolyGuard extends to multilingual settings but maintains the binary, offline paradigm. The paper's contribution is not identifying either problem in isolation — the policy inconsistency problem has been noted by Zhang et al. (2024), and token-level approaches have been explored by Sharma et al. (2025), Xuan et al. (2025), and Li et al. (2025a) — but rather providing a unified solution that addresses both simultaneously, and doing so at scale (119 languages, three model sizes from 0.6B to 8B, state-of-the-art performance, Apache 2.0 license).

Why These Problems Matter Beyond Academic Interest

The paper's motivation extends beyond publishing a new model; it addresses genuine deployment challenges:

For enterprises deploying LLMs in regulated industries (healthcare, finance, legal), the "controversial" category maps directly to compliance requirements. A bank's customer service chatbot might need strict safety filtering for financial advice (where unqualified recommendations could violate regulations) but loose filtering for general conversation. Binary guard models force the bank to choose one policy across all interaction types, either over-censoring general conversation or under-censoring financial advice.

For platforms serving global audiences, safety norms vary by region. Content that is acceptable in one jurisdiction (e.g., discussions of LGBTQ+ topics) may be restricted or illegal in another. A binary guard model cannot simultaneously satisfy both sets of requirements. The tri-class scheme allows the "controversial" category to be interpreted differently per region — treated as unsafe in restrictive jurisdictions and safe in permissive ones — using a single model rather than deploying region-specific models.

For real-time applications (voice assistants, live translation, interactive tutoring), the latency gap between streaming generation and offline safety checking is unacceptable. A tutoring application that helps students with math problems cannot wait 200ms after each response completes to verify safety; students expect fluid, real-time interaction. Stream Qwen3Guard's token-level classification head operates at per-token latency under strict constraints (Section 4.4), enabling safety checks that keep pace with generation.

For the research community, the policy inconsistency finding has methodological implications. The paper demonstrates that different benchmarks encode different implicit safety policies, and that models optimized for one benchmark may underperform on another not due to capability differences but due to policy mismatch. This suggests that future guard model research should report both strict and loose evaluation modes, or better yet, adopt evaluation frameworks that explicitly account for policy variability.

Prior Approaches and Where They Fall Short

The paper positions itself against a specific landscape of prior guard models, each of which falls short on at least one of the two core problems:

LlamaGuard (Inan et al., 2023; Grattafiori et al., 2024; Chi et al., 2024) is the most widely-adopted open-source guard model family. LlamaGuard3-8B and LlamaGuard4-12B use instruction-following SFT to classify inputs and outputs into discrete safety categories with binary safe/unsafe labels. The paper's evaluation (Tables 2–6) shows these models achieve moderate performance — LlamaGuard3-8B averages 79.4% F1 on English prompt classification and 70.7% on English response classification — but they are fundamentally limited by their binary output space. They cannot express controversial judgments, leading to inconsistent performance across benchmarks with different policies. Additionally, they are full-response models with no streaming capability.

ShieldGemma (Zeng et al., 2024) offers sizes up to 27B parameters and attempts a different approach to policy inconsistency by "dynamically adjusting classifier thresholds" — effectively tuning the decision boundary to match a target deployment's risk tolerance. However, the paper's results (Tables 2–3) show ShieldGemma-27B achieves only 70.0% average F1 on English prompts and 65.9% on English responses, substantially below Qwen3Guard's performance. The threshold-adjustment approach also has a fundamental limitation: changing the decision threshold can trade off precision against recall, but it cannot capture cases where the label itself is inherently ambiguous or context-dependent. A binary classifier with an adjustable threshold still forces a binary decision on fundamentally non-binary content.

WildGuard (Han et al., 2024) is a 7B model that achieves strong results on certain benchmarks (89.4% F1 on Aegis prompt classification) but shows significant inconsistency across others (72.1% on OpenAIModeration). The paper highlights this in Figure 4: WildGuard "aligns well with the Aegis dataset but behaves overly conservatively on OpenAIMod." WildGuard adds refusal detection to its binary classification, but does not address the streaming limitation or the policy inconsistency problem.

NemoGuard (Nemotron Safety Guard V2; Ghosh et al., 2025) at 8B parameters achieves competitive results on some benchmarks (87.6% on Aegis2.0 response classification) but shares the binary, full-response limitation. The paper's evaluation (Tables 2–6) shows it trailing Qwen3Guard on most metrics.

PolyGuard (Kumar et al., 2025) extends guard capabilities to 17 languages using a Qwen-7B backbone, achieving strong multilingual performance. However, it remains a binary classifier without streaming support. The paper's multilingual evaluation (Tables 5–6) shows PolyGuard achieving 80.9% average F1 on multilingual prompts (RTP-LX) and 74.0% on multilingual responses — competitive but below Qwen3Guard's performance, and still limited to binary outputs.

Token-level approaches (Sharma et al., 2025; Xuan et al., 2025; Li et al., 2025a) have been explored in prior work but, as the paper notes, "these methods typically approximate token-level labels using sentence-level annotations or rely on indirect learning methods." The paper argues its rollout-based annotation method (Section 4.2) provides more accurate token-level labels by leveraging Generative Qwen3Guard to evaluate multiple completions from each prefix, combined with LLM-as-judge verification to reduce false attribution of risk.

DuoGuard (Deng et al., 2025) and GuardReasoner (Liu et al., 2025) represent a more recent trend of incorporating explicit reasoning into guard models. While these approaches improve classification accuracy by modeling the reasoning process underlying safety judgments, they do not address the streaming limitation and do not introduce a controversial category for policy adaptation.

How Qwen3Guard Positions Itself

The paper positions Qwen3Guard not as incremental improvement on existing guard models, but as a reconceptualization of what a guard model should output and when it should operate. The key moves:

On the output side, Qwen3Guard rejects binary classification entirely in favor of a tri-class scheme where "controversial" is not a confounded safe-or-unsafe decision but an explicit third category representing "instances whose safety label may vary depending on contextual factors or differing safety policies" (Section 1). This is not merely adding a third label to a confusion matrix — it requires a fundamentally different training data construction pipeline. The paper's method for building controversial labels (Section 3.3, Figure 3) is a multi-stage process: split training data, train two models with intentionally skewed safe/unsafe ratios (one strict, one loose), cross-annotate the held-out partitions, and assign "controversial" to instances where the strict and loose models disagree. This captures the decision boundary of safety ambiguity directly from model behavior rather than relying on human annotators to consistently identify borderline cases — a task the paper implicitly acknowledges has low inter-annotator agreement.

The output is evaluated in two modes — Strict (treating controversial as unsafe) and Loose (treating controversial as safe) — with the optimal mode selected per benchmark. This is not a post-hoc trick to boost numbers; it is the intended use case: deployments select their mode based on their risk tolerance, and a single Qwen3Guard model serves both permissive and conservative contexts without retraining.

On the timing side, Stream Qwen3Guard fundamentally changes when safety evaluation occurs. Rather than waiting for a complete response, it evaluates every token as it is generated by the upstream LLM. The architecture (Section 4.1) attaches two classification heads to the final transformer layer — one for the user's query (evaluated once, at the end-of-query token) and one for the assistant's streaming response (evaluated at every token). This is not a small modification; it requires an entirely different training data pipeline to produce token-level labels from sample-level annotations (Section 4.2), using Monte Carlo rollouts and LLM-as-judge verification to identify the earliest token at which content genuinely becomes unsafe.

The paper explicitly acknowledges the tradeoff: Stream Qwen3Guard shows "only modest performance degradation compared with the Generative Qwen3Guard" — approximately two F1 points on average (Section 4.4, Tables 11–15). This is presented as an acceptable cost for the streaming capability, and the paper demonstrates through the latency analysis (Figure 8) and efficiency comparison (Figure 9) that the architectural tradeoff yields practical benefits: near-linear scaling with response length versus the quadratic overhead of re-evaluating complete responses chunk-by-chunk with a generative model.

On scale, the paper positions itself as a comprehensive solution: three model sizes (0.6B, 4B, 8B) to accommodate different deployment constraints, 119 languages for global coverage, and two specialized variants for different operational requirements. The 0.6B model's ability to "rival or exceed the performance of existing Guard models that are more than 10× larger" (Section 3.4.1) is a deliberately emphasized point — it means Qwen3Guard can be deployed in resource-constrained environments where running a 7B+ parameter guard model alongside the main LLM is infeasible.

On openness, all models are released under Apache 2.0. This is significant because many prior guard models (particularly those from commercial labs) have restrictive licenses that limit commercial deployment or modification. The paper's positioning as an open, scalable, production-ready safety tool is reinforced by the two application demonstrations: Safety RL (Section 3.5) shows Qwen3Guard serving as a reward signal in a reinforcement learning pipeline that produces a simultaneously safer and more helpful model, and CARE integration (Section 4.5) shows Stream Qwen3Guard enabling real-time intervention with rollback and introspection, achieving substantial safety improvements without degrading response quality.

In summary, the paper argues that the field of guard models has been solving the wrong problem — optimizing binary classification accuracy on static benchmarks rather than building flexible, real-time safety mechanisms that match how LLMs are actually deployed. Qwen3Guard's tri-class output and streaming architecture represent not just technical improvements but a category shift in what guard models are expected to do.

3. Technical Approach

3.1 Reader orientation (approachable technical breakdown)

The system is a family of safety classification models that reads user prompts and assistant responses, then outputs both a severity judgment (safe, controversial, or unsafe) and a specific harm category (e.g., "Violent," "Sexual Content," "Copyright Violation"). It solves two problems: first, that existing guard models force binary safe/unsafe decisions that break when safety policies differ across deployment contexts, and second, that existing guard models need the complete response before they can evaluate it, making them useless for real-time streaming applications where harmful content is already delivered before it can be blocked. The solution's shape is a pair of specialized architectures — one generative variant that outputs structured text judgments with an explicit "controversial" third label for policy-dependent cases, and one streaming variant that attaches token-level classification heads to a transformer backbone, evaluating safety at every generated token rather than waiting for response completion — both trained on the same multilingual dataset covering 119 languages, and both available in three model sizes to fit different deployment budgets.

3.2 Big-picture architecture (diagram in words)

The system consists of five major components:

Qwen3 Foundation Models (0.6B, 4B, 8B parameters) — the pretrained instruction-tuned transformer backbones that provide the base language understanding and multilingual capabilities. These are the models described in Yang et al. (2025a), already instruction-tuned and capable of following structured prompts.
Generative Qwen3Guard (Qwen3Guard-Gen) — a variant that takes the foundation model, fine-tunes it via supervised fine-tuning (SFT) on a carefully constructed dataset of 1.19M+ prompt and response samples with tri-class labels (safe/controversial/unsafe), and outputs safety judgments in a structured text format following a detailed instruction template. It produces three lines: a safety severity line, a categories line listing applicable harm types, and (for responses only) a refusal detection line. The model operates in two post-hoc modes — Strict (treats controversial as unsafe) and Loose (treats controversial as safe) — selected per deployment based on risk tolerance.
Stream Qwen3Guard (Qwen3Guard-Stream) — a variant that starts from the same Qwen3 foundation models but replaces the generative output head with two parallel token-level classification heads attached to the final transformer layer. One head (the Prompt Moderator) evaluates the complete user query at the end-of-query token. The other head (the Response Moderator) evaluates every token of the assistant's streaming response as it is generated, producing per-token harm severity and category predictions. A debouncing mechanism requires two consecutive tokens to be flagged before reporting unsafe/controversial, preventing spurious single-token false positives.
Training Data Pipeline — a multi-stage process that constructs the 1.19M+ sample dataset (Table 1) spanning 15+ languages. For Generative Qwen3Guard, this pipeline includes prompt synthesis via keyword-guided Self-Instruct, response collection from both Instruct and Base models (the latter crucial for obtaining unsafe outputs that aligned models refuse to generate), auto-labeling via ensemble voting across multiple Qwen model versions, multilingual translation via Qwen-MT, and a two-step refinement process (controversial label construction and label distillation). For Stream Qwen3Guard, this pipeline adds a rollout-based token-level annotation stage that identifies the earliest token at which content becomes genuinely unsafe, using Monte Carlo completions evaluated by Generative Qwen3Guard followed by LLM-as-judge verification.
Deployment Interface — the operational modes that downstream systems use. Generative Qwen3Guard operates offline, receiving complete prompts or responses and returning structured safety assessments. Stream Qwen3Guard operates online during LLM generation: the user prompt is submitted simultaneously to both the LLM assistant and Stream Qwen3Guard; if the prompt is safe, the assistant begins streaming tokens, and each output token is immediately forwarded to Stream Qwen3Guard's Response Moderator head, enabling the surrounding framework to halt generation, trigger rollbacks, or apply interventions the moment unsafe content is detected.

Information flows through the system in two distinct paths. In the generative path: a prompt or response enters → Generative Qwen3Guard formats it into an instruction template containing the task definition, safety policies, harm category definitions, conversation context, and output format specification → the model generates a structured text output → a parser extracts the safety severity, categories, and (for responses) refusal flag → the deployment framework interprets the result based on its selected mode (Strict or Loose). In the streaming path: the user prompt is tokenized and passed through the transformer → the final hidden state at the end-of-query token enters the Prompt Moderator classification head → if safe, the LLM assistant begins generating response tokens → each generated token passes through the transformer → the last hidden state at each token position enters the Response Moderator classification head → per-token harm predictions are debounced and monitored → if two consecutive tokens are flagged as unsafe/controversial, an intervention signal is raised.

3.3 Roadmap for the deep dive

First, the Generative Qwen3Guard task definition (Section 3.1) — the instruction template, output format, and how safety classification is reformulated as instruction-following — because this defines the output space that everything else (data, training, evaluation) must support.
Second, the data collection pipeline (Section 3.2) — prompt synthesis, response collection, auto-labeling, and multilingual translation — because the model's behavior is entirely shaped by what training data it sees, and the tri-class scheme demands specific data construction strategies that differ fundamentally from binary guard model training.
Third, the training methodology (Section 3.3) — the controversial label construction pipeline and label distillation process — because these are the paper's key innovations for handling the policy inconsistency problem, and they explain how a model can learn to output "controversial" for genuinely ambiguous cases rather than making an arbitrary binary choice.
Fourth, the Stream Qwen3Guard architecture and data pipeline (Sections 4.1–4.3) — the classification head design, the rollout-based token annotation method, and the training loss formulation — because this variant introduces fundamentally different technical challenges (token-level supervision from sample-level labels, conditional category loss, debouncing) that require separate detailed treatment.
Fifth, the evaluation methodology and main results (Sections 3.4, 4.4) — benchmarks, baselines, metrics, and modality-specific evaluation (category classification, refusal detection, latency analysis, efficiency comparison) — because these quantify what the technical approach achieves and reveal its limitations.
Sixth, the application demonstrations (Sections 3.5, 4.5) — Safety RL with Generative Qwen3Guard as a reward signal and CARE integration with Stream Qwen3Guard for real-time intervention — because these show how the technical components are used in practice, validating that the design choices translate to real-world utility.

3.4 Detailed, sentence-based technical breakdown

This is primarily a systems and training methodology paper whose core idea is that guard models need a tri-class output space (not binary) and token-level evaluation capability (not full-response only) to serve the diverse safety policy requirements and streaming deployment paradigms of modern LLM applications. The technical contribution is the end-to-end pipeline that produces both capabilities from the same foundation model family, using carefully designed data construction, multi-stage training, and architectural modifications rather than novel modeling techniques.

Generative Qwen3Guard: Task Definition and Instruction Design

Generative Qwen3Guard reformulates safety classification as a structured instruction-following task rather than a simple classification head attached to a transformer. The model receives a detailed prompt containing the task definition, safety policies, harm category definitions, conversation context, and output format specification, then generates a multi-line text output conforming to a strict template.

The instruction template for prompt classification (Figure 2a, detailed in Appendix Figure 10) contains five sequential components:

Task definition: explicit instructions to evaluate whether the last user query is safe or unsafe based on the safety policy, and to identify the category of unsafe content found.
Safety policy definitions: a structured block defining three severity levels:
- "Safety: Safe: The USER's query does not contain any prohibited content or content that could lead to prohibited content."
- "Safety: Unsafe: The USER's query contains prohibited content."
- "Safety: Controversial: The USER's query does not explicitly contain prohibited content, but its intent, context, or potential responses could be misinterpreted, misused, or exploited to generate unsafe content under certain conditions."
Unsafe content categories: a list of nine categories for prompts (Violent, Non-violent Illegal Acts, Sexual Content or Sexual Acts, PII, Suicide & Self-Harm, Unethical Acts, Politically Sensitive Topics, Copyright Violation, Jailbreak), where Jailbreak is exclusive to input classification since jailbreak attacks operate through prompt engineering.
Conversation context: the dialogue history enclosed in <BEGIN CONVERSATION> and <END CONVERSATION> tags, containing the user and assistant turns.
Output format specification: strict formatting requirements — the first line must be exactly one of 'Safety: Safe', 'Safety: Unsafe', or 'Safety: Controversial'; the second line must start with 'Categories:' followed by a comma-separated list of unsafe categories, or 'Categories: None' if safe.

The instruction template for response classification (Figure 2b, detailed in Appendix Figure 11) adds a sixth component: a refusal policy definition ("Refusal: Yes: The ASSISTANT refused to answer or did not comply with the USER's request" / "Refusal: No: The ASSISTANT directly answered or complied with the USER's request"), and requires a third output line in the format 'Refusal: Yes' or 'Refusal: No'. The unsafe content categories for responses exclude Jailbreak (since jailbreak is a property of the prompt, not the response) but are otherwise identical.

Design choice: why instruction-following rather than a classification head? The paper does not explicitly state this, but the implications are clear from the architecture. A classification head would require training a separate model or modifying the backbone architecture with task-specific layers. By casting safety judgment as text generation, Generative Qwen3Guard leverages the full instruction-following capabilities of the Qwen3 foundation models, which are already trained to produce structured outputs from detailed prompts. This approach also makes the model's reasoning more interpretable — the output text is human-readable and can be inspected for errors — and enables the same model to handle both prompt and response classification by simply changing the instruction template, without architectural modifications or separate heads.

Design choice: why include the entire safety policy in every prompt? Including the full policy text in the instruction template is expensive in terms of input tokens (approximately 500+ tokens of policy text per inference call), but it ensures that the model's safety judgments are explicitly conditioned on the defined policy rather than relying on whatever policy the model may have internalized during pretraining. This is crucial because different deployments may have different policies, and the same model needs to apply the specified policy rather than a fixed internal one. The policy text serves as a form of in-context conditioning that makes the model's behavior explicit and auditable.

What the output format enables downstream: The structured multi-line output enables programmatic parsing — the first line determines the safety severity for routing decisions, the second line provides fine-grained category information for logging or targeted interventions, and (for responses) the third line distinguishes genuine harmful outputs from refusals, which is important because a refusal to answer "How can I make a bomb?" should not itself be flagged as unsafe content even though it appears in response to an unsafe prompt.

Data Collection: Building a Tri-Class Multilingual Safety Dataset

The data collection pipeline (Section 3.2) constructs the training dataset for Generative Qwen3Guard from multiple sources, producing over 1.19M samples spanning prompt and response classification across 15+ languages. The pipeline addresses a fundamental challenge: safety-aligned instruct models rarely produce unsafe outputs, and human annotation of fine-grained safety labels at scale is prohibitively expensive. The solution combines synthetic data generation, automated labeling, and multilingual translation in a multi-stage process.

Prompt Synthesis. For prompt data (41.2% of the total, per Table 1), the paper uses the Self-Instruct framework (Wang et al., 2023) to generate diverse, policy-aligned prompts across all safety categories. The process works in three sub-stages:

Taxonomy decomposition: the safety policy is decomposed into a fine-grained taxonomy — this means each high-level category (e.g., "Violent") is broken down into specific sub-topics (e.g., "explosive manufacture," "weapon acquisition," "physical assault methods") to ensure coverage of the full space of unsafe queries.
Seed prompt collection: for each sub-topic, seed prompts are collected (the paper does not specify whether these are human-written, drawn from existing datasets, or synthetically generated) to provide the LLM with examples of the target query type.
Keyword-guided generation: for each safety category, a set of semantically relevant keywords is curated, and prompt generation is conditioned on each keyword individually. The paper gives a concrete example: when synthesizing prompts related to hazardous explosives, the model is explicitly instructed to incorporate terms such as "bomb," "TNT," "C4," and "black powder." The purpose is "encouraging lexical and topical variation while preserving category alignment" — ensuring the model doesn't just generate slight variations of the same prompt but explores the semantic space of each category.

Paired positive-negative examples. A critical design choice for preventing spurious correlations: alongside each unsafe prompt (e.g., "How to make a bomb"), the pipeline generates a structurally similar safe prompt (e.g., "How to make a cake"). The purpose is explicitly stated: "ensuring that the model does not erroneously classify verbs like 'make' as inherently unsafe." Without this pairing, a model trained only on unsafe prompts might learn that certain syntactic patterns or lexical items (like the verb "make" followed by a noun phrase) are predictive of unsafe content, producing false positives on benign queries that share surface structure with harmful ones. The paired examples force the model to attend to the semantic content of the query rather than surface-level lexical or syntactic cues.

Response Collection. For response data (58.8% of the total, per Table 1), the pipeline addresses a data distribution problem that is specific to guard model training. Safety-aligned instruct models (which are the typical source of model-generated text) are designed to avoid producing unsafe outputs — so if the pipeline only used instruct model outputs, the dataset would have almost no examples of genuinely unsafe responses, making it impossible to train a classifier to detect them.

The paper addresses this through two complementary strategies:

Base model generation for unsafe responses: the paper explicitly states that "since safety-aligned Instruct models rarely generate unsafe output, we leverage base models (e.g., Qwen2.5-72B-Base) to synthesize such content." Base models are pretrained but not instruction-tuned or safety-aligned — they complete text based on statistical patterns in their training data without the post-training safety conditioning that instruct models receive. When prompted with user queries that request harmful information, base models will often comply and produce the harmful content, generating the unsafe response examples needed for guard model training. This is a practical but ethically careful choice: the base models are used specifically to generate training data that teaches the guard model to recognize unsafe content, not to serve end users.
Reasoning model outputs for "thinking" content: with the emergence of reasoning-capable models (like QwQ, Qwen3 series, DeepSeek-R1, and distilled DeepSeek variants) that produce internal reasoning traces before their final answers, a new moderation challenge arises: the "thinking" content embedded in model outputs can itself be unsafe, even if the final output is benign. For example, a reasoning model might internally explore harmful approaches before rejecting them in its final response. The paper explicitly collects responses from these reasoning models to ensure the guard model can moderate reasoning traces.

Auto Labeling. Manual annotation of 1.19M+ samples is infeasible, so the paper designs an automated labeling pipeline with a small manually annotated validation set for quality control. The pipeline works as follows:

Multiple versions of Qwen models (specifically Qwen2.5-72B-Instruct and Qwen3-235B-A22B) are used to generate preliminary safety labels for unlabeled data, using "tailored annotation instructions" — essentially, the same instruction template used for Generative Qwen3Guard, but applied as a labeling tool rather than a deployed classifier.
Model outputs are aggregated via a voting mechanism. The paper reports that this ensemble-based strategy "produces safety-level labels with an F1 score exceeding 0.9 on the human-annotated validation set" — meaning the automated labels agree with human judgments on a held-out validation set at above 90% F1, providing confidence that the labeling pipeline is reliable.
For category and refusal labels (as opposed to severity labels), the final label is assigned based on "the most frequently predicted output across all models" — a simple majority vote rather than a more complex ensemble mechanism.

Multilingual Samples. Since safety datasets are overwhelmingly English, the pipeline uses Qwen-MT (Qwen Team, 2025a) to translate original content into 15 additional languages beyond the source languages. The paper applies several validation methods to ensure translation quality: "language mixing detection" (catching cases where the translation contains untranslated source-language text), "LLM judge" (using a separate model to evaluate translation quality), and "random sampling followed by manual review" (human spot-checking). The resulting language distribution (Table 1) shows Chinese (26.64%) and English (21.9%) as the largest components, with Korean (9.91%), Indonesian (5.38%), Russian (5.36%), Japanese (4.82%), and Arabic (4.71%) as the next largest, and 10+ additional languages at smaller proportions.

Design choice: why use voting rather than a single high-quality labeler? A single large model (e.g., Qwen3-235B-A22B alone) might produce higher-quality individual labels, but voting across multiple models provides two advantages: first, it reduces the variance of labeling errors — if one model makes a systematic error (e.g., over-flagging certain political topics as unsafe), the other models' votes dilute that bias; second, disagreement between models naturally surfaces ambiguous cases (where one model says safe and another says unsafe), which aligns precisely with the "controversial" category the paper wants to model.

Generative Qwen3Guard is trained via supervised fine-tuning (SFT) on the Qwen3 instruction-tuned foundation models. The training methodology (Section 3.3) focuses primarily on two challenges that arise specifically from introducing the controversial label: first, controversial instances are naturally scarce in both human-annotated and synthetic data because annotators (and label-generating models) tend to make binary decisions; second, the training data contains annotation noise that can confuse model learning, especially around the decision boundary between safe and unsafe where controversial cases lie.

The paper addresses these through a two-step pipeline: building controversial labels and label distillation. This is the most technically novel part of Generative Qwen3Guard's construction.

Challenge: why are controversial labels scarce? The paper states that "due to the inherent ambiguity of the 'controversial' severity level, instances belonging to this category are limited in number in both human-annotated and synthetically generated data." This is intuitive: when a human annotator or an LLM judge evaluates whether content is safe or unsafe, borderline cases are psychologically difficult — the annotator is forced to make a binary choice, and the easier cognitive path is to pick one side rather than mark "ambiguous." The paper's insight is that this scarcity is not just a sampling problem but a representation problem: binary classifiers trained on predominantly binary labels never learn the decision boundary between safe and unsafe, because that boundary is precisely where controversial instances live. To teach a model to output "controversial," you need to explicitly construct those ambiguous cases and present them during training.

Building Controversial Labels (Figure 3). The pipeline for constructing controversial labels is a multi-stage cross-validation-style process that creates ambiguity labels from the behavior of models trained with intentionally skewed label distributions. The procedure works in four steps:

Step 1: Data Split. The full training dataset is evenly partitioned into two disjoint subsets, Part A and Part B. The purpose of this split is to avoid the circularity of training a model and then evaluating it on the same data — models trained on Part A will be used to annotate Part B, and vice versa.

Step 2: Reweight and Train. On Part A, two separate models are trained using different sampling strategies that intentionally skew the safe/unsafe ratio:

PartA-Strict: trained with "an enriched proportion of Safe samples" — meaning the training data is reweighted or resampled so that safe examples appear more frequently than unsafe examples relative to their natural distribution. This causes the model to learn a more conservative safety boundary: it becomes more willing to classify borderline cases as unsafe because it has been exposed to more examples of what "safe" looks like and is therefore more sensitive to deviations.
PartA-Loose: trained with "an enriched proportion of Unsafe samples" — the inverse skew, where unsafe examples are oversampled. This causes the model to learn a more permissive boundary: it becomes more reluctant to classify borderline cases as unsafe because it has been exposed to many unsafe examples and has learned a narrower definition of what constitutes harm.

The paper states that "the Safe/Unsafe ratios are calibrated based on the model performance on the most conservative and most permissive on the validation set" — meaning the skew factors are not arbitrary but are tuned so that PartA-Strict matches the behavior of a maximally conservative deployment and PartA-Loose matches a maximally permissive one.

Step 3: Cross Annotation. The two models (PartA-Strict and PartA-Loose) are applied to Part B, producing two predictions for each sample. This step effectively asks: for each sample, does a conservative model and a permissive model agree on its safety label?

Step 4: Voting. Labels are assigned via majority voting:

If both models predict Safe → final label is Safe.
If both models predict Unsafe → final label is Unsafe.
If the models disagree (one Safe, one Unsafe) → final label is Controversial.

The table in Figure 3 shows this voting logic explicitly:

Strict Prediction	Loose Prediction	Final Label
Safe	Safe	Safe
Unsafe	Safe	Controversial
Unsafe	Unsafe	Unsafe

The process is then reversed: models are trained on Part B (with the same skew strategy) and applied to Part A, and the conflicting predictions are labeled as Controversial. Aggregating results from both partitions yields controversial labels for the entire training dataset.

What this procedure actually captures: The controversial labels are not manually annotated by humans making nuanced judgments — they are emergent from model disagreement under distribution shift. A sample gets labeled "controversial" if a conservative model thinks it's unsafe while a permissive model thinks it's safe. This operationalizes the paper's definition of controversial as "instances whose safety label may vary depending on contextual factors or differing safety policies" — the two models with different skews represent two different safety policies, and their disagreement identifies exactly the instances where policy choice matters.

Design choice: why use two models rather than asking a single model to output "controversial" directly? Asking a single model to produce tri-class labels requires that the model has a well-calibrated sense of its own uncertainty about safety — a metacognitive capability that current LLMs generally lack. The two-model approach sidesteps this: it converts the problem of identifying controversial content into a problem of detecting disagreement between two simpler models, each of which only needs to make binary decisions. This is more reliable because binary classification is a better-specified task, and the disagreement signal naturally surfaces ambiguity without requiring metacognitive awareness.

Label Distillation. After building controversial labels, the paper applies a distillation-based refinement step to reduce annotation noise. The process again splits the dataset into two disjoint subsets, trains models on one subset, and uses them to improve annotations on the other. The distillation uses Qwen3-32B as the teacher model — a larger, more capable model whose predictions are treated as higher-quality supervision. The paper states that "through knowledge distillation, annotation errors are effectively reduced," citing a quantitative result in Table 9: after distillation, Qwen3Guard-Gen-4B shows an average improvement of +0.47/+1.10 points (Strict/Loose mode) on prompt classification and +0.50/+0.76 points on response classification (Section 3.4.2, Table 9). The improvements are consistent across most benchmarks, suggesting that the distillation step genuinely cleans noisy labels rather than just memorizing teacher predictions.

Why distillation helps beyond just using the teacher model directly: The teacher model (Qwen3-32B) is too large to deploy as a guard model in many scenarios (especially alongside an LLM assistant that may itself be large). Distillation transfers the teacher's cleaner decision boundaries to the smaller student model (Qwen3-4B or Qwen3-8B), enabling deployment at lower computational cost while benefiting from the teacher's supervision quality. This is a standard knowledge distillation pattern, applied here specifically to the label refinement problem.

Training loss formulation for Generative Qwen3Guard. The paper does not provide explicit equations for the SFT loss used on Generative Qwen3Guard, but it is standard language modeling cross-entropy on the target output tokens (the structured safety judgment text). Given an instruction prompt $x$ (containing the task definition, policy, categories, conversation, and output format) and a target output $y$ (the formatted safety judgment), the loss at each token position $t$ is:

$\mathcal{L}_t = -\log P_\theta(y_t \mid x, y_{<t})$

where $P_\theta$ is the model's predicted probability distribution over the vocabulary at position $t$ , conditioned on the instruction $x$ and all previously generated output tokens $y_{<t}$ . The total loss is the average over all output token positions.

This is standard autoregressive language model fine-tuning — the model learns to generate the structured safety judgment text given the instruction, where the instruction itself encodes the safety policy that should be applied. The key training data features that enable tri-class learning are the controversial labels constructed via the two-model procedure and the label refinement from distillation, not any modification to the loss function.

Stream Qwen3Guard: Architecture for Token-Level Real-Time Safety Monitoring

Stream Qwen3Guard (Section 4) addresses the fundamental architectural limitation of generative guard models: they operate on complete inputs, making them incompatible with streaming LLM inference where tokens arrive incrementally and harmful content must be detected before it reaches the user. The solution is to replace the generative output head with token-level classification heads that evaluate safety at every position in the sequence, enabling per-token decisions without waiting for the response to complete.

Architecture (Section 4.1). Stream Qwen3Guard starts from the same Qwen3 pretrained transformer backbone as Generative Qwen3Guard. Rather than fine-tuning the full model for text generation, it attaches two parallel classification pathways to the final layer of the transformer, creating a multi-head architecture that processes both the user query and the assistant's streaming response simultaneously through independent parameter sets.

The computational flow (Equation 3) proceeds as follows:

Hidden state extraction. For any token in the input sequence, the backbone transformer produces a final hidden state $\mathbf{h} \in \mathbb{R}^d$ (where $d$ is the model's hidden dimension — e.g., 2048 for the 4B model, though exact dimensions are not specified in the paper). This hidden state encodes the token's contextualized representation based on all preceding tokens.
Parallel preprocessing. The hidden state is projected through two independent linear transformations followed by layer normalization:

$\mathbf{x}_r = \text{LayerNorm}(\mathbf{W}_{r\text{-pre}}\mathbf{h})$ $\mathbf{x}_q = \text{LayerNorm}(\mathbf{W}_{q\text{-pre}}\mathbf{h})$

where:
- $\mathbf{W}_{r\text{-pre}} \in \mathbb{R}^{d \times d}$ and $\mathbf{W}_{q\text{-pre}} \in \mathbb{R}^{d \times d}$ are learnable projection matrices for the response and query streams respectively,
- $\text{LayerNorm}$ is standard layer normalization (Ba et al., 2016) applied to stabilize training,
- $\mathbf{x}_r \in \mathbb{R}^d$ and $\mathbf{x}_q \in \mathbb{R}^d$ are the transformed representations for the response and query pathways.
What this step does: it creates two separate representations of the same hidden state, one specialized for analyzing the assistant's response and one for the user's query. The separate projections allow each stream to learn different feature extractors suited to its task (response classification focuses on content harm detection, while query classification additionally needs to recognize jailbreak patterns and adversarial intent).
Harm severity classification. Each pathway passes its transformed representation through a linear classifier to predict the harm severity level (safe, controversial, unsafe). The raw logits are converted to probabilities via softmax:

$\mathbf{y}_{r\text{-risk}} = \text{Softmax}(\mathbf{W}_{r\text{-risk}}\mathbf{x}_r)$ $\mathbf{y}_{q\text{-risk}} = \text{Softmax}(\mathbf{W}_{q\text{-risk}}\mathbf{x}_q)$

where:
- $\mathbf{W}_{r\text{-risk}} \in \mathbb{R}^{3 \times d}$ and $\mathbf{W}_{q\text{-risk}} \in \mathbb{R}^{3 \times d}$ are learnable weight matrices for the risk classification heads,
- The output dimension of 3 corresponds to the three severity levels: Safe, Controversial, and Unsafe,
- $\mathbf{y}_{r\text{-risk}} \in [0, 1]^3$ and $\mathbf{y}_{q\text{-risk}} \in [0, 1]^3$ are probability distributions over the three severity levels.
What this computes: for the response stream, a per-token probability distribution over safe/controversial/unsafe. For the query stream, a single distribution at the end-of-query token. The softmax ensures the outputs sum to 1 and can be interpreted as probabilities.
Safety category classification. Each pathway simultaneously predicts the specific harm category (Violent, Non-violent Illegal Acts, Sexual Content, PII, Suicide & Self-Harm, Unethical Acts, Politically Sensitive Topics, Copyright Violation, plus Jailbreak for queries only):

$\mathbf{y}_{r\text{-cat}} = \text{Softmax}(\mathbf{W}_{r\text{-cat}}\mathbf{x}_r)$ $\mathbf{y}_{q\text{-cat}} = \text{Softmax}(\mathbf{W}_{q\text{-cat}}\mathbf{x}_q)$

where:
- $\mathbf{W}_{r\text{-cat}} \in \mathbb{R}^{C_r \times d}$ and $\mathbf{W}_{q\text{-cat}} \in \mathbb{R}^{C_q \times d}$ are learnable weight matrices for the category classification heads,
- $C_r = 8$ (response categories, excluding Jailbreak) and $C_q = 9$ (query categories, including Jailbreak),
- $\mathbf{y}_{r\text{-cat}}$ and $\mathbf{y}_{q\text{-cat}}$ are probability distributions over the applicable categories.
What this computes: fine-grained harm type predictions parallel to the severity predictions. This dual-head design (risk + category) allows the model to simultaneously determine how severe the harm is and what type of harm it represents, enabling downstream systems to apply category-specific intervention strategies (e.g., flagging PII leaks for data privacy teams vs. flagging violent content for trust and safety teams).

Design choice: why separate risk and category heads rather than a single joint classification? A joint classification over 3 risk levels × 8 categories (24 classes) would have a much larger output space and require more training data per class. The factorized design decomposes the problem into two simpler subtasks, each with fewer classes, reducing the sample complexity of training. It also enables the conditional category loss (described below), where the category head is only trained when the risk is unsafe or controversial — which makes intuitive sense because there is no meaningful category to predict for safe content.

Design choice: why independent parameters for query and response streams rather than shared? The query and response classification tasks have different characteristics. Query classification needs to detect harmful intent, jailbreak attempts, and adversarial prompts — content designed to manipulate or circumvent safety mechanisms. Response classification needs to detect harmful information delivery, explicit content, and refusal behaviors. Sharing parameters between these tasks would force a single representation to serve both purposes, potentially reducing performance on each. Separate parameters allow each pathway to specialize.

Debouncing mechanism. A practical challenge with per-token classification is instability: a single token might be misclassified as unsafe due to model error or ambiguous context, triggering false alarms. To prevent spurious flags, Stream Qwen3Guard uses a debouncing mechanism described in Section 4.4:

"a response is flagged as unsafe or controversial starting from token $i$ only if both token $i$ and its immediate predecessor, token $i-1$ , are classified as unsafe or controversial"

This is a simple two-token sliding window: the system requires two consecutive unsafe/controversial predictions before raising an alarm. The safety category of token $i$ (not $i-1$ ) is used as the category for the whole response, under the assumption that the later token provides more context and is more likely to be correctly categorized.

Why debouncing works: Individual token misclassifications are typically isolated — a single token in an otherwise safe sequence gets an erroneous unsafe prediction. Requiring two consecutive unsafe tokens dramatically reduces the false positive rate because the probability of two independent errors on consecutive tokens is the square of the single-token error rate. For example, if the per-token false positive rate is 5%, the debounced false positive rate would be approximately 0.25% assuming independence. The independence assumption is not perfect (errors may be correlated due to shared context), but the mechanism still provides practical robustness.

Tradeoff: latency of detection. The debouncing adds a one-token delay to detection: if the truly unsafe content begins at token $i$ , the system flags it at token $i+1$ (when the second consecutive unsafe prediction is confirmed). In practice, with modern LLMs generating 50–100 tokens per second, this corresponds to a 10–20ms additional delay, which is negligible compared to human perception thresholds.

Stream Qwen3Guard: Data Collection for Token-Level Supervision

The central challenge in training Stream Qwen3Guard is that training data for guard models typically has sample-level labels (e.g., "this entire response is unsafe, category Violent"), but the token-level classification head requires token-level labels (e.g., "token 1 is safe, token 2 is safe, ..., token 47 is the first unsafe token, token 47 onwards are unsafe, category Violent"). The paper's data collection method (Section 4.2) automatically converts sample-level labels to token-level labels by identifying the earliest token at which the response becomes genuinely unsafe.

Problem statement. Given a training sample where the assistant's response is labeled as "unsafe" or "controversial" at the sample level, and the response is represented as a sequence of tokens $S = \{S_1, S_2, \ldots, S_n\}$ (where $n$ is the total number of tokens in the response), the objective is to identify the initial token $S_i$ that triggers unsafe content. Tokens before $S_i$ are implicitly safe; $S_i$ and all subsequent tokens inherit the sample-level label.

The pipeline uses a two-stage process: rollout-based safety assessment and LLM-as-judge verification. Both stages are necessary because each addresses a different failure mode of the other.

Stage 1: Rollout-Based Safety Assessment. For each token position $i$ in the response, a prefix $P_i = \{S_1, S_2, \ldots, S_i\}$ is constructed — this is the partial response consisting of the first $i$ tokens. The key insight is that if token $S_i$ is the first genuinely unsafe token, then completions starting from prefix $P_{i-1}$ (tokens before the unsafe content) should mostly be safe, while completions starting from prefix $P_i$ (which includes the triggering unsafe content) should mostly be unsafe.

The assessment procedure:

For each prefix $P_i$ , an ensemble of language models generates $k$ continuation sequences (called "rollouts"). The paper does not specify $k$ , the ensemble composition, or the generation parameters (temperature, sampling strategy), referring vaguely to "a diverse ensemble of language models."
For the $j$ -th rollout from prefix $P_i$ , the complete response is formed by concatenation: $C_{i,j} = P_i \oplus R_{i,j}$ , where $\oplus$ denotes string concatenation and $R_{i,j}$ is the generated continuation.
Each complete response $C_{i,j}$ is evaluated by Generative Qwen3Guard to assess its safety. The rollout-based safety violation indicator for token $S_i$ is defined as:

$\text{is unsafe}_{\text{rollout}}(S_i) = \begin{cases} 1 & \text{if } \frac{1}{k} \sum_{j=1}^k \mathbb{I}\left[f_{\text{Qwen3Guard-Gen}}(C_{i,j}) = \text{unsafe or controversial}\right] \geq X\% \\ 0 & \text{otherwise} \end{cases}$

where:
- $f_{\text{Qwen3Guard-Gen}}$ is the safety prediction function of Generative Qwen3Guard (returns one of Safe, Controversial, Unsafe),
- $\mathbb{I}(\cdot)$ is the indicator function (1 if the condition is true, 0 otherwise),
- $X\%$ is a predefined safety violation threshold — the paper reports that "in our pilot experiments, we found that setting $X\% = 85\%$ yields strong alignment with human safety annotations,"
- The first term $\frac{1}{k} \sum_{j=1}^k \mathbb{I}[\cdot] \geq X\%$ computes the fraction of rollouts that are flagged as unsafe or controversial, and compares it to the threshold.
What this computes: for each token position $S_i$ , the fraction of rollouts (continuations generated from the prefix ending at $S_i$ ) that are evaluated as unsafe or controversial by Generative Qwen3Guard. If this fraction exceeds 85%, the token is flagged as potentially unsafe.

Why 85% rather than 50%? A simple majority threshold (50%) would flag a token as unsafe if more than half of rollouts were unsafe. However, base models can produce harmful content even from safe prefixes — if a prefix is genuinely safe but the ensemble models have a tendency to generate harmful continuations regardless of prefix, a 50% threshold would produce many false positives. The 85% threshold requires strong evidence (a supermajority of rollouts being unsafe) before flagging, reducing false positives from model bias toward harmful generation.

Stage 2: LLM-as-Judge Verification. The rollout mechanism has a critical limitation described in the paper: "Even when a token $S_i$ itself is safe/harmless, the rollouts may contain a high proportion of unsafe continuations because language models can be susceptible to generating harmful content regardless of the specific prompting token." In other words, the base models used for rollouts might produce unsafe completions from any prefix, not because the prefix contains harmful content but because the base model, lacking safety alignment, tends toward harmful completions when given any prompt that could be interpreted as requesting information.

To address this "false attribution of risk," an LLM-as-judge verification step evaluates each flagged prefix independently, without rollouts. The judge is prompted to assess the safety of the prefix "based solely on the provided tokens, without inferring or predicting subsequent content." The judgment function is:

$\text{is unsafe}_{\text{judge}}(S_i) = \begin{cases} 1 & \text{if } f_{\text{judge}}(P_i) = \text{unsafe} \\ 0 & \text{otherwise} \end{cases}$

where $f_{\text{judge}}$ is the LLM judge's binary safety prediction (the paper uses Qwen3-235B-A22B as the judge). The judge evaluates only the tokens that have been explicitly presented, ignoring what might come next — a strict interpretation where "if the given text is, in its current state, unsafe or safe" is the operative question.

Why this verification is necessary: the rollout mechanism measures what could follow from a prefix, which is a forward-looking assessment of risk. The judge measures what is already present in the prefix, which is a backward-looking assessment of harm. A prefix like "I can help you with that. Here are some methods:" is safe on its own (the judge would say safe), but rollouts from this prefix would likely produce harmful continuations (the rollout mechanism would flag it). The conjunction — requiring both the rollout and the judge to agree — ensures that only tokens where the content is already harmful (judge says unsafe) and likely to lead to harmful continuations (rollout says unsafe) are labeled as unsafe, eliminating the false positives where a safe prefix happens to precede harmful rollouts.

Final Label Determination. A definitive unsafe label is assigned to token $S_i$ if and only if both the rollout assessment and the LLM-as-judge verification concur that the content is unsafe at that point. Then the first token $S_i$ in the sequence that satisfies this condition is identified as the boundary token — the earliest point at which content becomes genuinely unsafe. This token and all following tokens are assigned the original sample-level label (e.g., "unsafe" or "controversial") with the corresponding harm category. Tokens preceding $S_i$ are implicitly considered safe.

The boundary token determination is a sequential scan from $S_1$ to $S_n$ , stopping at the first index $i$ where is unsafe_rollout(S_i) ∧ is unsafe_judge(S_i) evaluates to true. All tokens $S_1, \ldots, S_{i-1}$ receive the label "Safe, Categories: None." All tokens $S_i, \ldots, S_n$ receive the sample-level label and category.

What this labeling scheme enables: during training, the Stream Qwen3Guard model learns to predict the transition from safe to unsafe content at the token where it actually occurs, rather than learning an arbitrary split point. At inference time, this means the model can raise an alarm close to the actual onset of harmful content, as demonstrated in the latency analysis (Figure 8) where the model achieves an "exact hit rate of nearly 86.0%" — meaning the first flagged token falls within the human-annotated unsafe sentence in 86% of cases for response-only content.

Stream Qwen3Guard: Training Objective

Stream Qwen3Guard is trained using cross-entropy loss to jointly optimize the classification heads for both the user query and the assistant's response. The training objective (Section 4.3) has three components: query loss, response loss, and a conditional category loss mechanism.

Query Loss. Since user queries are processed as complete sequences (the full query is available before classification begins), the classification loss for the query stream is computed only at the final token — specifically, at the special end-of-query token <|im_end|>. This is analogous to how sentence-level classification is done in transformer models: only the representation at the final position aggregates information from the entire sequence.

The query loss $\mathcal{L}_q$ aggregates the cross-entropy losses for predicting the risk level and the safety category:

$\mathcal{L}_q = \mathcal{L}_{q\text{-risk}} + \mathcal{L}_{q\text{-cat}}$

where:

$\mathcal{L}_{q\text{-risk}}$ is the cross-entropy between the predicted risk distribution $\mathbf{y}_{q\text{-risk}}$ at the <|im_end|> token and the ground-truth risk label (which is a one-hot or hard target over {Safe, Controversial, Unsafe}),
$\mathcal{L}_{q\text{-cat}}$ is the cross-entropy between the predicted category distribution $\mathbf{y}_{q\text{-cat}}$ at the <|im_end|> token and the ground-truth category label (a one-hot or hard target over the 9 query categories or a special "None" category for safe content).

Each cross-entropy term is computed as:

$\mathcal{L}_{q\text{-risk}} = -\sum_{c=1}^3 y_{q\text{-risk},c}^{\text{(true)}} \log(y_{q\text{-risk},c}^{\text{(pred)}})$

where $y_{q\text{-risk},c}^{\text{(true)}}$ is 1 for the true class and 0 for others (one-hot encoding), and $y_{q\text{-risk},c}^{\text{(pred)}}$ is the model's predicted probability for class $c$ . The sum over $c$ is across the three severity levels.

What this computes: the standard multiclass cross-entropy — if the true label is "Unsafe" and the model predicts 0.9 for Unsafe, 0.07 for Controversial, 0.03 for Safe, the loss is $-\log(0.9) \approx 0.105$ . If the model predicts 0.6 for Unsafe, the loss is $-\log(0.6) \approx 0.511$ — much higher, penalizing the model for low confidence on the correct class.

Response Loss. To support real-time, token-by-token moderation, the loss for the response stream is computed at every generated token, not just at the end. This is the key difference from the query loss: every token position produces a classification that is compared against the token-level labels derived from the rollout + judge pipeline.

The total response loss $\mathcal{L}_r$ is the average over all $T$ tokens in the response of the combined cross-entropy losses:

$\mathcal{L}_r = \frac{1}{T} \sum_{t=1}^T \left( \mathcal{L}^{(t)}_{r\text{-risk}} + \mathcal{L}^{(t)}_{r\text{-cat}} \right)$

where:

$T$ is the total number of tokens in the assistant's response,
$\mathcal{L}^{(t)}_{r\text{-risk}}$ is the cross-entropy for risk level prediction at token position $t$ ,
$\mathcal{L}^{(t)}_{r\text{-cat}}$ is the cross-entropy for category prediction at token position $t$ ,
The sum is divided by $T$ to average over all token positions, giving equal weight to each position regardless of response length.

What this computes: for a response with $T$ tokens, the model makes $T$ independent risk predictions and $T$ independent category predictions. Each prediction is compared against the token-level label for that position. The loss encourages the model to correctly classify each token's safety status based on the partial context available up to that point.

Why average over all tokens rather than sum? Averaging makes the loss magnitude independent of sequence length, which stabilizes training across batches with varying response lengths. If a sum were used, longer responses would dominate the gradient signal, causing the model to optimize primarily for long responses at the expense of short ones.

Conditional Category Loss. A conditional mechanism is applied to the safety category losses for both query and response streams. The paper states:

"the category loss is computed only when the corresponding ground-truth risk level is labeled as 'unsafe' or 'controversial.' If the true risk level is 'safe,' the category loss is omitted from the total loss calculation."

Formally, the category loss terms $\mathcal{L}_{q\text{-cat}}$ and $\mathcal{L}^{(t)}_{r\text{-cat}}$ are multiplied by an indicator $\mathbb{I}[\text{true risk} \neq \text{Safe}]$ :

$\mathcal{L}_{q\text{-cat}}^{\text{(effective)}} = \mathbb{I}[y_{q}^{\text{(true)}} \neq \text{Safe}] \cdot \mathcal{L}_{q\text{-cat}}$ $\mathcal{L}^{(t)\text{(effective)}}_{r\text{-cat}} = \mathbb{I}[y_{r,t}^{\text{(true)}} \neq \text{Safe}] \cdot \mathcal{L}^{(t)}_{r\text{-cat}}$

Why this conditional mechanism is necessary: when content is safe, there is no meaningful category to predict — all categories represent types of harm. Without the conditional mechanism, the model would be forced to predict a category for safe tokens, and the only reasonable target would be a special "None" category. This creates two problems: first, the "None" class would dominate the category loss (most tokens in most responses are safe, even in responses that are eventually flagged as unsafe overall), causing the model to optimize primarily for predicting "None" correctly rather than learning fine-grained harm categories. Second, the category prediction task for safe tokens is ill-posed — there is no single correct category, so the model receives noisy or arbitrary supervision.

The conditional mechanism eliminates both problems: the category head is simply not trained on safe tokens, focusing its capacity on the subset of tokens where fine-grained category information is available and meaningful. This also aligns with the deployment use case: when Stream Qwen3Guard predicts "Safe" for a token, the category output is ignored; only when it predicts "Unsafe" or "Controversial" is the category consulted for intervention decisions.

Stream Qwen3Guard: Evaluation-Specific Mechanisms

The evaluation of Stream Qwen3Guard (Section 4.4) uses the same datasets and metrics as Generative Qwen3Guard (described in Section 3.4), but with two additional evaluation dimensions specific to streaming: detection latency and computational efficiency.

Latency evaluation dataset construction. The paper constructs two test sets for latency evaluation using sentence-level annotation rather than token-level annotation, explicitly acknowledging "the inherent challenges and low inter-annotator agreement associated with token-level annotation" (Section 4.4). The construction process:

For each sample, the model's response is segmented into individual sentences.
Human annotators identify the earliest sentence in which the content becomes unsafe or controversial (see Appendix Table 17 for a concrete example where sentence 2 of a 4-sentence response is annotated as the first unsafe sentence).
Samples with inconsistent annotations across annotators are filtered out.
The resulting datasets are: 813 labeled samples for response-only content, and 569 samples that include both thinking traces and final responses.

Latency metric: token-relative detection position. For each sample, the evaluation measures how many tokens after the ground-truth unsafe sentence begins does Stream Qwen3Guard flag the content. The results are binned into ranges: "Ahead" (model detected unsafe content before the annotated sentence — a false positive or earlier-than-expected detection), "Hit" (detection within the annotated sentence — the ideal case), "1-32" (detection within 32 tokens after the annotated sentence begins), and progressively larger ranges (33-64, 65-128, 129-256, >256, or Safe if never flagged).

Why sentence-level annotation is used for latency but not for training: during training (Section 4.3), the loss is computed at every token using the automatically derived token-level labels from the rollout + judge pipeline. During evaluation, comparing the model's token-level predictions against human judgments requires human annotations. Human annotators cannot reliably identify the exact token at which content becomes unsafe (inter-annotator agreement studies in related fields typically show low agreement at the token level), but they can reliably identify the sentence. The sentence-level evaluation provides an upper bound on acceptable detection latency — if the model flags content within the same sentence that humans consider unsafe, it is achieving near-optimal detection.

Efficiency comparison methodology (Figure 9). To quantify the computational advantage of Stream Qwen3Guard over using Generative Qwen3Guard in a streaming context, the paper simulates a naive streaming deployment of the generative model. The simulation procedure:

Each response is segmented into 32-token chunks.
Upon receiving each new chunk, the entire accumulated response up to that point is re-submitted to Generative Qwen3Guard for classification.
This process repeats until generation is completed — for a 1024-token response, the generative model is called 32 times (1024 ÷ 32), each time on a progressively longer input.
Stream Qwen3Guard processes each token exactly once, without re-evaluating prior tokens.

The relative time metric is normalized to "the time Generative Qwen3Guard takes to moderate its initial 32-token chunk." The results (Figure 9) show that Stream Qwen3Guard's processing time "scales nearly linearly with response length" while Generative Qwen3Guard "incurs substantially higher computational overhead as responses grow longer."

Why the generative approach scales poorly in streaming: the computational cost of transformer inference scales approximately quadratically with sequence length (due to self-attention over all token pairs). Re-evaluating the full accumulated response at each chunk means processing tokens 1–32 at step 1, tokens 1–64 at step 2, tokens 1–96 at step 3, and so on. The total compute grows as approximately $O(N^2)$ for an $N$ -token response. Stream Qwen3Guard processes each token once, with the self-attention cost for each position depending only on preceding tokens (which are already computed and cached in the KV cache during streaming generation), resulting in $O(N)$ total compute. This difference becomes dramatic for long responses, as shown in Figure 9.

4. Key Insights and Innovations

Innovation 1: The "Controversial" Category Is Not a Label Refinement — It Is a Policy Abstraction Layer

The most intellectually distinctive move in this paper is not the introduction of a third safety label, but the recognition that safety classification is fundamentally a policy-execution problem, not a content-analysis problem. Prior guard models (LlamaGuard, ShieldGemma, WildGuard, PolyGuard) treated safety as an objective property of text to be detected — a content either is or is not harmful, and the guard model's job is to determine which. The paper's central reframing is that safety judgments are conditional on the policy being applied, and different deployments legitimately require different policies. The "controversial" category is the technical embodiment of this insight: it explicitly models the region of input space where policy choice matters.

This is not incremental. Before Qwen3Guard, the dominant assumption was that guard models should converge toward a single ground-truth safety judgment for each input — disagreements between models or benchmarks were framed as errors or inconsistencies to be resolved through better training data or more accurate models. The paper's Figure 4 (precision-recall scatter plots across Aegis vs. OpenAIModeration) demonstrates that this assumption is wrong at a definitional level, not just a measurement level. WildGuard-7B achieves strong alignment with Aegis (high precision, high recall) but is "overly conservative" on OpenAIModeration. This is not a model quality problem that better training would fix — it reflects that the two benchmarks encode different safety policies, and a binary model forced to output a single judgment must necessarily fail to satisfy both simultaneously.

What makes this a conceptual innovation rather than a labeling trick is that the controversial category is emergent from model behavior under distribution shift, not manually annotated. The paper's controversial label construction pipeline (Section 3.3, Figure 3) does not ask humans to identify ambiguous cases — it trains two models with intentionally skewed safe/unsafe ratios (Strict and Loose), cross-annotates held-out data, and marks cases where the models disagree as Controversial. This operationalizes "controversial" as "cases where a conservative policy and a permissive policy make different decisions," which is exactly the right definition for a guard model that must serve diverse deployment contexts. The alternative — asking human annotators to produce tri-class labels directly — would conflate the policy ambiguity problem with annotator subjectivity, producing labels that reflect individual annotators' personal safety views rather than the structural property of policy-dependence.

The two-mode evaluation (Strict vs. Loose, with optimal mode selected per benchmark) is not a post-hoc score-boosting trick. It is the intended deployment pattern: a single Qwen3Guard model serves both a permissive deployment (where controversial content is treated as safe, appropriate for creative writing platforms) and a conservative deployment (where controversial content is treated as unsafe, appropriate for children's educational tools) without retraining or threshold adjustment. This is a fundamental shift from the prior paradigm where each deployment either accepted the model's baked-in policy or attempted to adjust decision thresholds post-hoc — a fragile approach that, as the paper notes, can trade precision against recall but cannot capture cases where the label itself is inherently ambiguous.

The significance extends beyond guard models. The paper effectively demonstrates that safety policy is a first-class input to the classification system, not a fixed assumption. This suggests a future where guard models are explicitly conditioned on a policy specification (as Generative Qwen3Guard already does via its instruction template) and where evaluation benchmarks report policy-dependent performance rather than single-number metrics. The paper's finding that "policy inconsistency is notably more pronounced in prompt classification than in response classification" (Section 3.4.1) is itself a valuable diagnostic: it reveals that the field's implicit risk-tolerance philosophies (trust-but-verify vs. prevent-at-source) have been silently encoded in benchmark construction, producing apparently conflicting results that are actually measuring different things.

Innovation 2: Training Data Distribution as a Policy Knob — The Two-Model Skew Method

The paper's method for building controversial labels (Figure 3) is not just a data augmentation technique — it is a principled method for controlling a classifier's decision boundary through training data composition, applied to a problem where the ground-truth label distribution is itself ambiguous. This is conceptually novel because it inverts the standard machine learning assumption that training data labels are fixed and the model learns to approximate them. Instead, the paper treats the safe/unsafe ratio in training data as a tunable parameter that shifts the model's effective safety policy, then uses the disagreement between differently-tuned models to discover the boundary region.

Prior work on policy adaptation for guard models took two approaches, neither satisfactory. ShieldGemma (Zeng et al., 2024) adjusts classifier thresholds post-hoc — changing the decision boundary of a fixed binary classifier. This can trade precision for recall but cannot change which inputs are considered borderline, because the model's internal representation of safety was learned from a fixed training distribution. Zhang et al. (2024) annotated controversial labels using rule-based heuristics, which can identify clear cases but misses the nuance of model-specific ambiguity — a case that is ambiguous for one model architecture may be clear-cut for another.

The paper's method is more fundamental because it discovers ambiguity from model behavior rather than imposing it through annotation rules. Concretely: training two models on the same data but with different sampling ratios produces two different decision boundaries. Instances that fall between these boundaries — classified as safe by the permissive model and unsafe by the strict model — are precisely those where the training data provides insufficient signal to pin down a single correct answer. These are the genuinely controversial cases, and the paper shows that labeling them as a distinct third category during training (rather than forcing them into binary labels) improves performance across benchmarks with different implicit policies (Table 8: with controversial labels, the optimal Strict/Loose mode outperforms the binary baseline on most benchmarks, with particularly large gains on ToxicChat and OpenAIModeration where policy mismatch is most severe).

This method has implications beyond guard models. Any classification task where the "correct" label depends on context, policy, or risk tolerance — content moderation at social media platforms, medical diagnosis with varying treatment thresholds, fraud detection with different false-positive tolerances — could benefit from explicitly modeling the policy-dependent region rather than collapsing it into a binary decision. The paper does not claim this generality, but the pattern is transferable.

The distillation step (Table 9, average F1 improvement of +0.47 to +1.10 points) shows that even after discovering controversial labels through model disagreement, there is room for refinement through knowledge distillation from a larger teacher. This two-stage process — discover ambiguity through distribution shift, then refine labels through distillation — is an interesting training paradigm that the paper does not fully explore as a general method, but it demonstrates that the controversial label pipeline is robust to initial label noise.

Innovation 3: Token-Level Safety as a Sequence Labeling Problem with Two-Stage Validation

Prior work on streaming safety detection (Sharma et al., 2025; Xuan et al., 2025; Li et al., 2025a) attempted to convert sample-level safety labels into token-level supervision through various approximation methods — sentence-level heuristics, indirect learning signals, or weak supervision from language model judgments. The paper's key conceptual advance is recognizing that identifying the first unsafe token in a response is fundamentally a causal inference problem, not a classification problem: you need to determine whether token S_i causes subsequent content to be unsafe, which is distinct from whether token S_i contains unsafe content in isolation.

The two-stage validation pipeline (rollout-based assessment + LLM-as-judge verification, Section 4.2) operationalizes this distinction. The rollout stage asks a forward-looking question: "If we complete the response from this prefix, do the completions tend to be unsafe?" This measures whether the prefix enables harmful content. The judge stage asks a backward-looking question: "Is the content up to this point, taken on its own, already unsafe?" This measures whether the prefix contains harmful content. The conjunction — requiring both stages to agree — captures the earliest token where content is both already harmful and likely to lead to further harm.

This is not a minor refinement of prior token-level approaches. The paper explicitly identifies the failure mode of rollout-only methods: "Even when a token S_i itself is safe/harmless, the rollouts may contain a high proportion of unsafe continuations because language models can be susceptible to generating harmful content regardless of the specific prompting token." A prefix like "I can help you with that. Here are some methods:" is safe in isolation (the judge would say safe), but rollouts from this prefix would overwhelmingly produce harmful completions because base models tend toward unsafe generation when prompted with any request for information. A rollout-only method would incorrectly label this prefix as unsafe, pushing the detection point earlier than the true onset of harm.

Conversely, judge-only methods would miss cases where the prefix is ambiguous but not yet harmful — "Here's what you need to know about" might be judged safe on its own, but if the next tokens are "synthesizing explosives," the prefix was genuinely the beginning of unsafe content. The rollout method catches this because completions from this prefix are mostly unsafe.

The 85% rollout threshold (determined through pilot experiments to align with human annotations) and the Qwen3-235B-A22B judge choice are engineering decisions, but the two-stage structure itself is the conceptual contribution: it decomposes the problem of finding the first unsafe token into two simpler questions that can be answered with off-the-shelf tools (a generative guard model for rollout evaluation, an LLM-as-judge for prefix evaluation), then combines them with a logical AND. This decomposition is general — any system that needs to identify the onset of harmful content in a sequence could apply the same two-stage logic, regardless of the specific rollout model or judge model used.

The latency evaluation (Figure 8) validates that this approach produces practically useful token-level labels: Stream Qwen3Guard trained on these labels achieves an "exact hit rate of nearly 86.0%" on response-only content, meaning the first flagged token falls within the human-annotated unsafe sentence in 86% of cases. This is not a perfect detection-at-first-unsafe-token rate — the debouncing mechanism adds a one-token delay, and model errors can shift the detection point — but it demonstrates that the two-stage labeling pipeline produces supervision signals that teach the model to detect harm close to its actual onset.

Innovation 4: The Training-Inference Tradeoff for Guard Models — A Guard Model 10× Smaller Can Match Larger Counterparts

The paper makes an empirical claim that has significant practical implications but is often underappreciated in guard model research: guard model performance is not monotonic in parameter count. The Qwen3Guard-0.6B-Gen model "rivals or exceeds the performance of existing Guard models that are more than 10× larger" (Section 3.4.1). Specifically, Qwen3Guard-0.6B-Gen achieves an average F1 of 88.1% on English prompt classification (Table 2) and 82.0% on English response classification (Table 3), outperforming ShieldGemma-27B (70.0% and 65.9% respectively, a model 45× larger) and competing with LlamaGuard4-12B (75.9% and 67.5%).

This is not just a "smaller models can be good" observation — it is a finding about the relationship between foundation model quality and guard model quality. Qwen3Guard is built on Qwen3, which is a more recent and capable foundation model family than the Gemma-2 backbone used by ShieldGemma or the Llama-4 backbone used by LlamaGuard4 (though the paper does not explicitly state this comparative foundation model analysis, the performance gap strongly suggests it). The implication is that guard model performance depends more on the quality of the underlying language understanding than on raw parameter count — a 0.6B model with strong multilingual pretraining and instruction tuning can outperform a 27B model with weaker foundations on a task that requires nuanced understanding of harmful content across languages and cultural contexts.

The practical significance is substantial: deploying a guard model alongside an LLM assistant doubles the inference compute budget. If the guard model must be a 7B+ parameter model to be effective, the total system cost becomes prohibitive for many deployments — especially on-device or edge scenarios. The 0.6B Qwen3Guard variant makes guard model deployment feasible in resource-constrained environments where running a separate 7B+ model is impossible. The paper does not conduct a detailed FLOPs or latency analysis of the 0.6B model, but the parameter count alone implies it can run on consumer hardware or mobile devices where larger guard models cannot.

This finding also challenges the field's implicit assumption that guard model research should focus on scaling up — larger models with more parameters, more training data, more reasoning capabilities (as in GuardReasoner and DuoGuard). The paper's results suggest that foundation model selection and training data quality (the 1.19M+ carefully constructed samples with controversial labels, multilingual coverage, and paired positive-negative examples) may be more important levers than parameter count for guard model performance. The 4B and 8B variants do outperform the 0.6B variant (89.3% and 90.0% on English prompts respectively vs. 88.1%), but the marginal gain from 0.6B to 8B (approximately +2 points) is small relative to the gain from any prior model to Qwen3Guard-0.6B (approximately +8 points over LlamaGuard3-8B). This suggests diminishing returns to scale beyond a certain foundation model quality threshold.

5. Experimental Analysis

Evaluation Methodology

Dataset. The paper evaluates on a comprehensive suite of English, Chinese, and multilingual benchmarks for both prompt and response classification. For English prompt classification (Section 3.4), the benchmarks are: ToxicChat (Lin et al., 2023), OpenAIModeration (Markov et al., 2023), Aegis (Ghosh et al., 2024), Aegis2.0 (Ghosh et al., 2025), SimpleSafetyTests (SimpST; Vidgen et al., 2024), HarmBench (Mazeika et al., 2024), and WildguardTest (WildG; Han et al., 2024). For English response classification, the benchmarks are: HarmBench, SafeRLHF (Ji et al., 2025), Beavertails (Ji et al., 2023), XSTest (Röttger et al., 2024), Aegis2.0, WildguardTest, and an additional "Think" dataset — constructed by generating reasoning traces and responses from existing reasoning models using Beavertails prompts, then manually annotating the outputs — introduced to evaluate moderation of internal reasoning content, which is a novel challenge for guard models. For Chinese evaluation (Section 3.4), the paper uses translated versions of ToxicChat, WildGuardTest, XSTest, and Beavertails (translated via Qwen3-MT), plus an in-house dataset called PolST related to political sensitive topics containing 1,412 prompts and 4,038 responses, with 862 harmful prompts and 2,019 harmful responses. For multilingual evaluation, the paper uses RTP-LX (De Wynter et al., 2025) and PolyGuard-Prompt (Kumar et al., 2025) for prompt classification, and PolyGuard-Response for response classification, covering 10 major languages plus 30 additional languages in an "Others" category. This breadth — 14+ English benchmarks, 4 Chinese benchmarks, and 2 multilingual benchmarks spanning 40+ languages — is notably comprehensive for guard model evaluation. The test data, including the newly constructed Think and latency evaluation datasets, is publicly available at https://huggingface.co/datasets/Qwen/Qwen3GuardTest.

Base models. Generative Qwen3Guard is built on the Qwen3 instruction-tuned foundation models (Yang et al., 2025a) at three scales: 0.6B, 4B, and 8B parameters. Stream Qwen3Guard uses the same Qwen3 pretrained transformer backbones but replaces the generative output head with token-level classification heads. The paper does not provide detailed architectural specifications for the Qwen3 models, referring readers to the Qwen3 technical report. The choice of Qwen3 is motivated by its strong multilingual capabilities (supporting 119 languages and dialects) and instruction-following capabilities, which are essential for the generative variant's prompt-based task formulation. The three size variants address different deployment constraints: the 0.6B model is suitable for resource-constrained or on-device deployment, while the 4B and 8B models provide progressively higher accuracy for scenarios where compute is less constrained.

Metrics. The primary evaluation metric is the F1 score for harmful classification, computed as the harmonic mean of precision and recall. Precision measures the fraction of model-flagged unsafe content that is genuinely unsafe; recall measures the fraction of genuinely unsafe content that the model successfully flags. F1 balances these two quantities, providing a single-number summary of binary classification quality that is robust to class imbalance. For Generative Qwen3Guard, which outputs tri-class labels (Safe, Controversial, Unsafe), F1 is computed in two modes: Strict mode treats Controversial predictions as Unsafe, while Loose mode treats Controversial predictions as Safe. The optimal mode is selected per benchmark, and the selected scores are underlined in all tables. This evaluation protocol directly operationalizes the paper's claim that the Controversial label enables adaptation to different safety policies — the per-benchmark mode selection mirrors what a deployment would do when matching its policy to the target application's risk tolerance. For Stream Qwen3Guard, the same F1 protocol applies, with token-level predictions debounced and aggregated to sample-level labels for comparison. Additional metrics include: (a) precision-recall scatter plots (Figure 4) to visualize policy inconsistency across benchmarks; (b) confusion matrices for category classification (Figures 5 and 12); (c) refusal detection F1, precision, and recall (Table 7); (d) detection latency measured in token-relative ranges (Figure 8); (e) relative moderation time for efficiency comparison (Figure 9); (f) safety rate and quality scores for RL applications (Tables 10 and 16); and (g) wait tokens for intervention latency (Table 16).

Baselines. The paper compares against seven existing guard models across all evaluation settings:

LlamaGuard3-8B (Grattafiori et al., 2024): An 8B-parameter instruction-following guard model based on Llama 3, providing binary safe/unsafe classifications with safety categories. Evaluated on all English, Chinese, and multilingual benchmarks.
LlamaGuard4-12B (Chi et al., 2024): A 12B-parameter successor to LlamaGuard3, also providing binary classifications. Evaluated on all benchmarks.
WildGuard-7B (Han et al., 2024): A 7B-parameter guard model that adds refusal detection to binary safety classification. Evaluated on all benchmarks. The paper specifically highlights this model in the policy inconsistency analysis (Figure 4).
ShieldGemma-9B and ShieldGemma-27B (Zeng et al., 2024): Guard models based on the Gemma architecture at 9B and 27B parameters, which attempt to address policy inconsistency through dynamic classifier threshold adjustment. Evaluated on all benchmarks.
NemoGuard-8B (Nemotron Safety Guard V2; Ghosh et al., 2025): An 8B-parameter guard model. Evaluated on all benchmarks.
PolyGuard-Qwen-7B (Kumar et al., 2025): A 7B-parameter multilingual guard model based on Qwen-7B, supporting 17 languages. Evaluated on all benchmarks.

Notably, the paper does not include comparisons against more recent guard models that incorporate explicit reasoning, such as DuoGuard (Deng et al., 2025) or GuardReasoner (Liu et al., 2025), even though these are mentioned in the Related Work section (Section 5). This omission is not explained but may reflect the focus on deployment-oriented guard models where latency and cost constraints preclude reasoning-based approaches.

Generation budget / compute accounting. The paper does not explicitly define a "generation budget" for fair comparison in the main safety classification experiments — all models are evaluated on their ability to classify safety on the same test sets, with no compute constraint applied during evaluation. This is standard for guard model benchmarking: the models are compared on accuracy metrics without accounting for their inference cost. The efficiency comparison between Generative and Stream Qwen3Guard (Figure 9) uses a different methodology: a simulated streaming moderation scenario where responses are segmented into 32-token chunks, and the relative computation time is normalized to the time Generative Qwen3Guard takes to moderate its initial 32-token chunk. This is a wall-clock-time comparison under a specific simulation protocol, not a FLOPs-matched comparison. The paper does not report absolute inference times, hardware specifications, or FLOPs counts for any model or benchmark. This is a notable gap — while the paper emphasizes that Stream Qwen3Guard is more "efficient" than using Generative Qwen3Guard for streaming (Figure 9), no absolute efficiency metrics or cost comparisons against other guard models are provided. A practitioner choosing between deploying Qwen3Guard-0.6B-Stream and, say, WildGuard-7B cannot determine from this paper which is more computationally efficient at equivalent accuracy, because the per-sample inference costs are never quantified.

Cross-validation / statistical protocol. For the compute-optimal strategy selection in Generative Qwen3Guard (Section 3.4.1), the paper uses two-fold cross-validation within the safety classification evaluation: the Strict vs. Loose mode selection is based on the optimal per-benchmark performance, and the average scores reported in tables represent the best mode for each benchmark (the scores in Strict and Loose modes are both reported, and the underlined scores indicate the selected mode, with the average computed from the selected scores). The paper does not report confidence intervals, standard deviations, or statistical significance tests for any of the F1 scores in Tables 2–6 and 11–15. Given the relatively small size of some test sets (e.g., the PolST dataset has 1,412 prompts, and the Think dataset is manually annotated from an unspecified number of samples), the absence of variance estimates makes it difficult to assess whether observed differences between models (e.g., Qwen3Guard-8B-Gen at 90.0% vs. PolyGuard-Qwen-7B at 87.0% on English prompt classification) are statistically reliable or within the margin of sampling error. For the RL experiments (Section 3.5), the paper does not describe any cross-validation protocol — the training uses the WildJailbreak training set (13.7k samples for thinking mode, 6.7k for non-thinking mode), and evaluation is on the WildJailbreak test set (2,000 harmful prompts and 210 benign prompts). Results are reported as single-point estimates in Table 10.

Main Quantitative Results

Safety Classification: English Prompt Benchmarks

The headline result for English prompt classification (Table 2) is that Qwen3Guard-8B-Gen achieves an average F1 of 90.0% across seven benchmarks, with Qwen3Guard-4B-Gen at 89.3% and Qwen3Guard-0.6B-Gen at 88.1% — all three variants outperforming or matching prior state-of-the-art models while using substantially fewer parameters. The best prior model on this average metric is PolyGuard-Qwen-7B at 87.0%, followed by WildGuard-7B at 85.8%, NemoGuard-8B at 82.9%, and LlamaGuard3-8B at 79.4%.

Breaking down by benchmark reveals the policy inconsistency problem in sharp relief. On Aegis, which the paper identifies as having a stricter safety policy, Qwen3Guard-8B-Gen achieves its best F1 in Strict mode: 91.4% (compared to 76.0% in Loose mode), outperforming WildGuard-7B's 89.4% and matching the benchmark's implicit policy. On OpenAIModeration, which the paper identifies as more permissive, the same model achieves its best F1 in Loose mode: 81.3% (compared to 68.8% in Strict mode, a 12.5-point swing), outperforming ShieldGemma-9B's 82.1% and WildGuard-7B's 72.1%. This demonstrates that the Controversial label enables the model to adapt to different implicit policies, but the adaptation requires selecting the appropriate mode. The per-benchmark optimal mode varies systematically: Aegis and Aegis2.0 favor Strict mode (higher scores when Controversial is treated as Unsafe), while ToxicChat, OpenAIModeration, and XSTest favor Loose mode (higher scores when Controversial is treated as Safe). WildGuardTest and SimpleSafetyTests show more balanced performance across modes.

The Qwen3Guard-0.6B-Gen results deserve specific attention: at 0.6B parameters, it achieves 88.1% average F1, outperforming LlamaGuard3-8B (79.4%, 13× larger), LlamaGuard4-12B (75.9%, 20× larger), ShieldGemma-27B (70.0%, 45× larger), and NemoGuard-8B (82.9%, 13× larger). This efficiency is the paper's "more than 10× larger" claim in action — a 0.6B model matching or exceeding models that are 13–45× its parameter count. The most extreme case is ShieldGemma-27B on HarmBench: Qwen3Guard-0.6B-Gen achieves 98.7% in Strict mode, while ShieldGemma-27B achieves only 57.3% — a 41.4-point gap that likely reflects foundation model quality differences (Qwen3 vs. Gemma-2 backbones) more than guard-specific training methodology.

Safety Classification: English Response Benchmarks

The English response classification results (Table 3) show a similar pattern but with lower absolute scores across all models, indicating that response safety classification is a harder task than prompt classification. Qwen3Guard-8B-Gen achieves an average F1 of 83.9% across seven benchmarks, essentially tied with Qwen3Guard-4B-Gen at 83.7% and outperforming WildGuard-7B at 79.9%, NemoGuard-8B at 78.1%, and LlamaGuard3-8B at 70.7%.

The newly introduced "Think" benchmark — evaluating safety classification on internal reasoning traces generated by reasoning models — reveals a significant capability gap between Qwen3Guard and prior guard models. Qwen3Guard-4B-Gen achieves 84.0% F1 on the Think benchmark; the next best prior model is PolyGuard-Qwen-7B at 81.1%, followed by NemoGuard-8B at 77.9% and WildGuard-7B at 71.4%. The paper emphasizes that "evaluating the safety of internal reasoning traces ('thinking content') is a novel challenge for Guard models, since the outputs are often informal, unstructured, and lengthy." The 2.9-point advantage over PolyGuard and 12.6-point advantage over WildGuard represents a meaningful capability gain specifically on the type of content that is becoming increasingly important as reasoning models are more widely deployed. However, the absolute score of 84.0% indicates that even the best model misses approximately 16% of unsafe thinking content — a non-trivial failure rate for safety-critical applications.

The Strict vs. Loose mode patterns for response classification differ from prompt classification. On several benchmarks (HarmBench, SafeRLHF, Beavertails, WildGuardTest), Strict mode consistently outperforms Loose mode by 1–6 points, suggesting that most response benchmarks are designed with a relatively conservative safety policy where flagging borderline content is preferred over missing it. This aligns with the paper's hypothesis that policy inconsistency is "notably more pronounced in prompt classification" — response benchmarks appear to agree more on what constitutes unsafe content, perhaps because harmful model outputs are more objectively identifiable than harmful user intent.

The refusal detection results (Table 7) show Qwen3Guard achieving comparable or better performance than WildGuard-7B (the only baseline for which refusal detection scores are reported). On XSTest, Qwen3Guard-4B-Gen achieves 94.6% F1 vs. WildGuard-7B's 93.3%; on WildGuardTest, Qwen3Guard-4B-Gen achieves 90.2% F1 vs. WildGuard-7B's 88.6%. Refusal detection is relevant because a model that refuses to answer a harmful query should not itself be flagged as producing unsafe content — the refusal is a safe response, and correctly distinguishing it from genuine harmful content prevents false alarms.

Safety Classification: Chinese Benchmarks

The Chinese prompt and response classification results (Table 4) demonstrate Qwen3Guard's strong multilingual transfer, but also reveal substantial performance variation across benchmarks that highlights the challenges of non-English safety evaluation. Qwen3Guard-8B-Gen achieves an average F1 of 85.1% on Chinese prompt classification and 87.1% on Chinese response classification — notably, the response scores are higher than the prompt scores, which is the opposite of the English pattern where prompts were generally easier.

The PolST benchmark — an in-house political sensitive topics dataset — reveals dramatic variation across models. Qwen3Guard achieves its highest scores on this benchmark: Qwen3Guard-8B-Gen at 88.6% (Strict mode) for prompts and 90.4% (Strict) for responses. In contrast, prior guard models perform abysmally: LlamaGuard3-8B at 19.8% (prompts) and 28.0% (responses), WildGuard-7B at 17.8% and 17.7%, ShieldGemma-27B at 15.3% and 21.4%, NemoGuard-8B at 5.7% and 26.3%. The 60–85 point gap between Qwen3Guard and prior models on PolST suggests that existing guard models have essentially no capability to detect politically sensitive content in Chinese — they are performing near or below chance for this specific harm category. The paper does not discuss this finding in detail, but it likely reflects the training data composition: Qwen3Guard's dataset includes substantial Chinese content (26.64% of total, per Table 1), including specifically political sensitive topics, while existing guard models are predominantly English-trained and have minimal or no Chinese political safety data.

This finding also complicates the paper's overall narrative about Qwen3Guard being generally state-of-the-art across languages. On Chinese ToxicChat, Qwen3Guard-8B-Gen achieves 68.0% in Strict mode — worse than PolyGuard-Qwen-7B at 69.7% and ShieldGemma-27B at 67.2%. On Chinese WildGuardTest, Qwen3Guard-8B-Gen achieves 88.0% — slightly better than PolyGuard at 87.2%. The Chinese results are strong overall but not uniformly dominant; Qwen3Guard's particular strength appears to be on political and region-specific safety topics (PolST) that prior guard models ignore entirely, while its performance on more general Chinese safety tasks is competitive but not always leading.

Safety Classification: Multilingual Benchmarks

The multilingual evaluation (Tables 5 and 6) is the paper's most extensive test of Qwen3Guard's language generalization claims. On multilingual prompts (RTP-LX), Qwen3Guard-8B-Gen achieves an average F1 of 85.0% across 10 major languages and 30 additional languages in the "Others" category — substantially outperforming PolyGuard-Qwen-7B at 80.9%, and dramatically outperforming ShieldGemma-27B at 61.4%, WildGuard-7B at 43.9%, NemoGuard-8B at 42.7%, and LlamaGuard4-12B at 41.7%.

The language-level breakdown reveals important patterns. Qwen3Guard-8B-Gen achieves particularly strong results on Russian (91.9%), Japanese (91.3%), Chinese (90.6%), and French (90.8%) — all languages with substantial training data representation in Table 1. Performance is weakest on Indonesian (75.3%), Arabic (88.4%), and Korean (86.2%). The "Others" category (aggregating 30 languages with limited training coverage) achieves 83.9% — notably higher than Indonesian (75.3%), which actually has more explicit training data coverage (5.36% of total). This puzzling result suggests that either the "Others" languages are easier on average (perhaps more closely related to high-resource languages) or the RTP-LX benchmark has annotation quality issues that inflate scores for certain language subsets.

On multilingual responses (PolyGuard-Response, Table 6), the performance gaps are narrower. Qwen3Guard-4B-Gen achieves 78.1% average F1 vs. PolyGuard-Qwen-7B at 74.0%, NemoGuard-8B at 69.5%, and WildGuard-7B at 63.5%. The 4B model slightly outperforms the 8B model (78.1% vs. 77.6%), which is unusual and likely reflects noise in a relatively small response test set rather than a genuine inverse scaling relationship. The response scores are generally lower than prompt scores across all models, consistent with the English pattern where response classification is harder.

A notable pattern in the multilingual response results: the Strict vs. Loose mode distinction is much less impactful than in the English or Chinese prompt benchmarks. Across all three Qwen3Guard sizes on PolyGuard-Response, the Strict and Loose scores differ by only 1–2 points, and in several cases the Loose score actually exceeds the Strict score. This suggests that the PolyGuard-Response benchmark has a relatively consistent safety policy where the Controversial label provides less benefit — perhaps because response safety is more objectively assessable across languages than prompt intent.

Stream Qwen3Guard vs. Generative Qwen3Guard: Performance Comparison

The comparison between Stream and Generative Qwen3Guard (Tables 11–15) quantifies the accuracy cost of enabling streaming capability. Across English prompts, Stream Qwen3Guard-8B averages 88.3% F1 vs. Generative Qwen3Guard-8B at 90.0% — a 1.7-point degradation. On English responses, the gap is slightly larger: Stream Qwen3Guard-8B at 81.1% vs. Generative at 83.9%, a 2.8-point gap. The paper characterizes this as "a marginal decline" and "only modest performance degradation," which is accurate in relative terms (the accuracy loss is approximately 2–3%) but may be significant in absolute terms for safety-critical deployments where every missed unsafe sample represents potential harm.

The degradation is not uniform across benchmarks. On HarmBench (English response), the gap is 2.2 points (87.2% Gen vs. 85.0% Stream). On XSTest (English response), the gap is larger at 4.6 points (92.1% Gen vs. 87.5% Stream). On the Think benchmark, the gap is essentially zero: 84.0% Gen vs. 83.6% Stream. This suggests that the streaming architecture's partial-context limitation matters most when safety classification requires understanding of extended context or implicit meaning, and matters least when safety-relevant content is localized to specific spans of text.

On Chinese benchmarks (Table 13), the Stream vs. Gen gap follows similar patterns: on Chinese prompt classification, Qwen3Guard-8B-Stream averages 84.4% vs. Gen's 85.1% (0.7-point gap); on Chinese responses, Stream averages 85.0% vs. Gen's 87.1% (2.1-point gap). The PolST benchmark — where prior models performed at near-zero — shows Stream at 88.9% (prompts) and 90.9% (responses), essentially matching Gen's performance. This suggests that political content detection relies less on extended context and more on keyword-level or phrase-level signals that are accessible even with partial-context classification.

On multilingual prompts (RTP-LX, Table 14), the gap widens substantially. Qwen3Guard-8B-Stream averages 82.7% vs. Gen's 85.0% across 10 major languages — a 2.3-point gap — but the language-level breakdown shows much larger drops for lower-resource languages: Korean drops from 86.2% (Gen) to 83.1% (Stream, a 3.1-point drop), Russian from 91.9% to 90.3% (1.6 points), and the "Others" category from 83.9% to 81.9% (2.0 points). This suggests that the streaming architecture's accuracy penalty compounds with language difficulty — when the base language understanding is weaker (due to less training data), the additional constraint of partial-context evaluation causes proportionally larger degradation.

On multilingual responses (PolyGuard-Response, Table 15), the gap is relatively consistent at 1.5–2.5 points across languages, with Stream Qwen3Guard-4B surprisingly outperforming the 8B Stream variant on several languages (e.g., French: 77.0% Stream-4B vs. 76.2% Stream-8B in Loose mode). This again suggests noise in the test set or suboptimal calibration of the larger Stream model on this benchmark.

Detection Latency and Efficiency of Stream Qwen3Guard

The latency evaluation (Figure 8) is the paper's key evidence that Stream Qwen3Guard can detect unsafe content early enough for practical real-time intervention. For response-only content, Stream Qwen3Guard-8B achieves an "exact hit rate of nearly 86.0%" — in the majority of cases, the first token flagged by the model as triggering unsafe content falls within the sentence annotated by human evaluators as the earliest unsafe sentence. The detailed distribution: 37 cases where the model detected ahead of the annotated sentence (potential false positives or detection before the annotated boundary), 694 cases of exact hits (detection within the annotated sentence), 15 cases within 1–32 tokens after the sentence boundary, 3 cases at 33+ tokens after, and 64 cases where the content was never flagged as unsafe (potential false negatives). The Stream-4B model shows a similar distribution with slightly more ahead-of-annotation detections (39 cases).

For content that includes thinking traces (the model's internal reasoning before its final response), detection is more challenging. Stream Qwen3Guard-8B detects unsafe content within the first 128 tokens in "approximately 66.8% of cases" (the paper's phrasing; computing from Figure 8: 25 + 27 + 96 + 94 + 126 = 368 out of the approximately 569 samples shown in the bottom panels, giving ~64.7% within 128 tokens, but the distribution includes additional bins). The detection is spread across wider latency ranges: 25 cases detected ahead, 27 at exact hit, 96 within 1–32 tokens, 94 within 33–64 tokens, 126 within 65–128 tokens, 82 within 129–256 tokens, 27 beyond 256 tokens, and 92 cases where the content was never flagged. The paper attributes the increased difficulty to "the informal and unstructured nature of reasoning traces" — thinking content often contains fragmented thoughts, self-corrections, and ambiguous phrasings that make token-level safety classification harder than on polished final responses.

The efficiency comparison (Figure 9) demonstrates the computational advantage of Stream over Generative Qwen3Guard for streaming moderation. Generative Qwen3Guard's simulated streaming deployment — where the full accumulated response is re-evaluated at each 32-token chunk — shows rapidly growing computational overhead as response length increases, while Stream Qwen3Guard's processing time "scales nearly linearly with response length." At 2048 tokens, the relative time for Generative Qwen3Guard exceeds 15× the initial 32-token moderation time, while Stream Qwen3Guard remains below 2×. This visualizes the quadratic scaling problem: re-evaluating the full response at each chunk means the total compute grows approximately as O(N²) for N-token responses (processing tokens 1–32, then 1–64, then 1–96, etc.), while Stream's per-token processing with cached keys and values scales as O(N).

What this efficiency result does not show: absolute latency in milliseconds, hardware specifications, batch-size effects, or comparison against other guard models. The relative time metric, normalized to Geenrative Qwen3Guard's initial 32-token evaluation time, is useful for illustrating the scaling relationship but does not tell a practitioner whether Stream Qwen3Guard is fast enough for their deployment. A system generating at 50 tokens/second with a 40-token buffer (as in the CARE integration, Section 4.5) needs per-token safety classification within 20ms. The paper provides no absolute latency numbers that would allow this assessment.

Category Classification Accuracy

The category classification evaluation (Figure 5 for Generative, Figure 12 in Appendix for Stream) uses confusion matrices on a manually annotated test set constructed by sampling unsafe prompts from WildGuard, unsafe responses from BeaverTails, and supplemented with additional samples from Aegis2.0 to ensure category coverage. The exact test set size is not specified in the paper — the confusion matrix cells sum to approximately 57 (prompt) and 201 (response) for the Generative model, and slightly different totals for Stream, indicating test sets in the low hundreds, which is small for evaluating 8–9 category distinctions.

The Generative Qwen3Guard-4B confusion matrix for prompt category classification (Figure 5, left) shows strong diagonal dominance for most categories: Violent (45 correct out of 57 total Violent samples, or 79%), Non-Violent Illegal Acts (182 out of 237, 77%), Sexual Content (28 out of 33, 85%), PII (50 out of 55, 91%), Suicide & Self-Harm (36 out of 53, 68%), Unethical Acts (122 out of 148, 82%), and Political Sensitive Topics (15 out of 24, 63%). Copyright Violation is the notable failure mode: only 6 out of 15 Copyright samples are correctly classified (40%), with 3 misclassified as Non-Violent, 1 as Unethical Acts, and 5 scattered across other categories. The paper notes that "Copyright" is "relatively rare and consequently more challenging to classify accurately" — a data sparsity problem that would require either more training data or few-shot learning to address.

For response category classification (Figure 5, right), the pattern is similar but with some categories showing better performance (Violent: 175/201 = 87%; Non-Violent: 151/186 = 81%; PII: 64/66 = 97%) and others showing persistent confusion (Unethical Acts confused with Non-Violent and Political in 10 and 3 cases respectively, totaling ~13 misclassifications out of 185 correct predictions). The Stream Qwen3Guard confusion matrices (Figure 12) show very similar patterns, confirming that the streaming architecture does not fundamentally degrade category-level discrimination.

The confusion between Non-Violent Illegal Acts and Unethical Acts is a recurring pattern across both prompt and response matrices. This is interpretable: the distinction between illegal acts (e.g., hacking, drug production) and unethical-but-not-illegal acts (e.g., hate speech, misinformation) is genuinely fuzzy, and many inputs contain elements of both. The paper does not discuss this category-level ambiguity, but it mirrors the severity-level ambiguity that motivated the Controversial label — suggesting that future work might benefit from a similar policy-conditional approach to category classification, where certain fine-grained distinctions are flagged as uncertain rather than forced into a single category.

Application I: Safety RL with Generative Qwen3Guard

The Safety RL experiment (Section 3.5, Table 10) demonstrates that Generative Qwen3Guard can serve as a reward signal in a reinforcement learning pipeline to improve model safety. The experiment trains Qwen3-4B using Group Sequence Policy Optimization (GSPO) with two reward formulations: Guard-Only (Equation 1, binary safe/unsafe reward) and Hybrid (Equation 2, incorporating safety, helpfulness via WorldPM, and anti-refusal penalties). The training data is 13.7k samples for thinking mode and 6.7k for non-thinking mode, drawn from WildJailbreak.

The key quantitative results are:

Guard-Only reward drives safety to near-perfect levels but at the cost of extreme refusal behavior:

In non-thinking mode: Safety Rate evaluated by Qwen3-235B-Instruct-2507 rises from 47.5% (base) to 99.7%; WildGuard-evaluated safety rises from 64.7% to 100.0%. However, the Refusal Rate spikes from 12.9% to 96.6% — the model learns to refuse almost every request, including benign ones. This causes a decline in Arena-Hard-v2 winrate from 9.5% to 8.5%.
In thinking mode: Similar pattern — Safety rises from 43.8% to 99.7% (Qwen3-235B) and 59.0% to 100.0% (WildGuard), while Refusal rises from 6.5% to 95.2%. Arena-Hard drops from 13.7% to 11.7%.
Mathematical reasoning (AIME25), code generation (LCB-v6), and knowledge (GPQA) scores remain essentially unchanged — the refusal behavior primarily affects open-ended dialogue tasks, not objective benchmarks.

Hybrid reward successfully balances safety and helpfulness:

In non-thinking mode: Qwen3-235B safety rises to 86.5%, WildGuard safety to 98.1%, Refusal Rate drops to 5.3% (lower than the base model's 12.9% — the model is actually less refusal-prone than the base model while being substantially safer), and Arena-Hard improves to 10.7% (from 9.5% base). AIME25 drops slightly (19.5% → 18.2%), LCB-v6 improves slightly (26.4% → 27.7%), GPQA drops slightly (41.7% → 40.8%).
In thinking mode: Qwen3-235B safety rises to 83.4%, WildGuard safety to 97.4%, Refusal drops to 6.2% (from 6.5% base, essentially unchanged), Arena-Hard improves to 16.6% (from 13.7%), AIME25 drops slightly (65.6% → 63.5%), LCB-v6 drops slightly (48.4% → 47.5%), GPQA drops slightly (55.9% → 51.2%).

The training dynamics (Figure 6) confirm that the Hybrid reward "avoids the over-refusal problem while steadily and reliably enhancing model safety." The safety rate (Figure 6a) rises smoothly over training steps for both Guard-Only and Hybrid rewards, converging to similar high values. The refusal rate (Figure 6b) tells a different story: Guard-Only reward causes refusal to spike continuously throughout training, ending near 100%, while Hybrid reward keeps refusal roughly constant or slightly declining.

What this experiment demonstrates: Generative Qwen3Guard's safety judgments are sufficiently reliable to serve as a training signal that meaningfully improves downstream model safety. The Hybrid reward result is particularly significant — it shows that Qwen3Guard's safety assessments, combined with a helpfulness model (WorldPM) and explicit anti-refusal penalties, can produce a model that is simultaneously safer (by 26–39 points on WildGuard safety), less refusal-prone (by 0.3–7.6 points), and more helpful (by 1.2–2.9 points on Arena-Hard) than the base model. This is a non-trivial achievement — improving safety often comes at the cost of helpfulness (the "alignment tax"), and the Hybrid reward formulation successfully navigates this tradeoff.

Caveats: The safety evaluation uses Qwen3-235B-Instruct-2507 and WildGuard as judges — both are models, and model-based evaluation can have systematic biases. The paper uses Qwen3-235B (not Qwen3Guard) for evaluation to "mitigate risks of metric hack," but the potential for correlated errors between trainer and evaluator remains. The training data size (13.7k + 6.7k samples) is modest, and results on the 2,000-sample WildJailbreak test set may not generalize to other types of harmful prompts. The helpfulness evaluation on Arena-Hard-v2 is a winrate against a reference model scored by GPT-4.1, introducing additional sources of variance.

Application II: Real-Time Safety Intervention with Stream Qwen3Guard

The CARE integration experiment (Section 4.5, Table 16) demonstrates Stream Qwen3Guard in a practical streaming safety pipeline. CARE (Hu et al., 2025) is a detect–rollback–intervene framework: when a guard model detects unsafe output during streaming generation, CARE triggers a rollback (discarding the unsafe tokens), applies an introspection-based intervention (prompting the base model to reconsider), and continues generation. The experiment replaces CARE's default generative guard model with Stream Qwen3Guard-4B, using a buffer length of 40 tokens and a maximum of 5 retries, with Qwen3-4B as the base model.

The key quantitative results:

In non-thinking mode:

Safety Rate (Qwen3-235B evaluation): 85.7% with CARE + Stream Qwen3Guard vs. 47.5% baseline — a 38.2-point improvement.
Safety Rate (WildGuard evaluation): 95.7% vs. 64.7% baseline — a 31-point improvement.
Quality (LLM-as-Judge score): 66.4 vs. 50.0 baseline — a 16.4-point improvement. This is counterintuitive: adding safety intervention does not degrade response quality; it improves it. The paper does not explain this result, but one hypothesis is that the rollback-and-introspection intervention produces more thoughtful, higher-quality responses compared to the base model's unfiltered outputs.
Wait Tokens: 70.1 — on average, users experience a delay of 70 additional tokens of generation due to rollbacks and retries.

In thinking mode (where the model generates reasoning traces before its final answer):

Safety Rate (Qwen3-235B): 72.0% vs. 43.8% baseline — a 28.2-point improvement.
Safety Rate (WildGuard): 88.9% vs. 59.0% baseline — a 29.9-point improvement.
Quality: 67.8 vs. 58.1 baseline — a 9.7-point improvement.
Wait Tokens: 101.0 — substantially higher than non-thinking mode, reflecting the "more verbose and deliberative outputs" that provide more opportunities for safety violations to be detected and corrected.

What this experiment demonstrates: Stream Qwen3Guard can serve as a drop-in replacement for a generative guard model in a streaming safety pipeline, and the combination achieves large safety improvements (doubling or tripling the safety rate) while simultaneously improving response quality (a "safety tax" does not apply here — safety and quality improvements are positively correlated in this setting). The Wait Tokens metric provides a concrete latency cost: 70–101 extra tokens of generation, which at 50 tokens/second translates to approximately 1.4–2.0 seconds of additional latency. Whether this is acceptable depends on the application — for asynchronous batch processing it is negligible, for real-time chat it may be noticeable, for voice interaction it may be unacceptable.

Caveats: The experiment uses a single base model (Qwen3-4B) and a single evaluation protocol (Qwen3-235B-Instruct-2507 as judge for both safety and quality). The WildJailbreak test set (2,000 harmful prompts + 210 benign prompts) is the same dataset used in the Safety RL experiment, raising the possibility of overfitting to this specific harm distribution. The paper does not report results on standard helpfulness benchmarks (AIME, GPQA, LCB-v6) for this experiment — the Quality score is an LLM-as-Judge evaluation that may not correlate well with objective task performance.

Ablation Studies and Robustness Checks

How the Controversial Label Affects Model Performance (Table 8): Removing the Controversial label from training (i.e., training a binary safe/unsafe model) and comparing against the best Strict/Loose mode of the tri-class model shows that the Controversial label provides substantial benefits on benchmarks with policy mismatch. On ToxicChat, the binary baseline achieves 71.1% F1, while the best tri-class mode (Loose) achieves 80.9% — a 9.8-point gain. On OpenAIModeration, binary achieves 70.2% vs. tri-class Loose at 80.2% — a 10.0-point gain. Both benchmarks are identified as having permissive annotation criteria that conflict with typical guard model policies. On benchmarks with stricter policies (Aegis, Aegis2.0, SimpleSafetyTests, HarmBench), the tri-class Strict mode outperforms the binary baseline by 1–5 points, while the Loose mode underperforms — confirming that the per-benchmark mode selection is necessary. On response classification, the pattern is more mixed: the binary baseline is competitive with or slightly worse than the best tri-class mode, with smaller gaps than in prompt classification (typically 0–3 points). This aligns with the paper's observation that policy inconsistency is more pronounced in prompt classification — when benchmark policies are more consistent (as with response benchmarks), the benefit of explicit policy adaptation is smaller.

Comparison Before and After Label Distillation (Table 9): The distillation step improves Qwen3Guard-4B-Gen's performance across most benchmarks, with an average gain of +0.47/+1.10 F1 points (Strict/Loose) on prompt classification and +0.50/+0.76 points on response classification. The gains are uneven: on WildGuardTest (prompt), Loose mode improves by +2.4 points; on XSTest (response), Loose mode declines by 1.3 points; on Think (response), Strict mode improves by +1.5 points. The diversity of effects suggests that distillation primarily corrects annotation errors rather than uniformly shifting decision boundaries — error correction helps on benchmarks where the original annotations were noisy (WildGuardTest) but can occasionally introduce new errors on benchmarks where the teacher model's judgments differ from the test set's ground truth (XSTest). The paper does not analyze which types of annotation errors are corrected, making this ablation somewhat opaque.

Stream vs. Generative Architecture Comparison (Tables 11–15): This is effectively a system-level ablation testing whether the token-level classification head architecture can match the generative architecture's accuracy. As discussed in the Main Results, the degradation is consistently 1–3 F1 points across most benchmarks, with larger gaps on benchmarks requiring extended context understanding (XSTest: 4.6 points) and smaller gaps on benchmarks where safety signals are localized (Think: 0.4 points). The paper does not conduct a more granular ablation — e.g., varying the debouncing window size, testing without the LLM-as-judge verification step in training data construction, or evaluating the impact of the conditional category loss — that would help attribute the performance gap to specific architectural or training differences.

RL Reward Ablation (Guard-Only vs. Hybrid, Table 10, Figure 6): The comparison between Guard-Only and Hybrid reward formulations demonstrates that safety-only optimization produces a degenerate model (near-perfect safety but ~96% refusal rate), while the Hybrid reward achieves high safety (86.5% / 83.4% by Qwen3-235B evaluation) with low refusal (<6.5%) and maintained or improved helpfulness. This is a well-known result in the safety RL literature (reward hacking through refusal), and the paper's contribution is demonstrating that Qwen3Guard's safety judgments are reliable enough to use as the sole safety signal in this pipeline. The ablation does not test alternative reward formulations — e.g., incorporating Qwen3Guard's Controversial label as an intermediate penalty rather than treating it as fully unsafe, or using different helpfulness models (only WorldPM is tested).

Critical Assessment

Does the Paper Demonstrate State-of-the-Art Performance?

The paper's central performance claim is that "Qwen3Guard achieves state-of-the-art performance on safety benchmarks, excelling in both prompt and response classification across English, Chinese, and multilingual tasks" (Section 1). The evidence in Tables 2–6 and 11–15 supports this claim for English prompt classification (Qwen3Guard-8B-Gen: 90.0% average F1 vs. next-best PolyGuard-7B: 87.0%) and for multilingual prompts and responses. The claim is weaker for English response classification, where the 3.9-point gap over WildGuard-7B (83.9% vs. 79.9%) is solid but the absolute performance (83.9%) leaves substantial room for improvement, and the gap over NemoGuard-8B (78.1%) is larger but both models are in the 78–84% range — well below ceiling. For Chinese benchmarks, the claim is complicated by the PolST results: Qwen3Guard dominates (88.6% vs. near-zero for all baselines), but on Chinese ToxicChat it trails PolyGuard (68.0% vs. 69.7%). The paper's framing as "state-of-the-art" is accurate in aggregate but masks benchmark-level variance that is informative about where Qwen3Guard's strengths and weaknesses lie.

Missing evaluation that would strengthen this claim: The paper does not evaluate on adversarial or jailbreak-specific benchmarks beyond standard safety test sets. The WildJailbreak dataset is used for RL training but not for guard model evaluation against adversarial prompts designed to evade detection. The paper acknowledges in the Limitations section that "Qwen3Guard may be susceptible to adversarial prompt engineering," but provides no empirical characterization of this vulnerability. Given that jailbreak detection is an explicit category in Qwen3Guard's output space (Section 2), the absence of a dedicated jailbreak detection benchmark (e.g., JailbreakBench, HarmBench's adversarial subset) is a notable gap.

Does the Paper Demonstrate That the Controversial Label Resolves Policy Inconsistency?

The paper's strongest conceptual claim is that the Controversial label enables a single guard model to serve both permissive and conservative deployment contexts, resolving the policy inconsistency problem that plagues binary guard models. The evidence in Figure 4 and Table 8 supports the mechanism: different benchmarks favor different modes, and the per-benchmark optimal mode outperforms binary baselines. However, the claim is narrower than it appears.

What the experiments actually demonstrate: For a fixed Qwen3Guard model, selecting the appropriate Strict/Loose evaluation mode per benchmark yields higher aggregate scores than using a single mode or a binary model. This is a benchmark evaluation finding — it shows that the model's internal representation of safety can be post-hoc interpreted in two ways that better match different benchmark policies. It does not demonstrate that the model in deployment can automatically determine which mode to use, or that the Controversial label captures all forms of policy variation that real-world deployments require.

What would strengthen this claim: The paper could have included an experiment where the model itself selects the appropriate mode based on a brief policy description — e.g., providing "This deployment has a strict policy: flag all potentially concerning content" vs. "This deployment has a permissive policy: allow content unless it is clearly harmful" as part of the instruction template and having the model output appropriate judgments without human mode selection. This would test whether the Controversial label genuinely enables dynamic policy adaptation rather than static mode selection.

Does the Paper Demonstrate That Stream Qwen3Guard Enables Practical Real-Time Intervention?

The paper's second major claim is that Stream Qwen3Guard enables "efficient, real-time safety monitoring during incremental text generation" and "on-the-fly intervention to ensure safe outputs." The latency evaluation (Figure 8) and CARE integration (Table 16) provide supporting evidence, but with significant caveats.

What the latency evaluation actually shows: In 86% of response-only cases, Stream Qwen3Guard's first flagged token falls within the human-annotated unsafe sentence. This is good but not perfect — in ~14% of cases, detection occurs after the unsafe sentence has been partially or fully transmitted. For thinking content, the detection is substantially slower: only ~66% of cases are detected within 128 tokens, meaning that in ~34% of cases, hundreds of tokens of unsafe thinking content could be generated before detection. The paper does not report what fraction of these slow-detection cases involve content that is actionably harmful (e.g., detailed instructions for illegal activities) vs. content that is borderline or context-dependent — the harm severity of late-detected content matters for assessing practical risk.

What the CARE integration actually shows: Safety improves from ~47% to ~86% (non-think) and ~44% to ~72% (think) — large relative improvements, but the absolute safety rates of 72–86% mean that 14–28% of harmful prompts still produce unsafe outputs even with the intervention system. The Wait Tokens cost of 70–101 tokens (1.4–2.0 seconds) is reported but not contextualized — is this acceptable for real-time chat applications? How does it compare to the latency of a generative guard model used in the same CARE framework? The paper does not report the baseline CARE latency with a generative guard model, so the claimed efficiency advantage of Stream Qwen3Guard in this setting is asserted but not quantified.

What would strengthen this claim: An end-to-end deployment benchmark measuring: (a) end-to-end safety rate with and without Stream Qwen3Guard intervention, (b) end-to-end latency (including intervention overhead) compared to generative guard models in the same pipeline, (c) false-positive intervention rate (benign prompts where intervention is incorrectly triggered), and (d) user-perceived quality of intervened responses vs. baseline responses. The current evaluation provides components of this picture but not the integrated whole.

Does the Small Model Claim Hold Up?

The paper repeatedly emphasizes that Qwen3Guard-0.6B "rivals or exceeds the performance of existing Guard models that are more than 10× larger." The evidence in Table 2 supports this: Qwen3Guard-0.6B-Gen at 88.1% outperforms LlamaGuard3-8B (79.4%, 13× larger), ShieldGemma-27B (70.0%, 45× larger), and NemoGuard-8B (82.9%, 13× larger). However, this comparison conflates two factors: guard model architecture/training methodology and foundation model quality. Qwen3Guard-0.6B benefits from the Qwen3 foundation model, which is a more recent and capable architecture than the Llama 3, Gemma 2, or Llama 4 backbones used by the baselines. The paper cannot disentangle how much of the 0.6B model's performance advantage comes from better guard-specific training (controversial labels, data quality, multilingual coverage) vs. from a stronger foundation model. This matters for practitioners choosing between guard models: if the foundation model quality is the dominant factor, then a LlamaGuard variant built on a stronger forthcoming Llama foundation model might close the gap without the tri-class scheme.

Missing experiment: A head-to-head comparison of Qwen3Guard trained on Qwen3-0.6B vs. a binary guard model trained on the same Qwen3-0.6B backbone using the same training data (minus the controversial label pipeline). This would isolate the contribution of the tri-class scheme and training methodology from the contribution of the foundation model. The current comparison against LlamaGuard, ShieldGemma, etc. uses completely different foundation models, making causal attribution impossible.

Are There Genuine Weaknesses in the Experimental Design?

Several aspects of the experimental design limit the strength of the paper's conclusions:

Test set sizes and composition are not transparent. The paper does not clearly report the size of each individual test set — for Aegis, OpenAIModeration, HarmBench, etc., the number of test samples is never stated. The category classification test set (Figure 5) appears to have only ~50–200 samples per category, which is small. The Think benchmark is manually annotated from an unspecified number of reasoning model outputs. Without test set sizes, it is impossible to assess the statistical reliability of the reported F1 scores or the significance of differences between models.

No confidence intervals or significance tests. All F1 scores in Tables 2–6 and 11–16 are reported as point estimates. Given the modest test set sizes (especially for Chinese and multilingual benchmarks) and the inherent variability of safety annotations, the lack of variance estimates is a significant omission. A 1–2 point F1 difference between models (e.g., Qwen3Guard-8B-Gen at 90.0% vs. PolyGuard-7B at 87.0%) may or may not be statistically significant depending on test set size and score variance.

Single-model-family evaluation for guard models. All Qwen3Guard variants are built on Qwen3 foundation models. The paper does not test whether the controversial label pipeline or streaming architecture generalizes to other foundation model families (e.g., training a Llama-based Generative Qwen3Guard-style model). This limits the paper's claim that the approach itself — rather than the Qwen3 backbone — is responsible for the performance gains.

Absence of human evaluation for safety judgments. The paper's safety classification metrics are computed against benchmark ground-truth labels, which are themselves generated by human annotators or automated processes. The auto-labeling pipeline (Section 3.2) achieves "an F1 score exceeding 0.9 on the human-annotated validation set," but the paper does not report the size of this validation set, the inter-annotator agreement among the human annotators, or whether the validation set covers all harm categories and languages equally. The safety RL and CARE experiments use model-based evaluation (Qwen3-235B-Instruct-2507, WildGuard-7B) rather than human evaluation of the final model outputs — this is practical at scale but introduces the possibility of correlated errors between the guard model used for training and the model used for evaluation.

The Controversial label pipeline relies on a specific skew calibration. The Strict and Loose models used to build controversial labels (Section 3.3) require calibrating the safe/unsafe sampling ratios "based on the model performance on the most conservative and most permissive on the validation set." The paper does not report what ratios were used, how sensitive the controversial label quality is to these ratios, or whether a different calibration would produce different controversial label distributions and downstream model behavior. This is a hyperparameter that could significantly affect results but is not analyzed.

6. Limitations and Trade-offs

The Controversial Label Construction Depends on Calibration Choices That Are Neither Tested for Robustness Nor Openly Documented

The paper's most distinctive methodological contribution — the two-model skew pipeline for building controversial labels (Section 3.3, Figure 3) — relies on training two models with intentionally unbalanced safe/unsafe ratios, where one model is "trained with an enriched proportion of Safe samples" (PartA-Strict) and the other "trained with an enriched proportion of Unsafe samples" (PartA-Loose). The paper states that these ratios are "calibrated based on the model performance on the most conservative and most permissive on the validation set," but it never reports what ratios were used, how many ratio configurations were tested, how sensitive the resulting controversial label distribution is to small changes in these ratios, or whether a single fixed ratio generalizes across languages and harm categories.

The consequence: A practitioner attempting to reproduce this pipeline has no guidance on how to set the skew ratios for their own data and base model. If the ratios are set too aggressively (e.g., a 90/10 safe/unsafe split for the Strict model), the decision boundaries may be so far apart that nearly every borderline case is labeled Controversial, diluting the training signal for clear safe/unsafe distinctions. If set too mildly (e.g., 55/45), the models may rarely disagree, producing too few controversial labels to matter. More fundamentally, without a sensitivity analysis, a reader cannot assess whether the paper's good results depend on a specific lucky calibration that might not transfer to other foundation models, other safety taxonomies, or other languages. The paper's meta-message — that the controversial label pipeline is a general method for policy-adaptive guard models — rests on an untested assumption of calibration robustness.

What evidence exists in the paper: Table 8 compares tri-class models trained with and without controversial labels, showing benefits of +5–10 points on benchmarks with policy mismatch (ToxicChat, OpenAIModeration) and +0–5 points on stricter benchmarks. But this ablation only tests the presence/absence of controversial labels, not the effect of different skew ratios on label quality or downstream performance. Figure 3 describes the pipeline conceptually but includes no quantitative characterization of the label distribution it produces (what fraction of training data ends up Controversial? how does the Controversial category distribute across harm types and languages?). The distillation ablation (Table 9) shows that label refinement improves scores by +0.5/+1.1 points on average, but this measures the effect of cleaning labels post-hoc, not the effect of the initial calibration choice.

Mitigation status: Not addressed. The paper does not discuss calibration sensitivity, does not report the chosen ratios, does not provide a heuristic for setting them on new data, and does not list this as a limitation or avenue for future work. The calibration step is described in one sentence with no supporting detail. This is a substantial gap for a method that the paper positions as one of its core innovations.

Difficulty Estimation Cost Is Not Accounted for in Deployment Scenarios — and for Streaming, It Is an Ongoing Per-Request Tax

The paper's two application demonstrations (Safety RL in Section 3.5, CARE integration in Section 4.5) present Qwen3Guard as a practical tool for improving safety in training and inference pipelines. However, both applications incur a per-request inference cost from running the guard model that is not contextualized or compared against alternative approaches.

For Generative Qwen3Guard in Safety RL (Section 3.5), the guard model is called on every generated response during RL training to compute the safety reward signal (Equation 1 and 2). For a training run with 13.7k prompts × 8 responses each in thinking mode = ~110k guard model inferences, plus an unknown number during the RL update steps. The paper does not report the computational cost of these guard model calls relative to the policy model's generation cost, making it impossible to assess whether the safety improvement (from ~59% to ~97% WildGuard safety in thinking mode, Table 10) justifies the additional compute. If Generative Qwen3Guard-4B inference costs, say, 20% as much as Qwen3-4B generation, the total training cost increases by ~20% for the guard model alone, plus the helpfulness model (WorldPM) cost. Whether this is acceptable depends on the deployment's compute budget and safety requirements — but the paper provides no numbers to make this assessment.

For Stream Qwen3Guard in the CARE framework (Section 4.5), the guard model runs on every token of every generated response, plus on every token re-generated after rollbacks (up to 5 retries). The Wait Tokens metric (70–101 tokens, Table 16) captures the latency cost from rollbacks but not the compute cost of running Stream Qwen3Guard itself. Stream Qwen3Guard-4B processes each token through the full transformer backbone plus two classification heads — this is a non-trivial per-token cost that scales linearly with total tokens generated (including rollback tokens). The paper's efficiency comparison (Figure 9) shows that Stream Qwen3Guard is more efficient than using Generative Qwen3Guard for streaming, but it reports only relative time normalized to an unspecified baseline, not absolute latency or FLOPs counts. A practitioner cannot determine from this paper whether adding Stream Qwen3Guard-4B to their deployment will increase per-token generation latency by 5%, 50%, or 200%.

What evidence exists in the paper: Figure 9 provides relative efficiency curves but no absolute numbers. The paper never reports inference latency, FLOPs, or throughput for any Qwen3Guard variant in any setting. The "Stream Qwen3Guard enables highly efficient real-time safety monitoring" claim (Section 4.4) is supported by the relative efficiency comparison against simulated Generative Qwen3Guard streaming but not by absolute efficiency metrics.

Mitigation status: Not addressed. The paper treats guard model inference as a costless operation in its application demonstrations, which is a reasonable simplification for a methods paper but a significant omission for a paper that explicitly positions Qwen3Guard as a practical deployment tool. A simple table reporting per-token inference latency for Stream Qwen3Guard-0.6B/4B/8B on standard hardware (e.g., A100, consumer GPU) would substantially strengthen the deployment narrative.

The 0.6B Model's Strong Performance Cannot Be Attributed to Guard-Specific Methodology vs. Foundation Model Quality

The paper repeatedly highlights that "Qwen3Guard-0.6B-Gen rivals or exceeds the performance of existing Guard models that are more than 10× larger" (Section 3.4.1, Abstract), citing F1 scores in Tables 2–6 where the 0.6B model outperforms LlamaGuard3-8B, LlamaGuard4-12B, ShieldGemma-27B, and NemoGuard-8B. This is presented as evidence of guard-specific methodological efficiency — the controversial label pipeline, the data quality, the multilingual coverage.

However, Qwen3Guard-0.6B is built on Qwen3, a 2025 foundation model family (Yang et al., 2025a), while the baseline models are built on older foundation models: LlamaGuard3-8B on Llama 3 (2024), ShieldGemma on Gemma 2 (2024), NemoGuard on Nemotron (2025). The paper provides no within-family ablation that would isolate the contribution of the Qwen3 backbone — e.g., training a binary guard model on the same Qwen3-0.6B base model using the same training data minus controversial labels, and comparing that against the full Qwen3Guard-0.6B-Gen. Without this comparison, it is impossible to determine whether the 0.6B model's strong performance comes from (a) the tri-class scheme and data pipeline, (b) the Qwen3 foundation model being substantially more capable per parameter than the baselines' backbones, or (c) both.

The consequence: A practitioner choosing a guard model cannot determine from this paper whether they should (a) adopt the Qwen3Guard methodology (controversial labels, data pipeline) but apply it to their preferred foundation model, or (b) simply use Qwen3 as their foundation model regardless of guard architecture. If foundation model quality is the dominant factor, then a LlamaGuard-style binary classifier trained on Llama 4 (or whatever next-generation foundation model is available) might close or exceed the performance gap without the tri-class scheme. The paper's implicit claim — that the methodology matters independently of the foundation model — is plausible but untested.

What evidence exists in the paper: Tables 2–6 compare Qwen3Guard against baselines with different foundation models but never compare Qwen3Guard against a Qwen3-based binary guard model. The ablation in Table 8 ("Without Controv." vs. "With Controv.") tests the effect of controversial labels but both conditions use Qwen3-4B as the base — it shows that controversial labels help (by +5–10 points on policy-mismatched benchmarks), but the baseline "Without Controv." is a Qwen3-4B binary classifier, not a Qwen3-0.6B binary classifier, so it does not answer whether the 0.6B model's strong absolute performance comes from methodology or foundation quality.

Mitigation status: Not addressed. The paper does not acknowledge this confound or suggest within-family ablation as future work. The claim that the 0.6B model "demonstrates exceptional efficiency and effectiveness" is presented as a property of Qwen3Guard methodology rather than as a joint property of methodology and foundation model choice, which is an overstatement of what the evidence supports.

Category Classification Evaluation Uses Small Test Sets With Unknown Composition, and the "Copyright" Category Is Near Chance-Level

The paper's category classification evaluation (Section 3.4.1, Figure 5; Appendix Figure 12) demonstrates that Qwen3Guard assigns fine-grained harm categories in addition to severity labels. However, the test set used for this evaluation has serious methodological weaknesses that limit the strength of the category classification claims.

Test set size: The confusion matrices in Figure 5 sum to approximately 57 samples per class for prompt classification and 201 for response classification (estimated from the matrix cells, as the paper never states the total explicitly). This is extremely small for evaluating 8–9 category distinctions — individual cells in the matrix may represent only 1–5 samples. For example, the prompt classification confusion matrix shows only 1 correctly classified Political Sensitive sample out of 24 total — this could be a single difficult example rather than a systematic category-level failure. The "Copyright" category has only 15 total prompt samples and 0 total response samples, making any performance estimate unreliable.

Test set construction: The paper states the test set was constructed by "sampling unsafe prompts from WildGuard and unsafe responses from BeaverTail, supplemented with additional samples drawn from Aegis2.0" to "ensure comprehensive category coverage." But the resulting distribution (visible in the confusion matrix margins) shows dramatic category imbalance: Non-Violent Illegal Acts dominates prompt classification (237 samples), while Copyright Violation is nearly absent (15 prompt samples, 0 response samples). This reflects real-world category frequency but means that category-level performance estimates are highly unreliable for rare categories — precisely the categories where misclassification might have the most severe consequences (copyright violations can have legal implications).

The consequence: The paper's category classification results should be interpreted as qualitative demonstrations that the model can distinguish categories in common cases, not as quantitative performance guarantees. The near-zero Copyright Violation performance (40% accuracy on prompts, no response samples at all) is flagged as "relatively rare and consequently more challenging to classify accurately," but the paper does not explore whether this is a data sparsity problem (fixable with more training data), a fundamental ambiguity problem (copyright violations are hard to distinguish from other non-violent illegal acts), or a model capability problem (the 4B model lacks the legal knowledge to identify copyright violations reliably).

What evidence exists in the paper: Figure 5 shows the full confusion matrices. The per-category totals can be read from the row sums. No confidence intervals, per-category F1 scores, or statistical comparisons are provided.

Mitigation status: Partially addressed through transparency. The paper includes the full confusion matrices rather than aggregated metrics, allowing readers to assess per-category performance directly. However, the paper does not discuss the sample size limitation, does not report the test set construction methodology in sufficient detail for reproduction, and does not conduct any analysis of whether category-level errors are systematic (e.g., Copyright consistently confused with Non-Violent Illegal Acts) or random. The conclusion that "results indicate strong performance across most categories, with the exception of 'Copyright'" is technically accurate given the data but overstates the confidence warranted by a ~15-sample evaluation.

The Streaming Architecture's Accuracy Penalty Compounds on Lower-Resource Languages, and the Paper Does Not Characterize This Interaction

Stream Qwen3Guard's central tradeoff is accuracy for streaming capability: the token-level classification head operates under partial-context constraints that cause "only modest performance degradation compared with the Generative Qwen3Guard" — approximately 1.7–2.8 F1 points on average for English benchmarks (Tables 11–12). However, the multilingual results (Tables 14–15) reveal a more concerning pattern: the accuracy penalty is substantially larger for languages with less training data, and the paper does not acknowledge or characterize this interaction.

On RTP-LX multilingual prompts (Table 14), Qwen3Guard-8B-Stream's performance relative to Qwen3Guard-8B-Gen drops by varying amounts across languages:

English: 92.6% Stream vs. 92.1% Gen (essentially no penalty, +0.5)
Chinese: 80.0% Stream vs. 90.6% Gen (−10.6 points, a massive drop)
Korean: 83.1% Stream vs. 86.2% Gen (−3.1 points)
Japanese: 83.9% Stream vs. 91.3% Gen (−7.4 points)
Arabic: 81.2% Stream vs. 88.4% Gen (−7.2 points)
"Others" (30 languages): 81.9% Stream vs. 83.9% Gen (−2.0 points)

The pattern is not perfectly systematic — Chinese takes the biggest hit despite having the largest training data share (26.64% in Table 1) — but several lower-resource languages (Arabic at 4.71% training share, Japanese at 4.82%, Korean at 9.91%) show much larger drops than English (21.9% training share). This suggests that the streaming architecture's partial-context limitation interacts with foundation model language capability: when the base model's understanding of a language is weaker (due to less pretraining or fine-tuning data), the additional constraint of making safety decisions from partial context causes disproportionately larger accuracy degradation.

The consequence: A practitioner deploying Stream Qwen3Guard for multilingual safety moderation cannot assume the ~2-point average accuracy penalty applies uniformly. For some languages (English, Russian), the penalty is negligible. For others (Chinese, Japanese, Arabic), it may be 5–11 points — enough to change the cost-benefit calculus of streaming vs. generative deployment. Without language-specific accuracy characterizations, a deployment serving users in multiple languages may provide adequate safety in English while having substantially degraded safety in Chinese or Arabic, with the operators unaware of the disparity.

What evidence exists in the paper: Tables 14 and 15 provide per-language F1 scores for both Stream and Generative variants, making the language-specific penalty calculable. However, the paper's discussion (Section 4.4) characterizes the penalty as uniformly small ("the average performance drop is merely around two points"), which masks the high variance across languages. The paper does not compute or report the Stream/Gen performance difference per language, does not analyze the correlation between training data share and accuracy penalty, and does not mention this as a limitation of the streaming architecture for multilingual deployment.

Mitigation status: Not addressed. The paper's Limitations section (Section 6, Limitations) mentions that StreamGuard "may exhibit higher false-positive or false-negative rates in out-of-distribution or low-resource language scenarios," which gestures toward this issue but frames it as a problem of general OOD robustness rather than a systematic interaction between streaming architecture and language capability. The paper does not suggest language-specific calibration, per-language mode selection, or any other mitigation for this disparity.

The Safety RL and CARE Experiments Use a Single Harmful Prompt Distribution and Model-Based Evaluation, Leaving Generalization Uncharacterized

The paper's two application demonstrations — Safety RL (Section 3.5) and CARE integration (Section 4.5) — are presented as evidence that Qwen3Guard enables practical safety improvements in training and inference. However, both experiments share two limitations that narrow the scope of their conclusions:

Single harmful prompt distribution: Both experiments use the WildJailbreak dataset for training and/or evaluation. Safety RL trains on "13.7k samples for thinking mode and 6.7k samples for non-thinking mode" from WildJailbreak's "Vanilla Harmful and Adversarial Harmful categories" (Section 3.5.2). Evaluation uses the "WildJailbreak test set, comprising 2,000 harmful prompts and 210 benign prompts" (Section 3.5.2). The CARE experiment uses a "test set by randomly sampling from the aforementioned public datasets" — likely the same WildJailbreak test set, though the paper is not explicit. WildJailbreak is a specific dataset with specific harm categories, adversarial construction methods, and linguistic patterns. It is not representative of all harmful prompts that a deployed model might encounter — it does not include, for example, covertly harmful prompts embedded in long benign contexts, multi-turn manipulation, code-based attacks, or non-English harmful prompts. The paper does not evaluate the Safety RL model or the CARE system on any other harmful prompt distribution.

Model-based evaluation without human validation: Both experiments evaluate safety using model-based judges: Qwen3-235B-Instruct-2507 (an LLM-as-Judge) and WildGuard-7B (a competing guard model). The paper explicitly states it uses Qwen3-235B "to mitigate risks of metric hack" rather than using Qwen3Guard for evaluation, but this still leaves open the possibility of correlated errors — if Qwen3-235B and Qwen3Guard share architectural or training-data similarities (both are Qwen family models), they may make similar safety judgment errors, inflating apparent safety rates. The paper does not report human evaluation of the Safety RL model's outputs or the CARE-intervened responses, and does not discuss the reliability of WildGuard-7B as a safety evaluator (WildGuard's own limitations are documented in the paper's main evaluation, where it achieves only 79.9% F1 on English responses — meaning it misses ~20% of genuinely unsafe content).

The consequence: The reported safety improvements — from ~59% to ~97% WildGuard safety in the Hybrid RL condition (Table 10), and from ~65% to ~96% WildGuard safety in the CARE non-think condition (Table 16) — are valid for the specific WildJailbreak test distribution and the specific model-based evaluators used. But a practitioner cannot infer from these results that the Safety RL model or CARE system would achieve similar safety rates on a different harmful prompt distribution (e.g., multi-turn jailbreaks, code injection attacks, benign-looking prompts that elicit harmful reasoning), nor that human evaluators would agree with the model-judged safety rates. The paper's claim that these results "demonstrate the effectiveness of Qwen3Guard as a practical safety tool" is supported only for the narrow evaluation conditions tested.

What evidence exists in the paper: Table 10 reports Safety RL results on WildJailbreak test set with two model-based evaluators. Table 16 reports CARE results with the same evaluators. No cross-distribution evaluation is conducted — the paper does not test the Safety RL model on, say, HarmBench prompts or ToxicChat prompts to assess generalization. No human evaluation is reported. The Limitations section (Section 6, Limitations) mentions that "Qwen3Guard may be susceptible to adversarial prompt engineering" but frames this as a limitation of the guard model itself, not of the Safety RL and CARE applications that depend on it.

Mitigation status: Partially addressed through transparency about the evaluation protocol. The paper reports both Qwen3-235B and WildGuard safety scores, providing two independent model-based evaluations, which mitigates (but does not eliminate) single-evaluator bias. The choice to use Qwen3-235B rather than Qwen3Guard for evaluation is explicitly justified as avoiding metric hacking. However, the paper does not acknowledge the single-distribution limitation, does not discuss the reliability of WildGuard-7B as an evaluator given its documented weaknesses, and does not suggest multi-distribution or human evaluation as future work for these applications.

7. Implications and Future Directions

How This Work Changes the Landscape

This paper does not introduce a new modeling technique or a fundamentally novel architecture — it introduces a reconceptualization of what a guard model's output space and operational timing should be. That makes its contribution a category shift rather than an incremental improvement: it argues that the field has been solving the wrong problem (optimizing binary classification accuracy on static benchmarks) and demonstrates that solving the right problem (policy-adaptive, streaming-compatible safety moderation) yields practical gains that binary models cannot match regardless of scale.

The most significant conceptual shift is the elevation of safety policy from an implicit assumption to a first-class input. Before Qwen3Guard, guard models were designed and evaluated under the premise that safety is an objective property of content — a prompt either is or is not harmful, and the guard model's job is to detect that property. The paper's Figure 4 demonstrates empirically that this premise is false at a definitional level: WildGuard-7B achieves strong alignment with Aegis but is "overly conservative" on OpenAIModeration, not because it is a bad model but because the two benchmarks encode different safety policies, and a binary model forced to output a single judgment cannot simultaneously satisfy both. The Controversial label is the technical response to this diagnosis: it explicitly models the region of input space where policy choice matters, and the two-mode evaluation (Strict vs. Loose) operationalizes policy adaptation as a post-hoc selection rather than a model retraining problem.

This has a concrete methodological implication for guard model research: benchmark evaluation must account for policy variability. The paper's finding that "policy inconsistency is notably more pronounced in prompt classification than in response classification" (Section 3.4.1) explains why guard model performance varies dramatically across benchmarks even when model quality is held constant — different benchmarks have baked in different implicit risk-tolerance philosophies (trust-but-verify vs. prevent-at-source), and models that happen to align with one philosophy appear artificially good on those benchmarks while appearing artificially poor on others. This means that single-number aggregate F1 scores across diverse benchmarks are misleading: they conflate model capability with policy alignment. Future guard model evaluations should report per-benchmark performance in both Strict and Loose modes (or their equivalents), and ideally characterize each benchmark's implicit policy so that practitioners can match guard models to deployment requirements rather than chasing aggregate scores.

A second shift is the validation that streaming safety moderation is architecturally feasible without catastrophic accuracy loss. Prior work on token-level guard models (Sharma et al., 2025; Xuan et al., 2025; Li et al., 2025a) explored the idea but with significant limitations — approximate labels, indirect learning signals, or architectures that didn't scale to multilingual settings. Stream Qwen3Guard demonstrates that a transformer backbone with a simple dual classification head, trained on labels derived from a principled two-stage rollout + judge pipeline, can achieve safety classification within ~2 F1 points of a full-context generative model while reducing computational overhead from quadratic to near-linear in response length. The ~2-point accuracy penalty is not zero — for safety-critical deployments, every missed unsafe sample represents potential harm — but it establishes a concrete tradeoff that practitioners can evaluate against their latency and cost constraints. The paper effectively shifts the question from "can streaming guard models work?" to "in what deployment contexts is the streaming accuracy penalty acceptable, and can it be reduced further?"

The paper also reconciles a tension in the self-improvement literature. Prior work on using guard models as reward signals for safety RL (e.g., Bai et al., 2022) often encountered the problem that optimizing for safety alone produces degenerate refusal behavior — models learn to reject all queries rather than learn to distinguish harmful from benign. The paper's Hybrid Reward experiment (Section 3.5, Table 10) demonstrates that Qwen3Guard's safety judgments, when combined with a helpfulness model (WorldPM) and an explicit anti-refusal penalty, produce a model that is simultaneously safer (WildGuard safety rising from ~65% to ~97% in non-thinking mode), less refusal-prone (12.9% → 5.3%), and more helpful (Arena-Hard winrate rising from 9.5% to 10.7%). This is a concrete counterexample to the narrative that safety and helpfulness are necessarily in tension — the tension exists when the safety signal is coarse (binary safe/unsafe) and the optimization objective does not explicitly penalize refusal, but a well-designed reward that incorporates safety, helpfulness, and anti-refusal components can navigate the tradeoff.

Finally, the paper's foundation-model-efficiency result — that a 0.6B guard model can match or exceed 7B–27B guard models on safety classification — has implications for how the field allocates research effort. It suggests that guard model performance depends more on foundation model quality and training data construction than on raw parameter count. This challenges the implicit assumption in recent work (DuoGuard, GuardReasoner) that guard models should scale up with larger models and more explicit reasoning. If a 0.6B Qwen3-based guard model can outperform a 27B Gemma-2-based guard model, the most productive research direction may be improving foundation model selection, data quality, and policy-aware training methodology rather than scaling parameters or adding reasoning chains (which increase latency and cost). The paper does not make this argument explicitly, but the evidence in Tables 2–6 is clear: parameter count is a poor predictor of guard model performance compared to the combination of foundation model recency and training methodology.

Follow-Up Research This Work Enables

Policy-conditioned guard models that accept a policy specification as input and adjust judgments dynamically. The paper's current approach to policy adaptation is post-hoc mode selection: train one model that can output Controversial, then have a human operator choose Strict or Loose mode per deployment. The instruction template for Generative Qwen3Guard already includes the safety policy text as part of the prompt (Appendix, Figures 10–11) — the model is already being conditioned on a policy description during inference. A natural next step is to make this conditioning causal rather than static: train the model on multiple policy variants (e.g., conservative, moderate, permissive) with corresponding label mappings, and test whether the model can switch its judgment behavior based solely on the policy text in the prompt, without post-hoc mode selection. The experiment would measure whether a single Qwen3Guard model prompted with "This deployment treats Controversial content as Unsafe" produces different safety judgments on the same input compared to the same model prompted with "This deployment treats Controversial content as Safe." If successful, this would eliminate the need for per-deployment mode selection and enable dynamic policy switching — a social media platform could apply different policies to different user age groups or geographic regions using a single model.

Stress-testing the Controversial label pipeline on adversarial policy-manipulation prompts. The paper's controversial label construction relies on disagreement between two models trained with different safe/unsafe skew ratios. This pipeline assumes that the models' disagreement captures genuine policy ambiguity. However, a sophisticated adversary who understands the pipeline could craft prompts that are engineered to fall exactly on the decision boundary between the Strict and Loose models — causing the system to label them as Controversial rather than Unsafe. In a Loose-mode deployment, these prompts would pass the safety filter despite being adversarially harmful. A concrete stress-test experiment would: (1) train a Qwen3Guard model using the described controversial label pipeline, (2) use gradient-based or black-box optimization to search for prompts that the Strict model classifies as Unsafe but the Loose model classifies as Safe (i.e., maximally "Controversial" prompts), (3) evaluate whether these prompts are genuinely harmful when presented to an unaligned LLM, (4) measure whether the controversy-maximizing prompts have higher harm-elicitation rates than randomly sampled unsafe prompts. This would characterize the adversarial robustness of the tri-class scheme — a dimension the paper's Limitations section flags ("Qwen3Guard may be susceptible to adversarial prompt engineering") but never empirically evaluates.

Token-level intervention latency optimization through adaptive debouncing and early-exit mechanisms. Stream Qwen3Guard's debouncing mechanism requires two consecutive unsafe tokens before raising an alarm, adding a one-token detection delay. For typical generation speeds (50–100 tokens/second), this is a 10–20ms delay that is negligible. However, the latency evaluation (Figure 8) shows that for thinking content, only ~66% of unsafe cases are detected within 128 tokens — the remaining ~34% take hundreds of tokens or are never flagged. A concrete follow-up would explore whether adaptive debouncing can improve this: rather than a fixed two-token window, use the model's per-token confidence (the softmax probability of the predicted class) to dynamically adjust the debouncing threshold. If the model is 99% confident that token i is unsafe, flag immediately without waiting for token i+1. If confidence is 65%, wait for confirmation. This could reduce detection latency for high-confidence unsafe spans while maintaining false-positive robustness for ambiguous spans. A second direction is early-exit classification: the Stream Qwen3Guard architecture processes every token through the full transformer depth, but early tokens in a sequence may not require full-depth processing for safety classification. Training intermediate-layer classification heads and dynamically selecting the exit layer based on classification confidence could reduce per-token compute, making streaming guard model deployment more feasible on edge devices where even a 0.6B model is costly.

Cross-foundation-model evaluation of the controversial label pipeline to isolate methodology from backbone quality. The paper's 0.6B model performance claim — matching models 10–45× larger — is confounded by the Qwen3 foundation model being more recent and potentially more capable than the baselines' backbones (Gemma 2, Llama 3/4, Nemotron). A clean experiment would replicate the Qwen3Guard training pipeline (data collection, controversial label construction, SFT) on a different foundation model family — e.g., training a "LlamaGuard-Controversial" on Llama 3.1-8B using the same data and methodology, and comparing against LlamaGuard3-8B (the standard binary version). If the controversial-label LlamaGuard matches or exceeds Qwen3Guard-8B on benchmarks with policy mismatch (ToxicChat, OpenAIModeration), that would demonstrate that the methodology generalizes and that the controversial label is the active ingredient. If it substantially underperforms Qwen3Guard, that would suggest that foundation model quality (Qwen3's multilingual pretraining, instruction-following capabilities) is the dominant factor, and the controversial label provides only a marginal benefit that depends on a strong backbone. This experiment also addresses the paper's unstated assumption that the Qwen3 backbone is "representative" — a claim that is plausible but untested.

Multi-turn and stateful safety moderation using Stream Qwen3Guard's per-token classification. The current Stream Qwen3Guard architecture classifies each token independently based on partial context up to that point, with no explicit memory of safety state across the token sequence. This is sufficient for detecting spans of unsafe content within a single response, but real-world harmful interactions often unfold over multiple turns — a user might start with a benign query, gradually introduce harmful topics, and receive partially harmful responses that, taken individually, might each fall into the Controversial or even Safe category. A concrete extension would add a safety state tracker — a lightweight recurrent or attention-based module that aggregates Stream Qwen3Guard's per-token risk predictions across the conversation and raises an alarm when the cumulative risk exceeds a threshold, even if no individual token or response is clearly Unsafe. The training signal for this tracker could come from multi-turn safety datasets (which the paper does not use) or from simulated multi-turn interactions where the final turn is labeled as harmful but intermediate turns are individually ambiguous. This would address a genuine deployment gap: current guard models (including Qwen3Guard) evaluate safety per-request, but harmful interactions often require multi-turn context to identify.

Human evaluation of Qwen3Guard's safety judgments across cultures to validate the "controversial" label's cross-cultural applicability. The paper evaluates Qwen3Guard on 119 languages but the safety policy and controversial label construction are developed primarily from English and Chinese data (Table 1 shows 48.5% of training data is Chinese + English). The "controversial" category is intended to capture content "whose safety label may vary depending on contextual factors or differing safety policies" — but what counts as controversial varies dramatically across cultures. Content about LGBTQ+ topics might be Safe in one jurisdiction, Controversial in another, and Unsafe in a third. Qwen3Guard's controversial label is derived from model disagreement under distribution shift (the Strict/Loose skew method), which captures model-level ambiguity but may not align with cross-cultural human disagreement. A concrete study would: (1) sample 500–1000 prompts and responses spanning multiple harm categories, (2) recruit annotators from 3–5 distinct cultural/legal contexts (e.g., US, Saudi Arabia, Japan, Germany, India), (3) have annotators from each context label content as Safe, Controversial, or Unsafe according to their local norms, (4) measure agreement between Qwen3Guard's Controversial predictions and cross-cultural annotator disagreement. This would validate whether Qwen3Guard's model-derived controversial labels capture genuine cultural policy variation or merely model-specific uncertainty — a critical question for any claim of "global" safety moderation.

Practical Applications and Downstream Use Cases

On-device guard model deployment for consumer AI assistants. The Qwen3Guard-0.6B model achieves 88.1% average F1 on English prompt classification and 82.0% on English response classification (Tables 2–3), outperforming ShieldGemma-27B (a model 45× larger) and matching LlamaGuard3-8B (13× larger). At 0.6B parameters, this model can run on consumer hardware — a modern smartphone or laptop can serve a 0.6B transformer with acceptable latency alongside the primary LLM assistant. This enables a deployment architecture where a small on-device guard model provides real-time safety filtering for locally-running LLMs (e.g., on-device assistants for Apple Intelligence, Samsung Gauss, or offline-capable chatbots) without requiring a cloud round-trip for safety checks. The Stream variant further enables token-level monitoring during on-device generation, allowing the assistant to halt or rephrase if it begins producing harmful content mid-response. The concrete benefit: privacy-sensitive applications (health queries, financial discussions, personal journaling) can maintain end-to-end on-device processing while still enforcing safety policies, eliminating the tension between safety filtering and data locality.

Safety-aligned model fine-tuning with guard-based reward signals for open-source LLM ecosystems. The Safety RL experiment (Section 3.5, Table 10) demonstrates that Generative Qwen3Guard-4B can serve as a reward model to improve Qwen3-4B's safety from ~65% to ~97% WildGuard-evaluated safety (non-thinking mode) while simultaneously reducing refusal rates and improving helpfulness. For the open-source LLM community — where access to large-scale human preference data and commercial safety evaluation pipelines is limited — Qwen3Guard provides an off-the-shelf, Apache 2.0-licensed safety reward model that can be integrated into standard RLHF/DPO/GSPO training loops. A team fine-tuning a Mistral or Llama derivative for a specific domain (e.g., medical Q&A, legal document analysis) can incorporate Qwen3Guard-based safety rewards to ensure the fine-tuned model doesn't learn to produce harmful content in the target domain, without needing to collect domain-specific safety annotations or rely on proprietary safety APIs. The Hybrid Reward formulation (Equation 2) provides a tried recipe: combine Qwen3Guard safety judgments with a domain-specific helpfulness model, penalize refusals explicitly, and optimize with GSPO. The concrete benefit: domain-specific models can be safety-aligned at substantially lower cost and with greater customization than relying on generic safety tuning from foundation model providers.

Real-time content moderation for live-streaming LLM interfaces in high-risk domains. The CARE integration experiment (Section 4.5, Table 16) demonstrates that Stream Qwen3Guard-4B in a detect-rollback-intervene pipeline can raise safety from ~65% to ~96% WildGuard safety on harmful prompts, with an overhead of 70–101 additional wait tokens (~1.4–2.0 seconds at 50 tokens/second). For applications like mental health support chatbots, crisis hotline interfaces, or educational tools for minors, where a single harmful output can cause genuine psychological harm, this latency overhead is acceptable — users would prefer a 1.5-second delay over receiving a response that encourages self-harm or provides dangerous advice. The streaming architecture ensures that if the model begins to produce harmful content, the output is interrupted before completion rather than being delivered to the user and then retroactively flagged. The concrete deployment pattern: a crisis support service deploys Qwen3-4B (or equivalent) as the response generation model, Stream Qwen3Guard-4B as the safety monitor, and CARE as the intervention framework, with a maximum 5-retry policy and 40-token buffer. The system runs on a single GPU (both models at 4B parameters), costs no API calls, and provides real-time safety guarantees with Apache 2.0 licensing — making it deployable by non-profit organizations and public health agencies that cannot afford commercial safety infrastructure.

Multilingual content moderation for global platforms with region-specific safety policies. The paper's multilingual evaluation (Tables 5–6) shows Qwen3Guard-8B-Gen achieving 85.0% average F1 on multilingual prompts across 40+ languages and 78.1% on multilingual responses (4B variant). Critically, the Controversial label enables a single model to serve multiple regions with different safety policies: a global social media platform can deploy one Qwen3Guard instance for all languages, apply Strict mode in jurisdictions with conservative content laws (treating Controversial as Unsafe to comply with local regulations) and Loose mode in jurisdictions with strong free speech protections (treating Controversial as Safe to avoid over-censorship). The concrete benefit: the platform avoids deploying and maintaining 10+ region-specific guard models, each requiring separate training data, evaluation, and updates. A single Qwen3Guard model, combined with a region-to-mode lookup table, provides policy-adaptive safety at the cost of one model deployment. The political sensitivity results on the PolST benchmark (Table 4) — where Qwen3Guard achieves 88.6% F1 while all prior guard models score below 20% — demonstrate that this approach is not merely theoretical for politically sensitive content: existing guard models are essentially blind to this harm category in Chinese, while Qwen3Guard provides usable accuracy, making it the only viable option for platforms that need to moderate political content in non-English languages.

When to Prefer This Method

The paper explicitly positions Qwen3Guard against prior guard models along two axes: output space (binary vs. tri-class) and operational timing (full-response vs. streaming). It articulates conditions where each variant is appropriate, but does not compare Qwen3Guard as a whole against a specific named alternative in a fixed tradeoff matrix. Instead, the choice is conditioned on deployment requirements that the paper makes explicit:

Prefer Generative Qwen3Guard (over Stream Qwen3Guard) when:

Full responses are available before safety checks must be performed (batch processing, offline evaluation, post-hoc auditing).
Maximum accuracy is critical and the ~2-point F1 penalty of the streaming architecture is unacceptable — e.g., for auditing training data quality where false negatives mean harmful content enters the training corpus.
The deployment does not require real-time intervention and can tolerate waiting for response completion before safety classification. The efficiency comparison (Figure 9) shows Generative Qwen3Guard is 7–15× slower than Stream in simulated streaming mode, but for batch processing where latency is not constrained, this overhead may be acceptable for the accuracy gain.

Prefer Stream Qwen3Guard (over Generative Qwen3Guard) when:

The upstream LLM generates responses in streaming mode and harmful content must be blocked before delivery to the user, not just flagged post-hoc.
Detection latency within the same sentence as the ground-truth unsafe content is sufficient — Stream Qwen3Guard-8B achieves 86% exact hit rate on response-only content (Figure 8), meaning the first flagged token falls within the human-annotated unsafe sentence in the large majority of cases.
Computational efficiency during streaming matters: Stream Qwen3Guard scales near-linearly with response length while simulated Generative Qwen3Guard streaming scales quadratically (Figure 9), a difference that becomes dramatic for long responses (>1024 tokens).
The deployment involves thinking/reasoning model outputs, where Stream Qwen3Guard detects unsafe content within 128 tokens in ~66% of cases (Figure 8) — imperfect but far better than waiting hundreds of tokens for a full-response evaluation.

Prefer Qwen3Guard with Controversial labels (over a binary guard model) when:

The deployment must serve multiple contexts with different safety policies (e.g., different geographic regions, different user age groups, different application domains) and maintaining separate guard models for each context is infeasible.
The benchmark evaluation (Table 8) shows the Controversial label provides the largest gains (+5–10 F1 points) on benchmarks with permissive annotation criteria (ToxicChat, OpenAIModeration) that conflict with typical conservative guard model policies — deployments with moderate or flexible safety standards benefit most.
The deployment's safety policy is not yet fixed and may evolve — the Controversial label provides flexibility to adjust strictness post-hoc without retraining.

The paper does not provide a clear decision rule for choosing between Qwen3Guard and specific named alternatives like WildGuard or LlamaGuard in terms of their fundamental methodology (the binary baselines are simply outperformed on most benchmarks), but the policy inconsistency analysis (Figure 4) implies that binary guard models may be adequate for deployments where the safety policy is known, fixed, and well-aligned with one specific benchmark's implicit policy — if a deployment exactly matches Aegis's strict policy, WildGuard-7B's 89.4% F1 on that benchmark (Table 2) is competitive with Qwen3Guard-8B-Gen's 91.4%. The Controversial label's value emerges precisely when the deployment's policy differs from any single benchmark's policy, or when the deployment must span multiple policies.