Porównanie serwerów wnioskowania: rozwiązania open source dla modeli sztucznej inteligencji

Jakie funkcje pełni serwer wnioskowania

Serwer wnioskowania udostępnia już wytrenowany model sztucznej inteligencji do obsługi zapytań. Aplikacja wysyła dane wejściowe do API, serwer przekazuje je do środowiska uruchomieniowego modelu, które przetwarza je przy użyciu załadowanych wag modelu. Wynik wraca przez serwer do aplikacji. W przypadku modelu językowego może to być odpowiedź tekstowa; w zależności od interfejsu można ją również wyświetlać stopniowo jako strumień tokenów.

Serwer, środowisko uruchomieniowe i model to odrębne elementy. Wagi zawierają wyuczone parametry; środowisko uruchomieniowe wykonuje obliczenia na dostępnym sprzęcie. Serwer natomiast organizuje dostęp do zapytań i ich przekazywanie. Zmiana serwera nie powoduje zatem automatycznie wymiany modelu, ale może wymagać innego formatu lub innego środowiska uruchomieniowego.

Do zarządzania użytkownikami i logiki biznesowej zazwyczaj potrzebna jest dodatkowa warstwa aplikacji. To właśnie ona decyduje na przykład o tym, którzy użytkownicy mogą wysyłać zapytania, jakie dane trafiają do modelu oraz w jaki sposób jego odpowiedź jest włączana do przepływu pracy. Samo dostępne API modelu nie odzwierciedla tych reguł; również zabezpieczenia dostępu i rejestrowanie działań muszą zostać zaplanowane jako część całego systemu.

Serwer LLM przeznaczony do generowania tekstu nie jest zresztą automatycznie platformą do klasyfikacji obrazów ani innych typów modeli. Wymaga to obsługi odpowiedniej architektury modelu oraz odpowiedniego środowiska uruchomieniowego. Triton stosuje szersze podejście: przekazuje zapytania do backendów za pośrednictwem harmonogramów dostosowanych do poszczególnych modeli. To, czy konkretny model może tam zostać uruchomiony, zależy jednak od odpowiedniego backendu.

Sprawdź model, sprzęt i uprawnienia

Rozpocznij wybór od zadania i konkretnego Aktualizacja modelu: Model czatu, model osadzania oraz klasyfikator obrazów stawiają różne wymagania. Należy również zanotować format wag i sprawdzić, czy wybrany czas działania obsługuje dokładnie tę architekturę i wersję. Sama nazwa modelu nie wystarczy, by założyć kompatybilność lub spójność wyników.

• Należy określić zadanie, wersję modelu oraz dostępny format wagowy.
• Sprawdź procesor (CPU) lub kartę graficzną (GPU), dostępną pamięć, sterowniki oraz wymagany backend.
• Należy osobno ustalić prawa użytkowania serwerów, wagi modeli i dodatkowych komponentów.
• Należy udokumentować przewidywaną długość zapytań, równoległość oraz wymagania dotyczące zabezpieczeń dostępu.

Wybór sprzętu to coś więcej niż tylko kwestia tego, czy dysponujemy procesorem graficznym (GPU). Wagi muszą zmieścić się w dostępnej pamięci wraz z kodem źródłowym i dodatkowymi danymi; również sterowniki i backend muszą być dostosowane do platformy. Dokumentacja backendu Triton wskazuje, że nie każdy backend jest obsługiwany na każdej platformie. Dlatego należy sprawdzić kombinację wersji serwera, modelu, backendu i sprzętu, zamiast wyciągać wnioski na temat obsługi na podstawie nazwy produktu.

Format może również ograniczać wybór: zgodnie z dokumentacją projektu plik llama.cpp wymaga modeli w formacie Format GGUF. W przypadku innych formatów projekt opisuje proces konwersji; nie oznacza to jednak, że każda architektura lub każdy wariant modelu będzie działać bez zmian. Kod źródłowy znajduje się w gałęzi rozwojowej. Przed wdrożeniem należy zatem porównać te informacje z wybraną wersją.

Serwer typu open source nie przenosi swojej licencji na wagi modeli. Należy osobno sprawdzić w obu przypadkach, czy planowane wykorzystanie wewnętrzne lub komercyjne jest dozwolone oraz jakie warunki mają zastosowanie. Sam fakt, że wagi można pobrać, nie oznacza jeszcze zezwolenia na każde wykorzystanie lub udostępnianie.

