PrismML and Google Bring Local 200B Model Inference Closer with Bonsai and TurboQuant

Локальный запуск очень больших языковых моделей перестаёт быть фантазией для энтузиастов с серверной стойкой. Два свежих подхода — 1-битные веса Bonsai от PrismML и сжатие KV-cache TurboQuant от Google Research — бьют сразу по двум самым дорогим частям инференса: памяти под модель и памяти под длинный контекст.

Как сжимают веса

PrismML открыла Bonsai 8B с лицензией Apache 2.0 — модель на базе Qwen3-8B, где почти все веса хранятся в 1-битном представлении. В практическом смысле это означает резкое падение размера: около 1.

15 ГБ против 16.38 ГБ у FP16-версии, то есть примерно в 14 раз меньше. Компания подчёркивает, что это не просто архивная упаковка файла.

Для такого формата нужны специальные kernel’ы, чтобы не разворачивать веса обратно в полный FP16 во время инференса. Схема выглядит грубо, но не примитивно: каждый вес кодируется одним битом, а на группу из 128 весов даётся общий scale в FP16. В итоге эффективная стоимость получается около 1.

125 бита на вес. По заявлениям PrismML, Bonsai 8B выдаёт до 368 токенов в секунду на RTX 4090, около 131 токена в секунду на M4 Pro и остаётся конкурентоспособной по качеству среди 8B-моделей, хотя абсолютным лидером по бенчмаркам не становится.

Как режут KV-cache Но одних лёгких весов мало.

У больших моделей быстро разрастается KV-cache — рабочая память, которая хранит представления токенов и растёт вместе с длиной контекста. Именно здесь Google Research предлагает TurboQuant. Метод сжимает KV-cache без дообучения модели и, по результатам авторов, удерживает качество даже в диапазоне около 3–3.

5 бита на канал, где обычная квантизация уже начинает явно заметно рисковать качеством ответа. Внутри подхода две ключевые идеи: сначала данные поворачиваются в более удобное пространство, где их проще сильно ужать, а затем отдельный шаг компенсирует ошибку от сжатия. За счёт этого TurboQuant решает не только вопрос размера, но и проблему накладных расходов, которые часто съедают выгоду обычной векторной квантизации.

На тестах Google метод показал как минимум шестикратное снижение памяти KV-cache и ускорение вычисления attention по сравнению с нежатым представлением.

Если объединить подходы Самая интересная часть начинается там, где эти две идеи складываются вместе.

Если 1-битный подход PrismML однажды масштабируется на модели класса 200B+, а TurboQuant сохранит свои свойства на длинном контексте, локальный запуск таких систем перестанет быть уделом серверов с сотнями гигабайт памяти. На примере Qwen3-235B-A22B оценки выглядят уже не фантастическими, а инженерно спорными, но вполне реальными. Речь пока не о готовом продукте, а о траектории развития железа и инференса.

• Веса модели в bfloat16: около 437.7 GiB Гипотетический 1-битный вариант по аналогии с Bonsai: около 30.8 GiB KV-cache для контекста 128k в 16 битах: около 23.5 GiB KV-cache с TurboQuant на 3.5 бита: около 5.1 GiB Суммарно веса и кеш: порядка 36 GiB вместо более чем 460 GiB Это пока не обещание готового домашнего 235B-ассистента. Остаются вопросы к пропускной способности памяти, качеству низкобитных kernel’ов, стабильности на реальных задачах и тому, насколько хорошо 1-битная схема переносится с 8B на существенно более крупные модели. Но траектория меняется: раньше разговор шёл о том, как ужать 7B или 14B для ноутбука, теперь уже обсуждается, можно ли подтащить к локальному железу класс 200B.

Что это значит

Рынок локальных LLM смещается от косметической оптимизации к архитектурно важным прорывам в инференсе. Если Bonsai и TurboQuant окажутся масштабируемыми, выиграют не только энтузиасты, но и компании, которым нужны приватность, низкая задержка и запуск сильных моделей без постоянной зависимости от облака. Для корпоративных команд это уже путь к локальным ассистентам нового класса на одном мощном узле, а не на отдельном кластере.