Gyakorlati útmutató: SFT, jutalommodell és PPO lépések egy 1,5 milliárdos paraméteres Qwen-modellhez

Ez a cikk egy gyakorlati lépésről lépésre útmutató a klasszikus ChatGPT‑szerű post‑training folyamat három fő lépéséhez: SFT (supervised fine‑tuning), jutalommodell‑képzés és PPO (proximal policy optimization). A bemutatott munkafolyamat a Qwen2.5‑1.5B modellt használja kiinduló modellként: ennek mérete elég kicsi ahhoz, hogy egyetlen több‑GPU-s gépen lehessen vele dolgozni, de elég nagy ahhoz, hogy a post‑training viselkedésbeli változásai jól láthatóak legyenek.

A példában használt nyílt forráskódú eszközök és könyvtárak:

• torchtune — Meta PyTorch‑natív finomhangoló könyvtára SFT‑hez,
• TRL (RewardTrainer) — jutalommodell kiképzéséhez,
• verl — ByteDance által karbantartott, Ray‑re épülő, gyártásra szánt RL post‑training keretrendszer (PPO koordinációhoz).

Hardverigény: legalább 2 GPU (4 vagy 8 jobb), nagyjából 80 GB összes GPU‑memória ajánlott.

1. lépés: SFT (demonstrációkon)

A SFT során a előképzett modellt {prompt, response} párokon finomhangoljuk ugyanazzal a next‑token predikciós veszteséggel, mint a pretrainingnél, de a veszteséget csak az asszisztens (válasz) tokenjein számoljuk.

Adatformátum: többfordulós, beszélgetés‑szerű JSONL sorok. Egy példa egy bejegyzésre:

{ "messages": [ {"role": "user", "content": "Why do people like golden retrievers?"}, {"role": "assistant", "content": "Golden retrievers are one of the most popular dog breeds..."} ] }

A SFT célja, hogy a modell tényleges választ adjon a felhasználói beadványokra, ne csak a szövegfolytonosságot kövesse.

Konfigurációs példák (torchtune YAML): fontosabb beállítások és magyarázatuk

• train_on_input: false — csak a válasz tokenjein számolunk veszteséget, hogy a modell a generálásra koncentráljon, ne a promptokat másolja.
• learning rate: 2e‑5 — javasolt kiindulópont SFT‑hez; elég nagy ahhoz, hogy néhány epoch alatt viselkedésváltozást okozzon, de nem annyira, hogy tönkretegye az előképzett súlyokat.
• LoRA helyett teljes finomhangolás helyett: LoRA a gyakorlati alapértelmezett — kevesebb GPU‑memória és gyorsabb edzés; 1.5B modellnél a minőségi különbség elhanyagolható.
• epochs: 3 (a bemutatóban kicsi adatbázisra számolva). InstructGPT például ~13K példán és 16 epokon futott.
• batch_size: 4 és gradient_accumulation_steps: 4 => effektív batch_size 16.
• dtype: bf16 — pontosság és memóriahatékonyság miatt.

Indítási példaparancs: tune run lora_finetune_distributed --config sft_config.yaml

Értékelés: SFT után érdemes beszélgetéssel és összehasonlító tesztekkel ellenőrizni a model viselkedését (például ugyanazt a kérdést feltenni a bázis és az SFT modellnek). Reális használatnál automatikus értékelést (evals) is be kell állítani a finomhangoláshoz és a hyperparaméter‑hangoláshoz.

2. lépés: Jutalommodell kiképzése

A jutalommodellhez először preferencia‑párokat gyűjtünk: minden tételhez van egy prompt, egy "chosen" (jobbnak jelölt) válasz és egy "rejected" válasz. Példa:

{ "prompt": "What's the capital of that country that celebrates with a lot of colored powders?", "chosen": "You're probably thinking of Holi... The capital of India is New Delhi.", "rejected": "The capital of that country that celebrates with a lot of colored flowers is Amsterdam..." }

Fontos megjegyzések a jutalommodell‑képzésről (TRL RewardTrainer használatával):

• Kiindulási pont: használjuk az SFT checkpointot, nem a bázismodellt. A jutalommodellnek is értenie kell az SFT által létrehozott válaszdisztribúciót.
• Epochok: 1 epoch jellemzően elég, a jutalommodellek gyorsan túlilleszkednek.
• Learning rate: 1e‑5 (alacsonyabb, mint SFT), óvatos, kisebb súlyfrissítések.
• Tokenizer pad token beállítása: tokenizer.pad_token = tokenizer.eos_token.

