В статье подробно описаны 12 конкретных областей, в которых стандарт API, совместимый с OpenAI, расходится между различными движками вывода и хостинг-провайдерами, что приводит к скрытым сбоям или неожиданному поведению. Хотя базовая структура запросов и простой потоковый вывод работают надёжно, тонкие различия в обработке параметров, ответах об ошибках и поддержке функций могут нарушить работу приложений.
- Неизвестные параметры часто молча отбрасываются вместо возврата ошибки 400.
- Для моделей с рассуждением может потребоваться `max_completion_tokens` вместо `max_tokens`, при этом поддержка этого параметра непоследовательна.
- Статистика использования токенов часто отсутствует в потоковых ответах, если явно не запрошена через `stream_options`.
- Поддержка вызова инструментов значительно варьируется: многие серверы не поддерживают нативные параллельные вызовы или строгое соблюдение схемы.
- Реализации режима JSON различаются между базовой проверкой объектов и ограниченным декодированием с использованием схем.
- Обработка переполнения контекста варьируется от жёстких ошибок 400 до молчаливого усечения системных промптов.
- Значения `finish_reason` включают добавления, специфичные для провайдера, помимо стандартных stop, length и tool_calls.
- Обёртки ошибок и ответы об ограничении частоты запросов (429, 503 или 200 с ошибками в теле) непоследовательны.
- Настройки температуры в моделях с рассуждением могут игнорироваться на внутреннем уровне, несмотря на то что они принимаются.
- Обработка мультимодального ввода различается по ограничениям размера, типам MIME и параметру `detail`.
- Эндпоинты для эмбеддингов не обладают переносимостью из-за различной размерности и нормализации.
- Ключи идемпотентности редко поддерживаются, а заголовки с идентификатором запроса используют непоследовательные имена.
Автор рекомендует использовать скрипт-зонд для проверки соответствия провайдера этим специфическим поведением, поскольку версии моделей часто меняются, а скрытые сбои трудно отлаживать в продакшене.