Как подключить AI-модель через OdiRouter за несколько минут

Как мы подключили несколько AI-моделей через один API и начали управлять стоимостью запросов

Подзаголовок

Практический пример для разработчиков: Telegram-бот поддержки, OpenAI-compatible API, разные модели под разные задачи и контроль расходов через OdiRouter.ai.

Текст статьи

Когда команда впервые добавляет LLM в продукт, интеграция обычно выглядит просто: берем одну сильную модель, подключаем SDK, пишем первый prompt и получаем работающий прототип. Проблемы начинаются позже, когда сценариев становится больше, нагрузка растет, а стоимость запросов перестает быть абстрактной строкой в документации.

В реальном продукте одна модель редко оказывается оптимальной для всего. Быстрые ответы в Telegram-боте, суммаризация длинных диалогов, классификация обращений, генерация текста для оператора и сложный reasoning требуют разного качества, разной скорости и разной экономики.

Ниже простой пример архитектуры, где AI используется в Telegram-боте поддержки. Это не идеальный benchmark и не лабораторный тест, а типичный продуктовый сценарий: нужно быстро подключить несколько моделей, не переписывать код под каждого провайдера и понимать, где расходуются деньги.

В качестве API-слоя используем OdiRouter.ai: https://odirouter.ai/?utm_source=vc&channel=blog

OdiRouter.ai это AI API Router с доступом к 200+ моделям через один ключ, OpenAI-compatible интерфейсом, прозрачными ценами и оплатой в рублях.

Задача: один бот, несколько AI-сценариев

Представим Telegram-бот для первой линии поддержки SaaS-продукта. У него есть три AI-задачи:

быстро ответить на типовой вопрос пользователя

суммаризировать длинный диалог для оператора

разобрать сложное обращение и предложить следующий шаг

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

Поэтому разумнее разделить задачи:

fast_reply — недорогая модель для коротких ответов

summary — модель с хорошим соотношением цены и качества на длинном контексте

deep_analysis — более сильная LLM для сложных случаев

Главная идея: модель выбирается не вручную внутри бизнес-логики, а через отдельный конфигурационный слой.

MODELBYTASK = {"fastreply": "gemini-2.5-flash","summary": "gpt-5.5","deepanalysis": "claude-opus-4.8",}

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

Подключение через OpenAI-compatible API

OdiRouter совместим с OpenAI SDK, поэтому базовое подключение выглядит знакомо. В большинстве случаев достаточно заменить base_url и использовать ключ OdiRouter.

from openai import OpenAI

client = OpenAI(apikey="ODIROUTERAPIKEY",baseurl="https://api.odirouter.ai/v1",)

Дальше можно сделать универсальную функцию вызова модели:

def callllm(task: str, messages: list[dict]):model = MODELBY_TASK[task]

response = client.chat.completions.create(model=model,messages=messages,temperature=0.3,)

return response.choices[0].message.content

Теперь бизнес-логика бота не знает, какой именно provider стоит за моделью. Она работает с задачами:

def handlesupportmessage(usermessage: str):messages = [{"role": "system","content": "Ты ассистент первой линии поддержки. Отвечай кратко и понятно."},{"role": "user","content": usermessage}]

return callllm("fastreply", messages)

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

Где появляется контроль стоимости

Стоимость AI-инфраструктуры складывается не из цены модели в целом, а из конкретных сценариев. В одном продукте может быть так:

70% запросов — короткие типовые ответы

20% — суммаризация диалогов

10% — сложный анализ, где нужна сильная модель

Если все 100% запросов отправлять в дорогую модель, команда платит за качество там, где оно не нужно. Если же разделить сценарии, можно оставить сильную модель только для задач, где она действительно влияет на результат.

Router-подход помогает именно здесь. Команда получает один API-слой, но может управлять моделью на уровне задачи:

def choosetask(message: str) -> str:if len(message) < 300:return "fastreply"

if "история переписки" in message.lower():return "summary"

return "deep_analysis"

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

Актуальные цены по моделям стоит проверять на странице pricing OdiRouter: https://odirouter.ai/pricing?utm_source=vc&channel=blog

Стоимость и скидки могут обновляться. Для команды это нормальная практика: не выбирать модель один раз навсегда, а регулярно пересматривать экономику сценариев.

Что логировать

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

Минимально стоит логировать:

тип задачи

выбранную модель

длину входного prompt

длину ответа

статус запроса

примерную стоимость

latency

ошибку, если вызов не прошел

Пример структуры лога:

{"task": "summary","model": "gpt-5.5","inputtokens": 4200,"outputtokens": 600,"latency_ms": 1840,"status": "success"}

Такие логи быстро показывают, где продукт теряет деньги. Например, команда может обнаружить, что в prompt каждый раз передается слишком большой системный контекст, хотя для короткого ответа он не нужен. Или что часть запросов можно обработать более дешевой моделью без заметной потери качества.

Почему это удобно для российских разработчиков

Для российского рынка важна не только техническая совместимость, но и операционная простота. Разработчики смотрят на несколько вещей:

можно ли быстро подключить API без переписывания проекта

есть ли понятная документация

можно ли платить в рублях

насколько прозрачны цены

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

можно ли быстро заменить модель, если изменилась цена или качество

есть ли логи и контроль расходов

OdiRouter закрывает эту задачу как единый слой доступа: один ключ, OpenAI-compatible API, 200+ моделей и понятная модель использования для команд, которые не хотят превращать AI-интеграцию в отдельный инфраструктурный проект.

Что важно не переоценить

AI API Router не отменяет инженерную работу. Он не выбирает за команду идеальную модель и не гарантирует, что любой prompt будет дешевым и качественным. Все равно нужно тестировать модели на своих данных, смотреть latency, проверять качество ответов и считать экономику.

Но router снижает стоимость ошибки. Если первая выбранная модель оказалась слишком дорогой или недостаточно точной, команду не ждет полноценная миграция на новый SDK и новый provider. В большинстве случаев достаточно заменить модель в конфигурации и повторить тест.

Итог

Главная польза OdiRouter в таком сценарии — не просто доступ к большому числу моделей. Ценность в том, что разработчик получает управляемый API-слой между продуктом и модельным рынком.

Для Telegram-бота, внутреннего ассистента, AI SaaS или backend-автоматизации это дает три практических эффекта:

быстрее запускать AI-функции

выбирать модель под задачу, а не под привычку

контролировать стоимость без переписывания архитектуры

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