Self-hosted LLM neden 5 kullanıcıda yavaşlar?

Self-hosted bir LLM, kullanıcı sayısı arttığında neden yavaşlar?

Self-hosted bir LLM, 5 eşzamanlı kullanıcıda takılır çünkü sunucu aynı anda yalnızca bir yanıt üretmektedir ve diğer dört kullanıcı kuyrukta beklemektedir. Ollama belgeleri, varsayılan ayar konusunda oldukça nettir: OLLAMA_NUM_PARALLEL, "her modelin aynı anda işleyeceği maksimum paralel istek sayısıdır, varsayılan değer 1'dir." Herhangi bir arıza yoktur. Beş kişiden dördü sıra beklemektedir.

Çözüm nadiren daha güçlü bir donanımdır. Çözüm, birçok isteği aynı ileri geçişte (forward pass) model üzerinden geçiren bir sunum motoru ve bunu yaparken herkesin sohbetini bellekte tutacak kadar boş alan sağlamaktır. Her iki kısım da önemlidir; ancak ikinci kısım, kapasitenizin sınırını belirleyen asıl unsurdur.

Her isteğin geçtiği iki aşama

Prefill, istemin tamamını tek seferde okur ve bunun için dikkat önbelleğini (attention cache) oluşturur. Her istem belirteci (token) modelden birlikte geçer; bu nedenle prefill, büyük bir matris çarpımıdır ve aritmetik işleme kapasitesi ile sınırlıdır. Decode ise yanıtı her seferinde bir belirteç olacak şekilde yazar. Her belirteç, modelin tüm ağırlıklarının bellekten tekrar okunmasını gerektirirken, bu tek belirteç üzerinde yapılan aritmetik işlem oldukça küçüktür. Decode, bellek bant genişliği ile sınırlıdır.

Bu asimetri, toplu işlemenin (batching) çalışma nedenidir. Tek bir kullanıcı için decode işlemi, belirteç başına yaklaşık 5 GB ağırlık okur ve aritmetik birimlerin çoğunu boşta bırakır. İkinci bir istek eklendiğinde, motor aynı 5 GB'ı bir kez okur ve ardından bu veriden iki belirteç hesaplar. İkinci kullanıcı neredeyse hiç ek süre maliyeti oluşturmaz. İstekleri kesinlikle art arda sunmak, bu avantajı ortadan kaldırır.

Kullanıcının deneyimini iki sayı tanımlar. TTFT (ilk belirtece kadar geçen süre), kuyruk bekleme süresi ile prefill süresinin toplamıdır. ITL (belirteçler arası gecikme), akış halindeki belirteçler arasındaki boşluktur ve decode tarafından belirlenir. Yavaş bir sunucu genellikle bunlardan birinde yavaştır ve çözüm yolları birbirinden farklıdır.

Statik toplu işleme (static batching) herkesi en yavaş yanıt için bekletir

Statik toplu işleme, uygulamanızda istekleri kendiniz grupladığınızda ortaya çıkan basit yöntemdir. Motor, N adet isteği toplar, bunları birlikte çalıştırır ve gruptaki en uzun üretim tamamlanana kadar her bir yuvayı (slot) meşgul tutar.

1.200 token'lık bir özet isteyen bir kullanıcı, dört adet tek satırlık yanıtı toplu iş içerisinde kilitli tutar; çünkü toplu iş, en yavaş üyesi bitene kadar hiçbir yuvayı serbest bırakmaz.

Bu durum iki maliyeti beraberinde getirir. Tamamlanan diziler, hiçbir yararlı hesaplama yapmadıkları halde yuvaları işgal etmeye devam eder; bu nedenle çıktı uzunlukları değiştikçe efektif iş hacmi düşer ve sohbet çıktılarının uzunlukları büyük değişkenlik gösterir. Toplu iş oluşturulduktan hemen sonra gelen bir istek, prefill aşamasına başlamadan önce tüm toplu işin bitmesini bekler; bu da isteğin TTFT süresinin başkasının yazdığı uzun bir metne bağlı kalması demektir.

