A Falcon modellek teljesítményének javítása az Amazon SageMaker | Amazon webszolgáltatások

Mi az optimális keretrendszer és konfiguráció nagy nyelvi modellek (LLM) tárolására szöveggeneratív AI-alkalmazásokhoz? Az LLM-ek kiszolgálásának rengeteg lehetősége ellenére ez nehéz kérdés megválaszolása a modellek mérete, a változó modellarchitektúra, az alkalmazások teljesítménykövetelményei és egyebek miatt. A Amazon SageMaker Large Model Inference (LMI) konténer egyszerűvé teszi az LLM-ek kiszolgálását azáltal, hogy egy sor különféle keretrendszert és technikát egyesít, amelyek optimalizálják az LLM-ek telepítését. Az LMI konténerben van egy nagy teljesítményű kiszolgáló verem, az úgynevezett DJL felszolgálás ami agnosztikus a mögöttes LLM-mel szemben. Rendszerszintű konfigurációs paramétereket biztosít, amelyek hangolhatók az adott LLM tárhely-infrastruktúrájának legjobb teljesítményének eléréséhez. Támogatja a legújabb optimalizálásokat is, például a folyamatos kötegelést, más néven iteratív kötegelést vagy gördülő kötegelést, amely jelentős javulást biztosít az átviteli sebességben.

Egy korábban Hozzászólás, megmutattuk, hogyan használhatja az LMI-tárolót a Falcon modellcsalád telepítéséhez a SageMakeren. Ebben a bejegyzésben bemutatjuk, hogyan javítható a Falcon-40B kiszolgálásának átvitele és késleltetése olyan technikákkal, mint a folyamatos kötegelés. A SageMaker LMI konténer által biztosított konfigurációs paraméterek intuitív megértését is biztosítjuk, amely segíthet megtalálni a valós alkalmazáshoz legjobb konfigurációt.

A szöveggeneratív következtetés alapjai LLM-ek számára

Először nézzünk meg néhány alapvetést arról, hogyan lehet következtetéseket levonni az LLM-ek számára szöveggeneráláshoz.

Továbbítás, aktiválások és a KV gyorsítótár

Adott egy bemeneti tokenek sorozatot, ezek lefutnak a forward pass az LLM összes rétegén (például a Falconon) a következő token generálásához. A forward pass a bemeneti adatok neurális hálózaton való áthaladásának folyamatára utal, hogy kimenetet állítsanak elő. Szöveggenerálás esetén az előrelépés magában foglalja egy kezdeti mag vagy kontextus betáplálását a nyelvi modellbe, és a következő karaktert vagy tokent generálja a sorozatban. Szövegsorozat létrehozásához a folyamat gyakran iteratív módon történik, ami azt jelenti, hogy a kimeneti sorozat minden lépésénél vagy pozíciójában megismétlődik. A modell minden iterációnál előállítja a következő karaktert vagy tokent, amely a generált szöveg részévé válik, és ez a folyamat addig folytatódik, amíg a kívánt hosszúságú szöveget el nem állítják.

Szöveggenerálás olyan nyelvi modellekkel, mint a Falcon vagy a GPT autoregressive. Ez azt jelenti, hogy a modell egyszerre egy tokent generál, miközben kondicionálja a korábban generált tokeneket. Más szóval, a modell minden iterációnál az előzőleg generált szöveget veszi bemenetként, és ennek alapján jósolja meg a következő tokent. Mint említettük vLLM: Egyszerű, gyors és olcsó LLM kiszolgálás PagedAttention mellettEbben az autoregresszív dekódolási folyamatban az LLM összes bemeneti tokenje előállítja a figyelemkulcs- és értéktenzorait, és ezeket a tenzorokat a GPU memóriájában tartják a következő tokenek létrehozásához. Ezeket a gyorsítótárazott kulcs- és értéktenzorokat gyakran a KV cache.

Előtöltési és dekódolási fázisok

Az autoregresszív dekódolási folyamatban, mint amilyen a szöveggenerálásnál olyan nyelvi modellekkel, mint a Falcon, jellemzően két fő fázis van: prefill fázis és a decode fázis. Ezek a fázisok kulcsfontosságúak a koherens és kontextuálisan releváns szöveg létrehozásához.

