Paranna Falcon-mallien suorituskykyä Amazon SageMakerin avulla | Amazon Web Services

Mikä on optimaalinen kehys ja konfiguraatio suurten kielimallien (LLM) isännöimiseen tekstiä luoville generatiivisille tekoälysovelluksille? Huolimatta LLM-palveluiden lukuisista vaihtoehdoista, tähän on vaikea vastata mallien koon, vaihtelevien malliarkkitehtuurien, sovellusten suorituskykyvaatimusten ja muiden vuoksi. The Amazon Sage Maker Large Model Inference (LMI) -säiliö tekee LLM:ien palvelemisesta yksinkertaista yhdistämällä joukon erilaisia ​​kehyksiä ja tekniikoita, jotka optimoivat LLM:ien käyttöönoton. LMI-säiliössä on tehokas tarjoilupino nimeltä DJL-tarjoilu joka on agnostikko taustalla olevalle LLM:lle. Se tarjoaa järjestelmätason määritysparametreja, jotka voidaan virittää siten, että tietyn LLM:n isännöintiinfrastruktuurista saadaan paras suorituskyky. Se tukee myös viimeaikaisia ​​optimointeja, kuten jatkuvaa eräajoa, joka tunnetaan myös nimellä iteratiivinen erä tai rullaava erä, mikä parantaa merkittävästi suorituskykyä.

Aikaisemmassa posti, näytimme, kuinka voit käyttää LMI-säilöä Falcon-malliperheen käyttöönottamiseksi SageMakerissa. Tässä viestissä osoitamme, kuinka voit parantaa Falcon-40B:n palvelun suoritustehoa ja latenssia tekniikoilla, kuten jatkuvalla annostelulla. Tarjoamme myös intuitiivisen ymmärryksen SageMaker LMI -säilön tarjoamista konfigurointiparametreista, jotka voivat auttaa sinua löytämään parhaan kokoonpanon tosielämän sovelluksellesi.

Tekstigeneratiivisen päättelyn perusteet LLM:ille

Katsotaanpa ensin muutamia perusasioita siitä, miten LLM:t voivat tehdä päätelmiä tekstin luomista varten.

Eteenpäin pass, aktivointi ja KV-välimuisti

Kun on annettu syötemerkkijono, ne suoritetaan a forward pass kaikilla LLM:n kerroksilla (kuten Falconilla) seuraavan tunnuksen luomiseksi. A forward pass viittaa prosessiin, jossa syöttödata siirretään neuroverkon läpi tulosteen tuottamiseksi. Tekstin luomisen tapauksessa eteenpäin siirto sisältää alkusiemenen tai kontekstin syöttämisen kielimalliin ja seuraavan merkin tai merkin luomisen sekvenssissä. Tekstisarjan luomiseksi prosessi suoritetaan usein iteratiivisesti, mikä tarkoittaa, että se toistetaan jokaisessa vaiheessa tai kohdassa tulostesekvenssissä. Jokaisessa iteraatiossa malli luo seuraavan merkin tai tunnuksen, josta tulee osa luotua tekstiä, ja tämä prosessi jatkuu, kunnes haluttu tekstipituus on luotu.

Tekstin luominen kielimalleilla, kuten Falcon tai GPT autoregressive. Tämä tarkoittaa, että malli luo yhden tunnuksen kerrallaan samalla kun ehdoitetaan aiemmin luotuja tokeneita. Toisin sanoen jokaisessa iteraatiossa malli ottaa syötteeksi aiemmin luodun tekstin ja ennustaa seuraavan merkin tämän kontekstin perusteella. Kuten kohdassa mainittiin vLLM: Helppo, nopea ja halpa LLM-palvelu PagedAttentionilla, tässä autoregressiivisessä dekoodausprosessissa kaikki LLM:n syöttötunnukset tuottavat huomioavaimen ja arvotensorit, ja nämä tensorit säilytetään GPU:n muistissa seuraavien tokenien luomista varten. Näitä välimuistissa olevia avain- ja arvotensoreja kutsutaan usein nimellä KV cache.

