Kā optimizēt mākslīgā intelekta modeļus

Ī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.compile pā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 "astē". (“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:

1. Definējiet panākumus.
   Izvēlieties 1–2 galvenos rādītājus (latentums, izmaksas, caurlaidspēja, kvalitāte).

2. Izmēriet bāzes
   profila reālās darba slodzes, reģistrējiet p50/p95, atmiņu, izmaksas. (PyTorch Profiler)

3. Novērst cauruļvada sastrēgumus.
   Datu ielāde, tokenizācija, priekšapstrāde, partijveida apstrāde.

4. Lietot zema riska skaitļošanas ieguvumus
   Jaukta precizitāte, kodola optimizācija, labāka partijveida apstrāde.

5. Izmēģiniet kompilatora/izpildlaika optimizācijas.
   Grafu uztveršana, secinājumu izpildlaiki, operatoru sapludināšana. (torch.compile pamācība, ONNX izpildlaika dokumentācija).

6. Samaziniet modeļa izmaksas.
   Rūpīgi kvantificējiet, destilējiet, ja iespējams, un, ja nepieciešams, apgrieziet.

7. Kešatmiņas
   , vienlaicīguma, slodzes testēšanas un astes latentuma labojumi.

8. Kvalitātes validēšana.
   Veikt regresijas testus un salīdzināt rezultātus blakus.

9. 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 😴.

Reālās pasaules piemērs: atbalsta pieprasījumu apkopotāja optimizācija 🎟️⚡

Scenārijs

Iedomājieties nelielu SaaS komandu, kas izmanto mākslīgā intelekta modeli, lai apkopotu ienākošos atbalsta pieprasījumus, pirms cilvēks atbild. Modelis darbojas, bet ir lēns: aģenti pārāk ilgi gaida kopsavilkumus, un uzņēmums maksā vairāk nekā paredzēts par secinājumiem.

Mērķis nav padarīt modeli “labāku” visos iespējamos veidos. Komanda izvēlas vienu galveno ierobežojumu: samazināt p95 latentumu, vienlaikus saglabājot pieņemamu kopsavilkuma kvalitāti.

Viņu mērķis ir skaidrs:

Samazināt p95 latentumu no aptuveni 2,4 sekundēm līdz mazāk nekā 1,2 sekundēm, ar ne vairāk kā vienu nopietnu kopsavilkuma kļūdu 50 biļešu testa komplektā.

Kas nepieciešams darbplūsmai

Lai to īstenotu, komanda apkopo:

50 biļešu zelta testa komplekts ar īsām, vidējām un nekārtīgām biļetēm

Paredzētais kopsavilkuma stils: 3 aizzīmes, bez izdomātiem faktiem, norādiet steidzamību, ja tas ir acīmredzams

Sākotnējie rādītāji: p50, p95, p99 latentums, ģenerētie žetoni, izmaksas par biļeti un kļūdu skaits

Vienkāršs cilvēka veikts pārskatīšanas kontrolsaraksts

Piekļuve modeļu žurnāliem, žetonu skaitam un partijas/vienlaicības iestatījumiem

Atcelšanas iespēja, ja kvalitāte pasliktinās

Svarīgākais: tie nesāk ar kvantizāciju. Vispirms tie pārbauda, ​​vai cauruļvads netērē laiku.

Instrukcijas piemērs

Katrā atbalsta pieprasījumā klienta problēmu apkopojiet tieši trīs aizzīmēs.

Iekļaut:

• galvenā problēma

• jebkura minētā produktu joma

• steidzamība vai ietekme uz uzņēmējdarbību, ja norādīts

Neizdomā trūkstošās detaļas. Ja klients nesniedz pietiekami daudz informācijas, saki “nav norādīts”.

Kopsavilkumam jābūt ne garākam par 80 vārdiem.

Kā to pārbaudīt

Izpildiet tās pašas 50 biļetes, izmantojot gan veco, gan jauno iestatījumu.

Katram braucienam ierakstiet:

p50, p95 un p99 latentums

Vidējais izvades žetonu skaits

Cena par 1000 biļetēm

Kopsavilkumu skaits ar izgudrotām detaļām

Kopsavilkumu skaits, kam nepieciešama cilvēka pārrakstīšana

Pēc tam pārbaudiet dažus neveiklus gadījumus:

Biļete ar trim atsevišķām problēmām

Ļoti dusmīga klienta ziņa

Neskaidra biļete gandrīz bez detaļām

Biļete ar ielīmētiem žurnāliem

Pieteikums, kurā klients piemin sava konta dzēšanu

Tas novērš bieži sastopamo kļūmi, kad optimizācija padara modeli ātrāku, bet mazāk uzmanīgu.

Rezultāts

Ilustratīvais rezultāts, pamatojoties uz 50 parauga biļešu laika noteikšanu pirms un pēc trim optimizācijas reizēm:

Sākotnējais līmenis:

p95 latentums: 2,4 sekundes

p99 latentums: 3,1 sekundes

Vidējais izvades garums: 142 vārdi

Cilvēka pārrakstījumi: 11 no 50

Nopietnas izdomātu detaļu kļūdas: 3 no 50

Pēc optimizācijas:

p95 latentums: 1,1 sekundes

p99 latentums: 1,6 sekundes

Vidējais izvades garums: 61 vārds

Cilvēka pārrakstījumi: 5 no 50

Nopietnas izdomātu detaļu kļūdas: 1 no 50

Kas mainījās:

Komanda ierobežoja izvades garumu līdz 80 vārdiem

Viņi sadalīja zemas prioritātes biļetes 8 grupās

Viņi kešatmiņā saglabāja atkārtotu produkta politikas kontekstu

Pēc kvalitātes apstiprināšanas viņi ieslēdza jauktu precizitāti

Viņi atlika kvantizāciju uz vēlāku laiku, jo latentuma mērķis jau bija sasniegts

Šajā piemērā izmaksas arī samazinājās, jo modelis ģenerēja mazāk žetonu. Ja vecā iestatīšana ģenerēja aptuveni 142 vārdus uz vienu biļeti un jaunā iestatīšana ģenerēja aptuveni 61 vārdu, izvades garums samazinājās par aptuveni 57%. Šo rādītāju komanda var pārbaudīt tieši no žurnāliem.

Kas var noiet greizi

Kārdinošākā kļūda ir optimizēt ātrumu pašu par sevi. Ātrāks kopsavilkums, kas izdomā atmaksas solījumu, nav uzlabojums.

Citas vienkāršas kļūdas:

Testē tikai tīras biļetes

Ignorējot p99 latentumu

Aizmirst salīdzināt izvades garumu

Vienlaicīga partijveida apstrādes un modeļa iestatījumu maiņa

Tiek izmantots vidējais latentums, nevis astes latentums

Apgalvojums, ka “kvalitāte nemainījās”, bez atsauksmju kontrolsaraksta

Drošāka pārskatīšanas noteikums ir vienkāršs: ja vairāk nekā 2 no 50 kopsavilkumiem satur svarīgas detaļas, atgriezieties pie iepriekšējās situācijas un veiciet izpēti.

Praktiska līdzņemšana

Lūk, kā praktiski izskatās stabila mākslīgā intelekta modeļa optimizācija: izvēlieties vienu ierobežojumu, izmēriet pašreizējo sistēmu, vispirms noņemiet atkritumus, piemērojiet zema riska izmaiņas un pēc tam pārbaudiet kvalitāti ar ikdienišķām, bet vērtīgām pārbaudēm. Uzvara nav tikai ātrāks modelis. Tas ir ātrāks modelis, kuram joprojām varat uzticēties.

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

1. Amazon Web Services (AWS) — AWS CloudWatch procentiles (statistikas definīcijas) — docs.aws.amazon.com

2. Google — The Tail at Scale (astes latentuma labākā prakse) — sre.google

3. Google — pakalpojumu līmeņa mērķi (SRE grāmata) — latentuma procentiles — sre.google

4. PyTorch — torch.compile — docs.pytorch.org

5. PyTorch — FullyShardedDataParallel (FSDP) — docs.pytorch.org

6. PyTorch — PyTorch profilētājs — docs.pytorch.org

7. PyTorch — CUDA semantika: atmiņas pārvaldība (CUDA atmiņas piešķīrēja piezīmes) — docs.pytorch.org

8. PyTorch — automātiskā jauktā precizitāte (torch.amp / AMP) — docs.pytorch.org

9. PyTorch — torch.utils.checkpoint — docs.pytorch.org

10. PyTorch — veiktspējas regulēšanas rokasgrāmata — docs.pytorch.org

11. PyTorch — apgriešanas pamācība — docs.pytorch.org

12. PyTorch — CUDA atmiņas izmantošanas izpratne programmā PyTorch — docs.pytorch.org

13. PyTorch — torch.compile pamācība/pārskats — docs.pytorch.org

14. ONNX izpildlaiks — ONNX izpildlaika dokumentācija — onnxruntime.ai

15. NVIDIA — TensorRT dokumentācija — docs.nvidia.com

16. NVIDIA — TensorRT kvantizētie tipi — docs.nvidia.com

17. NVIDIA — Nsight Systems — izstrādātājs.nvidia.com

18. NVIDIA — Triton secinājumu serveris — dinamiskā partijveida apstrāde — docs.nvidia.com

19. DeepSpeed ​​— ZeRO 3. posma dokumentācija — deepspeed.readthedocs.io

20. bitsandbytes (bitsandbytes-foundation) — bitsandbytes — github.com

21. Sejas apskaušana — paātrinājums: gradienta uzkrāšanas ceļvedis — huggingface.co

22. Apskaujošā seja — Tokenizeru dokumentācija — huggingface.co

23. Apskaujošā seja — Transformers: PEFT ceļvedis — huggingface.co

24. Apskaujošā seja — Transformers: KV kešatmiņas skaidrojums — huggingface.co

25. Apskaujošā seja — Transformers: “Ātrie” tokenizeri (tokenizeru klases) — huggingface.co

26. arXiv — zināšanu destilēšana neironu tīklā (Hinton et al., 2015) — arxiv.org

27. arXiv — LoRA: lielu valodu modeļu zema ranga adaptācija — arxiv.org

28. arXiv — FlashAttention: ātra un atmiņā efektīva precīza uzmanība ar IO-Awareness — arxiv.org