Ölçülmüş benchmarklar 8B LLM çıkarımını CPU, NPU ve iGPU donanımında saniyede 10–35 token seviyesine koyuyor

GPU'suz çıkarım için ölçülmüş sayılar

dev.to'daki bir yazı, büyük dil modellerinin CPU'larda, sinir işlem birimlerinde (NPU) ve entegre GPU'larda çalıştırılması için elle ölçülmüş token hızlarını yayımladı; ve ana bulgu, tek kullanıcılı yerel AI'ın sıradan donanımda çalıştığı. Yazarın açılış örneği: 16 GB RAM'e sahip, harici GPU'suz üç yıllık bir danışmanlık dizüstü bilgisayarı, kuantalanmış bir 7B modeli saniyede yaklaşık 11 token hızında çalıştırdı ve firmanın kendi sözleşme PDF'leri üzerinde soruları yanıtladı. Bu bir üretim sohbet servisi değil; ama sorgu başına sıfır maliyetli ve makineden hiçbir veri çıkmayan özel bir asistan.

Sayıların dayandığı teknik iddia, tek kullanıcılı token üretiminin hesaplama değil, bellek bant genişliğiyle sınırlı olduğudur. Bir token üretmek tek bir forward pass gerektirir ve tek bir kullanıcının ürettiği küçük batch boyutlarında önemli olan ham FLOPS değil, ağırlıkların RAM'den ne kadar hızlı aktığıdır. Bu gerçek sonuçların çoğunu açıklıyor.

Donanım gerçekte ne sunuyor

Yazıya göre, güncel tüketici makinelerinde ölçülen hızlar şöyle dağılıyor:

• 2021 model ofis dizüstüsü, 16 GB RAM: Q4_K_M kuantalamasıyla (~5 GB) Llama 3.1 8B, saniyede yaklaşık 10–12 token
• Apple M2/M3 MacBook Air: aynı model saniyede 25–35 token; bu, CPU ile GPU arasında paylaşılan hızlı unified memory'ye bağlanıyor
• Apple M2 Pro/Max: Q4_K_M (~9 GB) ile 14B model, saniyede 20–35 token değil, 20–30 token
• NPU'lu yeni dizüstü CPU'ları (Intel, AMD, Qualcomm): NPU offload ile 7–8B modeller saniyede 15–30 token, daha düşük güç tüketimiyle
• GPU'suz, 16 çekirdekli DDR5 masaüstü CPU: Q4_K_M ile 8B model saniyede 15–20 token; 32 GB RAM'de 14B model saniyede 8–12 token başarıyor
• Paylaşımlı bellekle iGPU offload: yalnızca CPU'ya kıyasla mütevazı bir kazanç

Bağlam için yazar, rahat okuma hızını saniyede yaklaşık 20 token olarak veriyor ve etkileşimli sohbetin saniyede 8 token altında yavaş hissettirmeye başladığını söylüyor. Yüzlerce belgeyi özetlemek gibi gece boyu süren batch işleri etkileşimliliği hiç umursamıyor; bu da hesaplamayı tamamen değiştiriyor.

Prompt uzunluğu deneyimi domine ediyor

Yazı, üretimin iki aşaması arasında bir ayrım yapıyor. Prompt işleme, yani prefill, CPU'da hesaplama sınırldır ve yavaştır: 2.000 tokenlık bir prompt, ilk çıktı tokenı görünmeden önce bir iki saniye alabilir. Token üretimi, yani decode, bellek bant genişliğine bağlıdır ve model ısındıktan sonra istikrarlıdır. Pratik sonuç şu: uzun yanıtlı kısa promptlar iyi hissettirirken, kısa yanıtlı uzun promptlar yavaş hissettiriyor — tamamen prefill süresi. Bağlamı sınırlamak ve girdileri sıkı tutmak bir kalite tavizi değil, bir gecikme kaldıracı olarak çerçeveleniyor.

Dört parçalı stack

Yazara göre, ciddi her CPU inference kurulumu aynı bileşenlere dayanıyor:

• Kuantalanmış GGUF modelleri: 16-bit ağırlıkları 4-bit tamsayılara küçültmek belleği ve bant genişliğini kabaca dört kat azaltıyor. Q4_K_M, 8B bir model için ~5 GB ile önerilen varsayılan; Q8_0 ~9 GB ile daha iyi kalite sunuyor; Q3_K_M 4 GB'a sığıyor ama belirgin kalite kaybıyla.
• llama.cpp: CPU'da hızlı olacak şekilde yazılmış C/C++ referans runtime; layer-count bayrağıyla hibrit donanımda katmanları bir GPU'ya veya NPU'ya devredebiliyor.
• Bir server katmanı: llama.cpp, OpenAI uyumlu chat completions API'sini konuşan bir server binary'siyle geliyor.
• Yapıştırıcı olarak Ollama veya llama-cpp-python: tek bir model pull artı ollama serve, yerel bir OpenAI uyumlu endpoint'i açıyor; böylece mevcut herhangi bir client yalnızca base_url'ini değiştirerek çalışıyor.

Önerilen başlangıç noktası, 16 GB RAM'li makinelerde Q4_K_M ile 7–8B bir model — Llama 3.1, Qwen 2.5 veya Gemma; 8 GB veya daha eski donanımda 3–4B bir modele geçiliyor.

Neden önemli

Bu benchmarklar geliştiricilere pazarlama iddiaları yerine gerçekçi bir karar haritası veriyor. Kişi başına özel asistanlar ve gece boyu süren batch iş yükleri hiç GPU'ya ihtiyaç duymuyor; çok kullanıcılı üretim servisleri duyuyor. Sayılar ayrıca donanım konuşmalarını FLOPS yerine bellek bant genişliği ve prefill gecikmesi etrafında yeniden çerçeveliyor; fanı olmayan bir MacBook Air'in bu iş yükü için daha büyük bir Windows dizüstünü geçmesinin nedenini de bu açıklıyor. Ve yerel runtime'lar OpenAI uyumlu API'ler sunduğu için, mevcut uygulamalar tek satırlık bir yapılandırma değişikliğiyle cihaz üzerindeki modellere taşınabiliyor — "AI için pahalı GPU'lara ihtiyacımız var" cümlesini, gerçekte ne çalıştırdığınız ve kaç kullanıcı için çalıştırdığınız sorusuna dönüştürerek.