Serving LLM: vLLM, TGI

Стартап запустил LLM-приложение на Flask + transformers.generate(). При 10 одновременных пользователях - timeout. GPU utilization 20%. Переход на vLLM с continuous batching занял один день: throughput вырос в 15x, GPU utilization 90%+, P99 latency упала с 30 секунд до 2. Выбор serving фреймворка важнее выбора GPU.

• **Together AI**: специализированный провайдер open-source LLM. LLaMA-3-70B через их API работает быстрее чем у большинства компаний на своём железе - за счёт оптимизированного vLLM + custom CUDA kernels.
• **HuggingFace Inference Endpoints**: TGI под капотом. Провайдер берёт на себя масштабирование, мониторинг, обновления. Компании платят за compute вместо DevOps команды.
• **Mistral AI**: свои модели деплоит через собственный serving стек на базе vLLM с оптимизациями. La Plateforme API выдаёт 500+ токенов/сек на Mixtral-8x22B.

Предварительные знания

• Inference Optimization

vLLM, PagedAttention и continuous batching

В 2022 году исследователи представили Orca с идеей continuous batching: вместо ожидания, пока завершатся все запросы в батче, планировщик подмешивает новые запросы на каждом шаге генерации, держа GPU загруженным. В 2023 году Woosuk Kwon и команда из UC Berkeley выпустили vLLM с PagedAttention - механизмом, который управляет KV-кэшем как виртуальной памятью ОС, страницами, устраняя фрагментацию и резко поднимая throughput. Тогда же HuggingFace выпустила Text Generation Inference (TGI) - production-сервер для своих моделей. Эти проекты определили, как сегодня выглядит serving LLM: высокая утилизация GPU, низкая latency и стоимость токена, упавшая в разы.

vLLM: PagedAttention и throughput

Июнь 2023. UC Berkeley публикует **vLLM** с идеей PagedAttention. До этого LLM serving на A100: ~15 токенов/сек на один запрос, GPU занята на 30-40%. После vLLM: 230+ токенов/сек, GPU 95%+. Разница - в управлении KV-кэшем: вместо предварительного выделения максимально возможного блока памяти - страничная система как в ОС.

**vLLM производительность**: на A100 80GB, LLaMA-3-8B: throughput 5000+ токенов/сек при batch=32. С quantization AWQ: 8000+ токенов/сек. PagedAttention снижает memory waste с 60-80% до <4%. vLLM - де-факто стандарт для open-source LLM serving в production.

Text Generation Inference: HuggingFace serving

**Text Generation Inference (TGI)** - serving решение от HuggingFace. Написан на Rust (HTTP слой) + Python (логика) + CUDA kernels. Первым в production реализовал continuous batching и flash attention. Используется HuggingFace Inference Endpoints как основа для платных API.

**vLLM vs TGI**: vLLM имеет более высокий throughput на большинстве задач благодаря PagedAttention. TGI - лучшая интеграция с HuggingFace экосистемой, зрелый Docker образ. Оба поддерживают OpenAI-совместимый API, streaming, quantization. Для новых проектов vLLM чаще выбирают за throughput. TGI - для HuggingFace Inference Endpoints.

Tensor и Pipeline Parallelism

LLaMA-3-70B не влезает в один A100 80GB полностью (140 GB в BF16). Нужно распределить модель между несколькими GPU. Два основных подхода: **Tensor Parallelism (TP)** и **Pipeline Parallelism (PP)**. Они решают одну задачу разными способами с разными trade-offs.

**Megatron-LM (NVIDIA)**: библиотека для обучения и инференса с TP+PP+DP (Data Parallelism). Используется для обучения GPT-3, Llama-2 и других frontier моделей. **DeepSpeed** (Microsoft) - аналог с ZeRO (Zero Redundancy Optimizer) для снижения memory footprint при обучении.

Production Serving: архитектура и мониторинг

Production LLM serving - это больше чем запустить vLLM. Нужны: автомасштабирование под нагрузку, мониторинг latency/throughput/GPU utilization, fallback при ошибках, rate limiting, кэширование промптов, A/B тестирование моделей. **Kubernetes + vLLM** - стандартный стек.

**Litserve** (Lightning AI), **Ray Serve** (Anyscale), **BentoML** - альтернативные оркестраторы для LLM serving. Ray Serve хорошо для динамического масштабирования и ensemble моделей. BentoML - для пакетирования модели с зависимостями в Docker образ.

**Управляемые решения**: AWS Bedrock, Google Vertex AI, Azure OpenAI - берут на себя весь serving. Hugging Face Inference Endpoints - для open-source моделей. Together AI, Fireworks AI, Lepton AI - специализированные провайдеры open-source LLM с оптимизированным serving. Для большинства компаний managed решения дешевле собственной инфраструктуры.

Ключевые идеи

• **vLLM**: PagedAttention + continuous batching = 10-30x throughput по сравнению с naïve serving. OpenAI-совместимый API, поддержка quantization и speculative decoding.
• **TGI**: HuggingFace serving стек. Rust HTTP слой, continuous batching, Docker образ из коробки. Основа HuggingFace Inference Endpoints.
• **Tensor Parallelism**: разбивает матрицы слоёв между GPU на одном узле. Требует NVLink. **Pipeline Parallelism**: разбивает слои между GPU/узлами. Работает через Ethernet.
• **Production стек**: Kubernetes + vLLM + Prometheus/Grafana. Мониторинг: GPU utilization, P99 TTFT, queue depth, error rate.
• **Managed vs self-hosted**: AWS Bedrock, Together AI, Fireworks AI берут на себя операционную сложность. Для большинства компаний managed дешевле.

Связанные темы

Serving - финальный этап LLM pipeline:

• Inference Optimization — vLLM и TGI реализуют quantization, speculative decoding, KV-cache оптимизации - все техники из предыдущего урока
• GenAI System Design — Архитектурные решения serving - часть общего system design: выбор между managed и self-hosted, масштабирование, fallback

Вопросы для размышления

• Компания деплоит LLM для внутреннего использования: 50 concurrent users, данные конфиденциальные. Self-hosted vLLM или managed (Bedrock)? Какие факторы определяют выбор?
• vLLM и TGI оба поддерживают OpenAI-совместимый API. Как организовать A/B тестирование двух разных моделей (например GPT-4o vs LLaMA-3-70B) с одним клиентским кодом?
• Tensor Parallelism требует AllReduce после каждого слоя. Как это влияет на latency при увеличении числа GPU с 2 до 8?

Связанные уроки

• gai-19 — Стеки обслуживания реализуют оптимизации инференса
• gai-23 — Обслуживание - кирпич системного дизайна GenAI
• aie-40-model-serving — Продакшен-обслуживание и деплой моделей
• ml-54-distributed-training — Тензорный параллелизм шардит модели как распределённое обучение
• ml-46-model-serving — Обслуживание LLM обобщает обслуживание ML-моделей
• sd-03-scalability