llama.cpp CUDA Fusion łączy się z nawet o 10,7% szybszym przetwarzaniem promptów

llama.cpp połączył 25 października optymalizację CUDA, a testy współtwórcy wskazują na wzrost wydajności przetwarzania promptów sięgający 10,7% na DGX Spark. Zmiana llama.cpp CUDA fusion łączy operacje wewnątrz sieci feed-forward modelu, komponentu przekształcającego reprezentacje tokenów pomiędzy etapami uwagi. Jej korzyść dotyczy odczytywania promptów, a nie generowania każdego kolejnego tokenu odpowiedzi.

Pomiary współtwórcy anujj pokazują również poprawę na RTX 5090 firmy NVIDIA, choć zgłoszone wzrosty procentowe są mniejsze. Są to porównania raportowane przez autora, a nie wyniki niezależnie odtworzone. Sama zmiana jest możliwa do zweryfikowania w połączonym kodzie, jednak jej praktyczna wartość nadal zależy od formatu modelu, sprzętu i obciążenia.

Główne porównanie dotyczy wykonania połączonego, które scala powiązane operacje, oraz istniejącej ścieżki wykonawczej, która planuje te operacje osobno. Wcześniejsza propozycja realizowała tę samą możliwość w inny sposób. Połączone podejście reorganizuje sposób, w jaki wartości trafiają do wątków GPU, ograniczając pracę pośrednią bez zmiany zapisanych wag modelu. Dla deweloperów uruchamiających lokalnie długie prompty jest to konkretne ulepszenie programowe, które warto mierzyć względem istniejącego wdrożenia.

Co zmienia połączenie llama.cpp CUDA fusion

Połączona zmiana rozszerza istniejącą optymalizację na większe obciążenia przetwarzania promptów na obsługiwanym sprzęcie NVIDIA.

CUDA, platforma NVIDIA do obliczeń GPU, zapewnia środowisko wykonawcze dla tej implementacji. MMQ, ścieżka mnożenia macierzy skwantyzowanych w llama.cpp, obsługuje obliczenia z udziałem skompresowanych wag modelu. Kwantyzacja reprezentuje te wagi z mniejszą precyzją numeryczną, aby zmniejszyć wymagania dotyczące pamięci i przestrzeni dyskowej.

Połączona zmiana fusion celuje w powtarzalną sekwencję wewnątrz obsługiwanych gęstych warstw feed-forward. Oddzielne projekcje gate i up przekształcają to samo wejście. Następnie bramkowana jednostka liniowa, czyli GLU, łączy ich wyniki poprzez aktywację i mnożenie element po elemencie.

Wcześniej większe obciążenia na tej ścieżce obsługiwały projekcje i ich połączenie jako oddzielne operacje. Według anujj nowa implementacja wykonuje tę sekwencję za pomocą pojedynczego jądra mnożenia macierzy. Jądro to funkcja uruchamiana równolegle w wątkach GPU.

Ta konsolidacja ma znaczenie, ponieważ zasoby zużywa także praca towarzysząca. Przygotowywanie danych wejściowych, uruchamianie operacji, zapisywanie wyników pośrednich i ich ponowne odczytywanie mogą zwiększać narzut. Łączenie operacji daje możliwość ograniczenia części tego ruchu przy zachowaniu zamierzonego przekształcenia matematycznego.

Zmiana nie wprowadza tej idei jednocześnie we wszystkich ścieżkach wykonawczych. Współtwórca podaje, że fusion dla małych batchy istniało już w innych implementacjach macierz-wektor. Obliczenia macierz-wektor zwykle obsługują mniejsze obciążenia niż podkreślane tutaj obliczenia macierz-macierz.

To rozróżnienie wyjaśnia, dlaczego ogłoszenie koncentruje się na przetwarzaniu promptów. Prefill, faza przetwarzająca prompt wejściowy przed generowaniem odpowiedzi, może ujawniać większe batchy pracy. Nowo obsługiwana ścieżka wykonawcza dotyczy tej części inferencji.

Istotna jest również chronologia. Opis otwierający pull request datowany jest na 4 października, a projekt połączył go 25 października. Połączenie przenosi implementację do głównej gałęzi projektu. Nie oznacza to, że każda spakowana aplikacja już zawiera tę zmianę.

Aplikacja desktopowa, kontener lub projekt downstream może włączać llama.cpp zgodnie z własnym harmonogramem. Użytkownicy muszą więc ustalić faktyczną wersję środowiska wykonawczego stojącą za interfejsem. Aktualizacja aplikacji i połączenie kodu źródłowego upstream to odrębne wydarzenia.

