Локальная LLM: что внутри и что теряется при сжатии

Вы скачали модель, она запустилась, но отвечает как-то глупо. Или не запустилась: не хватило памяти. Или запустилась, но на ответ уходит минута. Во всех трёх случаях виноват не «плохой искусственный интеллект», а арифметика памяти и точности, которую можно посчитать заранее. Этот урок разбирает по шагам, как языковая модель помещается в домашний компьютер, что именно теряется при сжатии и как проверить, что после сжатия модель всё ещё годится для вашей задачи.

Разбор опирается на видео YouTube-канала ExtremeCode «Основные основы ИИ» (октябрь 2026 года, 1 час 36 минут): https://www.youtube.com/watch?v=KqkIMU-0aSU. Автор проходит путь от того, из чего состоит модель, до собственного теста квантованных моделей на ста задачах. Числа его измерений мы сохраняем как его результаты и указываем условия: RTX 3070 на 8 ГБ, 32 ГБ оперативной памяти, модель Qwen 3.6 35B-A3B (B — миллиард параметров) в кванте UD-IQ4_XS весом 17,7 ГБ; отдельно — тестовый стенд с несколькими видеокартами. Это не универсальные рейтинги, а измерения на одном столе.

Урок из двух частей. Первая — до запуска: из чего состоит модель, почему она упирается в память, как работает сжатие и какие архитектурные приёмы меняют цену. Вторая — запуск и проверка: контекст, llama.cpp, выбор кванта, измерение качества и тесты автора. После первой части будет пауза с коротким итогом: к ней можно вернуться через день.

Аудиоверсия

Слушать статью

1:46:18

Синтез речи, голос PuckСкорость 0,75×1×1,25×1,5×2×

Почему локальная модель упирается в память

Начнём с того, что вообще лежит на диске. Большая языковая модель, LLM, — это нейронная сеть, натренированная на больших объёмах текста предсказывать продолжение. Её задача: прочитать запрос, перевести слова в числа, сопоставить их со своей «базой знаний» и выдать статистически правдоподобный ответ. Автор подчёркивает: в этом определении нет слова «интеллект», зато есть статистика. Вся иллюзия понимания построена на вероятностях, а не на том, что модель что-то знает как человек.

Важно, что обучение и использование — разные процессы. Во время обучения модели показывают огромные объёмы текста и подправляют числа так, чтобы она лучше угадывала следующее слово. Сначала идёт предобучение на обычных текстах: модель зазубривает, как строятся последовательности. Потом — посттренировка на парах «инструкция-вывод», чтобы она научилась отвечать в формате чата. В результате получаются тренированные веса: числа, в которых зашиты связи между словами и вероятности. Модель не дообучается в ходе диалога: для обучения и для работы нужны разные объёмы вычислений.

Есть и первое ограничение: модель работает с числами, поэтому текст надо разбить на токены. Модель не работает с целыми словами. Она режет текст на небольшие куски — токены — и заменяет каждый кусок числом. Токен — это не слово и не буква, а единица, которую выбрал токенизатор: программа, которая переводит текст в последовательность чисел по заранее построенному словарю. В среднем один токен — примерно 4 символа латиницы, то есть около 0,75 обычного английского слова (часто говорят «75% слова»). Точная вместимость зависит от модели, её токенизатора и данных, на которых её учили; для русского 2–3 символа на токен — оценка, а не константа. Например, после «поздравляю тебя с днём» с вероятностью 90% идёт «рождение», но есть и менее вероятные продолжения вроде «с днём пива».

Деталь. на русском тексте в один токен обычно влезает меньше символов, чем на английском, потому что большинство токенизаторов оптимизированы под латиницу. Если вы платите за токены и каждая тысяча стоит денег, русский запрос может стоить заметно дороже английского при том же смысле.

Практическое следствие: на английском языке модели чаще выдают нужный результат, чем на русском, если их специально не учили на русском. Моделей с хорошим русским токенизатором долго было мало, и многие уже устарели; в 2026 у Qwen и Gemma словари заметно лучше, но перерасход токенов на русском в целом сохраняется. Это не приговор русскому языку, а свойство конкретных словарей.

Второе ограничение — характер работы. Традиционная LLM-модель хорошо обрабатывает человеческий текст, но плохо справляется с математикой: у неё нет абстрактного мышления, и сложный пример она не решает, а угадывает. Угадать 2 + 2 легко, а длинную цепочку вычислений — невозможно. Так же она плоха в изобретательстве: если в её данных нет понятия колеса и его физических свойств, она может только перекомбинировать уже известное. И плохо обрабатывает большие однородные Excel-таблицы: алгоритм, рассчитанный на текст, путается в цифрах, хотя в последнее время стало немного лучше. Внешние инструменты расширяют её возможности, но это отдельная тема. Общение остаётся самым удобным способом работы с такой моделью.

Зачем тогда запускать это дома? Причины простые: это бесплатно, приватность данных сохраняется, часть задач можно свалить на модель и не платить за API — интерфейс, через который программа общается с моделью. И ещё одна: чтобы понимать, какие настройки влияют на результат, а не выбирать модель по названию. Модели берут у публикаторов на Hugging Face — это аналог GitHub, только для моделей, датасетов и связанных инструментов. Можно обучить свою, можно дообучить готовую (подправить её на своих примерах), но начать проще с готовой.

Но чтобы модель запустить, нужна память для запуска; скорость разная: видеопамять быстрее, ОЗУ — запас. Чем больше памяти, тем больше модель можно позволить. Дальше разберёмся, из чего складывается эта память и почему размер модели — первое, на что смотрят.

Параметры: число, вес и скорость

Параметр — это одно тренированное число, один вес сети. Когда говорят «модель на 30 миллиардов параметров», речь о 30 миллиардах таких чисел. Отсюда три следствия, которые важно держать вместе: число параметров задаёт, сколько знаний помещается в модель, сколько места она занимает и сколько вычислений нужно на каждый токен.

Первое следствие — качество. Чем больше параметров, тем шире охват базы знаний и тем глубже модель может погружаться в тему. Автор приводит грубую шкалу: 270 миллионов параметров — уровень соседа, который вроде что-то знает и иногда связно пишет; 120 миллиардов — уровень человека, который может объяснить любые нюансы вымышленной вселенной. Шкала шуточная, но порядок величин передаёт верно.

Второе следствие — размер. Все эти числа где-то хранятся, поэтому чем больше параметров, тем больше весит файл модели. Третье — скорость: параметры не лежат мёртвым грузом, они участвуют в вычислениях. Чем их больше, тем больше математических операций на каждый токен и тем медленнее генерация.

При этом число параметров — не единственная характеристика. На результат влияют ещё архитектура модели и датасет, на котором её учили. Опытный человек по одному числу может прикинуть потенциал, но не предсказать всё.

Есть важное деление. Плотная модель, Dense-модель, использует на каждом токене все свои параметры целиком. Именно про такие модели верно утверждение «все параметры работают». У плотных моделей есть любопытное свойство: с ростом числа параметров появляются умения, которых в них специально не закладывали. В науке это называют эмерджентными свойствами: после определённого масштаба модель начинает выстраивать неочевидные логические связи, понимать сарказм или решать простые задачи, которым её не учили отдельно. Насколько это «скачок», зависит от метрики: часть навыков растёт постепенно.

Деталь. эмерджентность — не магия и не гарантия. Это наблюдение: на определённых масштабах часть навыков появляется, но предсказать, какие именно и при каком числе параметров, заранее нельзя.

Теперь память. Пока модель хранится «как с завода», на один параметр обычно приходится 16 бит — два байта. Это высокая точность, и для домашнего компьютера она слишком дорогая. Посчитаем на примере: 30 миллиардов параметров умножить на два байта — получится 60 миллиардов байт, то есть около 56 гибибайт. Автор говорит «56 ГБ»; разница в том, что гибибайт — это 1024³ байт, а десятичный гигабайт — 10⁹. Для планирования памяти важна именно двоичная величина, потому что видеопамять и операционная система показывают её.

Вывод простой: 16 бит на параметр — это много. Модель на 30 миллиардов параметров не влезет в 8 или 12 ГБ видеопамяти, даже если больше ничего не хранить. Значит, нужно либо брать модель меньше, либо хранить её числа грубее. Второй путь — квантизация: хранить те же числа с меньшей точностью. Об этом следующий раздел.

Сколько памяти съедают 16 бит

Теперь зафиксируем расчёт, чтобы дальше не путаться. Типичная заводская поставка отдаётся с высокой точностью: обычно 16 бит на параметр. Объём файла с весами ≈ число параметров × число бит на параметр / 8. Для 16 бит это два байта на параметр. Для 30 миллиардов параметров — 56 ГиБ, как в предыдущем разделе. Для 8 бит — один байт, то есть почти вдвое меньше: у реального Q8_0 (восьмибитного кванта; подробнее в разделе о квантах) 8,5 бита на вес. Для 4 бит — половина байта, то есть ещё вдвое меньше; у реального Q4-кванта 4,89 бита на вес, и он примерно втрое меньше FP16 (16 бит на вес).

Расчёт для трёх вариантов — на рис. 1.

Проверим на домашнем примере. Видеокарта на 8 ГБ не вместит 30-миллиардную модель в 16 битах: только веса займут 56 ГиБ. Даже 8-битная версия займёт 28 ГиБ, и это без кэша контекста. Контекст — текст, который модель держит в работе; под него нужен отдельный кэш, о нём дальше. Значит, на 8 ГБ реалистично смотреть на 7B (7 миллиардов параметров) в 8 битах с небольшим контекстом или на 10–12B в 4 битах. 14B в 4-битном кванте весит около 8,6 ГБ (8,0 ГиБ) только весами и уже не влезает, а 14B в Q8 — около 14,9 ГБ (13,9 ГиБ). Ещё вариант — модель с архитектурой, которая считает не все веса. И считайте не только видеопамять: вес модели + кэш + запас должны помещаться в сумму VRAM (видеопамяти) и ОЗУ, иначе нужен меньший квант.

Деталь. в расчёте не учтены служебные расходы — словарь токенов, буферы вычислений, сам контекст. Поэтому «влезает по формуле» на практике часто означает «не влезает». Оставляйте запас в гигабайт-полтора. И не смешивайте единицы: размеры файлов на Hugging Face — десятичные ГБ (10⁹ байт), а вывод llama.cpp — ГиБ (1024³ байт). 8 ГБ на ценнике — это 8 ГиБ (8192 МиБ, то есть 8,59 млрд байт); если размер файла указан в десятичных ГБ, в ГиБ он выглядит меньше. Где важно, указываем обе единицы.

Из этого расчёта появляется главный вопрос урока: что именно мы теряем, когда заменяем 16-битные числа на 8- или 4-битные? Ответ неочевиден: до определённого размера — почти ничего, а после — сразу много. Разберём, почему.

Квантование: меньше бит на параметр

