Dlaczego domowy asystent głosowy działa wolno, nawet gdy LLM odpowiada szybko?

Eva Wong

IceWhale author

Eva Wong jest Technicznym pisarzem i stałym majsterkowiczem w ZimaSpace. Całe życie geek z pasją do homelabów i oprogramowania open-source, specjalizuje się w tłumaczeniu skomplikowanych koncepcji technicznych na przystępne, praktyczne przewodniki. Eva wierzy, że samodzielne hostowanie powinno być zabawą, a nie czymś onieśmielającym. Poprzez swoje samouczki umożliwia społeczności rozwiewanie tajemnic konfiguracji sprzętu, od budowy pierwszego NAS po opanowanie kontenerów Docker.

Why Does a Home Voice Assistant Feel Slow Even When the LLM Responds Quickly? - Zima Store Online

Domowy asystent głosowy może wydawać się powolny, ponieważ przechwytywanie mowy, wykrywanie końca wypowiedzi, obsługa narzędzi, synteza i odtwarzanie otaczają model LLM szeregiem opóźnień przetwarzanych sekwencyjnie.

Lokalny model może wygenerować pierwszy token w 120 ms, a mimo to głośnik w kuchni odpowiada dopiero dwie sekundy po zakończeniu polecenia. Użytkownik doświadcza całej interakcji, a nie jednego wyniku testu. Wykrywanie ciszy przed wysłaniem zapytania i buforowanie dźwięku po wygenerowaniu odpowiedzi mogą osobno trwać dłużej niż szybkie wnioskowanie modelu językowego.

LLM odpowiada tylko za jeden etap interakcji głosowej

Wypowiedziana kwestia przechodzi przez buforowanie mikrofonu, wykrywanie aktywności głosowej, wykrywanie końca wypowiedzi, ASR, przygotowanie promptu, generowanie przez model, wykonywanie narzędzi, TTS i wyjście audio. Większość etapów czeka na poprzedni. Niski czas do wygenerowania pierwszego tokenu dowodzi więc tylko, że etap językowy działa szybko po otrzymaniu tekstu.

Analiza opóźnień w stosie głosowym dzieli tę ścieżkę na wiele etapów opóźnień, pokazując, dlaczego optymalizacja jednego komponentu nie gwarantuje szybkiej rozmowy. Narzut związany z sekwencyjnym przetwarzaniem kumuluje się, nawet gdy każdy etap z osobna wydaje się stosunkowo krótki.

Wykrywanie końca wypowiedzi często jest ukrytym kosztem po stronie wejścia. Asystent musi zdecydować, czy pauza oznacza koniec wypowiedzi, czy tylko chwilę namysłu. Zachowawczy limit czasu zapobiega przerywaniu, ale wydłuża ciszę przed finalizacją ASR, przez co system wydaje się niezdecydowany, mimo że LLM uruchamia się natychmiast później.

Strumieniowanie poprawia odczuwaną szybkość, ale nie eliminuje całej pracy

Częściowe transkrypcje mogą rozpocząć przygotowanie promptu, a strumieniowane tokeny mogą zasilać TTS, zanim odpowiedź zostanie ukończona. Te nakładające się działania skracają ścieżkę krytyczną. Jednak rozmiary fragmentów, kontrole bezpieczeństwa, potwierdzanie użycia narzędzi oraz ilość stabilnego tekstu wymagana przed rozpoczęciem syntezy nadal decydują o tym, kiedy pojawi się słyszalny sygnał.

Badania nad agentami głosowymi o niskich opóźnieniach łączą strumieniowe ASR, skwantyzowane modele językowe i syntezę w czasie rzeczywistym, ponieważ responsywność całego systemu zależy od koordynacji wszystkich trzech elementów, a nie tylko od raportowania szybkości modelu.

Pierwszy dźwięk ma również większe znaczenie niż końcowa długość nagrania. System, który rozpoczyna naturalną odpowiedź po 500 ms, może wydawać się szybszy niż taki, który w ciszy generuje całą odpowiedź w 900 ms. Strumieniowanie zmienia czas przekazywania informacji zwrotnej, ale nie sprawia, że powolne wywołanie narzędzia znika.

Gdzie wyjaśnienie oparte na potoku przestaje wystarczać

Opóźnienie potoku nie wyjaśnia wszystkiego, gdy asystent celowo czeka na potwierdzenie, ogranicza częstotliwość poleceń lub stosuje konwersacyjną pauzę. Poza stosem AI mogą wystąpić jitter sieciowy, przechodzenie głośnika w tryb oszczędzania energii, ponowne łączenie Bluetooth oraz czas wybudzania urządzenia audio. Szybki ślad po stronie serwera może mimo to kończyć się powolnym odtworzeniem w głośniku w pomieszczeniu.

Wskazówki dotyczące opóźnień w rozmowie zwracają uwagę, że ludzie oczekują krótkich przerw między wypowiedziami, dlatego odczuwany czas odpowiedzi jest cechą produktu, a nie statystyką pojedynczego modelu. Odczuwane opóźnienie może wzrosnąć, nawet gdy całkowity czas obliczeń pozostaje bez zmian, jeśli informacja zwrotna jest wstrzymywana.

Ten mechanizm nie wyjaśnia sytuacji, w której znaczniki czasu serwera pokazują, że odtwarzanie dźwięku zaczyna się szybko, a użytkownicy nadal zgłaszają opóźnienie. Przyczyną może być wtedy odległość akustyczna, synchronizacja urządzeń lub informacja zwrotna interfejsu. Nie wyjaśnia też powolnego pierwszego polecenia, po którym kolejne są obsługiwane szybko — to silniej wskazuje na zimny start lub przejście między stanami zasilania.

Featured

ZimaCube 2 Osobisty domowy NAS w chmurze

ZimaCube2

Mierz całą interakcję głosową, nie tylko LLM

Zapisuj jeden monotoniczny znacznik czasu dla początku przechwytywania przez mikrofon, wykrytego końca wypowiedzi, końcowej transkrypcji, wysłania promptu, pierwszego tokenu LLM, zakończenia działania narzędzia, pierwszego fragmentu TTS, kolejki odtwarzania i słyszalnego wyjścia. Wykonaj dwadzieścia krótkich poleceń oraz pięć poleceń korzystających z narzędzi, zarówno po zimnym, jak i ciepłym starcie.

Porównaj te ślady z analizą zimnych startów lokalnej AI, ponieważ ładowanie modelu może zniekształcać pomiar pierwszej interakcji, podczas gdy w kolejnych dominuje wykrywanie końca wypowiedzi. Zachowaj surowe czasy zamiast jednej połączonej wartości „czasu odpowiedzi”.

Optymalizuj największy powtarzalny przedział, a nie najbardziej widoczny model. Jeśli dominuje wykrywanie końca wypowiedzi, dostosuj wykrywanie tury; jeśli dominują narzędzia, pobieraj z wyprzedzeniem tylko bezpieczne dane; jeśli pierwszy dźwięk pojawia się długo po TTS, sprawdź buforowanie i wybudzanie głośnika. Opóźnienia związane z potwierdzeniem utrzymuj jako jawne, ponieważ celowe zabezpieczenia nie są błędem wydajności.