Īsa atbilde: Lai optimizētu mākslīgā intelekta modeļus, izvēlieties vienu primāro ierobežojumu (latentumu, izmaksas, atmiņu, kvalitāti, stabilitāti vai caurlaidspēju) un pēc tam pirms jebkādu izmaiņu veikšanas nosakiet uzticamu bāzes līniju. Vispirms noņemiet cauruļvada sastrēgumus, pēc tam izmantojiet zema riska ieguvumus, piemēram, jauktu precizitāti un partijveida apstrādi; ja kvalitāte saglabājas, pārejiet uz kompilatora/izpildlaika rīkiem un tikai pēc tam samaziniet modeļa lielumu, izmantojot kvantizāciju vai destilāciju, kad tas nepieciešams.
Galvenie secinājumi:
Ierobežojums : Izvēlieties vienu vai divus mērķa rādītājus; optimizācija ir kompromisu, nevis bezmaksas uzvaru ainava.
Mērīšana : Izveidojiet reālu darba slodžu profilu, izmantojot p50/p95/p99, caurlaidspēju, noslodzi un atmiņas maksimumus.
Cauruļvads : pirms modeļa apstrādes izlabojiet tokenizāciju, datu ielādētājus, priekšapstrādi un partijveida apstrādi.
Apkalpošana : Izmantojiet kešatmiņu, apzinātu partijveida apstrādi, vienlaicības regulēšanu un rūpīgi sekojiet līdzi astes latentumam.
Aizsargbarjeras : Pēc katrām veiktspējas izmaiņām palaidiet zelta norādījumus, uzdevumu metrikas un veiciet pārbaudes.
🔗 Kā efektīvi novērtēt mākslīgā intelekta modeļus.
Galvenie kritēriji un soļi, lai modeļus novērtētu taisnīgi un droši.
🔗 Kā izmērīt mākslīgā intelekta veiktspēju ar reāliem rādītājiem.
Salīdzināšanai izmantojiet etalonus, latentumu, izmaksas un kvalitātes signālus.
🔗 Kā pārbaudīt mākslīgā intelekta modeļus pirms to izstrādes.
Praktiska testēšanas darbplūsma: datu sadalīšana, stresa gadījumi un uzraudzība.
🔗 Kā izmantot mākslīgo intelektu satura veidošanai.
Ātrāk pārvērtiet idejas melnrakstos, izmantojot strukturētas uzvednes un iterāciju.
1) Ko praksē nozīmē “Optimizēt” (jo visi to lieto atšķirīgi) 🧠
Kad cilvēki saka “optimizēt mākslīgā intelekta modeli”, viņi varētu domāt:
-
Padarīt to ātrāku (mazāks latentums)
-
Padarīt to lētāku (mazāk GPU stundu, mazāki mākoņpakalpojumu izdevumi)
-
Samaziniet to (atmiņas aizņemtība, perifērijas izvietošana)
-
Padarīt to precīzāku (kvalitātes uzlabojumi, mazāk halucināciju)
-
Padarīt to stabilāku (mazāka dispersija, mazāk kļūmju ražošanā)
-
Atvieglot apkalpošanu (caurlaidspēja, partijveida apstrāde, paredzama veiktspēja)
Lūk, nedaudz kaitinoša patiesība: jūs nevarat maksimāli palielināt visus šos parametrus vienlaikus. Optimizācija ir kā balona saspiešana — iespiež vienu pusi uz iekšu, un otra puse izlec ārā. Ne vienmēr, bet pietiekami bieži, lai jums būtu jāplāno kompromisi.
Tāpēc, pirms pieskaraties jebkam, izvēlieties savu galveno ierobežojumu :
-
Ja apkalpojat lietotājus tiešraidē, jums rūp p95 latentums ( AWS CloudWatch procentiles ) un astes veiktspēja ( “astes latentuma” labākā prakse ) 📉
-
Ja jūs apmācāt, jums rūp laiks, kas nepieciešams kvalitatīvas apstrādes iegūšanai, un GPU noslodze 🔥
-
Ja veicat izvietošanu ierīcēs, jums rūp RAM un jauda 🔋
2) Kā izskatās laba mākslīgā intelekta modeļu optimizācijas versija ✅
Laba optimizācijas versija nav tikai "pielietot kvantizāciju un lūgties". Tā ir sistēma. Labākajām konfigurācijām parasti ir:
-
Uzticams pamats.
Ja nevarat atkārtot pašreizējos rezultātus, nevarat zināt, ka esat kaut ko uzlabojis. Vienkārši… bet cilvēki to izlaiž. Tad viņi iet spirālē. -
Skaidrs mērķa rādītājs
“Ātrāk” ir neskaidrs. “Samazināt p95 latentumu no 900 ms līdz 300 ms, saglabājot tādu pašu kvalitātes rādītāju” ir reāls mērķis. -
Kvalitātes aizsargbarjeras
Katrs snieguma uzlabojums riskē ar klusu kvalitātes regresiju. Jums ir nepieciešami testi, novērtējumi vai vismaz veselo saprātu apliecinošs komplekts. -
Aparatūras izpratne
“Ātrs” modelis vienā GPU var pārmeklēt citā. CPU ir savs īpaša veida haoss. -
Iteratīvas izmaiņas, nevis strauja pārrakstīšana.
Kad maināt piecas lietas vienlaikus un veiktspēja uzlabojas, jūs nezināt, kāpēc. Kas ir… satraucoši.
Optimizācijai vajadzētu justies kā ģitāras skaņošanai — nelielas korekcijas, uzmanīgi klausieties, atkārtojiet 🎸. Ja tā ir kā žonglēšana ar nažiem, kaut kas nav kārtībā.
3) Salīdzināšanas tabula: populāras iespējas mākslīgā intelekta modeļu optimizēšanai 📊
Zemāk ir sniegta ātra un nedaudz nekārtīga izplatītāko optimizācijas rīku/pieeju salīdzināšanas tabula. Nē, tā nav pilnīgi “taisnīga” — arī reālā dzīve tāda nav.
| Rīks/opcija | Auditorija | Cena | Kāpēc tas darbojas |
|---|---|---|---|
PyTorch torch.compile ( PyTorch dokumentācija ) |
PyTorch ļaudis | Bezmaksas | Grafu uztveršana + kompilatora triki var samazināt papildu izmaksas… dažreiz tā ir maģija ✨ |
| ONNX izpildlaiks ( ONNX izpildlaika dokumentācija ) | Izvietošanas komandas | Brīvības pieskaņa | Spēcīgas secinājumu optimizācijas, plašs atbalsts, piemērots standartizētai rādīšanai |
| TensorRT ( NVIDIA TensorRT dokumentācija ) | NVIDIA izvietošana | Apmaksātas vibrācijas (bieži vien komplektā) | Agresīva kodolu saplūšana + precīza apstrāde, ļoti ātra, kad tā noklikšķ |
| DeepSpeed ( ZeRO dokumentācija ) | Apmācību komandas | Bezmaksas | Atmiņas un caurlaidspējas optimizācija (ZeRO utt.). Var justies kā reaktīvais dzinējs |
| FSDP (PyTorch) ( PyTorch FSDP dokumentācija ) | Apmācību komandas | Bezmaksas | Šķembu parametri/gradients padara lielus modeļus mazāk biedējošus |
| bitu un baitu kvantēšana ( bitsandbytes ) | LLM meistari | Bezmaksas | Mazs bitu svars, milzīgs atmiņas ietaupījums — kvalitāte ir atkarīga, bet vau 😬 |
| Destilācija ( Hinton et al., 2015 ) | Produktu komandas | "Laika izmaksas" | Mazāks studentu modelis pārmanto uzvedību, parasti nodrošina vislabāko ilgtermiņa ieguldījumu atdevi |
| Atzarošana ( PyTorch atzarošanas pamācība ) | Pētniecība + produkts | Bezmaksas | Noņem lieko svaru. Darbojas labāk, ja to apvieno ar atkārtotu apmācību |
| Flash Attention / kausēti kodoli ( FlashAttention papīrs ) | Izrādes fanātiķi | Bezmaksas | Ātrāka uzmanība, labāka atmiņa. Īsta uzvara transformeriem |
| Triton secinājumu serveris ( dinamiskā partiju apstrāde ) | Operācijas/infrastruktūra | Bezmaksas | Ražošanas apkalpošana, partiju apstrāde, vairāku modeļu plūsmas — šķiet, ka tās ir uzņēmuma līmeņa |
Atzīšanās formatēšanas dīvainībā: “Cena” ir nekārtīga, jo atvērtā koda programmatūra joprojām var izmaksāt atkļūdošanas nedēļas nogali, kas ir… cena. 😵💫
4) Sāciet ar mērījumiem: profilējiet tā, kā jūs to domājat 🔍
Ja no visas šīs rokasgrāmatas darāt tikai vienu lietu, rīkojieties šādi: veiciet pareizus mērījumus.
Manos testos lielākie “optimizācijas sasniegumi” radās, atklājot kaut ko apkaunojoši vienkāršu, piemēram:
-
datu ielādētājs patērē daudz grafikas procesora (GPU)
-
CPU pirmapstrādes sastrēgums
-
mazi partiju izmēri, kas rada kodola palaišanas izmaksas
-
lēna tokenizācija (tokenizētāji var būt klusi ļaundari)
-
atmiņas fragmentācija ( PyTorch CUDA atmiņas piešķīrēja piezīmes )
-
viena slāņa dominējošais skaitļošanas
Kas jāmēra (minimālais komplekts)
-
Latentums (p50, p95, p99) ( SRE latentuma procentilēs )
-
Caurlaidspēja (tokeni/sekundē, pieprasījumi/sekundē)
-
GPU izmantošana (aprēķini + atmiņa)
-
VRAM/RAM maksimumi
-
Izmaksas par 1000 žetoniem (vai par secinājumu)
Praktiska profilēšanas domāšana
-
Aprakstiet vienu scenāriju, kas jums rūp (nevis rotaļlietu uzdevumu).
-
Pierakstiet visu nelielā “perf žurnālā”.
Jā, tas ir nogurdinoši… bet tas pasargās jūs no vēlākas maldināšanas.
(Ja vēlaties sākt ar konkrētu rīku: PyTorch Profiler ( torch.profiler docs ) un Nsight Systems ( NVIDIA Nsight Systems ) ir parastie aizdomās turamie.)
5) Dati + treniņu optimizācija: klusā superspēja 📦🚀
Cilvēki ir apsēsti ar modeļu arhitektūru un aizmirst par cauruļvadu. Tikmēr cauruļvads klusi patērē pusi no GPU.
Vieglas uzvaras, kas parādās ātri
-
Izmantojiet jauktu precizitāti (FP16/BF16, ja stabils) ( PyTorch AMP / torch.amp ).
Parasti ātrāk, bieži vien labi, taču pievērsiet uzmanību skaitliskām niansēm. -
Gradienta uzkrāšana , ja partijas lielums ir ierobežots ( 🤗 Paātrināšanas ceļvedis ).
Nodrošina optimizācijas stabilitāti, nepārtērējot atmiņu. -
Gradienta kontrolpunkts ( torch.utils.checkpoint ).
Apmaina skaitļošanas resursus atmiņas vietā — padara iespējamus lielākus kontekstus. -
Efektīva tokenizācija ( 🤗 Tokenizeri ).
Tokenizācija var kļūt par vājo vietu plašā mērogā. Tā nav glaunīga, tai ir nozīme. -
Datu ielādētāja regulēšana
Vairāk darbinieku, piesprausta atmiņa, iepriekšēja ielāde — neuzkrītoši, bet efektīvi 😴➡️💪 ( PyTorch veiktspējas regulēšanas rokasgrāmata )
Parametru ziņā efektīva precīza regulēšana
Ja veicat lielu modeļu precizēšanu, PEFT metodes (piemēram, LoRA stila adapteri) var ievērojami samazināt apmācības izmaksas, vienlaikus saglabājot pārsteidzoši spēcīgu sniegumu ( 🤗 Transformers PEFT ceļvedis , LoRA raksts ). Šis ir viens no tiem brīžiem, kad rodas jautājums: “kāpēc mēs to neizdarījām agrāk?”.
6) Arhitektūras līmeņa optimizācija: pareizā izmēra modelis 🧩
Dažreiz labākais optimizācijas veids ir… pārtraukt izmantot modeli, kas ir pārāk liels konkrētajam darbam. Zinu, svētulība 😄.
Veiciet zvanu, pamatojoties uz dažiem pamatprincipiem:
-
Izlemiet, vai jums ir nepieciešamas pilnīgas vispārējās izlūkošanas vibrācijas vai speciālista pakalpojumi.
-
Saglabājiet konteksta logu tik lielu, cik nepieciešams, nevis lielāku.
-
Izmantojiet modeli, kas ir apmācīts konkrētajam darbam (klasifikācijas modeļi klasifikācijas darbam utt.).
Praktiskas pareizā izmēra stratēģijas
-
Lielākajai daļai pieprasījumu
pārslēdzieties uz mazāku mugurkaulu. Pēc tam novirziet “stingros vaicājumus” uz lielāku modeli. -
Izmantojiet divpakāpju iestatījumu.
Ātri modeļa melnraksti, spēcīgākas modeļa pārbaudes vai rediģēšana.
Tas ir kā rakstīt kopā ar izvēlīgu draugu — kaitinoši, bet efektīvi. -
Samaziniet izvades garumu.
Izvades žetoni maksā naudu un laiku. Ja jūsu modelis maldās, jūs maksājat par maldīšanos.
Esmu redzējis, kā komandas ievērojami samazina izmaksas, ieviešot īsākus rezultātus. Tas šķiet sīkums, bet tas darbojas.
7) Kompilatora + grafika optimizācijas: no kurienes rodas ātrums 🏎️
Šis ir slānis “likt datoram darīt gudrākas datora lietas”.
Izplatītākās metodes:
-
Operatora sapludināšana (kodolu apvienošana) ( NVIDIA TensorRT “slāņu sapludināšana” )
-
Konstanta locīšana (fiksētu vērtību iepriekšēja aprēķināšana) ( ONNX izpildlaika grafika optimizācijas )
-
Kodola izvēle pielāgota aparatūrai
-
Grafu uztveršana , lai samazinātu Python papildu slodzi (
torch.compilepārskats )
Vienkārši sakot: jūsu modelis var būt matemātiski ātrs, bet operacionāli lēns. Kompilatori to daļēji novērš.
Praktiskas piezīmes (jeb rētas)
-
Šīs optimizācijas var būt jutīgas pret modeļa formas izmaiņām.
-
Daži modeļi ievērojami paātrinās, citi tik tikko pakustas.
-
Dažreiz gadās paātrinājums un mulsinoša kļūda — it kā būtu ievācies gremlins 🧌
Tomēr, kad tas darbojas, tā ir viena no tīrākajām uzvarām.
8) Kvantizācija, atzarošana, destilācija: mazāks bez raudāšanas (pārāk daudz) 🪓📉
Šī ir sadaļa, ko cilvēki vēlas… jo tas izklausās pēc bezmaksas uzstāšanās. Tas var būt, bet pret to jāizturas kā pret operāciju.
Kvantēšana (zemākas precizitātes svari/aktivizācijas)
-
Lieliski piemērots secinājumu ātrumam un atmiņai
-
Risks: kvalitātes kritums, īpaši sarežģītos gadījumos
-
Labākā prakse: novērtējiet, izmantojot reālu testa komplektu, nevis vibrācijas
Bieži sastopamas garšas, par kurām dzirdēsiet:
-
INT8 (bieži vien ciets) ( TensorRT kvantizētie tipi )
-
INT4 / zems bitu skaits (milzīgi ietaupījumi, kvalitātes risks pieaug) ( bitu un baitu k-bitu kvantizācija )
-
Jaukti kvanti (ne visam ir nepieciešama vienāda precizitāte)
Atzarošana (parametru noņemšana)
-
Noņem “nesvarīgus” svarus vai struktūras ( PyTorch atzarošanas pamācība )
-
Parasti ir nepieciešama pārkvalifikācija, lai atgūtu kvalitāti
-
Strādā labāk, nekā cilvēki domā… ja to dara uzmanīgi
Destilācija (skolēns mācās no skolotāja)
Šis ir mans personīgi iecienītākais ilgtermiņa sviras paņēmiens. Destilācija var radīt mazāku modeli, kas uzvedas līdzīgi, un tas bieži vien ir stabilāks nekā ekstremāla kvantizācija ( Zināšanu destilācija neironu tīklā ).
Nepilnīga metafora: destilācija ir kā sarežģītas zupas liešana caur filtru un… mazākas zupas iegūšana. Tā zupa nedarbojas, bet jūs saprotat domu 🍲.
9) Servēšana un secinājumi: īstā kaujas zona 🧯
Jūs varat “optimizēt” modeli un joprojām to slikti apkalpot. Apkalpošana ir tā vieta, kur latentums un izmaksas kļūst reālas.
Svarīgas uzvaras servē
-
Pakešu apstrāde
uzlabo caurlaidspēju. Bet palielina latentumu, ja to pārspīlē. Līdzsvaro to. ( Triton dinamiskā pakešu apstrāde ) -
Kešatmiņa.
Uzreiz saglabāt kešatmiņu un atkārtoti izmantot KV kešatmiņu var būt ļoti daudz atkārtotos kontekstos. ( KV kešatmiņas skaidrojums ). -
Straumēšanas izvade
Lietotājiem šķiet, ka tas ir ātrāk, pat ja kopējais laiks ir līdzīgs. Uztvere ir svarīga 🙂. -
Izdevumu samazināšana ar katru žetonu
Daži steki veic papildu darbu ar katru žetonu. Samazinot šīs izmaksas, jūs laimēsiet lielu laimestu.
Uzmanieties no astes latentuma
Jūsu vidējais rādītājs varētu izskatīties lieliski, savukārt jūsu P99 ir katastrofa. Diemžēl lietotāji dzīvo astes segmentā. ( “Astes latentums” un kāpēc vidējie rādītāji melo )
10) Aparatūras apzinīga optimizācija: saskaņojiet modeli ar iekārtu 🧰🖥️
Optimizācija bez aparatūras izpratnes ir kā sacīkšu automašīnas regulēšana, nepārbaudot riepas. Protams, to var izdarīt, bet tas ir mazliet muļķīgi.
GPU apsvērumi
-
Ierobežojošais faktors bieži vien ir atmiņas joslas platums, nevis neapstrādāti aprēķinu dati
-
Lielāki partiju izmēri var palīdzēt, līdz tie vairs nepalīdz
-
Kodola sapludināšana un uzmanības optimizācija ir ļoti svarīga transformatoriem ( FlashAttention: IO-aware precīza uzmanība )
CPU apsvērumi
-
Vītņošana, vektorizācija un atmiņas lokalitāte ir ļoti svarīga
-
Tokenizācijas izmaksas var dominēt ( 🤗 “Ātrie” tokenizeri )
-
Jums var būt nepieciešamas citas kvantēšanas stratēģijas nekā GPU
Apsvērumi par perifērijas/mobilajām ierīcēm
-
Atmiņas nospiedums kļūst par prioritāti numur viens
-
Latentuma dispersija ir svarīga, jo ierīces ir… kaprīzas
-
Mazāki, specializēti modeļi bieži vien pārspēj lielus, vispārīgus modeļus
11) Kvalitatīvas aizsargbarjeras: Neoptimizējiet sevi, lai radītu kļūdu 🧪
Katram ātruma uzlabojumam jābūt saistītam ar kvalitātes pārbaudi. Citādi jūs svinēsiet, nosūtīsiet produktu un pēc tam saņemsiet ziņojumu, piemēram, "kāpēc asistents pēkšņi runā kā pirāts?" 🏴☠️
Pragmatiskas aizsargbarjeras:
-
Zelta uzvednes (fiksēts uzvedņu kopums, ko vienmēr pārbaudāt)
-
Uzdevuma metrika (precizitāte, F1, BLEU, kas vien der)
-
Cilvēku veiktās pārbaudes (jā, nopietni)
-
Regresijas sliekšņi (“atļauts kritums ne vairāk kā X%)
Izsekojiet arī atteices režīmus:
-
formatēšanas nobīde
-
atteikšanās uzvedības izmaiņas
-
halucināciju biežums
-
atbildes garuma inflācija
Optimizācija var mainīt uzvedību pārsteidzošos veidos. Savādi. Kairinoši. Paredzami, atskatoties pagātnē.
12) Kontrolsaraksts: Kā optimizēt mākslīgā intelekta modeļus soli pa solim ✅🤖
Ja vēlaties skaidru darbību secību AI modeļu optimizēšanai , šeit ir darbplūsma, kas parasti palīdz cilvēkiem saglabāt veselo saprātu:
-
Definējiet panākumus.
Izvēlieties 1–2 galvenos rādītājus (latentums, izmaksas, caurlaidspēja, kvalitāte). -
Izmēriet bāzes
profila reālās darba slodzes, reģistrējiet p50/p95, atmiņu, izmaksas. ( PyTorch Profiler ) -
Novērst cauruļvada sastrēgumus.
Datu ielāde, tokenizācija, priekšapstrāde, partijveida apstrāde. -
Lietot zema riska skaitļošanas ieguvumus
Jaukta precizitāte, kodola optimizācija, labāka partijveida apstrāde. -
Izmēģiniet kompilatora/izpildlaika optimizācijas.
Grafu uztveršana, secinājumu izpildlaiki, operatoru sapludināšana. (torch.compilepamācība , ONNX izpildlaika dokumentācija ). -
Samaziniet modeļa izmaksas.
Rūpīgi kvantificējiet, destilējiet, ja iespējams, un, ja nepieciešams, apgrieziet. -
Kešatmiņas
, vienlaicīguma, slodzes testēšanas un astes latentuma labojumi. -
Kvalitātes validēšana.
Veikt regresijas testus un salīdzināt rezultātus blakus. -
Atkārtot.
Nelielas izmaiņas, skaidras piezīmes, atkārtot. Neuzkrītošs - efektīvs.
Un jā, tas joprojām ir kā optimizēt mākslīgā intelekta modeļus, pat ja tas vairāk atgādina “Kā pārtraukt kāpt uz grābekļiem”. Tas pats.
13) Bieži pieļautās kļūdas (lai jūs tās neatkārtotu tāpat kā mēs pārējie) 🙃
-
Optimizācija pirms mērīšanas.
Jūs iztērēsiet laiku. Un tad jūs pārliecinoši optimizēsiet nepareizo lietu… -
Dzenoties pēc viena kritērija.
Etaloni melo, jo tos izlaiž. Jūsu darba slodze ir patiesība. -
Atmiņas problēmu ignorēšana
izraisa palēnināšanos, avārijas un nervozitāti. ( CUDA atmiņas izmantošanas izpratne PyTorch ) -
Pārāk agra pārkvantēšana.
Zema bitu kvantēšana var būt pārsteidzoša, taču vispirms sāciet ar drošākiem soļiem. -
Nav atcelšanas plāna.
Ja nevarat ātri atgriezties pie iepriekšējās versijas, katra izvietošana kļūst stresaina. Stress rada kļūdas.
Noslēguma piezīmes: Cilvēcīgs veids, kā optimizēt 😌⚡
Kā optimizēt mākslīgā intelekta modeļus, nav viens triks. Tas ir daudzslāņains process: izmēriet, labojiet cauruļvadu, izmantojiet kompilatorus un izpildlaikus, noregulējiet apkalpošanu un pēc tam, ja nepieciešams, samaziniet modeli ar kvantizāciju vai destilāciju. Dariet to soli pa solim, saglabājiet kvalitātes drošības barjeras un neuzticieties kritērijam "tas šķiet ātrāk" (jūsu sajūtas ir jaukas, jūsu sajūtas nav profilētājs).
Ja vēlaties īsāko ēdienu līdzņemšanai:
-
Vispirms izmēri 🔍
-
Optimizējiet cauruļvadu tālāk 🧵
-
Pēc tam optimizējiet modeli 🧠
-
Pēc tam optimizējiet pasniegšanu 🏗️
-
Vienmēr veiciet kvalitātes pārbaudes ✅
Un, ja tas palīdz, atgādini sev: mērķis nav “ideāls modelis”. Mērķis ir modelis, kas ir ātrs, pieejams un pietiekami uzticams, lai tu varētu gulēt naktī… lielākoties naktīs 😴.
Bieži uzdotie jautājumi
Ko praksē nozīmē mākslīgā intelekta modeļa optimizācija
“Optimizēt” parasti nozīmē uzlabot vienu galveno ierobežojumu: latentumu, izmaksas, atmiņas patēriņu, precizitāti, stabilitāti vai apkalpošanas caurlaidspēju. Grūtākais ir kompromisi — vienas jomas uzlabošana var kaitēt citai. Praktiska pieeja ir izvēlēties skaidru mērķi (piemēram, p95 latentumu vai kvalitātes sasniegšanas laiku) un optimizēt atbilstoši tam. Bez mērķa ir viegli “uzlabot” un joprojām zaudēt.
Kā optimizēt mākslīgā intelekta modeļus, nemanāmi nezaudējot kvalitāti
Uztveriet katru ātruma vai izmaksu izmaiņu kā potenciālu klusu regresiju. Izmantojiet tādus drošības pasākumus kā zelta norādes, uzdevumu rādītājus un ātras cilvēku veiktas pārbaudes. Nosakiet skaidru slieksni pieņemamai kvalitātes novirzei un salīdziniet rezultātus blakus. Tas neļauj "tas ir ātrāk" pārvērsties par "kāpēc tas pēkšņi kļuva dīvains ražošanā?" pēc nosūtīšanas.
Kas jāizmēra pirms optimizācijas uzsākšanas
Sāciet ar latentuma procentīlēm (p50, p95, p99), caurlaidspēju (tokeni/sekundē vai pieprasījumi/sekundē), GPU izmantošanu un maksimālo VRAM/RAM. Izsekojiet izmaksas par secinājumu vai par 1000 tokeniem, ja izmaksas ir ierobežojums. Izveidojiet profilu par reālu scenāriju, ko apkalpojat, nevis rotaļu uzdevumu. Neliela "veiktspējas žurnāla" uzturēšana palīdz izvairīties no minējumiem un kļūdu atkārtošanas.
Ātras, zema riska uzvaras treniņu sniegumam
Jaukta precizitāte (FP16/BF16) bieži vien ir ātrākais pirmais solis, taču pievērsiet uzmanību skaitliskām īpatnībām. Ja partijas lielums ir ierobežots, gradienta uzkrāšana var stabilizēt optimizāciju, neiztērējot daudz atmiņas. Gradienta kontrolpunkti apmaina papildu skaitļošanas jaudu ar mazāku atmiņas apjomu, tādējādi nodrošinot lielākus kontekstus. Neignorējiet tokenizāciju un datu ielādētāja regulēšanu — tie var nemanāmi patērēt GPU.
Kad izmantot torch.compile, ONNX Runtime vai TensorRT
Šie rīki ir paredzēti darbības papildu izmaksu samazināšanai: grafu uztveršanai, kodola sapludināšanai un izpildlaika grafu optimizācijai. Tie var nodrošināt tīru secinājumu paātrinājumu, taču rezultāti atšķiras atkarībā no modeļa formas un aparatūras. Daži iestatījumi šķiet maģiski; citi tik tikko kustas. Esiet gatavi jutībai pret formas izmaiņām un neregulārām "gremlin" kļūdām — izmēriet pirms un pēc reālās darba slodzes.
Vai kvantizācija ir tā vērta, un kā izvairīties no pārāk lielas iešanas
Kvantēšana var samazināt atmiņu un paātrināt secinājumu izdarīšanu, īpaši ar INT8, taču kvalitāte var pasliktināties robežgadījumos. Zemāka bitu skaita opcijas (piemēram, INT4/k-bit) nodrošina lielākus ietaupījumus ar lielāku risku. Drošākais ieradums ir novērtēt reālā testa komplektā un salīdzināt rezultātus, nevis intuīciju. Vispirms sāciet ar drošākiem soļiem, pēc tam samaziniet precizitāti tikai tad, ja nepieciešams.
Atšķirība starp apgriešanu un destilāciju modeļa izmēra samazināšanai
Atzarošana noņem "liekā svara" parametrus un bieži vien ir nepieciešama atkārtota apmācība, lai atgūtu kvalitāti, īpaši, ja to dara agresīvi. Destilācija apmāca mazāku skolēna modeli atdarināt lielāka skolotāja uzvedību, un tā var būt spēcīgāka ilgtermiņa ieguldījumu atdeve nekā ekstremāla kvantācija. Ja vēlaties mazāku modeli, kas uzvedas līdzīgi un saglabā stabilitāti, destilācija bieži vien ir tīrāks ceļš.
Kā samazināt secinājumu izmaksas un latentumu, uzlabojot rādīšanu
Optimizācija kļūst taustāma apkalpošanas jomā: partijveida apstrāde palielina caurlaidspēju, bet, ja tiek pārspīlēta, var kaitēt latentumam, tāpēc to rūpīgi noregulējiet. Kešatmiņa (tūlītēja kešatmiņa un KV kešatmiņas atkārtota izmantošana) var būt milzīga, ja konteksti atkārtojas. Straumēšanas izvade uzlabo uztveramo ātrumu pat tad, ja kopējais laiks ir līdzīgs. Savā kaudzē meklējiet arī katra marķiera papildu slodzi — neliels darbs uz katru marķieri ātri uzkrājas.
Kāpēc astes latentums ir tik svarīgs, optimizējot mākslīgā intelekta modeļus
Vidējie rādītāji var izskatīties lieliski, savukārt p99 ir katastrofa, un lietotāji mēdz dzīvot astē. Astes latentums bieži rodas no svārstībām: atmiņas fragmentācijas, centrālā procesora pirmapstrādes kāpumiem, tokenizācijas palēnināšanās vai sliktas partijveida apstrādes darbības. Tāpēc rokasgrāmatā tiek uzsvērtas procentīles un reālās darba slodzes. Ja optimizējat tikai p50, jūs joprojām varat nodrošināt pieredzi, kas "nejauši šķiet lēna"
Atsauces
-
Amazon Web Services (AWS) — AWS CloudWatch procentiles (statistikas definīcijas) — docs.aws.amazon.com
-
Google — The Tail at Scale (astes latentuma labākā prakse) — sre.google
-
Google — pakalpojumu līmeņa mērķi (SRE grāmata) — latentuma procentiles — sre.google
-
PyTorch — torch.compile — docs.pytorch.org
-
PyTorch — FullyShardedDataParallel (FSDP) — docs.pytorch.org
-
PyTorch — PyTorch profilētājs — docs.pytorch.org
-
PyTorch — CUDA semantika: atmiņas pārvaldība (CUDA atmiņas piešķīrēja piezīmes) — docs.pytorch.org
-
PyTorch — automātiskā jauktā precizitāte (torch.amp / AMP) — docs.pytorch.org
-
PyTorch — torch.utils.checkpoint — docs.pytorch.org
-
PyTorch — veiktspējas regulēšanas rokasgrāmata — docs.pytorch.org
-
PyTorch — apgriešanas pamācība — docs.pytorch.org
-
PyTorch — CUDA atmiņas izmantošanas izpratne programmā PyTorch — docs.pytorch.org
-
PyTorch — torch.compile pamācība/pārskats — docs.pytorch.org
-
ONNX izpildlaiks — ONNX izpildlaika dokumentācija — onnxruntime.ai
-
NVIDIA — TensorRT dokumentācija — docs.nvidia.com
-
NVIDIA — TensorRT kvantizētie tipi — docs.nvidia.com
-
NVIDIA — Nsight Systems — izstrādātājs.nvidia.com
-
NVIDIA — Triton secinājumu serveris — dinamiskā partijveida apstrāde — docs.nvidia.com
-
DeepSpeed — ZeRO 3. posma dokumentācija — deepspeed.readthedocs.io
-
bitsandbytes (bitsandbytes-foundation) — bitsandbytes — github.com
-
Sejas apskaušana — paātrinājums: gradienta uzkrāšanas ceļvedis — huggingface.co
-
Apskaujošā seja — Tokenizeru dokumentācija — huggingface.co
-
Apskaujošā seja — Transformers: PEFT ceļvedis — huggingface.co
-
Apskaujošā seja — Transformers: KV kešatmiņas skaidrojums — huggingface.co
-
Apskaujošā seja — Transformers: “Ātrie” tokenizeri (tokenizeru klases) — huggingface.co
-
arXiv — zināšanu destilēšana neironu tīklā (Hinton et al., 2015) — arxiv.org
-
arXiv — LoRA: lielu valodu modeļu zema ranga adaptācija — arxiv.org
-
arXiv — FlashAttention: ātra un atmiņā efektīva precīza uzmanība ar IO-Awareness — arxiv.org