Lynkr: ваш личный диспетчер для 15+ LLM, который экономит деньги и нервы

Зачем платить за GPT-4, если Llama 3 справится?

Вы отправляете простой запрос на классификацию текста. Ваше приложение бездумно шлет его в GPT-4 Turbo. Счетчик API тикает: $0.01, $0.02, $0.03. За месяц набегает сотня долларов за задачи, которые быстрее и дешевле решила бы локальная Llama 3 через Ollama. Знакомо?

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

Что умеет Lynkr? Не только маршрутизация

• Поддержка 15+ провайдеров: OpenAI, Anthropic (Claude), Google (Gemini), Cohere, Together AI, Fireworks AI. И что важно — локальные модели через Ollama.
• Иерархическая маршрутизация: Основная фишка. Вы настраиваете цепочки приоритетов. Сначала пробуем локальную модель. Не справилась — идем в дешевое облако. Снова мимо — только тогда запускаем тяжелую артиллерию вроде GPT-4.
• Автоматическое падение (Fallback): Если выбранный провайдер недоступен или выдает ошибку, Lynkr автоматически переключается на следующий в цепочке.
• Единый API интерфейс: Все провайдеры выглядят для вашего приложения одинаково. Меняете конфигурацию маршрутизации на лету — код приложения не трогаете.
• Особенная любовь к Claude Code: Можно явно указать, что запросы, содержащие ключевые слова вроде "code", "function", "debug", должны идти напрямую к Claude. Это то, за что его и ценят.

Lynkr vs остальные: не перепутайте с аналогами

На рынке есть другие инструменты. LLMRouter — это библиотека для Python, которую нужно встраивать в код. Basis Router (про него мы писали) больше заточен под работу с базами данных.

Lynkr — это самостоятельный сервер (прокси). Его главное преимущество — независимость от стека технологий вашего основного приложения. Запустил раз, настроил правила — и все микросервисы, скрипты и демоны ходят через него. Не нужно обновлять десять разных кодовых баз.

1Ставим и запускаем за 2 минуты

Lynkr написан на Go. Бинарник весит немного. Устанавливается элементарно.

# Самый простой способ - через go install (нужен установленный Go)
go install github.com/lynkr/lynkr@latest

# Или качаем готовый бинарник с GitHub Releases
curl -L -o lynkr https://github.com/lynkr/lynkr/releases/latest/download/lynkr_linux_amd64
chmod +x lynkr

2Пишем конфиг. Здесь и кроется магия

Создаем файл config.yaml. Вот пример, который уже экономит деньги:

# config.yaml
server:
  port: 8080  # Lynkr будет слушать здесь

providers:
  # Локальная модель через Ollama - БЕСПЛАТНО
  - name: "local-llama"
    type: "ollama"
    base_url: "http://localhost:11434"
    model: "llama3"
    priority: 1  # Пробуем сначала всегда её

  # Дешевый облачный вариант
  - name: "gpt-cheap"
    type: "openai"
    api_key: "${OPENAI_KEY}"
    model: "gpt-3.5-turbo"
    priority: 2

  # Дорогой, но умный - только для сложного
  - name: "gpt-smart"
    type: "openai"
    api_key: "${OPENAI_KEY}"
    model: "gpt-4-turbo"
    priority: 3

  # Специалист по коду - сработает на ключевые слова
  - name: "claude-coder"
    type: "anthropic"
    api_key: "${ANTHROPIC_KEY}"
    model: "claude-3-sonnet-20240229"
    priority: 2
    # Магия: отправляем в Claude только если в запросе есть эти слова
    condition:
      prompt_contains: ["code", "function", "debug", "algorithm", "sql"]

# Правила маршрутизации по умолчанию
routing:
  default_chain: ["local-llama", "gpt-cheap", "gpt-smart"]

Что здесь происходит? Все запросы идут по цепочке local-llama → gpt-cheap → gpt-smart. Но если пользователь просит что-то про "code", условие prompt_contains перехватывает запрос и отправляет его сразу в claude-coder (с приоритетом 2, то есть после бесплатной локальной модели, но перед дорогим GPT-4).

