AI Gateway для теста моделей: как собрать воспроизводимый маршрут с лимитами и журналом

Команда хочет сравнить две модели на одних и тех же задачах. Обычно тест начинается быстро: меняют название модели в коде, отправляют несколько запросов и выбирают ответ, который выглядит убедительнее. Через неделю повторить результат уже невозможно. Не сохранили версию задания, забыли настройки, не разделили задержку провайдера и время ручной правки. AI Gateway решает часть этой организационной проблемы: даёт единый маршрут вызова разных моделей, учёт расхода и правила обработки сбоев. Но само качество ответа он не измеряет. Разберём, что именно стоит подключать и где провести границу ответственности.

Поводом вернуться к теме стало появление Kimi K3.1 Pro и версии Highspeed в AI Gateway 23 октября. Это удобный пример: две версии можно вызвать через один интерфейс, не переписывая всю интеграцию. Подробности самого анонса Kimi K3.1 Pro мы разбираем отдельно. Здесь речь о способе сравнения, который останется полезен и при смене модели.

Что находится между приложением и моделью

В обычной схеме приложение отправляет запрос непосредственно одному поставщику. В схеме со шлюзом приложение обращается к единому API, а шлюз передаёт запрос выбранному провайдеру. Это упрощает смену модели, учёт запросов и настройку резервного маршрута. По документации Vercel, AI Gateway также предоставляет трассировку, отчёты о расходе, бюджеты для ключей и правила маршрутизации. Наличие этих функций не означает, что все они включены автоматически или одинаково работают для каждой модели: конфигурацию и условия выбранного провайдера нужно проверить перед тестом.

Есть важное различие между «запрос завершился успешно» и «результат пригоден». Шлюз способен зафиксировать техническую ошибку или стоимость вызова. Он не знает, что модель перепутала две редакции договора, придумала цитату или нарушила внутренний стиль редакции. Для этого нужен собственный набор проверочных задач и человек, который имеет право отклонить ответ.

С чего начать настройку

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

Запишите две точные модели и способ маршрутизации. Для нашего примера это обычная версия Kimi K3.1 Pro и Highspeed, но не следует считать их идентичными из-за общего семейства. Отдельно укажите, разрешён ли автоматический переход на резервный провайдер. Для редакционного теста он часто вреден: если запрос незаметно ушёл другому поставщику, сравнение перестало быть контролируемым. Для боевого сервиса резервирование может быть нужно, но его следует отмечать в журнале и проверять на совместимость формата ответов.

Набор из десяти задач вместо красивой демонстрации

Возьмите не случайные вопросы из чата, а десять завершённых рабочих случаев. Например, три коротких извлечения фактов из документа, два сравнения версий, два ответа по длинному архиву, один случай с противоречивыми источниками и два вопроса, на которые в исходниках нет ответа. Для каждого случая до запуска подготовьте эталон: обязательные факты, допустимые оговорки и критические ошибки. В отдельном столбце отметьте, сколько времени сотрудник тратит без ИИ.

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

Что обязательно сохранять в журнале

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

Время до первого ответа удобно для демонстрации скорости, но для решения о внедрении полезнее время до принятого ответа. Допустим, Highspeed отвечает быстрее, но редактор тратит дополнительные четыре минуты на исправление ссылок. Тогда преимущество по задержке не стало преимуществом рабочего процесса. Аналогично низкая цена вызова не покрывает стоимость повторных проверок или серьёзной ошибки.

Где шлюз может запутать эксперимент

Первый риск — незаметная смена маршрута при сбое. Второй — неодинаковые возможности моделей: поддержка изображения, инструментов или структурированного вывода может отличаться. Третий — конфликт лимитов: ключ с маленьким бюджетом останавливает тест прежде, чем набрана сопоставимая выборка. Четвёртый — смешение задач разных людей в одном журнале, из-за которого нельзя связать конкретный ответ с конкретной версией задания.

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

Когда результат можно считать полезным

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

Практический итог пилота может звучать так: «для извлечения реквизитов используем модель А, для сравнения редакций — модель Б, вопросы без ответа передаём человеку». Это лучше, чем общий рейтинг «модель Б умнее». Шлюз в таком процессе полезен как приборная панель и контролируемый путь вызова, а не как автоматический арбитр качества.

Вопросы перед внедрением

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

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

Что делать после смены модели? Повторить сохранённый набор, отметить новый идентификатор и дату, сравнить не только скорость, но и правки. Старые результаты не перезаписывать: иначе история качества исчезнет.