Ollama v0.40.12 poprawia szybkość przetwarzania promptów i szczegółowość małych obrazów

Ollama opublikowała kandydata wydania Ollama v0.40.12, zawierającego cztery zmiany dotyczące wydajności modeli lokalnych, obsługi obrazów i bazowych zależności oprogramowania. To rozróżnienie ma znaczenie: usprawnienia przetwarzania promptów i generowania wynikają z odrębnych zmian, z różnymi ograniczeniami.

Kluczową kwestią jest różnica między obsługą modelu a jego efektywnym uruchamianiem. Model może zostać pomyślnie załadowany, a jednocześnie nieefektywnie przetwarzać dokumenty lub tracić użyteczne szczegóły obrazu. To wydanie rozwiązuje konkretne przykłady tej luki, zamiast zapowiadać nową rodzinę modeli.

Porównanie wykracza także poza samo Ollama. MLX, framework Apple do tablic uczenia maszynowego, oferuje badaczom tworzącym rozwiązania wokół jego podstawowych operacji bardziej bezpośrednią ścieżkę rozwoju. Rolą Ollama jest integrowanie tych możliwości z runtime'em modeli, czyli oprogramowaniem wykonującym modele. Dla twórców aplikacji ta integracja określa, które usprawnienia upstream faktycznie trafiają do ich obciążeń.

Co faktycznie zmienia Ollama v0.40.12

To ukierunkowana aktualizacja runtime'u, a opublikowany artefakt nadal pozostaje kandydatem wydania.

Kandydat wydania ma tag v0.40.12-rc0, choć jego wyświetlany tytuł brzmi v0.40.12. GitHub oznacza go jako wersję przedpremierową i datuje na 27 października 2026 r. Porównanie rozpoczyna się od v0.40.11.

Ta różnica w nazewnictwie zasługuje na uwagę, ponieważ sam wyświetlany tytuł nie potwierdza wydania stabilnej wersji. Osoby rozważające aktualizację powinny odróżniać opublikowanego kandydata od ewentualnego późniejszego stabilnego artefaktu. Ustalenia dotyczące tej kompilacji powinny zachować jej pełny tag.

Wymienione zmiany obejmują obsługę obrazów w kompaktowej Gemma 4, aktualizacje zależności MLX, obsługę DFlash2 oraz aktualizację zależności llama.cpp. Wszystkie cztery wpisy przypisano współtwórcy dhiltgen. Łącznie opisują one prace utrzymaniowe w kilku ścieżkach wykonania, a nie jedną uniwersalną funkcję przyspieszającą.

Ten zakres sprawia, że wydanie jest istotne dla różnych grup z różnych powodów. Twórcy korzystający z objętych zmianą modeli obrazowych mają pytanie o poprawność. Twórcy oczekujący na przetwarzanie promptów mają pytanie o responsywność. Twórcy testujący obsługiwaną akcelerację generowania mają kolejne pytanie o wydajność.

Przy interpretowaniu ogłoszenia te kwestie powinny pozostać rozdzielone. Szybsze przetwarzanie dokumentów nie oznacza automatycznie szybszego generowania odpowiedzi. Zachowanie szczegółów obrazu nie potwierdza wyższej dokładności we wszystkich zadaniach wizualnych. Aktualizacja zależności nie określa korzyści dla każdego obsługiwanego urządzenia.

Użyteczną perspektywą jest zatem specyfika obciążenia. Która operacja się zmieniła, który model z niej korzysta i od której części aplikacji zależy ta operacja? Te pytania prowadzą do bardziej praktycznej interpretacji niż traktowanie każdego wpisu w changelogu jako dowodu na szeroko rozumianą szybszą lokalną AI.

W przypadku asystenta dokumentowego najistotniejsze usprawnienie może następować, zanim pojawi się jakakolwiek odpowiedź. Dla asystenta obsługującego zrzuty ekranu może dotyczyć informacji zachowanych z danych wejściowych. W aplikacji generującej dłuższe odpowiedzi dokładniejszej analizy może wymagać ścieżka generowania.

Są to przykłady analityczne, a nie opisane wdrożenia u klientów. Pokazują, dlaczego to samo wydanie może mieć różne znaczenie dla aplikacji korzystających z identycznego interfejsu. Widoczny produkt może pozostać znajomy, podczas gdy wykonywana pod nim praca się zmienia.