Az előtöltési szakasz a következőket tartalmazza:

• Kezdeti kontextus – Az előtöltési fázis a felhasználó által megadott kezdeti kontextussal vagy kezdőszöveggel kezdődik. Ez a kezdeti kontextus lehet egy mondat, egy kifejezés vagy akár egyetlen szó is. Megadja a szöveggenerálás kiindulópontját, és kontextust biztosít a következő eseményekhez.
• Modell kondicionálás – A megadott kontextus a nyelvi modell kondicionálására szolgál. A modell ezt a kontextust veszi bemenetként, és a kontextus megértése alapján generálja a következő tokent (szót vagy karaktert) a sorozatban.
• Token generáció – A modell egy-egy tokent generál, előre jelezve, hogy mi következik a szövegben. Ez a token a kontextushoz van csatolva, hatékonyan kiterjesztve azt.
• Iteratív folyamat – A tokenek létrehozásának folyamata iteratív módon ismétlődik. A modell minden lépésben létrehoz egy tokent, miközben figyelembe veszi a frissített kontextust, amely most tartalmazza az előző lépésekben generált tokeneket.

Az előtöltési fázis addig tart, amíg egy előre meghatározott leállási feltétel teljesül. Ez a feltétel lehet a generált szöveg maximális hossza, egy adott token, amely a szöveg végét jelzi, vagy bármely más, a felhasználó vagy az alkalmazás által beállított feltétel.

A dekódolási fázis a következőket tartalmazza:

• Befejezés – Az előtöltési fázis után egy részben generált szöveget kap, amely esetleg hiányos vagy egy ponton le van vágva. A dekódolási fázis felelős a szöveg kiegészítéséért, hogy az koherens és nyelvtanilag helyes legyen.
• Folytatás az utolsó tokentől – A dekódolási fázisban a modell az előtöltési fázisban utoljára generált tokentől indul. Ezt a tokent használja kezdeti kontextusként, és létrehozza a következő tokent a szöveg folytatásához.
• Iteratív befejezés – Az előtöltési fázishoz hasonlóan a tokenek generálásának folyamata ismét iteratív. A modell egyszerre egy-egy tokent állít elő, a szekvencia előző tokenjein kondicionálva.
• Leállási feltétel – A dekódolási fázisnak van egy leállási feltétele is, amely ugyanaz lehet, mint az előtöltési fázisban, például eléri a maximális hosszt vagy találkozik egy szövegvégi tokennel. Ha ez a feltétel teljesül, a generálási folyamat leáll.

Az előtöltési és dekódolási fázisok kombinációja lehetővé teszi, hogy az autoregresszív modellek olyan szöveget állítsanak elő, amely egy kezdeti kontextusra épül, és koherens, kontextus szempontjából releváns és kontextuálisan konzisztens szövegsorozatokat hoz létre.

Hivatkozni Elosztott kiszolgáló rendszer transzformátor alapú generatív modellekhez a folyamat részletes ismertetéséhez.

Az átviteli sebesség optimalizálása dinamikus kötegelés segítségével

Eddig csak egyetlen bemenetről beszéltünk. A gyakorlatban azt várjuk, hogy az alkalmazás klienseitől véletlenszerűen érkező kéréseket párhuzamosan vagy lépcsőzetesen kezeljük a következtetések levonására. A hagyományos módon az alap kötegelés segítségével növelhető az átviteli sebesség és a GPU számítási erőforrásainak kihasználtsága. A kötegelés hatékonyan kombinálja egy kötegben egynél több kérelem numerikus megjelenítését, és párhuzamosan hajtja végre az autoregresszív előrelépéseket. Ez az intelligens adagolás a kiszolgálási oldalon történik. A SageMaker LMI DJLServing szervere a következő paraméterek beállításával konfigurálható úgy, hogy több kérést kötegeljen össze, hogy párhuzamosan dolgozza fel azokat. kiszolgáló.tulajdonságok:

• max_batch_delay = 100 – A kötegösszesítés maximális késleltetése ezredmásodpercben. Az alapértelmezett érték 100 ezredmásodperc.
• csomó méret = 32 – A dinamikus kötegméret. Az alapértelmezett az 1.

