IFM, Institute of Foundation Models, представила линейку K2-Horizon из четырех моделей: dense-версии 7B и 32B, а также MoE-модели 36B A4B и 375B A23B. Модель 32B опубликована как stage1 checkpoint, поэтому ее нельзя считать финальным релизом.
Названия K2-Horizon показывают широкий размерный ряд. 7B и 32B используют плотную архитектуру, а 36B A4B и 375B A23B задействуют механизм маршрутизации экспертов. Числа после буквы A обозначают активную часть параметров, но не описывают полный объем памяти, необходимый для хранения модели.
Пока линейку корректно оценивать по составу, типу архитектуры и статусу публикаций. Для выводов о качестве, скорости, совместимости с конкретными фреймворками и пригодности к рабочим задачам нужны финальные чекпойнты, документация и воспроизводимые тесты.
Что вошло в линейку IFM K2-Horizon
В состав K2-Horizon входят две dense-модели и две MoE-модели. Такое сочетание закрывает разные сценарии предварительной оценки: компактный локальный запуск, работу с более крупной плотной сетью и эксперименты с моделями, где общее число параметров заметно выше активной части.
| Модель | Архитектура | Статус и смысл обозначения |
|---|---|---|
| 7B | Dense | Младшая модель K2-Horizon по заявленному размеру |
| 32B | Dense | Stage1 checkpoint, промежуточная версия |
| 36B A4B | MoE | 36B общих параметров, около 4B активных для токена по смыслу обозначения |
| 375B A23B | MoE | 375B общих параметров, около 23B активных для токена по смыслу обозначения |
7B и 32B: dense-модели разного масштаба
7B и 32B относятся к классической плотной архитектуре. При обработке токена такая модель проходит через одну общую сеть, без выбора отдельных экспертных блоков. Разница между версиями прежде всего связана с масштабом: 32B содержит значительно больше параметров и потребует больше ресурсов в том же формате весов.
Для 32B есть отдельная оговорка. Это stage1 checkpoint, то есть сохраненное состояние промежуточного этапа подготовки модели. Публикация такой версии дает возможность изучать направление разработки, но не превращает checkpoint в окончательную модель с зафиксированными характеристиками.
7B тоже нельзя оценивать по одному числу параметров. Реальные результаты зависят от данных обучения, токенизатора, настроек инференса, формата весов и конкретной задачи. Размер помогает прикинуть ресурсную нагрузку, однако не заменяет тестирование.
36B A4B и 375B A23B: MoE-часть линейки
36B A4B и 375B A23B используют архитектуру Mixture of Experts, или MoE. Такая сеть состоит из набора экспертных блоков, а маршрутизатор выбирает часть из них для обработки каждого токена.
В обозначении 36B A4B первое число указывает общий масштаб модели, а A4B показывает активную часть примерно в 4B параметров для отдельного токена. Для 375B A23B логика такая же: общий размер составляет 375B, активная часть обозначена как A23B.
Активные параметры описывают объем вычислений для конкретного шага. Они не означают, что модель можно хранить и загружать как обычную модель на 4B или 23B. Полный набор экспертных весов по-прежнему нужно разместить там, откуда его сможет получать инференс-система.
Почему 32B stage1 checkpoint, это еще не финальная версия
Checkpoint представляет зафиксированное состояние обучения. Разработчики сохраняют такие состояния, чтобы продолжать работу, проводить внутренние проверки или публиковать промежуточный результат для изучения.
Пометка stage1 у 32B указывает на промежуточный этап. Она отделяет эту публикацию от финального релиза, где обычно фиксируют итоговые веса, документацию, совместимые форматы и правила использования. Для K2-Horizon нельзя заранее переносить свойства будущей версии на опубликованный stage1 checkpoint.
Что можно оценивать у промежуточного чекпойнта
У 32B уже можно зафиксировать несколько конкретных характеристик:
- модель относится к dense-архитектуре;
- заявленный размер составляет 32B;
- статус публикации обозначен как
stage1 checkpoint; - модель представляет промежуточное состояние, а не финальный релиз.
Если для checkpoint доступны файлы весов и конфигурация, техническая проверка может включать загрузку в совместимый инструмент, измерение потребления памяти и прогон одинаковых промптов. Такие действия описывают конкретную опубликованную версию. Они не дают окончательной оценки всей линейки и не предсказывают результат будущего этапа обучения.
Каких выводов делать не стоит
Ранний статус не позволяет объявлять 32B лучшей или худшей моделью K2-Horizon. Нельзя по одному пользовательскому запуску судить о стабильности, качестве рассуждений, генерации кода, работе с длинным контекстом или положении среди конкурентов.
Сравнение с финальными моделями требует одинаковых условий: версии весов, точности или квантизации, длины контекста, параметров сэмплирования, набора задач и аппаратной конфигурации. Пока хотя бы один из этих элементов не зафиксирован, результат остается предварительным наблюдением.
32B stage1 checkpoint имеет смысл воспринимать как материал для ранней технической проверки. Решение о рабочем использовании нужно принимать после появления финальной версии или после самостоятельной проверки именно тех задач, для которых модель планируют применять.
Dense и MoE: в чем разница на практике
Dense и MoE отвечают на одну задачу, генерацию следующего токена, разными способами. Dense-модель применяет одну плотную сеть к каждому токену. MoE направляет токен к выбранным экспертам, оставляя остальные блоки неактивными на этом шаге.
Как работает dense-модель
В dense-модели основные параметры сети участвуют в обработке каждого токена. Если модель содержит 7B параметров, этот размер служит ориентиром для хранения весов и вычислительной нагрузки. У версии 32B ориентир выше, поскольку плотная сеть крупнее.
При этом число параметров не описывает все затраты. На расход памяти влияют точность весов, размер контекста, KV-кэш, размер пакета запросов, служебные буферы и способ распределения слоев между GPU и оперативной памятью.
Преимущество dense-архитектуры для пользователя связано с более прямой логикой запуска. Не требуется отдельный механизм маршрутизации экспертов, а поведение нагрузки проще оценивать по размеру модели и выбранному формату. Это не гарантирует более высокую скорость или лучшее качество без измерений.
Как читать обозначения MoE 36B A4B и 375B A23B
Для MoE нужно разделять два числа:
- общее число параметров, сюда входят веса всех экспертов и общих компонентов;
- активные параметры, часть сети, которая участвует в обработке конкретного токена.
У 36B A4B активная часть по обозначению составляет около 4B параметров. У 375B A23B она составляет около 23B. Значения помогают оценить вычислительную работу одного шага, но не превращают эти модели в аналоги dense-моделей с таким же числом параметров.
Маршрутизатор выбирает экспертов не произвольно: его задача состоит в распределении токенов между доступными блоками. На практике к активным экспертам добавляются общие слои, операции маршрутизации и обмен данными. Поэтому точное число операций зависит от архитектуры и конкретной реализации, а одной маркировки A4B или A23B недостаточно для прогноза скорости.
Что MoE дает и чего не гарантирует
Частичная активация может уменьшить число вычислений на отдельном токене по сравнению с обработкой всей сети. Это позволяет строить модели с большим общим количеством параметров при меньшей активной нагрузке на шаге генерации.
Результат зависит от маршрутизации, загрузки экспертов, поддержки архитектуры в фреймворке, пропускной способности памяти, межпроцессорного обмена и размера пакета. При малом количестве запросов или неудачном распределении данных преимущества MoE могут проявиться слабее ожидаемого.
Схожая логика встречается и у моделей с гораздо меньшей активной частью. Практические последствия такого устройства разобраны в материале о MoE-моделях с 2B активных параметров. У K2-Horizon масштабы другие, поэтому переносить требования или скорость из этого класса нельзя.
Почему 375B не обязательно означает пропорционально дорогой запуск
Размер 375B описывает общее количество параметров. Цена и техническая сложность запуска зависят еще от того, где хранятся веса, сколько параметров активируется на токене и как система обслуживает контекст диалога.
Память для весов и память во время работы
Веса занимают место в зависимости от точности хранения. Для грубой оценки используют формулу: число параметров умножают на количество бит на параметр и делят на 8. Полученный результат показывает только базовый объем весов, без служебных данных и дополнительных буферов.
Во время генерации к весам добавляются KV-кэш, память под выбранный контекст, состояния вычислительных операций и буферы фреймворка. KV-кэш растет вместе с длиной диалога и числом одновременных запросов. Его объем зависит от устройства модели, точности хранения и настроек инференса.
У MoE к вычислениям на текущем токене подключается часть экспертов, но полный набор весов должен оставаться доступным системе. Если он не помещается в VRAM, часть данных размещают в оперативной памяти или распределяют между несколькими GPU. Это может добавить задержки из-за обмена по шине и обращения к более медленной памяти.
Как квантизация меняет требования к запуску
Квантизация хранит параметры в формате с меньшей разрядностью. Объем весов уменьшается, поэтому модель может стать доступнее для локального запуска на конфигурациях с ограниченной VRAM или RAM.
Снижение точности имеет ограничения. Потери зависят от метода квантизации, слоя, исходного чекпойнта и конкретной задачи. Совместимость тоже различается: один фреймворк может поддерживать нужный формат, а другой потребует конвертацию или не сможет загрузить модель.
Практические последствия сжатия для локальных LLM разобраны в материале о пределах сжатия моделей и квантизации. Для K2-Horizon перед запуском нужно отдельно проверить доступные форматы весов, а не рассчитывать на условный объем для абстрактной точности.
Локальный и облачный сценарии
Локальный запуск требует оценить совокупность ресурсов: VRAM GPU, объем оперативной памяти, свободное место на диске, пропускную способность памяти и скорость обмена между устройствами. Для крупных MoE это особенно заметно, поскольку активная часть снижает вычислительную нагрузку, но не отменяет хранение экспертных весов.
Облачный инференс переносит аппаратные требования на провайдера, но добавляет другие условия. Нужно проверить поддержку архитектуры, доступность нужного формата, ограничения по контексту, время ответа и схему тарификации. Цены и конкретные сервисы нельзя оценить по одному названию модели.
Для конфигураций с несколькими GPU и offload полезно заранее разобраться, как разные инструменты распределяют слои, KV-кэш и экспертные блоки. Практическое сравнение KTransformers и llama.cpp для MoE на нескольких GPU приведено в разборе инструментов запуска MoE-моделей.
Как оценивать K2-Horizon пользователю локальных LLM
Перед загрузкой любой модели из линейки нужно собрать техническую карту релиза. Для K2-Horizon она пока важнее громкого числа параметров: у разных версий различаются архитектура и статус публикации.
- Статус релиза. Для 32B нужно зафиксировать, что перед пользователем stage1 checkpoint. Остальные версии тоже следует проверять по документации, а не считать финальными автоматически.
- Артефакты. Нужны конфигурация, веса, описание токенизатора, сведения о лицензии и инструкции по загрузке. Без этих данных невозможно надежно оценить совместимость.
- Формат и квантизация. Следует выяснить, в какой точности опубликованы веса, доступны ли варианты для нужного инструмента и какие преобразования понадобятся.
- Память. Нужно отдельно считать место под веса, KV-кэш, контекст, служебные буферы и возможный offload в RAM.
- Скорость. Проверять следует как обработку входного промпта, так и генерацию. Замер нужно проводить на целевом GPU, с фиксированными контекстом, квантизацией и настройками.
- Качество. Для практического решения нужны одинаковые промпты на собственных задачах: код, документы, RAG, агенты или обычный диалог. Один удачный ответ не заменяет серию проверок.
Кому может быть интересна 7B
7B занимает младшую позицию в K2-Horizon среди четырех новых моделей. Поэтому ее логично проверять первой пользователям локальных LLM, которым нужен более компактный dense-чекпойнт и понятная схема размещения весов.
При выборе нужно сопоставить размер модели с конкретным форматом, задачами и доступной памятью. 7B может оказаться удобнее крупной версии для ежедневного диалога или локального помощника, но это предположение о сценарии, а не оценка качества K2-Horizon. Фактический выбор потребует собственных тестов.
Кому стоит смотреть на 32B
32B подойдет для предварительного изучения пользователям, которым нужен более крупный dense-класс и есть запас памяти под выбранный формат. Ее статус stage1 меняет порядок действий: сначала проверяют загрузку, стабильность и ответы на собственных данных, затем ждут финальную версию или сопоставляют обе публикации.
Результаты 32B нельзя сравнивать с завершенными моделями без фиксации условий. Различия в квантизации, контексте и параметрах генерации легко создают впечатление преимущества или отставания, которого нет при одинаковой методике.
Для кого важны MoE-модели 36B A4B и 375B A23B
36B A4B и 375B A23B прежде всего интересны разработчикам инференса, владельцам мощных домашних AI-серверов и пользователям облачных ресурсов. Для них важны распределение экспертных весов, поддержка маршрутизации и поведение модели при реальной нагрузке.
Обозначение A4B не означает требования, сравнимые с dense-моделью 4B. Аналогично, A23B не превращает 375B в модель, для которой достаточно памяти обычной dense-версии 23B. Перед запуском нужно оценить полный объем весов и способ их размещения.
Локальный тест MoE имеет смысл проводить на той конфигурации, где модель планируют использовать. Для одного GPU, нескольких карт, CPU-GPU offload и облачного сервера узкие места будут разными. Сравнивать только токены в секунду без учета задержки первого токена, длины контекста и расхода памяти недостаточно.
Как K2-Horizon продолжает линейку IFM
От 0.9B и 3.7B к моделям K2-Horizon
До K2-Horizon IFM уже публиковала небольшие модели с размерами 0.9B и 3.7B. Новый релиз расширяет линейку версиями 7B и 32B, а MoE-модели 36B A4B и 375B A23B добавляют существенно более крупные варианты с частичной активацией параметров.
Эта последовательность показывает расширение размерного ряда IFM. По одним цифрам нельзя утверждать, что каждая новая модель превосходит предыдущую, лучше подходит для кода или требует меньше ресурсов. Для таких выводов нужны описания задач, версии весов и одинаковые тесты.
| Группа | Что известно | Чего нельзя заключать из размера |
|---|---|---|
| 0.9B и 3.7B | Ранее опубликованные небольшие модели IFM | Нельзя автоматически сравнивать их качество с K2-Horizon |
| 7B и 32B | Новые dense-модели, причем 32B имеет статус stage1 checkpoint | Нельзя считать 32B финальной версией |
| 36B A4B и 375B A23B | Новые MoE-модели с указанными общими и активными параметрами | Нельзя принимать активный размер за полный объем хранения |
Что известно о K2-Horizon сейчас, а что еще предстоит проверить
Подтвержденная карта релиза выглядит так: K2-Horizon включает dense-модели 7B и 32B, MoE-модели 36B A4B и 375B A23B, а 32B опубликована как промежуточный stage1 checkpoint. Ранее IFM уже выкладывала модели 0.9B и 3.7B.
Эти данные объясняют устройство линейки, но не заменяют обзор качества. Пока нельзя честно назвать лучшую модель для кода, RAG, агентных сценариев или обычного диалога. Нельзя и обещать конкретную скорость на определенной видеокарте без формата весов, настроек и замеров.
Предварительный вывод для локальных пользователей
7B выглядит самым понятным кандидатом для первой технической проверки из-за меньшего заявленного размера и dense-архитектуры. 32B имеет смысл изучать пользователям с более мощной системой, но ее stage1-статус требует осторожности. 36B A4B и 375B A23B нужно оценивать как MoE-релизы, где активные параметры уменьшают вычисления на токене, но не отменяют хранение всей модели.
Планировать рабочее использование K2-Horizon можно после проверки трех вещей: доступного формата, совместимого инференс-фреймворка и поведения на собственных задачах. Для 32B к этому списку добавляется ожидание финального чекпойнта или четкая фиксация того, что тестируется промежуточная версия.
Какие данные изменят оценку линейки
Для полноценного сравнения понадобятся:
- финальные веса 32B и подтверждение статуса остальных моделей;
- модельные карты с архитектурными и техническими деталями;
- лицензия и условия использования;
- поддерживаемые форматы весов и квантизации;
- совместимость с инференс-фреймворками;
- требования к VRAM, RAM, контексту и KV-кэшу;
- воспроизводимые бенчмарки на одинаковых настройках;
- результаты на практических задачах локального и облачного инференса.
До появления этих сведений K2-Horizon лучше воспринимать как линейку для наблюдения и технической проверки. Самые осторожные выводы касаются уже заявленной архитектуры и статуса 32B, а вопрос качества и реальной стоимости запуска остается открытым.