Сравнение с собственной разработкой

Прототип AI-шлюза сделать легко. Но скорость исполнения, онлайн-расчет стоимости и работа без инцидентов обходятся дорого — и технологически, и организационно.

Кратко

Направление	Meridian	Собственный шлюз
Конкурентные операции над бюджетом	Резерв и списание согласуются кворумом узлов, списание по иерархии — одна атомарная запись	Как-то преодолеть блокировки в базе данных при работе с иерархиями бюджетов и счетчиков rate-limit
Профиль нагрузки	Спроектирован под преобладание операций изменения данных	Констурирование архитектуры серверного приложени с нуля, привычная архитектура stateless-сервисов не подходит
Целостность данных на нескольких узлах	Встроена: кластер, кворум, журнал на каждом узле	Задача уровня разработки собственной СУБД или биржевого процессинга
Изменения цен и кеширования у провайдеров	Каталог цен синхронизируется автоматически, цены переопределяются из Web или API	Постоянный мониторинг изменений внешних контрактов и доработка кода шлюза
Архитектура	Релизована поддержка множественных Raft-групп, собственный протокол коммуникации, локального хранения, встроенный распределенный кэш, система реконсиляции данных между узлами во время их обновления через Web-интерфейс или API	Нужен специалист по распределённым системам с первого дня
Сопровождение	Входит в продукт	Команда из нескольких инженеров даже для небольшого продукта
Автоматизация тестирования	Не требуется	Инфраструктура для сотен тестов, ежемесячный бюджет на токены AI-провайдеров для тестов

Конкурентные операции над бюджетом

Каждый запрос к модели меняет данные: резервирует бюджет, управляет пулом воркеров, списывает фактическую стоимость, обновляет счётчики лимитов. Много параллельных запросов порождают параллельные операции над одним и тем же бюджетом или над всей иерархией «виртуальный ключ → команда → заказчик».

Профиль нагрузки AI-шлюза противоположен классическому веб-сервису:

	Классический веб-сервис	AI-шлюз
Операции чтения	~95%	~1%
Операции изменения данных	~5%	~99%

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

Параллельная обработка в памяти с высокой надёжностью и целостностью данных на нескольких сетевых узлах — задача уровня computer science. По сложности она сравнима с созданием собственной специализированной базы данных или системы высоконагруженного процессинга биржевых или банковских транзакций.

В Meridian эта задача решена: операции с бюджетом реализованы через операции атомарного резервирования с кворумом записи в кластере. После получение ответа от AI-провайдера уже фактическая цена запроса также попадает с подтверждением кластера в журнал на каждом узле. Это позволяет увеличить пропускную способность каждого узла без затрать на более дорогие сервера и даже с увеличением надежности. Но это сильно усложняет архитеткру всего приложения, так как необходимо поддерживать в памяти большое количество согласованных объектов: цены, настройки маршрутизации, алиасы моделей, какой сейчас узел является лидером группы и т.п. Что трубует высокую компетенцию и опыт в разработке распредленных систем. Подробнее — Кластеризация и Политики резервирования бюджета.

Изменения на стороне провайдеров

AI-провайдеры постоянно оптимизируют затраты на инференс и меняют условия:

вводят и меняют механизмы кеширования промптов и их тарификацию;
меняют цены в зависимости от размера запроса — отдельные тарифы для длинного контекста;
добавляют режимы обработки с собственными ценами: batch, priority, flex.

В собственном шлюзе эти изменения нужно отслеживать и оперативно переносить в код. Иначе расчёт стоимости расходится со счетами провайдера.

В Meridian каталог цен синхронизируется автоматически и учитывает цены кеширования, тарифы по размеру контекста и режимам обработки. Собственные цены задаются переопределениями из веб-интерфейса или API без перезапуска. Подробнее — Кастомные цены.

Общая сложность

Промышленный AI-шлюз состоит из нескольких логических слоёв:

серверный транспорт — приём запросов и совместимость с API провайдеров;
фреймворки — безопасность, управление бюджетами, учёт данных и логирование, управление кластером и кластерные транзакции;
каталоги — провайдеры, модели и цены, в том числе собственные;
ядро обработки — маршрутизация и выполнение AI-запросов.

Без специалиста с опытом построения распределённых процессинговых систем архитектуру не заложить правильно на старте. Без детального понимания каждого слоя AI-ассистент, даже с контекстом в миллион токенов, предлагает изобретать велосипеды и заводит в тупики, где прежние решения несовместимы с новыми. В итоге даже небольшой продукт требует на сопровождение нескольких инженеров.

Затраты на автоматизацию разработки

Шлюз без автоматических тестов быстро накапливает регрессии. Собственная разработка требует затрат на:

инфраструктуру для сотен автоматических тестов: обработка запросов через реальных провайдеров и моки, внутренние фреймворки, тяжёлые кластерные тесты и UI-тесты;
токены: прямые затраты на тестирование непосредственно с провайдерами;
подписки на сервисы и инструменты разработки.

С Meridian эти затраты несёт разработчик продукта, а ваша команда занимается собственными AI-сервисами.

Дальше

Сравнение с LiteLLM — отличия от популярного open-source шлюза.
Кластеризация — архитектура отказоустойчивого кластера.
Политики резервирования бюджета — защита от перерасхода.
Кастомные цены — собственные тарифы поверх каталога цен.