Linux на ноутбуке RTX Spark, потому что Microsoft-аккаунта нет

Мотивация

Когда начали появляться слухи о ноутбуке с более чем 100 ГБ ОЗУ, доступного для GPU, первое желание было исследовать, что можно построить на такой машине. Особенно привлекала перспектива работать с open-weight моделями локально — экспериментировать с reinforcement learning, квантизацией и fine-tuning. Разработчик уже публикует собственные GGUF квантизации на Hugging Face с более чем 160 000 загрузок в месяц.

Однако оказалось, что официальная поддержка — только для Windows. A Windows есть немало причин избегать: принудительные требования к Microsoft-аккаунту при установке, многолетнее ожидание возможности положить панель задач на боковую сторону, отвратительная реклама прямо в ОС и многое другое.

Выбор был очевиден: Arch Linux. Разработчик уже входит в команду Arch как мейнтейнер пакетов и даже ставил его на IBM mainframes (слайды с FOSDEM). Начинать здесь было решено с Arch Linux ARM — отдельного проекта, портирующего Arch-пакеты на ARM, с добавленной поддержкой железа.

Установка и кастомизация

NVIDIA проводила работу над ядром для Ubuntu, что дало хорошую отправную точку. Эту работу использовали, исправили override для ACPI и маппинг framebuffer для консоли, а затем нашли необходимые ACPI overrides прямо из таблиц самого ноутбука. Драйвер NVIDIA и микрокод динамика ASUS пришли из официальных источников в интернете. Поддержка клавиатуры потребовала патча для hid-asus, а звук — собственного машинного драйвера.

Всё это было собрано в загрузочный USB и дополнено расширением upstream Archinstall 4.5 для установки поддержки железа. Репозиторий содержит скрипты сборки и патчи, включая шаги для выгрузки собственных таблиц ACPI и извлечения микрокода динамика из пакета драйвера ASUS локально.

Входные данные для сборки привязаны по хешу. Пакеты с поддержкой железа подписаны ключом Arch Linux Package Maintainer, а ACPI overrides берутся непосредственно с ноутбука.

Дисплей работает на 3840 × 2400 при 120 Гц, система использует NetworkManager, PipeWire и rootless Podman с NVIDIA CDI. Установщик фиксирует ядро, NVIDIA, пакеты управления питанием и прошивки через IgnorePkg, а остальные пакеты обновляются из Arch Linux ARM.

Производительность CPU

Тесты запускались 19 октября на нативной Arch Linux ARM с ядром 7.0.0-1022-nvidia и драйвером NVIDIA 615.78.08. Ноутбук был подключен к электросети с выбранным режимом производительности. Для сравнения CPU использовались опубликованные результаты Windows.

Тест CPU — нативный ARM64 7-Zip 26.04 с фиксированным 32 МБ словарём. Один проход для разогрева и три измеренных прохода на каждое количество потоков, затем взяты медианы:

StorageReview тестировал HP OmniBook Ultra 16 (128 ГБ) с тем же 20-ядерным N1X на нативных Windows ARM64 бинариках. Они приводят рейтинги 7-Zip в GIPS, поэтому показатели MIPS из логов разделены на 1 000 для сопоставимости. Больше — лучше.

Одиночный поток — практически ничья. Со всеми 20 потоками Linux-конфигурация примерно на 5% впереди в сжатии и на 3% в распаковке. В обзоре HP не указана версия 7-Zip и размер словаря, поэтому эти проценты сравнивают две конфигурации ноутбуков.

ComputerBase тоже тестировал ProArt P16 с 20-ядерным N1X. Перёведя в GIPS, её результат Windows 7-Zip составил 155,774; медиана из трёх прогонов составила 157,084 GIPS. Результат ComputerBase попал в диапазон трёх прогонов от 155,759 до 157,193 GIPS. Тестируемая машина была конфигурацией 64 ГБ с 7-Zip 26.00, размер словаря в таблице не указан.

Разделение памяти

