Azure OpenAI, osadzenia w chmurze firmy

Azure OpenAI, czyli te same modele w innej obudowie

Azure udostępnia modele osadzeń OpenAI w ramach chmury Microsoftu. Modele są dokładnie te same, więc jakość wyników i liczba wymiarów nie różnią się od dostępu bezpośredniego, natomiast wszystko wokół nich wygląda inaczej.

Ta różnica jest powodem, dla którego firmy wybierają tę drogę. Rozliczenie idzie przez istniejącą umowę z Microsoftem, dane przetwarzane są w wybranym regionie, dostęp kontrolujesz tym samym mechanizmem co resztę zasobów, a ruch może iść siecią prywatną, bez wychodzenia do publicznego internetu.

Ten tekst dotyczy tego, co jest specyficzne dla tej drogi dostępu. Opis samych modeli, wyboru między nimi i skracania wymiarów znajdziesz w osobnym opracowaniu.

Wdrożenie zamiast modelu

To najczęstsza przyczyna błędów przy przenoszeniu kodu i rzecz, która myli praktycznie każdego przy pierwszym podejściu.

W dostępie bezpośrednim podajesz nazwę modelu. Tutaj tworzysz wdrożenie, nadajesz mu własną nazwę i to jej używasz w wywołaniach. Nazwa wdrożenia może być dowolna i nie musi mieć nic wspólnego z nazwą modelu pod spodem.

from openai import AzureOpenAI

klient = AzureOpenAI(
    azure_endpoint="https://nazwa-zasobu.openai.azure.com",
    api_key=os.environ["AZURE_OPENAI_KEY"],
    api_version="2024-10-21",
)

odpowiedz = klient.embeddings.create(
    model="osadzenia-produkcja",
    input=fragmenty,
)

Wartość przekazana jako model to nazwa wdrożenia, a nie modelu. Wdrożenie nazwane w ten sposób może pod spodem korzystać z modelu mniejszego albo większego, a Ty tego z kodu nie widzisz.

Ma to zaletę i wadę. Zaletą jest możliwość podmiany modelu bez zmiany kodu: przestawiasz wdrożenie i aplikacja korzysta z nowego. Wadą jest to, że kod nie mówi, co faktycznie liczy wektory, więc nazwę modelu i wersję trzeba zapisać obok indeksu, inaczej po pół roku nikt tego nie odtworzy.

Praktyczna konwencja: nazywaj wdrożenia zgodnie z modelem i przeznaczeniem, na przykład łącząc nazwę modelu ze środowiskiem. Nazwy w rodzaju „wdrożenie-1" wyglądają niewinnie i po roku nikomu nic nie mówią.

Limity, czyli rzecz do zaplanowania

Drugie zaskoczenie dotyczy przepustowości, bo działa tu inaczej niż przy dostępie bezpośrednim.

Limit przydzielany jest subskrypcji osobno dla każdego regionu, każdego modelu i każdego rodzaju wdrożenia, wyrażony w tokenach na minutę. Przy tworzeniu wdrożenia przydzielasz mu część tej puli, a dostępna reszta odpowiednio maleje.

Z limitu tokenowego wynika automatycznie limit liczby żądań, w proporcji ustalonej osobno dla każdego modelu. To znaczy, że wdrożenie z małym przydziałem tokenów przyjmie niewiele żądań na minutę, nawet jeśli każde jest krótkie.

Konsekwencja praktyczna dotyczy indeksowania. Przetworzenie dużego archiwum wymaga wysyłania fragmentów partiami, a limit liczby żądań bywa tu ograniczeniem wcześniej niż limit tokenów. Rozsądny układ to partie po kilkadziesiąt fragmentów, kilka wątków równolegle i obsługa odpowiedzi o przekroczeniu limitu z opóźnieniem narastającym.

Warto też rozdzielić wdrożenia według przeznaczenia. Osobne wdrożenie na indeksowanie i osobne na obsługę zapytań sprawia, że nocne przetwarzanie archiwum nie zabiera przepustowości użytkownikom pytającym w ciągu dnia, a limity da się przydzielić proporcjonalnie do rzeczywistych potrzeb.

