Qwen3.8 27B (FP8, vLLM)

27 milyar parametreli bir modeli tek bir MIG dilimine sığdırıp OpenAI uyumlu bir uçtan sunmak, sonra da hızını tahmin etmek yerine ölçmek. Bu sayfadaki bütün sayılar bir H200 NVL kartının 4g.71gb dilimi üzerinde, vLLM'in kendi ölçüm aracıyla alınmıştır.

Neden FP8

Aynı model, üç ayrı biçimde:

H200 (Hopper) FP8'i donanımda destekler, yani küçültme hızdan çalmaz. Resmi Qwen/Qwen3.8-27B-FP8 deposu ince taneli (blok 128) FP8 kullanır.

vllm serve Qwen/Qwen3.8-27B-FP8 \
  --tensor-parallel-size 1 \
  --kv-cache-dtype fp8 \
  --enable-prefix-caching \
  --prefix-match-unit 16 \
  --reasoning-parser qwen3 \
  --host 0.0.0.0 --port 8000 \
  --max-model-len 65536

nvidia-smi -L

GPU 0: NVIDIA H200 NVL (UUID: GPU-ffa8158e-...)
  MIG 4g.71gb     Device  0: (UUID: MIG-a1b2be34-...)

Selected FlashInferFp8DeepGEMMDynamicBlockScaledKernel for Fp8LinearMethod
DeepGEMM PDL enabled · DeepGEMM E8M0 enabled
Using FlashAttention version 3

Available KV cache memory: 32.5 GiB
GPU KV cache size: 988,865 tokens
Maximum concurrency for 65,536 tokens per request: 15.09x

curl -s localhost:8000/v1/chat/completions -H 'Content-Type: application/json' -d '{
  "model": "Qwen/Qwen3.8-27B-FP8",
  "messages": [{"role":"user","content":"Explain what MIG (Multi-Instance GPU) is, in one paragraph."}]
}'

vllm bench serve --model Qwen/Qwen3.8-27B-FP8 \
  --base-url http://localhost:8000 --dataset-name random \
  --num-prompts 40 --random-input-len 512 --random-output-len 256 \
  --percentile-metrics ttft,tpot,itl,e2el --metric-percentiles 25,50,75,99

"Bu dilim kaç kişiye yeter?"

Bu soru tek sayıyla cevaplanmaz, çünkü aslında üç ayrı soru ve üçü birbirinin aleyhine çalışır. Ölçülen değerlerle:

Tek cümlelik cevap şöyle kurulur:

Tek 4g.71gb diliminde bir kullanıcı ilk kelimeyi 66 ms'de görür ve 256 tokenlık cevabın tamamını 4,2 saniyede alır. Aynı dilim 16 eşzamanlı üretimi kaldırır; o zaman tam cevap 5,8 saniyeye, ilk kelime 0,5 saniyeye çıkar ve sistem toplam 600 token/saniye üretir.

Tablodaki asıl ders: tam cevap süresi 1'den 16 kullanıcıya çıkarken neredeyse sabit kalıyor (4,25 → 5,84 sn) ama sistem çıktısı 10 kat artıyor. Paylaştırmak neredeyse bedava. Bozulan tek şey TTFT — sekiz kat. Kararınızı bu belirler:

• Sohbet arayüzü: algıyı TTFT belirler → eşzamanlılığı sınırlayın. mc=4 iyi bir denge: 227 ms'de ilk kelime, yine de 219 tok/sn.
• Toplu iş (özetleme, sınıflandırma, veri işleme): TTFT önemsiz → sınırı kaldırın, 1.180 tok/sn.

İki dilim: ölçek doğrusal mı?