Esitäyttö ja dekoodaus vaiheet

Autoregressiivisessä dekoodausprosessissa, kuten tekstin luomisessa kielimalleilla, kuten Falconilla, on tyypillisesti kaksi päävaihetta: prefill vaihe ja decode vaihe. Nämä vaiheet ovat ratkaisevan tärkeitä johdonmukaisen ja kontekstuaalisesti relevantin tekstin luomiseksi.

Esitäyttövaihe sisältää seuraavat:

• Alkuperäinen konteksti – Esitäyttövaihe alkaa käyttäjän antamalla alkuperäisellä kontekstilla tai alkutekstillä. Tämä alkukonteksti voi olla lause, lause tai jopa vain yksi sana. Se asettaa lähtökohdan tekstin luomiselle ja tarjoaa kontekstin seuraavalle.
• Mallin ilmastointi – Tarjottua kontekstia käytetään kielimallin ehdoittamiseen. Malli ottaa tämän kontekstin syötteenä ja luo seuraavan merkin (sanan tai merkin) sekvenssissä kontekstin ymmärtämisen perusteella.
• Tokenin sukupolvi – Malli luo yhden tokenin kerrallaan ennustaen, mitä tekstissä pitäisi seuraavaksi tulla. Tämä tunnus on liitetty kontekstiin ja laajentaa sitä tehokkaasti.
• Iteratiivinen prosessi – Tokenien luontiprosessi toistetaan iteratiivisesti. Jokaisessa vaiheessa malli luo tunnuksen ottaen huomioon päivitetyn kontekstin, joka sisältää nyt aiemmissa vaiheissa luodut tunnukset.

Esitäyttövaihe jatkuu, kunnes ennalta määrätty pysäytysehto täyttyy. Tämä ehto voi olla luodun tekstin enimmäispituus, tietty merkki, joka ilmoittaa tekstin loppumisesta, tai mikä tahansa muu käyttäjän tai sovelluksen asettama kriteeri.

Dekoodausvaihe sisältää seuraavat:

• Valmistuminen – Esitäyttövaiheen jälkeen sinulla on osittain luotu teksti, joka saattaa olla jossain vaiheessa epätäydellinen tai katkennut. Dekoodausvaihe on vastuussa tekstin täydentämisestä, jotta se on johdonmukainen ja kieliopillisesti oikea.
• Jatkoa viimeisestä tokenista – Dekoodausvaiheessa malli alkaa viimeisestä esitäyttövaiheessa luodusta tunnuksesta. Se käyttää tätä merkkiä alkuperäisenä kontekstina ja luo seuraavan tunnuksen jatkaakseen tekstiä.
• Iteratiivinen viimeistely – Kuten esitäyttövaiheessa, tokenien luontiprosessi on jälleen iteratiivinen. Malli luo yhden merkin kerrallaan ehdoittaen sekvenssin edeltäviä tokeneita.
• Pysäytystila – Dekoodausvaiheessa on myös pysäytysehto, joka voi olla sama kuin esitäyttövaiheessa, kuten maksimipituuden saavuttaminen tai tekstin lopun merkki. Kun tämä ehto täyttyy, luontiprosessi pysähtyy.

Esitäyttö- ja dekoodausvaiheiden yhdistelmä mahdollistaa autoregressiivisten mallien luomisen tekstin, joka perustuu alkuperäiseen kontekstiin ja tuottaa johdonmukaisia, kontekstuaalisesti relevantteja ja kontekstuaalisesti johdonmukaisia ​​tekstisarjoja.

Mainita Hajautettu palvelujärjestelmä muuntajapohjaisille generatiivisille malleille saadaksesi yksityiskohtaisen selityksen prosessista.

Suorituskyvyn optimointi dynaamisen erän avulla