Przy większej skali dostępny jest wariant z zarezerwowaną przepustowością, rozliczany godzinowo zamiast za tokeny. Opłaca się dopiero przy stałym, wysokim wykorzystaniu, więc warto policzyć to na własnym ruchu, zamiast przyjmować, że rezerwacja jest zawsze tańsza.

Regiony i zgodność

To jest zwykle prawdziwy powód wyboru tej drogi, więc warto wiedzieć, co dokładnie dostajesz.

Zasób tworzysz w konkretnym regionie i tam odbywa się przetwarzanie. Przy wymogach dotyczących miejsca przechowywania danych osobowych to bywa warunek wejścia, którego dostęp bezpośredni nie spełnia.

Zastrzeżenie, które trzeba postawić wprost: nie każdy model jest dostępny w każdym regionie. Sprawdź to przed wyborem regionu, bo przeniesienie zasobu później oznacza utworzenie nowego od zera i przeliczenie całego indeksu.

Dostęp kontrolujesz mechanizmem uprawnień wspólnym dla całej chmury, więc klucz w kodzie da się zastąpić tożsamością przypisaną do usługi. To rozwiązuje problem kluczy krążących po repozytoriach i plikach konfiguracyjnych, i warto z tego skorzystać zamiast kopiować wzorzec z dostępu bezpośredniego.

Ruch da się zamknąć w sieci prywatnej, przez punkt końcowy dostępny wyłącznie z Twojej sieci wirtualnej. Wtedy zapytania nie wychodzą do publicznego internetu w żadnym momencie, co przy części polityk bezpieczeństwa jest wymagane wprost.

Przy takiej konfiguracji warto od razu przemyśleć środowisko deweloperskie. Zasób dostępny wyłącznie z sieci wirtualnej nie odpowie z komputera programisty, więc praca lokalna wymaga albo połączenia do tej sieci, albo osobnego zasobu z dostępem publicznym przeznaczonego wyłącznie do rozwoju. Drugie rozwiązanie jest wygodniejsze i wymaga pilnowania, żeby nie trafiły do niego dane produkcyjne.

Różnice w rozliczeniu

Stawka za tokeny zależy tu od rodzaju wdrożenia i to pierwsza rzecz do sprawdzenia. Wdrożenie globalne, czyli takie, które nie ogranicza miejsca przetwarzania, kosztuje dokładnie tyle co dostęp bezpośredni. Wdrożenie ograniczone do strefy danych jest o około dziesięć procent droższe, a wdrożenie przypięte do jednego regionu od dziesięciu do ponad trzydziestu procent, zależnie od wybranego regionu. Ma to znaczenie, bo właśnie po ograniczenie miejsca przetwarzania sięga się tu najczęściej. Druga różnica bywa pomijana przy planowaniu.

Tryb wsadowy, zbijający cenę o połowę w zamian za wynik dostarczany z opóźnieniem, jest dostępny przy dostępie bezpośrednim, a przy tej drodze nie. To znaczy, że jednorazowe zaindeksowanie dużego archiwum kosztuje tu co najmniej dwa razy więcej niż tam, a przy wdrożeniu przypiętym do regionu jeszcze więcej.

Wniosek praktyczny bywa zaskakujący i warto go rozważyć uczciwie. Przy archiwum liczonym w miliardach tokenów różnica na większym modelu osadzeń idzie w setki dolarów, a przy dziesiątkach miliardów w tysiące, więc jednorazowe indeksowanie da się wykonać taniej przez dostęp bezpośredni, a bieżącą obsługę zapytań zostawić tutaj, jeśli wymogi zgodności dotyczą ruchu produkcyjnego, a nie samego przetwarzania archiwum.

To rozwiązanie wymaga oczywiście sprawdzenia z osobą odpowiedzialną za zgodność, bo w części organizacji wymóg dotyczy wszystkich danych niezależnie od tego, kiedy są przetwarzane. Warto natomiast wiedzieć, że taka możliwość istnieje, zamiast zakładać, że cena jest identyczna.