3Запускаем и тестируем

# Экспортируем ключи (безопаснее, чем хранить в конфиге)
export OPENAI_KEY="sk-..."
export ANTHROPIC_KEY="sk-ant-..."

# Запускаем Lynkr с нашим конфигом
./lynkr --config ./config.yaml

# Сервер запущен на http://localhost:8080
# Теперь вместо прямого вызова OpenAI API, шлем запросы в Lynkr

Как это выглядит в коде вашего приложения? Почти так же, как работа с OpenAI, но базовый URL меняется.

# БЫЛО (дорого)
from openai import OpenAI
client = OpenAI(api_key="ваш_ключ")
response = client.chat.completions.create(
    model="gpt-4-turbo",  # Всегда платим за GPT-4
    messages=[{"role": "user", "content": "Привет!"}]
)

# СТАЛО (умно и экономно)
from openai import OpenAI
# Меняем только базовый URL на адрес Lynkr!
client = OpenAI(api_key="any-dummy-key", base_url="http://localhost:8080/v1")
# Lynkr сам решит, какую модель использовать
response = client.chat.completions.create(
    model="*",  # Или можно указать конкретную цепочку
    messages=[{"role": "user", "content": "Напиши функцию сортировки на Python"}]  # Уйдет в Claude!
)

Где Lynkr спасет ваш проект (а где нет)

Берите Lynkr, если:

• Ваш счет за API LLM превышает $200 в месяц и растет.
• У вас уже крутятся локальные модели через Ollama (или вы прочитали наш гайд и готовы их запустить).
• В проекте используются разные типы запросов: одни простые (чат), другие сложные (анализ), третьи специфические (код).
• Вы хотите иметь план Б на случай, если у облачного провайдера начнутся проблемы. (Все помнят падения OpenAI?)
• Вы экспериментируете с разными моделями и хотите легко их переключать без переписывания кода.

Не тратьте время на Lynkr, если:

• У вас 100 запросов в месяц. Экономия будет копеечная, а настройка отнимет час.
• Все ваши запросы — сверхсложные, требующие максимальной точности. Просто используйте GPT-4 и платите.
• Вам нужна наносекундная задержка. Прокси добавляет небольшую overhead (менее 10 мс, но все же).
• Вы боитесь усложнения инфраструктуры. Еще один сервис — еще одна точка отказа. (Хотя Lynkr стабилен).

Под капотом: что может пойти не так?

Lynkr — не серебряная пуля. (Кстати, о том, почему LLM вообще не серебряные пули, мы уже говорили).

Первая проблема — консистентность. Если простой запрос в понедельник обработала Llama 3, а во вторник — GPT-3.5, ответы могут немного отличаться по стилю. Для чата это не страшно. Для формализованных задач — может быть.

Вторая — отладка. "Почему мой запрос пошел в Claude, а не в GPT-4?" Нужно смотреть логи Lynkr. Разработчики добавили подробное логирование, но это еще один источник, который нужно мониторить.

Третья — условия маршрутизации. Они сейчас простые (prompt_contains). Не ждите семантического анализа запроса. Если пользователь напишет "как сделать сортировку" без слова "code", запрос может не попасть к Claude. Настраивайте условия аккуратно, тестируйте на реальных данных. Используйте коллекции промптов для проверки.

Что дальше? Куда смотрит Lynkr

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

Главное, что Lynkr делает правильно — он решает конкретную, больную проблему: неконтролируемые расходы на LLM. Он не пытается быть всем для всех. Он — умный диспетчер. И в мире, где каждый месяц появляются новые модели с разными ценами и сильными сторонами, такой диспетчер становится не роскошью, а необходимостью.

Запустите его на тестовом стенде. Подключите Ollama с какой-нибудь легкой моделью. Настройте правило, чтобы все запросы с словом "привет" шли только локально. Увидите, как это работает. А потом начнете перенаправлять туда же все простые вопросы пользователей. Счет за API скажет вам спасибо. А вы — своему прошлому себе, который потратил полчаса на настройку.