Toistaiseksi olemme puhuneet vain yhdestä syötteestä. Käytännössä odotamme käsittelevän useita pyyntöjä, jotka tulevat satunnaisesti sovellusasiakkailta johtopäätösten tekemiseksi samanaikaisesti tai porrastetusti. Perinteisellä tavalla peruserätyöllä voidaan lisätä suorituskykyä ja GPU:n laskentaresurssien käyttöä. Erätoiminto yhdistää tehokkaasti useamman kuin yhden pyynnön numeeriset esitykset erässä ja suorittaa rinnakkaisia ​​autoregressiivisiä eteenpäinkulkuja. Tämä älykäs annostelu tapahtuu tarjoilupuolella. SageMaker LMI:n DJLServing-palvelin voidaan määrittää yhdistämään useita pyyntöjä käsittelemään niitä rinnakkain asettamalla seuraavat parametrit palvelevat.ominaisuudet:

• max_batch_delay = 100 – Erän yhdistämisen enimmäisviive millisekunteina. Oletusarvo on 100 millisekuntia.
• erä_koko = 32 – Dynaaminen eräkoko. Oletusarvo on 1.

Tämä osoittaa pohjimmiltaan, että DJLServing asettaa pyyntöjä jonoon 100 millisekuntia kerrallaan tai jos jonossa olevien pyyntöjen määrä on määritettyyn batch_size-arvoon asti, erä ajoitetaan ajamaan taustajärjestelmään päätelmiä varten. Tämä tunnetaan nimellä dynamic batching. Se on dynaaminen, koska erän koko voi muuttua erien välillä riippuen siitä, kuinka monta pyyntöä tuona aikana lisättiin. Koska pyynnöillä voi kuitenkin olla erilaisia ​​ominaisuuksia (esimerkiksi jotkin pyynnöt voivat olla muodoltaan 20 syöttötunnusta ja 500 lähtömerkkiä, kun taas toiset voivat olla käänteisiä, 500 syöttötunnusta, mutta vain 20 tulostetta). suorittaa käsittelyn nopeammin kuin muut samassa erässä. Tämä voi johtaa grafiikkasuorittimen vajaakäyttöön odottaessaan, että kaikki erän lennon aikana tehtävät pyynnöt suorittavat dekoodausvaiheen loppuun, vaikka jonossa olisi lisäpyyntöjä, jotka odottavat käsittelyä. Seuraava kaavio havainnollistaa tätä prosessia.

Suorituskyvyn optimointi jatkuvalla eräajolla

Kanssa continuous batching, tunnetaan myös iterative or rolling erässä, hyödynnämme esitäyttö- ja dekoodausvaiheiden välisiä eroja. Jatkuvan eräajon aktivoimiseksi DJServing tarjoaa seuraavat lisäasetukset serving.propertiesin mukaisesti:

• moottori=MPI – Suosittelemme käyttämään MPI-moottoria jatkuvaan annostamiseen.
• option.rolling_batch=auto tai lmi-dist – Suosittelemme käyttämään automaattista, koska se valitsee automaattisesti sopivimman rullaavan eräalgoritmin yhdessä muiden optimointien kanssa tulevaisuudessa.
• option.max_rolling_batch_size=32 – Tämä rajoittaa samanaikaisten pyyntöjen määrää. Oletusarvo on 32.

