Как настроить приоритеты CPU, GPU и NPU для локального ИИ: практическое руководство

Локальный запуск языковых и генеративных моделей упирается в один вопрос: какое устройство реально будет считать вашу модель. От того, как вы распределите работу между CPU, GPU и NPU, зависит скорость генерации, отзывчивость системы и то, запустится ли модель вообще. Главный принцип простой: самые тяжёлые вычисления нужно отдать самому быстрому доступному ускорителю, а остальное оборудование использовать как вспомогательное, а не как равноправного участника. Ниже разберём, как это сделать на практике в Windows и Linux, что настраивать в популярных инструментах вроде llama.cpp, Ollama и LM Studio, и какие ошибки чаще всего убивают производительность.

Почему распределение нагрузки важнее «мощности железа»

Генерация текста или изображений локальной моделью состоит из тысяч однотипных матричных операций. Каждое устройство обрабатывает их с разной скоростью, и итоговая скорость определяется самым медленным звеном в цепочке. Если половина слоёв модели считается на GPU, а половина на CPU, система работает не «в два устройства быстрее», а примерно со скоростью медленного устройства плюс накладные расходы на передачу данных между ними.

Отсюда следуют три практических вывода:

• GPU почти всегда приоритетнее CPU для инференса больших моделей: видеопамять даёт огромную пропускную способность, которая критичнее сырой вычислительной мощности.
• NPU полезен только там, где он поддержан программным стеком. Нейропроцессор (NPU) — специализированный блок в современных мобильных и настольных чипах, оптимизированный под низкое энергопотребление при инференсе компактных моделей. Но если фреймворк вашей модели не умеет с ним работать, NPU просто простаивает.
• CPU — это страховка и фон: он выполняет то, что не поместилось в видеопамять, обслуживает токенизацию, ввод-вывод и системные задачи.

Как понять, чем вы располагаете

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

Объём и тип видеопамяти

Для дискретной видеокарты важен объём VRAM: именно в неё нужно уместить веса модели, контекст (KV-кэш) и буферы. Модель на 7–8 миллиардов параметров в 4-битном квантовании занимает порядка 4–6 ГБ, модель на 13 миллиардов — примерно 8–10 ГБ, а 30+ миллиардов параметров уже требуют 20 ГБ и больше. Это ориентировочные порядки величин: точный размер зависит от формата квантования и длины контекста. Если VRAM меньше нужного, часть модели придётся выгружать в обычную память — и скорость резко падает.

Возможности CPU

Для процессора значимы количество физических ядер, поддержка AVX2 или AVX-512 (наборы инструкций, ускоряющих матричные операции) и пропускная способность оперативной памяти. Двухканальный режим памяти даёт заметный прирост именно потому, что инференс на CPU часто упирается не в вычисления, а в чтение весов из памяти.

Наличие и уровень поддержки NPU

NPU есть в ряде современных процессоров Intel Core Ultra, AMD Ryzen AI и Snapdragon. Само по себе его наличие ничего не гарантирует: нужен драйвер, среда исполнения (например, DirectML, ONNX Runtime или OpenVINO в зависимости от платформы) и модель, сконвертированная под этот стек. Проверьте на сайте производителя вашего чипа, какие инструменты официально поддерживают NPU, и уточните актуальное состояние поддержки — эта область быстро меняется, и сведения на дату покупки могут устареть.

Стратегия по умолчанию: GPU-first

Если у вас есть дискретная видеокарта с достаточным объёмом VRAM, базовая настройка выглядит так:

1. Загрузите модель в квантованном формате (4-битные варианты вроде Q4_K_M в экосистеме GGUF — разумный компромисс между качеством и размером).
2. Выгрузите на GPU максимально возможное число слоёв так, чтобы вместе с KV-кэшем они поместились в VRAM с запасом 10–20%.
3. Оставьте CPU обработку системных задач, токенизации и, при необходимости, нескольких последних слоёв.
4. Проверьте фактическую загрузку устройств через диспетчер задач (Windows) или nvidia-smi / nvtop / radeontop (Linux).

В llama.cpp и его графических оболочках за это отвечает параметр n-gpu-layers (в LM Studio — ползунок «GPU Offload», в Ollama — автоматическое размещение с возможностью влияния через переменные окружения). Начните с полного переноса всех слоёв; если система зависает или падает с ошибкой нехватки памяти, снижайте число слоёв шагами по несколько штук, пока не найдёте устойчивое значение.

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

Когда и как задействовать NPU

NPU имеет смысл рассматривать в трёх сценариях:

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

