Jak faktycznie zbudować LLM

00 — Kontekst: dlaczego ten wykład

Wykład Stanford CS229 prowadzony przez Yanna Dubois (Stanford, wspópracujący z zespołem Alpaca i Alpaca Farm) jest prawdopodobnie najgęstszym bezpłatnym kompendium tego, co naprawdę dzieje się przy budowie modeli pokroju ChatGPT, Claude i Gemini. Nie jest to tutorial "zbuduj sobie GPT w 2000 linijkach". To wykład operacyjny - pokazuje, gdzie uciekają pieniądze, gdzie siedzi realny leverage i dlaczego większość publikacji akademickich nie ma znaczenia.

Wykład wypłynął ponownie w kwietniu 2026 roku, gdy wielu użytkowników X zaczęło go udostępniać jako "jedną z najbardziej transparentnych rzeczy, które można obejrzeć o LLM". Dubois prowadzi go w bardzo szczególnym tonie: mówi o rzeczach, o których firmy tej skali raczej nie mówią publicznie - liczby, koszty, trade-offy, problemy otwarte.

Today we'll be talking about how they actually work. It's going to be an overview because it's only one lecture and it's hard to compress everything. But hopefully I'll touch a little bit about all the components that are needed to train some of these LLMs. Yann Dubois, Stanford CS229

Niniejszy playbook to pełne tłumaczenie i rozłożenie tego wykładu na części pierwsze, z moimi własnymi komentarzami w miejscach, gdzie coś wymaga rozwinięcia albo odniesienia do rynku polskiego. Jeśli chcesz obejrzeć oryginał, link do tweeta, w którym wypłynął, znajdziesz w źródłach powyżej.

01 — Pięć komponentów LLM

Dubois zaczyna od twierdzenia, że budowa LLM-a to w praktyce pięć odrębnych obszarów inżynierskich, nie jeden. Każdy z nich jest dyscypliną samą w sobie i w realnym projekcie ma własny zespół.

1. Architektura - jaki typ sieci neuronowej. Dziś w 99% przypadków to wariant transformera.
2. Training loss i algorytm treningu - co dokładnie minimalizujemy i jak (SGD, Adam, gradient clipping, learning rate schedule).
3. Dane - na czym model uczymy. W praktyce najważniejsza i najmniej opisana część.
4. Ewaluacja - skąd wiemy, że w ogóle posuwamy się do przodu.
5. Systemy - jak to w ogóle uruchomić na dostępnym sprzęcie bez marnowania miliardów na niewykorzystane GPU.

Jego pierwsza niespodziewana teza: architektury są dziś najmniej ciekawe. Dlaczego? Bo w sieci jest tysiące dobrych materiałów o transformerach, a dodatkowo - jego zdaniem - dalsze dłubanie w architekturze daje niewielki zysk w porównaniu z wygranymi po stronie danych, ewaluacji i systemów.

Most of academia actually focuses on architecture and training algorithm and losses. But in reality, what matters in practice is mostly the three other topics. Yann Dubois

02 — Autoregresja i next-token prediction

LLM to model probabilistyczny rozkładu nad sekwencjami tokenów. Rozkład ten rozkładamy przez regułę łańcuchową:

P(x₁, x₂, ..., x_L) = P(x₁) · P(x₂|x₁) · P(x₃|x₁,x₂) · ... · P(x_L|x₁,...,x_{L-1})

W konsekwencji zadanie treningu LLM upraszcza się do predykcji kolejnego tokena na podstawie wszystkiego, co było wcześniej. Matematycznie minimalizujemy cross-entropy między rozkładem predykowanym przez model a one-hot wektorem prawdziwego następnego tokena.

Dlaczego to ma sens

Cross-entropy minimalizacja na tokenach jest dokładnie maximum likelihood estimation na całym tekście. Model "uczy się" rozkładu prawdopodobieństwa nad ludzkim pismem w internecie. W konsekwencji model wytrenowany na całym internecie po prostu modeluje internet - to daje odpowiedź na pytanie, dlaczego GPT-3 bez post-trainingu odpowiadał pytaniami (bo w internecie po pytaniu najczęściej stoi inne pytanie).

Generacja: sampling w pętli

