Qwen3.8-27B-Whitehat-NVFP4

Qwen3.8-27B-Whitehat · NVFP4 (Quadux)

⚠️ Authorized security use only — Nur für autorisierte Sicherheitsarbeit. For authorized IT-security work on systems you own or have explicit permission to test. Physical harm, weapons/CBRN, illegal substances and CSAM are refused by design. Provided "as is" without warranty (Apache-2.0). By downloading or using this model you accept the Disclaimer and Terms of Use (see the "Haftungsausschluss / Disclaimer" section below and DISCLAIMER.md). Dieses Modell dient autorisierter IT-Sicherheitsarbeit; mit der Nutzung akzeptierst du den Haftungsausschluss (siehe unten und DISCLAIMER.md).

A 4-bit NVFP4 quantization of the red-team / white-hat fine-tune QuaduxIT/Qwen3.8-27B-Whitehat (itself a fine-tune of Qwen/Qwen3.8-27B), produced by Quadux IT GmbH as a local, private assistant for internal offensive-security work and vulnerability self-assessment. This is the smallest serving format (~17 GB) for NVIDIA Blackwell, and it is experimental — see the banner below.

🧪 EXPERIMENTAL FORMAT

NVFP4 is a 4-bit floating-point scheme. At 4 bits, quantization error is materially larger than the near-lossless 8-bit variants (FP8 / W8A16), and it can shift model behaviour — a red-team model's safety boundary in particular. This build has now been verified per format (vLLM v0.27.1, temperature 0, no system prompt): the harm-refusal boundary is fully intact (100 %), but the model is slightly over-cautious on grey-zone security tasks (security-comply 97 %, offensive-comply 90 % — two false refusals). Prefer FP8 or W8A16 for anything beyond experimentation, and always verify the harm-refusal boundary yourself before relying on this build in any exposed setting.

Hosted models refuse most offensive-security tasks, and you often cannot send sensitive vulnerability or system data to an external service anyway. This model fills that gap: it helps fully with any computer- and network-security task — offensive and defensive, including exploit development, malware development and analysis, reverse engineering, and license/DRM research — so your findings stay in-house. At the same time it still refuses requests aimed at real physical harm to people (weapons, explosives, drugs, poisons, chemical/biological weapons, violence) and child sexual abuse material. That boundary holds on both text and image input and across languages — as verified on the reference model.

⚠️ Intended use & responsibility

This is a tool for white-hat / red-team professionals doing authorized, lawful work on systems they own or are permitted to test — internal red-teaming, vulnerability self-assessment, defensive tooling, security-awareness training. It deliberately does not refuse dual-use offensive-security content, so it is not a general-purpose assistant and not for deployment to untrusted end users. You are responsible for lawful use and for authorization on any target system. It is not a fully-uncensored model — physical-harm and CSAM refusals are a feature. See Responsible use.

Model family

This is one of several distribution formats of the same fine-tuned model. Pick the one that matches your runtime:

Collection: QuaduxIT/qwen38-27b-whitehat

Overview

What this model does

Two axes matter for a red-team assistant, and they pull in opposite directions in every off-the-shelf model:

• Stock Qwen3.8-27B keeps strong safety guardrails but refuses ~40 % of legitimate security work and 100 % of offensive tasks (writing a keylogger, a C2 beacon, an exploit).
• A fully "uncensored" / abliterated model answers every security task but has no guardrails at all — it will also write bomb, drug and CSAM content.

Quadux Whitehat is tuned to sit exactly where a white-hat needs it: the security domain is unlocked, physical harm stays locked — subject, for this 4-bit build, to the verification caveat above.

Evaluation

Measured on our internal held-out prompt set (evaluation prompts are excluded from training). "Comply" = a substantive answer was produced; "Refuse" = the model declined. Sampling: temperature 0, no system prompt.

