Запуск 510 ГБ DeepSeek-V4.1-Flash на споживчому GPU з 8 ГБ пам'яті
Інженери продемонстрували локальний запуск 510-гігабайтної DeepSeek-V4.1-Flash на карті RTX 5060 з 8 ГБ VRAM за допомогою прямого потокового зчитування з диска. Метод обходиться без конвертації завдяки структурі safetensors та попередньому завантаженню експертів.
Чому це важливо
Ви можете експериментувати з важкими MoE-моделями на бюджетному споживчому залізі за допомогою стримінгу з диска замість оренди дорогих хмарних кластерів.
TL;DR
- 01У моделях MoE критичний не загальний обсяг ваг, а обсяг активованих експертів на кожен токен.
- 02Черга послідовних зчитувань з обмеженим паралелізмом запобігає забиванню дискової шини.
- 03Завжди порівнюйте виходи кастомних ядер з еталонними обчисленнями у PyTorch.
Ключові факти
- Розмір моделі на диску
- 510 ГБ
- Протестоване залізо
- NVIDIA RTX 5060 (8 ГБ VRAM)
- Обсяг даних на токен
- 4.2 ГіБ (6 з 384 експертів на 40 шарах)
- Швидкість генерації
- 1.64 токена/с (диск) та 2.4 токена/с (з RAM кешем)
Механіка прямого потокового зчитування з диска
DeepSeek-V4.1-Flash займає 510 ГБ на диску (40 шарів, по 384 експерти на шар). Кожен токен активує 6 експертів, зчитуючи близько 4.2 ГіБ. Використання викликів pread з прапорцем O_DIRECT безпосередньо до файлів safetensors уникає конвертацій і навантажує шину NVMe на 94–97%.
Конвеєризація та попереднє завантаження
Базовий підхід давав 0.89 токена/с. Оптимізація черги з лімітом у 2 активні експерти та поділом на 4 паралельні потоки скоротила час очікування диска з 0.65 до 0.31 с на токен. Евристичне передбачення маршрутизатора для шару i+1 дало 71% влучань, піднявши швидкість до 1.64 токена/с з диска та до 2.4 токена/с із кешем у RAM.
Приховані помилки ядер на Blackwell
Експерименти виявили системні помилки, які не викликали падінь програми:
- Бібліотека
TileLang 0.1.8на архітектуріsm_120розраховувала FP4 некоректно; оновлення до0.1.9повернуло косинусну подібність 0.9996. - Референсне ядро
act_quantстворювало спорадичні NaN у батчах понад 64 рядки; виправленням стало явне встановленняnum_stages = 2. - Обмеження shared memory (99 КБ проти необхідних 141 КБ) змусило виконувати sparse attention групами по 16 голів.
Спробуй за 2 хвилини
# Fix race condition in DeepSeek ue8m0 act_quant reference kernel
# Replace default num_stages = 0 with 2 to eliminate sporadic NaNs on consumer hardware
kernel_config = {"num_stages": 2}
# Slice sparse attention heads to fit within 99 KB consumer shared memory
heads_per_group = 16python
✓ Коли використовувати
- Офлайн-рефакторинг коду та складні задачі міркування на локальній робочій станції.
- Тестування великих відкритих моделей без витрат на хмарну інфраструктуру.
- Налагодження та аудит референсних GPU ядер на споживчому залізі.
✕ Коли НЕ варто
- Інтерактивні чат-боти реального часу, які вимагають швидкості понад 20 токенів/с.
- Системи без високошвидкісних NVMe накопичувачів Gen4/Gen5.
- Сервери з корпоративними картами рівня H100, де ваги повністю вміщуються у VRAM.
Що зробити сьогодні
- Оновіть TileLang до версії 0.1.9+ перед виконанням FP4 операцій на залізі Blackwell.
- Встановіть num_stages = 2 у ядрі DeepSeek act_quant, щоб позбутися плаваючих помилок NaN.
- Розбивайте sparse attention на сегменти по 16 голів, якщо на GPU бракує 141 КБ shared memory.