Сократите расходы на ИИ-модели с помощью маршрутизатора токенов LiteLLM

LiteLLM — это программный интерфейс с открытым исходным кодом, который позволяет отправлять запросы в формате OpenAI к множеству поставщиков услуг. Он находит применение в различных ролях; в данной статье рассматривается направление запросов к моделям — отправка каждого запроса к достаточно недорогой модели для контроля расходов токенов.

Что делает маршрутизатор моделей

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

Интуиция маршрутизации на основе токенов

LiteLLM может подсчитать количество входных токенов перед пересылкой запроса. Практический эвристический метод:

• Короткие задачи вроде «прочитать страницу и подвести итог» → модели класса Haiku
• Задачи, требующие сложного анализа на языке Python → модели класса Opus

Все, что находится посередине → модели класса Sonnet

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

Без маршрутизации

Каждый запрос обрабатывается одной дорогой моделью. Расходы растут линейно в зависимости от объема — без учета сложности задачи.

С маршрутизацией

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

Симуляция месяца инженерного трафика

Я протестировал оба варианта с помощью LiteLLM. Сначала все запросы обрабатывались моделью Opus. Примерно семьсот запросов привели к счету примерно в 60 долларов.

Затем я включил роутер. Opus принимал только те запросы, у которых количество входных токенов превышало 300. Пользовательский логгер, реализующий эту политику, выглядит так:

from litellm.integrations.custom_logger import CustomLogger
import litellm
import random

class TokenRouter(CustomLogger):
    async def async_pre_call_hook(self, user_api_key_dict, cache, data, call_type):
        # Skip routing for mock models - simulation handles model selection
        if "mock" in data.get("model", ""):
            return data

        # SMART ROUTING based on token complexity
        messages = data.get("messages", [])
        token_count = litellm.token_counter(
            model="gpt-3.5-turbo",
            messages=messages
        )

        if token_count < 50:
            data["model"] = "haiku"
            tier = "HAIKU  (5%)"
        elif token_count < 300:
            data["model"] = "sonnet"
            tier = "SONNET (30%)"
        else:
            data["model"] = "opus"
            tier = "OPUS   (65%)"

        print(f"[ROUTER] Tokens: {token_count} → {tier}")
        return data

proxy_handler_instance = TokenRouter()

Из 741 запроса 494 (примерно 66%) всё же дошли до Opus. Остальные распределились между Sonnet и Haiku, причём на долю Haiku пришла самая небольшая часть. Стоимость аналогичной нагрузки снизилась до 43 долларов — способ написания запросов разработчиками не изменился.

Выводы на основе цифр

• 741 запрос — реалистичное количество использования за месяц
• 60 долларов в качестве базовой цены — Opus для всего
• 43 доллара с использованием роутинга — та же работа, более умный выбор инструментов
• ~28% экономии — всё достигается за счёт прокси, что незаметно для клиентов

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

Маршрутизатор LiteLLM решает эту проблему незаметно. Инженеры продолжают использовать клиент в стиле OpenAI; отдел финансов видит более маленький счет.

В качестве ориентира здесь использовалась версия LiteLLM v1.98, запущенная локально с заменителями от Ollama, а также рекомендованные цены от Anthropic для расчета затрат. Фактическая экономия зависит от того, как распределяется набор ваших запросов по уровням сложности.