Квантование, или квантизация, — это хранение весов с меньшей точностью, чтобы уменьшить размер. Идея простая: зачем хранить число с большой точностью, если модели достаточно приблизительного значения? В имени типа данных число после букв обычно означает, сколько бит уходит на одно значение: FP16 — 16 бит на вес, FP8 — 8 бит, Q4 — около 4 бит. Это правило помогает читать незнакомые названия: смотрите на цифру.

Самое наглядное сравнение: 8 бит вместо 16 — это один байт вместо двух, то есть файл почти вдвое меньше. Идеальные 4 бита вместо 16 дали бы вчетверо меньше, но у реального Q4-кванта 4,89 бита на вес, поэтому он примерно втрое меньше FP16 и примерно в 1,7 раза меньше Q8_0. Именно поэтому квантование стало народным способом запускать модели дома: оно уменьшает и файл, и память, и нагрузку на шину.

Но у точности есть цена. Автор формулирует аккуратно: до определённого размера и в определённых обстоятельствах потеря практически никак не сказывается. Погрешность в тестах — порядка пары процентов, и обычный пользователь вряд ли её увидит. При инференсе (inference), то есть при работе обученной модели, это чаще всего незаметно. Проблемы начинаются, когда модель маленькая, а сжатие агрессивное: маленькие модели тупеют заметнее, потому что у них меньше запаса. «Пара процентов» — средняя погрешность, а не гарантия: на вашей задаче она может быть и меньше, и больше, поэтому в конце урока мы будем мерить на своих задачах.

Симптомы деградации выглядят по-разному. Модель начинает отвечать поверхностно, начинает путать факты, уходит в бесконечный цикл рассуждений или частично теряет нить разговора. На простых вопросах этого не видно; чем глубже задача, тем заметнее.

У квантования есть и неожиданный плюс: сжатые до 4–8 бит модели можно запускать на обычном процессоре. Автор говорит даже про Pentium 4 и процессор из Xiaomi, но это скорее риторика: технически запустить можно, а скорость автор называет относительно неплохой; практический смысл зависит от задачи. Причина выигрыша в том, что через шину данных проходит больше значений за такт, а SIMD-инструкции упаковывают в регистры процессора больше чисел. Грубая аналогия: за час через мост может проехать 1.000 тяжёлых фур или 5.000 легковушек — груз разный, но пропускная способность моста одна.

Почему же сжатие вообще портит модель? LLM — не однородная масса чисел, а слоёный пирог из множества слоёв. У каждого слоя своя роль: ранние отвечают за грамматику и форму входа, средние — за логику и связи, поздние — за стиль и вывод. Это упрощение: роли слоёв не разделены так чисто, но порядок помогает понять, почему сжатие бьёт по-разному. Когда мы сжимаем веса, связь между слоями слабеет: ошибка одного слоя становится неточным входом для следующего. Она не остаётся локальной, а передаётся дальше и накапливается.

Первые методы квантования делали это по статичному шаблону: заранее известно, какие слои сжимать, а какие оставить в исходном формате. От сжатия защищали самое важное: словарь и эмбеддинги — таблицу, которая переводит номер токена в набор чисел (если их сжать в ноль, разные токены перестанут различаться); слои нормализации, которые почти ничего не весят, но без которых вычисления разваливаются; и главные «мыслительные» блоки. Всё остальное сжимали одинаково, не глядя на то, как конкретная модель распределяет работу. До определённых значений это работало, а попытка сжать сильнее, до 3 или 2 бит, превращала модель в полного дебила.

Что такое FP8 и почему точка плавает

Этот раздел можно пропустить при первом чтении: на запуск модели он не влияет, но объясняет термин, который часто встречается в характеристиках видеокарт. FP8 — восьмибитное число с плавающей точкой, floating point. «Плавающая» значит, что положение запятой в записи числа не фиксировано, а задаётся отдельно.

В компьютере всё хранится в нулях и единицах, а дробные числа надо как-то закодировать. Приём такой: число разбивают на две части. Мантисса хранит значащие цифры, а экспонента — положение запятой. Например, 1,23 можно записать как 123 × 10⁻²: здесь 123 — мантисса, -2 — экспонента. Меняя экспоненту, мы сдвигаем запятую и получаем то же число в другом масштабе.

В восемь бит помещается 256 кодовых комбинаций; конечных значений меньше: в E5M2 есть бесконечности и NaN, в E4M3 — только NaN. Это немного. Но разработчики сделали несколько версий формата с разным размером мантиссы и разным окном значений. Главное: эти значения распределены по числовой оси неравномерно. Больше всего их около нуля, а чем дальше, тем реже. И это удивительно удобно, потому что веса нейросети тоже сосредоточены около нуля: большинство значений маленькие, а большие встречаются редко.

На рис. 2 — разбор числа и сетка значений FP8.

Деталь. у FP8 есть варианты вроде E4M3 и E5M2: в первом больше бит отдано мантиссе (точнее значения), во втором — экспоненте (шире диапазон). Поэтому «FP8» без уточнения варианта — неполное имя.

Почему модели всё равно? Потому что при работе ей важны не точные значения весов, а правильные сигналы: положительный или отрицательный, сильный или слабый. Грубость в третьем знаке после запятой обычно не меняет, какой токен выбрать следующим.

Есть и аппаратная причина: производители свежих видеокарт встраивают работу с такими числами прямо в кремний. Отсюда ускорение, которое заметно на длинных контекстах. Именно поэтому поддержка FP8 стала маркетинговой характеристикой: она ускоряет не любую операцию, а те, что выполняются в этом формате. Новые карты вроде RTX 5090 обещают ещё больше таких ускорений, но для домашней модели это лишь приятный бонус.

FP8 — семейство 8-битных форматов, а не один формат: конкретный вариант задаёт, сколько бит уходит на экспоненту и мантиссу. Отраслевой стандарт здесь — OCP OFP8 (2023), а не IEEE 754: в IEEE 754-2019 формата FP8 нет.

Дальше — самое важное для практики: где именно заканчивается безопасное сжатие и почему маленькие модели страдают первыми.

Где сжатие начинает портить модель

Граница, которую называет автор, — восемь бит; погрешность до неё он оценивает примерно в 2%. До неё потери малы, а ниже начинаются заметные проблемы. Это не абсолютный закон, а рабочая закономерность: 8-битная модель обычно почти не отличается от исходной, 4-битная уже отличается, а 3- и 2-битная может рассыпаться.

Причина в накоплении. Каждый слой получает вход от предыдущего; если слой сжали слишком грубо, он выдаёт чуть менее точный результат, следующий слой усиливает ошибку, и к концу цепочки ответ может уйти в сторону. На коротком вопросе это незаметно, на длинном рассуждении — заметно.

Второй фактор — размер модели. Большая модель терпит сжатие лучше: у неё больше избыточных связей, и потеря части точности не разрушает картину. Маленькая модель, наоборот, сжимается впритык: у неё мало запаса, и те же четыре бита бьют сильнее. Поэтому «Q4» для 30-миллиардной модели и «Q4» для 2-миллиардной — разные по последствиям.

Деталь. автор отдельно просит практикующих физиков не пользоваться чрезмерно сжатой моделью. Это не ирония ради иронии: в задачах, где важна точность расчёта, ошибка квантования может стоить дороже, чем сэкономленная память.

Симптомы стоит знать, чтобы не списать их на «модель глупая». Даже на Pentium 4 или на процессоре из Xiaomi сжатая модель работает, и именно поэтому деградацию легко не заметить. Поверхностные ответы, путаница фактов, бесконечный цикл размышлений, частичная потеря памяти о начале разговора — всё это признаки пережатия. Если модель вдруг начинает повторять одну и ту же фразу или теряет условие задачи, первое, что стоит проверить, — не слишком ли агрессивный квант.

Сравнение двух подходов — на рис. 3.

Умные кванты: imatrix и IQ

Статичные шаблоны простые и быстрые, поэтому ими пользуются до сих пор. Но у них есть очевидный недостаток: они не смотрят на конкретную модель. Умные методы делают следующий шаг — анализируют слои и веса именно этой модели и проверяют, к чему приводит сжатие.

Первая идея — разную битность по слоям. Алгоритм пробует сжать слой сильнее, смотрит на результат и откатывается, если качество падает. Например, 14-й слой после сжатия до четырёх бит заметно тупеет — ему оставляют 6 бит. А 67-му слою четыре бита безразличны — его можно сжать сильнее. В итоге файл получается лёгким, но не таким глупым, как при одинаковом шаблоне.

Вторая идея — imatrix (importance matrix), матрица важности. Перед сжатием модель прогоняют через набор текстов и смотрят, какие конкретные веса внутри слоя сильнее всего влияют на результат. На основе этой карты строят IQ-кванты: веса распределены нелинейно, поэтому внутри одного слоя важные веса получают более выгодное положение на нелинейной шкале, менее важные — менее выгодное. Это даёт лучшее качество при том же размере, но распаковка такого файла сложнее: на мощном компьютере разница в скорости почти незаметна, на слабом железе — заметна.

IQ4_XS — 4-битный квант с нелинейной шкалой и imatrix: 4,46 бита на вес в среднем, с учётом служебных шкал. Сами веса в нём 4-битные. «Разная точность» здесь означает не разные биты, а нелинейное расположение уровней: около нуля их гуще, и это лучше описывает веса. Файл IQ4_XS меньше обычного Q4-кванта (4,89 бита на вес), а не больше. Двух- и трёхбитные веса бывают в IQ2 и IQ3, но не в IQ4_XS.

Деталь. автор предупреждает, что по имени кванта нельзя предсказать производительность. Публикатор может заявлять один алгоритм, но использовать его не в чистом виде; одна и та же модель в разных клиентах может выдавать разные результаты. Сложный алгоритм не обязательно медленнее: он может лучше утилизировать железо. Поэтому заранее предсказать производительность нельзя. Проверять надо на своём стенде.

Третье направление — QAT, quantization-aware training. Модель учат сразу с учётом будущего сжатия, моделируя потери связей между слоями. Это не посмертная обработка готовой модели, а часть обучения, поэтому результат обычно лучше. И четвёртое, совсем экспериментальное: пытаться упаковать веса вплоть до полутора бит, используя три значения — −1, 1 и 0. Точнее говорить «около полутора бит в среднем»: сами значения трёхуровневые, но со служебными шкалами файл занимает больше. Это уже не «сжатие файла», а другой способ представления, и он пока не стал народным. Вероятно, в обозримом будущем ситуация изменится.

Прежде чем перейти к архитектуре, нужно понять, в каком виде всё это хранится. Потому что «модель» на диске — не папка с миллионом файлов, а один контейнер.

GGUF: один файл вместо папки

GGUF — формат файла, в котором лежат и сжатые веса, и метаданные: архитектура, число слоёв, размер контекста, параметры токенизатора, версия квантования. Это не просто архив, а умный контейнер: открыв файл, клиент сразу знает, как его загружать, и не требует отдельных настроек.

