freeqaz

decomp-synth-lifter-v17-full-qwen3.5-9b-r64-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. Start with the flagship write-up and the methodology post; the full project context lives on the r32 card, which is the primary release of this pair.

Why publish a twin

The family has run this experiment before: v13-chain r64 vs r32 was a measured null — doubled adapter capacity at fixed data bought nothing detectable at 9B — and a later internal rank ladder (v16) was flat as well. That history is exactly why the r32 arms are this generation's primaries. But v17's supply is qualitatively different from anything those rank experiments trained on (multi-turn trajectories to ~87k tokens, tool calls, recovery sequences), so the project re-ran the twin rather than assuming the null transfers.

No verdict exists yet: unlike the v13 pair, neither v17 arm has been evaluated, so this pair currently offers matched artifacts, not a measured contrast. Both repos' training-job-written PUBLISHED.json pin the same corpus sha256, so the corpus difference is provably zero for anyone who wants to run the comparison.

Honest status notes

Published as a research artifact with its evidence stated plainly:

No evaluation has been run on this adapter yet — nor on any v17 arm. Until numbers land, v14-evalformat remains the measured pick for the multi-turn feedback loop.
Training loss learned cleanly (1.03 → 0.48 over 190 optimizer steps, 2 epochs; min 0.42) — a supervision readout, not an evaluation claim, and the small gap to the r32's 0.52 endpoint is not evidence of capability.
"full" means all admissible trajectory rows, including tool-use turns from teacher sessions that did not end byte-exact; the byte-exact-only filter is the sibling v17-matched arm.
Single training seed (42) — any future r32-vs-r64 verdict is provisional under the project's multi-seed rule.
The adapter is ~2× the r32's size (660 MiB vs 330 MiB safetensors) for, on prior rank-ladder evidence, likely the same capability — prefer the r32 for actual decompilation work unless you are studying capacity.

Model facts

Table

base	`Qwen/Qwen3.5-9B` (apache-2.0)
method	LoRA r=64, α=128, dropout 0.05, all-linear, bf16
corpus	3,032 tool-trajectory rows (`v17full.jsonl`, sha `411cfaed…`) — byte-identical to the r32 arm
window	90,112 tokens max_seq (zero rows dropped)
schedule	2 epochs, 190 steps, eff. batch 32, linear LR, seed 42
trained	2026-08-31
format	Qwen3.5 chat template, thinking ON, native XML tool calls

Training data

The corpus is the project's 2026-08-30/31 teacher-mint union: multi-turn trajectories where a tool-armed teacher (GLM-5.3-flash) works decompilation targets from a private Halo: Combat Evolved Anniversary (Xbox 360) reconstruction effort through the project's compile-and-score harness — reading disassembly, proposing C++, compiling with the real toolchain, and reacting to objdiff feedback across turns (up to 8). Trajectories are converted at tool-turn granularity, holdout-gated at translation-unit grain against the project's eval sets, and student-rendered through Qwen3.5-9B's own tokenizer template.

The completions are therefore teacher-model-generated text plus tool-call structure; the surrounding context (assembly, diffs, compiler output) derives from that private reconstruction effort, which is not publicly linkable. No license claim is made for the corpus; it is not published. The shipped PUBLISHED.json pins the corpus file's sha256 (411cfaedcae6…, 3,032 rows) as provenance.

How to use it

python
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-v17-full-qwen3.5-9b-r64-lora")

This adapter is trained for agentic tool use: serve it behind an OpenAI-compatible endpoint with tool calling enabled and give it compile / diff / read tools. With vLLM:

markdown
vllm serve Qwen/Qwen3.5-9B --enable-lora \
  --lora-modules v17r64=freeqaz/decomp-synth-lifter-v17-full-qwen3.5-9b-r64-lora \
  --enable-auto-tool-choice --tool-call-parser qwen3_coder

The tool-call parser flag matters: the adapter emits tool calls in the Qwen3.5 template's native XML form, which qwen3_coder parses; without it (or with a JSON-style parser) the calls degrade silently into plain text.

Like every adapter in this family, it is a proposal engine for a compile-and-score loop — sample multiple candidates, compile each with the target project's real toolchain, and let objdiff judge. Byte-exact is the only acceptance criterion. Training rows ran up to ~87k tokens of session context, so give it a long context window. In bf16 the 9B base fits a single 24 GB GPU.

The adapter family

Table with columns: adapter, base, format, role
adapter	base	format	role
v10	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

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.

License

Adapter weights: Apache-2.0. A model trained to reproduce shipped game code can reproduce shipped game code — that is its purpose; decompilation projects operate in a long-standing community norm of clean-room reconstruction for interoperability and preservation.

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.5-9B

Adapter

this model

Input Modalities

TextImageVideo

Output Modalities

Text

Supported Functionality