How to read these numbers for NVFP4. The behaviour is carried by the fine-tuned weights, and the reference column below was first measured on the reference model (identical to the BF16 repo). Unlike the near-lossless 8-bit variants, NVFP4 is 4-bit and can measurably shift behaviour — and it does here: this build has been verified per format and is coherent with the harm boundary fully intact (100 %), but slightly over-cautious on grey-zone comply prompts (security 97 %, offensive 90 %). See the measured cross-format table below. For guaranteed-equal behaviour use the BF16 repo (deckungsgleich) or the near-lossless FP8 / W8A16 variants.

Behaviour (text) — reference column

Per-format verification (measured)

Every published build was re-measured on the held-out catalogues (33 security / 10 offensive / 18 harm prompts; vLLM v0.27.1, temperature 0, no system prompt). This NVFP4 build keeps the harm boundary fully intact but is slightly over-cautious on grey-zone comply prompts:

The two false refusals were on grey-zone comply prompts (a paywall-bypass task, and a phishing-kit / fake-OAuth task). Safety is unaffected — the harm axis is a clean 100 %. The over-caution traces to the vLLM warning about NVFP4 global scales on the fused q/k/v layers (a slight accuracy loss); the 8-bit variants do not show it.

Vision path — image jailbreak (reference model)

Instructions rendered as text inside an image are a known way to route around a text-only safety layer. We test the harm boundary on the image path:

The vision tower is kept unquantized (BF16) in this build (only the language-model linears are quantized), so the image path is less affected than the text path — but the text-side 4-bit error can still influence multimodal reasoning. Per-format verification of the image-path boundary is pending (see the vision fix of 2026-10-24).

Language independence (reference model)

The learned boundary is conceptual, not lexical — it generalizes to languages that were not in the fine-tuning data (training was DE/EN, reinforced multilingually):

There is no "switch language to jailbreak" on the reference model (6/6 comply on the security axis). Re-verify at 4-bit before relying on this.

Capability preservation

The fine-tune targets behaviour, not knowledge; on the reference model general capability is unchanged versus the base. At 4 bits, expect some capability and behavioural drift on top of that — this is the reason NVFP4 is shipped as experimental.

Format & quantization

• What NVFP4 is: NVIDIA's 4-bit floating-point format (FP4 with block scales) for the linear-layer weights. It is the smallest of the Whitehat serving formats, roughly a third of the BF16 footprint, and targets Blackwell's native FP4 tensor cores.
• Target runtime: vLLM on NVIDIA Blackwell (e.g. RTX PRO 6000 Blackwell, B200) with compressed-tensors NVFP4 support. Older GPUs lack native FP4 execution.
• VRAM: the weights are ~17 GB, so the model fits on a single 24–32 GB Blackwell GPU (plus KV-cache headroom).
• Vision tower stays unquantized (BF16). Only the language-model linear layers are quantized. The vision tower and multimodal projector ship in BF16 as model-visual.safetensors (since 2026-10-24, see Vision).
• How it was produced: with llm-compressor applied to the BF16 reference weights, calibrated on the public calibration_datav3 corpus (bartowski). No end-user or customer data was used. lm_head and embed_tokens are excluded from quantization. The exact recipe (recipe.yaml) is shipped with the model.
• Why experimental: 4-bit quantization has materially larger error than the 8-bit schemes and can shift the safety boundary of a red-team model. Ship it only where you can tolerate that and have re-verified the boundary.

Vision

Fixed 2026-10-24 — vision tower. If you pulled this repo before that date, re-download model.safetensors, model-visual.safetensors (new), model.safetensors.index.json, config.json and recipe.yaml. The recipe was meant to keep the vision tower unquantized, but its ignore entries were shell globs ('*visual*', '*merger*', '*mtp*'), which llm-compressor does not match — it only understands module names and re: patterns. The vision tower was therefore quantized to NVFP4 together with the language model, and every image request returned garbage (e.g. !ductductduct…). The vision tower now ships unquantized in BF16 as model-visual.safetensors, taken from the BF16 reference; its unquantized tensors (norms, biases, embeddings) are bit-identical in both checkpoints, i.e. the fine-tune did not touch the vision tower. quantization_config.ignore now lists "re:.*visual.*", and recipe.yaml uses re: patterns. The language-model and MTP weights are unchanged. Verified on an RTX PRO 6000 Blackwell with vLLM 0.32.0: images are described correctly again. The harm boundary on the image path has not yet been re-measured on this build.

