Репозиторий проекта: https://github.com/ExVRAM/exvram‑lab

ExVRAM Lab — открытый исследовательский проект, посвящённый запуску больших локальных LLM на потребительских видеокартах с небольшим объёмом VRAM. Мы исследуем, насколько далеко можно зайти, если не писать собственный inference engine с нуля, а системно использовать существующие open‑source технологии: ultra‑low‑bit quantization, полное размещение весов на GPU, оптимизацию KV cache и современные CUDA‑backends.

Название ExVRAM происходит от идеи Exchange Compute for VRAM. В упрощённом виде гипотеза звучит так: если видеокарте не хватает памяти для хранения модели, иногда выгоднее сильнее сжать веса и потратить часть вычислительных ресурсов GPU на работу с компактным представлением, чем оставить часть модели в системной памяти и постоянно передавать веса через PCIe.

Задача: 27B‑модель на видеокарте с 8 ГБ VRAM

В начале проекта мы поставили достаточно конкретную цель: проверить, можно ли запустить dense‑модель примерно на 27 миллиардов параметров на видеокарте всего с 8 ГБ VRAM. Причём нас интересовал не сам факт запуска. Модель должна была работать без decoder weight offload в оперативную память, поддерживать длинный контекст и обеспечивать скорость, достаточную для интерактивного использования.

В качестве основной тестовой системы используется NVIDIA GeForce RTX 5060 8 GB на архитектуре Blackwell. В качестве модели — Qwen3.8–27B.

Первые эксперименты были вполне ожидаемыми. Модель запускалась, но полностью в VRAM не помещалась: около 5,7 GiB весов находилось на GPU, ещё примерно 2,5 GiB оставалось в системной памяти. Скорость генерации при такой конфигурации составляла порядка 3,8–5,5 токена в секунду.

Однако мониторинг GPU показал интересную картину: видеокарта не была полностью загружена вычислениями. Ограничением становилась передача данных. Во время autoregressive generation модели на каждом следующем токене снова требуется доступ к весам, а часть этих весов приходилось получать из RAM через PCIe.

Получалась довольно простая последовательность: модель не помещается в VRAM, часть decoder weights остаётся в оперативной памяти, появляются дополнительные передачи данных через PCIe, GPU ждёт, а скорость генерации падает.

Именно этот результат сформировал основную гипотезу ExVRAM: в некоторых сценариях выгоднее дополнительно нагрузить GPU декодированием более компактных весов, чем экономить вычисления ценой постоянного обмена данными с системной памятью.

Почему мы не стали сразу писать собственный CUDA‑kernel

На старте казалось, что проект довольно быстро придёт к созданию собственного CUDA‑kernel. В теории схема выглядит привлекательно: хранить веса в максимально компактном low‑bit формате, загружать небольшой блок, восстанавливать его непосредственно перед вычислением и сразу использовать в GEMV/GEMM, не создавая полноценную деквантованную копию весов в VRAM.

Но прежде чем писать низкоуровневый код, мы решили проверить возможности уже существующей open‑source экосистемы. В ExVRAM исследуются llama.cpp, ExLlamaV3, GemLite, CUTLASS, Marlin, FlashInfer, HQQ и другие проекты, связанные с low‑bit inference.

Этот подход оказался полезным. Основную аппаратную задачу удалось решить без собственного CUDA‑kernel, поэтому сейчас в проекте действует простое правило: новый low‑level код появляется только после того, как найден конкретный измеренный bottleneck, который существующий OSS‑стек закрыть не может. Это позволяет не переписывать уже решённые задачи и сосредоточиться на тех местах, где действительно может возникнуть технологический выигрыш.

Полное размещение модели на GPU

Наиболее удачным из проверенных вариантов для текущей конфигурации оказался UD‑IQ2_XXS в llama.cpp. При этой конфигурации CUDA model buffer составляет около 6521 MiB. Главное же заключается в том, что все 65 из 65 слоёв модели размещаются на CUDA, а decoder weight offload на CPU отсутствует. Именно после устранения CPU offload производительность изменилась наиболее заметно. Один из первых коротких тестов показал скорость около 31,39 токена в секунду — на порядок выше ранних результатов с частичным размещением весов в RAM.

На этом этапе могло показаться, что задача практически решена. Однако дальнейшие эксперименты показали, насколько легко получить красивую цифру, если недостаточно строго определить методику измерения.

Как мы ошиблись с 8k‑контекстом

В одном из ранних экспериментов llama.cpp был запущен с размером контекстного окна 8192, и скорость составила около 29,04 токена в секунду. Первоначально этот результат выглядел как доказательство того, что 27B‑модель работает почти на 30 tok/s с 8k‑контекстом.

