# Հիշողությունը Strix Halo-ի վրա. ինչու է ROCm-ը 128 ԳԲ-ից փշրանքներ տեսնում, և ինչ կարգավորել BIOS-ի փոխարեն

> Ryzen AI Max+ 395 տուփի ամենահաճախ հանդիպող առաջին խափանումը. մոդելը չի տեղավորվում, կամ runtime-ը 128 ԳԲ մեքենայի վրա ցույց է տալիս մի քանի գիգաբայթ VRAM։ BIOS-ը գրեթե միշտ սխալ լծակն է։ Ինչ է հաղորդում մեր սերվինգ հանգույցի sysfs-ը և որ պարամետրն է որոշում։

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

Մեկ պարբերության տարբերակը. Linux-ի վրա BIOS-ում մեծ VRAM կտոր
առանձնացնելը սովորաբար պետք չէ։ Մեր սերվինգ հանգույցը հատկացված կտորը
թողնում է չնչին և GPU-ին թույլ տալիս հասնել համակարգային հիշողության գրեթե
ամբողջին GTT-ի՝ միջուկի գրաֆիկական հասցեների թարգմանության աղյուսակի,
միջոցով, իսկ առաստաղը որոշում է միջուկի TTM պարամետրը, ոչ թե
firmware-ի մենյուի կետը։ Ստորև այն է, ինչ այդ մեքենան հաղորդում է հենց
հիմա՝ երկու բեռնված մոդելով։

## Ախտանիշը

Գնում եք 128 ԳԲ Ryzen AI Max+ 395 տուփ հենց մեծ մոդելներ աշխատեցնելու
համար, իսկ runtime-ը հայտարարում է սարքի ընդամենը մի քանի գիգաբայթ
հասանելի հիշողություն։ Կամ մոդելը, որը պետք է տեղավորվեր, հրաժարվում է
բեռնվել։ Կամ ROCm-ը և Vulkan-ը իրար հետ չեն համաձայնվում, թե որքան
հիշողություն կա։ Բնազդը BIOS-ի մեջ վերաբեռնվելն է և GPU-ին ավելի մեծ կտոր
հանձնելը, և հենց այստեղ է կորչում ժամանակը. հատկացված կտորն այն տեղը չէ,
որտեղ unified memory-ով Linux տուփը պահում է մոդելները։

## Ինչ է հաղորդում մեր հանգույցը

Սա Beelink GTR9 Pro-ն է՝ llama.cpp սպասարկելիս, 7.0 միջուկի վրա, կարդացված
ուղիղ sysfs-ից՝ երկու բեռնված մոդելի պայմաններում.

```
mem_info_vram_total:    512 MiB      # BIOS-ում հատկացված կտորը
mem_info_gtt_total:  120266 MiB      # ինչին GPU-ն իրականում հասնում է
mem_info_gtt_used:   108704 MiB      # երկու ռեզիդենտ մոդել, հենց հիմա
```

Կես գիգաբայթ «VRAM» այն մեքենայի վրա, որը հանգիստ պահում է հարյուր
գիգաբայթ կշիռ։ Հատկացված կտորը մոտ է այն նվազագույնին, որն ընդհանրապես
առաջարկում է firmware-ը, և դա նշանակություն չունի, որովհետև ամեն էական բան
անցնում է GTT-ի միջով։

## Պարամետրը, որն իրականում որոշում է առաստաղը

GTT-ն թույլ է տալիս GPU-ին քարտեզագրել համակարգային հիշողությունը, իսկ թե
որքան կարող է քարտեզագրել, սահմանափակում է TTM-ը՝ միջուկի գրաֆիկական
սարքերի հիշողության կառավարիչը։ Դրա էջերի սահմանն է առաջինը ստուգելու
բանը.

```
# pages, at 4 KiB each
cat /sys/module/ttm/parameters/pages_limit
```

Մեր հանգույցի միջուկի հրամանային տողում կա `ttm.pages_limit=30788203` —
այստեղից է վերևի ~117 GiB առաստաղը։ Շատ դիստրիբուտիվներում լռելյայն դրված
է համակարգային հիշողության մի մասնաբաժինը, և հենց այդ լռելյայնն է, ոչ թե
BIOS-ը, որ թույլ չի տալիս մեծ մոդելին բեռնվել։ Բարձրացրեք, վերաբեռնեք և
վերընթերցեք երկու sysfs ֆայլերը՝ նախքան որևէ այլ բանի հավատալը։

