Qwen2.5-1.5B Math LoRA Collection

Provenance

• Base model: Qwen2.5-1.5B-Instruct
• Datasets: sampled from ../../prepare/data/math/*.json. Each JSON is a list of {prompt, response, system?} records. dataset_sampler.py draws 10 disjoint groups of 100 samples (unless the dataset has <1 000 examples, in which case sampling with replacement keeps the group size fixed) using a deterministic seed derived from the dataset name.
• Training recipe (from config/default.yaml):
  • sequence length 4 096; LoRA r=64, alpha=128, dropout=0.05, target modules = {q,k,v,o,gate,up,down}_proj
  • 12 epochs / max 1 800 steps, learning rate 1e-4, batch size per device 2, gradient accumulation 16, BF16 training, gradient checkpointing on, weight decay 0.01, warmup ratio 0.03, checkpoints saved every 300 steps (keeping at most 6) plus a final adapter export
  • Tokenizers are cloned from the base model (pad token defaults to EOS if missing)
• Monitoring & reproducibility:
  • Trainer logs (loss, LR, throughput) are in ../logs/<dataset>/group_xx/.
  • Slurm stdout/err for each shard live in ../logs/slurm/.
  • metadata.json captures the git commit (if GIT_COMMIT was set), timestamps, seeds, and the effective batch size so any experiment can be repeated exactly.

End-to-end data flow

1. Raw JSON data comes from ../../prepare/data/math. Each file is a list of dict objects with keys:
   json

   1{ 2 "prompt": "...question...", 3 "response": "...reference answer...", 4 "system": "optional system message" 5}
2. python -m train_lora.dataset_sampler --config config/default.yaml reads every dataset, filters out GSM8K_test.json, and deterministically samples 10×100 items per dataset. The samples plus metadata (indices, seeds, timestamps) are written to ../prompt_groups/<dataset>/group_xx.json.
3. python -m train_lora.run_tasks --run (or the Slurm array) iterates dataset/group pairs, loads the corresponding prompt group, and performs LoRA fine-tuning with Hugging Face Trainer.
4. After training finishes, the following artifacts land in outputs/<dataset>/group_xx/:
   • a ready-to-use LoRA adapter (adapter/)
   • intermediate checkpoints for analysis/resume
   • tokenizers and metadata
5. The evaluation stacks (../评估体系, ../parameter_generator/评估) and the LoRA parameter generator both consume these directories directly.

Directory layout

outputs/
├── Competition_Math/
├── GSM8K_train/
├── MATH/
├── Math-IIO-68K-Mini/
├── Math-Plus/
├── Math_QA/
├── Mu-Math/
└── ToT-Math-V1/

Tip: Use metadata.json to find the latest checkpoint, to confirm which base model/tokenizer were used, or to drive automated uploads/evaluations.

Dataset overview

How to navigate a single group

Math_QA/
└── group_00/
    ├── adapter/
    │   ├── adapter_config.json
    │   ├── adapter_model.safetensors
    │   ├── tokenizer/… (extra copies of merges, vocab, chat_template.jinja)
    │   └── training_args.bin
    ├── checkpoints/
    │   ├── checkpoint-300/
    │   ├── checkpoint-600/
    │   └── …
    ├── tokenizer/         # same as base tokenizer but pinned to this run
    ├── prompt_group.json  # 100-shot data
    └── metadata.json

Using the adapters

0. Environment prerequisites

• Python ≥ 3.10, transformers >= 4.37, peft >= 0.8, accelerate, safetensors, torch (GPU build).
• The base model directory must be accessible; otherwise download Qwen2.5-1.5B-Instruct from Hugging Face and update base_model path.
• Optional: set HF_HOME, TRANSFORMERS_CACHE to avoid repeated downloads.

0.5. Reproduce the training pipeline (optional)

1. Load adapter with PEFT

• Loading the tokenizer from adapter/ ensures identical chat template and additional tokens (if any). You can also point to the base tokenizer path if you prefer.
• For batch inference, wrap the model with model.merge_and_unload() if you need a single combined set of weights (at the cost of losing LoRA toggling).
• If you want maximal throughput on a single GPU, also call model.half() or model.to(torch.bfloat16) depending on your hardware; the adapters were trained with BF16 so keeping BF16 is the safest choice.

2. Resume or continue training

3. Evaluate with Math-Verify

4. Packaging for distribution

• Upload only adapter/ and metadata.json when sharing publicly (e.g., Hugging Face) to avoid huge checkpoint directories.
• Keep prompt_group.json if you want consumers to understand the training data or to regenerate LoRA weights with the same samples.
• When exporting, include a README snippet that references this document so downstream users know the provenance.
• Suggested Hugging Face layout:

  Math_QA/
    group_00/
      adapter/
      prompt_group.json
      metadata.json
  README.md (copy sections describing provenance + usage)

File reference (metadata.json)

Best practices

• Always match BF16 or FP16 settings between base model loading and adapter training; these adapters were trained in BF16.
• If you edit files inside this directory, keep structure intact—other scripts rely on relative paths (adapter, tokenizer, metadata.json).
• Before deploying a new LoRA, verify it with the evaluation suite and consider merging multiple groups (e.g., ensemble or checkpoint averaging) only after confirming stability.
• Use prompt_group.json and metadata.json as documentation when presenting results; they already include seeds, sample indices, and environment details.
• If you build new LoRAs with different configs (e.g., higher rank, more steps), add a sibling directory (e.g., outputs_v2/) or annotate the README so collaborators know which adapters correspond to which experiment.