Yerel LLM saniye başına token hızı nasıl ölçülür?

Saniye başına token değerinin GPU maliyetini belirleme nedeni

Saniye başına token değeri, sunucunuzun çıktı metnini üretme hızıdır ve bir GPU kiralamanın, token başına ücret ödenen bir API kullanmaktan daha ucuz olup olmadığına karar vermenizi sağlayan temel ölçüttür. Bir GPU sunucusu, meşgul veya boşta olmasına bakılmaksızın saatlik olarak faturalandırılır. Barındırılan bir API ise token başına ücretlendirilir. Dolayısıyla GPU kullanımı, yalnızca ödeme yaptığınız saatlerin büyük çoğunluğunda yeterince yüksek bir çıktı hızını koruyabildiğiniz durumlarda avantajlıdır.

Bu, bir yerlerde okuduğunuz teorik bir rakama değil, kendi ölçümünüze ihtiyaç duyduğunuz anlamına gelir. Bu sayfa, kaydedilmesi gereken dört değeri tanımlar, ardından bu değerleri üreten komutları ve bu değerleri bir karara dönüştüren aritmetik işlemleri açıklar.

Yayınlanan saniye başına token değeri neden sizin değeriniz değildir

DigitalOcean, Temmuz 2026'da vLLM altında FP8 (8-bit kayan nokta) formatında llama3.3-70b-instruct çalıştıran tek bir NVIDIA H200 için verim rakamları yayınladı. Bu rakamlar faydalıdır ancak sizin değerleriniz değildir.

[
  {
    "config": "H200, one stream",
    "tok_s": "47"
  },
  {
    "config": "H100, saturated",
    "tok_s": "236"
  },
  {
    "config": "H200, saturated",
    "tok_s": "2,036"
  },
  {
    "config": "H200, saturated, in+out",
    "tok_s": "4,071.6"
  }
]

Yukarıdaki her satır ilgili sayfadan alıntılanmıştır ve bunlardan ikisi verilen aralığın alt sınırıdır; bu nedenle bu ikisini bir taban değeri olarak okuyun. Bu tablodaki hiçbir şey tarafımızca ölçülmemiştir.

Son iki satırla başlayın. Manşet değeri 4,071.6 tok/s iken, yalnızca çıktı hızı 2,036 tok/s'dir. Manşet değeri, girdi ve çıktı tokenlarını birlikte sayar. Bu testte 1.024 girdi tokenına karşılık 1.024 çıktı tokenı kullanılmıştır, dolayısıyla manşet değerinin neredeyse tam olarak yarısı çıktıdır. Bu ayrım önemlidir çünkü faturalandırıldığınız kısım çıktıdır ve bu yavaş olan kısımdır. Prefill (istemi okuma), tüm girdi tokenlarını tek bir geçişte işler. Decode (cevabı yazma) ise her seferinde bir token üretir. Toplam verim manşeti, ucuz bir sayı ile pahalı bir sayının ortalamasını alır.

Şimdi ilk satıra bakın. Aynı H200, aynı anda tek bir istek sunarken 47 tok/s üretir; dolayısıyla doygunluk rakamı, aynı donanım üzerinde kırk katından daha fazladır. Bu farkın nedeni, tek bir decode adımının GPU'yu zamanının çoğunda bellek için bekletmesidir; eşzamanlı istekler ise bu boş zamanı doldurur. İkinci satır olan 236 tok/s, aynı model üzerinde tek bir H100'dür ve KV cache (anahtar ve değer önbelleği, sunulan bir konuşmanın kart üzerinde tuttuğu istek başına bellek) tarafından kısıtlanmıştır. 80 GB'lık bir kart, 70B'lik bir model için daha az eşzamanlı istek tutar, bu nedenle doygunluk noktası daha düşüktür.

Modeli veya girdi-çıktı oranını değiştirdiğinizde yukarıdaki her sayı değişir. Yayınlanan rakamlar beklentilerinizi belirler, bütçenizi değil; bu, bir VPS'i dürüstçe kıyaslama konusunda disk ve ağ için geçerli olan kuralın aynısıdır.

Önemli olan dört sayı