Sürekli toplu işleme (continuous batching) her belirteçte istek kabul eder ve sonlandırır

Sürekli toplu işleme, zamanlama işlemini tek bir kod çözme adımı seviyesinde gerçekleştirir. Her adımdan sonra zamanlayıcı, durdurma belirtecini (stop token) yeni yayınlayan dizileri çıkarır ve ardından boşalan yuvalara bekleyen istekleri dahil eder. 40. adımda sona eren bir yanıt, toplu işin (batch) sonunu beklemeden 40. adımda yuvasını serbest bırakır.

Bu egzotik bir yöntem değildir. llama-server, -cb, --cont-batching parametresini "sürekli toplu işlemenin (diğer adıyla dinamik toplu işleme) etkinleştirilip etkinleştirilmeyeceği (varsayılan: etkin)" şeklinde belgeler ve vLLM tamamen bu fikir üzerine inşa edilmiştir. Ollama da paralel istekleri sunabilir. Varsayılan ayar bu sayıyı bire sabitlediği için, birçok kullanıcı donanımlarının eşzamanlılığı destekleyemediği sonucuna varır; oysa bu durum tamamen yapılandırma ayarlarının kısıtlamasından kaynaklanmaktadır.

Yayınlanan sürekli toplu işleme sonuçları genellikle hem boşta işlem gücüne hem de önbellek için onlarca gigabayt alana sahip veri merkezi kartları üzerinde ölçülür. Bu sonuçların biçimi sizin sisteminize de uyarlanabilir. Ancak sonuçların ölçeği aynı kalmayacaktır; bunun nedeni ise aşağıdaki bellek bölümünde açıklanmıştır.

Prefill, decode ile aynı işlem gücü için rekabet eder

Dört yanıtın akışı devam ederken yeni bir istek geldiğinde, önce istemin (prompt) prefill edilmesi gerekir ve prefill işlemi yoğun işlem gücü gerektirir. Zamanlayıcı bu prefill işlemine kendi başına bir adım ayırırsa, bu süre zarfında akış halindeki dört kullanıcı hiçbir token alamaz. Uzun bir istemde bu durum, açık olan her pencerede gözle görülür bir duraksamaya neden olur. İnsanların, başka biri gönder tuşuna bastığında sunucunun teklediğini söyleyerek kastettikleri kekemelik budur.

Chunked prefill, uzun bir istemi parçalara böler ve her parçayı devam eden decode işlemleriyle aynı adıma karıştırır. vLLM'in ayarlama kılavuzu bu dengeyi doğrudan belirtir: daha küçük chunk bütçeleri, "decode işlemlerini yavaşlatan daha az prefill olduğu için daha iyi ITL sağlar", daha yüksek değerler ise "bir batch içinde daha fazla prefill token işlenebildiği için daha iyi ilk token süresi (TTFT) sağlar". Burada kimin deneyimini koruyacağınızı seçersiniz: yanıtın başlamasını bekleyen kişi mi, yoksa metnin akışını izleyen kişiler mi?

İstem uzunluğu, bu durumun ne kadar sorun yaratacağını belirler. 200 tokenlik bir yanıt içeren 6.000 tokenlik bir istem, 200 decode adımına karşı 6.000 tokenlik prefill işi demektir. Retrieval-augmented chat ve uzun sistem istemleri sizi bu rejime sokar; bu nedenle prefill, ihmal edilebilir bir hata payı olmaktan çıkıp kullanıcıların beklediği ana unsur haline gelir. Uzun kısım tekrarlandığında prefix caching yardımcı olur: vLLM, her istek için yeniden hesaplamak yerine paylaşılan bir istem öneki için önbelleği yeniden kullanan --enable-prefix-caching özelliğini sunar.

İlk tükenen bellek KV önbelleğidir

Aktif bir görüşmedeki her bir token, modelin her katmanında bir anahtar (key) vektörü ve bir değer (value) vektörü bırakır. Buna KV önbelleği (key/value cache) denir; bu yapı, kod çözme (decode) aşamasında her yeni token için tüm istemin (prompt) yeniden hesaplanmasını engeller. Token başına düşen boyut, modelin yapısına göre sabittir: 2 (bir anahtar, bir değer), katman sayısı, anahtar/değer başlığı sayısı, başlık boyutu ve değer başına düşen bayt sayısı ile çarpılır. Bu değerleri modelin config.json dosyasından okuyabilirsiniz.