W jaki sposób zapytania do modeli LLM zużywają zasoby

W przypadku zapytania tekstowego model najpierw przetwarza dane wejściowe. Ta faza nazywa się Wstępne wypełnienie. Następnie, na etapie dekodowania, generuje odpowiedź token po tokenie. Krótka prośba i długa odpowiedź powodują, że inna część pracy przypada na etapie generowania niż w przypadku długiego fragmentu dokumentu z krótką odpowiedzią. Dlatego też oba te przypadki powinny zostać uwzględnione w planowaniu wydajności.

Podczas generowania środowisko uruchomieniowe przechowuje dane pośrednie w Pamięć podręczna KV w celu umożliwienia wykorzystania już przetworzonego kontekstu w kolejnych krokach. To zapotrzebowanie na pamięć sumuje się z wagami modelu i zmienia się w zależności od długości sekwencji oraz liczby jednocześnie przetwarzanych zapytań. Fakt, że sam model mieści się w pamięci, nie oznacza jeszcze, że zmieści się w niej również przewidywane obciążenie.

Metoda Continuous Batching elastycznie grupuje bieżące żądania generowania, zamiast czekać na jeden stały, wspólny zestaw. PagedAttention organizuje pamięć bufora KV w blokach. Obie metody zostały opisane w odniesieniu do vLLM i mogą poprawić wykorzystanie zasobów. To, w jakim stopniu są one pomocne, zależy jednak między innymi od wielkości zapytań, równoległości i sprzętu; nie można na tej podstawie wywnioskować, że stanowią one korzyść dla każdego obciążenia.

Triton natomiast opisuje ogólną architekturę serwera: harmonogram oparty na modelu przyjmuje zapytania i przekazuje je do odpowiedniego backendu. Dla danego modelu można skonfigurować dynamiczne grupowanie zadań. Nie oznacza to jednak, że każdy backend traktuje żądania LLM w ten sam sposób wewnętrznie ani że stosuje te same metody przechowywania danych co vLLM. Dlatego też dla porównania istotna jest konkretna kombinacja backendu i modelu.

W przypadku wewnętrznego serwisu czatu nie wystarczy zatem podać tylko jedną liczbę tokenów na sekundę. Oprócz szybkości generowania tokenów na komfort użytkowania wpływają również czas do pojawienia się pierwszego tokenu oraz czasy oczekiwania w przypadku równoczesnych żądań. Porównaj rozwiązania, stosując reprezentatywne długości danych wejściowych i wyjściowych oraz ten sam stopień równoległości, zanim podejmiesz decyzję dotyczącą sprzętu.

Sklasyfikować cztery rozwiązania, zapisać SGLang jako alternatywę

Poniższe zestawienie klasyfikuje vLLM, llama.cpp, Triton i TGI na podstawie ich udokumentowanych podejść. Nie stanowi ono porównania funkcji ani wydajności w odniesieniu do poszczególnych wersji. SGLang pozostaje nieocenioną alternatywą: Hugging Face zaleca go obok vLLM jako następcę TGI, jednak nie pozwala to na określenie formatów modeli, interfejsów ani obsługi sprzętowej konkretnej wersji SGLang.

Baza źródłowa zawiera strony dokumentacji, które mogą ulec zmianie, a w przypadku llama.cpp – gałąź rozwojową. Oznacza to, że nie ma potwierdzonych wyników zakończonych testów dla vLLM 0.10.2, llama.cpp b6000, Triton 25.10 ani TGI 3.3.7. Dlatego też te przyporządkowania wersji nie są wykorzystywane jako podstawa do porównań. Przed wdrożeniem należy sprawdzić wymagane właściwości dla faktycznie wybranej wersji serwera i rewizji modelu.

Rzeczywisty Koszty operacyjne zależy między innymi od udostępniania modeli, zabezpieczeń dostępu i monitorowania. Na podstawie tabeli nie można dokonać bezpośredniego porównania nakładów: lokalna instalacja pojedyncza i platforma z wieloma backendami mają różne wymagania. Dlatego najpierw sprawdź, jakie zadania instalacja faktycznie musi spełniać.

