P1: proven-abliterated chain on a real abliterated Maverick checkpoint (Step 0: stopped at spend cap) #60

Part of #36, #58. Follows the design in research/security/DESIGN-VAST-ABLITERATED.md (PR #59).

Goal: a re-derivable chain from base checkpoint to published abliterated checkpoint to FlashProve commitment ID, then one proved and verified reply from the abliterated weights on a vast H100. Scope: this would show which weights served a reply. It would NOT show that refusals are gone or that there's no backdoor (see #54).

Step 0 result (CPU only, $0 spent): STOPPED at the spend cap

The lane's cap was: go ahead if the estimated total is at most $10, otherwise stop and ask. The estimate is $12.6 to $18.7 for one rental, and about $25 to $37 for the two separate rentals the plan asks for. So no instance was created. Vast credit before and after Step 0: $33.59 both times, 0 instances.

Checkpoint choice

Searching Hugging Face for abliterated Llama 4 Maverick turns up exactly one real checkpoint family. Nothing from huihui-ai, mlabonne or failspy exists for Llama 4. Two other repos re-upload the same files, and one repo is empty.

• Repo: Nekotekina/Llama-4-Maverick-17B-128E-Instruct-Projected-Abliterated-GGUF, revision 43205c0c990b322db0fff6de8f6537b4544f2a67. Not gated, license llama4. It has 216 downloads and 7 likes, which is modest and not "widely used" in the huihui or mlabonne sense.
• Files: Llama-4-Maverick-17B-128E-PAB-Q4_K_XL-0000{1..5}-of-00005.gguf. Hugging Face LFS sha256 (from the HF API, not hashed locally):
  • 1 b94bba7b65d4c46747127049e416dda266c35d3629c8e0d7a8c4615a8067a95f (49,878,929,568 B)
  • 2 e403ac8f60d0341b3bddeea1b49479bcf242afa74555393fbec2b70329b584f5 (49,830,263,808 B)
  • 3 a03ed5a15dcaaf451f2405a009d26ef8e8115637d3102cabfbafb0f0df986883 (49,832,905,856 B)
  • 4 5a0138a132fed94a8870be0b8cb9e9bd911f447eff8878fdfd5aa768361de2ff (49,508,645,760 B)
  • 5 6a76332efde6a41655c8ec85fcdcc878d6e372ad98ea23b3b03e426ba5e5937c (33,155,199,296 B)
  • The repo also has a Q8_0 set (9 shards, about 426 GB). It isn't needed.
• Claimed base: the card says meta-llama/Llama-4-Maverick-17B-128E. Inside the GGUF, general.name reads Llama-4-Scout-17B-128E-Instruct-Projected-Abliterated. Both of those are wrong in different ways, but the architecture matches Maverick exactly: llama4, 48 blocks, 5120 embedding, 128 experts, interleave step 2, vocab 202048. The imatrix metadata names unsloth's Maverick-Instruct calibration file.
• Method: "projected abliteration", per the grimjim HF blog post. No direction vectors, layer choice, harmful/harmless prompt sets or scripts are published. So the re-derivation leg (base plus direction, then re-hash) cannot be done from public material.
• Comparison with the upstream-supported base files (unsloth/...-GGUF rev 41032e54, UD-Q4_K_XL, the files examples/maverick/run.sh pins). We fetched only headers and range samples, about 100 MB in total:
  • Both have the same 531 tensor names and shapes.
  • Exactly 12 type changes: blk.0..11.attn_output.weight went from Q4_K/Q5_K to Q6_K.
  • Shards 2 to 5 have byte-identical lengths. 64 KiB samples at 8 offsets per shard: shard 2 is 8/8 identical, shards 3 to 5 are 15/24 identical and 9/24 different.
  • This is consistent with a modification of some tensors followed by requantization, but that is unconfirmed.
• Provability: every committed tensor type (F32, Q4_K, Q5_K, Q6_K) is one that weight_sums and cp_commit read. The new Q6_K tensors have 5120 rows, under the row-pass limit of 33,025. The architecture is the one upstream proves end to end. The fit (calibrate, then converter) has to be redone for these weights and could need extra worst-case rounds. That is the main schedule risk.
• Calibration set: the two pinned tokenizers are gated by Meta. Ungated mirrors with byte-identical sha256 exist: TheBloke/Llama-2-7B-Chat-fp16 tokenizer.json is bcd04f0e... and unsloth/Llama-4-Maverick-17B-128E-Instruct tokenizer.json is 172c9eb4..., both matching what scales/make_calibration_set.py pins. WikiText is ungated. So the set can be made on CPU before renting.

Cost estimate (from our rentals: rental 1 build 18.6 min; upstream figures commit 43 min, fit about 8 min, prove 4 min; rental 2 off-baseline host commit took 2x)

• Hardware: the commit needs 330 GB of free host RAM. No single-H100 vast offer has 320 GB or more right now. The cheapest fit is a 2x H100 SXM box with 516 GB RAM at $4.856/h, unverified, JP, $0 download. Two commits can't run side by side on one box (peak 310 GB each).
• Hours for one rental doing two sequential commits in two clean work dirs: setup+build 0.4-0.6, download 232 GB 0.25-0.75, sums+fit 0.15, commit x2 1.45-2.0, prove+verify+manifest 0.15, pull+teardown margin 0.2. That's 2.6-3.85 h, or $12.6-18.7, before any fit retry.
• Two separate rentals as specified: about $25-37.
• An option below the cap that we did not take: one H200 NVL with 516 GB at $1.96/h (unverified host, 16 cores). About $5-8, but it is off the supported GPU (upstream supports H100 only; our H200 run was synthetic, not NVL), and the plan says H100.

Proposed next step (needs Shadow GO)

One 2x H100 rental, cap $20. Two commits in separate clean work dirs on the same box, recorded as such. One proved reply, cp_verify, a signed manifest with the provenance above. The re-derivation leg is marked infeasible (no published direction). Or approve the H200 NVL route at a $10 cap as an off-spec experiment.