AI System Design: архитектура production AI-приложения от нуля до масштаба

Цели урока

• Рассчитать нагрузку, стоимость и concurrency для AI-системы
• Спроектировать 6-слойную архитектуру production AI-приложения
• Применить стратегии масштабирования: caching, routing, prompt compression, queue management
• Реализовать resilience patterns: circuit breaker, multi-provider fallback, budget kill switch

System design для AI отличается от классического одним: недетерминированный компонент в центре. REST API возвращает одно и то же. LLM - нет. Это меняет всё: тестирование, мониторинг, SLA, fallback-стратегии. Стартап добавляет OpenAI API, через месяц получает счёт USD 47K, 5% запросов падают по rate limit, пользователи жалуются на галлюцинации - и только тогда начинается настоящий system design.

• Notion AI обрабатывает 100M+ запросов в день - multi-provider routing, aggressive semantic caching, per-user rate limits; без этого стека стоимость была бы в 4x выше
• Vercel AI Gateway - open-source решение для routing, caching, fallback между LLM-провайдерами; появилось потому что каждая команда изобретала одно и то же
• 40% enterprise-клиентов Anthropic превышают бюджет в первый месяц без budget controls - budget kill switch стал стандартным компонентом архитектуры
• Stripe AI fraud detection: 6-слойная архитектура, 99.99% uptime через circuit breaker на 3 LLM-провайдера, shadow mode testing перед каждым переключением модели

Как сложился LLM app stack

До конца 2022 года типичное AI-приложение было обёрткой вокруг одного вызова модели. Запуск ChatGPT 30 ноября 2022 и публичный ChatGPT API в марте 2023 запустили волну, в которой за год оформился узнаваемый стек production LLM-приложений. Он сложился не из одной статьи, а из практики десятков команд: retrieval (RAG поверх векторной базы) даёт модели актуальный контекст, агенты и tool calling позволяют ей выполнять действия, guardrails фильтруют вход и выход, а слой оценки (eval) измеряет качество на регрессиях. В 2023 году появились инструменты, закрепившие эти слои: LangChain и LlamaIndex для оркестрации и retrieval, векторные базы Pinecone, Weaviate, pgvector, платформы наблюдаемости вроде LangSmith. Ключевое отличие от классической архитектуры в том, что центральный компонент недетерминированный: один и тот же запрос даёт разные ответы, поэтому тестирование, кеширование и обработка ошибок проектируются иначе. К 2024 году эта схема (RAG плюс агенты плюс guardrails плюс eval) стала фактически отраслевым шаблоном для построения AI-сервисов.

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

• Orchestration Patterns: routing, fallback, chain, map-reduce, branching
• Observability: Logging, Tracing, Monitoring AI Pipelines

Load Estimation: расчёт нагрузки для AI-системы

System design для AI начинается с estimation - и тут первый сюрприз. Обычный CRUD-запрос стоит USD 0.0001 и занимает 50ms. AI-запрос стоит USD 0.001-0.10 и занимает 1-30 секунд. Это не количественная разница - это другая физика. **Высокая латентность** (1-30с), **переменная стоимость** (зависит от длины промпта), **ограниченный throughput** провайдеров - каждый параметр ломает привычные паттерны масштабирования.

10 000 DAU, 15 AI-запросов на пользователя в день, Claude Sonnet (USD 3 per 1M input). Звучит как небольшой продукт. Считаем: 150 000 запросов/день × 2000 токенов = 300M токенов ввода = **USD 900 в день = USD 27,000 в месяц**. Без кеширования, без model routing, без prompt compression - только сырые запросы. Поэтому estimation для AI-системы делается в первую очередь, а не в последнюю.

**USD 60K/месяц на LLM API при 10K DAU - реальная цифра.** Поэтому AI system design ВСЕГДА включает стратегию оптимизации: semantic caching, model routing (дешёвая модель для простых запросов), prompt compression.

Один параметр из таблицы ниже меняет всё восприятие: throughput. Обычный backend держит 1000+ RPS на одном инстансе. AI-система с тем же трафиком работает на 1-5 RPS - потому что bottleneck не в сервере, а в API rate limits провайдера. Это полностью переворачивает логику масштабирования.

Component Diagram: архитектура AI-приложения

В обычном микросервисе можно добавить сервер - и throughput вырастет линейно. В AI-системе добавление серверов не помогает: bottleneck - в LLM API. Поэтому архитектура строится иначе - вокруг **6 слоёв**, каждый из которых решает конкретную проблему AI-специфичного трафика.

Observability layer в AI-системе - не просто логи и метрики. Это **hallucination rate**, **cost per request**, **качество ответов во времени** (model degradation после тихого обновления от провайдера). Langfuse и Helicone заточены именно под это - они понимают токены, модели, оценку качества. Prometheus + Grafana этого не умеют из коробки.

**Правило: каждый слой должен быть заменяемым без изменения остальных.** Переход с Pinecone на pgvector не должен затрагивать orchestration layer. Переход с OpenAI на Anthropic - только LLM layer. Interfaces между слоями - контракт.

Scaling Strategy: масштабирование AI-системы

