Как вы выбираете между online и batch инференсом для LLM?

Краткий тезис

Выбор между online и batch инференсом для LLM определяется компромиссом между задержкой (latency) и стоимостью (cost per token). inference|Online инференс (latency < 500 мс) требует стриминга, маленьких моделей и оптимизаций вроде speculative decoding, тогда как batch инференс (latency от минут до часов) позволяет использовать большие батчи (128–512), тяжёлые модели (70B+) и дешёвые spot instances. Гибридный подход (online днём, batch ночью) часто даёт наилучший баланс.

1. Термины: Online и Batch инференс

Online инференс — это обработка запросов в реальном времени, когда ответ должен быть получен за доли секунды (обычно < 500 мс). Используется в чат-ботах, голосовых ассистентах, поисковых системах.

Batch инференс — это пакетная обработка большого числа запросов без строгих требований к задержке. Запросы собираются в батчи и обрабатываются за один проход модели. Применяется для генерации отчётов, ETL-процессов, ночной обработки данных.

Ключевые метрики:

• Latency — время от отправки запроса до получения первого токена (TTFT) или полного ответа.
• Throughput — количество обработанных запросов в секунду.
• Cost per token — стоимость одного сгенерированного токена (включая compute, память, энергию).

2. Сравнение online и batch инференса

3. Когда выбирать online инференс

Online инференс необходим, когда пользователь ждёт ответа в реальном времени. Ключевые сценарии:

• Чат-боты и виртуальные ассистенты (например, ChatGPT, Alexa).
• Поисковые системы с генерацией ответов (RAG с real-time retrieval).
• Интерактивные приложения (кодинг-ассистенты, редакторы).

Техники для снижения latency

• Стриминг — отправка токенов по мере генерации (TTFT вместо полного времени).
• Speculative decoding — использование маленькой «драфт»-модели для предсказания нескольких токенов, которые проверяются большой моделью.
• Маленькие модели — 7B–13B вместо 70B+.
• vLLM — библиотека для эффективного управления KV-cache и continuous batching (даже при batch size = 1).
• PagedAttention — оптимизация памяти для KV-cache.

Пример конфигурации online сервиса:

# Псевдокод для online инференса с vLLM
from vllm import LLM, SamplingParams

model = LLM(model="mistralai/Mistral-7B-Instruct", max_num_seqs=1)
params = SamplingParams(temperature=0.7, max_tokens=512)

while True:
    user_input = get_user_input()
    output = model.generate([user_input], params)
    stream_output(output[0].outputs[0].token_ids)

4. Когда выбирать batch инференс

Batch инференс оправдан, когда задержка не критична, а важна стоимость. Сценарии:

• Ночная обработка данных — генерация отчётов, суммаризация документов.
• ETL-пайплайны — обогащение данных с помощью LLM.
• Офлайн-генерация — создание датасетов, синтетических данных.

Оптимизации для batch

• Большие батчи (128–512) — повышают throughput и утилизацию GPU.
• Большие модели (70B–405B) — дают лучшее качество, но требуют много памяти.
• Spot instances — дешёвые прерываемые инстансы (до 70% экономии).
• Tensor parallelism — распределение модели на несколько GPU.
• FlashAttention — ускорение attention и снижение памяти.

Пример batch пайплайна:

# Псевдокод для batch инференса
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer

model = AutoModelForCausalLM.from_pretrained("meta-llama/Llama-3-70B", device_map="auto")
tokenizer = AutoTokenizer.from_pretrained("meta-llama/Llama-3-70B")

batch_texts = load_batch_from_database(batch_size=256)
inputs = tokenizer(batch_texts, padding=True, return_tensors="pt").to("cuda")
with torch.no_grad():
    outputs = model.generate(**inputs, max_new_tokens=512)
results = tokenizer.batch_decode(outputs)
save_results_to_storage(results)

5. Гибридный подход: online днём, batch ночью

На практике часто применяют гибридную архитектуру:

• Днём — online инференс на маленьких моделях (7B–13B) с vLLM и стримингом для пользовательских запросов.
• Ночью — batch инференс на больших моделях (70B+) для обработки накопленных данных, дообучения, генерации отчётов.

Такой подход позволяет:

• Обеспечить низкую задержку для пользователей в часы пик.
• Использовать дешёвые ресурсы (spot instances) в нерабочее время.
• Периодически улучшать качество ответов за счёт больших моделей.

Пример архитектуры:

[User Requests] → [Load Balancer] → [Online Cluster: vLLM + Mistral-7B]
                                    ↓
                              [Message Queue] → [Batch Cluster: Llama-70B + Spot Instances]
                                    ↓
                              [Storage: Reports, Logs]

6. Метрики выбора: cost per token vs latency requirement

Основной компромисс — стоимость одного токена против требований к задержке. Формально можно ввести метрику эффективности:

Efficiency = (Throughput) / (Cost per token × Latency)

Но на практике выбор определяется бизнес-требованиями:

• Если latency < 500 мс обязательна → online (даже дороже).
• Если cost per token критичен → batch (даже медленнее).
• Если оба важны → гибрид.

Пороговые значения

• Online: TTFT < 200 мс, полное время < 2 с.
• Batch: время выполнения < 1 часа (для ночных окон).

Формула для оценки стоимости

Cost per token = (GPU cost per hour) / (tokens generated per hour)

Для online инференса GPU часто простаивает (низкая утилизация), поэтому cost per token выше. Для batch — высокая утилизация, cost per token ниже.

7. Инструменты и технологии

8. Примеры архитектур

Online (чат-бот):

• Модель: Mistral-7B-Instruct
• Сервер: vLLM с continuous batching
• Развёртывание: Kubernetes + GPU node (A100)
• Latency: TTFT ~100 мс, throughput ~50 запросов/сек

Batch (генерация отчётов):

• Модель: Llama-3-70B
• Пайплайн: Spark + PyTorch, батчи по 256 запросов
• Инфраструктура: Spot instances (p4d.24xlarge) на AWS
• Время выполнения: 2 часа для 10 000 запросов

Пет-проект для закрепления

Задача Реализовать гибридный сервис, который днём отвечает на вопросы пользователей через online инференс (маленькая модель), а ночью обрабатывает накопленные запросы через batch инференс (большая модель) и улучшает ответы.

Инструменты

• Python, FastAPI (online), Celery (batch)
• vLLM для online, Hugging Face Transformers для batch
• Redis как очередь сообщений
• PostgreSQL для хранения запросов и ответов
• Docker + docker-compose для локального развёртывания

Шаги:

1. Разверните vLLM с моделью microsoft/Phi-3-mini-4k-instruct (online).
2. Напишите FastAPI endpoint, который принимает запрос, отправляет в vLLM и возвращает стримингом.
3. Настройте Celery worker с моделью meta-llama/Llama-3-8B (batch).
4. Каждый запрос дублируется в Redis очередь.
5. Ночью Celery worker забирает все запросы, обрабатывает батчем (batch size = 64) и сохраняет улучшенные ответы в БД.
6. Сравните cost per token и latency для двух режимов.

Ожидаемый результат

• Online: latency < 500 мс, но ответы менее качественные.
• Batch: latency ~10 минут для 1000 запросов, но ответы лучше.
• Гибрид: пользователи получают быстрый ответ днём, а на следующий день видят улучшенную версию.

Связь с другими вопросами

Навигация

• Предыдущий: 454
• Следующий: 456
• Индекс: 00. Индекс разборов