Հաշվետվություն

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

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

lab_single_run internal research 21 օգոստոսի, 2026 թ. · Ֆինանսավորում: Սեփական ֆինանսավորում, ներքին հետազոտություն

Մեկ պարբերության տարբերակը. 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 ԳԲ-ի հաշվետվությունում, իսկ սեփականը չափելու պրոտոկոլը՝ այստեղ։

Ինչպես մեջբերել

AGmind Systems Lab (2026-08-21). Հիշողությունը Strix Halo-ի վրա. ինչու է ROCm-ը 128 ԳԲ-ից փշրանքներ տեսնում, և ինչ կարգավորել BIOS-ի փոխարեն. Evidence level: lab_single_run. https://agmind.ai/hy/reports/strix-halo-memory-allocation/
← Հաշվետվություններ