Warstwa techniczna wdrożenia on-prem AI: jak zbudować RAG, który nie halucynuje, jak dobrać GPU pod model i obciążenie oraz jak mierzyć jakość retrievalu i przepustowość inferencji. Konkrety, benchmarki i architektury referencyjne zamiast diagramów marketingowych.
Ten klaster to inżynierska strona on-prem AI. Rozkładamy pipeline RAG na części, które realnie decydują o jakości: chunking, embeddingi, retrieval i reranking, z odpowiedzią, kiedy reranker (cross-encoder) poprawia trafność, a kiedy tylko zjada budżet GPU. Publikujemy GPU sizing na liczbach (np. Llama 70B: throughput, VRAM, kwantyzacja, vLLM/TensorRT-LLM) i architektury referencyjne mapowane na wymogi bezpieczeństwa. To materiał dla CIO i architektów, którzy muszą podjąć decyzje sprzętowe i projektowe, a nie znajdują w polskim internecie neutralnych benchmarków, bo te są niemal wyłącznie po angielsku. Każdy artykuł techniczny łączymy z konsekwencją regulacyjną (logowanie, izolacja, nadzór) i z kalkulatorem TCO, żeby decyzja architektoniczna miała cenę.
Sizing GPU odpowiada, ile kart kupić. Wybór silnika serwującego decyduje, ile z nich wyciśniesz. Porównanie vLLM i TensorRT-LLM (plus SGLang) na Llama 70B: throughput, TTFT, koszt kompilacji i tabela decyzyjna, który wybrać do on-prem.
Peak throughput z benchmarku nie mówi, ile kosztuje milion tokenów. Rachunek to stawka za godzinę karty podzielona przez tokeny na godzinę i przez obłożenie. Liczymy koszt per milion tokenów na H100 i H200, zestawiamy z ceną API i pokazujemy próg obłożenia, powyżej którego on-prem wygrywa.
Awaria europe-west4 pokazała nie zawodność chmury, tylko coś gorszego: brak możliwości zaudytowania zależności, na których stoi twój AI. Co realnie zaudytujesz on-prem, a czego hiperskaler nie odsłoni.
Cztery warstwy telemetrii dla on-prem LLM: infrastruktura, serwowanie, jakość i audyt. Co logować, czego nie zapisywać i jak spiąć observability z audit trail wymaganym przez NIS2.
Reranker poprawia porządek top-k tam, gdzie zapytania są długie, a baza gęsta. Liczby, koszt w VRAM i opóźnieniu oraz pięć konfiguracji, w których się wykłada.
Jak zbudować RAG poza chmurą publiczną: warstwy pipeline'u, najczęstsze błędy retrievalu, granice danych w promptcie i pytania, które zadaje audytor. Notatka techniczna dla architektów i CISO.
Ile GPU realnie potrzeba, żeby postawić Llamę 3.1 70B u siebie? Konkretne konfiguracje (A100, H100, H200), wpływ kwantyzacji (FP16 → FP8 → INT4), tokens/s, TTFT i koszt per 1M tokenów. Bez marketingu, z liczbami z benchmarków vLLM i TensorRT-LLM.
Nie, pomaga przy dużych, zaszumionych korpusach; przy małych, dobrze pociętych zbiorach bywa zbędnym kosztem GPU i opóźnieniem.
Do developmentu Ollama jest wygodna; na produkcję przy obciążeniu vLLM daje wielokrotnie wyższą przepustowość (batching, multi-GPU).
Zależy od rozmiaru modelu i kwantyzacji, patrz artykuł o GPU sizing; z grubsza model w FP16 potrzebuje ~2× liczby parametrów w GB, plus zapas na kontekst.
Chcesz przełożyć to na swój przypadek: architekturę, zgodność i koszt?
→ Umów 30 min