Именно этот формат популяризировал локальный запуск: файл можно скачать, положить в папку и открыть одной командой. Его придумали в проекте llama.cpp, и он стал общим для большинства домашних клиентов.

Исправлено. в источнике «GGML, он же Гуф». Точнее: GGML — библиотека для вычислений на CPU и GPU, а GGUF — формат файлов моделей, который пришёл на смену GGML/GGMF/GGJT. Источник: спецификация GGUF в репозитории ggml.

У GGUF есть и практические детали, которые пригодятся дальше. Имя файла часто включает префиксы: mmproj- для мультимодального проектора и mtp- для головки предсказания нескольких токенов. Метаданные можно посмотреть перед запуском: там видно, сколько слоёв, какой контекст заявлен и как именно сжаты отдельные слои. Формат допускает отображение файла в память (mmap), поэтому модель не обязана сразу копироваться в ОЗУ целиком.

С форматом разобрались. Теперь — как уменьшить модель, не сжимая веса: её можно научить меньшему или заставить считать не всё.

Дистилляция, прунинг и дообучение

Есть три способа уменьшить модель, не трогая точность хранения: научить маленькую модель у большой, вырезать лишние веса или дообучить существующую под свою задачу. Они решают разные задачи, и путать их не стоит.

Дистилляция — это когда берут большую обученную модель и на её ответах учат маленькую. Маленькая старается отвечать так же, как большая, но у неё меньше параметров, поэтому её можно запустить на слабом железе. Такие модели называют Distilled. Схема типовая: сначала обучают крупную модель на 100 млрд параметров, потом с неё дистиллируют компактные версии.

Прунинг, Pruning, — более радикальный путь: из плотной модели напрямую вырезают наименее задействованные веса. Экономия может быть около 20%, но модель легко «лоботомировать»: после зачистки её обычно приходится дообучать, иначе качество падает слишком сильно. Поэтому прунинг применяют для узких, специфичных задач, а не как общий способ сжать всё подряд.

Дообучение, Fine-tuning, не уменьшает модель, а меняет её поведение: добавляет новую область знаний, углубляет существующую или задаёт тон и стиль ответов. Честное дообучение, при котором меняются сами веса, автор оценивает в 100–500 раз дороже инференса; универсального коэффициента нет, но дома это редко по карману. Существуют хаки, которые делают процесс дешевле, но это отдельная тема. Важно другое: если нужно просто дать модели новые факты, можно обойтись без дообучения — их можно положить в контекст. Часто дистилляцию и дообучение применяют вместе: сначала большую модель дообучают под задачу, потом дистиллируют в маленькую.

MoE: много параметров, мало работы

Дистилляция и прунинг уменьшают число параметров; дообучение — нет. MoE, mixture of experts, делает наоборот: оставляет все параметры, но на каждом токене использует только часть. Идея простая: зачем резать веса, если можно научить модель их игнорировать?

В MoE-слое вместо одного большого блока стоят несколько экспертов — маленьких подсетей. Рядом работает маршрутизатор, или роутер: небольшая сеть, которая на каждом токене решает, каких экспертов включить, а каких пропустить. Число параметров остаётся исходным, поэтому база знаний может быть такой же, как у плотной модели того же размера. А число активных параметров меньше, поэтому вычислений на токен меньше и инференс быстрее.

Например, модель на 30 млрд параметров с 3 млрд активных даёт скорость ближе к 3B, чем к 30B, но знания — как у большой модели. Ровно как 3B она не работает: роутинг и память тоже стоят времени. Звучит как бесплатный обед, но бесплатных обедов не бывает. MoE всё так же много весит: все параметры нужно загрузить в память, и большинство из них при работе будут лежать мёртвым грузом. Качество тоже может пострадать, потому что за выбор экспертов отвечает роутер, а суммарно активных параметров меньше, чем у аналогичной плотной модели. Наличие кучи параметров не делает MoE автоматически такой же умной.

Зато MoE отлично подходит для случая, когда мало видеопамяти, но много обычной оперативки. Клиент держит важные части и активных экспертов в видеопамяти, а спящие экспертные блоки оставляет в ОЗУ. Формально часть расчётов уходит на процессор, и это медленно, но активных параметров мало, поэтому даже слабая машина справляется. Желательно, чтобы оперативка была быстрой, вроде DDR5, — но это уже роскошь, а не условие.

На рис. 4 — активные эксперты в видеопамяти, спящие в ОЗУ.

Деталь. у MoE есть отдельное семейство оптимизаций — прунинг экспертов. Смотрят, какие эксперты почти не используются, и срезают их, затачивая модель под конкретный сценарий, чаще всего под кодинг. В источнике этот метод назван «RIP-модели»; по описанию это REAP-модели (Router-weighted Expert Activation Pruning), прунинг экспертов MoE. Название в расшифровке ненадёжно.

Спекулятивное декодирование и MTP

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

Спекулятивное декодирование пытается угадать несколько слов вперёд. Черновая модель или дополнительная головка предлагает 2, 3 или даже 4 токена, а основная модель проверяет их за один проход и принимает те, что совпали с её собственным распределением. Если угадали — получаем несколько токенов за шаг; если нет — лишние отбрасываются, и мы ничего не теряем, кроме небольшой работы.

MTP, multi-token prediction, — частный случай: в модель добавляют головку, которая предсказывает несколько следующих токенов. По заявлениям, на которые ссылается автор, ускорение может составлять в 2–3 раза (на 100–200%). Это не измерение автора, а чужие обещания, и они зависят от сценария: на предсказуемом тексте черновик попадает чаще, на творческом — реже.

Минус тоже есть: дополнительные мини-сети занимают память. Поэтому MTP — не бесплатное ускорение, а размен: немного памяти на заметно больше токенов в секунду, если ваш текст достаточно предсказуем. В llama.cpp оно включается отдельными флагами, а MTP-головка может лежать отдельным GGUF с префиксом mtp- или быть встроенной; публикатор пишет в README, как её активировать.

Ризонинг, картинки и речь

Современная модель — это не только «угадайка следующего слова». У неё могут быть дополнительные возможности, которые сильно меняют опыт.

Ризонинг, reasoning, — цепочка рассуждений перед ответом. Вместо того чтобы сразу выдать вероятное продолжение, модель строит рассуждение, рассматривает проблему с разных сторон и только потом отвечает. На части сложных задач качество заметно растёт, и главное — можно меньше стараться над промтом — текстом запроса: модель сама додумает шаги. Цена — время: думалка увеличивает время ожидания и расход вычислений. У гибридных моделей её можно выключить, но не у всех; для некоторых задач это правильно: когда нужна короткая выжимка из большого текста или поверхностный перевод, размышления только мешают. У моделей без встроенного ризонинга есть внешние костыли — промпт «думай по шагам», но это не то же самое, что обученная думалка.

Вторая возможность — мультимодальность: модель работает не только с текстом, но и с изображениями и звуком. Vision позволяет читать картинку: не просто детектировать собаку, как десять лет назад с OpenCV, а разбирать объекты, текст и композицию. Можно закинуть макет сайта и попросить собрать разметку с отступами и цветами. Speech-to-text переводит голос в текст, так что голосовое сообщение можно «нашептать» модели, и она ответит.

За всё это платят памятью. Для мультимодальных возможностей приходится наращивать эмбеддинги — представления входов, — и каждая дополнительная возможность требует своей памяти. При этом Vision и speech-to-text могут работать и в малопараметровых моделях, то есть их можно включить даже на домашнем железе. Но если память уже занята весами, добавка может стать последней каплей.

Пауза: что уже известно

Мы разобрали первую часть. Модель — это числа-веса; память под них считается как параметры × биты / 8, и 16 бит на вес дома не поднимаются. Сжатие уменьшает файл, но ниже 8 бит качество падает, а ниже 4 модель может рассыпаться. Умные кванты распределяют биты по слоям и уровни по весам неравномерно, GGUF упаковывает веса и метаданные в один файл, а архитектура меняет цену: MoE считает не все параметры, дистилляция уменьшает их число, спекулятивное декодирование ускоряет генерацию.

Дальше — вторая часть: контекст, запуск и проверка. Если хотите сделать перерыв, это хорошее место.

Контекстное окно и attention

До сих пор мы говорили о памяти под веса. Но чтобы модель работала, ей нужна ещё одна вещь — контекстное окно. Контекст — это количество информации, которое модель удерживает и обрабатывает в рамках одного разговора, и измеряется оно в токенах.

Размер контекста мы задаём сами, но не больше, чем позволяет модель. Выбор зависит от задачи и от железа: длинный контекст нужен для большого документа, но он дороже по памяти и времени. В этом и главный компромисс.

Зачем модели контекст? Потому что она должна понимать связи между словами. Этим занимается attention, внимание модели: алгоритм, который для каждого слова смотрит на все слова в контексте, сильнее всего — на близкие, и определяет, в каком значении оно использовано. Пример: «беру лук и стрелы» и «режу лук» — слово одно, а смысл разный. Внимание навешивает на слово невидимый ярлык в зависимости от соседей; технически это перемножение матриц.

Проблема в том, что attention умный, но медленный. При генерации модель выдаёт текст по одному токену, и чтобы родить следующий токен, ей нужно знать связи между всеми предыдущими. Наивный путь — пересчитать всю историю заново на каждом слове. На трёхтысячном токене компьютер бы просто закипел. Поэтому длинный контекст — не бесплатное улучшение: даже 262 тысячи токенов не значит, что их стоит скармливать каждой задаче.

Решение нашлось в виде промежуточной памяти. Она хранит не токены, а матрицы ключей и значений, которые нужны для расчёта внимания, и позволяет не пересчитывать историю с нуля. Об этом — следующий раздел.

KV-кэш: второй пожиратель видеопамяти

KV-кэш (KV cache) — это промежуточная память, блокнот, в который складываются ключи и значения для каждого уже прочитанного токена. Когда модель генерирует новый токен, она добавляет в блокнот новую строку и использует старые, чтобы посчитать внимание. Именно поэтому генерация ускоряется и не требует пересчёта всей истории: большая часть работы уже сделана.

Важное уточнение, которое автор подчёркивает: в кэше лежат не токены, как многие думают, а многомерные матрицы ключей и значений. Токен — это номер; матрицы — это числа, с которыми работают слои.

Размер кэша зависит от трёх вещей. Первая — размер контекстного окна: чем больше токенов мы держим, тем больше строк в блокноте. Вторая — тип данных: по умолчанию ключи и значения хранятся в 16 битах, но их можно сжать. Третья — число слоёв и их тип: у обычной модели с полным вниманием (full-attention) кэш есть на каждом слое; у гибридной слои разные, и кэш считается по-разному.

