Ollama թե vLLM․ պարզ տեղադրումը զիջում է, երբ միաժամանակ հարցումները շատանում են

Անհատական տեղային օգտագործման համար Ollama-ն սովորաբար ամենապարզ մեկնարկն է։ Եթե նույն լեզվային մոդելը պետք է միաժամանակ սպասարկի բազմաթիվ օգտատերերի, vLLM-ը դառնում է ավելի ուժեղ թեկնածու․ դրա հնարավորությունները նախատեսված են համատեղ ծանրաբեռնվածության համար։ Վերջնական ընտրությունը կախված է նույն մոդելի ու սարքավորման վրա չափված արդյունքից, հատկապես՝ հարցումների թվի աճի պահին։

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

Ollama-ի զուգահեռությունն ունի հիշողության գին

Ollama-ն կարող է զուգահեռ մշակել նույն մոդելին ուղղված հարցումները։ Ollama-ի FAQ-ն նշում է, որ OLLAMA_NUM_PARALLEL-ը սահմանում է մեկ մոդելի միաժամանակ մշակվող հարցումների առավելագույն թիվը, OLLAMA_MAX_QUEUE-ը՝ զբաղված սերվերի հերթի սահմանը, իսկ պահանջվող հիշողությունն աճում է զուգահեռության և համատեքստի երկարության արտադրյալին համեմատ։ Հերթի սահմանը լրանալու դեպքում սերվերը կարող է մերժել նոր հարցումը՝ վերադարձնելով ծանրաբեռնվածության սխալ։

Այս կապը կարևոր է հատկապես երկար մուտքային տեքստերի դեպքում։ Զուգահեռության սահմանը բարձրացնելիս մոդելի կշիռների համար անհրաժեշտ հիշողությանը գումարվում է ավելի մեծ համատեքստի պահանջը։ Եթե հիշողությունը բավարար չէ, սերվերի կարգավորման մեջ գրված ավելի մեծ թիվը ինքնին լրացուցիչ հզորություն չի ստեղծում։ Իսկ սահմանը ցածր պահելիս ավելորդ հարցումները սպասում են հերթում, և դրանց առաջին տոկենի ուշացումը մեծանում է։

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

Ինչ է փոխում vLLM-ի սպասարկման մեխանիզմը

vLLM-ի ուժեղ կողմը միաժամանակյա հարցումները կազմակերպելու ձևն է։ vLLM-ի պաշտոնական նկարագրությունը թվարկում է PagedAttention-ը՝ ուշադրության հաշվարկի հիշողությունը կառավարելու համար, շարունակական խմբավորումը, մուտքի մասերով նախնական մշակումը և ընդհանուր նախածանցների քեշավորումը։ Դրանք վերաբերում են այն ծանրաբեռնվածությանը, երբ տարբեր հարցումներ միաժամանակ մրցում են հաշվարկային ժամանակի ու հիշողության համար։

Շարունակական խմբավորման դեպքում նոր հարցումը կարող է ընդգրկվել ընթացիկ մշակման մեջ՝ առանց սպասելու, մինչև նախորդ պատասխանների ամբողջ խումբն ավարտվի։ Մասերով նախնական մշակումը երկար մուտքի աշխատանքը բաժանելու հնարավորություն է տալիս, իսկ նախածանցների քեշը կարող է օգտակար լինել, երբ տարբեր հարցումներ կրկնում են նույն սկզբնական հատվածը։ Օգուտի չափը կախված է հարցումների կառուցվածքից․ ընդհանուր նախածանց չունեցող կարճ հարցումները նույն կերպ չեն շահի քեշից։

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

Առաջին տոկենը, մեկ հոսքը և ընդհանուր թողունակությունը

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

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

Red Hat-ի հրապարակած փորձարկման ընթացքում մեկ NVIDIA A100-PCIE-40GB GPU-ի վրա Llama 3.1 8B Instruct մոդելի չսեղմված կշիռներով ստուգվել են 1-ից 256 միաժամանակյա օգտատերերի ծանրաբեռնվածություններ․ առավելագույն ընդհանուր թողունակությունը կազմել է 793 ելքային տոկեն/վրկ vLLM-ի և 41 ելքային տոկեն/վրկ Ollama-ի համար։ Փորձը նաև ցույց է տվել, որ Ollama-ի հերթը ծանրաբեռնվածության աճի հետ բարձրացրել է առաջին տոկենի ուշացումը։ Այդ թվերը վերաբերում են հրապարակված կազմաձևին և չեն տալիս այլ GPU-ի, քվանտացման կամ հարցումների խառնուրդի համար պատրաստի արագության գործակից։

Ինչպես ստանալ համեմատելի չափում

