Çıkarım çalışma zamanı
Donanım ve ölçülen gecikme süresi
Profiller, ölçülen GPU ve CPU değerleri, VRAM ve RAM alt sınırları, asgari kasa
Bu sayfa, İngilizce belgeden makine çevirisiyle çevrildi.
Buradaki her sayı, üzerinde ölçüldüğü donanımla etiketlenmiştir, projeksiyonlar ise projeksiyon olarak belirtilmiştir.
Tüm ölçümler, aynı istemlerle aynı 50 fotoğraflık altın küme üzerinde yapılmıştır. Yöntemin tamamı, güven aralıkları ve çalıştırmaların kendisi eval/BASELINE.md ve eval/PERFORMANCE.md içindedir.
Profiller
MODEL_PROFILE | model | indirme | lisans |
|---|---|---|---|
quality | Qwen3-VL-8B-Instruct, Q4_K_M + F16 mmproj | 5.8 GiB | Apache-2.0 |
lite | LFM2.5-VL-1.6B, Q8_0 + F16 mmproj | 2.0 GiB | LFM Open License v1.0, gelir sınırlı, bkz. Lisanslama |
lite-apache | Qwen3-VL-2B-Instruct, Q4_K_M + F16 mmproj | 1.8 GiB | Apache-2.0 |
Her iki lite varyantı da CPU üzerinde çalışır. quality de CPU üzerinde çalışır, ancak çok yavaştır ve aslında bir GPU profilidir.
GPU üzerinde quality: ölçülen
| kart | tarama başına p50 | tarama başına p95 | notlar |
|---|---|---|---|
| RTX 4090 (24 GB) | 0.94 s | 1.47 s | 3356 tok/s ön doldurma, 153.6 tok/s kod çözme, sunucu tarafı |
| RTX 3090 (24 GB) | 1,72 sn | 2,33 sn | 1749 tok/sn ön doldurma, 122,9 tok/sn kod çözme |
Her iki satır: Qwen3-VL-8B-Instruct Q4_K_M + F16 mmproj, 8192 bağlam boyutu, 896 px boyutuna küçültülmüş görseller, llama.cpp llama-server b10380, kiralanmış pod'lar, 50 fotoğraf. Her ikisi de kendi makinendeki bir konteynerin maruz kalmadığı yaklaşık 0,35 ila 0,6 sn ağ ve vekil sunucu gidiş geliş süresi içerir, bu yüzden doğrudan makinede sunmak bu sayılardan daha yavaş değil, daha hızlıdır. Aynı çalıştırmadaki doğruluk: 50 tabakta sıfır halüsinasyon ile %72,8 çekirdek öge yakalama, openplate'in varsayılan olarak kullandığı öncü bulut modelinden istatistiksel açıdan farksızdır.
Bu sınıftaki herhangi bir ~24 GB kart uygundur. Ölçtüğümüz değer budur, daha küçük bir kartı ölçmedik.
VRAM alt sınırı. Ağırlıklar 4,68 GiB (Q4_K_M) + 1,08 GiB (F16 görüntü kulesi) = 5.8 GiB tutarındadır ve 2 yuva ile 8192 bağlam boyutunda ölçülen toplam çalışma kümesi 6,3 GB idi. Dolayısıyla bir 12 GB sınıfı bir kart rahat olmalıdır ve 8 GB bir kart akla yatkındır ancak sınırdadır (büyük olasılıkla bağlam boyutunu düşürmen ya da modelin bir kısmını aktarman gerekir). Bu bir aritmetiktir, test edilmiş bir sayı değildir: ölçtüğümüz tek boyut 24 GB. 12 GB dener ve çalıştırırsan, bu yararlı bir bilgidir.
Gerçek değişken VRAM değil, bellek bant genişliğidir
Tek bir istekteki üretim hızı bant genişliğine bağlıdır: her belirteç etkin ağırlık kümesinin tamamını dolaşır. Ölçülen iki kart da kabaca ~1.000 GB/sn sınıfı sınıfındadır (RTX 4090 ≈ 1008 GB/sn, RTX 3090 ≈ 936 GB/sn) ve ölçülen p50 değerleri bunu takip eder: 0,94 sn ve 1,72 sn.
Ölçüm değil, tahmin: bir ~300 GB/sn sınıfı kart (L4 ve çoğu iş istasyonu kartının çıkarım yapabilen tarafı) 3090'a kıyasla yaklaşık 3 kat daha az bant genişliğine sahiptir, bu da onu tarama başına tahmini 4 ila 6 sn seviyesine getirir. Bu değer 3090 satırından oranlanmıştır, ölçülmemiştir ve gerçek sayılar genellikle doğrusal bir oranlamadan daha kötü çıkar.
CPU: ölçülen
Aşağıdaki her satır için sunucu: AMD Ryzen 9 7940HS, 14 iş parçacığı, GPU yok (-ngl 0), llama.cpp llama-server, 8192 bağlam boyutu, aynı 50 fotoğraf.
lite: planlama yaparken baz alınacak satır. 2026-08-13 tarihinde kullanıma sunulan servisi üzerinden ölçülmüştür: birebir bu kod, 896 px küçültmesi, grameri, çıktı eşlemesi, 50/50 görsel, 0 hata, loopback üzerinden ardışık istekler.
| tabak başına | |
|---|---|
| p50 | tabak başına 5,5 saniye |
| p95 | 6,8 sn / tabak |
| gözlemlenen en kötü tabak | 7,2 sn |
Kaynak: eval/runs/2026-08-13-lite-cpu-v3/results.json. Bu çalıştırmada yalnızca gecikme süresi ölçüldü, doğruluk puanlanmadı. lite modelinin yakalama oranı farklı çalıştırmasından gelir (2026-08-12: %62,1 çekirdek öge yakalama oranı, bu yüzden lite amiral gemisi olarak değil, kısıtlı imkanlara sahip kendi sunucusunu barındıranlar için taban olarak belgelenmiştir). İki çalıştırma, iki sayı, ayrı ayrı alıntılanmıştır.
Gecikme süresi, iş parçacıklarıyla olduğu kadar tabakla da artar. Bir taramanın maliyeti istemin uzunluğunu, modelin o fotoğraf için okuduğu belirteçleri takip eder; tam bir kahvaltının istemi, basit bir tabağa kıyasla dört kat daha uzundu. Aynı CPU modelinde, varsayılan 4 iş parçacıklı 6 sanal çekirdekli bir sanal makine içinde, dağıtılan servis üzerinden ölçülen iki tarama (2026-09-27):
| tabak | istem belirteçleri | süre |
|---|---|---|
| basit bir tabak | 547 | 9,5 sn |
| tam bir kahvaltı | 2084 | 50,1 sn |
Yani sıradan bir CPU makinesinde tabak başına kabaca 5 saniyeden bir dakikaya kadar plan yap: Çok iş parçacıklı ve basit bir tabakta alt sınır, az iş parçacıklı ve kalabalık bir tabakta ise üst sınır geçerlidir. Bunlar bir dağılım değil, yalnızca iki tekil taramadır.
Aynı CPU üzerinde quality: ≈94 sn / tabak (p50, 2026-08-12), daha önceki, daha ayrıntılı bir işlem hattında tam görüntü çözünürlüğünde ölçülmüştür ve sunulan işlem hattında yeniden ölçülmemiştir, bu nedenle bunu bir üst sınır olarak kabul et. quality bir GPU profilidir.
RAM (ölçülen RSS): lite 1,55 GB, quality 6,31 GB.
CPU işleme hızı eşzamanlılıkla artmaz. Ölçülen: iki eşzamanlı istek, art arda çalıştırılan aynı iki isteğin 0,75 ila 0,83 katı kadar kaynak harcar, bu da 2 katlık bir yayılımda 1,2 ila 1,3 kat işleme hızı kazanımı sağlar, ancak bunun bedeli tamamen istek başına gecikme süresiyle ödenir (tek istek tek başına 2,5 sn; iki istek aynı anda çalışırken her biri 3,7 sn). Kapasiteyi makine sıralı çalışıyormuş gibi planla.
lite için minimum CPU makinesi: AVX2 destekli 8+ modern çekirdek, 4 GB boş RAM (model için 1,55 GB, diğer her şey için ek alan), yaklaşık 3 GB disk (1,96 GiB ağırlıklar artı kalıp, yaklaşık 1 GB). 14 yerine 8 iş parçacığı kullanmak tabak başına gecikme süresini kabaca iki katına çıkarır. GPU yok, CUDA yok, harici çağrı yok; CPU kalıbını derleyen, GPU olmadan başlatan ve içinden gerçek bir fotoğraf geçiren scripts/smoke-lite.sh tarafından doğrulanmıştır.
Varsayılan olarak gecikme süresi tavanı yoktur
LATENCY_CEILING_MS varsayılan olarak 0, yani devre dışı değerini alır. Belirli bir eşikte yükü üzerinden atan bir makine, gayet rahat sunabileceği istekleri geri çevirir ve CPU üzerinde bir tarama işlemi doğal olarak birkaç saniye ile birkaç dakika arasında sürer. Buna uygun olan kullanıcı deneyimi asenkrondur: fotoğrafı çek, telefonu bir kenara koy, tekrar baktığında tabak çözümlenmiş olur. CPU üzerinde uygun olmayan şey ise, sen kadrajı ayarlarken yeniden çizilen canlı önizlemedir.
Kendi makinende bir sınır olmasını istiyorsan LATENCY_CEILING_MS=10000 ayarla, böylece servis on saniye içinde bitiremeyeceği işleri reddetmeye başlar. Kendi sunucusunu barındıranların çoğu bunu devre dışı bırakmalıdır.