Классическая мантра масштабирования - «добавь серверов». В AI-системе это не работает. Bottleneck не в CPU и не в RAM - это **LLM API rate limits и стоимость токенов**. Anthropic дает 40 000 токенов в минуту на API key. OpenAI - 30 000. Добавление серверов этот лимит не меняет. Масштабирование строится вокруг одного принципа: **как можно реже ходить к LLM**.

Semantic cache - самый контринтуитивный уровень пирамиды. Кажется: запросы разные, кеш не поможет. Но «Как интегрировать Stripe?» и «Как добавить Stripe в мой проект?» - это одно и то же. `text-embedding-3-small` (1536 dim, USD 0.02 per 1M) превращает оба запроса в близкие векторы. Cosine similarity > 0.95 - отдаём кешированный ответ. **Реальный hit rate в продакшне: 35-50%.** Каждый hit экономит USD 0.005-0.05 и экономит 2-10 секунд латентности.

**Case study:** Один SaaS-продукт сократил AI-расходы с USD 45K/мес до USD 12K/мес, применив все 4 уровня: BullMQ для smoothing (-5%), prompt compression (-20%), semantic cache с 42% hit rate (-42%), model routing (-25% от оставшегося).

Failure Modes: что ломается в AI-системе и как защищаться

REST API возвращает одно и то же при одних и тех же входных данных. LLM - нет. И это меняет всё: тестирование, мониторинг, SLA, fallback-стратегии. **Hallucination** - это не баг в коде, который можно воспроизвести и исправить. Это вероятностный failure mode, который появляется случайно и требует probabilistic mitigation: RAG grounding, fact-checking, confidence scores. Обычный backend такого не знает.

Есть ещё один failure mode, который застаёт врасплох: **model degradation**. OpenAI или Anthropic тихо обновляет модель - и GPT-4o-2025-04 ведёт себя иначе, чем GPT-4o-2024-08. Качество ответов падает на 15%. Метрики CPU и latency - в норме. Hallucination rate в Langfuse - растёт. Без AI-специфичного observability это обнаружится через неделю, когда пользователи начнут жаловаться.

Circuit breaker для LLM - это не то же самое, что для обычного сервиса. Классический circuit breaker считает ошибки (5xx, timeout) и открывается. LLM-circuit breaker считает также: **hallucination rate > 10%**, **cost per request > USD threshold**, **structured output parse failures > 20%**. Anthropic упал на 15 минут в марте 2024 - все системы без fallback легли вместе с ним.

**Budget Kill Switch** - критически важный компонент. Если из-за бага или атаки расходы начинают расти неконтролируемо, система должна автоматически остановиться:

AI system design - это просто добавить retry и fallback к LLM-вызовам

AI system design требует переосмысления каждого компонента: от SLA (hallucination rate < X%) до observability (Langfuse вместо Prometheus) и тестирования (shadow mode вместо unit-тестов)

Unit-тест для LLM-вызова бессмысленен - нет детерминированного правильного ответа. SLA «99.9% uptime» неполный без «hallucination rate < 2%» и «cost per request < USD 0.05». Обычный мониторинг покажет что всё зелёное, пока качество ответов деградирует после тихого обновления модели провайдером. Это другая инженерная дисциплина, а не надстройка над существующей.

Итоги

• Недетерминированный LLM в центре системы меняет тестирование, мониторинг, SLA и fallback-стратегии
• 6 слоёв архитектуры: Gateway, Orchestration, LLM, Retrieval, Tools, Observability
• Scaling pyramid: queue → prompt compression → semantic cache (35-50% hit rate) → model routing → multi-provider
• AI-специфичные failure modes: hallucination, content policy, model degradation, cost spikes - каждый требует своего подхода
• Shadow mode testing и A/B для LLM обязательны - нельзя тестировать вероятностную систему детерминированными тестами
• Budget kill switch и hallucination rate в observability - не опции, а базовые компоненты

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

• Как бы выглядел SLA для AI-фичи в реальном продукте - какие метрики помимо uptime и latency нужно туда включить?
• Shadow mode testing для LLM: как решить когда новая модель «достаточно хороша» для переключения, если нет детерминированного правильного ответа?
• Semantic cache даёт 35-50% hit rate - но кеш устаревает. Как определить TTL для ответов LLM в системе, где знания меняются?

Что дальше

Архитектура спроектирована. Следующий шаг - real-time AI: WebSocket + LLM streaming, voice assistants, collaborative editing. А потом - конкретная реализация на NestJS.

• Realtime AI — WebSocket + LLM streaming, voice assistants, live collaboration
• AI Backend на NestJS — Конкретная реализация архитектуры на Node.js/NestJS

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

• aie-21-orchestration-patterns — System design собирает паттерны оркестрации
• aie-35-observability — Observability - опора дизайна на масштабе
• aie-43-realtime-ai — Дизайн поддерживает real-time AI-нагрузки
• aie-40-model-serving — Serving - строительный блок дизайна
• sd-01-intro — Та же методология system design, специфичная для AI
• net-37-load-balancing
• db-04-cap