Jatkuvassa eräajossa tarjoilupino (DJLServing) ei odota, että kaikki erän lennonaikaiset pyynnöt ovat saaneet päätökseen dekoodausvaiheensa. Pikemminkin loogisissa tauoissa (yhden iteraation lopussa dekoodausvaiheessa) se hakee lisäpyyntöjä, jotka odottavat jonossa, kun nykyinen erä on vielä käsittelyssä (tästä nimi rullaava erä). Se tarkistaa odottavat pyynnöt jokaisen dekoodausvaiheen iteraation lopussa. Muista, että jokaista pyyntöä varten meidän on suoritettava esitäyttövaihe, jota seuraa peräkkäinen dekoodausvaihe. Koska voimme käsitellä kaikki pyynnön ensimmäisestä kehotteessa olevat tokenit rinnakkain sen esitäyttövaihetta varten, aina kun uusi pyyntö vedetään sisään, keskeytämme erän lennonaikaisten pyyntöjen dekoodausvaiheen väliaikaisesti – tallennamme tilapäisesti sen KV-välimuistin. ja aktivoinnit muistiin ja suorittaa uusien pyyntöjen esitäyttövaihe.

Tämän välimuistin koko voidaan määrittää seuraavalla vaihtoehdolla:

Kun esitäyttö on valmis, yhdistämme uudet pyynnöt ja vanhat keskeytetyt pyynnöt uudeksi rullaavaksi eräksi, joka voi edetä dekoodausvaiheessaan rinnakkain. Huomaa, että vanhat keskeytetyt pyynnöt voivat jatkaa dekoodausvaihettaan siitä, mihin ne jäivät, ja uudet pyynnöt alkavat ensimmäisestä uudesta tunnuksestaan.

Olet ehkä jo ymmärtänyt, että jatkuva erätyö on lähes samanlainen lähestymistapa, jonka kanssa me luonnollisesti rinnastamme tehtäviä jokapäiväisessä elämässämme. Viestejä, sähköposteja ja puhelinilmoituksia (mahdollisesti uusia pyyntöjä) tulee satunnaisesti (vastaavasti useiden pyyntöjen kanssa, jotka tulevat satunnaisesti porrastettuina GPU:ille). Tämä kaikki tapahtuu samalla, kun suoritamme lennon aikana tehtäviämme – kirjoitamme sähköposteja, koodaamme, osallistumme kokouksiin (analogisesti GPU:ssa tällä hetkellä suoritettavien tehtävien kanssa). Loogisissa tauoissa keskeytämme lennonaikaiset tehtävämme ja tarkistamme ilmoituksemme päättääksemme, tarvitaanko meidän osaltamme toimenpiteitä, ja jos on, lisäämme sen lennonaikaisiin tehtäviimme (todellinen rullaava erä) tai laita se tehtävälistalle (jonoon).

Laita kaikki yhteen: Miten ajatella GPU:iden muistin käyttöä

On suositeltavaa ladata mallisi, jotta näet, mikä kokoonpano on kustannustehokkain yrityksesi käyttöön. Ymmärryksen rakentamiseksi visualisoidaan GPU:iden muistin jalanjälki, kun mallia ladataan ja peräkkäisiä pyyntöjä käsitellään rullaavassa erässä. Tässä viestissä oletetaan, että lataamme Falcon-40B-mallin johonkin G5-ilmentymätyyppiseen ilmentymään, joka on asennettu NVIDIA A10G -grafiikkasuorittimiin, joissa kussakin on 24 Gt muistia. Huomaa, että samanlainen käsitys koskee p3-, p4- ja p5-instanssityyppejä, jotka tulevat V100-, A100- ja H100-grafiikkasuoritinsarjojen mukana.

Seuraavassa on yleiskatsaus Falcon-40B:n palvelemiseen tarvittavan kokonaismuistin likimääräisen arvon saamiseksi:

• Mallin koko = Mallin parametrien määrä (40 miljardia Falcon-40B:lle) x 4 tavua parametria kohden (FP32) = 160 Gt
• Likimääräinen kokonaismuisti, joka tarvitaan Falcon-40B:n lataamiseen päätelmiä varten = Mallin koko (=160 Gt) + KV-välimuisti (Attention Cache) (=*20 Gt) + ML Frameworksin lisämuisti (noin 2 Gt)