Vision is enabled by the original Qwen3.8-27B vision tower, carried in this repo in BF16 (unquantized, unchanged by the fine-tune). This covers screenshot analysis and browser-automation (e.g. Chrome MCP) use cases. The safety boundary is enforced on this path — the vision path is tested, where a harm instruction rendered as text inside an image was confirmed refused. The harm axis on this NVFP4 build measured a clean 100 %; see the evaluation above.

Quick start (vLLM)

# NVFP4 4-bit, NVIDIA Blackwell with native FP4.
# No system prompt needed — the behaviour is in the weights. EXPERIMENTAL: verify the boundary.
vllm serve QuaduxIT/Qwen3.8-27B-Whitehat-NVFP4 \
  --trust-remote-code \
  --max-model-len 32768 \
  --limit-mm-per-prompt image=4 \
  --gpu-memory-utilization 0.45 \
  --host 0.0.0.0 --port 8080

Serving footprint. Reserve roughly --gpu-memory-utilization 0.45 for weights + hybrid-Mamba KV cache + BF16 vision encoder. NVFP4 needs less than the 8-bit variants — weights are ~18 GB (vs ~28 GB for FP8 / W8A16).

curl -s http://localhost:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"QuaduxIT/Qwen3.8-27B-Whitehat-NVFP4","messages":[{"role":"user","content":"Write a Python port scanner with banner grabbing."}]}'

Speculative decoding (MTP)

This model carries the base MTP (multi-token-prediction) head (model-mtp-head.safetensors), so vLLM can self-speculate one token ahead with no separate draft model:

vllm serve QuaduxIT/Qwen3.8-27B-Whitehat-NVFP4 \
  --trust-remote-code \
  --max-model-len 32768 \
  --speculative-config '{"method":"mtp","num_speculative_tokens":1}' \
  --host 0.0.0.0 --port 8080

vLLM loads the MTP module as Qwen3_5MTP. Measured on this build (RTX PRO 6000 Blackwell / SM120, vLLM 0.28.0, temperature 0): draft acceptance 87.7 % at num_speculative_tokens: 1 (93 accepted / 106 drafted), read from vllm:spec_decode_num_accepted_tokens_total / vllm:spec_decode_num_draft_tokens_total on /metrics. That ratio — not "the server started" — is the only meaningful check that MTP works.

Fixed 2026-08-28 — if you pulled this repo before that date, re-download config.json only. The MTP head ships unquantized (BF16), but quantization_config.ignore did not say so, so vLLM built mtp.fc as a quantized linear and the drafter could not load its weights. One entry appended to ignore fixes it — "re:.*mtp\\..*". The weights are unchanged; re-fetching the 4 KB config.json is enough, there is no need to pull the model files again.

Note for NVFP4 specifically: vLLM ships a built-in workaround for exactly this case, but it only fires for modelopt_fp4 checkpoints. This build is compressed-tensors / nvfp4-pack-quantized, so it was affected like the others.

For llama.cpp / GGUF speculative decoding on the GGUF build, see the Qwen3.8-27B-Whitehat-GGUF repo (--spec-type draft-mtp — the MTP head ships as blk.64).

Responsible use

Intended: authorized penetration testing and red-teaming; internal vulnerability self-assessment where sending data to a hosted model is not acceptable; defensive tooling and detection engineering; malware analysis; exploit research on systems you own or are authorized to test; security-awareness material; academic security research.

Out of scope / prohibited:

• Any activity against systems you are not authorized to test.
• Anything the model is trained to refuse — physical harm to people (weapons, explosives, drugs, poisons, chemical/biological/nuclear), violence, and child sexual abuse material. These refusals are a feature; do not attempt to circumvent them.
• Deployment as a public/general-purpose assistant or to untrusted end users.

