English· Español· Deutsch· Nederlands· Français· 日本語· ქართული· 繁體中文· 简体中文· Português· Русский· العربية· हिन्दी· Italiano· 한국어· Polski· Svenska· Türkçe· Українська· Tiếng Việt· Bahasa Indonesia

un

gast
1 / ?
terug naar lessen

Teken, Exponent, Mantisse

IEEE 754 Floating-Point Formaat

Elk floating-point getal slaat drie velden op:


- Tekenbit (1 bit): positief of negatief

- Exponent (E bits): de schaal van de grootte, een geheel getal macht van 2

- Mantissa (M bits): de fractionele precisie, een getal tussen 1.0 & ~2.0


Totaal aantal bits = 1 + E + M. De waarde is ongeveer (-1)^sign (1 + mantissa) 2^(exponent - bias).


Twee eigenschappen zijn belangrijk voor training:


Dynamisch bereik = 2^(2^E) (ongeveer). Meer exponent bits betekent het kunnen vertegenwoordigen van kleinere & grotere getallen zonder overflow.


Precisie = 2^M verschillende waarden per macht van 2. Meer mantisse-bits betekent een fijnere representatie tussen opeenvolgende machten van 2.


De Drie Format


FormatTotaal bitsTekenExpMantDynamisch bereikPrecisie
FP32321823~10^-38 tot ~10^38~7 cijfers
FP16161510~10^-5 tot ~10^5~3 cijfers
FP8 E4M38143~2^-9 tot ~448~2 cijfers

FP8 E4M3 betekent "4 exponentbits, 3 mantissabits". Een alternatieve FP8 E5M2 ruilt precisie voor bereik; ANDREA-experimenten gebruiken E4M3 omdat transformeractivaties in smalle magnitudebanden blijven waar extra precisie wint van extra bereik.

Bytes Per Parameter

ANDREA-120M bevat ongeveer 120.000.000 parameters. Bereken de opslagruimte van alleen de gewichtsmatrices in (a) FP32, (b) FP16, (c) FP8. Toon je berekening in MB. Bereken vervolgens (d) de opslagruimte met gewicht + Adam eerste moment + Adam tweede moment (3x het gewichtsaantal) in FP16.

Waarom Lagere Precisie Sneller Draait

Geheugenbandbreedte Domineert Trainingsnelheid

Moderne GPU's brengen meer tijd door met wachten op geheugen dan met berekenen. De RTX 4090 heeft 1008 GB/s geheugenbandbreedte & 165 TFLOPS FP16-rekenkracht. Een typische laag leest gewichten uit VRAM, vermenigvuldigt activaties, schrijft resultaten terug. Bandbreedte, niet rekenkracht, bepaalt de doorvoer.


Het halveren van de precisie halveert bytes per parameter, dus het lezen van dezelfde gewichten gebruikt helft van de geheugenbandbreedte. Doorvoer verdubbelt ruwweg.


Tensor Cores: Hardwareversnelde Matrixvermenigvuldiging

De RTX 4090 heeft speciale tensor core-eenheden die matrixvermenigvuldigingen op FP16 of FP8 direct berekenen. Een enkele tensor core-operatie vermenigvuldigt een klein blok (bijv. 16x16) in één cyclus, veel sneller dan scalaire FP32-vermenigvuldigingen.


Empirische cijfers van ANDREA-120M:


PrecisieStappen/minOpmerkingen
FP32~3basislijn; geen tensor core-versnelling
FP16~6cuBLAS tensor cores; 2x speedup
FP8 E4M3~6tensor cores; vergelijkbaar met FP16

FP8 versloeg FP16 niet in doorvoer bij deze werklast omdat de rekenkrachtdoorvoer niet langer de bottleneck was; geheugenbandbreedte & lanceeroverhead werden limiterend. ANDREA-120M v3 wordt geleverd op FP16 cuBLAS met 6 stappen/min voor een comfortabele veiligheidsmarge zonder doorvoer te verliezen.


NaN-risico bij FP8

FP8 E4M3 vertegenwoordigt getallen van ~2^-9 tot ~448. Activaties of gradiënten buiten dat bereik overlopen naar NaN (not a number) of onderlopen naar nul. Een enkele NaN vergiftigt elke downstream berekening: matrixvermenigvuldigingen met een NaN geven all-NaN terug; all-NaN gradiënten corrumperen AdamW-staat; AdamW met NaN m & v geeft NaN-updates; gewichten worden NaN; de gehele training run sterft.