Do rachunku dolicz też koszty wokół: bazę wektorową, ruch sieciowy między usługami i ewentualne punkty końcowe sieci prywatnej, które mają własną opłatę godzinową.

Ta ostatnia pozycja bywa zaskoczeniem, bo nalicza się niezależnie od ruchu. Punkt końcowy sieci prywatnej kosztuje tyle samo przy jednym zapytaniu dziennie co przy milionie, więc przy niedużym projekcie potrafi przewyższyć koszt samych osadzeń. Przy trzech środowiskach, każdym z własnym punktem końcowym, ta pozycja rośnie trzykrotnie, mimo że dwa z nich stoją bezczynnie przez większość doby.

Przeniesienie istniejącej aplikacji

Jeśli masz działający kod korzystający z dostępu bezpośredniego, przejście jest wykonalne w popołudnie, o ile znasz cztery różnice.

Pierwsza to adres. Zamiast wspólnego punktu końcowego dostawcy podajesz adres swojego zasobu, unikalny dla Twojej organizacji i regionu.

Druga to wersja interfejsu, podawana jawnie przy tworzeniu klienta. To rozwiązanie ma zaletę: nowa wersja nie zmienia zachowania Twojej aplikacji, dopóki sam jej nie podniesiesz. Ma też wadę: łatwo utknąć na wersji sprzed dwóch lat, bo nic o tym nie przypomina.

Trzecia to nazwa wdrożenia zamiast nazwy modelu, opisana wyżej i odpowiedzialna za większość błędów przy pierwszym uruchomieniu.

Czwarta to uwierzytelnianie. Klucz działa i jest najprostszy, natomiast właściwym rozwiązaniem w chmurze jest tożsamość przypisana do usługi, która eliminuje przechowywanie sekretu gdziekolwiek.

Warto przy tej okazji sprawdzić, czy biblioteka klienta, której używasz, obsługuje tę drogę wprost. Oficjalne biblioteki mają osobną klasę klienta i przełączenie sprowadza się do jej podmiany. Biblioteki pośredniczące bywają tu mniej dopracowane i część z nich myli nazwę modelu z nazwą wdrożenia, co daje błędy trudne do zdiagnozowania z poziomu Twojego kodu.

Wersjonowanie modeli i wycofania

Ta część jest specyficzna dla tej drogi dostępu i przy dłużej żyjącym projekcie ma większe znaczenie niż wszystko powyżej.

Wdrożenie wskazuje na konkretną wersję modelu, a wersje są wycofywane według ogłaszanego harmonogramu. Otrzymujesz powiadomienie z wyprzedzeniem, natomiast to Ty musisz zareagować, bo wdrożenie oparte na wycofanej wersji przestaje działać.

Dostępna jest opcja automatycznej aktualizacji do najnowszej wersji, i to jest wybór, który warto podjąć świadomie. Automatyczna aktualizacja chroni przed nagłym zatrzymaniem usługi i wprowadza inne ryzyko: wektory policzone nową wersją modelu mogą nie być w pełni porównywalne ze starymi, a zmiana dzieje się bez Twojego udziału.

Rozsądny układ wygląda tak. Wdrożenie obsługujące zapytania użytkowników trzymaj na wersji przypiętej i aktualizuj świadomie, razem z przeliczeniem indeksu albo po sprawdzeniu, że różnica jest pomijalna. Wdrożenie testowe ustaw na aktualizację automatyczną, żeby zawczasu zobaczyć, co przynosi nowa wersja.

Zapisz też datę i wersję modelu przy każdym przeliczeniu indeksu. To jedna linijka w dokumentacji projektu, która przy pytaniu „dlaczego wyszukiwanie działa gorzej niż w marcu" oszczędza dzień dochodzenia.

Azure kontra alternatywy

