Логотип

5 путей построить AI-стек: опыт миллиона транзакций в секунду

Дата публикации

Почему корпоративная эволюция привела нас сюда

Вспомните путь, который мы прошли. Начинали с монолитных архитектур, и, кстати, Prime Video до сих пор использует их для мониторинга. Потом появились серверы, микросервисы, событийно-ориентированные архитектуры и serverless с Lambda-функциями.

Сейчас мы живем в эру AI-native решений. Это означает добавление способностей к рассуждению, больших языковых моделей, RAG-систем и агентного AI в существующие корпоративные стеки. Самая большая проблема не в технологиях как таких, а в интеграции. Как вплести агентные возможности в системы, которые уже работают, обслуживают клиентов и приносят прибыль?

Слои, которые имеют значение

Представьте современный агентный стек. Да, он сложный. Нет, пропускать слои нельзя.

Наверху располагаются API-слои - интерфейс между агентами и внешним миром. Ниже находится слой оркестрации: Kubernetes, микросервисы или LangGraph для управления рабочими процессами. Затем идут языковые модели (большие или маленькие, зависит от задачи), за ними следует слой памяти и контекста - здесь живут эмбеддинги, графы знаний обеспечивают семантическое понимание.

Слой действий особенно интересен. Агентам нужны инструменты и API для реальных операций. А в основании всего лежат данные и управление. Без правильной обработки данных и безопасности вы строите карточный домик.

Для практических рекомендаций по построению AI-стека посетите AI Projects - здесь вы найдете экспертные решения для интеграции искусственного интеллекта.

Императив микросервисов

Вот что критически важно: микросервисы должны быть безстейтовыми. Это невозможно переоценить. Храните информацию о состоянии в Kafka, Redis, Cassandra или MongoDB - где угодно, только не в самом сервисе. Это не просто следование лучшим практикам, это построение системы, способной масштабироваться по требованию.

Кстати о масштабировании: мы достигли поддержки миллиона транзакций в секунду. Да, вы правильно прочитали. Это возможно, но только если архитектура спроектирована для этого с первого дня.

API требуют четкого управления жизненным циклом. Экспериментальные? Стабильные? Устаревшие? Это важнее, чем кажется, особенно при быстрых итерациях.

Записи в базу данных должны быть append-only. Для чтения агрессивно используйте кеши. А ваш конвейер данных нуждается в валидации схем, ETL-процессах, инкрементальных загрузках и возможностях backfill. Это не опции, это необходимость.

Пять путей вперед

Методом проб и ошибок я выделил пять разных подходов к построению агентного стека.

Путь первый - для команд с существующими корпоративными системами. У вас есть микросервисы, они безстейтовые, состояние выгружается в Redis или Kafka. Красота здесь в эффективности токенов. Вы не вызываете модели без необходимости. Возможно, у вас Lambda-функция работает 15 минут, вызывая LLM или небольшие языковые модели по мере надобности. Быстрый выход на рынок, потому что строите на том, что уже имеете.

Путь второй выглядит похоже, но с ключевым отличием: хостинг. В первом пути вы сами хостите модели. Второй путь использует публичные облачные провайдеры: Google, Azure, AWS. Компромисс? Меньше контроля ради большего удобства.

Путь третий вводит MCP (Model Context Protocol) как отдельный компонент. Это стандартизирует инструменты, запросы и доступ к ресурсам. Речь о создании согласованности в мире постоянных изменений.

Путь четвертый фокусируется на рабочих процессах. Инструменты вроде LangGraph позволяют определять состояния и переходы, вызывая разные модели или агенты в зависимости от этапа процесса. Мощный подход для сложных многошаговых операций.

Путь пятый (это передовой край) включает агентные песочницы. Представьте Android-приложения, работающие в песочницах поверх Linux. Все контролируется: данные, файловая система, среда выполнения. Это буквально появилось на прошлой неделе с анонсами Enterprise Agent Cloud и Kubernetes North America 2025. Я оптимистичен насчет этого подхода. Представьте магазины агентов, где разработчики развертывают агенты как мобильные приложения. Мы еще не там, но это грядет.

Кейсы, которые научили всему

Поделюсь тем, что мы построили для OTT-агрегатора. Вместо подписки на множество стриминговых сервисов пользователи подписываются на агрегатор и получают доступ ко всем через один интерфейс. Мы создали модели для обогащения метаданных, рекомендаций, поиска, мониторинга видео, отслеживания качества и публикации контента.

Вот ключевой урок: мы построили этот фреймворк три года назад. Модели изменились. Фреймворки эволюционировали. Но данные приложения, паттерны интерфейса, пользовательские инсайты, которые мы собрали? Они до сих пор на вес золота. Данные, собранные сегодня, переживут любую конкретную модель или фреймворк, который вы выберете.

Наша мультимодальная рекомендательная система научила ценить гибкость. Мы используем прокси и балансировщик нагрузки для маршрутизации вызовов между локально размещенными и удаленными моделями. Это означает возможность переключать модели без нарушения работы сервиса. Такие архитектурные решения окупаются со временем.

Данные: константа в мире переменных

