Почему модель на 35 млрд параметров летает на домашней видеокарте
Если коротко: скорость, с которой языковая модель печатает ответ, почти не зависит от «мощности» видеокарты в терафлопсах. Её ограничивает память: ради каждого следующего токена карта должна заново прочитать все веса, которые участвуют в расчёте. Поэтому большая модель становится быстрой по двум причинам. Первая — веса ужимают до 2–4 бит, и читать их приходится меньше. Вторая — архитектура «смесь экспертов» (MoE), где на каждый токен включается лишь малая часть модели. Если сложить оба приёма, модель на 35 миллиардов параметров на обычной игровой карте выдаёт больше сотни токенов в секунду.
Это канал «Всё про ИИ и Роботов». На этой неделе одной из самых читаемых статей Хабра стала заметка разработчика Евгения Игумнова: он запустил на домашней RTX 4070 Ti SUPER локального кодинг-агента со скоростью 125 токенов в секунду. К пятнице у текста было около 34 тысяч прочтений, больше 300 добавлений в закладки и почти две сотни комментариев. Пересказывать рецепт по пунктам я не буду, у автора он и так подробный. Интереснее понять, почему он вообще работает. Ещё год назад на 16 гигабайтах видеопамяти «умная и быстрая» модель казалась противоречием.
Что было не так: умная модель — медленная, быструю — не о чем спросить
Автор описывает знакомую многим развилку. Плотная (dense) модель на 27 миллиардов параметров на его карте выдавала 10–20 токенов в секунду. Для чата этого хватает, для кодинг-агента нет: агент сам читает файлы, пишет план, правит код, запускает тесты и читает их вывод. Каждый шаг состоит из сотен и тысяч токенов. На 15 токенах в секунду одна задача растягивается на десятки минут ожидания, поэтому автор считает комфортной скорость 100–150 токенов в секунду.
Маленькие модели на 3–8 миллиардов параметров на той же карте летают, но для агентной работы им не хватает ума: они теряют нить, путают файлы и уверенно пишут несуществующие функции. Казалось, выбирать приходится между медленным умным и быстрым глупым. Выход нашёлся, когда стало понятно, что именно тормозит.
Ага-момент: видеокарта не считает, а ждёт память
Языковая модель пишет текст по одному токену: выдала кусочек слова, дописала его к контексту и посчитала следующий. Ради каждого токена через вычислитель проходят все веса, то есть все миллиарды чисел, из которых состоит модель. Арифметики при этом немного: каждый вес читается из памяти, участвует буквально в одном умножении со сложением и больше в этом шаге не нужен.
Когда вы общаетесь с моделью в одиночку, ядра видеокарты большую часть времени простаивают и ждут, пока память подвезёт следующую порцию чисел. Отсюда простая формула для прикидки: потолок скорости ≈ пропускная способность памяти ÷ объём весов, прочитанных за один токен. Ни количество ядер, ни терафлопсы в неё не входят.
Подставим цифры. По спецификации NVIDIA у RTX 4070 Ti SUPER 16 ГБ памяти GDDR6X на 256-битной шине. Это даёт около 670 ГБ/с, то есть за секунду карта может прочитать свою память примерно 40 раз. Плотная модель на 27 миллиардов параметров при привычном сжатии около 4,9 бита на вес весит около 16,5 ГБ. Она даже не помещается в видеопамять целиком, а будь карта побольше, упёрлась бы в потолок около 40 токенов в секунду. Часть весов приходится держать в обычной оперативной памяти, которая в разы медленнее, и получаются те самые 10–20 токенов.
Генерация текста упирается не в вычисления, а в чтение памяти. Быстрее станет тот, кто сумеет читать меньше байт на каждый токен.
Это главный вывод статьи, остальные приёмы из него следуют. Байты на токен можно сократить двумя способами: сделать каждый вес легче или читать не все веса.
Способ первый: ужать каждый вес
Обученная модель хранит веса в 16-битном формате. Квантизация огрубляет их до 8, 4, 3 или даже 2 бит: близкие значения группируют в блоки, и для каждого блока хранят масштаб и короткие целые числа. Часть точности теряется, зато файл становится в несколько раз меньше. Важнее другое: в той же пропорции уменьшается объём памяти, который приходится читать на каждом шаге.
Хорошо видно это в замерах из документации llama.cpp, популярного движка для локального запуска моделей. Там взяли Llama 3.1 8B и сжали её разными способами. В исходном 16-битном виде модель весит почти 15 ГиБ и генерирует около 29 токенов в секунду. В варианте Q4_K_M (около 4,9 бита на вес) она весит 4,6 ГиБ и выдаёт около 72 токенов. В Q2_K_S (около 3 бит на вес) это 2,8 ГиБ и примерно 90 токенов в секунду. Файл сократился в пять с лишним раз, скорость выросла втрое.
Почему не в пять? Кроме весов есть и другие расходы: распаковка сжатых блоков, механизм внимания, кэш уже прочитанного контекста. Но направление очевидное: меньше байт — быстрее ответ.
Чем за это платят
Бесплатно ничего не бывает. В 2-битных вариантах модель ошибается заметно чаще, чем в 4- или 8-битных, и автор оригинала это прямо признаёт. Он использует версии с пометкой UD-Q2_K_XL: в них важные слои сжаты слабее, а второстепенные сильнее. Это смягчает потери, но не отменяет их. Поэтому одна квантизация задачу не решает: 27 миллиардов параметров даже в 3 битах — это около 10 ГБ на токен, то есть потолок порядка 60–70 токенов в секунду. Нужен второй, гораздо более сильный приём.
Способ второй: читать не всю модель
Модель, которую взял автор, обозначена как «35B-A3B»: 35 миллиардов параметров всего, около 3 миллиардов активных. Это архитектура Mixture of Experts, «смесь экспертов». Внутри каждого слоя вместо одного большого блока стоит много маленьких параллельных блоков-«экспертов». Перед ними работает крошечный маршрутизатор, который для каждого токена выбирает несколько подходящих. Остальные эксперты в этот момент не участвуют, и их веса никто не читает.
Идею хорошо описывает работа о Mixtral 8x7B от Mistral AI. В каждом её слое восемь экспертов, на каждый токен маршрутизатор выбирает двух. В итоге модели доступны 47 миллиардов параметров, а при генерации задействуются 13 миллиардов. Современные модели довели этот приём до крайности: в карточке Qwen3-30B-A3B указано 128 экспертов в слое, из которых на токен включаются 8, и 3,3 миллиарда активных параметров из 30,5 миллиарда.
Теперь пересчитаем. Три миллиарда активных параметров по 3 бита — это чуть больше гигабайта на токен вместо десяти. Теоретический потолок на той же карте поднимается до нескольких сотен токенов в секунду. Реальные 125 заметно ниже: съедают внимание, кэш контекста и накладные расходы маршрутизации. Но это уже в 6–10 раз быстрее плотной модели сопоставимого уровня.
Миф: «35 миллиардов параметров — значит, в 35 раз тяжелее модели на миллиард»
Для MoE это неверно, и тут легко запутаться в обе стороны. По скорости модель 35B-A3B ведёт себя почти как трёхмиллиардная: на каждом шаге читается примерно столько. По памяти — как 35-миллиардная, ведь хранить нужно всех экспертов: заранее неизвестно, кого маршрутизатор позовёт на следующем токене. Отсюда практическое правило: объём видеопамяти определяет, какую модель вы вообще запустите, а пропускная способность памяти и число активных параметров — как быстро она будет отвечать.
Поэтому 16 ГБ — удобная точка. В 2–3-битном сжатии вся 35-миллиардная модель туда помещается, а читать на каждом шаге нужно лишь малую её часть.
Третий ускоритель: угадывать несколько токенов сразу
Автор упоминает и MTP (Multi-Token Prediction, предсказание нескольких токенов). Модель учат угадывать не только следующий токен, но и пару токенов после него. Исследователи Meta в работе о многотокенном предсказании показали, что модели, обученные предсказывать по 4 токена, при генерации работают до трёх раз быстрее.
Механика опирается на тот же ага-момент. Раз узкое место — чтение весов, выгодно за одно чтение проверить сразу несколько вариантов. Модель черновиком предлагает несколько токенов вперёд, затем одним проходом проверяет, совпадают ли они с тем, что она выдала бы честно. Совпавшие токены засчитываются бесплатно, на первом расхождении черновик отбрасывается. Качество ответа от этого не страдает, а скорость растёт ровно настолько, насколько часто черновик угадывает. В коде угадывать легко: скобки, отступы и повторяющиеся имена хорошо предсказуемы. Автор оценивает прирост скромнее, примерно в 20%, на его конфигурации.
Скорость есть — теперь надо уместить работу в память
Вторая половина статьи о том, что делать с ограничениями, которые остались. Контекстное окно у этой конфигурации — около 65 тысяч токенов. Для агента, который читает много кода, это тесно, и автор выкручивается тремя способами.
Лёгкий агент вместо тяжёлого. По подсчёту автора, популярные облачные кодинг-агенты ещё до вашего первого слова тратят 10–14 тысяч токенов на собственные системные инструкции, то есть 15–20% маленького окна. Он выбрал минималистичного агента Pi с инструкцией примерно на 1,5 тысячи токенов. Есть и второй довод: маленькие локальные модели легче теряют нить, и длинная служебная инструкция их отвлекает.
Сначала план, потом код. Крупную задачу агент не выполняет сразу. Сначала в отдельной сессии он пишет файл plan.md с описанием изменений. Затем контекст очищается, и вторая сессия работает уже по плану. Каждая фаза умещается в окно, потому что не тянет за собой историю другой.
Подзадачи в отдельных экземплярах. Очень большой план разбивается максимум на десять подзадач. Каждую выполняет отдельная копия агента, которой передают только относящееся к ней. Главный экземпляр получает короткие итоги и занимается координацией и проверкой, поэтому его окно не переполняется.
Рамки компенсируют сжатие
Последний приём закрывает слабость 2-битной модели. Раз она чаще ошибается, ей задают жёсткие правила в файле AGENTS.md: файлы не длиннее 300–500 строк, у каждого модуля одна ответственность, на каждую функцию юнит-тесты, перед сдачей прогон тестов и сборки, тесты нельзя ослаблять ради «зелёного» результата. Ошибки модели всплывают на тестах, и она исправляет их сама. Локально токены не стоят денег, так что пара лишних итераций обходится только временем, а при 125 токенах в секунду его уходит немного.
Что из этого следует, если вы выбираете железо или модель
Даже если вы не собираетесь запускать кодинг-агента, механизм пригодится при выборе.
Сравнение карт для ИИ
Характеристика → На что влияет → Почему
Объём видеопамяти → Какая модель вообще поместится → Хранить нужно все веса, включая спящих экспертов
Пропускная способность памяти → Скорость генерации текста → Каждый токен — новое чтение активных весов
Терафлопсы и число ядер → Обработка длинного входа (промпта) → Там много токенов считаются разом, и вычисления выходят на первый план
При выборе модели смотрите на число активных параметров, а не только общих: «30B-A3B» на домашней карте будет в разы быстрее плотной «27B». Сильное сжатие (2–3 бита) — это компромисс. Оно оправдано, когда результат проверяется автоматически, например тестами. Если ответ проверить нечем, лучше 4 бита и чуть меньшая скорость.
И честное ограничение. Локальная модель уровня 35B-A3B — сильный помощник, но не замена флагманским облачным моделям на сложных архитектурных задачах. Главные её плюсы — приватность кода, работа без интернета и отсутствие счётчика токенов. Автор оригинала ставит на первое место именно контроль над своими исходниками.
Коротко
— Скорость генерации текста ограничивает память, а не вычислительная мощность: ради каждого токена карта перечитывает все активные веса.
— Потолок можно прикинуть так: пропускная способность памяти ÷ байты на токен.
— Квантизация уменьшает байты на каждый вес: в замерах llama.cpp 16 бит → 3 бита дают примерно втрое больше токенов в секунду. Плата за это — точность.
— MoE сокращает количество читаемых весов: из 35 миллиардов параметров на токен работают около трёх.
— Многотокенное предсказание позволяет за одно чтение проверить несколько токенов.
— Ограничения памяти и точности компенсируют организацией работы: план отдельно от кода, подзадачи в чистых контекстах, тесты как страховка от ошибок сжатой модели.
Пока нет комментариев