Praktyka, pomiary i ograniczenia

Projekty, demonstratory i laboratorium AI-SCI

Pokazuję tu własne projekty, demonstratory i środowisko testowe wykorzystywane do sprawdzania lokalnych modeli LLM, RAG, automatyzacji dokumentów, edge AI oraz wydajności sprzętu. Każdy opis jasno określa status rozwiązania — bez przedstawiania prototypu jako wdrożenia klientowskiego.

Jawny status prac

Demonstrator nie jest wdrożeniem klientowskim

Ta strona pokazuje rzeczywiste projekty własne, prototypy, demonstratory i narzędzia badawczo-rozwojowe AI-SCI. Status przy każdym projekcie informuje, na jakim etapie znajduje się rozwiązanie. Nie publikuję fikcyjnych case studies ani wyników, których nie da się powiązać z konkretnym testem.

Wspólnym celem tych prac jest ograniczenie ryzyka przed wdrożeniem: sprawdzenie jakości modelu, wydajności całego potoku, wymagań sprzętowych, prywatności danych i punktów, w których prostsza automatyzacja może być lepsza od AI.

Projekty własne

Od architektury LLM po analizę obrazu na brzegu sieci

Każdy opis obejmuje problem, architekturę, rezultat, ograniczenia i możliwe zastosowanie biznesowe.

Projekt własny / demonstrator

Router LLM / lexSecureRouter

Warstwa pośrednicząca między użytkownikiem, modelami lokalnymi, usługami API i firmową wiedzą. Jej zadaniem jest dobrać sposób obsługi zapytania zamiast kierować każde zadanie do jednego modelu.

  • Python
  • FastAPI
  • Ollama
  • RAG
  • MongoDB
  • SearxNG / YaCy

Problem

Różne zadania wymagają różnej jakości, prywatności, czasu odpowiedzi i kosztu. Jeden model nie jest najlepszy do kodu, dokumentów, wyszukiwania wiedzy i prostych pytań jednocześnie.

Architektura

  1. API w FastAPI przyjmujące zapytanie i kontekst zadania
  2. klasyfikacja oraz routing do modelu lokalnego albo zewnętrznego API
  3. RAG i wyszukiwanie źródeł z użyciem SearxNG lub YaCy
  4. adaptery modeli, rejestrowanie wyników w MongoDB i testy automatyczne

Rezultat

Powstał działający demonstrator architektury wielomodelowej z obsługą modeli lokalnych i API, klasyfikacją zapytań, RAG oraz automatycznym testowaniem wybranych kategorii i wariantów wykonania.

Ograniczenia

Przed użyciem produkcyjnym potrzebne są reguły uprawnień, monitoring jakości i kosztów, polityka retencji danych, odporność na awarie dostawców oraz testy na rzeczywistych danych organizacji.

Możliwe zastosowanie biznesowe

Systemy, w których część zapytań musi pozostać lokalnie, a część może korzystać z mocniejszych usług chmurowych. Router pozwala dobierać wariant według prywatności, jakości, kosztu i czasu odpowiedzi.

Projekt własny / prototyp

lexSecure — automatyzacja dokumentów

Prototyp systemu wspierającego tworzenie, porządkowanie i standaryzację dokumentów z wykorzystaniem lokalnych modeli językowych, szablonów oraz kontrolowanego eksportu do DOCX.

  • Python
  • lokalne LLM
  • RAG
  • DOCX
  • HTML → DOCX
  • walidacja

Problem

Praca z dokumentami często łączy ręczne kopiowanie treści, niespójne formatowanie, wyszukiwanie właściwych informacji i konieczność zachowania poufności danych.

Architektura

  1. szablony i kategorie dokumentów opisujące oczekiwaną strukturę
  2. lokalne modele LLM oraz opcjonalny RAG do pracy ze źródłami
  3. walidacja i standaryzacja wygenerowanej treści
  4. konwersja HTML do DOCX i kontrola nazewnictwa plików

Rezultat

