Агрегаторы LLM: как выбирать живые free-модели и не врать про результат
Выбрать free-модель из списка — казалось бы, просто. На деле половина моделей нестабильна, часть исчезает из выдачи, а качество варьируется. Решение — не бескон
Если в проекте появляется выбор LLM, чаще всего берут самый очевидный путь: большой список моделей, выбираешь одну, отправляешь запрос. На короткой дистанции работает. На длинной начинает ломаться.
Где ломается простой подход
Проблемы появляются не в интерфейсе, а в поведении провайдеров и самих моделей: Нестабильные free-модели — числятся бесплатными, но отвечают нестабильно, пропадают в downtime провайдера Модели исчезают — вчера была в выдаче, сегодня провайдер её удалил или закрыл для новых пользователей Падение качества — формально живая, но годится только для демо или простых задач Несоответствие фронта и бэка — список на интерфейсе застарел на день-два, а backend знает другую реальность * Ошибки и переадресация — запросили одну модель, получили ошибку, или ответ пришёл от совсем другой модели Главная беда: интерфейс не знает, какая модель реально ответила. Пользователь выбрал Claude 3.5, а ответ пришёл от Gemini — и он об этом не узнает.
Это создаёт путаницу: если качество ответа не совпадает с выбранной моделью, пользователь теряет доверие.
Жёсткий инженерный контур вместо каталога
Решение строится не через бесконечный список, а через контроль на бэкенде: Шаг 1: очистка списка. Backend получает сырой список моделей от провайдера, фильтрует его — оставляет только подходящие free-варианты, выбрасывает нестабильные, убирает дубли. Можно добавить health checks — периодически стукается в каждую модель и смотрит, жива ли.
Шаг 2: по одной модели на бренд. Даже если у OpenAI в выдаче 5 free-моделей, на фронт идёт одна, самая стабильная. Это упрощает выбор пользователю и снижает вероятность попасть на плохую модель.
Шаг 3: fallback между брендами. Во время реального запроса — если первая модель вернула ошибку, автоматически пробуем вторую, потом третью. Пользователь о сбое не узнает, для него это просто займёт чуть больше времени.
Шаг 4: честность в ответе. Возвращаем не только генерированный текст, но и `actual_model` — какая модель реально это сгенерировала. Теперь интерфейс может честно сказать пользователю: «Ответ от GPT 4o mini, потому что основная была в downtime».
«Проблема не в том, как красиво показать список моделей.
Проблема в том, как построить систему, которая выбирает живые free-модели и не врёт про результат» — вот суть задачи. Это превращает нестабильный каталог в предсказуемый контур. Провайдер удалил модель — backend это заметит на следующей проверке и обновит список на фронте. Модель слегла — сработает fallback, пользователь получит ответ от другого провайдера.
Что это значит
Выбор LLM перестаёт быть UI-задачей и становится инженерной задачей — с очисткой данных, health checks, fallback логикой и честным трекингом. Для продукта это значит надёжность и меньше support-вопросов. Для пользователя — выбор работает, ответы приходят, интерфейс не врёт.