Сигнал из хука LLMScience: Samsung открыла исходный код LittleBit — метода, который сжимает языковую модель на 13 млрд параметров до размера меньше 1 ГБ. Вместо хранения весов обычными числами используется скрытая факторизация, объём падает ниже одного бита на вес, в некоторых конфигурациях — до 0,1 бита. Умножения чисел с плавающей точкой в ключевых операциях заменяются побитовым XOR. По заявленным результатам — ускорение до 11,6 раза против FP16, меньше памяти и меньше данных при загрузке, а устойчивость сохраняется даже ниже 0,5 бита на вес. Статья — arXiv 2506.13771. Витрина — vibe-studio.uk.
Соседи: EmbeddingGemma 2 и локальный RAG, Qwen 3.8 локально на 3090, Ollama и Claude Desktop, Kolibri от Aleph Alpha.
Что заявлено, по пунктам
- Размер: модель на 13 млрд параметров — меньше 1 ГБ.
- Плотность: меньше одного бита на вес, в отдельных конфигурациях до 0,1 бита.
- Как: скрытая факторизация вместо хранения весов обычными числами.
- Вычисления: ключевые умножения с плавающей точкой заменены на XOR, матричные операции сводятся к смене знаков.
- Скорость: до 11,6 раза быстрее FP16 — по заявленным результатам авторов.
- Устойчивость: метод держится ниже 0,5 бита на вес, где прошлые методы сжатия, по словам авторов, проваливаются.
- Статус: исходный код открыт.
Это цифры авторов. Независимых замеров качества на задачах кодинга в хуке нет, поэтому ниже — как читать новость, а не обещание «13B на телефоне пишет код как Opus».
Почему это не очередное «квантование в 4 бита»
Привычная локальная история — взять модель и ужать веса до 8 или 4 бит, чтобы влезла в видеокарту. Дальше начинается заметная потеря качества. LittleBit бьёт в другую точку: хранить не сами числа, а более компактное представление, и считать не умножениями, а битовыми операциями. Если это переносится на реальные модели без сильной деградации, меняется сама арифметика запуска: меньше памяти и меньше вычислений на каждый токен.
Отсюда и заявленное ускорение. Узкое место локального запуска часто не вычисления, а память: сколько весов нужно прочитать на каждый шаг. Модель меньше 1 ГБ читается быстрее, чем десятки гигабайт.
Что это даёт вайб-кодеру сейчас
- Пока — ничего «из коробки». Это метод и код, а не готовая модель в Ollama. Ждите, пока сообщество соберёт сжатые веса популярных моделей и проверит их на задачах.
- Ориентир для локального стека. Если вы держите локальную модель для приватных задач, как в разборе Qwen 3.8 на 3090, такие методы со временем могут снизить требования к железу.
- Мелкие агенты на устройстве. Классификация, разметка, короткие саммари, роутинг запросов — задачи, где маленькая сжатая модель может закрыть работу без облака. Похожая логика — у Haiku 5.5 как дешёвого субагента, только локально.
- Локальный RAG. В связке с компактными эмбеддингами вроде EmbeddingGemma 2 это шаг к поиску по своим документам целиком на ноутбуке.
Где не обольщаться
- Качество на коде не доказано. Сжатие ниже бита на вес почти всегда чем-то платит. Для агентной работы в репозитории пока надёжнее облачные модели.
- «До 11,6 раза» — верхняя граница. На вашем железе и с вашим рантаймом цифра будет другой. Нужна поддержка XOR-ядер в инференс-движке.
- Не путать размер и ум. 13B в 1 ГБ остаётся моделью на 13B параметров по возможностям, просто легче.
Как следить и когда пробовать
Практичный порядок: прочитать статью, дождаться сжатых весов знакомой модели и сравнить на своих задачах с обычной 4-битной версией той же модели — один и тот же набор промптов, одно железо. Если разница в качестве терпима, а память и скорость заметно лучше, переносите на это мелкие задачи. Основной кодинг оставляйте там, где он уже работает.
Коротко
Samsung открыла LittleBit: 13B меньше 1 ГБ, ниже одного бита на вес, XOR вместо умножений, по заявлению авторов до 11,6 раза быстрее FP16. Для вайб-кодера это пока сигнал, а не инструмент: следим за готовыми весами и проверяем на своих задачах. Соседние темы про локальный стек — Ollama и Claude Desktop и локальный RAG.