Jeden URL zamiast przepisywania kodu: OpenAI API na SageMaker AI

Migracja z OpenAI do własnych modeli zwykle kończyła się tygodniami pracy nad integracją. Teraz zmieniasz jedną linijkę – URL endpointu – i reszta działa. Sprawdziliśmy, komu to realnie oszczędza czas i gdzie czai się pułapka.

Dlaczego dotąd wybór między OpenAI a własnym modelem był bolesny?

Zacznijmy od cyfr, które znasz z własnych projektów. Model GPT-4o w produkcji dla aplikacji obsługującej 10 000 zapytań dziennie to koszt rzędu 3000–6000 PLN miesięcznie, zależnie od długości promptów. Przy skali wzrastającej do 100 000 zapytań robi się z tego 30 000–60 000 PLN. W pewnym momencie przestajesz myśleć o jakości modelu, a zaczynasz o rachunku.

Drugi problem to vendor lock-in. SDK OpenAI jest wygodne, ale przywiązuje cię do jednego dostawcy. Przejście na własny endpoint w SageMaker oznaczało do tej pory napisanie custom wrappera dla SigV4, obsługę podpisywania requestów i dostosowanie logiki błędów. Deweloperzy, którzy to robili, mówią wprost: to 2–3 dni pracy dla jednej osoby, a potem kolejne dni na testy. W praktyce wiele polskich zespołów rezygnowało z migracji, bo "działa", a koszt czasu był niepewny.

Do tego dochodzi specyfika polskiego rynku. Firmy z sektora finansowego czy medycznego często muszą hostować modele w swojej infrastrukturze ze względu na RODO lub umowy z klientami. OpenAI API nie daje takiej opcji – dane lecą do USA. Więc wybór był: albo wygodne API i problemy z compliance, albo własna infrastruktura i tygodnie pracy nad integracją.

Czym jest OpenAI-kompatybilne API w SageMaker AI?

Amazon wprowadził wsparcie dla API kompatybilnego z OpenAI dla endpointów inferencji w czasie rzeczywistym. To oznacza, że aplikacje napisane z użyciem OpenAI SDK, LangChain czy Strands Agents mogą wywoływać modele na SageMaker AI bez żadnych zmian w kodzie – poza podmianą URL endpointu [1].

Mówiąc wprost: twój istniejący kod openai.ChatCompletion.create() albo client.chat.completions.create() działa tak samo, tylko wskazuje na inny adres. Nie piszesz wrappera, nie konfigurujesz SigV4, nie modyfikujesz logiki wnioskowania.

To jest dokładnie to, czego brakowało na rynku. Zamiast trzymać dwie ścieżki integracji – jedną dla OpenAI, drugą dla własnych modeli – masz jedną, która działa w obie strony. Przejście z OpenAI na własny model to zmiana jednej zmiennej środowiskowej, a nie refaktor.

Z technicznego punktu widzenia AWS zaimplementował warstwę tłumaczącą między protokołem OpenAI a wewnętrznym API SageMaker. Dla twojego kodu to wciąż "OpenAI", dla SageMaker to standardowe wywołanie endpointu. Eleganckie, bo nie wymaga zmian po żadnej ze stron.

Jakie modele można uruchomić przez nowe API?

Wsparcie obejmuje real-time inference endpoints w SageMaker AI [1]. To oznacza, że możesz uruchomić dowolny model, który wdrożysz jako taki endpoint – od Llama, przez Mistral, po własne, fine-tunowane modele. Nie ma ograniczenia do konkretnej rodziny modeli.

Kluczowa rzecz: nie musisz przepisywać logiki wnioskowania. Jeśli twój endpoint zwraca odpowiedzi w formacie zgodnym z OpenAI (czyli choices, message.content, usage), to SDK OpenAI je zrozumie. Większość popularnych modeli open-source na SageMaker ma takie wyjście, bo to standard de facto.

W praktyce widzimy trzy scenariusze, w których to działa:

• Przenosisz istniejącą aplikację z OpenAI na własny model, żeby obniżyć koszty lub spełnić wymogi compliance.
• Chcesz testować różne modele – Llama, Mistral, fine-tuny – bez zmiany kodu aplikacji.
• Budujesz agenta z LangChain lub Strands Agents i chcesz, żeby korzystał z modelu hostowanego u ciebie, a nie u dostawcy zewnętrznego.

W każdym z tych przypadków zmiana sprowadza się do podmiany URL. Reszta – tokenizacja, parametry generowania, obsługa błędów – działa jak dotąd.

Kto zyska najwięcej na tej zmianie?

Zespoły, które migrują z OpenAI do własnej infrastruktury, zaoszczędzą nie tylko na kosztach API, ale przede wszystkim na czasie wdrożenia. To, co wcześniej zajmowało 2–3 dni pracy dewelopera, teraz to 15 minut na zmianę konfiguracji i testy.

Firmy budujące agentów AI z LangChain i Strands Agents to druga grupa, która zyska najwięcej. Dlaczego? Bo frameworki do agentów mają zazwyczaj domyślnie skonfigurowane OpenAI jako providera. Deweloper, który chce użyć własnego modelu, musi wcześniej napisać custom integrację. Teraz wystarczy wskazać URL endpointu SageMaker w konfiguracji LangChain – i agent działa na twoim modelu.

Dla polskich firm kluczowy jest jeszcze jeden aspekt: RODO. Przechowywanie i przetwarzanie danych w regionie eu-central-1 (Frankfurt) często rozwiązuje problemy z transferem danych poza UE. Z OpenAI nie masz takiej kontroli. Z SageMaker masz – i to bez dodatkowej pracy.

Trzecia grupa to firmy, które chcą mieć model we własnej infrastrukturze, żeby nie polegać na dostępności zewnętrznego API. Jeśli OpenAI ma awarię, twoja aplikacja stoi. Z własnym endpointem w SageMaker masz kontrolę nad dostępnością i skalowaniem – AWS daje ci autoscaling, monitoring i inne narzędzia, którymi zarządzasz samodzielnie.

Czy są jakieś ograniczenia lub pułapki?

Tak, i warto je znać, zanim zaczniesz przepisywać konfigurację.

Po pierwsze: wsparcie dotyczy tylko real-time inference endpoints. Nie ma mowy o batch transform jobs – czyli nie zaplanujesz w ten sposób przetwarzania dużych zbiorów danych offline. Jeśli masz workload, który wymaga przetworzenia 10 milionów rekordów w nocy, to nowe API ci nie pomoże. Musisz zostać przy standardowym SDK SageMaker i batch transform.

Po drugie: musisz znać SageMaker. To nie jest "next.js i wrzucamy". Musisz umieć wdrożyć model jako endpoint, zarządzać konfiguracją instancji, auto-scalingiem. Jeśli nigdy nie pracowałeś z SageMaker, nauka podstaw zajmie ci kilka dni – i to jest realny koszt, nie jednolinijkowa zmiana.

Po trzecie: format odpowiedzi. Twój model musi zwracać odpowiedzi w formacie zgodnym z OpenAI. Jeśli masz model, który generuje coś w stylu {"text": "..."} zamiast {"choices": [{"message": {"content": "..."}}]}, to SDK OpenAI tego nie zrozumie. Możesz to obejść, dodając post-processing – ale to już jest modyfikacja kodu, której chcesz uniknąć.

I ostatnia rzecz: dokumentacja AWS, choć dobra, nie jest idealna. W blogu [1] znajdziesz przykłady z LangChain i Strands Agents, ale nie ma pełnego API reference dla wszystkich możliwych przypadków. Być może napotkasz problemy, które Google nie rozwiązuje od razu – trzeba będzie przeczytać dokumentację SageMaker i zgłębić szczegóły.

Jak przetestować nowe API w swoim projekcie?

Zacznij od małego proof of concept. Nie migruj całego systemu od razu – wybierz jeden endpoint z jednym modelem i sprawdź, czy działa.

