Կարճ տարբերակը. մի քանի հոգու սպասարկող մեկ տուփի վրա engine-ը հազվադեպ է լինում խցանը, և այն փոխելու ազնիվ պատճառը workload-ի ձևի փոփոխությունն է, ոչ թե բենչմարքների աղյուսակը։ Մենք llama.cpp ենք սպասարկում մեր Strix Halo մեքենաների վրա և vLLM՝ DGX Spark զույգի վրա, և երկու դեպքում էլ որոշողն այն էր, թե ինչ էր պետք workload-ին, ոչ թե որ engine-ն է «ավելի արագ» վերացական իմաստով։
Նախ՝ զգուշացում ժանրի մասին։ Engine-ների համեմատությունների մեծ մասը, որ կգտնես, քշված է տվյալների կենտրոնի GPU-ների վրա, մեջբերում է թողունակության բազմապատկիչներ այնպիսի batch-չափերից, որ տնային սերվերը երբեք չի տեսնում, և բաց է թողնում մոդելը, քվանտն ու զուգահեռությունը, որոնք դրանք ծնել են։ Նույն սարքաշարի վրա միջ-engine թվեր չունենք նաև մենք — և ուրիշինը փոխ առնելու փոխարեն այս էջն ասում է այն, ինչ գիտենք երկուսի շահագործումից։
Ինչի համար է ամեն մեկը
llama.cpp-ն աշխատեցնում է քվանտացված GGUF կշիռները գրեթե ամեն ինչի
վրա, ներառյալ ինտեգրված GPU-ները Vulkan-ի միջոցով, — հենց դրա համար է
այն մեր սերվինգ runtime-ը unified հիշողությամբ տուփերի վրա։ Այն սերվեր
է գումարած backend-ների հավաքածու, մեկնարկում է վայրկյանների ընթացքում
և ազնվորեն պատմում է, թե ինչ է անում, եթե հարցնես. /props endpoint-ը
կվերադարձնի իր լուծած գործող կոնֆիգուրացիան, և պարզվում է, որ դա ավելի
կարևոր է, քան մարդկանց մեծ մասը սպասում է։
vLLM-ը կառուցված է մասշտաբով սպասարկման համար. continuous batching, հիշողության կառավարում paged attention-ով, տենզորային զուգահեռականություն սարքերի միջև։ Մեր Spark զույգի վրա տենզորային զուգահեռականությունը հաճելի հավելում չէ — այն միակ պատճառն է, որ 284B պարամետրանոց մոդելն ընդհանրապես աշխատում է, և սերվինգի բաղադրատոմսը գոյություն ունի, որովհետև այնտեղ հասնելը իրական օպերացիոն աշխատանք պահանջեց։ Հնարավորության դիմաց ստանում ես ավելի ծանր ստեկ. ավելի երկար մեկնարկ, մոդելի ֆորմատի սահմանափակումներ և միջուկների ընտրության վարք, որը կարող է լուռ վերցնել ավելի դանդաղ ուղին։
Ollama-ն դիստրիբուցիայի և մոդելների կառավարման շերտ է, որի տակ աշխատում է llama.cpp-ն։ «Ollama-ն ընդդեմ llama.cpp»-ն ուստի սովորաբար ընդհանրապես engine-ի հարց չէ — դա հարց է, թե ում դեֆոլտներն ես ժառանգում և տեսնո՞ւմ ես դրանք։
Հարցը, որն ավելի կարևոր է, քան engine-ը
Ինչ էլ քշես, իմացիր, թե ինչ է այն լուծել։ Մեր սեփական մատյանի չափման ամենաթանկ սխալը եկավ զուգահեռ slot-երի runtime-դեֆոլտից, որը փոխվել էր տարբերակների միջև և լուռ բաժանում էր մեկ հոսքի թողունակությունը — թյունինգի տեսությունների օրերը մեռան աշխատող սերվերին ուղղված մեկ հարցումից։ Ամբողջ պատմությունը էսսեում է, իսկ դասի ընդհանուր ձևը՝ այստեղ. դրոշը, որը դու չես դրել, միևնույն է քո կոնֆիգուրացիայի մասն է։
Ահա որտեղ են wrapper-ները թանկ նստում։ Շերտը, որը մոդելները կառավարում է քո փոխարեն, քո փոխարեն ընտրում է նաև կոնտեքստի երկարությունը, slot-երի քանակը, offload-ի վարքն ու sampling-ի դեֆոլտները, և եթե այդ ընտրությունները տեսնել չես կարող, չես կարող ո՛չ բացատրել սեփական թվերդ, ո՛չ ուղղել դրանք։
Երբ llama.cpp-ն բավական է
Այն ամենը, ինչ չափում ենք 128 ԳԲ-անոց մեկ տուփի վրա, աշխատում է դրա վրա. անհատական օգնականներ, փոքր թիմի զուգահեռություն, փաստաթղթային սեսիաներ, խիստ JSON ավտոմատացում և եռաժամյա շարունակական բեռ։ Այս դասի սարքաշարի վրա գործնական առաստաղը հիշողության թողունակությունն է, և ֆիզիկայի հետ ոչ մի engine չի վիճում. մեր թվերն ամենից շատ շարժեցին քվանտը և backend-ը, երկուսն էլ llama.cpp-ի ներսում։
Երբ workload-ը vLLM է խնդրում
Երեք ազդանշան՝ մեր սեփական շահագործման փորձից, ոչ թե բենչմարքից.
Մոդելը մեկ սարքի մեջ չի տեղավորվում։ Տենզորային զուգահեռականությունը հանգույցների միջև հենց այդ հնարավորությունն է, և բաց կշիռների ֆրոնտիր դասի համար այն ընտրովի չէ։
Իրական հերթ ես սպասարկում, ոչ թե մի քանի չաթ։ Continuous batching-ն իր բարդությունը վաստակում է, երբ հարցումներն իսկապես ամբողջ օրը վրա-վրա են գալիս։
Քեզ պետք է վենդորի արագ ուղին կոնկրետ մոդելի համար։ Որոշ միջուկներ մատակարարվում են միայն այս էկոհամակարգում — և, ինչպես պարզեցինք, երբեմն միայն եթե դրանք բացահայտ խնդրես։
Եթե սրանցից ոչ մեկը քո տուփը չի նկարագրում, ավելի ծանր ստեկը քեզ գնում է օպերացիոն մակերես, ոչ թե արագություն։
Ինչ մենք չենք չափել
Այս engine-ների՝ նույն սարքաշարի, նույն մոդելի, նույն workload-ի վրա համեմատություն մեր արխիվում չկա, ուստի այս էջը միջ-engine թվեր չի պարունակում։ Մեր երկու engine-ներն աշխատում են սարքաշարի երկու տարբեր դասերի վրա երկու տարբեր պատճառով, և դրանց թվերը հարևան սյունակների մեջ դնելը կարտադրեր հենց այն ֆոլկլորը, որի ապամոնտաժման վրա մենք ժամանակ ենք ծախսում։ Եթե համեմատությունը հետո կայանա, այն կգա հում գործարկումներով։
Մինչ այդ քո սեփական տուփի վրա հարցը փակելու պրոտոկոլը գրված է այստեղ. սառեցրու workload-ը, ամրագրիր երկու ստեկն էլ, հարցրու ամեն սերվերին, թե ինչ է իրականում լուծել, և ձախողումները պահիր հայտարարի մեջ։ Այդ չափումը քեզ համար ավելի արժեքավոր է, քան ցանկացած ընդհանուր պատասխան, ներառյալ այս մեկը։