Aktualizacja skłania również opiekunów aplikacji do ponownego przeanalizowania wcześniejszych założeń. Poprzednie porównanie może odzwierciedlać wcześniejszą ścieżkę wykonania, a nie trwałe ograniczenie modelu. Z drugiej strony nowy benchmark nie powinien bez kolejnego porównania przekreślać dowodów z obciążenia produkcyjnego.

To praktyczne znaczenie wydania utrzymaniowego takiego jak to. Tworzy ono konkretne powody do ponownej oceny istniejącego zachowania, pozostawiając jednocześnie nierozstrzygnięte szersze twierdzenia o jakości modelu i przydatności wdrożeniowej.

Małe obrazy ujawniają różnicę między ładowaniem a widzeniem

Zmiana dotycząca obrazów rozwiązuje problem utraty informacji, zanim model wygeneruje odpowiedź.

Poprawka kompaktowego widzenia dotyczy kompaktowych wież vision w Gemma 4, czyli komponentów przekształcających obrazy w dane wejściowe modelu. Według pull requestu dynamiczne ustalanie rozmiaru mogło zaokrąglać najmniejszą siatkę obrazu poniżej przewidzianego budżetu 70 tokenów.

Tokeny są tu jednostkami używanymi do reprezentowania informacji z obrazu podczas przetwarzania przez model. Zmiana zaokrągla tę siatkę w górę dla kompaktowej wieży, z limitem następnego obsługiwanego budżetu. Opiekun projektu twierdzi, że jawne budżety oraz dotychczasowe ustalanie rozmiaru dla większych i zunifikowanych wież pozostają bez zmian.

To wąska korekta, ale z użyteczną konsekwencją. Gdy dane wejściowe tracą szczegóły podczas przygotowania, późniejsze rozumowanie nie może niezawodnie odzyskać brakujących informacji. Nawet zdolny model zależy od tego, co runtime mu przekazuje.

Rozważmy aplikację odpowiadającą na pytania o mały zrzut ekranu zawierający etykietę statusu. Jeżeli przygotowanie usuwa istotny szczegół, zmiana sformułowania pytania może nie rozwiązać podstawowego problemu. Aplikacja potrzebuje, aby dowód wizualny przetrwał wystarczająco długo, by można było go zinterpretować.

Ten scenariusz wyjaśnia, dlaczego obsługa obrazów należy do dyskusji o wydajności. Użytkownicy oceniają ukończone zadanie, w tym to, czy system poprawnie odczytuje dane wejściowe. Odpowiedź, która pojawia się szybko, lecz pomija istotną etykietę, tworzy dodatkową pracę.

Nie należy jednak przekształcać tej poprawki w twierdzenie, że kompaktowe modele obsługują teraz dokładnie każdy mały obraz. Źródło wskazuje zachowanie związane z ustalaniem rozmiaru i ograniczoną korektę. Nie potwierdza ogólnego wyniku dla zrzutów ekranu, zeskanowanych dokumentów, diagramów ani fotografii.

Wymiary obrazu także nie opisują w pełni poziomu trudności. Mały obraz zawierający wyraźny symbol stanowi inne wyzwanie niż obraz z gęstym tekstem. Ocena powinna odzwierciedlać informacje, które rzeczywista aplikacja ma wydobywać.

Najbardziej klarowne porównanie zachowałoby oryginalny obraz i pytanie we wszystkich kompilacjach. Inne przeskalowanie obrazu podczas oceny wprowadziłoby kolejne wyjaśnienie ewentualnej zmiany odpowiedzi. Celem jest wyizolowanie badanego zachowania runtime'u.

Dla opiekunów projektów zmienia to sposób badania awarii. Błędna odpowiedź dotycząca obrazu nie musi wynikać z wyuczonych możliwości modelu. Przygotowanie danych wejściowych to kolejna wiarygodna warstwa, a ta łatka dostarcza konkretnego przykładu.

Zmienia to również interpretację wcześniejszych negatywnych wyników. Jeśli konfiguracja objęta zmianą odrzucała użyteczne informacje, starszy test mógł zaniżać możliwości tej konfiguracji po korekcie. Ta możliwość uzasadnia ponowne testowanie, a nie uznawanie poprzednich wyników za nieważne.

Szersza lekcja dotyczy granic porównań modeli. Sama nazwa modelu nie opisuje całego ocenianego systemu. Przygotowanie obrazu, oprogramowanie wykonawcze i zachowanie aplikacji wspólnie pomagają określić odpowiedź, która dociera do użytkownika.

