Silniki inferencyjne, orkiestracja klastra, kolejkowanie zadań, monitoring i warstwa orkiestracji wywołań modelu. Ta część stosu pracuje najdłużej po zakończeniu treningu.
BSD-3-ClauseTriton Inference Server
Silnik serwujący NVIDII, który potrafi jednocześnie hostować modele z różnych frameworków — PyTorch, TensorRT, ONNX, Python — za jednym API. Automatyczne grupowanie zapytań (dynamic batching) i kolejkowanie mają maksymalizować wykorzystanie GPU. Stosuje się go w produkcji, gdy trzeba serwować wiele modeli i wersji naraz z jednego węzła. Nazwa własna pokrywa się z kompilatorem OpenAI Triton; to dwa osobne projekty.
Apache-2.0
vLLM
Silnik serwujący modele językowe, zoptymalizowany pod przepustowość — technika PagedAttention ogranicza fragmentację pamięci GPU i pozwala obsłużyć więcej równoległych zapytań na tej samej karcie niż naiwna implementacja. Do tego dochodzi continuous batching, czyli dokładanie nowych zapytań do partii w trakcie generowania. Domyślny wybór do serwowania otwartych modeli językowych w skali produkcyjnej.
Apache-2.0
SGLang
Alternatywa dla vLLM z własnym językiem do opisywania złożonych, wieloetapowych zapytań do modelu — wywołań narzędzi czy generowania z ograniczeniami gramatycznymi. Agresywnie cachuje prefiksy rozmów, co ma znaczenie przy długich sesjach z powtarzalnym kontekstem. W benchmarkach przepustowości bywa szybszy niż vLLM na części obciążeń.
MIT
llama.cpp
Silnik inferencji napisany w czystym C/C++, który uruchamia skwantyzowane modele nawet na CPU bez GPU, bez zależności od Pythona i CUDA. Od tego projektu wywodzi się format GGUF, dziś standard dystrybucji skwantyzowanych wag. Wybiera się go, gdy trzeba uruchomić model lokalnie, na słabszym sprzęcie albo bez CUDA. Od sierpnia 2026 projekt wydaje tagi stabilne w schemacie vX.Y.Z; obok nich kilka razy dziennie wychodzą buildy nocne numerowane b####, oznaczone na GitHubie jako pre-release.
MIT
Ollama
Nakładka na llama.cpp, która sprowadza uruchomienie modelu do jednej komendy — pobiera, konwertuje i serwuje model przez lokalne API zgodne z OpenAI. Popularny wybór do szybkiego postawienia lokalnego punktu końcowego LLM bez ręcznej konfiguracji. Pod spodem pracuje ten sam silnik co w llama.cpp, więc możliwości inferencji są takie same.
Apache-2.0 (od v3.0)Text Generation Inference (TGI)
Silnik serwujący Hugging Face z continuous batchingiem i wsparciem kwantyzacji, mocno zintegrowany z ich Hubem. Konkuruje z vLLM i SGLang na tym samym polu — wybór zależy głównie od tego, z którym ekosystemem narzędzi zespół już pracuje. Pułapka historyczna: od wersji 1.0 (lipiec 2023) do 2.x TGI było na własnej licencji HFOIL 1.0, która zakazywała sprzedaży go jako usługi hostowanej bez umowy z Hugging Face. Od wersji 3.0 projekt wrócił do czystego Apache-2.0, ale przy audycie starszych wdrożeń trzeba o tamtej licencji pamiętać.
Apache-2.0
Ray i KubeRay
Framework do rozpraszania obliczeń Pythona na klaster — od strojenia hiperparametrów po trening rozproszony i serwowanie przez Ray Serve. KubeRay to operator zarządzający cyklem życia klastrów Ray wewnątrz Kubernetesa, więc w środowisku kontenerowym oba idą razem. W obu repozytoriach Apache-2.0 jest licencją główną, z dołączonymi atrybucjami dla wkomponowanego kodu innych projektów.
Apache-2.0Kubeflow
Zestaw komponentów do budowy platformy ML na Kubernetesie — pipeline'y, serwowanie modeli przez KServe i notebooki spięte jednym wdrożeniem. Sensowny wybór, gdy klient chce jedną spójną platformę zamiast składać ją samodzielnie z Raya, MLflow i Argo. Cykl wydawniczy jest wolniejszy niż w innych pozycjach z tej listy: dwa wydania rocznie, wersjonowanie kalendarzowe. Wersję i licencję podajemy za repozytorium kubeflow/manifests, bo realny kod żyje w wielu osobnych repozytoriach.
GPLv2 · copyleft
Slurm
Standardowy w HPC system kolejkowania zadań — użytkownik zgłasza zadanie z wymaganiami (liczba GPU, czas, priorytet), a Slurm decyduje, kiedy i gdzie je uruchomić. Używa się go tam, gdzie klaster dzieli wielu użytkowników i trzeba sprawiedliwie rozdzielać kolejkę. Licencja to GPLv2 z wyjątkiem pozwalającym linkować z OpenSSL. To silnik uruchamiany, nie linkowany do własnego kodu, więc copyleft nie obejmuje zadań, które Slurm tylko kolejkuje — ryzyko pojawia się dopiero przy modyfikowaniu i redystrybuowaniu samego Slurma.
Apache-2.0
Argo Workflows
Silnik workflow, w którym każdy krok pipeline'u to osobny kontener albo pod Kubernetesa. Pozwala opisać pipeline treningowy — przygotowanie danych, trening, ewaluacja, publikacja modelu — jako graf zależności. Często stoi pod spodem narzędzi wyższego poziomu, w tym części Kubeflow.
Apache-2.0Kubernetes
Standard orkiestracji kontenerów, na którym opiera się większość nowoczesnej infrastruktury AI — GPU Operator, KubeRay, Kubeflow i Argo Workflows z tej listy działają na nim albo obok niego. Planuje, skaluje i samoleczy obciążenia w klastrze. To narzędzie ogólnego przeznaczenia, na którym opiera się reszta stosu orkiestracyjnego. CNCF ma spisaną politykę użycia znaku towarowego, dlatego podajemy wyłącznie nazwę słowną.
Apache-2.0
Prometheus
Standard monitoringu metryk w świecie chmury natywnej — zbiera dane z węzłów, GPU (przez DCGM Exporter) i aplikacji, wystawia je do zapytań w PromQL i do alertów. Szeregi czasowe trzyma we własnym magazynie. Praktycznie zawsze stoi obok Grafany jako źródło danych do dashboardów.
AGPLv3 · copyleft sieciowyGrafana
Standardowe narzędzie do dashboardów operacyjnych — łączy się z Prometheusem, ClickHouse'em i dziesiątkami innych źródeł danych w jeden panel. AGPLv3 jest licencją zatwierdzoną przez OSI, ale silniejszą niż Apache. Samo stawianie niezmodyfikowanej Grafany do monitoringu, własnego albo klienckiego, jest bezpieczne. Ryzyko pojawia się przy modyfikowaniu i re-hostowaniu jej jako części własnej usługi: klauzula sieciowa §13 obejmuje udostępnianie zmienionej wersji przez sieć, nie tylko dystrybucję binarki.
Apache-2.0DCGM Exporter
Most między metrykami GPU zbieranymi przez NVIDIA DCGM a Prometheusem — temperatura, użycie, błędy ECC, przepustowość NVLink. Daje wgląd w rzeczywiste wykorzystanie kart w dashboardzie, więc to standardowy element stosu monitoringu przy każdym wynajmie GPU. Otwarty jest sam eksporter; biblioteka DCGM pod spodem jest dystrybuowana przez NVIDIĘ na własnej licencji.
MIT
LangChain
Warstwa orkiestracji nad wywołaniami modeli — łączy model językowy z narzędziami, bazą wektorową i pamięcią rozmowy w jeden pipeline, zamiast pisać to ręcznie za każdym razem. Najbardziej przydatna przy budowie agentów i systemów RAG korzystających z wielu źródeł danych naraz. Projekt wydaje osobno wersjonowane pakiety; rdzeniem jest langchain-core.
MIT
LlamaIndex
Framework skupiony na jednym zadaniu: jak wziąć własne dane — PDF-y, bazy, strony — i zrobić z nich indeks, po którym model może wyszukiwać przy odpowiadaniu na pytania. Węższy zakres niż LangChain, ale głębiej dopracowany akurat pod RAG. Nazwa zawiera „Llama”; projekt jest niezależny od Meta Platforms.
Apache-2.0
Haystack
Framework do budowy pipeline'ów RAG i agentów, z naciskiem na komponenty gotowe do produkcji — serwowanie asynchroniczne, introspekcję przebiegu, bezpieczne ładowanie pipeline'ów. Alternatywa dla LangChaina i LlamaIndexa, bliżej zorientowana na wdrożenie niż na prototypowanie. Nowa wersja główna 3.0 wyszła w lipcu 2026.
Apache-2.0
NVIDIA KAI-Scheduler
Otwarty planista Kubernetesa do zadań GPU — pozwala kilku zadaniom dzielić jedną kartę, ustawia priorytety kolejki i wywłaszczanie, żeby karty nie stały bezczynnie między zadaniami. To wydzielony, w pełni otwarty silnik szeregujący z produktu Run:ai, który NVIDIA przejęła w 2024 roku. Płatna platforma Run:ai pozostaje częścią NVIDIA AI Enterprise; KAI-Scheduler jest od niej niezależnym projektem sandbox CNCF.
