Сколько памяти нужно для локального ИИ: выбор моделей 7B, 14B и 32B

Для локальной модели 7B практичный ориентир — 16 ГБ оперативной или объединённой памяти: такой объём совпадает с базовой рекомендацией LM Studio. Для 14B разумно готовить 24–32 ГБ, а для 32B — около 48 ГБ; это расчётные диапазоны с резервом поверх опубликованной битности форматов GGUF, а не универсальные требования производителей моделей.

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

Ориентиры для первого выбора

Следующая памятка рассчитана на одну текстовую модель, один активный запрос и умеренный контекст. Она помогает отсеять заведомо тяжёлые файлы, но не заменяет проверку конкретной архитектуры в Ollama, LM Studio или другом движке.

• 7B в Q4 или Q5: начните с 16 ГБ общей памяти — это редакционный ориентир, согласующийся с рекомендацией LM Studio по оперативной памяти.
• 14B в Q4 или Q5: закладывайте 24–32 ГБ; диапазон добавляет системный и рабочий резерв к весам, рассчитанным по битности Q4_K и Q5_K.
• 32B в Q4 или Q5: ориентируйтесь примерно на 48 ГБ общей памяти, поскольку одна расчётная масса весов достигает примерно 18–22 ГБ по описанию квантования GGUF, а системе, кэшу и буферам требуется дополнительное место.
• 32B в Q8 или работа с длинным контекстом: рассматривайте 64 ГБ и более; восьмибитные веса такого класса дают расчётную нижнюю оценку около 32 ГБ на основании спецификации Q8_0.

Указанные объёмы относятся к общей памяти компьютера. На ПК с дискретной видеокартой отдельно проверьте VRAM: большой объём ОЗУ позволяет запустить модель через CPU или частично перенести её с GPU, но не увеличивает физическую видеопамять.

Как параметры модели превращаются в гигабайты

Обозначения 7B, 14B и 32B приблизительно показывают число параметров. Квантование сохраняет веса с меньшей точностью, сокращая файл и потребление памяти, однако формат GGUF также содержит метаданные и тензоры, поэтому реальный размер файла не всегда равен простой арифметической оценке.

Для предварительного расчёта умножьте количество параметров на среднее число бит на вес и разделите результат на восемь. Таблица типов GGUF указывает 4,5 бита на вес для Q4_K и 5,5 бита для Q5_K, а Q8_0 описывает как восьмибитное квантование.

• Для 7B расчётная нижняя оценка весов составляет около 3,9 ГБ в Q4_K, 4,8 ГБ в Q5_K и 7 ГБ в Q8_0 по опубликованному числу бит на вес.
• Для 14B та же формула даёт примерно 7,9 ГБ в Q4_K, 9,6 ГБ в Q5_K и 14 ГБ в Q8_0 на основе характеристик типов квантования.
• Для 32B получаются примерно 18 ГБ в Q4_K, 22 ГБ в Q5_K и 32 ГБ в Q8_0, если применить заявленную битность GGUF.

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

Как выбирать между Q4, Q5 и Q8

Q4 — рациональная отправная точка, если вы ограничены памятью или только проверяете пригодность модели. Более компактный файл оставляет больше пространства контексту и повышает вероятность полного размещения нагрузки на GPU.

Расчётные веса Q5_K примерно на 22% тяжелее Q4_K: соотношение получается из значений 5,5 и 4,5 бита на вес, приведённых в документации Hugging Face по GGUF. Дополнительная точность хранения может быть полезна, но размер улучшения качества зависит от модели и задачи.

Q8_0 требует почти вдвое больше места, чем четырёхбитный ориентир, что следует из описания восьмибитного и четырёхбитного квантования. Если Q8 вынуждает переносить слои в системную память, Q5 или Q4 часто оказывается практичнее благодаря более быстрому размещению.

Не считайте 7B Q8 прямой заменой 14B Q4 только из-за похожего размера файла. Первый вариант точнее хранит веса меньшей модели, второй использует больше параметров при сильном сжатии. Сравнивайте их одинаковыми рабочими запросами: извлечением данных, резюмированием, ответами по документу или генерацией кода.

Почему одного размера файла недостаточно

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

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

Файл или раздел подкачки иногда позволяет завершить загрузку при нехватке ОЗУ, но накопитель не становится полноценной оперативной памятью. Постоянный обмен с диском резко ухудшает отзывчивость, поэтому для регулярной работы лучше уменьшить модель, степень точности весов или контекст.

Как окно контекста меняет требования

Контекст — количество токенов, доступных модели при обработке запроса. Руководство Ollama прямо предупреждает, что увеличение окна повышает потребление памяти, и предлагает проверять перенос нагрузки командой ollama ps.

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

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

