mem_info_vram_total: 512 MiB

Ինչ եք տեսնում

Հատկացված VRAM-ի չնչին թիվ մի տուփի վրա, որը գնվել է հենց հիշողության համար։ Մոդելը, որը պետք է տեղավորվեր, հրաժարվում է բեռնվել։ ROCm-ն ու Vulkan-ը տարբեր բան են ասում այն մասին, թե որքան հիշողություն կա։ Կարդացված է մեր սերվինգ հանգույցի sysfs-ից այն պահին, երբ երկու մոդել նստած էր հիշողության մեջ.

mem_info_vram_total:    512 MiB      # the BIOS-dedicated slice
mem_info_gtt_total:  120266 MiB      # what the GPU can actually reach
mem_info_gtt_used:   108704 MiB      # two resident models, right now

Առաջին տողն է, որ մարդկանց անհանգստացնում է; երկրորդն ու երրորդն են, որ նշանակություն ունեն։ Այս հանգույցի վրա առաստաղն արդեն բարձրացված էր, հենց դրա համար էլ երկու մեծ մոդել ընդհանրապես տեղավորվել է GTT-ում։ Դիստրիբուտիվի լռելյայն էջերի սահմանի դեպքում հենց mem_info_gtt_total տողն է, որ պակաս է ստացվում։

Որտեղ ենք հանդիպել

Beelink GTR9 Pro (Ryzen AI Max+ 395), 7.0 միջուկ, llama.cpp սպասարկելիս։ Ցուցմունքները /sys/class/drm/card*/device/-ից՝ երկու բեռնված մոդելով, 2026-08-21 թվագրված հաշվետվության համար։ 2026-09-01 թվագրված տեղակայման ուղեցույցը նույն ստուգումը դարձնում է իր Քայլ 1-ը՝ նախքան llama.cpp server-ի Vulkan build-ը գործարկելը (ghcr.io/ggml-org/llama.cpp:server-vulkan)։ Շրջանակը՝ ինչպես հաշվետվությունն է այն ձևակերպում. մեկ հանգույց, միջուկի մեկ շարք, մեկ դիստրիբուտիվ՝ llama.cpp-ի սպասարկման համար կարգավորված։

Պատճառ

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

BIOS-ի կտորը մեծացնելը տարողություն չի ավելացնում։ Սա այն է, ինչ հաղորդում է մեկ սերվինգ հանգույց՝ մեկ աշխատանքի համար կարգավորված, ոչ թե պնդում, թե մեծ կտորն ոչ մի workload-ի երբեք չի օգնում։ Կտորը կտրվում է հենց նույն ֆիզիկական հիշողությունից և անհասանելի է դառնում մնացած ամեն ինչին, ներառյալ հենց այն GTT ուղին, որը runtime-ը նախընտրում է; այն ճկուն հիշողությունը դարձնում է ոչ ճկուն։ Այս սարքաշարի մասին շրջանառվող խորհուրդների զգալի մասը լուռ ենթադրում է Windows կամ ավելի հին միջուկ։ Runtime-ները հաղորդում են «VRAM»-ի իրենց սեփական պատկերացումը, որը բոլորովին այլ բան է նշանակում; sysfs ֆայլերն են ճշմարտությունը։

Լուծում

Նախ ստուգեք ընթացիկ առաստաղը։ Արժեքն էջերով է, ոչ թե բայթերով.

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

Եթե դա ձեր RAM-ի ընդամենը մի մասն է, բարձրացրեք այն միջուկի հրամանային տողում և վերագործարկեք։ Մեր հանգույցի միջուկի հրամանային տողը կրում է ներքևի արժեքը, հենց այստեղից է վերևի mem_info_gtt_total տողը; այն հաշվարկված է այս տուփի RAM-ի համար, այնպես որ ձերն էջերով ինքներդ հաշվեք՝ պատճենելու փոխարեն.

ttm.pages_limit=30788203

Հետո վերընթերցեք երկու sysfs ֆայլերն էլ՝ նախքան որևէ այլ բանի հավատալը.

/sys/class/drm/card*/device/mem_info_gtt_total
/sys/class/drm/card*/device/mem_info_gtt_used

BIOS-ի կտորը թողեք փոքր։ Պահուստ թողեք. GTT-ի հատկացումները վերցվում են հենց այն ֆիզիկական հիշողությունից, որից օգտվում է օպերացիոն համակարգը, իսկ սպասարկման ընթացքում swap-ի անցնող տուփն ուշացման խնդիր ունի, որը դուք սխալմամբ ախտորոշելու եք որպես մոդելի խնդիր։ Ստուգեք հաշվետվության հերթականությամբ. pages_limit, mem_info_gtt_total, mem_info_gtt_used բեռնված մոդելի պայմաններում, ազատ համակարգային հիշողությունը բեռի տակ, և միայն դրանից հետո՝ BIOS-ը։

Բա՞ց է դեռ upstream-ում

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

Ապացույցներ

• Strix Halo-ի հիշողության հատկացման հաշվետվություն
• Strix Halo-ի տեղակայման ուղեցույց, Քայլ 1