Համեմատության հիմքը նույն մոդելն ու նույն սարքավորումն են։ Երկու սպասարկիչների համար գրանցեք կշիռների տարբերակը, ճշգրտությունը կամ քվանտացումը, համատեքստի սահմանը, մուտքի ու սպասվող ելքի երկարությունը։ Նոր բեռնված մոդելի առաջին հարցումը չափեք առանձին կամ նախապես տաքացրեք երկու սերվերներն էլ։ Հակառակ դեպքում բեռնման ժամանակը կխառնվի սպասարկման ուշացմանը։

Ստորև բերված հրամաններում MODEL_TAG-ը Ollama-ում մոդելի անունն է, իսկ MODEL_ID-ը՝ նույն մոդելի համապատասխան նույնացուցիչը vLLM-ի համար։ Առանձին միջավայրերում գործարկեք OLLAMA_NUM_PARALLEL=4 ollama serve և vllm serve MODEL_ID --host 127.0.0.1 --port 8000։ Եթե Ollama-ն արդեն աշխատում է որպես համակարգային ծառայություն, OLLAMA_NUM_PARALLEL-ը սահմանեք հենց այդ ծառայության գործարկման միջավայրում։

Ollama-ի OpenAI-համատեղելի API-ի փաստաթղթերը ցույց են տալիս տեղային chat հասցեն՝ http://127.0.0.1:11434/v1/chat/completions։ Նույն տիպի հարցումը vLLM-ի սերվերին կարելի է ուղարկել http://127.0.0.1:8000/v1/chat/completions հասցեով։ Այսպես չափման գործիքը կարող է օգտագործել նույն հարցման ձևը, թեև API-ում փոխանցվող մոդելի անունը յուրաքանչյուր սերվերի համար տարբեր կլինի։

vLLM-ի չափման հրամանների նկարագրությունը սահմանում է հասցեի, chat վերջնակետի, tokenizer-ի, հարցումների քանակի, մուտքի ու ելքի երկարության և առավելագույն զուգահեռության պարամետրերը։ Ollama-ի համար օրինակային կանչն է vllm bench serve --backend openai-chat --base-url http://127.0.0.1:11434 --endpoint /v1/chat/completions --model MODEL_ID --served-model-name MODEL_TAG --tokenizer MODEL_ID --dataset-name random --random-input-len 256 --random-output-len 128 --num-prompts 100 --max-concurrency 4 --request-rate inf։ vLLM-ի համար պահպանեք մյուս պարամետրերը, հասցեն փոխեք http://127.0.0.1:8000-ի, իսկ API-ի մոդելի անունը՝ MODEL_ID-ի։

Այստեղ մուտքի ու ելքի երկարությունները փորձի պայմաններ են, ոչ արդյունավետության հրապարակված արդյունք։ Կրկնեք չափումը նախ մեկ ակտիվ հարցումով, ապա բարձրացրեք --max-concurrency-ը՝ մյուս պայմանները պահելով նույնը։ --request-rate inf-ը բոլոր հարցումները տալիս է միանգամից, ուստի լավ է հագեցման սահմանը տեսնելու համար։ Իրական օգտատերերի սպասումը գնահատելիս առանձին չափեք ձեր ծառայությանը բնորոշ ժամանման հաճախականությամբ և դիտեք նաև չափման գործիքի հերթում անցկացրած ժամանակը։

Որ ծանրաբեռնվածության համար որն ընտրել

Եթե մոդելը հիմնականում օգտագործում է մեկ մարդ, կամ հարցումները գալիս են ընդմիջումներով ու կարող են հերթով ավարտվել, Ollama-ն գործնական ընտրություն է։ Փոքր թիմի դեպքում նախ պարզեք՝ արդյոք կարճ հերթն իրականում խանգարում է աշխատանքին։ Զուգահեռության սահմանը բարձրացնելիս միաժամանակ գնահատեք հիշողության պահանջը, քանի որ կարգավորումը կարող է փոխել հենց այդ ռեսուրսի սպառումը։

Եթե API-ն պետք է սպասարկի բազմաթիվ միաժամանակյա օգտատերերի, vLLM-ը գնահատեք որպես հիմնական թեկնածու։ Ընտրության վճռական պահը սպասվող ծանրաբեռնվածությունն է․ որքան շատ հարցումներ են հանդիպում իրար, այնքան կարևոր է չափել առաջին տոկենի ուշացումը ընդհանուր թողունակության կողքին։ Հրապարակված համեմատությունը ցույց է տալիս, թե ինչու պարզ տեղադրումը կարող է զիջել այդ պայմաններում, իսկ ձեր մոդելի ու սարքավորման չափումը ցույց կտա՝ որտեղ է այդ սահմանը ձեր ծառայության համար։

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

• Semantic cache-ը կրճատում է հարցումները, բայց նման իմաստը նույն պատասխանը չէ
• Անձնական տվյալը հեռացրեք մինչև ԱԲ հարցումը․ միայն դիմակավորումը բավարար չէ
• Jira թե Linear․ գրեթե նույն գինը գնում է ճկունություն կամ ավելի պարզ հոսք