Hugging Face wprowadza TGI w Tryb konserwacji i wymienia vLLM oraz SGLang jako alternatywy. Nie ma zatem konieczności natychmiastowej wymiany istniejącej instalacji. W przypadku nowych projektów należy jednak uwzględnić w planowaniu ograniczony zakres dalszego rozwoju; przed migracją należy oddzielnie porównać zachowanie interfejsów API oraz jakość modeli.

Triton i vLLM zasadniczo nie wykluczają się wzajemnie: Triton może korzystać z backendu vLLM. Niemniej jednak należy sprawdzić, czy dany model będzie działał z wybranymi wersjami i na danej platformie w tej konkretnej konfiguracji. Ogólna architektura Triton sama w sobie nie gwarantuje obsługi każdego backendu na każdej platformie.

Przygotowanie lokalnego prototypu

Aby stworzyć lokalny prototyp, najpierw określ zadanie i kilka typowych danych wejściowych. Następnie wybierz konkretną wersję modelu, która wydaje się odpowiednia do tego celu, i sprawdź warunki jej użytkowania. Sama licencja serwera nie określa, czy możesz pobrać, modyfikować lub wykorzystywać wagi modelu do zamierzonego celu.

Plik llama.cpp wykorzystuje format GGUF. Poszukaj odpowiedniej wersji GGUF lub sprawdź, czy model wyjściowy można przekonwertować przy użyciu udokumentowanych narzędzi. Dokumentacja projektu opisuje takie konwersje w gałęzi rozwojowej; nie stanowi ona jednak dowodu na to, że każda starsza wersja obsługuje każdą architekturę lub opcję konwersji.

Przed pobraniem sprawdź, czy wybrana wersja jest obsługiwana przez Twój procesor lub kartę graficzną z przewidzianym backendem oraz czy dostępna jest wystarczająca ilość pamięci na wagi i czas działania. Wersja kwantyzowana może zmniejszyć zapotrzebowanie na pamięć dla wag. Porównaj jednak uzyskane wyniki z własnymi wymaganiami jakościowymi, zamiast zakładać, że mniejszy plik zapewni niezmienione wyniki.

Wybierz konkretną kompilację dla prototypu i porównaj instalację oraz opcje serwera z jej dokumentacją. W przypadku wspomnianej wcześniej kompilacji b6000 nie odnotowano tutaj żadnej weryfikacji związanej z wersją; dlatego nie jest ona zalecana jako sprawdzony punkt wyjścia. Dostępna dokumentacja modelu w gałęzi rozwojowej nie zastępuje ani dokumentacji serwera wybranego zestawu, ani jego testu zgodności.

Najpierw uruchom usługę tylko lokalnie i wyślij kilka reprezentatywnych zapytań. Sprawdź przy tym nie tylko, czy pojawia się odpowiedź, ale także, czy format danych wejściowych, model i ustawienia generowania są zgodne z planowaną aplikacją. Pomyślne wykonanie pojedynczego wywołania nie świadczy ani o zdolności do obsługi większego obciążenia, ani o jakości wszystkich odpowiedzi.

Zapisz osobno trzy wyniki: jakość merytoryczną na podstawie przypadków testowych, odczuwalny czas odpowiedzi oraz nakład pracy związany z pobraniem, konwersją i udostępnieniem. W ten sposób można na przykład stwierdzić, czy model skonfigurowany w pośpiechu jest nieodpowiedni pod względem merytorycznym. Do oddzielnego zarządzania hostem z systemem Linux służy Przegląd narzędzia 1Panel do zarządzania serwerami dodatkowy kontekst; panel serwera nie zastępuje sprawdzenia czasu działania modelu.

Planowanie obciążenia i zapotrzebowania na pamięć

W przypadku wewnętrznego serwisu czatowego zapytania często znacznie się od siebie różnią: krótkie pytanie z zwięzłą odpowiedzią wymaga innych zasobów niż długi fragment dokumentu z obszerną odpowiedzią. Dlatego należy uwzględnić typowe i większe długości danych wejściowych i wyjściowych, a także przewidywaną liczbę jednoczesnych użytkowników. Pojedyncze pomyślne wywołanie nie oddaje w wystarczającym stopniu sytuacji pod obciążeniem.

Zapotrzebowanie na pamięć nie wynika wyłącznie z rozmiarów modeli. Czas działania i wartości pośrednie również zajmują miejsce; ponadto w przypadku równoległych zapytań do modeli LLM rośnie zapotrzebowanie na Pamięć podręczna KV. Dłuższe konteksty i większa liczba jednocześnie przetwarzanych zapytań mogą zatem doprowadzić konfigurację do granic jej możliwości, mimo że same wagi mieszczą się w dostępnej pamięci.