Позже выяснилось, что сам параметр ctx‑size не говорит о фактической заполненности контекста. Можно выделить окно на 8192 токена, но реально иметь внутри него несколько сотен токенов. С точки зрения нагрузки на attention и KV cache это совершенно другой сценарий.

При повторной проверке старый результат не воспроизвёлся. В одном из контрольных запусков размер окна действительно составлял 8192, однако фактически было занято только 266 токенов. Медианная скорость в таком режиме составила 17,67 tok/s при коэффициенте вариации 0,74%.

После этого мы изменили benchmark methodology. Теперь в результатах отдельно фиксируются размер настроенного context window, реальное количество prompt tokens, состояние cache перед началом decode, количество сгенерированных токенов и финальная заполненность контекста. Это позволило разделить два разных теста: большой context window с коротким prompt и действительно заполненный длинный контекст. Для практического применения важен именно второй сценарий.

Что получилось на реально заполненном контексте

После переработки методики удалось получить воспроизводимый результат на действительно длинном контексте. Текущая подтверждённая конфигурация выглядит следующим образом: Qwen3.8–27B, UD‑IQ2_XXS, RTX 5060 8 GB, backend llama.cpp, все 65 слоёв на CUDA, без decoder weight offload. Для KV используется q4_0.

На пяти измеренных запусках медианная скорость decode составила 30,10 токена в секунду. Коэффициент вариации составил 2,0%, а пиковое использование VRAM — 7767 MiB. Именно этот результат мы сейчас считаем основной аппаратной вехой ExVRAM. Важное отличие от ранних тестов состоит в том, что речь идёт не о единичном наиболее удачном запуске, а о медиане серии повторных измерений с контролируемыми условиями.

Таким образом, первоначальный вопрос о том, можно ли полностью разместить dense‑модель примерно на 27B параметров на потребительской видеокарте с 8 ГБ VRAM и получить интерактивную скорость генерации, для нашей конфигурации фактически получил положительный ответ.

Почему формат KV cache имеет значение

При такой плотной упаковке модели свободной VRAM остаётся очень мало. Доступные 8 ГБ приходится делить между самими весами, KV/state, CUDA runtime, compute buffers и временными allocations.

Поэтому формат KV cache начинает заметно влиять не только на объём памяти, но и на производительность. На текущей конфигурации q4_0 оказался лучшим из полноценно проверенных вариантов. q8_0 показал меньшую скорость и большую нестабильность. F16 остаётся одним из пунктов следующего этапа проверки.

Это важный практический момент. Нельзя заранее считать, что более высокая точность обязательно будет быстрее, точно так же как нельзя считать, что меньшее количество бит автоматически даст максимальную производительность. Итог зависит от конкретных CUDA kernels, Flash Attention, dequantization path, memory traffic, архитектуры модели и самой GPU. Поэтому ExVRAM ищет не универсально «лучший quant» или «лучший KV», а оптимальное сочетание параметров для конкретного ограничения по памяти и конкретного железа.

Теперь главный вопрос — качество

После получения воспроизводимой скорости задача «запустить 27B на 8 ГБ» перестала быть главным приоритетом проекта. Следующая проблема гораздо важнее: насколько хорошо модель сохраняет свои способности после настолько агрессивной квантизации. UD‑IQ2_XXS позволяет радикально уменьшить memory footprint, но само по себе это ещё не делает конфигурацию пригодной для реального использования. Поэтому текущая активная фаза проекта, P9, посвящена quality validation.

В рамках P9 отдельно проверяются reasoning, mathematics, coding, factual QA, instruction following и long‑context retrieval. Результаты текущего UD‑IQ2_XXS будут сравниваться с более качественным reference той же модельной семьи. До завершения этих измерений мы сознательно не используем формулировки вроде «без потери качества». На момент написания статьи quality gate ещё не завершён. Для исследовательского проекта это принципиальный момент: возможность загрузить модель в VRAM и получить высокий tok/s не означает, что модель после квантования сохранила исходную полезность.

Minimal‑refusal версия модели

Параллельно мы работаем с более steerable, minimal‑refusal вариантом той же модели.

В качестве исходного checkpoint выбран JonathanColetti/Qwen3.8–27B‑Uncensored. Собственный алгоритм изменения поведения модели ExVRAM не разрабатывает: готовый BF16 checkpoint уже существует.

Наша задача заключается в другом — построить полноценную importance matrix, получить matching IQ2_XXS, проверить full‑GPU execution, заполненный 8k‑контекст и затем прогнать тот же quality gate.