W przypadku istniejących plików modeli kwestia kompatybilności jest stosunkowo prosta. Współtwórca stwierdza, że układ zapisanych wag pozostaje niezmieniony. Użytkownicy nie powinni interpretować zawartego w tytule odniesienia do przeplatanych wierszy jako wymogu pobrania specjalnie przeorganizowanych plików modelu.

Bezpośrednia wiadomość jest zatem wąska i konkretna. Obsługiwana sekwencja wykonawcza ma teraz dodatkową optymalizację dostępną upstream. To, czy dane żądanie z niej skorzysta, zależy od kontroli kwalifikowalności środowiska wykonawczego.

Wzrosty w testach bardziej sprzyjają Spark, z mniejszą poprawą na RTX 5090

Raportowane wyniki pokazują spójny kierunek we wszystkich wymienionych konfiguracjach, ale ich skala różni się zależnie od sprzętu i kwantyzacji.

Autor testował DGX Spark z procesorem GB10, a osobno RTX 5090. Obie tabele testowe porównują bazową wersję oznaczoną jako master z pull requestem. Każdy wymieniony wiersz wskazuje wyższą przepustowość przetwarzania promptów dla zmodyfikowanej implementacji.

Na DGX Spark największa wymieniona poprawa procentowa dotyczy Llama-3.1-8B używającego IQ4_XS, skompresowanego formatu wag. Przepustowość wzrasta z 2 933,9 do 3 249,0 tokenów na sekundę. Autor raportuje dla tej konfiguracji wzrost o 10,7%.

Inne wyniki Llama-3.1-8B na Spark pozostają poniżej tego maksimum, ale nadal wskazują na znaczne raportowane usprawnienia. Konfiguracja Q4_K_M przechodzi z 2 749,3 do 3 000,6 tokenów na sekundę. Konfiguracja Q5_K_M wzrasta z 2 699,4 do 2 960,3 tokenów na sekundę.

Te etykiety oznaczają różne skwantyzowane konfiguracje modeli, a nie wymienne pomiary identycznego pliku binarnego. Ich wyniki pokazują, dlaczego przy ocenie optymalizacji użytkownicy powinni dopasować dokładny format pliku. Sama nazwa rodziny modeli pomija istotną zmienną.

Tabela Spark wymienia również modele oznaczone jako Qwen3.8-27B i Qwen3.6-27B. Nazwy te przytoczono tutaj jako etykiety testowe z raportu współtwórcy. Sama tabela wydajności nie potwierdza niezależnie szczegółów ich treningu, możliwości ani szerszej dostępności.

W przypadku wpisu oznaczonego jako Qwen3.8-27B poprawa na Spark wynosi od 4,6% do 7,4%. Wiersz Q4_K_M rośnie z 840,1 do 899,9 tokenów na sekundę. Wiersz IQ4_XS wzrasta z 882,4 do 948,0 tokenów na sekundę.

Wyniki RTX 5090 pokazują inną skalę poprawy. We wszystkich wymienionych konfiguracjach autor raportuje wzrosty od 1,9% do 4,7%. Ten mniejszy zakres procentowy sprawia, że interpretacja zależna od sprzętu jest niezbędna.

W przypadku Llama-3.1-8B w IQ4_XS wynik RTX 5090 wzrasta z 12 997,6 do 13 603,3 tokenów na sekundę. Raportowana poprawa wynosi 4,7%. Dla wpisu Qwen3.8-27B Q6_K przepustowość wzrasta z 3 220,5 do 3 281,0 tokenów na sekundę, czyli o 1,9%.

Testy llama.cpp fusion wspierają zatem ograniczony wniosek. W wybranych przez autora testach z długimi promptami optymalizacja poprawia zmierzoną przepustowość wejściową w całej raportowanej macierzy. Nie wykazują one identycznego wzrostu dla każdego obsługiwanego GPU.

Porównanie procentowe nie ujawnia też, dlaczego Spark zyskuje więcej. Różne zachowania pamięci, charakterystyki wykonania i istniejące wąskie gardła mogą wpływać na wyniki optymalizacji. Ustalenie ich względnego wkładu wymagałoby dodatkowego profilowania, którego same te podstawowe pomiary nie zapewniają.

Dla kupujących użyteczny wniosek dotyczy dyscypliny oceny. Wyniki te nie uzasadniają wyboru sprzętu wyłącznie na podstawie wzrostów procentowych. Bezwzględna przepustowość, dopasowanie modelu, pojemność pamięci i rzeczywiste opóźnienie aplikacji pozostają odrębnymi kwestiami.