Wydajność Ollama MLX poprawia się, zanim rozpocznie się odpowiedź

Zmiana szybkości promptów przyspiesza odczytywanie żądania, podczas gdy opiekun projektu wyraźnie zgłasza niezmienioną szybkość dekodowania.

Aktualizacja przetwarzania promptów aktualizuje MLX i MLX-C, jego interfejs w języku C. Wykorzystuje natywną uwagę z przesuwanym oknem, która ogranicza istotne operacje uwagi do ruchomego okna danych wejściowych modelu.

Opiekun projektu zgłasza usprawnienia prefill na Apple M5 Max. Prefill to faza przetwarzająca dane wejściowe przed generowaniem nowego wyniku. Przy prompcie o długości 2 048 tokenów zgłoszona przepustowość rośnie o 9,2% dla Gemma, 14,5% dla Flint i 24,1% dla Laguna.

Przy prompcie o długości 6 144 tokenów odpowiadające zgłoszone wzrosty wynoszą 7,5%, 14,3% i 27,0%. Są to pomiary opiekuna projektu dla określonych konfiguracji modeli. Pull request stwierdza, że szybkość dekodowania, czyli tempo generowania wyniku, pozostaje bez zmian.

To zastrzeżenie określa zakres twierdzenia o wydajności Ollama MLX. Użytkownik czekający na odczytanie długiego dokumentu ma inne wąskie gardło niż użytkownik czekający na długą odpowiedź. Usprawnienie pierwszego nie potwierdza usprawnienia drugiego.

Jest to szczególnie istotne, gdy żądanie zawiera znaczną ilość materiału pomocniczego i wymaga krótkiej odpowiedzi. W takim hipotetycznym obciążeniu przetwarzanie danych wejściowych może stanowić znaczącą część doświadczenia. Szybsze przygotowanie może mieć znaczenie, nawet jeśli późniejszy wynik pojawia się w tym samym tempie.

Odwrotna sytuacja wymaga innej interpretacji. Aplikacja z krótkim żądaniem i rozbudowanym generowanym wynikiem może poświęcać stosunkowo niewiele czasu na przetwarzanie promptu. Jej ogólnego działania nie należy przewidywać wyłącznie na podstawie przepustowości prefill.

Wartości procentowe opisują także przepustowość, a nie uniwersalne skrócenie czasu oczekiwania. Opóźnienie end-to-end, czyli czas upływający dla kompletnego żądania, obejmuje więcej niż zmierzoną fazę przetwarzania. Ładowanie, narzut aplikacji i inne zadania komplikują każde bezpośrednie przełożenie.

To rozróżnienie zapobiega znanemu błędowi w raportowaniu: przedstawianiu usprawnienia jednego komponentu jako równoważnego usprawnienia ukończonego zadania. Benchmark może precyzyjnie opisywać komponent, pozostawiając otwarty wynik na poziomie aplikacji.

Wydanie daje twórcom bardziej konkretny powód do zbadania obciążeń z długimi danymi wejściowymi. Nie wymaga od nich uznania, że ich aplikacja przyspieszyła przed wykonaniem pomiaru. To różne standardy dowodowe.

Dla zespołów zestawiających kontekst dokumentów implikacje obejmują także projektowanie oceny. Buforowane dane wejściowe, które ponownie wykorzystują wcześniej obliczoną pracę, powinny być odróżniane od świeżych danych wejściowych. W przeciwnym razie powtarzane żądania mogą zacierać obraz tego, na które przetwarzanie wpływa aktualizacja.

Wiarygodne porównanie aplikacji powinno zatem opisywać, co przesłał użytkownik i co system wykorzystał ponownie. Bez tego rozróżnienia pozornie niewielka różnica może ukrywać usprawnienie, a pozornie duża różnica może mieć inną przyczynę.

Wydajność Ollama MLX jest najbardziej użyteczna jako precyzyjne twierdzenie inżynieryjne. Dotknięta faza, konfiguracja modelu, sprzęt i długość danych wejściowych dają czytelnikom coś do przetestowania. Usunięcie tych granic rozszerzyłoby twierdzenie, ale uczyniło je mniej informacyjnym.

Obsługa Ollama DFlash2 dotyczy innego wąskiego gardła

DFlash2 dotyczy generowania odpowiedzi, dlatego jego wyniki powinny pozostać oddzielone od usprawnień przetwarzania promptów.

