LiteLLM թե Portkey․ 4 մվ արագությունը դեռ չի վճարում կառավարման գինը

|Հեղինակ: QUASA-ի խմբագրական թիմ|6 րոպե ընթերցանություն| 1
LiteLLM թե Portkey․ 4 մվ արագությունը դեռ չի վճարում կառավարման գինը

Եթե ինքնատեղակայվող LLM gateway-ի ընտրության գլխավոր չափանիշը լռելյայն կազմաձևի արագությունն է, այս փորձարկման առավելությունը Portkey-ինն է։ Markaicode-ի տեղային փորձարկման մեջ նույն 200 մվ ուշացումով կեղծ backend-ի նկատմամբ Portkey-ի բաց gateway-ն մեկ հարցման p50 ուշացմանն ավելացրել է 4,1 մվ՝ կլորացված 4 մվ, LiteLLM-ը՝ 9,3 մվ, իսկ 40 զուգահեռ հարցման թողունակությունը եղել է համապատասխանաբար 164,5 և 96 հարցում վայրկյանում։

Եթե թիմին պետք են բազմաթիվ մատակարարների միավորում, վիրտուալ բանալիներ և ինքնուրույն կառավարվող ծախսային սահմաններ, LiteLLM-ը գործնական ընտրություն է։ Եթե առաջնային են երթուղավորման կանոններն ու հարցումների բովանդակության ստուգումը, Portkey-ի բաց gateway-ն ուժեղ թեկնածու է։ Երկուսի դեպքում էլ արագության առավելությունը պետք է կշռել այն աշխատանքի դիմաց, որն անհրաժեշտ է բյուջեները, մատյանները, հասանելիությունն ու ծառայության անխափան աշխատանքը կառավարելու համար։

Ինչ է չափում արագության համեմատությունը

Հրապարակված թվերը նկարագրում են gateway-ի ավելացրած ուշացումն ու թողունակությունը մեկ մեքենայի վրա, որտեղ երկու ծրագիրն էլ դիմել են նույն կեղծ OpenAI-համատեղելի backend-ին։ Մեկ հարցման p50-ը միջնարժեքն է. այն ցույց է տալիս, թե տվյալ փորձի հարցումների կեսն ինչ ուշացման սահմանում է ավարտվել։ Զուգահեռ փորձի թողունակությունը այլ հարցի է պատասխանում՝ որքան աշխատանք է ավարտվել ծանրաբեռնվածության պայմաններում։ Արագ միակ հարցումը և մեծ հոսքին դիմանալը նույն հատկությունը չեն։

LiteLLM-ը գործարկվել է լռելյայն մեկ worker-ով, Portkey-ի բաց gateway-ն՝ մեկ պրոցեսով։ Հետևաբար ծանրաբեռնվածության տարբերությունը նախ վերաբերում է հենց այդ կազմաձևերին, ոչ թե բոլոր հնարավոր տեղակայումներին։ Արտաքին մատակարարի ցանցային ուշացումը, իրական մոդելի աշխատանքի տատանումները, հոսքային պատասխանը և միացված guardrail-ի արժեքը այդ տեղային փորձի մեջ չեն չափվել։ Եթե թիմի ծառայության համար կարևոր են հերթերն ու դանդաղ հարցումները, օգտակար է նույն երթուղիները համեմատել իր իրական բեռով և հավասարեցված worker-ների քանակով։

Մատակարարների ծածկույթը և պահուստային երթուղին

LiteLLM-ի առավելությունն այն է, որ տարբեր մատակարարների API-ները հավաքում է մեկ OpenAI-համատեղելի միջերեսի շուրջ։ LiteLLM-ի պաշտոնական ուղեցույցը նշում է 100-ից ավելի LLM մատակարար, վիրտուալ բանալիներ, ծախսերի գրանցում, retry ու fallback երթուղիներ, իսկ SSO-ն և audit logs-ը ներկայացնում է Enterprise առաջարկի շրջանակում։ Լայն ծածկույթը հատկապես օգտակար է, երբ թիմը հաճախ է փոխում մատակարարին կամ օգտագործում է մի քանի ծառայության մոդելներ։ Այնուամենայնիվ, միասնական API-ն ինքնաբերաբար չի նույնացնում յուրաքանչյուր մոդելի հատուկ պարամետրերն ու պատասխանի ձևը։

