# Матрица совместимости inference API: что проверять провайдеру

Как построить проверяемую матрицу совместимости inference API: параметры, режимы ответа, fixtures, версии и границы выводов при интеграции провайдера.

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/provider-api-conformance-matrix/
Language: ru

Совместимый API — не одно свойство, которое можно проверить ответом на приветствие. Один сервер принимает обычный диалог, но иначе обрабатывает инструменты, пустые значения или завершение потока. Поэтому инженерный результат удобнее хранить как матрицу: конкретная возможность, условия проверки, наблюдаемый исход и версия реализации. Такая запись полезна и до интеграции с маршрутизатором, и после обновления движка.

## Разделите описание и доказательство

[Публичный API OpenRouter](https://openrouter.ai/docs/api_reference/overview) описывает внешние запросы и ответы платформы. Это источник для понимания интерфейса клиента, но не полный перечень требований к подключению upstream-провайдера. Матрица собственного адаптера должна прямо называть, с каким интерфейсом проводится сравнение. Согласование интеграции остаётся отдельной процедурой, а пример из документации не заменяет её результат.

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

## Выберите оси матрицы

Строка представляет возможность: обычный chat, streaming, tools или структурированный вывод. Столбцы описывают режим запроса, ожидаемую структуру, проверенный fixture и итог. Не объединяйте принятие параметра с его фактическим действием: сервер может принять поле, но проигнорировать значение.

[Документация vLLM](https://docs.vllm.ai/en/stable/serving/online_serving/) отдельно перечисляет поддерживаемые интерфейсы и ограничения. Этот пример показывает пользу подробного описания: общий ярлык совместимости слабее проверяемого списка исключений. Для каждого исключения нужен понятный ожидаемый исход, а не молчаливое предположение тестировщика.

## Сделайте один fixture воспроизводимым

Пусть проверяется завершение короткого потокового ответа. Вход не содержит секретов; максимальный выход ограничен; сохраняются статус, тип содержимого, последовательность событий и terminal marker. Проверка отвечает на структурный вопрос, а не требует дословно одинакового текста при каждом запуске.

Для строки матрицы запишите идентификатор fixture, hash входа и ожидаемые свойства. Например: ответ связан с правильной моделью, получено завершение, usage расположен в допустимом месте. Если одна проверка не пройдена, итог строки не должен оставаться зелёным из-за успешного HTTP-статуса.

## Различайте четыре исхода

Полезны статусы «поддержано», «не поддержано», «не проверено» и «зависит от модели». Последние два нельзя автоматически превращать в отказ или подтверждение. Укажите причину зависимости: парсер инструментов, модельный артефакт, backend либо настройка запуска.

Схему можно описать через [OpenAPI](https://spec.openapis.org/oas/v3.1.1.html), но описание не выполняет тесты само. Версия документа и версия результата должны связываться явно. После изменения адаптера повторяются затронутые строки, затем небольшой контрольный набор остальных функций.

## Используйте матрицу как границу релиза

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

Контекст интеграции разобран в [материале о провайдере](/ru/journal/openrouter-provider/), а идентификатор модели — в [настройке served-model-name](/ru/journal/vllm-served-model-name/). Эти проверки дополняют матрицу, сохраняя различие между работой локального сервера и подтверждённым подключением внешней платформы.