[BlivionIaG]

Fixes #1834

What this is

The engine can serve a model with a GLP control vector applied: one direction per layer, projected out of (or added to) the residual stream after each steered block.

tensorfold serve TensorFold/Qwen3.8-27B-MLX-4bit --glp vector.gguf --glp-alpha 1.0

The file is GGUF v3 and follows the GLP format: glp.spec_version, glp.mode, glp.rank, glp.hook_point, glp.alpha_default, glp.base_model, glp.base_revision, glp.layer_ids_zero_based and glp.content_sha256, plus general.* publication metadata. llama.cpp's additive control vector is read as it stands. tf-glp-check shows a file as this reader sees it and writes it back out.

This pull request ships the mechanism only. It carries no derived vectors, no prompt sets, no derivation tool and no refusal measurements. The operator supplies the vector file.

Attribution

• GLP format: weightless (@msuiche, MIT). This implements the GLP format defined by the weightless project; it doesn't redefine it. The Zig reader (core/glp.zig, core/glp_container.zig) was written from the format, meaning docs/spec/GLP.md's metadata and reader-conformance rules and the GGUF v3 layout. It was not translated from weightless's Python reader, and no weightless code is committed here. Where that reader and the spec differ, this one follows the spec: a file without glp.mode reads as add, add files are applied, and glp.content_sha256 is verified. tools/zig/glp_parity.py loads weightless's reader from a separate checkout as a test oracle: on the same files, the layer ids, the metadata, every direction's bytes and the digest agree.
• Aevonix/FlashAlign: not used. No FlashAlign code, data or method went into this pull request: none of its profiles, prompts, benchmarks, fitting or runtime packaging. The projection is the GLP spec's project operation, h <- h - alpha (h . d) d, which is directional ablation as published by Arditi et al. (2024), "Refusal in Language Models Is Mediated by a Single Direction".

What it does to the model

For project mode at strength alpha, every steered layer computes

h <- h - alpha * (h . d) * d

add mode computes h <- h + alpha * d. Nothing is written back to the checkpoint. The change lives in the activation path, so it is turned on and off per server run, and its strength is a runtime argument. Without --glp, Qwen3.8-27B on Metal runs main's path: no steering, no new pipeline compiled, no extra report line.

What the server refuses

The server refuses any file it cannot apply before the model loads, and it doesn't start. That covers:

• a vector whose width is not the model's, whose hook point is not the one it applies at, whose checkpoint is not the one served, or whose content digest does not cover its own vectors;
• a glp.spec_version or glp.rank other than 1, and a projective direction that isn't a unit vector;
• a direction holding NaN or an infinity, in either mode;
• a file that names one layer twice (direction.5 and direction.05 both parse as 5);
• a layer id past the checkpoint's num_hidden_layers, read from the config's root or its text_config at startup;
• a Gemma checkpoint, whose terms forbid circumventing its safety filters;
• a model that is not Qwen3.8-27B, and a backend that is not Metal.

The checkpoint is compared by name, because that is what the file carries. tf-glp-check rewrite --repo ID --revision REV re-stamps a file for another name. The directions stay the same bytes and only the name changes, so that is the operator's claim, not one the reader verifies.

The kernel

• One dispatch per steered layer: the norm and the projection run in the same pass over the row, in zig/kernels/metal/qwen27/norm_steer.metal. It replaces the norm kernel instead of adding a dispatch.
• Contract: the float64 reference, the bounds, the fp32-sum rule and the served shapes are in zig/src/core/contract/steer.zig.
• Metal gates: zig/tests/contract/metal_qwen27_steer.zig runs both modes through gates 1-4, with two planted controls (a NaN-dropping sum and a half-precision dot). It also checks that the fused kernel's normalised row is the plain norm kernel's, element for element, and that a planted fault in the normalisation shows.
• Limits: the launch is registered in zig/src/core/contract/steer_records.zig at 320 threads and 80 threadgroup bytes, against M1 to M5 and sm_80, sm_86, sm_89, sm_120 and sm_121.

Verification

