Microsoft Olive: kiedy optymalizować model AI

Microsoft Olive ma sens wtedy, gdy model działa już poprawnie, lecz nie spełnia wymagań konkretnego sprzętu dotyczących opóźnienia, pamięci, rozmiaru albo przepustowości. Narzędzie pomaga składać i oceniać techniki konwersji, kwantyzacji oraz optymalizacji dla ONNX Runtime. Nie gwarantuje jednak, że każdy model przyspieszy bez utraty jakości. Potrzebne są pomiary na docelowym urządzeniu i własnym zbiorze testowym.

Co optymalizuje Microsoft Olive

Olive jest otwartym zestawem narzędzi do optymalizacji modeli uruchamianych przez ONNX Runtime. Typowe wejście stanowi model PyTorch lub model z Hugging Face, a wynikiem jest wariant ONNX przygotowany dla wskazanego CPU, GPU lub NPU. Workflow składa się z uporządkowanych kroków, takich jak przechwycenie grafu, konwersja, kwantyzacja, kompresja i strojenie parametrów wykonania. Omówienie Microsoft Olive.

Olive nie jest usługą do trenowania kompletnej aplikacji AI ani zamiennikiem testów modelu. Optymalizuje artefakt oraz jego wykonanie. Warstwa danych, interfejs, bezpieczeństwo i logika biznesowa pozostają odpowiedzialnością zespołu wdrożeniowego.

Sygnał	Czy rozpoczynać optymalizację?	Następny krok
Model nie spełnia jakości	Nie	Popraw dane, model lub sposób oceny
Model nie mieści się w pamięci	Tak	Zmierz rozmiar i zbadaj kwantyzację
Opóźnienie przekracza limit	Tak	Profiluj na docelowym sprzęcie
Brak docelowego urządzenia	Jeszcze nie	Zabezpiecz reprezentatywne środowisko
Koszt infrastruktury jest za wysoki	Tak	Policz koszt na zaakceptowany wynik

Ustal bazę przed zmianą modelu

Najpierw uruchom niezmieniony model na sprzęcie, na którym ma pracować produkcyjnie. Zapisz wersję modelu, biblioteki, sterownika, systemu, Execution Provider i parametry sesji. Zmierz czas pierwszego uruchomienia, opóźnienie kolejnych wywołań, przepustowość, zużycie pamięci, rozmiar artefaktu i energię, jeżeli ma znaczenie dla urządzenia.

Przygotuj dwa zbiory: kalibracyjny potrzebny przez wybraną technikę oraz niezależny zbiór odbiorczy. Ten drugi powinien reprezentować łatwe, trudne i krytyczne przypadki biznesowe. Jeżeli zespół poprawia workflow na podstawie wyników odbiorczych, przestają one być wiarygodnym testem końcowym.

Przykład syntetyczny: model bazowy osiąga 91% poprawnych klasyfikacji i medianę 240 ms. Wariant skwantyzowany osiąga 89,5% oraz 105 ms. Średnia utrata 1,5 punktu procentowego może być nieakceptowalna, jeśli dotyczy jednej krytycznej klasy. Decyzja wymaga wyniku per kategoria, nie tylko jednej liczby.

Wydajność mierz przy rzeczywistym rozmiarze wsadu i typowej długości wejścia. Osobno sprawdź zimny start, serię równoległych żądań oraz najdłuższe przypadki. Wynik z laptopa programisty nie zastąpi pomiaru na docelowym urządzeniu z uruchomionymi pozostałymi procesami. Ustal także limit temperatury, poboru energii lub czasu pracy na baterii, jeżeli model działa na brzegu sieci.

Dobierz workflow do urządzenia

Polecenie olive optimize może pobrać model, przeprowadzić kwantyzację, konwersję do ONNX i optymalizację grafu. Użytkownik wskazuje między innymi precyzję, urządzenie i Execution Provider. Dokumentacja polecenia optimize. Wygodny automat nadal wymaga sprawdzenia wygenerowanej konfiguracji oraz artefaktu.

