В какой-то момент каждый разработчик, который пробовал заменить OpenAI на локальную модель, сталкивался с ситуацией: модель запустилась, отвечает, но твой код падает с ошибкой. Ты чешешь голову, лезешь в документацию, а там — магия. Оказывается, модель не поддерживает streaming. Или function calling. Или возвращает поля не в том формате. В общем, обещание «полная совместимость с OpenAI API» часто оказывается маркетинговым трюком. Инструмент Am I OpenAI compatible (далее просто aiooc) — это тот самый тест на полиграфе, который выводит вранье на чистую воду.

Суть: маленький open-source скрипт (на Python), который гоняет вашу модель через все ключевые эндпоинты OpenAI API — chat completions, completions, embeddings, moderation, image generation (если применимо) — и выдаёт детальный отчёт: какие поля, заголовки, форматы ответов и коды ошибок совпадают, а какие нет.

Что конкретно он проверяет (и почему это боль)

OpenAI API — это не просто один эндпоинт. Это целая экосистема соглашений: поддерживаемые параметры (temperature, top_p, frequency_penalty), формат сообщений (role, content, tool_calls), стриминг через SSE, лимиты токенов, системы аутентификации. Локальные сервера часто реализуют только /v1/chat/completions и то с багами.

💡

aiooc проверяет не только эндпоинты, но и поведение: например, правильно ли модель обрабатывает пустые сообщения, игнорирует ли неизвестные поля, возвращает ли ошибку при превышении контекста.

На практике я видел случаи, когда модель «совместимая» отваливалась на стриминге — отправляла корректные чанки, но забывала закрывающий [DONE]. Или вообще не поддерживала stream_options: { include_usage: true } (да, такое есть). Без формального теста вы это заметите только когда пользователи начнут жаловаться на зависшие чаты.

Как это работает — быстрый старт

Установка через pip или Docker. Пример базового запуска:

docker run --rm -ti ghcr.io/simonw/am-i-openai-compatible:latest \
  --base-url http://localhost:8080/v1 \
  --api-key sk-test

Через минуту получаете отчёт в консоли или JSON-файле. Флаг --verbose покажет, какой именно запрос упал и какой ответ ожидался.

Я обычно запускаю с --report-format json и потом паршу результат в CI/CD. Например, в пайплайне перед деплоем новой версии модели — чтобы не сломать интеграцию с фронтендом. Это как smoke-тест для вашего AI-бэкенда.

Сравнение с другими подходами

Инструмент	Что делает	Отличие от aiooc
Am I OpenAI compatible	Тестирует совместимость, выдаёт отчёт	Не прокси, не сервер — только тест
LiteLLM	Прокси с унифицированным API	Может скрыть несовместимость, не выявляет
llama.cpp server	Реализует OpenAI-эндпоинты	Только inference, нет верификации
Open WebUI	Фронтенд для совместимых API	Не проверяет, а потребляет

На самом деле, лучший сетап — комбинировать. Запустить aiooc один раз при настройке, потом подключить к Open WebUI для интерфейса. А если нужен production-ready прокси с гарантией совместимости — посмотрите на AITunnel, который берёт на себя маршрутизацию к совместимым моделям.

Реальный кейс: function calling и streaming

Один из самых частых сценариев, где модель обманывает — function calling. Заявляет поддержку, но на деле игнорирует параметр tools в запросе. aiooc это ловит.

// Фрагмент отчёта
{
  "test": "chat: function calling",
  "status": "FAIL",
  "reason": "Model returned plain text instead of tool_calls in response"
}

Если ваши агенты полагаются на вызовы инструментов, читайте отдельный гайд — там я подробно разбирал, почему opensource-модели фейкают вызовы и как это чинить. Но первый шаг — убедиться, что ваш сервер их вообще корректно передаёт.

Второй больной момент — стриминг. Тест aiooc проверяет, что SSE-поток содержит правильные поля, что каждое сообщение — валидный JSON, и что в конце есть data: [DONE]. Большинство серверов на базе llama.cpp и vLLM стримят корректно, но бывают грабли с кастомными форками.

Кому этот инструмент реально нужен

Разработчикам AI-продуктов, которые мигрируют с OpenAI на self-hosted. Прогоните тест перед тем, как менять в коде base_url.
DevOps/SRE, которые обслуживают инфраструктуру для LLM. Включите тест в CI для каждой новой модели.
Энтузиастам, собирающим свой AI-стек. Например, после того как нашли подходящую модель через Models Explorer — проверьте её на совместимость.
Тем, кто пишет интеграции в Java/Kotlin или других языках — универсальный тест спасёт от багов, которые вылезут только на проде.

Особенно рекомендую, если вы используете llama.cpp server как замену OpenAI — даже у него есть нюансы с некоторыми эндпоинтами (например, embeddings могут не поддерживаться).

Быстрый совет: как не надо делать

Не верьте документации модели, которая говорит «fully compatible with OpenAI». Запустите тест. Я видел модели, которые валились на таких базовых вещах как поддержка system роли в сообщениях. Без aiooc вы бы узнали об этом от пользователей.

Кстати, если вам лень самостоятельно поднимать инфраструктуру для тестов, но нужно стабильное API — обратите внимание на AITunnel. Это готовый шлюз, который из коробки совместим с OpenAI, но при этом можно переключаться на opensource-модели. У них есть стандартные тесты совместимости — по сути, тот же aiooc, только встроенный в платформу.

Чего не хватает?

Инструмент хорош, но не идеален. Он не тестирует производительность (лагенси, TPS). Не проверяет поведение при параллельных запросах. И не умеет автоматически исправлять несовместимости — только констатирует факт. Но для задач «быстро проверить, взлетит ли» — лучшее, что есть. Судя по трендам, к концу 2026 такие тесты станут стандартной частью любого open-source релиза модели — как unit-тесты для API.

Мой прогноз: в ближайшие полгода появятся форки aiooc с интеграцией в Open WebUI и другие популярные интерфейсы. Тогда проверка совместимости станет делом одного клика. А пока ставьте в крон или делаетйте pre-commit hook с этим скриптом — спасётесь от десятков часов дебага.

Подписаться на канал

Am I OpenAI compatible: как проверить, обманывает ли вас локальная модель