API-диалекты похожи, но не идентичны. Нельзя считать, что шлюз способен без потерь перевести любое поле.
Sampling и служебные параметры#
Параметры вроде frequency_penalty, presence_penalty, logprobs, seed, service_tier и top_k существуют не во всех диалектах. Если они важны для результата, проверьте их на выбранной модели и endpoint.
Reasoning#
reasoning, reasoning_effort, thinking и reasoning_content — разные контракты:
управляющий параметр не всегда имеет эквивалент;
внутреннее reasoning может быть скрытым;
summary, raw reasoning и signed thinking block — не одно и то же;
служебную подпись thinking нельзя воссоздать из обычного текста;
при смене диалекта часть reasoning metadata может исчезнуть.
Не стройте бизнес-логику на обязательном наличии chain of thought.
Tools#
Наиболее переносимый вариант — function tool с JSON Schema входа. Встроенные инструменты поиска, файлов, выполнения кода, компьютера, MCP и генерации изображений требуют нативной поддержки endpoint и модели.
Неизвестный тип tool нельзя безопасно превратить в function call.
Structured Outputs#
Chat Completions использует response_format, Responses — text.format, а Messages — собственный output format у поддерживаемых моделей.
В текущем публичном контракте DSLab:
нельзя сохранить точно.
Chat JSON Schema может перейти в Responses;
Responses JSON Schema может перейти в Chat;
маршрут через Messages не используется, если структурированный контракт
Используйте json_schema, когда нужна проверяемая структура. Свободный json_object не задаёт схему и переносится хуже.
Responses-only возможности#
conversation, background, item_reference, hosted tools и полный набор типизированных tool events нельзя гарантировать на Chat- или Messages-маршруте.
Если поле критично, отправляйте минимальный тест и проверяйте фактический тип ответа до запуска рабочего трафика.