Как проверить поставщика LLM API: модель, маршрутизация и списания

Проверяя поставщика LLM API, сопоставьте заявленные модель и правила маршрутизации с запросом, метаданными ответа и списанием. Фраза модели «я GPT», низкая цена или один удачный ответ не доказывают, какие веса обработали запрос.

Это рабочая проверка для разработчиков, выбирающих API для агентов и приложений. Эта статья не является сертификацией Ofox или его конкурентов: ко всем поставщикам нужно применять одинаковые требования.

Зафиксируйте документированный ID модели

Сохраните идентификатор из запроса, endpoint и дату. Имя модели у разработчика может отличаться от ID с пространством имён у шлюза. Псевдоним допустим, но поставщик должен объяснять, на что он указывает и может ли это соответствие измениться.

Скриншот каталога OpenAI от 16 сентября 2026 года; сохранён исходный английский интерфейс. Каталог показывает опубликованные модели, но не доказывает, что именно обслужило запрос через сторонний шлюз.

Для Ofox начните со страницы модели. Если интерфейс показывает поставщика или маршрут, сохраните их. Поля endpoint, протоколов и цен описывают разные свойства: отсутствие значения в одном поле не доказывает отсутствие функции.

Соберите четыре вида свидетельств

Не включайте ключи API, заголовки авторизации и закрытые промпты в скриншоты или публичные обращения. Начните с обезличенных метаданных и синтетического примера. Справочник API OpenAI описывает собственный сервис; совместимый шлюз может использовать другие метаданные. Отсутствие специфичного для OpenAI заголовка не является доказательством нарушения.

Сравнивайте полезность, а не угадывайте веса

Составьте небольшой набор своих типичных задач: структурированный ответ, вызов инструмента, длинный ввод и сложная задача с проверяемым результатом. Отправляйте только разрешённые данные. По возможности сохраняйте одинаковыми промпты, настройки и исходные материалы.

Разные ответы могут объясняться случайностью генерации, инструкциями, инструментами и обработкой контекста. Совпадение ответов тоже не доказывает одинаковые веса. Для кода проверяйте diff и необходимые тесты; для извлечения данных сверяйте обязательные поля с эталоном. Сохраняйте неудачи и ручные исправления, а не только лучший ответ.

Если один ID ведёт себя по-разному в разных клиентах, начните с проверки различий между клиентами.

Сверьте запрос со списанием

Проверьте точный маршрут, валюту и единицу тарифа. Разделяйте обычный ввод, чтение кэша, запись кэша, вывод и дополнительные сборы. Нельзя умножать объединённый счётчик токенов на одну ставку ввода. В разборе стоимости кэша показано, как избежать двойного учёта.

Тайм-аут не доказывает, что upstream ничего не выполнил или не начислил плату. Сначала проверьте доступную историю запросов. Для разделения проблем соединения, ответа и потока используйте инструкцию по тайм-аутам.

Шаблон ниже пустой; это не выдуманный журнал тестирования:

Дата, время и часовой пояс:
Поставщик, endpoint, ID из документации:
Запрошенная модель и модель в ответе:
Маршрут и правила переключения, если раскрыты:
ID запроса и состояние завершения:
Обычный ввод, чтение кэша, запись кэша, вывод:
Источник тарифа, валюта и единица:
Списание и расхождения при сверке:
Критерий приёмки, результат, ручные исправления:
Неизвестные или нераскрытые поля:

До увеличения нагрузки запросите объяснение существенных расхождений. Если сведений недостаточно, учитывайте эту неопределённость при выборе поставщика.