De FP8-experimenten van ANDREA produceerden occasionele NaN-kliffen die loss scaling, geplande precisie-wisselingen of fallback-paden vereisten. Het dynamische bereik van FP16 (~10^-5 tot ~10^5) is breed genoeg dat NaN-gebeurtenissen zeldzaam blijven zonder ingewikkelde scaling-trucs.


Precisie Vergelijking: FP32 vs FP16 vs FP8

Precisie Kiezen voor een Nieuwe Run

Je start een nieuwe ANDREA-stijl training run op een RTX 4090. Je hebt twee conflicterende prioriteiten: (1) maximaliseer steps/min, (2) vermijd debuggen van NaN-crashes midden in de training. ANDREA-120M v3 koos FP16 cuBLAS boven FP8 E4M3 ondanks dat beide op ~6 steps/min draaien. Redeneer waarom FP16 deze beslissing won. Verwijs naar dynamisch bereik EN tensor core-ondersteuning in je antwoord.

120M passen op een enkele 4090

De 6-8x Vermenigvuldiger uit de Introles

Herinner je van grow_a_language_model_intro dat trainingsgeheugen ruwweg 6-8x het rauwe gewichtenaantal bedraagt, rekening houdend met:


- Gewicht (1x)

- Adam eerste moment m (1x)

- Adam tweede moment v (1x)

- Gradient buffer (1x)

- Activaties & tijdelijke waarden (~2-4x, afhankelijk van batch & context)


ANDREA-120M op FP16 met batch_size=8, context=1024:


ComponentFP16 grootte
Weights240 MB
m (eerste moment)240 MB
v (tweede moment)240 MB
Gradienten240 MB
Activaties~2-4 GB (batch, ctx)
Totaal~3.5 GB

RTX 4090 heeft 24 GB VRAM. ANDREA-120M gebruikt ~14% bij FP16. Ruim voldoende voor grotere batch-groottes of langere contextvensters. ANDREA-12M gebruikte slechts 1.4 GB totaal.


Waar Mixed Precision Thuis Is

ANDREA houdt NIET alles op één precisie. Mixed-precision training slaat op:


- Master weights: FP32 (behoudt trainingsstabiliteit)

- Forward & backward compute: FP16 (gebruikt tensor cores)

- AdamW optimizer state: FP32 (m & v hebben precisie nodig voor long-tail updates)

- Gradient buffer: FP16 (compute side)


De uiteindelijke geheugenbudget mixt beide. ANDREA's werkelijke footprint zit tussen pure FP16 (720 MB optimizer state) & pure FP32 (1.44 GB optimizer state), dichter bij FP32 omdat m & v in FP32 blijven.

Een Budget Opstellen voor ANDREA-480M

ANDREA-480M (het geplande derde lid van de familie) heeft ~480 miljoen parameters. Schat (a) alleen FP16 gewichten in MB, (b) FP16 gewichten + m + v in MB (neem aan dat m & v ook FP16 zijn voor eenvoud), & (c) gegeven de vuistregel van 6-8x multiplier, totale training-time footprint bij FP16. Past ANDREA-480M op een enkele RTX 4090 (24 GB)?

Precisie in de Praktijk

Stel je voor dat je midden in de training ontdekt dat ANDREA-120M af en toe NaN-verliezen produceert elke ~5000 stappen bij FP16, & elk NaN een herstart vanaf een checkpoint vereist. Welke ÉÉN wijziging zou je als eerste proberen om de NaN-frequentie te verminderen zonder FP16 te verlaten? Rechtvaardig met een zin over het mechanisme.

Aangrenzende Activiteiten

Drie broers/zussen linken aan precisie:


- Activiteit 1: Intro / VRAM-budget. Precisie vermenigvuldigt elke term in de geheugenbudget-aritmetiek. De vuistregel van 6-8x vermenigvuldiger is eenheidloos; bytes-per-param geeft het eenheden.

- Activiteit 10: AdamW. Optimalisatorstatus (m & v) blijft typisch op FP32, zelfs wanneer forward/backward berekeningen op FP16 draaien. Reden: precisie van de long-tail accumulator is belangrijker dan runtime-snelheid voor de optimalisator.

- Activiteit 12: Gradient clipping. Clipping beperkt de grootte van gradiënten vóór optimalisatorstatusupdates. Met FP16 forward/backward & FP32 optimalisator vindt clipping plaats op de grens waar precisie verandert & waar overflow-risico zich concentreert.


Precisie is een gratis knop: verander het, het model traint sneller & gebruikt minder geheugen. De kosten zijn numerieke zorg: NaN-behandeling, loss scaling, mixed-precision discipline. ANDREA-120M v3 demonstreert het rendement: 120M parameters getraind op consumentenhardware in 23 dagen omdat FP16 alles halveerde.