• İlk token süresi, TTFT. Bir istek gönderilmesi ile ilk çıktı token'ının ulaşması arasındaki gecikmedir. Prefill süresi ile kuyruk süresinin toplamıdır. Kullanıcı bunu doğrudan hisseder.
• Akış başına saniyedeki çıktı token sayısı. Bir yanıt yazılmaya başlandıktan sonra ne kadar hızlı üretildiğidir. Yaklaşık 20 tok/s değerinin üzeri, çoğu insanın okuma hızından daha hızlıdır; bu nedenle buradaki fazladan hızın getirisi azdır.
• Doygun toplam çıktı verimi. Sunucu tam yük altındayken tüm eşzamanlı akışların toplamıdır. Bu, kapasiteyi belirleyen sayıdır ve GPU maliyetini karşılayan metrik budur.
• Eşzamanlılık altında p50 ve p99 TTFT. p50, ortadaki isteği temsil eder. p99, 100 isteğin 99'unun altında kaldığı değerdir. Kuyruklanma her zaman önce p99 değerinde kendini gösterir.

İlk iki değer, sunucu boşta olduğunda iyileşir. Üçüncü değer ise sunucu yoğun olduğunda iyileşir. Bu değerler birbirine zıt çalıştığı için, tek bir sayı bir sunucunun performansını tam olarak tanımlayamaz.

Ölçüm yapmadan önce girdi ve çıktı uzunluklarını sabitleyin

İş hacmi (throughput), trafiğin yapısına bağlıdır. 4,000 token'lık bir istem ve 50 token'lık bir yanıt, prefill (ön dolum) ağırlıklı bir iştir. 200 token'lık bir istem ve 2,000 token'lık bir yanıt ise decode (kod çözme) ağırlıklı bir iştir. Aynı sunucu, bu iki senaryo için birbirinden çok farklı saniye başına token değerleri raporlar; bu nedenle tek bir oran belirleyin, kaydettiğiniz her sayının yanına bu oranı yazın ve farklı oranlara sahip sonuçları asla birbiriyle kıyaslamayın. Birçok tedarikçi bu oranda yayın yaptığı için 1,024 girdi ve 1,024 çıktı makul bir varsayılan değerdir. Eğer gerçek trafik yapınızı biliyorsanız, kendi verilerinizi kullanın.

Çıktı uzunluğunu da zorunlu tutun. 60 token sonra durma belirtecine (stop token) ulaşan bir model, daha kısa bir çalışma süresi sunar ve TTFT (ilk token'a kadar geçen süre) toplam sürede daha büyük bir paya sahip olduğu için daha hızlı görünür. vLLM benchmark istemcisindeki --ignore-eos bayrağı, her isteğin tam olarak belirtilen miktarda token üretmesini sağlar; böylece iki farklı çalışma birbiriyle kıyaslanabilir hale gelir. Model seçimi, bu sayıları herhangi bir bayrak ayarından çok daha fazla etkiler: Qwen 3 modelini tek bir VPS GPU'suna sığdırmak başlıklı yazı, bu seçimin bellek tarafındaki detaylarını ele almaktadır.

Önce tek bir akışı ölçün

En basit durumla başlayın. Bu bir doğrulama testidir ve bir üst sınır belirler. Ollama kendi zamanlama verilerini yazdırır.

ollama run llama3.1:8b --verbose "Write 200 words about disk scheduling."

Okunması gereken satır, saniye başına üretilen token miktarını gösteren eval rate değeridir. prompt eval rate ön doldurma (prefill) hızını, load duration ise modelin VRAM'e yüklenmesi için harcanan süreyi temsil eder. Soğuk başlatma sonrası ilk çağrıda load duration büyük olacağından, total duration yanıltıcıdır. Komutu iki kez çalıştırın ve ikinci sonucu dikkate alın. Ollama, boşta kalan bir modeli varsayılan olarak beş dakika sonra bellekten boşaltır; bu nedenle çalıştırmalar arasında uzun bir duraklama olması sizi tekrar soğuk başlatma durumuna döndürür.

Aynı alanlar, betik yazmak için daha kolay olan API üzerinden de alınabilir.

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Write 200 words about disk scheduling.",
  "stream": false
}' | jq '{eval_count, eval_duration,
         tok_s: (.eval_count / (.eval_duration / 1000000000))}'

