API Hop

Poradniki

Jedno API dla GPT, Claude, Gemini i DeepSeek: praktyczny przewodnik dla deweloperów

Dowiedz się, jak podłączyć wiele modeli AI, przełączać je, porównywać koszty i czas odpowiedzi oraz sprawdzać najważniejsze kwestie przed uruchomieniem produkcyjnym.

Sprawdzono:

Żądania tekstowe przechodzą z zaplecza aplikacji przez API Hop do wybranego modelu, a odpowiedzi wracają do aplikacji.
Żądania tekstowe przechodzą z zaplecza aplikacji przez API Hop do wybranego modelu, a odpowiedzi wracają do aplikacji.

Jeśli tworzysz aplikację AI, zapewne znasz tę sytuację: do jednego zadania chcesz użyć GPT, do innego Claude, a do tego wypróbować Gemini. Gdy liczy się koszt, chcesz również porównać DeepSeek.

Różne modele naprawdę dobrze radzą sobie z różnymi zadaniami.

Znalezienie tych modeli nie jest trudne. Właściwe pytanie brzmi: jak podłączyć je wszystkie do aplikacji?

Może być konieczne zarządzanie różnymi kluczami API, kontami i panelami rozliczeniowymi, a czasem także używanie różnych SDK.

W API Hop pracujemy nad uproszczeniem tego procesu. Udostępniamy jedną platformę, na której deweloperzy mogą korzystać z wielu modeli AI przez wspólne API i saldo.

Jak jednak wygląda to w kodzie? Czy ujednolicone API naprawdę ułatwia programowanie?

W tym artykule zaczniemy od rzeczywistej konfiguracji, pokażemy przełączanie modeli, pomiar kosztów i czasu odpowiedzi oraz omówimy, co sprawdzić przed uruchomieniem produkcyjnym.

1. Rzeczywisty scenariusz: wiele modeli, wiele integracji

Załóżmy, że budujemy niewielką aplikację AI.

Planujemy użyć:

  • GPT: do ogólnych zadań i odpowiedzi o określonej strukturze.
  • Claude: do pisania, programowania i dłuższych zadań.
  • Gemini: do zadań multimodalnych.
  • DeepSeek: jako kolejnej opcji do przetestowania kosztu i jakości wyników.

Jeśli połączymy się osobno z oficjalnym API każdego dostawcy, musimy obsłużyć cztery zestawy danych uwierzytelniających API, cenników i metod integracji.

Oto proste porównanie:

ZadanieOddzielne połączenie z każdym dostawcą modeluUjednolicone API
Zarządzanie danymi uwierzytelniającymi APIDo 4 kluczy1 klucz platformy
Zarządzanie kontami rozliczeniowymiDo 41 saldo platformy
Wybór modeluOddzielna konfiguracja każdego dostawcyZmiana identyfikatora modelu tam, gdzie jest obsługiwana
Porównanie wyników modeliWłasny proces testowyPonowne użycie tego samego procesu żądań
Monitorowanie kosztówŁączenie wielu rachunkówPodgląd zużycia na jednej platformie
Obsługa różnic między modelamiNadal potrzebnaNadal potrzebna

Ostatni wiersz ma znaczenie.

Jedno API nie oznacza, że każdy model AI zachowuje się dokładnie tak samo.

Modele mogą różnić się obsługiwanymi parametrami, długościami kontekstu, wywołaniami narzędzi, formatami odpowiedzi i typami wejścia. Ujednolicone API może uprościć integrację, ale nadal musimy wiedzieć, co faktycznie obsługuje każdy model.

2. Rozpocznij pracę z API Hop

Potrzebujemy tylko trzech rzeczy:

  1. Konta API Hop.
  2. Klucza API API Hop.
  3. Identyfikatora modelu, który jest obecnie dostępny.

Obsługiwane modele i aktualne ceny możesz sprawdzić w witrynie:

Dla integracji zgodnych z OpenAI SDK API Hop udostępnia ten bazowy adres URL:

https://api.apihop.ai/openai/v1

Pamiętaj, że nie jest to ten sam adres co nasz ogólny punkt końcowy czatu HTTP:

POST https://api.apihop.ai/v1/chat-completions

W poniższych przykładach SDK użyjemy punktu końcowego zgodnego z OpenAI.

Krok 1: Zainstaluj SDK

Python:

pip install --upgrade openai

Node.js:

npm install openai

Krok 2: Ustaw klucz API

Zalecamy umieszczenie klucza API w zmiennej środowiskowej zamiast wpisywania go na stałe w kodzie.

export APIHOP_API_KEY="your-api-key"
export APIHOP_MODEL="your-supported-model-id"

Zastąp your-supported-model-id rzeczywistym identyfikatorem z aktualnej listy modeli.

Sugerujemy bezpośrednie skopiowanie identyfikatora zamiast zgadywania na podstawie marketingowej nazwy modelu. Identyfikator API może nie odpowiadać dokładnie nazwie na oficjalnej stronie modelu.

3. Wykonaj pierwsze wywołanie API w Pythonie

Oto podstawowy przykład w Pythonie z OpenAI SDK.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["APIHOP_API_KEY"],
    base_url="https://api.apihop.ai/openai/v1",
)

response = client.chat.completions.create(
    model=os.environ["APIHOP_MODEL"],
    messages=[
        {
            "role": "user",
            "content": "Explain what an API is in one sentence."
        }
    ],
)

print(response.choices[0].message.content)

To podstawowa konfiguracja.

Klucz API i bazowy adres URL ustawiamy tylko raz, a następnie wysyłamy żądania czatu z obsługiwanym modelem.

Co powinno wrócić?

Jeśli żądanie się powiedzie, otrzymamy odpowiedź zawierającą treść wygenerowaną przez model.

Model może na przykład wyjaśnić: „API to sposób komunikacji między dwiema aplikacjami”.

Dokładne sformułowanie zależy od modelu i żądania.

Jeśli żądanie się nie powiedzie, zacznij od sprawdzenia:

  • Czy klucz API jest ważny.
  • Czy wybrany identyfikator modelu jest dostępny.
  • Czy punkt końcowy obsługuje żądaną operację.
  • Czy konto ma wystarczające saldo.
  • Czy któryś parametr żądania nie jest obsługiwany.

Nie zalecamy ślepego ponawiania każdego błędu. Błędy uwierzytelniania, niepoprawne nazwy modeli i tymczasowe limity częstotliwości wymagają różnych podejść.

4. Przełączaj się między GPT, Claude, Gemini i DeepSeek

Teraz część, którą uważamy za najbardziej przydatną: testowanie różnych modeli przy możliwie małej zmianie kodu aplikacji.

Zamiast pisać cztery oddzielne integracje API, możemy zacząć od funkcji przyjmującej identyfikator modelu.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["APIHOP_API_KEY"],
    base_url="https://api.apihop.ai/openai/v1",
)

def ask_model(model_id, question):
    response = client.chat.completions.create(
        model=model_id,
        messages=[
            {
                "role": "user",
                "content": question
            }
        ],
    )

    return response.choices[0].message.content

Teraz możemy wywoływać tę samą funkcję z różnymi identyfikatorami modeli.

question = "Explain REST APIs to a beginner."

model_ids = {
    "GPT": os.environ["GPT_MODEL_ID"],
    "Claude": os.environ["CLAUDE_MODEL_ID"],
    "Gemini": os.environ["GEMINI_MODEL_ID"],
    "DeepSeek": os.environ["DEEPSEEK_MODEL_ID"],
}

for name, model_id in model_ids.items():
    print(f"\n--- {name} ---")

    try:
        answer = ask_model(model_id, question)
        print(answer)
    except Exception as error:
        print(f"Request failed: {error}")