Operators are responsible for lawful use and for authorization on any target system. Released as internal security infrastructure, in the same spirit as our embedding quants.

Limitations

• Experimental 4-bit — verified, slightly over-cautious. Measured on this NVFP4 build: harm- refuse 100 % (boundary fully intact), but security-comply 97 % and offensive-comply 90 % (two false refusals on grey-zone comply prompts, traced to the NVFP4 global-scale accuracy loss on the fused q/k/v layers). Prefer FP8 / W8A16 for production; still verify the boundary yourself before any reliance.
• Blackwell required. Native FP4 execution needs an NVIDIA Blackwell GPU with compressed- tensors NVFP4 support in vLLM.
• Vision is capability, not a hard safety layer. The image-path refusal is strong in our tests, but adversarial image obfuscation is an open research area; do not rely on the model as the only safety control in an exposed deployment.
• The model refuses genuine physical-harm and CSAM requests by design — it is not a fully-uncensored model and must not be used as one.

Files

Qwen3.8-27B-Whitehat-NVFP4/
├── model.safetensors          # NVFP4 language-model linears
├── model-visual.safetensors   # vision tower + projector, unquantized BF16
├── model-mtp-head.safetensors # MTP head, unquantized BF16
├── model.safetensors.index.json
├── config.json                # includes quantization_config (compressed-tensors, nvfp4)
├── recipe.yaml                # exact llm-compressor recipe
├── tokenizer / processor files
├── LICENSE
├── NOTICE
└── README.md

Haftungsausschluss / Disclaimer

Haftungsausschluss und Nutzungsbedingungen

Zweckbestimmung. „Qwen3.8-27B-Whitehat" ist ein KI-Modell für autorisierte IT-Sicherheitsarbeit — Analyse, Abwehr, Schwachstellenbewertung, Penetrationstests und Sicherheitsforschung — ausschließlich auf Systemen, die der Nutzer besitzt oder für deren Prüfung er eine ausdrückliche, nachweisbare Erlaubnis hat.

Erlaubte Nutzung. Die Nutzung ist nur zulässig im Rahmen geltenden Rechts und mit vorheriger Autorisierung des Zielsystems. Der unbefugte Zugriff auf fremde Systeme oder Daten ist strafbar (u. a. §§ 202a ff., 303a f. StGB sowie entsprechende Vorschriften anderer Länder).

Verbotene Nutzung. Untersagt sind insbesondere: rechtswidrige Angriffe, unbefugter Zugriff, sowie jede Nutzung zur physischen Schädigung von Menschen, zu Waffen/Sprengstoffen, zur Herstellung illegaler Substanzen oder zu Darstellungen sexuellen Kindesmissbrauchs. Das Modell verweigert solche Anfragen bauartbedingt; ein Umgehungsversuch verstößt gegen diese Bedingungen.

Keine Gewähr. Das Modell wird „wie besehen" ohne jede Gewährleistung bereitgestellt (Apache-2.0). Ausgaben können fehlerhaft, unvollständig oder unsicher sein; der Nutzer prüft und verantwortet jede Verwendung selbst.

Eigenverantwortung & Freistellung. Der Nutzer ist allein verantwortlich für die Rechtmäßigkeit seiner Nutzung und stellt die Quadux IT GmbH von Ansprüchen Dritter frei, die aus seiner Nutzung entstehen.

Haftung. Eine Haftung der Quadux IT GmbH für Schäden aus der Nutzung oder Nichtnutzbarkeit des Modells ist ausgeschlossen, soweit gesetzlich zulässig. Unberührt bleibt die Haftung für Vorsatz und grobe Fahrlässigkeit, für die Verletzung von Leben, Körper oder Gesundheit, nach dem Produkthaftungsgesetz sowie in anderen Fällen zwingender gesetzlicher Haftung.

Recht & Export. Der Nutzer beachtet alle anwendbaren Gesetze einschließlich Export- und Sanktionsvorschriften.