Bu hesabı bir kez yaptığınızda, üst sınır bir gizem olmaktan çıkar. 36 katmanlı, 8 anahtar/değer başlıklı ve 128 başlık boyutlu tipik bir 8B model, önbelleği 16-bit olarak tuttuğunda token başına 2 36 8 128 2 baytlık bir maliyet oluşturur. Bu da 147.456 bayt, yani yaklaşık 144 KiB eder. Dolayısıyla 8.192 tokenlık bir görüşme yaklaşık 1,2 GB önbellek gerektirir. Ağırlıkların üzerine ek olarak, beş görüşme yaklaşık 6 GB bellek gerektirir; kaç kullanıcının sığabileceğine dair gerçek cevap budur.

Eşzamanlılık bağlamı çoğaltır ve araçlar bunu açıkça belirtir. Ollama'nın FAQ bölümü: "Belirli bir model için paralel istek işleme, bağlam boyutunun paralel istek sayısı kadar artmasına neden olur. Örneğin, 4 paralel istek ile 2K bağlam, 8K bağlam ve ek bellek tahsisine yol açar." Gereken RAM, OLLAMA_NUM_PARALLEL ile OLLAMA_CONTEXT_LENGTH çarpılarak ölçeklenir. llama-server içinde, -c ile talep ettiğiniz bağlam -np yuvalarına paylaştırılır; bu nedenle yuva sayısını artırmak, her isteğin tutabileceği kapasiteyi tek başına düşürür. Varsayımda bulunmak yerine, yuva başına düşen bağlamı başlangıç günlüğünden (startup log) okuyun.

vLLM ise önceden tahsis (preallocate) yapar. --gpu-memory-utilization (varsayılan 0.92), "model yürütücüsü için kullanılacak GPU belleğinin oranıdır". Ağırlıklardan sonra kalan kısım sayfalanmış KV havuzu olur ve bu havuz tükendiğinde zamanlayıcı, isteği başarısız kılmak yerine tahliye eder (evict):

WARNING 05-09 00:49:33 scheduler.py:1057] Sequence group 0 is preempted by PreemptionMode.RECOMPUTE mode because there is not enough KV cache space.

vLLM'in V1 motorunda varsayılan ön alma (preemption) modu RECOMPUTE'tur; bu nedenle tahliye edilen bir istek önbelleğini atar ve tekrar kabul edildiğinde ön doldurma (prefill) işlemini yeniden yapar. Bu işlem iki kez gerçekleştirilmiş olur. Dokümantasyon, "ön alma ve yeniden hesaplamanın uçtan uca gecikmeyi olumsuz etkileyebileceği" konusunda uyarır. Bu günlük satırı, ortalama değerleriniz sağlıklı görünürken neden şanssız bir kullanıcının diğerlerinden çok daha uzun süre beklediğinin en iyi açıklamasıdır. Kümülatif sayıyı günlüğe kaydetmek için disable_log_stats=False ayarını yapın veya vLLM'in sunduğu Prometheus metriklerinden ön alma sayacını okuyun.

2, 5 ve 20 eşzamanlı kullanıcıda neler değişir

İki kullanıcı. Önbellek kapasitesi yeterli olan bir GPU üzerinde neredeyse fark edilmez; çünkü ikinci kod çözme akışı, ilkinin yanında çok az ek süreyle ilerler. 4 ila 8 GB RAM'e sahip, yalnızca CPU kullanan bir VPS üzerinde ise bu durum ücretsiz değildir: her iki akış aynı vCPU havuzunu ve aynı RAM bant genişliğini paylaşır. Bu nedenle her kullanıcı saniyede üretilen token sayısının kabaca yarısını görür ve önbellek talebi, çok daha kısıtlı bir bütçeye karşı iki katına çıkar.

