OpenRouter или прямое подключение: выбираем способ вызова LLM

Три способа организовать вызов LLM

1) Прямое обращение к API поставщика

Вы интегрируетесь с конечной точкой одного поставщика и берёте на себя всё остальное: повторные попытки, резервные варианты, учёт использования, ротацию ключей и переключение при сбоях.

Это самый простой путь, когда:

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

2) Шлюз / агрегатор / ретранслятор

Вы отправляете запросы промежуточному слою, который пересылает их одному из множества поставщиков. OpenRouter — самый известный пример, но этот подход не ограничивается какой-либо одной компанией.

Это привлекательный вариант, когда:

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

3) Самостоятельное размещение

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

Этот вариант выигрывает, когда:

• контроль над данными — обязательное требование,
• объём запросов достаточно велик, чтобы оборудование не простаивало,
• или вам нужна предсказуемая стоимость в расчёте на токен и вы готовы взять на себя эксплуатационную нагрузку.

Что меняется на практике

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

Таблица скрывает важную истину: шлюз редко экономит деньги сам по себе. Он экономит деньги, когда помогает избежать излишнего усложнения, сокращает простои или позволяет автоматически направлять задачи в самую дешёвую модель с приемлемым качеством.

За счёт чего на самом деле меняются расходы

Если вы используете одну модель для всех задач, прямые вызовы часто оказываются самым простым и дешёвым вариантом. Но большинство реальных систем устроено сложнее:

• чат в продукте использует премиальную модель,
• черновики ответов службы поддержки создаёт более дешёвая модель,
• для суммаризации используется небольшая быстрая модель,
• а для всплесков трафика нужны резервные мощности.

Именно здесь может помочь посредник. Не потому, что у него ниже заявленные цены, а потому, что он позволяет централизованно принимать решения о маршрутизации.

Простая политика может выглядеть так:

{
  "primary": "anthropic/claude-sonnet-4.6",
  "fallbacks": [
    "openai/gpt-5.5",
    "google/gemini-3"
  ],
  "cheap_path": "openai/haiku-class",
  "timeout_ms": 8000,
  "retry_on": ["rate_limit", "timeout", "upstream_5xx"]
}

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

• не отправляйте каждую задачу извлечения данных в самую дорогую модель,
• не повторяйте бесконечно запросы к нестабильному поставщику,
• не поддерживайте вторую интеграцию только ради 2% трафика, приходящихся на пятничные всплески.

Распространённая ловушка: если ваше приложение вызывает инструменты или выполняет действия с побочными эффектами, повторные попытки могут дублировать действия. Если шлюз повторяет запрос после тайм-аута, модель может снова выдать тот же вызов функции. Без ключей идемпотентности и тщательно продуманных инструментов «полезное переключение на резервный вариант» превращается в «создан дубликат заявки» или «платёж списан дважды».

Когда шлюз действительно помогает

Я бы выбрал агрегатор или посредник, если выполняется хотя бы одно из следующих условий:

• Вы ещё изучаете характер нагрузки. На начальном этапе вы не знаете, что лучше справится с вашей задачей: GPT-5.5, Claude Opus 4.8, Sonnet 4.6, Gemini 3 или открытая модель.
• Вам нужна маршрутизация по задачам, а не по поставщикам. Классификатор может направлять короткие промпты в дешёвую быструю модель, а задачи с длинным контекстом — в модель вроде Fable 5, когда она действительно лучше подходит.
• Вам нужно быстрое переключение на резервный вариант. Если один поставщик начинает ограничивать частоту запросов, посредник может перенаправить трафик до того, как пользователи это заметят.
• Вы не хотите работать с пятью системами оплаты. Один счёт и одна интеграция проще, чем управление множеством ключей, квот и панелей расходов.
• Вам нужен слой абстракции для мультитенантных продуктов. Шлюз позволяет менять поставщиков внутри системы, не переписывая приложение.

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

Когда прямые вызовы — лучший выбор

Прямые API поставщиков обычно выигрывают, если для вас важно что-либо из следующего:

• Минимальная задержка. Отсутствие одного промежуточного перехода имеет значение, когда допустимая задержка в продукте невелика. Если вы хотите, чтобы взаимодействие за 300 мс ощущалось мгновенным, дополнительные сетевые затраты и маршрутизация могут отнять ощутимую часть этого времени.
• Строгие границы обработки данных для соблюдения требований. Каждый дополнительный обработчик данных — это ещё одно взаимодействие, ещё один набор правил хранения и ещё одна проверка договора.
• Возможности конкретного поставщика. Некоторые поставщики предоставляют возможности, которые агрегаторы либо убирают при унификации, либо поддерживают с опозданием.
• Большой и предсказуемый объём запросов. Когда объём использования становится стабильным, собственная маршрутизация может обходиться дешевле, чем оплата промежуточного слоя.
• Более понятный порядок обращения в поддержку. Когда что-то ломается, стороны реже перекладывают ответственность друг на друга.

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