Ez alapvetően azt mutatja, hogy a DJLServing egyszerre 100 ezredmásodpercig állítja sorba a kéréseket, vagy ha a sorba állított kérelmek száma eléri a megadott batch_size értéket, akkor a köteg úgy lesz ütemezve, hogy lefusson a háttérben a következtetések levonására. Ez az úgynevezett dynamic batching. Dinamikus, mert a köteg mérete a kötegek között változhat attól függően, hogy hány kérést adtak hozzá az adott időtartam alatt. Mivel azonban a kérések eltérő jellemzőkkel rendelkezhetnek (például egyes kérések 20 bemeneti és 500 kimeneti token alakúak lehetnek, míg mások megfordulhatnak, 500 bemeneti tokennel, de csak 20 kimenettel), egyes kérések lehetnek gyorsabban fejezze be a feldolgozást, mint az azonos köteg többi része. Ez a GPU kihasználatlanságát eredményezheti, miközben arra vár, hogy a köteg összes futás közbeni kérése befejezze a dekódolási szakaszt, még akkor is, ha további kérések várnak feldolgozásra a sorban. A következő diagram ezt a folyamatot szemlélteti.

Az áteresztőképesség optimalizálása folyamatos kötegelés segítségével

A continuous batching, más néven iterative or rolling kötegelés, kihasználjuk az előtöltési és dekódolási szakasz közötti különbségeket. A folyamatos kötegelés aktiválásához a DJServing a következő további konfigurációkat biztosítja a serving.properties szerint:

• motor=MPI – Javasoljuk, hogy az MPI-motort használja a folyamatos kötegeléshez.
• option.rolling_batch=auto vagy lmi-dist – Az auto használatát javasoljuk, mert a jövőben automatikusan kiválasztja a legmegfelelőbb gördülő kötegelt algoritmust, más optimalizálásokkal együtt.
• opció.max_rolling_batch_size=32 – Ez korlátozza az egyidejű kérések számát. Az alapértelmezett a 32.

Folyamatos kötegelés esetén a kiszolgáló verem (DJLServing) nem várja meg, hogy egy köteg összes futás közbeni kérése befejezze a dekódolási szakaszt. Inkább logikai szünetekben (egy iteráció végén a dekódolási szakaszban) további kéréseket von be, amelyek a sorban várakoznak, miközben az aktuális köteg még feldolgozás alatt áll (innen a név gördülő tétel). Ellenőrzi a függőben lévő kéréseket a dekódolási szakasz minden iterációjának végén. Ne feledje, hogy minden kérésnél le kell futtatnunk az előtöltési szakaszt, amelyet a szekvenciális dekódolási szakasz követ. Mivel a kérés kezdeti promptjából származó összes tokent párhuzamosan tudjuk feldolgozni annak előkitöltési szakaszában, bármikor új kérést vonnak be, ideiglenesen szüneteltetjük a köteg repülés közbeni kérelmeinek dekódolási szakaszát – ideiglenesen elmentjük a KV gyorsítótárat. és aktiválások a memóriában, és futtassa az új kérések előtöltési szakaszát.

A gyorsítótár mérete a következő opcióval állítható be:

Amikor az előtöltés befejeződött, az új kéréseket és a régi szüneteltetett kéréseket egy új gördülő kötegben egyesítjük, amelyek párhuzamosan folytathatják a dekódolási szakaszukat. Vegye figyelembe, hogy a régi szüneteltetett kérések folytathatják a dekódolási szakaszt ott, ahol abbahagyták, és az új kérések az első új tokenjüktől indulnak.

Talán már rájött, hogy a folyamatos kötegelés szinte hasonló megközelítés, amellyel a mindennapi életünkben természetesen párhuzamosítjuk a feladatokat. Üzeneteink, e-mailjeink, telefonos értesítéseink (potenciálisan új kérések) véletlenszerű időpontokban érkeznek (hasonlóan a GPU-k esetében véletlenszerűen, lépcsőzetesen érkező több kéréssel). Mindez akkor történik, amikor a repülés közbeni feladatainkat teljesítjük – e-maileket írunk, kódolunk, részt veszünk az értekezleteken (hasonlóan a GPU-k aktuális feldolgozási feladataihoz). A logikai szünetekben szüneteltetjük a repülés közbeni feladatainkat, és ellenőrizzük az értesítéseinket, hogy eldöntsük, van-e valamilyen intézkedés szükséges a részünkről, és ha igen, hozzáadjuk a repülés közbeni feladatainkhoz (valós életben futó köteg), ill. tedd fel a teendők listájára (a sorba).

