Последние новости в сфере ИИ натолкнули меня на одну обнадёживающую мысль: локальный запуск очень больших моделей уже не выглядит чем-то совсем фантастическим.
Пока это ещё не новая реальность, но последние опубликованные технологи подводят именно к этому. Давайте разберёмся, какие именно новости к этому подводят и чего можно ожидать в ближайшем будущем.
PrismML анонсировала и выложила в открытый доступ Bonsai 8B
Это 1-bit модель с лицензией Apache 2.0, размером около 1.15 ГБ в GGUF. В модельной карточке прямо указано, что это Qwen3-8B dense по архитектурной базе, а ключевая новизна — не в новой архитектуре, а в end-to-end 1-bit представлении весов для embeddings, attention projections, MLP projections и LM head
В чём суть новости
Главная новость в том, что PrismML заявляет радикальное уменьшение веса модели без полного развала качества: 1.15 ГБ против 16.38 ГБ у FP16, то естьпримерно 14.2x меньше.
То есть по сути, это говорит нам о том, что для полной загрузки весов модели требуется в 14.2 раза меньше памяти.
В официальном анонсе PrismML пишет, что Bonsai 8B работает примерно на 131 ток/с на M4 Pro, 368 ток/с на RTX 4090 и около 44 ток/с на iPhone 17 Pro Max.
В model card для GGUF-версии заявлены до 6.2x ускорения генерации текста относительно FP16 на RTX 4090 и 4–5x лучшая энергоэффективность. Там же приведена их внутренняя таблица бенчмарков: средний оценка 70.5 по шести категориям против 79.3 у Qwen 3 8B, 71.0 у Mistral 3 8B и 67.1 у Llama 3.1 8B.
То есть заявление не в том, что Bonsai 8B стала лучшей 8B-моделью по качеству, а в том, что она остаётся конкурентоспособной при радикально меньшем размере. Бенчмарков с квантизированными моделям не проводились, это ещё открытый вопрос.
Как они этого достигли
Идея простая: каждый вес хранится как 1 бит, где 0 и 1 соответствуют примерно −scale и +scale, а на каждую группу из 128 весов даётся один общий FP16 scale.
Поэтому эффективная стоимость получается не ровно 1 бит на вес, а 1.125 бита на вес.
Именно так они и выходят на порядок меньший размер: для Bonsai 8B заявлены 1.15 GB против 16.38 GB у FP16.
На инференсе они не разворачивают всё обратно в FP16 полностью. В model card они отдельно пишут про inline dequantization kernels и “no FP16 materialization”, а в demo-репозитории указывают, что нужные kernel’ы пока вообще отсутствуют в upstream llama.cpp и MLX, поэтому используются их собственные форки. То есть ускорение идёт не только от маленького файла на диске, а от того, что они специально переписали исполнение под такой формат весов.
При этом есть важное ограничение: точный “секретный соус” они публично не раскрывают полностью.
В официальных материалах PrismML говорит о proprietary mathematical framework и о годах работы над сжатием нейросетей без потери reasoning capabilities, но из открытых документов видно скорее общий принцип и runtime-часть, чем воспроизводимый пошаговый training recipe.
Попробовать запустить модели локально можете по их инструкции наgithub.
Также прилагаю ссылку наwhitepaper
Если раньше локальная машина тянула только обычную 8B-модель, то при успешном масштабировании Bonsai-подобного подхода граница может сдвинуться и к 100B-классу по весам. Но есть дваНО
- это проприетарная технология
- общая память инференса — это не только веса
Если по первому пункту нам остаётся надеяться на раскрытие, либо развитие подобных технологий, то по второму пункту, у нас, кажется, уже есть решение.
И тут на сцену выходит вторая новость
Google Research представила TurboQuant
Это метод экстремального сжатия данных при инференсе, прежде всего KV-cache, то есть той части памяти, которая растёт вместе с длиной контекста и быстро становится одним из главных ограничений для больших моделей.
В чём суть новости
В отличие от Bonsai, который бьёт по размеру самих весов, TurboQuant нацелен на другую проблему: сделать значительно дешевле память, которую модель потребляет уже во время работы.
В официальном материале Google пишет, что метод позволяет сильно уменьшить объём KV-cache без дообучения модели, а в работе авторы показывают, что на их тестах удаётся добиться “quality neutrality” на уровне около 3.5 бит на канал и лишь небольшой деградации при 2.5 битах.
Что это даёт?
Google заявляет:
TurboQuant умеет ужимать KV-cache до 3 бит без потери качества на их тестах, а также даёт как минимум6-кратное снижение памяти KV-cacheв практических экспериментах.
Главное отличие TurboQuant в том, что он обещает удерживать качество даже в экстремально низком диапазоне — около 3–3.5 бит на канал, где обычные подходы уже начинают чувствительно рисковать качеством.
Для примера можно взять Qwen3-235B-A22B.
При хранении KV-cache в 16-битном формате контекст 128k требует 23.5 GiB памяти только под кеш. Если применить TurboQuant в режиме 3.5 бита на канал — именно этот режим авторы исследования описывают как не дающий потери качества на их тестах, — тот же KV-cache сжимается примерно до 5.1 GiB. Иными словами, только на рабочей памяти модели экономится больше 18 GiB
Как они этого достигли
Если максимально упростить, TurboQuant делает две вещи.
Сначала метод специальным образом “поворачивает” данные в более удобное представление, где их можно намного сильнее сжать, а затем отдельным шагом компенсирует возникающую ошибку, чтобы сжатие не ломало ключевые вычисления модели.
В самой работе этот подход не только проверяют на практике, но и математически обосновывают; для KV-cache авторы показывают отсутствие потери качества на 3.5 бита на канал в своих тестах.
ссылка на ресерч
Теперь давайте поразмышляем
Я надеюсь, что в будущем эти технологии будут широко развиты и открыты для использования. Я хочу прикинуть, что будет, если мы сможем объединить и масштабировать их?
Объединение технологий
Если попробовать мысленно объединить обе технологии, картина становится уже по-настоящему интересной.
Допустим, 1-bit-подход PrismML однажды удастся масштабировать с тем же порядком эффективности, что и у Bonsai 8B: там компания заявляет уменьшение веса модели примерно в 14.2 раза — с 16.38 ГБ до 1.15 ГБ. Тогда модель класса Qwen3-235B-A22B, чьи веса в bfloat16 занимали бы около 437.7 GiB, теоретически могла бы опуститься примерно до 30.8 GiB только по весам.
Но одних только весов недостаточно: большая модель упирается ещё и в KV-cache.
Для Qwen3-235B-A22B при контексте 128k он занимает около 23.5 GiB в 16-битном формате.
Если же взять режим TurboQuant, который в исследовании описывается как не дающий потери качества на 3.5 бита на канал, тот же KV-cache сжимается примерно до 5.1 GiB. Иными словами, только на рабочей памяти модели экономится больше 18 GiB.
Если сложить эти два эффекта вместе, то получается почти фантастическая, но уже не совсем безумная оценка: модель класса 235B при контексте 128k могла бы требовать порядка 36 GiB только на веса и KV-cache вместо более чем 460 GiB в обычном 16-битном представлении.
Это ещё не означает, что такую модель завтра можно будет без проблем запускать на любой домашней машине: остаются накладные расходы рантайма, пропускная способность памяти, качество реализации ядер и главный вопрос — удастся ли вообще так же хорошо масштабировать 1-bit-схему на действительно большие модели.
Но сама траектория уже выглядит иначе: то, что ещё недавно казалось чисто серверным классом моделей, начинает приближаться к локальным машинам.
Именно поэтому связка 1-bit-весов и TurboQuant выглядит такой важной: вместе они впервые позволяют всерьёз представить, что модель класса 235B — не как далёкая абстракция, а как реальный кандидат на локальный запуск в будущем.
