:: Aurora Zine ::

numer 04 phile 02 z 02

Wzrok albo szybkość. Przez pół roku wybierałem

Ten sam model występuje w mojej konfiguracji trzy razy, bo trzeba było wybrać: albo szybkie generowanie, albo szybki wzrok. 24 sekundy na obrazek kontra sekunda. O ograniczeniu, które okazało się właściwością silnika, a nie karty.

grzegorz404

  • vision
  • mmproj
  • nvfp4
  • pomiary
  • lokalne modele
  • cache

W mojej konfiguracji ten sam model występuje trzy razy.

Te same wagi, ten sam plik na dysku, trzy osobne wpisy różniące się kilkoma flagami. Nie dlatego, że lubię bałagan — dlatego, że musiałem wybrać, co ma działać dobrze, a co ma działać w ogóle.

To jest tekst o wyborze, który przez długi czas uważałem za prawo natury. Nie jest.

Skąd się biorą trzy wpisy

Model, którego używam, potrafi patrzeć na obrazki. Żeby to robiło się samo, obok wag języka musi siedzieć drugi, mniejszy model — ten, który zamienia piksele na coś, co reszta rozumie. W świecie plików GGUF nazywa się to mmproj i jest osobnym plikiem, ładowanym osobno.

I tu zaczyna się arytmetyka. Karta ma trzydzieści dwa gigabajty. Wagi zajmują dwadzieścia parę. Pamięć na kontekst — kilka kolejnych. Zostaje niewiele, a chętnych jest dwóch: enkoder obrazu i mechanizm przewidywania w przód, który przyspiesza generowanie tekstu.

Obaj naraz się nie mieszczą. Więc wybierasz.

Wpis pierwszy: enkoder obrazu zepchnięty do pamięci systemowej, przewidywanie zostaje na karcie. Tekst leci szybko, obrazki są rozpaczliwie wolne, ale nic się nie wywala.

Wpis drugi: enkoder na karcie, przewidywanie wyłączone. Obrazki szybkie, tekst wolniejszy.

Wpis trzeci to ten sam model w innym formacie, na innym silniku. Do niego wrócę.

Ile kosztuje zły wybór

Zmierzyłem wszystkie trzy tym samym zestawem: trzy różne wykresy słupkowe, prośba o odczytanie tytułu i wartości. Za każdym razem inny obrazek — o tym, dlaczego to ważne, za chwilę.

enkoder w pamięci systemowej:   ~24 600 ms
enkoder na karcie:               ~3 555 ms
inny silnik, format NVFP4:       ~1 030 ms

Dwadzieścia cztery sekundy. Na jeden obrazek. Przy wrzuceniu trzech zrzutów ekranu do rozmowy robi się z tego ponad minuta samego patrzenia, zanim model powie pierwsze słowo.

Różnica między skrajnymi wariantami to dwadzieścia cztery razy. Nie dwadzieścia cztery procent.

Co ważniejsze: wariant najszybszy nie każe niczego poświęcać. Ma wzrok wbudowany w silnik — nie jako doklejony plik obok, tylko jako część tego samego modelu — i równocześnie ma włączone przewidywanie w przód. Czyli to, czego w plikach GGUF nie dało się mieć naraz.

Pułapka, w którą wdepnąłem po drodze

Pierwszy pomiar wariantu z enkoderem w pamięci systemowej dał mi tysiąc dwieście czterdzieści dwie milisekundy. Dwadzieścia razy lepiej niż w rzeczywistości.

Wysłałem ten sam obrazek dwa razy pod rząd. Za drugim razem nikt niczego nie liczył — silnik rozpoznał, że początek rozmowy jest identyczny, i oddał gotowy stan z pamięci podręcznej. Zmierzyłem cache, nie widzenie.

To dokładnie ta sama pułapka, którą opisałem w poprzednim tekście przy okazji prefillu, gdzie wyszło mi dziewięćdziesiąt dwa tysiące tokenów na sekundę. Zastawiona w innym miejscu, zadziałała drugi raz tego samego popołudnia.

Jeśli mierzysz cokolwiek, co ma pamięć podręczną, a chcesz zmierzyć pracę — każde powtórzenie musi być inne. Trzy obrazki zamiast jednego. Inny prompt za każdym razem. Inaczej mierzysz, jak szybko silnik rozpoznaje, że już to widział.

I ta sama uwaga co poprzednio: pierwszy przebieg po przełączeniu modelu zawsze jest fałszywy. We wszystkich trzech wariantach pierwszy pomiar pokazał dziewięć sekund — bo w czasie siedziało ładowanie wag. Dopiero drugi i trzeci są prawdziwe.

Co z tego wynika

Przez kilka miesięcy traktowałem te trzy wpisy jak coś oczywistego. Potrzebujesz obrazków — przełączasz się na wersję od obrazków. Potrzebujesz szybkiego kodu — wracasz na wersję z przewidywaniem. Koszt: kilkadziesiąt sekund na przeładowanie modelu za każdym razem, kiedy zmieniasz rodzaj zadania.

Uznałem, że tak po prostu jest, bo karta ma tyle pamięci, ile ma.

A to nie była właściwość karty. To była właściwość tego, jak konkretny silnik pakuje model do pamięci. Inny silnik, ten sam sprzęt, te same trzydzieści dwa gigabajty — i nagle nie ma czego wybierać, bo wzrok kosztuje sekundę i nie zabiera niczego innego.

Najdroższe ograniczenia to te, które przestajesz zauważać. Nie dlatego, że są nie do obejścia — dlatego, że dawno przestałeś sprawdzać, czy nadal obowiązują.

Trzy wpisy w konfiguracji zostają. Ale już nie dlatego, że muszę wybierać — tylko żeby mieć z czym porównywać.