Gdy chcemy generować tekst, iterujemy: model predykuje rozkład, z tego samplujemy token, dodajemy go do kontekstu, powtarzamy. Minus: generacja jest sekwencyjna, nie da się jej trywialnie zrównoleglić. Dla długiego outputu (10k tokenów) robi się drogie.

03 — Tokenizacja: BPE i pułapki

Przed transformerem stoi tokenizer, który dzieli surowy tekst na tokeny (małe kawałki, zwykle 3-4 znaki średnio). Dlaczego nie całe słowa i dlaczego nie pojedyncze znaki? Dubois wyjaśnia to dość elegancko:

• Słowa - nie obsługują literówek, nie obsługują języków bez spacji (tajski, chiński). Zbyt sztywne.
• Znaki - zbyt długie sekwencje. Koszt uwagi w transformerze rośnie kwadratowo z długością.
• Tokeny - kompromis. Jedno słowo = zwykle 1-2 tokeny, rzadkie słowa rozbijane na kawałki.

Byte-Pair Encoding (BPE)

Dominujący algorytm tokenizacji. Zaczyna od pojedynczych znaków, następnie iteracyjnie łączy najczęstsze pary znaków w nowe tokeny. Powtarzane tysiące razy. Efekt: vocabularz o rozmiarze 50k-100k tokenów, gdzie najczęstsze słowa ("the", "and", "który") to pojedyncze tokeny, a rzadkie słowa ("defenestracja") rozbijane są na kilka podtokenów.

Na etapie inferencji tokenizer działa deterministycznie: dla danego ciągu znaków zawsze tworzy ten sam podział (greedy matching: najdłuższy pasujący token).

Gotcha: matematyka i kod

Dubois zwraca uwagę na ważny problem. Jeśli liczba "327" dostała własny token, model nie widzi cyfr "3", "2", "7" osobno. W konsekwencji utrudnia to generalizację arytmetyczną - model musi nauczyć się każdej liczby jako osobnej jednostki, zamiast operować na cyfrach.

OpenAI rozwiązał część tego problemu w GPT-4, wprowadzając specjalne tokenizowanie kodu (4 spacje = jeden token, co radykalnie skraca sekwencje Pythona). Dubois spekuluje, że w horyzoncie 5-10 lat, gdy attention przestanie być kwadratowe, tokenizacja może zniknąć.

04 — Pretraining: loss i perplexity

Cross-entropy loss

Na etapie pretrainingu minimalizujemy średnią cross-entropy loss po całym korpusie. W praktyce oznacza to: ile "bitów" zaskoczenia model ma przy każdym kolejnym tokenie.

Perplexity - jednostka codzienna

W praktyce zespoły treningowe patrzą nie na loss, tylko na perplexity:

perplexity = 2 ^ (average_loss)

Intuicja Dubois: perplexity to liczba tokenów, między którymi model "się waha" przy każdej predykcji. Jeśli perplexity = 10, model faktycznie rozważa około 10 różnych tokenów jako prawdopodobne. Jeśli perplexity = 1, model jest pewny. Jeśli perplexity = 50000 (= rozmiar vocabularu), model zgaduje zupełnie na ślepo.

Skok w jakości 2017-2023

• 2017: perplexity ≈ 70 tokenów (model "gubił się" w 70 możliwych kontynuacjach)
• 2023: perplexity < 10 tokenów

To jest olbrzymia poprawa, choć ludzka intuicja jej nie uchwytuje - wszystko dzieje się w logarytmach prawdopodobieństwa.

05 — Benchmarki: HELM, MMLU, leaderboardy

Perplexity zależy od tokenizera - nie porównasz modeli z różnych vocabularów. Stąd w akademii używa się zbiorczych benchmarków.

Główne benchmarki

• HELM (Stanford) - setki zadań, agregacja wyników.
• Hugging Face Open LLM Leaderboard - publiczna tablica dla modeli open-source.
• MMLU - multiple choice z 57 domen (medycyna, fizyka, prawo, historia). De facto gold standard dla "ogólnej wiedzy" LLM.

MMLU w praktyce

