Temporal apo Restate për agjentët AI: llogaritni hapat

Zgjidhni Temporal kur agjenti organizohet natyrshëm si Workflow që koordinon Activities dhe ekipi mund të operojë punëtorët që i ekzekutojnë. Dokumentacioni i Temporal për detyrat përshkruan radhët nga të cilat punëtorët marrin punën dhe historikun që përdoret për të rikrijuar gjendjen pas dështimit. Sa shpesh agjenti kalon nëpër këtë mekanizëm ka rëndësi për vonesën dhe koston.

Zgjidhni Restate kur agjenti shkruhet më natyrshëm si funksion ose shërbim me hapa të ruajtur brenda tij, gjendje që vazhdon mes thirrjeve dhe komunikim mes shërbimeve. Dokumentacioni i Restate përshkruan ruajtjen e hapave të përfunduar, rifillimin pas dështimit dhe pritjet me kohëmatës. Për agjentë me shumë veprime, vendimi kërkon të numërohen kufijtë e ruajtjes së përparimit dhe të matet ngarkesa konkrete.

Ku vendoset kufiri i një hapi të qëndrueshëm?

Në Temporal, Workflow mban vendimet e orkestrimit, ndërsa Activities kryejnë punë që mund të përdorë sisteme të jashtme, si thirrjet e modelit ose të mjeteve. Për një Activity të zakonshme, shërbimi krijon detyrën, një punëtor e merr nga radha dhe rezultati regjistrohet përpara se Workflow të vazhdojë. Ky kufi i jep ekipit një mënyrë të qartë për të ndarë koordinimin nga puna e jashtme, si edhe për të shpërndarë kapacitetin e punëtorëve.

Në Restate, hapi i qëndrueshëm mund të qëndrojë brenda funksionit që ekzekuton ciklin e agjentit. Rezultati i një thirrjeje ose i një ndryshimi gjendjeje regjistrohet në journal dhe përdoret gjatë rifillimit, në vend që kodi të përsërisë hapat e përfunduar. Për një agjent që merr kërkesa të njëpasnjëshme me të njëjtin identitet, Virtual Objects shtojnë gjendje për atë identitet dhe kontroll të thirrjeve që mbërrijnë njëkohësisht. Kjo e bën seancën njësi të natyrshme organizimi, ndërsa Workflow mbetet një zgjedhje e vlefshme kur vetë procesi ka faza të qarta.

Kufiri i ruajtjes nuk është domosdoshmërisht i njëjtë me çdo rresht kodi. Në një skenar të kushtëzuar, agjenti mund të marrë përgjigjen e modelit, të kontrollojë rezultatin dhe më pas të thërrasë një mjet. Ekipi duhet të vendosë cilat prej këtyre veprimeve duhen ruajtur veçmas: sa më i imët kufiri, aq më pak punë e përfunduar rrezikon të përsëritet, por aq më shumë veprime të qëndrueshme prodhon ekzekutimi.

Çfarë tregon realisht pretendimi për vonesën?

Në krahasimin e publikuar nga Restate, furnizuesi raporton mbingarkesë vonese nën 10 ms për veprim të qëndrueshëm në percentilin e 99-të nën ngarkesë dhe përshkruan ekzekutime të Replit Agent me mijëra hapa të ruajtur. Këto janë matje dhe shembuj të paraqitur nga Restate; faqja nuk jep një benchmark të pavarur kokë më kokë me të njëjtin agjent, konfigurim dhe ngarkesë në të dy platformat.

Arkitektura shpjegon pse ia vlen ta matni vonesën, por nuk cakton fituesin. Një Activity e zakonshme në Temporal kalon nëpër planifikim dhe marrje nga punëtori; një hap brenda funksionit në Restate regjistrohet pa një punëtor të veçantë për Activity. Temporal ka edhe Local Activities për punë të shkurtër: ato shmangin kalimin në radhën e Activity, por rezultati bëhet i qëndrueshëm kur përfundon Workflow Task. Nëse punëtori ndalet para këtij regjistrimi, puna mund të përsëritet.

Kur një thirrje modeli ose API zgjat shumë më tepër se orkestrimi, vonesa e kufirit mund të ketë pak peshë në kohën totale. Kur agjenti kryen një varg të gjatë kontrollesh dhe veprimesh të shkurtra, e njëjta mbingarkesë përsëritet shpesh. Prandaj matja duhet të dallojë kohën e modelit, pritjen në radhë dhe regjistrimin e hapit; një numër i vetëm për kohën e plotë të agjentit i fsheh këto ndryshime.

Punëtorët, serverless dhe pritjet e gjata

