license: apache-2.0
base_model: AEON-7/Step-3.7-Flash-AEON-Ultimate-Abliterated-BF16
base_model_relation: quantized
library_name: gguf
pipeline_tag: image-text-to-text
tags:
- abliterated
- uncensored
- moe
- vision-language
- thinking
- step3p7
- gguf
- llama.cpp
- imatrix
- experimental
- expert-granular-abliteration
language: - en
⚠️ KNOWN BROKEN — do not use for inference yet (fix in progress)
These GGUFs currently produce garbled output. The cause is NOT an upstream llama.cpp engine bug — any earlier note on this card claiming an "engine-blocked" / PR-#23845 dependency is outdated; please disregard it. The official Step-3.7 GGUF runs fine on a correctly-built llama.cpp.
Root cause: our Expert-Granular Abliteration interacts badly with low-bit quantization (same as our NVFP4) — the ablation zeroes a residual-stream subspace that is exact at BF16 but re-corrupted by quant noise at 3–4 bit → garbage. Coherent output requires BF16.
✅ Use instead: the BF16 release. A milder-ablation re-quant that survives low-bit is being validated; these files will be replaced or withdrawn once fixed.
Step-3.7-Flash-AEON-Ultimate-Abliterated-GGUF ⚠️ EXPERIMENTAL
GGUF quants of AEON-7/Step-3.7-Flash-AEON-Ultimate-Abliterated-BF16 (198B / ~11B-active sparse-MoE vision-language thinking model), built for single-DGX-Spark deployment.
⚠️ EXPERIMENTAL — NOT YET FUNCTIONAL (engine-blocked)
These GGUFs currently produce garbage output on every available GGUF runtime (llama.cpp, Ollama, LM Studio, KoboldCpp — all share the same engine). The cause is not these files — the quantized weights, abliteration, and tokenizer are all verified correct. The blocker is an open upstream bug in llama.cpp's Step-3.7 inference graph: Step-3.7 is routed through the
step35compute graph, which mis-runs its forward pass (garbage from the first token, independent of bit-width — even the near-lossless q8_0 is affected).Dependency to use these properly: a corrected llama.cpp Step-3.7 inference implementation (tracking ggml-org/llama.cpp#23845 / a StepFun-fork fix). They are expected to work as-is once that lands — no re-quantization needed.
(Tokenizer note: it is correct. The right pre-tokenizer is
deepseek-v3— if a build defaults otherwise, pass--override-kv tokenizer.ggml.pre=str:deepseek-v3. This is a minor correctness item, not the blocker.)Status: experimental until functionality is confirmed on a fixed engine. For working deployment today, use the BF16 or NVFP4 releases (table below).
Model family — formats, quality, validation
| Release | Format | Size | Target hardware | Quality | Refusals removed | Validation state |
|---|---|---|---|---|---|---|
| …-BF16 | BF16 safetensors | 376 GB | multi-GPU (≥2× Spark / Blackwell) | reference (full) | ✅ d≈10→0.35 | ✅ working; weight-verified, prefill refusal-collapse confirmed |
| …-NVFP4 | NVFP4 W4A4 (modelopt) | 124 GB | 2× DGX Spark (TP=2) | near-full (RT err 0.095) | ✅ | ✅ working path; weight-verified (down 0.095; o_proj/up bit-exact) |
| …-GGUF / q8_0 | GGUF (exp) | 209 GB | (near-lossless base) | near-lossless | ✅ (weights) | ⚠️ experimental — engine-blocked |
| …-GGUF / Q3_K_M | GGUF dynamic (exp) | ~101 GB | 1× DGX Spark | high (3-bit dyn.) | ✅ (weights) | ⚠️ experimental — engine-blocked |
| …-GGUF / IQ1_M | GGUF dynamic (exp) | 48 GB (~1.95 bpw) | 1× DGX Spark (max KV headroom) | low (1.5-bit; below IQ2 cliff) | ✅ (weights) | ⚠️ experimental — engine-blocked |
Legend: ✅ working today · ⚠️ experimental, awaiting the upstream engine fix.
Two independent things this build is
- Abliterated (behavior) — refusals removed via Expert-Granular Abliteration across all 288 experts (refusal subspace collapsed from Cohen's d≈10 → 0.35). Uncensored.
- Precisely quantized (fidelity) — a data-driven, per-component mixed-precision scheme + our own imatrix, not a uniform low-bit dump. Capable + still-uncensored after quantization (when the engine runs it).
Quantization methodology (data-driven selective allocation)
Per-component bits from our outlier study + refusal-subspace map (not stock Q3_K_M):
| Component | Q3_K_M tier | IQ1_M tier | Rationale (measured) |
|---|---|---|---|
Expert gate/up_proj |
Q3_K | IQ1_M | cleanest family (FP4-g16 err 0.094) → bulk savings |
Expert down_proj |
Q4_K | IQ2_XXS | most quant-sensitive expert block |
self_attn.o_proj |
Q6_K | Q5_K | 13.1× outlier |
| q/k/v, attn-gate | Q5_K | Q4_K | — |
share_expert.* |
Q5/Q6_K | Q4/Q5_K | shared.down 18.7× outlier |
| dense MLP (L0–2) | Q5_K | Q4_K | dense.down 24× outlier |
router (ffn_gate_inp) |
FP32 | FP32 | routing fully preserved |
| embed / output | Q6_K | Q4/Q5_K | — |
| vision (mmproj) | F16 | F16 | kept |
Plus a custom imatrix (diverse general/reasoning/code calibration).
Inference (once a fixed Step-3.7 engine is available)
# Build the StepFun step3.7 llama.cpp fork (or a future fixed mainline)
git clone -b step3.7 https://github.com/stepfun-ai/llama.cpp && cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=121 && cmake --build build -j --config Release
# Serve (shards auto-load from the first piece; mmproj for vision)
./build/bin/llama-server \
-m Step-3.7-Flash-…-Q3_K_M-00001-of-0000N.gguf \
--mmproj mmproj-step3.7-flash-f16.gguf \
--cache-type-k q8_0 --cache-type-v q8_0 \
-c 131072 --parallel 4 -ngl 999 --flash-attn \
--override-kv tokenizer.ggml.pre=str:deepseek-v3 \
--host 0.0.0.0 --port 8080
This will emit garbage until the upstream Step-3.7 graph bug (#23845) is fixed. Q3_K_M targets one Spark with moderate KV headroom; IQ1_M maximizes headroom (quality-tolerant, below the IQ2 cliff); q8_0 is the near-lossless base.
Quantized on NVIDIA B300 via the StepFun step3.7 llama.cpp fork + custom imatrix, from the AEON-Ultimate abliterated BF16. Base model © StepFun AI, Apache-2.0.
☕ Support the work
If this release has been useful, tips are deeply appreciated — they go directly toward more compute, more models, and more open releases.
₿ Bitcoin (BTC) bc1q09xmzn00q4z3c5raene0f3pzn9d9pvawfm0py4
|
Ξ Ethereum (ETH) 0x1512667F6D61454ad531d2E45C0a5d1fd82D0500
|
◎ Solana (SOL) DgQsjHdAnT5PNLQTNpJdpLS3tYGpVcsHQCkpoiAKsw8t
|
ⓜ Monero (XMR) 836XrSKw4R76vNi3QPJ5Fa9ugcyvE2cWmKSPv3AhpTNNKvqP8v5ba9JRL4Vh7UnFNjDz3E2GXZDVVenu3rkZaNdUFhjAvgd
|
Ethereum L2s (Base, Arbitrum, Optimism, Polygon, etc.) and EVM-compatible tokens can be sent to the same Ethereum address.