vLLM: как устранить несовпадение формата content в chat template

Несовпадение формата content исправляют согласованием клиентского сообщения и chat template. Шаблон может ожидать обычную строку либо список типизированных частей. Если эти представления перепутаны, корректный JSON запроса еще не означает корректный промпт. Сначала сравните данные перед рендерингом, затем меняйте настройки сервера. Переустановка CUDA такую ошибку не объясняет.

Где возникает различие

В простом текстовом сообщении content содержит строку. В представлении OpenAI это может быть массив объектов с полями типа и текста. Для шаблона это разные структуры: цикл по частям и прямое включение строки работают по-разному. Согласно документации vLLM, сервер определяет ожидаемый формат и позволяет явно задать chat-template-content-format. Это механизм преобразования сообщений, а не изменение весов модели или ее контекстного окна.

Что собрать до изменения настройки

Сохраните минимальный запрос без изображений, выбранную ревизию tokenizer и сам шаблон. Отметьте, поступает ли строка непосредственно от клиента или создается промежуточной библиотекой. Полезно записать тип каждого content после сериализации, а не ориентироваться только на объект в исходном коде. Также проверьте, совпадает ли шаблон, указанный при запуске, с файлом, который просматривает оператор. Локальная копия могла быть заменена независимо от checkpoint.

Пример диагностической пары

Возьмите сообщение «Верни слово готово» и отправьте два отдельных запроса с одинаковой ролью: один со строкой, другой с массивом, содержащим единственную текстовую часть. Это синтетические входы для диагностики, не результаты измерения качества. Если ошибка появляется только для одного представления, сравните рендеринг и журнал определения формата. Если оба запроса ломаются одинаково, проверьте роли и синтаксис шаблона прежде, чем объявлять причиной content format.

Как принять исправление

После согласования формата повторите проверку для system, user и assistant сообщений, затем добавьте историю с несколькими ходами. В руководстве Hugging Face шаблон рассматривается как преобразование списка сообщений в последовательность токенов. Поэтому проверяйте сохранение текста, порядка частей и границ ролей, а не только отсутствие исключения. Для ожидаемого текстового запроса недопустимы буквальные представления словарей, исчезнувшие фрагменты и дважды добавленные служебные разделители.

Когда явный override уместен

Явный формат полезен, когда требуется зафиксировать поведение проверенного шаблона или автоматическое определение неоднозначно. Но такой override следует включать в конфигурацию конкретного deployment вместе с ревизией шаблона. Он не доказывает поддержку изображений, audio или инструментов: у этих путей свои структуры данных. Перед выпуском сохраните пару «входное сообщение — подготовленный промпт» как приемочный артефакт. При следующем обновлении сравнивайте именно преобразование, чтобы изменение шаблона не выглядело загадочным ухудшением ответа. Отдельно включите пустой текст и Unicode: они помогают обнаружить условные ветви, которые не покрывает единственное обычное сообщение. Результат проверки должен показывать, что конкретно поступило модели, а не просто сообщать об успешном HTTP статусе.

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

vLLM OpenAI-совместимый API: как проверить потоковый ответ; vLLM served-model-name: почему API не находит загруженную модель.