Przeplatane wiersze eliminują pracę między obliczeniami

Głównym posunięciem implementacji jest umieszczenie powiązanych wyników razem przed zastosowaniem operacji gate.

Anujj opisuje ładowanie wierszy gate i up naprzemiennie, w fragmentach po osiem. Taki układ umieszcza odpowiadające sobie wartości w wynikach roboczych tego samego wątku. Wątek może następnie połączyć te wartości podczas zapisywania końcowego wyniku.

Rejestry, niewielkie lokalizacje pamięci GPU przypisane do wykonywanych wątków, przechowują te wyniki pośrednie. Zastosowanie połączenia w nich pozwala uniknąć osobnego przejścia przez pośrednie bufory wyjściowe dla tej części obliczenia. Zamierzona oszczędność wynika z organizacji wykonania.

Implementacja zachowuje jeden układ akumulatora zamiast wprowadzać drugi kafelek akumulatora dla projekcji gate. Akumulator przechowuje sumy częściowe podczas mnożenia. Kafelek to blok elementów macierzy przetwarzanych razem.

Ten wybór projektowy odróżnia implementację od wcześniejszej propozycji fusion. Zgodnie z opisem współtwórcy nowsze podejście realizuje sugestię am17an. Obie propozycje dotyczą powiązanych operacji, ale inaczej organizują obliczenie.

Różnica ma charakter praktyczny, a nie kosmetyczny. Przechowywanie większej ilości stanu pośredniego może zwiększać presję na ograniczone zasoby wykonawcze GPU. Łączenie operacji pomaga tylko wtedy, gdy oszczędności przewyższają dodatkowy koszt planowania lub przechowywania.

Dlatego „mniej jąder” nie oznacza automatycznie „szybszej inferencji”. Większa połączona operacja może w pewnych warunkach mniej efektywnie wykorzystywać sprzęt. Optymalizacja musi zachować wystarczającą równoległość pracy, jednocześnie unikając nowych ograniczeń, które zniwelują jej korzyści.

Połączony kod odzwierciedla tę kwestię poprzez kontrole kwalifikowalności. Ocena określa, czy dane obciążenie nadaje się do tej ścieżki fusion. Same obsługiwane operacje matematyczne nie gwarantują, że fusion powinno zostać uruchomione.

Implementacja konkuruje również ze stream-k, metodą planowania, która dzieli pracę mnożenia macierzy wzdłuż jej wymiaru redukcji. Połączona ścieżka nie może wykorzystać tego podziału. Musi więc w inny sposób zdecydować, czy jej układ kafelków zapewnia wystarczającą wydajność.

Johannes Gaessler poruszył tę kwestię podczas przeglądu, prosząc o wcześniejsze porównanie oczekiwanej wydajności kafelkowania ze stream-k. Połączony kod zawiera decyzję dotyczącą wydajności przed wybraniem ścieżki fusion. Warunkowe wykonanie stanowi więc część projektu.

Przegląd planowania fusion przedstawia najbardziej użyteczną sceptyczną perspektywę wobec optymalizacji. Koncentruje się na okolicznościach, w których atrakcyjne uproszczenie może obniżyć wydajność. Jest to ograniczenie techniczne, a nie spór o istnienie testu wydajności.

Główna konkurencja pozostaje tu w konsekwencji wewnątrz środowiska wykonawczego. Wykonanie połączone musi przewyższać istniejące podejście planowania dla kwalifikującego się kształtu operacji. Wyniki te nie stanowią dowodu na szersze zwycięstwo nad innym frameworkiem inferencyjnym.

Mechanizm ten wyjaśnia również, czego użytkownicy powinni oczekiwać od llama.cpp CUDA fusion. Reorganizuje pracę dla istniejącego obliczenia. Nie zwiększa zdolności modelu do rozumowania, nie rozszerza jego wytrenowanej wiedzy ani nie usuwa niezwiązanych ograniczeń pamięci.

Ten sam model nadal wykonuje to samo ogólne zadanie. Możliwość inżynieryjna polega na poświęcaniu mniejszej ilości czasu na uzyskanie wyniku określonej sekwencji.

Szybsze przetwarzanie promptów zmienia jedną część czasu oczekiwania

Test mierzy przetwarzanie danych wejściowych, więc jego praktyczna wartość zależy od tego, jak duży udział przetwarzanie wejścia ma w rzeczywistym żądaniu.