Continuous Batching i PagedAttention to udokumentowane w vLLM podejścia do zarządzania bieżącymi zapytaniami oraz pamięcią podręczną. Nie zwalniają one jednak użytkownika z konieczności planowania wydajności: to, jaka kombinacja równoległości i długości kontekstu jest praktyczna, zależy od modelu, sprzętu i wybranej konfiguracji. Nie można na tej podstawie wywnioskować ogólnego wzrostu wydajności dla każdego obciążenia.

W przygotowaniach pomocne jest proste obliczenie ilościowe: 100 hipotetycznych wniosków, z których każdy obejmuje 200 tokenów wypłaty, daje łącznie 20 000 tokenów wypłaty. To jest brak pomiaru przepustowości. Bez określenia przedziału czasowego, długości danych wejściowych, równoległości i innych parametrów operacyjnych nie można na tej podstawie wyciągnąć żadnych wniosków ani co do liczby tokenów na sekundę, ani co do kosztów.

W celu późniejszego porównania należy utworzyć matrycę testową zawierającą model i wersję, kwantyzację, wersję serwera, sprzęt oraz dostępną pamięć. W kontrolowany sposób zmieniaj długość danych wejściowych i wyjściowych oraz stopień równoległości. Rejestruj czas do pojawienia się pierwszego tokenu, szybkość generowania wyników oraz wskaźnik błędów; osobno oceniaj jakość odpowiedzi na podstawie tych samych przypadków testowych. Parametry generowania i szablon czatu również należy uwzględnić w protokole, aby różnice były zrozumiałe.

Bezpieczne i monitorowane korzystanie z API

Dostępny Serwer wnioskowania nie jest to jeszcze usługa bezpieczna. Na początek ogranicz dostęp do sieci wyłącznie do systemów, które muszą wysyłać żądania lub administrować serwerem. W przypadku dostępu zewnętrznego przed interfejsem API należy zainstalować mechanizm ochrony dostępu; sprawdź przy tym wszystkie dostępne punkty końcowe, a nie tylko ścieżkę służącą do generowania tekstu.

Ostrzeżenie: Zgodnie z dokumentacją opcja klucza API w vLLM nie chroni wszystkich punktów końcowych. Ustawiony klucz nie zastępuje zatem ani odłączenia od sieci, ani wcześniejszej kontroli dostępu, która uwzględnia również interfejsy administracyjne i inne dostępne interfejsy. Przed udostępnieniem usługi sprawdź reguły z poszczególnych sieci.

Wpisy i odpowiedzi mogą zawierać informacje poufne. Dlatego należy z góry określić, jakie dane będą w ogóle rejestrowane, kto będzie miał do nich dostęp oraz kiedy zostaną usunięte. Do celów diagnostyki często wystarczają dane techniczne, takie jak czas, wersja modelu, rodzaj błędu i czas trwania zapytania; pełną treść należy rejestrować tylko w uzasadnionych przypadkach.

Die Obserwowalność należy osobno rejestrować czas oczekiwania, czas do otrzymania pierwszego tokenu, szybkość wydawania tokenów oraz błędy. Jeśli na przykład czas oczekiwania wzrasta przy równoczesnych żądaniach, podczas gdy poszczególne odpowiedzi po rozpoczęciu przebiegają szybko, wskazuje to na inne wąskie gardło niż powolne wydawanie tokenów. Należy przeanalizować te wskaźniki wraz z wielkością żądań i równoległością.

W celu obsługi hostów bazowych narzędzia administracyjne mogą grupować zadania i zakresy odpowiedzialności. Aby umożliwić oddzielny wybór tego poziomu zarządzania, Porównanie ISPConfig i Froxlor dodatkowy kontekst. Wybór panelu serwerowego stanowi odrębną decyzję dotyczącą infrastruktury; taki panel nie zastępuje ani zabezpieczenia interfejsu API modelu, ani monitorowania usługi wnioskowania.

Określenie źródła błędu i migracja TGI

Jeśli model się nie uruchamia, najpierw sprawdź wersję modelu i format pod kątem wybranego środowiska uruchomieniowego. W przypadku pliku llama.cpp wymaganym formatem jest GGUF; sama konwersja nie gwarantuje jednak, że konkretna architektura i zadanie będą działać. Następnie sprawdź, czy wybrany backend i kombinacja sprzętowa są obsługiwane oraz czy dostępna jest wystarczająca ilość pamięci.

