24 godziny i 1000 wywołań narzędzi: co naprawdę udowadnia case study z kernelami

Układ eksperymentu

Meta sprawdziła, jak Muse Spark 1.2 radzi sobie z iteracyjną optymalizacją kerneli GPU na przestrzeni ponad 1000 wywołań narzędzi, w przebiegach trwających do 24 godzin. Wewnątrz agentowego środowiska Muse Code model pisze kernel, kompiluje go, profiluje względem dostarczonego baseline’u i na podstawie danych z profilera próbuje ponownie — ciasna pętla „napisz–skompiluj–sprofiluj–popraw“ utrzymana przez pełną dobę. Celem benchmarku były kernele atencji KDA i MLA na GPU NVIDIA Hopper.

Jedna zasada uczyniła ten test uczciwym: modelom zabroniono importowania zewnętrznych bibliotek kerneli, takich jak FLA. Żadnego opakowywania cudzej szybkiej implementacji i przypisywania sobie zasług — agent musiał użyć prawdziwej wiedzy o optymalizacji kerneli i samodzielnie zaimplementować algorytmy w Tritonie.

Co agent faktycznie zbudował

Rozwiązania nie były generyczne. Dla KDA — porównywanego z implementacją FLA w Tritonie — Muse Spark 1.2 zestawił chunk-równoległy kernel przygotowawczy z sekwencyjnym skanem między chunkami, łącząc standardową fuzję i tiling z zagraniami specyficznymi dla KDA, jak ponowne wycentrowanie bramkowanego skumulowanego zaniku w środku chunka. Dla MLA — mierzonego względem referencji w PyTorchu przy batch size 1, 64 głowicach, długości sekwencji 8192 i wymiarze latentnym 512 — zaprojektował dwukernelowy pipeline w Tritonie, który reużywa współdzielony latent KV zarówno jako K, jak i V.

To są optymalizacje, jakie specjalista pisze dopiero po zrozumieniu struktury algorytmu, a nie powierzchowne poprawki pętli. I co ważne, agent w miarę trwania przebiegu wciąż znajdował istotne ulepszenia względem baseline’u — postęp kumulował się przez setki iteracji, zamiast wypłaszczyć się po pierwszym zrywie.

Dlaczego prawdziwym nagłówkiem są te 24 godziny

Mnóstwo modeli potrafi poprawiać kernel przez dwadzieścia minut. Utrzymanie ukierunkowanego postępu przez całą dobę wymaga infrastruktury, której większość agentów nie ma. Ciężar dźwigają trzy elementy. Goal conditioning sprawia, że iteracja numer 700 celuje w ten sam cel co iteracja pierwsza — model był trenowany dokładnie pod to. Kompakcja kontekstu zachowuje wiedzę, która ma znaczenie (które strategie zawiodły, co powiedział profiler), nie tonąc w historii z całego dnia. A log zdarzeń czyni runtime odpornym na restarty — w ciągu 24 godzin coś się na pewno zatnie, a crash kasujący 23. godzinę uczyniłby całe ćwiczenie bezcelowym.

Co to oznacza dla zwykłej roboty

Mało który zespół optymalizuje kernele pod Hoppera. Ale kształt tego zadania — iteruj względem mierzalnego celu, ucz się z każdej próby, nie gub wątku — pasuje do masy mało efektownej inżynierii: gonienie niestabilnego zestawu testów, mozolne zbijanie rozmiaru bundle’a, migracja API po sto call site’ów naraz. To case study to dowód Mety na to, że „odpal i sprawdź jutro“ jest już realnym workflow. Metodologia ewaluacji jest opublikowana na stronie badawczej Mety; produktowa strona pracy long-horizon zaczyna się w dokumentacji.