Հարցը, որ վաղ թե ուշ տալիս է 128 ԳԲ-անոց մինի-ՀՀ-ի ամեն գնորդ, ոչ թե «քանի՞ թոքեն վայրկյանում է տալիս» է, այլ «կկարողանա՞ սրանով աշխատել իմ հնգանոց թիմը»։ Հրապարակված բենչմարքները գրեթե երբեք դրան չեն պատասխանում. նրանք չափում են մեկ հոսք և հաղորդում դեկոդի արագությունը։ Այստեղ նույն տուփն է՝ միաժամանակյա բեռի տակ, չափված այնպես, ինչպես զգում են օգտատերերը։
Ինչ է չափվել
Մեկ Beelink GTR9 Pro (Ryzen AI Max+ 395, 128 ԳԲ unified) llama.cpp server-ով, Vulkan build-ը ամրագրված է image-ի digest-ով, սպասարկում է Qwen3.6-35B-A3B Q4_K_M-ը՝ ամրագրված արտեֆակտի հեշով։ Workload-ը առօրյա մարդկային հարցումների սառեցված կորպուս է՝ հաղորդագրություններ, նամակներ, բացատրություններ, պլաններ, և ոչ թե բենչմարք-պրոմպտներ։ Reasoning-ն անջատած է; ամեն հարցում դատվում է ֆորմատի, լեզվի և կրկնությունների gate-երով, ձախողված հարցումները մնում են հայտարարի մեջ։
Երեք բջիջների միջև փոխվում է ուղիղ մեկ փոփոխական. քանի հարցում է միաժամանակ թռիչքի մեջ՝ մեկ, չորս, ութ։
Սպասումը՝ չափված
Մեկ հոսքի դեպքում օգնականը պատասխանում է 210մվunit_replicated-ում։ Չորս զուգահեռ չաթի դեպքում մեդիան սպասումը դառնում է 338մվrepeated, ութի դեպքում՝ 865մվrepeated։
Կորի ձևն ավելի կարևոր է, քան ցանկացած առանձին թիվ. առաջին թոքենը մնում է վայրկյանի սահմաններում ամբողջ սանդուղքի վրա, բայց աճն անվճար չէ — չորսից ութ զուգահեռ օգտատիրոջ անցումն ավելի թանկ է, քան մեկից չորս։ Թիմի չափի մասին որոշումը, կայացված միայն մեկհոսք թվից, կսխալվի հենց այն ուղղությամբ, որն ավելի ցավոտ է։
Ինչը չկոտրվեց
Ավարտվածությունը պահպանվեց ամեն աստիճանում. 100.0հարցումների %unit_replicated մեկ հոսքի վրա, 100.0հարցումների %repeated չորսի, 100.0հարցումների %repeated ութի դեպքում։ Ոչ մի հարցում չի հրաժարվել, կտրվել կամ վերադարձվել դատարկ՝ զուգահեռության պատճառով։ Ինչ էլ որ անի այս տուփը բեռի տակ, այն լուռ չի ձախողվում։
Ինչ սա ՉԻ ասում
- Սա տարողունակության պնդում չէ։ «Ութ զուգահեռ հարցում»-ը «ութ աշխատակից» չէ. իրական թիմերն աշխատում են ալիքներով, դադար են տալիս հաղորդագրությունների միջև և տեղադրում երկար փաստաթղթեր։ Մարդը հարցում չէ։
- SLO նախապես չի համաձայնեցվել, ուստի operating envelope այստեղ չկա։ Ազնիվ արդյունքը սպասման ձևն է, ոչ թե սպասարկվող օգտատերերի թիվը։
- Մեկ յունիթ, մեկ արտեֆակտ, մեկ runtime build, մեկ կորպուս։ Prefill-ով գերիշխող բեռը (տեղադրված փաստաթղթեր, RAG-կոնտեքստներ) այլ կերպ է իրեն պահում — դա long-context-ի և doc-session-ի աշխատանքն է, ոչ թե սա։
- Reasoning-ն անջատած է։ Միացրած մտածողության բլոկով սպասումն արդեն մեկ հոսքի վրա երկու կարգով ավելի մեծ է — տես thinking-մոդելի հաշվետվությունը։
Ինչպես օգտվել սրանից չափն որոշելիս
Որոշեք սպասումը, որը ձեր օգտատերերը կհանդուրժեն մինչև առաջին տեսանելի բառը, և կարդացեք սանդուղքը հակառակ ուղղությամբ։ Եթե սահմանը կես վայրկյան է, այս տուփը սպասարկում է փոքր թիմ այս workload-ի վրա; եթե պետք է 250 մվ-ից պակաս՝ մեկ-երկու մարդ միաժամանակ։ Հետո չափեք ձեր սեփական կորպուսը. harness-ը բաց է, իսկ գործարկումների փաթեթները կնքված են և հասանելի ներբեռնման։
Վերևի ամեն թիվ ունի մշտական էջ՝ իր շրջանակով, սահմանափակումներով և հում ապացույցներով. claim-երի ռեեստր։