# Մեկ տուփը՝ կեղտոտ, մյուսը՝ մաքուր. երկու նոդանոց տնային AI-լաբը, որ թվերը պահում է ազնիվ

> Մեր երկու նույնական Strix Halo միավորներն ապրում են հակադիր կյանքերով. մեկը կրում է ամբողջ կոնտեյներային ստեկը, մյուսը սպասարկում է մեկ մոդել և մնում դատարկ։ Բաժանումը կոկիկություն չէ. harness-ն անվավեր է ճանաչում ցանկացած գործարկում, որի հոսթի վրա GPU-հարևան է գտնվել։

- Published: 2026-08-21
- Evidence level: lab_single_run
- Funding: Սեփական ֆինանսավորում, ներքին հետազոտություն
- Canonical: https://agmind.ai/hy/reports/two-node-home-ai-lab/

Կարճ տարբերակը. մեր լաբի երկու Strix Halo տուփերը կոմերցիոն առումով
նույնական են և միտումնավոր հակադիր։ Մեկը կրում է ամբողջ կոնտեյներային
ծառայությունների ստեկը, և նրան թույլատրված է խառնաշփոթ լինել։ Մյուսը մեկ
runtime-ով սպասարկում է մեկ մոդել և մնացած ամեն ինչից դատարկ է պահվում։
Բաժանումը կարգուկանոնի հարց չէ. այն նախապայման է, որը մեր
բենչմարք-harness-ը ֆիզիկապես ստուգում է։
[Habr-ի բնօրինակը՝ ռուսերեն](https://habr.com/ru/articles/1058502/),
պատմում է պատմության օպերացիոն կեսը. այս էջն ավելացնում է այն կեսը, որն
իմաստ ունի միայն մեր չափման կանոնների կողքին։

Երկու մեքենաներն էլ Beelink GTR9 Pro միավորներ են՝ Ryzen AI Max+ 395,
128 ԳԲ unified հիշողություն, ինտեգրված GPU, որն այդ հիշողությունը կիսում է
հոսթի վրա եղած ամեն ինչի հետ։ Վերջին հատկությունն է որոշում
ճարտարապետությունը։ Դիսկրետ քարտով աշխատակայանում կողմնակի ֆոնային
ծառայությունը խլում է մի քիչ CPU և ձեր VRAM-ին ձեռք չի տալիս։ Unified
հիշողության վրա «առանձին» գոյություն չունի. ամեն հարևան ապրում է նույն
թողունակության վրա, որով դեկոդում է ձեր ինֆերենսը։

## Ի՞նչ է աշխատում որ տուփի վրա

Ծառայությունների նոդը՝ կեղտոտը, կրում է պլատֆորմը։ Dify-ն՝ իր API-ով,
worker-ով և վեբ մասերով։ RAGFlow-ն՝ MySQL-ի, Elasticsearch-ի ու MinIO-ի իր
շքախմբով։ Milvus վեկտորային պահոց։ Փոքր llama.cpp սերվերներ, որ ինտեգրված
GPU-ի վրա անում են embedding-ներ ու reranking, որովհետև այդ կանչերը կարճ
են, հաճախակի և բավական հանդուրժող՝ զբաղված հոսթ կիսելու համար։ Prometheus,
Grafana և Loki՝ ամեն ինչին հետևող. Traefik, Authelia, n8n և Open WebUI՝
եզրին։
Habr-ի հոդվածը գրվելու պահին հաշվարկը 34 կոնտեյներ էր։

Ինչ կեղտոտ տուփը չի անում, ծանր գեներացիան է։ Մեծ մոդելների պատասխանները
գալիս են լոկալ ցանցով՝ այլ սարքաշարից. այս տուփը պլատֆորմ է, ոչ թե շարժիչ։

Մաքուր նոդն աշխատեցնում է llama.cpp սերվեր Vulkan backend-ով՝ բեռնված մեկ
Qwen3.6 MoE մոդելով, և դա ամբողջական գույքացուցակն է։ Ոչ բազաներ, ոչ
proxy, ոչ դաշբորդներ։ Չափումների միջև այն գրեթե պարապ է կանգնում՝
միտումնավոր։

## Ինչո՞ւ է չափմանը դատարկ հոսթ պետք

Որովհետև մեր harness-ը ոչ մեկի խոսքին չի վստահում, ներառյալ մերին։ Ամեն
բենչմարք-գործարկում սկսվում է հոսթի գույքագրումով. այդ պահին մեքենայի վրա
կենդանի կոնտեյներների ամբողջական ցուցակը։ Երբ գործարկումն ավարտվում է,
գույքագրումը վերցվում է նորից։ Երկու սնապշոթներն էլ մտնում են գործարկման
մանիֆեստ որպես ապացույց, և եթե դրանցից որևէ մեկում կա GPU-ընդունակ հարևան
— որևէ բան, որ նման է երկրորդ ինֆերենս-սերվերի կամ GPU-runtime-ի — բջիջն
ուղղակի անվավեր է ճանաչվում։ Գործարկման կեսին հայտնված հարևանը չափումը
սպանում է նույնքան հաստատ, որքան սկզբից այնտեղ եղածը։

Սա նույն կեցվածքն է, ինչ
[մեր բենչմարքինգի մեթոդի](https://agmind.ai/hy/reports/how-to-benchmark-local-llm/) մնացած
մասը. պայմանը, որը կարող է արժեզրկել թիվը, պետք է ստուգվի մեքենայով, ոչ թե
խոստացվի տեքստում։ Իսկ երբ «այստեղ ուրիշ ոչինչ չի աշխատում»-ը կոշտ gate է,
այն ամեն օր անցնելու ամենաէժան ձևը երկրորդ մեքենան է, որտեղ աշխատում է
մնացած ամեն ինչը։ Կեղտոտ տուփը գոյություն ունի, որ մաքուր տուփը կարողանա
դատարկ մնալ։ Այդ նախադասությունն ամբողջ ճարտարապետությունն է։

## Ի՞նչ սովորեցրեց կեղտոտ տուփի շահագործումը

**Ամրագրեք ստեկը և գրի առեք ամրագրումները։** Այս GPU-ընտանիքի վրա միջուկի,
firmware-ի ու դրայվերի աշխատող համադրությունը հենց դա է՝ համադրություն։
Անվնաս թվացող մեկ անդամի թարմացումը նախկինում ռեգրեսիաներ է բերել։ Աշխատող
ստեկը գրանցվում է որպես հավաքածու և փոխվում է որպես հավաքածու։

**Ստանդարտ մոնիտորինգը ձախողվում է լռությամբ։** Վաճառողի GPU-գործիքն այս
սիլիկոնի վրա առանցքային սենսորների համար պատասխանում է N/A, ուստի
ջերմաստիճանն ու սնուցումը կարդացվում են միջուկի hwmon ֆայլերից՝
node-exporter-ին կերակրող փոքր կոլեկտորով։
[Մեր DGX Spark մոնիտորինգի հաշվետվության](https://agmind.ai/hy/reports/dgx-spark-gpu-monitoring/)
ընթերցողները հիվանդությունը կճանաչեն. այլ վաճառող, նույն կանաչ ու դատարկ
դաշբորդը, նույն ձանձրալի դեղը։

**GPU offload-ը կարող է անհետանալ առանց սխալի։** Սխալ անվանված Vulkan ICD
մանիֆեստը լուռ անջատում է GPU-ն. գեներացիան շարունակվում է CPU-ի վրա՝
ավելի դանդաղ ու ավելի լուռ։ Վստահելու արժանի միակ հաստատումը runtime-ի
սեփական լոգ-տողն է, որ հայտնում է մոդելի բոլոր շերտերի offload-ը — ահա թե
ինչու harness-ը հայտնաբերված CPU-fallback-ը նույնպես համարում է
անվավերացում, ոչ թե ծանոթագրություն։

Եվս մեկ սովորություն, որ արդարացրեց իրեն. restart-հաշվիչները՝ որպես
առողջության գլխավոր ազդանշան։ Կեղտոտ տուփի գրեթե բոլոր կոնտեյներները երբեք
չեն վերագործարկվել. այն մեկը, որի հաշվիչը զրո չէ, անվանված է Habr-ի
նյութում և հսկվում է։ Հաշվիչը, որ շարժվում է միայն, երբ ինչ-որ բան իրապես
մեռել է, ավելին է ասում, քան կանաչ պանելների պատը։

## Շրջանակ

Այս էջը նկարագրում է երկու կոնկրետ միավոր, մեկ կոնտեյներային ստեկ և
runtime-ի մեկ ընտրություն՝ այնպես, ինչպես դրանք կային Habr-ի նյութի պահին։
Սա օպերացիոն պատմություն է, ոչ թե համեմատական ուսումնասիրություն. մենք
չենք պնդում, որ այս բաժանումն օպտիմալ է, միայն որ հենց այն է թույլ տալիս,
որ ամեն հրապարակված թիվ կրի ապացույց՝ հոսթը հանգիստ էր։ Կոնֆիգուրացիաները,
հիշողության թյունինգը և չափված թվերը
[առաջնային աղբյուրում են՝ Habr-ում](https://habr.com/ru/articles/1058502/),
ռուսերեն։

---

Machine-readable claim registry: https://agmind.ai/claims.json · llms.txt: https://agmind.ai/llms.txt