eval_duration nanosaniye cinsindendir, bu yüzden 1.000.000.000'a bölmek saniyeyi verir. Bu bölme işlemi, Ollama'nın kendi API dokümantasyonunda saniye başına token için önerdiği yöntemdir. Sunucu henüz hazır değilse, Ollama ile VPS üzerinde LLM barındırma rehberi kurulumu ve systemd birimini kapsar.

TTFT (ilk token'a kadar geçen süre) için bir akış isteği gerekir ve curl bunu sizin için zamanlayabilir.

curl -s -o /dev/null -N \
  -w 'ttfb=%{time_starttransfer}s  total=%{time_total}s\n' \
  http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen/Qwen3-8B",
       "messages":[{"role":"user","content":"Write 200 words about disk scheduling."}],
       "stream":true,"max_tokens":256}'

time_starttransfer, yanıt gövdesinin ilk baytının ulaştığı andır. Akışlı bir sohbet tamamlamasında bu bayt, ya ilk içerik token'ına ya da ondan hemen önce gönderilen rol bilgisi delta'sına aittir. Bu nedenle değeri, bir olaylık sapma payıyla TTFT olarak kabul edin. Aynı sunucudaki iki çalıştırmayı karşılaştırmak için yeterince doğrudur.

Tek akışlı sayılar, sunucuyu olduğundan daha iyi gösterir. TTFT, alabileceğiniz en iyi değerdir çünkü önünüzde kuyrukta bekleyen başka bir işlem yoktur. Akış başına hız da en iyi değerdir çünkü tüm ekran kartı tek bir isteğe hizmet vermektedir. Bu değerlerin hiçbiri, sunucunun gerçek kapasitesini tek başına yansıtmaz.

Eşzamanlılık taraması nasıl çalıştırılır?

Bir tarama, sabit bir iş yükünü artan eşzamanlılık seviyelerinde çalıştırır ve her adımda ne olduğunu kaydeder. vLLM bunun için gerekli istemciyi sunar; bu istemci OpenAI API ile konuştuğu için Ollama ve OpenAI uyumlu diğer tüm araçlarla da çalışır.

vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/chat/completions \
  --model Qwen/Qwen3-8B \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 1024 \
  --ignore-eos \
  --num-prompts 160 \
  --max-concurrency 16 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,99

--max-concurrency, uçuş halindeki istekleri sınırlar ve taradığınız değişken budur. --num-prompts gönderilen toplam istek sayısıdır; kararlı bir ortalama elde etmek için bu değeri eşzamanlılığın yaklaşık on katı tutun. Özet rapor Output token throughput (tok/s): ve Total token throughput (tok/s): değerlerini, ardından Time to First Token başlığı altında Mean TTFT (ms):, Median TTFT (ms): ve P99 TTFT (ms): verilerini yazdırır.

Çıktıda akış başına hız bilgisi yer almaz ancak bu değer basit bir bölme işlemiyle elde edilebilir. Mean TPOT (ms):, ilk tokendan sonraki ortalama token süresidir; dolayısıyla token başına 25 ms, akış başına saniyede 40 token anlamına gelir. Çıktı verimini eşzamanlılığa bölmek de aynı sonucu verir.

Ardından her çalıştırmayı kaydederek bir döngü oluşturun.

for C in 1 4 16 32 64 128; do
  vllm bench serve \
    --backend openai-chat \
    --base-url http://127.0.0.1:8000 \
    --endpoint /v1/chat/completions \
    --model Qwen/Qwen3-8B \
    --dataset-name random \
    --random-input-len 1024 \
    --random-output-len 1024 \
    --ignore-eos \
    --num-prompts $(( C * 10 )) \
    --max-concurrency "$C" \
    --percentile-metrics ttft,tpot,itl,e2el \
    --metric-percentiles 50,99 \
    --save-result --result-filename "sweep-c$C.json"
done

