Привет, Хабр! На связи команда Рег.облака. Современные ИИ-платформы — это сложные распределенные системы, где за одним пользовательским запросом стоит целый конвейер микросервисов, GPU-кластеров и систем хранения. Но с точки зрения разработчика взаимодействие обычно выглядит просто: отправил запрос в API или через веб-интерфейс и получил ответ.
Что происходит между этими двумя точками? Как запрос авторизуется, маршрутизируется, попадает на инференс, обрабатывает контекст и возвращается обратно? В этой статье разберем архитектуру ИИ-платформы для тех, кто хочет заглянуть под капот, но не имеет бэкграунда в ML-инфраструктуре.
Важно: эта статья — обзорный материал по типовой архитектуре ИИ-платформ, а не описание конкретной реализации Рег.облака. Мы не претендуем на универсальность или эталонность описанных решений. В реальности каждый провайдер выстраивает архитектуру под свою целевую аудиторию и конкретные бизнес-задачи — компромиссы и технические решения могут сильно отличаться. Наша цель — дать общее представление о том, как устроен конвейер обработки запросов «от и до», чтобы новичкам было проще погрузиться в тему.
Навигация по тексту:
Аутентификация и валидация
Работа с ИИ-платформой начинается не с запроса, а с получения API-ключа. Это учетная запись машины, которая нужна, чтобы подключать внешние инструменты — агентов, IDE (среды разработки), n8n-автоматизации, чат-интерфейсы или любые другие системы через стандартный OpenAI-совместимый протокол.
Под ИИ-платформой в этой статье мы понимаем прежде всего инференс-ядро — часть, отвечающую за обработку запросов к моделям. В реальности платформа может включать гораздо больше: конструкторы агентов, nocode-автоматизации, интеграции с внешними сервисами и другие надстройки. Но здесь мы сфокусируемся именно на инфраструктуре инференса — том, что происходит между API-запросом и генерацией ответа.
Ключ идентифицирует приложение или агента, принадлежащего пользователю, но не обязательно идентифицирует прямые действия самого пользователя. Так система понимает, кто и с какими правами обращается к моделям.
Первый этап — проверка пользователя. Запрос попадает в сервис аутентификации, который выполняет несколько задач:
проверяет API-ключ или JWT-токен на валидность и срок действия;
убеждается, что аккаунт активен и не заблокирован.
Параллельно работает rate limiting — ограничение частоты запросов. Существуют разные механизмы ограничений, для LLM-моделей часто применяются: по числу запросов в минуту (RPM, requests per minute) или по количеству токенов в минуту (TPM, tokens per minute). При этом ограничения могут быть настроены на разные промежутки времени — секунды, минуты, часы или сутки — в зависимости от бизнес-логики и сценариев использования.
На всех этапах формируется сквозной идентификатор запроса для технической маршрутизации и диагностики. Содержимое запросов и ответов при этом не логируется — в систему наблюдаемости попадают только служебные метрики и события ошибок.
Маршрутизация запросов
После авторизации запрос попадает в L7-балансировщик. Он решает несколько задач:
обеспечивает отказоустойчивость: если одна из реплик или даже часть самого балансировщика выходит из строя, трафик автоматически перенаправляется на живые инстансы;
направляет запрос к конкретной модели на основе поля
modelв теле запроса;распределяет нагрузку между несколькими репликами одной модели;
поддерживает канареечные развертывания — часть трафика отправляет на новую версию для проверки стабильности.
Как правило, балансировщик не хранит маршруты статически. Используется сервис-дискавери, который динамически обновляет список доступных инстансов. Когда поднимается новый экземпляр модели, он автоматически регистрируется и начинает получать трафик.
Некоторые платформы предоставляют пользователям возможность настраивать интеллектуальную маршрутизацию: простые запросы отправляются на легкие модели (7B–13B параметров), сложные — на флагманские (70B+). Это позволяет снизить среднюю стоимость инференса, но выбор стратегии остается за пользователем — при неверной настройке качество результата может пострадать.
Инференс: как генерируется ответ
Этап выполнения модели после получения запроса. Для LLM он обычно делится на две части: prefill и decode. Именно здесь потребляются вычислительные ресурсы GPU, память для весов и KV-cache, а также пропускная способность памяти и меж-GPU-соединений.
Токенизация. Входная строка разбивается на токены. У каждой модели свой токенизатор, поэтому одна и та же фраза может занимать разное число токенов. Число входных и выходных токенов влияет на задержку, стоимость и потребление памяти.
Эмбеддинги. Каждый ID токена преобразуется в вектор признаков фиксированной размерности — embedding. Модель также получает информацию о позиции токена в последовательности. Это позволяет различать порядок слов и учитывать расстояние между токенами.
Prefill: обработка входного контекста. Все токены prompt проходят через блоки трансформера. На этом этапе модель рассчитывает и сохраняет для каждого слоя ключи и значения attention — KV-cache. Prefill хорошо распараллеливается по токенам и обычно интенсивно использует вычислительные ресурсы GPU.
Декодирование. На каждом шаге модель выдает вероятности для всех токенов словаря. Дальше стратегия выбора:
greedy — самый быстрый, но менее креативный;
top-k или top-p — баланс между скоростью и вариативностью;
beam search — держит несколько гипотез и выбирает лучшую.
Детокенизация. Когда сгенерирован токен конца последовательности, токены превращаются обратно в текст. При стриминге они отправляются клиенту по SSE (Server-Sent Events, события, отправляемые сервером) по мере появления.
Аппаратная часть
Инференс больших моделей требует серьезного железа:
GPU — моделям топового уровня нужные терабайты памяти.
Тензорный параллелизм — веса разрезаются по нескольким GPU внутри сервера, вычисления идут параллельно. Требуется быстрая связь — используются NVLink/NVSwitch, характерные для сборок SXM и HGX.
Конвейерный параллелизм — слои модели распределяются по разным GPU или серверам, запрос проходит через них последовательно.
Квантизация снижает точность представления весов, например до INT8, INT4 или других форматов. GPTQ и AWQ — популярные методы квантизации; GGUF — формат хранения моделей, поддерживающий несколько вариантов квантования. Может быть достигнута экономия памяти с небольшим снижением качества.
Важный механизм — динамическое батчирование (continuous batching). Новые запросы могут добавляться в батч во время генерации предыдущих, а завершившиеся — освобождать ресурсы. Это помогает повысить пропускную способность сервиса, уменьшить простои GPU и снизить среднюю стоимость обработки запросов.
Работа с контекстом: RAG
Современные модели поддерживают окна контекста до 100–200 тысяч токенов, но этого недостаточно, чтобы модель знала ваши внутренние документы, базу знаний или специфику бизнеса. Передать новые сведения через промпт можно, но для больших и часто обновляемых коллекций данных это плохо масштабируется по стоимости, длине контекста и качеству отбора. Поэтому используют RAG (Retrieval-Augmented Generation) — технологию, которая подгружает релевантные фрагменты из ваших собственных данных прямо в момент запроса:
Пользователь загружает документ.
Система разбивает его на чанки (500–1000 токенов).
Каждый чанк проходит через embedding-модель и превращается в вектор.
Векторы сохраняются в векторной БД с индексом для быстрого поиска.
При запросе система векторизует вопрос, находит ближайшие чанки и подставляет их в промпт.
Обогащенный запрос отправляется в LLM.
На инфраструктурном уровне добавляются отдельные сервисы: конвертер документов, чанкер, эмбеддинг-сервис и векторная база (Qdrant, Milvus, Pinecone). Каждый масштабируется независимо.
Мультимодальность
Если платформа поддерживает мультимодальные модели, добавляются дополнительные компоненты:
кодировщик изображений (CLIP, ViT) — превращает картинку в эмбеддинги;
проектор — «переводит» визуальные эмбеддинги в пространство языковой модели;
для аудио — спектрограммные кодировщики, для видео — покадровая выборка.
Стоимость и число внутренних визуальных токенов зависят от конкретной мультимодальной модели, разрешения, способа разбиения изображения и режима обработки.
Мониторинг и наблюдаемость
В распределенной системе с GPU-кластерами мониторинг обязателен. Собираются метрики:
загрузка GPU, температура, потребление памяти;
время до первого токена (TTFT) и время на каждый последующий токен;
размер батчей и длина очереди;
частота ошибок — таймауты, OOM, некорректные запросы.
Метрики стекаются в Prometheus, визуализируются в Grafana, алерты уходят в PagerDuty или Telegram. Логи агрегируются в ELK-стек с корреляцией по идентификатору запроса.
Для биллинга ведется отдельная система учета — сколько токенов сгенерировано, для какой модели, от какого пользователя.
Формирование ответа
Когда генерация завершена:
токены детокенизируются в текст;
для веб-интерфейса применяется форматирование (Markdown, подсветка кода);
формируется JSON-ответ с текстом, количеством токенов и идентификатором запроса;
при стриминге токены отправляются по SSE, финальный ответ собирается на клиенте.
Вместо итога: почему оплата по токенам — новый стандарт
Использование LLM стремительно становится повсеместным. Модели применяют для консультирования по предметным областям, написания кода, системного администрирования, автоматизации рутинных процессов, генерации контента и многих других задач. Нейросети проникают в бизнес-процессы компаний любого масштаба — от стартапов до крупных корпораций.
Но за простотой пользовательского запроса скрывается сложнейшая инфраструктура: GPU-кластеры, системы хранения, балансировщики, векторные базы, инструменты мониторинга. Чтобы эффективно развернуть и эксплуатировать всё это, нужна команда высококвалифицированных инженеров, понимающих и аппаратную часть, и ПО для инференса, и распределенные системы.
Очевидно, что каждый бизнес не может позволить себе такую экспертизу — ее дефицит на рынке ощущается всё острее. Именно поэтому логичным решением становится использование ИИ-платформ как готового сервиса. Разработчикам и компаниям больше не нужно разбираться в нюансах тензорного параллелизма или подбирать конфигурацию GPU — достаточно интегрироваться через единый API и платить только за фактически обработанные токены.
Модель оплаты по токенам превращает ИИ из сложной инженерной задачи в предсказуемый операционный расход. Например, мы в Рег.облаке недавно добавили оплату по токенам для нашей ИИ-платформы. Теперь доступны более 30 моделей через единый OpenAI-совместимый API — от GPT-5.5 и Claude Sonnet 5 до Gemini 3.1 Pro, Kimi K2.6 и Qwen 3.7 Max. Это закрывает широкий спектр задач: текстовая генерация, мультимодальные сценарии, работа с длинными контекстами, глубокие исследования и подключение агентов.