Что показал форк ik_llama.cpp: замеры на RTX 2060 с 6 ГБ VRAM
IceFog72 выложил обновление форка ik_llama.cpp с MoE-оптимизациями и оптимизацией размещения экспертов. Замеры на RTX 2060 с 6 ГБ VRAM: модель Qwen3.6-35B-A3B-UD-Q4_K_M выдаёт около 45-48 т/с на коротких промптах и около 37 т/с при контексте 28K. Prefill идёт на скорости 430-700 т/с. Цифры автор приводит в посте на r/LocalLLaMA.
Статус данных стоит обозначить до разбора деталей: это замеры одного разработчика на одной видеокарте. Независимой проверки на другом железе нет. IceFog72 прямо пишет, что не пытается провести изменения через слияние в основной проект, потому что обратной связи слишком мало, а тестирование шло только на RTX 2060.
Публикация продолжает его предыдущую работу по MoE-оптимизациям в ik_llama.cpp. Отличие от прошлой версии автор описывает одной фразой: идея та же, реализация немного отличается. Что конкретно переписано, в посте не разобрано, подробности и код лежат в репозитории IceFog72/ik_llama.cpp на GitHub.
Цифры в таблице: генерация, контекст 28K и prefill
Все три замера сделаны на одной конфигурации: RTX 2060, 6 ГБ VRAM, модель Qwen3.6-35B-A3B-UD-Q4_K_M.
| Сценарий | Скорость | Примечание |
|---|---|---|
| Генерация, короткий промпт | 45-48 т/с | Вилка из публикации, длина промптов не указана |
| Генерация, контекст 28K | около 37 т/с | Просадка примерно на 20% относительно короткого промпта |
| Prefill | 430-700 т/с | Разброс почти вдвое, разбивки по сценариям нет |
Вилка prefill в 430-700 т/с выглядит широкой, и это ожидаемо: автор приводит диапазон, а не одно измеренное значение. В посте нет данных о длине обрабатываемых промптов, размере батча и числе потоков, поэтому привязать диапазон к конкретному сценарию нельзя. Практический вывод из таблицы один: на коротких промптах скорость генерации держится в районе 45 т/с, на 28K контекста падает примерно до 37 т/с.
В тексте поста упоминается сравнение со Strata, но конкретных значений Strata автор не приводит. Численно сравнивать нечего, так что ограничимся числами самого форка.
Почему это не независимый бенчмарк
Три обстоятельства стоит держать в голове при чтении цифр. Первое: тестирование проводилось только на одной RTX 2060, других карт в замерах нет. Второе: изменения не предложены к слиянию в апстрим, то есть основной веткой llama.cpp они не проверены. Третье: код, по словам автора, требует разбиения и чистки, потому что в него добавлено много разнородных изменений.
Формулировки IceFog72 в том же обсуждении самокритичны: он не считает нормальным мержить то, что полностью протестировано только на 2060. Значит, 45-48 т/с стоит воспринимать как отправную точку для собственной проверки, а не как доказанное преимущество над другими сборками.
Как крупная MoE-модель вообще помещается в 6 ГБ VRAM
Модель с 35B в названии не помещается в 6 ГБ целиком даже в 4-битном кванте. На такой карте она работает за счёт трёх вещей: разреженной активации, квантования весов и выноса части экспертов за пределы видеопамяти.
Разреженная активация и роль квантования Q4_K_M
MoE (mixture of experts) делит слои на множество экспертов, и на каждый токен роутер выбирает только часть из них. Остальные эксперты в вычислении не участвуют. В имени Qwen3.6-35B-A3B суффикс A3B обозначает архитектуру с примерно 3 млрд активных параметров на токен при 35 млрд общих; это обозначение из названия модели, а не измеренная величина.
Второй множитель экономии, квантование. Q4_K_M хранит веса примерно в 4 бита вместо 16 бит в FP16, с разной точностью для разных тензоров. Память на веса сокращается в 3-4 раза относительно полной точности.
Третья часть, размещение. Даже после квантования модель не влезает в 6 ГБ, поэтому часть экспертов остаётся в системной RAM и подгружается по мере надобности. Как именно это организовано в форке, в публикации не раскрыто, детали есть только в репозитории.
Оптимизация размещения экспертов: что это даёт на практике
Логика простая: эксперты, которые роутер запрашивает часто, держать в VRAM, редкие в RAM и подкачивать по PCIe. Каждое обращение к эксперту, лежащему вне видеопамяти, стоит времени на передачу по шине. На карте с 6 ГБ таких обращений много, и именно они определяют итоговую скорость генерации.
Отсюда и название направления, которое развивает IceFog72. Горячие эксперты должны оставаться в VRAM, а раскладка холодных минимизировать число промахов. Идея перешла из предыдущей версии форка, реализация отличается, но конкретных деталей в посте нет.
Похожие задачи решают и в основной ветке llama.cpp. В сообществе обсуждают Hot Expert Reload: подкачку активных экспертов в VRAM прямо во время генерации. Отдельно разбирался GPU-кеш для MoE-экспертов в pull request #29887, где речь идёт о кэшировании на GPU тех экспертов, что лежат в оперативной памяти хоста. Форк IceFog72 двигается в том же направлении, но своей реализацией.
Чем обновление отличается от предыдущей версии и от основной ветки llama.cpp
От прошлой версии форка, которую обсуждали на r/LocalLLaMA, отличие минимальное по формулировке и непрозрачное по сути. Автор пишет: идея та же, реализация немного отличается. Какие именно части переписаны и что это меняет в поведении на других картах, из поста не следует.
От апстрима отличие принципиальное. ik_llama.cpp остаётся отдельным форком, изменения в основную ветку llama.cpp не отправлены. Причины названы прямо: слишком мало обратной связи, тесты только на одной RTX 2060, код требует разбиения и чистки.
Из этого следует практическое ограничение: заявления вида «форк быстрее основной ветки» из публикации не вытекают, сравнения с апстримом в ней нет. Опыт других MoE-экспериментов с llama.cpp показывает, что прирост сильно зависит от карты и сценария: на RTX 4080 часть патчей ускоряет обработку промптов и работу с кодом, но там же нашлись регрессии и компромиссы.
Кому и зачем пробовать форк на своём железе
Смысл есть, если вы попадаете в одну из групп:
- владелец GPU с 6-8 ГБ VRAM, которому интересно запустить крупную MoE-модель там, где обычные сборки упираются в память;
- энтузиаст, готовый собирать из исходников и разбираться с сырым кодом;
- человек с другой видеокартой, который может дать автору данные, которых у него нет.
Смысла мало, если нужна стабильность и поддержка апстрима: изменения не в основной ветке, форк может отставать от неё, а код, по признанию автора, требует чистки. Второй риск, единственная протестированная конфигурация. Третий, отсутствие численных сравнений со Strata и с апстримом, поэтому оценивать прирост придётся самому.
Как проверить форк самому и что сообщить автору
Порядок действий без экзотики:
- Открыть репозиторий
IceFog72/ik_llama.cppна GitHub и прочитать описание: там код и подробности реализации. - Собрать форк по инструкции из репозитория, не добавляя флагов, которых автор не описывал.
- Взять ту же модель, Qwen3.6-35B-A3B-UD-Q4_K_M в кванте UD-Q4_K_M, иначе результат будет несопоставим с замерами.
- Прогнать три сценария: короткий промпт, контекст 28K и отдельный замер prefill.
- Зафиксировать конфигурацию: модель GPU и объём VRAM, процессор, объём RAM, версию драйвера и ОС.
- Опубликовать результаты в обсуждении на r/LocalLLaMA.
Просьба про обратную связь здесь не формальность. IceFog72 не идёт в апстрим именно потому, что данных с других карт нет. Один прогон на RTX 3060, RTX 4060 Ti или на карте с 8 ГБ даст больше, чем ещё один повтор на 2060.
Что это значит для запуска MoE-моделей на малом объёме VRAM
Пример показывает: 35B MoE-модель в 4-битном кванте может работать на карте с 6 ГБ VRAM и выдавать десятки токенов в секунду, если эксперты разложены по уровням памяти с умом. Для чата такой скорости хватает, хотя ощущения зависят от задачи и длины ответа.
Ограничение ровно одно, зато важное: все цифры получены на одной RTX 2060. Переносить 45-48 т/с на другую карту без проверки нельзя. На результат влияют пропускная способность PCIe, скорость системной RAM и то, насколько удачно легла раскладка экспертов именно под вашу модель.
Практический вывод скромный. Подход интересен для владельцев карт с малым объёмом VRAM и заслуживает проверки на разном железе. Сравнивать его с другими способами запуска MoE при дефиците памяти имеет смысл по одинаковым замерам, а не по обещаниям. Ориентиры для такого сравнения уже есть, например экспериментальные патчи под пару Tesla P100 для той же модели Qwen3.6 35B A3B.
Если у вас есть карта с 6-8 ГБ VRAM, самый полезный шаг сейчас: собрать форк, прогнать три сценария и выложить цифры с описанием конфигурации в обсуждении на r/LocalLLaMA. Без таких замеров форк останется набором оптимизаций, проверенных на одной видеокарте.