Մեկ պարբերության տարբերակը. բենչմարքի թիվն արժե հրապարակել այն ժամանակ, երբ անծանոթ մարդը կարող է չհամաձայնել դրա հետ — վերարտադրել ստենդը, ստանալ այլ արժեք և պատճառը գտնել կոնֆիգների տարբերության մեջ։ Դրա համար թիվը պետք է իր հետ կրի իր կոնֆիգուրացիան, իր workload-ը, իր ձախողումներն ու իր ցրվածությունը։ Ստորև ամեն ինչ ծառայում է հենց այդ մեկ հատկությանը, և ամեն կանոն իր տեղը վաստակել է՝ նախ այրելով մեզ։
Սա մեր հրապարակած թվերի հետևում կանգնած պրոտոկոլն է՝ գրված բոլորի համար, ովքեր լոկալ LLM-ի չափում են տեղադրում ֆորումում, README-ում կամ բլոգում։ Այն իրագործող harness-ը բաց է; այստեղից ոչինչ մեր գործիքակազմը չի պահանջում։
Ի՞նչ է իրականում աշխատեցնում ձեր սերվերը
Հարցրեք ոչ թե ձեր գործարկման սկրիպտին, այլ հենց սերվերին։ llama.cpp-ն
/props-ի վրա պատասխանում է իր գործող կարգավորումներով; vLLM-ը գործարկման
պահին տպում է իր փաստացի կոնֆիգուրացիան։ Լռելյայն արժեքները թողարկումների
միջև փոխվում են, և դրոշը, որը դուք չեք դրել, միևնույն է ձեր կոնֆիգի մասն
է։ Մեր սեփական մատյանի չափման ամենասուր
սխալը եկել է զուգահեռ slot-երի լռելյայն արժեքից, որը տարբերակների միջև
փոխվել էր և բենչմարքը դեռ չսկսված լուռ բաժանում էր մեկ հոսքի
թողունակությունը։ Ձեր հիշողությունը հրամանի տողի մասին ապացույց չէ;
պրոցեսի սեփական պատասխանը՝ այո։
Ո՞ր բայթերն են տվել ձեր թիվը
Runtime-ը՝ image-ի digest-ով, ոչ թե tag-ով — tag-երը շարժվում են։ Մոդելը՝ արտեֆակտի հեշով, ոչ թե անունով — պահոցները ֆայլերը վերբեռնում են նորից։ Սարքի firmware-ը՝ բացահայտ անվանված — DGX Spark-ի շուրջ քննարկումը firmware-ի թարմացումից հետո նույն սարքաշարի վրա շրջեց իր վճիռը, ինչը նշանակում է, որ անթվագիր Spark-թվերն այժմ անհասցե բամբասանք են։ Եթե ընթերցողը չի կարող ասել, թե որ բայթերն են տվել ձեր թիվը, նա չի կարող չհամաձայնել դրա հետ — կարող է միայն վիճել դրա շուրջ։
Ո՞ր workload-ն է կանգնած թվի հետևում
Մեր արխիվի ամենամեծ ցրվածությունը գալիս է ոչ թե սարքաշարից կամ դրոշներից, այլ workload-ի ձևից. prompt-ի երկարություն, ելքի երկարություն, բովանդակության դաս։ Նույն տուփի և նույն build-ի վրա կարճ ելքով պրոֆիլն ու ծանր կոնտեքստով պրոֆիլը տալիս են թվեր, որոնց տարբերությունը գերազանցում է սարքաշարային թարմացումների մեծ մասի էֆեկտը — DGX Spark-ի հրապարակված թվերի հաշտեցումը հիմնականում նշանակում էր պարզել, թե չհայտարարված որ պրոֆիլով է ստացվել ամեն մեկը։ Սառեցրեք կորպուսը, սառեցրեք sampling-ի կարգավորումները և պրոֆիլը հրապարակեք թվի կողքին։ tok/s թիվն առանց իր workload-ի հնարավոր չէ ո՛չ հաստատել, ո՛չ հերքել։
Ո՞ր թոքեններն եք հաշվում, և ո՞ր կողմից
Այստեղ երեք առանձին թակարդ է ապրում։ Ելքի թոքենները հաշվեք API-ի
usage.completion_tokens-ից, երբեք՝ streaming-իրադարձությունների
քանակից — speculative decoding-ի դեպքում մեկ իրադարձությունը կարող է մի
քանի թոքեն կրել, և իրադարձությունների հաշիվը լուռ ուռճացնում է
թողունակությունը։ Ասեք, թե լարի որ կողմում եք չափել. client-ի կողմը
ներառում է ցանցը և սերվերի հերթը, engine-ի կողմը՝ ոչ, և բեռի տակ երկուսը
չեն համընկնում։ Իսկ reasoning-մոդելների համար որոշեք՝ ձեր առաջին թոքենի
մետրիկան նշանակում է ինչ-որ բանի առաջին թոքե՞ն, թե՞ պատասխանի առաջին
թոքեն — այդ սահմանումների միջև ճեղքը
երբեմն ամբողջ արդյունքն է։
Ինչո՞ւ են ձախողումները մնում հայտարարում
Հարցումը, որը վերադարձրել է HTTP 200՝ դատարկ պատասխանով, կորած նմուշ չէ; այն արդյունք է։ Ձախողված, դատարկ կամ խեղված պատասխանները միջինացումից առաջ դեն նետելը հուսալիության խնդիրը լուռ դարձնում է արագության բոնուս — հաղթում է այն սերվերը, որն ամենաարագն է ձախողվում։ Մենք ամեն պատասխան գնահատում ենք ֆորմատի, լեզվի և կրկնությունների gate-երով և ոչինչ չտված բաժինը հրապարակում ենք տվածների ուշացման կողքին։
Քանի՞ անցում է դարձնում թիվը մեջբերելի
Մեկ անցումը տասնորդական նիշերով պատմություն է։ Մեջբերելի թվի մեր նվազագույն շեմը երեք կրկնված գործարկում է մեկ միավորի վրա, իսկ որտեղ դա կարևոր է, նույն օրինաչափությունը կրկնում ենք երկրորդ, կոմերցիոն առումով նույնական միավորի վրա։ Որոշ սարքաշարային դասերի վրա նույնական գործարկումներն իրարից տարբերվում են այնպիսի չափով, որի կողքին վիճարկվող էֆեկտները գաճաճ են թվում — ցանկացած մեկ անցումից բխող տասնորդական ճշգրտությունը, ներառյալ մերը, լաբորատոր խալաթ հագած լավատեսություն է։
Ուրիշ ի՞նչ էր աշխատում տուփի վրա
Չափման ընթացքում տուփի վրա ուրիշ ոչինչ չի աշխատում — բայց «ուրիշ ոչինչ»-ն ինքնին պնդում է, ուստի արձանագրեք այն։ Մեր մանիֆեստներն ամեն բջիջից առաջ և հետո կրում են host-ի գույքացուցակի պատկերը; գործարկման կեսին հայտնված GPU-հարևանը բջիջը դարձնում է անվավեր։ Նույն առիթով ստուգեք սերվերի լոգը լուռ CPU fallback-ի համար. մոդելը, որն աննկատ լքել է GPU-ն, հիանալի վերարտադրելի թվեր է տալիս սխալ սարքի մասին։
Ինչպե՞ս հրապարակել, որ ձեզ հետ հնարավոր լինի չհամաձայնել
Հում գործարկումների գրառումները, ճշգրիտ կոնֆիգը, workload-ի ինքնությունը և թիվը — միասին, կայուն հասցեում։ Հենց դա է մեր claim-էջերի ամբողջ դիզայնը. արժեքը, շրջանակը, սահմանափակումները և գործարկումները կիսում են մեկ permalink։ Իսկ երբ ինչ-որ մեկի թիվը չի համընկնում ձերի հետ, դրան վերաբերվեք որպես տվյալի. անհամաձայնության հետևում կանգնած կոնֆիգների տարբերությունը սովորաբար ավելի ինֆորմատիվ է, քան երկու թվերից որևէ մեկը։ Մերոնք ունեն մշտական ներկայացման ուղի։
Ստուգաթերթը
Նախքան թիվը հրապարակելը, այն պետք է պատասխանի հարցերին. ինչ սարք և firmware, ինչ runtime և digest, ինչ մոդել և հեշ, ինչ քվանտ, ինչ workload-ի ձև և sampling, ինչ զուգահեռություն, լարի որ կողմը, քանի կրկնություն, ինչ է դուրս մնացել և ինչու։ Եթե պատասխաններից թեկուզ մեկը «վստահ չեմ» է, թիվը պատրաստ չէ — իսկ եթե բոլոր պատասխանները տեղում են, նույնիսկ հետագայում սխալ դուրս եկած թիվն օգտակար է, որովհետև այն կարելի է սխալ գտնել։ Հենց դա է չափման և տրամադրության ամբողջ տարբերությունը։