Это важно для моделей из практики. У Qwen 3.6 35B-A3B 40 слоёв, но полных attention среди них только 10; остальные 30 — линейные слои, которым KV-кэш не нужен. У Gemma 4 E4B 42 слоя: 7 глобальных, которые видят весь контекст, и 35 скользящих с локальным окном 512 токенов; последние 18 слоёв переиспользуют K/V предыдущих слоёв того же типа, поэтому кэш меньше. «Только full-attention» — не общее правило для всех гибридов: у каждой модели своя схема.

Формула со всеми слоями — верхняя оценка; ниже считаем только full-attention слои Qwen. У Qwen 3.6 35B-A3B 10 слоёв полного внимания, 2 KV-головы (grouped-query attention: ключи и значения общие для групп голов), размер головы 256. На 32 768 токенов в FP16 это 2 (ключи и значения) × 10 слоёв × 2 KV-головы × 256 × 2 байта × 32 768 ≈ 0,67 десятичного ГБ (0,63 ГиБ). В q8_0 — около 0,34–0,36 ГБ (0,33 ГиБ), экономия ≈0,3 ГБ, то есть те самые 300 МБ, которые называет автор. Формула со всеми 40 слоями при тех же 2 KV-головах завысила бы результат в 4 раза, потому что 40 / 10 = 4.

На рис. 5 — обычная модель и два гибрида рядом.

Теперь посмотрим, что происходит при чтении промпта. Этот этап называется prefill, или prompt processing: модель прогоняет весь входной текст за один проход и строит матрицу внимания. Для 1000 токенов это матрица размером в миллион элементов — 1000 × 1000 на одну голову внимания. На десятках и сотнях тысяч токенов временные данные разрастаются до гигабайт, и гонять их туда-сюда из видеопамяти в чип медленно. Именно здесь понадобится приём, который разберём дальше.

Flash Attention и PagedAttention

Flash Attention — приём, который ускоряет расчёт внимания, не меняя его результата. Большую промежуточную матрицу внимания режут на маленькие плитки и по очереди загоняют в сверхбыструю память на кристалле видеопроцессора — SRAM. Там плитка мгновенно считается, и гигантские временные данные не записываются в обычную видеопамять. Это не приближение: ответ остаётся точным, меняется только порядок вычислений и работа с памятью.

Практический вывод автора: без современной видеокарты Flash Attention либо не включится, либо будет работать медленно. Это зависит от поддержки в бэкенде и драйвере и от размера SRAM: на старых картах плитки не помещаются или поддержки нет.

Полезно сразу разделить два этапа по стоимости. Prefill, который читает промпт, в обычной модели с полным вниманием считает попарные связи всех токенов и растёт примерно квадратично с длиной: удвоили промпт — вчетверо больше работы. У гибридной модели часть слоёв линейная, поэтому это оценка сверху. Генерация с готовым кэшем добавляет по одному токену: время на каждый следующий токен растёт линейно, а суммарное время на N токенов — квадратично. Поэтому «контекст замедляет» — верно, но скорость падает по-разному на чтении и на письме.

Главный минус кэша — память. KV-кэш — второй по величине пожиратель видеопамяти после самой модели. Чем больше контекст, тем больше он занимает. И хранить его важно именно в видеопамяти: тогда Flash Attention может ускорить чтение контекста. Правда, сам KV-кэш Flash Attention не сокращает: он экономит память под промежуточные данные, но не под кэш.

Второй минус — время. Чем больше контекст, тем медленнее обработка и генерация. Частичное решение — сжимать сам кэш, как сжимают веса. Но за это платим качеством: кэш в 4 битах может сделать модель тупее. Отключить кэш целиком нельзя: без него вычисления становятся квадратичными и всё встаёт.

Третья проблема — как выделять память под кэш. Если резервировать максимум под каждого пользователя, память тратится впустую: не всегда контекст заполняется целиком. PagedAttention решает это страницами, но сам расчёт не ускоряет. Свободная видеопамять режется на блоки, в каждый влезает, например, 16 токенов. Пришёл промпт на сотню токенов — выделяется ровно семь страниц кэша. Модель сгенерировала ещё 16 токенов — добавляется ещё одна страница, и так далее.

Экономия двойная. Во-первых, память выделяется по мере роста, а не авансом. Во-вторых, несколько пользователей могут делить один и тот же кусок кэша: если системный промпт на 4.000 токенов используется пятью клиентами, без PagedAttention он загрузился бы пять раз, а с ним — один.

Деталь. PagedAttention придуман для серверов с десятками одновременных запросов; число «20–30 пользователей» — не из статьи. Дома он тоже полезен, но там обычно один пользователь и один длинный контекст, поэтому выигрыш скромнее.

На рис. 6 — оба приёма рядом: плитки и страницы.

Lost in the Middle: почему длинный контекст не спасает

Даже с быстрым вниманием и экономным кэшем остаётся проблема. Многие модели хорошо читают начало и конец контекста, но могут наглухо игнорировать факты из середины. Это называют Lost in the Middle.

Причины — гипотезы. Первая — статистика обучающих текстов: в интернете большинство материалов построено по схеме «во введении тема, в середине вода, в конце выводы». Модель привыкает, что главное лежит на краях. Вторая, более важная — сам attention: сила связи между токенами на больших расстояниях ослабевает. Чем длиннее контекст, тем заметнее эффект. Исследование показывает U-образную кривую, но не доказывает эти механизмы.

Бытовой пример: вы кладёте в начало инструкцию «отвечай только на русском», в конец — вопрос, а нужный факт прячете в середине длинного документа. Модель может ответить по краям и пропустить факт, хотя формально «видела» его.

Отсюда практический вывод: пихать максимальный контекст не всегда лучшая идея. Особенно с локальными моделями, где память и скорость и так ограничены. Универсального решения нет; автор честно говорит, что проблема останется.

Деталь. существуют и другие архитектуры без attention — State Space Models (SSM) и рекуррентные варианты, — но автор сознательно их не разбирает: это отдельная большая тема. В этом уроке их тоже нет.

Теперь, когда понятна цена памяти и контекста, можно перейти к софту: чем всё это запускают.

Клиенты: llama.cpp против Ollama и LM Studio

Клиентов для локального запуска много, и автор делит их на три категории. Первая — «нормальные», и там всего один кандидат: llama.cpp. Вторая — клиенты с красивым интерфейсом вроде Ollama и LM Studio. Третья — продакшен-движки для серверов.

llama.cpp — выбор автора для дома. У него полная гибкость настроек: можно крутить параметры почти на любом железе, а разработчики постоянно добавляют оптимизации. Именно в llama.cpp придумали GGUF. Клиент сам оценивает железо и модель и рассчитывает, сколько слоёв влезет в видеопамять, какой контекст поднять и сколько оставить под кэш. Минус — высокий порог входа: работа в терминале и десятки аргументов, которые надо понимать. Но если теория уже разобрана, остаётся потыкать их на практике.

Ollama и LM Studio ориентированы на удобство, а не на сам инференс. По мнению автора, обёртки обычно работают медленнее llama.cpp: они тратят силы на user experience, добавляют слой и реже получают свежие оптимизации. Измерений автор не приводит; при этом часто используют llama.cpp как бэкенд — движок, который считает модель. Отсюда вопрос автора: если внутри всё та же llama.cpp, зачем лишняя прокладка? Свежие обновления быстрее появляются в оригинале, а не в обёртке. Кроме того, есть десятки, если не сотни интерфейсов, которые не тянут за собой движок и подключаются к API.

Деталь. это мнение автора, а не измерение. Ollama удобна для первого запуска и для тех, кто не хочет разбираться в аргументах. Если ваша цель — «просто работает», обёртка может быть разумным выбором.

Продакшен-движки и нативные форматы GPU

Третья категория — серьёзный софт для серверов: параллельные сессии, много одновременных клиентов, автоматическое распределение памяти. Его можно поставить и дома, но порог входа выше: на Windows понадобятся Docker и WSL (подсистема Linux в Windows), проброс GPU в контейнер и возня с конфигами.

У продакшен-движков есть техническое преимущество. Они работают с нативными форматами GPU: у Nvidia это FP8 и NVFP4. В таком режиме чип выполняет матричные операции без промежуточного деквантования, что даёт заметный выигрыш на длинных контекстах. llama.cpp тоже использует тензорные ядра — блоки GPU для матричных операций — но через унифицированные типы, потому что должен работать и на GPU, и на CPU. Поэтому на самых быстрых режимах он пока отстаёт.

У Nvidia 8-битный формат называется FP8, а 4-битный — NVFP4; «NVFP8» в расшифровке — неточное имя.

Автор добавляет, что поддержку NVFP в llama.cpp уже добавили, но моделей в этом формате от проверенных дилеров он пока не видел. Это быстро меняющаяся область: к моменту чтения ситуация может быть другой.

Установка llama.cpp и первый запуск

На странице релизов llama.cpp лежат готовые сборки. Для Nvidia берите архив с cuda в имени и отдельный архив cudart-... — это CUDA runtime; какую версию брать, подскажет nvidia-smi: он покажет драйвер и поддерживаемую версию CUDA. Для AMD нужен архив с vulkan или путь через ROCm: Vulkan — универсальный графический API, ROCm — стек AMD для вычислений; Vulkan проще поставить, ROCm может дать больше скорости. На macOS проще Homebrew (менеджер пакетов).

Дальше — две команды. llama serve -m model.gguf поднимает веб-интерфейс и OpenAI-совместимый API; llama cli -m model.gguf работает в терминале. В старых сборках те же режимы называются llama-server -m model.gguf и llama-cli -m model.gguf. Вместо model.gguf подставьте имя скачанного файла из списка квантов.

На Windows запускайте PowerShell или встроенный терминал, на Linux — любой привычный.

Сборку лучше положить в надёжную папку и добавить её в PATH, чтобы клиент запускался из любого терминала. Если не знаете, что такое PATH, просто распакуйте архив и запускайте команду из этой папки. Аргументы, влияющие на инференс, одинаковые в обоих режимах.

Автоподбор: fit и fit target

По умолчанию llama.cpp стартует с включённым fit. Клиент смотрит, какое у вас железо, сравнивает с требованиями модели и сам решает, сколько слоёв выгрузить в видеопамять, какой контекст поднять и как распределить остальное между GPU и CPU. Для первого запуска этого достаточно.

У fit есть настройка fit target. По умолчанию она равна 1024 МиБ: клиент намеренно оставляет нетронутым примерно 1 ГБ видеопамяти, чтобы система не начала задыхаться. Если хотите, чтобы llama.cpp заняла больше, уменьшите запас; значение задаётся в МиБ.

Деталь. запас нужен не из вежливости. Видеопамять делят драйвер, браузер и другие приложения; если занять её под ноль, система может начать сбрасывать память на диск и всё замедлится.

После недавнего обновления логи стали короче, и параметры запуска не видны. Вернуть их можно флагом -lv 4 — это уровень подробности логов. В логе видно, сколько слоёв ушло в GPU, сколько они заняли и какой контекст выбрал fit.

