Przewodnik po inżynierii LLM: 45 pojęć dotyczących systemów produkcyjnych

Viacheslav Dubrov

2026-03-13 · Zaktualizowano 2026-08-31 · 58 min · Inżynieria modeli · Infrastruktura AI

Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.

Usługa LLM może nie spełnić swojego SLO opóźnienia, ponieważ faza decode jest ograniczona przepustowością pamięci, ponieważ KV cache wyczerpał budżet batcha albo ponieważ kolejka maskuje oba te problemy. Run fine-tuningu może zakończyć się niepowodzeniem z innego wariantu tego samego powodu: stan modelu przestał mieścić się w sprzęcie. Właściwa poprawka wynika z wąskiego gardła, a nie z najdłuższej listy technik.

To materiał referencyjny dla inżynierów, którzy znają już podstawowe pojęcia ML i systemów, ale potrzebują połączyć objaw produkcyjny z odpowiednią częścią stosu. Obejmuje 45 pojęć z zakresu sprzętu, inferencji, treningu, wdrażania, aplikacji i operacji. Użyj danego wpisu, aby zidentyfikować mechanizm, jego praktyczne konsekwencje oraz warunek ograniczający przytoczony wynik; następnie skorzystaj z powiązanego pogłębionego artykułu lub własnego benchmarku, aby podjąć decyzję.

Uwaga dotycząca zakresu

To materiał referencyjny, a nie liniowy tutorial. Zacznij od części odpowiadającej decyzji, przed którą stoisz.

Jak korzystać z tego przewodnika jako huba

Ta strona jest celowo szeroka. Traktuj ją jak mapę, a gdy decyzja stanie się konkretna, przejdź do bardziej szczegółowych artykułów.

Zacznij od wąskiego gardła, użyj najmniejszego stosu, który pozwala je ujawnić, zmierz rzeczywisty workload i dodawaj złożoność tylko tam, gdzie uzasadniają ją liczby.

Część I — Podstawy sprzętowe

Intensity arytmetyczna, hierarchia pamięci GPU i terminy sprzętowe z tej części wyjaśniają wiele decyzji omawianych w dalszej części przewodnika.

1. Ograniczenie pamięcią a ograniczenie obliczeniami i model Roofline

Punktem wyjścia do analizy wydajności LLM jest intensity arytmetyczna: ile użytecznych obliczeń GPU wykonuje dla każdego bajta danych załadowanego z pamięci? Ten stosunek decyduje, czy operacja jest ograniczona obliczeniami (czeka na procesor), czy ograniczona pamięcią (czeka na załadowanie danych).

Każde GPU ma próg „krytycznej intensywności”, przy którym szczytowa przepustowość obliczeniowa zrówna się z przepustowością pamięci. Dla NVIDIA H100 SXM, wykorzystującego gęste Tensor Cores w BF16 lub FP16 (989 TFLOPS; specyfikacja 1979 TFLOPS zakłada strukturalną sparsity):

$\frac{989 \text{ TFLOPS}}{3.35 \text{ TB/s}} \approx 295 \text{ FLOPs/byte}$

Decode dla batch-one oraz długi lub wystarczająco batchowany prefill zwykle znajdują się po przeciwnych stronach tego progu:

• Decode jest ograniczony pamięcią. Generowanie tokenów jeden po drugim oznacza ładowanie wielogigabajtowej macierzy wag z pamięci, aby wymnożyć ją przez pojedynczy nowy token. W uproszczonej analizie gęstej operacji 16-bitowej dla batch-one operacja ma około 1 FLOP/bajt, czyli mniej więcej 295 razy poniżej progu Roofline H100. Ta luka wyjaśnia, dlaczego decode nie może w tym trybie zbliżyć się do szczytowej przepustowości obliczeniowej.
• Długi lub wystarczająco batchowany prefill jest często ograniczony obliczeniami. Przetwarzanie wielu tokenów promptu ponownie wykorzystuje wagi w dużych mnożeniach macierzy, co może podnieść intensity arytmetyczną powyżej progu Roofline. Krótkie prompty i małe batche mogą być natomiast ograniczone ruchem danych lub narzutem uruchamiania jąder.

Aby przyspieszyć decode, pracuj nad przepustowością pamięci: zmniejsz wagi za pomocą kwantyzacji, ogranicz narzut pamięciowy KV za pomocą GQA i PagedAttention oraz zwiększ intensity przez batching. W przypadku długich lub dobrze batchowanych prefillów mogą pomóc szybsze obliczenia macierzowe i niższa precyzja; obciążenia z krótkim prefill warto profilować osobno.

2. Hierarchia pamięci GPU

GPU ma cztery warstwy pamięci ułożone jak piramida: dużą, lecz wolną pamięć główną (HBM) na dole oraz niewielkie, ale bardzo szybkie rejestry na szczycie. Przenoszenie danych przez tę hierarchię jest istotnym ograniczeniem wydajności.

Od najszybszej do najwolniejszej na H100:

1. Rejestry są najszybszą pamięcią i są bezpośrednio przypisane do wątków obliczeniowych. W przypadku WGMMA architektury Hopper macierz A może pochodzić z rejestrów lub pamięci współdzielonej, natomiast macierz B pochodzi z pamięci współdzielonej.
2. SRAM (pamięć współdzielona) to szybka pamięć robocza on-chip, lokalna dla każdego SM.
3. Cache L2 to współdzielona warstwa o pojemności 50 MB. Może dostarczać dane ponownie wykorzystywane przez różne SM bez kolejnego odczytu z HBM.
4. HBM3 to główna pamięć o pojemności 80 GB, przechowująca wagi modelu i KV cache, z przepustowością ~3,35 TB/s.

FlashAttention i kernel fusion ograniczają ruch danych z HBM, zatrzymując lub łącząc pośrednie wyniki on-chip. PagedAttention rozwiązuje inny problem: mapuje logiczne bloki KV na nieciągłe fizyczne bloki pamięci GPU, ograniczając fragmentację i umożliwiając współdzielenie bloków.

3. Glosariusz sprzętu GPU

Poniższe terminy pojawiają się w dalszej części przewodnika.

HBM (High Bandwidth Memory) składa się ze stosów układów DRAM połączonych przez TSV (through-silicon vias), umieszczonych obok układu GPU. Kolejne generacje obejmują HBM2e (A100, 2 TB/s), HBM3 (H100, 3,35 TB/s) i HBM3e (H200/B200, 4,8–8 TB/s). Przepustowość HBM bezpośrednio ogranicza TPOT w trybach decode ograniczonych pamięcią.

GDDR (Graphics DDR) to tradycyjna pamięć graficzna używana w konsumenckich i workstationowych GPU, takich jak RTX 4090 i L40S. Ma niższą przepustowość niż HBM, ale niższy koszt za GB. GDDR6X w RTX 4090 zapewnia około 1 TB/s wobec 3,35 TB/s przepustowości HBM3 w H100.

SM (Streaming Multiprocessor) to podstawowy blok obliczeniowy w GPU NVIDIA. Każdy SM zawiera CUDA cores, Tensor Cores, pamięć współdzieloną i scheduler warps. H100 ma 132 SM, a A100 ma ich 108.

Tensor Cores to wyspecjalizowane jednostki multiply-accumulate dla macierzy wewnątrz każdego SM. Przyspieszają mieszanej precyzji matmule dominujące w obliczeniach Transformera. Tensor Cores H100 SXM zapewniają 494,5 gęstych lub 989 rzadkich TF32 TFLOPS; przy porównywaniu tej wartości zawsze uwzględniaj precyzję i tryb sparsity.

CUDA Cores to uniwersalne jednostki zmiennoprzecinkowe i całkowitoliczbowe. Obsługują operacje element-wise, funkcje aktywacji i inne zadania niemacierzowe, podczas gdy Tensor Cores wykonują obsługiwane operacje macierzowe.

Warp to grupa 32 wątków wykonujących instrukcje synchronicznie na SM, czyli najmniejsza jednostka schedulingu NVIDIA. Specjalizacja warpów przypisuje różne warpy do przenoszenia danych i obliczeń, aby zadania mogły zachodzić równolegle.

NVLink to szybkie połączenie GPU-GPU firmy NVIDIA w obrębie węzła. NVLink 4.0 w H100 zapewnia 900 GB/s dwukierunkowej przepustowości; NVLink 5.0 w B200 osiąga 1,8 TB/s. Ta przepustowość ma znaczenie dla tensor parallelism, ponieważ GPU wymieniają częściowe wyniki po każdej warstwie Transformera.

InfiniBand to szybka infrastruktura sieciowa do komunikacji między węzłami. Adaptery InfiniBand klasy ConnectX zapewniają sieć międzywęzłową dla ruchu pipeline parallelism lub distributed training; przepustowość zależy od adaptera i konfiguracji portu.

RDMA (Remote Direct Memory Access) pozwala urządzeniu uzyskać dostęp do pamięci innej maszyny bez kierowania ścieżki danych przez CPU. GPUDirect RDMA obsługuje bezpośrednie transfery GPU-GPU między węzłami, w tym transfery KV cache w disaggregated serving.

NVMe (Non-Volatile Memory Express) to interfejs SSD używany do offloadingu KV cache oraz offloadingu parametrów przez ZeRO-Infinity, gdy pamięć GPU i CPU jest niewystarczająca. Przepustowość sekwencyjna zależy od dysku i workloadu, ale pozostaje znacznie niższa niż przepustowość HBM.

TFLOPS i PFLOPS oznaczają odpowiednio biliony i biliardy operacji zmiennoprzecinkowych na sekundę. Jeden TFLOPS to $10^{12}$ FLOPS. H100 osiąga 989 rzadkich TF32 tensor TFLOPS, natomiast FlashAttention-3 raportuje około 1,2 PFLOPS w FP8; wartości te dotyczą różnych formatów i nie należy porównywać ich tak, jakby były jedną metryką.

Część II — Podstawy inferencji

Inferencja zamienia model w usługę widoczną dla użytkownika. Poniższe pojęcia rozdzielają pracę opóźniającą pierwszy token od pracy spowalniającej każdy kolejny token oraz ujawniają ograniczenia pamięci stojące za obiema fazami.

4. Opóźnienie: TTFT, TPOT i percentyle

Time to First Token (TTFT) to opóźnienie end-to-end od wysłania żądania do pierwszego tokena wyjściowego. Obejmuje kolejkowanie, tokenizację, scheduling, prefill promptu, pierwszy krok decode i dostarczenie przez sieć. Dłuższe prompty zwykle zwiększają składową prefill, ale dominować może dowolny z tych etapów. Cele zależą od produktu; MLPerf Inference v5.0 używa limitu P99 TTFT równego $\leq$ 450 ms dla interaktywnego scenariusza Llama 2 70B.

Time Per Output Token (TPOT) to średni odstęp między kolejnymi tokenami po pierwszym tokenie. Odzwierciedla fazę decode. Decode dla batch-one lub o niskiej intensywności jest zwykle ograniczony przepustowością pamięci, natomiast odpowiednio duże batche mogą stać się ograniczone obliczeniami:

$\text{TPOT} = \frac{\text{E2E Latency} - \text{TTFT}}{\text{Output Tokens} - 1}$

Definicja ta wymaga co najmniej dwóch tokenów wyjściowych; dla odpowiedzi jedn tokenowej TPOT jest nieokreślone.

Średnia prędkość cichego czytania po angielsku przez dorosłych wynosi około 238 słów na minutę dla tekstów non-fiction (Brysbaert, 2019). Cele streamingu powinny jednak wynikać z testów produktu; MLPerf używa limitu P99 TPOT równego $\leq$ 40 ms w swoim scenariuszu interaktywnym.

Opóźnienie P50 vs P99 ma znaczenie, ponieważ mediana ukrywa ogon rozkładu. System z dobrym P50 i złym P99 może mieć problemy z batchingiem, preempcją, kolejkowaniem lub zróżnicowaniem workloadu; do ich rozróżnienia potrzebne są trace’y.

5. Przepustowość: tokeny na sekundę i kompromis z opóźnieniem

Przepustowość mierzy się jako liczbę tokenów wyjściowych na sekundę dla współbieżnych żądań. Sama liczba żądań na sekundę jest słabszą miarą, ponieważ odpowiedź zawierająca 10 tokenów i odpowiedź zawierająca 1000 tokenów mają zupełnie różny koszt. Publikowane wyniki benchmarków zależą od modelu, precyzji, sprzętu, długości promptu i odpowiedzi, współbieżności oraz SLO. Porównuj vLLM, SGLang i TensorRT-LLM za pomocą jednego harnessu, zamiast łączyć ich nagłówkowe wyniki.