Portkey-ի բաց gateway-ի պահոցը փաստագրում է տեղային գործարկում, retry, fallback, բեռի բաշխում, պայմանական երթուղավորում, guardrail-ներ և տեղային մատյանները ցուցադրող console։ Այստեղ կարևոր է ստուգել ոչ միայն այն, թե հիմնական մատակարարը հասանելի է, այլ նաև թե որ պայմանով է հարցումն անցնում պահուստային երթուղու։ Մատակարարի փոխարինումը կարող է փոխել գինը, թույլատրելի պարամետրերը կամ պատասխանի կառուցվածքը, թեև հավելվածը շարունակում է դիմել նույն gateway-ին։ Մատակարարների թվի և աջակցվող մոդելների թվի միջև էլ ուղիղ հավասարություն չկա. ընտրության համար վճռորոշ են թիմի իրական երթուղիները։

Բյուջեն աշխատեցնում է լրացուցիչ ենթակառուցվածք

LiteLLM-ում բանալու, թիմի կամ օգտվողի ծախսային սահմանը արժեքավոր է, երբ մի gateway-ից օգտվում են տարբեր ծառայություններ և հարկավոր է ծախսը վերագրել ճիշտ պատասխանատուին։ Սակայն բյուջեների պաշտոնական փաստաթղթավորումը պահանջում է PostgreSQL տվյալների բազա և զգուշացնում, որ առանց դրա սահմանված ընդհանուր բյուջեն չի կանգնեցնում հարցումները, իսկ վիրտուալ բանալիների ու թիմերի բյուջեները հասանելի չեն։ Ուստի proxy-ն գործարկելն ու ծախսային սահմանը իրականում պարտադրելը տարբեր ծավալի աշխատանքներ են։

Տվյալների բազան իր հերթին պահանջում է հասանելիության վերահսկում, պահուստավորում, թարմացումներ և խափանման ընթացակարգ։ Ծախսերի ցուցադրումը ևս պետք է տարբերել կանխարգելիչ սահմանափակումից. հաշվետվությունը ցույց է տալիս արդեն կատարված օգտագործումը, մինչդեռ սահմանը պետք է որոշի հաջորդ հարցման ընդունումը։ Եթե ծախսային շեմը թիմի համար պարտադիր կանոն է, տեղակայման արժեքի մեջ մտնում են նաև դրա հետևողական կիրառումն ու սխալների մշտադիտարկումը։ Դա կարող է ավելի մեծ շահագործման պարտավորություն լինել, քան gateway-ի ավելացրած մի քանի միլիվայրկյանը։

Guardrail-ը, մատյանը և աուդիտը տարբեր խնդիրներ են

Portkey-ի բաց gateway-ի guardrail-ը կարող է կանոն կիրառել հարցման կամ պատասխանի բովանդակության նկատմամբ, իսկ տեղային console-ը օգնում է տեսնել հարցումների մատյանները։ Սա օգտակար է կիրառական վերահսկման համար, հատկապես երբ երթուղու որոշումը կախված է բովանդակությունից։ Կազմակերպական աուդիտը ավելի լայն պահանջ է. պետք է պարզ լինի՝ ով կարող է փոխել կանոնը, ում են հասանելի գրառումները, ինչպես են դրանք պահվում և ինչպես է հետագայում վերականգնվում փոփոխությունների ընթացքը։ Միայն հարցումների մատյանը այդ ամբողջ շղթան չի ապահովում։

Portkey-ի սակագնային էջը առանձին է ներկայացնում ինքնատեղակայվող Open Source տարբերակը, ամսական $49 արժողությամբ Production փաթեթը և անհատական գնով Enterprise առաջարկը՝ տարբեր հնարավորություններով ու կառավարման պայմաններով։ Կառավարվող փաթեթի դերային հասանելիությունը, պահման ժամկետները կամ աջակցությունը պետք չէ ինքնաբերաբար վերագրել բաց gateway-ին։ Նույն կերպ LiteLLM-ի հիմքային proxy-ն ընտրելիս հարկավոր է որոշել՝ պահանջվող audit գործառույթները մտնում են ընտրված տեղակայման ու լիցենզիայի մեջ, թե պահանջում են առանձին շերտ։ Երկու նախագծերն էլ կարող են լուծել երթուղավորման հարցը, բայց կազմակերպական վերահսկման ամբողջ արժեքը երթուղավորման չափումով չի երևում։