Буду предельно ясен: обработка данных определит успех или провал вашей агентной системы. Нужно думать о данных на трех уровнях:

  • Сессионные данные: что остается в рамках одной пользовательской сессии?
  • Кросс-сессионные данные: что сохраняется между взаимодействиями?
  • Долгосрочные данные: что становится частью институциональных знаний?

Каждая порция данных, входящая в систему, должна захватываться и оркестрироваться. Нужна ли ей ранжирование, дедупликация, приоритизация или устаревание - вам нужен план. Это не гламурная работа, но это фундамент, на котором строится все остальное.

Мы активно экспериментировали с векторными базами данных. Модели LightFM и DeepFM давали медленную производительность запрос-эмбеддинг. После тестирования множества вариантов мы остановились на Milvus из-за возможностей масштабирования. Для графов знаний мы углубились в обогащение метаданных, тщательно проектируя структуры узлов и контекста.

Матрица решений: разрабатывать или покупать

Здесь начинается стратегия. Нужно определить, что не изменится и что добавит уникальную ценность организации.

Разрабатывайте эти компоненты:

  • Слой оркестрации (если есть микросервисы, держите их безстейтовыми и добавьте SEO-слой для распределения)
  • Архитектура памяти (Redis или Hazelcast для краткосрочной, Neo4j для графов знаний)
  • Маршрутизация контекста (это ваш секретный соус, держите внутри компании)
  • Конвейер данных (трансформация, маппинг схем, дедупликация - все критично и специфично для вашего случая)
  • Правила управления и безопасности (доменно-специфичные и важные для соответствия требованиям)
  • Оптимизация затрат и маршрутизация моделей (нужна видимость того, что стоит денег)

Покупайте или используйте готовое:

  • Большие и малые языковые модели (экосистема open-source богата)
  • Возможности edge-инференса (edge inference от Akamai меняет правила игры для масштаба)
  • Векторные базы данных (Milvus доказал себя)
  • MCP-фреймворки (LangGraph или CrewAI - надежный выбор)
  • DevOps и MLOps платформы (если нет очень специфичных потребностей)
  • Экспериментальные платформы (Weights & Biases, Comet или MLflow для версионирования моделей)

Революция edge-инференса

Вот что не получает достаточно внимания: инференс не обязан происходить в централизованной инфраструктуре. Edge-инференс критичен для масштаба. Когда вы стремитесь к миллиону TPS, централизация всего инференса становится узким местом. Akamai и CloudFlare делают невероятные вещи здесь. Серьезно рассмотрите это.

Получите экспертную консультацию по оптимизации AI-инфраструктуры на AI Projects - специалисты помогут выбрать оптимальную архитектуру для ваших задач.

Стратегия точек интеграции

Это про защиту от будущего. Ваш стек нуждается в множественных точках интеграции: API-driven, модульный, заменяемый. Вы будете менять модели. Вы будете внедрять новые платформы. Если вы жестко связаны с каким-то одним компонентом, вы готовите себе боль.

Выводы, которые важны

После построения и перестройки этих систем я точно знаю следующее:

Во-первых, фундаментальные столпы корпоративной системы по-прежнему важны. Масштаб, надежность, безопасность - они не исчезают с добавлением AI. Они становятся критичнее.

Во-вторых, интеллект должен быть вплетен в корпоративную ткань, а не прикручен сверху. Ваша агентная архитектура должна рассуждать, адаптироваться, сотрудничать и, что критично, работать с существующими системами.

В-третьих, определите бизнес-кейс сейчас. Не через три месяца. Не после дополнительных исследований. Сейчас. Используйте промпты и агенты, чтобы построить что-то сегодня. Но признайте, что это только первая стадия.

В-четвертых, создайте рабочее пространство, установив агентные правила и структуры, специфичные для вашей области. Это не следование чужому плану, это создание собственного.

В-пятых, создавайте надежные рабочие процессы приложений, обрабатывающие память, контекст и графы знаний. Это становится вашим богатством информации, которое только вы можете создать для своей конкретной области.

В-шестых, безжалостно файн-тюньте. Общие языковые модели не справятся. Используете ли вы LoRA, QLoRA или другие методы - нужны модели, понимающие ваш специфический контекст.

В-седьмых, инвестируйте в лучшие методы инференса. Edge-based инференс не опционален, если хотите масштабироваться. Думайте в масштабе Meta, а не MVP.

Наконец, владейте своей областью. Прикладной слой, данные, поведение пользователей - это ваше. Они переживут любой конкретный технологический выбор, сделанный сегодня.

Итог

Построение агентного стека ощущается как возведение здания во время землетрясения. Все смещается, эволюционирует, улучшается. Но некоторые вещи остаются константами: потребность в надежной архитектуре, ценность ваших данных и важность построения для изменений, а не для стабильности.

Ваш прикладной слой и генерируемые им данные останутся с вами долго после того, как сегодняшний горячий фреймворк устареет. Стройте стек так, чтобы захватывать и использовать эту ценность. Сделайте его достаточно гибким для эволюции, но достаточно стабильным, чтобы на него полагаться.

Модели изменятся. Фреймворки эволюционируют. Но проблемы, которые вы решаете, и ценность, которую создаете? Это ваше владение. Стройте соответственно.