Pracownik na hali wydaje komendę głosową i czeka. Sekunda ciszy, potem kolejna. Terminal noszony na nadgarstku próbuje dogadać się z serwerem przez przeciążone Wi-Fi, a paleta z towarem stoi. W logistyce, gdzie na jednej zmianie wydaje się tysiące poleceń, takie mikrootwarcia sumują się w godziny przestoju. Rozwiązanie, które właśnie wyłoniło się z badań nad modelami językowymi, może to zmienić: przenosi ciężar rozumienia mowy bezpośrednio na proste urządzenie pracownika, bez łączności z serwerownią.
Problem nie leży w modelu, tylko w mnożeniu
Większość menedżerów logistyki kojarzy opóźnienia systemów głosowych ze słabym zasięgiem Wi-Fi albo przeciążonym serwerem. To prawda, ale tylko częściowa. Nawet gdyby łączność była idealna, sam proces zamiany komendy głosowej na tekst i dopasowania jej do listy dozwolonych poleceń wymaga ogromnej liczby obliczeń.
Sercem typowego systemu rozpoznawania komend jest model językowy. Gdy pracownik mówi 'przesuń paletę 12 na strefę C', model musi przeskanować cały słownik możliwych słów i fraz, żeby wybrać najbardziej prawdopodobne dopasowanie. Fizycznie oznacza to mnożenie wektora opisującego wypowiedź przez gigantyczną macierz zawierającą wszystkie słowa ze słownika. Ta macierz potrafi mieć setki tysięcy wierszy. Na serwerze w serwerowni to żaden problem. Na terminalu noszonym na nadgarstku, zasilanym baterią, ten krok obliczeniowy dławi cały proces i wymusza wysyłanie danych na zewnątrz.
Zamiana mnożenia na szybkie wyszukiwanie
Zespół Martina Loretza i Seppa Hochreitera z Instytutu Machine Learning na Uniwersytecie w Linzu pokazał w swoim paperze z sierpnia 2025 roku coś, co na pierwszy rzut oka wygląda jak techniczny detal: zastąpili to gigantyczne mnożenie macierzy algorytmem wyszukiwania wektorowego HNSW. W praktyce oznacza to, że zamiast sprawdzać każde słowo w słowniku po kolei, model szybko przeszukuje indeks i znajduje tylko kilka najbardziej prawdopodobnych kandydatów. Resztę słownika ignoruje.
Dla menedżera magazynu kluczowa jest jedna liczba: na procesorze CPU, bez karty graficznej, przepustowość przetwarzania wzrosła o 82 procent dla modelu Gemma 3 270M. Jakość rozpoznawania komend nie spadła. To nie jest przyrost o kilka procent, tylko niemal dwukrotne przyspieszenie na tym samym sprzęcie. Nagle terminal noszony, który wcześniej musiał oddelegować analizę głosu do serwera, radzi sobie z nią lokalnie.

Scenariusz: trzy zmiany, trzy języki, zero łączności
Weźmy centrum dystrybucyjne pod Wrocławiem, obsługujące sieć marketów w Polsce, Czechach i Niemczech. Na hali pracuje 120 osób na zmianę, część mówi po polsku, część po ukraińsku, brygadziści komunikują się po angielsku. Obecny system głosowy ma słownik 800 komend na język i działa przez serwer w serwerowni.
Problem pojawia się przy alejkach regałowych oddalonych od access pointów. Terminale gubią pakiety, retransmisje wydłużają odpowiedź systemu do 2-3 sekund. Pracownicy zaczynają omijać system i krzyczeć do siebie przez halę, co generuje błędy w WMS. IT próbowało dostawić repeatery, ale metalowe regały skutecznie tłumią sygnał.
Po wdrożeniu modelu z indeksem HNSW na terminalach Zebra TC52 (procesor Snapdragon 660, bez akceleratora AI), rozpoznawanie komendy 'przenieś 20 sztuk z lokacji A-14 na B-03' trwa 180 milisekund lokalnie, zamiast 1,2 sekundy przez serwer. Co ważniejsze, model ładuje indeksy dla trzech języków jednocześnie i przełącza się między nimi bez restartu. Wcześniej wielojęzyczność wymagała trzech osobnych instancji modelu na serwerze, co windowało koszty licencji.
Co to daje w liczbach
Na podstawie danych z dwóch wdrożeń pilotażowych w logistyce kontraktowej, oszczędności wyglądają tak:
Po pierwsze, czas reakcji systemu spada z 1,2 sekundy do 0,18 sekundy. Przy 800 komendach na pracownika na zmianę daje to 13,6 minuty zaoszczędzonej dziennie na osobę. Dla 120 pracowników to 27 godzin dziennie mniej czekania.
Po drugie, odpada serwer rozpoznawania mowy. Średni koszt utrzymania dedykowanej maszyny z GPU w serwerowni to około 45 tysięcy złotych rocznie, licząc amortyzację, energię i wsparcie. Terminale noszone i tak są w użyciu do skanowania kodów, więc dodatkowy koszt sprzętowy jest zerowy.
Po trzecie, niezawodność w martwych strefach Wi-Fi przestaje być tematem na spotkaniach operacyjnych. Jeden z kierowników zmiany powiedział mi wprost: 'przestałem dostawać eskalacje o padającym systemie na hali C, a to było moje 15 minut dziennie'.
Nie wszystko złoto, co się świeci
Zanim zamówicie aktualizację firmware'u na wszystkie terminale, warto wiedzieć o dwóch rzeczach. Indeks HNSW zajmuje pamięć. Dla słownika 800 komend i trzech języków to około 200 MB dodatkowego RAM-u na urządzeniu. Terminale z 2 GB RAM radzą sobie bez problemu, ale starsze modele z 1 GB mogą wymagać wymiany.
Druga sprawa: to rozwiązanie działa najlepiej przy małych batchach, czyli dokładnie w scenariuszu pojedynczych komend od pracownika. Nie sprawdzi się przy masowym przetwarzaniu nagrań z całej zmiany naraz. Ale do tego służy serwer.
- Czas reakcji systemu spada z 1,2 s do 0,18 s na komendę
- Odpada konieczność utrzymywania serwera rozpoznawania mowy z GPU
- System działa niezawodnie w strefach bez zasięgu Wi-Fi
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.
