Własny model językowy na GPU w chmurze: vLLM i serverless

Własny model językowy uruchomiony na GPU w chmurze ma sens wtedy, gdy dane nie powinny trafiać do zewnętrznego API, gdy chcesz kontrolować wersję modelu albo gdy przewidywalny koszt jest ważniejszy niż wygoda. W pozostałych przypadkach API dużego dostawcy zwykle wychodzi prościej. Poniżej opisuję, jak wygląda wariant serverless na przykładzie vLLM i otwartego modelu GPT-OSS, jakie parametry decydują o tym, czy użytkownik poczeka sekundę, czy minutę, i na jaką pułapkę łatwo trafić przy streamingu odpowiedzi.

Piszę o tym z perspektywy CTO, który uruchamiał taki zestaw w praktyce. Nie będzie tu benchmarków, tylko decyzje, które trzeba podjąć, zanim model trafi do użytkowników.

Kiedy własny model językowy zamiast API

Własny model wybiera się z powodów biznesowych, a nie dlatego, że jest modny. Najczęściej chodzi o jeden z trzech.

• Dane. Treść zapytań i dokumentów zostaje w infrastrukturze, którą kontrolujesz, w wybranym centrum danych. To bywa warunek klienta, działu prawnego albo inspektora ochrony danych.
• Przewidywalne koszty. Płacisz za czas pracy GPU, a nie za każdy token. Przy stałym, dużym ruchu łatwiej to zaplanować w budżecie.
• Kontrola wersji. Model nie zmienia się bez Twojej decyzji. Dostawca API może wycofać wersję albo zmienić jej zachowanie, a Ty musisz wtedy testować wszystko od nowa.

Ceną jest odpowiedzialność za całą warstwę techniczną: wybór modelu, serwer, aktualizacje, monitoring i jakość odpowiedzi. Jeśli żaden z tych powodów Cię nie dotyczy, API będzie zwykle rozsądniejszym wyborem na start, a do własnego modelu można wrócić, gdy pojawi się konkretny wymóg. Rachunek warto zrobić uczciwie, z kosztem pracy zespołu, tak jak opisywałem przy temacie kosztu wdrożenia AI w firmie.

Jak działa serverless GPU i na co uważać

Serverless GPU oznacza, że płacisz za czas, w którym karta faktycznie obsługuje zapytania, a gdy ruchu nie ma, workery się wyłączają. vLLM to serwer, który ładuje model na GPU i wystawia go przez API zgodne z popularnym formatem zapytań, więc aplikacja nie musi wiedzieć, czy rozmawia z chmurą dostawcy, czy z Twoim modelem.

O tym, jak to działa w praktyce, decydują cztery ustawienia:

1. Zimny start. Gdy żaden worker nie pracuje, pierwsze zapytanie musi poczekać, aż kontener wystartuje i załaduje model do pamięci GPU. Przy dużym modelu użytkownik odczuje to wyraźnie. Pomaga trzymanie modelu w obrazie albo na szybkim wolumenie zamiast pobierania go przy każdym starcie.
2. Idle timeout. To czas, po którym bezczynny worker się wyłącza. Krótki oszczędza pieniądze, ale zwiększa liczbę zimnych startów. Dobiera się go do rytmu ruchu: inaczej dla narzędzia używanego w godzinach pracy, inaczej dla czatu dostępnego całą dobę.
3. Limity workerów. Minimalna liczba workerów różna od zera eliminuje zimny start w godzinach szczytu, maksymalna chroni budżet przed nagłym skokiem ruchu albo pętlą w kodzie.
4. Lokalizacja centrum danych. Jeśli przez model przechodzą dane osobowe, region ma znaczenie prawne. Przekazanie danych poza Europejski Obszar Gospodarczy podlega regułom z rozdziału V RODO o przekazywaniu danych, więc region wybiera się razem z umową powierzenia, a nie według najniższej ceny.

Pułapka: tryb rozumowania psuje streaming

Modele z trybem rozumowania, takie jak GPT-OSS, najpierw generują tok rozumowania, a dopiero potem właściwą odpowiedź. Jeśli ten tryb jest włączony domyślnie, a aplikacja tego nie obsługuje, streaming przestaje działać tak, jak oczekuje użytkownik. Widzi długą ciszę, bo pierwsze fragmenty to rozumowanie, którego interfejs nie pokazuje, albo widzi tekst, który nie jest odpowiedzią.

Rozwiązania są dwa i warto wybrać jedno świadomie. Pierwsze: ustawić niski poziom rozumowania albo go wyłączyć dla zadań, które go nie potrzebują, na przykład dla krótkich odpowiedzi w czacie. Drugie: obsłużyć w aplikacji osobny kanał z rozumowaniem i pokazywać użytkownikowi wskaźnik, że model pracuje. W obu przypadkach trzeba to sprawdzić na serwerze testowym przed startem, bo problem nie wychodzi w testach, które czytają odpowiedź dopiero w całości.

Lista kontrolna przed produkcją

Zanim własny model językowy obsłuży pierwszych użytkowników, przejdź przez tę listę:

• Model i wersja zapisane w konfiguracji, aktualizacja tylko po testach.
• Zmierzony czas zimnego startu i świadomie dobrany idle timeout.
• Minimalna i maksymalna liczba workerów ustawione do rytmu ruchu i budżetu.
• Region centrum danych zgodny z umową powierzenia i polityką ochrony danych.
• Tryb rozumowania ustawiony jawnie, streaming sprawdzony w prawdziwym interfejsie.
• Limity długości zapytań i odpowiedzi, żeby jedno zapytanie nie zajęło GPU na długo.
• Logi bez treści danych osobowych, alerty o błędach i kosztach.
• Zestaw pytań testowych, uruchamiany po każdej zmianie modelu lub ustawień.
• Plan awaryjny: co się dzieje, gdy model nie odpowiada.

Zestaw pytań testowych to ta sama praktyka, którą opisywałem przy wdrożeniu asystenta na dokumentach. Przy własnym modelu jest jeszcze ważniejszy, bo nikt poza Tobą nie sprawdzi, czy nowa wersja odpowiada równie dobrze jak poprzednia.

Obowiązki, które zostają po stronie firmy

Własny model nie zdejmuje z firmy obowiązków wobec użytkowników. Trzeba wiedzieć, do czego model jest używany, kto odpowiada za jego wyniki i jak użytkownik dowiaduje się, że rozmawia z AI. Przegląd tych obowiązków opisałem w tekście o tym, jakie obowiązki nakłada AI Act.

Jeśli rozważasz własny model językowy zamiast API, zacznij od jednego zastosowania, zmierz zimny start i koszt na prawdziwym ruchu, a dopiero potem przenoś kolejne funkcje. Jeśli chcesz przejść przez te decyzje z kimś, kto je już podejmował, przeczytaj jak wygląda współpraca ze mną.