Beş kullanıcı. Varsayılan ayarların artık yeterli olmadığı ve sorunun bir kuyruk problemi olarak başladığı nokta burasıdır. OLLAMA_NUM_PARALLEL değeri 1 olduğunda, dört kişi uzun yanıtı talep eden kişinin bitmesini bekler ve her biri kendi sırası geldiğinde normal hızı görür. Paralel işleme sayısını artırdığınızda sorunun şekli değişir: her biri 8K bağlam (context) boyutuna sahip beş yuva, bulunması gereken 40K token'lık bir önbellek demektir. Eğer bu VRAM'e sığmazsa, motor katmanları sistem RAM'ine aktarır; eğer RAM'e de sığmazsa, sistem swap kullanmaya başlar ve saniyedeki token üretimi çöker.

Yirmi kullanıcı. Bir sohbet arayüzündeki yirmi insan genellikle yirmi eşzamanlı istek anlamına gelmez; donanım satın almadan önce anlaşılması gereken en önemli konu budur. Bir kişi yanıtı okur ve hamleler arasında 20 ila 60 saniye düşünür, bu nedenle oturumlarının çoğu boşta geçer. Yirmi yapay zeka ajanı veya yirmi belge özetleme işi ise, boşta kalma süresi olmayan yirmi gerçek akış demektir. Bu, tamamen farklı bir makine gerektirir.

Kullanıcılarınız eş zamanlı mı, yoksa sadece oturum açmış durumda mı?

Herhangi bir boyutlandırma yapmadan önce işlemdeki (in flight) istek sayısını hesaplayın. Matematik basittir: işlemdeki istek sayısı, kullanıcı sayısı çarpı tur başına üretim için harcanan saniye, bölü turlar arasındaki saniye süresine eşittir.

1. Önce kendi tek akışlı hızınızı ölçün; hem ön doldurma (prefill) hem de kod çözme (decode) işlemlerini dahil edin. Başkasının kartına ait bir değeri ödünç almayın: kendi makinenizde saniyedeki token sayısını ölçün ve elde ettiğiniz değeri kullanın.
2. Görev döngüsünü tahmin edin. Yirmi sohbet kullanıcısı, tur başına 12 saniyelik üretim ve her 90 saniyede bir tur, 20 * 12 / 90 hesabıyla yaklaşık 2.7 işlemdeki istek anlamına gelir.
3. Yuva (slot) sayısını bu değerin biraz üzerine ayarlayın, ardından bellek ile karşılaştırın: yuva sayısı çarpı istek başına bağlam (context), sahip olduğunuz önbellek token kapasitesine sığmalıdır.
4. Kuyruğu kısa tutun; böylece taşma durumları hızlı ve görünür bir şekilde başarısız olur.

Kullanılabilir önbellek token sayısı, ağırlıklardan sonra kalan boş belleğin, yukarıdaki bölümde belirtilen token başına maliyete bölünmesiyle bulunur. 16-bit modunda 8B model çalıştıran 24 GB'lık bir kart, ağırlıklar için yaklaşık 16 GB harcar ve varsayılan kullanım oranında yaklaşık 6 GB kullanılabilir önbelleğe sahiptir; bu da yaklaşık beş adet 8K'lık görüşmeye denk gelir. Daha fazlasını sığdırmak için istek başına bağlamı kısaltın veya önbelleği 8-bit olarak saklayın (llama-server, --cache-type-k q8_0 gerektirir). Her iki yöntem de bir şeylerden feragat ederek eş zamanlılık sağlar; bu takasın dürüst bir değerlendirmesini yapmak, donanıma yatırım yapmadan önce okunmaya değerdir: GPU VPS'in API token maliyetlerine karşı başa baş noktası.

Ollama varsayılanlarının yetersiz kaldığı durumlar

Paralel istek sayısını servis birimi üzerinden artırın; çünkü shell ortamında yapılan bir export işlemi, systemd tarafından yönetilen bir arka plan sürecine (daemon) ulaşmayacaktır.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=4"
Environment="OLLAMA_CONTEXT_LENGTH=8192"
Environment="OLLAMA_MAX_QUEUE=64"