Implementacja DFlash2 dodaje podejście do generowania spekulacyjnego, w którym proponowany wynik jest sprawdzany przez model docelowy. Opiekun projektu opisuje selektor kandydatów, który uzależnia kolejne wybory od poprzedzających selekcji.

Według notatek implementacyjnych sesja tworzy szkic siedmiu tokenów na rundę i weryfikuje je za pomocą istniejącego mechanizmu wycofywania. Współtwórca twierdzi, że weryfikacja zachowuje rozkład wyników modelu docelowego. Jest to twierdzenie implementacyjne, a nie niezależna walidacja przedstawiona tutaj.

Pull request porównuje DFlash2 z wbudowaną głowicą przewidywania wielu tokenów, czyli mechanizmem proponującym wiele przyszłych tokenów. Dla qwen3.8:27b, przy użyciu wymienionej konfiguracji o obniżonej precyzji, opiekun projektu zgłasza wzrosty szybkości generowania w systemach M5 Max, M5 Pro i M2 Ultra.

Na M5 Max zgłoszona przepustowość generowania wzrasta z 57,0 do 71,0 tokenów na sekundę przy krótszym testowanym promptcie. Porównanie wykorzystało ten sam build, zamiast mierzyć poprzednie wydanie względem tego kandydata.

To ostatnie rozróżnienie ma znaczenie. Wyniki porównują metody generowania w ramach jednego builda. Nie należy przedstawiać ich jako zmierzonego zysku po aktualizacji dla każdego użytkownika przechodzącego z poprzedniego wydania.

Obsługa Ollama DFlash2 dodaje więc kolejną ścieżkę ewaluacji, zamiast zapewniać ogólną obietnicę szybkości. Obsługiwana konfiguracja stwarza możliwość porównania zachowania. Nie mówi jednak każdej aplikacji, która metoda generowania zapewni najlepszy rezultat.

Ogólny kompromis w generowaniu spekulatywnym jest prosty. Propozycje pomagają, gdy wystarczająco wiele z nich okazuje się użytecznych, by uzasadnić pracę związaną z ich tworzeniem i sprawdzaniem. Ocena wyłącznie etapu propozycji pominęłaby koszt weryfikacji.

Dla dewelopera aplikacji ukończony wynik ma większe znaczenie niż liczba tokenów kandydujących zaproponowanych wewnętrznie. Metoda, która agresywnie tworzy szkice, nadal musi efektywnie generować zaakceptowane wyjście. Istotnym wynikiem jest użyteczne generowanie w rzeczywistych warunkach aplikacji.

Zachowanie wyjścia zasługuje na analizę obok szybkości. Zespoły korzystające ze strukturyzowanych odpowiedzi powinny sprawdzić, czy aplikacja nadal otrzymuje oczekiwany format. Zespoły oceniające odpowiedzi faktograficzne powinny zachować dotychczasowe kontrole poprawności przy wprowadzaniu kolejnej ścieżki wykonania.

Są to priorytety ewaluacyjne, a nie dowody na to, że ta implementacja powoduje problemy z formatem lub jakością. Źródło opisuje zabezpieczenia mające zachować dotychczasowe zachowanie. Niezależne testy aplikacji pozwalają zespołowi ustalić, czy jego własne wymagania nadal są spełnione.

Istnieje także różnica raportowa między obsługą a zachowaniem domyślnym. Informacja o wydaniu ogłaszająca funkcję sama w sobie nie potwierdza, że korzysta z niej każdy zainstalowany model. Czytelnicy muszą zidentyfikować faktyczną konfigurację stojącą za każdym zaobserwowanym wynikiem.

Ten punkt łączy tę funkcję z resztą wydania. Usprawnienia środowiska uruchomieniowego stają się użyteczne dzięki łańcuchowi decyzji dotyczących kompatybilności i integracji. Użytkownik widzi odpowiedź, ale wybrany model i metoda wykonania decydują o tym, które zmiany miały wkład w rezultat.

W przypadku obciążeń obejmujących długie odpowiedzi mechanizm generowania zasługuje na uwagę sam w sobie. Łączenie zgłoszonych korzyści z niepowiązanymi wartościami procentowymi przetwarzania promptów stworzyłoby niepoparte szacunki. Każde ulepszenie wymaga odpowiadającego mu obciążenia, zanim będzie mogło wesprzeć wniosek na poziomie aplikacji.

Aktualizacja zależności utrzymuje porównania w realnych ramach

Nowsza zależność wskazuje na zmieniony fundament, ale nie potwierdza uniwersalnego wyniku wydajnościowego.

