Typowym wzorcem, który zaobserwowaliśmy, jest to, że budowanie i wdrażanie modelu ML do celów produkcyjnych jest wykonywane przez różne zespoły, zazwyczaj zespół algorytmów ML i zespół obsługujący urządzenia. Zespół ML zajmuje się szkoleniem i oceną modeli, podczas gdy zespół ds. urządzeń jest odpowiedzialny za migrację modelu do środowiska produkcyjnego.

Taka separacja wynika częściowo z faktu, że uczenie i wnioskowanie rozeszły się, zarówno w odniesieniu do platform sprzętowych, jak i stosów oprogramowania. W przeszłości używaliśmy Caffe na serwerze GPU zarówno do trenowania, jak i udostępniania. W dzisiejszych czasach ludzie używają potężnych narzędzi i serwerów do szkolenia, a następnie wdrażają modele w wysoce zoptymalizowanych środowiskach wykonawczych i na różnych urządzeniach. Problemy z wdrażaniem są często napotykane ze względu na złożoność modelu i ograniczenia sprzętowe, a zespół ML zwykle musi polegać na opiniach zespołu obsługi urządzenia, aby rozwiązać te problemy.

W rezultacie inżynierom uczenia maszynowego (MLE) często brakuje bardzo podstawowych informacji na temat możliwości wdrożenia ich własnych modeli. Dzisiejsze wdrożenie modelu to często wewnętrzny potok składający się z wielu skryptów Bash/Python obejmujących różne maszyny i środowiska. Obejmuje również wiele bibliotek open source lub zestawów narzędzi specyficznych dla dostawcy do konwersji modelu, kwantyzacji, dostrajania wydajności i weryfikacji dokładności. Nie jest to przyjemne doświadczenie w porównaniu z tworzeniem modeli w natywnym dla chmury środowisku Pythona.

Oprócz złożoności narzędzi, innym problemem jest brak możliwości interpretacji wydajności. Raporty profilowania z łańcuchów narzędzi podrzędnych często wymagają wiedzy o domenie, aby zrozumieć i przekonwertować je na praktyczne spostrzeżenia modelu, jak w poniższym przykładzie TensorRT. Wraz z długim potokiem konwersji modelu programistom ML trudno jest zidentyfikować rzeczywiste wąskie gardła wydajności własnych modeli i wprowadzić odpowiednie zmiany.

Pomimo tych wad rozdzielenie projektowania i wdrażania modeli jest nadal normą w branży, ponieważ zazwyczaj wymagają one zupełnie innych umiejętności. „Już teraz trudno jest zatrudnić eksperta ML lub eksperta od urządzeń, nie mówiąc już o ekspertach w obu przypadkach”, to wciąż słyszymy od naszych klientów. Ale to nie znaczy, że powinniśmy dalej tolerować obecny przepływ pracy ML.

W oprogramowaniu 1.0 trudno sobie wyobrazić, że program jest napisany przez jednego inżyniera i skompilowany przez innego inżyniera. Programiści mogą samodzielnie skompilować kod, mając niewielką lub żadną wiedzę na temat podstawowych etapów, takich jak asembler i łączenie, a jednocześnie mogą uzyskiwać znaczące informacje, aby poprawić swój kod. Bez takich spostrzeżeń proces debugowania mógłby przekształcić się w niekończącą się wymianę zdań między dwoma inżynierami, którzy nie mówią swoim językiem.

Do tej pory najczęstsze problemy, które opóźniały wdrażanie modeli ML, to:

1. Niedopuszczalne opóźnienie/przepustowość
2. Nieobsługiwani operatorzy
3. Niezgodność dokładności

Rozwiązaniem jest prosty i zrozumiały przepływ pracy do wdrażania i diagnozowania modelu. Interfejs, którego inżynierowie ML mogą używać i rozumieć samodzielnie, znacznie poprawi produktywność.

Zbudowanie super wydajnego kompilatora ML to tylko część rozwiązania, ponieważ istnieją pewne fundamentalne różnice między oprogramowaniem 2.0 a oprogramowaniem 1.0: po pierwsze, nowi operatorzy są stale wprowadzani ze środowiska akademickiego i wielu z nich nie można skomponować z istniejących; po drugie, modele ML mogą tolerować zastępowanie operatorów, które nie zachowują funkcjonalności , i nadal zachowują podobną dokładność, co zapewnia większą elastyczność dostosowywania dla programistów ML. Nie będziemy jednak zagłębiać się w szczegóły, bo chyba warto poświęcić osobny blog na temat dostosowywania modelu do wdrożenia.