sudo systemctl daemon-reload
sudo systemctl restart ollama
systemctl show ollama --property=Environment
ollama ps

systemctl show komutu, az önce ayarladığınız üç değişkeni yazdırmalıdır. Eğer yazdırmıyorsa, drop-in dosyası kaydedilmemiştir ve yapacağınız diğer işlemlerin bir etkisi olmayacaktır. ollama ps komutu ise yüklenen modeli, sadece ağırlıkların boyutundan daha büyük bir değerle listeler; çünkü 8,192 token kapasiteli dört yuva, yanlarında 32,768 tokenlik bir önbellek alanı rezerve eder. PROCESSOR sütununda modelin bir kısmının GPU yerine CPU üzerinde göründüğünü fark ederseniz, ekran kartının kapasitesinden daha fazla önbellek talep etmişsiniz demektir. Bu iki sayıdan birini düşürün.

Kuyruk varsayılanı ayrıca değerlendirilmelidir. Ollama, OLLAMA_MAX_QUEUE değerine kadar istekleri kuyruğa alır ve "varsayılan değer 512'dir". Bu sayının ötesinde, "sunucunun aşırı yüklendiğini belirten bir 503 hatası" ile yanıt verir. Aynı anda dört istek işleyebilen bir makinede 512 derinliğinde bir kuyruk, tutamayacağınız bir sözdür; çünkü 300. sıradaki istemci, sıra kendisine gelmeden çok önce zaman aşımına uğrayacaktır. Kısa bir kuyruk, uygulamanızın yeniden deneyebileceği veya raporlayabileceği bir hata döndürür; bu durum, asla sonuçlanmayan bir yükleme simgesinden daha iyidir.

Gerçek bir test yapın. İki terminalden aynı anda iki istek gönderin ve her ikisini de izleyin. Eğer ikincisi, ilki bitene kadar hiçbir çıktı üretmiyorsa, paralel yapılandırma ayarı devreye girmemiştir.

Gerçek bir sunum motoru kendi maliyetini ne zaman karşılar

vLLM, GPU üzerinde boş kapasite olduğunda ve eş zamanlı olarak dört isteğin üzerinde gerçek bir trafik akışı bulunduğunda kurulum maliyetini amorti eder. Zamanlayıcısı token bazlı çalışır, önbelleği sayfalandırılmıştır; böylece boş parçalar yeniden kullanılır ve boşta duran VRAM, eş zamanlılık kapasitesine dönüştürülür. Ağustos 2026 itibarıyla belgelenen kurulum ve başlatma işlemleri iki komuttan ibarettir:

uv pip install vllm --torch-backend=auto
vllm serve Qwen/Qwen2.5-1.5B-Instruct

curl http://localhost:8000/v1/chat/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "Qwen/Qwen2.5-1.5B-Instruct",
        "messages": [{"role": "user", "content": "Say hello."}]
    }'

choices dizisini içeren bir yanıt, sunucunun ayakta olduğunu ve modelin yüklendiğini gösterir. Yük altındayken dikkat edilmesi gereken iki temel ayar; "tek bir iterasyonda işlenecek maksimum dizi sayısı" olan --max-num-seqs ve "tek bir iterasyonda işlenecek maksimum token sayısı" olan --max-num-batched-tokens parametreleridir. İlki eş zamanlılığı sınırlar, ikincisi ise daha önce açıklanan parçalı ön doldurma (chunked prefill) bütçesini belirler.

Eş zamanlı istek sayısı dördün altındaysa veya desteklenen bir GPU'ya sahip olmayan bir sunucuda çalışılıyorsa, vLLM karmaşıklığı artırır ancak düşük verim sağlar. CUDA destekli bir kart gerektirir ve başlatma sırasında belleğin büyük kısmını rezerve eder; bu durum 4 ila 8 GB RAM kapasiteli VPS'ler için yanlış bir tercihtir. Bu tür sistemlerde çözüm, daha kısa bağlama sahip daha küçük bir model ve sizin kontrolünüzde olan bir kuyruk yapısıdır. Ollama ve vLLM'in sunum motoru olarak farkları bu seçimi detaylıca ele alır; Qwen 3 8B modelini bir VPS üzerinde çalıştırmak ise orta ölçekli bir modelin tek bir kullanıcı eklenmeden önce ne kadar kaynak talep ettiğini gösterir.