Uruchomiono przepływ od zebrania danych i wygenerowania treści do utworzenia ustandaryzowanego dokumentu DOCX. Projekt służy również do porównywania modeli polskojęzycznych i sposobów ograniczania błędów generowania.

Ograniczenia

Wynik modelu wymaga walidacji merytorycznej. System nie zastępuje specjalisty, a zakres automatyzacji zależy od jakości szablonów, źródeł oraz reguł kontroli dokumentu.

Możliwe zastosowanie biznesowe

Procesy z dużą liczbą powtarzalnych pism, raportów, formularzy i dokumentów wewnętrznych, w których liczą się spójność, krótszy czas przygotowania i kontrola nad danymi.

Demonstrator edge AI

Raspberry Pi 5 + Hailo-10H — detekcja i śledzenie

Lokalny potok wizyjny wykorzystujący kamery, Raspberry Pi 5 i akcelerator Hailo-10H do detekcji oraz śledzenia obiektów bez wysyłania całego strumienia obrazu do chmury.

  • Raspberry Pi 5
  • Hailo-10H
  • YOLO
  • GStreamer
  • V4L2
  • Python / C++

Problem

Analiza obrazu w chmurze zwiększa opóźnienie, zużycie łącza i ekspozycję nagrań. W wielu zastosowaniach decyzja powinna powstać blisko kamery.

Architektura

  1. kamery i lokalny potok wideo na Raspberry Pi 5
  2. detekcja obiektów modelami YOLO wykonywana przez Hailo-10H
  3. identyfikatory śledzenia i logika wyboru obserwowanego obiektu
  4. oddzielny pomiar inferencji oraz całego potoku z dekodowaniem i prezentacją obrazu

Rezultat

Demonstrator wykrywa i śledzi obiekty w obrazie. W testach wewnętrznych część inferencyjna bez wyświetlania osiągała około 190–230 FPS, natomiast pełny potok z prezentacją obrazu działał około 8,5 FPS. Pokazuje to, że wąskim gardłem może być obsługa obrazu, a nie sam akcelerator.

Ograniczenia

Wyniki zależą od modelu, rozdzielczości, oświetlenia, liczby strumieni i sposobu prezentacji. Rozpoznanie konkretnej osoby lub obiektu wymaga osobnego mechanizmu identyfikacji oraz oceny prawnej zastosowania.

Możliwe zastosowanie biznesowe

Lokalna kontrola zdarzeń, analiza ruchu, detekcja obiektów, monitoring urządzeń i inne zadania wymagające krótkiej reakcji oraz ograniczenia przesyłania obrazu.

Projekt B+R / narzędzie wewnętrzne

Automatyczna pętla tworzenia i testowania kodu

Architektura, w której model generuje zmianę kodu, uruchamia testy, analizuje wynik i przygotowuje kolejną iterację, korzystając z wielu modeli oraz kilku maszyn obliczeniowych.

  • lokalne modele kodowe
  • Git
  • testy automatyczne
  • benchmarki
  • sandbox
  • praca rozproszona

Problem

Samo wygenerowanie kodu nie gwarantuje poprawności. Kolejna iteracja może naprawić jeden test, a jednocześnie pogorszyć wcześniejsze wyniki lub bezpieczeństwo projektu.

Architektura

  1. opis zadania i kryteria zakończenia zapisane jako testowalne wymagania
  2. generowanie zmian w odizolowanej gałęzi albo katalogu roboczym
  3. uruchamianie testów, benchmarków i analizy statycznej
  4. porównanie z wynikiem bazowym, kontrola regresji i decyzja o kolejnej iteracji

Rezultat

Opracowywana jest pętla łącząca lokalne modele, generowanie kodu, automatyczne testy i ocenę regresji. Projekt służy jako środowisko badawcze do sprawdzania, jak bezpiecznie delegować kolejne kroki wielu agentom i komputerom.

Ograniczenia

Pełna autonomia jest ryzykowna. Potrzebne są limity zasobów, sandbox, wersjonowanie, możliwość szybkiego rollbacku, zestaw testów chroniących dotychczasowe funkcje i punkty zatwierdzania przez człowieka.

