decomp-synth-lifter-v13-chain-qwen3.5-9b-lora

decomp-synth lifter v13-chain-full — Qwen3.5-9B LoRA (r32)

A LoRA adapter that tunes Qwen3.5-9B for single-shot byte-exact decompilation matching of PowerPC C++: given a target listing and a compiling-but-wrong source, emit source that compiles byte-identical. This is the project's headline single-turn 9B; for the multi-turn feedback-driven variant see v14-evalformat.

The project

This adapter comes out of a campaign teaching fleets of AI coding agents to reconstruct shipped game binaries byte-for-byte — matching decompilation, the console-preservation community's gold standard: rewrite C++ until the original vintage compiler, at the original flags, reproduces the retail machine code exactly. In that campaign, agent swarms byte-matched over 44,000 functions of a stripped retail Xbox 360 binary in about ten weeks — with every proposal judged by the real compiler and objdiff, never by a model.

decomp-synth is the search-and-ML side of that system: an engine that searches behavior-preserving C++ rewrites against the real build, and mines its own verified attempts into training data. The "chain" in this adapter's name is that flywheel: its corpus includes byte-exact endpoints mined from the search engine's own verified repair chains. The design rule the whole system is built on: models propose, deterministic oracles dispose — a fuzzy match score is a search gradient and an adversary, and byte-exact recompilation is the only terminal judge.

Background reading, in order:

• How agent swarms decompile games byte-for-byte — the campaign, and what byte-exact matching actually demands
• LLM-assisted decompilation: tools, not prompts — why the model is never allowed to judge its own work
• Forking the decompilation toolchain — the compiler, splitter, and diff stack underneath
• Infrastructure for running agent swarms — what running the fleet takes

Model facts

Evaluation

E3 instrument: 233 held-out functions (222 clean / 11 taint-flagged, reported separately), X360 MSVC substrate. k=20 draws, six repeat draws per condition (repeat-draw noise floor measured before any verdict):

• clean-set byte-exact solves at T=0.6: 17-18 across six draws (range 1); stock Qwen3.5-9B base: 0
• at T=1.0: 19-23 across six draws — the temperature lift is confirmed in a pre-registered rank test (Mann-Whitney U=36/36, p=0.0011), quotable only as a six-draw centre (~20.5 vs ~17.7), never a single draw
• best-of-k fuzzy (clean, k=20 T0.6): mean ≈46.5-47.6, median ≈33.6-34.5 across draws

An r=64 twin trained on the byte-identical corpus measured within the noise floor of this adapter at every operating point (rank is not the lever at 9B); it is released alongside as the r64 companion for anyone studying LoRA-capacity effects on a clean matched pair.

How to use it

from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

base = AutoModelForCausalLM.from_pretrained("Qwen/Qwen3.5-9B", dtype="bfloat16", device_map="auto")
tok = AutoTokenizer.from_pretrained("Qwen/Qwen3.5-9B")
model = PeftModel.from_pretrained(base, "freeqaz/decomp-synth-lifter-v13-chain-qwen3.5-9b-lora")

This is a search proposal engine, not a one-shot decompiler. It was trained — and evaluated — inside a compile-and-score loop:

1. Render the prompt: an objdiff-annotated listing of the target function's original bytes, followed by the current (compiling but mismatching) C++. RAW completion — no chat template.
2. Sample many candidates. The evaluation above uses k=20; T=1.0 measurably beats T=0.6 on solves for this adapter, so start hotter than you would for the 27Bs.
3. Compile every candidate with the target project's real toolchain.
4. Score each object against the retail object with objdiff. Byte-exact is the only acceptance criterion; the fuzzy % is a gradient for picking what to try next.

At 9B this runs comfortably on a single 24 GB GPU in bf16, which is the point of the size class: cheap wide sampling. For batch sampling, any OpenAI-compatible server that supports LoRA adapters (e.g. vLLM with --enable-lora) works well.

The adapter family

Integrity

PUBLISHED.json (shipped) carries per-file sha256 written by the training job at publish time. Two internal metadata files it pins (train_summary.json, artifact-manifest.json) are retained in the project's artifact store but not shipped here — they carry training-box paths. adapter_config.json was rewritten post-training to the HF base id; original bytes at provenance/adapter_config.orig.json.

Training data & license

Adapter weights: Apache-2.0. Training rows derive from public CC0-1.0-dedicated decompilation projects (X360 Rock Band 3 / Dance Central 3; zeldaret Wind Waker / Twilight Princess). See the v10 card for the full provenance discussion. Corpora are not published; PUBLISHED.json names the corpus file and sha256 as provenance.