Geleneksel bilginin gizlediği ödünleşim

Continuous batching toplam iş hacmini artırır ve genellikle ortalama gecikmeyi de iyileştirir; çünkü kuyruktaki bir istek daha erken başlar. Kuyruk gecikmesi (tail latency) ise ters yönde hareket eder ve bu durum nadiren dile getirilir.

Bir adımdaki her ek dizi küçük bir iş yükü ekler, bu nedenle batch doldukça ITL herkes için yükselir. Yeni gelen bir isteğin prefill işlemi, streaming yapan kullanıcıların aksi takdirde sahip olacağı bir adım dilimini alır. Önbellek baskısı altında zamanlayıcı (scheduler) önceliklendirme yapar (preempt), bu da yarıda kalmış bir isteği prefill aşamasının başına geri gönderir.

Bir sohbet arayüzü ortalamaları değil, kuyrukları (tails) gösterir. Cümle ortasında iki saniye duraksayan bir akış, toplam tamamlama süresi iyi olsa bile bozuk olarak algılanır. Beklenen yük altında p95 TTFT ve p95 ITL değerlerini ölçün; saniye başına ortalama token değerini deneyimin bir tanımı olarak değil, bir kapasite verisi olarak ele alın.

Pratik ayar buradan çıkar. Eşzamanlılığı (concurrency), belleğin izin verdiğinden biraz daha düşük tutun; böylece motorun asla önceliklendirme (preempt) yapması gerekmez. Kısa ve öngörülebilir bir kuyruk, sürekli kesintiye uğrayan (thrashing) derin bir batch yapısından daha iyidir. Dört saniye bekleyip ardından akıcı bir şekilde veri alan bir kullanıcı, anında başlayıp iki kez duraksayan bir kullanıcıdan daha memnundur.

Yavaşlık durumunda kontrol edilmesi gerekenler

Her kullanıcı normal, ancak bekleme süresi uzun. Bu bir hız sorunu değil, bir kuyruk sorunudur. Öncelikle parallel ayarını kontrol edin. Model, istekleri tek tek işleyerek doğru şekilde hizmet veriyor.

Ollama üzerinden HTTP 503 hatası. Kuyruk doludur. Sunucu gerçekten kapasitesinin sınırında olabilir veya yükü hafifletmek için OLLAMA_MAX_QUEUE kasten düşük ayarlanmış olabilir; bu, sistemin yapmasını istediğiniz davranıştır.

CPU tabanlı bir sunucuda yük altında saniye başına üretilen token sayısı düşüyor. Sorun yaşandığı sırada vmstat 1 komutunu çalıştırın. si ve so sütunlarındaki sıfır dışı değerler, makinenin swap yaptığını ve ağırlıkların her token için diskten okunduğunu gösterir. Hiçbir yapılandırma değişikliği bunu düzeltemez. Model boyutunu veya slot sayısını azaltın.

On kullanıcıdan biri diğerlerinden çok daha uzun süre bekliyor. vLLM günlüklerinde preempted ifadesini aratın. Preemption ve bunun sonucunda gerçekleşen yeniden hesaplama (recompute) genellikle temel nedendir; bu, önbelleğin izin verdiğiniz bağlam uzunluğu (context length) için aşırı yüklendiği anlamına gelir.

Sunucu boşta olsa bile TTFT (ilk token süresi) kötü. Bu durum eşzamanlılık ile değil, prefill aşaması ile ilgilidir. Uzun istemler (prompt), ilk token görünmeden önce gerçek zaman harcar; bu nedenle donanıma bakmadan önce istem boyutunu ve prefix caching ayarlarını inceleyin.

FAQ

Kendi sunucumda barındırdığım LLM, ikinci bir kişi kullandığında neden yavaşlıyor?

