LiteLLM или готовый шлюз для Claude: купить или собрать

Пока Claude нужен паре инженеров, шлюз кажется лишним. Как только использование выходит за эти рамки, появляется развилка: ставить ли прокси перед Anthropic API, а если ставить, то поднимать его самим или платить за готовый. Open-source вариант по умолчанию в 2026 году это LiteLLM, популярный Python-прокси, который прячет 100+ провайдеров моделей за единым OpenAI-совместимым API. Управляемый вариант по умолчанию это codexkey. Ниже спокойное сравнение: посчитаем реальный TCO, покажем, какую эксплуатационную нагрузку вы берёте на себя, и отметим, где по безопасности и комплаенсу каждый вариант выигрывает по делу.

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

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

Программа хорошая. Но теперь она ваша, вместе с патчами, инцидентами и планированием мощностей.

TCO самохоста LiteLLM: сколько стоит «бесплатный» прокси

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

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

Всё вместе это примерно $200-$500 в месяц чистой инфраструктуры, пока к ней не притронулся человек. Инфраструктура здесь самая дешёвая часть.

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

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

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

Что входит в готовый шлюз codexkey

codexkey даёт именованные API-ключи, каналы Premium и Cheap, резервный Premium для Cheap, срок действия ключа и статистику расхода. Доступны и OpenAI-совместимые, и нативные Anthropic-эндпоинты. Чего нет в API ключей личного кабинета: бюджетов, RPM/TPM, параллелизма, списков моделей, IP-фильтров и ограничений IDE для ключа.

Поэтому выбор между покупкой и сборкой на умеренном масштабе упирается не в инфраструктуру. Сравниваются две суммы: маржа, которую codexkey берёт с токенов, и $2 500-$3 500 в месяц, которые вы иначе потратите на эксплуатацию LiteLLM. Пока вы укладываетесь в пару сотен миллионов токенов в месяц, управляемый вариант выигрывает уверенно.

Сравнение функций: LiteLLM и codexkey

Под Claude набор функций почти одинаков. Различаются два параметра: кто всё это эксплуатирует и сколько провайдеров стоит за шлюзом.

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

Решение стоит принимать скорее по этому вопросу, чем по TCO.

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

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

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

Если вы идёте через codexkey, путь такой:

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

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

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

Бывают случаи, когда самохост не предпочтение, а требование:

• HIPAA-нагрузки, если BAA с вендором шлюза подписать нельзя. Когда единственный путь к Claude с BAA идёт напрямую через Anthropic поверх AWS Bedrock, шлюз должен стоять внутри HIPAA-контура.
• Жёсткие границы SOC 2 или ISO 27001. Если в scope аудита записано, что сторонние процессоры не касаются клиентских данных, управляемый шлюз превращается в нового субпроцессора. Его придётся декларировать, оценивать и защищать перед аудитором.
• Требования к резидентности данных. Трафик нельзя выпускать за пределы региона, поэтому маршрутизация идёт только в ЕС или только в РФ.
• Изолированные (air-gapped) контуры и окружения только внутри VPC. Здесь обсуждать нечего.

Узнали свой случай? Поднимайте 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 для балансировщика, алертинг, бэкапы и регламент апгрейдов.

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

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-5",
    messages=[{"role": "user", "content": "hello"}],
)

Та же задача через codexkey:

from openai import OpenAI

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

Код приложения одинаковый намеренно: в этом смысл OpenAI-совместимого стандарта. Отличие в другом: второй фрагмент и есть вся настройка.

Когда лучше LiteLLM

Выдавать codexkey за ответ для всех мы не будем. LiteLLM подходит лучше, если:

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

Итог

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

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