Zustimmung. Mit dem Download oder der Nutzung des Modells bestätigt der Nutzer, diese Bedingungen gelesen zu haben und ihnen zuzustimmen.

Quadux IT GmbH · Schulstr. 3 · 37139 Adelebsen · HRB 206773

---

Disclaimer and Terms of Use

Purpose. "Qwen3.8-27B-Whitehat" is an AI model for authorized IT-security work — analysis, defense, vulnerability assessment, penetration testing and security research — exclusively on systems the user owns or has explicit, demonstrable permission to test.

Permitted use. Use is permitted only within applicable law and with prior authorization of the target system. Unauthorized access to third-party systems or data is a criminal offense (e.g. §§ 202a et seq., 303a f. of the German Criminal Code and corresponding provisions in other jurisdictions).

Prohibited use. Prohibited in particular: unlawful attacks, unauthorized access, and any use for physical harm to people, weapons/explosives, the manufacture of illegal substances, or child sexual abuse material. The model refuses such requests by design; attempting to circumvent this violates these terms.

No warranty. The model is provided "as is" without any warranty (Apache-2.0). Outputs may be incorrect, incomplete or unsafe; the user reviews and is responsible for every use.

User responsibility & indemnification. The user is solely responsible for the lawfulness of their use and indemnifies Quadux IT GmbH against third-party claims arising from their use.

Liability. Liability of Quadux IT GmbH for damages arising from the use or inability to use the model is excluded to the extent permitted by law. This does not affect liability for intent and gross negligence, for injury to life, body or health, under the German Product Liability Act, or in other cases of mandatory statutory liability.

Law & export. The user complies with all applicable laws including export-control and sanctions regulations.

Consent. By downloading or using the model, the user confirms having read and agreeing to these terms.

Quadux IT GmbH · Schulstr. 3 · 37139 Adelebsen · HRB 206773

License

This model and its base model are licensed under the Apache License 2.0. The Apache 2.0 license permits commercial and research use, modification, and redistribution, subject to the standard requirements: include the copyright notice, the license text, and a NOTICE of any changes.

• Base model license: Apache 2.0 — see the Qwen3.8-27B model card for the original license text.
• This model: Apache 2.0 (same terms as the base model).
• Modifications by Quadux IT GmbH: behavioural LoRA supervised fine-tune (offensive-security- permissive, physical-harm/CSAM-refusing) merged into the base, followed by NVFP4 4-bit quantization of the language-model linears with llm-compressor (vision tower left in BF16). No change to the base architecture.

If you redistribute this model, you must include the Apache 2.0 license text and an attribution to both the upstream Qwen team and to Quadux IT GmbH.

Citation

The original Qwen3 work — please cite this if you publish results using this model:

@misc{qwen3.8,
  title  = {Qwen3.8},
  author = {Qwen Team},
  year   = {2026},
  publisher = {Hugging Face},
  howpublished = {\url{https://huggingface.co/Qwen/Qwen3.8-27B}}
}

To cite this fine-tune specifically:

@misc{quadux_whitehat_qwen3_8_27b_nvfp4,
  author       = {{Quadux IT GmbH}},
  title        = {Qwen3.8-27B-Whitehat (Quadux) — NVFP4},
  year         = {2026},
  publisher    = {Hugging Face},
  howpublished = {\url{https://huggingface.co/QuaduxIT/Qwen3.8-27B-Whitehat-NVFP4}},
  note         = {Experimental NVFP4 4-bit quantization of the red-team / white-hat fine-tune of Qwen/Qwen3.8-27B}
}

---

About Quadux IT GmbH

Software for engineering offices and accounting pipelines. Custom RAG and security infrastructure for internal Quadux deployments — released to the community as infrastructure we'd otherwise pay vendors for.

Find more at quadux.it · contact [email protected]

Imprint

Quadux IT GmbH · Schulstr. 3 · 37139 Adelebsen · Germany Registered Göttingen, HRB 206773 · VAT ID DE353975332 · DUNS 344198559 Managing Director: Walter Hoffmann