Kompromis wygląda następująco: przy niskiej współbieżności każde żądanie ma świetne opóźnienie, ale GPU jest niedostatecznie wykorzystane. Zwiększanie rozmiaru batcha podnosi przepustowość niemal liniowo do momentu nasycenia obliczeń, po czym opóźnienie gwałtownie rośnie. Goodput, czyli liczba żądań na sekundę spełniających docelowe SLO, łączy surową przepustowość z rzeczywistym doświadczeniem użytkownika.

6. KV cache: wąskie gardło stojące za większością innych wąskich gardeł

Podczas autoregresywnego generowania każdy nowy token korzysta z attention względem wszystkich wcześniejszych tokenów. KV cache przechowuje projekcje Key i Value każdego tokena w każdej warstwie, aby uniknąć $O(n^2)$ ponownych obliczeń. Bez niego wygenerowanie tokena $n$ wymagałoby ponownego uruchomienia modelu dla wszystkich $n-1$ wcześniejszych tokenów.

KV cache może stać się dominującym źródłem presji na pamięć zmienną przy długich sekwencjach lub wysokiej współbieżności, ponieważ rośnie liniowo wraz z długością sekwencji, rozmiarem batcha i liczbą warstw:

$KVcache = 2 \times L \times h_{kv} \times d_h \times s \times B \times \text{bytes}$

gdzie:

• $L$ = liczba warstw
• $h_{kv}$ = liczba głów KV
• $d_h$ = wymiar głowy
• $s$ = długość sekwencji
• $B$ = rozmiar batcha
• $\text{bytes}$ = liczba bajtów na cachowany element, ustalana przez precyzję KV cache

Konkretne przykłady dla FP16 i batch size 1: Llama 3.1 8B przy 8192 tokenach używa około 1,0 GB KV cache; przy 128K tokenów jest to 16 GB. Llama 3.1 70B przy 128K tokenów potrzebuje ~40 GB dla pojedynczej sekwencji, czyli połowy VRAM H100. Przy wysokiej współbieżności lub długim kontekście KV cache może przekroczyć pamięć zajmowaną przez wagi modelu; wynik zależy od długości sekwencji, aktywnego batcha, precyzji KV i liczby głów KV. Naiwne implementacje marnują 60–80% zaalokowanej pamięci KV z powodu fragmentacji — właśnie ten problem miał rozwiązać PagedAttention.

Najważniejsze optymalizacje to GQA (mniej głów KV), kwantyzacja KV cache (FP8/INT8), PagedAttention (alokacja blokowa z marnotrawstwem <4%) oraz offloading KV cache do CPU lub NVMe.

7. Prefill a decode: dwie fazy, dwa wąskie gardła

Faza prefill przetwarza wejściowy prompt równolegle i wypełnia KV cache. Długie lub wystarczająco batchowane prefille często stają się ograniczone obliczeniami, ponieważ wykorzystują duże mnożenia macierzy; krótkie prefille mogą nadal być ograniczone ruchem danych lub narzutem uruchamiania jąder. Prefill wpływa na time to first token (TTFT) wraz z kolejkowaniem, tokenizacją, schedulingiem, pierwszym krokiem decode i dostarczeniem przez sieć. Faza decode generuje po jednym tokenie naraz. Każdy krok odczytuje wagi modelu i KV cache z HBM, dlatego decode dla batch-one jest ograniczony przepustowością pamięci i zwykle dominuje time per output token (TPOT).

Chunked prefill dzieli prompt na chunki o stałym rozmiarze zamiast przetwarzać go w całości naraz. Scheduler może przeplatać te chunki z pracą decode, dzięki czemu jeden długi prompt nie monopolizuje iteracji. Sarathi-Serve raportuje lepszy kompromis między przepustowością a opóźnieniem w testowanych workloadach, ale zysk zależy od modelu, sprzętu, rozkładu długości żądań, rozmiaru chunka i baseline’u. Dodatkowy scheduling i mniejsze jądra mogą zwiększyć TTFT nowego żądania.

Disaggregated serving umieszcza prefill i decode w oddzielnych pulach GPU, dzięki czemu każda pula może celować w inne wąskie gardło. Splitwise i DistServe opisują ten wzorzec. Pule przesyłają dane KV cache przez szybkie połączenie, takie jak RDMA, więc koszt komunikacji staje się częścią projektu.

8. GQA i MQA: zmniejszanie KV cache

Standardowe Multi-Head Attention (MHA) przydziela każdej głowie query własną głowę K i V. Multi-Query Attention (MQA) współdzieli jedną głowę KV między wszystkie głowy query, co stanowi skrajną redukcję. Grouped-Query Attention (GQA) to praktyczny kompromis: grupy głów query współdzielą jedną głowę KV.

Llama 3 70B używa 64 głów query, ale tylko 8 głów KV, co daje 8-krotną redukcję KV cache względem tej samej architektury z jedną głową KV na każdą głowę query. Llama 3.1 405B używa 128 głów query i 8 głów KV, czyli 16-krotnej redukcji przy tym samym obliczeniu (Meta, 2024). Ainslie i in. raportują jakość GQA zbliżoną do MHA w testowanych modelach przy szybkości zbliżonej do MQA. Mniejszy KV cache może obsługiwać większe batche, ale rzeczywisty zysk pod względem opóźnienia i przepustowości nadal zależy od jądra i workloadu.

9. Kwantyzacja: zamiana bitów na szybkość i pamięć

Kwantyzacja zmniejsza precyzję wag modelu i/lub aktywacji. Główne kompromisy:

AWQ (Activation-Aware Weight Quantization) identyfikuje istotne kanały wag na podstawie magnitud aktywacji i stosuje skalowanie per-channel, aby je chronić. Wymagania kalibracji zależą od modelu i konfiguracji; w jednym porównaniu OPT-6.7B INT3-g128 AWQ używało 16 sekwencji kalibracyjnych, a GPTQ — 192. W odtwarzalnej konfiguracji raportuj zarówno liczbę sekwencji, jak i ich długość. GPTQ wykorzystuje przybliżone informacje drugiego rzędu do kwantyzacji warstwowej. bitsandbytes może kwantyzować model podczas ładowania bez osobnego przebiegu preprocessingowego; jego format NF4 zasila fine-tuning QLoRA. FP8 na sprzęcie klasy Hopper zmniejsza pamięć wag o połowę względem FP16/BF16, ale jakość i szybkość nadal zależą od modelu, kalibracji i jądra.

Kernel servingowy może mieć równie duże znaczenie jak algorytm kwantyzacji. Sekcja 10 podaje ograniczony wynik dla Marlin i wyjaśnia, dlaczego zysk zależy od konfiguracji servingowej.

Część III — Optymalizacje inferencji

Optymalizacje w tej części rozwiązują różne ograniczenia. FlashAttention zmniejsza ruch danych attention przez HBM; PagedAttention usprawnia alokację KV; continuous batching zapobiega zajmowaniu pojemności batcha przez zakończone sekwencje.

10. Jądra CUDA i kernel fusion

Jądro CUDA to funkcja napisana dla GPU, wykonywana równolegle przez tysiące wątków. Gdy CPU wywołuje jądro, GPU rozdziela pracę między swoje SM: każdy SM uruchamia wiele warpów po 32 wątki, a każdy wątek przetwarza fragment danych. Każda operacja podczas inferencji LLM, od mnożenia macierzy po sampling tokenów, jest ostatecznie uruchomieniem jądra. Pojedynczy forward pass przez model 70B wywołuje od setek do tysięcy jąder, a różnica między naiwnym i zoptymalizowanym jądrem może decydować o spełnieniu SLO opóźnienia.

Główne kategorie jąder w serving LLM:

• Jądra GEMM do mnożenia macierzy, dominujące zarówno w obliczeniach prefill, jak i decode.
• Jądra attention, takie jak FlashAttention, które dzielą obliczenia na kafelki, aby pozostać w SRAM zamiast przelewać dane do HBM.
• Fused kernels, które łączą wiele operacji (np. add + layer norm lub projekcję QKV) w jedno uruchomienie, pomijając pośrednie podróże danych do HBM i z powrotem.
• Jądra samplingu, które zamieniają logity na identyfikatory tokenów za pomocą samplingu top-k, top-p lub temperature.

Jakość jądra może decydować o tym, czy skompresowane wagi zapewnią przyspieszenie. Artykuł o Marlin raportuje do 2,8-krotnego przyspieszenia end-to-end względem baseline’u FP16 dla testowanych konfiguracji vLLM z weight-only INT4. Wynik ten dotyczy modeli, GPU, rozmiarów batcha i konfiguracji servingowej z artykułu, dlatego nie jest uniwersalnym zyskiem INT4.

Triton obniża próg wejścia do pisania własnych jąder, udostępniając programowanie GPU przez Python zamiast surowego CUDA C++, dzięki czemu optymalizacja na poziomie jąder staje się dostępna dla inżynierów ML, a nie tylko specjalistów GPU. Większość późniejszych optymalizacji w tej części (FlashAttention, fused kernels, PagedAttention) to albo lepsze jądra, albo inteligentniejsze sposoby orkiestracji ich uruchomień.

Kernel fusion łączy sekwencyjne operacje w jedno jądro GPU i pomija pośrednie zapisy do HBM. Typowe fuzje obejmują projekcję QKV, attention z softmax, add z RMSNorm (FlashNorm) oraz aktywację SwiGLU (DeepFusionKernel). Triton udostępnia te jądra przez Python. Dokładne zyski pod względem liczby uruchomień i wykorzystania zależą od grafu modelu, kompilatora, GPU i frameworka servingowego, dlatego profiluj wdrożony stos zamiast opierać się na uniwersalnym procencie.

11. FlashAttention: kafelkowanie attention tak, aby działać w SRAM

Standardowe attention materializuje pełną macierz attention $N \times N$ w HBM, co kosztuje $O(N^2)$ pamięci i generuje duży ruch danych. Idea FlashAttention polega na tym, aby w ogóle nie materializować tej macierzy. Macierze Q, K i V są dzielone na bloki mieszczące się w SRAM, w każdym kafelku obliczane jest częściowe attention, a wyniki są łączone za pomocą online softmax (inkrementalnego śledzenia bieżącego maksimum i sumy w blokach). Zużycie pamięci spada z $O(N^2)$ do $O(N)$, a odczyty z HBM zmniejszają się o rząd wielkości.

Każda wersja celuje w wąskie gardło swojej generacji GPU:

• FlashAttention v1 (A100, 2022) dowiodło, że idea kafelkowania i online softmax działa. Artykuł raportował przyspieszenie 2–4x względem standardowego attention, ale tylko 25–40% wykorzystania GPU, ponieważ scheduling jąder pozostawiał wiele SM bez pracy.
• FlashAttention v2 (A100, 2023) przeprojektowało równoległość, dzieląc pracę wzdłuż wymiaru sekwencji zamiast batcha i głów. Osiągnęło 50–73% wykorzystania na A100, czyli około 2x większą szybkość niż v1.
• FlashAttention v3 (H100 Hopper, 2024) dodało specjalizację warpów (osobne warpy do przesyłania danych i obliczeń) oraz potokowanie GEMM-softmax w celu nakładania odczytów pamięci na obliczenia. Artykuł raportuje do 740 TFLOPS/s w FP16 (75% wykorzystania) i niemal 1,2 PFLOPS/s w FP8 na H100. NeurIPS 2024 spotlight.
• FlashAttention v4 (B200 Blackwell, 2026) rozwiązuje nowe wąskie gardło: na Blackwell przepustowość Tensor Cores rośnie tak szybko, że operacje niemacierzowe (eksponencjacje softmax, reskalowanie) stają się ograniczeniem. FA4 emuluje programowo eksponentę za pomocą przybliżeń wielomianowych na jednostkach FMA, używa warunkowego reskalowania w celu ograniczenia narzutu i przechowuje wartości pośrednie w dedykowanej pamięci tensorowej Blackwell (TMEM), a nie w rejestrach. Artykuł raportuje około 1,6 PFLOPS na B200 w BF16, 1,3x większą szybkość niż cuDNN 9.13 i 2,7x większą niż Triton w swoich testach.

12. FlashDecoding: równoleglenie wąskiego gardła decode

Standardowe FlashAttention utrzymuje GPU zajęte, dzieląc pracę według rozmiaru batcha i długości query. Podczas decode model generuje dokładnie 1 token naraz (długość query = 1). Jeśli iloczyn rozmiaru batcha i liczby głów attention jest mniejszy niż całkowita liczba SM GPU (108 na A100), większość GPU pozostaje bezczynna, podczas gdy kilka jednostek sekwencyjnie przetwarza historię tokenów.

FlashDecoding rozwiązuje ten problem, dodając nowy wymiar równoległości: długość sekwencji KV. Dzieli KV cache na mniejsze chunki i rozdziela je między wszystkie nieużywane procesory GPU, aby ewaluować je równolegle, a następnie scala częściowe obliczenia przez redukcję log-sum-exp.

