Karpathy udostępnia nanochat — kompletny, lekki pipeline ChatGPT do treningu w 4 godziny za 100 dolarów

Nanochat to otwarte repozytorium autorstwa Andreja Karpathy’ego, które łączy wszystkie elementy w jedną, relatywnie zwartą implementację całego przepływu pracy — od trenowania tokenizera, przez pretraining i mid-training, aż po fine-tuning, opcjonalne RL i prosty serwer z webowym interfejsem czatu. Celem jest umożliwienie eksperymentów typu „end-to-end” na pojedynczym węźle z wieloma GPU: zalecana konfiguracja to 8×NVIDIA H100, a przykładowy „speedrun” ma zajmować ~4 godziny i kosztować około 100 dolarów (przy założeniu stawki ~24 USD/godzina za cały węzeł).

Jak działa „speedrun”?

Repo zawiera pojedynczy skrypt uruchamiający pełną sekwencję kroków: trening tokenizera, pretraining bazowego modelu, mid-training ukierunkowany na konwersacje i zadania zamknięte, Supervised Finetuning (SFT), opcjonalny RL na zbiorze GSM8K, ewaluację i serwowanie (CLI oraz prosty webowy interfejs przypominający ChatGPT). Po zakończeniu generowany jest raport (report.md) z metrykami takimi jak CORE, ARC, MMLU, GSM8K, HumanEval i ChatCORE.

Tokenizer i dane

nanochat korzysta z własnego tokenizera opartego na BPE napisanym w Rust (kompilowanym przez Maturin). Słownik ma 65 536 tokenów, a tokenizer trenowany jest na shardach FineWeb-EDU — przetworzonych i przemieszanych, by ułatwić dostęp. Autor raportuje kompresję rzędu ~4,8 znaków/token, porównywalną do wyników niektórych popularnych tokenizerów i zamierzoną jako neutralna względem metryk straty wyrażanej w bits-per-byte.

Model i założenia skalowania

Domyślny „speedrun” trenuje transformera o głębokości 20 warstw (~560 mln parametrów, 1280 kanałów ukrytych, 10 głów atencji po 128 wymiarów) na około 11,2 miliarda tokenów, co odpowiada zasadzie Chinchilla (proporcja parametrów × ~20 tokenów). Autor szacuje, że taka konfiguracja odpowiada zdolnościom rzędu ~4e19 FLOPs. Implementacja wykorzystuje Muon dla macierzy matmul oraz AdamW dla embeddingów/unembeddings; straty raportowane są w bpb, by być niezależnymi od konkretnego tokenizera.

Mid-training, SFT i obsługa narzędzi

Po wstępnym pretrainingu model przechodzi mid-training — adaptację do rozmów (korzystając z zestawu SmolTalk), uczenie zachowań dla zadań wielokrotnego wyboru (100k pomocniczych pytań MMLU) oraz naukę użycia narzędzi przez wstawki znaczników typu <|python_start|>…<|python_end|>. Zestaw domyślny to 568k wierszy mieszanki: SmolTalk (460k), MMLU aux-train (100k) i fragment GSM8K (8k). SFT nastawiony jest na wysoką jakość konwersacji i dopasowanie formatu treningu do formatu inferencji (pad, rozłączne wiersze), by zmniejszyć mismatch między treningiem a testowaniem.

Opcjonalne RL: uproszczone GRPO

Repo oferuje też uproszczoną procedurę GRPO na GSM8K jako etap opcjonalny. Ważne jest jednak, że autor jasno opisuje kompromisy w porównaniu do standardowego PPO/RLHF: brak modelu referencyjnego i kar KL, brak trust-region, on-policy aktualizacje bez klipów PPO, tokenowy GAPO-like normalizer i mean-shift przy advantage. W praktyce przypomina to REINFORCE z kilkoma modyfikacjami, co upraszcza implementację, ale może mieć konsekwencje dla stabilności i jakości uczenia.

Wyniki i koszty

Przykładowy raport dla ~4-godzinnego speedrunu pokazuje umiarkowane wyniki: CORE baseline 0,2219; po mid-training i SFT ARC-Easy wzrósł do 0,3876, ARC-Challenge ~0,2807, MMLU 0,3151, GSM8K 0,0455, HumanEval 0,0854 i ChatCORE 0,0884. Cały proces zajmuje około 3h51m przy założeniu rekomendowanej infrastruktury.

Skalowanie poza „speedrun”

README opisuje też dwa kolejne progi kosztowe: Tier ~300 USD (d=26, ~12h) — według autora nieco przewyższający GPT-2 CORE — oraz Tier ~1 000 USD (~41,6h), który ma przynieść wyraźną poprawę spójności i podstawowych umiejętności rozumowania i kodowania. Wcześniejsze eksperymenty wskazują, że model d=30 trenowany ~24 godziny osiągał lepsze wyniki MMLU i ARC.

Co warto docenić, a co krytykować?

Siła nanochat tkwi w prostocie i reprodukowalności: stosunkowo mały zestaw zależności (~8k LOC), czytelny skrypt „speedrun” i generowany raport umożliwiają szybkie iteracje i transparentne eksperymenty. To cenna baza dla badaczy, studentów i inżynierów, którzy chcą zrozumieć cały pipeline bez wchodzenia w ciężkie frameworki.

Jednak projekt nie jest pozbawiony ograniczeń. Uproszczone RL może nie dawać tych samych korzyści co pełne RLHF z reference model i karami KL — w praktyce wpływa to na stabilność i na to, jakie zachowania model faktycznie wyuczy. Metryki podane w speedrunie są użyteczne jako punkt startowy, lecz jeden krótki przebieg na specyficznej konfiguracji sprzętowej nie zastępuje pełnej walidacji; wyniki są podatne na wariancję treningową i wybory danych. Dodatkowo wymóg 8×H100 i koszt ok. 100 USD choć relatywnie niski dla zespołu badawczego, pozostaje barierą dla hobbystów z ograniczonym budżetem.

Znaczenie dla społeczności

nanochat ma wartość edukacyjną i praktyczną: demontuje czarną skrzynkę „jak zbudować ChatGPT” na poziomie, który da się odtworzyć lokalnie i iterować na nim szybko. Dla społeczności open-source to też sygnał, że sensowne eksperymenty LLM nie zawsze wymagają setek tysięcy GPU-godzin — choć lepsze właściwości modelu nadal zależą od skali i dopracowania procedur szkoleniowych.

Podsumowanie

Projekt Karpathy’ego to solidne narzędzie referencyjne — kompaktowe, dobrze udokumentowane i angażujące. Umożliwia zrozumienie i replikację pełnego pipeline’u LLM, z zastrzeżeniem, że uproszczenia (zwłaszcza w części RL) i ograniczenia sprzętowe przekładają się na granice jakości modeli osiąganych w „speedrunie”. Dla badaczy i praktyków nanochat jest wygodnym punktem wyjścia do dalszych eksperymentów i optymalizacji; dla osób oczekujących modelu „produkcji” pozostaje raczej narzędziem edukacyjnym niż gotowym rozwiązaniem klasy enterprise.