Pierwszy wiersz wygrywa wtedy, gdy organizacja pracuje już w tej chmurze i ma wymogi dotyczące regionu albo sieci. Wtedy dodanie modeli do istniejącej umowy jest wyraźnie prostsze niż wprowadzanie nowego dostawcy przez dział zakupów i dział prawny.

Trzeci wiersz warto rozważyć uczciwie, bo bywa pomijany przy takich decyzjach. Jeśli wymóg brzmi „dane nie opuszczają naszej infrastruktury", to model uruchomiony u siebie spełnia go w sposób, którego żadna chmura nie zapewni, niezależnie od tego, co mówią umowy i certyfikaty.

Typowe błędy

Pierwszy to przekazywanie nazwy modelu zamiast nazwy wdrożenia. Kod przeniesiony wprost z dostępu bezpośredniego zwraca błąd, którego treść nie wskazuje przyczyny.

Drugi to jedno wdrożenie do wszystkiego. Nocne indeksowanie archiwum zabiera wtedy przepustowość użytkownikom pytającym w ciągu dnia.

Trzeci to zakładanie dostępności modelu w wybranym regionie. Nie każdy model jest dostępny wszędzie, a przeniesienie zasobu później oznacza przeliczenie indeksu.

Czwarty to planowanie trybu wsadowego. Przy tej drodze dostępu nie jest dostępny, więc jednorazowe indeksowanie kosztuje co najmniej dwa razy więcej, niż wynikałoby z cennika dostępu bezpośredniego.

Piąty to trzymanie klucza w kodzie, gdy dostępna jest tożsamość przypisana do usługi. Mechanizm uprawnień chmury rozwiązuje ten problem lepiej niż jakakolwiek rotacja kluczy.

Szósty to brak zapisu, które wdrożenie i która wersja modelu wytworzyły wektory. Nazwa wdrożenia nie mówi tego sama z siebie, a po pół roku nikt tego nie odtworzy bez zgadywania.

FAQ

Czym różni się od dostępu bezpośredniego?

Modele są te same, więc wyniki się nie różnią. Różni się wszystko wokół: wybór regionu przetwarzania, kontrola dostępu przez mechanizm uprawnień chmury, możliwość zamknięcia ruchu w sieci prywatnej oraz rozliczenie w ramach istniejącej umowy z dostawcą. Różni się też stawka: wdrożenie globalne kosztuje tyle co dostęp bezpośredni, a ograniczone do strefy danych albo do jednego regionu wyraźnie więcej.

Dlaczego kod z dostępu bezpośredniego nie działa?

Najczęściej przez to, że w wywołaniu podaje się nazwę wdrożenia, a nie nazwę modelu. Wdrożenie tworzysz sam i nadajesz mu dowolną nazwę, więc ta sama aplikacja przełączona na tę drogę wymaga zmiany tej wartości oraz adresu zasobu i wersji interfejsu.

Czy tryb wsadowy jest dostępny?

Nie, i to jest istotna różnica przy planowaniu kosztów. Zniżka o połowę za wynik dostarczany z opóźnieniem obejmuje dostęp bezpośredni, więc jednorazowe zaindeksowanie dużego archiwum wypada tu co najmniej dwukrotnie drożej.

Jak zaplanować limity przy indeksowaniu?

Limit przydzielany jest w tokenach na minutę osobno dla regionu, modelu i rodzaju wdrożenia, a z niego wynika limit liczby żądań, w proporcji zależnej od modelu. Przy dużym archiwum warto utworzyć osobne wdrożenie na indeksowanie, wysyłać fragmenty partiami i obsłużyć odpowiedzi o przekroczeniu limitu opóźnieniem narastającym.

Gdzie trzymać policzone wektory?

W bazie wektorowej, przy czym warto sprawdzić, czy ona również spełnia Twoje wymogi dotyczące regionu. Dostępna jest usługa wyszukiwania w tej samej chmurze, a przy mniejszych zbiorach wystarczy rozwiązanie opisane w tekście o pgvectorze albo Qdrancie uruchomionym we własnej infrastrukturze.

Dokumentacja stoi na stronie Microsoftu, a zarządzanie limitami opisuje osobna strona.