Tek Bir RTX 3090 Üzerinde 381 tok/s Qwen Yığını: Gerçek Sohbette 118 tok/s ve Çöken Manşet Modu

Geçtiğimiz günlerde tek bir RTX 3090 ekran kartında çalışan 27B parametreli bir modelin saniyede 82 ila 381 token (tok/s) hıza ulaştığına dair bir paylaşım ses getirdi. Kendi ajan (agent) oturumlarım için sürekli aktif tuttuğum bir RTX 3090 kartım olduğundan, bu yığını kurup kendi test ortamımda iki kez ölçümledim. Kullanılan yığın, Qwen3.8-27B modeli için W4A16 nicelemesiyle (~19.5 GB ağırlık) ve DFlash2 spekülatif kod çözme (speculative decoding) tekniğiyle optimize edilmiş Apache-2.0 lisanslı bir vLLM derlemesi olan HyperQwen'dir. Referans noktamız ise aynı kartta llama.cpp altında yaklaşık 42 tok/s hız veren Q4_K_M GGUF formatındaki aynı 27B modelidir. Bu süreç, yerel LLM dağıtımlarında ve Ölçeklendirme ve Optimizasyon süreçlerinde kağıt üzerindeki hızlarla üretim ortamı gerçekleri arasındaki farkı anlamak adına önemli dersler sunuyor.

İlk Deneme BIOS Menüsünde Son Buldu#

Ekim başında sistemde Windows kuruluydu. HyperQwen yığını yalnızca Linux desteklediği için tek yol Docker Desktop ve WSL2 kullanmaktı. Bir gecede tüm hazırlıkları tamamladım:

WSL ve VirtualMachinePlatform etkinleştirildi, depo klonlandı ve model indirildi.
Yeniden başlatma sonrası sunucuyu ayağa kaldıracak görevler ve hipervizör (hypervisor) göründüğünde çıkarım (inference) cron işlerini duraklatıp testi otomatik başlatacak 10 dakikalık bir izleyici döngü kuruldu.

Ancak ilk deneme çalışması hypervisor present: False ... enable it in BIOS hatasıyla durdu. Bellenimde (firmware) sanallaştırma kapalıydı ve bunu açmak fiziksel olarak klavyenin başına geçip BIOS'tan SVM modunu etkinleştirmeyi gerektiriyordu. Daha sonra sistem tamamen silinip Arch Linux ile yeniden kuruldu. Yerel (native) Docker hipervizöre ihtiyaç duymadığı için hem Windows hazırlıkları hem de BIOS engeli ortadan kalktı.

Pratik Çıkarım: Yapay zeka altyapılarında Linux üzerinde yerel konteyner çalıştırmak, sanallaştırma katmanlarının getirdiği donanım ve yapılandırma engellerini doğrudan ortadan kaldırır.

On Gün Sonra, On Dört Dakikalık Bir Pencere#

Sistemin yeniden canlandırılması çoğunlukla altyapı tesisatından ibaretti: Depoyu ~/HyperQwen dizinine klonlamak, 9.5 GB'lık imajı çekmek, ağırlıkları indirmek ve .env dosyasına SPEC=dflash2 ile PREFIX_CACHE=1 ayarlarını girmek. Buradaki temel kısıtlama ekran kartı belleğiydi. 24 GB'lık bir RTX 3090 yalnızca tek bir 21 GB sınıfı modeli barındırabilir ve benim kartım halihazırda :8080 portunda llama-swap ile sunulan 21.6 GB'lık kodlayıcı modelim (Strata) tarafından doldurulmuştu.

İkinci büyük bir model yalnızca kısa bir zaman penceresinde var olabilirdi. Önce trafiği kontrol ettim; model kilidini tutan aktif bir oturum yoktu, yalnızca kesintiye uğraması güvenli olan cron trafiği vardı. Tekrarlayan yedi ajan cron işini duraklattım, mevcut modeli durdurdum ve HyperQwen'i :18020 portunda ayağa kaldırıp test ettim. Eski modeli durdurmaktan sonuçları diske yazmaya kadar geçen süre 14 dakikaydı ve sistemin ilk sağlıklı duruma (healthy) gelmesi yaklaşık 3 dakika sürdü.

Sistemimdeki Gerçek Rakamlar#

420W güç sınırında, 610.57 sürücüsü ve CUDA 13.3 ile yapılan ölçümlerde elde edilen sonuçlar şunlardır:

Açgözlü (Greedy) Sohbet (Düşünme Odaklı İstemler): Spekülatif kod çözme için en kötü senaryo olan bu durumda dört istem genelinde ortalama 118.1 tok/s (111 ile 131 arası) hız alındı.
Örneklemeli Sohbet (temp 0.7): Ortalama 123.3 tok/s hıza ulaşıldı. Projenin tek kullanıcılı sohbet için belirttiği ~127 tok/s referans değeriyle uyumlu bir sonuç elde edildi.
Bağlam Alıntılama (Context Quoting): Modelin 29k token'lık bir istemden bir bölümü birebir kopyaladığı testte 237.6 tok/s decode hızı ve başarılı doğrulama sağlandı.
Ön Dolum (Prefill) ve Başlatma: Prefill hızı yaklaşık 1,210 tok/s (~24 saniye) olarak ölçüldü; bu da llama.cpp'nin (~250 tok/s) yaklaşık beş katıdır. İlk JIT derlemesiyle hazır olma süresi ~3 dakika, sıcak başlatmada (warm boot) ise ~1 dakikadır.

42 tok/s'lik GGUF referans noktasına kıyasla gerçek sohbette 3 kat, alıntılamada ise 6 kat hız artışı sağlandı.

381 Rakamı Nereden Geliyor ve Nerede Çöküyor?#

Manşetlerdeki 381 tok/s rakamına ulaşmak için spekülatif kod çözücüde daha uzun bir taslak bloğu anlamına gelen ve varsayılan olmayan DFLASH_TOKENS=15 ayarına ihtiyaç var. Bu ayarı denediğimde normal sohbet hızı 115.5 ve 123.4 tok/s ile aynı bantta kaldı. Ancak 20k bağlamlı alıntılama isteği gönderildiğinde motor çöktü. Sistem, int4 taslak çekirdeklerinde (draft kernels) aten::empty çağrısının başarısız olması ve marlin_gemm bellek ayırma hatası nedeniyle EngineDeadError verdi.

Pratik Çıkarım: Spekülatif kod çözme parametrelerini agresif şekilde artırmak, VRAM sınırlarında çalışan GPU'larda uzun bağlam (long context) işlemleri sırasında bellek tahsis hatalarına ve üretimde çökmelere yol açabilir. Kendi donanımınızda gerçek iş yükleriyle doğrulama yapmadan varsayılan dışı "rekor" parametreleri canlı ortama taşımayın.