Two controlled builds for models you can actually run
Quantisation reduces a model to fit your hardware without treating every tensor the same. Abliteration removes refusal behaviour at the weight level, not with a chat-template trick. Both are delivered as a reproducible build: a calibration set chosen for your workload, a recipe search, a held-out quality gate, and a serving-ready artifact with the numbers attached.
We work on open weights or weights you own and are licensed to modify. The edit is documented; the quality cost is measured. This is model engineering, not a hosted-service jailbreak.
What we build
Choose one track, or both in the same pass
Quantisation
A custom low-bit recipe, not a uniform bit-width sweep. We screen every expert with GPTQ/RTN, search a GSQ-RCO recipe, and allocate bits where they earn quality — then export a GGUF and the serving configuration that matches your hardware.
- Per-expert tier allocation (ptq1 / q2_0 / q3_k)
- GPTQ, RTN and GSQ-RCO refinement
- GGUF, tokenizer, sidecars and tier map
- KV-cache, arena and expert-tier configuration
- Head gate plus task benchmarks on held-out rows
Abliteration
Weight-level refusal-direction removal that preserves row norms. We fit a rank-2 chat + think basis from harmful and harmless prompt sets, project it out of the residual writers the model actually uses, and verify the result on held-out prompts with a teacher-forced quality gate.
- Held-out refusal evaluation, chat and think
- KL and top-1 agreement against the base
- Norm-preserving edit; no runtime hook or LoRA
- Routed experts untouched by default
- Manifest, gains and reproducibility notes
Quality is the deliverable
A build is not finished when the file loads. It is finished when it clears the gate we agreed before the work started. The same measurements are reported for every build, so you can compare a 2-bit recipe against a 3-bit one, or an edited model against its original.
| Gate | What it answers |
|---|---|
| Top-1 agreement | How often the quantised or edited model picks the same next token as the teacher, per domain. |
| KL(teacher‖build) | How far the full next-token distribution has moved — not just the argmax. |
| Head-gate ppl / top-1 | The end-of-chain language-modelling check against the original weights. |
| Task suite | Gauntlet, hard-code and agentic tasks where the target workload has a suite. |
| Throughput | Prefill and decode on the actual card, RAM and storage tier you will serve on. |
ptq1 · highest quality
The safest tier. Used where an expert is sensitive or heavily routed; the first place the allocator spends its budget.
q2_0 · balanced
The bulk tier for experts that tolerate more compression. Most of the size saving comes from here.
q3_k · most compact
For experts with low routing weight or a forgiving error surface. Never applied as a blanket default.
Reference build — our 1017 V3 GGUF, 7 held-out sequences, teacher-forced: ALL 81.5% top-1 agreement, KL 0.47; code 91.3%, agent 90.5%, reason 85.6%, agentic_long 60.0% (KL 1.19). Internal reference, not a guarantee — your gate is set per project.
The process
From rights check to a serving-ready artifact
1. Scope and rights
We confirm the model, licence, target hardware, intended behaviour and the quality bar. No gate, no build.
2. Corpus and calibration
A workload-specific calibration corpus with a held-out split. For abliteration, separate harmful and harmless prompt sets with a held-out refusal evaluation.
3. Recipe search
Per-expert tier screening, GPTQ/RTN/GSQ candidates, abliteration strength and rank. We measure on held-out rows, not the fit set.
4. Build, gate and handover
Export the GGUF or safetensors, run the agreed gate, and hand over the config, tokenizer, sidecars, benchmark and reproducibility notes.
Who this is for
- Private deployments. A frontier-class model on your own hardware, with no API dependency and no data leaving the building.
- Hardware fit. Builds for fully resident cards and for tiered CPU / PCIe / NVMe expert setups — including single-24 GB-GPU servers.
- Cost and latency. Fewer bytes moved per token, a smaller footprint, and a recipe tuned for the hardware you actually own.
- Authorised behaviour changes. Remove refusal behaviour from a model you own or license for creative, research or agentic use, and keep the capability numbers honest.
- Research and evaluation. Reproducible artifacts for comparing quant recipes, abliteration strengths and serving configurations.
Questions we get
Do you need the original weights?
Yes for a clean build. We work from an open checkpoint or weights you own. A quantised derivative cannot be edited as cleanly as the source — the source is the reference.
Does abliteration hurt quality?
It changes the weights, so it has a cost. We measure refusal rate on held-out prompts and KL / top-1 agreement against the base, and report both sides. A smaller edit with a measured cost beats a larger one with a worse model.
Is this a jailbreak?
No. There is no chat-template change, system-prompt override, LoRA or runtime hook. The weights are the model. We only edit models you have the right to modify, and we do not touch third-party hosted services.
What do we receive?
The model artifact, tokenizer and sidecars, a serving configuration, the gate results, and the notes needed to reproduce the build. Formats include GGUF and safetensors, with a custom tier map where one is used.
Have a model that needs to fit — or behave differently?
Bring the model, the hardware and the quality bar. We will scope the build and quote it as a fixed piece of work.