W benchmarku batch-one dla CodeLlama-34B przeprowadzonym przez Stanford, przy długościach sekwencji od 512 do 64K tokenów, FlashDecoding osiągnął do 8-krotnego przyspieszenia end-to-end względem testowanych baseline’ów i utrzymał niemal stałe opóźnienie attention aż do 64K. Wynik ten jest ograniczony do danego sprzętu i benchmarku, a nie stanowi ogólnej gwarancji dla decode.

13. Continuous batching a static batching

Static batching czeka na zakończenie każdej sekwencji w batchu przed rozpoczęciem kolejnego, dlatego krótkie sekwencje marnują cykle GPU, pozostając bezczynne po osiągnięciu końca sekwencji. Continuous batching (wprowadzone w artykule Orca, OSDI 2022) działa z granularnością iteracji: na każdym kroku decode zakończone sekwencje są usuwane, a nowe dodawane.

W benchmarku OPT-13B firmy Anyscale zoptymalizowany static batching osiągnął 4x względem naiwnego baseline’u, continuous batching osiągnął 8x, a vLLM z continuous batching i PagedAttention — 23x (Anyscale, 2023). Continuous batching zwiększa również presję na alokację KV, dlatego często łączy się go ze stronicowanym zarządzaniem pamięcią.

14. PagedAttention: pamięć wirtualna dla KV cache

PagedAttention w vLLM stosuje ideę pamięci wirtualnej z systemów operacyjnych do zarządzania KV cache. KV cache dzieli się na bloki o stałym rozmiarze (zwykle 16 tokenów), bloki są alokowane na żądanie podczas generowania tokenów, a pozycje logiczne (sekwencyjne) mapują się na fizyczne (rozproszone) lokalizacje pamięci za pośrednictwem tablic bloków. Wiele żądań współdzielących prefix (prompty systemowe, beam search) może wskazywać te same fizyczne bloki.

Wcześniejsze systemy marnowały 60–80% pamięci KV z powodu fragmentacji i prealokacji. PagedAttention zmniejsza tę wartość do <4%, co pozwala zwiększyć przepustowość 2–4x przy tym samym opóźnieniu i do 24x względem HuggingFace Transformers (vLLM Blog, 2023).

15. Speculative decoding: wiele tokenów w jednym forward pass

W speculative decoding mały model draft generuje $K$ tokenów kandydujących, a duży model target ocenia wszystkie pozycje $K$ w jednym forward pass. Dekoder akceptuje tokeny draft od lewej do prawej, korzystając z prawdopodobieństw wynikających z rozkładów target i draft. Po pierwszym odrzuceniu losuje korektę z resztkowego rozkładu target i odrzuca pozostałe tokeny draft. Ten zmodyfikowany krok rejection sampling zachowuje rozkład wyjściowy modelu target z uwzględnieniem numeryki sprzętowej; samo dokładne dopasowanie tokenów tego nie gwarantuje.

Zysk jest najbardziej prawdopodobny przy małych batchach servingowych i krótkich draftach, gdy ocena draft jest zdominowana przez ruch wag, KV cache lub komunikację, a nie przez dodatkowe obliczenia tokenów. Oryginalny artykuł o speculative sampling raportował 2–2,5x przyspieszenia decode dla testowanej konfiguracji Chinchilla 70B; EAGLE-3 raportował do 6,5x w swoich testach. Warianty obejmują Medusa (dodatkowe głowy predykcji, bez osobnego modelu), prompt lookup decoding (dopasowanie n-gramów do wejścia bez osobnego forward pass modelu draft) oraz EAGLE (ekstrapolacja na poziomie cech).

Przy dużych batchach dodatkowa praca draft i weryfikacji może zniwelować zysk. Speculative decoding jest najbardziej obiecujące, gdy batch servingowy jest wystarczająco mały, a akceptacja draft wysoka; benchmarkuj pełną pętlę servingową, a nie tylko kernel weryfikacji.

16. Prefix caching i ponowne użycie KV cache

Zamiast wyrzucać KV cache po zakończeniu żądania, prefix caching zachowuje go do ponownego użycia w nowych żądaniach współdzielących te same tokeny prefixu. Ogranicza to redundantny prefill dla promptów systemowych, przykładów few-shot, kontekstu RAG i historii rozmów wieloturowych.

Automatic Prefix Caching w vLLM hashuje bloki KV i używa globalnej tablicy hashy do wyszukiwania. RadixAttention w SGLang utrzymuje drzewo radix cachowanych tensorów KV z granularnością tokenów. Oba podejścia zależą od powtarzalnych, identycznych tokenowo prefixów, dlatego obok opóźnienia lub przepustowości raportuj hit rate.

17. Streaming w praktyce

Streaming wysyła tokeny do klienta w miarę ich generowania, zamiast czekać na pełną odpowiedź. Wiele frameworków servingowych udostępnia go przez Server-Sent Events: klient otwiera długotrwałe połączenie HTTP, a serwer wysyła każdy token lub batch tokenów jako zdarzenie data:. TTFT określa, kiedy użytkownik po raz pierwszy zobaczy wynik; TPOT wpływa na płynność odbioru. Ustal cel na podstawie testów produktu i wybranego modelu interakcji.

Po stronie klienta streaming wymusza decyzje dotyczące buforowania. Renderowanie token po tokenie może powodować wizualne migotanie, szczególnie w przypadku markdownu lub bloków kodu, które do poprawnego formatowania potrzebują wielu tokenów kontekstu. Typowe wzorce to buforowanie na poziomie słów (akumulowanie tokenów do granicy białego znaku), buforowanie na poziomie wierszy (czekanie na znak nowej linii przed renderowaniem) oraz buforowanie adaptacyjne (natychmiastowe renderowanie prozy i buforowanie bloków kodu). W OpenAI Chat Completions API, stream_options: {"include_usage": true} dodaje końcowy chunk usage przed wiadomością data: [DONE]. Serwery kompatybilne z OpenAI mogą się różnić, dlatego zweryfikuj wybraną implementację.

Chunked prefill to jeden ze sposobów zapobiegania blokowaniu dostarczania tokenów współbieżnym użytkownikom przez długie prefille. Scheduling z priorytetem decode może chronić żądania będące w toku, a disaggregated serving izoluje prefill i decode w osobnych pulach GPU.

Część IV — Architektura modelu

Architektura ustala footprint pamięci, zachowanie attention i dynamikę treningu, z którymi muszą radzić sobie sekcje dotyczące serving i treningu.

18. Podstawy architektury Transformera

Nowoczesny transformer decoder-only (GPT, Llama) jest stosem identycznych warstw, z których każda ma dwa podbloki: attention i feed-forward. Każdy podblok jest opakowany połączeniem rezydualnym i normalizacją. Kluczowe elementy:

Multi-Head Attention pozwala każdemu tokenowi ważyć informacje z tokenów widocznych zgodnie z maską attention. Wejście jest rzutowane na trzy macierze: Queries (czego szukam?), Keys (co zawieram?) i Values (jakie informacje niosę?). Wyniki attention oblicza się następująco:

$\text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V$

Iloczyn skalarny $QK^T$ mierzy podobieństwo między każdą parą tokenów. Dzielenie przez $\sqrt{d_k}$ zapobiega nadmiernemu wzrostowi iloczynów skalarnych (co wypchnęłoby softmax w obszary zanikających gradientów). Softmax zamienia wyniki na prawdopodobieństwa, a mnożenie przez $V$ tworzy ważoną kombinację wektorów Value. Wykonywanie tego równolegle dla wielu głów pozwala modelowi jednocześnie zwracać uwagę na różne relacje (jedna głowa może śledzić składnię, inna koreferencję itd.).

Feed-Forward Network (FFN) niezależnie przekształca reprezentację każdego tokena po tym, jak attention wymiesza informacje między tokenami. Nowoczesne LLM często używają SwiGLU zamiast oryginalnego dwumacierzowego FFN z ReLU:

$\text{SwiGLU}(x) = \left(\text{Swish}(xW_{gate}) \odot xW_{up}\right)W_{down}$

SwiGLU ma trzy macierze wag zamiast dwóch w FFN z ReLU i używa gładkiej funkcji Swish. Używają go Llama, Mistral i Qwen; Gemma używa przybliżenia GeGLU. Znana reguła dwóch trzecich dotyczy konwencjonalnego bloku full-MHA z $d_{ff} \approx 4d$: jego dwie macierze FFN odpowiadają za około $8d^2$ parametrów, wobec około $4d^2$ dla attention. Nie jest to uniwersalne przybliżenie dla architektur SwiGLU/GQA. W Llama 3 8B, $d=4{,}096$, $d_{ff}=14{,}336$ oraz osiem głów key/value dają FFN o wielkości $3d \times d_{ff} \approx 176$M parametrów na warstwę, wobec około 42M parametrów projekcji attention: około 81% tych wag projekcji, przed uwzględnieniem embeddings i normalizacji.

Połączenia rezydualne dodają wyjście każdego podbloku do jego wejścia: $\text{Output} = \text{Input} + \text{Sublayer}(\text{Input})$. Ścieżka pomijająca poprawia propagację sygnału i gradientu przez głębokie stosy.

RMSNorm jest powszechne w nowoczesnych rodzinach LLM. LayerNorm ponownie centruje przez odjęcie średniej i skaluje przez odchylenie standardowe. RMSNorm pomija odejmowanie średniej i tylko skaluje; artykuł raportuje 7–64% przyspieszenia w testowanych modelach bez pogorszenia wydajności w tych eksperymentach. Powszechne jest również umieszczanie pre-norm, które normalizuje przed attention lub FFN, ponieważ poprawia stabilność gradientów.

Szacowanie liczby parametrów dla modelu decoder-only:

$\text{Total} \approx V \times d + 12 \times L \times d^2$

gdzie $V$ oznacza rozmiar słownika, $d$ wymiar ukryty, a $L$ liczbę warstw. Składnik $V \times d$ to macierz input embedding; składnik $12 \times d^2$ przybliża wagi attention i FFN w każdej warstwie. Dla Llama 3 8B ($V=128{,}256$, $d=4{,}096$, $L=32$) oszacowanie wynosi około $0.53B + 6.44B = 6.97B$ parametrów. Opublikowana wartość 8,03B jest wyższa, ponieważ przybliżenie pomija szczegóły architektury, takie jak dokładna szerokość FFN i osobna projekcja wyjściowa.

19. Modele decoder-only do generowania ogólnego przeznaczenia

Oryginalny Transformer (2017) miał zarówno encoder, jak i decoder. Od tego czasu dziedzina podzieliła się na trzy rodziny architektoniczne, z których jedna stała się domyślna dla generative AI.

Modele encoder-only (BERT, RoBERTa) używają bidirectional attention: każdy token zwraca uwagę na każdy inny token w obu kierunkach. Tworzy to bogate reprezentacje do zadań rozumienia (klasyfikacja, NER, podobieństwo semantyczne), ale nie pozwala autoregresywnie generować tekstu. Modele encoder-only nadal są powszechne jako backbone dla modeli embeddingowych, rerankerów i lekkich klasyfikatorów (np. routerów opartych na BERT w RouteLLM).

Modele encoder-decoder (T5, BART, oryginalny Transformer) oddzielają rozumienie od generowania. Encoder przetwarza całe wejście z bidirectional attention, a następnie decoder generuje wyjście autoregresywnie, korzystając z reprezentacji encodera przez cross-attention. Dawało to naturalną przewagę w zadaniach sequence-to-sequence, takich jak tłumaczenie, gdzie wejście i wyjście są różnymi sekwencjami. T5 firmy Google pokazał, że każde zadanie NLP można sformułować jako text-to-text, a modele encoder-decoder nadal napędzają niektóre wyspecjalizowane systemy (Whisper do rozpoznawania mowy, FLAN-T5 do instruction following).

Modele decoder-only (GPT, Llama, Mistral, Gemini) używają causal attention (unidirectional): każdy token zwraca uwagę tylko na wcześniejsze tokeny. Są powszechne w generowaniu tekstu ogólnego przeznaczenia, ponieważ jeden cel causal language modeling skaluje się na niesparowanym tekście, a podczas inferencji instrukcje, demonstracje few-shot i zapytanie traktuje się jako tokeny jednego prefixu. Powtarzalny blok decodera eliminuje również oddzielny stos encodera i ścieżkę cross-attention. Modele encoder-decoder pozostają użyteczne, gdy zadanie korzysta z osobnego zakodowania wejścia i generowania względem tej reprezentacji, w tym w tłumaczeniu i rozpoznawaniu mowy.

20. Mixture of experts

MoE zastępuje gęsty FFN w każdej warstwie Transformera wieloma mniejszymi expert FFN oraz lekkim gating routerem. Router oblicza wynik dla każdego eksperta (zwykle softmax na wyuczonych projekcjach liniowych) i wybiera top-$k$ ekspertów na token. Obliczenia wykonują tylko aktywowane eksperti, dzięki czemu model może mieć ogromną całkowitą pojemność przy zachowaniu niskiego kosztu na token. To sparse conditional computation: całkowita liczba parametrów określa, co model może reprezentować, a aktywne parametry określają, ile kosztuje jego uruchomienie.

