oLLM: запуск LLM с 100K контекстом на 8 ГБ GPU за счет выгрузки памяти на SSD
Обзор
oLLM — легкая Python-библиотека на базе Huggingface Transformers и PyTorch, которая делает возможным инференс трансформеров с очень длинным контекстом на одном потребительском NVIDIA GPU с 8–10 ГБ VRAM. Вместо квантизации oLLM активно выгружает большие объекты, такие как веса слоев и KV-кэш внимания, на быстрые локальные SSD, используя FP16/BF16 и FlashAttention-2, чтобы удерживать использование видеопамяти в районе 8–10 ГБ и поддерживать контексты до примерно 100K токенов.
Ключевые нововведения
- Операции чтения/записи KV-кэша, минующие mmap, чтобы снизить использование оперативной памяти хоста.
- Поддержка DiskCache для Qwen3-Next-80B, что позволяет запускать этот MoE-модельный стек на одном GPU при большом дисковом объеме.
- Интеграция Llama-3 с FlashAttention-2 для стабильности и снижения пиков памяти.
- Снижения потребления памяти для GPT-OSS через ядра, похожие на flash-attention, и поэтапные (chunked) MLP-проекции.
Замеры использования
Поддерживаемые примеры и таблицы разработчика на RTX 3060 Ti (8 ГБ) показывают такие места хранения и потребления VRAM:
- Qwen3-Next-80B (bf16, 160 GB весов, 50K контекст) -> ~7.5 GB VRAM + ~180 GB SSD; заявленная пропускная способность ≈ 1 ток/2 с.
- GPT-OSS-20B (packed bf16, 10K контекст) -> ~7.3 GB VRAM + 15 GB SSD.
- Llama-3.1-8B (fp16, 100K контекст) -> ~6.6 GB VRAM + 69 GB SSD.
Принцип работы
oLLM стримит веса слоев с SSD в GPU по мере необходимости, выгружает KV-кэш внимания на диск и при желании может выгружать слои на CPU. Применяется FlashAttention-2 с online softmax, поэтому полная матрица внимания никогда не материализуется в памяти, а крупные MLP-проекции разбиваются на чанки, чтобы ограничить пик использования памяти. В результате основным узким местом становится пропускная способность и задержки хранилища, поэтому проект рекомендует NVMe SSD и высокопроизводительные пути ввода-вывода вроде KvikIO и cuFile (GPUDirect Storage).
Поддерживаемые модели и железо
Примеры покрывают Llama-3 (1B/3B/8B), GPT-OSS-20B и Qwen3-Next-80B. Целевые архитектуры NVIDIA включают Ampere (RTX 30xx, A-series), Ada (RTX 40xx, L4) и Hopper. Для Qwen3-Next требуется девелоперская сборка Transformers (>= 4.57.0.dev). Qwen3-Next-80B — это разреженная MoE-модель с общим размером 80B и примерно 3B активных параметров за проход; обычно для неё используют несколько A100/H100, но oLLM показывает путь запуска на одиночном потребительском GPU, если согласиться с ценой в виде большого SSD и низкой пропускной способности.
Установка и минимальное использование
oLLM распространяется под MIT-лицензией и доступен на PyPI через pip install ollm. Для быстрого доступа к диску требуется зависимость kvikio-cu{cuda_version}, а для Qwen3-Next нужно установить Transformers из GitHub согласно инструкции проекта. В README показан короткий пример, где подключается DiskCache и выполняется generate с потоковой обратной связью по тексту. Обратите внимание, что версия на PyPI может отставать от описанных в README изменений.
Ожидания по производительности и компромиссы
Пропускная способность при очень длинных контекстах невысока: указывается примерно 0.5 tok/s для Qwen3-Next-80B при 50K контексте на RTX 3060 Ti, что делает подход пригодным скорее для пакетной или офлайн-аналитики, а не для интерактивного чата. Латентность SSD и пропускная способность диска доминируют в профиле производительности. Для длинных контекстов требуется большой объем дискового пространства для KV-кэша, который записывается и читается с SSD, чтобы держать VRAM стабильным.
Когда стоит использовать oLLM
oLLM имеет смысл как практичный путь выполнения задач с огромным контекстом, например анализ документов, соответствие требованиям или суммаризация больших наборов данных, когда важна точность и допустима задержка. Это не замена продакшн-стеков для высокопроизводительного сервинга, таких как vLLM или TGI.
Дополнительные ресурсы
Репозиторий проекта содержит примеры, руководства и ноутбуки для старта. Сообщества и страницы проекта помогают с подбором NVMe-накопителей и настройкой GPUDirect I/O для достижения максимальной производительности.