ТЕХНОЛОГИИ

vLLM tool calling: как согласовать parser, шаблон и историю вызовов

В этом материале
ГЛАВНОЕ ЗА МИНУТУ

Надежный tool calling в vLLM требует согласованной тройки: parser, chat template и история сообщений с результатами инструментов.

Надежный tool calling в vLLM требует согласованной тройки: parser, chat template и история сообщений с результатами инструментов. Флаг включения auto выбора не заменяет эту совместимость. Проверяйте полный цикл вызова и следующего ответа модели. Один удачно распознанный объект tool_calls еще не доказывает, что сервер правильно обработает ответ инструмента и продолжит разговор без потери связи между сообщениями.

Назначение parser и шаблона

Parser извлекает вызовы из формата, который генерирует конкретная модель, а шаблон готовит ей описание инструментов и историю. vLLM связывает auto tool choice с enable-auto-tool-choice, выбором tool-call-parser и совместимым шаблоном. Возможности зависят от parser и модели. Не считайте поддержку одного режима доказательством поддержки strict схем, параллельных вызовов или любого значения tool choice. Эти свойства следует перечислить отдельно в приемочном контракте.

Проверьте сообщение с результатом

После assistant вызова клиент возвращает результат инструмента с нужной идентификацией. В руководстве Hugging Face показана история, включающая tools и соответствующие сообщения. Обратите внимание на различие представления аргументов: внутренний шаблон и внешний OpenAI совместимый API могут ожидать разные структуры. Сохраняйте реальный сериализованный запрос второго хода. Проверка только первого ответа пропускает ошибки, проявляющиеся при повторном применении chat template к расширенной истории разговора.

Учебный цикл без внешних действий

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

Отдельно проверьте сложные ветви

Добавьте ответ без инструмента, повторный вызов, два разрешенных вызова и некорректный аргумент. Там, где parser не поддерживает параллельность, зафиксируйте ограничение вместо искусственного ожидания успешного теста. Для streaming проверьте сборку аргументов из частей и момент завершения вызова. Не выполняйте инструмент по первому похожему текстовому фрагменту: до завершения структуры аргументы могут быть неполными. Сохраняйте сырые события вместе с итоговым представлением клиента для диагностики преобразований.

Что считать готовым контрактом

Приемочный артефакт содержит model revision, parser, шаблон, tool schema и две последовательные пары запрос–ответ. В нем видно, когда допустим обычный текст и когда требуется вызов. Отдельно опишите обработку неизвестного инструмента и отказа локальной функции. Parser извлекает структуру, но не дает модели право выполнять произвольный код: выбор разрешенных функций остается за приложением. При обновлении любого из трех компонентов повторите весь цикл, а не только проверку JSON первого хода. Согласованная история важна даже при неизменном публичном имени модели, потому что именно она определяет вход следующего обращения и позволяет корректно связать полученный результат с ранее запрошенным действием.

Связанные материалы

Tool calling через OpenRouter: модель предлагает, приложение выполняет; vLLM OpenAI-совместимый API: как проверить потоковый ответ.

← Все материалы