Shared expert w DeepSeek-V3 jest aktywowany dla każdego tokena. Zapewnia bazową reprezentację, na której routed experts mogą się specjalizować.

Trening MoE ma trzy powtarzające się problemy: niezrównoważenie obciążenia, collapse ekspertów i narzut komunikacyjny dla expert parallelism. Tradycyjne modele MoE dodają auxiliary loss karzący niezrównoważony routing, ale ten loss może konkurować z głównym celem. DeepSeek-V3 używa głównie strategii batch-wise bez auxiliary loss: bias terms poza backpropagation obniżają wynik przeciążonych ekspertów i podnoszą wynik ekspertów niewykorzystywanych. Stosuje również niezwykle mały sequence-wise balance loss, aby zapobiegać skrajnemu niezrównoważeniu w obrębie sekwencji. Artykuł raportuje lepsze zrównoważenie routingu bez kompromisu związanego z głównym auxiliary loss w swojej konfiguracji.

21. Tokenizacja: BPE, SentencePiece i tiktoken

LLM nie widzą tekstu. Widzą sekwencje całkowitoliczbowych identyfikatorów tokenów. Tokenizer dzieli surowy tekst na tokeny (fragmenty subword) i mapuje każdy z nich na identyfikator. Wybór tokenizera wpływa na jakość modelu, szybkość inferencji i sprawiedliwość wielojęzyczną.

Byte Pair Encoding (BPE) to powszechny algorytm. Iteracyjnie scala najczęściej występujące sąsiednie pary w korpusie treningowym. Uproszczony przykład:

1. Zacznij od słownika na poziomie znaków: [l, o, w, e, r, _]
2. Najczęstsza para to (l, o) → scal do lo → słownik: [l, o, w, e, r, _, lo]
3. Następna najczęstsza para to (lo, w) → scal do low → słownik rozszerza się o low
4. Kontynuuj, aż słownik osiągnie docelowy rozmiar (np. 128K tokenów)

Typowe słowa, takie jak „the”, stają się pojedynczymi tokenami, natomiast rzadkie słowa, takie jak „defenestration”, są dzielone na fragmenty subword, np. ["def", "en", "est", "ration"]. Kompromis dotyczy rozmiaru słownika i długości sekwencji.

Większość produkcyjnych zastosowań obejmują trzy implementacje tokenizerów:

• SentencePiece trenuje bezpośrednio na surowym tekście Unicode bez pretokenizera zależnego od języka. Zachowuje białe znaki za pomocą symbolu meta ▁ i opcjonalnie może używać tokenów bajtowych UTF-8 jako fallbacku. Obsługuje modele BPE i unigram oraz jest używany przez Llama 1/2, T5 i Mistral.
• tiktoken to tokenizer OpenAI oparty na Rust, wykorzystujący byte-level BPE. W opublikowanym benchmarku GPT-2 działał 3–6x szybciej niż testowana konfiguracja GPT2TokenizerFast. Llama 3 przeszła z SentencePiece na algorytm tiktoken.
• Hugging Face Tokenizers to szeroko używana biblioteka oparta na Rust, obsługująca BPE, WordPiece i Unigram.

Fertility mierzy, ile tokenów tokenizer tworzy na słowo lub inną wybraną jednostkę tekstu. Zależy od dokładnego tokenizera, języka, pisma, normalizacji, domeny i próbki. Mierz ją na reprezentatywnym ruchu, zamiast ekstrapolować z jednego tokenizera lub języka.

22. Okna kontekstu i kodowanie pozycyjne

Okno kontekstu to maksymalna liczba tokenów, które model może przetworzyć w jednym forward pass. Znacznie się zwiększyło:

Unmasked self-attention jest permutation-equivariant: jeśli zmienisz kolejność tokenów wejściowych, wyjścia zmienią kolejność w ten sam sposób. Maska causal decodera już ogranicza każdy token do jego prefixu, dlatego odwrócenie zdania nie daje identycznych stanów ukrytych. Kodowanie pozycyjne dodaje jawną informację o pozycji i względnej odległości w obrębie widocznego prefixu.

Trzy popularne podejścia to:

• RoPE (Rotary Position Embeddings) obraca wektory query i key o zależne od pozycji kąty, dzięki czemu ich iloczyn skalarny zależy od pozycji względnej. Treść tokena nadal określa wynik attention; RoPE dodaje informację o pozycji bez wyuczonych embeddingów pozycji absolutnej. Jest używane przez otwarte rodziny modeli, w tym Llama, Mistral i Qwen.

• ALiBi (Attention with Linear Biases) pomija modyfikowanie embeddingów i dodaje karę bezpośrednio do wyników attention: im dalej od siebie są dwa tokeny, tym większy jest ujemny bias. Nie ma wyuczonych parametrów pozycyjnych. W oryginalnym artykule model 1.3B trenowany na sekwencjach o długości 1024 osiągał przy 2048 tokenach wyniki porównywalne z modelem z pozycjami sinusoidalnymi trenowanym na długości 2048. Zachowanie poza testowanymi modelami i długościami zależy od modelu.

• YaRN (Yet another RoPE extensioN) rozszerza model RoPE poza kontekst treningowy. Grupuje wymiary częstotliwości w trzy kategorie i skaluje każdą z nich inaczej. Artykuł raportuje 10x mniej tokenów fine-tuningu i 2,5x mniej kroków treningowych niż baseline z interpolacją pozycji.

Część V — Trening i alignment

Ta część rozróżnia cel, który tworzy zdolności modelu, techniki pozwalające dopasować trening do dostępnego sprzętu oraz metody kształtujące zachowanie modelu później.

23. Pretraining, fine-tuning i alignment

Pretraining to self-supervised next-token prediction na dużym korpusie. Jego koszt obliczeniowy obejmuje wiele rzędów wielkości; Llama 3 405B używała na przykład $3.8 \times 10^{25}$ FLOPs. Supervised fine-tuning (SFT) dostosowuje pretrained model do oznaczonych danych specyficznych dla zadania. RLHF / RLAIF kształtuje zachowanie za pomocą danych preferencji: klasyczny pipeline RLHF zbiera porównania, trenuje reward model, a następnie optymalizuje policy. RLAIF zastępuje część ludzkich ocen feedbackiem generowanym przez AI.

Koszt obliczeń zależy od rozmiaru modelu, długości sekwencji, ilości danych, optymalizatora i metody. PPO przechowuje również więcej stanu modelu niż SFT, ponieważ typowa konfiguracja obejmuje modele policy, reference, reward i critic. Pełne ramy decyzyjne dotyczące fine-tuningu opisałem w LLM Fine-Tuning Guide.

24. LoRA i QLoRA: parameter-efficient fine-tuning

LoRA zamraża pretrained weights i wstrzykuje trenowalne macierze niskiego rzędu $A$ ($r \times k$) oraz $B$ ($d \times r$), tak aby zaktualizowana waga wynosiła $W_0 + BA$. Artykuł LoRA zredukował liczbę trenowalnych parametrów GPT-3 175B do około 18 milionów w swojej konfiguracji. Rank jest parametrem strojenia, a nie regułą wynikającą ze złożoności zadania; wybierz go za pomocą sweepu jakości i pamięci. Adaptery LoRA można po treningu scalić z wagami bazowymi, aby uniknąć osobnej ścieżki adaptera podczas inferencji.

QLoRA ładuje model bazowy w 4-bitowej kwantyzacji NF4, a adaptery LoRA trenuje w BF16. NormalFloat4 umieszcza więcej poziomów kwantyzacji blisko zera, gdzie gęstość wag jest największa. Artykuł dostrajał model 65B na pojedynczym GPU 48 GB i raportował wyniki zbliżone do baseline’ów 16-bitowych. Kompromisy dotyczące czasu działania i pamięci są specyficzne dla testowanego stosu.

25. Trening z mixed precision

Każdy format zmiennoprzecinkowy rozdziela bity na trzy pola: znak (zawsze 1 bit), wykładnik (ustala zakres dynamiczny) i mantysa (ustala precyzję). Więcej bitów wykładnika oznacza szerszy zakres reprezentowanych wartości; więcej bitów mantysy oznacza dokładniejsze rozróżnianie sąsiednich wartości. Formaty całkowitoliczbowe nie mają wykładnika i reprezentują wyłącznie równomiernie rozmieszczone liczby całkowite w ustalonym zakresie.

BF16 ma ten sam zakres co FP32, ponieważ zakres ustala pole wykładnika, a BF16 zachowuje wszystkie 8 bitów wykładnika z FP32. Rezygnuje za to z części bitów mantysy (7 zamiast 23), wymieniając precyzję na 2-krotną redukcję pamięci i unikając wielu problemów z zakresem występujących w treningu FP16. FP16 ma tylko 5 bitów wykładnika, co ogranicza jego skończony zakres do około 65K. Wiele gradientów jest natomiast zbyt małych dla FP16 i ulega underflow w kierunku zera. Loss scaling mnoży loss przed backpropagation, aby gradienty pozostały reprezentowalne, a następnie skaluje je z powrotem przed krokiem optymalizatora; dynamic scaling zmniejsza współczynnik, jeśli wystąpi overflow. Szerszy zakres wykładnika BF16 zwykle eliminuje tę konieczność.

Formaty całkowitoliczbowe są rzadko używane w głównej arytmetyce treningu, ponieważ backpropagation wymaga szerokiego zakresu dynamicznego. Są za to powszechne w inferencji, gdzie zamrożone wagi można odwzorować na skalibrowane skale. Kwantyzacja wag INT4 zmniejsza model 7B z około 14 GB do 3,5 GB przed narzutem runtime; jakość trzeba zmierzyć dla wybranego modelu i metody.

Trening FP8 na H100 przez Transformer Engine wykorzystuje E4M3 tam, gdzie ważniejsza jest precyzja, i E5M2 tam, gdzie ważniejszy jest zakres. Artykuł FP8-LM raportuje, że jego framework mixed precision trenował GPT-175B 75% szybciej niż baseline BF16 Megatron-LM oraz 37% szybciej niż NVIDIA Transformer Engine w testowanej konfiguracji H100. DeepSeek-V3 użył mixed precision FP8 i raportował około $5,6 miliona kosztu obliczeń w przeliczeniu na wynajem dla końcowego runu treningowego, bez kosztów R&D i infrastruktury.

26. Gradient checkpointing

Każda warstwa forward pass tworzy pośredni wynik zwany aktywacją:

$\text{Input} \rightarrow [\text{Layer 1}] \rightarrow \text{activation}_1 \rightarrow [\text{Layer 2}] \rightarrow \text{activation}_2 \rightarrow [\text{Layer 3}] \rightarrow \text{output}$

Zwykle wszystkie aktywacje muszą pozostać w pamięci, ponieważ backpropagation potrzebuje ich do obliczenia gradientów. W głębokim Transformerze przechowywane aktywacje mogą zajmować więcej pamięci niż same wagi modelu.

Gradient checkpointing wymienia obliczenia na pamięć, odrzucając większość aktywacji i przeliczając je w locie podczas backpropagation. Standardowa strategia (Chen et al., 2016) dzieli sieć złożoną z $n$ warstw na $\sqrt{n}$ równomiernie rozmieszczonych segmentów i zapisuje tylko aktywację graniczną każdego segmentu. Te zapisane granice to „checkpointy”. Wszystkie pośrednie aktywacje w segmencie są natychmiast usuwane.

Gdy backward pass dociera do warstwy wewnątrz segmentu, jej aktywacje są odtwarzane z najbliższego checkpointu. Dla strategii z równomiernym podziałem pamięć zapisana dla aktywacji spada z $O(n)$ do $O(\sqrt{n})$. Rzeczywiste oszczędności pamięci i narzut ponownych obliczeń zależą od modelu, granic checkpointów, długości sekwencji, frameworka i implementacji, dlatego zmierz oba parametry na docelowym runie treningowym. FlashAttention stosuje tę samą zasadę wewnątrz attention, nie materializując pełnej macierzy attention. Włącz ją w HuggingFace za pomocą gradient_checkpointing=True.

27. Etapy DeepSpeed ZeRO

W standardowym data parallelism każde GPU przechowuje pełną kopię wag modelu, gradientów i stanów optymalizatora. Dla Adam każdy parametr zajmuje 2 bajty dla wagi FP16 + 4 bajty dla master weight FP32 + 4 bajty dla momentum + 4 bajty dla wariancji + 2 bajty dla gradientu, czyli 16 bajtów na parametr. Model z 7,5B parametrów potrzebuje ~120 GB na GPU, a każde GPU przechowuje to samo. Na 64 GPU daje to 64 identyczne kopie po 120 GB. Dużo marnotrawstwa.

