AirLLM: запуск 70B моделей на GPU с 4GB — правда или маркетинг?

AirLLM: запуск 70B моделей на GPU с 4GB — правда или маркетинг?

AirLLM утверждает, что позволяет запускать модели с 70B параметров на видеокарте с 4GB памяти без квантизации, дистилляции и прунинга. Звучит невероятно, но давайте проверим: действительно ли это работает, как настроить и, главное, стоит ли оно того?

Суть метода: один слой за раз

Трансформер — это стек слоёв, которые выполняются последовательно: вход → слой 1 → слой 2 → … → слой 80 → выход. Когда вычисляется слой 1, все остальные слои просто занимают место в VRAM, ничего не делая. Обычный инференс загружает все 80 слоёв в память GPU, потому что это быстро. AirLLM задаёт очевидный вопрос: а что если не загружать все сразу? Загрузили слой 1, выполнили, выбросили, загрузили слой 2, выполнили, выбросили.

Теперь требование к VRAM — не размер модели, а размер самого большого слоя. Для 70B модели в FP16 это примерно 1.75GB на слой, что помещается в 4GB с запасом. Сама модель весит 140GB, но живёт на диске, а не в GPU, и потоково подаётся по одному слою за раз. Вот и вся идея, и она действительно работает.

Проверка заявлений: правда ли это?

Да, с оговоркой размером с саму модель. Разберём по пунктам.

«70B на GPU с 4GB» — реально

Математика сходится (~1.75GB на слой в FP16), и это воспроизведено независимыми пользователями. Споров нет.

«Без квантизации, дистилляции и прунинга» — реально

Это самая интересная часть. Большинство трюков для запуска больших моделей на слабом железе работают за счёт ухудшения модели — сжатия весов с 16 до 4 бит, что снижает точность. AirLLM этого не требует: вы получаете оригинальную, немодифицированную модель в полной точности. Квантизация здесь опциональна — можно передать compression='4bit' для ускорения, но это не обязательно.

Более крупные модели — тоже работают

Таблица масштабирования из README выглядит абсурдно, но следует той же логике:

• Llama 3.x 70B — ~4 GB VRAM
• Llama 3.1 405B — ~8 GB VRAM
• DeepSeek-V3 (671B) — ~12 GB VRAM
• Qwen3-235B (MoE) — ~3 GB VRAM
• Kimi K3 (MoE, 2.8T) — ~3.7 GB VRAM

Заметили странность? Модель с 2.8 триллионами параметров требует меньше VRAM, чем 671B. Это не ошибка: это Mixture-of-Experts (MoE) модели. В MoE-слое сотни «экспертных» подсетей, но каждый токен обращается только к нескольким из них. Например, Kimi K3 имеет 896 экспертов на слой, но каждый токен использует только 16. Полный слой экспертов занимает ~55GB, но для одного токена нужно всего ~1GB. AirLLM загружает только нужных экспертов, а не весь слой. Разреженная модель → меньше рабочее множество → меньше VRAM. Контринтуитивно, но верно.

Что скрывает заголовок

Из официальных заметок к релизу v3.1.0 (замеры на RTX 6000 Ada):

• Пиковое потребление VRAM при генерации: 3.72 GB
• Одноразовая инициализация: 900 секунд
• Скорость генерации: 292 с/токен (ограничено диском)

Это значит, что ответ из 100 токенов займёт более 8 часов. Автор честно публикует эти цифры, но они не в маркетинговой строке.

Для типичных конфигураций сообщество сообщает: 70B на хорошем NVMe — 5–35 секунд на токен; 70B на MacBook — ~0.07 токенов/сек (~14 с/токен). Для сравнения, llama.cpp с квантизированной 70B на RTX 4090 выдаёт 8–15 токенов в секунду.

Честная формулировка: AirLLM не делает 70B быстрой на 4GB GPU, он делает её возможной.

Почему это медленно: формула, которую стоит запомнить

Чтобы сгенерировать один токен, модель должна прогнать все слои. Значит, AirLLM должен прочитать всю модель с диска для каждого токена. Отсюда формула:

секунд на токен ≈ размер модели на диске ÷ скорость чтения диска

Для 70B в FP16 (~140GB):

• Gen4 NVMe SSD (7 GB/s) — ~20 с
• Gen3 NVMe SSD (3.5 GB/s) — ~40 с
• SATA SSD (0.5 GB/s) — ~280 с
• Жёсткий диск (0.15 GB/s) — ~933 с (15 минут)

Ваш диск — это движок инференса. GPU почти простаивает, ожидая данные. Отсюда два следствия:

1. Используйте compression='4bit' — это уменьшает объём данных для чтения в ~4 раза. README обещает ускорение до 3 раз, и теперь понятно почему: дело не в скорости вычислений, а в объёме перемещаемых данных.
2. RAM — ваше лучшее обновление. Если системная память вмещает большую часть модели, кэш ОС отдаёт слои из памяти, а не с диска. Поэтому у людей с 128GB RAM цифры значительно лучше, чем предсказывает формула.

Настройка AirLLM