Przed uruchomieniem znajdź cztery prawidłowe, dostępne identyfikatory w najnowszej liście modeli i ustaw odpowiadające im zmienne środowiskowe:

export GPT_MODEL_ID="supported-gpt-model-id"
export CLAUDE_MODEL_ID="supported-claude-model-id"
export GEMINI_MODEL_ID="supported-gemini-model-id"
export DEEPSEEK_MODEL_ID="supported-deepseek-model-id"

Celem jest ponowne użycie tej samej funkcji żądania zamiast pisania osobnej integracji SDK dla każdej rodziny modeli.

Pamiętaj: Wybrane modele muszą obsługiwać punkt końcowy czatu zgodny z OpenAI i konkretne wysyłane parametry. Niektóre zaawansowane funkcje mogą wymagać innych punktów końcowych.

5. Niech przemówią dane z testów

Oczywiście jedno udane żądanie API mówi nam tylko, że punkt końcowy działa. Nie dowodzi, że usługa jest wystarczająco szybka, niezawodna lub tania do użytku produkcyjnego.

Przeprowadźmy więc mały test dla własnej aplikacji.

Wyślij ten sam prompt do wszystkich czterech modeli i zapisz:

  • Czy żądanie się powiodło.
  • Ile trwa każde żądanie.
  • Liczbę tokenów wejściowych.
  • Liczbę tokenów wyjściowych.
  • Co model faktycznie zwraca.

W pierwszej rundzie używamy tego promptu:

Explain how HTTPS protects data between a browser and a server. Use fewer than 100 words.

To dość proste pytanie, ale stanowi dobry punkt wyjścia do sprawdzenia, czy ten sam format żądania działa z różnymi modelami.

Skrypt testowy w Pythonie

import os
import time
import json
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["APIHOP_API_KEY"],
    base_url="https://api.apihop.ai/openai/v1",
    timeout=60.0,
    max_retries=0,
)

models = {
    "GPT": os.environ["GPT_MODEL_ID"],
    "Claude": os.environ["CLAUDE_MODEL_ID"],
    "Gemini": os.environ["GEMINI_MODEL_ID"],
    "DeepSeek": os.environ["DEEPSEEK_MODEL_ID"],
}

prompt = (
    "Explain how HTTPS protects data between "
    "a browser and a server. Use fewer than 100 words."
)

results = []

for provider, model_id in models.items():
    for run in range(5):
        start = time.perf_counter()

        try:
            response = client.chat.completions.create(
                model=model_id,
                messages=[
                    {"role": "user", "content": prompt}
                ],
            )

            elapsed = time.perf_counter() - start
            usage = response.usage

            results.append({
                "provider": provider,
                "model_id": model_id,
                "run": run + 1,
                "success": True,
                "latency_seconds": round(elapsed, 3),
                "input_tokens": (
                    usage.prompt_tokens if usage else None
                ),
                "output_tokens": (
                    usage.completion_tokens if usage else None
                ),
                "answer": (
                    response.choices[0].message.content
                ),
            })

        except Exception as error:
            elapsed = time.perf_counter() - start

            results.append({
                "provider": provider,
                "model_id": model_id,
                "run": run + 1,
                "success": False,
                "latency_seconds": round(elapsed, 3),
                "error": str(error),
            })

with open("apihop-test-results.json", "w") as f:
    json.dump(results, f, indent=2)

print(json.dumps(results, indent=2))

Ustawiamy max_retries=0, ponieważ chcemy zobaczyć, czy każde pojedyncze żądanie zawodzi, zamiast pozwalać SDK ukrywać błędy automatycznym ponawianiem. To ustawienie służy pomiarowi; nie musi oznaczać, że należy używać go także w produkcji.

