Uruchamianie Qwen3.8-27B na jednym RTX 3090 z poprawionym vLLM i DFlash2
Jak przymocowana gałąź vLLM 0.28.0 z rekwantyzowanymi embeddingami i technologią DFlash2 umożliwia uruchomienie hybrydowego modelu o wielkości 27 miliardów parametrów na karcie pamięci o pojemności 24 GB, oraz dlaczego długi kontekst spowalnia jego działanie.
Model z 27 miliardami parametrów na pojedynczej karcie graficznej konsumenckiej zazwyczaj oznacza trudny wybór pomiędzy długością kontekstu, równoczesnością a szybkością. Społecznościowa wersja vLLM dostosowana do Qwen3.8-27B zmienia tę sytuację na karcie RTX 3090 o pojemności 24 GB: w zadaniu wymagającym wykorzystania wielu agentów osiąga około 177 tokenów na sekundę przy dekodowaniu na zwykłej karcie (nie Ti) o ograniczeniu mocy do 300 W. Ten przewodnik opisuje instalację bez użycia kontenerów, wyjaśnia, które optymalizacje zapewniają taką szybkość, oraz pokazuje dokładnie, w którym momencie ten podejście przestaje być opłacalne, abyś mógł zdecydować, czy pasuje do twoich zadań.
Dwa profile uruchomienia opisane poniżej kompromitują się między długością kontekstu a równoległością oraz szybkością. Dane pochodzą z zadania dla agenta na jednym urządzeniu, więc należy je traktować jako wskazówkę, a nie gwarancję.
| Config | Context | Parallel requests | My measured decode speed |
|------------|-----------|-------------------|--------------------------|
| CTX=fast | 65,536 | 8 | ~177 tok/s |
| CTX=long | 131,072 | 4 | ~122 tok/s |
Ponieważ serwer udostępnia API kompatybilne z OpenAI, podłączenie go do narzędzia typu DeepSeek Harness polega jedynie na wskazaniu klientowi adresu bazowego w formacie http://<host>:18020/v1 oraz dostarczeniu klucza uprawniającego. Podagenty mogą następnie wysyłać żądania równolegle do lokalnego modelu, który odpowiada z szybkością wymagającą wcześniej sprzętu typu datacenter.
Czym właściwie jest projekt qwen38-27b-rtx3090
Projekt znajduje się w repozytorium syv-ai/qwen38-27b-rtx3090. Nie jest to ani nowy model, ani nowy silnik inferencji. Jest to odgałęzienie przytwierdzone do wersji vLLM 0.28.0, połączone z zestawem poprawek, skryptów do rekwantyzacji oraz profili uruchamiania, których jedynym celem jest umieszczenie tego specyficznego modelu hybrydowego na karcie pamięci o pojemności 24 GB i jego szybkie uruchamianie.
Dostarczono obraz Dockera, a docker compose --profile single up -d stanowi pełną procedurę instalacji, jeśli jesteś zadowolony z użycia kontenerów. Repozytorium umożliwia również wykonywanie tych samych kroków ręcznie w wirtualnym środowisku Pythona, co zostało tu zastosowane. Dzięki temu logi pozostają widoczne, unika się dodatkowego dużego obrazu na dysku i łatwiej jest zobaczyć, jakie zmiany wprowadza każdy krok.
Dlaczego wartość pojedynczego tok/s niewiele znaczy
Przepustowość tego stacku w dużej mierze zależy od wykonywanej zadania. Generowanie kodu jest szybkie, pisanie dłuższych tekstów wolniejsze, natomiast odtwarzanie tekstu już zawartego w promptzie odbywa się znacznie szybciej (sekcja poniżej wyjaśnia dlaczego). Dokumentacja projektu podkreśla ten sam punkt: liczba przepustowości dla tego stacku nic nie mówi, jeśli nie wiemy również, jaki prompt ją wygenerował. Wartość 177 tok/s została zmierzona przy użyciu obciążeń agenta; twoje wyniki będą zależeć znacznie bardziej od treści twoich promptów niż od przypadku.
Instalacja natywna, bez Dockera
Zanim zaczniesz, upewnij się, że maszyna posiada:
- Linux lub WSL2 z kartą RTX 3090 dowolnej wersji (ważna jest ilość pamięci VRAM – 24 GB)
- Aktualny sterownik NVIDIA, aby
nvidia-smidziałał bez błędów - Python 3.12 lub nowszy, wraz z odpowiednimi plikami headerów do rozwoju
Pрактиcznym sposobem na szybkie spełnienie wymagań na poziomie systemu jest skorzystanie z agenta programistycznego z dostępem do wiersza poleceń (Claude Code, Codex, OpenCode lub podobne), który zajmie się instalacją. Wskazuj mu repozytorium i poproś go o uruchomienie całego zestawu narzędzi na karcie 3090. Gdy coś pójdzie nie tak, agent odczytuje błąd i rozwiązuje go na miejscu – czy to instalując python3.12-dev lub libssl za pomocą apt, aktualizując sterownik lub zmieniając zestawy narzędzi CUDA. Dzięki temu poszukiwanie brakujących pakietów, które wcześniej zajmowałoby całe popołudnie na przeglądaniu forów, staje się zwykłym krokiem. Sprawdzaj, co uruchamia agent, tak jak robisz to w przypadku każdego narzędzia z dostępem do wiersza poleceń.
Krok 1: sklonuj repozytorium
Najpierw pobierz repozytorium i przenieś się do niego.
git clone https://github.com/syv-ai/qwen38-27b-rtx3090
cd qwen38-27b-rtx3090
Krok 2: utworzenie środowiska wirtualnego i zainstalowanie określonej wersji vLLM
Fork dotyczy konkretnie wersji vLLM 0.28.0, ponieważ to właśnie w tej wersji dekodowanie spekulatywne DFlash2 stało się częścią oryginalnego vLLM (połączone w PR #52816). Poniższe polecenia tworzą nowe środowisko wirtualne i instalują dokładnie tę wersję wraz z FlashInfer, narzędziami do pobierania plików z Hugging Face, ninja do budowy jąder oraz pandas.
python3.12 -m venv venv
venv/bin/pip install -U pip
venv/bin/pip install vllm==0.28.0 huggingface_hub hf_transfer ninja \
flashinfer-python flashinfer-cubin==0.6.13 pandas
Dwa szczegóły w tym tekście mogą łatwo zostać błędnie zrozumiane:
- Nie pozwól, aby pip przeniósł plik
flashinfer-pythondo innej wersji. Program uruchamiający ustawia wartośćFLASHINFER_DISABLE_VERSION_CHECK=1, a poprawki zostały sprawdzone dokładnie na tym określonym zestawie wersji.
curand.h. Jeśli Twoja instalacja CUDA nie posiada plików nagłówkowych curand, kompilacja zawodzi już przy pierwszym uruchomieniu, a serwer cicho przechodzi na wolniejszą alternatywę. Wynik pozostaje prawidłowy, przepustowość spada o około 5%, a w logach nic o tym nie informuje. Na Ubuntu z CUDA 13 problem ten można rozwiązać, instalując libcurand-dev-13-0 za pomocą apt.Drugi punkt to dobry przykład awarii, której nie wykryje żadna kontrola stanu. Jeśli Twoje wartości są o kilka procent niższe, najpierw sprawdź te pliki nagłówkowe.
Krok 3: pobierz podstawowy punkt kontrolny
Punktem wyjścia jest punkt kontrolny dbirks/Qwen3.8-27B-W4A16-AutoRound o wielkości około 19,5 GB. Włączenie wysokowydajnego trybu transferu Xet znacznie przyspiesza pobieranie.
HF_XET_HIGH_PERFORMANCE=1 venv/bin/hf download \
dbirks/Qwen3.8-27B-W4A16-AutoRound \
--local-dir models/Qwen3.8-27B-W4A16-AutoRound
Krok 4: przygotuj model
Skrypty w katalogu prepare/ modyfikują punkt kontrolny. Przekształcają matryce embeddingów wejściowych i wyjściowych, które publiczne punkty kontrolne w formie kwantyzowanej zachowują z pełną precyzją, odbudowują głowę MTP wokół lepiej dopasowanego słownictwa, a następnie pobierają szybką wersję wraz z plikiem DFlash2 o rozmiarze 1,2 GB. Wszystko działa na procesorze CPU, a każdy skrypt jest wykonywany w ciągu kilku minut.
M=models/Qwen3.8-27B-W4A16-AutoRound
venv/bin/python prepare/quant_lm_head.py $M
venv/bin/python prepare/quant_embed.py $M
venv/bin/python prepare/quant_mtp.py $M
venv/bin/python prepare/build_draft_vocab.py $M --ids prepare/draft_vocab_ids.json
venv/bin/python prepare/fetch_fast_variant.py
venv/bin/python prepare/fetch_dflash2.py
Krok 5: zastosowanie stosu patchów
Katalog patches/ zawiera około piętnastu plików .patch, które obejmują m.in. konfigurację kwantyzacji embeddowania, mechanizm uwagi split-KV do weryfikacji projektów, poprawki do jąder Marlin int8, funkcje wyszukiwania w DFlash2 oraz inne elementy. Kolejność tych plików jest określona w pliku patches/series. Poniższy pętla usuwa komentarze i puste linie z tego pliku oraz aplikuje każdą poprawkę do pakietu vLLM znajdującego się w środowisku venv. Pętla pomija plik dflash2-backport.patch, który istnieje tylko w wersjach vLLM starszych niż 0.28.0, gdy DFlash2 jeszcze nie był wbudowany.
sed -e 's/#.*//' -e 's/^[[:space:]]*//;s/[[:space:]]*$//' -e '/^$/d' patches/series |
while IFS= read -r name; do
[ "$name" = "dflash2-backport.patch" ] && continue
patch -p1 -d venv/lib/python3.12/site-packages/vllm < "patches/$name"
done
Poprawka, której aplikacja nie udaje się, niemal zawsze wskazuje na niezgodność wersji. Uruchom polecenie venv/bin/pip show vllm i upewnij się, że wyświetla dokładnie wartość 0.28.0.
Krok 6: weryfikacja instalacji
Zanim cokolwiek uruchomisz, utwórz klucz API i wyślij skrypt weryfikacyjny w trybie offline. Sprawdza on, czy wszystkie aktualizacje zostały zainstalowane i czy model ma oczekiwany kształt.
openssl rand -hex 24 > api_key.txt
bash verify.sh --no-server # checks all patches applied + model shape correct
Czysty wynik oznacza, że twoja instalacja jest identyczna, bajt po bajcie, z konfiguracją, na której opierają się testy utrzymywaczy oprogramowania. W przypadku samodzielnej obsługi modeli, gdy subtelne różnice wersji stanowią stałe źródło zamieszania, ta powtarzalność jest niezwykle cenna.
Krok 7: uruchomienie serwera
Cała konfiguracja odbywa się za pomocą zmiennych środowiskowych. Domyślny polecenie aktywuje funkcje DFlash2 oraz cacheowanie prefiksów na wybranym GPU; komentarz pokazuje, jak przełączyć się na profil długiego kontekstu lub na profil 245k po uruchomieniu kvarn/install.sh.
CUDA_VISIBLE_DEVICES=0 SPEC=dflash2 PREFIX_CACHE=1 bash single-user/start_qwen.sh
# add CTX=long for ~131k context (4 slots), or CTX=huge after kvarn/install.sh for 245k
Zawsze ustawiaj CUDA_VISIBLE_DEVICES wyraźnie. W przeciwnym razie vLLM ma tendencję do wyboru karty GPU z największą ilością wolnej pamięci, co na maszynie z wieloma kartami GPU może nie być tą kartą, którą zamierzałeś użyć. Klucz dostępu jest odczytywany z pliku api_key.txt lub z zmiennej VLLM_API_KEY; ustaw go przed udostępnieniem portu komukolwiek poza localhost, ponieważ bez klucza serwer akceptuje nieautoryzowane żądania. Pozostałe ustawienia pochodzą z pliku .env. Kilka minut po uruchomieniu masz endpoint kompatybilny z OpenAI, który obsługuje model 27B na jednej karcie o cenie niższej niż używane rower.
Z czego pochodzi szybkość
Zapусk vLLM na gotowych, skwantyzowanych punktach kontrolnych marnuje wydajność w kilku nieoczywistych miejscach. Dokument z optymalizacjami projektu (docs/optimizations.md w repozytorium) opisuje dziewięć zmian. Cztery z nich odpowiadają za większość uzyskanych korzyści.
Skwantyzacja embeddingów, które wszyscy pomijają
Qwen3.8-27B wykorzystuje niespowiązane embeddingi, co oznacza oddzielne tabele wejściowe i wyjściowe po około 2,5 GB każda. Publiczne „skwantyzowane” punkty kontrolne przechowują obie tabele w formacie bf16, głównie dlatego, że ich skwantyzacja jest trudna. Skrypty przygotowawcze przekształcają je obie na int8, co pozwala zaoszczędzić 2,6 GB pamięci VRAM bez widocznego spadku jakości. Na karcie o pojemności 24 GB to wystarcza mniej więcej na kontekst dodatkowego użytkownika.
Tylko 16 z 64 warstw modelu to konwencjonalne warstwy uwagi, których pamięć rośnie wraz z kontekstem. Pozostałe 48 to warstwy Gated DeltaNet – projekt oparty na uwadze liniowej, którego stan na dany dialog ma stałą wielkość, niezależnie od tego, czy dialog składa się z 100, czy 100 000 tokenów. Wersja stock vLLM przechowywała ten stan w formacie fp32, co zajmowało około 150 MB na każdą prośbę, i nie była w stanie obsłużyć więcej niż 37 jednoczesnych zapytań, mimo ustawionej granicy na 64. Wersja fork przechowuje ten stan w formacie fp16, wartość perplexity pozostaje identyczna z dokładnością do trzech miejsc po przecinku, a wszystkie ustawione sloty stają się dostępne do użytku.
DFlash2: tworzenie siedmiu tokenów w jednej rundzie
Ta zmiana ma największe znaczenie dla opóźnienia przy pojedynczych żądaniach. Dekodowanie spekulatywne łączy mały model pomocniczy z dużym modelem docelowym. Model pomocniczy proponuje kilka kolejnych tokenów, a model docelowy weryfikuje je wszystkie w jednej transmisji danych, zachowując poprawny prefiks i regenerując tekst od pierwszego błędu. Weryfikacja jest znacznie tańsza niż generowanie na karcie GPU o ograniczonej pamięci, ponieważ wagi są czytane tylko raz dla kilku tokenów, dzięki czemu każdy krok może przynieść więcej niż jeden token.
Wbudowany w Qwen mechanizm MTP łączy cztery próby jedna po drugiej. Zamiast niego używany jest DFlash2 – narzędzie o pięciu warstwach, które przewiduje cały blok składający się z siedmiu tokenów w jednej, nieautoregresywnej iteracji, wykorzystując ukryte stany pochodzące z pięciu różnych głębokości modelu docelowego. Sam mechanizm ten został skwantyzowany z GPTQ z 3,85 GB do 1,19 GB, dzięki czemu może korzystać z tej samej karty bez intensywnego konkurowania o przepustowość pamięci. W rezultacie uzyskuje się około trzech tokenów na krok zamiast jednego. Ponieważ standardowe dekodowanie spekulacyjne przyjmuje lub odrzuca tokeny wstępne, aby końcowa dystrybucja wyników odpowiadała wyłącznie modelowi docelowemu, przyspieszenie jest bezstratne; dokładność GSM8K pozostaje na poziomie 96–96,5% we wszystkich konfiguracjach opisanych w repozytorium.
Słownictwo wstępne utworzone na podstawie własnych wyników modelu
Twórca może proponować jedynie tokeny, które istnieją w jego skróconej bazie słów kluczowych; wszystko poza nią jest z definicji odrzucane. Początkowa baza słów kluczowych pochodziła z tekstów internetowych i obejmowała 92% tokenów faktycznie generowanych przez ten model. Konserwatorzy zebrali 5,4 miliona tokenów z własnych wyjść modelu i odbudowali bazę słów kluczowych na podstawie tych danych, osiągając 97,5% pokrycia. Sam ta zmiana zwiększyła wydajność o około 10%, bez konieczności używania nowego sprzętu ani modyfikacji modelu.
Szukanie tokenów dla tekstu cytowanego przez model
Kolejna technika wyjaśnia najbardziej ekstremalne wartości. Gdy wynik powtarza materiał już obecny w zapytaniu, takie jak kod źródłowy pod edycją lub wklejony dokument, ta technika omija proces tworzenia wyniku i proponuje tokeny bezpośrednio z kontekstu. Odtworzenie dokumentu składającego się z 25 tysięcy tokenów osiąga prędkość 381 tok/s na podanych urządzeniach. Agenci kodujący spędzają dużo czasu na odtwarzaniu kodu, który pojawił się chwilę wcześniej w zapytaniu – to idealny przypadek dla tej techniki, i jest to jeden z powodów, dla których pomiary wydajności agentów są tak wysokie.
Dlaczego podwojenie kontekstu nie powoduje wyczerpania VRAM
Zainstalowany domyślnie launcher dla jednego użytkownika używa kontekstu o wielkości 65 tysięcy elementów. Ustawienie CTX=long mniej więcej podwaja tę wartość do 131 tysięcy, więc można by oczekiwać błędu braku pamięci na karcie o pojemności 24 GB. Tymczasem serwer uruchamia się normalnie i działa tylko nieco wolniej. Kilka decyzji projektowych tłumaczy to zjawisko.
- Masy mają ustaloną objętość pamięci. Przy kwantyzacji W4A16 korpus modelu zajmuje około 15 GB, niezależnie od długości kontekstu.
- Zbiór KV jest rezerwowany raz, w bajtach. Przed obsługą jakiegokolwiek ruchu fork rezerwuje określoną ilość pamięci, w tym przypadku około 5,2 GiB, a vLLM zapisuje ten wynik, na przykład „Rozmiar bufora KV GPU: 136 429 tokenów”. Ponieważ zbiór ten jest przydzielany podczas uruchamiania, albo mieści się w dostępnej pamięci, albo serwer odmawia uruchomienia. Nie ma możliwości przydzielania pamięci na żądanie, które mogłoby zawieść w trakcie wykonywania zadania agenta.
CTX=long przechowuje je w formacie int8, co zmniejsza koszt na token o mniej więcej połowę. To samo 5,2 GiB może więc pomieścić 136 429 tokenów zamiast 68 605, podwajając maksymalną długość kontekstu do 131 tysięcy. Wartość perplexity wymuszona przez nauczyciela dla identycznego tekstu różni się między tymi dwoma profilami zaledwie o 0,2%.Dlaczego limit wynosi 131 072, a nie 136 429
Nie cała pojemność bufora może zostać przeznaczona na cache zapytań. Każde zapytanie wymaga również swojego stanu DeltaNet o stałej wielkości, a DFlash2 dodaje do tego osiem miejsc na stan spekulatywny na każde zapytanie. Ponieważ w profilu długim dostępnych jest cztery miejsca, program uruchamiający ustawia maksymalną liczbę kontekstów na 131 072, co stanowi około 4% mniej niż całkowita pojemność bufora, pozostawiając resztę na te strony stanu oraz na wyprostowanie bloków. To zapas pojemności jest podstawą obietnicy braku problemów z pamięcią: podczas uruchamiania sprawdzany jest najtrudniejszy scenariusz, czyli pojedyncze zapytanie o maksymalnej długości, przy jednoczesnym wykorzystaniu wszystkich pozostałych miejsc.
Czego zamiast tego tracisz
Dłuższy kontekst jest opłacany szybkością, a nie awariami. Tokeny są przechowywane w formacie int8, a każda prośba użytkownika rezerwuje strony stanu z puli, która teraz jest podzielona na mniej miejsc. Liczba slotów równoległych spada z 8 do 4, a szybkość dekodowania spada z około 177 do około 122 tok/s. Karta realizuje więcej z tych samych danych i jest opłacana za to przepustowością, a nie liczbą wyjątków.
Gdzie ulega osłabieniu: głęboki kontekst pojedynczej prośby
Stack funkcjonuje najlepiej przy krótkich i średnich kontekstach, które to są głównie tym, co wysyłają agenci. Jedna prośba obejmująca blisko 100 tysięcy tokenów zachowuje się inaczej. Zmierzone na karcie 3090, jedna prośba dekodowana była z prędkością około 107 tok/s przy krótkim promptzie, 78 tok/s przy około 10 tysiącach tokenów oraz 38 tok/s przy około 43 tysiącach, spadając do około 31 tok/s przy blisko 100 tysiącach tokenów. Przyczyną jest stopa akceptacji modelu, która maleje wraz z głębokością kontekstu. Repozytorium wykazuje ten sam efekt – stopa akceptacji utrzymuje się na poziomie około 0,29 niezależnie od typu pamięci cache – więc jest to właściwość modelu i głębokości kontekstu, a nie błąd wymagający naprawy.
Dla porównania wersja oparta na llama.cpp na tej samej klasie kart osiąga stałe tempo 65 do 80 toków na sekundę przy kontekście 150k. Nie posiada mechanizmu szacowania, którego wyniki by się pogarszały, ani bloku weryfikacji zapobiegającego dalszym obliczeniom, więc nigdy nie jest szczególnie szybka, ale też nigdy nie wolna. Poniższa tabela przedstawia obie wersje obok siebie; należy zauważyć, że zakres krótkiego kontekstu vLLM łączy dane dotyczące pojedynczej prośby z pomiarami dla agenta wielołotkowego.
| Context depth | vLLM fork (DFlash2) | llama.cpp ATX fork |
|-----------------|---------------------|--------------------|
| short (<4k) | 107–177 tok/s | 65–80 tok/s |
| ~10k | ~78 tok/s | 65–80 tok/s |
| ~43k | ~38 tok/s | 65–80 tok/s |
| ~100k | ~31 tok/s | 65–80 tok/s |
Praktyczna zasada jest prosta. Jeśli twoja praca polega głównie na powolnym czytaniu jednego bardzo długiego dokumentu, llama.cpp jest bardziej stabilną opcją; zapoznaj się z naszym przewodnikiem na temat serwowania modelu Qwen3.8 MoE na kartach RTX 3090s przy użyciu mechanizmu offloadingu tensorów w llama.cpp, aby dowiedzieć się więcej na temat tego kompromisu. Jeśli twoja praca polega na wielu rozmowach programistycznych o średniej długości, wersja vLLM jest znacznie lepsza.
Dlaczego to pasuje do narzędzi dla agentów
Narzędzia takie jak Pi, Hermes czy DeepSeek Harness nie obsługują pojedynczej rozmowy. Dzięki podagentom generują jednocześnie wiele równoległych wątków, zazwyczaj od pięciu do dwunastu, każdy o średniej długości, przy czym większość z nich wykorzystuje identyczny prompt systemowy oraz ten sam kontekst bazy kodu. To właśnie taki obciążenie zostało dostosowane dla tego rozgałęzienia:
- Ogólna przepustowość rośnie wraz z równoczesnością. Cztery równoległe strumienie dostarczyły łącznie ponad 300 toków na sekundę na jednej karcie 3090. Referencyjne testy z repozytorium pokazują od 279 do 335 toków na sekundę przy czterech równoczesnych żądaniach, a przy ośmiu żądaniach z użyciem MTP – nawet około 400 toków na sekundę łącznie.
PREFIX_CACHE=1 64 żądania wykorzystujące wspólny prompt systemowy o długości 5,8 tys. tokenów zostały zrealizowane w ciągu 17 sekund, zamiast 222 sekund w testach bazowych repozytorium, przy czym średni czas oczekiwania spadł z 95 s do 8 s. Po pierwszym żądaniu podagenty prawie w ogóle nie płacą za wspólne instrukcje. W tym hybrydowym modelu cache przechowuje również powtarzające się stany DeltaNet, a nie tylko dane attention KV, dlatego kolejna operacja na dokumencie o długości 24 tys. tokenów trwa około 1 sekundy, zamiast 23.Istnieje pewien limit. Po przekroczeniu około czterech strumieni długiego kontekstu uruchomionych lokalnie, ograniczeniem staje się sposób podziału zasobów, a nie moc obliczeniowa. W dokumencie producenta jasno stwierdza się, że osiem jednoczesnych zapytań o długi kontekst działa znacznie gorzej niż cztery, określając to mianem „nie kompromisu, lecz straty”. Optymalny projekt opiera się na około czterech równoległych procesorach o średniej głębokości, co pozwala w pełni wykorzystać możliwości karty. Aby zobaczyć przykład tego, co lokalna konfiguracja Qwen3.8-27B może stworzyć w praktyce, zapoznaj się z tworzeniem lokalnej klonów gier za pomocą Qwen3.8-27B i Pi.
Główne wnioski
- Szybkość pochodzi od oprogramowania: rekwantyzowane embeddingi, stan DeltaNet w formacie fp16, narzędzie DFlash2 obsługujące siedem tokenów oraz słownictwo dostosowane do rzeczywistych wyników modelu. Karta graficzna pozostaje bez zmian.
verify.sh, zanim zaufasz jakimkolwiek wynikom testów.Aby uzyskać więcej szczegółów, folder docs/reproductions w repozytorium zawiera instrukcje krok po kroku dotyczące odtworzenia procesu bez użycia Dockera na karcie 3090.
Literatura pokrewna
- Dostarczanie Qwen3.8-Flash-Next na kartach RTX 3090s przy użyciu llama.cpp Tensor Offloading — Dlaczego model o rozmiarze 88 GB i 180 miliardów parametrów nadaje się do kart graficznych konsumenckich oraz jak flagi takie jak -ot, -ncmoe i mmap w llama.cpp rozkładają jego dane pomiędzy VRAM, RAM i NVMe.
- Tworzenie lokalnego klonu Angry Birds za pomocą Qwen3.8-27B i Pi — Dowiedz się, jak skonfigurować w pełni lokalny proces tworzenia kodów AI przy użyciu LM Studio i agenta Pi, aby stworzyć gralny poziom Angry Birds z wykorzystaniem Qwen3.8-27B.