Falcon-40B:lle, jos pakkaamme mallin kvantisoimalla mallin bfloat16 (2 tavua) tietotyyppiin, mallin kooksi tulee noin 80 Gt. Kuten näette, tämä on silti suurempi kuin yhden kiihdytinlaitteen tukema muisti, joten meidän on otettava käyttöön mallin osiointi (sharding) tekniikka erityisellä tensorin rinnakkaisuus (TP) lähestyy ja sirpalee mallia useiden kiihdytinlaitteiden välillä. Oletetaan, että olemme valinneet g5.24xlargen, jossa on 4 A10G GPU-laitetta. Jos määritämme DJLServingin (serving.properties) seuraavilla tavoilla, voimme odottaa, että 80 Gt:n mallipainot jaetaan tasan kaikkien 4 GPU:n kesken:

Kanssa tensor_parallel_degree Jos arvoksi on asetettu 4, noin 20 Gt 24 Gt:n GPU-muistista (noin 84 %) on jo käytössä jo ennen kuin yksittäinen pyyntö on käsitelty. Loput 16 % GPU:sta käytetään KV-välimuistiin saapuvia pyyntöjä varten. On mahdollista, että yrityksesi skenaarioon ja sen viive- ja suorituskykyvaatimuksiin 2–3 Gt jäljellä olevasta muistista on enemmän kuin tarpeeksi. Jos ei, voit suurentaa ilmentymän koon g5.48xlargeen, jossa on 8 GPU:ta ja tensor_parallel_degree on asetettu arvoon 8. Tällöin vain noin 10 Gt kunkin GPU:n käytettävissä olevasta 24 Gt:n muistista käytetään mallipainoihin ja me niillä on noin 60 % jäljellä olevasta GPU:sta aktivointia ja KV-välimuistia varten. Intuitiivisesti voimme nähdä, että tämä kokoonpano voi mahdollistaa suuremman suorituskyvyn. Lisäksi, koska meillä on nyt suurempi puskuri, voimme lisätä puskuria max_rolling_batch_prefill_tokens ja max_rolling_batch_size parametreja suorituskyvyn optimoimiseksi edelleen. Yhdessä nämä kaksi parametria ohjaavat mallin aktivoinnin esitäyttöjen ja KV-välimuistin esivarauksia. Suurempi luku näille kahdelle parametrille liittyy suurempaan suorituskykyyn olettaen, että sinulla on tarpeeksi puskuria KV-välimuistia varten GPU-muistissa.

Jatkuva eräajo PagedAttentionilla

PagedAttention on UC Berkeleyn kehittämä uusi optimointialgoritmi, joka parantaa jatkuvaa eräprosessia sallimalla huomiovälimuistin (KV-välimuistin) olla epäyhtenäinen varaamalla muistia kiinteän kokoisille sivuille tai lohkoille. Tämä on saanut inspiraationsa käyttöjärjestelmien käyttämistä virtuaalimuistista ja hakukonsepteista.

Kuten kohti vLLM paperilla kunkin merkkijonon huomiovälimuisti ositetaan lohkoihin ja kartoitetaan fyysisiin lohkoihin lohkotaulukon kautta. Huomion laskennan aikana PagedAttention-ydin voi käyttää lohkotaulukkoa noutaakseen lohkot tehokkaasti fyysisestä muistista. Tämä vähentää merkittävästi muistin hukkaa ja mahdollistaa suuremman eräkoon, paremman GPU-käytön ja suuremman suorituskyvyn.

Suorituskyvyn vertailu