Jeśli serwer uruchamia się, ale generuje nieoczekiwane odpowiedzi na czacie, sprawdź to Szablon czatu oraz przekazane parametry generowania. Interfejs zgodny ze standardem OpenAI nie oznacza, że każdy parametr jest realizowany w identyczny sposób: dokumentacja vLLM wymienia również parametry, które nie są obsługiwane lub są ignorowane. Należy zatem porównać faktycznie zastosowane ustawienia, a nie tylko formę wywołania API.

W przypadku istniejącej usługi TGI migracja rozpoczyna się od analizy aktualnego stanu: obejmuje to przegląd modelu, wykorzystywane wywołania API, ustawienia próbkowania oraz wymagania dotyczące jakości odpowiedzi. Hugging Face prowadzi TGI w trybie konserwacyjnym i jako alternatywy wymienia między innymi vLLM oraz SGLang. Sprawia to, że warto rozważyć zmianę, nie oznacza to jednak natychmiastowej awarii istniejących instalacji.

Zbuduj Instalacja docelowa Przeprowadź testy osobno i porównaj obie usługi, stosując te same reprezentatywne dane wejściowe, długości danych wyjściowych oraz warunki obciążenia. Oprócz jakości odpowiedzi i błędów sprawdź również, czy klienci radzą sobie z nowym interfejsem i jego parametrami. Przekieruj ruch dopiero wtedy, gdy wyniki będą akceptowalne dla przewidzianego zastosowania i gdy przygotowana zostanie ścieżka powrotna.

W instrukcji Hugging Faces dotyczącej punktów końcowych wnioskowania również zaleca się utworzenie nowego punktu końcowego i przeprowadzenie wywołań testowych przed przełączeniem. Jest to pomocny model postępowania przy planowaniu, ale nie stanowi uniwersalnej instrukcji krok po kroku dla instalacji obsługiwanych we własnym zakresie: organizacja sieci, wdrożenia i sterowania ruchem może się tam różnić.

Wybór odpowiedniej architektury

Dla lokalny prototyp Plik llama.cpp stanowi oczywisty punkt kontrolny, jeśli dostępny jest odpowiedni model GGUF i odpowiednia obsługa sprzętowa. Nie oznacza to jednak rekomendacji konkretnej kompilacji. Decydujące znaczenie ma nie tylko to, czy serwer się uruchamia: należy również porównać jakość pożądanego zadania, czas odpowiedzi oraz nakład związany z wagami modelu. Należy sprawdzić obsługę modelu i zaplecza dla konkretnej kombinacji.

W przypadku wewnętrznej usługi czatu vLLM może być brany pod uwagę jako kandydat do testów: w dokumentacji opisano interfejs czatu zgodny z OpenAI wraz z wymaganym szablonem czatu. Nie ma jednak dowodów na przeprowadzenie testów dla wersji 0.10.2. SGLang pozostaje tutaj nieocenioną alternatywą wymienioną w dokumentacji TGI; bez technicznego testu wersji nie można go traktować jako równoważnego rozwiązania.

Platforma dla modeli obrazowych i językowych stawia inne wymagania niż pojedynczy punkt końcowy czatu. Triton stanowi punkt kontrolny ze względu na swoje harmonogramy i zaplecza związane z modelami, choć wersja 25.10 nie została tu jeszcze zweryfikowana. Ta architektura sprawia, że Wsparcie techniczne po stronie serwera Jeśli chodzi o kluczową kwestię szczegółową: nie każdy backend jest obsługiwany na każdej platformie, a każdy wymagany model należy sprawdzić w konkretnej kombinacji.

Przy podejmowaniu decyzji należy uwzględnić wersję modelu, wersję serwera, sprzęt, zaplecze oraz prawa użytkowania. Następnie należy porównać jakość, czasy odpowiedzi przy przewidywanym obciążeniu oraz nakład pracy związany z zabezpieczeniem, aktualizacjami i wykrywaniem błędów. Rozwiązanie, które wystarcza do lokalnych testów, może wymagać dodatkowej infrastruktury w przypadku większej liczby użytkowników lub typów modeli; ogólny ranking nie uwzględniałby tych różnic.