Tego typu podejście jest szczególnie ważne w świecie sztucznej inteligencji, symulacji naukowych i coraz potężniejszych centrów danych. Dzisiejsze GPU są fenomenalne w wykonywaniu ogromnej liczby podobnych operacji, ale ta ich potęga ma pewien haczyk. Najlepiej czują się wtedy, gdy dane są uporządkowane, regularne i gęsto upakowane. Tymczasem rzeczywisty świat bardzo często taki nie jest. Pełno w nim pustych miejsc, zer i danych, z którymi komputer ostatecznie… nie musi robić absolutnie niczego.
GPU liczy zera. Dużo zer
W centrum całej historii są macierze oraz ich wielowymiarowi kuzyni, czyli tensory. Operacje na nich stanowią fundament m.in. uczenia maszynowego, symulacji naukowych czy części obliczeń związanych z grafiką. Problem w tym, że wiele takich struktur jest “rzadkich”, czyli ogromna część ich elementów ma wartość zero. Pierwszy lepszy przykład? Zdjęcie jasnego obiektu na niemal całkowicie czarnym tle. Możemy potraktować wszystkie piksele jak pełny zestaw danych i wykonywać na nich operacje albo pamiętać, że większość z nich nie wnosi niczego ciekawego. W końcu zero pomnożone przez dowolną liczbę nadal daje zero.
Czytaj też: Naukowcy zbudowali hamulec dla światła. Optyczne komputery dostały brakujący element

Na GPU robi się z tego spory problem. Rzadkie dane oznaczają bowiem nieregularne dostępy do pamięci, problemy z równomiernym rozłożeniem pracy oraz konieczność przechowywania dodatkowych informacji o tym, gdzie właściwie znajdują się wartości niezerowe. Dlatego wysokowydajne jądra dla takich obliczeń są trudne do napisania i często powstają jako tysiące linii ręcznie optymalizowanego kodu CUDA lub Tritona.
Insum sprawia, że GPU wie, gdzie nie warto zaglądać
Zespół Jaeyeona Wona z MIT, Willow Ahrens z Georgia Tech oraz Joela Emera i Samana Amarasinghe zaproponował rozwiązanie nazwane Insum, które to zostało zaprezentowane podczas konferencji ASPLOS 2026. Pomysł ten wyrasta z notacji Einsum, która pozwala bardzo zwięźle opisywać operacje wykonywane na tensorach. Problem polega na tym, że typowy zapis operacji nie niesie ze sobą wystarczającej wiedzy o sposobie przechowywania rzadkich danych. Insum wykorzystuje więc “Indirect Einsums“, w których informacje o formacie oraz położeniu wartości zostają włączone w sposób wykonywania operacji poprzez pośrednie indeksowanie.
Czytaj też: 128 kubitów bez próżni i ciekłego helu. Komputery kwantowe wchodzą pod strzechy

W uproszczeniu GPU nie dostaje już polecenia w rodzaju “przejdź przez wszystkie miejsca i zobacz, co w nich siedzi”. Dostaje mapę prowadzącą tam, gdzie rzeczywiście znajduje się coś wartego policzenia. Badacze opracowali przy tym własne formaty GroupCOO i BlockGroupCOO, które grupują niezerowe wartości tak, aby ograniczyć liczbę kosztownych odwołań do pamięci. W jednym z testów samo grupowanie zmniejszyło zapotrzebowanie na pamięć do 69 procent względem klasycznego COO, a połączenie grupowania z blokowaniem pozwoliło wykorzystać Tensor Cores.
Compiler może dodatkowo scalać pobieranie danych, mnożenie i zapis wyniku w jeden kernel, dzięki czemu pośrednie dane nie muszą niepotrzebnie wędrować do pamięci DRAM. W badanym przypadku uniknięto w ten sposób tworzenia struktur przekraczających 1,5 GB.
Prawie cztery razy szybciej, ale nie we wszystkim
Insum nie sprawi oczywiście nagle, że Cyberpunk 2077 zacznie działać cztery razy szybciej na tej samej karcie. Badacze testowali specjalistyczne, rzadkie obciążenia obliczeniowe na GeForce RTX 3090 z 24 GB pamięci, a uzyskane przyspieszenie zależało mocno od rodzaju zadania. W porównaniu z ręcznie napisanymi implementacjami rozwiązanie dawało od 1,14 do 3,81 razy wyższą wydajność. Dla strukturalnego mnożenia macierzy rzadkiej przez gęstą było to 1,95x, dla wariantu nieregularnego 1,20x, dla rzadkiej konwolucji 1,14x, a w przypadku równoważnego iloczynu tensorowego właśnie 3,81x.
Czytaj też: Naukowcy mają sześć nowych stopów do druku 3D. Wymyślił im je komputer
Dla mnie równie ciekawa jest jednak druga liczba. Te same operacje wymagały wcześniej odpowiednio 202, 1918, 225 oraz 4491 linii wyspecjalizowanego kodu. W Insum każdą z nich badacze opisali pojedynczym wyrażeniem. Sam kompilator ma około 500 linii, a modyfikacje TorchInductora kolejne około 800, a to już nie jest tylko kwestia szybkości. To bardziej próba przerzucenia ogromnej części eksperckiej optymalizacji z programisty na kompilator.
Przyszłość komputerów może polegać na liczeniu mniej
Nie oznacza to jeszcze rewolucji gotowej do wrzucenia do każdego programu. Korzyści zależą od poziomu rzadkości danych, ich struktury i kosztu konwersji do odpowiedniego formatu. Sam proces przygotowywania takich obliczeń również nie jest jeszcze całkowicie automatyczny, a kompilacja z autotuningiem w jednym z testów zajmowała 14,8 sekundy. Przy wielokrotnym wykonywaniu tego samego kernela, np. podczas inferencji modelu, taki jednorazowy koszt można jednak łatwo zamortyzować.
Właśnie dlatego uważam tę pracę za znacznie ciekawszą niż kolejną premierę GPU z jeszcze większym TDP za krocie. Pisałem już o tym dlaczego przy rosnącym zapotrzebowaniu kart graficznych i centrów danych na energię oraz przy superkomputerach próbujących odejść od klasycznego kultu GPU. Branża może oczywiście ciągle budować większe akceleratory i zasilać nimi coraz większe serwerownie, ale druga droga wydaje mi się znacznie bardziej elegancka, bo najszybsza operacja matematyczna nie zawsze jest tą wykonaną przez najpotężniejsze GPU. Czasami jest nią operacja, której komputer był wystarczająco sprytny, żeby w ogóle nie wykonywać.
Źródła: Arxiv, MIT CSAIL, ASPLOS 2026

