Wybór systemu pod LLM warto zacząć od aplikacji, którą chcesz uruchomić, i narzędzi, które zna Twój zespół. Sama nazwa dystrybucji nie mówi, ile tokenów na sekundę wygeneruje GPU. Ważny jest cały zestaw: sterownik, biblioteki, silnik modelu i jego ustawienia.
Ubuntu, Debian i Rocky Linux mogą być podstawą takiego serwera. Poniżej porównujemy sposób przygotowania i utrzymania środowiska, nie wyniki wyścigu między trzema systemami.
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ć.