Որտեղ է կուտակվում սպասարկման ծախսը

Ինքնատեղակայման դեպքում թիմն է պատասխանատու ծառայության հասանելիության, տարբերակների թարմացման, մատակարարների գաղտնի բանալիների, պահուստային երթուղիների և մատյանների համար։ LiteLLM-ի բյուջետային հնարավորությունն այդ ցանկին ավելացնում է տվյալների բազայի շահագործումը։ Portkey-ի բաց տարբերակում պետք է հստակեցնել, թե տեղային կազմաձևում ինչպես են պահպանվում կանոնները, ով է դրանք փոփոխում և ինչ դիտելիություն է ստանում հերթապահ թիմը։ Սրանք ծրագրի գնի փոխարեն մարդկանց ժամանակով և ենթակառուցվածքով վճարվող ծախսեր են։

Portkey-ի կառավարվող ծառայությունը փոխում է հաշվարկը. gateway-ի շահագործման մի մասը տեղափոխվում է մատակարարի մոտ, իսկ թիմը գնահատում է փաթեթի սահմանները, տվյալների մշակման պայմաններն ու պայմանագրային աջակցությունը։ Եթե հարցումները պետք է անցնեն միայն թիմի վերահսկվող միջավայրով, համեմատելի զույգը ինքնատեղակայվող LiteLLM-ն ու Portkey-ի ինքնատեղակայվող տարբերակն են։ Կառավարվող ծառայության ցանցային ուղին այլ է, ուստի տեղային կեղծ backend-ի չափումը դրա վերջնական ուշացման կանխատեսում չէ։ Ընտրության մեջ պետք է հաշվել նաև այն աշխատանքը, որն առաջանում է առաջին խափանման, բանալու փոփոխության կամ կանոնի սխալի ժամանակ։

Ընտրության ծառը՝ ըստ թիմի պահանջների

  • Փոքր թիմ. Եթե մոդելների շրջանակը կայուն է, իսկ հիմնական կարիքը retry, fallback և պարզ guardrail կանոններն են, Portkey-ի բաց gateway-ն տրամաբանական մեկնակետ է։ Նրա տեղային փորձարկման արագությունը լրացուցիչ առավելություն է, եթե թիմը պատրաստ է ինքնուրույն պահել ծառայությունն ու մատյանները։ Երբ պարտադիր են ծախսային սահմանները, ընտրությունից առաջ պետք է հաշվարկել դրանց ամբողջ տեղային կազմը։
  • Աճող արտադրական թիմ. Եթե տարբեր ծառայություններին պետք են առանձին բանալիներ, թիմային բյուջեներ և հաճախ փոփոխվող մատակարարներ, LiteLLM-ը տալիս է ավելի ուղիղ կառավարման հիմք։ Դրա դիմաց անհրաժեշտ է պատասխանատու նշանակել տվյալների բազայի, worker-ների, թարմացումների և բյուջետային կանոնների համար։ Այդ բեռը արդարացվում է, երբ ծախսերի բաժանումն ու մատակարարների ճկունությունը ամենօրյա պահանջ են։
  • Խոշոր կամ խիստ վերահսկվող թիմ. Որոշումը սկսվում է տվյալների տեղակայման, դերային հասանելիության, մատյանների պահպանման, փոփոխությունների աուդիտի և աջակցության պահանջներից։ Դրանք կարող են տանել սեփական միջավայրում ընդլայնված կառավարման շերտի կամ համապատասխան կազմակերպական փաթեթի։ Բաց gateway-ների տեղային արագության տարբերությունն այստեղ ընտրության միայն մի մասն է։

Համեմատության օգտակար վերջնական միավորը նույն գործառույթներով տեղակայված հարցման ամբողջ ուղին է՝ հիմնական մոդելից մինչև պահուստային երթուղի, բյուջեի կիրառում և մատյանագրում։ Այդ ուղին ցույց է տալիս, թե արագության շահը որքան է պահպանվում իրական բեռի տակ և ինչ շարունակական աշխատանք է պահանջում ընտրված կառավարումը։

Կարդացեք նաև:

Կիսվել:

Առնչվող հոդվածներ

Բաժանորդագրվեք մեր տեղեկագրին

Ստացեք Web3-ի, ԱԲ-ի և կրիպտոյի վերջին լուրերն անմիջապես ձեր էլ. փոստին։

0