Кроме обычных capability benchmarks будут отдельно измеряться refusal rate и benign over‑refusal rate. Это две разные характеристики, и смешивать их нельзя. Простое уменьшение числа отказов не означает автоматически улучшение модели: важно убедиться, что она продолжает корректно выполнять нормальные запросы и не теряет reasoning, coding или instruction following. Поэтому опубликованные upstream‑метрики используются только как ориентир. Финальные показатели должны быть измерены повторно именно на полученном в ExVRAM low‑bit artifact.

Отдельный R&D‑трек: можно ли уйти ниже двух бит

Помимо основного pipeline у проекта есть экспериментальная ветка experiment/p8-low‑bit, где исследуется более агрессивное представление весов. Идея заключается в том, чтобы вместо условных двух бит на каждый вес использовать около одного бита, но чаще задавать локальные параметры квантования. Например, небольшая группа одно‑битных весов может иметь собственный scale или дополнительную correction structure. В теории выигрыш по памяти значителен. Для 27 миллиардов параметров 2 bpw соответствуют примерно 6,75 ГБ raw storage, 1,5 bpw — примерно 5,06 ГБ, а 1,25 bpw — около 4,22 ГБ.

Освободившуюся память можно было бы использовать для более качественного KV cache, увеличения контекста или других runtime structures. Однако у таких форматов есть очевидный риск: сильная потеря качества, а также дополнительные расходы на scales, metadata и реконструкцию весов. Поэтому вместо разработки собственного бинарного формата с нуля мы сначала проверяем уже существующие open‑source подходы: HQQ, GemLite, PB‑LLM и BiLLM. Особенно интересны схемы, где основная масса весов хранится в бинарном виде, а небольшая доля наиболее важных параметров или residual correction сохраняется с более высокой точностью. Этот трек пока остаётся отдельным экспериментом и не влияет на основной рабочий pipeline.

Что мы вынесли из экспериментов

Один из наиболее интересных выводов проекта заключается в том, что самый большой прирост производительности пока был получен не за счёт нового алгоритма и не за счёт собственного kernel.

Результат появился благодаря комбинации уже существующих технологий: агрессивной квантизации, полного размещения decoder weights на GPU, подходящего KV cache, Flash Attention и более строгой методики измерений.

Не менее важным оказался процесс проверки собственных результатов. Несколько привлекательных цифр пришлось снять после повторных тестов. Мы не удаляем такие эксперименты из истории проекта: они остаются в документации как часть исследовательского процесса.

Для ExVRAM воспроизводимый отрицательный результат полезнее, чем красивый benchmark, который нельзя повторить.

Что дальше

Текущая активная стадия P9 посвящена качеству базового UD‑IQ2_XXS и minimal‑refusal варианта. После получения этих результатов станет понятно, подходит ли настолько агрессивное сжатие для практического использования или потребуется другой компромисс между precision и memory footprint.

Следующим этапом станет P10. В нём производительность снова выйдет на первый план, но уже более детально: prefill, time to first token и decode будут измеряться и оптимизироваться отдельно. После этого планируется завершить KV matrix и только затем перейти к speculative decoding — N‑gram, MTP и DFlash2.

Диапазон 35–45 токенов в секунду рассматривается как цель будущих экспериментов, а не как уже полученный результат.

P11 посвящён переходу от лаборатории к пользовательскому инструменту. ExVRAM Runtime предполагается как тонкий слой над готовым inference backend: определить GPU и доступный объём VRAM, выбрать проверенный recipe, подобрать подходящий KV/context, запустить backend и предоставить OpenAI‑compatible endpoint.

Модельные веса в GitHub не хранятся. Для derived artifacts планируется использовать Hugging Face с отдельными model cards, SHA‑хешами, provenance, параметрами квантизации и результатами измерений.

Итог

На сегодняшний день ExVRAM уже подтвердил одну из основных гипотез проекта: dense‑модель примерно на 27 миллиардов параметров можно полностью разместить на RTX 5060 8 GB без decoder CPU‑offload и использовать с реально длинным контекстом при интерактивной скорости.

В нашей текущей конфигурации медианная скорость составляет 30,10 токена в секунду на пяти измеренных запусках, коэффициент вариации — 2,0%, а пиковое использование VRAM — около 7767 MiB. Но теперь вопрос о том, помещается ли модель в 8 ГБ, уже не является главным. Следующий этап должен ответить на более важный вопрос: насколько хорошо модель сохраняет свои способности после настолько агрессивного сжатия.

Если P9 покажет приемлемое качество, ExVRAM сможет перейти от доказательства технической возможности к воспроизводимому пользовательскому решению. Если нет, придётся искать более сложный компромисс между количеством бит, распределением precision, KV cache и вычислительной стоимостью работы с компактным представлением весов.