Raportowane polecenie przetwarza prompt zawierający 16 384 tokeny i żąda wygenerowania zerowej liczby tokenów. Tokeny to jednostki tekstu, które model przetwarza i wytwarza. Taka konfiguracja izoluje przepustowość promptu zamiast mierzyć ukończoną odpowiedź konwersacyjną.

Polecenie wykorzystuje rozmiary batchy i mikrobatchy wynoszące 2 048. Mikrobatch to mniejsza jednostka wykonawcza wydzielona z większego batcha. Włącza ono również Flash Attention — implementację mechanizmu attention zaprojektowaną tak, aby ograniczać ruch danych w pamięci podczas obliczeń attention.

Autor określa przechowywanie pamięci podręcznej klucz-wartość w półprecyzji; przechowuje ona informacje attention z wcześniej przetworzonych tokenów. W poleceniu występuje pięć powtórzeń. Ustawienia te definiują testowane warunki i powinny towarzyszyć każdemu cytowanemu wynikowi.

Projektowa metodologia benchmarków rozróżnia przetwarzanie promptu od generowania tokenów. To rozdzielenie jest kluczowe dla interpretacji tych liczb. Liczba tokenów wejściowych na sekundę i liczba tokenów wyjściowych na sekundę odpowiadają na różne pytania dotyczące wydajności.

Wyobraźmy sobie dewelopera proszącego lokalny model o przeanalizowanie dużego pliku źródłowego. Przetworzenie tego wejścia może istotnie wydłużyć czas, zanim odpowiedź zacznie się pojawiać. Szybsza, kwalifikująca się ścieżka prefill usprawnia właśnie tę część interakcji.

Krótka wymiana w rozmowie stanowi inne obciążenie. Jej prompt może wymagać stosunkowo niewielkiego przetwarzania w porównaniu z czasem potrzebnym na wygenerowanie długiej odpowiedzi. To samo usprawnienie przepustowości wejściowej wpłynie wtedy na mniejszą część całkowitego czasu oczekiwania.

Prompty z pamięci podręcznej wprowadzają kolejne rozróżnienie. Cache promptów ponownie wykorzystuje obliczenia dla wejścia, które system już przetworzył. Gdy aplikacja skutecznie wykorzystuje tę pracę ponownie, pozostaje mniej nowego wejścia, które ta optymalizacja może przyspieszyć.

Analiza dokumentów obejmuje także pracę wykraczającą poza inferencję. Aplikacja może pobierać pliki, wyodrębniać tekst, oceniać trafność fragmentów lub przygotowywać instrukcję, zanim cokolwiek wyśle do modelu. Szybsze przetwarzanie wejścia przez model nie oznacza, że te otaczające etapy również zakończą się wcześniej.

Dla zespołów utrzymujących przeszukiwalną bazę wiedzy to rozdzielenie wspiera lepsze decyzje dotyczące wydajności. Jakość wyszukiwania i dobór kontekstu określają, co trafia do modelu. Przepustowość środowiska wykonawczego określa, jak szybko przetwarzane są kwalifikujące się obliczenia.

To rozróżnienie wywiera też presję na osoby utrzymujące aplikacje. Muszą wiedzieć, jakie środowisko wykonawcze dostarcza ich produkt oraz czy jego typowe obciążenia trafiają na zoptymalizowaną ścieżkę. Ogólna informacja o wydaniu mówiąca o szybszym lokalnym AI nie może odpowiedzieć na te pytania.

Użyteczną odpowiedzią są pomiary na granicy aplikacji. Czas do pierwszego tokenu mierzy opóźnienie, zanim rozpocznie się generowanie. Całkowity czas odpowiedzi mierzy całą interakcję, natomiast przepustowość generowania mierzy tempo po rozpoczęciu wyjścia.

Każda z tych metryk może zmienić się inaczej po aktualizacji środowiska wykonawczego. Usprawnienie prefill może skrócić początkowe oczekiwanie bez zmiany tempa późniejszego tekstu. Oddzielne raportowanie tych wyników daje użytkownikom dokładniejszy obraz aktualizacji.

W przypadku przetwarzania promptów przez llama.cpp najsilniejszym zastosowaniem pozostaje nowe, obszerne wejście w kwalifikującej się konfiguracji. Benchmark autora celowo akcentuje właśnie takie obciążenie. Rozszerzanie jego wyniku na każdą sesję czatu wykraczałoby poza przedstawione dowody.

Obsługiwane formaty i kontrole poprawności wyznaczają granice

