--- title: "Czego nauczyłem się, szkoląc swój własny model" author: "Jakub Ćwirlej" id: training-lessons language: pl url: "https://jakubcwirlej.com/pl/articles/training-lessons.md" page: "https://jakubcwirlej.com/pl/ai-dev/" translations: en: "https://jakubcwirlej.com/articles/training-lessons.md" fr: "https://jakubcwirlej.com/fr/articles/training-lessons.md" nl: "https://jakubcwirlej.com/nl/articles/training-lessons.md" updated: 2026-10-14 words: 2195 summary: "Dziesięć praktycznych lekcji z doświadczeń autora w samodzielnym trenowaniu modeli językowych. Dotyczą zbyt optymistycznych wyliczeń mocy obliczeniowej, zaczynania od małej skali, stałego monitorowania, izolowanych zmian i testów ablacyjnych, wyboru danych, realistycznych oczekiwań, cierpliwości podczas plateau i potrzeby więcej niż jednej karty GPU. Na koniec autor przekonuje, że małe, wyspecjalizowane modele budowane przez pojedyncze osoby wciąż mają sens." summary_type: editorial --- # Czego nauczyłem się, szkoląc swój własny model Jakub Ćwirlej · język tekstu: PL · 2195 słów ## Streszczenie (redakcyjne) Dziesięć praktycznych lekcji z doświadczeń autora w samodzielnym trenowaniu modeli językowych. Dotyczą zbyt optymistycznych wyliczeń mocy obliczeniowej, zaczynania od małej skali, stałego monitorowania, izolowanych zmian i testów ablacyjnych, wyboru danych, realistycznych oczekiwań, cierpliwości podczas plateau i potrzeby więcej niż jednej karty GPU. Na koniec autor przekonuje, że małe, wyspecjalizowane modele budowane przez pojedyncze osoby wciąż mają sens. ## Najważniejsze punkty (redakcyjne) - Rzeczywiste wykorzystanie sprzętu (MFU) jest dużo niższe, niż sugerują specyfikacje; jego pierwszy model, liczący 1.5B parametrów, okazał się niedotrenowany. - Śledzenie norm i porównywanie codziennych odpowiedzi ujawnia problemy, których nie pokazuje loss; przeszedł z AdamW na MuonH. - Należy zmieniać jedną rzecz naraz; swój zbiór danych budował od zera aż trzy razy. - Umiejętności często rosną skokowo po długim plateau, a monitorowanie top10 może pokazać postęp, którego nie widać w top1. - Małe, wąskie modele działające lokalnie lub na CPU mogą być bardziej opłacalne niż największe modele, a trenowanie własnego to najlepszy sposób, by zrozumieć, jak działa AI. ## Pełny tekst (słowa autora) ### 1. Wszelkie kalkulacje robione na sucho zawsze będą zbyt optymistyczne Kiedy myślimy o szkoleniu modelu, naturalnie na myśl przychodzi nam proces uczenia maszynowego – praca, którą wykonują za nas potężne klastry Nvidii w centrach danych, lub jeśli mamy więcej szczęścia, nasza własna piekielnie mocna stacja robocza. Czytając specyfikację, łatwo zapomnieć o tym, że realne MFU (Model FLOPs Utilization) jest dużo niższe, niż sugerowałyby materiały marketingowe producenta kart. W zależności od architektury i szczegółowości, sprzęt pozwoli ci wycisnąć z krzemu zaledwie ułamek mocy obliczeniowej. Cóż z tego, że karta liczy w FP4, jeśli w treningu modelu bazowego od zera nie będzie to działać stabilnie, albo przy szerokości twojego modelu zejście poniżej BF16 nie daje żadnych korzyści. Moment, w którym zdajesz sobie sprawę, że nie jesteś w stanie wytrenować modelu, który planowałeś, w zakładanym czasie, ani nawet w przybliżonych rozmiarach, nie należy do łatwych. Zwłaszcza, jeśli poświęciłeś tygodnie na to, żeby dojść do miejsca, w którym możesz zacząć trening i nagle okazuje się, że cały plan był nierealny. Przecież na papierze wszystko się zgadzało! Pierwszy odruch to szukanie metod optymalizacji – torch compile, autocast, flash attention, FLCE, głowice i minibatch dopasowane wielkością do preferencji CUDA. To wszystko działa, ale fizyki krzemu nie oszukasz. Jeżeli trenujesz mały model, jego mała szerokość będzie działać przeciw tobie. Jeżeli nie stać cię na trening dużego modelu, nie stać cię też na wyciągnięcie maksimum ze swojego GPU. Dojście do momentu optymalnego wykorzystania karty może zająć dni, a finalny spadek TPS (Tokens Per Second) w treningu o 30-40% względem początkowych kalkulacji to różnica dni, czy wręcz tygodni pracy karty. ### 2. Startuj zawsze od jak najmniejszej skali, która jest w stanie zwalidować twoje pomysły Mój pierwszy model miał 1.5B parametrów i byłem w stanie go wytrenować zaledwie do trzech Chinchilla. Przy jego budowie popełniłem wiele błędów, ale mimo wszystko działał. O jego znikomej użyteczności zadecydowało przede wszystkim niedotrenowanie. Gdybym z tym samym budżetem zdecydował się szkolić model 10-krotnie mniejszy, mógłbym pochwalić się modelem dobrze wytrenowanym i użytecznym. Miałbym czas na testy i uniknąłbym z pewnością wielu błędów, co pozwoliłoby mi zbudować lepszą architekturę. Oczywiście rozmiar ma znaczenie, ale jeszcze większe znaczenie mają dane, architektura i wydajność obliczeniowa. Szanse, żeby zaprojektować dobry model na podstawie literatury, bez testów i bez pomyłek, są bliskie trafieniu w totolotka. ### 3. Model nie trenuje się sam Trenowanie modelu brzmi fajnie, ale jest dużo bardziej nudne, niż może się wydawać. W rzeczywistości to w większości proces polegający na ciągłym projektowaniu badań, przeprowadzaniu pomiarów, analizie wyników modelu i szukaniu rozwiązań problemów, które pojawiają się w trakcie. Cały czas, na okrągło, dzień po dniu. Jeśli nie potrafisz czerpać satysfakcji z małych odkryć i drobnych sukcesów może się okazać zbyt nudne. Tymczasem to właśnie żelazna konsekwencja w przeprowadzaniu pomiarów decyduje o wszystkim. Nawet przy prawidłowo dobranych parametrach treningu z czasem może okazać się, że nasz model potrzebuje nowych danych lub degraduje w sposób trudny do wychwycenia na pierwszy rzut oka. Tego nie zauważysz bez dobrego monitoringu i ciągłych testów, a im rzadziej je robisz, tym więcej czasu stracisz, jeśli model zacznie zachowywać się w sposób niepożądany. Weźmy pod uwagę jeden z częstych scenariuszy. Po kilku dniach treningu orientujesz się, że model zaczyna odpowiadać coraz krócej i jest przy tym coraz bardziej pewny siebie. Loss i zbiór held-out wyglądają dobrze, ale z modelem dzieje się coś nie tak. Jeśli na bieżąco analizujesz normy i porównujesz codziennie odpowiedzi modelu z tymi z wczoraj, możesz szybko wyłapać wzrost logitów i zorientować się, że model przypisuje coraz większe prawdopodobieństwo określonym tokenom. Ta arogancja to sztuczka leniwego optymalizatora – AdamW znalazł sposób na to, żeby nas oszukać i zamiast uczyć model, zmniejsza stratę w inny sposób. Jeśli wyłapiesz to po kilku dniach, możesz stracić kilkadziesiąt dolarów; jeśli puszczasz trening, licząc, że jednostka Nvidii po prostu wykona całą pracę, możesz wydać setki, czy tysiące a model może być już niemożliwy do uratowania. Sam spędziłem tygodnie, obserwując, jak Adam pompuje normy moich modeli, obniżając efektywny learning rate (LR), i to pomimo nałożonej normalizacji QK-norm i weight decay 0.1. Trening zwalniał, doprowadzając mnie do rozpaczy, bo jak wiemy, działa tu prawo Pitagorasa i rosnący wektor wag coraz trudniej obracać stałym LR. Sprawa jest dobrze opisana w literaturze, ale dopóki sam tego nie zobaczysz, nie zrozumiesz, dlaczego lepiej zastosować inny optymalizator. W końcu AdamW pomógł wytrenować setki modeli. Ja zdecydowałem się ostatecznie na MuonH i to była jedna z lepszych decyzji, jakie podjąłem. Oczywiście wiele tego typu rzeczy można wyciągnąć z literatury, podręczników czy śledząc prace naukowe publikowane na arXiv, ale nigdy nie wiesz, jak to zadziała u ciebie. Wiele rozwiązań, które teoretycznie powinny przynieść dobrze udokumentowane korzyści, u mnie nie zadziałało. Nie przekonasz się, dopóki sam nie sprawdzisz, a żeby się przekonać, trzeba trzymać rękę na pulsie i na bieżąco śledzić postępy. ### 4. Wprowadzaj zawsze tylko jedną zmianę i rób testy ablacyjne Przez ostatnie miesiące przetestowałem setki małych modeli – zarówno klasycznych transformerów, jak i moich własnych pomysłów... i dziś wiem, że testowałem za mało. Chcąc iść do przodu zbyt szybko, niepotrzebnie traciłem czas. Ilość warstw, FFN ratio, d_model, wiązanie wag, wielkość głowic, ilość głowic KV, batch, optymalizator, rekurencja, rzadkość (sparsity), dane treningowe – czynników, które mają wpływ na zachowanie modelu, są dziesiątki, a możliwe kombinacje dają tysiące możliwych architektur. I choć z grubsza wszystko działa tak, jak można by się spodziewać po przeczytaniu pierwszego podręcznika na temat inżynierii AI, tak długo jak sam nie przetestujesz swojej architektury, nie będziesz wiedział, gdzie jesteś. Tymczasem drobne zmiany często potrafią prowadzić do dużych różnic w wydajności obliczeniowej i benchmarkach i to przy tym samym datasecie oraz wielkości batcha. Jeżeli nie wprowadzasz zmian w sposób izolowany, łatwo się w tym pogubić. Sam popełniłem ten błąd wiele razy. Nie chodzi o to, że poprawki były złe. Choć często były. Prawdziwy problem polegał na tym, że kiedy rzeczywiście robiłem krok do przodu, nie byłem w stanie powiedzieć, której zmianie to zawdzięczam. ### 5. Zacznij od danych Hugging Face ma niewyobrażalny zasób danych treningowych jak na potrzeby treningu małego modelu. Mogłoby się wydawać, że jeśli te dane są na wyciągnięcie ręki w ilościach przekraczających znacznie potrzeby jakiegokolwiek garażowego projektu, to sprawa jest załatwiona. Jednak dobór danych ma dużo większe znaczenie, niż mogłoby się na początku wydawać. I fakt, że zostały już one zebrane w gotowe datasety, wcale sprawy nie ułatwia. Dochodzi też kwestia wybrania właściwego tokenizera, języków, których chcemy nauczyć model, czy proporcji. Na przykład decyzja ile procent danych ma stanowić kod, ile matematyka, a ile język naturalny. Następnie w jakich domenach ma się specjalizować nasz model. Im głębiej w las, tym więcej możliwości. Ja sam musiałem przygotowywać swój dataset od zera aż 3 razy. Zaliczyłem też kilka mniejszych wpadek, jak przeciek szablonu instruct, którego nie wyłapałem na etapie przygotowywania danych. Każda taka pomyłka wymuszała cofnięcie treningu o godziny czy nawet dni. ### 6. Nie oczekuj zbyt wiele Widząc, jak duże i mniejsze laboratoria co chwilę przesuwają granice tego, co potrafi AI, nietrudno ulec wrażeniu, że wytrenowanie użytecznego modelu to w zasadzie prosta sprawa. Są jednak powody, dla których to przesuwanie granic kosztuje miliardy dolarów. To, że Twój model zaczyna mówić ludzkim głosem czy osiąga dobre wyniki w popularnych benchmarkach, nie mówi nic o jego finalnej jakości ani użyteczności. Modele bardzo szybko uczą się na początku, w pierwszych dniach treningu, ale walka o każdy kolejny procent w wynikach wymaga sprytu, uwagi i samozaparcia. Szczególnie, kiedy przez wiele dni widzisz, jak model zalicza plateau, czy wręcz się cofa. Poza tym popularne benchmarki niewiele mówią o realnych możliwościach modelu. Twój model może być dobry w Pythonie i robić świetne wyniki w HumanEval i MBPP, ale jeżeli nie ma wiedzy o najnowszych bibliotekach, jego użyteczność w prawdziwym świecie będzie umiarkowana. ### 7. Uzbrój się w cierpliwość Wiele umiejętności modeli rośnie skokowo. To dobrze opisane zjawisko grokkingu poprzedza często długotrwałe plateau, które może trwać dniami. Widząc, jak model nie osiąga żadnych postępów, podczas gdy ty za każdą godzinę treningu musisz płacić dolarami za wynajem mocy obliczeniowej czy choćby za sam prąd, nietrudno o chwilę zwątpienia. Myślisz: "Model osiągnął capacity, więcej się nie nauczy", albo "Duże laboratoria, które trenują do 1000x Chinchilla, pewnie stosują jakieś triki". Tymczasem umiejętności często rosną skokowo. Wystarczy, że model nauczy się domykać jakąś funkcję i nagle zamiast jednego, w MBPP wskakuje kilkanaście zaliczonych zadań. Często jest też tak, że model robi realne postępy, ale jeśli z powodów oszczędnościowych monitorujesz tylko top1 odpowiedzi zamiast top10, możesz tego przez długi czas w ogóle nie zauważyć. Model musi nauczyć się przypisywać większą pewność, a to wymaga czasu. ### 8. Jedna karta to za mało Może się wydawać, że jeśli dysponujesz jednostką H100 czy RTX PRO 6000 (96 GB), to ogranicza cię tylko budżet. Problem w tym, że trening wymaga ciągłych testów i pomiarów, które pomagają zorientować się, na jakim jesteśmy etapie. Dodatkowe GPU może być też potrzebne do generacji dodatkowych danych treningowych. Sam znaczne postępy w treningu modelu uzyskałem, trenując go metodą STaR, polegającą na generacji przez mój własny model dużej ilości zadań i dołączaniu do datasetu tych poprawnych oraz zestawowi danych zawierających przykłady translacji między językami programowania. Przerywanie treningu na mocnej karcie na czas generacji odpowiedzi przez model jest bardzo kosztowne i zwyczajnie nieopłacalne, a generowanie obok – nawet jeśli pozwala na to VRAM – może stanowić poważne zagrożenie. Ostatnią rzeczą, jakiej pragniesz, jest przekonanie się po trzech dniach, kiedy wyniki modelu pójdą w dół, że podczas generacji na karcie obok treningu doszło np. do chwilowego „głodzenia” loadera, w czego następstwie loss po cichu przestał spadać. Takie rzeczy na późniejszym etapie treningu są często niezwykle trudne do wychwycenia, nawet jeśli masz monitoring ostrzegający cię przed skokami norm. ### 9. Zacznij od czegoś prostego Mój pierwszy model zacząłem budować w oparciu o przeczucie, że w treningu llm da się wykorzystać własne aktywacje modelu, a śledzenie ich w trakcie nauki powinno pomóc zbudować inteligentniejszy i bardziej prawdomówny model. Dziś nie mogę się nadziwić samemu sobie, jak naiwne było to podejście. Nie dlatego, że dziś myślę, że to niemożliwe, ale dlatego, że nie mając pojęcia o tym, jak wygląda proces treningu LLM-a, zacząłem eksperymentować z czymś, co mnie przerastało. Musiałem przyswoić olbrzymią porcję wiedzy, a jednocześnie testować rozwiązania związane z architekturą klasycznych transformerów, jak i własne pomysły, które – jak pokazał czas – w dużej mierze były niemożliwe do realizacji. Natrafiłem przy tym na szereg problemów – sygnał aktywacji bramek SwiGLU poddany normalizacji tracił sens, a bez niej AdamW wykorzystywał moje modyfikacje do pompowania norm modelu. Dopiero po czasie zrozumiałem, że wiele z zalet, które znalazłem w moim pierwszym modelu, pochodziło ze zjawiska przypominającego regularyzację szumem. Na dodatek samo obliczanie Gini z aktywacji bramek SwiGLU było drogie obliczeniowo, nakładając kilka procent dodatkowego compute, czego rezultaty nie zwracały w jakości. Obecnie trenuję mały model 160M w standardowej architekturze, który specjalizuje się w kodowaniu. To była najlepsza decyzja, jaką mogłem podjąć, bo dałem sobie szansę na stworzenie czegoś, co może być realnie użyteczne. A pierwsze wyniki modelu pokazują, że nauka na błędach nie poszła na marne. ### 10. Nie buduj modelu, który będzie dobry we wszystkim Biorąc pod uwagę astronomiczne koszty i samą wykonalność, budowanie modelu ogólnego zastosowania przez pojedynczą osobę bądź małą organizację jest dziś zupełnie bez sensu z powodów czysto ekonomicznych. Konkurencja z gigantami, czy nawet mniejszymi laboratoriami wypuszczającymi otwarte modele, jest nie do wygrania bez olbrzymich nakładów i doświadczenia. Ale to wcale nie znaczy, że budowanie własnych modeli nie ma sensu. Można wyobrazić sobie setki zastosowań, gdzie małe modele wytrenowane od podstaw lub doszkolone na unikalnych danych, będą miały przewagę nad gigantami – i ta przewaga niekoniecznie musi polegać na wiedzy. Wystarczy, że model będzie szybki i możliwy do uruchomienia lokalnie w przeglądarce, lub na procesorze dowolnej stacji roboczej. Dla konkretnych wąskich zastosowań, dużo bardziej opłacalne może być użycie mikro modelu o wielkości kilkuset milionów parametrów, niż zaprzęgnięcie najpotężniejszych dostępnych OpenAI czy Anthropic. Nie chodzi tylko o koszty. Choć różnica jest kolosalna. Model, który specjalizuje się w wąskim zakresie, nie tylko znacznie łatwiej wytrenować, ale również kontrolować i dostosować do potrzeb użytkownika. Jednak co najważniejsze to zadanie, które nie wykracza poza możliwości zwykłego człowieka, który jest gotowy podjąć takie wyzwanie. Modele wielkich laboratoriów są trenowane na tysiącach bardzo drogich układów. Dla przykładu: wytrenowanie modelu klasy Llama 3 400B, wymagało klastra 16 000 kart H100. Koszty to dziesiątki milionów dolarów. Wytrenowanie najnowszego GPT Astra prawdopodobnie podniosło poprzeczkę znacznie wyżej. Biorąc pod uwagę, że cały ten sektor rozwija się na kredyt, a implementacja AI na szeroką skalę, przy obecnych kosztach API i kwestiach bezpieczeństwa danych, jest często trudna do obronienia biznesowo, w dłuższej perspektywie można spodziewać się, że małe modele będą odgrywać coraz większą rolę. Małe modele będą też coraz wydajniejsze. Nie zdziwiłbym się, gdyby do większości zadań w przyszłości wystarczył nam model rzędu 7B parametrów. Pęknięcie „bańki AI”, o której coraz częściej zaczyna się mówić w mediach, może ten proces tylko przyspieszyć. Dlatego uważam, że budowanie małych modeli ma głęboki sens. Po pierwsze, nie ma lepszej drogi do zrozumienia tego, jak działa AI, niż trenowanie własnego modelu. Po drugie, choć w dużych laboratoriach za rozwój AI coraz częściej odpowiada... samo AI, można się spodziewać, że ludzkość, traktując poważnie kwestie bezpieczeństwa, będzie oczekiwać kontroli i ludzkiego nadzoru nad procesem szkolenia. Do tego niezbędne jest zrozumienie, jak ten proces przebiega w praktyce. Oczywiście, wchodząc na LinkedIna, jesteśmy dziś zalewani postami na temat sztucznej inteligencji od najróżniejszych specjalistów oferujących tutoriale i szkolenia. Ale ilu z nich tak naprawdę wytrenowało swój własny model? --- Jakub Ćwirlej — Dziennikarz, który buduje z AI · na stronie: https://jakubcwirlej.com/pl/ai-dev/ Pełny kontekst: https://jakubcwirlej.com/context/pl.md · https://jakubcwirlej.com/llms.txt