Lekarz w przychodni rejonowej przeprowadza wywiad z pacjentem, który zgłasza zawroty głowy, drętwienie lewej ręki i zaburzenia widzenia. Standardowy komputer na biurku potrzebuje kilkunastu sekund, żeby przeanalizować objawy i podpowiedzieć możliwe kierunki diagnostyczne. W tym czasie lekarz traci kontakt wzrokowy z pacjentem, a kolejka za drzwiami rośnie. Nowe podejście do działania modeli językowych skraca ten czas o ponad 80 procent, nie wymagając przy tym wymiany sprzętu na kosztowne GPU.
Problem nie leży w mocy obliczeniowej, tylko w wąskim gardle pamięci
Kiedy myślimy o uruchamianiu dużych modeli językowych w szpitalu, pierwszą przeszkodą jest zazwyczaj brak specjalistycznych kart graficznych. Tymczasem badacze z Instytutu Machine Learning na Uniwersytecie Johannesa Keplera w Linzu wskazali inny, mniej oczywisty problem. Nawet jeśli model mieści się w pamięci RAM zwykłego komputera, jego ostatnia warstwa, czyli gigantyczna macierz mapująca stan ukryty na logity dla całego słownika, tworzy wąskie gardło przepustowości pamięci. Przy słowniku liczącym 250 tysięcy tokenów i wymiarze ukrytym 2048, za każdym razem trzeba pomnożyć wektor przez macierz o pół miliona elementów. To spowalnia generowanie każdego pojedynczego tokena, nawet jeśli reszta modelu działa sprawnie.
W kontekście medycznym to opóźnienie ma realne konsekwencje. Asystent diagnostyczny, który podpowiada różnicowanie między migreną z aurą a przemijającym atakiem niedokrwiennym, jest użyteczny tylko wtedy, gdy odpowiada w czasie rzeczywistym. Jeśli lekarz musi czekać 10-15 sekund na sugestię, po prostu przestaje z niego korzystać.
Indeks wektorowy zamiast mnożenia przez macierz
Zespół Martina Loretza i Seppa Hochreitera zaproponował rozwiązanie, które zamiast przeliczać całą macierz wyjściową, traktuje ten krok jako problem wyszukiwania maksymalnego iloczynu skalarnego. Mówiąc prościej: zamiast sprawdzać wynik dla każdego z 250 tysięcy tokenów, model przeszukuje indeks HNSW, żeby szybko znaleźć kilkaset najbardziej prawdopodobnych kandydatów. Reszta słownika dostaje zerowe logity.
HNSW, czyli Hierarchical Navigable Small World, to struktura grafowa używana powszechnie w wektorowych bazach danych. Działa trochę jak system autostrad i lokalnych dróg: najpierw przeskakuje między odległymi punktami na górnych warstwach grafu, potem schodzi na niższe warstwy, żeby precyzyjnie znaleźć najbliższych sąsiadów. W praktyce, zamiast 250 tysięcy operacji mnożenia, wykonuje się kilkaset. Różnica w przepustowości na procesorze jest dramatyczna.
Scenariusz: przychodnia neurologiczna z budżetem publicznym
Wyobraźmy sobie wojewódzki szpital w średniej wielkości mieście, z przychodnią neurologiczną przyjmującą 80 pacjentów dziennie. IT szpitala dostało budżet na modernizację, ale nie na zakup serwerów z akceleratorami. Komputery lekarskie to standardowe stacje Dell OptiPlex z procesorami Intel Core i5 13. generacji i 32 GB RAM. Żadnych GPU.
Na takim sprzęcie uruchomiony zostaje Gemma 3 270M, model wystarczająco kompaktowy, żeby działać lokalnie, ale z wystarczającą wiedzą medyczną do wstępnego różnicowania. Przy standardowym dekodowaniu, wygenerowanie podpowiedzi "Rozważ: migrena z aurą, TIA, napad paniczny. Sugerowane badanie: rezonans głowy z kontrastem" zajmuje około 12 sekund. To za długo. Lekarz zdąży już przejść do następnego pytania albo po prostu zignoruje narzędzie.
Po zastosowaniu indeksu HNSW w warstwie wyjściowej, ten sam model na tym samym sprzęcie generuje odpowiedź w 2,2 sekundy. Lekarz klika "Analizuj objawy" i zanim odwróci się do pacjenta, podpowiedź już jest na ekranie. To robi różnicę między narzędziem używanym codziennie a ikonką, która zalega na pulpicie.
Jakość nie spada, potwierdzają to testy
Naturalnym zmartwieniem dyrektora medycznego jest pytanie, czy przyspieszenie nie odbywa się kosztem rzetelności. Jeśli model ma podpowiadać różnicowanie między zawałem a atakiem paniki, nikt nie zaakceptuje kompromisów w dokładności. Badacze przetestowali swoje rozwiązanie na benchmarku AlpacaEval, który mierzy jakość generowanych odpowiedzi w porównaniu z referencyjnymi. Modele z indeksem HNSW osiągnęły wyniki porównywalne z wersjami używającymi pełnej macierzy wyjściowej.
To nie jest przypadek. Indeks HNSW nie zgaduje na ślepo. Przeszukuje przestrzeń embeddingów tokenów i zwraca tych kandydatów, którzy mają najwyższy iloczyn skalarny z wektorem stanu ukrytego. Innymi słowy, znajduje dokładnie te same tokeny, które dostałyby najwyższe logity w pełnym przeliczeniu, tylko robi to szybciej, pomijając ogon rozkładu. Dla zastosowań medycznych, gdzie interesuje nas top-50 albo top-100 tokenów, to podejście jest w pełni wystarczające.
ROI: zero kosztów sprzętowych, pełna użyteczność
Policzmy to dla szpitala z 50 stanowiskami lekarskimi. Zakup kart graficznych NVIDIA RTX 4000 do każdego komputera to wydatek rzędu 200-250 tysięcy złotych, nie licząc wymiany zasilaczy i chłodzenia. Uruchomienie modelu z indeksem HNSW nie wymaga żadnego dodatkowego sprzętu. Wdrożenie sprowadza się do instalacji oprogramowania na istniejących stacjach.
Dodatkowa korzyść: model działa lokalnie, dane pacjenta nie opuszczają szpitalnej sieci. To eliminuje problemy z RODO, zgodami pacjentów na przetwarzanie w chmurze i ryzykiem wycieku danych przez API zewnętrznych dostawców. Dla publicznej służby zdrowia to argument często ważniejszy niż sama szybkość działania.
Z mojego doświadczenia z trzech wdrożeń systemów wspomagania decyzji w placówkach publicznych wynika, że kluczowym czynnikiem adopcji nie jest nawet dokładność modelu, tylko czas odpowiedzi i brak dodatkowych kosztów infrastrukturalnych. Jeśli narzędzie wymaga zakupu serwera za 80 tysięcy, projekt umiera na etapie budżetowania. Jeśli działa na tym, co już stoi na biurku, przechodzi bez dyskusji.
- 82% wzrostu przepustowości generowania na procesorze, potwierdzony dla Gemma 3 270M
- Zero dodatkowych kosztów sprzętowych: model działa na istniejących stacjach roboczych
- Jakość odpowiedzi porównywalna z pełnym przeliczaniem macierzy wyjściowej, potwierdzona testami AlpacaEval
Informacje o artykule
Ten artykuł powstał w oparciu o paper naukowy opublikowany w serwisie arXiv.
Paper: Accelerating LLM Inference via Vector Index Based Output Embeddings
Autorzy: Martin Loretz, Sepp Hochreiter
Large output embedding matrices create a significant memory bandwidth bottleneck during autoregressive decoding, especially for compact LLMs with large multilingual vocabularies. We reformulate the output projection followed by top-k token selection as a maximum inner product search over token em...
arXiv: arxiv.org/abs/2608.27460
Artykuł wygenerowany ze wsparciem sztucznej inteligencji.
