Claudexia vs самохост LiteLLM: купить или собрать Claude-шлюз в 2026

Любая команда, которая масштабирует использование Claude дальше пары инженеров, рано или поздно упирается в одну и ту же развилку: ставить ли шлюз перед Anthropic API, и если да — поднимать самим или платить кому-то за управляемый сервис. Дефолтный open-source ответ в 2026 году — LiteLLM, популярный Python-прокси, который прячет 100+ провайдеров моделей за единым OpenAI-совместимым API. Дефолтный managed-ответ — Claudexia. Этот пост — трезвое сравнение двух подходов: реальные цифры TCO, операционная нагрузка, на которую вы подписываетесь, и те границы безопасности и комплаенса, где каждое решение объективно выигрывает.

Что такое LiteLLM на самом деле

LiteLLM начинался как тонкая Python-библиотека, которая нормализовала вызовы OpenAI, Anthropic, Cohere и других за одной функцией litellm.completion(). Со временем он вырос в полноценный прокси-сервер с control plane на PostgreSQL: виртуальные API-ключи, бюджеты на ключ, rate limits, иерархия команд и пользователей, audit log, админка и webhook-колбэки. Вы деплоите его контейнером, прописываете upstream-ключи провайдеров, а ваше приложение ходит в ваш прокси через OpenAI SDK с кастомным base_url.

Это действительно хорошее ПО. Это также ПО, которое теперь принадлежит вам — вместе с патчами, инцидентами и capacity planning.

Реальный TCO самохоста LiteLLM

Прайс-тег у LiteLLM нулевой. Реальные расходы на production-шлюз для, скажем, команды из 20 инженеров и нескольких внутренних приложений выглядят примерно так в месяц:

• Compute. Две небольшие инстанции за балансировщиком плюс staging. $80–$150/мес на любом крупном облаке с учётом самого LB.
• PostgreSQL. Managed Postgres под control plane (ключи, расходы, audit log). $50–$120/мес за небольшой HA-тариф с бэкапами.
• Redis. Нужен для корректного распределённого rate limiting между репликами прокси. $20–$50/мес.
• Наблюдаемость. Логи, метрики, трейсы — Datadog, Grafana Cloud или ваш стек. Реалистично $50–$200/мес инкрементальных расходов, когда вы реально это инструментируете.
• Egress и TLS. Сертификаты бесплатные, egress в Anthropic — нет, и на масштабе он заметен.

Это примерно $200–$500/мес чистой инфраструктуры до того, как к ней прикоснулся человек. Инфраструктура — дешёвая часть.

Дорогая часть — люди. Production-шлюзу нужны:

• On-call ротация, которая владеет прокси, когда у Anthropic региональный инцидент, когда ваш Postgres делает failover в 03:00, или когда сбежавший агент сжигает бюджет виртуального ключа за десять минут.
• Security-патчинг контейнера LiteLLM, его базового образа и Python-зависимостей — прокси стоит на пути каждого промпта и каждого ответа, поэтому CVE здесь не опциональны.
• Регулярная ротация upstream-ключей Anthropic, виртуальных ключей для внутренних команд и админских кредов самого прокси.
• Апгрейды. LiteLLM релизится часто и иногда привозит миграции схемы или ломающие конфиг изменения; кто-то должен читать changelog и тестировать апгрейды на staging.

Если оценить senior-инженера в $150/час с учётом нагрузки и заложить четыре часа в неделю на устойчивое владение плюс редкие инциденты, это $2 000–$3 000/мес человеческого времени поверх инфры. Честный TCO «бесплатного» LiteLLM на умеренном масштабе ближе к $2 500–$3 500/мес, чем к нулю.

Управляемая альтернатива от Claudexia

Claudexia — продукт той же формы: виртуальные ключи, бюджеты, rate limits, audit log, OpenAI-совместимые и Anthropic-нативные эндпоинты — поставляемый как managed-сервис. Не нужно деплоить прокси, бэкапить Postgres, сайзить Redis и держать on-call. Регистрируетесь, выпускаете ключ, направляете SDK на https://api.claudexia.tech/v1 — всё. Тариф — оплата за токены по прямым ставкам Anthropic, без месячного минимума и платы за seat.

Поэтому buy-vs-build на умеренном масштабе сводится не к инфраструктуре. Вопрос в том, больше или меньше маржа, которую Claudexia забирает с токенов, чем те $2 500–$3 500/мес, которые вы иначе тратите на эксплуатацию LiteLLM. Для большинства команд под пару сотен миллионов токенов в месяц managed выигрывает уверенно.

Паритет фич одним взглядом

Функциональная поверхность под Claude практически идентична. Разница — кто это эксплуатирует и сколько провайдеров фронтит.

Безопасность: кто реально видит промпты