Żądanie bazowe wysyła tylko model i messages, które muszą obsługiwać wszystkie wybrane modele. Pomija opcjonalne parametry próbkowania, takie jak temperature i top_p. Przed dodaniem opcjonalnego parametru dla konkretnego modelu sprawdź jego obsługę i zapisz zmianę. Błąd 400 spowodowany nieobsługiwanym parametrem to błąd zgodności żądania, a nie dowód słabej jakości wyników modelu.

Zapisz wystarczający kontekst do odtworzenia testu

Ten skrypt to metoda oceny, a nie opublikowany ranking wydajności. Poprzednie podsumowanie pięciu żądań zostało usunięte, ponieważ czytelnicy nie mają dostępu do źródłowych zapisów żądań i historycznych stawek, aby je zweryfikować.

Dla własnego przebiegu zachowaj czas testu UTC, dokładny identyfikator modelu, punkt końcowy, pełne parametry i prompt, surowe pola usage, odpowiedź lub zanonimizowany błąd oraz źródło i datę stosowanej stawki. Nigdy nie umieszczaj w zapisie kluczy API. Rozdziel zwykłe wejście, wejście z pamięci podręcznej, zapisy do pamięci podręcznej i wyjście zgodnie z regułami rozliczeniowymi modelu, zamiast liczyć to samo zużycie dwukrotnie.

Tutaj latency_seconds mierzy całe żądanie bez strumieniowania, a nie czas do pierwszego tokenu. Przed porównaniem kosztów zbadaj nieoczekiwane liczby tokenów na podstawie pełnego żądania i zapisu zużycia. W kosztach zadania uwzględnij nieudane próby i ponowienia. Pięć udanych żądań nie ustanawia SLA ani rankingu jakości całej platformy.

6. Porównaj koszty API na podstawie rzeczywistego zużycia tokenów

Jedną z głównych przyczyn niejasności cen API AI jest to, że tokeny wejściowe i wyjściowe zwykle mają różne ceny.

Niektóre modele oferują także ceny wejścia z pamięci podręcznej, co dodatkowo wpływa na koszt końcowy.

W przypadku tekstowych API zwykle zaczynamy od tego wzoru:

Szacowany koszt = (tokeny wejściowe x cena wejścia + tokeny wyjściowe x cena wyjścia) / 1,000,000

Zakłada on, że obie ceny są za milion tokenów, a całe zużycie rozliczane jest według standardowej stawki bez pamięci podręcznej.

Wypróbuj proste obliczenie kosztu

Załóżmy, że nasza aplikacja wykonuje 100,000 żądań miesięcznie.

Szacujemy, że każde żądanie zużywa średnio:

  • 1,000 tokenów wejściowych.
  • 300 tokenów wyjściowych.

Daje to następujące miesięczne zużycie:

WskaźnikZużycie miesięczne
Żądania100,000
Tokeny wejściowe100,000,000
Tokeny wyjściowe30,000,000

Następnie porównajmy dwa zestawy hipotetycznych cen.

Pozycja cennikaPrzykład APrzykład B
Cena wejścia / milion tokenów$2.00$1.00
Cena wyjścia / milion tokenów$8.00$4.00
Miesięczny koszt wejścia$200$100
Miesięczny koszt wyjścia$240$120
Łączny koszt miesięczny$440$220

W tym przykładzie B jest o 50% tańsze od A.

Przy tym samym zużyciu tokenów różnica wynosi $220 miesięcznie.

Przed wyborem dostawcy wstawilibyśmy do wzoru najnowsze ceny modelu i sprawdzili opłaty platformy, reguły pamięci podręcznej, minimalne opłaty oraz inne warunki rozliczeń.

Aktualne ceny modeli API Hop znajdziesz w cenniku.

Dlaczego rzeczywiste dane o tokenach są ważne?

Różne modele mogą generować różne liczby tokenów wyjściowych, nawet odpowiadając na to samo pytanie.

Ma to znaczenie, ponieważ tokeny wyjściowe często kosztują więcej niż wejściowe.