W bardziej kontrolowanym procesie workflow jest zapisany w YAML lub JSON i zawiera kolejność kroków. Dokumentacja pokazuje przykład konwersji, dynamicznej kwantyzacji i strojenia parametrów sesji. Uruchamianie workflow Olive. Taki plik warto wersjonować razem z kodem i definicją testów.

Próba	Porównywane wartości	Warunek zaliczenia
Jakość	Baza i kandydat na stałym zbiorze	Brak przekroczenia limitu błędu
Opóźnienie	Mediana oraz wysoki percentyl	Limit spełniony po rozgrzaniu
Pamięć	Szczyt podczas realnego zadania	Zapas dla pozostałych procesów
Stabilność	Długa seria wywołań	Brak wycieku i awarii
Zgodność	Docelowy system i sterownik	Artefakt uruchamia się bez obejścia
Pakiet	Model, konfiguracja i zależności	Powtarzalne wdrożenie z czystego środowiska

Nie utożsamiaj mniejszego modelu z lepszym wdrożeniem

Kwantyzacja zmniejsza precyzję reprezentacji i często redukuje pamięć oraz koszt obliczeń, ale wpływ na jakość zależy od modelu, zadania, danych i sprzętu. Konwersja grafu może również ujawnić nieobsługiwane operatory. Dlatego każdy kandydat musi przejść pełny test, nawet jeśli narzędzie zakończyło workflow bez błędu.

Olive potrafi oceniać kandydatów według kilku metryk i wyszukiwać rozwiązania na froncie Pareto. „Najlepszy” model istnieje tylko względem zapisanych celów. Jeżeli evaluator mierzy wyłącznie opóźnienie, może wybrać wariant, którego jakość biznesowa jest zbyt niska. Projekt workflow i evaluatorów Olive.

Sprawdź także koszt przenośności. Artefakt zoptymalizowany dla jednego Execution Provider może nie działać równie dobrze na innym urządzeniu. Jeżeli aplikacja obsługuje kilka klas sprzętu, przygotuj osobne pakiety i testy albo świadomie wybierz mniej agresywną wspólną konfigurację.

Nie usuwaj modelu bazowego po wygenerowaniu kandydata. Jest potrzebny do regresji, analizy błędów i bezpiecznego powrotu. Nazwa pliku powinna wskazywać model źródłowy, wersję workflow, urządzenie i precyzję. W rejestrze wydania zapisz również licencję modelu oraz ograniczenia redystrybucji, bo zoptymalizowany artefakt nie zmienia warunków jego użycia.

Wprowadź kontrolę wydania

Zachowaj model wejściowy, konfigurację Olive, wersje zależności, dane kalibracyjne, skrót artefaktu i raport z testów. Kandydat powinien trafiać do produkcji dopiero po spełnieniu progów jakości i wydajności. Rollback musi przywracać zarówno plik modelu, jak i pasującą konfigurację runtime.

Po aktualizacji sprzętu, sterownika, ONNX Runtime albo danych ponów pomiary. Monitoruj opóźnienie i błędy na produkcji, ale nie zapisuj niepotrzebnych danych wejściowych. Koszt optymalizacji obejmuje także utrzymanie kilku wariantów i ponawianie oceny przy zmianie modelu.

Jeżeli optymalizacja nie spełnia progu, zatrzymaj kandydata zamiast obniżać kryteria po fakcie. Możliwe decyzje to inna precyzja, inny Execution Provider, mniejszy model źródłowy albo mocniejszy sprzęt. Każdy wariant powinien przejść ten sam zestaw testów, aby porównanie pozostało uczciwe.

W ten sposób Olive staje się kontrolowanym etapem systemu pracy z AI, a nie jednorazowym eksperymentem. Przykład modelu, który również wymaga oceny względem docelowej infrastruktury, opisuje artykuł o GPT-4o w Microsoft Azure AI.