Ollama թե LM Studio․ նույն մոդելի արագությունը որոշում է նաև build-ը

Եթե տեղային մոդելը պետք է միացնել հավելվածին կամ կրկնվող սցենարին, Ollama-ն հարմար մեկնակետ է։ Եթե թիմը մոդելները հիմնականում ընտրում և փորձում է տեսողական միջավայրում, արժե սկսել LM Studio-ից, սակայն այն նույնպես ունի ծրագրային API։ Արագության համընդհանուր հաղթող չկա. Mozilla-ի համեմատական չափման ընթացքում նույն GGUF ֆայլերը գործարկվել են Mac Studio, NVIDIA-ով Linux համակարգում և Steam Deck OLED-ում, իսկ վերջինի վրա նույն llamafile/llama.cpp կոդի՝ Vulkan shader գործիքաշարի տարբեր տարբերակներով հավաքված build-երից մեկը Qwen 9B մոդելի մուտքային տեքստը մշակել է 63,3% ավելի արագ։ Այդ աճը Ollama-ի և LM Studio-ի ուղիղ մրցակցության արդյունք չէ. այն ցույց է տալիս, թե որքան կարող է փոխել չափումը build-ը։

Փոքր թիմի որոշումը սկսվում է երկու հարցից՝ ինչպե՞ս է մոդելը կանչվելու, և ո՞ր սարքի վրա է աշխատելու։ Ծրագրի համար կարևոր են API-ի անհրաժեշտ գործողություններն ու ավտոմատացման հարմարությունը, իսկ ձեռքով փորձարկման համար՝ մոդելների կառավարումն ու ինտերֆեյսը։ Արագության թիվը օգտակար է միայն այն դեպքում, երբ հայտնի են նույն ֆայլը, առաջադրանքը, կարգավորումները և չափման եղանակը։

Արագության ո՞ր չափումն է կարևոր

Մուտքային տեքստի մշակման արագությունը ցույց է տալիս, թե որքան արագ է գործարկիչը պատրաստում հարցումը պատասխանի ստեղծումից առաջ։ Պատասխանի գեներացման արագությունը վերաբերում է հաջորդող տոկեններին։ Երկար փաստաթղթի ամփոփման դեպքում առաջին փուլը կարող է կազմել սպասման զգալի մասը, իսկ կենդանի զրույցում ավելի նկատելի է պատասխանի հայտնվելու ընթացքը։ Ուստի մեկ ընդհանուր «տոկեն վայրկյանում» ցուցանիշը բավարար չէ երկու աշխատանքները գնահատելու համար։

Նույն կշիռներով փորձարկումը մեկուսացնում է ֆայլի տարբերության ազդեցությունը, բայց չի վերացնում միջավայրի բոլոր տարբերությունները։ Mozilla-ի փորձարկման մեջ գործարկիչների սեփական batching կարգավորումները պահպանվել են, իսկ պատասխանի արագության չափման եղանակը LM Studio-ի macOS արդյունքի համար տարբերվել է մյուսներից։ Այդ հանգամանքը հատկապես կարևոր է, երբ գծապատկերներում մոտ արժեքներ են երևում. փոքր տարբերությունը միշտ չէ, որ կարելի է վերագրել միայն գործարկիչին։

Build-ի ազդեցությունը նույնպես սահման ունի։ Steam Deck-ի վրա shader գործիքաշարի փոփոխությունը վերաբերում էր նույն կոդից հավաքված համեմատվող տարբերակներին. օգտվողը չի կարող նույն կերպ վերակառուցել LM Studio-ի պատրաստի runtime-ը։ Այս փաստը գործնական ընտրության մաս է. ինքնուրույն հավաքվող գործարկիչը կարգավորման ավելի մեծ ազատություն է տալիս, մինչդեռ պատրաստի հավելվածի դեպքում թիմը աշխատում է մատակարարված տարբերակով։

API և ինտերֆեյս․ որտեղ է գործնական տարբերությունը

Ollama-ի API փաստաթղթերում նշված են տեղային սերվերի հասցեն, ինչպես նաև OpenAI և Anthropic հաճախորդների համար համատեղելի հասցեները։ Դա թույլ է տալիս առկա հաճախորդը միացնել տեղային մոդելին՝ փոխելով համապատասխան հասցեն ու մոդելի անունը։ Համատեղելիությունը պետք է գնահատել թիմին անհրաժեշտ գործողություններով. ծանոթ հասցեն դեռ չի երաշխավորում, որ բոլոր պարամետրերն ու պատասխանների վարքը նույնն են։

