В этом материале
Capability относится к реально обслуживающей конфигурации. Объявлять функцию стоит только в пределах проверенного поведения участвующих реплик.
Каталог сообщает, что модель поддерживает инструменты, а одна из реплик ещё работает со старым parser. Клиент получает непредсказуемый результат в зависимости от выбранного узла. Это не проблема списка полей сама по себе, а рассогласование между публикацией возможностей и rollout. Для провайдера нужна проверка, связывающая объявленную функцию с фактически обслуживающими экземплярами и определённой версией конфигурации.
Опишите источник capabilities
OpenAPI определяет способ описания интерфейса, но наличие поля в документе не подтверждает работающую функцию. В release record укажите, откуда берётся объявленная capability: конфигурация, результат теста либо отдельный управляемый реестр. Автоматическая генерация списка тоже нуждается в проверке источника данных.
Не придумывайте универсальную схему регистрации провайдера по примеру клиентского каталога. Публичные возможности собственного API и условия внешней платформы относятся к разным уровням. Статья описывает внутреннюю согласованность сервиса, а не обещает, что публикация файла автоматически подключит его к маршрутизатору.
Привяжите функцию к реализации
Документация vLLM перечисляет интерфейсы и их ограничения. Для tools или structured output важны модель, engine version, parser и параметры запуска. Одна строка supported=true не объясняет эту комбинацию. Сохраните ссылку на проверенный release и fixture, который подтверждает функцию.
Если capability зависит от режима, отразите различие: stream и non-stream могут требовать отдельных проверок. Нельзя переносить успешный ordinary chat на tool calls. Аналогично поддержка одной простой schema не является доказательством всех возможных ограничений сложного документа.
Проверьте участвующие реплики
Во время rollout старые и новые экземпляры могут сосуществовать. Решите, допустима ли публикация новой возможности до окончания перехода. Если клиентский маршрут способен попасть на неподготовленную реплику, объявление опережает реальное состояние сервиса. Альтернатива — отдельный маршрут или задержка публикации по выбранной стратегии.
Kubernetes readiness помогает исключать неготовые экземпляры из обычного обслуживания. Однако readiness сама по себе не знает вашу feature matrix. Проверка приложения должна подтверждать нужную конфигурацию, а не только открытый TCP-порт. Не превращайте каждый probe в тяжёлую генерацию; используйте ограниченные контрольные шаги.
Создайте release checklist
Артефакт включает public model ID, внутренний release, список объявленных функций, результаты fixtures и состояние допуска реплик. Добавьте время публикации и ответственного за изменение. Это позволяет объяснить, почему capability стала доступна, вместо поиска причин по разрозненным логам после жалобы клиента.
Негативный fixture проверяет вызов функции на заведомо неподготовленной тестовой конфигурации. Он показывает, что gate действительно различает состояния, а не всегда сообщает готовность. Такой тест проводится в изолированном контуре и не требует намеренно направлять настоящие запросы на несовместимый узел.
Сохраните путь обратного изменения
При откате новая capability может перестать быть доступной. Документ и фактический маршрут должны измениться согласованно с политикой совместимости. Нельзя сохранять прежнее обещание только потому, что интерфейс каталога уже обновлён. Открытые операции и новые запросы рассматриваются отдельно.
Связанные темы — каталог OpenRouter и canary модели. Здесь проверяется собственный rollout и его описание; успешный checklist не подтверждает внешнее одобрение, качество любой задачи или существование production-ресурсов конкретного проекта.