Sugerujemy testowanie modeli na własnych rzeczywistych promptach i sprawdzanie zużycia na podstawie danych zwracanych przez API, gdy tylko jest to możliwe.

Łatwo przeoczyć jeszcze jeden szczegół: różne rodziny modeli mogą używać różnych tokenizerów, więc zgłaszane liczby tokenów nie zawsze są bezpośrednio porównywalne.

Dlatego zamiast pytać tylko „Który model zużywa mniej tokenów?”, bardziej interesuje nas: Ile rzeczywiście zapłaciliśmy za wykonanie tego samego, stałego zestawu zadań?

7. Co jeszcze sprawdzamy przed uruchomieniem produkcyjnym?

W demonstracji otrzymanie odpowiedzi modelu zwykle wystarcza do ukończenia pierwszego kroku.

Udostępnienie aplikacji prawdziwym użytkownikom to jednak coś innego.

Większą uwagę zwracamy na nieudane żądania, przekroczenia budżetu, kwestie bezpieczeństwa oraz spójne i przewidywalne zachowanie systemu.

Oto kilka rzeczy, które sugerujemy sprawdzić przed skierowaniem rzeczywistego ruchu biznesowego.

Obsługa błędów

Rozróżniamy:

  • Problemy z uwierzytelnianiem, na przykład nieprawidłowy klucz API.
  • Limity częstotliwości lub tymczasowe niedobory przepustowości.
  • Nieobsługiwane modele lub parametry żądania.
  • Przekroczenia czasu oczekiwania i błędy sieci.
  • Błędy po stronie serwera.

Ponawiamy tylko wtedy, gdy kolejna próba ma szansę się powieść, z ograniczoną liczbą prób i rozsądnymi opóźnieniami między nimi.

Zgodność modeli

Nie zakładamy, że każdy model obsługuje każdą funkcję.

Przed użyciem wywołań narzędzi, ustrukturyzowanego wyniku JSON, obrazów na wejściu, długiego kontekstu lub odpowiedzi strumieniowych sprawdzamy obsługę konkretnego modelu i punktu końcowego.

Kontrola kosztów

Zalecamy śledzenie kosztu każdego głównego zadania biznesowego.

Na przykład przy budowie narzędzia do generowania treści powinniśmy skupić się na pytaniu „Ile średnio kosztuje wygenerowanie kompletnego dokumentu?”, a nie tylko na cenie katalogowej za milion tokenów.

Tani model wymagający trzech dodatkowych prób może ostatecznie nie oszczędzić pieniędzy.

Bezpieczeństwo i przetwarzanie danych

Przechowujemy klucze API na serwerze, aby ograniczyć ryzyko ujawnienia, i niezwłocznie je wymieniamy, gdy to konieczne.

Przed wysłaniem danych klientów do jakiejkolwiek zewnętrznej platformy API, w tym API Hop, czytamy także jej zasady przetwarzania i przechowywania danych.

Zgodne API nie oznaczają identycznych warunków prywatności i zobowiązań usługowych.

Niezawodność

Dla krytycznych obciążeń sugerujemy przetestowanie planu awaryjnego i sprawdzenie, czy model zapasowy obsłuży te same dane wejściowe.

Przełączenie awaryjne pomaga tylko wtedy, gdy model zapasowy jest faktycznie zgodny z zadaniem.

8. Kiedy ujednolicone API ma sens?

Uważamy, że warto rozważyć ujednolicone API, gdy:

  • Budujesz niewielki SaaS AI i chcesz porównać modele.
  • Testujesz GPT, Claude, Gemini i DeepSeek.
  • Nie chcesz utrzymywać kilku oddzielnych kont rozliczeniowych.
  • Twój produkt szybko się zmienia i najpierw chcesz uprościć integrację.
  • Chcesz dobierać różne modele do różnych zadań na podstawie rzeczywistych wyników testów.

Ujednolicone API nie zawsze jest jednak najlepszym wyborem.