Połączony kod zawiera istotne ograniczenia, a raport autora dotyczący poprawności należy odczytywać w ramach deklarowanego zakresu testów.

Pull request opisuje obsługę typów wag Q4_K, Q5_K, Q6_K, Q8_0 i IQ4_XS na architekturach NVIDIA Turing lub nowszych. Są to obsługiwane rodziny wag. Pliki modeli mogą łączyć różne typy, dlatego ogólne oznaczenie pliku nie opisuje każdego wewnętrznego tensora.

Implementacja sprawdza również, czy odpowiednie wagi gate i up spełniają warunki wymagane do fuzji. Kształt, typ i układ mają znaczenie, ponieważ połączona operacja oczekuje odpowiadających sobie obliczeń. Nieobsługiwany układ powinien zachować inną ścieżkę wykonania.

Połączony kod wyklucza przypadki wymagające mechanizmu fallback dla granic wierszy. Fallback obsługuje kształty, które nie wypełniają prawidłowo standardowych kafelków przetwarzania. To ograniczenie ma znaczenie, ponieważ pierwotny opis omawia testy obejmujące przypadki brzegowe podczas prac rozwojowych.

Czytelnicy powinni zatem rozróżniać początkowe podsumowanie testów od reguł wyboru w finalnym kodzie. Testowanie szerszej implementacji rozwojowej nie dowodzi, że każdy testowany kształt nadal kwalifikuje się w połączonej wersji. Rzeczywiste wykonanie określają końcowe zabezpieczenia.

Istnieją również ograniczenia dotyczące parametrów operacji. Kod sprawdza określone ustawienia aktywacji przed wybraniem fuzji. Kontrole te zapobiegają traktowaniu przez środowisko wykonawcze powierzchownie podobnych operacji jako wymiennych, gdy ich wymagane zachowanie się różni.

Zakres koncentruje się też na gęstych operacjach feed-forward. Modele mixture-of-experts, które kierują tokeny przez wybrane podsieci, wprowadzają inne wymagania wykonawcze. Recenzja wyraźnie wskazuje na potrzebę dodatkowych prac nad obsługą, zamiast ustanawiać uniwersalne pokrycie dla takich modeli.

Inne backendy sprzętowe nie otrzymują tej optymalizacji tylko dlatego, że obsługują llama.cpp. Autor zmian wyraźnie oddziela tę zmianę od innych backendów. Wyniki z hardware NVIDIA nie mogą więc potwierdzać równoważnych korzyści na GPU Apple ani w konfiguracji AMD.

Dowody poprawności są zachęcające, ale pozostają raportowane przez autora. Anujj twierdzi, że pełny zestaw testów operacji backendu przechodzi na GB10. Raport stwierdza również, że zestawy testów mnożenia macierzy przechodzą na RTX 5090.

Autor zmian dodatkowo raportuje identyczne wyniki perplexity w określonych testach z włączoną i wyłączoną fuzją. Perplexity mierzy, jak dobrze model przewiduje tekst ewaluacyjny. Zapewnia użyteczną kontrolę numeryczną, choć nie reprezentuje każdego możliwego zachowania aplikacji.

Wynik ten wspiera węższe stwierdzenie niż uniwersalna identyczność wyników. Identyczne wyniki w określonej ewaluacji nie dowodzą identycznych generowanych odpowiedzi dla wszystkich promptów, ustawień czy platform. Szersza walidacja wymaga szerszych dowodów.

W analizowanych dla tego raportu źródłach brakuje też niezależnego odtworzenia benchmarków fuzji llama.cpp. Recenzja upstream i połączenie zmian potwierdzają, że projekt zaakceptował kod. Nie przekształcają jednak pomiarów autora zmian w zewnętrzny audyt wydajności.

Żadna z tych granic nie eliminuje raportowanego zysku. Określają one, gdzie twierdzenie staje się użyteczne. Czytelnik z odpowiadającym sprzętem i typami modeli ma konkretny powód do testów, podczas gdy inne konfiguracje wymagają odrębnych dowodów.

Najmocniejsza interpretacja łączy obie strony. Zmiana ma jasny mechanizm i opublikowane pomiary, a jednocześnie wyraźne warunki określające, kiedy jest uruchamiana.

Trzy sygnały pokażą, jak szeroko przenosi się usprawnienie

Kolejne dowody powinny połączyć kod upstream, odtwarzalne pomiary oraz opóźnienia odczuwane przez użytkowników.