Możliwe zastosowanie biznesowe

Wsparcie utrzymania kodu, budowy prototypów, migracji i optymalizacji, gdy wynik można obiektywnie sprawdzić testami, benchmarkami albo regułami jakości.

Laboratorium AI-SCI

Sprzęt dobierany do rodzaju testu

Laboratorium nie jest kolekcją komputerów. Każda platforma ma określoną rolę: większe modele, CUDA, bieżąca inferencja, edge AI, bazy danych albo praca rozproszona.

Większe modele lokalne i architektury wielomodelowe

ASUS Ascent GX10 z NVIDIA GB10

Platforma do testowania większych modeli, długiego kontekstu, pracy wielu komponentów oraz prototypów wymagających dużej pamięci współdzielonej.

CUDA, inferencja i obliczenia numeryczne

NVIDIA Tesla V100 32 GB

Środowisko do porównań GPU, eksperymentów CUDA, testów modeli mieszczących się w 32 GB pamięci oraz obliczeń wymagających dobrej wydajności numerycznej.

Współczesna inferencja i analiza obrazu

NVIDIA RTX 5070 Ti

Stacja robocza używana do bieżących testów modeli, narzędzi generatywnych, przetwarzania obrazu i integracji aplikacyjnych.

Edge AI i lokalna analiza obrazu

Raspberry Pi 5 z Hailo-10H

Platforma do detekcji, śledzenia i eksperymentów z przetwarzaniem obrazu blisko źródła danych, bez stałego wysyłania materiału do chmury.

RAG, dokumenty, bazy danych i usługi pomocnicze

Serwery CPU i duża pamięć RAM

Zaplecze do indeksowania dokumentów, baz wektorowych, baz danych, usług API oraz testów wariantów CPU i GPU.

Praca rozproszona i przepływ danych

Sieć 10 Gb/s

Połączenie platform testowych umożliwiające sprawdzanie architektur rozproszonych oraz sprawne przenoszenie modeli i danych między maszynami.

Co publikuję, a czego nie ujawniam

Pokazuję klasę platformy, jej rolę i metodę testu. Nie publikuję numerów seryjnych, adresów IP i MAC, danych dostępowych, dokładnej topologii sieci, otwartych portów ani informacji o fizycznym zabezpieczeniu sprzętu.

Pomiar własny

Ten sam model na trzech generacjach sprzętu

Rekomendacja sprzętowa powinna wynikać z pomiaru, a nie z karty katalogowej. Poniżej wynik dla gemma3:12b w kwantyzacji Q4_K_M, uruchomionego przez Ollamę 0.16.1 na trzech platformach laboratorium: streszczenie umowy, ekstrakcja encji do JSON-a i odpowiedź wyłącznie z podanego kontekstu. Pięć powtórzeń po odrzuceniu przebiegu rozgrzewkowego, raportowana mediana.

Przepustowość generowania tokenów na trzech platformachNVIDIA RTX 5070 Ti: 84,10 tokenów na sekundę przy granicy 110,6 (76% sufitu). NVIDIA Tesla V100 32 GB: 61,98 tokenów na sekundę przy granicy 111,1 (56% sufitu). NVIDIA GB10 Grace Blackwell: 26,96 tokenów na sekundę przy granicy 33,7 (80% sufitu).NVIDIA RTX 5070 Ti84,10 tok/s76% sufitu · granica 110,6NVIDIA Tesla V100 32 GB61,98 tok/s56% sufitu · granica 111,1NVIDIA GB10 Grace Blackwell26,96 tok/s80% sufitu · granica 33,7pomiar własnygranica przepustowości pamięci
Pełny słupek to wynik zmierzony, jaśniejszy — granica wynikająca z przepustowości pamięci przy tym modelu. Im pełniejszy słupek, tym lepiej platforma wykorzystuje to, czym dysponuje.
16 GB GDDR7, ok. 896 GB/s

NVIDIA RTX 5070 Ti

Rozrzut pięciu prób: 83,85–84,55 tok/s.

