Skip to content

v.0.5.3-alpha

Choose a tag to compare

@omgitsbase omgitsbase released this 01 Oct 03:46
· 36 commits to main since this release

Install command, run in a user level powershell.

irm https://raw.githubusercontent.com/omgitsbase/llmash/main/install.ps1 | iex

On Linux:

curl -fsSL https://raw.githubusercontent.com/omgitsbase/llmash/main/install.sh | sh

Already installed: llmash update.

Abliteration

llmash abliterate <model> uncensors a model in place. It does not touch the weights: it writes a small control vector beside them that the model picks up on its own the next time it runs. ablate is the same command, and pull --ablate does it right after a download.

  • It reads the model's own refusal direction, layer by layer, from the gap between how it answers harmful and harmless prompts, then searches sixteen projection vectors for the gentlest one that still stops the refusals. A refusal is decided in the opening words, so a first-token gate counts them cheaply, and the search is held to a forward-KL budget measured against the base model on harmless prompts. A model that will not come apart cleanly writes nothing and says so, rather than shipping a damaged vector.
  • The result is <model>.ablation.gguf, a control vector with mode = "project": zero bytes changed in the model, and the removal happens at inference as cur - w (r·cur) r per layer. Launch applies it on its own and the registry hides it like any other sidecar; LLMASH_NO_ABLATE=1 runs the model untouched, and deleting the file puts the refusals back.
  • The harmful/harmless split it reads is pulled once and cached under ablate-data. The run shows friendly progress the whole way and finishes well under two minutes on a single modern card; a mixture-of-experts model is cheaper still, since it only moves its active parameters.

Runtime

The runtime changed, so llmash update replaces the one you have (its stamp carries the new commit).

  • It carries llama-ablate and the projection-mode control vector. The projection runs per layer on that layer's own device, so it is correct on a model split across several GPUs, by the same mechanism the ordinary additive control vector already relies on.
  • A fused matvec-add no longer trips the CUDA mmvq assert at high concurrency: it counts the columns from the added tensor's rows and reads a strided source as columns only when that source is contiguous. This is a general correctness fix and is not specific to abliteration.

Checked before release:

  • Refusals on 100 harmful prompts, judged by a model reading each whole answer, base → abliterated: Qwen3.8-27B 94 → 2, Qwen3.5-4B 98 → 22, Gemma 4 E4B 98 → 3, Gemma 4 26B-A4B 99 → 2. Gemma needs the per-layer direction; a single global direction leaves one massive-activation channel that keeps it refusing.
  • StrongREJECT, the human-validated fine-tuned grader rather than a teacher model judging itself, on qwen3.5-4b: 0.05 base → 0.53 abliterated.
  • First-token KL against the base on harmless prompts stays low where the method holds (Qwen3.8-27B 0.11, Gemma 4 E4B 0.06); the search rejects and writes nothing when it would not.
  • llmash abliterate qwen3.5-4b --yes end to end: the split pulled and cached, the vector written beside the model, picked up on the next run with the refusals gone, and the model running untouched under LLMASH_NO_ABLATE=1.
  • The Windows and Linux runtimes built from the same commit; the client program and its tests on both.

The runtime carries abliteration and the mmvq fix; everything else is unchanged from 0.5.2.

Fixed since release (same version; the program and installer were replaced in place)

  • llmash ablate says why it failed instead of "ablation did not complete": a runtime that cannot load the model's architecture, too little free GPU memory, or the tool's own last lines.
  • On a machine that runs upstream llama.cpp (an older NVIDIA driver, a non-NVIDIA GPU, or a llama-server found on PATH) llmash ablate says that abliteration needs llmash's runtime and what would get it, instead of "run llmash update".
  • The installer no longer lets a llama-server that is only on PATH stand in for llmash's runtime on a card that runs it.
  • The server applies an ablation vector only on a runtime that can project it; another build would add it to the stream and damage every answer.
  • A model kept in an Ollama store gets its vector in llmash's own folder, not inside Ollama's blobs; the prompt-set download retries when the hub rate-limits it.
  • A second llmash serve refuses a port the running one holds instead of sharing it.
  • llmash help lists ablate; help run and help pull list the flags they were missing.