Երկու բան, որ արժե իմանալ, քանի դեռ այնտեղ եք։ Առաջին՝ ստուգեք սարքից, ոչ
թե գործիքից։ `/sys/class/drm/card*/device/`-ի տակ գտնվող
`mem_info_gtt_total`-ը և `mem_info_gtt_used`-ը հենց ճշմարտությունն են, իսկ
runtime-ները հաճախ հաղորդում են «VRAM»-ի իրենց սեփական պատկերացումը, որը
բոլորովին այլ բան է նշանակում։ Երկրորդ՝ թողեք պահուստ։ Մեր հանգույցի վրա,
ռեզիդենտ մոդելների պայմաններում, հոսթին մնացել էր սովորական RAM-ի մի քանի
գիգաբայթ. GTT-ի հատկացումները վերցվում են հենց այն ֆիզիկական
հիշողությունից, որից օգտվում է օպերացիոն համակարգը, իսկ սպասարկման
ընթացքում swap գնացող տուփը հապաղման խնդիր է, որը դուք ախտորոշելու եք
որպես մոդելի խնդիր։

## Ինչու է BIOS-ի կտորը սխալ լծակ

Հատկացված կտորը կտրվում է հենց նույն ֆիզիկական հիշողությունից և դրանից
հետո անհասանելի է դառնում մնացած ամեն ինչին, ներառյալ հենց այն GTT ուղին,
որը runtime-ը նախընտրում է։ GPU-ին մեծ ֆիքսված կտոր հանձնելը տարողություն
չի ավելացնում, այլ ճկուն հիշողությունը դարձնում է ոչ ճկուն։ Windows-ն
այստեղ այլ կերպ է վարվում, և այս սարքաշարի շուրջ շրջանառվող խորհուրդների
զգալի մասը լուռ ենթադրում է Windows կամ ավելի հին միջուկ. նայեք, թե որ
պլատֆորմի համար է գրված հրահանգը, նախքան firmware-ի մենյու մտնելը։

Սրանցից ոչ մեկը պնդում չէ, թե մեծ կտորը ոչ մի բեռի չի օգնում։ Սա
նկարագրություն է այն մասին, թե ինչ է հաղորդում մեկ սերվինգ հանգույց՝
կարգավորված ուղիղ մեկ աշխատանքի տակ, հենց այդ աշխատանքը կատարելիս։

## Ինչ ստուգել՝ ըստ հերթականության

1. `cat /sys/module/ttm/parameters/pages_limit` — իրական առաստաղը։
2. `/sys/class/drm/card*/device/mem_info_gtt_total` — ինչին է GPU-ն
   հասնում։
3. `mem_info_gtt_used` բեռնված մոդելի պայմաններում — արդյոք ամեն ինչ գնաց
   այնտեղ, ուր կարծում եք։
4. Ազատ համակարգային հիշողությունը բեռի տակ — պահուստ, ոչ միայն
   տարողություն։
5. Եվ միայն դրանից հետո՝ BIOS-ը։

## Շրջանակ

Մեկ հանգույց, մեկ միջուկի շարք, մեկ դիստրիբուտիվ՝ կարգավորված llama.cpp-ի
սերվինգի տակ։ Միջուկի և դրայվերի վարքն այս սարքաշարի վրա արագ է շարժվում;
վերաբերվեք վերևի թվերին որպես նրան, ինչ այս մեքենան հաղորդում է այսօր, ոչ
թե որպես սպեցիֆիկացիա։ Ինչ է անում տուփը, երբ հիշողության հարցը լուծված է,
չափված է [128 ԳԲ-ի հաշվետվությունում](https://agmind.ai/hy/reports/what-128gb-unified-memory-runs/),
իսկ սեփականը չափելու պրոտոկոլը՝
[այստեղ](https://agmind.ai/hy/reports/how-to-benchmark-local-llm/)։

---

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