gik|iewicz

Projekt FeSens/openTPU stawia pytanie, czy sztuczna inteligencja może zaprojektować chip, na którym sama działa. Odpowiedzią jest openTPU, czyli otwarty akcelerator inferencji AI, którego hardware stworzyły agenty AI. Repozytorium liczy obecnie 333 gwiazdki na GitHubie i działa na prawdziwej karcie PCIe.

TL;DR: OpenTPU to otwarty akcelerator inferencji AI, którego hardware zaprojektowały agenty AI. Projekt obejmuje kod RTL w SystemVerilog, ISA, symulator bit-exact, język kerneli z kompilatorem oraz oprogramowanie sterujące kartą PCIe. Całość działa na karcie Kintex-7 i uruchamia dziesięć współczesnych modeli z prawdziwymi wagami, między innymi LFM2.5-230M oraz Qwen3-0.6B, przy pełnej zgodności tokenów z symulatorem.

Czym jest OpenTPU i kto go zaprojektował?

OpenTPU to akcelerator inferencji AI o otwartym kodzie, którego sprzęt zaprojektowały agenty AI. Projekt żyje w publicznym repozytorium FeSens/openTPU i jest udostępniony na licencji Apache 2.0. Zgodnie z opisem projektu opiera się on na doświadczeniach wcześniejszego repozytorium auto-arch-tournament, przenosząc wnioski z niego na akceleratory AI.

Źródła podają, że projekt stawia sobie dwa pytania, które sformułowano wprost: jak daleko agenty AI mogą zajść w projektowaniu hardware’u oraz czy są w stanie zbudować chip, który uruchamia ich własną inferencję. Autor zauważa, że wyniki benchmarków pokazują, że to już się dzieje. Ponadto openTPU pełni rolę projektu edukacyjnego, ponieważ cały akcelerator mieści się w jednym niewielkim monorepo, które można przeczytać od początku do końca.

Dla osób chcących zrozumieć, jak działa akcelerator AI, projekt stanowi według autora dobre miejsce na start. Ścieżka nauki prowadzi od mnożenia macierzy w Pythonie aż po same przewody. Co więcej, cały stos technologiczny spina się w jednym miejscu, co ułatwia analizę zależności między poszczególnymi warstwami.

Jakie elementy akceleratora stworzyły agenty AI?

Pierwszą z nich jest kod RTL napisany w języku SystemVerilog, czyli sama konstrukcja sprzętowa akceleratora. Drugą warstwę stanowi instrukcja ISA, opisująca zestaw instrukcji procesora.

Pozostałe elementy to symulator bit-exact, język kerneli wraz z jego kompilatorem oraz oprogramowanie hosta sterujące kartą PCIe. W opisie repozytorium mowa przy tym o profilującym elemencie zestawu, wymienionym obok kompilatora jako część jednego repozytorium. W rezultacie cały projekt, od instrukcji po narzędzia pomiarowe, znajduje się w jednym miejscu.

Taka kompletność wyróżnia openTPU na tle typowych projektów open-source. Zamiast rozproszenia po wielu repozytoriach całość jest spójna i czytelna. Mianowicie opis na GitHubie podkreśla, że RTL, ISA, symulator, kompilator i profiler znajdują się w jednym repozytorium, co ułatwia zrozumienie całego stosu.

Na jakim sprzęcie działa OpenTPU?

Zgodnie z README projekt działa na karcie Inspur YPCB-00338 opartej na układzie Xilinx Kintex-7 xc7k480t. Karta posiada dwa kanały pamięci DDR3, co potwierdzają dane techniczne podane w dokumentacji projektu. Sprzęt łączy się z komputerem przez magistralę PCIe i jest sterowany przez oprogramowanie hosta.

Wybór klasycznej karty FPGA oznacza, że projekt można odtworzyć na dostępnym sprzęcie. Do tego celu służy wspomniane oprogramowanie hosta, które uruchamia realne zadania na karcie. Na przykład materiał ilustracyjny w README pokazuje aplikację otpu-chat działającą na karcie FPGA, obok narzędzia otpu-smi, które wyświetla wykorzystanie karty oraz przepustowość pamięci DRAM.

Taki zestaw pozwala obserwować pracę akceleratora w czasie rzeczywistym. Ponadto zgodność zachowania sprzętu i symulacji została zweryfikowana. Według dokumentacji karta produkuje te same tokeny co symulator, bit po bicie, co potwierdza poprawność implementacji.

Jakie modele uruchomiono na OpenTPU i z jakimi wynikami?

Zgodnie z README projekt uruchamia dziesięć współczesnych modeli z ich prawdziwymi wagami. Wśród potwierdzonych modeli znajdują się LFM2.5-230M, Qwen3-0.6B, Qwen3.5-0.8B oraz Gemma 4 E2B. Wagi testowano w dwóch wariantach, a mianowicie w kwantyzacji int8 oraz 4-bit z głowicą int8.

Wyniki dekodowania prezentują się następująco:

Pomiary pokazują także obciążenie pamięci DRAM podczas dekodowania. Dla modelu LFM2.5-230M w wersji int8 wyniosło ono 14.5 GB/s, co stanowi 85 procent wartości szczytowej. Natomiast dla Gemma 4 E2B odnotowano 15.6 GB/s, czyli 92 procent. Najważniejsze jest jednak to, że te liczby pochodzą z realnego hardware’u, a nie z samej symulacji. Dlatego stanowią potwierdzony punkt odniesienia dla możliwości tej architektury.

Co dokładnie pokazują benchmarki projektu?

Benchmarki openTPU pochodzą z realnej karty FPGA, a nie z samej symulacji. Dla LFM2.5-230M w int8 urządzenie dekoduje 59.0 tok/s, a w wersji 4-bit z głowicą int8 aż 85.8 tok/s. Qwen3-0.6B osiąga 21.6 tok/s w int8, Qwen3.5-0.8B w 4-bit 24.5 tok/s, a Gemma 4 E2B w 4-bit 10.57 tok/s. Te liczby pozwalają porównać modele i kwantyzacje na tym samym sprzęcie.

Pomiary obejmują również dekodowanie mierzone od strony aplikacji, czyli tzw. wall time. Dla LFM2.5-230M w 4-bit wynosi ono 82.1 tok/s wobec 85.8 tok/s na urządzeniu, co oznacza niewielki narzut hosta. W rezultacie dane z tabeli pokazują zarówno wydajność samego akceleratora, jak i realne wrażenia użytkownika.

Warto też spojrzeć na prefill, czyli fazę przetwarzania kontekstu. LFM2.5-230M w 4-bit osiąga tutaj 335.4 tok/s, a Qwen3-0.6B w int8 92.1 tok/s. Z kolei Gemma 4 E2B w wariancie 4-bit z głowicą 4-bit dekoduje 12.14 tok/s. Ponadto pełna tabela w README projektu zawiera także obciążenie pamięci DRAM dla każdego wariantu, dzięki czemu można śledzić zachowanie całego układu, a nie tylko licznik tokenów.

Po co OpenTPU zawiera symulator bit-exact i własny język kerneli?

Symulator bit-exact służy do weryfikacji, ponieważ karta FPGA produkuje dokładnie te same tokeny co symulacja, bit po bicie. Zgodnie z README ta zgodność została potwierdzona dla wszystkich uruchomionych modeli. Dzięki temu deweloper może sprawdzać poprawność zmian w oprogramowaniu bez fizycznego dostępu do sprzętu przy każdym teście.

Z kolei język kerneli wraz z kompilatorem pozwala opisywać obliczenia wykonywane na akceleratorze w formie bliższej programiście niż surowa ISA. W repozytorium znajduje się on obok symulatora, profilera i kodu RTL, w jednym spójnym monorepo. Taka struktura ułatwia zrozumienie, jak kod kernela zamienia się w instrukcje, a instrukcje w sygnały na układzie.

Ponadto pełny łańcuch narzędzi ogranicza liczbę miejsc, w których mogą pojawić się rozbieżności. Skoro symulator jest bit-exact i sprzęt generuje identyczne tokeny, to cały stos zachowuje się przewidywalnie. Dlatego README opisuje projekt jako miejsce do nauki, gdzie można prześledzić ścieżkę od mnożenia macierzy w Pythonie aż po same przewody. W opisie projektu na GitHubie ta kompletność jest wprost wymieniona jako cecha wyróżniająca.

Czy OpenTPU nadaje się do nauki o akceleratorach AI?

Według samego projektu openTPU jest również projektem edukacyjnym. Cały akcelerator mieści się w jednym niewielkim monorepo, które można przeczytać od początku do końca. README podaje wprost, że jeśli ktoś chce zrozumieć, jak działa akcelerator AI od mnożenia macierzy w Pythonie po fizyczne przewody, to jest to dobre miejsce na start.

Materiał obejmuje kilka warstw, na których można się uczyć:

• projekt sprzętowy w SystemVerilog, czyli kod RTL akceleratora,
• zestaw instrukcji ISA opisujący działanie procesora,
• symulator bit-exact pozwalający weryfikować zachowanie bez sprzętu,
• język kerneli z kompilatorem, spinający kod z instrukcjami,
• oprogramowanie hosta sterujące kartą PCIe,
• profiler oraz narzędzia otpu-chat i otpu-smi do obserwacji pracy karty.

Co więcej, wszystkie warstwy powstały w jednym projekcie, więc ich zależności są spójne. Czytelnik widzi te same nazwy i struktury od poziomu aplikacji aż po sprzęt. Mimo to nauka wymaga podstaw programowania, ponieważ materiał obejmuje pełny stos od języka Python po SystemVerilog. Dla początkujących może to być spore wyzwanie, ale za to kompletne.

Na jakiej licencji udostępniono projekt i jak przyjęła go społeczność?

Projekt openTPU jest udostępniony na licencji Apache 2.0 i żyje w publicznym repozytorium FeSens/openTPU. Oba fakty potwierdzają zarówno artykuł w serwisie Ecosistema Startup, jak i dane widoczne na stronie repozytorium. Licencja pozwala na przeglądanie, wykorzystywanie i modyfikowanie kodu na warunkach tej licencji.

