Что такое Swift-Qwen3.8-27B-Genesis-GGUF и почему о ней говорят
GGUF-сборка Qwen-модели класса 27B с поддержкой зрения занимает меньше 17 ГБ и умещается в 32 ГБ видеопамяти вместе с полным контекстом 262k токена. Такой запуск показал пользователь Then_Blueberry7290: модель LuffyTheFox/Swift-Qwen3.8-27B-Genesis-GGUF он прогнал через llama.cpp на двух RTX 5060 Ti по 16 ГБ. Отчёт опубликован в r/LocalLLaMA 27 сентября 2026 года.
Главная цифра здесь не скорость, а память. Файл модели с vision-частью меньше 17 ГБ, при этом контекст 262k доступен целиком, ubatch увеличен, включён mtp4. Для сравнения: аналогичные модели в формате nvfp4 обычно занимают 19-20 ГБ и больше. Практическая выгода в том, что длинный контекст и работа с изображениями больше не конкурируют за VRAM в одной сессии.
Дальше важная оговорка, без которой цифры читаются неправильно. Это личный опыт одного человека на своей конфигурации. Независимых тестов нет, официального бенчмарка модели тоже, точные значения ubatch и mtp4, версия llama.cpp, сборка CUDA и драйверы в отчёте не указаны. Всё, что ниже, опирается на эти данные и на общие принципы работы GGUF и llama.cpp.
Отдельно стоит сказать, что в названии сборки есть приставки Swift и Genesis, но из отчёта не следует, что именно они означают и чем файл отличается от базовой Qwen 27B по составу дообучения. Для выбора модели это существенно: два GGUF одинакового размера могут вести себя по-разному, если один из них прошёл дополнительную настройку.
GGUF-квантование: что это и как оно влияет на размер модели
GGUF - формат контейнера, в котором llama.cpp и совместимые с ним движки хранят модели. В одном файле лежат тензоры весов, метаданные архитектуры (число слоёв, размерность, количество KV-голов), шаблон чата и словарь токенизатора. Мультимодальные сборки идут с отдельным файлом mmproj - проектором, который превращает картинку в набор эмбеддингов, понятных языковой модели.
Квантование - снижение точности весов. Вместо FP16, где на параметр уходит 2 байта, квант хранит 5, 4, 3 или ещё меньше бита на вес. Арифметика для модели на 27B простая: FP16-веса без квантования - это порядка 54 ГБ только под параметры, а 4-битный квант укладывается примерно в 15-16 ГБ. От выбранного кванта зависит, влезет модель в видеопамять целиком, частично или потребует расчётов на CPU.
Второй потребитель VRAM - KV-кэш, где модель держит состояния внимания по мере роста контекста. Он растёт линейно с длиной контекста и зависит от числа слоёв, KV-голов, размерности головы и типа кэша (FP16, Q8, Q5). На длинных контекстах кэш легко перевешивает сами веса, поэтому каждый освобождённый гигабайт напрямую превращается в доступные токены контекста.
Как выбирать между Q4, Q5 и Q6 и что реально меняется при переходе к более мягкому кванту, разбирается в материале о запуске Qwen 3.8 Flash Next на 6 ГБ VRAM.
Почему GGUF-версия компактнее nvfp4
У автора отчёта есть прямое сопоставление размеров: GGUF-сборка меньше 17 ГБ, аналогичные модели в nvfp4 - 19-20 ГБ и больше. nvfp4 - четырёхбитный формат для GPU NVIDIA поколения Blackwell с блочным масштабированием, где веса хранятся в FP4 с общими множителями на блок. GGUF-кванты устроены иначе: они бывают разной агрессивности, а в k-квантах битность может отличаться от слоя к слою, так что чувствительные тензоры получают больше точности, а остальные меньше. Такая раскладка и позволяет ужать файл.
Разница в размере не означает автоматически разницу в качестве. Она означает другое: за один и тот же бюджет VRAM вы получаете либо длиннее контекст, либо больше запаса под KV-кэш, либо крупнее батч обработки промпта. Какой именно квант лежит внутри этих 17 ГБ, в отчёте не сказано, и это первое, что стоит уточнить перед скачиванием.
Запуск в llama.cpp: как уместить 262k контекста в 32 ГБ VRAM
Конфигурация из отчёта: две RTX 5060 Ti по 16 ГБ, суммарно 32 ГБ VRAM. Модель занимает меньше 17 ГБ, то есть остаётся около 15 ГБ. В этот остаток автор поместил полный контекст 262k, увеличенный ubatch и mtp4, а vision-часть отправил в системную память. Формулировка из отчёта: vision goes to ram, not gpu.
Что именно скрывается за увеличенным ubatch и mtp4, автор не раскрыл. ubatch влияет на размер буфера при обработке промпта, MTP (multi-token prediction) - на этап декодирования. Эффект от MTP зависит от реализации и от того, как часто предсказанные токены принимаются, поэтому без замеров это скорее заявка, чем подтверждённое ускорение. Про MTP, sparse attention и vision в GGUF-моделях есть отдельный обзор набора сборок.
Третий момент - как задаётся сама длина контекста. В llama.cpp это параметры запуска, и от их сочетания зависит, сколько памяти уйдёт на кэш и на слоты обработки запросов. Разбор этих настроек на примере другой модели Qwen 3.8 есть в материале об устройстве Qwen3.8-Flash-Next.
Выгрузка mmproj в RAM: что это даёт и какие ограничения
mmproj - мультимодальный проектор, который переводит эмбеддинги изображения в пространство токенов языковой модели. В llama.cpp проектор можно не грузить на GPU, а оставить на CPU: тогда его веса живут в системной памяти. Именно это и сделал автор отчёта, и именно это освободило VRAM под длинный контекст.
Выигрыш измеримый: освобождённые гигабайты уходят в KV-кэш, поэтому 262k контекста становятся реальными, а не теоретическими. Плата тоже понятна. Обработка изображений идёт через CPU и оперативную память, значит узким местом становится их пропускная способность. На одной картинке разница может быть незаметной, на потоке изображений или при больших разрешениях задержка вырастет. Отдельного замера скорости vision в отчёте нет, поэтому конкретные цифры приводить не из чего.
Второе ограничение - объём RAM. Для выноса нужно столько системной памяти, сколько занимает проектор, плюс буферы, плюс всё, что уже занято системой и остальными процессами. Сколько именно требует эта сборка, автор не указал, так что подбирать запас придётся экспериментально.
Скорость работы: 40-113 т/с в бенчмарке и 45-65 т/с в агентных задачах
По данным автора, скорость генерации при контексте 262k лежит в диапазоне 40-113 токенов в секунду, в его бенчмарке получилось 76 т/с. В обычной агентной работе, где модель вызывает инструменты и обменивается короткими репликами, скорость падает до 45-65 т/с.
Диапазон в 40-113 т/с широкий, и это нормально для локального инференса. Скорость декодирования зависит от длины активного контекста, от объёма вычислений, которые ушли на CPU, от загрузки двух карт и от характера генерируемого текста. В отчёте не сказано, на какой длине контекста получены верхняя и нижняя границы, поэтому воспринимать 113 т/с как типичную скорость на 262k не стоит.
Порядок величин полезно сверить с другим пользовательским отчётом: Qwen3.8-Flash-Next в IQ3_XXS на 12 ГБ VRAM выдаёт 14-15 т/с и падает до 11,3 т/с на 90-100K. Там картина хуже, но и железо скромнее, а модель тяжелее. Сравнивать эти цифры напрямую нельзя, зато видно общий закон: с ростом контекста скорость оседает, и запас VRAM здесь работает на результат.
Сравнение с nvfp4 и ThinkingCap nvfp4 на vLLM: в чём разница
| Параметр | Swift-Qwen3.8-27B-Genesis-GGUF в llama.cpp | Аналогичные модели в nvfp4 |
|---|---|---|
| Размер модели | меньше 17 ГБ | 19-20 ГБ и больше |
| Движок | llama.cpp | vLLM (в случае ThinkingCap nvfp4) |
| Доступный контекст | 262k | 160k у ThinkingCap nvfp4 |
| mmproj | выносится в RAM | вынести в RAM нельзя, по словам автора |
| Качество | по первому впечатлению совпадает | точка сравнения автора |
Ключевое различие не в размере, а в потолке контекста. Для ThinkingCap nvfp4 на vLLM автор называет 160k, и причина конкретная: mmproj нельзя выгрузить в оперативную память. Об этом он пишет прямо: for example thinkingcap nvfp with vllm i can only have 160k context. Разница между 262k и 160k при работе с длинными документами и агентными цепочками заметная.
Про качество автор высказался осторожно: по первому впечатлению сборка совпадает с другими swift-моделями в nvfp4. Это субъективная оценка без задач на рассуждение, код и следование инструкциям, поэтому считать её измерением нельзя. Она лишь означает, что заметной деградации на глаз не видно.
Почему в vLLM нельзя выгрузить mmproj в RAM
vLLM рассчитан на серверный GPU-инференс: веса и вспомогательные модули живут в видеопамяти, а планировщик управляет батчами параллельных запросов. Раскладка слоёв между GPU и CPU там не основной сценарий. llama.cpp работает иначе: он изначально умеет разносить вычисления между видеокартой и процессором и оставлять отдельные модули на CPU. Отсюда и разница в описанной конфигурации.
Стоит подчеркнуть: это ограничение движка, а не изъян модели. ThinkingCap nvfp4 в vLLM на мощной карте может дать куда большую пропускную способность на множестве одновременных запросов, и там 160k контекста не выглядят проблемой. Но если задача - один длинный диалог с картинками на потребительской сборке, свобода llama.cpp в распределении памяти выигрывает.
Какие компромиссы скрывает компактная GGUF-версия
Автор отчёта сам ставит вопрос: в чём компромисс этой сборки. Прямого ответа в данных нет, зато видны конкретные пробелы, которые придётся закрывать самостоятельно.
- Тип кванта не назван. Формулировка «меньше 17 ГБ» ничего не говорит о битности. Q4_K и IQ3_XXS могут дать близкий размер файла при разном поведении на сложных задачах, а сравнение с nvfp4 тогда превращается в сравнение объёма, а не качества.
- Качество оценено на глаз. Никаких бенчмарков, наборов задач и замеров на следование инструкциям в отчёте нет, поэтому тезис о совпадении с nvfp4 остаётся впечатлением.
- Скорость не привязана к длине контекста. Диапазон 40-113 т/с дан без указания, на каких контекстах получены его границы. Как поведёт себя модель на 200k+ токенов, неизвестно.
- Vision ушёл на CPU. Экономия VRAM оплачена скоростью обработки изображений, и эти замеры в отчёте отсутствуют.
- Настройки не воспроизводимы. Значения ubatch, параметр mtp4, версия llama.cpp и драйвер не раскрыты, повторить конфигурацию один в один не получится.
- Стабильность не проверена. Долгие сессии на полном контексте, поведение при переполнении окна, работа с несколькими параллельными агентами в отчёте не описаны.
Часть этих рисков снимается ценой размера: чем мягче квант, тем предсказуемее поведение, но и больше файл. Где проходит граница между экономией памяти без видимых потерь и моментом, когда модель начинает путаться в вызовах инструментов, разбирается в сравнении IQ1_S и Q4 на одном классе моделей.
Кому подходит такая конфигурация и стоит ли повторять
Сборка рассчитана на владельца 32 ГБ VRAM: две карты по 16 ГБ или одна на 32 ГБ, плюс достаточный объём системной памяти под вынесенный проектор и под сами процессы. Основной сценарий, где такая схема оправдана, - длинный контекст и работа с изображениями в одной локальной сессии без аренды GPU.
Проверьте арифметику под своё железо. Файл меньше 17 ГБ не поместится целиком на одну карту с 16 ГБ: останется либо частичная выгрузка слоёв в RAM, либо урезанный контекст, либо оба ограничения сразу. Карта на 24 ГБ даёт больше запаса, но KV-кэш на 262k всё равно заберёт свою долю, а вынос mmproj останется полезным приёмом. Сколько приходится жертвовать на ещё более скромной видеокарте, видно по опыту запуска на 12 ГБ VRAM, ссылка выше.
Практический порядок действий простой. Сначала уточните тип кванта внутри файла и убедитесь, что ваша сборка llama.cpp умеет держать мультимодальный проектор на CPU. Затем измерьте скорость на 30-50k контекста на своей реальной задаче, и только после этого поднимайте длину до 262k, следя за потреблением RAM. Если на длинном контексте качество просядет, следующий шаг - более консервативный квант весов или квантование KV-кэша, а не отказ от идеи целиком.