SageMaker LLM optimizavimas: kai modelio kaina pagaliau matoma iš notebooko

SageMaker LLM optimizavimas šiandien nėra teorinis žaislas. Tai jau darbas, pinigai, duomenys ir kartais labai žemiškas klausimas: kas prisiims atsakomybę, kai DI pradės veikti už žmogų?

SageMaker LLM optimizavimas rugpjūčio 6 d. AWS tinklaraštyje pristatytas labai praktiškai: inžinierius gali benchmarkinti endpointą, gauti rekomendacijas ir diegti pasirinktą konfigūraciją tiesiai iš notebooko.

Turiu prisipažinti, tokias naujienas skaitau ne kaip blizgančią vitriną. Skaitau kaip žmogus, kuris iš karto galvoja apie komandą pirmadienio rytą. Kas iš to bus naudinga? Kur bus painiava? Ir kur po mėnesio kas nors pasakys: „mes galvojom, kad čia automatiškai susitvarkys“.

KAS NUTIKO

Amazon SageMaker Python SDK v3 dabar turi generatyvinio DI inference rekomendacijas. Jos padeda įvertinti modelio diegimo variantus pagal našumą, kainą ir darbo krūvį, o tada paleisti rekomenduojamą konfigūraciją.

Modelių diegimas dažnai primena spintelę su daug varžtų. Viskas lyg ir telpa, bet vienas pasirinkimas kainą pakelia tyliai. Ir tada mėnesio gale finansai paklausia: kas čia įvyko?

Čia svarbi detalė: kalbame ne apie dar vieną gražų demonstracinį video. Kalbame apie produktus, politiką, infrastruktūrą arba tyrimus, kurie keičia, kaip žmonės dirba su DI realiose organizacijose.

KODĖL TAI SVARBU

DI projektai dažnai sugenda ne todėl, kad modelis blogas. Jie sugenda todėl, kad pasirinkta per brangi arba per lėta infrastruktūra.

DI jau išlipo iš „parašyk tekstą“ dėžutės. Jis naršo, jungiasi prie įrankių, analizuoja duomenis, planuoja veiksmus, kartais tvarko dokumentus ar padeda priimti sprendimą. Trumpai: jis artėja prie darbo proceso, ne tik prie pokalbio lango.

Ir čia smegenys mėgsta paslysti. Norisi sakyti: „ai, čia dar užsienyje“. Bet tas pats modelis ar funkcija rytoj atsiras kliento kompiuteryje, darbuotojo naršyklėje arba partnerio pasiūlyme.

KĄ TAI REIŠKIA VERSLUI

Verslui tai reiškia, kad techninės komandos gali anksčiau matyti, kiek kainuos realus modelio veikimas. Ne po paleidimo, o dar testuojant.

• testuoti endpointą su realiu krūviu
• vertinti kainą ir atsako laiką kartu
• nepasikliauti vien numatytomis reikšmėmis
• rekomendacijas fiksuoti prie projekto sprendimų

Jei turite modelį produkcijai, paprašykite komandos parodyti ne tik tikslumą, bet ir kainą vienai užklausai prie skirtingo apkrovimo.

Man patinka paprastas testas: ar po šios naujienos tavo komanda turi vieną aiškesnį sprendimą? Jei ne, vadinasi dar tik skaitome. Skaityti galima. Tik nereikia apsimesti, kad tai jau strategija.

KUR GALI SKAUDĖTI

Rizika – optimizuoti laboratorinį scenarijų, kuris nepanašus į realų naudojimą. Tada rekomendacija graži, bet sąskaita vis tiek kandžiojasi.

Dažniausia klaida labai ūkiška. Žmonės įsijungia įrankį, pabando, nustemba, pasidžiaugia ir tada palieka viską savieigai. Po kelių savaičių paaiškėja, kad vieni darbuotojai kelia jautrius failus, kiti matuoja naudą iš jausmo, o treti net nežino, kas leidžiama.

Ne tragedija. Bet tvarkos reikia.

KĄ PASIDARYTI ŠIĄ SAVAITĘ

Šią savaitę vienam DI endpointui suskaičiuokite tris skaičius: vidutinį atsako laiką, kainą už 1000 užklausų ir klaidų procentą.

Šaltinis: AWS Machine Learning Blog.

DUK

Kas yra SageMaker LLM optimizavimas?

Tai SageMaker Python SDK galimybės testuoti generatyvinio DI endpointus ir gauti diegimo rekomendacijas.

Kodėl tai svarbu?

Nes modelio kaina ir greitis lemia, ar DI sprendimą įmanoma naudoti realiame procese.

Ką matuoti pirmiausia?

Atsako laiką, kainą už užklausas ir stabilumą prie realaus krūvio.

Jei nori DI naudoti praktiškai, pradėk nuo vieno proceso. Vienas pasikartojantis darbas. Vienas atsakingas žmogus. Vienas matavimas. Daugiau praktikos rasi MasterSprint.