Этот вопрос должен влиять на решение сильнее TCO.

При самохосте LiteLLM промпты и ответы проходят через:

1. Ваше приложение.
2. Ваш LiteLLM-прокси (в вашем VPC).
3. API Anthropic.

Три участника, два из которых под вашим контролем. Логи, если они есть, живут в вашей инфраструктуре и наследуют ваши политики ретенции и доступа.

При Claudexia промпты и ответы проходят через:

1. Ваше приложение.
2. Шлюз Claudexia.
3. API Anthropic.

Три участника, один из которых — мы. Мы не храним содержимое промптов и ответов сверх необходимого для биллинга и отладки конкретного запроса и не используем его для обучения. Но вы доверяете нашему слову и нашему SOC 2, а не своим внутренним контролям. Большинству команд это подходит, некоторым — нет.

Комплаенс: когда самохост действительно обязателен

Есть сценарии, где самохост — не предпочтение, а требование:

• HIPAA-нагрузки, где вы не можете подписать BAA с вендором шлюза. Если ваш единственный BAA-покрытый путь к Claude — напрямую через Anthropic поверх AWS Bedrock, шлюз обязан жить внутри HIPAA-контура.
• Жёсткие границы SOC 2 / ISO 27001. Если ваш audit scope говорит, что никакие сторонние процессоры не касаются клиентских данных, managed-шлюз — это новый субпроцессор, которого пришлось бы декларировать, оценивать и защищать.
• Требования по data residency. Только-EU или только-RU роутинг, где трафик не должен покидать конкретный регион.
• Air-gapped или VPC-only окружения. Очевидно.

Если что-то из этого ваш случай — поднимайте LiteLLM. Разговор про TCO становится беспредметным.

Код: как реально выглядит сетап

Самохост LiteLLM, минимально жизнеспособный production:

# 1. Postgres + Redis уже подняты, далее:
docker run -d --name litellm \
  -e DATABASE_URL=postgres://... \
  -e REDIS_URL=redis://... \
  -e ANTHROPIC_API_KEY=sk-ant-... \
  -e LITELLM_MASTER_KEY=sk-master-... \
  -p 4000:4000 \
  ghcr.io/berriai/litellm:main-stable \
  --config /app/config.yaml

Плюс config.yaml со списком моделей, плюс Terraform на балансировщик, плюс алертинг, плюс бэкапы, плюс runbook на апгрейды.

Дальше приложение:

from openai import OpenAI

client = OpenAI(
    api_key="sk-virtual-key-for-this-team",
    base_url="https://litellm.internal.example.com/v1",
)
resp = client.chat.completions.create(
    model="claude-sonnet-4.6",
    messages=[{"role": "user", "content": "hello"}],
)

Claudexia, та же задача:

from openai import OpenAI

client = OpenAI(
    api_key="cdx-...",
    base_url="https://api.claudexia.tech/v1",
)
resp = client.chat.completions.create(
    model="claude-sonnet-4.6",
    messages=[{"role": "user", "content": "hello"}],
)

Код приложения намеренно одной формы — в этом и смысл OpenAI-совместимого стандарта. Разница в том, что второй сниппет — это весь сетап целиком.

Когда LiteLLM всё ещё выигрывает

Не будем делать вид, что Claudexia — правильный ответ для всех. LiteLLM лучше, когда:

• Вам нужно bring-your-own ключи под много провайдеров — OpenAI, Anthropic, Bedrock, Vertex, Azure OpenAI, Cohere, Mistral, Together, Groq, ваш собственный vLLM — за одним эндпоинтом. Claudexia Claude-сфокусированный; LiteLLM — мультипровайдерный швейцарский нож.
• Вам нужна кастомная Python-логика роутинга в самом прокси: pre-call хуки, переписывающие промпт, post-call хуки, редактирующие PII, fallback-цепочки между провайдерами или гардрейлы прямо в request path.
• У вас комплаенс-граница, запрещающая managed-субпроцессора, как обсуждалось выше.
• У вас уже есть зрелая платформенная команда, для которой ещё один сервис — погрешность округления.

Итог

Если вы Claude-first команда под пару сотен миллионов токенов в месяц, buy-решение очевидно: managed-шлюзы вроде Claudexia дешевле полной стоимости самостоятельного владения LiteLLM и освобождают инженеров, чтобы те шипали продукт, а не патчили прокси. Если вы мультипровайдерные, нуждаетесь в кастомном роутинге в request path или сидите внутри комплаенс-границы, которая запрещает сторонний шлюз — поднимайте LiteLLM сами и закладывайте в бюджет честную стоимость эксплуатации.

В любом случае не пропускайте шлюз вовсе. Ходить в Anthropic напрямую из двадцати разных сервисов с общим root-ключом — это худший из миров.