DeepSpeed ZeRO (Zero Redundancy Optimizer) usuwa tę duplikację, dzieląc te komponenty między GPU zamiast je replikować:

• Stage 1 — partycjonowanie stanów optymalizatora. Każde GPU przechowuje tylko 1/N stanów optymalizatora (master weights FP32 oraz pierwszy i drugi moment Adam, 12 bajtów/parametr). Gdy GPU musi zaktualizować wagę, aktualizuje tylko swój fragment i rozgłasza wynik. Przy poniższych założeniach pamięć spada z ~120 GB do ~41,3 GB na GPU.
• Stage 2 — dodatkowo partycjonowanie gradientów. Gradienty (2 bajty/parametr) nie są już all-reduced do każdego GPU. Każde GPU otrzymuje tylko potrzebny fragment gradientu przez reduce-scatter. Przy tych samych założeniach pamięć spada do ~28,1 GB na GPU.
• Stage 3 — dodatkowo partycjonowanie wag modelu. Każde GPU przechowuje tylko 1/N wag FP16. Przed forward lub backward pass każdej warstwy GPU wywołuje all-gather, aby tymczasowo odtworzyć pełne wagi warstwy z pozostałych GPU, wykonuje obliczenia i usuwa zebrane wagi. Przy tych samych założeniach pamięć spada do ~15,0 GB na GPU.

Są to przybliżone wartości stanu modelu dla modelu 7,5B parametrów na 8 GPU (world size $N=8$), z wagami i gradientami FP16 oraz master weights, momentum i wariancją Adam w FP32. Nie obejmują aktywacji, tymczasowych buforów all-gather, fragmentacji alokatora ani narzutu frameworka/runtime. Granica obliczenia to $7.5B \times$ bajtów na parametr, przy czym każdy stan jest dzielony przez $N$ tylko wtedy, gdy tabela oznacza go jako podzielony.

Kompromisem jest komunikacja. Stage 1 dodaje minimalny narzut, a Stage 2 zastępuje all-reduce reduce-scatter o podobnym koszcie. Stage 3 wymaga wywołań all-gather przed każdą warstwą zarówno w forward, jak i backward pass, czyli około 1,5x większego wolumenu komunikacji niż standardowy data parallelism.

ZeRO-Infinity rozszerza Stage 3, przenosząc podzielone stany do RAM-u CPU, a nawet na dyski NVMe SSD, co może umożliwić trening modeli z bilionami parametrów na ograniczonych klastrach GPU. Offloading do storage dodaje koszt PCIe i transferu danych; jego zmierzony wpływ zależy od dysku, topologii PCIe, partycjonowania, prefetchingu, nakładania transferów i workloadu. Używaj go, aby spełnić wymagania pojemnościowe, a nie zakładaj z góry stałego spowolnienia; profiluj docelową konfigurację.

28. FSDP: shardowanie natywne dla PyTorch

Fully Sharded Data Parallel (FSDP) to wbudowana w PyTorch odpowiedź na DeepSpeed ZeRO-3. Dzieli parametry, gradienty i stany optymalizatora między GPU, wykorzystując tę samą podstawową ideę. Mechanika dla każdej warstwy jest prostą pętlą:

1. All-gather pełnych parametrów ze wszystkich GPU (tymczasowe odtworzenie kompletnej warstwy).
2. Obliczenia forward lub backward pass dla tej warstwy.
3. Natychmiastowe zwolnienie zebranych parametrów. Każde GPU zachowuje tylko własny fragment.
4. Reduce-scatter gradientów, aby każde GPU otrzymało tylko przypisany mu fragment gradientu.

Ponieważ FSDP jest natywne dla PyTorch, integruje się bezpośrednio z narzędziami debugowania PyTorch, profilerami i torch.compile. Wydajność względem DeepSpeed ZeRO-3 zależy od polityki wrappingu, topologii komunikacji, ustawień offloadingu i rozmiaru modelu, dlatego porównuj je na tym samym klastrze.

FSDP2 (2024–2025) to przepisana wersja, która poprawia integrację torch.compile z myślą o lepszym kernel fusion, dodaje obsługę treningu FP8 przez TorchAO i upraszcza API. Zarówno FSDP, jak i DeepSpeed są dostępne przez HuggingFace Accelerate, co pozwala przełączać się między nimi pojedynczą zmianą konfiguracji.

29. Prawa skalowania i pułapka Chinchilli

Skalowanie Chinchilla (DeepMind, 2022) wykazało, że przy jego założeniach alokacja optymalna obliczeniowo znajduje się w pobliżu 20 tokenów treningowych na parametr. Cel ten nie uwzględnia kosztu downstream serving. Jeśli mniejszy model wytrenowany na większej ilości danych osiąga wymaganą jakość, może kosztować mniej w całym cyklu inferencji o dużym wolumenie.

Jedną ze strategii kosztu cyklu życia jest trening mniejszego modelu na znacznie większej ilości danych:

Jest to wyświetlany stosunek tokenów do parametrów podzielony przez przybliżony punkt 20 tokenów na parametr z artykułu Chinchilla. To opisowy stosunek, a nie zmierzona jakość ani mnożnik kosztu.

Dla modelu serwowanego na dużą skalę wydanie większej ilości compute treningowego na mniejszy model może obniżyć koszt cyklu życia. Llama 3 8B ilustruje tę strategię, ale jej opłacalność zależy od wymaganej jakości i prognozowanego wolumenu inferencji. „Chinchilla-optimal” odnosi się do efektywności względem compute treningowego, co jest innym celem niż koszt cyklu życia.

30. RLHF, DPO, GRPO i krajobraz alignment

Alignment kieruje pretrained model w stronę pożądanych instrukcji, preferencji i zasad bezpieczeństwa. Sam w sobie nie gwarantuje prawdziwości ani bezpiecznego zachowania. Poniższe metody wymieniają złożoność implementacji, wymagania dotyczące danych, eksplorację i stabilność treningu.

Klasyczny pipeline RLHF: SFT → zbieranie par ludzkich preferencji → trening reward model na tych parach → fine-tuning policy za pomocą PPO (Proximal Policy Optimization). PPO przechowuje jednocześnie 4 kopie modelu w pamięci (policy, reference, critic/value model, reward model) i jest wrażliwe na hiperparametry. Jest również podatne na reward hacking, gdy model wykorzystuje niedoskonałości reward modelu, np. generując rozwlekłe, brzmiące pewnie odpowiedzi zamiast rzeczywiście poprawiać jakość.

DPO (Direct Preference Optimization) pomija wyuczony reward model i pętlę online RL, optymalizując bezpośrednio loss na parach preferencji. Upraszcza to pipeline treningowy. Standardowe DPO jest offline: trenuje się na stałym zbiorze danych i nie eksploruje nowych odpowiedzi w pętli aktualizacji. To, czy ograniczenie ma znaczenie, zależy od zadania i pokrycia danych.

GRPO (Group Relative Policy Optimization, DeepSeek) usuwa wyuczonego critica PPO, generując wiele completions dla promptu i używając względnych nagród grupowych jako baseline’u. Zmniejsza to obciążenie stanem modelu względem typowej konfiguracji PPO. W przeciwieństwie do DPO GRPO działa on-policy: model generuje świeże odpowiedzi podczas treningu. DeepSeek-R1 łączy GRPO z RLVR (reinforcement learning from verifiable rewards), używając testów takich jak odpowiedzi matematyczne, kompilacja kodu i testy jednostkowe. Takie nagrody łatwiej audytować niż wyuczony score preferencji, ale niepełne testy i cele zastępcze nadal mogą być wykorzystywane.

31. Distillation: kompresowanie wiedzy między modelami

Knowledge distillation przenosi zdolności z dużego teachera do mniejszego studenta. Distillation oparta na logitach uczy studenta dopasowywać rozkład wyjściowy teachera. Distillation oparta na danych polega na generowaniu przez teachera przykładów, na których następnie fine-tunuje się studenta. Metody oparte na danych są powszechne w przypadku LLM, ponieważ mogą działać między architekturami i z teacherami dostępnymi wyłącznie przez API, ale ich wartość ograniczają jakość teachera, pokrycie danych, filtrowanie i koszt generowania.

DeepSeek-R1 przygotował mieszankę około 800 000 przykładów — około 600 000 próbek związanych z rozumowaniem i 200 000 niezwiązanych z rozumowaniem — i użył jej do distillation modeli Qwen2.5 i Llama 3 od 1.5B do 70B parametrów. W ewaluacji artykułu:

• DeepSeek-R1-Distill-Qwen-32B osiąga 72,6% na AIME 2024 i 94,3% na MATH-500, powyżej raportowanych przez artykuł wyników OpenAI o1-mini.
• DeepSeek-R1-Distill-Qwen-7B osiąga 55,5% na AIME 2024, powyżej wyniku QwQ-32B-Preview z artykułu, przy mniejszym modelu.

W eksperymentach DeepSeek-R1 z małymi modelami distillation przewyższyło bezpośrednie GRPO na testowanych modelach bazowych. Wynik wspiera distillation w tej konfiguracji; nie ustanawia uniwersalnego rankingu między distillation i RL.

32. Generowanie danych syntetycznych

Dane treningowe generowane przez LLM są używane w kilku powtarzających się wzorcach:

• Self-Instruct zaczyna od małego zbioru instrukcji napisanych przez ludzi: LLM generuje nowe instrukcje, wejścia i wyjścia, które są filtrowane i dodawane z powrotem do puli. Projekt Alpaca użył 52 000 przykładów wygenerowanych na podstawie 175 seedów. Stanford raportował generowanie danych za $500 and fine-tuning under$100, co dawało początkowy koszt reprodukcji poniżej $600; porównanie z GPT-3.5 było ograniczoną ewaluacją projektu, a nie dowodem szerokiej równoważności.
• Evol-Instruct (WizardLM) bierze istniejące instrukcje i iteracyjnie ewoluuje je wzdłuż osi złożoności (dodawanie ograniczeń, pogłębianie rozumowania, nadawanie problemom większej konkretności), aby tworzyć coraz trudniejsze przykłady treningowe.
• Phi-4 firmy Microsoft (Phi-4) (14B) używał danych syntetycznych w dużej części pretrainingu, w tym generowania, krytyki, samorewizji i odwracania instrukcji. Raport techniczny porównuje uzyskaną wydajność w STEM i kodowaniu z większymi modelami na wybranych benchmarkach.

Ryzykiem istotnym w tym kontekście jest model collapse: gdy modele są rekurencyjnie trenowane na danych syntetycznych pochodzących z poprzednich generacji, ogony oryginalnego rozkładu stopniowo zanikają. Model przecenia typowe wzorce i traci rzadkie, lecz ważne warianty (Shumailov et al., 2024). Osobne badanie klasyfikatora Ahrefs pobrało jedną nowo wykrytą angielską stronę na domenę z 900 000 stron w kwietniu 2025 i sklasyfikowało 74,2% z nich jako zawierające pewien tekst wygenerowany przez AI. To badanie dostawcy nie jest spisem całego internetu. Ograniczanie ryzyka zaczyna się od mieszania danych syntetycznych z rzeczywistymi, filtrowania i śledzenia lineage, aby można było mierzyć materiał generowany rekurencyjnie.

Część VI — Skalowanie i wdrażanie

Gdy workload przestaje mieścić się na jednym urządzeniu lub nie spełnia na nim SLO, trzeba zdecydować, jak podzielić pracę, który runtime udostępnia potrzebne mechanizmy kontrolne oraz czy każde żądanie wymaga tego samego modelu.

33. Cztery formy równoległości

Tensor Parallelism (TP) dzieli poszczególne macierze wag między GPU i zwykle komunikuje się po każdej warstwie. Szybkie połączenia wewnątrz węzła, takie jak NVLink, sprawiają, że jest najbardziej praktyczne w obrębie jednego węzła. Więcej shardów zmniejsza pamięć i obliczenia na urządzenie, ale zwiększa komunikację, dlatego stopień TP dobieraj na podstawie benchmarku opóźnienia.

Pipeline Parallelism (PP) dzieli warstwy sekwencyjnie między GPU, przekazując aktywacje między etapami. Jego wzorzec komunikacji może działać między węzłami, ale bubbles pipeline’u i nierówny czas etapów zmniejszają wykorzystanie. Duże wdrożenia często łączą TP wewnątrz węzła i PP między węzłami.

Data Parallelism (DP) replikuje model servingowy, dzięki czemu każda replika obsługuje niezależne żądania bez komunikacji między replikami dla każdego żądania. Jest efektywne, gdy model się mieści, a ruch można zbalansować. W treningu DP często łączy się z ZeRO lub FSDP w celu shardowania stanu.

