Як використовувати один шлюз, сумісний з OpenAI, для чат-API, відповідей, векторних представлень, ранжування, зображень та аудіо API
https://ift.tt/OMbIP9h
Якщо ви зараз створюєте застосунок з штучним інтелектом, ви, ймовірно, працюєте з декількома постачальниками моделей. OpenAI для GPT. DeepSeek за економією коштів. Китайська модель для конкретних завдань. Можливо, Anthropic для Claude.
Кожен постачальник має свій власний SDK, свій потік автентифікації, свої особливості. Це не просто дратує — це крихке. Перехід на іншу модель означає перезапис коду. Додавання нового постачальника означає більше обслуговування.
Існує більш чистий підхід: один шлюз, який говорить протоколом OpenAI, але маршрутизує до декількох бекендів.
Це не про заміну вашого постачальника. Це про абстрагування інтеграційного рівня, щоб ви могли змінювати, порівнювати та поєднувати моделі, не торкаючись коду вашого застосунку.
Давайте розглянемо, як це виглядає на практиці, використовуючи ChinaLLM як конкретний приклад публічно документованого шлюзу.
Чому сумісність з OpenAI має значення більше, ніж інший SDK
Формат API OpenAI став фактично стандартом. Більшість інструментів штучного інтелекту — LangChain, AutoGen, власні агенти — очікують інтерфейс у стилі OpenAI:
– Базова URL: https://ift.tt/NyPGRsQ
– Аутентифікація: токен Bearer у заголовку
– Точки доступу: /v1/chat/completions, /v1/embeddings тощо.
Якщо переходите до іншого постачальника, ви або:
– переписуєте інтеграційний код
– використовуєте специфічний SDK постачальника (і зашиваєтеся у нього)
– знайдете шлюз, який переводитиме все у знайомий вам формат
Третій варіант стає все більш життєздатним. Шлюз, який надає сумісні з OpenAI кінпойнти, але маршрутизує до декількох бекенд‑сервісів, дає вам:
– Переносимість: змінювати постачальників без змін коду
– Порівняння: тестувати різні моделі поруч із однаковим API‑закликом
– Оптимізацію витрат: маршрутизувати до дешевших моделей, коли якісні відмінності не критичні
– Простішу стек: одна потік автентифікації, один SDK, один набір зразків обробки помилок
Це не теорія. ChinaLLM, наприклад, надає саме такий шлюз — публічно документований, з відомими контурами та цінами.
Що ChinaLLM публічно надає сьогодні
ChinaLLM — шлюз API, сумісний з OpenAI, який маршрутизує до моделей OpenAI та постачальників, що працюють в Китаї (DeepSeek, плани кодування Alibaba, GLM, ZAI).
Публічна документація показує такі кінпойнти:
Core chat:
– /v1/chat/completions — стандартний формат чат‑OpenAI
– /v1/responses — формат API Responses від OpenAI
– /v1/responses/compact — компактні відповіді для зменшення використання токенів
– /v1/messages — повідомлення в стилі Anthropic (протокол Claude)
Discovery та embeddings:
– /v1beta/models — список доступних моделей
– /v1/embeddings — текстові векторні представленя
– /v1/rerank — повторний ранжирування для пошуку/пошуково‑змішаних пайплайнів
Image:
– /v1/images/generations — створення зображень за текстом
– /v1/images/edits — редагування існуючих зображень
– /v1/images/variations — створення варіантів зображення
Audio:
– /v1/audio/speech — перетворення тексту в мову
– /v1/audio/transcriptions — розпізнавання промови
– /v1/audio/translations — переклад аудіо на англійський текст
Усі кінпойнти використовують формати запитів/відповідей, сумісні з OpenAI. Те саме SDK, який ви використовуєте для OpenAI, працює тут — просто змініть базову URL.
Як отримати токен та встановити базову URL
Налаштування мінімальне:
1) Отримати API‑ключ у ChinaLLM (реєстрація стандартна)
2) Встановити базовий URL на https://ift.tt/Lk8mvlM
3) Використовувати наявний OpenAI SDK або HTTP клієнт
Жодних нових залежностей. Жодних нових патернів автентифікації.
Для повних прикладів коду дивіться репозиторій на GitHub:
https://ift.tt/gCy7L6D
Приклад з OpenAI Python SDK:
import openai
client = openai.OpenAI(
api_key=”your-chinallm-key”,
base_url=”https://ift.tt/Lk8mvlM”
)
# Тепер використовуйте це точно як з OpenAI
response = client.chat.completions.create(
model=”deepseek-v4-flash”,
messages=[{“role”: “user”, “content”: “What’s the capital of France?”}]
)
print(response.choices[0].message.content)
Той же SDK. Ті ж сигнатури методів. Інший бекенд.
Перший запит через /v1/chat/completions
Зробимо реальний запит. Візьмемо економну модель з публічного прайса: deepseek-v4-flash.
import openai
client = openai.OpenAI(
api_key=”your-chinallm-key”,
base_url=”https://ift.tt/Lk8mvlM”
)
response = client.chat.completions.create(
model=”deepseek-v4-flash”,
messages=[
{“role”: “system”, “content”: “You are a helpful coding assistant.”},
{“role”: “user”, “content”: “Write a Python function to merge two sorted lists.”}
],
temperature=0.7
)
print(response.choices[0].message.content)
Ця відповідь повертається у стандартному форматі OpenAI.
Ключова ідея: ви не змінили жодного коду, щоб перейти з OpenAI на DeepSeek. Ви просто змінили назву моделі.
Розширення поза чатом (відповіді / embeddings / rerank)
Чат — очевидний варіант використання. Але об’єднаний шлюз стає ще кориснішим, коли вам потрібні кілька можливостей в одному застосунку.
Responses API
API Responses (/v1/responses) корисний, коли потрібні структуровані виходи з вбудованими ланцюжками висновків:
response = client.responses.create(
model=”gpt-5.4″,
input=”Analyze this customer feedback and extract sentiment, topic, and action items.”,
instructions=”Return a JSON object with sentiment, topic, and action_items fields.”
)
print(response.output)
Embeddings
Для RAG або семантичного пошуку:
embedding = client.embeddings.create(
model=”text-embedding-3-small”,
input=”What are the best practices for API design?”
)
vector = embedding.data[0].embedding
print(f”Embedding dimension: {len(vector)}”)
Rerank
Коли є кілька кандидатів документів і потрібно ранжувати їх за релевантністю до запиту:
import requests
response = requests.post(
“https://ift.tt/hakKmo7”,
headers={“Authorization”: f”Bearer {api_key}”},
json={
“model”: “rerank-model”,
“query”: “What is the refund policy?”,
“documents”: [
“Our refund policy allows returns within 30 days…”,
“Shipping takes 5-7 business days…”,
“We accept PayPal and credit cards…”
]
}
)
print(response.json()[“results”])
Кожна можливість використовується з тією ж схемою автентифікації, тією ж базовою URL, знайомими форматами запитів. Ніяких окремих SDK для embeddings проти чату проти rerank.
Публічне ціноутворення та відкриття моделей
Сторінка з цінами ChinaLLM демонструє прозорі витрати на моделі з множниками для груп:
– CodingPlan (Alibaba coding plans): 1.1x
– DeepSeek: 1.05x
– GLM: 1.05x
– OpenAI: 1.3x
Це означає:
– Моделі DeepSeek коштують приблизно на 5% дорожче за базове ціно DeepSeek
– Моделі OpenAI коштують приблизно на 30% дорожче за базове ціно OpenAI
– шлюз додає маржу, але ви отримуєте єдиний доступ та спрощену інтеграцію
Видимі моделі (частковий перелік з публічних документів):
– gpt-5.4, gpt-5.5 (OpenAI)
– gpt-image-2 (OpenAI зображення)
– deepseek-v4-flash, deepseek-v4-pro (DeepSeek)
– glm-4.7 (GLM/Zhipu)
Щоб дізнатися всі доступні моделі:
models = client.models.list()
for model in models.data:
print(model.id)
Це повертає поточний каталог моделей — корисно, коли нові моделі додаються без оголошення.
Коли цей підхід корисний
Єдиний шлюз не для всіх. Але він надзвичайно цінний, коли:
– ви порівнюєте моделі — хочете тестувати GPT vs DeepSeek vs GLM на одній задачі без переписування інтеграційного коду
– ви оптимізуєте витрати — хочете направляти прості запити до дешевших моделей, складні — до преміум‑моделей — все через одну API
– ви будуєте мультимодальні застосунки — потрібен чат + embeddings + зображення + аудіо в одному стеку, і не хочете окремих потоків автентифікації для кожного
– ви створюєте інструменти — хочете, щоб ваш фреймворк підтримував кілька постачальників «з коробки», без хардкодінгу логіки конкретного постачальника
– ви зменшуєте ризики залежності від постачальника — хочете можливість швидко переключитися, якщо ціни зміняться, якість сервісу впаде або з’являться кращі опції
Шлюзовий підхід абстрагує відмінності між постачальниками. Вам все одно потрібно знати, яку модель використати для якого завдання — але вам не потрібен окремий код для кожного постачальника.
Останній підсумок
Один шлюз, сумісний з OpenAI. Багато бекендів. Такий же SDK. Такий же потік автентифікації. Ті самі формати запитів.
Це не про заміну вашого постачальника. Це про те, щоб зробити ваш інтеграційний шар більш переносним, більш перевірюваним та більш стійким до змін постачальників.
ChinaLLM — одна конкретна реалізація цього патерну — публічно документована, з прозорими цінами та чітким каталогом моделей. Якщо ви оцінюєте цей підхід, це корисна точка відліку.
Головна думка: припиніть писати інтеграційний код, прив’язаний до конкретного постачальника. Пишіть під стандартний інтерфейс і дозвольте шлюзу керувати маршрутизацією.
HI-FI News
via DEV Community https://dev.to
29 квітня 2026 о 16:01
April 29, 2026 at 04:01PM
Залишити відповідь