Käyttöönottokokoonpanon tehokkaan kuormitustestauksen varmistamiseksi on suositeltavaa aloittaa ottamalla huomioon liiketoimintaskenaario ja määrittelemällä selkeästi LLM-pohjaisen sovelluksen tulon ja lähdön ominaisuudet. Jos esimerkiksi työskentelet puhelinkeskuksen yhteenvedon käyttötapauksen parissa, syöte voi koostua suuremmasta tekstistä, kuten 500-tunnuksen chat-kopiosta asiakaspalvelun edustajan ja asiakkaan välillä, mutta tulos voi olla suhteellisen pienempi, noin 100 tokeneita, jotka edustavat tiivistelmää transkriptista. Toisaalta, jos työskentelet koodin luomisskenaariossa, syöte voi olla jopa 15 merkkiä, kuten "kirjoita tehokas toteutus Pythonissa kaikkien EC2-resurssien kuvaamiseen, mukaan lukien sivutus", mutta tulos voi olla paljon suurempi, saavuttaen 500 merkkiä. On myös tärkeää harkita, onko alhaisemman viiveen saavuttaminen tai suorituskyvyn maksimointi ensisijainen tavoite tietyssä skenaariossasi.

Saatuaan kattavan ymmärryksen liiketoimintaskenaariosta, voit analysoida ja määrittää optimaalisen kokoonpanon isännöintiympäristöllesi. Tässä yhteydessä isännöintiympäristö sisältää useita avainelementtejä, mukaan lukien ilmentymän tyyppi ja muut konfigurointiparametrit, kuten tensori_rinnakkaisaste, max_rolling_batch_size, max_rolling_batch_prefill_tokens, ja enemmän. Tavoitteenamme on tunnistaa tehokkain kokoonpano, joka tukee vasteaikaa, suorituskykyä ja mallin tulosteen laatuvaatimuksia.

Analyysissamme vertailimme suorituskykyä havainnollistaaksemme jatkuvan eräajon etuja perinteiseen dynaamiseen annosta. Käytimme seuraavassa taulukossa kuvattuja määrityksiä serving.propertiesissa dynaamiseen ja iteratiiviseen eräajoin käyttämällä LMI-säilöä SageMakerissa.

Dynaaminen eränsiirto	Jatkuva eräajo	Jatkuva eräajo PagedAttentionilla
moottori = Python option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 erän_koko=4 max_batch_delay=100 option.trust_remote_code = tosi	moottori = MPI option.model_id = {{s3_url}} option.trust_remote_code = tosi option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = auto option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Väärin	moottori = MPI option.model_id = {{s3_url}} option.trust_remote_code = tosi option.tensor_parallel_degree = 8 option.max_rolling_batch_size = 32 option.rolling_batch = auto option.dtype = fp16 option.max_rolling_batch_prefill_tokens = 1024 option.paged_attention = Totta

Nämä kaksi kokoonpanoa verrattiin Falcon-40B:lle FP16-tietotyypillä, joka on otettu käyttöön ml.g5.48xlargessa parissa eri skenaariossa, jotka edustavat todellisia sovelluksia:

• Pieni määrä syöttötunnuksia ja suuri määrä tunnuksia luodaan – Tässä skenaariossa syöttötunnisteiden määräksi vahvistettiin 32 ja uusia merkkejä luotiin 128

Erästrategia	Suorituskyky (tunteja/s)	Latenssi p90 (s)
Dynaaminen eränsiirto	5.53	58.34
Jatkuva eräajo	56.04	4.74
Jatkuva eräajo PagedAttentionilla	59.18	4.76

• Suuri syöte ja pieni määrä tokeneita luodaan – Tässä vahvistamme syöttötunnisteiden lukumäärän 256:een ja kehotamme LLM:ää tekemään yhteenvedon syötteestä 32 tunnukseksi

Erästrategia	Suorituskyky (tunteja/s)	Latenssi p90 (s)
Dynaaminen eränsiirto	19.96	59.31
Jatkuva eräajo	46.69	3.88
Jatkuva eräajo PagedAttentionilla	44.75	2.67

Voimme nähdä, että jatkuva eränjako PagedAttentionin avulla parantaa suoritustehoa 10 kertaa enemmän skenaariossa 1 ja 2.3 kertaa skenaariossa 2 verrattuna dynaamisen erän käyttämiseen SageMakerissa LMI-säilöä käytettäessä.

Yhteenveto