Expert Parallelism (EP) rozdziela ekspertów MoE między GPU, używając komunikacji all-to-all do routingu tokenów. Wydajność zależy od równowagi tokenów, rozmieszczenia ekspertów i topologii interconnectu; ruch all-to-all może stać się dominującym wąskim gardłem.

Początkowa heurystyka równoległości:

• Model mieści się na jednym GPU: zacznij od niezależnych replik i zmierz skalowanie DP.
• Model mieści się w jednym węźle: przetestuj TP w obrębie węzła, a następnie replikuj grupę, jeśli wymaga tego ruch.
• Model obejmuje wiele węzłów: przetestuj kombinację TP i PP względem interconnectu i celu opóźnienia.
• Mixture of experts: dodaj EP tylko wtedy, gdy wymaga tego rozmieszczenie ekspertów.

34. Porównanie frameworków servingowych

vLLM zapewnia stronicowaną alokację KV, continuous batching, API kompatybilne z OpenAI i kilka trybów równoległości. Obsługa modeli i sprzętu często się zmienia, dlatego zweryfikuj docelowy model względem aktualnej macierzy kompatybilności.

SGLang łączy RadixAttention do ponownego użycia prefixów, własny scheduler i structured generation. Publikowane zyski przepustowości zależą od workloadu i konfiguracji; porównuj go z vLLM i TensorRT-LLM przy identycznych promptach, wyjściach, sprzęcie i SLO.

TensorRT-LLM celuje w niskie opóźnienie pojedynczego żądania przez fuzję grafów CUDA i optymalizację jąder, z natywną obsługą FP8/FP4. Publikowane liczby są specyficzne dla sprzętu i modelu. Kompromisem jest bardziej stroma krzywa uczenia i powierzchnia wdrożeniowa specyficzna dla NVIDIA.

TGI integruje się z ekosystemem Hugging Face i obsługuje kilka backendów sprzętowych. Przed wyborem do nowego wdrożenia sprawdź aktualny stan utrzymania repozytorium i funkcji.

Ollama kładzie nacisk na prosty lokalny workflow modelu. Używaj go dla wygody podczas developmentu; gdy ważna jest wysoka współbieżność lub jawna kontrola SLO, benchmarkuj inny stos servingowy.

llama.cpp to przenośny runtime C/C++ ze ścieżkami ARM, x86, Metal, CUDA, ROCm i Vulkan. GGUF obsługuje kilka poziomów kwantyzacji. Wydajność znacznie się różni w zależności od modelu, kwantyzacji, kontekstu i backendu, dlatego używaj lokalnego narzędzia benchmarkowego dla docelowej maszyny.

35. Dobór GPU do inferencji

Tabela porównuje opublikowane charakterystyki sprzętu. Obsługa precyzji przez dostawcę nie sprawia, że szczytowe wartości obliczeniowe są bezpośrednio porównywalne między formatami, dlatego najpierw wybieraj na podstawie dopasowania pamięci, a następnie benchmarkuj docelowy workload. Aktualne ceny chmurowe sprawdzaj osobno, ponieważ zależą od dostawcy, regionu, zobowiązań i dostępności.

Najpierw wybieraj według dopasowania pamięci, a następnie według zmierzonej przepustowości przy docelowym opóźnieniu. Pojemność 141 GB H200 może uprościć niektóre wdrożenia dużych modeli, natomiast B200 dodaje obsługę FP4, 180 GB HBM3e i nowszą generację NVLink. Mniejsze GPU oparte na GDDR mogą być ekonomiczne dla modeli kwantyzowanych, gdy ich ograniczenia pamięci i interconnectu pasują do workloadu.

AWQ i GPTQ obsługują modele 4-bitowe, dekwantyzując obsługiwane operacje macierzowe do formatu obliczeniowego takiego jak FP16 lub BF16. Kompatybilność i szybkość nadal zależą od architektury modelu, formatu kwantyzacji, backendu servingowego, jądra i GPU, dlatego sprawdź macierz obsługi backendu i benchmarkuj dokładny artefakt. Hopper (H100/H200) i Ada (L40S/4090) natywnie przyspieszają FP8, a Blackwell (B200) dodaje natywne FP4 Tensor Cores. Wszystkie wymienione GPU obsługują operacje macierzowe INT8.

Decode LLM jest często ograniczony przepustowością pamięci, więc pojemność i przepustowość HBM mogą mieć większe znaczenie niż szczytowe TFLOPS dla workloadów servingowych. Porównuj GPU przy stałych: modelu, precyzji, rozkładzie batcha, długości kontekstu i celu opóźnienia.

36. Cascading modeli i routing

Routing modeli wybiera LLM obsługujący każde zapytanie na podstawie przewidywanej złożoności lub zdolności. RouteLLM (LMSYS/UC Berkeley, ICLR 2025) raportuje 85% redukcji kosztu w swojej konfiguracji MT-Bench przy zachowaniu 95% jakości baseline’u GPT-4. Opłacalność routingu zależy od bieżących cen, miksu ruchu, błędów routera i minimalnego poziomu jakości.

Routery obejmują zarówno lekkie klasyfikatory, jak i sędziów opartych na LLM. Cascading to wariant sekwencyjny: zapytanie zaczyna od tańszego modelu i eskaluje, gdy funkcja scoringowa odrzuci odpowiedź. FrugalGPT raportuje do 98% niższego kosztu lub do 4% wyższej dokładności w ocenianej puli modeli. Produkcyjny cascade potrzebuje skalibrowanych kryteriów eskalacji i monitoringu zapytań, które tani model akceptuje błędnie.

Część VII — Aplikacje

Aplikacje dodają własne powierzchnie awarii. Retrieval może zakończyć się niepowodzeniem przed rozpoczęciem generowania, agenci mogą wybrać nieprawidłową akcję, a zmiana promptu może poprawić jedno zadanie i zepsuć inne.

37. Modele embeddingowe a modele generatywne

Modele embeddingowe kodują tekst do wektorów o stałym wymiarze, które reprezentują znaczenie semantyczne. W przeciwieństwie do modeli generatywnych produkujących sekwencje tokenów zwracają jeden gęsty wektor wejścia, zwykle o kilkuset do kilku tysięcy wymiarów. Ich backbone’y obejmują bidirectional encoder-only transformers i modele wywodzące się z decoderów, dostosowane do uczenia reprezentacji. Warstwa pooling często redukuje reprezentacje per-token do jednego wektora przez mean pooling, specjalny token klasyfikacyjny lub specyficzną dla modelu metodę last-token. Contrastive fine-tuning zbliża następnie teksty semantycznie podobne i oddala od siebie teksty różne.

Obecne systemy embeddingowe odpowiadają różnym potrzebom wdrożeniowym. Qwen3-Embedding-8B obsługuje konfigurowalne wymiary wyjściowe i wiele języków. Gemini Embedding 2 przyjmuje tekst, obrazy, wideo, audio i dokumenty. pplx-embed-v1-4B bada dense embeddings o niższej precyzji. OpenAI text-embedding-3-large obsługuje skrócone embeddingi za pomocą parametru dimensions. To przykłady, a nie ranking: oceń język, modality, zadanie, wymiar i koszt servingowy na jednym zbiorze retrieval.

Matryoshka Representation Learning (MRL, Kusupati et al., NeurIPS 2022) zapewnia elastyczność wymiarów embeddingu. Nazwane na cześć rosyjskich matrioszek, MRL tworzy embedding tak, aby jego pierwsze $m$ wymiarów było równie informatywne jak niezależnie trenowany model o $m$ wymiarach. Podczas treningu MRL agreguje lossy po wybranym $O(\log d)$ zbiorze prefiksowych wymiarów, zwykle będących kolejnymi połowami; przykład 2048-wymiarowy w artykule używa $\{8, 16, \ldots, 1024, 2048\}$. Zagregowany loss wymusza przechowywanie ogólnej informacji semantycznej w początkowych wymiarach, a późniejsze wymiary dodają bardziej szczegółowe informacje.

Po treningu embedding MRL można obciąć do obsługiwanego wymiaru prefixu. OpenAI raportuje, że text-embedding-3-large przy 256 wymiarach przewyższa text-embedding-ada-002 przy 1536 wymiarach w przytoczonym porównaniu MTEB. Daje to 6-krotną redukcję surowego storage wektorów; opóźnienie wyszukiwania i koszt bazy danych zależą również od indeksu, metadanych, filtrowania i sprzętu.

Model embeddingowy jest jednym z ważnych komponentów pipeline’u RAG, obok parsowania, chunkowania, wyszukiwania, rerankingu i generowania. Jeśli istotne dowody nie zostaną znalezione, silniejszy generator nie będzie w stanie niezawodnie ich odzyskać.

38. Architektura RAG w produkcji

Retrieval-Augmented Generation dostarcza LLM dokumenty pobrane w czasie zapytania. Może zapewnić aktualne lub prywatne dowody nieobecne w wagach modelu, ale retrieval nie gwarantuje, że odpowiedź prawidłowo z nich skorzysta. Produkcyjny system RAG to wieloetapowy pipeline, którego etapy wymagają osobnej ewaluacji.

Pipeline ingestii działa offline. Surowe dokumenty (PDF, HTML, Markdown, bazy danych) są najpierw parsowane do czystego tekstu, co jest trudniejsze, niż się wydaje: samo parsowanie PDF może utracić tabele, nagłówki i formatowanie. Następnie tekst dzieli się na chunki, które są osobno embedowane i indeksowane.

Chunking wpływa zarówno na recall retrieval, jak i na kontekst dostępny generatorowi. Użyteczne rozmiary zależą od struktury dokumentu, granularności zapytań, limitów embeddera i rerankera. Typowe podejścia to stały rozmiar z overlapem, rekurencyjne dzielenie według granic dokumentu oraz chunking semantyczny na podstawie podobieństwa embeddingów. Porównuj je na etykietach relewancji na poziomie strony lub sekcji, zamiast uniwersalnie przyjmować jeden zakres tokenów.

Każdy chunk jest następnie embedowany za pomocą modelu, takiego jak modele z Sekcji 37, i przechowywany w wektorowej bazie danych (Pinecone, Weaviate, Qdrant, pgvector itd.).

Pipeline retrieval działa w czasie zapytania. Zacznij od mierzalnego baseline’u, a następnie dodawaj etapy, gdy analiza błędów pokaże, że rozwiązują rzeczywisty problem:

• Hybrid search łączy dense vector retrieval ze sparse retrieval, takim jak BM25, często scalając wyniki przez Reciprocal Rank Fusion (RRF). Dense search obsługuje parafrazy semantyczne, a sparse search wychwytuje dokładne identyfikatory, kody błędów i akronimy. Benchmarki dostawców raportują zyski względem baseline’ów vector-only, ale ich wielkość zależy od korpusu i etykiet relewancji.
• Reranking przekazuje znalezionych kandydatów do modelu, który wspólnie ocenia zapytanie i dokument. Może to poprawić szczegółową relewancję kosztem kolejnego wywołania modelu. Liczbę kandydatów, liczbę zachowanych wyników i opóźnienie należy stroić razem. Pełny wieloetapowy pipeline opisałem w Building a Modern Search Ranking Stack.
• Query transformation przepisuje zapytanie użytkownika przed retrieval, aby poprawić recall. HyDE (Hypothetical Document Embeddings) każe LLM wygenerować hipotetyczną odpowiedź, która jest następnie embedowana i używana do retrieval. Multi-query expansion generuje wiele sformułowań tego samego pytania. Step-back prompting najpierw zadaje pytanie bardziej ogólne, aby pobrać szerszy kontekst.

Typowe tryby awarii:

• Błąd retrieval — poprawny dokument istnieje, ale nie zostaje znaleziony. Testuj chunking, query transformation, hybrid search i filtrowanie metadanych względem konkretnego braku.
• Zatrucie kontekstu — nieistotne znalezione chunki wprowadzają LLM w błąd. Testuj reranking, filtry kontekstu i mniejsze zbiory zachowanych wyników.
• Lost-in-the-middle — w testowanych ustawieniach multi-document question answering i retrieval kluczy-wartości Liu et al. stwierdzili, że wydajność odpowiedzi była zwykle najwyższa, gdy istotna informacja znajdowała się blisko początku lub końca wejścia, a niższa, gdy znajdowała się pośrodku.

GraphRAG (Microsoft, 2024) rozszerza retrieval wektorowy o graf encji i relacji wyekstrahowanych z danych. Celuje w pytania dotyczące całego korpusu i relacji, które płaski retrieval chunków może pomijać. Kompromisem jest dodatkowa praca związana z ekstrakcją, indeksowaniem, storage’em i ewaluacją.

Poradniki praktyczne publikują zakresy opóźnień dla embeddingu, wyszukiwania, rerankingu i generowania, ale wartości te zależą od regionu, korpusu, sprzętu i modelu. Mierz każdy etap w trace’ach i oceń zmianę jakości przed zaakceptowaniem dodatkowego opóźnienia.

