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

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

Выбор между online и batch инференсом для LLM — это компромисс между latency (задержкой ответа) и throughput (пропускной способностью) при заданных ограничениях по стоимости и инфраструктуре. Online инференс (режим реального времени) требуется для интерактивных приложений (чат-боты, ассистенты) с latency < 500 мс, где применяются техники вроде streaming, speculative decoding и малых моделей. Batch инференс (пакетная обработка) оптимален для фоновых задач (генерация отчетов, обработка корпуса текстов), где latency не критична, а приоритет — минимизация cost per token за счет больших батчей и моделей. Выбор диктуется SLA (Service Level Agreement) по времени ответа, бюджетом и характером нагрузки.

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

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

Batch инференс — это режим, при котором множество запросов собираются в пакет (batch) и обрабатываются за один проход модели. Ключевые метрики — throughput (количество обработанных запросов в единицу времени) и cost per token (стоимость генерации одного токена). Latency может составлять минуты или часы.

Термин «latency» — задержка между отправкой запроса и получением ответа. Измеряется в миллисекундах или секундах.

Термин «throughput» — количество запросов или токенов, обработанных за единицу времени. Измеряется в requests per second (RPS) или tokens per second (TPS).

Термин «cost per token» — стоимость генерации одного токена, включая затраты на compute (GPU/CPU) и электроэнергию. Ключевая метрика для batch-режимов.

2. Ключевые критерии выбора

Выбор между online и batch инференсом определяется четырьмя факторами:

Примеры

• Online: Чат-бот поддержки клиентов — каждый запрос должен быть обработан за < 1 секунды.
• Batch: Ночная генерация описаний для 1 млн товаров в e-commerce — latency не важна, важна стоимость.

3. Online инференс: техники и компромиссы

3.1 Streaming (потоковая генерация)

Streaming — это отправка токенов пользователю по мере их генерации, а не после завершения всего ответа. Это снижает time-to-first-token (TTFT) до десятков миллисекунд, хотя полный ответ может занимать секунды.

Реализация

# Псевдокод для streaming через FastAPI
from fastapi import FastAPI, Response
from transformers import AutoModelForCausalLM, AutoTokenizer
import asyncio

app = FastAPI()
model = AutoModelForCausalLM.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")
tokenizer = AutoTokenizer.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

@app.post("/generate")
async def generate(prompt: str):
    inputs = tokenizer(prompt, return_tensors="pt")
    async def token_stream():
        for token_id in model.generate(**inputs, max_new_tokens=256, stream=True):
            token = tokenizer.decode(token_id, skip_special_tokens=True)
            yield token
    return Response(token_stream(), media_type="text/plain")

3.2 Speculative Decoding (спекулятивное декодирование)

Speculative decoding — техника, при которой малая «драфт-модель» (draft model) генерирует несколько токенов, а большая «таргет-модель» (target model) проверяет их за один проход. Это ускоряет генерацию в 2–3 раза без потери качества.

Термин «draft model» — малая модель (например, 7B), которая быстро генерирует кандидатов. Термин «target model» — большая модель (например, 70B), которая верифицирует кандидаты.

3.3 KV Cache и его оптимизация

KV cache (Key-Value cache) — кэш промежуточных представлений ключей и значений из слоёв attention. При последовательной генерации токенов KV cache переиспользуется, но занимает память O(n^2) от длины контекста.

Online-оптимизации

• PagedAttention (vLLM): управление KV cache страницами, как виртуальная память.
• Prefix caching: кэширование KV для общих префиксов (например, системных промптов).

3.4 Quantization (квантизация)

Quantization — снижение точности весов модели (FP16 → INT8/INT4) для уменьшения latency и потребления памяти. Для online инференса часто применяют AWQ (Activation-aware Weight Quantization) или GPTQ, которые сохраняют качество при 4-битном представлении.

3.5 Малая модель vs большая модель

Для online инференса часто выбирают малые модели (7B–13B), так как они дают latency < 100 мс даже без оптимизаций. Если нужно качество большой модели (70B+), применяют distillation (дистилляция) — обучение малой модели имитировать большую.

4. Batch инференс: техники и компромиссы

4.1 Большие батчи (Large Batches)

Batch size — количество запросов, обрабатываемых за один проход модели. Чем больше batch, тем выше throughput, но растёт и latency (из-за ожидания заполнения батча и большего времени на генерацию).

Пример:

• Batch size = 1: throughput = 10 TPS, latency = 100 мс.
• Batch size = 64: throughput = 500 TPS, latency = 3 секунды.

Термин «throughput» в batch-режиме часто измеряется в tokens per second per GPU (TPS/GPU).