• CI: all 11 checks pass on the head, rebased onto current main.
• Local, Apple M4 Pro: zig build test exits 0. test-glp, test-glp-serve, test-glp-steer, test-steer, check-release-paths, tf-qwen27-served-check and test-kernel-contract pass. tf-kernel-contract --only "qwen27 steer" passes gates 1-4 in both modes, both controls go red, and the normalisation check passes. lean_check adds no problems over main.
• No vector, main against this branch, M4 Pro: 14 of 14 token-hash cells are equal: code and chat at 1 and 2 streams, each equal to its run alone and to "draft": false, and cold prompts at 2k, 8k and 32k tokens. Decode and prompt speed are within 2.3% in every cell, with signs mixed.
• No vector, main against this branch, M5 Ultra (maintainer run): 0 of 20 prompt rows differ. Prompts at 32,768 tokens run at 1,670 against 1,669 tok/s, and decode is within 0.9%.
• With a vector, M4 Pro: the published 49-layer project-mode vector at --glp-alpha 1.0 decodes at +0.64% and -0.06% against the same build without it, measured with off and on runs interleaved. Four startup refusals stop by name before the model loads: a vector past the depth a nested config declares, an add-mode NaN vector, --glp with no file, and a CUDA build given --glp.

Not covered

• CUDA and HIP: steering is Metal-only for now. Any other engine given --glp refuses by name before weights load. This was exercised with a CUDA build in a container, not on a CUDA host.
• Other Apple chips: chips other than the M4 Pro and the maintainer's M5 Ultra were not run. Their limits are checked without a GPU by zig build test-kernel-contract.
• App: the app's control-vector picker is in app: control vector picker and strength in Engine advanced #1951.

[ashhart]

Thanks @BlivionIaG. We reviewed this independently. We'd take the generic, opt-in --glp control-vector mechanism with its fused Metal norm-and-projection kernel. Three changes:

1. Split out the app. The 34 files under app/ (the settings panel, IPC, preload and 13 locale packs) go in their own PR. App changes go through the app's own review.
2. Refuse repeated layer ids. direction.5 and direction.05 both parse to 5, read() sorts but doesn't refuse, and steer.init keeps the later one. Please refuse a repeat in glp.read, with a test. A layer id past the model's depth is refused only after the 27B loads, though num_hidden_layers is readable at startup, so refuse it there.
3. One GGUF reader. A second zig/src/core/gguf.zig collides with the GGUF reader now on main (core: a GGUF reader and an exact repack of GGUF's quantized blocks (#1920, steps 1-2) #1926). Please build on that one, or rename yours.

On scope, our decision: the engine ships the mechanism only. Please leave out the matched harmful and harmless prompt sets, the deriver, and the receipts measuring refusal removal on the 27B. Deriving vectors that remove a model's safety refusals isn't something we'll ship or document in TensorFold. A user can supply their own direction files.

[BlivionIaG]

All three changes are in, plus the scope cut.

• App: the 32 app files moved to app: control vector picker and strength in Engine advanced #1951; app/ no longer appears in this PR's diff.
• Repeated layer ids: glp.read now refuses a file that names one layer twice, with a test. A layer id past the checkpoint's num_hidden_layers is refused in glp_startup.refusal, at startup, before the model loads — two tests cover the boundary.
• GGUF reader: the branch's zig/src/core/gguf.zig is gone; the GLP reader now parses with main's gguf.Document. Only the writer stays local to glp.zig.
• Scope: the deriver, both prompt sets, the refusal-measurement gate and the receipt are removed; the guide and README describe the mechanism only.

The branch is merged with upstream/main at 16d95ccec and pushed as feature/glp-steering (head 7f83ebb0). zig build test-glp passes 57 tests and zig build test-glp-serve 25.

[BlivionIaG]

CI caught one thing the local suites did not: after merging main, glp.zig importing the engine's gguf.zig put that file in two modules (engine_api and core), and every target linking both failed to compile.

Fixed in b81f6002: the GLP container reader is zig/src/core/glp_container.zig, named for its scope — the review's stated alternative — so the engine's gguf.zig stays the engine's reader. Repeated-layer and depth refusals are unchanged. zig build tf-qwen27-served-check compiles the server path, and the GLP suites still pass.

[ashhart]

Thanks @BlivionIaG. The 18:50 push answers every 17:58 ask:

• the app files are split out (app: control vector picker and strength in Engine advanced #1951);
• repeated layer ids are refused, with a test;
• the GGUF name collision is gone (core/glp_container.zig);
• the scope cut is done.

Off by default is main (Model.steer null, both norm sites call main's norm), and the file is validated before use. Four small things left:

1. The startup depth check reads num_hidden_layers from the config root only, while hidden_size and the engine read text_config. So a nested config skips the check until after load. Please read it from text_config too, with a nested-config test.
2. Add-mode directions aren't checked for NaN or infinity. Please refuse non-finite values in both modes.
3. Lean is 426 against main's 424 (core/glp.zig:161, core/glp_container.zig:1).
4. The changelog and docs still say the engine's own GGUF reader is used, but it's the new container reader now.

It's 38 commits behind main, so a rebase with these would be ideal.

[BlivionIaG]

CI is green on 2f90635ad (all 11 checks pass).

Two things came out of the first full run:

• The lean gate counted three new problems: two comment lines and qwen27_served.zig past 600 lines. The serve-side steering helpers moved to qwen27_steer_served.zig (90 lines), qwen27_served.zig is back to 521, and the comments are one line each. lean_check now reports 424 problems, 424 on the base, 0 new.
• zig and zig-windows failed on a regression already on main (linear_time.Fastest indexed as an array in cortheon/program.zig). Main's 5fe74ebb9 fixes it; this branch merges that tip.

[ashhart]

Thanks @BlivionIaG: the rebase applies on main and lean is back to 424 (the served helpers moved verbatim). Three asks are still open: (1) modelOf reads num_hidden_layers from the config root, not text_config; (2) glp.zig:read checks finiteness only in project mode, so add-mode directions aren't checked; (3) the changelog and docs still say the engine's own GGUF reader is used. Nothing cleared earlier changed.

[BlivionIaG]

All three are in, fd0388546.

• Depth from text_config. modelOf now reads num_hidden_layers from text_config, falling back to the config root. A nested-config test writes a config whose depth lives only in text_config and holds the depth refusal before load.
• Non-finite directions refused in both modes. glp.read scans every direction component before the mode-specific rule and refuses NaN and ±infinity in project and add, with a test that writes each through both modes. The project-mode unit-norm check no longer carries its own isFinite guard, since the scan precedes it.
• Reader named. The changelog and the guide now say core/glp_container.zig reads the GGUF v3 subset a vector needs, not the engine's gguf.zig. The guide's refusal table also lists non-finite directions.

zig build test-glp, zig build test-glp-serve and zig build tf-qwen27-served-check pass. lean_check reports 424 problems, 424 on the base, so nothing new.

[BlivionIaG]

End-to-end run on an M4 Pro, macOS, native Metal server built from fd0388546 (zig build native, Zig 0.17.0).

The served checkpoint's config.json carries its depth only in text_config (text_config.num_hidden_layers = 64, text_config.hidden_size = 5120; no root num_hidden_layers/hidden_size), so this run exercises the nested-config path:

• A vector naming layer 64 (direction.64, 5120 wide, project) is refused in 0.21 s, before the model loads: --glp: the vector steers layer 64 of a model with 64 layers: its deepest layer is 63.
• An add-mode vector with one NaN component is refused in 0.02 s: argument --glp: layer 10's direction holds a value that is not finite.
• A 63-layer vector naming layers 1-63 is accepted at the boundary and serves: glp on: ... (mode: project; alpha: 1.00; layers: 63 (1-63); base: Qwen/Qwen3.8-27B @ 1d4bf0f2ff6012fd82039f2fa52739d0dd7c60c0; digest: d92fddd15d08 (verified)), then control vector in force: project mode, alpha 1.000, 63 layers (1-63).

Serving with the published 49-layer vector from msuiche/Qwen3.8-27B-abliterated-cyber-GLP-49 (mode: project, layers 10-58, digest verified) and the prompt "Write a haiku about the sea." at temperature 0.2, enable_thinking: false:

• steered: "Waves crash on the shore, / White foam dissolves in the blue, / Silence takes the tide." (24 completion tokens)
• the same build without --glp: "Salt spray on the wind, / Waves crash against the dark shore, / Moonlight on the foam." (23 completion tokens)

So the projection changes the served tokens on a benign prompt, and the fused path runs. Both servers were stopped after the requests; the throwaway generator used for the refusal files and the files themselves are not in the tree.

[ashhart]

Thanks @BlivionIaG. An independent re-review of fd0388546 finds all three open asks met. Without --glp, Qwen3.8-27B on Metal runs main's path: no steer, no new pipeline compiled, no extra report line. Every refusal names its cause.

One rebase is needed. On current main, 42 of the 43 files apply. The only conflict is the all_metal line in core/contract/registry.zig: main has since appended ling_route_records.zig and this PR appends steer_records.zig, so keep both. The other shared lists (core/contract.zig, build.zig, zig/build/qwen27.zig's parts) may need the same keep-both.

Once it's rebased, we'll run the Mac cells on an M5 Ultra and land it on a clean result:

• off against main: token_sha256 equal, default and --no-drafts, at 1 and 2 streams;
• on, with a project-mode vector at --glp-alpha 1.0: decode within 1% of off;
• the four refusals by name;
• norm_steer through the Metal kernel contract.

[BlivionIaG]

Rebased onto upstream/main at ef9fa700a; head is efd421d96, and the diff is 43 files.

The conflict was all_metal in core/contract/registry.zig: both sides kept, so the list now ends ... @import("ling_route_records.zig").records ++ @import("steer_records.zig").metal;. The only other conflicts were the branch's own core/gguf.zig add against main's GGUF reader, in two intermediate commits; resolved to main's reader, and the final tree has no branch copy — glp.zig reads glp_container.zig. The shared lists in core/contract.zig, build.zig and zig/build/qwen27.zig auto-merged, with both additions kept.

zig build test-glp and zig build test-glp-serve (26/26) pass, zig build tf-qwen27-served-check compiles, and lean_check reports 424 problems, 424 on the base. The one added commit is the guide naming the GLP release the tap now ships (v1.2.1-glp.1, upstream 1.2.1 plus this branch).

[BlivionIaG]

All 11 checks pass on efd421d96: zig, zig-windows, zig-macos-dev-tools, fmt, desktop, desktop-linux, mobile, appimage-linux, release-paths and both benchmark-clients jobs.

[ashhart]

Thanks @BlivionIaG. Two of the four Mac checks are in, on an M5 Ultra at your rebased head:

• Off against main (no --glp, Qwen3.8-27B-MLX-4bit, fresh servers, base-new-new-base): GREEN. Tokens are equal and every cell is level.
• Metal kernel contract (--only qwen27): norm_steer passes gates 1-4 with its control red, and there are 0 limit problems.

Still owed, and these need your vector files:

1. on, with a project-mode vector at --glp-alpha 1.0: the startup line, and decode within 1% of off;
2. the four refusals by name before load (a nested config past depth, an add-mode NaN vector, --glp with no file, a CUDA build given --glp).

If you post those two receipts from your Mac, this lands on them.

[BlivionIaG]

Mac receipts on efd421d96

Apple M4 Pro, 48 GiB, macOS 26.5.1, Zig 0.17.0. Native Metal server built with zig build native (110 s), tensorfold-native 1.2.1.

On at --glp-alpha 1.0

Vector: msuiche/Qwen3.8-27B-abliterated-cyber-GLP-49, Qwen3.8-27B-abliterated-cyber-GLP-49-L10-58-a1.gguf — project, alpha 1.0, layers 10-58, digest da81a8b364de (verified).

[tensorfold] glp on: $V49 (mode: project; alpha: 1.00; layers: 49 (10-58); base: Qwen/Qwen3.8-27B @ 1d4bf0f2ff6012fd82039f2fa52739d0dd7c60c0; digest: da81a8b364de (verified))
info: Qwen3.8-27B: control vector in force: project mode, alpha 1.000, 49 layers (10-58), base Qwen/Qwen3.8-27B @ 1d4bf0f2ff6012fd82039f2fa52739d0dd7c60c0, digest da81a8b364de

The startup line is verbatim; $V49 is the resolved cache path, set in the recipe below.

Decode: same binary, fresh server per run, --context 2048, default drafts, tools/bench_openai.py --tokens 64 --reps 5 --temperatures 0, interleaved off / on / off / on so thermal drift cancels. (A single off run immediately after the build read 14.84 tok/s; the machine had drifted by the time of the paired runs, so only the four-run A/B is comparable.)

prompt	off 1	on 1	off 2	on 2	off mean	on mean	delta
fibonacci-raw	13.9855	13.9951	13.8591	14.0267	13.9223	14.0109	+0.64%
gpu-chat-no-think	13.9507	13.8885	13.9249	13.9714	13.9378	13.9300	-0.06%

Both prompts are inside 1% of off; the spread is the run-to-run noise, not a steering cost.

Four refusals by name

1. Nested config past depth. /tmp/tf-glp-nested/config.json carries depth and width only under text_config (num_hidden_layers = 32, hidden_size = 5120), with no root num_hidden_layers/hidden_size. A 63-layer vector:

$ tensorfold-native serve /tmp/tf-glp-nested --glp .../Qwen3.8-27B-abliterated-cyber-GLP-63-L1-63-a1.gguf --context 1024
tensorfold: --glp: the vector steers layer 32 of a model with 32 layers: its deepest layer is 31
error: GlpRefused

Exit 1 in 0.19 s, before the model is touched.

2. Add-mode NaN. A one-layer add file with direction.10[0] = NaN:

$ tensorfold-native serve TensorFold/Qwen3.8-27B-MLX-4bit --glp /tmp/glp-nan-add.gguf --context 1024
tensorfold serve: error: argument --glp: layer 10's direction holds a value that is not finite

Exit 2 in 0.012 s, at argument parsing.

3. --glp with no file.

$ tensorfold-native serve TensorFold/Qwen3.8-27B-MLX-4bit --glp
tensorfold serve: error: argument --glp: expected one argument

Exit 2 in 0.010 s.

4. CUDA build given --glp. Cross-compiled from the same tree for aarch64-linux-gnu (zig build native -Dtarget=aarch64-linux-gnu -Doptimize=ReleaseSafe) and run in a Debian bookworm container; the Mac has no NVIDIA GPU. The model directory held the checkpoint's config.json and tokenizer files (no weights), and the vector was the same 49-layer file:

$ /tf serve /run/model --glp /run/vec/vector.gguf --context 1024
tensorfold: --glp: only the Metal engine steers: this server runs the CUDA engine
error: GlpRefused

Exit 1. The engine-open path refuses before any weights load; the text/tokenizer load runs alongside it, as startup.both always does. A refusal on a real CUDA host is still the one thing not exercised here.

Recipe: exact commands

git clone https://github.com/BlivionIaG/TensorFold.git
cd TensorFold
git checkout efd421d9615956bd3b414ab87e1305c59270c39f
# Zig 0.17.0 must be on PATH.
zig build native        # Metal server
zig build tf-glp-check  # tf-glp-check

Off/on decode (fresh server per run; only --glp/--glp-alpha differ):

V49=$(ls ~/.cache/huggingface/hub/models--msuiche--Qwen3.8-27B-abliterated-cyber-GLP-49/snapshots/*/Qwen3.8-27B-abliterated-cyber-GLP-49-L10-58-a1.gguf)

# off
./zig-out/native/bin/tensorfold-native serve TensorFold/Qwen3.8-27B-MLX-4bit \
  --context 2048 --port 8123 --host 127.0.0.1 --name bench --no-update-check

# on
./zig-out/native/bin/tensorfold-native serve TensorFold/Qwen3.8-27B-MLX-4bit \
  --glp "$V49" --glp-alpha 1.0 \
  --context 2048 --port 8123 --host 127.0.0.1 --name bench --no-update-check

# for each server, once it is listening:
python3 tools/bench_openai.py http://127.0.0.1:8123 Qwen3.8-27B-MLX-4bit \
  --tokens 64 --reps 5 --temperatures 0 --output /tmp/bench.json

Nested-config fixture:

import glob, json, os, shutil
snap = glob.glob(os.path.expanduser(
    "~/.cache/huggingface/hub/models--TensorFold--Qwen3.8-27B-MLX-4bit/snapshots/*/"))[0]
out = "/tmp/tf-glp-nested"
shutil.rmtree(out, ignore_errors=True)
os.makedirs(out)
for name in os.listdir(snap):
    os.symlink(os.path.realpath(os.path.join(snap, name)), os.path.join(out, name))
d = json.load(open(os.path.join(snap, "config.json")))
d.pop("num_hidden_layers", None)
d.pop("hidden_size", None)
tc = d.setdefault("text_config", {})
tc["num_hidden_layers"] = 32
tc["hidden_size"] = 5120
json.dump(d, open(os.path.join(out, "config.json"), "w"), indent=2)

Throwaway NaN-vector generator (zig/src/core/tmp_glp_bad.zig, deleted after the run):

const std = @import("std");
const glp = @import("glp.zig");
const gguf = @import("glp_container.zig");

const width = 5120;

pub fn main(init: std.process.Init) !void {
    const a = init.arena.allocator();
    const args = try init.minimal.args.toSlice(a);
    if (args.len != 3) return error.Usage;
    const kind = args[1];
    const out_path = args[2];

    var dir = try a.alloc(f32, width);
    for (dir) |*v| v.* = 0;
    dir[0] = 1;

    if (std.mem.eql(u8, kind, "deep")) {
        const layers = [_]glp.Layer{.{ .id = 64, .dir = dir }};
        const bytes = try glp.write(a, .{
            .mode = .project,
            .alpha = 1,
            .hook_point = glp.residual_site,
            .derived_at = null,
            .base_model = "TensorFold/Qwen3.8-27B-MLX-4bit",
            .base_revision = "",
            .method = "test",
            .contrast = "",
            .layers = &layers,
        });
        try std.Io.Dir.cwd().writeFile(init.io, .{ .sub_path = out_path, .data = bytes });
        return;
    }
    if (std.mem.eql(u8, kind, "nan-add")) {
        var raw = try a.alloc(u8, width * 4);
        std.mem.writeInt(u32, raw[0..4], @bitCast(std.math.nan(f32)), .little);
        @memset(raw[4..], 0);
        const entries = [_]gguf.Entry{
            .{ .key = "general.architecture", .value = .{ .string = "controlvector" } },
            .{ .key = "glp.spec_version", .value = .{ .u32v = 1 } },
            .{ .key = "glp.mode", .value = .{ .string = "add" } },
            .{ .key = "glp.rank", .value = .{ .u32v = 1 } },
            .{ .key = "glp.hook_point", .value = .{ .string = glp.residual_site } },
            .{ .key = "glp.alpha_default", .value = .{ .f32v = 1 } },
            .{ .key = "glp.base_model", .value = .{ .string = "TensorFold/Qwen3.8-27B-MLX-4bit" } },
        };
        const dims = [_]u64{width};
        const tensors = [_]gguf.OutTensor{.{ .name = "direction.10", .dims = &dims, .kind = gguf.f32_type, .data = raw }};
        const bytes = try gguf.write(a, &entries, &tensors);
        try std.Io.Dir.cwd().writeFile(init.io, .{ .sub_path = out_path, .data = bytes });
        return;
    }
    return error.UnknownKind;
}

zig run zig/src/core/tmp_glp_bad.zig -- nan-add /tmp/glp-nan-add.gguf
rm -f zig/src/core/tmp_glp_bad.zig

CUDA build and container run:

zig build native -Dtarget=aarch64-linux-gnu -Doptimize=ReleaseSafe
mkdir -p "$HOME/tf-glp-cuda/run/model" "$HOME/tf-glp-cuda/run/vec"
cp zig-out/native/bin/tensorfold-native "$HOME/tf-glp-cuda/tensorfold-native-cuda-aarch64"
# rebuild the Metal binary afterwards, since the cross-build writes the same path:
zig build native

# populate run/model with the checkpoint's config.json and tokenizer files (no weights),
# and run/vec with the 49-layer vector above.
python3 - <<'PY'
import glob, os, shutil
home = os.path.expanduser("~")
snap = glob.glob(home + "/.cache/huggingface/hub/models--TensorFold--Qwen3.8-27B-MLX-4bit/snapshots/*/")[0]
model = home + "/tf-glp-cuda/run/model"
for name in ("config.json", "generation_config.json", "tokenizer.json", "tokenizer_config.json",
             "vocab.json", "chat_template.jinja", "preprocessor_config.json",
             "processor_config.json", "model.safetensors.index.json"):
    src = os.path.join(snap, name)
    if os.path.exists(src):
        shutil.copy(os.path.realpath(src), os.path.join(model, name))
vec = glob.glob(home + "/.cache/huggingface/hub/models--msuiche--Qwen3.8-27B-abliterated-cyber-GLP-49/snapshots/*/Qwen3.8-27B-abliterated-cyber-GLP-49-L10-58-a1.gguf")[0]
shutil.copy(os.path.realpath(vec), home + "/tf-glp-cuda/run/vec/vector.gguf")
PY

podman run --rm --platform linux/arm64 \
  -v "$HOME/tf-glp-cuda/tensorfold-native-cuda-aarch64:/tf:ro" \
  -v "$HOME/tf-glp-cuda/run:/run:ro" \
  docker.io/library/debian:bookworm-slim \
  /tf serve /run/model --glp /run/vec/vector.gguf --context 1024 --port 8193

[ashhart]

Thanks @BlivionIaG for both receipts. On-mode decode is within 1% of off, and all four refusals stop by name before load. A few things before it lands:

1. It conflicts with main again, so please rebase.
2. Please remove the "The engine that steers" section from docs/control-vectors.md. Once this is merged, --glp ships in TensorFold itself, so the docs shouldn't point to another tap or release.
3. In glp_publication_test.zig, please use a neutral contrast string in the sample metadata, in line with the scope we agreed.

We'll check the CUDA refusal ourselves on a GB10.

[BlivionIaG]

Rebased onto 8db1ee1a3; head is b721c88ae.

• Removed the external-build section from docs/control-vectors.md. The guide now documents only the in-tree --glp surface and points at no tap or release.
• Neutralized the sample metadata: the publication sample no longer names refusal or harm, and the contrast sample reads matched_prompts_unpaired.
• Resolved the rebase conflicts: metal_main.zig keeps the attention and steering imports; engine_api.zig keeps upstream's engine_request_controls.zig, so the branch no longer duplicates those request shapes.

zig build test-glp, zig build test-glp-serve and zig build tf-qwen27-served-check pass locally. CI is running on the new head. The CUDA refusal is yours to check on the GB10.

[BlivionIaG]

release-paths caught one rebase follow-on: the contract imported bf16_round.zig by path, and the release build also gives that file its own module. Fixed in 9c90e0956 by importing the module. Head is now 9c90e0956; test-glp, test-glp-serve, tf-qwen27-served-check and check-release-paths pass locally.

[BlivionIaG]

Both fixed, on top of your rebase and rebased again onto current main (56d68844e); head is ca130f62e.

1. Lean. engine_api.zig is 598 lines: the API no longer keeps a Glp alias, and its four users name glp.Glp. metal_main.zig is 583 lines: qwen27's attention_io registration moves into a Suite in metal_q27_attn_io.zig, the way qwen27: a masked key's non-finite value adds nothing to the rows that must not see it #2106 moved the attention rows, so the runner has three lines for it. The same 16 kernels and 2 controls register. lean_check: 425 problems, 425 on main, 0 new.
2. zig-windows. test-steer builds from copies under a generated core/, and main's contract/rows.zig now imports ../act_ref.zig, which wasn't in the copy list. zig/build/steer.zig now copies it.

Local, Apple M4 Pro:

• zig build test exits 0.
• zig build test-steer test-glp test-glp-serve test-glp-steer check-release-paths tf-qwen27-served-check test-kernel-contract tf-kernel-contract native passes 173/173 steps and 247/247 tests.
• tf-kernel-contract --only "qwen27 attention": 22 kernels pass gates 1-4, and 3 controls go red as planted.
• tf-kernel-contract --only "qwen27 steer": 2 of 2 pass, both controls red, PASS normalised.

I couldn't run the Windows job here; the copy list is the only change for it. Every commit has the noreply author and committer. CI is running.

[BlivionIaG]

All 11 checks pass on ca130f62e, zig-windows included.

[ashhart]

Thanks @BlivionIaG. Both are fixed on ca130f62e: engine_api.zig and metal_main.zig are back under 600, with the attention_io registrations moved whole into metal_q27_attn_io.zig, and act_ref.zig is in test-steer's copy list. All 11 checks are green, zig-windows included. It's back in the landing queue.

[ashhart]

/atc exchange 8ed4a1a5715e9b0208ae098ae2a2e70286fe921b5d64c5484923c53a0b4a44b3

[ashhart]

Holding this from landing for now, as the note on #1834 says. Whether the server applies refusal-removal control vectors is a maintainer decision, and the attribution question there is open too. The code review stands, and nothing more is needed from you on it meanwhile.