Hacker News Reader

Comment by wren6991 | Hacker News Reader

Speaking to the "uncensored model" angle: there's little reason to distribute abliterated weights anyway. Instead of orthogonalising the weights that write back to the residual stream, you can just orthogonalise the activations themselves. It's equivalent.

Orthogonalising activations at runtime is computationally cheap. Just distribute the refusal vectors (few thousand floats per layer), then run against the stock weights. Antirez's DS4 already supports this: https://github.com/antirez/ds4/blob/8db1d1d155cb0400a86a86b9...

Abliterated weights are just a bad habit we've gotten into. It's also deeply suboptimal from a precision point of view to take a model that's already been QATed and distributed in pre-quantised form (DeepSeek V4, Kimi K2.5 or K3...), modify its weights, and re-quantise it. Similarly, abliterated models regain some of their refusal behaviour when they're re-quantised after abliteration -- avoidable by keeping the two separate.

View on HN

I believe abliterated models are mostly still created at this point because they're "universal": they can not only be run locally, and on cloud GPUs, but also on "managed inference" providers (i.e. services where you hand them a model URI, and they blindly fetch it, load it, and give you inference access to it through standard text/chat-completion APIs. Think HuggingFace Spaces, or Google CoLab, or CloudFlare Workers AI.)

Such managed inference providers have (for now) plausible deniability of behaving ethically (at least enough that they don't get boycotted / scare away investors) due to them being "blind" to what gets run on their systems. They're acting as the inference equivalent of data transit carriers.

But I don't think it would be possible for managed inference providers to publicly expose "runtime activation steering" in the way antirez's DS4 does, without that reading much more explicitly as them inviting unethical workloads.

(Yes, there are other things you can do with runtime steering. But almost all of those things are workload-specific, relying on you privately tuning to the needs of your own dataset. And if you can do that, you can run inference without the help of a managed inference provider. The only time a customer will come along with a pre-made runtime-steering vector file in hand, is if that vector is an alignment-orthogonalization vector.)

These providers can also just ignore insinuations they're being "unethical" when people come to them with steering vectors in hand. Nobody has to listen to the scolds.

Not if those people are legislators or law enforcement

Yeah I use a custom fork of llama.cpp that has an abliteration feature that basically does this. It's sloppily vibe coded and I don't have time to coordinate on a way to do this cleanly upstream, but it's absolutely possible and saves a lot of time and bandwidth from being wasted

> Similarly, abliterated models regain some of their refusal behaviour when they're re-quantised after abliteration

Thanks for this information, Q4 seemed fine but they reappeared again in Q5 with an vengeance, I couldn't understand why. Very Strict and I've only found one jail break that barely works around 60% of the time.

Can you explain this a bit to a non-expert?

I haven't wrapped my mind around this

Instead of editing the weights so they don't create the refusal signal, just let them do whatever, then delete the refusal signal itself. You don't want to edit quantised weights because it causes a loss of precision that can be pretty bad.

This is the original description of abliteration and it's quite approachable and interesting to read: Refusal in Language Models Is Mediated by a Single Direction (https://arxiv.org/abs/2406.11717). Warning: changes to your world view caused by seeing "HarmBench" used to maximise expected harm instead of minimising it may be irreversible.

There's an empirical observation that models often have a single direction in their activation space for "hmm no I shouldn't do this". It forms naturally during pre-training, and is then surfaced during post-training to make the model refuse to engage in certain behaviour.

With a little bit of linear algebra you can zap that direction from the model's activations, and it stops refusing to do things. You can also do the opposite: magnify that direction, and the model refuses to do anything at all.

Damn what's happened since this? Presumably they scramble refusal intentionally somehow now? Like intentionally couple it to "directions" that effect performance if messed with? Or is it more like just don't rely on the model to refuse and instead capture bad responses between generation and delivery?

I'm not active in this space but why do you think anything happened since this? As far as I know, it still works.

I've seen attempts to obfuscate the refusal direction, like here: https://arxiv.org/html/2608.18093v1

Also this one was interesting, training the model to give preambles with reasons for the reasons for refusal seems to make it less sensitive to modulating the single refusal direction: https://arxiv.org/html/2505.19056v1

My empirical observation is that when a new model is released on HuggingFace, an abliterated version with < 10/100 refusals (baseline usually 100/100) is uploaded the same day, so either these techniques don't work very well or the open-weight labs aren't applying them.

There's some defense-in-depth, like a lot of the "guardrails" people hit on cloud models are classifiers applied to prompt or output, not a refusal generated by the model. Also closed-weight models obviously try to avoid this by not letting you see or modify the weights.

I'm pretty sure this was achieved with prompting rather than with weights, but there is a chatbot available that tries to maximize the motivated refusals:

https://www.goody2.ai/chat

I didn’t know about that method, thank you. I’ve needed a local model for security research but Qwen 27b abliterated did 30% worse than the stock weights on my internal benchmarks (I just skip the public benches now, it’s honestly useless noise on an operational level).

Interesting. Is there a paper that explains this in a bit more detail, like [0] for abliteration (underlying the Heretic software, afaik)?

[0] https://arxiv.org/abs/2406.11717

That paper you linked has all of the information you need. The linear algebra they do on the weights there to null out one direction reduces to a single (dot-product + broadcast-multiply + add) on the activations.

So... distribute a LoRA (or equivalent) that modifies the base weights with the abliteration vectors. That makes sense as it would be possible to try different abliterations and keep the storage space down.

Yeah, orthogonalisation is a special case of a rank-1 LoRA.

I don’t think this is true.

Could you please explain why? It's an additive update to the weights, adding an outer product of a vector with its transpose, which must have rank 1. What am I missing?

You can’t diagonalize a generic matrix by adding a rank 1 matrix. That holds only for dimension 2.

A question that comes up in my mind, since I don't fully understand how this works, is how does this affect runtime performance. It feels like abliterated weight models would work faster than some extra runtime operations?

The vector that needs to be checked is length n while computing that vector requires n^2 operations. I haven't benchmarked it but I expect the performance overhead to be a rounding error.

Who is offering the refusal vectors or instructions on how to generate them?

I am, in fact, I’m offering something much better, a compact format that exactly restores an abliterated model from a tiny JSON file:

https://www.reddit.com/r/LocalLLaMA/s/iksvmXBzuC

Here's a widely used toolkit: https://github.com/p-e-w/heretic

Distributing the vectors themselves isn't (yet) common practice, because people have gotten used to just putting the full modified weights up on HuggingFace's huge free storage.

Reply on news.ycombinator.com