Zacznij od aplikacji i sposobu jej utrzymania, a dopiero potem wybierz dystrybucję Linuksa. System ma współpracować z wybranym programem, sterownikiem GPU i narzędziami zespołu. Sama nazwa Ubuntu, Debian czy Rocky Linux nie przesądza o szybkości odpowiedzi modelu.
Nasze opublikowane pomiary llama.cpp wykonaliśmy na Rocky Linux 10.2. To potwierdzenie działania opisanego zestawu, nie porównanie wydajności trzech dystrybucji. Wspólna metodyka testów LLM wyjaśnia, jakie wersje i warunki trzeba zachować, aby uczciwie zestawiać wyniki.
Najpierw ustal, co właściwie chcesz uruchomić
„Serwer AI” może oznaczać prosty program udostępniający jeden model albo większą aplikację z wyszukiwaniem dokumentów, kontami użytkowników i bazą danych. Lista składników określa wymagania systemu. Przed instalacją sprawdź dokumentację konkretnej aplikacji: obsługiwane wydania, sposób dostępu do GPU i zalecaną ścieżkę uruchomienia.
Jeżeli celem jest pierwszy działający model, wygodnym początkiem może być gotowy program wraz z jego bibliotekami. Taką drogę pokazuje poradnik własnego API z Qwen3 i llama.cpp. Kompilacja całego środowiska od podstaw nie jest konieczna tylko dlatego, że używasz GPU.
Jeśli zespół ma już aplikację w kontenerze, czyli pakiecie z programem i jego zależnościami, wybór systemu hosta nadal wymaga uwagi. Kontener porządkuje środowisko programu, ale nie zastępuje sterownika karty ani prawidłowego udostępnienia GPU. To dwie różne części instalacji.
Kiedy rozważyć Ubuntu, Debiana lub Rocky Linux?
- Ubuntu LTS: gdy zespół zna Ubuntu lub wybrana aplikacja opisuje właśnie tę drogę instalacji. Oznaczenie LTS dotyczy dłuższego utrzymania wydania, nie automatycznej zgodności dowolnego sterownika i programu.
- Debian: gdy chcesz zachować sposób administracji używany na pozostałych serwerach. Znajomość aktualizacji i konfiguracji usług może ułatwić utrzymanie, ale nadal trzeba potwierdzić obsługę konkretnego wydania przez stos GPU.
- Rocky Linux: gdy korzystasz z narzędzi i procedur rodziny Enterprise Linux albo chcesz odtworzyć opisane tu środowisko testowe. Działanie naszego zestawu nie zastępuje sprawdzenia wymagań innej aplikacji.
Przykładowo firma utrzymująca już usługi na Debianie nie musi zmieniać całego sposobu pracy tylko dlatego, że dodaje GPU. Powinna najpierw sprawdzić, czy jej wybrany program i sterownik mają zgodną ścieżkę instalacji. Z kolei zespół zaczynający od instrukcji aplikacji przygotowanej dla Ubuntu może ograniczyć liczbę niewiadomych, wybierając dokładnie opisane środowisko. To przykłady decyzji organizacyjnych, nie zmierzone przewagi wydajności.
Sterownik to nie to samo co biblioteki aplikacji
Sterownik pozwala systemowi obsługiwać kartę. Program potrzebuje także bibliotek, z których korzysta podczas pracy. Osobnym elementem są narzędzia do budowania programu ze źródeł, często określane jako Toolkit. Gotowa aplikacja nie zawsze wymaga całego tego zestawu.
Dlatego komunikat o brakującej bibliotece nie oznacza automatycznie konieczności wymiany systemu lub sterownika. Najpierw ustal, którego składnika brakuje i jakie wersje przewiduje instrukcja programu. W szczegółach rozdzielamy nasz działający zestaw od oficjalnych list zgodności, aby nie rozszerzać jednego udanego uruchomienia na każdą kombinację.
Jak odebrać gotowe środowisko przed wdrożeniem aplikacji?
Przejdź cały krótki przepływ: system widzi właściwą kartę, program ładuje wybrany model, zapytanie trafia do niego i pojawia się ukończona odpowiedź. Sprawdź, czy obliczenia rzeczywiście korzystają z GPU, a nie jedynie to, że proces się uruchomił. Następnie zweryfikuj ponowne uruchomienie usługi i dostęp do modelu z lokalnego dysku.
Zapisz wersje systemu, sterownika, aplikacji i modelu oraz parametry uruchomienia. Taki opis pozwala wrócić do działającej konfiguracji i porównać zachowanie po aktualizacji. Jeśli jednocześnie zmienisz system, model i ustawienia, szybsza odpowiedź nie wskaże, który z tych elementów pomógł.
Na końcu dołącz pozostałe części planowanej usługi: uwierzytelnianie, aplikację kliencką i ewentualne wyszukiwanie dokumentów. Działający model jest ważnym etapem, lecz nie końcem przygotowania kompletnej aplikacji. Przy publicznym dostępie trzeba osobno zaplanować uprawnienia i sposób ochrony usługi.
Wniosek: wybierz środowisko zgodne z aplikacją i znane osobom, które będą je utrzymywać. Przypnij działający zestaw, sprawdź rzeczywisty przepływ i oceniaj szybkość na swoich zadaniach. Nie ma podstaw, by z naszych pomiarów Rocky wyprowadzać podium Ubuntu–Debian–Rocky.
Sprawdź ofertę serwera lub napisz, jaki model i środowisko chcesz uruchomić. Podstawowe pojęcia wyjaśnia słownik AI i GPU.
Szczegóły techniczne
Najpierw wybierz sposób uruchamiania modelu
Masz trzy praktyczne drogi:
- Gotowa aplikacja z bibliotekami. Wybierasz konkretny build, sprawdzasz jego wymagania i uruchamiasz go na zgodnym sterowniku. Tak wygląda nasz poradnik własnego API z llama.cpp.
- Kontener. Przenosisz z aplikacją jej zależności użytkowe. Na hoście nadal potrzebujesz działającego sterownika i poprawnie skonfigurowanego dostępu do GPU.
- Kompilacja ze źródeł. Dobierasz również CUDA Toolkit, kompilator i biblioteki deweloperskie. To daje kontrolę nad buildem, ale zwiększa liczbę elementów do zapisania i odtworzenia.
To rozróżnienie często jest ważniejsze niż samo „Ubuntu czy Debian”. Gotowy program korzystający z bibliotek CUDA nie wymaga automatycznie instalowania całego zestawu narzędzi do kompilacji.
Kiedy rozważyć każdą z dystrybucji
| System | Praktyczny punkt wyjścia | Co sprawdzić przed instalacją |
|---|---|---|
| Ubuntu LTS | Zespół pracuje już z Ubuntu albo wybrana aplikacja opisuje właśnie to środowisko | konkretne wydanie LTS, wymagania aplikacji i zgodną ścieżkę instalacji sterownika |
| Debian stable | Chcesz zachować znany z innych serwerów sposób administracji Debianem | wersję Debiana wspieraną przez wybrany stos NVIDIA, nie samo oznaczenie „stable” |
| Rocky Linux | Używasz już narzędzi RPM/DNF i procedur dla środowiska z rodziny Enterprise Linux | dokładne wydanie Rocky, jądro, sterownik i biblioteki wymagane przez aplikację |
To kryteria organizacyjne, nie podium wydajności. Ubuntu opisuje cykl wydań LTS, Debian wskazuje stable jako wydanie produkcyjne, a dokumentacja Rocky wyjaśnia zarządzanie pakietami RPM/DNF. Dobrze utrzymane środowisko, które zespół zna, jest rozsądniejszym punktem wyjścia niż zmiana systemu tylko ze względu na jego nazwę.
Sterownik, runtime i Toolkit to różne elementy
Sterownik łączy system z kartą. Biblioteki runtime są używane przez aplikację, a Toolkit zawiera także narzędzia potrzebne do jej budowania. Warto zapisać wersję każdego z tych elementów osobno.
NVIDIA publikuje macierz dystrybucji dla konkretnego wydania CUDA. Nie przenoś automatycznie zgodności jednego wydania na inne. Przykładowo dokumentacja CUDA 12.8.1 wymienia określone wydania Ubuntu, Debiana i Rocky 8/9; nie wymienia Rocky 10. Nowsza macierz może mieć inny zakres.
Nasze opublikowane testy llama.cpp wykonaliśmy na Rocky Linux 10.2, ze sterownikiem NVIDIA 595.91.07 i bibliotekami CUDA 12.8 dostarczonymi z przypiętym buildem aplikacji. Potwierdza to działanie tego zestawu w opisanych próbach. Przy budowaniu własnego programu dobierz pełny Toolkit i kompilator według jego dokumentacji.
Pole „CUDA Version” w nvidia-smi opisuje możliwości sterownika, a nie kompletny spis zainstalowanych bibliotek. Przy zmianie wersji pomocne są zasady zgodności CUDA i sterownika.
Czy kontener rozwiązuje problem zgodności?
Kontener ułatwia utrzymanie tej samej wersji aplikacji i jej zależności. Nie zastępuje sterownika hosta ani prawidłowego udostępnienia GPU. Dokumentacja kontenerów llama.cpp opisuje osobny wariant CUDA, a NVIDIA podaje obsługiwane platformy Container Toolkit.
Do odtwarzania środowiska zapisuj konkretną wersję lub digest obrazu, model i jego sumę kontrolną oraz parametry uruchomienia. Zmienny tag latest jest wygodny do eksperymentów, ale nie mówi, jaki obraz działał podczas wcześniejszego pomiaru.
Jak sprawdzić własny wybór
Przed przeniesieniem aplikacji wykonaj krótki test: załaduj ten sam model, sprawdź użycie właściwej karty, wyślij reprezentatywne zapytanie i zapisz czas pierwszego tokena oraz szybkość odpowiedzi. Potem sprawdź ponowne uruchomienie usługi i dostępność modelu z lokalnego dysku.
Jeśli chcesz porównać wydajność dystrybucji, zachowaj ten sam sprzęt, model, build aplikacji, sterownik, kontekst i równoległość. Zmiana wszystkich tych elementów naraz pokaże różnicę między dwoma środowiskami, ale nie wyjaśni wpływu samego systemu.
Praktyczna decyzja: wybierz dystrybucję zgodną z Twoją aplikacją i sposobem pracy, a następnie przypnij działające środowisko. Do oceny szybkości użyj pomiarów silnika LLM i testów odpowiedzi API, nie popularności systemu.
Zobacz konfigurację serwera lub napisz, jaki model i środowisko chcesz uruchomić.