Зачем компании свой LLM‑кластер на обычных серверах, если есть A100 и облака
Слово «LLM» обычно тянет за собой две ассоциации: «дорогие GPU» и «платить за токены в облаке». Но если вы строите внутренние сервисы, а не новый ChatGPT, архитектура может быть гораздо проще и дешевле: кластер из нескольких CPU‑серверов в своём периметре.
Разберёмся, что даёт такой подход на практике и как по цене одной A100 собрать кластер, который по объёму обработки запросов её догоняет, а по управляемости даже выигрывает.
Какие задачи LLM реально решает в бизнесе
В большинстве кейсов компаниям нужны не «магические генерации», а очень конкретные вещи:
- вытащить из письма или заявки ключевые параметры (клиент, продукт, сумма, сроки) и вернуть строгий JSON по схеме;
- понять тип запроса: поддержка, продажа, риск, жалоба — чтобы отправить дальше в нужный сервис;
- сделать семантический поиск по документам через векторные представления (embeddings).
Это короткие и относительно простые запросы. Для них не нужны гигантские 70B‑модели: достаточно компактных LLM до нескольких миллиардов параметров, если их аккуратно сжать и держать у себя.
Какие модели мы реально гоняем и с какой скоростью
В тестах использовались две компактные, квантованные модели:
- примерно 0,6B параметров — маленький LLM для простых инструкционных задач;
- примерно 4B параметров — уже тяжелее, но всё ещё «лайт» по меркам LLM.
На одном CPU‑сервере с AVX‑512 (AMD EPYC) получилось следующее (на квантованных весах):
- модель 0,6B: примерно 125 токенов в секунду;
- модель 4B: примерно 22 токена в секунду.
Для типичных задач (извлечение сущностей, JSON‑ответы, классификация, векторные представления) этого часто более чем достаточно:
- лёгкие сценарии можно гонять на 0,6B и получать хорошую скорость;
- 4B подходит, когда нужен чуть более «умный» ответ, но всё ещё без тяжёлого GPU.
Переводим скорость в годовую мощность
Возьмём лёгкую модель 0,6B с 125 токенами/сек как ориентир для экономических расчётов.
125 токенов/сек → это примерно:
- ~324 млн токенов в месяц;
- ~3,9 млрд токенов в год на один сервер.
Даже если вы ориентируетесь на более тяжёлую модель 4B (22 токена/сек), порядок понятен: цифру можно грубо делить на 5–6 и всё равно получать сотни миллионов — около миллиарда токенов в год на сервер для типовых задач.
Ключевой момент: это on‑prem. Вы платите за железо и эксплуатацию, а не за каждый токен во внешнем API.
Сколько стоит CPU‑сервер и сколько — A100
Ориентиры по стоимости железа:
- сервер на AMD EPYC 9015 с AVX‑512 — порядка 375 тыс. руб.;
- одна NVIDIA A100 (только видеокарта, без сервера) — порядка 2,44 млн руб.
По сути, по цене одной A100 вы можете купить около шести CPU‑серверов на EPYC.
Это сразу меняет угол зрения: выбор не «GPU или CPU», а «1×A100 или 6×EPYC‑серверов».
Что даёт кластер из 2–6 CPU‑серверов
Для лёгкой модели 0,6B с 125 ток/сек на сервер цифры такие:
- 1 сервер → ~125 ток/сек, ~3,9 млрд токенов/год;
- 2 сервера → ~250 ток/сек, ~7,8 млрд токенов/год;
- 4 сервера → ~500 ток/сек, ~15,6 млрд токенов/год;
- 6 серверов (примерно как одна A100 по цене) → ~750 ток/сек, ~23,3 млрд токенов/год.
Преимущество не только в объёме, но и в том, как это масштабируется:
- запросы распределяются между независимыми машинами;
- при росте нагрузки вы добавляете сервер, а не пытаетесь выжать ещё немного из уже забитого GPU;
- профиль задержек (latency) остаётся предсказуемым.
Отсюда два управленческих тезиса:
- 2–4 CPU‑сервера по годовому объёму обработки догоняют один A100, при этом проще держать SLA по задержке.
- По цене одной A100 можно взять шесть CPU‑серверов и получить кластер, который по количеству токенов в год заметно её обгоняет.
А как же GPU? Реальный опыт с RTX 5090 и A100
GPU из этой картины не исчезают — у них своя роль. Ниже — цифры из конкретного тестового стенда; это не универсальный бенчмарк, но хороший ориентир по порядку.
На реальных тестах с компактной моделью получилось так:
- RTX 5090 даёт ~300–600 ток/сек на одиночных запросах;
- при нагрузке всего 5 запросов в секунду задержка растёт до ~700 мс–3 секунд;
- A100 на той же модели работает примерно в 2–2,5 раза медленнее RTX 5090 в этом сценарии.
Независимые бенчмарки подтверждают: современные RTX часто обгоняют A100 на небольших моделях, но упираются не только в вычислительную мощность, а в пропускную способность и латентность памяти.
Что это означает для архитектуры:
- один, даже очень быстрый GPU плохо масштабируется по параллельным запросам — при росте количества запросов в секунду вы упираетесь в память и платите задержками (latency);
- GPU отлично подходят для тяжёлых моделей и длинных контекстов, но не обязаны обслуживать весь поток простых задач.
Почему ставка только на «большой GPU» рискованна для on‑prem
С точки зрения бизнеса:
- GPU класса A100/H100 — дорогие и дефицитные. Привязка масштабирования LLM только к ним — стратегический риск.
- Один или два GPU становятся «бутылочным горлышком» для десятков сервисов: при пике нагрузок SLA неизбежно страдает.
- Любые изменения в задачах или моделях приводят к пересборке всей схемы обслуживания запросов.
CPU‑кластер, наоборот, даёт:
- доступное железо, которое проще купить/арендовать и нарастить по мере необходимости;
- понятную модель масштабирования — добавили ещё один сервер, получили плюс X токенов/сек;
- стабильный latency‑профиль при горизонтальном масштабировании.
Рабочая стратегия: CPU‑кластер как база, GPU — по делу
Здравый подход для компании, которая хочет свой LLM‑контур, выглядит так:
CPU‑кластер (EPYC/AVX‑512) — основа платформы
- ведёт массовые сценарии: entity extraction, структурированные ответы в JSON, классификацию, embeddings, простую маршрутизацию;
- даёт десятки миллиардов токенов в год при понятном CAPEX (по цене одной A100 — до шести серверов).
GPU (RTX 5090 / A100 и выше) — точечный ресурс
- подключается для действительно тяжёлых моделей и длинных контекстов;
- не является единственной точкой входа для всех LLM‑запросов.
Экономика и управляемость
- вы считаете не «стоимость миллиона токенов у провайдера», а «сколько запросов в год обслуживает наш кластер за такой‑то CAPEX»;
- масштабирование похоже на привычные для ИТ‑директора задачи по росту инфраструктуры, а не на охоту за редкими GPU;
- при этом при необходимости в схему всегда можно аккуратно добавить ещё пару GPU‑узлов.