Сравнение с LiteLLM

Кратко

---

Финансы

Резервирование бюджета для каждого запроса

Перерасход бюджета — прямой убыток AI-сервиса: провайдер выставляет счёт за выполненный запрос, даже если клиент уже исчерпал оплаченный лимит. Meridian резервирует сумму до отправки запроса провайдеру и списывает фактическую стоимость после ответа. Это практически устраняет риск перерасхода даже при параллельных запросах.

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

В Meridian резервирование включено по умолчанию и настраивается без изменения кода:

• Flat — фиксированная сумма на запрос, политика по умолчанию;
• Worst-case — верхняя оценка стоимости по каталогу цен модели;
• переопределения по моделям — например, фиксированный резерв для дешёвых моделей и оценка по каталогу для дорогих.

В LiteLLM строгое соблюдение бюджета зависит от способа развёртывания. Счётчик расходов на горячем пути хранится в Redis, а база данных сверяется в фоне. Если Redis перезапустится со старым снимком, счётчик может показать меньше фактических трат. Чтобы исключить это, нужно принудительно включить режим fail_closed_budget_enforcement: в нём каждый запрос с бюджетом сверяется с базой данных, что кратно снижает производительность. Альтернатива — Redis, который добавляет затраты на инфраструктуру и ещё одну точку отказа. Источник: Budgets, Rate Limits.

Подробнее — Политики резервирования бюджета.

Предварительная оценка стоимости запроса

Политика Worst-case оценивает максимальную стоимость запроса по каталогу цен ещё до обращения к провайдеру. Запрос, который не помещается в остаток бюджета, отклоняется сразу.

Это позволяет строить сервисы с дорогой интеллектуальной частью и небольшим бюджетом на пользователя:

• пробные периоды с жёстким лимитом;
• низкий порог входа для первого использования;
• самые дешёвые подписки с полным набором функций.

Кворумное подтверждение и журналирование транзакций

Операции с бюджетом в Meridian подтверждаются кворумом узлов кластера (Raft) и записываются в локальный журнал каждого узла. Состояние бюджетов асинхронно синхронизируется в PostgreSQL.

• Нет блокировок в базе данных на иерархиях бюджетов. Списание по цепочке «виртуальный ключ → команда → заказчик» — одна атомарная запись в Raft-группе шарда, а не серия транзакций в базе. Блокировки не возникают даже при высокой частоте запросов.
• Нет задвоения транзакций при сбоях. Операция считается выполненной только после подтверждения кворумом. Отказ узла или кластера базы данных не приводит к повторному или потерянному списанию.

Подробнее — Кластеризация и Шардинг.

Самодиагностика перед обработкой запроса

Meridian перед обработкой запроса проверяет, успеет ли он его выполнить. Если задержка подтверждения операций или очередь шарда превышает пороги, новый запрос сразу получает ответ 503 с заголовком Retry-After — до обращения к провайдеру. Уже начатые запросы при этом завершаются и учитываются. Узел, который не может обслуживать трафик, отвечает 503 на пробу готовности, и балансировщик выводит его из ротации.

В документации LiteLLM механизм отклонения запросов при перегрузке не описан — для роста нагрузки рекомендуется автомасштабирование по CPU. Источник: Production Best Practices. Без такого механизма шлюз принимает все входящие запросы. Из-за конкуренции за ресурсы, в том числе во внешней базе данных, время обработки растёт и становится непредсказуемым. Когда оно превышает таймауты протокола, шлюз уже не может принять ответ провайдера или передать его пользователю. Владелец шлюза оплачивает запрос провайдеру, но не оказывает услугу: сервис деградирует непредсказуемо и с прямым ущербом.

Подробнее — Управление нагрузкой шарда.

---

Операционные затраты

• В Meridian НЕТ затрат на промежуточные кеширующие серверы. Распределённый кэш встроен в узлы Meridian. LiteLLM для работы нескольких экземпляров требует Redis (Production Best Practices).
• В Meridian НЕТ потребности в дорогих серверах. Менее производительные серверы обеспечивают не меньший уровень производительности.
• В Meridian НЕТ затрат на автоматизацию обновления без потери трафика. Узлы обновляются по одному без окна обслуживания. Не нужно разрабатывать сценарии обновления, держать резервные мощности и тратить время на согласование работ.
• В Meridian НЕТ затрат на автоматику восстановления кластера. Не нужно разрабатывать и сопровождать собственные скрипты и плейбуки восстановления после сбоев. Достаточно подключить балансировщик нагрузки и указать ему пробы живости и готовности узлов: /internal/live и /internal/ready.

Как кластер восстанавливается сам

Топология и состояние кластера хранятся в служебной Raft-группе: состав узлов, размещение реплик шардов и их версии. Любое изменение топологии подтверждается кворумом узлов, поэтому узлы не расходятся во взглядах на состав кластера.

• Контур авто-восстановления. Лидер служебной группы регулярно сверяет живой кластер с объявленной топологией. Вернувшийся после сбоя узел снова получает реплики шардов, а безопасные ремонты применяются без участия оператора.
• Подключение узлов согласовано с кворумом. Новая реплика сначала подключается без права голоса, догоняет журнал и только затем становится голосующей. Кворум шарда при этом не нарушается.
• Трафик — только на готовые узлы. Узел отвечает 200 на пробу готовности, только когда подключён к кластеру и его шарды имеют кворум. До этого балансировщик не направляет на него запросы.

Автоматика не трогает шард, потерявший кворум: восстановление в этом случае — решение оператора, чтобы исключить потерю данных. Подробнее — Эксплуатация кластера.

Подробнее — Типичная конфигурация кластера.

---

Производительность и пользовательский опыт

• Низкая задержка — и при потоковой передаче, и в режиме запрос-ответ.
• Больше возможностей фильтрации логов запросов: по провайдерам, моделям, алиасам, виртуальным ключам, заказчикам, командам, пользователям, бизнес-подразделениям, правилам маршрутизации, метаданным запросов и кэшированию.

---

Безопасность

• Контролируемый список зависимостей. Meridian поставляется единым исполняемым файлом с зафиксированными зависимостями. Для сравнения: 24 марта 2026 года в PyPI около 40 минут были доступны скомпрометированные версии пакета litellm 1.82.7 и 1.82.8. По заявлению LiteLLM, официальный Docker-образ LiteLLM Proxy не пострадал. Источники: Security Update, Datadog Security Labs.
• LDAP даже в бесплатной редакции. Синхронизация пользователей и групп из каталога доступна во всех редакциях. В Community — до 50 учётных записей. Подробнее — LDAP-каталог.

---

Затраты и лицензии

• Меньше затрат на серверы — до 50%.
• Меньше затрат времени DevOps-инженеров — до 50%.
• Ниже риски потери трафика и прямого ущерба от сбоев.
• ClickHouse для логов запросов. Долговременное аналитическое хранилище снижает стоимость хранения и анализа истории запросов.
• Лицензия и расширенная поддержка в России.

---

Дальше

• Политики резервирования бюджета — как настроить резервирование.
• Кластеризация — архитектура отказоустойчивого кластера.
• Защита от опустошения бюджета и отказа в обслуживании — сценарий защиты бюджета.
• Отладка и аудит LLM-приложений — логи и аналитика запросов.