В примере автора на карте с 16 ГБ (модель в источнике не названа) в GPU ушли все 33 слоя, веса заняли почти 5 ГБ, а fit выбрал максимальный контекст, который разрешает модель, — 262 тысячи токенов. Кэш на такой контекст занял 8 ГБ в FP16. Flash Attention при этом включился автоматически. На 8 ГБ fit выберет контекст заметно меньше — иначе модель не поместится.

Как читать страницу модели на Hugging Face

Локально доступны только модели с открытыми весами, Open Weight: файлы, которые публикатор выложил для скачивания. Список реально хороших моделей не такой большой, и автор советует начать с нескольких проверенных дилеров квантов — публикаторов GGUF-файлов, а не со случайных ссылок.

На странице модели смотрят три вещи: название и версию, число параметров и формат GGUF. Если формат GGUF есть, модель можно запустить в llama.cpp; внутри страницы обычно лежит целая куча переквантованных версий с разной битностью. Это удобно: не нужно квантовать самому.

Разберём имя на примере Gemma 4. «Gemma» — семейство, 4 — версия, 12 миллиардов параметров — размер. Приписка IT означает instruction tuned: модель уже натренирована отвечать в формате чата. Не все публикаторы её указывают, иногда предполагая, что модель и так чатовая. Приписка A3B означает active 3B: например, у Qwen 3.6 35B-A3B (в предыдущей версии — Qwen 3.5 35B-A3B) всего 35 млрд параметров, но на каждом токене работают около 3 млрд. Приписка A3B указывает на MoE. Но её отсутствие не гарантирует плотную модель: часть публикаторов не указывает активные параметры, поэтому смотрите README или конфиг. Gemma 4 12B в примере — плотная dense-модель: все 12 млрд параметров задействованы.

В README лежит паспорт модели: чем хороша, какие технические ограничения, какой максимальный размер контекстного окна, как она выглядит на заявленных бенчмарках. Это стоит прочитать до скачивания: иногда модель отлично решает задачи одного типа и плохо — другого. Но README пишет публикатор, а не независимый тест: заявленные бенчмарки можно накрутить, об этом ниже.

Расшифровка имён квантов

Самое интересное — список файлов модели. Сначала он пугает, но запомнить стоит три правила: Q и цифра — сколько бит на основные веса; K — важные тензоры (массивы чисел) получают больше бит; IQ — нелинейная шкала и imatrix. Остальные буквы — размер и происхождение.

Первая буква Q и цифра означают, во сколько бит заквантованы основные веса. Q4_0, Q4_1, Q8_0 — старый тип квантизации по статичным шаблонам: все основные 2D-веса (основные матрицы) квантуются равномерно, а нормы и служебные тензоры остаются в FP16 или FP32 (32 бита на вес). Q8_0 — не исходник и не «просто более качественная версия»: в нём 8,5 бита на вес, файл почти вдвое меньше FP16, но потери всё равно есть. Идеальный эталон — FP16, а Q8 годится как практический эталон, когда FP16 не влезает. Все заметные проблемы начинаются при квантовании меньше восьми бит, а Q4_K_M меньше Q8_0 примерно в 1,7 раза, не ровно вдвое.

Дальше идут комбинированные K-кванты: Q4_K_M, Q3_K_M. Цифра по-прежнему задаёт битность основных весов, а K означает K-кванты: алгоритм смотрит на слои и выделяет важным участкам чуть больше бит, а менее важные сжимает сильнее. Вместо M можно встретить S или L — это размер: S экономит сильнее, L оставляет больше бит важным слоям, M — середина. Чем больше размер (S → M → L), тем больше файл и тем меньше потерь, в теории.

Теперь IQ-кванты. IQ4_XS — 4-битный нелинейный квант на основе imatrix; подробности — в разделе «Умные кванты». XS значит extra small: режим экономии, но не за счёт перехода на 2–3 бита — такие веса бывают в IQ2 и IQ3.

Отдельно стоит линейка UD — Unsloth Dynamic, например UD-Q4_K_XL. Публикатор комбинирует разные приёмы (в расшифровке UDQ4KL) и обещает лучшее качество при том же весе, чем у статического кванта. Проверять это надо на своих задачах: смесь внутри файла может быть разной, и по имени нельзя сказать, что именно сжато.

Метаданные кванта показывают раскладку по слоям. Иногда в UD Q3 внутри обнаруживаются IQ-кванты, хотя в имени о них не сказано. Также стоит проверить, поддерживает ли семейство спекулятивное декодирование: это почти бесплатное ускорение. Для Q4_K_M видно, что нормы и служебные тензоры оставлены в FP32 (это не целые слои), основные веса сжаты до четырёх бит, а отдельным тензорам выделено 6 бит. Это и есть та самая разная битность: «Q4» — не четыре бита абсолютно везде.

Публикаторы не всегда пишут «MoE» явно: иногда достаточно посмотреть на A3B в имени.

Ещё две вещи, которые легко пропустить. Первая — MTP: если у семейства есть головка предсказания нескольких токенов, её можно включить, скачав дополнительный GGUF; например, на GLM-4 (в расшифровке «GML4» — неясно, GLM-4 или Gemma 4); иногда она уже встроена, как у Qwen 3.5, и тогда нужны другие параметры запуска; публикатор пишет об этом в README. Вторая — мультимодальность: для чтения картинок нужен отдельный файл mmproj — проектор для картинок, он же Vision-модуль, которого нет в списке квантов; он лежит в списке файлов репозитория.

Практика: RTX 3070 и Qwen 3.6 35B

Теперь соберём всё вместе на конкретном стенде. Видеокарта RTX 3070 на 8 ГБ, 32 ГБ оперативной памяти, модель Qwen 3.6 35B-A3B в 4-битном кванте UD-IQ4_XS весом 17,7 ГБ. Модель MoE, поэтому активных параметров меньше, чем всего.

Деталь. точный размер зависит от кванта. У этой модели UD-Q4_K_M весит 22,1 ГБ, UD-IQ4_XS — 17,7 ГБ, UD-Q3_K_XL — 16,9 ГБ. В примере второй: у UD-IQ4_XS средняя битность ниже, около 4,0, поэтому файл 17,7 ГБ, а 4,46 — у обычного IQ4_XS.

В метаданных видно, что у модели 40 слоёв. Логичный первый шаг: половину слоёв отправить в видеопамять, половину оставить на CPU. Число слоёв, которые уходят в GPU, задаёт -ngl (--n-gpu-layers). Он работает и для плотной модели: часть слоёв можно оставить в ОЗУ, это медленнее, но позволяет запустить 12B в Q8 на 8 ГБ. На контексте 32 тысячи токенов автор получил четыре токена в секунду — феноменально медленно.

Причина в том, что в видеопамять ушли не только нужные веса. У MoE много экспертов, и если грузить слои целиком, часть экспертов занимает память, но не используется. Нужно заставить клиента держать в GPU только активных экспертов, а остальных — в ОЗУ. Для этого есть аргумент --n-cpu-moe: он оставляет на CPU экспертов первых N слоёв.

Исправлено. в источнике «NC MOE — число экспертов, которые должны оставаться в оперативной памяти». Точнее: --n-cpu-moe N оставляет на CPU экспертов первых N слоёв модели, а не N отдельных экспертов. Источник: README llama.cpp, общие параметры.

С этим аргументом автор получил 32,5 токена в секунду. Оптимальное значение он подбирал через llama-bench, потому что универсальной формулы нет. Логика размена простая: увеличиваете N — больше экспертов остаётся в ОЗУ, память видеокарты свободнее, но скорость чуть падает; уменьшаете — больше экспертов в GPU, быстрее, но память кончается. Методом тыка он докрутил N до 28.

Деталь. в расшифровке после этого стоит «307 токенов в секунду»; это ошибка распознавания, в выводах не используется.

Дальше — память операционной системы. Windows и llama.cpp постоянно пытаются оптимизировать ОЗУ, кэшируя часть данных на SSD. Чтобы этого не было, используют --load-mode none: файл модели читается в память, а не отображается в неё, и система меньше двигает страницы. В старых сборках у этого режима было другое имя; историческое название — в приложении. С ним автор получил 38,5 токена в секунду.

Следующий шаг — квантование самого кэша. Аргументы -ctk и -ctv задают тип ключей и значений. Автор не рекомендует опускаться ниже восьми бит: дальнейшее сжатие уже влияет на «мозг» модели. Даже с восьмибитными типами освобождается около 300 МБ видеопамяти, а этого хватает, чтобы нарастить контекст. Инференс после квантизации кэша чуть замедлился: часть вычислений уходит на деквантизацию.

Ещё два аргумента — batch и ubatch. Первый задаёт логический максимум токенов на один вызов обработки промпта, второй — физический размер микропакета, который реально уходит на вычисление за раз. Большие значения ускоряют prefill на длинном промпте, потому что железо эффективнее загружено; меньшие экономят пиковую память, но на длинном промпте prefill тормозит. На коротких контекстах разница почти незаметна, поэтому на потребительском железе это не главная точка оптимизации.

Итого у автора пять ключевых параметров, которые реально влияют на опыт: -ngl, --n-cpu-moe, --load-mode none, типы KV-кэша и batch/ubatch. Плюс спекулятивное декодирование, если модель его поддерживает.

Что меняется от шага к шагу — на рис. 7.

Температура и top-p

До сих пор мы оптимизировали память и скорость. Но у модели есть параметры, которые меняют не скорость, а поведение. Главный — температура.

Температура управляет случайностью выбора. В llama.cpp по умолчанию 0,8; в OpenAI-совместимых API часто 1,0. Увеличивая её, вы разрешаете модели выбирать менее вероятные слова: ответы становятся разнообразнее, иногда во вред. Выкрутив в ноль, вы получаете почти одинаковые ответы на один и тот же запрос: модель всегда выбирает самый вероятный вариант, случайность минимальна.

Деталь. «почти одинаковые» — не «побитово одинаковые». На GPU с батчингом порядок вычислений меняется, и даже при нулевой температуре ответы могут чуть отличаться. Автор говорит об этом же: минимальная погрешность, а не абсолютный детерминизм.

Второй параметр — top-p. Он работает в паре с температурой и ограничивает пул слов, из которых модель выбирает. Значение 0,1 — это 10% вероятностной массы: слова берутся по убыванию вероятности, пока их сумма не дойдёт до 10%. Это может быть одно-два слова, а не 10% словаря. Значение 1 разрешает все слова, даже странные для контекста. Чем ниже top-p, тем предсказуемее ответ; чем выше — тем больше свободы.

Есть ещё top-k: он задаёт, сколько самых вероятных слов вообще рассматривать. В тестах автора top-p и top-k оставлены по умолчанию, чтобы сравнивать модели в одинаковых условиях.

На рис. 8 — как набирается эта масса.

Исправлено. в источнике top-p 0,1 описан как «10% самых подходящих слов». Точнее это 10% вероятностной массы, а не доля словаря.

