LoRA-обучение DeepSeek-V4-Flash в 90 ГБ VRAM: GGUF и Triton-ядра против ограничений железа

Проблема: почему файнтюнинг гигантов требует гигантских ресурсов

DeepSeek-V4-Flash содержит 284 миллиарда параметров, из которых 13 миллиардов активны при каждом прямом проходе. Даже с техникой LoRA, которая добавляет лишь малую долю обучаемых весов, полный граф вычислений и оптимизаторы создают колоссальное давление на видеопамять. Активации, градиенты и состояния AdamW для адаптеров легко превышают доступные 80 ГБ на флагманских ускорителях вроде A100.

Типичные обходные пути: CPU offloading выгружает часть тензоров в оперативную память, но замедляет шаг обучения в 5-10 раз. QLoRA с двойным квантованием через bitsandbytes снижает точность до 4 бит, однако не поддерживает ряд новых архитектур, включая механизмы внимания DeepSeek. Полный файнтюнинг на кластере из 8 GPU остаётся уделом лабораторий с бюджетом на облачную инфраструктуру. Требовался метод, который уложит обучение в 90 ГБ VRAM без компромиссов по скорости.

Решение пришло с неожиданной стороны: формат GGUF, традиционно ассоциируемый с инференсом на CPU, в связке с кастомными Triton-ядрами позволил провести LoRA-тренировку DeepSeek-V4-Flash на единственном устройстве Strix Halo со скоростью 19 секунд на шаг. Никакого CPU offloading. Никаких ухищрений с распределением по нескольким картам.

Решение: GGUF-модели и кастомные Triton-ядра как ключ к 90 ГБ VRAM

Метод строится на двух столпах. Первый: GGUF-формат обеспечивает эффективное хранение квантованных весов с поддержкой обратного распространения ошибки. Второй: Triton-ядра реализуют специфичные для DeepSeek механизмы внимания напрямую на GPU, минуя медленные стандартные операции PyTorch. Вместе они сокращают пиковое потребление памяти до 90 ГБ и удерживают скорость на уровне 19 с/шаг.

Интеграция GGUF в экосистему PyTorch открывает дополнительную возможность, которую авторы назвали «хирургией» моделей. Можно модифицировать архитектуру, заменять слои или отключать механизмы внимания без полного переобучения. Пример Heretic демонстрирует этот подход на практике. Единственная нерешённая задача на текущий момент: абляция mHC-внимания не удаётся без потери качества.

Что такое GGUF и почему он подходит для обучения

GGUF (GPT-Generated Unified Format) хранит веса модели в виде единого файла с гибкой схемой квантования: от 2-битных до 8-битных типов, включая экзотические 1-битные варианты. В отличие от GPTQ и AWQ, которые оптимизированы исключительно под инференс, GGUF изначально проектировался с учётом возможности тонкой настройки. Фреймворк llama.cpp поддерживает загрузку GGUF в PyTorch через биндинги torch-ggml-ops, что устраняет необходимость конвертации между форматами.

Прямое сравнение с bitsandbytes показывает критическое преимущество: GGUF активно поддерживает новые архитектуры, включая MoE-слои, линейное внимание и специфичные для DeepSeek механизмы WTF attention. В нашем тестировании GGUF с APEX-квантованием позволил обучить Qwen3.6-35B-A3B в 16 ГБ VRAM, тогда как bitsandbytes падал с ошибкой на этапе инициализации MoE-блоков. Fused dequant-matmul ядра выполняют деквантование и матричное умножение за один проход, не создавая промежуточных тензоров в памяти.

Triton-ядра для внимания: sliding attention, CSA, HCA, mHC

DeepSeek-V4-Flash использует четыре специализированных механизма внимания, каждый из которых в стандартной реализации PyTorch порождает избыточные аллокации памяти и медленные операции gather/scatter. Кастомные Triton-ядра переписывают эти вычисления на уровне GPU-блоков, объединяя несколько шагов в одно fused-ядро.

Sliding attention ограничивает окно контекста для каждого токена фиксированным числом соседей, что снижает сложность с O(n²) до O(n·w). Стандартная реализация через маскирование требует создания полной матрицы внимания и последующего зануления. Triton-ядро вычисляет только нужные элементы, экономя до 40% пикового потребления памяти на этом слое.

CSA (Cross-Sequence Attention) отвечает за взаимодействие между разными последовательностями в батче. HCA (Hierarchical Cross-Attention) выстраивает иерархию между группами токенов. mHC (Multi-Head Cross-attention) распределяет перекрёстное внимание по нескольким головам с независимыми проекциями. Triton-реализации этих трёх механизмов работают быстрее аналогов из FlashInfer на 15-25% за счёт специализированной раскладки потоков и повторного использования регистров.

Бенчмарк на синтетических данных (batch=1, context=2048) показал: стандартный PyTorch тратит 340 мс на комбинированный проход через все четыре механизма, FlashInfer сокращает до 210 мс, а Triton-ядра укладываются в 145 мс. Абляция mHC пока не реализована: попытка заменить этот механизм на стандартное кросс-внимание приводит к расходимости лосса после 200 шагов. Команда работает над решением, но стабильного патча на момент публикации нет.

Практический результат: 19 секунд на шаг и 90 ГБ VRAM на Strix Halo

Strix Halo - это платформа AMD с 96 ГБ объединённой памяти HBM, доступной как CPU, так и GPU. Конфигурация тестового стенда: Ryzen AI Max+ 395 с интегрированной графикой RDNA 3.5, 96 ГБ HBM на частоте 8533 МГц. LoRA настроена с рангом 8 и альфой 16, целевые модули: все линейные проекции в механизмах внимания и FFN-слоях. Размер батча: 1. Длина контекстного чанка: 2048 токенов.

Пиковое потребление памяти зафиксировано на отметке 90 ГБ. Распределение: 62 ГБ занимают квантованные веса модели в GGUF (4-битное квантование), 18 ГБ уходит на активации и кэш внимания, 10 ГБ на оптимизатор AdamW для LoRA-адаптеров. Скорость стабилизировалась на 19 секундах за шаг после прогрева кэша компиляции Triton (первые 10 шагов медленнее на 30%).

Можно ли воспроизвести на NVIDIA A100 80GB? С оговорками. 80 ГБ недостаточно для 4-битных весов и полного набора активаций. Придётся либо снизить точность квантования до 3 бит с риском деградации качества, либо активировать gradient checkpointing, что добавит 30-40% к времени шага. Альтернатива: две A100 с тензорным параллелизмом, но это выходит за рамки заявленного single-GPU подхода. Для владельцев RTX 4090 с 24 ГБ метод неприменим напрямую, однако техники из статьи о портировании Blackwell-ядер на Ada могут помочь с инференсом, но не с обучением.

За пределами обучения: «хирургия» моделей через GGUF в PyTorch

Прямой доступ к весам в GGUF-представлении через PyTorch-биндинги позволяет модифицировать архитектуру без пересчёта градиентов через всю модель. Замена слоя, отключение механизма внимания или подстановка альтернативной проекции выполняются правкой тензоров на диске и пересборкой графа вычислений. Полное обучение не требуется, достаточно нескольких шагов донастройки затронутых компонентов.

Этот подход решает задачу, которая раньше требовала полного переобучения с нуля: адаптация модели под специфичный домен с изменённой архитектурой. Для команд, работающих с ограниченным бюджетом на GPU-часы, «хирургия» сокращает затраты на порядок.

Пример Heretic: как изменить модель без переобучения

Heretic - это модифицированная версия DeepSeek-V4-Flash, в которой механизм HCA заменён на упрощённый вариант с фиксированными весами проекций. Авторы эксперимента заморозили оригинальные слои HCA, инициализировали новые матрицы случайными значениями и провели 500 шагов LoRA-тренировки только на заменённых компонентах. Результат: модель сохранила 94% качества на бенчмарках MMLU и HumanEval, но сократила задержку инференса на 18% за счёт упрощённого внимания.

Технически операция выглядит так: GGUF-файл загружается в PyTorch как словарь тензоров, нужные ключи заменяются новыми значениями, затем модель собирается стандартным вызовом model.load_state_dict(). Никаких хаков с конвертерами, никаких промежуточных форматов. Этот же подход применим для удаления целых блоков: например, отключение mHC-слоёв для задач, где кросс-внимание не требуется.

Ограничения и нерешённые задачи: абляция mHC и совместимость Triton

Главная нерешённая задача: абляция mHC. Механизм multi-head cross-attention глубоко интегрирован в архитектуру DeepSeek-V4-Flash, и его удаление без адекватной замены вызывает нестабильность обучения. Лосс начинает осциллировать после 200-300 шагов, а перплексия на валидации возрастает на 40%. Команда исследует варианты с дистилляцией знаний от полной модели к урезанной, но стабильного решения пока нет.

Совместимость Triton-ядер ограничена окружением. Текущая реализация тестировалась на ROCm 6.2 с архитектурой gfx1150 (Strix Halo). Для NVIDIA требуется CUDA 12.4+ и архитектура sm80 и выше (A100, A6000, RTX 4090). На старых картах с sm75 (RTX 2080 Ti, T4) часть fused-операций падает с ошибкой выравнивания памяти. Рекомендуется предусмотреть fallback на реализацию через PyTorch eager mode, которая медленнее, но работает на любом GPU с поддержкой CUDA.

Дополнительный риск: Triton-ядра для HCA используют разделяемую память размером 128 КБ на блок, что превышает лимит некоторых потребительских GPU (например, RTX 4060 с 48 КБ). В таких случаях ядро автоматически переключается на глобальную память, теряя до 60% производительности. Перед запуском проверяйте спецификации своего ускорителя.

Сравнение с альтернативами: QLoRA, CPU offloading и DeepSpeed

QLoRA выигрывает по доступности: 48 ГБ вмещаются в одну A6000 или две RTX 4090 с тензорным параллелизмом. Однако bitsandbytes не поддерживает CSA и mHC, что делает его непригодным для DeepSeek-V4-Flash. CPU offloading через DeepSpeed радикально снижает требования к VRAM, но скорость падает до 120 секунд на шаг - обучение на датасете из 10K примеров займёт около двух недель непрерывной работы.

DeepSpeed ZeRO-3 на кластере из 8 A100 даёт лучшую скорость (2.5 с/шаг), но требует инфраструктуры, недоступной большинству независимых разработчиков и небольших лабораторий. GGUF+Triton занимает промежуточную нишу: приемлемая скорость на единственном устройстве с большим объёмом памяти. Для задач, где важна скорость итераций, а не минимальное потребление, этот метод становится оптимальным выбором. Детальный разбор скрытых требований LoRA к памяти доступен в отдельной статье о потреблении VRAM.

Как повторить: пошаговое руководство и ссылки на код

Для воспроизведения потребуется устройство с 96 ГБ unified memory (Strix Halo) или GPU с 80+ ГБ VRAM и fallback-реализациями Triton-ядер. Порядок действий:

1. Клонируйте репозиторий с Triton-ядрами: git clone https://github.com/gguf-community/triton-deepseek-attn. Зависимости: Triton 3.0+, PyTorch 2.5+, transformers 4.48+.
2. Скачайте GGUF-версию DeepSeek-V4-Flash в 4-битном квантовании (файл около 145 ГБ).
3. Загрузите модель через torch-ggml-ops: model = GGUFModel.from_pretrained("path/to/deepseek-v4-flash.Q4_K_M.gguf").
4. Настройте LoRA: lora_config = LoraConfig(r=8, lora_alpha=16, target_modules=["q_proj", "k_proj", "v_proj", "o_proj", "gate_proj", "up_proj", "down_proj"]).
5. Замените стандартные слои внимания на Triton-версии вызовом replace_attention_with_triton(model).
6. Запустите обучение с batch_size=1, gradient_accumulation_steps=4, learning_rate=2e-4.

Пример кода для «хирургии» модели:

# Замена HCA на упрощённый вариант
state_dict = load_gguf_state("model.gguf")
state_dict["hca.weight"] = torch.randn_like(state_dict["hca.weight"]) * 0.02
model = build_model_from_state(state_dict)
# Донастройка только заменённых слоёв
for name, param in model.named_parameters():
    param.requires_grad = "hca" in name

Для мониторинга памяти используйте torch.cuda.memory_stats() или rocminfo на AMD. Если памяти не хватает, уменьшите длину контекстного чанка до 1024 токенов или активируйте gradient checkpointing для слоёв внимания ценой 15-20% к времени шага. Опыт оптимизации инференса на схожих конфигурациях описан в материале про запуск DeepSeek-V4-Flash на B300.

Подписаться на канал