Почему загрузка модели объемом 17 ГБ не означает наличия 17 ГБ памяти для ее работы
Узнайте, как активные параметры, общее количество параметров, рост размера кэша KV и усилия по обработке информации определяют реальные затраты на память и вычисления при работе с языковой моделью локально.
Источники: A 17 GB AI Model Sounds Small. Running It Is a Different Story.
Была анонсирована новая открытая модель — в заголовках говорится, что она конкурирует с гораздо более крупными системами, и одна цифра привлекает внимание всех: размер загрузки составляет всего 17 ГБ. Это кажется свидетельством того, что серьезная помощь в программировании становится доступной обычному рабочему столу, пока вы не загрузите настоящую базу кода или длинный диалог, после чего у процесса заканчивается память. Размер файла, количество активных параметров и объем памяти, действительно необходимый работающей модели, — это три разных показателя. В этой статье объясняется, как они связаны, чтобы вы могли оценить реальные затраты на запуск модели перед тем, как планировать аппаратное обеспечение на основе заголовочных данных.
Количество параметров — менее надежный показатель, чем раньше
При сравнении языковых моделей большинство людей сначала обращают внимание на количество параметров. Это разумный подход: параметры представляют собой веса, выученные сетью, и кажется логичным, что чем их больше, тем модель крупнее, умнее и дороже.
Современные архитектуры сделали эту связь гораздо менее строгой. Одним из важных поворотных моментов стали исследования DeepMind по теме Chinchilla, посвящённые оптимизации процесса обучения с точки зрения вычислительных ресурсов. Они показали, что модель с 70 миллиардами параметров, обученная на гораздо большем объёме данных, может превзойти модели гораздо большего размера, включая Gopher с 280 миллиардами параметров, даже при использовании сопоставимого количества вычислительных ресурсов для обучения.
Вывод заключался не в том, что побеждают небольшие модели. Он был более тонким и полезным: способ, которым модель использует свои параметры, может иметь такое же значение, как и их количество. Эта идея стала основой другой архитектуры, которая сейчас доминирует в обсуждениях эффективных моделей — Mixture of Experts.
Активные параметры против общего числа параметров
Модель типа Mixture of Experts (MoE) содержит множество специализированных подсетей. Вместо того чтобы пропускать каждый токен через всю сеть, небольшой маршрутизатор выбирает несколько специалистов для обработки каждого токена, и только эти специалисты выполняют работу.
Полезной аналогией может служить компания с 100 сотрудниками. Для обработки запроса от клиента может понадобиться всего пять из них, так что можно сказать, что для этого запроса «активны» пять человек. Однако компания по-прежнему должна нанимать, обеспечивать рабочими местами и оплачивать труд всех 100 сотрудников, поскольку для следующего запроса может понадобиться другая группа из пяти человек.
Модели MoE ведут себя аналогичным образом:
- Количество активных параметров — это примерное количество параметров, участвующих в генерации одного токена.
- Общее количество параметров — это общий объем параметров в модели.
Разница между ними может быть огромной. Хорошим примером является DeepSeek-V3: в общей сложности у него около 671 миллиарда параметров, причем приблизительно 37 миллиардов из них активны за один токен. Поэтому генерация токена стоит гораздо дешевле, чем у модели с высокой плотностью параметров в 671 миллиард. Однако это не означает, что DeepSeek-V3 во всех практических аспектах ведет себя как модель с 37 миллиардами параметров, и именно здесь многие сравнения ошибаются.
Затраты на вычисления и память — это разные показатели
Количество активных параметров — хороший показатель для оценки вычислительных затрат: он показывает, сколько операций умножения и суммирования требуется для каждого токена, а значит, насколько быстро можно генерировать токены на определенном оборудовании.
Память — это отдельный бюджет. Механизм вывода не может удалять экспертов, которые не были выбраны для текущего токена, поскольку маршрутизатор может выбрать любого из них для следующего токена. Все они должны оставаться доступными, обычно в GPU или объединенной памяти, поскольку загрузка весов с диска для каждого токена была бы слишком медленной.
Таким образом, модель может быть дешевой в вычислениях, но при этом требовать большого объема памяти. Это можно описать с помощью краткого правила:
Активные параметры показывают, сколько вычислений требуется для каждого токена. Общий размер модели указывает, сколько памяти должно быть доступно.
Эти два показателя связаны, но отвечают на разные вопросы и не могут заменять друг друга.
Что на самом деле содержится в загрузке объемом 17 ГБ
Вот почему описание «модель ИИ размером 17 ГБ» является вводящим в заблуждение. Файл с квантизированными весами действительно может иметь такой размер. Квантизация позволяет хранить каждый вес за счёт использования меньшего количества бит — например, 4 вместо 16, что в несколько раз уменьшает размер файла при незначительных потерях качества.
Однако файл на вашем SSD — это лишь один из компонентов, необходимых для работы процесса. Помимо него требуется память для:
- весов после их загрузки в память,
- собственных ресурсов, затрачиваемых на выполнение вычислений,
- временных буферов, используемых в процессе обработки,
- контекста, хранящегося в кэше KV,
- а также ресурсов, уже занимаемых операционной системой и другим программным обеспечением.
Следовательно, наличие файла размером 17 ГБ не означает, что устройство с 17 ГБ свободной памяти сможет комфортно запускать модель или вообще запустить её при увеличении объёма контекста.
Результаты тестирования модели Qwen3.8-27B в сообществе наглядно иллюстрируют этот факт. Квантизированная версия модели объемом около 17 ГБ может потребовать значительно больше памяти при загрузке длинного контекста, а при стандартной длине контекста модели в 262 144 токенов один только кэш KV становится очень объемным. Чтобы понять почему, необходимо рассмотреть, как модель запоминает ход разговора.
Сам разговор занимает память
Трансформер не читает ваш запрос один раз и затем игнорирует его. При генерации каждого нового токена он обращается ко всем предыдущим токенам в контексте. Пересчет внутреннего представления всего контекста для каждого нового токена был бы чрезмерно медленным, поэтому движки инференса хранят промежуточные результаты вместо этого.
Этот хранилище — это KV cache, сокращение от key/value cache. Для каждого токена в контексте каждый слой внимания хранит вектор ключа и вектор значения. Поэтому объем кэша растет примерно линейно с длиной контекста: модель, которая легко справляется с коротким чатом, может стать гораздо тяжелее при обработке десятков или сотен тысяч токенов, например всего репозитория.
Согласно информации о модели Qwen3.8-27B на Hugging Face, эта модель поддерживает нативный контекст длиной 262,144 токенов. Она использует гибридную архитектуру, в которой только некоторые слои применяют традиционное внимание, и именно это позволяет использовать такое длинное окно вообще.
Согласно одному из анализов архитектуры, для слоев, которые всё ещё используют традиционную кэш-память, на каждый токен требуется примерно 64 КБ данных кэша FP16. Умножив это значение на 262 144 токена, получаем примерно 16,8 ГБ памяти кэша KV ещё до учёта других компонентов. Примерный бюджет памяти для сессии с полным контекстом выглядит следующим образом:
- веса модели: примерно 17 ГБ
- кэш KV при полном контексте: примерно 17 ГБ
- дополнительные расходы памяти и буферы: ещё больше
Модель никогда не сокращается до размера 17 ГБ. Вы скачиваете 17 ГБ квантизированных весов, но фактическая нагрузка может быть примерно в два раза больше или даже выше. Теперь становится понятно, почему при ограниченной памяти важно учитывать длину контекста: уменьшение её вдвое приводит к примерному уменьшению объема кэша, а многие движки позволяют квантизировать сам кэш KV для дальнейшего сокращения его объема, хотя это и влечет некоторую потерю точности. Приведенные в сообществе цифры являются оценками; сравнивайте их с данными об использовании памяти, указанными вашим движком.
Как гибридное внимание позволяет обрабатывать длинные контексты
Именно в архитектуре всё становится интереснее. В традиционном трансформере каждый слой внимания хранит собственные записи KV, поэтому объем кэша растет как с увеличением количества слоев, так и количества токенов.
Согласно опубликованным анализам его архитектуры, Qwen3.8-27B использует гибридный подход. Из 64 слоев лишь относительно небольшое их количество применяет полную атенцию, в то время как большинство использует линейную атенцию. Слои с линейной атенцией сводят прошлую информацию к состоянию фиксированного размера вместо хранения ключей и значений для каждого токена, поэтому они не увеличивают объем растущей кэш-памяти. Только слои с полной атенцией влекут затраты за каждый токен, именно поэтому показатель стоимости за токен настолько низкий.
Именно такие приемы делают возможным использование очень больших окон контекста. Без них память, необходимая для ста тысяч токенов, быстро станет непрактичной даже на оборудовании, отличном от серверных центров.
Поэтому каждый раз, когда модель рекламирует огромное окно контекста, задайте дополнительный вопрос: что делает ее архитектура, чтобы сделать такой контекст доступным? Одного только размера окна контекста недостаточно для ответа на этот вопрос.
Победа в тесте-бенчмарке — не победа в целом
У заголовков есть ещё одна особенность: модель «побеждает Claude» или «побеждает GPT» в каком-то тесте-бенчмарке, и делается вывод, что она лучше в целом. Тесты-бенчмарки измеряют конкретные задачи в определённых условиях, и один результат мало что говорит о чём-либо ещё.
Qwen3.8-27B хорошо иллюстрирует это. Опубликованные результаты показывают высокие показатели в области программирования:
- Terminal-Bench 2.1, который тестирует работу в терминале: 73.0
- SWE-bench Pro, который тестирует устранение реальных проблем в репозиториях: 61.7
- GPQA Diamond, набор вопросов по науке уровня магистратуры: 89.2
Если сравнивать показатели модели Opus 4.6 Max с результатами данной модели в том же списке, то картинка неоднозначная. В тесте Terminal-Bench 2.1 показатель Qwen ниже, чем 78.2 у Opus 4.6 Max. В тесте SWE-bench Pro его показатель 61.7 превышает 53.4 у Opus. В тесте GPQA Diamond его показатель 89.2 ниже, чем 91.3 у Opus.
Какая модель лучше? Это зависит от задачи. Работа с терминалом, исправление ошибок на уровне репозитория и решение научных задач учебного уровня требуют разных навыков, так же как и задачи агентов с долгосрочными целями. Каждый тест является свидетельством лишь одной способности, а не универсальным рейтингом интеллекта.
Методология тоже имеет большое значение. Инструменты оценки, стратегия формулирования запросов, доступные инструменты, метод оценки и настройки модели могут повлиять на результаты, к тому же поставщики не всегда запускают конкурирующие модели в идентичных условиях. Утверждение вроде «Модель X превосходит Модель Y» упускает важную деталь. Более точная формулировка будет выглядеть так:
В этих условиях Модель X показала более высокие результаты по сравнению с Моделью Y в ходе данной оценки.
Это менее захватывающе, но гораздо полезнее.
Усилия по логическим рассуждениям — скрытый фактор, увеличивающий затраты
Даже после понимания параметров и объема памяти еще один фактор может незаметно повлиять на стоимость работы модели: время, которое она тратит на логические рассуждения перед ответом.
Модели, ориентированные на рассуждения, всё чаще предоставляют параметр для настройки этого процесса. Qwen3.8 поддерживает параметр reasoning_effort с уровнями low, medium и xhigh; по умолчанию выбирается уровень xhigh. В документации прямо указано, что эти уровни контролируют глубину и затраты на рассуждения.
Компромисс здесь очевиден: более сложные рассуждения могут помочь при решении трудных задач, но каждый шаг рассуждения генерирует дополнительные токены, что влечёт за собой увеличение вычислительных затрат, задержек и объёма данных в KV-кэше, особенно при длинных цепочках рассуждений. Поэтому два человека, использующие одну и ту же модель, могут столкнуться с сильно разными затратами исключительно из-за этой настройки.
Это особенно актуально для агентов, занимающихся программированием, которые выполняют задачи самого разного уровня сложности. Сравните запрос на переименование переменной с запросом на исследование незнакомого репозитория, поиск архитектурной ошибки, изменение шести файлов, запуск тестов, диагностику сбоев и создание патча. Для первого вовсе не требуется такой же мощности рассуждений, как для второго. Применение максимальных возможностей рассуждений к каждому запросу подобно тому, как привлекать старшего инженера к обсуждению метки на кнопке: это работает, но является плохим использованием ресурсов.
Существует одно ограничение, на которое указывает и сама документация Qwen. Снижение уровня нагрузки может ускорить выполнение каждого отдельного шага, но привести к большему количеству попыток или сбоев при выполнении многоэтапных задач агента, что может свести на нет полученные преимущества. Практический подход заключается в измерении общей стоимости выполнения задачи от начала до конца, а не задержки на каждом шаге, а также в направлении простых и сложных задач на разные настройки, если это позволяют инструменты. Нет единой настройки, подходящей для всего.
Почему эффективные локальные модели по-прежнему очень важны
Несмотря на все эти ограничения, легко может показаться, что идея способных небольших локальных моделей — это просто рекламный трюк. Но это не так. Прогресс действительно существует: модели с ограниченными ресурсами теперь могут выполнять серьезные задачи в области инженерии программного обеспечения, которые еще несколько лет назад было бы крайне сложно запустить локально.
Единственная необходимая корректировка заключается в том, что высокая эффективность вычислений не обязательно означает небольшое потребление памяти.
Это различие имеет ещё большее значение в масштабах центров обработки данных. Провайдер, обслуживающий тысячи пользователей, загружает веса модели один раз и использует их для всех запросов. В отличие от этого, кэш типа KV принадлежит каждому отдельному диалогу. Сокращение объёма памяти, необходимого для каждого активного диалога, позволяет разместить больше одновременных пользователей на одном оборудовании, что напрямую снижает затраты на обслуживание модели.
С такой точки зрения архитектурные детали, которые кажутся сложными исследовательскими приёмами, такие как гибридное внимание или сжатие кэша KV, становятся важными факторами экономии. Модели не обязательно должны быть маленькими везде — им достаточно быть эффективными там, где инфраструктура находится под наибольшим давлением.
Когда модель объёмом 17 ГБ действительно представляет собой отличную покупку
Есть и очень положительная сторона. Во многих реальных задачах используется короткий контекст:
- один файл,
- одна конкретная задача по программированию,
- небольшой проект,
- обычный чат.
В таких случаях хорошо квантизированный модель этого класса может быть действительно впечатляющим инструментом. Для её тестирования не требуется мощный облачный сервер. Модель с хорошими показателями можно запустить на бытовом оборудовании, сохранять данные на собственном устройстве и избегать платы за каждый токен в API при проведении экспериментов. Пример такого подхода вы найдете по ссылке «Создание локальной копии Angry Birds с использованием Qwen3.8-27B и Pi».
Это расширяет круг людей, которые могут экспериментировать с серьезными технологиями искусственного интеллекта, что, пожалуй, важнее, чем простое превосходство одного показателя над другим на три балла.
Четыре вопроса, которые стоит задать вместо «сколько параметров?»
В следующий раз, когда в заголовке указано небольшое количество параметров или небольшие размеры загрузки, рассмотрите эти четыре вопроса.
Сколько параметров находится в активном состоянии?
Это показывает, сколько вычислений требуется на один токен, и, следовательно, примерную скорость генерации модели на вашем оборудовании.
Сколько параметров существует в общей сложности?
Это указывает на общий объем ресурсов, необходимых модели, и является основным фактором, определяющим количество памяти, требуемое для хранения весов.
Насколько велика размерность кэша KV?
Это зависит от архитектуры и длины контекста, которую вы планируете использовать; при длинных контекстах этот фактор становится наиболее значимым.
Сколько времени модель тратит на обдумывание ответа?
Это влияет на задержку, потребление токенов и стоимость обработки; этот параметр можно настраивать в зависимости от конкретной задачи.
Все четыре ответа вместе говорят о гораздо большем, чем может сообщить размер файла для загрузки.
Модели стали более эффективными, но не обязательно меньшими по размеру
Общая тенденция — реальное повышение эффективности во всей структуре системы: улучшенные стратегии обучения и масштабирование данных, более эффективное распределение задач между экспертами, улучшенная квантизация, более совершенные архитектуры внимания, а также возможность настройки процесса рассуждений во время выполнения запросов.
Ни один из этих факторов не делает эффективные вычисления эквивалентными малому объему памяти:
- Модель типа MoE может активировать лишь часть своих параметров для обработки каждого токена, при этом оставаясь очень большой сетью.
- Квантизированная модель может занимать небольшое количество места на диске, но требовать гораздо больше памяти во время выполнения запросов.
- Большое окно контекста может привести к тому, что сам диалог займет несколько гигабайт.
- Более высокий уровень рассуждений может сделать один и тот же запрос гораздо более ресурсоемким с точки зрения вычислений.
Поэтому лучший вопрос — не в том, сколько параметров имеет модель. Он ближе к следующему:
Сколько памяти и вычислительных ресурсов требуется для выполнения конкретной задачи, начиная с загрузки модели и заканчивая генерацией финального токена?
Основные выводы
- Размер модели при загрузке включает только её веса; кэш KV, накладные расходы во время работы и буферы увеличивают общие требования, и при длинном контексте они могут удвоить фактические потребности.
- Активные параметры показывают количество вычислений на токен, в то время как общее число параметров определяет объем памяти, который необходимо сохранить.
- Размер кэша KV увеличивается с длиной контекста и в значительной степени зависит от архитектуры, поэтому гибридные схемы внимания критически важны для работы с длинными контекстами.
- Победы в тестах характерны для конкретных задач и зависят от методологии; следует рассматривать их как «лучшие результаты в данной оценке», а не как «лучшие в целом».