Մեթոդաբանություն v1

1. Qualification cell — ընդգրկման միավորը

Յուրաքանչյուր արդյունք պատկանում է մեկ qualification cell-ի՝ կոմերցիոն սարքի, firmware-ի և BIOS-ի, ՕՀ-ի և միջուկի, GPU դրայվերային ստեկի, runtime-ի build-ի, հայտնի հեշով մոդելի ֆայլի, քվանտիզացիայի, կոնտեքստի և KV կարգավորումների, գործարկման հրամանի և workload-ի ռևիզիայի մեկ ճշգրիտ համակցության։ Ամբողջական system fingerprint-ը ֆիքսվում է չափումներից առաջ։

Ցանկացած մեկ կրիտիկական շերտի փոփոխությունը ստեղծում է նոր cell։ Արդյունքները երբեք լուռ չեն տեղափոխվում այլ դրայվերի, runtime-ի այլ build-ի, մոդելի այլ ռևիզիայի կամ սարքի տարբերակի վրա։ Կոնֆիգուրացիայի հրապարակային քարտը նկարագրում է թեստավորված cell-ը — և ոչ թե սարքի բոլոր տարբերակները։

2. Նախագրանցում headline գործարկումներից առաջ

Ցանկացած headline գործարկումից առաջ նախագրանցման փաստաթղթում ֆիքսվում են՝

• հիմնական հարցը և համակարգերն իրենց կրիտիկական տարբերակներով,
• workload-ի ռևիզիան և մոդելի ընտրության կանոնը,
• cell-երը, կրկնությունների թիվը և headline մետրիկաները,
• quality gate-երը և բացառման/ինվալիդացիայի կանոնները,
• պլանավորված համեմատությունները և scope-ի ընդլայնման պայմանները։

Նախագրանցումից հետո headline մետրիկան, բացառման կանոնները և configuration cell-երը չեն կարող փոխվել առանց նոր ռևիզիայի։ Exploratory գործարկումները թույլատրվում են, բայց մարկավորվում են առանձին և երբեք չեն փոխարինում նախագրանցված արդյունքին։

3. Run-ի կենսացիկլը և ինվալիդացիան

Յուրաքանչյուր run անցնում է ֆիքսված կենսացիկլ.

Run-ը դառնում է invalid — պահպանվում է մատյանում, բայց բացառվում է headline պնդումներից — մասնավորապես, եթե՝

• runtime-ի կամ մոդելի հեշն անհայտ է կամ չի համընկնում նախագրանցված ռևիզիայի հետ,
• տեղի է ունեցել աննկատ device fallback — օրինակ, GPU-ի համար նախատեսված workload-ը լուռ կատարվել է CPU-ի վրա,
• warmup տրաֆիկը հայտնվել է չափվող միջակայքում, կամ սառը մեկնարկը խառնվել է warm serving latency-ի հետ,
• օպերատորը փոխել է համակարգի կոնֆիգուրացիան run-ի ընթացքում,
• չի պահպանվել ելքի թիրախային երկրաչափությունը, թելեմետրիայի ժամացույցների դրեյֆը ժամանակային շարքերը դարձրել է անհամեմատելի, կամ benchmark-կլիենտը սպառել է սեփական ռեսուրսները,
• failed request-երի թիվը հնարավոր չէ որոշել։

Failed request-երը երբեք չեն անհետանում հայտարարից։ Timeout-ով կամ սխալով ավարտված հարցումը հաշվվում է run-ի դեմ, նույնիսկ եթե չունի ժամանակային տվյալներ։ Արդյունքի հետ միասին հրապարակվում է հարցումների հաշվառումը յուրաքանչյուր cell-ի համար՝ scheduled, started, completed valid, functional failures, timeouts, transport errors, server errors, invalid outputs, cancelled։ OOM-ից կամ խափանումից հետո run-ը չի շարունակվում որպես վալիդ. վերականգնումը պահանջում է run-ի նոր իդենտիֆիկատոր։

4. Կրկնություններ և ցրվածք

Headline cell-ը թիրախում է առնվազն երեք անկախ չափված գործարկում; ապացույցի մակարդակների սանդուղքը ֆիքսում է, թե հրապարակված թիվը իրականում որտեղ է հասել (lab_single_run → lab_repeated → lab_unit_replicated), և երեք գործարկումից պակաս ամեն ինչ հրապարակվում է միայն այդ ավելի ցածր մակարդակը թվի կողքին նշված։ Գործարկումների անհատական արժեքները հրապարակվում են, իսկ headline թիվը մեդիանն է, եթե workload-ի մեթոդիկան այլ բան չի սահմանում։

Եթե գործարկումների միջև ցրվածքն ավելի լայն է, քան որակի հսկողության ներքին շեմը, կատարվում են լրացուցիչ գործարկումներ կամ պատճառը պարզվում է մինչև թվի հրապարակումը։ Այս շեմը AGmind-ի ներքին QC կանոն է, ոչ թե ոլորտային ստանդարտ։

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

5. Claim-երի տիպերը՝ controlled, system, diagnostic

