DGX Spark: як повернути 1,5 ГБ пам’яті через UEFI

Що саме змінюється в UEFI

Я б не називав це дрібним твіком: за замовчуванням прошивка DGX Spark резервує 2 ГБ спільної пам’яті під дисплейний буфер, навіть коли монітор не використовується. У системі без дисплея режим Auto зменшує цей резерв до 0,5 ГБ і повертає приблизно 1,5 ГБ операційній системі, CUDA та звичайним застосункам.

У публічній документації NVIDIA для DGX Spark змінну NvidiaDispFrmSizeRequest вказано для керування цим резервом. Це одноразовий запит до прошивки: під час наступного завантаження вона перевіряє значення, застосовує його та видаляє змінну. Підтримку механізму задокументовано починаючи з OTA2610; у базовій конфігурації також вказано UEFI 1.111.17.

Тут є пастка на рівні байтів. Код Auto — це 0x00, а 0x07 позначає атрибути EFI-змінної: non-volatile, boot-service і runtime access. Тому послідовність 07 00 00 00 00 є правильною як чотири байти атрибутів і один байт даних, але вважати 0x07 кодом Auto не можна.

Змінна NvidiaDispFrmStatus призначена лише для читання результату. Після чотирибайтового заголовка efivarfs ідуть код вибраного режиму та розмір резерву в МіБ. Для Auto без підключеного монітора очікуються дані 00 00 02 00 00: режим 0x00 і 512 МіБ у little-endian.

Після запису request-змінної потрібне перезавантаження. Результат перевіряють через NvidiaDispFrmStatus і MemTotal у /proc/meminfo. Фактичний приріст може трохи відрізнятися від теоретичних 1536 МіБ через інші зарезервовані області та облік пам’яті ядром.

Де є виграш і де можна помилитися

Виграш цілком реальний, особливо для локальних моделей, яким бракує останніх сотень мегабайт. DGX Spark використовує об’єднану пам’ять CPU і GPU, тому дисплейний резерв безпосередньо зменшує обсяг, доступний системі та обчислювальним навантаженням.

Проте Auto не означає динамічного перерозподілу пам’яті під час роботи. Прошивка оцінює підключені дисплеї на етапі завантаження; монітор, підключений пізніше, автоматично не збільшить резерв.

• Для кількох дисплеїв або високої роздільної здатності 0,5 ГБ може виявитися замало та спричинити помилки драйвера або нестачу дисплейної пам’яті.
• Змінювати слід request-змінну, а не статус, згенерований прошивкою.
• Працюючи з efivarfs, варто враховувати ризик некоректного запису та мати спосіб відновити налаштування UEFI.

Головний ресурс у цьому прийомі — не пам’ять, а точність: один байт вибирає режим, а неправильне тлумачення сусідніх байтів перетворює корисні 1,5 ГБ на експеримент із прошивкою.

Раніше ми розглядали Rust LocalGPT — локального асистента в одному бінарному файлі з постійною пам’яттю та HTTP API. Цей приклад показує, чому оптимізація споживання ресурсів особливо важлива для локального запуску ШІ-навантажень.