Bir dilim yetmiyorsa modeli iki dilime bölemezsiniz (MIG'de tensor-parallel-size 1 zorunlu), ama aynı modelin iki bağımsız kopyasını iki dilimde çalıştırıp önlerine bir yük dengeleyici koyabilirsiniz. Soru şu: iki kopya gerçekten iki katı iş yapar mı, yoksa aynı kartı paylaştıkları için birbirlerini yavaşlatırlar mı?

Ölçtük. Aynı kartın iki 4g.71gb dilimi, birbirinin aynı iki kopya (4 CPU / 15 GiB), aynı yük (--max-concurrency 16, 40 istek):

Ölçek katsayısı 2,0039 — doğrusal. Gecikmede de kayıp yok: paralel yükte TTFT %0,04 daha düşük, TPOT değişmemiş, uçtan uca süre %0,01 farklı. İki dilim birbirini pratikte hiç etkilemiyor.

İki koşunun %93'ü gerçekten çakıştı (başlangıçlar arasında 0,11 sn fark), 40/40 istek başarılı, iki pod da yeniden başlamadı.

Tek adres: iki kopyanın önüne yük dengeleyici

İki kopya iki ayrı adres demek; müşteriye tek uç vermek istiyorsanız araya bir yük dengeleyici koyun. Kiracı ağınızda pod'lar birbirini görür (izolasyon yalnızca interneti kapatır, küme içi trafiği değil), yani üçüncü bir pod olarak HAProxy yeterlidir. Her pod'un kendi IP'si olduğu için ikisinin de 8000 dinlemesi sorun değildir.

frontend llm
    bind *:8080
    default_backend vllm_pool

backend vllm_pool
    balance leastconn
    option httpchk GET /health
    http-check expect status 200
    default-server check inter 5s rise 2 fall 3 maxconn 64
    server r1 qwen-r1-svc:8000
    server r2 qwen-r2-svc:8000

Ölçüm (aynı kıyaslama, 512 girdi / 256 çıktı):

Yük dengeleyicinin bedeli ölçülemedi, çünkü negatif çıktı: aynı yükte LB yolu her metrikte daha hızlı. Trafiğin yarısı ikinci kopyaya düşünce kuyruk azalıyor ve bu kazanç proxy'nin kendi gecikmesini gölgeliyor. Dolayısıyla bu ölçüm hop'un maliyetini ölçmez, üst sınırını koyar: 185 ms'den ucuz.

Çift yükte havuz iki kopyanın toplamını veriyor: 1.248,6 tok/sn, eşleştirilmiş doğrudan tabana (659,1) göre 1,894× — mükemmel 2×'in %94,7'si. leastconn dağılımı da dengeli: 200 isteklik koşuda 99'a 106.

Bundan sonrası: önbellek-farkında yönlendirme

Düz bir yük dengeleyici LLM'in durumlu olduğunu bilmez. Kullanıcılarınız ortak bir sistem istemi paylaşıyorsa, leastconn onları farklı kopyalara dağıtır ve her kopya aynı ön eki sıfırdan hesaplar. Bu sayfadaki kurala göre 32K'lık ortak bir istem her seferinde ~4,25 saniye prefill demektir; önbellekten gelse neredeyse sıfır. (Tek kopya içinde ön ek önbelleğini açmayı aşağıdaki bölüm anlatıyor — ama o yalnızca aynı kopyaya düşen istekleri kurtarır.)

Çözüm, aynı ön eke sahip istekleri aynı kopyaya yönlendiren önbellek-farkında yönlendirmedir (vLLM Router'ın tutarlı hash'lemesi, Ray Serve'in PrefixCacheAffinityRouter'ı, llm-d'nin inference scheduler'ı bunu yapar). vLLM'in kendi belgesi de sınırı açıkça çiziyor: iki basit kopya için standart bir yük dengeleyici yeterlidir; router'ın değeri çok pod'lu mimaride ve durumlu sohbet desenlerinde ortaya çıkar.

Bir sonraki adım olan prefill/decode ayrımı ise MIG'de yapılamaz — dilimler arası P2P kapalı olduğu için ayrı GPU havuzları gerekir.

Uzun istem: TTFT'nin fiyatı

Yukarıdaki bütün sayılar 512 token girdi içindir. İstemi büyütünce ne olduğunu tahmin etmeye gerek yok, ölçtük — aynı araç, aynı çıktı uzunluğu, tek değişken girdi:

Girdi 64 kat arttı, TTFT 64,8 kat arttı — prefill hızı ise ikisinde de aynı (fark %1,3). Yani prefill sabit hızlı bir borudur ve şu kural çıkar:

TTFT ≈ girdi token sayısı ÷ 7.700

32K'lık bir istemde ilk kelimeden önce yaklaşık 4,25 saniye sessizlik olur. 8K'da ~1 saniye, 64K'da ~8,5 saniye.

Uzun istemin bedeli peşin ödenir. Tek kullanıcıda token temposu neredeyse değişmiyor (16,40 → 17,78 ms). Yani istem uzun diye metin yavaş akmaz, sadece geç başlar.

Eşzamanlılıkla birlikte ise tablo bozulur:

512 tokenlık istemlerde 16 eşzamanlı istek 600 tok/sn veriyordu; 32K'da sınırsız yük 51,7 tok/sn'de kalıyor. mc=4'te P99 ITL 326,7 ms — birinin metni akarken başkasının 32K prefill'i araya girip duraklatıyor.

Ön ek önbelleği: bu modelde varsayılan olarak kapalı

Aynı sistem istemini ya da aynı belgeyi tekrar tekrar gönderiyorsanız vLLM prefill'i yeniden hesaplamak zorunda değildir — ortak ön eki önbellekten okuyabilir. Ama bu modelde bunu kendiliğinden yapmaz. Çalışan sunucunun /metrics çıktısı açıkça söylüyordu:

enable_prefix_caching = "False"
vllm:prefix_cache_queries_total = 0.0

--enable-prefix-caching bayrağını açıkça eklemek gerekiyor. Eklediğinizde vLLM Mamba önbelleğini align moduna alır ve bunun deneysel olduğunu söyler.

Bayrakla birlikte ölçüm — aynı ~5.000 tokenlık istem üç kez, ardından ön eki değiştirilmiş bir kontrol isteği:

3,08 kat hızlanma, istek başına 635 ms. Son satır kontrol deneyidir: ön ek değişince isabet sayacı yerinde çakılı kalıyor, yani kazanç "ikinci istek ısınmış olur" etkisi değil, gerçekten ön ek eşleşmesi.

İsabet oranındaki %7'lik boşluk da gürültü değil: bu kopyanın block_size'ı 784 ve 4.704 = 6 × 784. Varsayılan ayarda yalnızca tam bloklar yeniden kullanılır; sondaki 359 tokenlık yarım blok her seferinde yeniden hesaplanır. Aşağıdaki --prefix-match-unit bölümü bu israfı kaldırıyor.

fp8 KV YOK -> enable_prefix_caching=False
fp8 KV VAR -> enable_prefix_caching=False

Hangi bayrak işe yarar, hangisi yaramaz

Ön ek önbelleğini açtıktan sonra akla iki ayar geliyor. Biri boşa kürek, diğeri asıl kazanç.

--prefix-caching-hash-algo: dokunmayın. Varsayılanı zaten sha256, yani en güvenli seçenek; onu tekrar yazmak hiçbir şey değiştirmez. Tek gerçek hamle xxhash'e düşmek olur ve bunun iki sorunu var: vLLM'in kendi belgesi kriptografik olmayan hash'in çok kiracılı ortamda çakışma yoluyla başka kullanıcının verisini sızdırabileceğini yazıyor, üstelik vllm/vllm-openai imajında xxhash paketi kurulu bile değil — pod açılışta ölür. Kazanç tarafı da yok: 784 tokenlık bir bloğun sha256'sı 17,3 µs, aynı bloğun prefill'i 203.636 µs. Yani toplam sürenin on binde 0,85'i.

--prefix-match-unit: asıl kazanç burada. Ön ek isabeti varsayılan olarak yalnızca tam blok sınırında oluşur; blok boyutuna göre her istekte 783 tokene kadar yeniden hesaplanır. Bu bayrak eşleşme granülerliğini düşürür.

Tek değişken farkla iki kopya, aynı ~7.000 tokenlık istem, beşer tekrar:

%26,8 kazanç, 67 ms. Sapma yok (183,9–184,3 ms'ye karşı 251,2–251,7 ms) ve iki kopyanın cevabının SHA-256'sı aynı.

Sayılar tesadüf değil: 6.272 = 8 × 784 ve 6.976 = 436 × 16.

curl -s localhost:8000/metrics | tr ',' '\n' | grep -E 'block_size|prefix_match_unit'

MIG'de GPU okumaları — hangisi çalışır

Bu, MIG'e özgü ve şaşırtıcı: sorgu biçimi çalışmaz, tablo çalışır.

nvidia-smi --query-gpu=utilization.gpu,memory.used,memory.total --format=csv

[N/A], [Insufficient Permissions], [Insufficient Permissions]

Ama düz nvidia-smi çıktısındaki MIG tablosu dilimin belleğini verir:

30241MiB / 71424MiB     (ağırlıklar yüklendi)
65799MiB / 71424MiB     (KV cache dolarken)

Yani "MIG'de bellek görünmez" doğru değil — --query-gpu görmez, MIG tablosu görür. İzleme kurarken buna dikkat edin.

Sıcaklık ve güç okunur ve — sezginin aksine — kartın geneline değil, sizin kendi GPU örneğinize aittir. İki dilimden aynı saniyede örnekleme yaptık: boştaki konteyner 129,2 W / 55 °C okurken çalışan 401,3 W / 68 °C okuyordu. Yani bu değerlerle kartın toplam yükünü çıkaramazsınız; board toplamı için nvidia-smi'yi host üzerinde çalışormalısınız.

Ölçülen dilim değerleri: boşta 129,2 W / 55 °C, tek kopya yük altında 401,3 W / 68 °C.

Ölçülen süreler

Sık karşılaşılan hatalar