Temporal i përshtatet një ekipi që dëshiron të operojë kapacitet punëtorësh dhe ta ndajë atë sipas radhëve të detyrave. Punëtorët marrin kodin e Workflow dhe Activities, ndaj vendosja e versioneve të reja, shkallëzimi dhe disponueshmëria e tyre bëhen pjesë e funksionimit të agjentit. Në mjedis serverless, modeli i punëtorit vazhdon të ekzistojë: kapaciteti duhet të niset dhe të fillojë të marrë detyra kur ato mbërrijnë.

Restate thërret handler-at e shërbimit dhe ruan përparimin kur ekzekutimi pezullohet. Një pritje për kohëmatës ose ngjarje të jashtme mund të zgjasë pa mbajtur aktiv procesin e aplikacionit gjatë gjithë intervalit. Edhe Temporal mbështet procese që presin me muaj; kohëzgjatja, e marrë veçmas, nuk vendos mes platformave. Për një proces të tillë rëndësi kanë mënyra si rifillon kodi, ku mbahet gjendja dhe çfarë infrastrukture duhet të mirëmbajë ekipi gjatë pritjes.

Faturimi ndryshon bashkë me mënyrën e vendosjes

Temporal Cloud i faturon veprimet dhe ruajtjen e historikut. Restate BYOC përdor çmim sipas kapacitetit të rezervuar, ndërsa Restate Cloud ka model faturimi sipas përdorimit. Një krahasim mes Temporal Cloud dhe Restate BYOC përzien një shërbim me tarifë për veprim me një vendosje me kapacitet të rezervuar; rezultati varet nga volumi i qëndrueshëm, kapaciteti i papërdorur dhe shpenzimet e infrastrukturës. Vlerësimet e kursimit të publikuara nga Restate janë llogaritje të furnizuesit sipas supozimeve të tij, jo çmim i garantuar për një agjent tjetër.

Për një ekzekutim, numëroni nisjen, përfundimin, thirrjet, kohëmatësit dhe hapat e ndërmjetëm sipas njësive që faturon oferta përkatëse. Shtoni madhësinë dhe kohën e ruajtjes së historikut ose gjendjes, si edhe kapacitetin e nevojshëm në orët e pikut. Nëse vetëhostimi është kusht, të dy sistemet e lejojnë, por fatura përfshin edhe mirëmbajtjen, kopjet për rikuperim dhe kapacitetin e aplikacionit. Një çmim i ulët për veprim nuk përshkruan vetë koston e plotë të operimit.

Pema e vendimit për agjentin

Nëse procesi ndahet qartë në orkestrimin e Workflow dhe punë të jashtme si Activities, dhe ekipi ka kapacitet për punëtorë, niseni vlerësimin me Temporal. Vonesa e radhës dhe sjellja gjatë rifillimit janë matjet kryesore.
Nëse cikli i agjentit ka mijëra hapa të vegjël që duhen ruajtur brenda funksionit, niseni me Restate. Matni sa shpesh regjistrohet përparimi dhe sa punë përsëritet pas një ndërprerjeje.
Nëse vendosja është kryesisht serverless, përfshini nisjen nga gjendja e ftohtë dhe kufijtë e mjedisit ku ekzekutohet kodi. Krahasoni nisjen e punëtorit në Temporal me thirrjen e handler-it në Restate.
Nëse agjenti pret me muaj ose duhet të vetëhostohet, vlerësoni veçmas pritjen e qëndrueshme dhe barrën e operimit. Asnjëra prej këtyre kërkesave, e vetme, nuk e përcakton platformën.

Prova që e kthen krahasimin në vendim

Përdorni të njëjtin cikël agjenti, të njëjtat thirrje të jashtme dhe kufij rikuperimi me kuptim të krahasueshëm. Një provë me përgjigje të fiksuara nga modeli izolon vonesën e orkestrimit; një provë me shërbimet reale tregon vonesën që përjeton përdoruesi. Regjistroni kohën për hap, kohën totale, pritjen në radhë, nisjen e ftohtë dhe percentilat nën ngarkesë. Shënoni edhe numrin e veprimeve të faturueshme për një ekzekutim të përfunduar.

Ndërpriteni procesin si para, ashtu edhe pas regjistrimit të një hapi dhe shihni cilat veprime kryhen sërish. Për thirrjet me efekt të jashtëm, provoni edhe çfarë ndodh kur shërbimi tjetër e ka pranuar kërkesën, por rezultati nuk është regjistruar ende; aty identifikuesit e kërkesës dhe idempotenca kanë rëndësi. Përsëriteni provën me paralelizmin, numrin e hapave dhe pritjet e gjata që prisni në prodhim. Këto rezultate lidhin vonesën, rikuperimin dhe faturën me sjelljen e agjentit tuaj.

Lexoni gjithashtu: