RTX Spark на Linux від мережі в тесті в 4,7 раза повільніший: прошивка і що робити

Коротко (TL;DR)

RTX Spark на Linux в єдиному опублікованому тесті працює в 4,7 раза повільніше, ніж на Windows, але лише тоді, коли ноутбук підключений до мережі. Модель GPT-OSS-120B видала 65,4 токена на секунду на Windows і 13,9 — на «чистому» Linux на тому самому MSI Prestige N16 Flip AI Plus. Відеоядро під Linux від мережі тримається близько 780 МГц замість ~2,2 ГГц.

• Що винне. Не GSP-прошивка відеокарти, як пишуть у заголовках, а відсутність у Linux компонента, який у Windows ділить бюджет потужності між процесором і відеоядром. Таблиця налаштувань живлення для нього зашифрована, ключ має лише Windows-драйвер (за розбором MindStudio, NVIDIA цього не підтверджувала).
• Наскільки це надійно. Один ноутбук, одна модель, один вихідний замір Alex Ziskind від 31 жовтня 2026 року. Незалежного повтору станом на 4 листопада немає.
• Що робити вже зараз. Запускати моделі через WSL2 усередині Windows — там той самий ноутбук дав 65,1 ток/с. Чекати, поки NVIDIA перенесе керування живленням у Linux-драйвер: у драйвері 620.70.06 пристрій N1X уже є.
• Якщо у вас звичайна RTX 3090/4090. Робочі налаштування — ліміт потужності (на 3090 зниження до 275 Вт за одним заміром не коштує швидкості генерації), правильна збірка FlashAttention і свіжий драйвер. Моди ядра пришвидшують обробку промпту й картинки, але не генерацію тексту.

Інференс — це робота вже навченої моделі: ви ставите запитання, модель генерує відповідь. Швидкість генерації міряють у токенах на секунду (ток/с), токен — шматочок слова. Далі всі цифри подано з джерелом і датою.

RTX Spark на Linux: що заміряли і скільки швидкості втрачено

Ноутбуки на платформі RTX Spark побудовано на «суперчипі» N1X: процесор Grace на ядрах Arm і відеоядро Blackwell в одному корпусі. Кристали процесора й GPU з’єднано просунутим пакуванням, і вони ділять спільну пам’ять до 128 ГБ LPDDR5X. За даними The Register, N1X зроблено на основі того самого GB10, що стоїть у настільному NVIDIA DGX Spark, тільки DGX Spark постачається з власною Linux-збіркою NVIDIA, а ноутбуки — з Windows 11 на Arm.

У продажу ноутбуки з 16 жовтня 2026 року; перші заміри на Windows ми розбирали в новині про старт продажів ноутбуків RTX Spark, а сам чип RTX Spark N1X у Geekbench — ще влітку.

WTIBRENT

Binance · Wall Street 24/7Новини рухають нафтуWTI · BrentРеагуйте одразу: нафта на Binance торгується цілодобово

WTIBRENTGAS

Ціна нафти зараз

Розробникам потрібен Linux: на ньому живуть vLLM, SGLang і більшість інструментів для локальних моделей. 31 жовтня 2026 року Alex Ziskind опублікував відео, де поставив Linux другою системою на MSI Prestige N16 Flip AI Plus. Наступного дня його заміри переказав MindStudio у статті «Linux on the Nvidia RTX Spark Laptop», потім emergent.sh і NeoTeo. Ось що вийшло:

CVE-2026-98432 у Linux на Ubuntu: як захистити валідатор Ethereum до патча

Qwen 3.8 27B для кодингу: 7 причин «непридатності» і як їх виправити

MIT CSAIL і GPT-6 Astra: правка ваг Qwen3.5-0.8B підняла MATH-500 з 7,9% до 48,1%

Відеомодель Wan 3.0 від Alibaba: 30 секунд відео з картинки, звуку, PDF і сайту

Gemini Omni 1.1 Flash: 40 секунд відео складаються з чотирьох 10-секундних генерацій

Джерело: заміри Alex Ziskind у переказі MindStudio і NeoTeo, 31 жовтня — 1 листопада 2026 року.

Довгий прогін показав те саме в часі: Windows завершив завдання приблизно за 8 хвилин за частоти близько 2,2 ГГц, Linux — за 37 хвилин на ~790 МГц. Температура відеоядра весь цей час трималася на рівні 40–47 °C. Отже, це не перегрів: відеоядро просто не пускають на повну частоту.

Найдивніша деталь — зворотна залежність від живлення. Від батареї Linux майже наздоганяє Windows, а після підключення зарядки падає в рази. Зазвичай буває навпаки: від мережі ноутбук працює швидше. Саме ця деталь і виводить на справжню причину.

Зашифрована прошивка RTX Spark: не GSP, а таблиця живлення

Заголовок обговорення на Hacker News звучить як «зашифрована прошивка сповільнює інференс». Він змішує дві різні речі, і від того, яку з них мають на увазі, залежить відповідь на запитання «чи можна це обійти».

GSP (GPU System Processor) — окремий керувальний процесор усередині відеочипа NVIDIA. Він бере на себе ініціалізацію та керування GPU, а працює на бінарній прошивці gsp_*.bin, яка постачається разом із драйвером. За README драйвера, GSP увімкнено за замовчуванням на всіх GPU, починаючи з Turing. Відкриті модулі ядра NVIDIA мають працювати в парі з GSP-прошивкою тієї самої версії, а відкритий драйвер nouveau отримує її як готові бінарні файли, які видобуває скрипт із репозиторію NVIDIA. Для Blackwell — а RTX Spark це Blackwell — NVIDIA підтримує лише відкриті модулі ядра: пропрієтарний драйвер на цих платформах не підтримується.

Platform Controllers and Framework (PCF) — компонент Windows, який видно в диспетчері пристроїв. Він ділить спільний бюджет потужності ноутбука між процесором і відеоядром. У настільному DGX Spark цього немає: відеоядро живиться окремо. У ноутбуці бюджет спільний, і хтось має вирішувати, скільки ватів віддати GPU.

Binance · Wall Street 24/7А якби ви купили золото влітку?+? %Тренажер на реальних цінах Binance покаже результат. Без грошей і реєстрації

GOLDNVDATSLA

Відкрити тренажер

Чому Nvidia RTX Spark на Linux гальмує саме через PCF, а не через GSP, показав експеримент із того самого тесту: у Windows вимкнули PCF — швидкість упала приблизно з 83 до 31 ток/с, частота — з ~2 ГГц до тих самих 786 МГц, що на Linux від мережі. Увімкнули назад — швидкість одразу повернулася. Далі, за версією MindStudio, прошивка передає контролеру таблицю налаштувань живлення в зашифрованому вигляді, і розшифрувати її вміє лише Windows-драйвер.

Звідси відповідь на популярне запитання «чому відкриті драйвери цього не обходять». Nouveau і побудований на ньому Vulkan-драйвер NVK використовують ту саму GSP-прошивку й так само нічого не знають про таблицю живлення: проблема живе рівнем вище, у логіці платформи. У тесті пробували ввімкнути керування живленням програмно — одна зі спроб закінчилася kernel panic (аварійною зупинкою ядра). Видобути ключ із Windows-драйвера теоретично можна, але це крихкий хак під одну машину, а не рішення. Виправити це може тільки NVIDIA, перенісши логіку PCF у свій Linux-драйвер.

Частина коментаторів на Hacker News (понад 500 балів і 230 коментарів станом на 4 листопада 2026 року) вважає заголовок сенсаційним: на їхню думку, ідеться про драйвер платформи, написаний поки що лише під Windows, а не про навмисне блокування. Це думки, а не факти, але з цифрами тесту вони узгоджуються краще, ніж версія «прошивка ріже швидкість навмисно».

Підтримка Linux на RTX Spark: що підтвердила NVIDIA, а що ні

Коротка відповідь станом на 4 листопада 2026 року: Linux NVIDIA офіційно не підтримує. У рядку OS Support специфікації RTX Spark для всіх трьох конфігурацій N1X — двох ноутбучних і настільної — вказано лише Windows 11.

Офіційна сторінка специфікацій NVIDIA RTX Spark, знімок від 4 листопада 2026 року. Рамкою виділено рядок OS Support.

Водночас драйвер уже знає пристрій. У README драйвера NVIDIA для Linux aarch64 версії 620.70.06 у списку підтримуваних GPU є три рядки RTX Spark N1X з кодами пристрою 2E03, 2E06 і 2E13. У попередній гілці 615.78.08 із цього сімейства є лише GB10 (2E12), тобто DGX Spark. Дату виходу 620.70.06 знайти не вдалося.

README драйвера NVIDIA 620.70.06 для Linux aarch64, розділ Supported NVIDIA GPU Products, знімок від 4 листопада 2026 року. Рамкою виділено рядки RTX Spark N1X і GB10.

Важливе застереження є в тому самому README: GPU у списку ще не гарантує, що конкретний ноутбук із цим GPU сумісний із Linux-драйвером, і NVIDIA прямо відсилає з цим питанням до виробника пристрою. Тобто сумісність із Linux (Linux compatibility) у RTX Spark упирається не в те, чи бачить драйвер чип (бачить), а в платформну частину — живлення, пам’ять, дисплей, — яку робить виробник ноутбука разом із NVIDIA.

На Computex у червні 2026 року співробітник NVIDIA на запитання DER STANDARD про Linux-драйвери для RTX Spark відповів: наразі нічого сказати не можемо. Phoronix тоді ж писав, що RTX Spark «чудово працюватиме на Linux», — це думка видання, а не обіцянка компанії. ComputingForGeeks 3 жовтня перевіряв драйвер 615.71.09 і кодів N1X у ньому не знайшов, тож їхня поява в 620.70.06 — свіжа зміна.

Спільнота тим часом запускає Linux самотужки. На ASUS ProArt P16 з RTX Spark мейнтейнер пакетів Arch Linux поставив Arch Linux ARM: система бачить 116 ГіБ і як оперативну пам’ять, і як пам’ять CUDA, а ядро, драйвери NVIDIA, керування живленням і прошивки заморожено від оновлень. Швидкість там теж заміряли: за оцінкою автора, 30,9 ток/с (медіана трьох прогонів) на рев’ю коду моделлю Qwen3.8-Flash-Next-FP4-Local через vLLM. Від мережі чи від батареї йшов прогін, у матеріалі не сказано, тому безпосередньо порівняти ці цифри з тестом Ziskind не можна.

Замір RTX Spark на Linux: звідки «35 %» і чому йому рано вірити

Цифра «35 %» із заголовків не збігається з жодним заміром швидкості в самому тесті. Ми перерахували всі пари:

Найближче до «35 %» співвідношення частот: 780 МГц — це приблизно 35 % від 2,2 ГГц. Звідки взято цифру, ні MindStudio, ні автор треду на Hacker News не пояснюють, тож це збіг, а не встановлене джерело. Швидкість генерації в головному замірі впала сильніше — до 21 % від Windows.

Що обмежує висновки:

• Один вихідний замір. MindStudio, emergent.sh і NeoTeo — три сайти, але всі переказують одне відео Alex Ziskind. Незалежного повтору станом на 4 листопада 2026 року немає, а ComputingForGeeks писав, що ноутбук RTX Spark не тестував (3 жовтня, до старту продажів).
• Один пристрій. NeoTeo прямо застерігає: цифри описують конкретний MSI Prestige N16 Flip AI Plus, а не всі ноутбуки RTX Spark. У ASUS і Dell платформа може поводитися інакше — на них, наприклад, інакше проходило встановлення.
• Немає версій. Ні версії ядра Linux, ні версії драйвера в переказах не вказано.
• Плутанина в соцмережах. Частина дописів називає проблемний комп’ютер DGX Spark. Насправді DGX Spark у тесті — еталон, який на Linux дав нормальні 61 ток/с.

Водночас сам механізм правдоподібний. На форумі NVIDIA в лютому 2026 року власник DGX Spark описував схожу історію: швидкість LLM упала вдвічі за споживання GPU близько 14 Вт, а допомогло повне скидання живлення. Це інший пристрій і поодинокий випадок, але він показує, що логіка живлення на цій платформі справді здатна вдвічі зрізати швидкість. Тест стане надійним, коли його повторить хтось інший на іншому ноутбуці із зазначенням версій — або коли NVIDIA відповість.

Як пришвидшити інференс на ноутбуці RTX Spark уже сьогодні

Якщо ви купили ноутбук на RTX Spark і хотіли працювати в Linux, робочих шляхів станом на 4 листопада 2026 року три: WSL2, ручне налаштування пам’яті та, для експериментів, нативний Linux із розумінням обмежень.

1. Запускайте моделі у WSL2, а не в нативному Linux. WSL2 — це Linux, який працює всередині Windows і користується її драйвером NVIDIA. Тому він успадковує нормальне керування живленням: 65,1 ток/с проти 65,4 у Windows. За описом MindStudio, повна частота у WSL2 зберігається і від мережі, і від батареї, але окремого заміру WSL2 від батареї в переказах немає. vLLM і SGLang у ньому працюють.
2. Дайте WSL2 більше пам’яті. За документацією Microsoft, WSL2 за замовчуванням отримує половину пам’яті, яку бачить Windows; у тесті MindStudio це вийшло близько 14 ГБ — замало для великих моделей. Пам’ять задають у файлі .wslconfig у теці користувача Windows, після правки потрібен перезапуск WSL командою wsl --shutdown:

ini [wsl2] memory=20GB

Значення добирайте під свою конфігурацію. За штатного резерву 96 ГБ під відеоядро системі лишається близько 32 ГБ (наш розрахунок: 128 − 96), і 14 ГБ за замовчуванням — приблизно половина того, що бачить Windows. Більше за це WSL2 не отримає, а Windows потрібен запас для своїх програм. Якщо й 20 ГБ замало, доведеться перерозподіляти резерв відеоядра (крок 3) — коштом пам’яті, доступної моделям на GPU. 3. Перевірте, скільки пам’яті віддано відеоядру. За замовчуванням прошивка ноутбука резервує 96 ГБ зі 128 під GPU, і змінити це можна лише з Windows. Нативний Linux за такого резерву бачить усього 28 ГБ; у тесті резерв знизили до 4 ГБ, і Linux побачив 120 ГБ. 4. Ollama у WSL2 поки бачить не всю пам’ять. Користувач HP OmniBook X 14 з RTX Spark описав у PR #19520 (відкрито 4 листопада 2026 року, ще не прийнято): штатна Ollama вважає доступними для GPU 22,7 ГіБ (усього бачить 109,7), а з патчем — 82,9 ГіБ (з 84,2). Модель qwen3.8:27b-q8_0 з контекстом 131 072 токени пришвидшилася з 0,53 до 7,72 ток/с, бо всі 66 шарів помістилися в GPU замість 37. Замір робили під стороннім навантаженням, це орієнтир, а не бенчмарк. Поки патч не в релізі, дивіться, скільки шарів моделі реально пішло на GPU. 5. Нативний Linux — з поправкою на живлення. Якщо потрібен саме він: від батареї в тесті було 61–67 ток/с, від мережі — близько 15. Батарея тут — спосіб перевірити, що проблема саме в живленні, а не постійний режим роботи. Встановлення теж непросте: перша спроба з Omarchy (дистрибутив на базі Arch) на MSI провалилася через мерехтіння екрана під час завантаження; Debian з коробки не побачив клавіатуру, тачпад і GPU та не підключився до Wi-Fi (ставили через USB-Ethernet). Спрацював повторний захід з Omarchy, бо його ядро вже містить відкритий драйвер NVIDIA.

Перевірити, на якій частоті працює відеоядро і що його гальмує, можна штатною утилітою NVIDIA:

# частота і споживання щосекунди
nvidia-smi --query-gpu=clocks.current.graphics,power.draw --format=csv -l 1
# які причини зараз знижують частоту
nvidia-smi -q -d PERFORMANCE

У розділі Clocks Event Reasons драйвер перелічує, що саме обмежує частоту: програмний ліміт потужності, перегрів, зовнішній сигнал від блока живлення. Якщо всі причини «Not Active», частота максимальна. Яка з них спрацьовує на RTX Spark під Linux від мережі, публічних даних поки немає.

Налаштування драйвера NVIDIA на Linux для LLM: що дає швидкість

Власники звичайних відеокарт у тому самому обговоренні питали інше: як вичавити максимум з уже наявної GPU під Linux. Тут важливо розуміти, у що впирається робота. Генерація відповіді (decode) впирається в пропускну здатність пам’яті: на кожен токен треба прочитати ваги моделі. Обробка промпту (prefill) і генерація картинок упираються в обчислення. Тому налаштування частоти майже не пришвидшують генерацію тексту, а впливають на споживання і стабільність.

Усі команди нижче — з документації nvidia-smi і працюють із драйвером NVIDIA; команди, які змінюють налаштування (-pm, -pl, -lgc, -rgc), потребують прав root, перегляд (-q) — ні.

# 1. GSP-прошивка працює? Покаже версію або N/A
nvidia-smi -q | grep -i "GSP Firmware"

# 2. Persistence mode: драйвер не вивантажується між запусками
sudo nvidia-smi -pm 1

# 3. Допустимі межі потужності й поточний ліміт
nvidia-smi -q -d POWER
sudo nvidia-smi -i 0 -pl 280

# 4. Фіксація частоти GPU для повторюваних замірів і скидання
sudo nvidia-smi -i 0 -lgc 1500,1500
sudo nvidia-smi -i 0 -rgc

Що кожна з них дає насправді:

• Persistence mode (-pm 1) тримає драйвер завантаженим, навіть коли GPU ніхто не використовує. Перший запуск моделі не витрачає час на ініціалізацію карти. Швидкості генерації він не змінює. Діє одразу, але скидається після перезавантаження і працює лише в Linux.
• Ліміт потужності (-pl) задають у ватах, і він має лежати між Min і Max Power Limit, які показує nvidia-smi -q -d POWER. Дає економію електрики й тепла майже за тієї самої швидкості генерації — цифри в наступному розділі.
• Фіксація частоти (-lgc) потрібна для коректного порівняння налаштувань: карта не «гуляє» частотами між прогонами. Працює з Volta і новішими. Тримається, доки її не скинуть командою -rgc, — не забувайте про це після замірів.
• Ліміт на модуль (-pl із ключем -sc 1) у документації описано для пристроїв, де GPU і CPU ділять спільний бюджет. Чи працює він на N1X під Linux, публічних даних немає.
• Версія драйвера. Ollama потребує драйвер NVIDIA 550 і новіший для GPU з compute capability 5.0+, а для старих карт із compute capability 5.0–6.2 — 570 і новіший. Ще одна порада з документації Ollama: якщо після сну Linux модель раптом пішла на CPU, перезавантажте модуль nvidia_uvm командою sudo rmmod nvidia_uvm && sudo modprobe nvidia_uvm.

FlashAttention у llama.cpp. FlashAttention — спосіб рахувати «увагу» моделі без зайвих звернень до пам’яті. У таблиці результатів llama.cpp для RTX 3090 (Llama 2 7B Q4_0, одна збірка, один учасник) увімкнення FlashAttention підняло обробку промпту з 5 175 до 5 560 ток/с (+7 %) і генерацію з 158,2 до 161,9 ток/с (+2 %). Приріст скромний, але безкоштовний.

Є й пастка. У трекері llama.cpp (issue #24485, червень 2026 року) описано: якщо ввімкнути FlashAttention разом із квантованим KV-кешем (наприклад, --cache-type-k q8_0), а llama.cpp зібрано без прапорця -DGGML_CUDA_FA_ALL_QUANTS=ON, увага мовчки переходить на процесор. В автора звіту на ноутбучній RTX 5070 Ti обробка промпту падала в 25–45 разів, а GPU показував 0 % завантаження. Якщо ви збираєте llama.cpp самі й квантуєте кеш, перевірте цей прапорець.

Ліміт потужності RTX 3090: 280 Вт майже не знижують швидкість LLM

RTX 3090 з коробки споживає до 350 Вт. Jean Brito у квітні 2026 року прогнав на ній Qwen 3.6 27B (щільна модель, llama-swap, драйвер 590.48.01) за шести лімітів потужності:

*Наш розрахунок: реальне споживання, поділене на швидкість. Джерело замірів — Jean Brito, 28 квітня 2026 року.

Від 350 до 250 Вт швидкість майже не змінюється, бо частота пам’яті весь час стоїть на 9 501 МГц, а генерація впирається саме в неї. Сам автор обрав 280 Вт: його замір показав, що на 275 Вт швидкість навіть трохи вища, ніж на 350 Вт, а споживання нижче приблизно на 60 Вт. За нашим розрахунком, енергія на один токен водночас падає з 10,4 до 8,3 Дж — на 20 %. За роботи 8 годин на день економія 60 Вт — це близько 14,4 кВт·год на місяць на одну карту, а у збірці на двох RTX 3090 — удвічі більше. На 200 Вт карта вже не втримує базову частоту (480 МГц), і швидкість обвалюється до 20,6 ток/с, а на 150 Вт — до 8,3.

Застереження: це один замір на одній моделі. У таблиці llama.cpp інший користувач отримав на RTX 3090 з лімітом 250 Вт 137,7 ток/с на маленькій Llama 2 7B, а на карті без ліміту в іншій збірці було 158,2 ток/с — різниця близько 13 %. Порівняння неоднорідне (різні карти й збірки), тому висновок один: ціна ліміту залежить від моделі та рушія. Перевірте на своїй моделі:

llama-bench -m model.gguf -ngl 99 -fa 0,1

Ліміт скидається під час перезавантаження драйвера, тому Puget Systems пропонує ставити його під час кожного старту системи: скрипт із командою nvidia-smi -pl і systemd-сервіс, який його запускає.

# /etc/systemd/system/nv-power-limit.service
[Unit]
Description=NVIDIA GPU Set Power Limit
After=syslog.target systemd-modules-load.service
ConditionPathExists=/usr/bin/nvidia-smi

[Service]
User=root
Environment="PATH=/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin"
ExecStart=/usr/local/sbin/nv-power-limit.sh

[Install]
WantedBy=multi-user.target

У /usr/local/sbin/nv-power-limit.sh вистачить двох рядків — nvidia-smi -pm 1 і nvidia-smi -i 0 -pl 280; після цього sudo systemctl enable nv-power-limit.service. Якщо обираєте карту під локальні моделі з нуля, порівняння за обсягом пам’яті та ціною є в нашому виборі відеокарти для локального ШІ.

Прийоми пришвидшення LLM на GPU NVIDIA: приріст, джерело і ризик

Зведення всього, що обговорюють під темою «як пришвидшити інференс на наявній GPU», — з цифрами лише з першоджерел:

Висновок із таблиці простий. Якщо впираєтеся в генерацію тексту — допомагають лише пам’ять (чи вмістилася модель цілком у GPU) і пропускна здатність пам’яті. Якщо в обробку довгих промптів або картинки — є сенс дивитися на FlashAttention і, обережно, на моди.

gpu-unlock для RTX 20/30/40: що пришвидшує, а що ні

gpu-unlock — неофіційний модуль ядра Linux, який знімає програмне обмеження тензорних ядер GeForce в режимах BF16/FP16. За README проєкту він пришвидшує prefill на 25–55 % (звіти користувачів у переказі TechSpot і TweakTown — 14–36 %) і генерацію картинок: на RTX 3090 Ti у ComfyUI модель Z-Image Turbo в BF16 рахувала кадр 4,35 с замість 6,79 с (+56 %). Заголовок Reddit про «RTX 3090 на 55 % швидше» насправді про 3090 Ti, а «на 40 % менше енергії» в першоджерелах не підтверджується. Генерацію тексту в LLM мод не пришвидшує зовсім, RTX 50 і RTX Spark не підтримує. Як він влаштований і на яких картах працює, ми докладно розібрали в матеріалі про розблокування BF16 на RTX 3090 і 4090.

Ризики модів і тюнінгу GPU NVIDIA: гарантія, збої, перегрів RTX Spark

• Надто низький ліміт потужності. На RTX 3090 за ліміту 200 Вт частота падає до 480 МГц, швидкість — до 20,6 ток/с, а на 150 Вт — до 8,3. Перш ніж закріплювати ліміт у systemd, перевірте його власним заміром.
• Нативний Linux на RTX Spark. Програмно ввімкнути керування живленням у тесті не вдалося, а ключ із Windows-драйвера — шлях під одну машину, який може зламатися з будь-яким оновленням. Неофіційні збірки (як патч Ollama) теж можуть зламатися з першим оновленням.
• Перегрів самого RTX Spark. The Register на HP OmniBook Ultra 16 під Windows бачив, як за годину безперервного ШІ-навантаження GPU нагрівся понад 90 °C, а далі пішли артефакти зображення і зависання. Паузи в кілька секунд між запитами проблему знімали. Для багатогодинного безперервного ШІ-навантаження ноутбук підходить погано.
• Моди ядра. gpu-unlock — непідписаний модуль, який змінює поведінку прошивки GPU до завантаження драйвера. У разі збою карта не ініціалізується: у звіті від 24 жовтня 2026 року (issue #23) дві RTX 3090 лишалися недоступними драйверу до повного перезавантаження. За даними TweakTown, будь-яка модифікація GPU позбавляє гарантії, а NVIDIA, за даними TechTimes, раніше закривала такі лазівки оновленнями драйвера.
• Підроблені інсталятори. Автор gpu-unlock окремо попереджає: мережею ходять «інсталятори для Windows», до них треба ставитися дуже обережно. Завантажуйте лише вихідний код з офіційного репозиторію.

Що робити: власнику RTX Spark, власнику RTX 3090 і покупцеві

Покупцеві варто пам’ятати дві речі. Перша: швидкість генерації визначає пам’ять. У N1X пропускна здатність близько 300 ГБ/с проти 273 ГБ/с у GB10 в DGX Spark, і в тесті The Register це дало 67,64 ток/с на Qwen3.6-35B-A3B у ноутбука HP OmniBook Ultra 16 під Windows проти 63,77 у DGX Spark. Друга: офіційно ноутбуки RTX Spark — це Windows 11. Якщо вам потрібен Linux з коробки й без застережень, ту саму архітектуру дає DGX Spark із DGX OS — у тесті 61 ток/с.

Що застаріє першим: список пристроїв у наступному Linux-драйвері NVIDIA, статус PR #19520 в Ollama і позиція NVIDIA щодо сповільнення. Свіжий статус дивіться в README нових версій драйвера та в репозиторії open-gpu-kernel-modules.

FAQ

Чому RTX Spark на Linux працює повільніше, ніж на Windows?

У тесті на MSI Prestige N16 Flip AI Plus під Linux не працює компонент Platform Controllers and Framework, який у Windows ділить потужність між процесором і відеоядром. Без нього від мережі GPU сидить на ~780 МГц замість ~2,2 ГГц, і GPT-OSS-120B видає 13,9 ток/с замість 65,4. Від батареї розриву майже немає. Це один ноутбук і один замір від 31 жовтня 2026 року.

Чи можна обійти зашифровану прошивку NVIDIA на RTX Spark?

Практично ні. Зашифрована не GSP-прошивка відеоядра, а таблиця налаштувань живлення, яку вміє читати лише Windows-драйвер. Програмні спроби в тесті не допомогли, одна закінчилася kernel panic. Видобути ключ із Windows-драйвера теоретично можна, але цього ніхто не продемонстрував, і це був би крихкий хак під одну машину. Робочий обхід зараз один — WSL2, де використовується Windows-драйвер.

Чи допоможе WSL пришвидшити нейромережі на ноутбуці RTX Spark?

Так, за єдиним доступним тестом це найшвидший Linux-варіант: 65,1 ток/с на GPT-OSS-120B проти 13,9 у нативного Linux від мережі та 65,4 у Windows. У vLLM з вісьмома клієнтами WSL2 дав 127 ток/с проти 39,5. Треба лише підняти ліміт пам’яті WSL2 у файлі .wslconfig: за замовчуванням у тесті було близько 14 ГБ.

Як пришвидшити RTX 3090 для ComfyUI на Linux?

Генерація картинок упирається в обчислення, тому ліміт потужності її радше сповільнить. Спершу переконайтеся, що модель цілком вміщується у відеопам’ять. Помітний приріст дають моди на кшталт gpu-unlock: за README проєкту — +30–55 % на генерації картинок у FP16/BF16, а в ComfyUI на RTX 3090 Ti кадр Z-Image Turbo в BF16 рахувався 4,35 с замість 6,79 с. Але це непідписаний модуль ядра без гарантії і з ризиком, що карта не запуститься.

Чи можна поставити пропрієтарний драйвер NVIDIA на RTX Spark?

Ні. RTX Spark побудовано на архітектурі Blackwell, а для Blackwell NVIDIA підтримує лише відкриті модулі ядра — пропрієтарний варіант на цих платформах не підтримується. Відкриті модулі при цьому працюють у парі з GSP-прошивкою тієї самої версії драйвера. Зміна типу драйвера проблему з живленням не розв’язує: вона не в GPU-драйвері, а у відсутності керування живленням платформи.

Який драйвер NVIDIA потрібен для LLM на Linux?

Ollama потребує драйвер NVIDIA 550 або новіший для карт із compute capability 5.0 і вище, а для старих карт із compute capability 5.0–6.2 — 570 або новіший. Для RTX Spark N1X у Linux-драйвері для aarch64 пристрій з’явився в гілці 620.70.06. Для Blackwell використовуйте відкриті модулі ядра, для решти карт від Turing і новіших NVIDIA їх рекомендує.