Самостоятельное размещение — другая задача

Самостоятельное размещение открытых моделей — это не просто «более дешёвый API, но на моём сервере». Это задача построения и эксплуатации систем.

Вам нужно продумать:

• подбор GPU и их загрузку,
• пакетную обработку,
• квантизацию,
• нагрузку на KV-кеш,
• автоматическое масштабирование,
• запуск с предварительной подготовкой,
• фильтры безопасности,
• обновления моделей,
• и процедуры отката.

Преимущество — контроль. Если ваша нагрузка стабильна и достаточно велика, самостоятельное размещение может быть экономически привлекательным. Но расчёты сходятся только при постоянной загрузке оборудования. Простаивающие GPU обходятся дорого. Как и время инженеров, необходимое, чтобы обеспечить стабильную работу стека обслуживания моделей под нагрузкой.

Ещё одна распространённая ловушка — изменение качества. Сегодня открытая модель может достаточно хорошо справляться с суммаризацией, но результаты оценок могут резко ухудшиться при изменении длины промптов, требований к стилю или использования инструментов. Не считайте, что «открытая» автоматически означает «достаточно дешёвая для замены управляемого API».

Практическая гибридная схема

В реальных системах лучшая архитектура часто сочетает разные подходы:

# direct path for latency-sensitive traffic
export LLM_ROUTE=direct
export LLM_PROVIDER=anthropic
export LLM_MODEL=claude-sonnet-4.6

# relay path for experimental or burst traffic
export LLM_ROUTE=gateway
export LLM_MODEL=openai/gpt-5.5

А внутри приложения:

def choose_route(task_type, tenant_tier, prompt_tokens):
    if task_type == "tool_calling":
        return {"route": "direct", "model": "anthropic/claude-sonnet-4.6"}
    if prompt_tokens > 120_000:
        return {"route": "gateway", "model": "openai/gpt-5.5"}
    if tenant_tier == "free":
        return {"route": "gateway", "model": "openai/haiku-class"}
    return {"route": "direct", "model": "google/gemini-3"}

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

Конфиденциальность, задержка и доверие

Здесь инженерные решения переходят в область правил и политик.

Конфиденциальность

Шлюз меняет вашу границу доверия. Даже если промпты пересылаются конечному поставщику, вам всё равно нужно ответить на вопросы:

• Записывает ли посредник промпты в журналы?
• Как долго они хранятся?
• Какие субобработчики имеют к ним доступ?
• Можно ли ограничить маршрут обработки для отдельных тенантов?
• Поддерживается ли привязка к региону?

Для нагрузок, подпадающих под регуляторные требования, недостаточно того, что «поставщик обещал вести себя надлежащим образом». Нужны документальные подтверждения и соответствующая им архитектура.

Задержка

Посредник добавляет ещё один переход. Это не делает приложение медленным автоматически, но добавляет неопределённость. Если приложение часто обменивается запросами и потоковая передача токенов важна, каждый дополнительный слой может сделать время до первого токена менее предсказуемым.

Ограничения частоты запросов

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

Моё правило выбора

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

Несколько конкретных практических правил:

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

Практические рекомендации

• Отдавайте предпочтение прямым API для минимальных накладных задержек, самой простой отладки и наиболее полной поддержки возможностей конкретного поставщика.
• Отдавайте предпочтение шлюзу или агрегатору когда нужны маршрутизация между моделями, резервные варианты или одна интеграция для работы со многими поставщиками.
• Отдавайте предпочтение самостоятельному размещению только если можете обеспечить загрузку оборудования и готовы принять сложность эксплуатации.
• Обеспечьте идемпотентность и строгие правила повторных попыток прежде чем добавлять автоматическое переключение на резервные варианты.
• Сравните полную стоимость: токены, наценку, повторные попытки, время инженеров и восстановление после инцидентов.
• Храните конфиденциальность и сроки хранения данных при принятии решения с самого начала, а не после вопросов отдела закупок.
• Используйте гибридную архитектуру если в вашей рабочей нагрузке есть как премиальные, так и массовые сценарии.

Если хотите, я могу сделать этот текст более категоричным и адаптировать его для конкретной аудитории: создателей стартапов, платформенных команд или корпоративных команд со строгими требованиями к соблюдению нормативов.