Bezpośrednie użycie oficjalnego API może lepiej pasować, jeśli potrzebujesz nowej funkcji niedawno udostępnionej przez dostawcę modelu, której brama jeszcze nie obsługuje, bezpośredniej umowy z dostawcą, jego dedykowanego wsparcia lub zaawansowanych ustawień niewystawianych przez zgodne API.

Podobnie, jeśli Twój zespół już prowadzi dojrzałą wewnętrzną bramę spełniającą wymagania niezawodności, monitorowania i integracji modeli, zmiana platformy może przynieść niewielką korzyść.

Wolimy, by deweloperzy porównywali opcje według rzeczywistych potrzeb, a nie samych deklaracji marketingowych.

9. Często zadawane pytania

Czy mogę używać jednego klucza API do wywoływania GPT, Claude, Gemini i DeepSeek?

API Hop udostępnia wspólny klucz API i saldo platformy dla obsługiwanych modeli. Każde wywołanie nadal wymaga dokładnego identyfikatora z aktualnej listy modeli i odpowiedniego obsługiwanego punktu końcowego.

Czy muszę zmienić istniejący kod OpenAI SDK, aby używać API Hop?

Dla obsługiwanych żądań czatu zgodnych z OpenAI zwykle możesz nadal używać OpenAI SDK, zmieniając tylko bazowy adres URL, klucz API i identyfikator modelu.

Jeśli jednak korzystasz z zaawansowanych funkcji specyficznych dla dostawcy, nadal mogą być potrzebne zmiany kodu.

Czy ujednolicone API jest zawsze tańsze od bezpośredniego połączenia z oficjalnym API?

To zależy od modelu, zużycia tokenów, cen pamięci podręcznej, opłat platformy i rzeczywistego obciążenia.

Sugerujemy porównywanie rzeczywistych rachunków za ten sam zestaw zadań zamiast zakładania, że wszystkie bramy są tańsze.

API Hop nie obiecuje niższych cen ani lepszej jakości wyników dla każdego modelu i obciążenia. Porównaj aktualne stawki przy takich samych warunkach rozliczenia, a następnie oceń jakość wyników na własnych zadaniach.

Czy mogę dynamicznie przełączać modele podczas działania aplikacji?

Tak. Aplikacja może wybrać inny obsługiwany identyfikator modelu dla każdego żądania.

Nadal musisz jednak obsługiwać różnice w parametrach, odpowiedziach i funkcjach modeli.

Czy API Hop obsługuje tylko modele tekstowe?

Nie.

API Hop oferuje także obrazy, wideo i niektóre usługi API danych.

Usługi te mogą używać innych punktów końcowych i formatów żądań, więc nie można wywoływać ich tak samo jak tekstowego API czatu.

Na zakończenie

Korzystanie z wielu modeli AI nie powinno oznaczać utrzymywania czterech całkowicie oddzielnych systemów integracji.

W API Hop chcemy uprościć wspólne elementy: jedna platforma, jedno saldo do zarządzania i ujednolicony dostęp do obsługiwanych modeli.

Uważamy jednak także, że najważniejszy jest pomiar rzeczywistych wyników.

Przed wyborem modelu lub dostawcy usługi sugerujemy odpowiedzieć na trzy pytania:

  1. Czy to działa? Przetestuj funkcje API faktycznie potrzebne Twojej aplikacji.
  2. Ile to kosztuje? Oblicz koszty na podstawie rzeczywistego zużycia, a nie tylko reklamowanych cen.
  3. Jakie daje wyniki? Porównaj opóźnienia, błędy i jakość wyników na własnych promptach.

Powyżej udostępniliśmy kod i prosty proces testowania, aby można było sprawdzić to samodzielnie na własnym koncie.

Na początek zajrzyj do listy modeli, sprawdź najnowsze ceny i skorzystaj z dokumentacji API.

Chętnie zobaczymy, co z tym zbudujesz.

Zespół API Hop