Эти два параметра не спасают от плохого качества модели, но помогают не путать «модель глупая» с «модель слишком креативная». Если ответы скачут, сначала проверьте температуру и top-p, а потом уже квант.

Теперь у нас есть всё, чтобы запустить модель и покрутить параметры. Остаётся главный вопрос: как понять, что после сжатия от модели осталось.

Перплексия: сколько модель удивилась

Мы подошли к главному практическому вопросу: как измерить, что осталось от модели после сжатия. Универсального способа нет, и автор называет это главной проблемой сферы. Но есть инструменты, которые дают полезную отправную точку.

Сначала — важное правило сравнения. Сравнивать квантованные модели между собой некорректно: так мы узнаем только, «насколько тупой тупее тупого». Нужна исходная модель без квантизации, с которой сравнивают каждую сжатую версию. Чем больше бит у эталона, тем точнее результат, поэтому идеально держать исходник в 16 битах; на практике автора эталон — Q8, потому что FP16 не влезает. Возьмём для примера Qwen 3.5 9B и сравним все доступные четырёхбитные версии. Qwen 3.5 9B в 4 битах: только веса — около 5,5 ГБ; с контекстом и буферами ближе к 8 ГБ, как в оценке автора. Для сравнения нужен Q8-эталон почти на 10 ГБ, поэтому тест шёл на карте побольше.

Первый инструмент — llama-perplexity. В его основе лежит «фактор удивления» модели. Модель не думает, она выдаёт следующее слово по вероятностям. Если она уверена в слове на 99%, слово выходит чётко. Если уверенность была 10%, а слово всё равно оказалось правильным, внутренний счётчик удивления растёт. Перплексия — это средняя неожиданность на правильном тексте. «Расхождение перплексии» в этом уроке — относительный рост перплексии кванта к Q8-эталону в процентах; меньше — лучше. Даже пара процентов роста может приводить к накоплению ошибок на длинной последовательности: чем выше число, тем выше шанс, что модель выдаст дичь.

Механика теста такая. Берут несжатый эталон, прогоняют его по корпусу текста и сохраняют логиты — оценки вероятностей всех токенов до выбора. Потом те же тексты прогоняют через каждый квант и сравнивают распределения с эталоном. Файл логитов получается огромным: у автора он вышел в 72 ГБ. Зато последующие прогоны идут кратно быстрее.

Для перплексии в llama.cpp есть готовый корпус WikiText-2; в расшифровке он назван «WikiTest-1» — вероятно, это WikiText-2.

Кроме корреляции перплексии, важны KL-дивергенция и Δp — разница вероятностей, а не параметр top-p. Автор оставляет их на самостоятельное изучение: они показывают, насколько сильно изменилось распределение вероятностей, а не только среднее удивление.

Результат на публичном корпусе оказался скучным: качество предсказания токена почти не изменилось, а древний статичный квант почти не уступал новомодным. Напрашивается вывод «все методы одинаковые». Это ловушка, и следующая глава объясняет, почему.

Почему перплексия вообще не приговор? Она усредняет неожиданность следующего токена на коротком окне. Задаче нужна длинная связность и следование ограничениям: локально гладкий текст может быть глобально неверным, а отдельные ошибки — компенсироваться или, наоборот, накапливаться. Поэтому модель бывает «локально гладкой» и «глобально неправильной».

Почему публичный датасет врёт

Автор взял свой набор данных: алгоритмические задачи на JavaScript и темы вокруг вайб-кодинга — когда код пишут с помощью модели и принимают по результату, а не набирают вручную. Текста было на порядок меньше, чем в публичном корпусе, но знакомые эксперты заверили, что объёма хватит.

И тут случилось странное. На публичном датасете кванты выглядели почти как эталон, а на своём — резко просели. Причина не в квантах, а в датасете. Любой опубликованный набор текстов рано или поздно попадает в обучающую выборку. На знакомом тексте даже низкобитная модель узнаёт последовательность, и зазубренные веса срабатывают триггером: она выдаёт красивые, но нечестные результаты. На новом тексте она не узнаёт, а предсказывает: на собственных данных сразу видно, как кванты проседают и начинают генерировать несвязный бред. Поэтому модель иногда «знает» ответ на популярный тест, но не решает его вариант с другими числами: она не обобщает, а вспоминает.

Вывод: публичный датасет годится для быстрой проверки работоспособности, но не для сравнения квантов. Для сравнения нужен свой текст, который модель точно не видела.

Публичные бенчмарки и их ловушки

С перплексией та же проблема, что и с любым публичным тестом. Разберём MMLU: это набор вопросов с вариантами ответа из разных областей — биология, физика, юриспруденция и десятки других. Модель выбирает правильный вариант, и по доле попаданий судят о знаниях.

Минус первый: если правильные ответы лежат в интернете, модель можно заранее натренировать на этот тест. Публикаторы клянутся, что так не делают, а если делают, то при помощи выбросов подчищают следы. Верить этому трудно: у них есть интерес получить высокий балл любой ценой.

Минус второй виден на конкретном примере. Автор разбирает график с Реддита, где разница между 1-битным и 8-битным квантом — всего один балл. Это почти невозможно, если модель действительно решает задачи; похоже, она шпарила по зазубренному тексту. Автор графика, видимо, этого не заметил и вместо переделки подогнал результаты к ожидаемым, нарисовав график с масштабированием: до 2 бит разница минимальна, а потом якобы яма вниз.

Автор признаётся, что сам сначала выдернул этот график не глядя. Это была большая ошибка, говорит он. Отсюда совет: смотреть на чужие тесты в режиме паранойи и не доверять им, особенно если модель вот-вот вышла. Идеальный вариант — свой персональный датасет, хотя бы сотня задач: следование инструкциям, вызов инструментов, прикладные задачи из вашей области. И этот датасет нельзя публиковать, иначе произойдёт утечка и он перестанет быть честным.

Публичные бенчмарки не отвечают на главный вопрос: будет ли модель лучше на ваших задачах. Проблема интерпретации остаётся: совпадение рейтингов с вашей работой — не факт, а надежда.

Три способа оценить ответы

Свой тест можно построить разными способами. На Hugging Face есть раздел датасетов, где среди студенческих наборов попадаются готовые бенчмарки; их можно взять за основу и переделать под свои задачи. Но главный вопрос — как оценивать правильность ответов. Автор знает о трёх способах, два из которых топорные.

Первый — вручную сверять ответы и выбирать модель субъективно, «как чувствуется». Минусы очевидны: долго, дорого и зависит от настроения.

Второй — тест с вариантами ответов, как MMLU. Проверку можно автоматизировать простым скриптом, и это плюс. Но сами тесты годятся лишь для поверхностной оценки знаний: они не проверяют, умеет ли модель строить решение.

Третий — использовать умную облачную LLM как судью. Берут два или более ответов от разных моделей, дают судье критерии и просят выбрать лучший. Судья может проверить и корректность, и глубину: учла ли модель все варианты решения. Критерии задаются в системном промпте — инструкции, которая задаёт правила для всех ответов, — и они должны быть чёткими и простыми.

У этого способа есть ловушки. Судья может предпочитать ответ, который идёт в промпте первым. На длинных ответах или большой пачке может сработать lost in the middle: судья запутается или пропустит нюанс. Решения: давать ответы по одному, чтобы судья оценивал каждый независимо; или ротация порядка и три прогона, усредняя балл; или дать судье решить задачу самому и сравнить своё решение с предоставленным; или приложить свой эталонный ответ.

Деталь. главный минус облачной судьи — утечка. Вы сливаете свой датасет в облако, а он с некоторой вероятностью попадает в обучающую выборку. Оттуда через дистилляцию он может просочиться в открытые модели. Автор напоминает, сколько было случаев, когда DeepSeek выдавал себя за ChatGPT. Число «146%» в источнике — ирония, а не измерение.

Можно взять локальную модель в роли судьи, но это работает, только если в датасете уже есть эталонный ответ. И есть предвзятость: судья чаще ставит высокие оценки ответам, которые сгенерировала она сама или модель того же семейства.

Минимальный честный тест

1. Возьмите эталон Q8 (лучше FP16) и получите его ответы.
2. Соберите свой закрытый набор задач с критериями.
3. Оценивайте ответы по одному или с ротацией порядка.

Автор советует не лениться и потратить пару вечеров на свой набор и свои критерии. Гипотеза простая: если модель следует пошаговому плану из пяти пунктов и справляется с синтаксисом языка программирования, скорее всего, она справится и с остальным.

Методология автора: G0VNO

Посмотрев на YouTube, автор решил, что никто не умеет тестировать модели правильно: все занимаются перебиранием промптов вроде «какая ты модель» или «сделай мне Minecraft». Он собрал свою методологию и назвал её G0VNO.

Название методологии — авторская шутка, а не стандарт; в уроке важны три части теста, а не аббревиатура.

Первая часть — синтетический бенчмарк llama-bench. Он измеряет две скорости: обработку промпта, prefill (префил), и генерацию токенов, decoding (декодинг). Контекст задаётся отдельно; остальные параметры автор оставляет дефолтными. Почему не максимум контекста? Потому что бенчмарк делает несколько итераций и усредняет, а на максимальном контексте даже одна итерация длится так долго, что тесты устареют раньше, чем закончатся. Поэтому в таблицах — максимально возможная скорость на карте; на практике она будет ниже из-за большего контекста.

Деталь. синтетический тест не умеет оценивать спекулятивное декодирование. Автор честно говорит, что либо не разобрался, либо это невозможно. Поэтому MTP-модели в этой части выглядят так же, как обычные.

Вторая часть — перплексия. Она показывает, как сжатые версии ведут себя относительно эталона. Но у неё есть ограничение: модели на 20 с лишним миллиардов параметров не влезают в видеопамять целиком, а прогон с офлоадом занимал бы слишком много времени, поэтому перплексию для них не считали.

Третья часть — LLM как судья, но не в обычном виде. Ответ Q8-модели берут как эталон и смотрят, насколько изменилось качество ответов у сжатых версий. Судья оценивает два вопроса: правильно ли решена задача и насколько хорошо модель следовала инструкции. В первой версии на выходе был vibe score от 0 до 100. После прогона шести моделей и более 40 миллионов токенов судьи автор увидел, что шкала смешивает качество с длиной и мелкими замечаниями, а модели активнее накапливают ошибки на краях, и перешёл к бинарной оценке pass / not pass. Критерии и комментарии судьи остались, а в таблицах — число задач, решённых эталоном, и главный сбой сжатых.

Схема проверки — на рис. 9.

Критерии выглядят так. Лучший ответ семантически эквивалентен эталону и выполнил все инструкции. Дальше — ответ в целом корректен, но качество пострадало: модель потеряла техническую грамотность и говорит как пещерный человек. Потом — логика рабочая, но появились допущения, которые могут сломать решение. Дальше идут проблемные случаи: модель явно нарушила инструкцию (в промпте просили опрос каждую секунду, а она делает раз в 2 секунды), решение нерабочее, задача неверно понята, вывод — мусор, обрезан из-за нехватки контекста или зациклен.