Összefoglalva: Hogyan gondolkodjunk a GPU-k memóriahasználatáról

Javasoljuk, hogy töltse le a modellt, hogy megtudja, melyik konfiguráció a legköltséghatékonyabb az Ön üzleti felhasználása szempontjából. A megértés érdekében vizualizáljuk a GPU-k memóriaterületét a modell betöltésekor és az egymást követő kérések gördülő kötegben történő feldolgozása során. Ebben a bejegyzésben tegyük fel, hogy a Falcon-40B modellt betöltjük az egyik olyan G5 példány típusú példányra, amely NVIDIA A10G GPU-kkal van telepítve, mindegyik 24 GB memóriával. Vegye figyelembe, hogy hasonló felfogás érvényes a p3, p4 és p5 példánytípusokra, amelyek a V100, A100 és H100 GPU sorozathoz tartoznak.

Az alábbiakban áttekintjük a Falcon-40B kiszolgálásához szükséges teljes memória hozzávetőleges értékét:

• Modellméret = Modellparaméterek száma (40 milliárd Falcon-40B esetén) x 4 bájt paraméterenként (FP32 esetén) = 160 GB
• Hozzávetőleges teljes memória szükséges a Falcon-40B betöltéséhez a következtetéshez = Modellméret (=160 GB) + KV-gyorsítótár (figyelemgyorsítótár) (=*20 GB) + többletmemória az ML-keretrendszer által (körülbelül 2 GB)

A Falcon-40B esetében, ha a modellt bfloat16 (2 bájt) adattípusra kvantálva tömörítjük, a modell mérete körülbelül 80 GB lesz. Mint látható, ez még mindig nagyobb, mint egy gyorsítóeszköz által támogatott memória, ezért egy modellparticionálási (sharding) technikát kell alkalmaznunk egy speciális eszközzel. tenzor párhuzamosság (TP) megközelíti és feldarabolja a modellt több gyorsítóeszközön keresztül. Tegyük fel, hogy a g5.24xlarge-ot választottuk, amiben 4 db A10G GPU van. Ha a DJLServing-et (serving.properties) a következőkkel konfiguráljuk, akkor arra számíthatunk, hogy a 80 GB-os modellsúly egyenlően oszlik el mind a 4 GPU között:

A tensor_parallel_degree 4-re állítva, a 20 GB-os GPU-memória körülbelül 24 GB-a (körülbelül 84%) már az egyetlen kérés feldolgozása előtt is kihasználva van. A GPU fennmaradó 16%-át a KV gyorsítótár fogja használni a bejövő kérésekhez. Lehetséges, hogy az üzleti szcenárióhoz, valamint annak késleltetési és átviteli követelményeihez a fennmaradó memória 2–3 GB több mint elegendő. Ha nem, akkor növelheti a példány méretét g5.48xlarge-ra, amely 8 GPU-val rendelkezik, és a tensor_parallel_degree értéket 8-ra használja. Ilyen esetben az egyes GPU-k rendelkezésre álló 10 GB-os memóriájából csak körülbelül 24 GB-ot használunk fel a modellsúlyokhoz, és mi a fennmaradó GPU körülbelül 60%-a az aktiváláshoz és a KV gyorsítótárhoz. Intuitív módon láthatjuk, hogy ez a konfiguráció nagyobb átviteli sebességet tesz lehetővé. Ezenkívül, mivel most nagyobb pufferünk van, növelhetjük a max_rolling_batch_prefill_tokens és a max_rolling_batch_size paramétereket az átviteli sebesség további optimalizálásához. Ez a két paraméter együtt fogja vezérelni a modell aktiválási előtöltéseinek és KV-gyorsítótárának előzetes kiosztását. E két paraméter nagyobb száma nagyobb átviteli sebességet jelent, feltéve, hogy elegendő puffer van a KV gyorsítótár számára a GPU memóriájában.

Folyamatos kötegelés PagedAttention segítségével

