Підводні камені OpenAI-сумісних API: що насправді ламається між різними провайдерами
Підміна base_url для виклику Anthropic, Gemini чи Qwen через клієнт OpenAI часто приховує неочевидні помилки. Провайдери ігнорують непідтримувані параметри, зміщують ролі повідомлень і по-різному інтерпретують параметри міркування.
Чому це важливо
Проведіть аудит шарів маршрутизації між моделями, щоб уникнути непомітної втрати параметрів і погіршення міркувань у продакшені.
TL;DR
- 01Ендпоінти сумісності Anthropic переносять системні повідомлення з середини діалогу на початок, руйнуючи покрокові інструкції.
- 02Параметр reasoning_effort повністю ігнорується в Anthropic, мапиться на власні рівні у Qwen і транслюється в Gemini.
- 03Успішний статус HTTP 200 часто маскує повне ігнорування параметрів на зразок metadata чи service_tier.
Ключові факти
- Перевірена версія бібліотеки
- llm-api-adapter 0.9.8
- Рівні міркування Qwen 3.8
- low, medium, xhigh (xhigh за замовчуванням)
- Підтримка reasoning_effort в Anthropic
- Ігнорується через OpenAI-сумісний ендпоінт
Переміщення ролей повідомлень
Передача developer- або system-повідомлень у середину діалогу через OpenAI-сумісний ендпоінт Anthropic змінює логіку обробки. Шар сумісності збирає всі системні інструкції на початок розмови в один блок. Якщо ваша програма розраховує на динамічну зміну правил на певному кроці, ця логіка ламається, тоді як нативний API Anthropic дозволяє системні повідомлення всередині розмови лише на моделях рівня Opus 5.5.
Ілюзія сумісності параметрів міркування
Параметр reasoning_effort працює по-різному залежно від бекенду:
- Anthropic: повністю ігнорує
reasoning_effortчерез шар сумісності. - Google Gemini: транслює
reasoning_effortу власні механізми thinking (наприклад, наgemini-3.6-flash). - Qwen: конвертує
minimalуlow, аhighуxhigh. Некоректні значення повертають помилку, а спільна передачаthinking_budgetблокується.
Тихе ігнорування параметрів та вибірка
Статус HTTP 200 не означає застосування всіх конфігурацій. DeepSeek без попереджень ігнорує metadata та service_tier. У моделях OpenAI спроба передати temperature разом із активним reasoning призводить до відхилення запиту. Інженерні абстракції (наприклад, llm-api-adapter) вимагають винесення правил валідації в окремий проміжний шар замість сліпої зміни базового URL.
Спробуй за 2 хвилини
# Example of handling reasoning parameter drift via llm-api-adapter
from llm_api_adapter import AdapterClient
from llm_api_adapter.models.messages import UserMessage
adapter = AdapterClient(provider="gemini", model="gemini-3.6-flash")
response = adapter.chat(
messages=[UserMessage("Solve this architecture bottleneck.")],
reasoning_level="high"
)
print(response.content)python
✓ Коли використовувати
- Побудова систем резервного перемикання між Anthropic, OpenAI, DeepSeek та Google Gemini.
- Керування глибиною міркування (reasoning) для моделей із різними схемами параметрів.
✕ Коли НЕ варто
- Прості одноразові запити зі стандартною температурою без складного роутингу.
- Проєкти, жорстко прив'язані до одного постачальника без потреби у резервних моделях.
Що зробити сьогодні
- Перевірте конфігурації роутингу моделей: видаляйте temperature та top_p перед викликом reasoning-моделей.
- Переконайтеся, чи підтримуються системні повідомлення всередині діалогу нативно, чи вони зміщуються на початок.
- Перевірте логи провайдерів, щоб переконатися, що reasoning_effort транслюється, а не відкидається.