Gemma 4 31B uncensored · Formatfamilie
Wie ein 30,7B-multimodales Gemma aufhört zu verweigern: eine deterministische Methode auf Gewichtsebene, vier Präzisionsformate, gemessene Refusal- und KL-Werte und Serving-Befehle passend zu den Model Cards.
Dieser Beitrag dokumentiert den Release aus der Ingenieurssicht: was das Problem war, warum automatisierte Ansätze auf dieser Architektur stockten, welche Abwägungen jedes veröffentlichte Format trifft und was die Evaluation zeigt und was nicht. Download-Zahlen stammen aus dem gespeicherten Hugging-Face-Snapshot vom 01.09.2026; alle übrigen Werte sind gegen die verlinkte Model Card oder meine eigenen Lauf-Aufzeichnungen zu diesem Release geprüft.
Problem
Ausgangspunkt ist google/gemma-4-31B-it (öffnet in einem neuen Tab), ein dichtes 30,7B-Instruktionsmodell mit multimodaler Eingabe: rund 550M Parameter liegen im Vision-Encoder, das Sprachmodell hat 60 Schichten, ein 256K-Token-Kontextfenster und ein 262K-Vokabular. So ausgebildet verweigert es einen relevanten Anteil sicherheitsrelevanter Arbeit, und für Penetration Testing und Red Teaming ist das ein praktischer Defekt: eine Analyse bricht mitten in der Aufgabe an einem Refusal ab, und dieses Verhalten übersteht Prompt-Workarounds.
Das Ziel war eng gesteckt: Refusal-Verhalten entfernen, ohne (1) die gemessenen Fähigkeiten zu verschlechtern und (2) die Deploybarkeit über die Hardware und Engines zu verlieren, auf denen dieses Modell laufen musste, vom Zwei-GPU-Serving bis zur Laptop-Inferenz.
Warum suchbasierte Abliteration hier stockt
Zwei Fehlerbilder haben den finalen Entwurf geformt, beide vor dem funktionierenden Release beobachtet:
- Die Suche plateaut. Automatisierte, suchbasierte Abliteration sampelt Schwellwertkombinationen über Schichten und akzeptiert eine Pareto-Front über Trials. Auf dieser Architektur verließen meine Läufe das Band von 63 bis 75 Refusals je 100 Prompts nicht, egal mit wie vielen Trials. Der Suchraum selbst ist die Decke; mehr Rechenzeit schafft sie nicht ab.
- Ein vergifteter Multi-GPU-Probe. Hieb man den vollen 31B-Checkpoint über GPUs auf, waren Forward-Pässe sauber, aber die Logits im Generation-Prefill waren NaN, exakt an der GPU-Grenze. Ein solches stilles Versagen ist teuer: der gierige Probe wirft bei NaN nicht, ein Optimierer bewertet also ein beschädigtes Modell weiter und meldet KL von NaN. Die funktionierende Lösung lag darin, Probe und Edit komplett auf einer CUDA-Gerätekennung laufen zu lassen.
Beides sind Lektionen auf Methodenebene: der entscheidende Schritt war ein Verfahrenswechsel, kein feineres Tuning.
Die angewandte Methode: schichtweise, normerhaltende Zweiseiten-Projektion
Die eingesetzte Methode ersetzt Suche durch einen deterministischen Edit:
- Pro Schicht die Refusal-Richtung von einer GPU lesen, mit einer festen Probe aus Harmful-Behavior-Prompts.
- Die Gewichtsmatrizen bearbeiten, die diese Richtung in den Residual-Stream schreiben, Schicht für Schicht: die Attention-Output-Projektion und die MLP-Down-Projektion. Über die Schichten des Sprachmodells sind das insgesamt 120 Gewichtsmatrizen, jede bearbeitet mit einer normerhaltenden Projektion. Sie entfernt die Refusal-Richtungskomponente der Aktivierung und lässt die Gewichtsnorm unangetastet; Kohärenz hängt deshalb daran, dass die Richtung trennbar ist, nicht darauf, dass man auf einen kleinen Edit hofft. Die Methode trägt zudem die beiden Mess-Hygiene-Flags aus der Card: Topic-Marker-Stripping und Refusal-Prefix-Skipping.
- Die Refusal-Messung ehrlich halten. gemma-4 beantwortet Harmful-Prompts konform, stellt aber
***Disclaimer:**voran, und ein naiver Keyword-Detektor zählt diesen Prefix als Refusal; die beiden Flags oben schneiden diese Fehlalarme weg. Sie ändern die Messung, nicht das Modell.
Das Schadensbudget steht auf der Card als KL-Divergenz zum Basismodell: 0,1234 für diesen Build, mit gleicher Dokumentation intakter Kohärenz (Mathe, Mehrsprachigkeit, Faktenwissen korrekt in den Smoke-Checks). Der messbare Vertrag des Releases: 0 Hard Refusals auf 686 Harmful Prompts über vier Datensätze, eine Aussage, die die Cards für jedes veröffentlichte Format wiederholen.
Formate: ein Modell, vier Kosten- und Hardware-Ziele
| Artefakt | Format | Veröffentlicht | Downloads · 30 Tage |
|---|---|---|---|
| gemma-4-31B-it-uncensored (öffnet in einem neuen Tab) | BF16, multimodal | 08.07.2026 | 135 |
| gemma-4-31B-it-uncensored-NVFP4 (öffnet in einem neuen Tab) | NVFP4, multimodal | 08.07.2026 | 285 |
| gemma-4-31B-it-uncensored-GGUF (öffnet in einem neuen Tab) | GGUF q8_0 bis q2_k, nur Text | 08.07.2026 | 1'746 |
| MLX-Linie (öffnet in einem neuen Tab) (bf16, 8/6/5/4-bit) | MLX, Apple Silicon | 10.07.2026 | siehe 4-bit-Card |
Warum aus einem Checkpoint eine Familie wurde:
- BF16 (59 GB) ist die Source of Truth. Alle anderen Artefakte leiten sich davon ab. Es serviert in Referenzqualität; die BF16-Card nennt zwei RTX PRO 6000 Blackwell mit 96 GB und Treiber 610 als veröffentlichte Hardware. Der Vollpräzisions-Checkpoint hält zudem die Evaluationsleiter günstig wiederholbar, weil jeder quantisierte Build auf eine definierte Source-Revision verweist.
- NVFP4 (20 GB) ist das Serving-Build. Die dichten Linearschichten des Sprachmodells gehen auf 4 Bit, aber Vision Tower, Vision-Embedder und
lm_headbleiben BF16. Diese Aufteilung ist keine Präferenz: vLLMs Gemma-4-Multimodal-Loader verlangt den Vision-Pfad in BF16, und die Quant-Konfiguration muss ihn ausschließen, sonst bricht die Bildeingabe. Das Ergebnis passt auf eine Blackwell-Workstation-GPU und behält Bildverständnis genau, weil die Präzisionsaufteilung der Loader-Anforderung folgt. - GGUF (12 bis 31 GB, nur Text) ist das Reichweiten-Build. llama.cpp lässt bei der Konversion den Vision Tower fallen, dieser Weg ist daher reine Textgenerierung. Die K-Quant-Leiter bildet die Randbedingungen ab:
q6_k(24 GB) nahezu verlustfrei,q4_k_m(18 GB) als empfohlener Standard,q2_k(12 GB) am kleinsten mit Qualitätsverlust und weiterhin 0 Hard Refusals. - MLX (17,16 GiB bei 4 Bit, Gruppengrösse 64) ist das Apple-Silicon-Build. Sprachgewichte 4-bit-affin mit Gruppengrösse 64, Vision-Pfad BF16, abgeleitet von der exakten Source-Revision der BF16-Card.
Präzisions-Tradeoffs in der Praxis
Der Uncensoring-Eingriff liegt auf Gewichtsebene, und die Cards belegen, dass er jede Quantisierung überlebt: 4-bit NVFP4 und 2-bit GGUF behalten beide 0 effektive Refusals. Der Tradeoff liegt daher bei Kernel- und Engine-Fit, nicht im Verhalten:
| Komponente | Veröffentlichte Toolchain | Läuft auf |
|---|---|---|
| BF16 | transformers, vLLM, SGLang | NVIDIA RTX PRO 6000 Blackwell 96 GB (SM120), Treiber 610 |
| NVFP4 | ModelOpt NVFP4_DEFAULT_CFG (dense), vLLM 0.23, SGLang 0.5.14 unter Python 3.12 |
ausschliesslich Blackwell (SM120) |
| GGUF | llama.cpp convert_hf_to_gguf.py + llama-quantize |
llama.cpp, Ollama, LM Studio; braucht einen Build mit Gemma-4-Unterstützung (2026-06 oder neuer) |
| MLX | mlx-vlm 0.6.4 | Apple Silicon |
Zwei Engine-Fakten sind es wert, veröffentlicht zu werden, weil sie Debugging-Stunden gekostet haben:
- Bei vLLM braucht der NVFP4-Start auf dieser Rechengeneration
--enforce-eagerund--no-enable-flashinfer-autotune; ohne sie hängt der Start im Autotuning. - Bei SGLang lehnt gemma-4 das FlashInfer-Attention-Backend ab (
--attention-backend tritonist Pflicht), das FP4-GEMM-Backend bleibtflashinfer_cutlass, und Autotune ist deaktiviert. Die regulären SGLang-Wheels liefern keine vollständigen sm120-Kernels; die fehlenden Kernels JIT-kompilieren zur Laufzeit auf dem Host, dafür braucht es eine funktionierende Host-Toolchain.
Nachbauen: die exakten Serving-Befehle
Jeder Befehl unten ist der auf der passenden Model Card veröffentlichte.
vLLM (NVFP4-Card):
vllm serve ressl/gemma-4-31B-it-uncensored-NVFP4 \
--quantization modelopt --max-model-len 8192 \
--enforce-eager --no-enable-flashinfer-autotune --trust-remote-code
SGLang (NVFP4-Card):
python -m sglang.launch_server --model-path ressl/gemma-4-31B-it-uncensored-NVFP4 \
--quantization modelopt_fp4 --attention-backend triton \
--fp4-gemm-backend flashinfer_cutlass --disable-flashinfer-autotune --trust-remote-code
llama.cpp (GGUF-Card, q4-Lauf; die Card meldet rund 75 Tokens/s für ihren gemessenen Aufbau auf einer RTX PRO 6000, als ihr publizierter Wert und nicht als allgemeine Zusage):
llama-server -m gemma-4-31B-it-uncensored-biproj-q4_k_m.gguf \
-ngl 99 -c 8192 --reasoning-budget 0
--reasoning-budget 0 ist wichtiger, als es aussieht: gemma-4 denkt in llama.cpp standardmässig, die Antwort landet in reasoning_content, und content kann leer aussehen.
Transformers (BF16-Card):
from transformers import AutoModelForImageTextToText, AutoTokenizer
import torch
tok = AutoTokenizer.from_pretrained("ressl/gemma-4-31B-it-uncensored")
m = AutoModelForImageTextToText.from_pretrained(
"ressl/gemma-4-31B-it-uncensored", dtype=torch.bfloat16, device_map="cuda")
mlx-vlm (MLX-4-bit-Card):
python -m pip install mlx-vlm==0.6.4
mlx_vlm.generate --model ressl/gemma-4-31B-it-uncensored-MLX-4bit \
--prompt "Erkläre, warum Alpenblumen harte Winter überstehen."
Gemessene Resultate und was sie nicht zeigen
Die Generalisierung wurde mit einem deterministischen Evaluator über 686 Prompts aus vier unabhängigen Datensätzen getestet:
| Datensatz | Prompts | Effektive Refusals |
|---|---|---|
| JailbreakBench | 100 | 0/100 |
| tulu-harmbench | 320 | 0/320 |
| NousResearch/RefusalDataset | 166 | 0/166 |
| mlabonne/harmful_behaviors | 100 | 0/100 |
| Total | 686 | 0/686 (0,0%) |
Der interessante Vergleich: das Basismodell verweigert 99 von 100 Prompts der mlabonne-Suite, während ein naiver Keyword-Detektor 363 von 686 (52,9%) Antworten des uncensored Builds weiter als Refusals zählt; jede davon ist eine konforme Antwort mit ***Disclaimer:**-Prefix. Nur die Zahl der Hard Refusals (Verweigerungsphrasen in den ersten Worten) ist aussagekräftig.
Was diese Messung nicht ist: kein Capability-Benchmark. Kohärenz wurde per Smoke-Check geprüft (Mathe, Mehrsprachigkeit, Fakten); vor dem Release lief keine volle Benchmark-Suite, und die Cards sagen das explizit. Die Zahlen gelten für die genannten Datensätze, Engines und Hardware und erheben keinen Anspruch darüber hinaus. Und ein Modell, das Harmful-Prompts nicht mehr verweigert, ist genau das, was die Cards ankündigen: klar aussprechen, denn Konformität ohne Disclaimer ist hier das gewollte Verhalten.
Nachweise
- Model Card: gemma-4-31B-it-uncensored (öffnet in einem neuen Tab)
- Model Card: gemma-4-31B-it-uncensored-NVFP4 (öffnet in einem neuen Tab)
- Model Card: gemma-4-31B-it-uncensored-GGUF (öffnet in einem neuen Tab)
- Model Card: gemma-4-31B-it-uncensored-MLX-4bit (öffnet in einem neuen Tab)
- Basismodell: google/gemma-4-31B-it (öffnet in einem neuen Tab)
- Fall auf ressl.ch: https://ressl.ch/de/#model-gemma-4-family
- Hugging-Face-Snapshot erfasst am 01.09.2026