for f in sweep-c*.json; do
  jq -r --arg f "$f" \
    '[$f, .output_throughput, .total_token_throughput,
      .median_ttft_ms, .p99_ttft_ms] | @tsv' "$f"
done

Eşzamanlılık taraması gerçekte neyi gösterir?

[
  {
    "label": "1 stream",
    "per_stream_tok_s": 92,
    "total_tok_s": 92,
    "ttft_p50_ms": 48,
    "ttft_p99_ms": 61
  },
  {
    "label": "4 streams",
    "per_stream_tok_s": 88,
    "total_tok_s": 352,
    "ttft_p50_ms": 71,
    "ttft_p99_ms": 96
  },
  {
    "label": "16 streams",
    "per_stream_tok_s": 71,
    "total_tok_s": 1136,
    "ttft_p50_ms": 152,
    "ttft_p99_ms": 244
  },
  {
    "label": "32 streams",
    "per_stream_tok_s": 54,
    "total_tok_s": 1728,
    "ttft_p50_ms": 287,
    "ttft_p99_ms": 498
  },
  {
    "label": "64 streams",
    "per_stream_tok_s": 34,
    "total_tok_s": 2176,
    "ttft_p50_ms": 611,
    "ttft_p99_ms": 1240
  },
  {
    "label": "128 streams",
    "per_stream_tok_s": 18,
    "total_tok_s": 2304,
    "ttft_p50_ms": 1490,
    "ttft_p99_ms": 3820
  }
]

6 satırlık veri, küçük ve kiralanabilir bir GPU sunucusunda taramanın oluşturduğu yapıyı makul büyüklük değerleriyle göstermektedir. Bunlar sizin sunucunuza ait ölçümler veya bir satıcı verisi değildir. Yukarıdaki döngüyü çalıştırın ve değerleri kendinizinkilerle değiştirin.

Yapıyı inceleyin; çünkü genellenebilir olan şey yapının kendisidir. Tek bir akışta sunucunun tamamı saniyede 92 token üretirken, p99 TTFT değeri 61 ms seviyesindedir. 128 streams değerinde toplam çıktı saniyede 2304 token ile yirmi beş katına çıkar; ancak her bir akışın hızı saniyede 18 token değerine düşer ve p99 TTFT süresi 3820 ms olur. Toplam iş hacmi artar çünkü toplu işleme (batching), boşta bekleyen bellek süreçlerini verimli işe dönüştürür. Akış başına hız düşer çünkü aynı hesaplama gücü artık paylaşılmaktadır.

Son ikiye katlama aşaması belirleyicidir. Akış sayısını 64'ten 128'e çıkarmak toplam çıktıyı yüzde altıdan daha az artırırken, p99 TTFT süresi yaklaşık üç katına çıkar. Bu durum KV önbelleğinin dolduğunu ve isteklerin çalışmak yerine kuyrukta beklediğini gösterir. Verimli çalışma noktası daha erkendedir: 32 akışta sunucu, zirve noktasının yüzde 75'i olan saniyede 1728 token üretir; akış başına saniyede 54 token ve p99 TTFT değeri 498 ms sağlar. Kapasiteniz olarak bu noktayı raporlayın. Eğrinin zirve noktası, kullanıcılara hizmet verilebilecek bir değer değildir.

Ollama ve vLLM aynı metrikleri ölçmez

Bu taramayı varsayılan bir Ollama sunucusunda çalıştırırsanız toplam değer neredeyse hiç değişmez. OLLAMA_NUM_PARALLEL varsayılan olarak 1 değerine ayarlanmıştır; bu nedenle bir istek çalışırken diğerleri bekler. p99 TTFT süresinin artmasına neden olan şey bu kuyruktur, toplam çıktı ise sabit kalır. Herhangi bir ölçüm yapmadan önce bu değeri yükseltin.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

