--- title: "Microsoft Olive: kiedy optymalizować model AI" url: "https://majchrzycki.com/blog/co-to-jest-microsoft-olive-optymalizacja-modeli" description: "Sprawdź, kiedy Microsoft Olive pomaga zoptymalizować model dla CPU, GPU lub NPU oraz jak mierzyć jakość, opóźnienie, pamięć i zgodność wdrożenia." --- # Microsoft Olive: kiedy optymalizować model AI 22 czerwca 2024· Aktualizacja: 25 września 2026·4 min czytania·Krzysztof Majchrzycki Temat: [Architektura systemów AI](https://majchrzycki.com/blog/filar/architektura-systemow-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](https://microsoft.github.io/Olive/why-olive.html). 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](https://microsoft.github.io/Olive/how-to/cli/cli-optimize.html). 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](https://microsoft.github.io/Olive/how-to/cli/cli-run.html). 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](https://microsoft.github.io/Olive/how-to/extending/design.html). 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](https://majchrzycki.com/system), 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](https://majchrzycki.com/blog/model-gpt-4o-od-openai-i-jego-wykorzystanie-w-biznesie-za-omoc%C4%85-microsoft-azure-ai). - Modele i LLM ## Przełóż temat na projekt w Twojej firmie Zobacz zakres współpracy: od rozpoznania procesu i danych po projekt rozwiązania AI. [Zobacz współpracę](https://majchrzycki.com/wspolpraca) ## Czytaj dalej - [Małe modele językowe SLM: kiedy mają sens w firmie](https://majchrzycki.com/blog/small-language-model-slm-ai) - [ONNX Runtime w suwerennym AI OS](https://majchrzycki.com/blog/onnx-runtime-ai-os) - [RLHF: co wnosi informacja zwrotna człowieka](https://majchrzycki.com/blog/czym-jest-uczenie-ze-wzmocnieniem-z-informacją-zwrotną-w-ai-rlhf-reinforcement-learning-from-human-feedback) - [Narrow AI: czym jest wąska AI i kiedy ją stosować](https://majchrzycki.com/blog/narrow-ai-czym-jest-i-jakie-ma-zastosowania-biznesowe-microsoft-azure-ai)