LM Studio-ի REST API-ի նկարագրությունը ներառում է հոսքային պատասխաններ, վիճակը պահպանող զրույց, մոդելի ներբեռնման, բեռնման ու ապաբեռնման գործողություններ և OpenAI ու Anthropic համատեղելի endpoint-ներ։ Հետևաբար LM Studio-ն միայն ձեռքով զրույցի գործիք համարելը սխալ կլինի։ Նրա սեփական զրույցի endpoint-ի և համատեղելի endpoint-ների հնարավորությունները նաև ամբողջությամբ չեն համընկնում, ուստի ընտրությունը պետք է կապել կոնկրետ հաճախորդի պահանջների հետ։

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

Ինչպես պահել GGUF համեմատությունը արդար

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

Ollama-ի GGUF ներմուծման հրահանգը պահանջում է Modelfile-ի FROM տողով նշել ֆայլի ուղին և ապա գործարկել ollama create հրամանը. ներմուծման ընթացքում GGUF-ը նորից չի քվանտացվում։ Սա հարմար է արդեն ընտրված քվանտացումը պահպանելու համար։ Գրանցեք նաև ստեղծված տեղային մոդելի անունը, որպեսզի հաջորդ վազքի ժամանակ պատահմամբ ուրիշ տարբերակ չկանչվի։

LM Studio-ի lms import հրամանը ներմուծում է առկա ֆայլը առանց կրկին ներբեռնելու. սովորական ներմուծումը տեղափոխում է ֆայլը, իսկ --copy տարբերակը պահպանում է սկզբնական պատճենը։ Եթե երկու գործիքներն էլ պետք է աշխատեն մեկ սկզբնական ֆայլով, պատճենման եղանակը պարզեցնում է ֆայլերի նույնականության վերահսկումը։ Փորձարկման մատյանում պահեք նաև LM Studio-ում բեռնված մոդելի նույնականացուցիչը։

Չափման ձևանմուշ փոքր թիմի համար

Հրապարակված փորձարկման տրամաբանությունը կարելի է հարմարեցնել թիմին հասանելի Apple համակարգչին, NVIDIA քարտով Linux մեքենային և AMD/Vulkan միջավայրին, եթե դրանք իսկապես օգտագործվում են աշխատանքի մեջ։ Պետք չէ ձեռք բերել հենց հրապարակման սարքերը։ Յուրաքանչյուր սարքի վրա համեմատեք գործարկիչները առանձին՝ նույն GGUF ֆայլով և նույն առաջադրանքով. տարբեր սարքերի արդյունքները միավորելը կթաքցնի այն տարբերությունը, որը փորձարկումը պետք է բացահայտի։

1. Գրանցեք օպերացիոն համակարգը, պրոցեսորը, գրաֆիկական միջավայրը, գործարկիչի և runtime-ի տարբերակները, GGUF ֆայլի հեշն ու քվանտացումը։ Նշեք համատեքստի սահմանը, GPU-ին փոխանցման չափը և արագության վրա ազդող միացված կարգավորումները։
2. Պատրաստեք կարճ զրույցի և երկար մուտքային տեքստի առաջադրանքներ։ Երկու գործարկիչին տվեք նույն մուտքը, ելքի նույն սահմանը և հնարավորինս համարժեք գեներացման պարամետրերը։
3. Յուրաքանչյուր համադրությունը աշխատեցրեք բազմիցս։ Առաջին վազքը առանձնացրեք տաքացման համար, գործարկիչների հերթականությունը փոխեք և գրանցեք՝ արդյոք մոդելն ու քեշը յուրաքանչյուր անգամ սկսում են սառը վիճակից։
4. Առանձին հաշվեք մուտքային տեքստի մշակման և պատասխանի գեներացման արագությունները։ Եթե հավելվածում կարևոր է առաջին տոկենին սպասելը, չափեք նաև այդ ժամանակը՝ հստակ նշելով հաշվարկի սկիզբն ու ավարտը։

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

Ո՞ր գործարկիչն ընտրել

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

Վերջնական արագության որոշումը կայացրեք այն սարքի վրա, որտեղ մոդելն իսկապես գործելու է։ Պահպանված GGUF ֆայլը, runtime-ի տարբերակը, build-ի պայմանները և առանձին չափված երկու փուլերը ցույց կտան, թե որ համադրությունն է համապատասխանում թիմի իրական հարցումներին։ Այդպես հնարավոր է ընտրել նաև այն տարբերակը, որը փոքր-ինչ դանդաղ է մեկ չափմամբ, բայց ավելի հարմար է պահանջվող API-ի կամ մոդելների կառավարման համար։

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

• Meta թե Alphabet․ ԱԲ ծախսերի նույն մրցավազքը թաքցնում է տարբեր շարժիչներ
• Դրամաշնորհ, թե աքսելերատոր․ հայկական ստարտափի փուլն է որոշում ընտրությունը
• Signal թե WhatsApp․ նույն գաղտնագրումը չի նշանակում նույն գաղտնիությունը