llama.cpp czy vLLM dla Qwen3.8-27B na RTX 3090?

llama.cpp jest lekkim silnikiem do uruchamiania modeli na różnych procesorach i kartach, szczególnie w formacie GGUF. vLLM jest serwerem nastawionym na wydajne kolejkowanie i obsługę wielu zapytań na GPU. Wybór dotyczy całej usługi. Szybkość pojedynczej odpowiedzi jest jednym z kilku kryteriów.

W eksperymencie po godzinach na domowym PC zmodyfikowany vLLM ukończył dopasowane zadanie Qwen Code w 502,14 s wobec 1468,76 s na llama.cpp. Zachowaliśmy llama.cpp jako rozwiązanie zapasowe, ponieważ GGUF jest prostszy do uruchomienia, przeniesienia i odtworzenia.

To porównanie dwóch kompletnych profili. Nie dowodzi, że oficjalne wydanie vLLM zawsze pokonuje llama.cpp ani że wagi W4A16 mają wyższą jakość od GGUF Dynamic V3.

Dwa różne produkty operacyjne

llama.cpp daje dojrzały format GGUF, prosty serwer, szeroki wybór sprzętu i precyzyjną kontrolę przenoszenia warstw między procesorem i kartą oraz pamięci kontekstu. Dobrze nadaje się do pilota, stanowiska osobistego i środowiska, w którym łatwość odtworzenia jest ważniejsza od maksymalnej przepustowości.

vLLM jest serwerem nastawionym na wydajne obsługiwanie modeli i udostępnia między innymi interfejsy zgodne z OpenAI. Wariant z domowego eksperymentu używał jednak zewnętrznej poprawki dla Qwen3.8/RTX 3090, zamrożonego vLLM 0.27.1, osobnego pliku wag AutoRound, FP8 KV, pamięci podręcznej wspólnego prefiksu i MTP-3. Tego wyniku nie należy przypisywać czystej instalacji z pip.

Najpierw surowe 115k

Na tym samym wejściu 115 074 tokenów oba profile odtworzyły fakty z początku, środka i końca.

vLLM był o 11,6% szybszy kosztem około 0,9 GiB dodatkowego VRAM. To czystszy test inferencji niż sesja agenta, choć profile nadal różnią się formatem wag i pamięcią kontekstu.

Potem całe zadanie Qwen Code

W zadaniu kodowym interesował nas zaakceptowany wynik:

Obie wersje dały kod nadający się do dalszej pracy. vLLM dołożył mocniejszy test serializacji, uniknął kompresji i zakończył zadanie znacznie szybciej. To wystarczyło, by został profilem zachowanym do kolejnych domowych prób.

Nie rozdzielimy z tej tabeli, ile zysku dały kernely, ile MTP, ile 30k dodatkowego kontekstu, a ile konkretny układ wag. Do tego potrzebna byłaby macierz kontrolująca każdą zmienną i wiele powtórzeń.

Gdzie llama.cpp nadal wygrywa

• Prostota artefaktu. Jeden plik GGUF łatwiej zweryfikować i przenieść.
• Zakres sprzętu. CPU, różne GPU i częściowy offload rozszerzają możliwości awaryjne.
• Kontrola pamięci. Profile wag, pamięci kontekstu i wielkości paczki są jawne i przewidywalne.
• Odtwarzanie. Mniej prywatnych poprawek oznacza mniejszy koszt aktualizacji.
• Rozwiązanie zapasowe. Gdy obraz vLLM lub jego plik wag przestanie działać po zmianie sterownika, sprawdzony GGUF przywraca usługę.

Rozwiązanie zapasowe zachowane w eksperymencie to llama.cpp, Dynamic V3 Q4_K_M, Q8 KV, 120k i medium, sterowany przez Codex. Nie jest najszybszy, ale ma zachowane testy i prostszą ścieżkę diagnostyczną.

Gdzie wybrany vLLM ma sens

Zmodyfikowany vLLM jest uzasadniony, gdy długie zadania są częste, różnica czasu powtarza się na zestawie akceptacyjnym, a zespół potrafi utrzymać obraz, plik wag i zgodność protokołu. Pamięć podręczna wspólnego prefiksu pomaga, gdy kolejne żądania współdzielą duży początek. Silnik daje też lepszą drogę do późniejszych testów kolejkowania.

Koszt utrzymania należy policzyć. Poprawka spoza oficjalnego projektu może zablokować aktualizację bezpieczeństwa albo nowy sterownik. Wtedy szybszy przebieg konkuruje z godzinami inżyniera potrzebnymi do ponownego zbudowania obrazu.

Matryca decyzji

Syntalith wdraża zwycięski profil razem z rozwiązaniem zapasowym, wykazem wersji, testem po restarcie i progiem aktualizacji. Audyt procesu AI od 4990 zł netto może zakończyć się rekomendacją prostszego llama.cpp, jeśli skala nie płaci za dodatkową złożoność. Bezpłatny skan procesu ustala zadanie, na którym warto to rozstrzygnąć.