KernelGenBench: jak LLM-y radzą sobie z pisaniem kerneli na różnym sprzęcie
Badacze stworzyli benchmark do oceny, jak dobrze modele językowe i systemy agentowe generują kernele Triton na sześciu platformach sprzętowych. Wyniki pokazują, że sukces na jednym typie sprzętu nie przekłada się automatycznie na inne.
👁 116 przeczytań
Praca pochodzi z lipca 2026 roku (aktualizacja z września 2026) i jest dostępna na arXiv pod numerem 2607.27231. Autorzy to Peiyu Zang, Jian Tao, Jialing Zhang, Yichen Yuan, Wentao Zhang, Guang Liu i Yonghua Lin. Kod i dane są publicznie dostępne.
Problem, który benchmark ma rozwiązać
Nowoczesne systemy AI opierają się na wyspecjalizowanych kernelach dla akceleratorów sprzętowych. Ich tworzenie jest coraz trudniejsze, bo rośnie różnorodność zarówno operatorów, jak i platform sprzętowych. Modele językowe i systemy agentowe obiecują zautomatyzować tę pracę, ale dotychczasowe benchmarki nie odpowiadały na pytanie, czy wyniki uzyskane na jednym źródle operatorów lub jednej platformie sprzętowej przenoszą się na inne - i ile taka przenośność kosztuje. KernelGenBench ma tę lukę wypełnić.
Co wchodzi w skład benchmarku
Benchmark używa wspólnego celu w postaci języka Triton i obejmuje sześć platform sprzętowych - autorzy twierdzą, że to najszersze wieloproducentowe pokrycie sprzętowe spośród istniejących benchmarków generowania kerneli. Benchmark dzieli się na dwa widoki analityczne. KernelGenBench-MS (Multi-Source) obejmuje 210 operatorów pochodzących z trzech źródeł: PyTorch ATen, operatorów produkcyjnych vLLM oraz zastrzeżonych procedur cuBLAS. KernelGenBench-MC (Multi-Chip) ocenia semantycznie stabilny podzbiór 110 operatorów na sześciu platformach sprzętowych.
Wyniki ewaluacji
Ewaluacja pochłonęła łącznie ponad 15 miliardów tokenów. Wykonanie agentowe poprawiało poprawność generowanych kerneli, ale żadna metoda nie dominowała we wszystkich źródłach i platformach jednocześnie. Autorzy wskazują trzy konkretne obserwacje: vLLM był najtrudniejszym wyzwaniem pod względem poprawności, cuBLAS wyznaczał najwyższy pułap wydajności, a dokładność systemu AutoKernel spadła z 87% na sprzęcie NVIDIA do 25% na platformie Iluvatar CoreX.
Poprawa jakości generowania przez agentów ma swoją cenę. Wyspecjalizowane agenty zużywały średnio 4,99 miliona tokenów na jeden skutecznie wygenerowany operator. W przypadku podejścia CUDA Optimized Skill ta liczba rosła do 6,25 miliona tokenów na operator.
Główny wniosek
Autorzy formułują wniosek, że źródło operatorów, platforma sprzętowa i rodzaj rusztowania agentowego to trzy osobne wymiary zdolności do generowania kerneli. Sukces w znajomym zestawieniu źródło-sprzęt nie jest wiarygodnym wskaźnikiem gotowości do wdrożenia produkcyjnego.
Google · Twoje źródłaPromptowy wyżej w Twoim Google - jednym kliknięciemDodaj do preferowanych źródeł →Co z tego wynika
Według mnie najważniejsza liczba w tej pracy to spadek dokładności AutoKernela z 87% do 25% przy zmianie samego sprzętu - przy identycznych operatorach. To konkretny dowód na to, że obecne systemy agentowe do generowania kerneli są kruche i silnie uzależnione od platformy, na której były trenowane lub oceniane. Z kolei koszt rzędu 5-6 milionów tokenów na jeden operator to sygnał, że automatyzacja tego rodzaju pracy jest technicznie możliwa, ale wciąż bardzo droga. Benchmark jest publicznie dostępny, co dobrze - będzie można śledzić postęp w kolejnych modelach na wspólnej skali. Dokument nie zawiera informacji o tym, jakie konkretnie sześć platform sprzętowych wchodzi w skład KernelGenBench-MC poza wymienionymi NVIDIA i Iluvatar CoreX.
Źródło: arXiv cs.AI: KernelGenBench: A Multi-Source and Multi-Chip Benchmark for LLM-based Kernel Generation (dokument z 2026-09-07). To omówienie powstało na podstawie pełnego tekstu dokumentu, nie relacji innych mediów.
Cały tydzień w AI, w jednym mailu
Wybrane premiery, narzędzia i analizy. Raz w tygodniu, prosto do skrzynki.
Zapisz się za darmo →
Podobne tematy na Promptowym