A PagedAttention az UC Berkeley által kifejlesztett új optimalizálási algoritmus, amely javítja a folyamatos kötegelési folyamatot azáltal, hogy lehetővé teszi, hogy a figyelem gyorsítótár (KV cache) ne legyen egybefüggő azáltal, hogy rögzített méretű oldalakon vagy blokkokban memóriát foglal le. Ezt az operációs rendszerek által használt virtuális memória és lapozási koncepciók ihlették.

Mint a vLLM papíron, az egyes tokenek sorozatok figyelmi gyorsítótárát blokkokra particionáljuk, és egy blokktáblázaton keresztül fizikai blokkokra képezzük le. A figyelem számítása során a PagedAttention kernel a blokktáblázat segítségével hatékonyan lekérheti a blokkokat a fizikai memóriából. Ez jelentősen csökkenti a memóriapazarlást, és nagyobb kötegméretet, nagyobb GPU-kihasználást és nagyobb átvitelt tesz lehetővé.

Teljesítmény-összehasonlítás

A telepítési konfiguráció hatékony terhelési tesztelésének biztosítása érdekében ajánlott az üzleti forgatókönyv átgondolásával kezdeni, és egyértelműen meghatározni az LLM-alapú alkalmazás bemeneti és kimeneti jellemzőit. Például, ha egy call center-összefoglaló használati eseten dolgozik, a bemenet állhat nagyobb szövegből, például egy 500 tokenből álló csevegési átiratból az ügyfélszolgálati ügynök és az ügyfél között, de a kimenet viszonylag kisebb, körülbelül 100 tokenek, amelyek az átirat összefoglalását jelentik. Másrészt, ha kódgenerálási forgatókönyvön dolgozik, a bemenet akár 15 tokenből is állhat, például „írjon hatékony megvalósítást Pythonban az összes EC2 erőforrás leírásához, beleértve a lapozást is”, de a kimenet sok lehet. nagyobb, elérve az 500 tokent. Azt is fontos mérlegelni, hogy az alacsonyabb késleltetés elérése vagy az átviteli sebesség maximalizálása a legfontosabb prioritás az adott forgatókönyvben.

Az üzleti forgatókönyv átfogó megértése után elemezheti és meghatározhatja a tárhelykörnyezet optimális konfigurációját. Ebben az összefüggésben a tárhelykörnyezet számos kulcselemet foglal magában, beleértve a példánytípust és egyéb konfigurációs paramétereket, mint pl. tenzor_párhuzamos_fok, max_rolling_batch_size, max_rolling_batch_prefill_tokens, és több. Célunk, hogy megtaláljuk a leghatékonyabb beállítást a válaszidő, átviteli sebesség és modell kimeneti minőségi követelményeink támogatásához.

Elemzésünkben összehasonlítottuk a teljesítményt, hogy bemutassuk a folyamatos kötegelés előnyeit a hagyományos dinamikus kötegeléshez képest. A következő táblázatban részletezett konfigurációkat használtuk a serving.properties-ben a dinamikus kötegelés és az iteratív kötegelés során, a SageMaker LMI-tárolójának használatával.

Dinamikus kötegelés	Folyamatos adagolás	Folyamatos kötegelés PagedAttention segítségével
engine=Python option.model_id=tiiuae/falcon-40b option.tensor_parallel_degree=8 option.dtype=fp16 batch_size=4 max_batch_delay=100 option.trust_remote_code = igaz	motor = MPI option.model_id = {{s3_url}} option.trust_remote_code = igaz 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 = Hamis	motor = MPI option.model_id = {{s3_url}} option.trust_remote_code = igaz 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 = Igaz

A két konfigurációt a Falcon-40B-hez hasonlították össze az ml.g16xlarge oldalon telepített FP5.48 adattípussal, néhány különböző forgatókönyvben, amelyek valós alkalmazásokat képviselnek:

• Kis számú bemeneti token nagy számú token generálásával – Ebben a forgatókönyvben a bemeneti tokenek számát 32-ben rögzítették, és 128 új token keletkezett

Kötegelési stratégia	Átbocsátási sebesség (token/s)	Késés p90 (mp)
Dinamikus kötegelés	5.53	58.34
Folyamatos adagolás	56.04	4.74
Folyamatos kötegelés PagedAttention segítségével	59.18	4.76

