CPU или GPU для локальной LLM: что выгоднее

MAATRIX

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

Почему GPU в принципе быстрее: дело в памяти, а не в ГГц

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

потолок, ток/с ≈ пропускная способность памяти (ГБ/с) / размер весов (ГБ) × 0,7

Поправка 0,7 — не пессимизм, а честность: реальная пропускная способность всегда ниже паспортной, часть трафика уходит на KV-кэш и служебные буферы. Дальше решает числитель — сколько гигабайт в секунду умеет прокачать железо.

Здесь CPU и GPU расходятся не на проценты, а в разы. Двухканальная память сервера: DDR4-3200 даёт эффективные 30–38 ГБ/с на чтение, DDR5-4800 — 55–65 ГБ/с. Видеопамять устроена принципиально шире:

Даже младшая в списке L4 обгоняет DDR5 в 4,5–5,5 раза, а H100 — в 50–60 раз. Заметьте: RTX 4060 Ti новее RTX 3060, но по памяти медленнее — 128-битная шина против 192-битной. Поколение карты само по себе ничего не гарантирует.

Оговорка: правило про генерацию (decode). Обработка промпта (prefill) считает всю входную последовательность разом и упирается в вычисления, а не в память — здесь CPU выглядит куда приличнее.

CPU: сколько реально получаете и когда этого достаточно

У нас есть реальный стенд, а не оценка на глаз: AMD EPYC 9554, 16 vCPU (8 физических ядер плюс гипертреды), DDR5, Ollama 0.33.1, модели в Q4_K_M, контекст 4096. На qwen2.5:7b генерация выходит на полку уже на 4 потоках — 7,6 ток/с, на 8 и 16 то же самое в пределах погрешности. А на 32 потоках при тех же 16 vCPU скорость обваливается до 0,35 ток/с — в двадцать раз, а не «немного медленнее»: потоки вытесняют друг друга с ядер вместо параллельного чтения памяти. Полный разбор с htop, cgroup и NUMA — в статье про ядра CPU у Ollama; вывод один: лишние ядра генерацию не ускоряют начиная с четырёх-восьми штук.

Интереснее то, что происходит между разными моделями на одном и том же железе. Замер на 16 потоках, тот же стенд:

Прочерк — память под эту модель отдельно не переизмеряли. Две вещи бросаются в глаза. qwen2.5:3b обгоняет пропорцию весов: в 2,3 раза меньше qwen2.5:7b по памяти, а быстрее — почти в 4,6 раза; у младшей модели меньше слоёв, и накладные расходы на шаг генерации занимают меньшую долю времени. А gemma2:9b медленнее llama3.1:8b, хотя параметров в ней меньше, — у Gemma2 словарь около 256 тысяч токенов против ~128 тысяч у Llama 3.1, и слой предсказания следующего токена заметно шире. Формула по одной пропускной способности даёт порядок величины, а не точное число — остальное решает архитектура.

Практический вывод: 7–13 ток/с быстрее, чем читает большинство людей (комфортная скорость чтения — примерно 4–6 токенов в секунду). Для личного чата, помощника в терминале, ночной суммаризации и внутреннего RAG на одного-двух человек CPU честно хватает, GPU не нужен. Граница — там, где к диалогу подключаются сразу несколько человек: генерация одна на всех, и 7–8 ток/с делятся на число запросов.

GPU: когда без него генерация не спасается никакими настройками

Три ситуации, где CPU не вытянуть ни num_thread, ни квантованием.

Несколько пользователей одновременно. На CPU параллельные запросы делят одну пропускную способность памяти: qwen2.5:7b даёт 7,4 ток/с одному диалогу, а на пять одновременных — в разы меньше на каждого, потому что каждый запрос заново читает все веса. На GPU запросы объединяются в один проход: умножение вектора на матрицу становится умножением матрицы на матрицу, веса читаются один раз на всю пачку — задача из упирающейся в память превращается в упирающуюся в вычисления, где у видеокарты преимущество ещё больше.

Модели крупнее 30 млрд параметров. Формула из первой секции жёстко режет CPU на больших весах: 32B в Q4_K_M — это порядка 20 ГБ, и на тех же 55–65 ГБ/с DDR5 расчётный потолок — 55×0,7/20 ≈ 1,9, максимум 65×0,7/20 ≈ 2,3 ток/с. Дочитать ответ в три абзаца можно успеть заварить чай. GPU с 24 ГБ VRAM и полосой в 600–1000 ГБ/с меняет этот потолок на порядок — но это расчёт по формуле, не измерение: GPU-бенчмарков у нас нет.

Обучение и дообучение. Инференс читает веса один раз на токен, а обучение хранит для каждого параметра ещё градиент и состояния оптимизатора. Полное дообучение 7B в смешанной точности с Adam — это примерно 16 байт на параметр (веса и градиенты в fp16, master-копия и два момента Adam в fp32), то есть около 112 ГБ VRAM только на состояние обучения, без активаций. Отсюда LoRA/QLoRA — способы не хранить всю эту массу; но даже они делаются на GPU, потому что обратный проход требовательнее к параллелизму, чем прямой. На CPU дообучение технически возможно, практически — его никто в здравом уме не делает: разница не в разы, а в порядки.

Экономика: во сколько раз дороже GPU и когда переплата окупается

Видеокарта — самый дорогой компонент сервера: это не жадность провайдера, а физика счёта за электричество и цена чипа. Топовая карта под нагрузкой ест 300–450 Вт, CPU-сервер для 7–9B моделей укладывается в 65–150 Вт целиком, плюс сама карта уровня A10 или A100 в закупке сопоставима с несколькими CPU-серверами сразу. В сумме GPU-сервер в месяц обходится в разы дороже CPU-сервера сравнимого класса — так устроено у любого провайдера, и спорить с физикой бессмысленно.