W OmniML zaczęliśmy od zbudowania wewnętrznego narzędzia dla naszych inżynierów do wdrażania i profilowania ich modeli ML bez kłopotliwego studiowania sprzętu i jego łańcucha narzędzi ML. Szybko zdaliśmy sobie sprawę, że takie narzędzie zwiększa wydajność. Ponadto ten ujednolicony, bogaty w informacje interfejs umożliwia zarówno ludziom, jak i algorytmom odblokowanie wspaniałych możliwości optymalizacji modeli. Dlatego te funkcje są teraz formalnie dostępne w produktach OmniML: Omnimizer i Omnimizer Enterprise .

Omnimizer — zunifikowana platforma do optymalizacji i wdrażania modeli

Omnimizer jest przeznaczony przede wszystkim dla inżynierów ML, którzy projektują i szkolą modele PyTorch. Pomaga im zidentyfikować wady projektowe i skrócić czas produkcji.

Omnimizer zapewnia interfejs natywny dla PyTorch i natywny dla chmury, aby szybko przetestować model na docelowym sprzęcie. Użytkownicy muszą tylko określić konfigurację wdrożenia wysokiego poziomu, a następnie wysłać żądanie do chmury urządzeń hostowanych przez OmniML. Kluczowe informacje o wdrożeniu, w tym ogólne opóźnienie, opóźnienie w warstwach i ewentualne błędy wdrożenia, zostaną przekazane w najprostszy sposób zrozumiały dla eksperta niezwiązanego ze sprzętem.

Omnimizer pozwala użytkownikom łatwo porównać dokładność urządzenia z oryginalnym modelem. Pozbywa się kłopotów związanych z przenoszeniem modelu i danych na inne urządzenie, zapoznawaniem się z różnymi systemami operacyjnymi i łańcuchami narzędzi oraz utrzymywaniem wielu zdezorganizowanych i pełnych błędów skryptów. W poniższym przykładzie użytkownicy mogą uzyskać dane wyjściowe modelu w interfejsie podobnym do PyTorch, podczas gdy rzeczywiste wnioskowanie odbywa się na zdalnym urządzeniu, np. procesorze graficznym klasy serwerowej lub smartfonie.

Omnimizer to nie tylko biblioteka oprogramowania, ale także platforma MLOps, która zapewnia przyjazny dla użytkownika interfejs do poruszania się po szczegółach wydajności, dzielenia się spostrzeżeniami z modelu i odtwarzania środowisk wdrożeniowych. Użytkownicy mogą przeglądać kroki wdrażania, uzyskiwać porównawcze opóźnienia i lepiej rozumieć swój model na sprzęcie.

Omnimizer Enterprise — Uwolnij pełny potencjał sprzętu AI

W porównaniu z wersją społecznościową, która pomaga wdrażać i optymalizować modele, wersja korporacyjna zapewnia zautomatyzowaną optymalizację modelu w oparciu o lata badań nad wyszukiwaniem architektury neuronowej (NAS) i szerokie dostosowywanie do potrzeb przedsiębiorstwa.

NAS zawsze był uważany za kosztowny proces, który wymaga głębokiej wiedzy w zakresie przestrzeni wyszukiwania i projektowania zadań proxy. Dzięki Omnimizerowi każdy użytkownik może zastosować NAS, aby dostosować swoje modele do sprzętu docelowego. Proces ten wymaga zaledwie kilku linijek zmiany kodu, niskich kosztów szkolenia i, co najważniejsze, braku wymogu bycia ekspertem w zakresie projektowania modeli i wydajności sprzętu.

Omnimizer można łatwo zintegrować z repozytoriami typu open source i przyspieszyć gotowe modele przy niewielkiej ręcznej optymalizacji. Jak dotąd OmniML i jego klienci wykazali przyspieszenie 1,2–6,8x na platformach NVIDIA i Qualcomm. Te repozytoria będą otwarte dla użytkowników korporacyjnych jako przykłady:

• YOLO-X (wykrywanie obiektów)
• EfficientDet (wykrywanie obiektów)
• YOLO-P (model wielozadaniowy do jazdy autonomicznej)
• DDRNet (segmentacja semantyczna)
• ResNet (klasyfikacja obrazu)
• DD3D (wykrywanie obiektów 3D)
• RAFT (przepływ optyczny)
• DistilBERT (tłumaczenie maszynowe)

Wypróbuj Omnimizer!

Beta Omnimizera właśnie została wydana. Zarejestruj się teraz na stronie OmniML i zacznij optymalizować swój przepływ pracy!

Di Wu, Song Han, Lucas Liebenwein, Riyad Islam, Keval Morabia, 
Asma K.T. Beevi, Henry Guo and Shengliang Xu also contributed to this article.