Масштабирование LLM: как рассчитать инфраструктуру для 1000 одновременных запросов

Когда 1000 пользователей нажимают "Отправить" одновременно

Вы запускаете образовательную платформу с ИИ-ассистентом. Утром начинается занятие - тысяча студентов одновременно открывают интерфейс и задают вопросы. Серверы молчат. База данных не отвечает. Билл от облачного провайдера приходит на сумму годового бюджета.

Знакомая история? Масштабирование LLM - это не просто "добавить ещё GPU". Это расчёт десятков параметров, понимание архитектурных компромиссов и знание, где система сломается первая.

Из чего складывается нагрузка в 1000 RPS

Запросы в секунду (RPS) - бессмысленная метрика для LLM. Два запроса: "2+2" и "Напиши эссе о влиянии квантовой физики на современную поэзию" - это разная нагрузка.

Continuous Batching: магия, без которой ничего не работает

Представьте ресторан, где каждый посетитель заказывает одно блюдо, повар готовит его, подаёт, и только потом берёт следующий заказ. Так работал инференс LLM до появления Continuous Batching.

Теперь представьте, что повар готовит 100 блюд одновременно: картошку для всех, потом мясо, потом салат. Это Continuous Batching. vLLM и Text Generation Inference (TGI) используют эту технику.

1 Выбор модели: компромисс между качеством и стоимостью

Для образовательного ассистента не нужна Llama 3 70B. Llama 3 8B справится с 90% задач. Разница в инфраструктуре:

• Llama 3 8B: помещается в одну A100 40GB с запасом
• Llama 3 70B: требует 2-4 A100 или специализированной оптимизации
• Производительность: 8B даёт ~100 токенов/сек, 70B - ~20 токенов/сек на том же железе

Если нужна точность - рассмотрите сравнение моделей для специализированных задач.

2 Расчёт GPU: не только память, но и tensor cores

Формула для грубого расчёта количества GPU:

# Пример расчёта для Llama 3 8B, 1000 RPS
# Предположения:
# - Средний промпт: 150 токенов
# - Средний ответ: 350 токенов
# - Задержка P95: 2 секунды
# - vLLM с оптимизацией

import math

model_size_gb = 8  # Llama 3 8B в FP16
kv_cache_per_token_bytes = 128  # Примерно для Llama
batch_size_per_gpu = 64  # Зависит от GPU памяти
throughput_per_gpu = 500  # Токенов/сек на A100

tokens_per_request = 150 + 350  # Промпт + ответ
total_tokens_per_second = 1000 * tokens_per_request / 2  # Учитываем параллелизм

gpu_needed = math.ceil(total_tokens_per_second / throughput_per_gpu)
print(f"Требуется GPU: {gpu_needed}")

На практике для 1000 RPS с Llama 3 8B потребуется 8-12 A100 40GB или 16-24 A10/A6000. Почему такой разброс? Зависит от оптимизации.

3 Оптимизация: vLLM против TGI против кастомных решений

vLLM с его PagedAttention даёт до 24x лучшее использование памяти по сравнению с наивной реализацией. Для 1000 RPS это разница между 10 и 40 GPU.

4 Архитектура: один большой кластер или несколько маленьких?

Ошибка номер один - ставить все GPU в один сервер. Ограничения:

• PCIe lanes: 8 GPU делят 128 линий, каждая получает x16 → x2 в реальности
• NVLink: есть только в дорогих конфигурациях
• Надёжность: падает один сервер - падает вся система

Лучшая архитектура для 1000 RPS:

# Пример архитектуры на Kubernetes
apiVersion: v1
kind: ConfigMap
metadata:
  name: vllm-config
data:
  tensor_parallel_size: "1"  # Одна модель на сервер
  max_num_seqs: "256"        # Максимальный батч
  gpu_memory_utilization: "0.9"
---
# 12 серверов, в каждом 2xA100
# 3 сервера - Llama 3 8B (основная нагрузка)
# 6 серверов - Llama 3 8B (пиковая нагрузка)
# 3 сервера - CodeLlama 13B (специализированные задачи)
---
# Load balancer распределяет запросы
# Мониторинг: Prometheus + Grafana с метриками:
# - Время обработки перцентили
# - Использование GPU памяти
# - Размер батча

Для экономии рассмотрите бюджетные 4-GPU фермы вместо монолитных серверов.

Что ломается первым при 1000 RPS

GPU - последнее, что упирается. Сначала падает:

1. Сеть между инстансами: 1000 запросов × 500 токенов × 2 байта = 1 МБ на запрос. Это 1 ГБ/сек чистых данных. Добавьте overhead.
2. Load balancer: Nginx по умолчанию обрабатывает ~10k соединений. Кажется много? Каждый запрос к LLM держит соединение 2-10 секунд.
3. Система кеширования промптов: 30% промптов повторяются. Redis кластер должен выдержать 10k RPS.
4. Мониторинг: Каждая метрика с 12 серверов × 8 GPU = 96 потоков данных. Prometheus съедает 32GB RAM.

Стоимость: облако против железа на площадке

Для образовательного учреждения с постоянной нагрузкой своё железо выгоднее через 8-12 месяцев.

Своё железо - это не только серверы. Нужен дата-центр, инженеры, резервное питание. Но для университета с существующей инфраструктурой - оптимальный выбор.

Чеклист для запуска

• □ Профилировать реальную нагрузку (длины промптов, ответов)
• □ Выбрать модель: начать с Llama 3 8B, проверить качество
• □ Настроить vLLM с PagedAttention
• □ Рассчитать GPU: (токены/сек) / (500-1000 токенов/сек на GPU)
• □ Разделить на кластер: 2-4 GPU на сервер максимум
• □ Настроить кеширование промптов (Redis Cluster)
• □ Реализовать circuit breaker и fallback на более лёгкую модель
• □ Настроить детальный мониторинг: задержки P50, P95, P99
• □ Запустить нагрузочное тестирование с реалистичными сценариями

Что будет, когда придут 2000 пользователей

Хорошая архитектура масштабируется линейно до определённого предела. Плохая - требует перепроектирования.

Сценарий роста в 2 раза:

• Хорошо: добавляем такие же серверы в кластер, настраиваем автоскейлинг
• Плохо: обнаруживаем, что load balancer не справляется, сеть между стойками перегружена, система кеширования не масштабируется

Решение: изначально проектировать с запасом 3-5x. Не по железу, а по архитектурным ограничениям.

Самое интересное: после 10,000 RPS экономически выгоднее перейти на специализированные кластеры с оптимизированными под вашу модель кастомными CUDA ядрами. Но это уже другая история.

Главный секрет: 1000 одновременных запросов - это не про железо. Это про архитектуру, которая превращает дорогие GPU в работающий сервис. Начните с мониторинга, закончите автоматическим масштабированием. И никогда не верьте продавцам, которые говорят "просто добавьте ещё GPU".