Sunucuyu sudo systemctl restart ollama ile yeniden başlatın ve modelin hala VRAM'e sığdığını doğrulayın. Her paralel yuva (slot), bağlam penceresinden (context window) kendi payını alır; bu nedenle Ollama belgeleri, 4 paralel istek ile 2K bağlamın 8K alan tükettiğini belirtir. Yuva sayısını çok fazla artırırsanız model VRAM'den taşar. ollama ps çıktısını kontrol edin: PROCESSOR sütununda 48%/52% CPU/GPU gibi bir değer görmeniz, modelin bir kısmının CPU üzerinde çalıştığı anlamına gelir. Bu durumda, eşzamanlılığı artırdıkça verim artmak yerine düşecektir. Paralel yuvaların ötesindeki istekler, varsayılan olarak 512 olan OLLAMA_MAX_QUEUE değerine kadar kuyruğa alınır; bu sınırdan sonra sunucu 503 hatası döndürür.

vLLM sürekli toplu işleme (continuous batching) kullanır; bu sayede yuvalar boşaldıkça yeni istekleri çalışan toplu işe dahil eder ve KV önbelleği tükenene kadar performans eğrisi yükselmeye devam eder. Ollama; tek model, tek makine ve düşük kurulum maliyeti için optimize edilmiştir. Bu nedenle iki motor, aynı tarama işlemine farklı yanıtlar verir; Ollama ve vLLM sunum motorları olarak karşılaştırması konusunun asıl özü de budur. Her bir verinin hangi motor ve hangi sürüm ile üretildiğini mutlaka kaydedin.

Yanlış metrikleri ölçmenin beş yolu

• İstemci çok uzakta. İnternet üzerinden dizüstü bilgisayarınızla kıyaslama yapmak, her TTFT değerine gidiş-dönüş sürenizi ekler; bu durumda kendi ev bağlantınızı ölçmüş olursunuz. İstemciyi sunucuyla aynı bölgede çalıştırın.
• Model soğuktu. İlk istek ağırlıkların yüklenmesine neden olur; vLLM üzerinde ayrıca grafik yakalama (graph capture) maliyeti de oluşabilir. Bir ısınma (warmup) grubu gönderin ve sonucu dikkate almayın.
• Önek önbelleği (prefix caching) sizin yerinize yanıt verdi. vLLM, önek önbelleğini varsayılan olarak etkinleştirir; bu nedenle aynı istemi tekrar tekrar göndermek, prefill (ön doldurma) yerine önbelleği ölçmenize neden olur ve TTFT değeri gerçek değerin çok altına düşer. --dataset-name random her istem farklı olduğu için bu durumu engeller. Emin olmak için sunucuyu --no-enable-prefix-caching ile başlatın.
• Çıktılar çok kısaydı. 32-token'lık yanıtlarla TTFT her isteğe hakim olur ve saniye başına token değeriniz aslında sadece prefill sürecini tanımlar. Gerçekçi bir çıktı uzunluğu ile --ignore-eos kullanın.
• Eşzamanlılığı (concurrency) 1 olarak raporladınız. Bu, tablodaki en iyimser sayıdır ve maliyetle hiçbir ilgisi yoktur.

Ölçülen değerinizi bir karara dönüştürün

Tekil akış hızını değil, tarama sonucunda elde ettiğiniz doygunluktaki toplam çıktı verimini alın ve bunu token başına fiyatlandırma ile karşılaştırın. Başabaş noktası basit bir bölme işlemiyle bulunur:

break_even_tok_s = (price_per_hour / price_per_million_output_tokens) * 1000000 / 3600

Bunu DigitalOcean'ın Temmuz 2026 fiyatlarıyla hesaplayalım. H200 özel çıkarım uç noktası saatlik 4.47 dolar, sunucusuz eşdeğeri ise milyon token başına 0.65 dolardı. Bu durumda 4.47 bölü 0.65, saatte 6.88 milyon token eder; bunu 3.600 saniyeye böldüğümüzde saniyede yaklaşık 1.910 çıktı tokeni elde ederiz. Fiyatlar onlara, bölme işlemi ise bize aittir.

