DeepSeek-V4-Flash 0731-ը երկու DGX Spark-ի վրա. բաղադրատոմսը՝ նշված թակարդներով

Սա runbook-ն է մեր հրապարակված DeepSeek-V4-Flash-0731 թվերի հետևում՝ DGX Spark-երի զույգի վրա (GB10, TP=2՝ 200G RoCE-ով) — ամեն քայլն այնպես, ինչպես իրականում գործարկում ենք, իսկ թակարդները, որոնք մեզ ժամանակ արժեցան, նշված են որպես թակարդներ։ Հեղինակային, տարբերակավորված պատճենն ապրում է հրապարակային ռեպոզիտորիայում՝ run-մանիֆեստի և հում ելքերի հետ միասին; այս էջը ծանոթագրված շրջայցն է։

Հինգ քայլերը

1. Կշիռները ԵՐԿՈՒ հանգույցի վրա — ~156 GiB սկավառակի վրա՝ մեկ հանգույցին

ռևիզիայով; պաշտոնական չեքփոինթը ռեպոզիտորիայում նշված է, բայց մեր թվերը ոչ նրան են նկարագրում։ Ամրագրեք ռևիզիան — main-ը շարժվում է։

2. Runtime-ի պատկերը digest-ով՝ երկու հանգույցի վրա։ Թեգերը շարժվում են; ռեպոզիտորիայի digest-ը՝ ոչ։ Ամեն հրապարակված թիվ անվանում է այն digest-ը, որի տակ գործարկվել է — հենց դա է ապագա տարաձայնությունը դարձնում ախտորոշելի։

3. Սկզբում HEAD-ը, հետո peer-ը։ Rank 0-ն է հյուրընկալում TCPStore-ը; peer-ը, որը միանում է նախքան head-ը կսկսի լսել, կախվում է broken pipe-ի վրա՝ առանց օգտակար սխալի։ Գործարկեք head-ը, սպասեք, մինչև ss -tln-ը ցույց տա, որ store-ի պորտը լսում է, միայն հետո գործարկեք peer-ը։ Կարգի այս բագը գրված վիճակում ակնհայտ է կարդացվում — կենդանի իրավիճակում այն մեզ իրական ժամեր արժեցավ։

4. Պատրաստ է, երբ /v1/models-ը պատասխանում է։ Կշիռների բեռնումը տևում է ≈6–7 րոպե ; ֆաբրիկայի կարգավորումները (head/peer IP-ներ, HCA, GID index) միջավայրի փոփոխականներ են գործարկման սկրիպտի վերնամասում։

5. Ստուգեք, որ MoE backend-ն իրոք գործել է։ Engine-ը ներառում է միջուկ՝ հատուկ հավաքված այս մոդելի MXFP4 փորձագետների համար GB10-ի վրա, և միտումնավոր բացառում է այն auto-ից.

docker logs vllm_dsv4 2>&1 | grep "Mxfp4 MoE backend"
# պետք է՝ Using 'B12X_MXFP4'     ոչ թե՝ Using 'DEEPGEMM_MXFP4'

Այս ստուգումը բաց թողնելն ամենատարածված պատճառն է, որ Spark-ի հրապարակված թիվը հայտնվում է հիսունականների վերջում՝ վաթսունականների վերջի փոխարեն. auto-ն մեզ տվեց 59.7 tok/s կլիենտային դեկոդ այնտեղ, որտեղ flashinfer_b12x-ը տվեց 67.6 ՝ engine-ի կողմից չափված 9–12% վերիֆիկացիայի քայլերի հաճախության շահույթ

Ինչ թվեր սպասել

Վերջնական կոնֆիգուրացիան և մեդիանները կրկնվող հարցումների վրայով՝ հրապարակային արդյունքներից ։

Պրոֆիլային ցրվածքն ավելի մեծ է, քան կոնֆիգուրացիոն փոփոխությունների մեծ մասը — առանց իր պրոֆիլի մեջբերված թիվը հնարավոր չէ հերքել։ Թե ինչու ֆորումներում շրջանառվող թվերը միմյանց հետ չեն համընկնում — առանձին էջ։

Թոքենները հաշվեք usage.completion_tokens-ից, երբեք՝ SSE իրադարձությունների քանակից։ Սպեկուլյատիվ դեկոդինգի տակ մեկ իրադարձությունը կարող է կրել մի քանի ընդունված թոքեն; իրադարձությունների հաշվարկը թողունակությունը լուռ ուռճացնում է։

Մոնիտորինգի թակարդը

GB10-ի unified memory-ի վրա dcgm-exporter-ն ընդհանրապես չի աշխատում, իսկ NVML-ը հարցումների զգալի մասի վրա վերադարձնում է N/A — ձեր Grafana-ն կլինի կանաչ ու դատարկ։ Մենք nvidia-smi-ն սեփական textfile collector-ով պարսում ենք node-exporter մետրիկների մեջ; վերլուծությունը Habr-ում է, ռուսերեն։ Սա դրեք բյուջեի մեջ. սերվինգի տուփը, որը չես կարող դիտարկել, տուփ է, որը չես կարող շահագործել։

Ազնվության բաժինը

• Այստեղ ամեն ինչ lab_single_run է. միանվագ անցումներ warmup-ներով, մեկ զույգ միավոր, մեր եռակի կրկնության մեթոդաբանությունից դուրս։ Սխալի միջակայքերը սարքաշարի այս դասի վրա լայն են — նույնական ագրեգատային գործարկումները տատանվում էին 18–24% սահմաններում, — ուստի մեկ տասնորդականի ճշգրտությունը ցանկացած աղբյուրից, ներառյալ մերը, համարեք լավատեսություն։
• Մեր սեփական չափման առաջին անցումը կլիենտային կողմի շեղում ուներ, և մենք ռեպոզիտորիայում այն նշեցինք superseded՝ ջնջելու փոխարեն; մեջբերելու արժանի սերիան engine-ի կողմինն է։
• Գտե՞լ եք թիվ, որը չի համընկնում։ Ուղարկեք այն — տարաձայնության հետևում կանգնած կոնֆիգուրացիոն դելտան սովորաբար ավելի տեղեկատվական է, քան թվերից որևէ մեկը։

Առնչվող՝ 1M-կոնտեքստի խորության կորը · MoE backend-ի հաշվետվությունը · արժե՞ արդյոք Spark-ն ընդհանրապես։