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

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

Автор: Команда Retrivium
Обновлено: 2026-11-01
Канонический URL: https://retrivium.ai/ru/journal/vllm-tool-parser-template-contract/
Language: ru

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

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

Parser извлекает вызовы из формата, который генерирует конкретная модель, а шаблон готовит ей описание инструментов и историю. [vLLM](https://docs.vllm.ai/en/stable/features/tool_calling/) связывает auto tool choice с `enable-auto-tool-choice`, выбором `tool-call-parser` и совместимым шаблоном. Возможности зависят от parser и модели. Не считайте поддержку одного режима доказательством поддержки strict схем, параллельных вызовов или любого значения tool choice. Эти свойства следует перечислить отдельно в приемочном контракте.

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

После assistant вызова клиент возвращает результат инструмента с нужной идентификацией. В [руководстве Hugging Face](https://huggingface.co/docs/transformers/main/en/chat_extras) показана история, включающая tools и соответствующие сообщения. Обратите внимание на различие представления аргументов: внутренний шаблон и внешний OpenAI совместимый API могут ожидать разные структуры. Сохраняйте реальный сериализованный запрос второго хода. Проверка только первого ответа пропускает ошибки, проявляющиеся при повторном применении chat template к расширенной истории разговора.

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

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

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

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

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

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

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

[Tool calling через OpenRouter: модель предлагает, приложение выполняет](/ru/journal/openrouter-tool-calling/); [vLLM OpenAI-совместимый API: как проверить потоковый ответ](/ru/journal/vllm-openai-streaming-test/).