Եթե օգնականին հարցնեք, թե DeepSeek-V4-Flash-ն ինչ արագությամբ է աշխատում DGX Spark-ի զույգի վրա, թիվ կստանաք։ Վաղը կրկին հարցրեք — կարող եք ուրիշը ստանալ։ Հավանաբար երկու պատասխանն էլ մեջբերում է ինչ-որ իրական բան. հենց այս մոդելի համար հենց այս սարքի վրա հրապարակված թվերը ձգվում են մոտավորապես հիսունականների վերջից մինչև յոթանասունականների սկիզբ՝ վայրկյանում թոքեն, և ցրվածքն աղմուկ չէ — դա մեկ միավորով պատասխանվող չորս տարբեր հարց է։
Այս էջը յուրաքանչյուր թիվ կապում է այն կոնֆիգուրացիայի հետ, որը դա տալիս է։ Այստեղի ամեն թիվ մեջբերվում է մեր իսկ հրապարակային գործարկումների ռեպոզիտորիայից և վերարտադրելի է դրանում եղած բաղադրատոմսով; այս էջում ոչինչ չի գալիս claim registry-ից, որովհետև DGX գիծը մեթոդաբանություն v1-ից դուրս է (տես ստորև սահմանափակումները)։
Չորս հարց, որ թաքնված են «թոքեն վայրկյանում»-ի հետևում
1. Ո՞ր MoE backend-ն է ակտիվ։ Runtime-ի պատկերում կա MoE միջուկ,
հավաքված DeepSeek-V4-ի նատիվ MXFP4 փորձագետների համար GB10-ի վրա — և այն
միտումնավոր բացառված է auto ընտրությունից։ Քարտանման կոնտրոլ պրոֆիլի վրա
auto-ն տալիս է կլիենտային դեկոդի միջին 59.7 tok/s , իսկ
flashinfer_b12x-ը՝ 67.6 tok/s ։ Նույն կշիռները, նույն հանգույցները,
նույն prompt-երը. դրոշակը, որը լռելյայն ոչ ոք չի դնում, արժե
մոտ 13% ։
Եթե հրապարակված թիվը հիսունականների վերջում է, առաջին բանը, որ պետք է
ստուգել, այն է, թե հեղինակն ընդհանրապես գործարկե՞լ է
docker logs … | grep "Mxfp4 MoE backend". auto-ով ստանում ես
DEEPGEMM_MXFP4, ոչ թե B12X_MXFP4։
2. Ի՞նչ էր prompt-ը։ Workload-ի ցրվածքն ավելի մեծ է, քան կոնֆիգուրացիայի փոփոխությունների մեծ մասը։ 500-թոքենանոց սերիայում code պրոֆիլը տալիս է 65.5 tok/s 1 զուգահեռության դեպքում, իսկ ~4K թոքենանոց ռուսերեն տեխնիկական կոնտեքստը («heavy») տալիս է 43.7 tok/s ՝ նույն մեքենան, նույն backend-ը, նույն օրը։ Առանց իր prompt-պրոֆիլի մեջբերված թիվը հնարավոր չէ հերքել։
3. Չափվե՞լ է կլիենտի, թե՞ engine-ի կողմից։ Մեր իսկ առաջին անցումը թոքենները ժամանակագրում էր SSE-ի ժամանման պահով և հաղորդում էր MoE միջուկի 16–18% շահույթ քայլերի հաճախության վրա։ Ավելի ուշ վերաչափումը, որը թվերը վերցնում է engine-ի սեփական հաշվիչներից, նույն շահույթը դրեց 9–12% ։ Կլիենտային մեթոդը շեղված է դեպի վեր. ուշացումը, մինչև առաջին chunk-ը հասնի կլիենտին, հանվում է դեկոդի պատուհանից, իսկ նրա թոքենները շարունակում են հաշվվել։ Ռեպոզիտորիայում ավելի վաղ բաժինը նշեցինք որպես superseded՝ ջնջելու փոխարեն. ուղղությունը մնաց, մեծությունը՝ ոչ։
4. Զուգահեռությունը 1 է, թե՞ ագրեգատ։ c=12-ի դեպքում նույն code պրոֆիլն ագրեգացվում է 260.4 tok/s ։ Դա ճշմարիտ թիվ է և անօգուտ պատասխան «որքա՞ն արագ է զգացվում» հարցին, որը c=1-ի հարց է։ Ագրեգատ թողունակությունն ու միահոսք դեկոդն այստեղ տարբերվում են մոտ 4× ։
Ուրեմն ո՞ր թիվը մեջբերել
- «Որքա՞ն արագ է զգացվում մեկ մարդու համար» — c=1 կլիենտային դեկոդի թիվը ձեր աշխատանքին նման պրոֆիլի վրա. 67.6 tok/s քարտանման կարճ ելքի համար՝ միացրած MoE միջուկով, 43.7 tok/s ծանր 4K-թոքենանոց կոնտեքստի համար։
- «Կարևո՞ր է դրոշակը» — engine-ի կողմից՝ 9–12% վերիֆիկացիայի քայլերի հաճախության վրա։ Ոչ թե կլիենտային 16–18%-ը։
- «Ի՞նչ կարող է տուփն ընդհանուր սպասարկել» — ագրեգատը ձեր թիրախային զուգահեռության դեպքում՝ նշված զուգահեռության հետ միասին, երբեք առանձին։
Ազնիվ սխալի միջակայքեր
Քարտանման կոնտրոլի վրա auto-ն գործարկումների միջև ձգվեց
59.0–60.1 (մոտ 2%), իսկ MoE-միջուկի թևը՝ 62.6–71.0
(մոտ 12%)։ 500-թոքենանոց ագրեգատները նույնական գործարկումների միջև տատանվեցին
18–24% ։ Այստեղի ամեն համեմատության ուղղությունը հետևողական է;
ճշգրիտ մեծությունն այս կրկնությունների քանակի դեպքում լուծելի չէ։ Ով այս դասի
սարքից մեջբերում է երկու տասնորդական նշանով թիվ, մեջբերում է ճշգրտություն,
որը չափումը չունի։
Սահմանափակումներ
- Սա մեթոդաբանություն v1-ի արդյունք չէ։ DGX գիծը bring-up աշխատանք է.
դրա հետևի գործարկումները warmup-ներով միանվագ անցումներ են, ոչ թե եռակի
կրկնության և սառեցված workload-ի այն կարգապահությունը, որը կանգնած է մեր
claim-երի ռեեստրի հետևում։ Հենց դրա համար է այն պիտակված
lab_single_run։ - Մեկ մոդել, մեկ չեքփոինթ, մեկ runtime image։ MoE-միջուկի գտածոն վերաբերում է հատկապես GB10-ի վրա DeepSeek-V4-ի MXFP4 փորձագետներին — այն ոչինչ չի ասում այլ MoE մոդելների կամ այլ սարքի մասին։
- Խաղի մեջ է սպեկուլյատիվ դեկոդինգը։ Թոքենների հաշվառումն օգտագործում է
usage.completion_tokens-ը, երբեք SSE իրադարձությունների քանակը. սպեկուլյատիվ դեկոդինգի տակ մեկ իրադարձությունը կարող է կրել մի քանի ընդունված թոքեն, և իրադարձությունների հաշվարկը լուռ ուռճացնում է թողունակությունը։
Գտե՞լ եք թիվ, որը շեղվում է սրանցից որևէ մեկից։ Ուղարկեք հակասող թիվը — շեղման հետևում կանգնած կոնֆիգուրացիոն դելտան սովորաբար ավելի տեղեկատվական է, քան թվերից որևէ մեկը։
Ինչպես վերարտադրել
Սերվինգի բաղադրատոմսը, գործարկման սկրիպտները, run-մանիֆեստը՝ image-ի digest-ով և մոդելի ռևիզիայով, և հում ելքերը բաց են. botAGI/dspark-0731-gb10։ Այս էջի հետևում կանգնած լոնգրիդը՝ ռուսերեն, Habr-ում է։
Առնչվող՝ նույն կլաստերի վրա 1M կոնտեքստի խորության կորը և MoE backend-ի հաշվետվությունը։