Aktualizacja llama.cpp przenosi zależność Ollama z builda b11845 do b11901. llama.cpp jest silnikiem inferencji, czyli oprogramowaniem wykonującym wytrenowane modele w celu uzyskania wyników. Pull request został scalony 26 października.

Widoczny pull request odsyła do porównania upstream, nie przedstawiając odpowiadającego mu benchmarku aplikacyjnego. Uzasadnia to raportowanie zmiany wersji. Nie uzasadnia przypisania konkretnej poprawy szybkości lub jakości każdemu obciążeniu korzystającemu z tej ścieżki.

Ma to znaczenie, ponieważ aktualizacje zależności łatwo nadinterpretować. Nowszy numer builda opisuje pochodzenie oprogramowania. Nie wskazuje, które operacje zmieniły się dla konkretnej aplikacji, ani nie ustala, czy przesunęło się jej istniejące wąskie gardło.

Porównanie z bezpośrednim użyciem frameworka pomaga wyjaśnić pozycję Ollama. Framework MLX udostępnia programistom bezpośrednio interfejsy programistyczne i operacje uczenia maszynowego. Ollama integruje podstawowe możliwości ze środowiskiem do uruchamiania modeli.

Podejścia te zaspokajają nakładające się potrzeby przy różnych poziomach odpowiedzialności. Badacz pracujący bezpośrednio z operacjami frameworka może szczegółowo analizować wybory implementacyjne. Zespół aplikacyjny korzystający ze zintegrowanego środowiska uruchomieniowego polega na obsługiwanych przez nie ścieżkach wykonania.

Żadne z tych podejść nie wygrywa z definicji każdego porównania. Bezpośredni dostęp zapewnia kontrolę, podczas gdy integracja może ograniczyć pracę potrzebną do obsługi wspieranego modelu. Rzetelna ocena powinna pytać, które obowiązki zespół aplikacyjny chce przejąć.

Kandydat pokazuje także, dlaczego wyniki upstream i downstream powinny pozostać odrębne. Możliwość frameworka potrzebuje odpowiedniej integracji, zanim aplikacja z niej skorzysta. Odwrotnie, zintegrowanego ulepszenia nie należy przypisywać nowemu modelowi, gdy sam model się nie zmienił.

To rozróżnienie wpływa na twierdzenia konkurencyjne. Wynik dla jednego modelu, urządzenia i ścieżki wykonania nie dowodzi, że Ollama ogólnie przewyższa alternatywne środowiska uruchomieniowe. Ustala wynik dla testowanego systemu, z uwzględnieniem granic tego systemu.

Dostępne dowody pochodzą głównie od opiekunów projektu. Potwierdzają istnienie zmian i zgłoszone przez nich pomiary. Nie przedstawiają niezależnego konsensusu na temat wdrożeń produkcyjnych, niezawodności ani przewagi w różnych opcjach wdrożenia.

Nie trzeba tworzyć sztucznej publicznej kontrowersji, aby te dowody miały znaczenie. Nierozstrzygnięte pytanie jest praktyczne: czy zmiany przynoszą użyteczne korzyści w aplikacjach poza pomiarami opiekunów. To pytanie jest wystarczająco istotne bez wymyślonych zwolenników czy krytyków.

W przypadku nabywców korporacyjnych właściwa presja dotyczy jakości dowodów. Szeroka demonstracja lokalnej AI jest mniej użyteczna niż wyniki odpowiadające zamierzonemu zadaniu. Decyzje zakupowe wymagają zgodności modelu, sprzętu, obciążenia i wymagań operacyjnych.

Deweloperzy również korzystają na zachowaniu kontekstu stojącego za porównaniami. Zespoły dokumentujące ewaluacje mogą używać przeszukiwalnej bazy wiedzy, aby zachować ustalenia wraz z konfiguracjami i przykładami. Użyteczny zapis obejmuje porażki i ograniczenia, a nie tylko najszybsze uruchomienie.

Trzy sygnały pokażą, jak duże znaczenie ma ten kandydat

Kolejnymi istotnymi dowodami będą postęp wydania, odtwarzalne pomiary czasu i zweryfikowane zachowanie zadań — w tej kolejności.

Po pierwsze, obserwuj, co dzieje się z opublikowanym kandydatem. Stabilny artefakt, kolejny kandydat lub wydanie korygujące wyjaśniłyby, jakie oprogramowanie jest dostępne do szerszego wdrożenia. Zdarzenia te nie potwierdzą automatycznie jakości aplikacji, ale rozstrzygną część kwestii statusu wydania.