Отдельно автор предусмотрел случай, когда эталон сам ошибся. Судья проверяет, воспроизвела ли сжатая модель баг эталона или придумала новый бред, опираясь на саму задачу. Высокий балл за это не дают. Есть и версия без сравнения с эталоном: судья просто анализирует ответ и следование инструкциям, критерии те же самые, чтобы распределения можно было сравнивать.

Главная оговорка: результаты зависят от датасета и задач. В наборе автора 100 вопросов уровня middle fullstack — средний разработчик с опытом около двух-трёх лет, на JavaScript (JS) со стеком Express, React, Mongo, Redis и Postgres. Вопросы с React проще, примерно уровня новичка; автор сам это признаёт. Задачи — реализация готового решения в рамках одного модуля или компонента. Автор подозревает, что на питоновом датасете все модели работали бы лучше, но это гипотеза.

Задачи на одну простую функцию он исключил намеренно: с ними справится любая модель, даже сжатая до одного бита, и результат будет лучше, чем у 50% начинающих разработчиков. Интерес начинается на крупных задачах. Первая половина вопросов содержит прямые инструкции и правила, вторая половина — мягче и позволяет креативить.

Деталь. прогон одной модели со всеми квантами занимал около 12 часов и съедал 6–8 миллионов токенов судьи. Судейская модель тоже ошибается, хоть она и в облаке. Для автоматизации автор написал скрипт; отчёты, датасет, генерации и комментарии обещал опубликовать.

Тестовый стенд

Этот раздел можно пропустить: он описывает железо автора и не нужен для понимания метода. Тесты шли на нескольких видеокартах, и это важно для чтения результатов. Стенд: процессор Ryzen 9800X3D, 32 ГБ DDR5, несколько карт, киловатт потребления из розетки. Автор подчёркивает: для запуска локальных моделей всё это не обязательно, это увлечение, доведённое до конца.

Самая слабая карта — GTX 1050. Для вычислений она бесполезна, но у неё есть роль: видеовывод. Windows в зависимости от разрешения может съедать несколько гигабайт видеопамяти, а если переключиться на встроенную графику, она заберёт эти гигабайты из оперативной. Поэтому иногда выгодно воткнуть любую затычку вроде GT 710, чтобы освободить память под модель. Слабая карта для вывода освобождает и видеопамять основной карты, и ОЗУ, которое забрала бы встроенная графика; при 32 ГБ ОЗУ важен второй эффект.

RTX 2060 — Turing (Тьюринг), 6 ГБ GDDR6, шина 192 бита, тензорные ядра первого поколения. В 2019 году это была мечта, а сегодня карта бодрая, но памяти мало: на неё помещаются модели до 8 млрд параметров с небольшим контекстом, либо её используют как ускоритель вместе с другой картой.

RTX 3070 — Ampere (Ампер), 8 ГБ GDDR6, шина 256 бит. Хорошая карта для игр, но в некоторых проектах уже упирается в 8 ГБ. В тестах автор смотрит, можно ли дать ей вторую жизнь как калькулятору для LLM.

CMP 90HX — майнерская карта Nvidia 2021 года, 10 ГБ видеопамяти и тензорные ядра. Выглядит выгодно, особенно по цене: автор купил её примерно за 10.000, потому что спрос был никакой. Но нюансов много. У неё нет видеовыходов, распаяны только четыре линии PCI Express, а продавцы любят называть её аналогом RTX 3080. Это неправда: на бумаге она ближе к 3070 Ti, а по факту хуже. Чипы отбракованные или урезанные, функции для графики ограничены, и функции для ИИ, похоже, тоже. Прошивкой BIOS и разгоном это почти не лечится.

Деталь (необязательно): теплопакет (TDP) у неё заявлен 320 Вт, но в экземпляре автора выставлено 250, а в нагрузке она потребляет максимум 160 Вт. После установки в Windows карта выдаёт ошибку 43 и работает только с патченными драйверами; в системе определяется как 3070 Ti, а в nvidia-smi всё равно видна под майнерским именем. После патча отвалился аппаратный энкодер NVENC (кодировщик видео Nvidia), причём даже на основной карте. Автор не рекомендует её покупать для нейросетей.

RTX 5070 Ti — Blackwell, 16 ГБ GDDR7. На ней автор играет в Forza Horizon без фризов; в тестах она основной калькулятор. Остальные карты — старые, из кладовки после апгрейдов, дождавшиеся часа из-за всеобщей истерии по ИИ.

Что показали тесты моделей

Теперь — результаты. Общие условия: top-p и top-k по умолчанию, температура 0,3, контекст 32.000 токенов, но API ограничивал вывод 16.000 токенами. KV-кэш без квантизации, бюджет ризонинга — 4.000 токенов, то есть лимит на рассуждение. Перплексия считалась на том же корпусе, что и судейские задачи, но с контекстом 4.000 токенов, потому что текста мало.

Коротко: что показали тесты

Проверяли шесть моделей и их кванты на 100 задачах по коду. Эталон — Q8, судья — облачная LLM. Отдельно, вне этой серии, прогоняли Qwen 3.6 35B-A3B — его результаты в таблице помечены прочерком. Главный результат: сжатые версии почти всегда решают меньше задач, а на длинном коде ошибки накапливаются. Перплексия предсказывает не всё: у Gemma 12B она плохая, а задачи решаются лучше, чем у E4B.

На узком экране таблица прокручивается вбок; главные числа — в колонке Q8.

Прочерк — модель не входила в эту серию. Дальше — короткие детали по моделям.

Пауза: что показала таблица

Сжатые кванты почти всегда решают меньше задач, чем Q8, и чаще ломаются на длинном коде. Но перплексия не предсказывает результат: Gemma 12B с плохой перплексией обошла E4B, а UD-квант Qwen с хорошей — провалился. Дальше — детали по моделям; если устали, здесь можно сделать перерыв.

Qwen 3 (размер не распознан)

Первая модель — Qwen 3; размер в расшифровке не распознан, возможно 4B или 8B. Рост перплексии к Q8 всего 2%, но на задачах этого хватает: Q8 решила 27, а сжатые посыпались. Лучшей из сжатых была Q4_K_M — меньше всего ошибок. Чаще всего встречались мусор в ответах и логические ошибки; когнитивный краш — это ответ, где модель теряет условие и не доводит решение. Автор описывает модель как отличный способ решать задачи быстро и неправильно. По скорости порядок обычный: 5070 Ti, затем 3070, 2060 и CMP 90HX, которая оказалась слабее всех.

Gemma 4 E2B

У Gemma 4 E2B рост перплексии около 5%, то есть хуже, чем у Qwen. Q8 справилась с 47 задачами. Модель сильна в React, но проваливается на серверной части приложения; сжатые просели, что согласуется с высокой перплексией. Когнитивных крашей мало, в основном ошибки логики; даже в зачтённых задачах качество ниже. По производительности 5070 Ti выдала 15.000 токенов в секунду на prefill. 3070 примерно в три раза хуже на prefill и в два раза по декодингу. 2060 всё ещё даёт годную скорость, а 90HX — худшая.

Gemma 4 E4B

У Gemma 4 E4B из всех 8 млрд параметров 3,5 млрд — таблицы эмбеддингов (в основном PLE — отдельные таблицы на каждый слой), поэтому E4B означает примерно 4,5 млрд полезных весов. Модель мультимодальная. Перплексия лучше, чем у E2B, и задачи лучше: Q8 прошла 60–70, это первые модели выше порога полезности в 50 задач. По React около 40 успешных. Важное наблюдение — перекос в edge case (рабочее решение с недоделанными крайними случаями): квантизация повлияла и на верно решённые задачи. Идеальных решений нет, но работоспособный каркас остаётся.

Qwen 3.5 9B

Здесь в расшифровке стоит «Quantri 5.9B»; по контексту это вероятно Qwen3.5 9B. UD-квант в теории лучше предсказывает следующий токен, но на реальных задачах — провал. Q8 вывезла 45 задач, сжатые конкретно посыпались: у самой слабой краш почти на каждом десятом ответе. Ризонинг в Qwen не абсолютно поломан, но часто зацикливается и заваливает решение; поймать момент отказа невозможно — чистый рандом. Без ризонинга крашей меньше, но модель просто не справляется. По скорости 5070 Ti снова лучшая, 3070 проседает; у Q8 prefill деградировал, потому что модель не влезла целиком, а на 2060 квантованные версии были впритык к 6 ГБ.

Ornith

Ornith (в расшифровке «Ornit 1.9B», вероятно Ornith 1.0 9B) автор называет «принципиально новой моделью от американцев». Архитектурно это тот же Qwen 3.5, только обученный на другом датасете. Старые кванты бьют по перплексии сильно, UD держится приемлемо. На задачах — хуже Qwen 3.5, зацикливается даже в восьми битах; автор сразу делал прогон без ризонинга. По скорости то же самое, потому что это по сути Qwen.

Gemma 4 12B

У Gemma 4 12B на этом корпусе суперплохая перплексия: по метрике модель должна генерировать только бред, а по факту она справляется лучше E4B. React остался на уровне сорока задач, но подтянулась серверная часть; выросло число идеальных решений, хотя edge case всё ещё высоко. На 5070 Ti и 3070 заметна деградация в prefill; на 2060 модель уже не лезет. Это важный контрпример к перплексии: метрика предсказывает катастрофу, а задача решается. Значит, перплексия — не приговор, а сигнал.

Почему Gemma обгоняет Qwen на коде

Синтез простой: Gemma доводит простое решение до конца, Qwen выбирает более сложный вариант и ломается на деталях. В задаче про теги оба решения работают, с проверкой ввода и защитой от дубликатов, но оба игнорируют регистр букв (заглавные и строчные); у Gemma предупреждения проще — всплывающее окно. В остальных задачах — график, календарь, виртуальный список — картина та же.

Деталь. в задаче про график Gemma делает бар-чарт, Qwen — пай-чарт и проваливается. В дейтпикере-календаре Gemma сохраняет выбранную дату при переходе между месяцами, Qwen переносит её на следующий месяц. В виртуальном листе Gemma ошибается в тестовых данных, после правки работает; Qwen конфликтует с переменными, забывает useState и не генерирует 10.000 элементов — после правок список пуст, браузеру нечего рендерить.

Тяжёлые модели — плотные и MoE

Для тяжёлых плотных моделей нужно минимум 20 ГБ видеопамяти с учётом KV-кэша; MoE может уложиться в меньшее количество видеопамяти, если часть экспертов держать в ОЗУ. Автор собирал комбинации: основная 5070 Ti плюс 3070, 2060 или 90HX. Перплексию для них не считали, но прогнали по «соло»-версии бенчмарка — прогону на одной карте без второй.