Текущая документация Ollama назначает по умолчанию контекст 4K при объёме VRAM менее 24 ГиБ, 32K при 24–48 ГиБ и 256K начиная с 48 ГиБ, согласно таблице автоматических настроек приложения. Эти пороги описывают поведение Ollama, но не гарантируют, что любая модель сможет использовать выбранное окно без переноса на CPU.

Кэш контекста допускает отдельное квантование: справка Ollama о кэше сообщает, что q8_0 занимает приблизительно половину памяти f16, а q4_0 — около четверти. Более сильное сжатие может заметнее менять ответы при длинном контексте, причём результат зависит от архитектуры и задачи.

Сколько видеопамяти закладывать

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

• Для 7B ориентируйтесь на 5–6 ГБ VRAM с Q4, 6–7 ГБ с Q5 и 9–10 ГБ с Q8; диапазоны добавляют рабочий резерв к арифметическому размеру квантованных весов.
• Для 14B закладывайте 10–12 ГБ с Q4, 12–14 ГБ с Q5 и 16–18 ГБ с Q8, используя битность GGUF только как нижнюю основу расчёта.
• Для 32B предварительные цели составляют 22–24 ГБ с Q4, 26–28 ГБ с Q5 и 36–40 ГБ с Q8; это редакционный резерв поверх расчётного объёма весов.

Если модель не помещается в VRAM, движок может перенести часть слоёв или вычислений в системную память. Такой режим расширяет выбор запускаемых моделей, но обычно уступает полному размещению на GPU по скорости.

Опубликованный Windows Central показательный тест проводился с DeepSeek-R1 14B, RTX 5080 с 16 ГБ VRAM, 32 ГБ DDR5 и Intel Core i7-14700K: при контексте до 16K и полной загрузке GPU автор получил около 70 токенов в секунду. При увеличении до 32K результаты того же испытания показали распределение 21% нагрузки на CPU и 79% на GPU, а скорость снизилась до 19,2 токена в секунду.

Автор публикации прямо называет проверку простой иллюстрацией, а не всесторонним испытанием. Результат нельзя переносить на другие модели и компьютеры как норму, но он наглядно показывает возможное последствие нехватки видеопамяти.

Чем различаются обычный ПК и Mac

На ПК с дискретной видеокартой ОЗУ и VRAM — разные пулы. Дополнительная системная память помогает при работе через CPU или смешанном размещении, однако не устраняет ограничение видеокарты.

В компьютерах Mac с Apple Silicon центральный и графический процессоры используют объединённую память, но модель не получает её целиком. Требования LM Studio для Mac рекомендуют 16 ГБ и более, а для конфигураций с 8 ГБ советуют выбирать небольшие модели и умеренный контекст.

При выборе Mac разумно заранее учитывать следующий нужный класс модели, поскольку память приобретается вместе с устройством. Для настольного ПК отдельно оцените возможность расширения ОЗУ и доступный объём VRAM: модернизация одного пула не заменяет второй.

Как проверить фактическое потребление

Окончательное решение принимайте после запуска точного файла с рабочим контекстом. Оценивайте не только появление ответа, но и пиковое потребление, распределение нагрузки и устойчивую скорость генерации.

1. Запишите точное имя файла GGUF, его размер, вариант квантования и планируемое окно контекста.
2. Закройте тяжёлые приложения и зафиксируйте свободную оперативную и видеопамять до загрузки.
3. Запустите воспроизводимый запрос, близкий по длине и типу к вашей обычной работе.
4. В Ollama выполните ollama ps: описание столбца Processor объясняет обозначения полного размещения на GPU, работы в системной памяти и смешанного режима.
5. Если появился перенос на CPU, сначала уменьшите контекст или перейдите с Q8 на Q5 либо Q4. При сохранении проблемы выберите меньший класс модели.
6. После успешного размещения сравните варианты квантования одинаковыми запросами и оставьте наиболее компактный файл с приемлемым качеством.

Сервер с несколькими пользователями проверяйте отдельно: документация Ollama о параллельных запросах приводит пример, где четыре запроса с контекстом 2K создают эффективный контекст 8K и требуют дополнительной памяти. Потребление растёт вместе с числом одновременно обрабатываемых запросов и установленным окном.

Что делать перед загрузкой модели

Сначала выберите Q4 и посмотрите точный размер файла. Для 7B подготовьте около 16 ГБ общей памяти по базовому ориентиру LM Studio; для 14B заложите 24–32 ГБ, а для 32B — около 48 ГБ как расчётный резерв поверх размера квантованных весов GGUF.

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

Читайте также:

• Ramp Router: как маршрутизация ИИ-моделей снижает расходы на 30%