Երկու DGX Spark դասի սարք, մեկ մոդել՝ յուրաքանչյուրի վրա մոդելի ամբողջական պատճեն

Օպերացիաներ2026-10-31

Յոթ շաբաթ մեր տեղական լեզվական մոդելը աշխատում էր երկու NVIDIA GB10 մեքենաների միջև բաժանված՝ օգտագործելով տենզորային զուգահեռացում։ Հոկտեմբերի 22-ին մենք դրա փոխարեն յուրաքանչյուր մեքենայի վրա տեղադրեցինք մոդելի ամբողջական պատճենը և առջևում դրեցինք նվազագույն կապերով պրոքսի։ Արտադրողականությունը մոտ 180-ից դարձավ 210 տոկեն վայրկյանում, և այժմ ցանկացած մեքենա կարող է վերագործարկվել՝ առանց մոդելը հասանելիությունից զրկելու։

Ինչու էինք բաժանել մոդելը

Յուրաքանչյուր մեքենա ունի 128 ԳԲ հիշողություն, որը բաժանված է CPU-ի և GPU-ի միջև։ Սեպտեմբերին մոդելը տեղավորվում էր մեկ մեքենայի վրա, բայց նրա քեշը գրեթե չէր տեղավորվում. մեր օգտագործած vLLM կառուցվածքը չէր կարողանում պահել այս մոդելի KV քեշը FP8 ձևաչափով, ուստի քեշը BF16 էր, և մեկ մեքենայում դրա համար կար 499,110 տոկենի տեղ։ Դա մոդելի 262,144 տոկենի ամբողջական համատեքստով երկու հարցումից էլ քիչ է։ Երկու մեքենաների միջև բաժանելով մոդելը՝ օգտագործելով տենզորային զուգահեռացում նրանց ուղղակի ցանցային կապի միջոցով, քեշը աճեց մինչև ավելի քան երեք միլիոն տոկեն։ Մենք բաժանել էինք մոդելը տեղի համար, ոչ թե արագության համար։

Ինչ փոխվեց

Նույն մոդելի ավելի նոր 4-բիթանոց կառուցվածքը (NVFP4, ստացված քվանտացմանը հաշվի առնող դիստիլյացիայի միջոցով) զբաղեցնում է մոտ 71 GiB հիշողություն, և GB10-ի համար համայնքային vLLM կառուցվածքը (eugr/spark-vllm-b12x) աշխատեցնում է նրա քեշը FP8-ով։ Այժմ մեկ մեքենա պահում է ամբողջ մոդելը և 0.76-ից 1.08 միլիոն տոկենի քեշ, ինչը ամբողջական համատեքստով 2.9-ից 4.1 հարցման տեղ է՝ կախված նրանից, թե մեքենան որքան հիշողություն է տրամադրում։ Երկու պատճեններն էլ օգտագործում են մոդելի սեփական սպեկուլյատիվ դեկոդավորումը (MTP, չորս սևագիր տոկեն)։ Փոխանակումից առաջ մենք նոր կառուցվածքի վրա կատարեցինք մեր գործիքային կանչերի թեստը. այն ստացավ 86 միավոր, իսկ փոխարինված կառուցվածքը՝ 75։

Ինչ էինք չափել

Մեկ պատճենը՝ առանձին, ըստ միաժամանակ սպասարկվող հարցումների թվի. կարճ հարցումներով 1 հարցումը տալիս էր 36 տոկեն վայրկյանում, 4-ը՝ 82, 8-ը՝ 109 և 16-ը՝ 150: Մեր էլ-փոստի գործակալի ավելի երկար հարցումներով 4-ը տալիս էր 81, 8-ը՝ 113, իսկ 16-ը՝ ընդամենը 87. ութից ավելի հարցումների դեպքում ավելին դարձնում էր ավելի դանդաղ:

Կեսօրվա ընթացքում մեկ պատճենը վերցնում էր առավելագույնը 12 հարցում միաժամանակ, իսկ մյուսը՝ 8: Առաջինը արտադրում էր 91-ից 93 տոկեն վայրկյանում և ավարտում 26-ից 27 հարցում րոպեում, երկրորդը՝ 81-ից 83 տոկեն վայրկյանում և 22 հարցում րոպեում: Այժմ երկուսն էլ վերցնում են 12:

Ինչից հրաժարվեցինք

Տարածքից: Բաժանված մոդելն ուներ 3 միլիոնից ավելի տոկենի մեկ քեշ, պատճեններն ունեն երկու ավելի փոքր քեշ, և հարցումը կարող է օգտագործել միայն այն պատճենի քեշը, որը սպասարկում է այն: Մեր գործակալները ուղարկում են շատ կարճ և միջին հարցումներ, և դրանց համար արտադրողականությունն ավելի կարևոր էր: Եթե դուք սպասարկում եք միաժամանակ մի քանի շատ երկար համատեքստեր, բաժանումը կարող է դեռ ավելի լավ ընտրություն լինել: Մենք պահպանեցինք բաժանված կարգավորումը, և հետ դառնալը մեկ սկրիպտ է:

Ինչ սխալվեց անցման ընթացքում

1. Տասնմեկ րոպե առանց մոդելի, ապա 30 վայրկյան 502 սխալներ: Բաժանված մոդելը պետք է կանգնեցվեր, նախքան պատճենը կարող էր բեռնվել նույն մեքենաներում, ուստի մեր գործակալները սպասեցին մոտավորապես տասնմեկ րոպե: Երբ առաջին պատճենը բարձրացավ, պրոքսին շարունակում էր պատասխանել «502 no live upstreams» մոտավորապես 30 վայրկյան ևս. այն նշել էր բեքենդները որպես ձախողված, մինչ դրանք կանգնած էին (max_fails=3, fail_timeout=30s), և չէր փորձում դրանք նորից, մինչև ժամանակը չլրանար:
2. Պրոքսին բաց թողնող հաճախորդ: Մեր խմբային աշխատանքներից մեկն ուներ առաջին մեքենայի հասցեն իր կոնֆիգում, ուստի ամբողջ բեռը գնաց մեկ պատճեն, մինչդեռ մյուսն ուներ ազատ հզորություն: Այժմ բոլոր հաճախորդներն անցնում են պրոքսիով, մեքենաների սեփական հասցեները միայն առողջության ստուգումների համար են:
3. Ցատկած մետրիկաներ: Մեր արտադրողականության մոնիտորը կարդում էր vLLM-ի /metrics-ը պրոքսիով: Երկու բեքենդների դեպքում հաջորդական ընթերցումները գալիս էին տարբեր պատճեններից, հաշվիչները ցատկում էին առաջ-հետ, և մոնիտորը մոդելը հաղորդում էր որպես սոված: Այժմ այն կարդում է յուրաքանչյուր պատճեն ուղղակիորեն և գումարում դրանք:
4. Հին վոչդոգ, որը կանգնեցնում էր նոր պատճենը։ Բաժանված կոնֆիգուրացիան ուներ վոչդոգ, որը վերագործարկում էր իր ծառայությունը, երբ մոդելը դադարում էր պատասխանել։ Նոր ծառայությունը հայտարարում է Conflicts= հինի հետ, ուստի այդ վերագործարկումը կանգնեցներ նոր պատճենը։ Այն պետք է անջատել systemctl disable --now հրամանով, ոչ թե պարզապես կանգնեցնել, քանի որ մեր օպերացիոն շերտը վերագործարկում է միավորները, որոնք միացված են, բայց չեն աշխատում։
5. Հիշողություն այն մեքենայի վրա, որը կատարում է այլ աշխատանքներ։ Մեկ մեքենա նաև վարում է մեր տվյալների բազաները և կայքի կառուցումները։ vLLM-ի gpu-memory-utilization-ը 0.78-ի դեպքում մնացել էր ընդամենը 5 GiB մնացած ամեն ինչի համար, ուստի մենք իջեցրինք այն մինչև 0.74 և վերագործարկեցինք միայն այդ պատճենը, մինչդեռ մյուսը ստանձնում էր բեռը։ Այս մեքենաներում vLLM-ին տրամադրվող հիշողության բաժինը վերցվում է նույն հիշողությունից, ինչ ամեն ինչը։

Եթե դուք ունեք այս մեքենաներից երկուսը

• Եթե մոդելը և ձեզ անհրաժեշտ քեշը տեղավորվում են մեկ մեքենայի վրա, աշխատեցրեք պատճեն յուրաքանչյուրի վրա՝ նվազագույն կապերով պրոքսիի հետևում։ Բաժանեք մոդելը միայն այն դեպքում, եթե մեկ մեքենան չի կարողանում պահել ձեզ անհրաժեշտ քեշը։
• Ուղղեք բոլոր կլիենտները դեպի պրոքսի, ներառյալ խմբային առաջադրանքները և հին կոնֆիգուրացիաները։
• Կարդացեք մետրիկաները յուրաքանչյուր պատճենից ուղղակիորեն։
• Տրամադրեք յուրաքանչյուր մեքենայի իր հիշողության բաժինը՝ համաձայն նրա վրա աշխատող մնացածի։
• Որոշեք, թե քանի հարցում է մեկ պատճենը սպասարկում միաժամանակ՝ ձեր սեփական երթևեկությամբ. մեր խառնուրդի համար 12-ը գերազանցում էր 8-ին։
• Սպասեք, որ անջատումը կհեռացնի մոդելը այնքան ժամանակ, որքան պատճենին անհրաժեշտ է մեկնարկելու համար, և պլանավորեք դա։

Factory Floor-ը տրամադրում է պրոքսի և մեկնարկային կոնֆիգուրացիաներ մեկ կամ երկու մեքենայի համար, առողջության ստուգում և գործիքների օգտագործման թեստ, որը մենք կատարում ենք մոդելները փոխելուց առաջ, ինչպես նաև վոչդոգներ և հիշողության պահպանիչներ մեքենայի մնացածի համար։