Model zajął 9,0 GB. Karta obsługuje równolegle dwa monitory, więc zajętość liczona jest jako przyrost względem stanu przed startem.

32 GB HBM2, ok. 900 GB/s

NVIDIA Tesla V100 32 GB

Rozrzut pięciu prób: 61,39–62,69 tok/s.

Ta sama przepustowość co karta nowsza, a wynik o jedną trzecią niższy. Różnicy nie tłumaczy pamięć, tylko dojrzałość jąder obliczeniowych: architektura z 2017 roku dostaje dziś mniej uwagi optymalizacyjnej.

128 GB LPDDR5X wspólnie z CPU, ok. 273 GB/s

NVIDIA GB10 Grace Blackwell

Rozrzut pięciu prób: 26,93–26,99 tok/s.

Najbliżej swojej fizycznej granicy ze wszystkich trzech platform — granica leży po prostu trzykrotnie niżej. W zamian mieści modele, których dwie pozostałe nie wczytają w ogóle.

Dlaczego nowsze nie znaczy szybsze

Generowanie każdego kolejnego tokena wymaga przeczytania z pamięci wszystkich wag modelu. Przy jednym strumieniu decyduje więc przepustowość pamięci, a nie moc obliczeniowa — dlatego karta z 2017 roku wypada tu ponad dwukrotnie lepiej od układu z roku 2025, mimo wielokrotnie niższej liczby operacji na sekundę. Kolumna „sufit” to przepustowość katalogowa podzielona przez rozmiar wag; żaden silnik inferencji nie przekroczy tej wartości.

Wniosek dla doboru sprzętu nie brzmi więc „kupcie najszybsze”. Przy interaktywnej rozmowie na mniejszym modelu liczy się szybka pamięć. Przy analizie długich dokumentów i przy modelach, które nie mieszczą się w karcie, wygrywa duża pamięć wspólna — i wtedy platforma najwolniejsza w tym zestawieniu jest jedyną, która zadanie w ogóle wykona.

Zakres tego pomiaru jest ograniczony i mówię to wprost: mierzę wydajność, nie trafność odpowiedzi, a to drugie wymaga korpusu z etykietami i będzie osobnym badaniem. Wynik dotyczy jednego silnika i jednego formatu wag — dla platformy GB10 format natywny jest inny, więc ta liczba jest dla niej zaniżona. Wyniki surowe, wraz z każdą pojedynczą próbą, udostępniam na życzenie.

Metodyka

Najpierw kryteria, potem benchmark

Sam wynik tokenów na sekundę albo liczba klatek nie odpowiada jeszcze na pytanie, czy rozwiązanie będzie użyteczne. Pomiar musi obejmować cały proces i jakość wyniku.

  1. 1. Zadanie i daneDefinicja procesu, danych wejściowych, ograniczeń i oczekiwanego rezultatu.
  2. 2. MetrykiJakość odpowiedzi, czas pierwszej odpowiedzi, przepustowość, pamięć, stabilność i koszt.
  3. 3. WariantyPorównanie modeli, kwantyzacji, kontekstu, RAG, CPU, GPU oraz architektury lokalnej i hybrydowej.
  4. 4. Cały potokPomiar nie tylko modelu, lecz także wczytywania danych, wyszukiwania, walidacji, sieci i interfejsu.
  5. 5. Raport i ograniczeniaRekomendacja wraz z ryzykami, przypadkami błędnymi i warunkami dalszego pilotażu.
Od demonstratora do PoC

Podobny problem można sprawdzić na małej, mierzalnej próbie

PoC powinien odpowiedzieć, czy rozwiązanie osiąga wymaganą jakość, mieści się w dostępnej infrastrukturze i daje przewagę nad prostszą automatyzacją. Dopiero wtedy ma sens planowanie pilotażu i wdrożenia.

Kod źródłowy

Część tego kodu możecie przeczytać

Opis na stronie to deklaracja. Repozytorium to dowód, który da się otworzyć i sprawdzić samodzielnie — łącznie z historią zmian, testami i miejscami, w których rozwiązanie jest niedokończone.