Tréning példa: RewardConfig paraméterek között per_device_train_batch_size: 8, num_train_epochs: 1, learning_rate: 1e‑5, bf16 True, max_length: 2048.

Ellenőrzés: a modell kiképzése után manuálisan pontozzunk néhány prompt–válasz párt, hogy a nyilvánvalóan jobb válasz magasabb pontot kapjon; ha ez nem teljesül, probléma van az adattal vagy a tréninggel.

3. lépés: PPO végrehajtása verl‑lel

A PPO során az SFT modellel (policy) optimalizáljuk a válaszokat úgy, hogy a jutalommodell magasabb score‑ot adjon nekik. A verl feladata a rolloutok koordinálása, a négy, memóriában egyszerre szükséges modell (policy, reference, reward, critic) kezelése és az update‑loop orchestration.

Előkészítés: prompts parquet formátumban — minden sor tartalmaz egy tokenizált, chat‑template‑tel formázott prompt mezőt. A promptok címkézetlenek; a jutalommodell adja a jelet.

Reward function: készítsünk olyan wrapper osztályt, amely batch‑ként kap promptokat és válaszokat, egyesíti őket, tokenizálja, majd a jutalommodell logitjaiból skalár jutalmakat ad vissza.

PPO konfigurációs fontosabb pontok (példa YAML):

• actor.optim.lr: 1e‑6 — nagyon alacsony tanulási ráta, RL frissítések zajosabbak, lassan akarunk mozogni.
• kl_penalty_coeff: 0.1 — a KL büntetés mérsékli az SFT‑től való eltérést; ha reward hackinget látunk, növeljük; ha a modell nem változik, csökkentsük.
• clip_ratio: 0.2 — PPO eredeti cikkében javasolt érték.
• ppo_epochs: 4, ppo_mini_batch_size és ppo_micro_batch_size a GPU memória függvénye.
• rollout temperature: 0.7, top_p: 0.9, n:1.

Indítás: python -m verl.trainer.main_ppo --config ppo_config.yaml --n_gpus 4

Mit érdemes figyelni a tréning közben:

• A jutalom értékének általában emelkednie kell, ha a modell javul.
• A KL‑divergencia növekedhet, de ha explodál, növeljük a KL büntetést.
• Rendszeresen generáljunk mintaválaszokat az aktuális checkpointból és emberi szemmel is értékeljük őket — a metrikák önmagukban nem mindig megbízhatóak.

Konkrét futásra javasolt metrikák a configban: total_training_steps: 500, save_freq: 100, test_freq: 50.

Összekapcsolás és gyakorlatias tanulságok

A pipeline sorrendje: SFT → jutalommodell → PPO. Mindhárom fázis egymásra épül: az SFT adja az alapot a jutalommodellhez és a policy‑hez, a jutalommodell adja a jelzést PPO‑hez, majd a PPO adja a végső modellt.

Strukturálisan ez megegyezik az InstructGPT/ChatGPT első generációinak folyamatával, csak sokkal kisebb skálán: a bemutatott példa 1.5 milliárd paraméteres modellt használ, míg az eredeti munkák 175 milliárd paraméteres modelleket, sokkal több emberi annotátort és jóval több számítási erőforrást alkalmaztak.

Gyakorlati figyelmeztetések:

• A legtöbb munka adatkészítési és annotálási feladat: jó SFT demonstrációk, megbízható preferencia‑címkék és diverz RL promptok kialakítása sok időt és gondoskodást igényel.
• Az infrastruktúra ma már elég jól megoldott: dokumentációk és LLM‑asszisztencia segítségével gyorsan scaffoldolható egy működő pipeline. De a jó adatok és a helyes jutalommodell nélkül az eszközök nem fognak csodát tenni.

Összefoglalva, egy 1.5B paraméteres Qwen modell post‑trainingje három jól elkülöníthető fázisból áll: SFT (3 epoch, LR 2e‑5, LoRA), jutalommodell (1 epoch, LR 1e‑5, indítás SFT checkpointból) és PPO (nagyon alacsony LR ~1e‑6, kl_penalty_coeff ~0.1). Ezeket a lépéseket követve a modell a bázisváltozathoz képest érdemben jobb, irányítottabb válaszokat ad majd a tipikus felhasználói kérésekre.