Все статьи
LLMRAGProductionvLLM

Как снизить latency LLM в production в 25 раз

InfoScale Team·10 февраля 2026· 8 мин

AI-стартап с 12 000 активных пользователей пришёл к нам с одной проблемой: их RAG-система отвечала за 28 секунд. Пользователи уходили. Мы снизили latency до 1.1 секунды за 5 дней — без смены модели и без переписывания приложения.

Почему 28 секунд — это катастрофа

Пользователь задаёт вопрос в чате. Через 5 секунд он начинает думать, что что-то сломалось. Через 10 — закрывает вкладку. Через 28 секунд — уходит к конкуренту.

Исследования показывают: конверсия падает на 7% при каждой дополнительной секунде задержки. При 28 секундах вы теряете большинство пользователей до получения ответа.

Диагностика: где теряется время

Первым делом мы профилировали запрос от начала до конца. Вот что нашли:

ЭтапВремя (до)Время (после)
Embedding запроса4.2s0.08s
Поиск в векторной БД8.1s0.12s
Загрузка контекста3.4s0.05s
LLM inference12.3s0.85s
Итого28.0s1.10s

Что мы сделали: 5 конкретных изменений

01

Заменили embedding-модель на оптимизированную

Оригинальная модель запускалась через Hugging Face Transformers без оптимизаций. Мы перешли на ONNX Runtime с квантизацией INT8. Embedding одного запроса: 4.2s → 0.08s.

02

Развернули Qdrant вместо FAISS in-memory

FAISS перезагружал весь индекс при каждом рестарте (8 минут). Qdrant с персистентным хранилищем и HNSW-индексом: поиск 0.12s, мгновенный старт.

03

Перешли с Ollama на vLLM с PagedAttention

Ollama не поддерживает batching и continuous batching. vLLM с PagedAttention обрабатывает параллельные запросы эффективно. LLM inference: 12.3s → 0.85s при той же модели Mistral 7B.

04

Добавили семантическое кэширование

Похожие вопросы (cosine similarity > 0.92) возвращают кэшированный ответ мгновенно. 35% запросов обслуживаются из кэша за < 50ms.

05

Параллелизировали embedding и retrieval

Embedding запроса и retrieval из БД выполнялись последовательно. Мы запустили их параллельно через asyncio.gather(). Экономия: ~200ms на каждом запросе.

Итоговая архитектура

# RAG Pipeline — Optimized Stack
Embedding: ONNX Runtime + INT8 quantization
Vector DB: Qdrant (persistent, HNSW index)
LLM serving: vLLM + PagedAttention + continuous batching
Cache: Redis + semantic similarity (cosine > 0.92)
Orchestration: Kubernetes + GPU node pool
Monitoring: Prometheus + Grafana + LLM-specific metrics
# Result: p50 latency 1.1s, p95 latency 2.3s

Выводы

  • 1Большинство проблем с latency — не в модели, а в инфраструктуре вокруг неё
  • 2ONNX Runtime + квантизация даёт 10-50x ускорение embedding без потери качества
  • 3vLLM с PagedAttention — стандарт для production LLM serving
  • 4Семантическое кэширование снижает нагрузку на GPU на 30-40%
  • 5Профилируйте каждый этап отдельно — проблема может быть неочевидной

Есть похожая проблема?

Мы специализируемся на production LLM-инфраструктуре. Расскажите о вашем стеке — предложим конкретный план.