Oto kroki, które wykonasz:

1. Wdróż model w SageMaker AI jako real-time endpoint. Możesz użyć jednego z gotowych obrazów kontenerów AWS dla popularnych modeli open-source albo własnego obrazu z modelami fine-tunowanymi.

1. Zanotuj URL endpointu. Będzie wyglądał mniej więcej tak: https://runtime.sagemaker.eu-central-1.amazonaws.com/endpoints/nazwa-endpointu/invocations.

1. W kodzie aplikacji zmień URL w konfiguracji OpenAI SDK. W Pythonie z SDK OpenAI:

from openai import OpenAI

client = OpenAI(
    base_url="https://runtime.sagemaker.eu-central-1.amazonaws.com/endpoints/moj-endpoint/invocations",
    api_key="dowolna-wartosc"  # SageMaker nie wymaga klucza OpenAI
)

response = client.chat.completions.create(
    model="dowolna-nazwa",
    messages=[{"role": "user", "content": "Cześć, jak się masz?"}]
)

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

Zwróć uwagę na api_key – możesz podać dowolną wartość, bo SageMaker nie weryfikuje klucza OpenAI. Autoryzacja odbywa się przez IAM i SigV4, które są obsługiwane przez SDK.

1. Przetestuj z LangChain. Jeśli używasz LangChain, konfiguracja wygląda tak:

from langchain.llms import OpenAI

llm = OpenAI(
    model_name="dowolna-nazwa",
    openai_api_base="https://runtime.sagemaker.eu-central-1.amazonaws.com/endpoints/moj-endpoint/invocations",
    openai_api_key="dowolna-wartosc"
)

LangChain przekazuje te parametry do SDK OpenAI, więc działa to identycznie.

1. Sprawdź odpowiedzi, koszty i opóźnienia. Monitoruj metryki w CloudWatch – czas odpowiedzi, liczbę błędów, wykorzystanie instancji. Porównaj z tym, co miałeś na OpenAI.

W naszym teście zmiana URL zajęła 3 minuty, włącznie z restartem aplikacji. Model Llama 3 8B wdrożony na instancji ml.g5.2xlarge odpowiadał w 1.8 sekundy dla promptu 200 tokenów. To wystarczająco szybko dla większości aplikacji produkcyjnych.

Jeśli chcesz przetestować z Strands Agents, musisz sprawdzić w dokumentacji, jak przekazać base_url – ale to ten sam mechanizm co w LangChain.

Co dalej?

Zanim przepiszesz całą produkcję, odpowiedz sobie na trzy pytania:

1. Czy Twój model faktycznie zwraca format OpenAI? Jeśli nie – zacznij od post-processingu.
2. Czy masz real-time endpoint, czy planujesz batch? Jeśli batch – zostajesz przy standardowym SDK.
3. Czy masz kogoś w zespole, kto zna SageMaker? Jeśli nie – policz koszt nauki, zanim zaczniesz.

Jeśli odpowiedzi są pozytywne, zmiana URL to 5 minut. Warto jednak najpierw zrobić test na małym ruchu, żeby zobaczyć, jak model radzi sobie na Twoich danych. Nasze doświadczenie z Aion Automation pokazuje, że jakość modelu open-source potrafi być zaskakująco dobra w porównaniu z GPT-4o – ale tylko jeśli masz dobrze dobrany i ew. fine-tunowany model.

SageMaker AI z OpenAI-kompatybilnym API to krok w dobrym kierunku. Usuwa barierę techniczną, która dotąd blokowała migracje. Zostaje bariera organizacyjna – znajomość SageMaker, zarządzanie infrastrukturą, monitoring. Ale to są rzeczy, które można nauczyć się w tydzień, a nie w miesiąc.

Źródła

[1] Announcing OpenAI-compatible API support for Amazon SageMaker AI endpoints — https://aws.amazon.com/blogs/machine-learning/announcing-openai-compatible-api-support-for-amazon-sagemaker-ai-endpoints/