Çoğu durumda yavaşlama olmaz, sadece kuyruğa girer. Ollama, OLLAMA_NUM_PARALLEL değerini 1 olarak ayarlanmış şekilde gelir; bu nedenle ikinci istek, ilkinin son token'ı üretmesini bekler. İki durumu birbirinden ayırmak için bir kullanıcı veri akışı alırken diğerinin bekleme süresini ölçün: Eğer kullanıcılar akışa başladığında saniye başına düşen token sayısı normalse, bir kuyruklanma sorunu yaşıyorsunuzdur ve paralel sayısını artırmak bunu çözer. Eğer her iki akış da yarı hızda çalışıyorsa, bellek bant genişliğini paylaşıyorsunuzdur; bu bir donanım sınırıdır.

Küçük bir GPU aynı anda kaç kullanıcıya hizmet verebilir?

Kullanıcı sayısını değil, belleği hesaplayın. Önce ağırlıklar, ardından aktif konuşma başına, token başına, 2 çarpı katman sayısı çarpı anahtar/değer başlıkları çarpı başlık boyutu çarpı bayt şeklinde hesaplanan KV önbelleği gelir. 36 katmanlı, 8 anahtar/değer başlıklı ve 128 başlık boyutlu tipik bir 8B model, 16-bit formatında token başına yaklaşık 144 KiB yer kaplar; dolayısıyla 8,192 token'lık bir konuşma yaklaşık 1.2 GB gerektirir. Bu modeli 16-bit olarak tutan 24 GB'lık bir kartta önbellek için yaklaşık 6 GB boş yer kalır; bu da tam bağlamda yaklaşık beş konuşma veya bağlamı kısaltırsanız daha fazlası demektir.

Sürekli toplu işleme (continuous batching) her kullanıcının yanıtını yavaşlatır mı?

İstekler tüm grubun bitmesini beklemeyi bıraktığı için ortanca gecikme süresi genellikle iyileşir. Kuyruk gecikmesi (tail latency) ise kötüleşir. Eklenen her dizi, her kod çözme adımına iş yükü ekler; yeni gelen bir isteğin ön doldurma (prefill) işlemi, akış halindeki kullanıcılardan bir adımın bir kısmını çalar ve önceliği alınan bir istek iki kez ön doldurma yapmak zorunda kalır. Ortalamaların gizlediği duraksamalar sohbet penceresinde belirginleştiği için, ortalamayı değil, p95 token arası gecikmeyi ölçün.

OLLAMA_NUM_PARALLEL değerini mi artırmalıyım yoksa vLLM'e mi geçmeliyim?

Önce paralel sayısını artırın. Bu işlem ücretsizdir, tek bir ek dosya ile yapılır ve dört kişinin uzun bir yanıtın arkasında kuyrukta beklediği yaygın durumu çözer. Sınır bellektir: paralel istekler tutmanız gereken bağlamı çoğaltır, bu yüzden katmanların CPU'ya taşmadığından emin olun. VRAM'iniz boşta olduğunda ve aynı anda dörtten fazla istek gerçekten işlendiğinde vLLM'e geçin; çünkü sayfalama önbelleği (paged cache) ve token bazlı zamanlamanın maliyetinden daha fazla verim sağladığı nokta burasıdır.

Daha fazla CPU çekirdeği yavaş bir LLM sunucusunu hızlandırır mı?

Kullanıcıların en çok fark ettiği kısım için hayır. Kod çözme (decode) işlemi, her token için tüm modeli bellekten okur; bu nedenle RAM bant genişliği ile sınırlıdır ve bant genişliği doygunluğa ulaştığında ekstra çekirdekler fayda sağlamaz. Ön doldurma (prefill) işlemi çekirdek sayısıyla ölçeklenir, bu nedenle daha fazla çekirdek, uzun istemlerde ilk token'a ulaşma süresini kısaltır. 4 ila 8 GB'lık bir VPS'te kısıtlayıcı faktör genellikle bellek kapasitesidir; bu durumda etkili çözüm daha fazla vCPU değil, daha küçük bir model veya daha kısa bir bağlamdır.