С памятью результаты более впечатляющие. Linux-конфигурация сообщает 116,0 ГБ одновременно как системное ОЗУ и как общую память CUDA из одного физического пула. Windows делит ОЗУ на выделенную для GPU, общую и только для CPU. Рабочие нагрузки CPU не могут использовать выделенную GPU, а выделение памяти GPU не может использовать только CPU-область.

Приложение NVIDIA на Windows позволяет менять выделенный объём и перезагружаться; ProArt P16 на 128 ГБ Frandroid достигал 96 ГБ. CUDA может превышать это за счёт выделения из общей памяти, в рамках бюджета памяти Windows.

При выделении 91 ГБ для GPU, Windows-конфигурация Frandroid сообщала о 109,7 ГБ общей памяти CUDA, включая общую. Linux-конфигурация сообщила 116,0 ГБ — примерно на 6,3 ГБ больше. Главное преимущество — иметь больший пул доступным для работы CPU без необходимости двигать ползунок резервирования и перезагружаться между рабочими нагрузками.

Локальный запуск Qwen

Запущен контрольный пункт Qwen3.8-Flash-Next-FP4-Local от NVIDIA через vLLM с B12X CUDA kernels в нативном ARM64 контейнере, с использованием смешанной квантизации и FP8 KV кэша. Для этого прогона режим "думанья" отключен.

До загрузки модели Linux сообщил 110,9 ГБ свободной ОЗУ. vLLM записал 68,2 ГБ для загрузки модели и выделил ещё 21,1 ГБ для KV кэша. Это почти 90 ГБ, выделённых модели и KV кэшу прямо на ноутбуке.

Загрузка и компиляция модели заняли примерно 16 минут перед первым запросом. Тайминги ниже начинаются после разогрева. Таблицы встраивания PLE поддерживаются диском и выигрывают от тёплого кэша страниц; остальные компоненты используют CPU offload. CUDA обрабатывает вывод, часть модели находится вне памяти GPU.

Дали Qwen два глючащих Python-помощника на проверку, длинный журнал инцидента с одной неудачной операцией для поиска и платёжную записку для преобразования в JSON. Каждая задача запускалась три раза после разогрева с известными ответами для проверки. Нужно было узнать, сколько ждать и вернёт ли он правильные поля.

Задача с логом прочитала почти 10 000 токенов и вернула правильный запрос, причину и следующее действие менее чем за 6 сек. Ответ содержал всего 39 токенов, что составило 6,8 токена/сек для всего запроса. Большинство времени ушло на обработку подсказки, поэтому для этой задачи время ответа показывает больше, чем показатель токена/сек.

Для проверки кода скорость генерации оценивалась как (выходные токены − 1) / (время ответа − время до первого токена), обе времени в секундах. Сюда входит overhead потока. Frandroid запускал задачи кодирования Qwen3.8-Flash-Next на своём Windows ProArt:

Обе конфигурации ProArt работают около 30 токенов/сек. Для вывода Frandroid использовал выделение 85 ГБ для GPU и лимит контекста 262 144 токена; лимит контекста в Linux-конфигурации был 32 768 токенов. Подсказки, квантизации, runtime'ы и методы замера различаются. Это сравнивает две рабочие конфигурации; не изолирует влияние ОС.

Также запущены четыре проверки кода одновременно. Медиана пакета завершилась за 5,314 сек, произведя 86,6 выходных токенов/сек для всех четырёх запросов вместе. Этот показатель включает обработку подсказки и overhead ответа. Все 12 ответов прошли проверку за три пакета.

Затем система крутилась в цикле через три задачи, один запрос за раз, в течение десяти минут. Завершила 150 запросов, 50 каждого типа, и каждый ответ прошёл проверки. Средние времена ответа составили 4,036 сек для проверки кода, 5,921 сек для логов и 2,046 сек для извлечения. При сравнении первых десяти и последних десяти повторений каждой задачи средние времена ответов выросли менее чем на 1,6%.

Все 171 измеренные ответы прошли проверки. Это три подсказки, повторённые с детерминированным декодированием; проверка при проверке кода верифицирует выходы регрессии. Сохранил каждый ответ и сырой поток событий, проверил их против сводок.