freeqaz

decomp-synth-lifter-v10-qwen3.6-27b-lora

README

License: apache-2.0

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 adapters published under this account are the resulting proposer models. 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

Table

base	`Qwen/Qwen3.6-27B` (apache-2.0)
method	LoRA r=32, α=64, dropout 0.05, 12 target modules, bf16
window	20,480 tokens
corpus	4,992 repair/recover pairs, PowerPC X360 MSVC (`dec` representation)
trained	2026-08-06
format	RAW completion (not chat) — prompt is an annotated objdiff listing + current source

Evaluation

Drift roster r3: 380 real-drift functions from an X360 decompilation tree where the checked-in source compiles but does not match. k=20 samples, T=0.6, max_new 768. Grader: objdiff-cli 4.2.8 (≥4.1.0 asserted), functionRelocDiffs=none ruler. Numbers from the 2026-08-26 paired scoring session (grader-matched with the Qwen3.8 sibling below):

12 / 380 byte-exact solves (raw+reloc equal, fresh-recompile verified)
best-of-k fuzzy: mean 45.5, median 15.0, 44 rows ≥90, 21 rows ≥99
compile rate 68.4% of 7,600 draws
Δ best-of-k fuzzy vs the untouched-tree null: +6.74 (restored method)

An untrained Qwen2.5-Coder-7B control on the same instrument solves 0-2 and sits at or below the null. Numbers are not comparable across rosters or k; always state both.

Sibling

The same recipe run verbatim on Qwen3.8-27B is a statistical tie (paired Δ +0.37, p=0.52, 380 paired rows) with a different shape: broader coverage (compile 71.4%, p25 +3.7), fewer concentrated solves (9 vs 12). Released as a matched pair across base generations.

How to use it

python
from transformers import AutoModelForCausalLM, AutoTokenizer
from peft import PeftModel

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

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

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.
Sample many candidates (the evaluation above uses k=20 at T≈0.6).
Compile every candidate with the target project's real toolchain.
Score each object against the retail object with objdiff. A byte-exact result is a solve; the fuzzy % is a gradient for picking what to try next, never an acceptance criterion.

Single greedy completions waste the model; nearly all of its measured value is in the k-sample tail. For batch sampling, any OpenAI-compatible server that supports LoRA adapters (e.g. vLLM with --enable-lora) works well.

The adapter family

Table with columns: adapter, base, format, role
adapter	base	format	role
v10 (this repo)	Qwen3.6-27B	RAW	single-turn matcher, reference 27B
gtp0c	Qwen3.8-27B	RAW	v10 recipe verbatim on the newer base (matched pair)
v13-chain r32	Qwen3.5-9B	RAW	headline single-turn 9B

Integrity

PUBLISHED.json (shipped) carries the sha256 of every artifact file, 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 point base_model_name_or_path at the HF id; the original bytes are preserved at provenance/adapter_config.orig.json. To verify the weights, check them against the files map in PUBLISHED.json directly:

markdown
sha256sum adapter_model.safetensors  # a1904fae11de1ce4…

(identity_sha256 is the training job's digest over the original {path, size, sha256} records — the config record matches provenance/adapter_config.orig.json, not the rewritten file.)

Training data & license

Adapter weights: Apache-2.0. The training corpus consists of before→after C++ repair pairs derived from public, CC0-1.0-dedicated decompilation projects (Xbox 360 Rock Band 3 / Dance Central 3 community decompilations). CC0 covers the decomp contributors' authorship; it does not speak for the game publishers' rights in the underlying works. A model trained to reproduce shipped game code can reproduce shipped game code — that is its purpose. Use accordingly; decompilation projects operate in a long-standing community norm of clean-room reconstruction for interoperability and preservation.

The training corpora themselves are not published. PUBLISHED.json names the corpus file and its sha256 as a provenance pointer.

Available on FriendliAI

Dedicated Endpoints

Run this model inference on single tenant GPU with unmatched speed and reliability at scale.

Learn more

Model Details

Model Provider

freeqaz

Model Tree

Base

Qwen/Qwen3.6-27B

Adapter

this model

Input Modalities

TextImageVideo

Output Modalities

Text

Supported Functionality