MMLU daje modelowi pytanie i 4 odpowiedzi (A, B, C, D). Ewaluator sprawdza, któremu tokenowi ("A", "B", "C", "D") model przypisuje największe prawdopodobieństwo. To działa, bo odpowiedź jest dyskretna i weryfikowalna.

Problem: wyniki MMLU nie są porównywalne między publikacjami

Dubois pokazuje przykład: Alpaca 65B w jednym źródle raportowana z 63.7%, w innym z 48.8%. Ten sam model, te same dane, różne metody ewaluacji (np. zero-shot vs few-shot, sposób formatowania pytania, sposób liczenia prawdopodobieństwa).

Test set contamination

Jeśli w danych treningowych siedzi już zbiór testowy (np. MMLU przeciekł do Common Crawla), model "zna" odpowiedzi z pamięci. Laboratorium Hashimoto w Stanford ma sprytny trick: jeśli model daje wyższe prawdopodobieństwo pytaniom w kolejności zbioru testowego niż w losowej kolejności, to znak, że zbiór był w danych treningowych.

06 — Dane: 15 trylionów tokenów

Tu zaczyna się dział, którego firmy nie opisują dokładnie, bo to ich przewaga konkurencyjna. Dubois przemycą dużo konkretów.

Skala

• 2017 (GPT-1): ~150 mld tokenów (≈800 GB tekstu)
• 2024 (Llama3): 15 trylionów tokenów
• GPT-4: ~13 trylionów (szacunki z przecieków)

To 100-krotny wzrost w 7 lat. Stosunek tokenów do parametrów w Llama3 wynosi około 40:1 - kompromis między optymalnym treningiem (20:1, Chinchilla) a optymalną inferencją (150-200:1, bo mniejszy model = tańszy deployment).

Źródło: Common Crawl

Większość danych pochodzi z Common Crawla - publicznego archiwum indeksującego internet. 250 miliardów stron, 1 petabajt surowego HTML. Wszystkie liczące się LLM-y zaczynają od tego samego źródła. Różnica leży w filtrowaniu.

Pipeline czyszczenia danych (6 etapów)

1. HTML parsing - ekstrakcja czystego tekstu. Wyzwania: matematyka w LaTeX, boilerplate (nagłówki forów, cookie banners).
2. Filtrowanie niepożądanych treści - NSFW, PII (dane osobowe), treści toksyczne. Duże zespoły utrzymują tu klasyfikatory ML.
3. Deduplikacja - te same artykuły Wikipedia pojawiają się w Common Crawl setki razy, długa książka może być tam 1000 razy pod różnymi URL. To najbardziej obciążający obliczeniowo etap.
4. Heurystyczne filtrowanie niskiej jakości - zbyt krótkie dokumenty, zbyt długie, anomalne rozkłady tokenów, dokumenty złożone z 90% liczb etc.
5. Filtrowanie modelem - trenujemy prosty klasyfikator "Wikipedia vs losowy web". Ten klasyfikator ocenia wszystkie 250 mld stron. Strony przypominające Wikipedię dostają większą wagę.
6. Klasyfikacja domeny - kod, książki, papiery naukowe, rozrywka. Na koniec treningu zespoły zmniejszają learning rate i dotreniają model wyłącznie na wysokiej jakości danych (Wikipedia, książki, kod). To forma świadomego overfittingu na tym, co naprawdę warto znać.

Kod pomaga w matematyce

Dubois wspomina intrygujący efekt: zwiększenie udziału kodu w danych treningowych poprawia zdolności rozumowania w zadaniach niekodowych. Mechanizm nie jest dobrze zrozumiany, ale efekt jest empirycznie powtarzalny. Hipoteza: kod wymusza sztywne, ustrukturyzowane rozumowanie krok po kroku.

Zespół danych

W zespole Llama (70 osób total) około 15 osób pracowało nad danymi - więcej niż nad modelowaniem. Co ciekawe, praca nad danymi wymaga głównie CPU, nie GPU - filtrowanie, deduplikacja, parsing to zadania tekstowe, nie treningowe.

We really haven't solved data at all for pre-training. Yann Dubois

07 — Scaling laws i Chinchilla

Jedno z najważniejszych empirycznych odkryć ostatniej dekady w ML. Paper OpenAI z 2020 roku pokazał, że dla LLM:

log(loss)  vs.  log(compute)       →  prosta linia
log(loss)  vs.  log(data_size)     →  prosta linia
log(loss)  vs.  log(parameters)    →  prosta linia

Konsekwencje

Skoro to prosta linia w skali log-log, możemy ekstrapolować. Znając compute dostępny za 2 lata (prawo Moore'a), można przewidzieć jakość modelu za 2 lata. Przy zachowaniu wszystkich innych czynników (dane, architektura).

That's crazy because it means that you can predict how well we're going to perform in two, three years, depending on how much compute we will add, assuming that these things will hold. Yann Dubois

Overfitting nie istnieje

W klasycznym ML uczą cię: za duży model + za mało danych = overfitting. W świecie LLM to po prostu nie zachodzi empirycznie. Większy model + więcej danych = zawsze lepiej. To wywróciło całą intuicję akademii i trwało lata, zanim środowisko się z tym pogodziło.

Chinchilla (DeepMind, 2022)

Kluczowa praca: dla danego compute budgetu, jakie jest optymalne rozłożenie między liczbę parametrów a liczbę tokenów?

Odpowiedź empiryczna: ~20 tokenów na parametr.

• Model 70B → optymalnie 1.4 tryliona tokenów
• Model 400B → optymalnie 8 trylionów tokenów

To odwróciło podejście. Wcześniej trenowano GPT-3 na 175B parametrach przy 300B tokenach (1.7:1). Po Chinchilli zaczęto trenować mniejsze modele na dużo większych danych.

Training-optimal vs inference-optimal

Chinchilla 20:1 minimalizuje koszt treningu. Ale jeśli chcesz modelu, który potem będzie tanio inferować miliardy razy dziennie, chcesz modelu mniejszego (czyli wytrenowanego na większej ilości danych niż Chinchilla zaleca). Llama3 405B przy 15.6T tokenów jest na poziomie 40:1 - świadomy kompromis Meta: większy model niż czysty inference-optimal, mniejszy niż training-optimal.

Bitter Lesson Richarda Suttona

The only thing that matters is to have architectures that can leverage computation. Richard Sutton, 2019

Wniosek: każda drobna modyfikacja architektury (nowa funkcja aktywacji, nowy normalization layer) w horyzoncie 5 lat zostanie wypłukana przez same scaling laws. Co się opłaca: systemy, dane, ewaluacja. Co się nie opłaca: mikro-optymalizacje architektury.

08 — Back-of-envelope: ile kosztuje Llama3 405B

Dubois przeprowadza publicznie kalkulację kosztów Llama3 405B. Rzadka okazja zobaczenia, jak powstaje bilans takiego projektu.

Dane wejściowe

• 405 mld parametrów
• 15.6 bln tokenów
• Token-to-param: ~40

FLOPs potrzebne

FLOPs ≈ 6 × params × tokens
       = 6 × 4.05 × 10¹¹ × 1.56 × 10¹³
       ≈ 3.8 × 10²⁵

Ciekawostka regulacyjna

Executive Order Bidena (październik 2023) ustanowił próg 1 × 10²⁶ FLOPs, powyżej którego trenowanie modelu wymaga raportowania do rządu USA. Llama3 405B ląduje 2x poniżej progu. Dubois sugeruje, że nie jest to przypadek - Meta świadomie zaplanowała trening w ten sposób, by uniknąć tego reżimu.

Czas i infrastruktura

• 16 000 GPU H100
• ~70 dni treningu
• ~26 milionów GPU-godzin (Meta raportuje 30M, 10% bufor)

Koszt

• H100 wynajem: ~$2/godzina (dolny ogranicznik)
• Compute: 26M × $2 = ~$52M
• Zespół: 50 osób × $500k/rok = ~$25M
• Łącznie: ~$75M (±10-15M)

Ślad węglowy

Około 4 000 ton CO₂. Dla porównania: ~2 000 lotów JFK-Londyn tam i z powrotem. Dubois nie uznaje tego za problematyczne dla pojedynczego treningu, ale ostrzega: GPT-6/7 będą 100x większe, a ślad skaluje się liniowo.

09 — Post-training: po co w ogóle

GPT-3 (czysty language model) na pytanie "wyjaśnij 6-latkowi lądowanie na Księżycu" odpowiadał w stylu: "wyjaśnij 6-latkowi teorię grawitacji, wyjaśnij 6-latkowi fotosyntezę, wyjaśnij 6-latkowi...". Dlaczego? Bo w internecie po jednym pytaniu tego typu bardzo często stoi lista podobnych pytań. Model nie robi nic złego - idealnie odtwarza rozkład internetu.

Problem w tym, że tego nie chcemy od asystenta. Chcemy modelu, który rozumie intencję i odpowiada zgodnie z nią. To dokładnie robi post-training.

Dwa cele post-trainingu

1. Alignment - dopasowanie do intencji użytkownika.
2. Safety - unikanie generowania treści toksycznych, niebezpiecznych, szkodliwych.

Historycznie: to właśnie post-training, nie większy model, był skokiem od GPT-3 (znanego researcherom) do ChatGPT (znanego wszystkim).

10 — SFT: Supervised Fine-Tuning

Najprostszy post-training. Bierzesz pretrained model i dotreniowywujesz go na zbiorze par (instrukcja, pożądana odpowiedź) napisanych przez człowieka. Funkcja straty - ta sama cross-entropy co w pretrainingu. Różnica jedynie w danych.

Ilu przykładów potrzebujesz

Kontrintuicyjna odpowiedź: niewielu. Praca LIMA (Meta, 2023) pokazała, że przy zbiorze 1 000 wysokojakościowych przykładów model osiąga porównywalną jakość jak przy 32 000. Więcej danych SFT nie pomaga.

Dlaczego tak mało wystarcza

Wyjaśnienie Dubois jest piękne: SFT nie uczy modelu nowej wiedzy. Model już zna wszystko, co wie, z pretrainingu. SFT jedynie "mówi modelowi, który styl użytkowania ma zachowywać". Pretrenowany model modeluje wszystkie style internetu - SFT filtruje ten jeden, którego chcesz.

You're not learning new knowledge, just redistributing probability mass. All you learn is how to format your desired answers. Yann Dubois

Alpaca: syntetyczne dane

Jedna z najbardziej znanych prac Stanford (Dubois współautor). Recepta:

1. 175 seed examples napisanych przez ludzi.
2. Prompt do text-davinci-003: "wygeneruj więcej podobnych par pytań i odpowiedzi".
3. 52 000 wygenerowanych syntetycznie przykładów.
4. Fine-tune Llama 7B na tym zbiorze.

Wynik: model jakościowo zaskakująco blisko ChatGPT, koszt generowania danych ~$500. To uruchomiło całą falę prac nad syntetycznymi danymi. Dziś większość open-source modeli ma w danych SFT znaczny udział tekstu wygenerowanego przez silniejszy model.

Ograniczenia SFT

• Behavioral cloning - model kopiuje styl ludzkich labelerów, co ogranicza go do ludzkiej jakości.
• Hallucination z SFT - jeśli labeler napisze w odpowiedzi referencję, której model nie widział w pretrainingu, model nauczy się generować plausible-looking referencje, których nie ma. To jest mikroźródło halucynacji, o którym rzadko się mówi.

11 — RLHF i reward model

SFT ma swoje limity. Żeby iść dalej, trzeba porzucić paradigm "ucz się pisać jak człowiek" i przejść do "ucz się maksymalizować ludzką preferencję".

Pipeline RLHF

1. Model generuje dwie odpowiedzi na każdą instrukcję.
2. Człowiek wybiera, która jest lepsza (A lub B).
3. Trenujemy reward model - osobna sieć neuronowa, która dostaje (instrukcję, odpowiedź) i zwraca liczbę (reward).
4. Używamy RL (zwykle PPO) do optymalizacji polityki - model uczy się generować odpowiedzi, które reward model wysoko ocenia.

Bradley-Terry: od binary do ciągłego sygnału

Kluczowy trick: nie trenujemy reward modelu na binarnej etykiecie "A lepsze od B", tylko na rozkładzie prawdopodobieństwa przez softmax dwóch reward score'ów. To daje gradientowi więcej sygnału niż sparsy binary label.

PPO (Proximal Policy Optimization)

Algorytm RL z OpenAI (John Schulman). Dość skomplikowany w praktyce: rollouty, clipping, dwa modele jednocześnie, pętle zewnętrzne. Dubois jest bardzo szczery:

Reinforcement learning is something that's super nice theoretically. In practice, anyone who ever worked with RL knows it's such a mess. Yann Dubois

Po PPO model nie jest już LLM-em

Kluczowy punkt: po PPO model jest polityką, nie modelem prawdopodobieństwa. Nie można już na nim liczyć perplexity, a rozkład prawdopodobieństwa, który zwraca, nie ma już klasycznej interpretacji. To komplikuje ewaluację.

12 — DPO: prościej niż PPO

W 2023 roku zespół z Princeton i Stanford zaproponował Direct Preference Optimization - algorytm, który osiąga efekt PPO, ale bez reward modelu i bez RL. Tylko maximum likelihood.

Loss DPO (intuicyjnie)

L = -log σ(β · (log π(y_win|x)/π_ref(y_win|x)
             - log π(y_lose|x)/π_ref(y_lose|x)))

Gdzie π to nasza aktualna polityka, π_ref to polityka referencyjna (zwykle po SFT, przed RLHF). Loss zwiększa prawdopodobieństwo preferowanej odpowiedzi i zmniejsza prawdopodobieństwo odrzuconej, z regularyzacją KL względem polityki referencyjnej.

Dlaczego to genialne

• Jedna funkcja straty zamiast pipeline RL.
• Jeden trening zamiast czterech.
• Matematycznie równoważne PPO w optymalnym punkcie.
• Łatwiejsze debugowanie, przewidywalny gradient.

Dlaczego OpenAI używał PPO zamiast DPO

DPO został sformułowany po ChatGPT. Dodatkowo OpenAI miało mocny background RL (John Schulman to autor PPO). Plus: reward model ma potencjalną zaletę - można go trenować na danych bez par preferencji (np. etykietach "ta odpowiedź jest toksyczna"), co daje większy leverage z tagów.

W praktyce open-source cały świat przeszedł na DPO. AlpacaFarm, zephyr-7b, mistral-instruct - wszystko na DPO.

13 — Ewaluacja post-training

Po RLHF/DPO mamy problem: jak ocenić, czy model jest lepszy. Perplexity nie działa (wyjaśnione powyżej). Benchmarki typu MMLU mierzą wiedzę, nie jakość konwersacji. Standard rynkowy to pairwise comparison.

Chatbot Arena (lmsys.org)

Gold standard. Użytkownicy dostają losowe pytanie, dwa modele generują odpowiedzi anonimowo, użytkownik wybiera lepszą. Setki tysięcy porównań miesięcznie. Wyniki agregowane w ranking Elo (jak szachy). To jest najbardziej zaufane źródło rankingów w open community.

Limit: użytkownicy Chatbot Areny to programiści i entuzjaści AI. Preferencje przeciętnego użytkownika mogą się różnić.

LLM-as-judge

Zamiast pytać ludzi, pytamy silniejszy model (zwykle GPT-4): "który output lepszy - A czy B?". Tanie, szybkie, skalowalne.

AlpacaEval

Benchmark Dubois. Standardowy zestaw 805 instrukcji, GPT-4 jako sędzia, baseline = GPT-4 text-davinci-003. Mierzymy win rate modelu względem baseline. Korelacja z Chatbot Areną: 98%. Koszt ewaluacji: pod $10, pod 3 minuty.

Length bias - największy problem

LLM jako sędzia ma silne preference dla dłuższych odpowiedzi (ludzie też mają, ale model to wzmacnia). Dubois pokazuje eksperyment:

• GPT-4 vs GPT-4 (kontrola): 50% win rate
• GPT-4 z instrukcją "pisz zwięźle" vs GPT-4 standard: 20%
• GPT-4 z instrukcją "pisz rozwlekle" vs GPT-4 standard: 64.4%

Ta sama jakość, radykalnie różne wyniki. Rozwiązanie: length-controlled win rate - regresja kontrolująca spurious correlation z długością odpowiedzi.

14 — Systems: GPU i mixed precision

Dubois zostawia systemy na koniec i przeznacza na nie mniej czasu - ale liczby są tu brutalne.

Bottleneck: komunikacja, nie compute

GPU są projektowane pod throughput, nie pod latencję (odwrotnie niż CPU). Optymalizowane są pod jedną operację: mnożenie macierzy. Mnożenie jest ~10x szybsze niż inne operacje.

Problem: compute (FLOPs/s) rośnie szybciej niż memory bandwidth i komunikacja między GPU. W praktyce: pipe'y danych są wąskim gardłem.

Model FLOPs Utilization (MFU)

Metryka: ile procentowo teoretycznego maximum FLOPs GPU faktycznie używamy w trakcie treningu.

• Naiwny trening: ~20-30% MFU (GPU leży bezczynnie 70% czasu).
• Dobrze zoptymalizowany trening: ~50% MFU.
• Meta Llama3 training: ~45% MFU.

50% to docelowy poziom, nie "źle zrobione". Druga połowa czasu GPU czeka na dane.

Mixed precision (half precision)

Standardowo obliczenia neural networks trzyma się w float32 (32 bity). Pomysł: obliczenia w bf16 lub fp16 (16 bitów), ale wagi trzymamy w float32. Korzyść: 2x mniej danych do przesłania = 2x szybszy trening (komunikacja była wąskim gardłem).

Dlaczego to działa: deep learning jest hałaśliwy. Zastąpienie update 0.01 przez 0.015 nic nie zmienia w długim horyzoncie. Margines precyzji jest duży.

Operator fusion (torch.compile)

Każda linijka w PyTorchu to osobny transfer danych na GPU. Dwa kolejne operacje (x.cos(), x.sin()) = dwa transfery. Operator fusion łączy je w jeden kernel: jeden transfer, cała operacja, jeden transfer z powrotem. Efekt: ~2x przyspieszenie z jedną linijką kodu (torch.compile).

Czego Dubois nie pokrywa

• Tiling (dzielenie macierzy na kawałki mieszczące się w cache GPU)
• Tensor parallelism / pipeline parallelism (rozkład modelu na wiele GPU)
• Mixture of Experts (inny paradygmat skalowania)
• Inference optimization (osobny olbrzymi temat)

15 — 8 wniosków contrarian

Rzeczy, które idą pod włos temu, czego uczy większość kursów i tutoriali.

1. Overfitting nie istnieje w LLM

Klasyczne ML uczy: duży model + mało danych = overfitting. W LLM ta zasada empirycznie nie zachodzi. Im większy model i więcej danych, tym zawsze lepiej. Scaling laws tego dowodzą.

2. Architektura ma mniejsze znaczenie niż sądzisz

Drobne modyfikacje architektury (nowa funkcja aktywacji, nowy positional encoding) zmieniają jedynie intercept scaling law - krótkoterminową przewagę, która po 10x więcej compute znika.

3. Perplexity jest bezużyteczna dla modeli po RLHF

Post-trained modele to polityki, nie rozkłady prawdopodobieństwa. Porównywanie perplexity ChatGPT z Gemini jest błędem metodologicznym.

4. SFT nie uczy nowej wiedzy

Tylko redystrybuuje masę prawdopodobieństwa. Cała wiedza jest już w modelu po pretrainingu. Stąd 1 000 przykładów SFT wystarczy.

5. Część halucynacji pochodzi z SFT

Kiedy labeler pisze odpowiedź z referencją, której model nie widział w pretrainingu, model uczy się generować plausible-sounding referencje, które nie istnieją.

6. LLM-judge ma silne length bias

GPT-4 jako sędzia daje 64% win rate tej samej jakości modelowi, jeśli prompt każe mu pisać rozwlekle. Wyniki benchmarków post-trainingu muszą być kontrolowane na długość.

7. Dane > architektura

Sam Dubois, po latach pracy nad architekturami, uznaje dane za ważniejsze. To kompletnie odwrotne od narracji akademickiej (architektura = sexy, dane = unglamorous).

8. Tokenizacja to dług techniczny

Liczby i kod cierpią z powodu tokenizacji. GPT-4 już to częściowo naprawił dla kodu. W horyzoncie 5-10 lat tokenizacja może zniknąć całkowicie.

16 — 5 praktycznych rekomendacji

Jeśli trenujesz LLM (albo fine-tune'ujesz):

1. Alokuj czas zgodnie z realnym ROI

Większość zespołów inżynierskich spędza za dużo czasu na architekturze i za mało na danych. Zmień proporcje: 50% dane, 20% ewaluacja, 20% systemy, 10% architektura.

2. Przy SFT idź na małe, wysokojakościowe zbiory

1 000-5 000 naprawdę dobrych przykładów > 100 000 średnich. Używaj LIMA jako punktu odniesienia. Jeśli potrzebujesz syntetycznych danych, użyj silniejszego modelu + ludzkiej redakcji (zamiast pełnej generacji).

3. Dla post-trainingu: DPO, nie PPO

Prościej, szybciej, bez inżynierskiego długu. Standard open source w 2026.

4. Przy ewaluacji zawsze kontroluj spurious correlations

Długość odpowiedzi. Styl. Format. Używaj length-controlled win rate. Porównuj z Chatbot Areną, nie polegaj na pojedynczych benchmarkach.

5. Inwestuj w systemy, bo to trwała przewaga

Mixed precision + torch.compile + dobrze napisane parallelism daje 3-5x speedup na tym samym sprzęcie. MFU 50% to cel.

17 — Co zostaje otwarte

Dubois wymienia (eksplicytnie lub implicytnie) długą listę rzeczy nierozwiązanych:

• Efektywne filtrowanie danych - wszystko co mamy dziś to ad-hoc heurystyki. Nie ma "sztuki" filtrowania Common Crawla.
• Synthetic data collapse - co się stanie, gdy kolejne modele będą trenować się na coraz większym udziale danych wygenerowanych przez poprzednie modele. Hipoteza: degradacja jakości po 3-4 generacjach.
• Test set contamination - trudna do wykrycia, niemożliwa do prewencji w pełnej skali.
• Ewaluacja w długich interakcjach - wszystko co mamy to pytania-odpowiedzi. Nie mamy dobrych benchmarków dla agentowych, wieloetapowych zadań.
• Inference-optimal vs training-optimal trade-off - nikt nie ma dobrej teorii, która powie, gdzie jest optimum ekonomiczne dla danej aplikacji.
• Komunikacja między GPU - MFU 50% znaczy, że 50% czasu idzie na transfer, nie na compute. Sprzętowy bottleneck, który nie został rozwiązany.
• Czy internet się skończy - szacunki na 2027-2030 mówią, że przy obecnym tempie wzrostu modeli tekst w internecie będzie wyczerpany. Co dalej: dane syntetyczne, multimodal, robotyka.

Podsumowanie

Wykład Dubois jest wart 104 minut z jednego powodu: to jeden z niewielu publicznych dokumentów, który traktuje budowę LLM jako operacyjną inżynierię, nie jak akademicką ciekawostkę. Pokazuje, gdzie są realne dźwignie, gdzie są pieniądze i gdzie są trade-offy, o których nie usłyszysz na konferencji.

Jeśli miałbym wybrać jedną myśl do zapamiętania: data jest dziś moat, nie architektura. Każdy kto w ekosystemie AI chce budować coś unikalnego, inwestuje w dane. Każdy kto kopiuje konkurencję, dłubie w architekturze.

If you train your model more on code, actually it helps reasoning. This is the type of thing that people discover and it's actually really important. Yann Dubois

Ten jeden przykład - że dodanie kodu do danych tekstowych poprawia rozumowanie matematyczne, choć mechanizm nie jest w pełni zrozumiany - pokazuje, że nadal jesteśmy na etapie empirycznym. Nie ma teorii. Jest eksperyment, obserwacja, iteracja. Jak biologia w XIX wieku, nie jak fizyka w XX.

Dla każdego kto myśli o zostaniu operatorem AI w firmie, konsultantem, architektem systemów agentowych - to wykład, którego fundamenty trzeba rozumieć. Nie trzeba umieć trenować modelu. Trzeba rozumieć, dlaczego on jest taki, jaki jest.