4.2 Batching Strategies (стратегии батчирования)

Continuous batching — ключевая техника для batch инференса в современных системах (vLLM, TGI). Она позволяет обрабатывать запросы с разной длиной генерации без простоев GPU.

4.3 Off-peak scheduling (планирование вне пика)

Batch инференс часто запускают в off-peak часы (ночью), когда стоимость GPU ниже (например, spot instances на AWS). Это снижает cost per token на 50–70%.

4.4 Model Parallelism (модельный параллелизм)

Для больших моделей (70B+) batch инференс требует распределения модели на несколько GPU:

• Tensor Parallelism (TP): разделение слоёв модели между GPU.
• Pipeline Parallelism (PP): разделение модели по слоям, каждый GPU обрабатывает часть слоёв.

Пример конфигурации для batch инференса

# Конфигурация для vLLM batch inference
model: "meta-llama/Llama-3.1-70B"
tensor_parallel_size: 4  # 4 GPU
pipeline_parallel_size: 2  # 2 группы
max_num_batched_tokens: 8192  # Максимум токенов в батче

5. Гибридные подходы

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

5.1 Online с batch-обработкой фоновых задач

• Online: интерактивные запросы пользователей (latency < 500 мс).
• Batch: генерация рекомендаций, препроцессинг данных, которые не требуют мгновенного ответа.

Архитектура

Пользователь → API Gateway → [Online Worker (vLLM, малая модель)]
                        ↓
Фоновая очередь (Redis/Kafka) → [Batch Worker (большая модель, ночной запуск)]

5.2 Burst handling (обработка пиков)

При резком росте нагрузки (burst) online-система может переключать часть запросов на batch-обработку с увеличенной latency, но гарантированной обработкой.

Термин «burst» — кратковременный пик запросов, превышающий мощность online-инфраструктуры.

6. Таблица сравнения: Online vs Batch

7. Пример кода: Online vs Batch на практике

Online (FastAPI + vLLM)

from vllm import AsyncLLMEngine, SamplingParams
from fastapi import FastAPI, Response
import asyncio

app = FastAPI()
engine = AsyncLLMEngine.from_pretrained("mistralai/Mistral-7B-Instruct-v0.2")

@app.post("/chat")
async def chat(prompt: str):
    sampling_params = SamplingParams(temperature=0.7, max_tokens=256)
    async def stream():
        async for output in engine.generate(prompt, sampling_params):
            yield output.outputs[0].text
    return Response(stream(), media_type="text/plain")

Batch (Python + Hugging Face + multiprocessing)

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch
from multiprocessing import Pool

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

def process_batch(prompts: list[str]) -> list[str]:
    inputs = tokenizer(prompts, return_tensors="pt", padding=True)
    with torch.no_grad():
        outputs = model.generate(**inputs, max_new_tokens=256)
    return [tokenizer.decode(o, skip_special_tokens=True) for o in outputs]

# Запуск batch-обработки ночью
if __name__ == "__main__":
    all_prompts = load_prompts_from_file("nightly_batch.txt")
    with Pool(processes=4) as pool:  # 4 GPU
        results = pool.map(process_batch, chunks(all_prompts, 64))
    save_results(results, "output.txt")

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

Задача Построить систему, которая для одного и того же набора запросов может работать в двух режимах: online (с latency < 500 мс) и batch (с минимальным cost per token). Сравнить метрики.

Инструменты

• vLLM (для online с continuous batching)
• Hugging Face Transformers (для batch)
• FastAPI (для online API)
• Redis (для очереди batch-запросов)
• Prometheus + Grafana (для мониторинга latency и throughput)

Шаги:

1. Разверните малую модель (Mistral-7B) через vLLM с streaming и speculative decoding.
2. Реализуйте API с двумя эндпоинтами: /chat (online) и /batch (принимает список промптов).
3. Для batch-режима используйте большую модель (Llama-3.1-70B) с Tensor Parallelism на 4 GPU.
4. Соберите датасет из 10 000 запросов (например, вопросы из SQuAD).
5. Запустите нагрузочное тестирование (locust или k6) для online-режима.
6. Запустите batch-обработку того же датасета ночью.
7. Сравните метрики: latency (p50, p95, p99), throughput (RPS), cost per token (стоимость GPU-часов).

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

• Online: latency p95 < 300 мс, throughput ~50 RPS на одном GPU.
• Batch: throughput ~500 TPS/GPU, cost per token в 5–10 раз ниже.
• Вывод: для интерактивных сценариев — online, для фоновых задач — batch.

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

Навигация

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