В этом материале
Совместимость нужно подтверждать по отдельным возможностям и версиям. Один успешный запрос не доказывает поддержку всего интерфейса.
Совместимый API — не одно свойство, которое можно проверить ответом на приветствие. Один сервер принимает обычный диалог, но иначе обрабатывает инструменты, пустые значения или завершение потока. Поэтому инженерный результат удобнее хранить как матрицу: конкретная возможность, условия проверки, наблюдаемый исход и версия реализации. Такая запись полезна и до интеграции с маршрутизатором, и после обновления движка.
Разделите описание и доказательство
Публичный API OpenRouter описывает внешние запросы и ответы платформы. Это источник для понимания интерфейса клиента, но не полный перечень требований к подключению upstream-провайдера. Матрица собственного адаптера должна прямо называть, с каким интерфейсом проводится сравнение. Согласование интеграции остаётся отдельной процедурой, а пример из документации не заменяет её результат.
Рядом с названием спецификации сохраните дату проверки, версию сервера и набор включённых функций. Ссылка на постоянно меняющуюся страницу без этих сведений затрудняет повторный аудит. Если функция проверялась только через один клиент, такой предел также должен быть виден.
Выберите оси матрицы
Строка представляет возможность: обычный chat, streaming, tools или структурированный вывод. Столбцы описывают режим запроса, ожидаемую структуру, проверенный fixture и итог. Не объединяйте принятие параметра с его фактическим действием: сервер может принять поле, но проигнорировать значение.
Документация vLLM отдельно перечисляет поддерживаемые интерфейсы и ограничения. Этот пример показывает пользу подробного описания: общий ярлык совместимости слабее проверяемого списка исключений. Для каждого исключения нужен понятный ожидаемый исход, а не молчаливое предположение тестировщика.
Сделайте один fixture воспроизводимым
Пусть проверяется завершение короткого потокового ответа. Вход не содержит секретов; максимальный выход ограничен; сохраняются статус, тип содержимого, последовательность событий и terminal marker. Проверка отвечает на структурный вопрос, а не требует дословно одинакового текста при каждом запуске.
Для строки матрицы запишите идентификатор fixture, hash входа и ожидаемые свойства. Например: ответ связан с правильной моделью, получено завершение, usage расположен в допустимом месте. Если одна проверка не пройдена, итог строки не должен оставаться зелёным из-за успешного HTTP-статуса.
Различайте четыре исхода
Полезны статусы «поддержано», «не поддержано», «не проверено» и «зависит от модели». Последние два нельзя автоматически превращать в отказ или подтверждение. Укажите причину зависимости: парсер инструментов, модельный артефакт, backend либо настройка запуска.
Схему можно описать через OpenAPI, но описание не выполняет тесты само. Версия документа и версия результата должны связываться явно. После изменения адаптера повторяются затронутые строки, затем небольшой контрольный набор остальных функций.
Используйте матрицу как границу релиза
Итогом служит файл с наблюдениями и открытыми вопросами, а не универсальное обещание совместимости. Он помогает отделить регрессию адаптера от неподдерживаемой возможности модели. Нельзя переносить положительный результат на другой endpoint или новую версию без проверки условий.
Контекст интеграции разобран в материале о провайдере, а идентификатор модели — в настройке served-model-name. Эти проверки дополняют матрицу, сохраняя различие между работой локального сервера и подтверждённым подключением внешней платформы.