Bu kararı belirleyen kelime sürdürülebilirliktir. Doygunluk noktasında günde iki saat boyunca saniyede 1.910 token hızına ulaşmak, saniyede 1.910 token sürdürülebilir hız anlamına gelmez; çünkü diğer yirmi iki saatin de ödemesini yaparsınız. DigitalOcean'ın daha ucuz olan saatlik 3.44 dolarlık GPU Droplet seçeneği için başabaş noktası yüzde 72.2 sürdürülebilir ortalama kullanımdır; bunun altındaki kullanımlarda token başına fiyatlandırma daha avantajlıdır. Kendi sunucunuzu barındırırken maliyeti genellikle yavaş tokenler değil, boşta geçen GPU saatleri artırır.

Dolayısıyla kararınız iki girdiye dayanır. Tarama size tavan değerini verir. Trafik düzeniniz ise bu tavan değerin ne kadarını fiilen kullandığınızı belirler. Bu ikisini çarpın, ardından sonucu GPU VPS ile token başına API başabaş noktası kısmına götürün ve hacminiz için geçerli olan cevabı okuyun.

FAQ

Kendi kendine barındırılan bir LLM için saniyedeki iyi token sayısı nedir?

Bu metrik iki farklı işlevi yerine getirdiği için iki cevabı vardır. Çıktıyı okuyan tek bir kullanıcı için, akış başına saniyede yaklaşık 20 token üzerindeki herhangi bir hız, okuma hızından daha yüksek olduğu için daha fazlası bir avantaj sağlamaz. Maliyet açısından önemli olan sayı, doygunluğa ulaşmış toplam çıktı verimliliğidir; "iyi" ifadesi, başa baş noktanızı kurtaran her değer için geçerlidir. Saati 4.47 dolar olan bir sunucuda milyon token başına 0.65 dolarlık bir maliyete karşı, Temmuz 2026 fiyatlarıyla bu alt sınır saniyede yaklaşık 1,910 sürekli çıktı tokenidir. Büyük bir modeldeki tek bir akış bu seviyeye asla ulaşamaz, batching (toplu işleme) yönteminin var olma nedeni de budur.

Eşzamanlı istek eklediğimde Ollama verimliliğim neden sabit kalıyor?

OLLAMA_NUM_PARALLEL varsayılan olarak 1 değerindedir; bu nedenle sunucu model başına aynı anda tek bir istek çalıştırır ve 503 hatası dönmeden önce geri kalanını OLLAMA_MAX_QUEUE (varsayılan olarak 512) değerine kadar kuyruğa alır. Toplam çıktı sabit kalırken p99 TTFT değerinin yükselmesi, GPU'nun meşgul olmasından ziyade bir kuyruğun oluştuğunun göstergesidir. Değişkeni bir systemd drop-in dosyası içinde ayarlayıp servisi yeniden başlatın, ardından ollama ps değerini kontrol edin; çünkü her paralel yuva, ayrılan bağlamı (context) çoğaltır ve modelin bir kısmını CPU üzerine itebilir.

İlk token süresini mi yoksa saniyedeki token sayısını mı ölçmeliyim?

Her ikisini de ölçmelisiniz, çünkü yük arttıkça zıt yönlerde hareket ederler. TTFT kullanıcının hissettiği değerdir, doygunluğa ulaşmış çıktı verimliliği ise faturanıza yansıyan değerdir. Her eşzamanlılık adımında p50 ve p99 TTFT değerlerini kaydedin, ardından p99 TTFT'nin sizin için hala kabul edilebilir olduğu en yüksek eşzamanlılık seviyesini seçin. Kapasiteniz olarak eğrinin tepesindeki maksimum değeri değil, o noktadaki verimliliği raporlayın.

Saniyedeki token sayısının yüksek olması her zaman token başına maliyetin düşük olduğu anlamına mı gelir?

Hayır. Token başına maliyet, saatlik fiyatın o saat içinde sunucunun gerçekten ürettiği token sayısına bölünmesiyle hesaplanır; bu nedenle günün büyük kısmında boşta kalan hızlı bir sunucunun token başına maliyeti yine de yüksektir. Bunu belirleyen şey tepe hızı değil, kullanım oranıdır. Birimlere de dikkat edin: belirtilen toplam token verimliliği giriş tokenlerini de sayar; bu nedenle 1:1 giriş-çıkış oranında, bu değer faturalandırıldığınız çıktı hızının yaklaşık iki katıdır.