На практике подключение NPU выглядит так: установите драйвер и среду исполнения от производителя платформы, возьмите модель в совместимом формате (чаще всего ONNX), конвертируйте или скачайте версию, собранную под ваш NPU, и укажите эту среду исполнения в приложении. Важно понимать ограничение: популярные инструменты для запуска LLM, построенные вокруг CUDA и GGUF, исторически ориентированы на GPU и CPU, и поддержка NPU в них появляется постепенно и неравномерно. Перед покупкой ноутбука «ради NPU» проверьте, что конкретные программы, которые вы планируете использовать, действительно умеют с ним работать — маркетинговая поддержка чипа и реальная поддержка в вашем софте не одно и то же.

Роль CPU: когда он главный, а когда вспомогательный

CPU становится основным устройством в двух случаях: когда дискретной видеокарты нет вовсе и когда модель слишком велика даже для частичной выгрузки. Тогда задача настройки меняется: нужно выжать максимум из подсистемы памяти.

Что реально влияет на скорость инференса на CPU:

• Двухканальная или четырёхканальная память. Пропускная способность RAM — узкое место номер один. Установка второй планки памяти в ноутбук нередко ускоряет генерацию сильнее, чем любой программный твик.
• Поддержка AVX2/AVX-512. Собирайте или выбирайте сборки llama.cpp с поддержкой набора инструкций, который есть в вашем процессоре.
• Число потоков. Параметр n-threads обычно оптимально ставить равным числу физических ядер, без гиперпоточности: логические ядра добавляют накладные расходы, а не скорость. Проверьте экспериментально значения «физические ядра» и «физические минус одно» — иногда резервирование одного ядра под систему даёт более плавный результат.
• Отсутствие конкуренции. Закройте браузер с десятками вкладок, индексацию и обновления на время генерации: фоновые процессы отбирают память и кэш.

Смешанный режим: гибридная выгрузка

Когда модель не помещается в VRAM целиком, применяется частичная выгрузка: часть слоёв на GPU, остальные на CPU. Здесь важно понимать механику. Слои обрабатываются последовательно, поэтому активации каждый раз перемещаются между видеопамятью и оперативной памятью. Чем больше граница раздела, тем больше обменов и тем ниже скорость. Поэтому правило такое: лучше уменьшить размер модели или квантование и уместить её целиком в VRAM, чем гонять большую модель пополам между устройствами.

Условный пример: видеокарта с 8 ГБ VRAM. Модель на 14 миллиардов параметров в 4-битном формате займёт около 8–9 ГБ только весами, плюс контекст — целиком не влезает. Альтернатива: взять модель на 7–8 миллиардов в том же квантовании (4–5 ГБ) с запасом под длинный контекст. Второй вариант почти всегда даст более высокую скорость и предсказуемое поведение, хотя первая модель «умнее» на бумаге.

Конфигурация системы	Приоритет устройств	Что настроить в первую очередь
Дискретная GPU с большой VRAM	GPU → CPU → NPU	Полная выгрузка слоёв, контроль свободной VRAM под контекст
GPU со средней VRAM	GPU + частично CPU	Меньшая модель или более сильное квантование, чтобы уйти от смешанного режима
Ноутбук с NPU, без дискретной GPU	NPU для лёгких задач, CPU для LLM	Среда исполнения производителя, модели в поддерживаемом формате
Только CPU	CPU	Двухканальная память, AVX-сборки, подбор числа потоков
iGPU (встроенная графика)	iGPU + CPU	Выделение фиксированного объёма общей памяти под графику, умеренный контекст

Приоритеты на уровне операционной системы

Помимо распределения самой модели, стоит управлять тем, как ОС распределяет ресурсы между процессами.

Windows

В диспетчере задач на вкладке «Подробности» можно задать приоритет процесса (например, «Высокий» для сервера инференса) и привязку к ядрам (affinity). Это оправдано, когда модель работает долго в фоне и вы параллельно пользуетесь компьютером: привязав процесс к части ядер, вы оставите остальным отзывчивость интерфейса. Не ставьте приоритет «Реального времени» — это может привести к подвисанию всей системы. Для гибридных процессоров с разными по производительности ядрами (P-cores и E-cores) привязка тяжёлого процесса к производительным ядрам иногда даёт ощутимый выигрыш, но требует эксперимента на вашей конкретной машине.

Linux

Здесь доступны утилиты nice/renice для приоритета, taskset для привязки к ядрам и cgroups для ограничения ресурсов. Для постоянного фонового сервиса удобно описать лимиты в юните systemd. Принцип тот же: выделить инференсу стабильную долю ресурсов, не отбирая всё у интерактивных задач.

Энергоплан

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

Контекст и KV-кэш: недооценённый потребитель памяти

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

Практические ориентиры:

• Начинайте с умеренного контекста (например, 4–8 тысяч токенов) и увеличивайте его, наблюдая за свободной VRAM.
• Если инструмент позволяет выбирать реализацию внимания (flash attention и подобные), включение такой оптимизации обычно снижает расход памяти на контекст — проверьте поддержку в вашей сборке.
• Следите за поведением при длинных диалогах: деградация скорости по мере роста переписки — признак того, что кэш перестал помещаться.

Типичные ошибки и их последствия

• Частичная выгрузка «по привычке». Значение слоёв по умолчанию оставляет половину работы CPU. Симптом: GPU загружен рывками, скорость низкая при свободной VRAM. Решение: увеличить число слоёв до максимума, который держится стабильно.
• Игнорирование памяти под контекст. Модель запускается, но падает на длинном запросе. Решение: закладывать запас 10–20% VRAM и тестировать максимальную длину запроса заранее.
• Слишком много потоков на CPU. Установка числа потоков равным числу логических ядер часто замедляет генерацию. Решение: физические ядра, затем тонкая подстройка.
• Ожидания от NPU без проверки софта. Пользователь покупает устройство ради NPU, а его основной инструмент этот блок не использует. Решение: проверить список поддерживаемых приложений и моделей до покупки.
• Одновременный запуск нескольких тяжёлых задач. Генерация изображений на фоне работы LLM заставляет устройства делить ресурсы, и обе задачи замедляются непредсказуемо. Решение: очередность вместо параллельности, если нет избытка ресурсов.
• Перегрев и троттлинг. Ноутбук в режиме производительности без охлаждающей подставки снижает частоты через минуты работы. Решение: мониторинг температур и чистка системы охлаждения.

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

Оценка результата строится на наблюдаемых показателях, а не на ощущениях:

1. Замерьте скорость генерации в токенах в секунду — большинство инструментов показывает её в логе или интерфейсе. Зафиксируйте значение до изменений.
2. Во время генерации откройте мониторинг: загрузка GPU должна быть стабильно высокой при полной выгрузке; загрузка CPU — умеренной.
3. Проверьте потребление VRAM в покое и под пиковой длиной контекста. Свободный запас должен оставаться.
4. Оцените отзывчивость системы при фоновом инференсе: курсор, окна и видео не должны заметно подтормаживать.
5. Повторите замер после каждого изменения ровно одним параметром — иначе не поймёте, что именно дало эффект.

Сценарии действий под разные условия

Есть игровая видеокарта с 12+ ГБ VRAM. Ваш путь — GPU-first без компромиссов: полная выгрузка, квантование Q4/Q5, комфортный контекст. NPU и CPU в расчёт не берите, кроме случаев, когда GPU занят другой задачей.

Видеокарта на 6–8 ГБ. Подбирайте модель под объём памяти, а не наоборот. Модели 7–9 миллиардов параметров в 4-битном формате — рабочая зона. Экспериментируйте с квантованием: иногда Q5 меньшей модели даёт лучший практический результат, чем Q4 большей.

Современный ноутбук с NPU без дискретной графики. Разделите задачи: лёгкий постоянный ИИ-фон (распознавание, ассистентские функции) — на NPU через поддерживаемые приложения, основную языковую модель — на CPU/iGPU с упором на память и потоки. Реалистичных ожиданий по скорости придерживайтесь: это конфигурация «работает», а не «летает».

Старый ПК только с CPU. Ставьте компактные модели (до 7 миллиардов параметров), обеспечьте двухканальную память, используйте AVX2-сборки и не рассчитывайте на большие контексты. Это сценарий для экспериментов и неторопливых задач.

С чего начать прямо сейчас

Определите объём VRAM и наличие NPU в вашей системе, затем выберите строку из таблицы выше, соответствующую вашей конфигурации. Дальнейший порядок простой: запустите модель с полной выгрузкой на самый быстрый поддерживаемый ускоритель, замерьте базовую скорость, после чего меняйте по одному параметру — число слоёв, квантование, размер контекста, число потоков — фиксируя результат каждого изменения. Через несколько итераций вы получите конфигурацию, которая на вашем железе даёт максимум скорости без нестабильности. И помните: программная поддержка NPU и рекомендации по квантованию быстро развиваются, поэтому перед крупными решениями (например, покупкой оборудования под конкретные задачи) сверьтесь с актуальной документацией используемых вами инструментов.

Материал носит информационный характер. Конкретные параметры, названия настроек и уровень поддержки оборудования зависят от версии ПО, драйверов и модели устройства — сверяйтесь с официальной документацией ваших инструментов и производителя железа перед принятием решений о покупке или изменении системных настроек.