Ilu użytkowników obsłuży Qwen na jednej RTX 3090?

Jedna RTX 3090 może obsługiwać krótkie żądania kilku użytkowników, ale sama liczba pracowników niczego tu nie rozstrzyga. Znaczenie mają długość wejścia, długość odpowiedzi, liczba żądań obsługiwanych naraz i czas oczekiwania, który firma może zaakceptować. Nasza domowa konfiguracja obsługiwała jedno żądanie naraz, dlatego mierzyliśmy czas pracy pojedynczego agenta. Publiczny test tej samej klasy karty pokazuje dodatkowo, co dzieje się przy wielu strumieniach.

W artykule zestawiamy dwa źródła. Pierwsze to nasze zmierzone czasy pojedynczych zadań. Drugie to publiczny test Qwen3.8-27B na jednej RTX 3090, przygotowany dla 1, 2, 4 i 8 równoległych strumieni. Każda przytoczona wartość pochodzi z zapisanego przebiegu. Zestawienie pomaga oddzielić możliwości modelu od decyzji dotyczących kolejki i serwera, a także wskazuje pomiary potrzebne przed wdrożeniem.

Co zmierzyliśmy przy jednym zadaniu naraz

Na domowym komputerze po godzinach uruchamialiśmy jedno żądanie. Kolejne żądania czekały w kolejce. VRAM oznacza pamięć karty graficznej. Czas zależał od rodzaju pracy:

Codex przyznał Qwen Code wynik 100/100 po zakończeniu pracy, stosując kryteria Syntalith. Skala obejmuje poprawność (40 pkt), testy regresji (20), zgodność (15), zakres zmian (10), weryfikację (10) i dokumentację (5). Ocena dotyczy tego jednego przebiegu; niezależne laboratorium nie brało udziału.

Każdy wiersz opisuje pojedyncze uruchomienie. Z tych czasów nie wynika liczba zadań możliwych do wykonania w godzinę przy obciążeniu. Pomiar nie obejmował równoczesnego przetwarzania wejścia, zmiany konfiguracji, oczekiwania w kolejce ani ponowienia po błędzie.

Publiczny test wielu strumieni na RTX 3090

Repozytorium syv-ai/qwen38-27b-rtx3090 opisuje test Qwen3.8-27B na jednej RTX 3090, z poprawionym stosem vLLM. Każdy strumień otrzymywał osobne wejście długości 4 tys. tokenów i generował 256 tokenów. Serwer dopuszczał najwyżej osiem sekwencji.

MTP to dodatkowy moduł predykcyjny używany do przewidywania kolejnych tokenów. W tym teście autor zmierzył konfigurację serwera z MTP:

Tempo na strumień oznacza liczbę tokenów odpowiedzi generowanych w sekundę dla jednego użytkownika. Łączne tempo sumuje wynik wszystkich strumieni. Czas pojedynczego przejścia modelu pokazuje koszt jednego kroku obliczeń.

Łączna przepustowość rosła, lecz każdy użytkownik dostawał odpowiedź wolniej. Przy ośmiu strumieniach było to 23 tok/s na strumień, a przy jednym 126 tok/s. Skrót tok/s oznacza liczbę tokenów odpowiedzi wygenerowanych w ciągu sekundy. Pojedyncza liczba tokens/s nie pokazuje kosztu współbieżności.

W pomiarze DFlash2 uzyskano 137 tok/s dla jednego strumienia, 97 dla dwóch i 46 dla czterech. Przy żądaniu ośmiu strumieni pamięć GPU pomieściła tylko pięć sekwencji, więc autor nie podał stabilnego wyniku C8, czyli wariantu dla ośmiu strumieni. Konfiguracja najszybsza dla jednego użytkownika miała mniejszą pojemność.

Długie wejścia potrafią zdominować wynik

W tym samym repozytorium uruchomiono osiem niezależnych wejść po 16 tys. tokenów. Łączne tempo całej próby spadło do 15,8 tok/s, a średni czas do pierwszego tokena wyniósł 71,7 s. Wstępne przetworzenie około 131 tys. tokenów wejściowych zajęło większość pracy przed rozpoczęciem generowania odpowiedzi.

Przy ośmiu żądaniach współdzielących ten sam prefiks 16 tys. tokenów serwer mógł użyć pamięci podręcznej prefiksu. Dla dwóch strumieni zmierzono 128,4 tok/s łącznie i średni TTFT, czyli czas do pierwszego tokena, równy 1,3 s. Dla czterech strumieni było to 147,8 tok/s i 2,6 s. Te wartości opisują ten konkretny test i nie stanowią obietnicy dla firmowego czatu. Pokazują, że rozkład długości wejść i możliwość współdzielenia prefiksu wpływają na pojemność usługi.

Dlaczego te wyniki nie trafiają wprost do oferty

Publiczny test korzysta z dostrojonego, zmodyfikowanego stosu, odpowiedzi o długości 256 tokenów i ściśle zdefiniowanych wejść. Nasza konfiguracja używała innego serwera, a agenty wykonywały wieloetapowe zadania z narzędziami. Wyników nie można bezpośrednio porównać ani przepisać do prognozy dla zespołu.

Przed wdrożeniem trzeba zmierzyć na docelowym serwerze:

• czas do pierwszego tokena i czas całego zadania dla każdej klasy pracy;
• tempo na użytkownika oraz tempo łączne przy 1, 2, 4 i 8 żądaniach;
• liczbę sekwencji mieszczących się w pamięci przed błędem;
• wpływ długiego przetwarzania wejścia i pamięci podręcznej wspólnego prefiksu;
• 95. centyl czasu oczekiwania przy reprezentatywnym ruchu, czyli wartość, poniżej której mieści się 95% obserwacji;
• odsetek zadań zakończonych wynikiem zaakceptowanym przez test, ponieważ szybki błędny wynik nie zwiększa przepustowości procesu.

Wniosek na dziś

Jedna RTX 3090 może obsłużyć więcej niż jedną krótką sekwencję, ale tempo na użytkownika spada, a pojemność zależy od konfiguracji. Nasz serwer wykonywał jedno aktywne zadanie naraz, co wystarczyło do eksperymentu programistycznego, lecz nie opisuje architektury dla zespołu. Publiczny test utrzymał osiem krótkich strumieni w konkretnym stosie MTP, podczas gdy pamięć GPU w konfiguracji DFlash2 pomieściła pięć sekwencji.

Decyzję o zakupie drugiej karty powinny wyznaczać docelowy TTFT, długość kolejki i udział zaakceptowanych wyników. Liczba pracowników sama w sobie nie jest miarą przepustowości.

Jak Syntalith prowadzi taki pilotaż

Możemy uruchomić model na sprzęcie klienta albo zbudować odizolowane środowisko pilotażowe. Odtworzymy szczytowy ruch i przedstawimy pomiary opóźnienia, przepustowości, VRAM oraz jakości. Projekt obejmuje kolejkę, limit współbieżności, klasy danych, kontrolowany wariant zapasowy i jasno określony próg skalowania.

Audyt procesu AI zaczyna się od 4990 zł netto. Jeśli test uzasadni lokalny system, Aplikacje AI mogą obejmować API, panel, monitoring i plan aktualizacji. Pierwszym krokiem może być bezpłatny skan procesu.