Comments 19
Эээ... Вы статью не через ии же генерили? Уж очень на нейрослоп похоже. Либо как-то не очень с подачей получилось
недать
Что за зверь такой?
Может временно недать доступ к конкретной free-модели.
Верно, что заметили. Должно быть «не дать доступ». У OpenRouter особенность - модели, которые числятся в /api/v1/models с фильтром free, не всегда реально доступны в момент запроса. Некоторые отдают ошибку при попытке вызова. Отсюда и логика с fallback - пробуем одну, не дало доступ, идём к следующей
Возможно ли сделать супер LLM которая прогоняла бы запрос через несколько моделей, анализировала и выдавала уточненный результат?
Это обычный агент. В openai agents sdk есть agents as tools. В качестве инструментов как раз могут быть запросы через другие модели
В проекте используется OpenRouter, он сам по себе уже является агрегатором моделей и поддерживает fallback между ними на уровне API. То есть описанная в статье логика - надстройка поверх его возможностей, а не замена. Но согласен, OpenAI Agents SDK тоже рабочий вариант для более сложной маршрутизации
Fallback -- как я понимаю, это не то же самое, что запрос одновременно к нескольким моделям и суммаризация, а запрос с возможностью гарантированно получить ответ, если какая-то из моделей недоступна. Т.е. отвечает одна модель.
Верно, fallback - это последовательный перебор, одна модель не ответила, пробуем следующую. Гарантия не абсолютная, если весь пул моделей недоступен, пользователь всё равно получит ошибку. В текущей реализации цикл проходит по списку один раз. Можно улучшить, либо использовать встроенный fallback OpenRouter (он пробует внутри себя), либо сделать цикл с повторным проходом и задержкой, либо добавить параллельный запрос к двум моделям и брать первый успешный ответ. Но это уже усложнение под конкретные сценарии
Вы немного не о том. Вопрос был про параллельный запрос к нескольким моделям и суммаризацию.
Возможно ли сделать супер LLM которая прогоняла бы запрос через несколько моделей, анализировала и выдавала уточненный результат?
Вы ответили про fallback, подразумевая (комментарий же об этом), что его можно использовать в упомянутом качестве -- параллельный запрос с суммаризацией. На что и был мой комментарий.
а вообще, fallback наоборот может навредить, если нужен ответ от конкретной модели (например, opus-4.7). Кроме того, цена будет другой (если вместо opus-4.7 внезапно будет fallback, настроенный Вами, на условную gpt-5.5)
Вы правы, я смешал два разных сценария. Fallback - это последовательная подмена недоступной модели, а не параллельный опрос с агрегацией. Для параллельного опроса и суммаризации нужна отдельная логика, OpenRouter в базовом API этого не даёт, только через надстройку. Цена и выбор конкретной модели тоже важные ограничения, согласен.
Да, из статьи это следует прямо. Backend уже пробует разные модели при сбое, ничего не мешает расширить логику, отправлять запрос параллельно в несколько моделей, сравнивать результаты, выбирать лучший или агрегировать. Вопрос только в цене и времени ответа. OpenRouter, кстати, даёт такую возможность через routing и fallback на уровне платформы
на опенроутере через fallback нельзя отправлять запросы к нескольким моделям параллельно
Сильная мысль про то, что harness — это часть модели. Мне кажется, в таких сравнениях это один из главных confounders: permission model, persistent shell, качество tool API, sandbox и даже то, насколько удобно агенту читать результат тестов, могут сильно менять итог.
Было бы интересно прогнать все три реализации не их собственными тестами, а одним независимым black-box набором: happy path, malformed messages, плохая сеть, повторный запуск, несовместимые версии peer-ов, повреждённая сериализация key shares. Особенно для threshold crypto «собралось и прошло demo» ещё не означает, что протокол корректно переживает неприятные сценарии.
Агрегатор LLM, как выбирать живые free-модели и переживать сбои провайдера