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, до запуска Vulkan-сборки llama.cpp server (ghcr.io/ggml-org/llama.cpp:server-vulkan). Скоуп тот же, что в отчёте: одна нода, одна серия ядра, один дистрибутив, настроенный под llama.cpp server.

Причина

На Linux модели не живут в выделенном через BIOS куске VRAM. GPU отображает обычную системную память через GTT, таблицу трансляции адресов графики в ядре. Сколько ему позволено отобразить, ограничивает TTM — менеджер памяти графических устройств, тоже часть ядра. Лимит страниц TTM и есть потолок. Во многих дистрибутивах по умолчанию это доля системной памяти, и именно дефолт, а не разбивка в прошивке, не даёт большой модели загрузиться.

Если увеличить кусок в BIOS, ёмкости не прибавится. Это показание одной обслуживающей ноды, настроенной под одну работу, а не утверждение, что большой кусок не помогает ни одной нагрузке. Кусок вырезается из той же физической памяти и становится недоступен всему остальному, включая тот путь через GTT, который рантайм предпочитает; гибкая память превращается в негибкую. Немалая часть советов по этому железу молча подразумевает Windows или ядро постарше. У рантаймов своё понятие «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 берётся из той же физической памяти, что и у операционной системы, а у коробки, которая уходит в своп, пока обслуживает запросы, проблема с задержкой — и вы примете её за проблему модели. Проверяйте в том же порядке, что и отчёт: pages_limit, mem_info_gtt_total, mem_info_gtt_used при загруженной модели, свободная системная память под нагрузкой и только потом BIOS.

Открыто ли апстрим?

Мы не отслеживаем. Отчёт отмечает лишь, что поведение ядра и драйверов на этом железе быстро меняется и что его показания — то, что отдаёт одна машина сегодня, а не спецификация.

Доказательства

• Отчёт про распределение памяти на Strix Halo
• Гайд по развёртыванию на Strix Halo, Шаг 1