Требования — прочитайте до начала

Дисковое пространство — главная проблема. AirLLM скачивает модель, затем разбивает её на послойные шарды. Какое-то время на диске лежат обе копии. Для 70B FP16 нужно: ~140GB (оригинал) + ~140GB (шарды) = ~280GB свободного места. Самая частая ошибка в FAQ — safetensors_rust.SafetensorError: Error while deserializing header: MetadataIncompleteBuffer — почти всегда означает, что закончилось место на диске.

Также понадобятся: NVMe SSD (не SATA, точно не HDD), как можно больше системной RAM, токен Hugging Face для gated-моделей (например, Llama), и терпение.

Установка

pip install airllm

Для ускорения с 4-битной квантизацией (рекомендуется):

pip install -U bitsandbytes

Запуск

from airllm import AutoModel

model = AutoModel.from_pretrained(
    "Qwen/Qwen3-32B",
    compression='4bit',  # ~3x быстрее; пропустите для полной точности
    delete_original=True,  # удаляет оригинал после разбиения — экономит ~50% диска
    profiling_mode=True,  # логирует время по слоям, чтобы видеть узкое место
)

input_text = ['What is the capital of United States?']
input_tokens = model.tokenizer(
    input_text,
    return_tensors="pt",
    return_attention_mask=False,
    truncation=True,
    max_length=128,
    padding=False,  # избегает частой ошибки токенизатора
)

generation_output = model.generate(
    input_tokens['input_ids'].cuda(),
    max_new_tokens=20,
    use_cache=True,
    return_dict_in_generate=True,
)

print(model.tokenizer.decode(generation_output.sequences[0]))

Весь API — это. Переключение на 671B модель — одна строка:

model = AutoModel.from_pretrained("deepseek-ai/DeepSeek-V3")  # 671B, ~12GB VRAM

Начните с малого: сначала запустите 8B модель, чтобы проверить настройку, прежде чем выделять 280GB и несколько часов на скачивание 70B.

Полезные флаги конфигурации

• compression: '4bit' или '8bit' — блочная квантизация, главный рычаг скорости
• delete_original: удаляет оригинальную загрузку после разбиения — вдвое уменьшает использование диска
• layer_shards_saving_path: сохранить шарды на другой (более быстрый/большой) диск
• profiling_mode: логирует время на каждый слой
• hf_token: для gated-моделей (Llama и др.)
• prefetching: перекрывает загрузку и вычисления (~10% прирост), включено по умолчанию

Частые ошибки и их причины

• MetadataIncompleteBuffer — закончилось место на диске, почти всегда
• 401 Client Error... Repo is gated — передайте hf_token='...'
• Asking to pad but the tokenizer does not have a padding token — установите padding=False
• ValueError: max() arg is an empty sequence — используйте AutoModel, а не конкретный класс модели
• macOS — работает только на Apple Silicon. Установите mlx и torch, убедитесь, что Python нативный (не Rosetta). В остальном код тот же.

Стоит ли пробовать?

Зависит от вашей ситуации.

Пропустите, если хотите общаться с большой моделью

Интерактивный чат требует ~20+ токенов в секунду, а AirLLM даёт секунды-минуты на токен. Разговора не получится.

Пропустите, если нужен серьёзный объём

Каждый токен читает десятки гигабайт с SSD. Потребительские NVMe рассчитаны на конечное число терабайт записи, а постоянные полные чтения модели и перезапись шардов — не то, для чего они созданы. Кроме того, машина будет практически непригодна для других задач во время работы.

Отлично подходит для офлайн-пакетной обработки

Это реальный сценарий использования. Ключевая идея: дорого загружать слой, а не использовать его. Если загрузить слой 1 и прогнать через него 50 промптов, стоимость загрузки амортизируется на 50 запросов. Один из бенчмарков: 35 с/токен для одного промпта против 5.3 с/токен при батче из 50 — ускорение в 6.6 раза бесплатно. Если нужно классифицировать 10 000 документов за ночь и нет бюджета на GPU, AirLLM — легитимный инструмент. Задержка не важна, когда никто не ждёт.

Полезно, если нужна полная точность

Исследования эффектов квантизации, численная воспроизводимость, оценка модели как опубликованной — случаи, где 4-битное приближение ломает суть. AirLLM — почти единственный способ сделать это на своём железе.

Итог

Заявление реально: 70B на 4GB VRAM, полная точность, без обмана. Инженерная работа умная, стриминг экспертов в MoE впечатляет. Проблема в формулировке: «Запустите 70B на 4GB GPU» подразумевает быстрые ответы на дешёвом железе. На деле вы получаете ответы 70B-качества, но со скоростью минут на токен, где движок — ваш SSD, а GPU простаивает. AirLLM не убирает стоимость запуска большой модели, он переносит её из VRAM во время и дисковый ввод-вывод. Хорош ли такой обмен — зависит от того, чего у вас больше: времени или денег.

Попробуйте AirLLM на небольшой модели, замерьте скорость на своём диске и поделитесь результатами в комментариях — сообществу не хватает данных.