W aplikacjach typu sklep internetowy, serwis streamingowy czy media społecznościowe często chcemy dawać użytkownikom sugestie: „Może Ci się spodoba to albo tamto”.
To tzw. rekomendacje.

Zwykle te modele siedzą w chmurze — serwer ma moc, użytkownik wysyła zapytanie, dostaje odpowiedź.
Ale coraz częściej przenosi się część modelu na urządzenia użytkownika (telefon, tablet). Dzięki temu:

  • działa szybciej (mniej czekania),
  • może być bardziej prywatnie (mniej danych leci do chmury),
  • mniej obciążenia dla serwerów.

Tylko że… telefony są różne. Jeden to rakieta, drugi ledwo zipie.
I teraz: jak upchnąć model AI na różnych urządzeniach, żeby nadal działał dobrze?

Autorzy pracy CHORD: Customizing Hybrid-precision On-device Model for Sequential Recommendation with Device-cloud Collaboration (arXiv:2510.03038)
mówią: hej, zróbmy to sprytniej.
Nie jeden model dla wszystkich, tylko każdy dostaje model o innej precyzji — dostosowany do siebie.
I to wszystko dzięki współpracy między chmurą a urządzeniem.

1. Wersja modelu dla każdego użytkownika

Wyobraź sobie, że masz aplikację sklepu.
Użytkownik A ma wypasionego flagowca, a użytkownik B — tani telefon sprzed kilku lat.

Jeśli dasz im ten sam model rekomendacji, to:

  • A: spoko, działa szybko i dokładnie;
  • B: telefon się grzeje, laguje, bateria leci jak woda.

Można by więc dać każdemu inną wersję modelu. Ale jak?
Nie będziesz przecież trenować miliona wersji dla każdego użytkownika osobno.
I tu wchodzi CHORD.

CHORD robi coś takiego:

  • Dzieli model na kawałki (kanały, warstwy).
  • Dla każdego kawałka decyduje, jaką precyzję zachować (czyli ile bitów użyć).
  • Dla ważnych części — zostawia dokładność.
    Dla mniej ważnych — używa uproszczonej wersji.
  • Ta decyzja zależy od profilu użytkownika i możliwości jego urządzenia.

Czyli jak pakowanie plecaka:
rzeczy najważniejsze bierzesz w pełnym rozmiarze, resztę — w wersji mini.

A co najlepsze — to wszystko dzieje się automatycznie.
Chmura analizuje i mówi telefonowi:

„Hej, dla Ciebie ta część może być w 8 bitach, ta w 4 bitach, a ta zostaje dokładna.”

Telefon kwantuje (czyli „odchudza”) model zgodnie z tą mapą i działa dalej.
Szybciej, lżej i bez większej straty jakości.

2. Matematyka i szczegóły techniczne

Teraz wejdźmy trochę głębiej w szczegóły, ale spokojnie, da się to ogarnąć.

2.1 Problem i cel

Mamy model sekwencyjnych rekomendacji (np. SASRec, Caser).
Działa on na pełnej precyzji — powiedzmy 32-bit float.

Na urządzeniu chcemy go skwantować, czyli używać mniejszej liczby bitów — np. 8, 4 lub nawet 2.
To zmniejsza rozmiar i przyspiesza działanie, ale pogarsza dokładność.

CHORD chce zrobić hybrydową kwantyzację —
czyli różne kawałki modelu mają różną liczbę bitów, w zależności od tego, jak bardzo są „wrażliwe”.

2.2 Matematycznie

Załóżmy, że mamy wagi $W$, a po kwantyzacji dostajemy $\tilde W$:

$$ \tilde W = Q(W; b) $$

gdzie $Q$ to funkcja kwantyzacji, a $b$ to liczba bitów.

Błąd kwantyzacji:

$$ E = W - \tilde W $$

Wpływ błędu na stratę modelu można przybliżyć przez:

$$ \Delta L \approx \frac{\partial L}{\partial W} \cdot E $$

Im większe $|E|$ w miejscach, gdzie gradient jest duży, tym większy wpływ na wynik.
Tak CHORD ocenia, które kanały wymagają większej precyzji.

2.3 Hypernetwork i mapa bitów

Aby nie liczyć tego wszystkiego dla każdego użytkownika od zera,
CHORD używa tzw. hypernetworku, który generuje mapę precyzji na podstawie profilu użytkownika $u$:

$$ B(u) = f_{\text{hyper}}(u; \theta) $$

gdzie $\theta$ to parametry hypernetworku,
a $B(u)$ to mapa bitów dla poszczególnych kanałów modelu.

Ta mapa ($B(u)$) mówi:

„Ten kanał daj w 8 bitach, ten w 4, ten w 2.”

Potem telefon kwantuje model zgodnie z tym planem:

$$ \tilde W = Q(W; B(u)) $$

i już — gotowy, spersonalizowany model działa lokalnie.

2.4 Pipeline krok po kroku

  1. W chmurze: trenujesz duży model bazowy.
  2. Analiza wrażliwości: sprawdzasz, które części modelu są bardziej „delikatne”.
  3. Hypernetwork: uczy się mapować profil użytkownika → mapa bitów.
  4. Na urządzeniu: dostajesz mapę $B(u)$, kwantujesz lokalnie i używasz modelu.
  5. Bez trenowania lokalnego – oszczędzasz baterię i czas.

Efekt: model prawie tak dokładny jak oryginał, ale działa szybciej i lekko.

3. Jak to można wykorzystać w praktyce

No dobra, ale gdzie to się przyda?

  • Aplikacje mobilne z rekomendacjami: sklepy, social media, serwisy wideo.
    Rekomendacje generowane lokalnie, szybciej, bardziej prywatnie.
  • Offline lub słaby net: gdy chmura jest niedostępna, lokalny model działa dalej.
  • Oszczędzanie baterii: mniej operacji = dłuższe życie telefonu.
  • Prywatność: dane użytkownika nie lecą do chmury, tylko model.
  • Mnóstwo różnych urządzeń: każdy telefon może dostać model „na miarę”.

Można to też rozszerzyć:
model mógłby się adaptować w czasie (profil użytkownika się zmienia),
albo mieć tryby: eco (oszczędzanie energii) i turbo (maksymalna dokładność).

4. Podsumowanie – po co to komu

Podsumowując:

  • CHORD pokazuje, że można łączyć personalizację + kwantyzację sprytnie.
  • Nie trzeba trenować lokalnie — wystarczy współpraca z chmurą.
  • Efekt to mniejszy model, szybsze działanie i prawie ta sama jakość.
  • Działa to szczególnie dobrze w systemach rekomendacyjnych.

Po chłopsku:
to jak robienie mebli z różnych materiałów —
tam, gdzie trzeba, używasz litego drewna, a gdzie indziej lekkiej sklejki.
Efekt? Stabilne, a nie waży tony.

CHORD to właśnie taki sprytny sposób na AI dla telefonów:
nie za ciężko, nie za lekko — po prostu w sam raz.

📚 Na podstawie publikacji 📄 arXiv:2510.03038