Reakcja społeczności jest widoczna w licznikach GitHuba. Repozytorium liczy obecnie 333 gwiazdki oraz 19 forków, a na stronie projektu widoczni są dwaj współtwórcy. Ponadto projekt nie ma otwartych zgłoszeń issues, choć na rzetelność tej obserwacji wpływa młodość repozytorium, której źródła nie precyzują.

Dla porównania wiele projektów sprzętowych open-source kończy na samym kodzie bez działającego sprzętu. Tymczasem openTPU pokazuje działającą kartę PCIe z aplikacją otpu-chat i monitoringiem otpu-smi. Zatem społeczność zyskała nie tylko opis idei, lecz również kompletne, uruchamialne narzędzia. Wobec tego można oczekiwać, że liczba gwiazdek będzie dalej rosła, choćby ze względu na nietypowy rodowód projektu.

Co OpenTPU mówi o możliwościach AI w projektowaniu sprzętu?

OpenTPU dostarcza konkretnego dowodu, że agenty AI potrafią zaprojektować działający układ. Według opisu projektu agenty stworzyły pięć warstw, począwszy od kodu RTL w SystemVerilog, przez ISA, symulator bit-exact, język kerneli z kompilatorem, aż po oprogramowanie hosta. Wynikiem nie jest jedynie koncepcja, lecz karta PCIe, na której działa dziesięć współczesnych modeli z prawdziwymi wagami.

Projekt stawia dwa pytania i odpowiada na nie własnymi benchmarkami. Pierwsze brzmi, jak daleko agenty AI mogą zajść w projektowaniu hardware’u, a drugie, czy są w stanie zbudować chip, który uruchamia ich własną inferencję. Ponadto projekt opiera się na doświadczeniach wcześniejszego repozytorium auto-arch-tournament, co sugeruje iteracyjną drogę rozwoju tej metody.

Na przykład zgodność bit-exact między kartą a symulatorem pokazuje, że wygenerowany kod jest nie tylko zgodny składniowo, lecz także poprawny funkcjonalnie. To odróżnia openTPU od projektów, w których AI wspiera jedynie fragmenty procesu.

Często zadawane pytania

Kto zaprojektował OpenTPU?

Sprzęt openTPU zaprojektowały agenty AI, co jest główną tezą projektu. Obejmuje to kod RTL w SystemVerilog, ISA, symulator bit-exact, język kerneli z kompilatorem oraz oprogramowanie hosta sterujące kartą PCIe. Projekt żyje w repozytorium FeSens/openTPU i opiera się na doświadczeniach wcześniejszego repozytorium auto-arch-tournament.

Jakie modele można uruchomić na OpenTPU?

Projekt uruchamia dziesięć współczesnych modeli z ich prawdziwymi wagami. Wśród potwierdzonych są LFM2.5-230M, Qwen3-0.6B, Qwen3.5-0.8B oraz Gemma 4 E2B. Wagi testowano w kwantyzacji int8 oraz 4-bit z głowicą int8, a najlepszy zmierzony wynik dekodowania to 85.8 tok/s dla LFM2.5-230M w 4-bit.

Na jakiej karcie działa OpenTPU?

Zgodnie z README projekt działa na karcie Inspur YPCB-00338 opartej na układzie Xilinx Kintex-7 xc7k480t. Karta posiada dwa kanały pamięci DDR3 i łączy się z komputerem przez magistralę PCIe. Karta produkuje te same tokeny co symulator, bit po bicie.

Czy kod OpenTPU jest publicznie dostępny?

Tak, projekt jest dostępny publicznie w repozytorium FeSens/openTPU na GitHubie i został wydany na licencji Apache 2.0. Cały akcelerator, od RTL po profiler, znajduje się w jednym monorepo.

Podsumowanie

OpenTPU pokazuje, że agenty AI potrafią zaprojektować kompletny akcelerator inferencji, od SystemVerilog po oprogramowanie hosta. Projekt działa na realnej karcie z układem Kintex-7 i uruchamia dziesięć modeli z prawdziwymi wagami. Zgodność bit-exact między sprzętem a symulatorem potwierdza poprawność wygenerowanego kodu. Ponadto licencja Apache 2.0 oraz czytelne monorepo czynią projekt dostępnym dla każdego, kto chce zrozumieć budowę akceleratora AI. Wreszcie benchmarki, takie jak 85.8 tok/s dla LFM2.5-230M w 4-bit, dają twarde dane zamiast obietnic.

Jeśli temat projektowania sprzętu przez AI jest bliski Twoim zainteresowaniom, przejrzyj repozytorium FeSens/openTPU i przeczytaj README od początku do końca. To jedna z niewielu okazji, by zobaczyć pełny stos akceleratora w jednym miejscu. Obserwuj projekt na GitHubie, aby śledzić dalszy rozwój, i podziel się własnymi wnioskami z tej lektury w komentarzach na blogu.