39. Architektury agentów i tool calling

Agenci LLM używają modeli do wybierania i porządkowania wywołań narzędzi wokół ewoluującego stanu. Trzy użyteczne wzorce orkiestracji to:

• ReAct — przeplata wybór akcji z obserwacjami. Może dostosowywać się po każdym wyniku narzędzia, ale rosnąca historia zwiększa koszt tokenów i opóźnienie.
• ReWOO — planuje wywołania narzędzi z placeholderami, wykonuje niezależną pracę równolegle, a następnie syntetyzuje wyniki. Artykuł raportuje oszczędność tokenów względem ReAct, ale stały plan wymaga jawnej ścieżki odzyskiwania po awarii narzędzia.
• Planner-executor — oddziela planowanie od wykonania i może dodać politykę ponownego planowania po awarii. Umożliwia specjalizację modeli, ale dodaje stan orkiestracji i kolejną granicę decyzyjną.

Function calling to powszechny mechanizm wywoływania narzędzi. APIs udostępniają definicje narzędzi i zwracają ustrukturyzowane argumenty, ograniczając potrzebę parsowania tekstu swobodnego. Argumenty zgodne ze schematem nadal mogą wybrać nieprawidłowe narzędzie lub zawierać niewłaściwe wartości. Parallel function calling może ograniczyć liczbę round tripów, gdy operacje są niezależne.

Ustrukturyzowane dane wyjściowe i constrained decoding wymuszają schemat przez ograniczenie tokenów dostępnych na każdym kroku generowania. Silniki takie jak xgrammar, używane w vLLM i SGLang, mogą przy niskim narzucie wyeliminować wiele błędów składni i parsowania w obsługiwanych konfiguracjach. Nie gwarantują jednak poprawności wyekstrahowanych wartości ani decyzji. Schema-Guided Reasoning (SGR) wykorzystuje kolejność pól i strukturę schematu, aby stan pośredni był możliwy do inspekcji przed końcową decyzją. Jego trzy wzorce to Cascade (kroki sekwencyjne), Routing (union types jako przełączniki semantyczne) i Cycle (listy o ograniczonym rozmiarze).

Jakość wyboru narzędzi, opóźnienie end-to-end i koszt tokenów zwykle pogarszają się wraz ze wzrostem liczby narzędzi i głębokości akcji. Mierz te krzywe na rzeczywistych opisach narzędzi i rozkładzie awarii. Frameworki takie jak LangGraph mogą uwidaczniać stan i ścieżki odzyskiwania, ale nie usuwają potrzeby ewaluacji.

40. Prompt engineering w produkcji

Prompting produkcyjny to problem ewaluacyjny: zmień jedną część promptu lub kontekstu, a następnie zmierz jakość zadania i tryby awarii. Poniższe techniki są typowymi punktami wyjścia, a nie uniwersalną kolejnością.

Przykłady few-shot często skutecznie kontrolują format wyjścia. Zacznij od 3–5 przykładów obejmujących puste wejścia, niejednoznaczne zapytania i odpowiedzi wieloczęściowe, a następnie zmierz wynik na zbiorze hold-out. Przykłady powinny obejmować rzeczywisty rozkład wejść, a nie tylko ścieżkę happy path. Większa liczba przykładów zużywa kontekst i nie gwarantuje dalszych zysków.

Prompting chain-of-thought (CoT) prosi model o ujawnienie pośredniego rozumowania przed odpowiedzią. Kojima i in. raportowali zyski po dodaniu sufiksu „Let’s think step by step” w testowanych zadaniach rozumowania, ale efekt zależy od modelu, a nowsze reasoning APIs mogą nie udostępniać ukrytych trace’ów. W produkcji preferuj możliwy do inspekcji podział zadania lub zwięzłe uzasadnienie, jeśli jest użyteczne dla ewaluatora. Self-consistency (Wang et al., 2023) próbuje wiele ścieżek rozumowania i agreguje odpowiedzi, wymieniając dodatkowy koszt inferencji na większą odporność w odpowiednich zadaniach.

Ustrukturyzowane dane wyjściowe z jawnymi schematami JSON (Sekcja 39) eliminują wiele błędów parsowania. Silniki constrained decoding, takie jak xgrammar, mogą wymuszać obsługiwaną gramatykę podczas generowania; dokładność faktograficzna i poprawność semantyczna nadal wymagają ewaluacji, a nieobsługiwane funkcje schematu mogą wymagać dodatkowej obsługi.

Prompt chaining dzieli zadanie na skoncentrowane etapy, np. klasyfikuj intencję → pobierz kontekst → wygeneruj odpowiedź → zwaliduj wynik. Może lokalizować awarie, umożliwiać użycie różnych modeli na różnych etapach i ujawniać cache’owalny stan pośredni. Dodaje jednak interfejsy i opóźnienie, dlatego porównuj je z baseline’em pojedynczego wywołania.

Temperature zmienia rozkład samplingu. Niskie wartości są rozsądnym punktem wyjścia dla klasyfikacji lub ekstrakcji; wyższe mogą zwiększyć różnorodność podczas ideacji. Dokładne zachowanie różni się między APIs modeli i wchodzi w interakcję z top_p, top_k oraz domyślnymi ustawieniami dostawcy, dlatego wykonaj sweep obsługiwanych ustawień dla danego zadania, zamiast kopiować jeden zakres.

Rozdzielenie wiadomości systemowych i użytkownika oddziela trwałą politykę od treści konkretnego żądania. Chat templates i instruction tuning nadają tym rolom różne priorytety, ale nie czynią z wiadomości systemowej granicy enforcementu. Umieszczaj stabilne zachowanie w wiadomości systemowej, niezaufane dane trzymaj w treści użytkownika lub narzędzia, a twarde ograniczenia, takie jak usuwanie PII, egzekwuj również poza modelem.

Context engineering rozszerza pracę nad promptem o składanie pobranych dokumentów, wyników narzędzi, historii rozmowy i przykładów. Liu i in. znaleźli efekt lost-in-the-middle w testowanych modelach z długim kontekstem, dlatego pozycja powinna być częścią ewaluacji, a nie być z góry uznawana za nieistotną. Szerszy workflow opisałem w Context Engineering for AI Agents.

Część VIII — Operacje produkcyjne

Operacje produkcyjne zamieniają wcześniejsze pojęcia w limity przyjmowania żądań, testy obciążeniowe, alerty i decyzje dotyczące pojemności przy rzeczywistym ruchu.

41. Rate limiting dla żądań o zmiennym koszcie

Tradycyjne ograniczanie liczby żądań na sekundę zakłada w przybliżeniu równy koszt każdego żądania. LLM łamią to założenie. Prompt klasyfikacyjny z 10 tokenami i analiza dokumentu z 100K tokenów trafiają do tego samego endpointu API, ale różnią się kosztem o cztery rzędy wielkości. Ograniczanie przez RPS albo przepuszcza drogie żądania bez kontroli, albo niepotrzebnie blokuje tanie.

Systemy produkcyjne potrzebują token-based rate limiting w wielu wymiarach. OpenAI dokumentuje limity żądań i tokenów według tieru użycia. Anthropic rozdziela limity input-tokenów i output-tokenów. Dokładne quota i algorytmy mogą się zmieniać, dlatego dokumentację dostawcy traktuj jako źródło prawdy; punkt architektoniczny polega na niezależnym budżetowaniu żądań i tokenów.

Praktyczny wzorzec implementacyjny to wielowymiarowa hierarchia limitów (użytkownik → aplikacja → organizacja → globalnie) z tierami priorytetów dla dostępu premium. Na poziomie żądania kluczowa jest rezerwacja budżetu tokenów: przy admission oszacuj całkowitą liczbę tokenów (wejściowych + max_tokens), odejmij ją z bucketa, a po zakończeniu żądania skoryguj wartość na podstawie rzeczywistego użycia. Zapobiega to sytuacji, w której burst długich żądań generowania wyczerpuje pojemność, zanim żądania zaczną zwracać tokeny.

W przypadku wdrożeń self-hosted odpowiednikiem jest provisioned throughput: rezerwowanie dedykowanej pojemności GPU dla docelowych poziomów tokenów. Dla wdrożeń vLLM oznacza to konfigurację admission control wokół aktywnych slotów decode i presji na KV cache, a nie tylko liczby żądań. Jak wyjaśnia Sekcja 5, przepustowość i admission również wymagają limitów świadomych liczby tokenów.

42. Tryby awarii, na które trzeba się przygotować

Serving LLM dodaje tryby awarii związane ze zmienną długością sekwencji, pamięcią KV i długotrwałą pracą decode. Zaprojektuj i przetestuj obciążeniowo zabezpieczenia, zanim ruch produkcyjny zacznie od nich zależeć.

Out-of-Memory (OOM) to częsta awaria. Model 70B w FP16 potrzebuje około 140 GB tylko na wagi, a KV cache dla pojedynczej sekwencji Llama 3.1 70B z kontekstem 128K może dodać około 40 GB przy założeniach z Sekcji 6. Różnica między „mieści się w pamięci” a „OOM pod obciążeniem” jest mniejsza, niż wygląda, ponieważ batch długich żądań kontekstowych może zużyć więcej pamięci KV, niż oczekiwano. Zapobieganie łączy zmierzoną rezerwę pamięci z kwantyzacją i stronicowaną alokacją KV. W workloadach z wysoką presją na KV LMCache może przenosić dane KV do pamięci CPU lub na dysk; opublikowane wyniki traktuj jako punkt wyjścia i benchmarkuj lokalną hierarchię pamięci.

Preempcja występuje, gdy presja na KV cache zmusza scheduler do eksmitowania lub ponownego obliczania pracy. Dokładna strategia zależy od wersji i konfiguracji servingowej. Z perspektywy użytkownika objawem jest wyższe opóźnienie end-to-end bez oczywistego błędu aplikacji. Obserwuj liczbę preempcji i koreluj ją z użyciem KV, głębokością kolejki i długościami żądań.

Opóźnienie ogona może gwałtownie rosnąć, gdy duże prefille opóźniają pracę decode. Chunked prefill (Sekcja 7) i scheduling świadomy długości celują w tę interferencję. Artykuły Learning-to-Rank scheduler i CascadeInfer raportują poprawę względem swoich baseline’ów w testowanych workloadach, ale dokładny wynik zależy od rozkładu długości żądań i konfiguracji schedulera.

Awarie kaskadowe mogą rozpocząć się, gdy wolne żądania wydłużają kolejkę, klienci upstream przekraczają timeouty, a retry dodają jeszcze większe obciążenie. Zabezpieczenia obejmują admission control, limity współbieżności per tenant, limity wyjścia, budżety retry i circuit breakery na gatewayu. Rozdzielone pule prefill i decode mogą pomóc, gdy testy obciążeniowe pokażą trwałą interferencję faz.

43. Monitoring systemów LLM

Monitoring LLM różni się od tradycyjnego monitoringu API na kilka podstawowych sposobów. Każde żądanie ma zmienny koszt, dwie odrębne fazy z różnymi wąskimi gardłami oraz footprint pamięci zależny zarówno od długości wejścia, jak i generowania. Standardowe metryki, takie jak opóźnienie żądania i error rate, pomijają większość istotnych informacji.

Goodput to liczba żądań na sekundę spełniających wszystkie zdefiniowane progi SLO, takie jak TTFT, TPOT i całkowite opóźnienie. Jest użyteczną miarą łączną, ponieważ surowa przepustowość może wyglądać dobrze, gdy SLO opóźnienia są niespełnione: system przetwarzający 100 żądań na sekundę, ale niespełniający progów dla 40% z nich, ma goodput równy 60 żądań na sekundę. Optymalizacja pod goodput zachowuje widoczność rozkładu wydajności zamiast raportowania wyłącznie średniej.

vLLM udostępnia endpoint Prometheus pod adresem /metrics z informacjami o wykonywanych i oczekujących żądaniach, użyciu KV cache, rozkładach długości generowania i statystykach prefix cache. Nazwy metryk mogą zmieniać się między wydaniami, dlatego powiąż dashboardy z wdrożoną wersją. Typowy stos używa Prometheus do metryk, Grafany do wizualizacji oraz trace’ów zgodnych z OpenTelemetry między komponentami aplikacji i serving.

Przydatne wzorce alertów obejmują poniższe przypadki. Progi wyprowadź z testów obciążeniowych, zamiast bezpośrednio kopiować te przykłady:

• Skok liczby preempcji — runtime zamienia lub ponownie oblicza pracę, co zwiększa opóźnienie bez błędu aplikacji.
• Wykorzystanie KV cache zbliża się do przetestowanego obszaru preempcji — dodaj pojemność lub ogranicz obciążenie, zanim eksmisje uruchomią lawinę.
• Głębokość kolejki stale przekracza przetestowany envelope batcha — admission control powinien zacząć odrzucać lub obniżać priorytet.
• TTFT rośnie, podczas gdy TPOT pozostaje płaskie — ta rozbieżność wskazuje najpierw na kolejkowanie, admission, sieć lub presję prefill, a nie na przepustowość decode. Użyj trace’ów i metryk kolejki, aby je rozróżnić.

44. Optymalizacja kosztu: strategia kumulacyjna

Ceny dostawców i proporcje cen input-output zmieniają się. Przed decyzją zakupową pobierz aktualne stawki; tier modelu i długość wyjścia mogą dominować rachunek jeszcze przed optymalizacjami infrastruktury.

Kilka podejść można łączyć, ale dopiero po zmierzeniu, które dotyczą danego workloadu:

1. Kwantyzacja z FP16 do INT4 zmniejsza pamięć wag o 75%. To, czy obniży rachunek, zależy od szybkości jądra, rozmiaru batcha i wykorzystania sprzętu (Sekcja 9).
2. Routing modeli kieruje kwalifikujący się ruch do tańszych modeli. Zmierz false-accept rate routera i jakość end-to-end, zanim zwiększysz udział ruchu obsługiwanego przez tańszy model (Sekcja 36).
3. Prompt caching ogranicza pracę dla powtarzających się prefixów. Rabaty dostawców i sposób traktowania rate limitów zmieniają się z czasem, dlatego połącz zmierzony hit rate z aktualnymi warunkami (Sekcja 16).
4. Batch APIs mogą obniżać koszt pracy niewymagającej czasu rzeczywistego, takiej jak ewaluacje, generowanie danych syntetycznych i klasyfikacja zbiorcza. Sprawdź aktualne ceny i okna realizacji.
5. Self-hosting może wygrywać przy stałym wykorzystaniu, ale nie ma uniwersalnego progu rentowności względem wolumenu tokenów. Uwzględnij engineering, orkiestrację, obserwowalność, zapas pojemności i koszty on-call oprócz wynajmu GPU.

Pomnożenie przykładowych czynników daje dużą teoretyczną redukcję, ale dane wejściowe nie są niezależne: kwantyzacja zmienia przepustowość, routing zmienia miks jakości, a caching i batching dotyczą tylko kwalifikującego się ruchu. Zbuduj estymację z pomierzonych udziałów ruchu i zweryfikuj ją względem faktury.

45. Planowanie pojemności i autoscaling

Planowanie pojemności dla serving LLM musi uwzględniać zmienny koszt żądań, długotrwałą pracę decode i pamięć zależną od sekwencji. W zależności od workloadu ograniczeniem może być pamięć KV, przepustowość pamięci, compute lub interconnect.

Teoretyczny limit pamięci dla współbieżnych żądań wynika z budżetu KV cache:

$\text{max concurrent sequences} = \frac{\text{GPU memory} - \text{model weights} - \text{overhead}}{\text{per-sequence KV cache size}}$

Załóżmy na potrzeby obliczeń pojemności, że runtime udostępnia budżet KV wynoszący 40 GiB dla Llama 3.1 70B z KV cache w FP16. Każda sekwencja 4K zużywa około 1,25 GiB, a sekwencja 128K około 40 GiB. Budżet ten mieści zatem najwyżej około 32 sekwencje 4K lub jedną sekwencję 128K przed uwzględnieniem alokatora, runtime, zmienności workloadu i narzutu SLO. Dlatego dobór GPU i optymalizacja KV cache bezpośrednio wpływają na plan pojemności.

Wzór na rozmiar floty:

$\text{required GPUs} = \frac{\text{peak tokens/s} \times \text{safety-factor multiplier}}{\text{per-GPU tokens/s at target SLO}}$

Przed dzieleniem przelicz obie stawki na tę samą jednostkę czasu. Kluczowe jest „przy docelowym SLO”. Mnożnik safety factor, np. 1,3, rezerwuje 30% headroomu; wybierz go na podstawie zmierzonej burstowości, awarii i czasu odtwarzania. Szczytowa przepustowość tokenów i przepustowość zgodna z SLO mogą znacznie się różnić wraz ze wzrostem współbieżności. Benchmarkuj rzeczywisty rozkład długości promptów i wyjść przy wymaganych progach TTFT i TPOT, zamiast używać teoretycznego maksimum.

Wykorzystanie GPU jest niewystarczającym jedynym sygnałem autoscalingu, ponieważ może pozostawać wysokie zarówno podczas zdrowego przetwarzania, jak i przeciążenia. Połącz je z głębokością kolejki, wykorzystaniem KV cache i pogorszeniem goodputu. Progi dostrajaj na podstawie testów obciążeniowych; wartości takie jak 80% wykorzystania KV są punktami wyjścia, a nie uniwersalnymi limitami. Metryki te wprowadzono w Sekcji 43.

Scale-to-zero może pasować do środowisk development i staging z długimi okresami bezczynności. Serverless inference platforms i autoscalery oparte na Kubernetes, takie jak KEDA, mogą usuwać nieużywaną pojemność, ale oszczędności i czas cold startu zależą od rozmiaru modelu, cache’owania obrazu i wag oraz infrastruktury. Zmierz czas uruchomienia przed użyciem tej samej polityki dla wrażliwego na opóźnienie ruchu produkcyjnego.

Użyj przewodnika, aby wybrać kolejny pomiar

Pojęcia oddziałują na siebie, ale nadal prowadzą do niewielkiego zestawu użytecznych pierwszych pomiarów. Zapotrzebowanie na KV cache ogranicza rozmiar batcha obok pamięci wag, narzutu runtime i długości żądań. Większe batche mogą podnosić intensity arytmetyczną, podczas gdy continuous batching zwiększa churn alokacji KV, a PagedAttention zmniejsza wynikającą z tego fragmentację.

Po stronie treningu koszt cyklu życia może przemawiać za trenowaniem mniejszego modelu na większej liczbie tokenów, jak ilustruje Llama 3 8B. GRPO zmniejsza obciążenie stanem critica względem PPO. W testowanej przez DeepSeek-R1 konfiguracji małego modelu distillation przewyższyło bezpośrednie RL. To opcje do ewaluacji, a nie gotowa recepta.

Routing, caching, kwantyzacja i wybór sprzętu kumulują się tylko wtedy, gdy każda technika jest oceniana względem tego samego celu jakości i opóźnienia. Wybierz jeden objaw, ustal baseline i wprowadź kolejną zmianę tak, aby łatwo można było ją wycofać.

Dalsza lektura

Powiązane pogłębione artykuły z tego bloga, uporządkowane tematycznie:

• LLM Fine-Tuning Guide — kiedy wybrać fine-tuning, RAG lub prompt engineering
• Open-Source LLM Variants and File Formats — dopasowanie wariantów modeli i formatów kwantyzowanych do sprzętu
• LoRAX Serving Guide — serving tysięcy adapterów LoRA w produkcji
• Scaling Large Language Models — strategie multi-GPU i multi-node
• Local LLMs on macOS — praktyczna konfiguracja z llama.cpp i Ollama
• AI Agent Reasoning Loops in 2026 — pogłębienie ReAct, ReWOO i pętli planner-executor
• AI Agent Memory Architecture in 2026 — checkpointy, vector stores i pamięć dokumentowa dla agentów ze stanem

Referencje

Uporządkowane według obszaru tematycznego.

Inferencja i attention

• FlashAttention: Fast and Memory-Efficient Exact Attention with IO-Awareness - Dao et al., NeurIPS 2022
• FlashAttention-2: Faster Attention with Better Parallelism and Work Partitioning - Dao, 2023
• FlashAttention-3: Fast and Accurate Attention with Asynchrony and Low-precision - Shah et al., NeurIPS 2024
• Flash-Decoding for long-context inference - Dao et al., 2023
• Efficient Memory Management for Large Language Model Serving with PagedAttention - Kwon et al., SOSP 2023
• Orca: A Distributed Serving System for Transformer-Based Generative Models - Yu et al., OSDI 2022
• GQA: Training Generalized Multi-Query Attention - Ainslie et al., 2023
• Triton: an intermediate language and compiler for neural network computations - Tillet et al., MAPL 2019
• FlashNorm: Fast Normalization for LLMs - 2024
• Deep Kernel Fusion for Transformers - DeepFusionKernel, 2026

Speculative decoding

• Accelerating Large Language Model Decoding with Speculative Sampling - Chen et al., 2023
• EAGLE-3: Scaling up Inference Acceleration of Large Language Models - Li et al., NeurIPS 2025
• Medusa: Simple LLM Inference Acceleration Framework with Multiple Decoding Heads - ICML 2024

Kwantyzacja

• AWQ: Activation-aware Weight Quantization for LLM Compression and Acceleration - MLSys 2024 Best Paper
• GPTQ: Accurate Post-Training Quantization for Generative Pre-trained Transformers - Frantar et al., ICLR 2023
• Marlin: Mixed-Precision (FP16xINT4) LLM Inference Kernel - Frantar et al., 2024

Trening i fine-tuning

• LoRA: Low-Rank Adaptation of Large Language Models - Hu et al., ICLR 2022
• QLoRA: Efficient Finetuning of Quantized LLMs - Dettmers et al., NeurIPS 2023
• ZeRO: Memory Optimizations Toward Training Trillion Parameter Models - Rajbhandari et al., SC20
• ZeRO-Infinity: Breaking the GPU Memory Wall for Extreme Scale Deep Learning - Rajbhandari et al., 2021
• Self-Instruct: Aligning Language Models with Self-Generated Instructions - Wang et al., ACL 2023
• WizardLM: Empowering Large Language Models to Follow Complex Instructions - Xu et al., ICLR 2024
• Phi-4 Technical Report - Microsoft, 2024
• AI models collapse when trained on recursively generated data - Shumailov et al., Nature 2024

Alignment

• Direct Preference Optimization: Your Language Model is Secretly a Reward Model - Rafailov et al., NeurIPS 2023
• DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models - Wprowadzono GRPO
• DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning - DeepSeek, 2025

Skalowanie i architektura

• The Llama 3 Herd of Models - Meta, 2024
• LLaMA: Open and Efficient Foundation Language Models - Touvron et al. (Meta), 2023
• Llama 2: Open Foundation and Fine-Tuned Chat Models - Touvron et al. (Meta), 2023
• Qwen3 Technical Report - Qwen Team (Alibaba), 2025
• Training Compute-Optimal Large Language Models - Hoffmann et al. (Chinchilla), NeurIPS 2022
• RoFormer: Enhanced Transformer with Rotary Position Embedding - Su et al., 2021
• YaRN: Efficient Context Window Extension of Large Language Models - Peng et al., ICLR 2024
• SGLang: Efficient Execution of Structured Language Model Programs - Zheng et al., NeurIPS 2024
• Mixtral of Experts - Jiang et al. (Mistral AI), 2024

Embeddings

• Matryoshka Representation Learning - Kusupati et al., NeurIPS 2022
• pplx-embed-v1: Diffusion-Pretrained Dense and Contextual Embeddings - Perplexity AI, 2026

Architektury agentów

• ReAct: Synergizing Reasoning and Acting in Language Models - Yao et al., ICLR 2023
• ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models - Xu et al., 2023

Routing

• RouteLLM: Learning to Route LLMs with Preference Data - Ong et al., ICLR 2025

Benchmarki

• MLPerf Inference v5.0 Results - MLCommons, kwiecień 2025

Architektury servingowe

• Taming Throughput-Latency Tradeoff in LLM Inference with Sarathi-Serve - Agrawal et al., OSDI 2024 (Chunked prefill)
• Splitwise: Efficient Generative LLM Inference Using Phase Splitting - Patel et al., ISCA 2024 (Disaggregated Serving)
• DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving - Zhong et al., OSDI 2024 (Disaggregated Serving)

Frameworki servingowe

• vLLM - Silnik servingowy oparty na PagedAttention
• SGLang - RadixAttention i structured generation
• TensorRT-LLM - Zoptymalizowana inferencja NVIDIA
• llama.cpp - Przenośna inferencja C/C++
• DeepSpeed - Biblioteka Microsoft do treningu rozproszonego
• Ollama - Lokalny runner LLM

Operacje

• Efficient LLM Scheduling by Learning to Rank - Fu et al., NeurIPS 2024 (vLLM-LTR)
• CascadeInfer: Length-Aware Scheduling of LLM Serving with Low Latency and Load Balancing - Yuan et al., 2025
• Goodput metric as measure of ML productivity - Google Cloud, 2024
• vLLM Optimization and Tuning - Dokumentacja vLLM
• vLLM Metrics - Dokumentacja vLLM
• LMCache: KV Cache Management for LLM Serving - Offloading KV cache
• OpenAI Rate Limits - Dokumentacja OpenAI API
• Anthropic Rate Limits - Dokumentacja Anthropic API