• Controlled — պայմանների միջև փոխվում է ուղիղ մեկ գործոն։ Թույլատրվում են հարաբերական պնդումներ այդ գործոնի մասին։
• System — համեմատվում են պատրաստի կոնֆիգուրացիաներն այն տեսքով, որով դրանք մատակարարվում են։ Թույլատրվում են միայն զուգահեռ observed value-ներ՝ բոլոր հայտնի տարբերությունների բացահայտմամբ. արդյունքը չի վերագրվում որևէ առանձին բաղադրիչի։
• Diagnostic — միկրոբենչմարքներ և զոնդեր։ Դրանց արդյունքները երբեք չեն էքստրապոլացվում օգտագործողական հզորության վրա։

6. Որակի շեմը

Ցանկացած performance առաջարկություն պահանջում է նախապես սահմանված quality կամ functional gate-եր — օրինակ՝ server/API contract, JSON-ի և սխեմայի վալիդություն, ելքի լեզու, կրկնությունների և collapse-ի հայտնաբերում, խնդրի կոռեկտություն, retrieval և ցիտման աջակցություն, ֆունկցիաների կատարում, ձեռնպահում unanswerable մուտքերի դեպքում։ Եթե ոչ մի gate չի ստուգվել, արդյունքը կրում է բացահայտ նշում.

7. Երկար կոնտեքստ. հինգ տարբեր մակարդակ

«Աջակցում է երկար կոնտեքստին» — սա մեկ հատկություն չէ։ Մեթոդաբանությունը տարբերակում է.

1. Configured context — այն, ինչ runtime-ը կարգավորված է ընդունել։
2. Loadable context — այն, ինչ իրականում բեռնվում է առանց խափանման։
3. Successfully completed context — այն, որի վրա հարցումներն ավարտվում են սկզբից մինչև վերջ։
4. Quality-preserving context — այն, որտեղ ելքի որակը պահպանվում է կարճ կոնտեքստով հսկիչ չափման համեմատ։
5. Recommended context — այն, ինչ AGmind-ը խորհուրդ է տալիս կոնկրետ workload-ի և SLO-ի համար։

Long-context թեստերի նվազագույն հավաքածուն ներառում է կարճ կոնտեքստով հսկողություն, դիրքային հավասարակշռված խնդիրներ, multi-hop և ագրեգացնող խնդիրներ, unanswerable հսկողություն, կրկնությունների/collapse-ի հայտնաբերում և latency/հիշողության կորը կոնտեքստի երկարությունների կտրվածքով։

8. Endurance նվազագույնը

Հրապարակային endurance արդյունքը պահանջում է անընդհատ ակտիվ ծանրաբեռնվածության սեսիա՝ ոչ կարճ, քան մեթոդիկայով սահմանված ֆիքսված նվազագույն տևողությունը, առանձին drain փուլով, ֆիքսված workload-ի և cell-ի վրա։ Թողունակությունը, ուշացումները և սխալները հրապարակվում են ժամանակային միջակայքերով՝ ջերմաստիճանի, հաճախությունների, utilization-ի և սնուցման աղբյուրի հետ միասին։ Թրոթլինգի իրադարձությունները, հիշողության աճը և ցանկացած վերագործարկում, խափանում ու վերականգնում ֆիքսվում են run-ի մատյանում։

9. Ռեպլիկացիա օրինակների միջև

Երբ լաբորատորիայում կա երկու միանման կոմերցիոն օրինակ, headline anchor point-երը կրկնվում են երկրորդ սարքի վրա։ Սա ընտրանքը չի դարձնում ներկայացուցչական ամբողջ արտադրական խմբաքանակի համար, բայց տարանջատում է գործարկումների միջև կրկնելիությունը մեկ անոմալ օրինակի հնարավորությունից։

10. Վճիռների բառարանը

Վճիռները վերցվում են ֆիքսված բառարանից։ Վճիռը միշտ վերաբերում է կոնկրետ տարբերակի, workload-ի և acceptance criteria-ների — և երբեք սարքին ամբողջությամբ։

11. Ուղղումներ, superseded և retracted

Ուղղումները հրապարակվում են, ոչ թե թաքցվում։ Յուրաքանչյուր ուղղում ստանում է ամսաթիվ, պատճառ և առնչվող claim-երի ցանկ։ Առնչվող claim-ը մարկավորվում է superseded կամ retracted. հին հաշվետվությունը մնում է հասանելի կամ արխիվացվում է բացահայտ redirect-ով։ Ուղղված թվերը վերահաշվարկվում են ելակետային տվյալներից և երբեք ձեռքով չեն խմբագրվում։ Էական սխալները թվարկվում են errata էջում, իսկ headline էջերը թարմացվում են claim registry-ից։

12. Ինչ այս մեթոդաբանությունը չի պնդում

• համապատասխանություն MLPerf-ին կամ որևէ այլ արտաքին բենչմարք ծրագրի,
• վիճակագրական ներկայացուցչականություն սարքերի ամբողջ շուկայի կամ արտադրական խմբաքանակի համար,
• պիտանիություն ցանկացած workload-ի համար, որը չի թեստավորվել,
• արտադրանքի անվտանգություն կամ որևէ եզրակացություն regulatory compliance-ի մասին,
• firmware-ի, դրայվերների, runtime-ների կամ մոդելների ապագա տարբերակների երկարաժամկետ աջակցություն,
• պատճառականություն, եթե պայմանների միջև փոխվել է մեկից ավելի գործոն։