Версия в один абзац: на Linux большой кусок VRAM в BIOS отрезать обычно не нужно. Наша обслуживающая нода держит выделенный кусок крошечным и пускает GPU почти во всю системную память через GTT — таблицу трансляции адресов графики в ядре, — а потолок задаёт параметр ядра для TTM, а не пункт в меню прошивки. Ниже то, что эта машина отдаёт прямо сейчас, с двумя загруженными моделями.
Симптом
Берёшь коробку на Ryzen AI Max+ 395 со 128 ГБ ровно ради больших моделей, а рантайм объявляет пару гигабайт доступной памяти устройства. Или модель, которая обязана влезать, отказывается грузиться. Или ROCm и Vulkan расходятся между собой в том, сколько памяти вообще есть. Первый порыв — уйти в BIOS и выдать GPU кусок побольше, и вот здесь теряется время: выделенный кусок не то место, где Linux-коробка с unified memory держит модели.
Что отдаёт наша нода
Это 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» на машине, спокойно держащей сотню гигабайт весов. Выделенный кусок близок к минимуму, который вообще предлагает прошивка, и это не имеет значения, потому что всё существенное идёт через GTT.
Параметр, который на самом деле задаёт потолок
GTT позволяет GPU отображать системную память, а сколько именно ему позволено отобразить, ограничивает TTM — менеджер памяти графических устройств в ядре. Его лимит страниц проверяют первым:
# pages, at 4 KiB each
cat /sys/module/ttm/parameters/pages_limit
На нашей ноде в командной строке ядра стоит ttm.pages_limit=30788203 —
отсюда и потолок в ~117 GiB выше. Во многих дистрибутивах по умолчанию
выставлена доля системной памяти, и именно этот дефолт, а не BIOS, не даёт
большой модели загрузиться. Поднимите, перезагрузитесь и перечитайте оба
sysfs-файла прежде, чем поверить чему-то ещё.
Две вещи, которые стоит знать, пока вы там. Первое: проверяйте с устройства,
а не из инструмента. mem_info_gtt_total и mem_info_gtt_used в
/sys/class/drm/card*/device/ и есть истина, а рантаймы сплошь и рядом
сообщают собственное представление о «VRAM», означающее совсем другое.
Второе: оставляйте запас. На нашей ноде с резидентными моделями у хоста
оставалось несколько гигабайт обычной RAM; выделения GTT берутся из той же
физической памяти, которой пользуется операционная система, а коробка,
уходящая в своп во время обслуживания, — это проблема задержки, которую вы
будете диагностировать как проблему модели.
Почему BIOS-кусок не тот рычаг
Выделенный кусок вырезается из той же физической памяти и после этого недоступен всему остальному, включая тот самый путь через GTT, который рантайм предпочитает. Выдать GPU большой фиксированный кусок значит не добавить ёмкости, а превратить гибкую память в негибкую. Windows ведёт себя здесь иначе, и заметная часть советов по этому железу молча предполагает Windows или ядро постарше; посмотрите, под какую платформу написана инструкция, прежде чем уходить в меню прошивки.
Ничто из этого не утверждает, что большой кусок не помогает ни одной нагрузке. Это рассказ о том, что отдаёт одна обслуживающая нода, настроенная ровно под одну работу, пока она эту работу делает.
Что проверять, по порядку
cat /sys/module/ttm/parameters/pages_limit— настоящий потолок./sys/class/drm/card*/device/mem_info_gtt_total— докуда GPU дотягивается.mem_info_gtt_usedпри загруженной модели — туда ли всё легло, куда вы думаете.- Свободная системная память под нагрузкой — запас, а не только ёмкость.
- И только потом BIOS.
Скоуп
Одна нода, одна серия ядра, один дистрибутив, настроенный под обслуживание llama.cpp. Поведение ядра и драйвера на этом железе меняется быстро; относитесь к цифрам выше как к тому, что эта машина отдаёт сегодня, а не как к спецификации. Что коробка делает, когда с памятью разобрались, измерено в отчёте про 128 ГБ, а протокол для собственных замеров — здесь.