Model Card for mypo-qwen2.5-coder-1.5b-sft
SFT LoRA adapter for
Qwen/Qwen2.5-Coder-1.5B-Instruct, trained on the
chosen (type-hinted) responses of
joshuasundance/mypo-4k-rfc. The goal is to teach the base model to emit modern, fully-annotated Python code.
This is a PEFT/LoRA adapter, not a merged model. Load the base model first, then attach the adapter.
TL;DR — does it work?
Two complementary measurements are reported — both published, both reproducible.
Batched eval (n=150 stratified held-out validation prompts, run 2026-04-22-qwen2.5-1.5b):
| metric | base | this adapter (sft) | gold (chosen) |
|---|
| parse rate | 97.3 % | 100 % | 100 % |
ruff pass rate | 93.3 % | 96.0 % | 100 % |
black pass rate | 12.0 % | 97.3 % | 98.0 % |
mypy --strict pass rate | 6.0 % | 92.7 % | 100 % |
| mean annotation slot coverage | 0.000 | 0.953 | 0.955 |
| fully-annotated function fraction | 0.000 | 0.893 | 0.898 |
mean ruff violations / sample | 0.47 | 0.07 | 0.00 |
mean mypy errors / sample | 2.30 | 0.13 | 0.00 |
| preference win rate vs base | — | 100 % | — |
preference win rate vs rejected | — | 100 % | — |
preference win rate vs chosen | — | 49.0 % (tie) | — |
Single-prompt validation (n=30, batch=1, no padding — realistic one-user inference):
| metric | base | this adapter (sft) |
|---|
| parse rate | 93.3 % | 100 % |
ruff pass rate | 90.0 % | 93.3 % |
black pass rate | 6.7 % | 100 % |
mypy --strict pass rate | 0.0 % | 73.3 % |
| mean annotation slot coverage | 0.000 | 0.971 |
The core claim — base never annotates, SFT almost always does — survives under single-prompt decoding. The batched and single-prompt validations are retained as two different in-domain measurement regimes, but we no longer attribute their gap specifically to left-padding or batching as a general causal explanation. Full characterization is in
joshuasundance/mypo-training; single-prompt artifacts are in
single-prompt-validation/single-prompt-2026-04-23T002137Z/.
External benchmark note: on the latest canonical full HumanEval+ run (n=164),
this adapter reaches 97 / 164 = 59.1 % pass@1 on base tests and
86 / 164 = 52.4 % on plus tests, which is below the untuned Qwen base
(112 / 164, 99 / 164). So SFT improves the narrow type-hinting objective,
but not broad HumanEval+ correctness.
Quick start
1import torch
2from peft import PeftModel
3from transformers import AutoModelForCausalLM, AutoTokenizer
4
5base_id = "Qwen/Qwen2.5-Coder-1.5B-Instruct"
6adapter_id = "joshuasundance/mypo-qwen2.5-coder-1.5b-sft"
7
8tokenizer = AutoTokenizer.from_pretrained(base_id)
9base = AutoModelForCausalLM.from_pretrained(base_id, torch_dtype=torch.bfloat16, device_map="auto")
10model = PeftModel.from_pretrained(base, adapter_id)
11
12messages = [{"role": "user", "content": "Write a typed Python function that returns the nth Fibonacci number."}]
13inputs = tokenizer.apply_chat_template(messages, add_generation_prompt=True, return_tensors="pt").to(model.device)
14out = model.generate(inputs, max_new_tokens=256, do_sample=False)
15print(tokenizer.decode(out[0, inputs.shape[-1]:], skip_special_tokens=True))
Training
Trained with
TRL SFTTrainer on a single NVIDIA A10G via Hugging Face Jobs. Training script:
mypo_sft_train.py. Job id:
69e8a4522aa1660eaffa894d.
Data
- Dataset:
joshuasundance/mypo-4k-rfc (train + validation concatenated → 6361 examples).
- Format: DPO
(prompt, chosen, rejected) collapsed to SFT conversational, keeping only chosen.
Hyperparameters
| Group | Setting |
|---|
| Quantization | 4-bit NF4 + double-quant, bnb_4bit_compute_dtype=bfloat16 |
| LoRA | r=256, alpha=16, dropout=0.05, target_modules="all-linear", task_type=CAUSAL_LM |
| Optimization | paged_adamw_8bit, lr=2e-4, cosine schedule, warmup_steps=100 |
| Batching | per_device_train_batch_size=1, gradient_accumulation_steps=8 (effective 8) |
| Schedule | 3 epochs, max_length=2048, packing=off |
| Precision | bf16, gradient checkpointing on |
| Seed | 42 |
Final training metrics (from job logs)
| Metric | Value |
|---|
train_runtime | 8339.5 s (~2h 19m) |
train_loss | 0.3679 |
mean_token_accuracy (final step) | 0.9038 |
grad_norm (final step) | ~0.66 |
Environmental impact
CodeCarbon telemetry from the training run (emissions.csv in this repo):
| Metric | Value |
|---|
| Duration | 8339.5 s |
| Energy consumed | 0.4721 kWh |
| CO₂e emissions | 0.1743 kg |
| GPU energy / power | 0.3079 kWh / 132.9 W avg |
| CPU energy / power | 0.0434 kWh / 19.4 W avg |
| RAM energy / power | 0.1209 kWh / 54.0 W |
| Hardware | 1 × NVIDIA A10G, AMD EPYC 7R32 (48 vCPU), 187 GB RAM |
| Region | AWS us-east-1 (Virginia), PUE 1.0 |
| Tracker | codecarbon 3.2.6, tracking_mode=machine |
Framework versions
- TRL 1.2.0, Transformers 5.5.4, PyTorch 2.11.0, Datasets 4.8.4, Tokenizers 0.22.2, PEFT ≥ 0.12, bitsandbytes ≥ 0.44.
License
Apache 2.0 (inherits from the
Qwen2.5-Coder-1.5B-Instruct base model).
Citations
CodeCarbon (emissions tracking)
Emissions for this run were measured with
CodeCarbon v3.2.6.
1@software{codecarbon,
2 author = {Benoit Courty and Victor Schmidt and Sasha Luccioni and Goyal-Kamal and MarionCoutarel and Boris Feld and Jérémy Lecourt and LiamConnell and Amine Saboni and Inimaz and supatomic and Mathilde Léval and Luis Blanche and Alexis Cruveiller and Ouminasara and Franklin Zhao and Aditya Joshi and Alexis Bogroff and Hugues de Lavoreille and Niko Laskaris and Edoardo Abati and Douglas Blank and Ziyao Wang and Armin Catovic and Marc Alencon and Michał Stęchły and Christian Bauer and Lucas Otávio N. de Araújo and JPW and MinervaBooks},
3 title = {{CodeCarbon: Estimate and track carbon emissions from machine learning computing}},
4 year = 2024,
5 doi = {10.5281/zenodo.11171501},
6 url = {https://github.com/mlco2/codecarbon}
7}
TRL
1@software{vonwerra2020trl,
2 title = {{TRL: Transformer Reinforcement Learning}},
3 author = {von Werra, Leandro and Belkada, Younes and Tunstall, Lewis and Beeching, Edward and Thrush, Tristan and Lambert, Nathan and Huang, Shengyi and Rasul, Kashif and Gallouédec, Quentin},
4 license = {Apache-2.0},
5 url = {https://github.com/huggingface/trl},
6 year = 2020
7}
