Własne modele językowe na vLLM i Kubernetes, z danymi w firmie i kosztami, które możesz zaplanować

Własne modele dają dwie rzeczy, których publiczne API nie daje: dane, które nie mogą opuścić twojej infrastruktury, można wykorzystać z AI, a zadanie działające przez cały dzień kosztuje tyle, ile kosztują GPU, niezależnie od liczby zapytań. Zachowujesz też kontrolę nad wersją modelu, więc odpowiedzi nie zmieniają się dlatego, że dostawca zaktualizował swój model.

Wiele firm już się do tego przygotowuje. W badaniu CIO i Computerwoche z firmą Dell z 2026 roku wśród 106 szefów IT średnich i mniejszych firm z Niemiec, Austrii i Szwajcarii 20% zaczęło budować lokalną infrastrukturę serwerową dla AI. GPU to duży zakup, więc mierzymy na twoim obciążeniu, zanim cokolwiek zostanie kupione.

Własne modele opłacają się, gdy dane nie mogą opuścić twojej infrastruktury, gdy jedno zadanie działa stale przy dużym wolumenie albo gdy potrzebujesz pełnej kontroli nad wersją modelu. Zwykle to zły wybór dla małej grupy użytkowników, bardzo nierównego użycia albo zadań, w których wystarczająco dobre są tylko największe modele komercyjne.

Koszt zależy od klasy i liczby GPU, od tego, jak bardzo są obciążone, od rozmiaru modelu i od nakładu na utrzymanie usługi. Zanim podejmiesz decyzję, porównujemy te czynniki z kosztem tej samej pracy przez API.

Na pytanie „ile GPU potrzebujemy dla 50 użytkowników?” nie da się odpowiedzieć bez szczegółów: ile zapytań przychodzi jednocześnie, jak długie są dokumenty i odpowiedzi, jaki rozmiar modelu i jaka kwantyzacja przechodzą twoje testy i jakie czasy odpowiedzi akceptują użytkownicy. Przy wielu równoczesnych zapytaniach zwykle najpierw kończy się pamięć GPU na KV cache, a dopiero potem moc obliczeniowa.

Dlatego najpierw mierzymy, na wynajętych GPU albo sprzęcie, który już masz, z twoimi promptami i dokumentami. Serwery kupujesz dopiero wtedy, gdy zobaczysz liczby.

vLLM dobrze działa na Kubernetes, gdy rozwiązane są elementy specyficzne dla GPU.

• Pule węzłów GPU ze sterownikami i wtyczką urządzeń, których potrzebuje klaster, we własnej serwerowni albo na EKS lub AKS.
• Pliki modeli trzymane blisko węzłów, żeby nowa replika nie pobierała gigabajtów, zanim zacznie odpowiadać.
• Autoskalowanie według metryk vLLM, takich jak oczekujące zapytania i wykorzystanie pamięci podręcznej, bo obciążenie CPU pozostaje niskie, gdy pracuje GPU.
• Kontrole gotowości, które czekają na załadowanie modelu, i wdrożenia, które utrzymują wystarczającą moc, gdy startuje nowa wersja.
• Dashboardy i alerty dla czasów odpowiedzi, kolejki, błędów i wykorzystania GPU w monitoringu, którego już używasz.

vLLM to silnik serwujący. KServe dodaje standardowy sposób opisywania i wdrażania usług modeli na Kubernetes, a llm-d to nowszy projekt do rozkładania inferencji z vLLM na wiele GPU. Naszym zdaniem większość firm dobrze zaczyna od zwykłych wdrożeń vLLM za bramą i dodaje te warstwy, gdy liczba modeli albo GPU zaczyna to uzasadniać.

Mniejszy albo skwantyzowany model może być tańszy i szybszy, ale gorszy w twoim zadaniu. Zanim model trafi na produkcję i przed każdą aktualizacją uruchamiamy twoje testy regresji wobec modelu, który miałby zostać zastąpiony, i zmieniamy go tylko wtedy, gdy jakość się utrzymuje.