• Nagy bemenet, kevés számú token generálásával – Itt rögzítjük a bemeneti tokenek számát 256-ban, és felszólítjuk az LLM-et, hogy összegezze a bevitelt 32 tokenre

Kötegelési stratégia	Átbocsátási sebesség (token/s)	Késés p90 (mp)
Dinamikus kötegelés	19.96	59.31
Folyamatos adagolás	46.69	3.88
Folyamatos kötegelés PagedAttention segítségével	44.75	2.67

Láthatjuk, hogy a PagedAttention segítségével történő folyamatos kötegelés az 10. forgatókönyvben 1-szer, a 2.3. forgatókönyvben 2-szoros átviteli javulást biztosít, mint a SageMakerben az LMI-tároló használata közbeni dinamikus kötegelés.

Következtetés

Ebben a bejegyzésben megvizsgáltuk, hogy az LLM-ek hogyan használják a memóriát, és elmagyaráztuk, hogyan javítja a folyamatos kötegelés az átviteli sebességet egy LMI-tároló használatával a SageMakeren. Bemutattuk a folyamatos adagolás előnyeit a Falcon-40B esetében a SageMaker LMI konténer használatával, összehasonlító eredmények bemutatásával. A kódot megtalálod a GitHub repo.

---

A szerzőkről

Abhi Shivaditya az AWS vezető megoldástervezője, stratégiai globális vállalati szervezetekkel dolgozik együtt, hogy elősegítse az AWS-szolgáltatások alkalmazását olyan területeken, mint a mesterséges intelligencia, az elosztott számítástechnika, a hálózatépítés és a tárolás. Szakértelme a Deep Learning területén rejlik a természetes nyelvi feldolgozás (NLP) és a számítógépes látás területén. Az Abhi segít az ügyfeleknek a nagy teljesítményű gépi tanulási modellek hatékony telepítésében az AWS ökoszisztémán belül.

Dhawal Patel az AWS vezető gépi tanulási építésze. Az elosztott számítástechnikával és a mesterséges intelligenciával kapcsolatos problémákon a nagyvállalatoktól a közepes méretű induló vállalkozásokig szervezetekkel dolgozott együtt. A mély tanulásra összpontosít, beleértve az NLP és a Computer Vision tartományokat. Segít az ügyfeleknek abban, hogy a SageMaker-en nagy teljesítményű modellkövetkeztetést érjenek el.

Pinak Panigrahi együttműködik az ügyfelekkel, hogy gépi tanulásra támaszkodó megoldásokat építsenek a stratégiai üzleti problémák megoldására az AWS-en. Ha nem a gépi tanulással van elfoglalva, akkor kirándulni, könyvet olvasni vagy sportokat nézni.

Abhi Sodhani Az AWS vezető AI/ML megoldások építészei pozícióját tölti be, ahol arra specializálódott, hogy műszaki szakértelmet és útmutatást kínáljon az ügyfelek számára a generatív AI és ML megoldásokhoz. Elsődleges célja, hogy segítse a digitális natív vállalkozásokat a Generative AI és ML technológiák teljes potenciáljának kiaknázásában, lehetővé téve számukra üzleti céljaik hatékony elérését. Szakmai törekvésein túl Abhi erős szenvedélyt mutat az olyan intellektuális tevékenységek iránt, mint az olvasás, valamint olyan tevékenységeket folytat, amelyek elősegítik a fizikai és szellemi jólétet, mint például a jóga, a meditáció.

Qing Lan az AWS szoftverfejlesztő mérnöke. Számos kihívást jelentő terméken dolgozott az Amazonban, beleértve a nagy teljesítményű ML következtetési megoldásokat és a nagy teljesítményű naplózási rendszert. Qing csapata sikeresen elindította az Amazon Advertising első milliárdos paraméterű modelljét, nagyon alacsony késleltetéssel. Qing mélyreható ismeretekkel rendelkezik az infrastruktúra optimalizálásával és a Deep Learning gyorsításával kapcsolatban.

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
• PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
• PlatoESG. Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
• PlatoHealth. Biotechnológiai és klinikai vizsgálatok intelligencia. Hozzáférés itt.
• Forrás: https://aws.amazon.com/blogs/machine-learning/improve-performance-of-falcon-models-with-amazon-sagemaker/