Տեղակայման ուղեցույց

Ինչպես տեղակայել մեծ MoE DGX Spark-ի վրա vLLM-ով. մեկ հանգույցից մինչև զույգ

Տեղակայման հերթականությունը, որը շրջանցում է մեր GB10 զույգի վրա բռնած լուռ կախումները. ամրագրված կշիռներ և image, head-ը peer-ից առաջ, պատրաստվածությունը endpoint-ով, ոչ թե զգացողությամբ, և MoE միջուկի ընտրության ստուգումը, որն արագ կոնֆիգը բաժանում է սովորականից։

Պլատֆորմ:
DGX Spark (GB10)
Անցնելու ժամանակը:
2-3 ժ
Թարմացվել է:
01.09.2026

Սա մեր սերվինգ բաղադրատոմսի ձեռնարկային տարբերակն է — նույն քայլերը՝ դասավորված առաջին անգամ անողի համար, թակարդները, որոնց համար մենք վճարել ենք, նշված են նախքան դրանց հասնելը։ Գրվել է GB10 միավորների իրական զույգի վրա, որը սպասարկում է 284B պարամետրով MoE; մեկ հատ Spark-ը գնում է նույն ուղով՝ հանած ֆաբրիկայի բաժինը։

Ձեզ պետք է. մեկ կամ երկու DGX Spark՝ ընթացիկ firmware-ով, Docker՝ NVIDIA runtime-ով, և շատ սկավառակ — ֆրոնտիր դասի կշիռները չափվում են հարյուրավոր գիգաբայթներով մեկ հանգույցի հաշվով։

Քայլ 1 — ամրագրեք ամեն ինչ՝ նախքան որևէ բան ներբեռնելը

Երեք ինքնություն են որոշում, թե ձեր տեղակայումը հետագայում հնարավոր կլինի՞ դեբագել. մոդելի ռևիզիան, կոնտեյների digest-ը և firmware-ի տարբերակը։ Նախ գրի առեք երեքն էլ։ main-ը շարժվում է, tag-երը շարժվում են, իսկ Spark-ի firmware թարմացումները պատմականորեն վարքը փոխել են այնքան, որ շրջել են համայնքի տրամադրությունն ամբողջ սարքի նկատմամբ։ Տեղակայումը, որը չեք կարող ճշգրիտ անվանել, տեղակայում է, որի դեբագին որևէ մեկին օգնության կանչել չեք կարող։

# գրանցեք այս երեք տողը մշտական մի տեղում.
# model:    <repo> @ <revision>
# image:    vllm/vllm-openai@sha256:<digest>
# firmware: (ձեր համակարգի տվյալներից)

Քայլ 2 — կշիռները ամեն հանգույցի վրա

Զույգի համար. ամբողջական կշիռները գնում են ԵՐԿՈՒ հանգույցի վրա էլ՝ նույնական ռևիզիա։ Դրա համար իրական ժամանակ նախատեսեք և վերջում ստուգեք, որ չափերը համընկնում են։ Մեկ հանգույցի համար ընտրեք մոդել, որն իրոք տեղավորվում է մեկ սարքում — ֆրոնտիր դասը չի տեղավորվում, հենց դրա համար էլ զույգը կա։

Քայլ 3 — նախ մեկ հանգույց, նույնիսկ եթե երկուսն ունեք

Նախ բարձրացրեք մեկ հանգույցը մենակ, նախքան տենզորային զուգահեռականությանը ձեռք տալը։ Ձեզ պետք է սովորել կոնտեյների վարքը — գործարկման ժամանակը, հիշողության օրինաչափությունը, լոգերի ձևը — առանց ֆաբրիկայի՝ որպես երկրորդ փոփոխականի.

docker run -d --name vllm --gpus all \
  -v /var/lib/llm/models:/models -p 8000:8000 \
  vllm/vllm-openai@sha256:YOUR_DIGEST \
  --model /models/YOUR-MODEL --max-model-len 32768

Պատրաստվածությունը endpoint է, ոչ թե զգացողություն. սերվերը բարձրացել է, երբ curl localhost:8000/v1/models-ը պատասխանում է։ Այս դասի մոդելի կշիռների բեռնումը րոպեներ է տևում — հետևեք docker logs -f vllm-ին և կես ճանապարհին անհամբերությունից մի վերագործարկեք։

Քայլ 4 — զույգի համար. նախ head-ը, հետո peer-ը, հենց այդ հերթականությամբ

Rank-0 հանգույցը պահում է կոորդինացիոն store-ը։ Peer-ը, որը գործարկվել է նախքան head-ի լսել սկսելը, մեռնում է broken pipe-ով՝ առանց օգտակար սխալի — գրված վիճակում այս հերթականության բագը ակնհայտ է թվում, բայց մեզ իրական ժամեր է արժեցել։ Աշխատող հաջորդականությունը. գործարկեք head-ը, սպասեք, մինչև store-ի պորտը երևա ss -tln-ում, միայն դրանից հետո գործարկեք peer-ը։ Ֆաբրիկայի կարգավորումների (head-ի և peer-ի IP-ներ, HCA, GID index) տեղը ձեր գործարկման սկրիպտի վերևի environment փոփոխականներն են, ոչ թե դրա միջով ցրված։

Քայլ 5 — ստուգեք, որ միջուկի ընտրությունն իրոք գործեց

MoE մոդելների համար vLLM-ի backend-ի ավտոընտրությունը կարող է միտումնավոր բաց թողնել հենց ձեր մոդելի քվանտացման համար կառուցված միջուկը։ Grep-եք լոգերը MoE backend-ի տողի համար և ստուգեք, թե որն է բեռնվել — տարբերությունը կոսմետիկ չէ։ Եթե ձեր մոդելի ընտանիքն ունի մասնագիտացված backend, դրեք այն բացահայտ և նորից ստուգեք լոգը։ Այս մեկ ստուգումը ամենահաճախ հանդիպող տարբերությունն է հրապարակված Spark-թվի և հիասթափված ֆորումային գրառման միջև։

Քայլ 6 — smoke-թեստը

Նույն կարգապահությունը, ինչ ցանկացած տուփի վրա. ուղարկեք իրական chat completion, ստուգեք, որ content-ը դատարկ չէ և finish_reasonstop է, իսկ թոքենների հաշիվը վերցրեք usage.completion_tokens-ից — speculative decoding-ի դեպքում streaming-իրադարձությունների հաշիվը ստում է։

Քայլ 7 — մոնիտորինգ՝ նախքան այն ձեզ պետք կգա

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

Հաջորդ քայլերը

← Բոլոր ուղեցույցները