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

Часть моделей числится бесплатными, но отвечает нестабильно. Часть внезапно исчезает из выдачи провайдера. Часть формально жива, но по качеству ответа годится только для демо. Иногда пользователь выбрал одну модель, а провайдер вернул ошибку. Иногда ответ пришел, но уже от другой модели. Иногда список моделей на фронте устарел, а backend уже живет в другой реальности.

То есть проблема тут не в том, как красиво показать список LLM. Проблема в том, как построить агрегатор, который умеет выбирать живые free-модели, переживать сбои провайдера и не врать интерфейсу о том, какая модель реально ответила.

В одном из своих проектов эта задача решалась не через бесконечный каталог моделей, а через более жесткий инженерный контур. Backend получает сырой список моделей от провайдера, очищает его, отбирает только подходящие free-варианты, оставляет по одной модели на бренд, отдает этот набор на фронт, а во время реального запроса умеет сделать fallback на модель другого бренда. При этом в ответе возвращается не только текст, но и actual_model, чтобы интерфейс знал, кто реально сгенерировал результат.

Почему первая free-модель часто оказывается плохим выбором

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

У провайдера список моделей обычно меняется. Одни модели становятся недоступны, другие деградируют по скорости, третьи остаются в каталоге, но начинают нестабильно отвечать. Если просто брать первую попавшуюся free-модель, система быстро привязывается к случайному порядку выдачи. А случайный порядок выдачи не имеет отношения ни к качеству, ни к стабильности.

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

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

Что делает агрегатор вместо бесконечного списка

На backend логика начинается с запроса к провайдеру моделей. Но на фронт этот список не уходит напрямую. Сначала он проходит нормализацию и отбор.

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

Упрощенно это выглядит так:

# chat_app/views.py

def get_top_models(raw_models):
    filtered = []

    for model in raw_models:
        model_id = model.get("id", "")
        pricing = model.get("pricing", {})
        is_free = pricing.get("prompt") == "0" and pricing.get("completion") == "0"

        if not is_free:
            continue

        if "image" in model_id or "embedding" in model_id:
            continue

        filtered.append(model)

    grouped_by_brand = {}

    for model in filtered:
        brand = model["id"].split("/")[0]
        grouped_by_brand.setdefault(brand, []).append(model)

    top_models = []
    for brand, models in grouped_by_brand.items():
        best_model = choose_best_model(models)
        top_models.append(
            {
                "id": best_model["id"],
                "brand": brand,
                "label": brand.title(),
            }
        )

    return top_models

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

Пользователь на фронте видит не десятки похожих вариантов, а несколько внятных точек выбора. Для free-слоя это обычно намного полезнее.

Почему одной модели на бренд часто достаточно

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

Во-первых, пользователь редко понимает разницу между пятнадцатью близкими free-моделями одного бренда. Во-вторых, большой список выглядит богато только до первого сбоя. После него становится ясно, что выбор был декоративным. В-третьих, одна модель на бренд сильно упрощает fallback. Если базовая модель бренда A не сработала, можно переходить к бренду B, а не метаться по длинной лесенке почти одинаковых id внутри одного семейства.

Где обычно ломается простой интеграционный сценарий

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

Провайдер может вернуть rate limit. Может временно недать доступ к конкретной free-модели. Может ответить ошибкой маршрутизации. Может молча подменить внутренний маршрут. В этот момент у системы два плохих варианта: либо вернуть пользователю ошибку сразу, либо делать вид, что все хорошо, и не сообщать, что фактически ответ пришел не от той модели.

Нормальный вариант между ними такой: backend должен иметь fallback-механику и одновременно быть честным с фронтом.

Fallback не как украшение, а как часть архитектуры

В проекте fallback встроен прямо в слой запроса к LLM. Если выбранная модель не отработала, backend не просто валится с ошибкой, а пытается подобрать другой живой free-вариант, желательно другого бренда. Это важно, потому что сбой часто бывает не у всей платформы целиком, а у конкретной модели или группы маршрутов.

Упрощенный контур:

# chat_app/model_providers/openrouter_service.py

def query_openrouter(messages, selected_model, fallback_models):
    tried_models = [selected_model]

    try:
        result = call_provider(model=selected_model, messages=messages)
        return {
            "content": result["content"],
            "actual_model": selected_model,
            "fallback_used": False,
        }
    except Exception:
        pass

    for fallback_model in fallback_models:
        if fallback_model in tried_models:
            continue

        try:
            result = call_provider(model=fallback_model, messages=messages)
            return {
                "content": result["content"],
                "actual_model": fallback_model,
                "fallback_used": True,
            }
        except Exception:
            tried_models.append(fallback_model)
            continue

    raise RuntimeError("No alive free models available")

Здесь важны две вещи. Первая: fallback живет в backend, а не на фронте. Фронт не должен угадывать, какую следующую модель пробовать. Вторая: backend возвращает actual_model. Это маленькое поле, но оно снимает целый класс архитектурной лжи.

Почему actual_model важнее, чем кажется

Без actual_model интерфейс почти неизбежно начинает показывать не то, что реально произошло. Пользователь выбрал одну модель, ответ пришел от другой, а UI продолжает писать старое имя. В логах backend одно, в клиенте другое, в аналитике третье.

Если система умеет делать fallback, она обязана сообщать, какая модель реально сработала. Иначе продукт начинает врать сам себе. Для демо это может пройти. Для живого интерфейса нет.

Поэтому в ответе полезно возвращать и контент, и фактическую модель:

return Response(
    {
        "answer": answer_text,
        "selected_model": requested_model,
        "actual_model": actual_model,
        "fallback_used": fallback_used,
    }
)

Дальше фронт уже может решить, как это показать. Иногда достаточно молча обновить подпись у ответа. Иногда полезно подсветить, что система временно переключилась на другой живой вариант. Главное, что у интерфейса есть правда, а не догадка.

Почему fallback лучше делать между брендами

Еще одна полезная деталь. Если fallback идет на почти ту же модель того же бренда, система может остаться в той же зоне проблем. Например, один и тот же провайдерский маршрут или вся линейка конкретного бренда деградировала одновременно.

Поэтому практичнее держать fallback-пул не как список похожих id, а как набор альтернативных брендов. Это повышает шанс, что сбой действительно будет обойден, а не просто повторен с косметическими изменениями.

Именно здесь хорошо работает стратегия одна модель на бренд. Она упрощает и интерфейс, и fallback-контур.

Как фронт узнает о моделях без ручной перезагрузки

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

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

На фронте это выглядит:

// src/features/chat/api/chatApi.ts

getModels: builder.query<ModelOption[], void>({
  query: () => "/api/chat/models/",
  providesTags: ["Models"],
  keepUnusedDataFor: 60,
}),

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

const { data: models = [], isLoading } = useGetModelsQuery(undefined, {
  pollingInterval: 60000,
});

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

Что в итоге получает продукт

На выходе получается управляемый слой моделей. Frontend получает короткий список живых free-вариантов, а не бесконечную простыню id. Backend не привязан к одной случайной модели и умеет переживать сбои провайдера. Пользователь не сталкивается с молчаливой подменой, потому что система умеет возвращать actual_model. Список моделей не тухнет в клиенте, потому что обновляется polling-механикой.

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

Главная архитектурная мысль

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

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

Для примеров в статье использован живой проект AI-Chat. Отдельная витрина на GitHub Pages пингует основной проект на спящем Render и содержит переход в рабочее приложение. В последовательной сборке с фронтом, бэкендом и их стыковкой этот контур можно посмотреть на Stepik курс AI на Django и Next II.