В этом материале
Принятое поле не обязательно применяется. Политика неподдерживаемых параметров должна быть явной и проверяться независимо от качества текста.
Неподдерживаемый параметр создаёт две разные проблемы. Клиент может получить ошибку сразу или получить формально успешный ответ, который выполнен с другими настройками. Во втором случае проблема менее заметна: вызывающая сторона считает ограничение действующим. Для провайдера нужна явная политика, которая отделяет синтаксическое принятие запроса от поддержки функции и от наблюдаемого эффекта.
Назовите проверяемый интерфейс
OpenRouter описывает параметры своего внешнего API и отмечает, что пропущенные sampling-поля не подменяются общей жёсткой настройкой. Из этого нельзя вывести, что каждый upstream обязан принимать любые поля или одинаково выбирать значения по умолчанию. Собственный адаптер должен иметь описанную область поддержки для конкретной версии.
Запишите, где заканчивается ответственность клиента, маршрутизатора и движка. Если поле преобразуется между слоями, тест должен наблюдать результат преобразования отдельно. Иначе отсутствие эффекта легко ошибочно приписать модели, хотя параметр потерялся раньше.
Разделите допустимые политики
Один вариант — явный отказ с описанием неподдерживаемой возможности. Другой — документированное игнорирование, если именно так определён интерфейс. Третий — поддержка только для некоторых моделей. Ни один из вариантов не следует скрывать под общей надписью «совместимо».
В документации vLLM есть конкретные исключения для интерфейсов и параметров. Это полезный образец точности, а не правило для любого сервера. Если выбран иной движок, его поведение проверяют самостоятельно. Нельзя переносить исключение одной реализации в описание другой без фактического основания.
Проверьте принятие отдельно от действия
Создайте небольшой fixture с одним спорным полем. Сначала проверьте статус и структуру ответа. Затем подтвердите, что параметр дошёл до нужного слоя и влияет на заявленное свойство. Для численного sampling-параметра один удачный текст не служит надёжным доказательством применения.
Удобный артефакт содержит исходный запрос, ожидаемую политику, фактический исход и подтверждение на границе адаптера. Секретные заголовки в такой записи не нужны. Если наблюдение ограничено чёрным ящиком, прямо укажите, какие выводы остаются недоказанными.
Добавьте негативные варианты
Проверьте неизвестное поле, известное поле неверного типа и известное поле у модели без нужной функции. Эти случаи могут иметь разные причины отказа. Не называйте их одной общей ошибкой параметров, если клиенту важно отличать исправление формы запроса от выбора другой возможности.
JSON Schema различает свойства объекта, обязательность и ограничения дополнительных полей. Схема помогает выразить выбранную политику, но сама не подтверждает реализацию. Тесты должны включать проверку реального endpoint, а не только локального валидатора.
Сохраните исключения при обновлении
После изменения версии сравните список поддержанных, проигнорированных и отклонённых параметров. Неожиданное начало игнорирования может быть регрессией даже при прежнем HTTP-статусе. Изменение политики требует обновить документацию и ожидаемые fixtures вместе.
Связанные вопросы маршрутизатора рассмотрены в выборе провайдеров, а среда движка — в совместимости установки vLLM. Разделение этих уровней позволяет описать конкретную поддержку без выдуманных требований подключения или заявлений о действующей интеграции.