Вопрос не «что дешевле», а «что выгоднее для вашей задачи». Три честных ориентира.

• Модель до 9B, пользователь один или пара, ответ не обязан быть мгновенным. CPU-сервер отбивает разницу сразу: вы платите за память и ядра, а не за карту, которая простаивает девять часов из десяти.
• Нагрузка эпизодическая — раз в неделю дообучить LoRA, прогнать пакет изображений, протестировать модель покрупнее. Переплачивать за круглосуточный GPU-сервер невыгодно; честнее почасовая аренда на нужные часы, а не постоянная дорогая машина. Разбор, когда так выгоднее, — в статье про свою карту против аренды GPU.
• Нагрузка постоянная и параллельная — десятки пользователей, продукт с живым чатом, регулярное обучение. Здесь считать разницу в цене бессмысленно: CPU-сервер того же класса физически не тянет задачу, вопрос не «дешевле ли CPU», а «работает ли он вообще».

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

Частые ошибки при выборе между CPU и GPU

Берут CPU-сервер с максимумом vCPU, ожидая пропорциональный прирост. Наш замер выше: 32 потока на 16 vCPU дают не «немного медленнее», а 0,35 ток/с вместо 7,6 — обвал в двадцать раз из-за конкуренции потоков за ядра. Для CPU-инференса важнее объём и скорость памяти, чем строчка с числом ядер в тарифе.

Берут GPU впритык по VRAM «попробовать». Если модель с контекстом и KV-кэшем не помещается в память карты целиком, движок либо откажет с ошибкой, либо начнёт выгружать часть слоёв в системную RAM — и скорость падает кратно, а не на проценты. При инференсе через vLLM или TGI это выглядит примерно так:

torch.cuda.OutOfMemoryError: CUDA out of memory. Tried to allocate 256.00 MiB.
GPU 0 has a total capacity of 23.64 GiB of which 98.31 MiB is free.

Разбор именно этой ошибки и как посчитать VRAM заранее — в статье про vLLM и нехватку памяти.

Сравнивают цифры разных квантований как одинаковые. Требование «нужна модель 7B» без уточнения кванта — не число: в fp16 это ~14 ГБ, в Q8_0 — ~7,5 ГБ, в Q4_K_M — ~4,7 ГБ. Спорить, нужен ли GPU «для 7B», без кванта — как спорить о температуре без термометра. Проверить занятость уже арендованной карты просто: nvidia-smi в обычный рабочий день покажет, простаивает она большую часть времени или действительно нагружена.

Как посчитать под свою задачу: пошаговый пример

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

1. Определяем вес модели. 14B в Q4_K_M — около 9 ГБ, плюс KV-кэш под контекст 8k — ещё 1,5–2 ГБ.
2. Считаем потолок на CPU. DDR5 даёт 55–65 ГБ/с эффективно; возьмём консервативные 35 ГБ/с, как на разделяемой памяти VPS: потолок одного запроса — 35×0,7/9 ≈ 2,7 ток/с. Пятерым одновременно делить особо нечего — очередь неизбежна.
3. Считаем потолок на GPU. 9 ГБ весов свободно помещаются в карту от 12 ГБ с запасом на контекст. Даже младшая в списке L4 (300 ГБ/с) даёт расчётный потолок 300×0,7/9 ≈ 23 ток/с — не измерение, а тот же расчёт, просто с другим числителем. С батчингом пятеро пользователей не делят эти токены так же болезненно, как на CPU — эффект батчинга разобран в статье про ядра CPU выше.
4. Сверяем с реальной нагрузкой. Если пятеро пишут ассистенту по паре сообщений в час — CPU-сервер справится, очередь никто не заметит. Если это живой чат с одновременными диалогами весь рабочий день — берите GPU, иначе интерфейс будет казаться сломанным, хотя технически всё работает.

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

Какой сервер брать в MAATRIX: с CPU или сразу с GPU

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

Минимум для CPU-инференса. 4 физических ядра с поддержкой AVX2, 16 ГБ RAM, 60 ГБ NVMe. Помещается модель на 7–8B в Q4_K_M с запасом под KV-кэш и систему, честные 7–8 ток/с на диалог — быстрее, чем читает человек. Для личного помощника, ночной суммаризации и внутреннего RAG на одного-двух пользователей это рабочая, а не урезанная конфигурация.

Комфортный вариант. 8 физических ядер, 32 ГБ RAM, 100+ ГБ NVMe. Свободно идёт 14B, помещаются сразу две модели (OLLAMA_MAX_LOADED_MODELS=2), есть запас под несколько параллельных запросов без ухода в своп. Это уровень, где CPU можно честно назвать комфортным, а не «пока терпимо».

Ollama устанавливается автоматически при заказе сервера из каталога apps.maatrix.io — на Ubuntu и Debian, без ручной установки, доступы появляются в личном кабинете сразу. Локация — Великобритания, Лондон: модель держит переписку и документы в европейском правовом периметре, что снимает вопросы у клиентов с GDPR, а пинг до ЕС держится в районе 10–25 мс.

И честная граница. Если по разделам выше у вас получилось «нужен GPU» — параллельные пользователи, модель крупнее 30B или обучение, — у MAATRIX есть выделенные серверы с GPU в тех же локациях, включая Великобританию: конфигурация подбирается под нужный объём VRAM, а не наоборот. Разбор конкретно под инференс — в статье про GPU-сервер в UK. Оплата в обоих случаях одинаковая — картой российского банка, по СБП, криптовалютой или токеном MAAT, зарубежная карта не нужна ни для CPU-, ни для GPU-сервера в Лондоне.

Частые вопросы