Pierwszym sygnałem jest wdrożenie downstream. W nadchodzących miesiącach wydania aplikacji i spakowane kompilacje powinny ustalić, które produkty zawierają połączoną implementację. Ma to znaczenie, ponieważ użytkownicy często korzystają z llama.cpp za pośrednictwem innej aplikacji.

Projektowe instrukcje budowania CUDA opisują ścieżkę kompilacji upstream. Spakowane dystrybucje mogą podlegać innym harmonogramom wydań. Identyfikator wersji powiązany z dołączonym kodem źródłowym jest bardziej informatywny niż ogólne twierdzenie o używaniu najnowszego backendu.

Jeśli szeroko używane aplikacje włączą tę zmianę, argument za szybkim wdrożeniem się wzmocni. Jeśli pozostaną przy starszych rewizjach, praktyczny zasięg połączenia zmian pozostanie ograniczony. Taki wynik dotyczyłby harmonogramu dystrybucji, a nie podważałby samej optymalizacji.

Drugim sygnałem jest niezależne odtworzenie z jawnymi ustawieniami. Użyteczne raporty powinny wskazywać sprzęt, pliki modeli, rewizje środowiska wykonawczego i argumenty benchmarków. Powinny też rozdzielać przetwarzanie nowych promptów od wejścia z cache i generowanego wyjścia.

Odtworzenia dla różnych długości promptów wyjaśniłyby, jak wrażliwy jest zysk na rozmiar obciążenia. Raporty obejmujące obsługiwane generacje GPU sprawdziłyby, czy trend utrzymuje się poza wymienionymi maszynami. Wyniki wskazujące regresje pomogłyby określić ograniczenia logiki wyboru.

Właściwe pytanie nie brzmi, czy każde uruchomienie osiąga maksymalny wynik z nagłówka. Chodzi o to, czy porównywalne obciążenia wykazują powtarzalną poprawę przy akceptowalnej zmienności. Mniejszy, lecz konsekwentny zysk nadal może być użyteczny operacyjnie.

Trzecim sygnałem jest opóźnienie aplikacji. Zespoły powinny mierzyć, czy zaktualizowane środowisko wykonawcze skraca oczekiwanie, zanim rozpocznie się odpowiedź, w reprezentatywnych żądaniach. Powinny zachować przepustowość generowania i całkowity czas odpowiedzi jako odrębne pomiary.

Taki dowód połączyłby zmianę kernela z doświadczeniem użytkownika. Mniejsze początkowe opóźnienie przy długich promptach bez cache wspierałoby praktyczną obietnicę implementacji. Niezmieniony całkowity czas odpowiedzi wskazywałby, że mierzony przepływ pracy zdominowany jest przez inne etapy.

Rozszerzona obsługa formatów lub architektur byłaby dodatkowym rozwojem, a nie czymś ustanowionym przez to połączenie zmian. Przyszłe twierdzenia powinny wskazywać własną implementację i pomiary. Obecne wyniki zapewniają punkt odniesienia do porównań, a nie potwierdzenie z wyprzedzeniem takich rozszerzeń.

Na razie fuzja CUDA w llama.cpp daje konkretny powód, by ponownie przyjrzeć się wydajności lokalnej inferencji. Celuje w powtarzalną pracę w ramach kwalifikujących się obliczeń feed-forward i raportuje mierzalne zyski w ujawnionych warunkach przetwarzania promptów. To wystarcza, by uzasadnić ewaluację, bez obiecywania powszechnego wzrostu szybkości.

Przed aktualizacją działającego wdrożenia zachowaj jego obecny identyfikator środowiska wykonawczego oraz reprezentatywny zestaw żądań. Po aktualizacji porównaj te same pliki modeli, długości promptów, warunki cache i ustawienia wyjścia. Rejestruj początkowy czas oczekiwania oddzielnie od generowania odpowiedzi i zachowuj argumenty benchmarków przy każdym wyniku. W przypadku przepływów pracy z długimi dokumentami uwzględnij nowe wejścia przypominające codzienne użycie, zamiast opierać się wyłącznie na syntetycznej przepustowości. W przypadku obciążeń konwersacyjnych sprawdź, czy krótsze opóźnienie przetwarzania wejścia zmienia doświadczenie na tyle, by miało znaczenie. Następnie wykorzystaj własne pomiary, aby zdecydować, gdzie usprawnienie upstream powinno znaleźć się w harmonogramie wydań. Czy zaktualizowane środowisko wykonawcze skraca tę część żądania, na którą rzeczywiście czekają Twoi użytkownicy?