[j-luwierski]

What

Adds residual control-vector projection to the engine: per-layer control vectors loaded from GGUF files are projected onto the residual stream during generation, so model behaviour can be steered at inference time without modifying the weights.

New options

• --control-vector-scaled - enable the projection with a given strength
• --control-vector-layer-range - apply the vector only to a range of layers
• --cvec-mode project - projection mode
• --cvec-dir - directory with the per-layer GGUFs

Ready-to-use control vector

A refusal-projection control vector for Qwen3.8-Flash-Next can be downloaded from:

https://huggingface.co/Cudecnik/Qwen3.8-Flash-Next-refusal-projection

[Niko1221]

Give me an hour please.

[Niko1221]

Thanks for this, and sorry it sat so long. This landed in v0.1.9 as the experimental speed projection. It's the same idea: the same llama.cpp-style flags (--control-vector-scaled, --control-vector-layer-range 4 44, --cvec-mode project, --cvec-dir per-layer) and the same operation, h -= s (h.v) v on the residual after each steered layer, with a refusal-direction projection vector.

I implemented it separately rather than merging this branch:

• one kernel that runs on every hyper-connection stream right after each layer's FFN write, in all three paths (per-token decode, the verify windows and the batched prompt path);
• a per-request switch (a toggle in the web app, or "experimental_speed_projection": false in the API). Switched off, the output is token-for-token the stock model's;
• setup asks for it and defaults to off, and the docs label it experimental and say what it does (fewer refusals).

The vector ships in data/experimental-speed-projection/.

So I'm closing this without merging, and none of the changes from this branch are applied (they'd conflict with the new code). Thanks for the idea and the pointer to the vector.

[j-luwierski]

Sure, I understand. No worries. I had a lot of fun trying my hand at this task anyway :) Great job, by the way. I'll try to come up with a different new PR. *POZDRAWIAM* J*akub L**uwierski* niedz., 27 wrz 2026, 17:43 użytkownik Niko ***@***.***> napisał:

…

*Niko1221* left a comment (Niko1221/Strata#15) <#15 (comment)> Thanks for this, and sorry it sat so long. This landed in v0.1.9 as the *experimental speed projection*. It's the same idea: the same llama.cpp-style flags ( --control-vector-scaled, --control-vector-layer-range 4 44, --cvec-mode project, --cvec-dir per-layer) and the same operation, h -= s (h.v) v on the residual after each steered layer, with a refusal-direction projection vector. I implemented it separately rather than merging this branch: - one kernel that runs on every hyper-connection stream right after each layer's FFN write, in all three paths (per-token decode, the verify windows and the batched prompt path); - a per-request switch (a toggle in the web app, or "experimental_speed_projection": false in the API). Switched off, the output is token-for-token the stock model's; - setup asks for it and defaults to off, and the docs label it experimental and say what it does (fewer refusals). The vector ships in data/experimental-speed-projection/. So I'm closing this without merging, and none of the changes from this branch are applied (they'd conflict with the new code). Thanks for the idea and the pointer to the vector. — Reply to this email directly, view it on GitHub <#15?email_source=notifications&email_token=AV2UZBD5C6DITLB4KN32XGT5REYTPA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKOBVG4ZTGOJUGAY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-5857339401>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AV2UZBEI7DVZ2DIVE2KS4VD5REYTPAVCNFSNUABGKJSXA33TNF2G64TZHMYTGOBVHE2DMMZQGE5US43TOVSTWNJVHE3TANJSGEZTJILWAI> . You are receiving this because you authored the thread.Message ID: ***@***.***>