Najbardziej informatywny postęp zachowałby wyraźne powiązania między tagami a zmianami. Pozwoliłoby to deweloperom ustalić, czy późniejszy wynik dotyczy tego kandydata, czy zmodyfikowanego builda. Bez tej ciągłości dyskusje mogą łączyć ustalenia dotyczące różnego oprogramowania pod tą samą skróconą nazwą wersji.

Kolejna korekta nie unieważniłaby automatycznie opisanej tutaj pracy. Jej znaczenie zależałoby od dotkniętego nią zachowania. Czytelnicy powinni szukać konkretnego związku między zgłoszonym problemem, jego zakresem i używaną przez nich konfiguracją.

Po drugie, obserwuj odtwarzalne pomiary czasu aplikacji, które oddzielają przetwarzanie wejścia od generowania wyjścia. Pozwoli to sprawdzić, czy zgłoszone usprawnienia komponentów utrzymują się poza pierwotnymi warunkami pomiaru. Wyniki powinny identyfikować faktyczną konfigurację modelu i sprzęt.

Dowody z odpowiadającego obciążenia wzmocniłyby argument za wdrożeniem istotnej zmiany. Porównanie wykazujące niewielką korzyść end-to-end zawęziłoby ten argument, niekoniecznie przecząc benchmarkowi komponentu. Aplikacja może po prostu spędzać czas gdzie indziej.

Raporty czasowe stają się bardziej informatywne, gdy opisują zarówno świeże, jak i ponownie użyte dane wejściowe. Powinny także rozróżniać model, który jest już załadowany, od żądania, które musi go załadować. Warunki te odpowiadają na różne pytania dotyczące codziennego użycia.

Po trzecie, obserwuj kontrole na poziomie zadań dotyczące obsługi obrazów i przyspieszonego generowania. Korekta dotycząca obrazów wymaga przykładów sprawdzających zachowane informacje wizualne. Ścieżka generowania wymaga kontroli wyjścia obok pomiarów czasu, zwłaszcza tam, gdzie aplikacje zależą od przewidywalnej struktury.

Przydatne raporty obejmowałyby oryginalne wejście, oczekiwane zachowanie i wynik z każdej porównywanej konfiguracji. Pozwoliłoby to innym przeanalizować twierdzenie, zamiast polegać na stwierdzeniu, że odpowiedź wyglądała lepiej.

W przypadku zadań obrazowych poprawna odpowiedź na łatwym przykładzie dostarczyłaby ograniczonych dowodów dotyczących trudnych wejść. W przypadku zadań generowania szybka odpowiedź dostarczyłaby ograniczonych dowodów dotyczących kompatybilności aplikacji. Siła każdego wyniku zależy od tego, co faktycznie testuje.

Sygnały te należy odczytywać łącznie, bez sprowadzania ich do jednego wyniku. Postęp wydania dotyczy artefaktu. Pomiary czasu dotyczą wykonania. Kontrole zadań dotyczą tego, czy aplikacja poprawnie wykonuje użyteczną pracę.

W nadchodzących miesiącach najcenniejsze dalsze działania połączą te warstwy. Odtwarzalny wynik powiązany z konkretnym wydaniem i reprezentatywnym zadaniem wzmocniłby praktyczny argument. Niepoparte uogólnienia przyciągnęłyby uwagę bez rozstrzygnięcia kwestii wdrożenia.

Dla czytelników oceniających Ollama v0.40.12 punktem wyjścia powinno być obciążenie, które już ma dla nich znaczenie. Zachowaj jego wejście, konfigurację modelu i oczekiwane wyjście przed porównaniem buildów. Zapisz osobno czas poświęcony na przetwarzanie żądania i czas na generowanie odpowiedzi. Jeśli obrazy mają znaczenie, zachowaj oryginalne pliki i sprawdź szczegóły potrzebne aplikacji. Jeśli przyspieszone generowanie ma znaczenie, kontroluj ukończone odpowiedzi obok szybkości. Zachowaj pełny tag kandydata wraz z ustaleniami, aby późniejsze porównania pozostały możliwe do interpretacji. Następnie podejmij decyzję o aktualizacji wokół konkretnego rezultatu: czy zmieniona ścieżka wykonania poprawiła zadanie, które użytkownicy faktycznie wykonują, w warunkach, z którymi aplikacja rzeczywiście się mierzy?