Muse Glimmer (30B) от Meta автору понравилась: пишет код по делу и не гадит в контекст. Свежий Qwen 3.8 (27B) — полный провал: игнорирует бюджет ризонинга, периодически зацикливается, и это первая модель, которой не хватило выделенного контекста на задачи. Дальше Gemma 4 31B, Nemotron, Qwen 3.6, Qwen3 Coder и GPT-OSS; GPT-OSS от Unsloth был только в одном кванте, поэтому автор взял что было. По скорости 90HX сильно снижает общий результат: 5070 Ti большую часть времени курит, пока майнерская карта пытается приумножить 2 на 2. Связки с 2060 и 3070 выглядят интереснее в разы. Qwen3.8 27B меньше Gemma 31B по числу параметров, но декодинг у него на пару токенов медленнее. У Qwen3.6 35B всего параметров больше, а активных около 3B. У Qwen3.8 вроде изменился только датасет, а перформанс ухудшился ещё заметнее.

Оговорка автора: все слабые карты стояли вторым слотом на PCI Express 4 всего с четырьмя линиями. Пропускная способность шины могла быть узким местом, поэтому у тебя результаты по скорости могут быть лучше.

Выводы автора

Главный вывод начинается с возражения онлайн-экспертам: «кто проверяет модель одним запросом (one-shot), она же на один промпт отвечает по-разному?». Автор отвечает: сжатая модель даже при низкой температуре не отвечает так же стабильно, как восьмибитная, потому что у неё выше перплексия. Даже один неверно предсказанный токен в начале влияет на всю дальнейшую последовательность. Поэтому разные ответы на один запрос — прямой сайд-эффект сжатия.

Отсюда второй вывод: накопление ошибок в пережатых моделях — реальность, и оно сильно влияет на результат. Если восьмибитная модель спокойно решала задачу, сжатые часто теряли возможность довести решение до конца или делали это заметно хуже.

Третий вывод — про длину ответа. Судья цепляется за минимальные косяки. Модели, которые следовали промпту, выдавали компактное и функциональное решение, допускали меньше ошибок и получали оценку выше. Qwen каждый раз начинал креативить и писать длинные полотна кода с лишними надстройками; чем больше кода за раз, тем выше шанс, что рано или поздно там появится ошибка. Исправление таких косяков требует времени: либо самому разбираться, либо гонять модель повторно, и не факт, что с первого раза.

Для четырёхбитных Qwen автор советует отключать ризонинг и тратить больше времени на промпт со всеми edge case. Есть ощущение, что излишняя «пытливость» ризонинга взвинчивает накопление ошибок ещё на этапе размышления и ухудшает финальный результат.

Практические выводы простые. Не раздувать контекст и держать решения в рамках одной сессии компактными: тогда меньше шансов на нерабочий код, хотя гарантии нет. Не использовать для кода локальные модели, сжатые меньше 8 бит. Как поведут себя 6 бит — непонятно; возможно, это золотая середина, но нужны тесты. Это позиция автора, а не доказанный факт: он сам приглашает доказать, что он ошибается, на своих задачах.

Личный выбор автора: для вайб-кодинга на JavaScript он лучше возьмёт восьмибитную Gemma 12B, чем четырёхбитный Qwen на много параметров. Не потому, что Qwen плохая модель, а потому, что сжатие съедает точность, которая нужна для длинного кода. На 16 ГБ Gemma 12B в Q8 помещается целиком; на 8 ГБ её можно запустить, отдав часть слоёв в ОЗУ через -ngl. Это медленнее, но качество кода сохраняется — в отличие от перехода на Q4.

Что автор исправил бы в бенчмарке: добавить опорные примеры для судьи, чтобы она корректно оценивала решение (сейчас были статистические погрешности — ответы эталона иногда оценивались по-разному); сравнивать не все задачи, а только те, которые решил эталон, чтобы точнее увидеть, где именно сжатая модель тупеет; поработать над статусами и промптом, чтобы судья анализировала разницу ответов, а не только корректность. Последнее сложно: Q4-модели уже на этапе ризонинга генерируют совершенно другие последовательности, чем Q8, на том же промпте.

Важная оговорка: качество зависит от сценария. Малопараметровую или пережатую модель можно использовать как автокомплит или декомпозировать задачи до отдельных функций — но это требует большего вовлечения. Для длинных полотен кода нужна точность, а Q4 часто ошибается и точности не даёт.

Деталь. кроме 7.000 генераций, попавших в видео, у автора остались материалы, которые в ролик не вошли, например Omnicoder. Все отчёты судьи, бенчмарки железа, тесты перплексии и шаблоны графики он обещал выложить для подписчиков.

Короткий путь: Ollama и первая попавшаяся модель

В конце автор показывает, как всё выглядит для обычного пользователя: скачать Ollama, выбрать популярную модель с 600.000 скачиваний и запустить. Оно работает: настоящий ИИ на компьютере, можно даже поиграть в простую игру.

Но до облачных моделей такой модели далеко. Разница между «запустилось» и «полезно для моей задачи» — это и есть тема всего урока: память, квант, контекст и проверка на своих задачах.

Вся модель целиком

Языковая модель — это набор числовых весов, обученных предсказывать следующий токен, и при работе веса только читаются. Память под неё в байтах считается как произведение числа параметров на число бит на параметр, делённое на 8; 1 ГиБ = 1024³ байт. Исходные 16 бит на вес не влезают в домашнюю видеокарту, а квантование снижает биты: до 8 потери малы, 4 бита уже заметно отличаются, ниже 4 модель может рассыпаться, и для кода автор не советует ниже 8.

Ошибка одного токена меняет всю дальнейшую генерацию, поэтому сжатая модель может отвечать по-разному на один запрос. Архитектура меняет цену: MoE держит все веса в памяти, но считает только активных экспертов, дистилляция уменьшает число весов, спекулятивное декодирование ускоряет генерацию ценой памяти. Контекст требует отдельного KV-кэша и времени на attention, а длинный контекст не гарантирует, что модель прочитает середину.

Поэтому в llama.cpp слои и эксперты раскладывают между видеопамятью и ОЗУ, а кэш при необходимости сжимают. Имя кванта описывает смесь типов по слоям, и по имени нельзя предсказать ни качество, ни скорость. Проверять надо на своём тексте: перплексия даёт первый сигнал, но публичные датасеты искажают картину утечкой, а выбор автора для длинного кода — восьмибитная малая модель, а не четырёхбитная большая.

Приложение: что в расшифровке распознано неточно

Автосубтитры путают имена и числа. Ниже — места, которые пришлось привести к узнаваемому виду; на выводы урока они не влияют.

Вернись через несколько дней

Ответьте, не перечитывая статью.

1. Модель на 14 млрд параметров, 8 бит на вес. Сколько примерно займут веса и что ещё нужно добавить в бюджет памяти?

   Ответ. 14 ГБ (13 ГиБ) идеальных 8 бит; у Q8_0 — 14,9 ГБ (13,9 ГиБ). Сверху нужны KV-кэш под контекст, буферы вычислений и запас для системы.

   Почему. 8 бит — это байт на параметр; кэш и служебные расходы не входят в размер файла.

   В хорошем ответе:

   • 14 ГБ (13 ГиБ)
   • Упомянут KV-кэш
   • Упомянут запас или служебные расходы

   Вернуться к разделу

2. Почему MoE на 30 млрд параметров с 3 млрд активных всё равно требует памяти как 30-миллиардная модель?

   Ответ. Потому что все веса нужно загрузить, даже если на каждом токене используется только часть. Экономия идёт в вычислениях, а не в объёме памяти.

   Почему. Маршрутизатор выбирает экспертов на лету, поэтому спящие эксперты должны быть доступны.

   В хорошем ответе:

   • Все веса загружены
   • Экономия в вычислениях
   • Упомянут маршрутизатор или выбор экспертов

   Вернуться к разделу

3. Вы удвоили контекст с 16.000 до 32.000 токенов. Что произойдёт с KV-кэшем и скоростью?

   Ответ. Кэш примерно удвоится по объёму. Prefill подорожает примерно вчетверо: работа растёт квадратично. Генерация каждого токена станет примерно вдвое дороже. Размер кэша считается в разделе KV-кэша; подробнее о скорости — в разделе Flash Attention.

   Почему. Кэш хранит ключи и значения на каждый токен каждого full-attention слоя; в гибридных моделях таких слоёв меньше, чем всего. Внимание в prefill в обычной модели считает все пары; у гибридной часть слоёв линейная, поэтому это оценка сверху.

   В хорошем ответе:

   • Кэш примерно удвоился
   • Prefill дороже квадратично
   • Генерация дороже линейно

   Вернуться к разделу

4. Чем Q4_K_M отличается от IQ4_XS и почему Q8_0 нельзя считать «просто более качественной версией»?

   Ответ. Q4_K_M — K-квант с 4 битами на основные веса, 4,89 бита на вес. IQ4_XS — 4-битный нелинейный квант с imatrix, 4,46 бита на вес: он меньше Q4_K_M, но на слабом CPU медленнее. Q8 лучше Q4 по качеству, но это не исходник: 8,5 бита, потери есть; он в 1,7 раза больше Q4, поэтому годится как практический эталон, когда FP16 не влезает.

   Почему. Имя кванта описывает схему и среднюю битность, а не гарантию качества; размер и скорость — часть выбора.

   В хорошем ответе:

   • Различие K и IQ
   • Q8 лучше Q4 по качеству, но не исходник
   • Q8 примерно в 1,7 раза больше Q4
   • Выбор зависит от памяти и задачи

   Вернуться к разделу

5. Вы хотите проверить два кванта на своих задачах. Опишите минимальный честный тест из трёх шагов.

   Ответ. Взять эталон Q8 (или FP16) и получить его ответы; собрать свой непубличный набор задач с критериями; прогнать кванты и сравнить с эталоном, оценивая по одному ответу или с ротацией порядка.

   Почему. Без эталона не видно абсолютной потери, без своего набора — утечка, без контроля порядка — позиционная предвзятость судьи.

   В хорошем ответе:

   • Есть эталон
   • Есть свой закрытый набор
   • Есть контроль порядка или оценка по одному

   Вернуться к разделу

6. У вас 8 ГБ видеопамяти и 32 ГБ ОЗУ. Вы пишете код на JavaScript. Какую стратегию выбрать: Q4 большой MoE или Q8 модели на 12 млрд, и почему?

   Ответ. Q8 модели на 12 млрд с частичной выгрузкой слоёв в ОЗУ через -ngl: она не влезает целиком, но так запускается и сохраняет точность. Q4 большой MoE быстрее по вычислениям, но теряет точность, которая нужна для длинного кода.

   Почему. Автор сравнил именно такой выбор и предпочёл Q8 Gemma 12B против Q4 Qwen 35B для вайб-кодинга; на 8 ГБ помогает выгрузка части слоёв, а не переход на Q4.

   В хорошем ответе:

   • Выбор Q8 малой модели
   • Назван -ngl или частичная выгрузка
   • Причина — точность для кода

   Вернуться к разделу