pushkarsharma/arabic-translation-challenge-adapters

Arabic-Centric Machine Translation — Fine-Tuned Checkpoints

42 fine-tuned checkpoints for Arabic-centric machine translation: seven base models × six directions (ar↔en, ar↔hi, ar↔ur). Thirty-six are LoRA adapters; six are full fine-tunes of NLLB-200-3.3B.

Code: https://github.com/p-sharma-7/Arabic-Translation-Challenge

Contents

Family	Base model	Kind	Directions
acegpt/	FreedomIntelligence/AceGPT-v2-8B-Chat	LoRA	6
fanar/	QCRI/Fanar-1-9B-Instruct	LoRA	6
gemmax2/	ModelSpace/GemmaX2-28-9B-v0.1	LoRA	6
hala9b/	hammh0a/Hala-9B	LoRA	6
madlad/	google/madlad400-10b-mt	LoRA	6
translategemma/	google/translategemma-4b-it	LoRA	6
nllb/	facebook/nllb-200-3.3B	full fine-tune	6

Directions: ar-en, en-ar, ar-hi, hi-ar, ar-ur, ur-ar.

Every weight file has been verified complete — each safetensors header's declared tensor extent matches the file, and uploads were checksum-verified against the training machine.

Checkpoint provenance

gemmax2/, madlad/, and nllb/ were published from their final training checkpoint rather than an end-of-run save. The step each one came from:

Family	ar-en	ar-hi	ar-ur	en-ar	hi-ar	ur-ar
gemmax2/	657	629	635	657	629	635
madlad/	3285	2516	635	1971	1887	2540
nllb/	2628	3145	2540	3285	1887	3175

For NLLB, eval_loss decreased monotonically to the published step in five of six directions. In ur-ar, step 2540 scored 1.2722031 against the published 3175's 1.2722178 — a difference of 1.5e-05, within noise. trainer_state.json is included in each directory so the full trajectory is inspectable.

Optimizer, scheduler, and RNG state are not included: they are needed only to resume training, not for inference, and would have added roughly 60 GB.

LoRA configuration

For the six adapter families: r=16, alpha=32, dropout=0.05. Target modules follow each base architecture:

• Decoder-only (acegpt, fanar, gemmax2, hala9b): q_proj, k_proj, v_proj, o_proj, gate_proj, up_proj, down_proj
• T5-style (madlad): q, k, v, o, wi_0, wi_1, wo
• translategemma: the decoder-only set plus fc1, fc2, out_proj

nllb/ is a full fine-tune and has no LoRA configuration.

Usage

LoRA adapters — load the base model, then apply the adapter:

from huggingface_hub import snapshot_download
from peft import PeftModel
from transformers import AutoModelForCausalLM, AutoTokenizer

path = snapshot_download(
    "pushkarsharma/arabic-translation-challenge-adapters",
    allow_patterns="fanar/ar-en/*",
)
base = AutoModelForCausalLM.from_pretrained("QCRI/Fanar-1-9B-Instruct", device_map="auto")
model = PeftModel.from_pretrained(base, f"{path}/fanar/ar-en")
tok = AutoTokenizer.from_pretrained(f"{path}/fanar/ar-en")

madlad/ is seq2seq — use AutoModelForSeq2SeqLM with PeftModel.

NLLB is a complete model; load it directly, no base model or PEFT needed:

from huggingface_hub import snapshot_download
from transformers import AutoModelForSeq2SeqLM, AutoTokenizer

path = snapshot_download(
    "pushkarsharma/arabic-translation-challenge-adapters",
    allow_patterns="nllb/ar-en/*",
)
model = AutoModelForSeq2SeqLM.from_pretrained(f"{path}/nllb/ar-en")
tok = AutoTokenizer.from_pretrained(f"{path}/nllb/ar-en")

Each NLLB direction is ~6.3 GiB, so fetch only the ones you need — a full snapshot_download of this repository is ~43 GiB.

To reconstruct the layout the pipeline code expects:

hf download pushkarsharma/arabic-translation-challenge-adapters \
  --local-dir finetuned_checkpoints

Several base models are gated — request access on the Hub and authenticate (hf auth login, or set HF_TOKEN) before loading.