Tässä viestissä tarkastelimme, kuinka LLM:t käyttävät muistia, ja selitimme, kuinka jatkuva eräkäsittely parantaa suorituskykyä käyttämällä LMI-säilöä SageMakerissa. Osoitimme Falcon-40B:n jatkuvan annostelun edut käyttämällä LMI-säiliötä SageMakerissa näyttämällä vertailutuloksia. Löydät koodin osoitteesta GitHub repo.

---

Tietoja Tekijät

Abhi Shivaditya on AWS:n vanhempi ratkaisuarkkitehti, joka työskentelee strategisten maailmanlaajuisten yritysorganisaatioiden kanssa helpottaakseen AWS-palvelujen käyttöönottoa sellaisilla aloilla kuin tekoäly, hajautettu tietojenkäsittely, verkko ja tallennus. Hänen asiantuntemuksensa on syväoppiminen luonnollisen kielenkäsittelyn (NLP) ja tietokonenäön aloilla. Abhi auttaa asiakkaita ottamaan käyttöön tehokkaita koneoppimismalleja tehokkaasti AWS-ekosysteemissä.

Dhawal Patel on AWS:n koneoppimisarkkitehti. Hän on työskennellyt organisaatioiden kanssa suurista yrityksistä keskikokoisiin startup-yrityksiin hajautettuun tietojenkäsittelyyn ja tekoälyyn liittyvien ongelmien parissa. Hän keskittyy syväoppimiseen, mukaan lukien NLP- ja Computer Vision -alueet. Hän auttaa asiakkaita tekemään korkean suorituskyvyn mallipäätelmiä SageMakerissa.

Pinak Panigrahi työskentelee asiakkaiden kanssa rakentaakseen koneoppimiseen perustuvia ratkaisuja strategisten liiketoimintaongelmien ratkaisemiseksi AWS:ssä. Kun koneoppiminen ei kiinnosta, hänet voi tavata patikoimassa, lukemassa kirjaa tai katsomassa urheilua.

Abhi Sodhani Hän on AWS:n Senior AI/ML Solutions Architect -tehtävä, jossa hän on erikoistunut tarjoamaan asiakkailleen teknistä asiantuntemusta ja ohjausta generatiivisiin tekoäly- ja ML-ratkaisuihin. Hänen ensisijaisena tavoitteenaan on auttaa digitaalisia natiiveja yrityksiä hyödyntämään Generative AI- ja ML-tekniikoiden koko potentiaali, jotta ne voivat saavuttaa liiketoimintatavoitteensa tehokkaasti. Ammatillisten pyrkimystensä lisäksi Abhi osoittaa vahvaa intohimoa älyllisiin harrastuksiin, kuten lukemiseen, sekä fyysistä ja henkistä hyvinvointia edistäviin toimiin, kuten joogaan ja meditaatioon.

Qing Lan on ohjelmistokehitysinsinööri AWS:ssä. Hän on työskennellyt useiden haastavien tuotteiden parissa Amazonissa, mukaan lukien korkean suorituskyvyn ML-johtopäätösratkaisut ja korkean suorituskyvyn lokijärjestelmä. Qingin tiimi lanseerasi onnistuneesti ensimmäisen Billion-parametrin mallin Amazon Advertisingissä erittäin alhaisella latenssilla. Qingillä on syvällinen tietämys infrastruktuurin optimoinnista ja Deep Learning -kiihdytyksestä.

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• PlatoData.Network Vertical Generatiivinen Ai. Vahvista itseäsi. Pääsy tästä.
• PlatoAiStream. Web3 Intelligence. Tietoa laajennettu. Pääsy tästä.
• PlatoESG. hiili, CleanTech, energia, ympäristö, Aurinko, Jätehuolto. Pääsy tästä.
• PlatonHealth. Biotekniikan ja kliinisten kokeiden älykkyys. Pääsy tästä.
• Lähde: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/