Ollama num_ctx ayarı ile bağlam uzunluğunu artırma

num_ctx ne işe yarar ve uzun isteminiz neden kesildi

Ollama bağlam uzunluğu, yüklenen bir modelin aynı anda bellekte tutabileceği token sayısıdır ve num_ctx bunu ayarlayan seçenektir. Ollama, modelin sunduğu maksimum değerin çok altında bir varsayılan değer seçer; bu nedenle daha uzun bir istem, model onu okumadan önce kesilir. Yanıt içerisinde bunun gerçekleştiğine dair hiçbir uyarı yer almaz.

Llama 3.1 8B, Ollama model kütüphanesinde 128k bağlam penceresi ile listelenir. Standart bir sunucu size bu değeri vermeyecektir. Ollama'nın kendi belgeleri farklı sayfalarda farklı varsayılan değerler sunar: SSS bölümü 4096 token değerini belirtirken, Modelfile referansı num_ctx değerinin varsayılan olarak 2048 olduğunu söyler ve bağlam uzunluğu sayfası varsayılan değerin mevcut VRAM (video RAM) miktarına göre seçildiğini belirtir: 24 GiB altı için 4k, 24 ile 48 GiB arası için 32k ve üzeri için 256k. Bunların her biri belirli bir sürüm için doğruydu. Bu tutarsızlık, buradan çıkarılması gereken faydalı derstir: bu sayfa dahil hiçbir kaynağa güvenmek yerine, değeri doğrudan çalışan kendi sunucunuzdan okuyun.

Kırpma işlemi sessizce gerçekleşir çünkü model yanıt vermeye devam eder ve yanıt akıcı görünür. Yanıt, girdinizin son kısmından oluşturulmuştur. Bir belgenin ilk yarısını içermeyen bir özet, zayıf bir model izlenimi verir. Bunun nedeni genellikle küçük bir bağlam penceresidir.

Sunucunuzun uyguladığı Ollama bağlam uzunluğunu denetleyin

Her sürümde çalışan denetim prompt_eval_count komutudur; bu komut, sunucunun işlediğini bildirdiği istem belirteçlerinin (prompt tokens) sayısını verir. Bağlamın alabileceğinden daha fazla veri gönderdiğinizde bu sayı sınırda durur.

sudo apt update && sudo apt install -y jq
LONG=$(python3 -c "print('the quick brown fox jumps over the lazy dog. ' * 2000)")
jq -n --arg p "$LONG" '{model:"llama3.1:8b", prompt:$p, stream:false, options:{num_ctx:4096}}' |
  curl -s http://localhost:11434/api/generate -d @- |
  jq '{prompt_eval_count, prompt_eval_duration}'

Bu istem yaklaşık 18.000 kelimedir, yani 4096 belirteçten çok daha fazladır. prompt_eval_count çıktısı, sunucu geri kalanını attığı için gerçek belirteç sayısına yakın olmak yerine 4096 civarında bir değer döndürür. Komutu "num_ctx":16384 ile tekrar çalıştırdığınızda sayı yükselir. Eğer sürümünüz veriyi kırpmak yerine hata döndürüyorsa, bu durum aynı bulgunun daha belirgin bir göstergesidir.

ollama ps

CONTEXT sütunu, bunu yazdıran sürümlerde, yüklü modelin o an hangi bağlam uzunluğuyla çalıştığını gösterir. Yanındaki PROCESSOR sütunu ise modelin nerede konumlandığını belirtir. 100% CPU, GPU bulunmayan bir VPS üzerinde normaldir. GPU içeren bir sunucuda 30%/70% CPU/GPU gibi bir bölünme, ağırlıkların ve önbelleğin artık VRAM'e sığmadığı anlamına gelir; bunun yaygın nedeni ise yükseltilmiş num_ctx değeridir.

journalctl -u ollama --no-pager | grep -i n_ctx | tail -n 5

Çıkarım çalıştırıcısı (inference runner), bağlam boyutunu n_ctx içeren bir satırda yazdırır. Tam ifade sürümler arasında değişebilir, bu nedenle satırın eksik olması durumunda bunu bir kanıt olarak değil, isim değişikliği olarak değerlendirin.

num_ctx ayarının yapılabileceği dört yer

İstek içerisinde. "options": {"num_ctx": 16384} değerini /api/generate veya /api/chat parametresine gönderin. Bu yöntem diğer tüm ayarları geçersiz kılar ve yalnızca ilgili çağrı için geçerli olur. Eğer değer, yüklü modelin o an çalıştığı değerden farklıysa, sunucu önce modeli yeniden yükler; bunu yanıt içerisindeki load_duration değerinde görebilirsiniz: değer sıfıra yakın bir seviyeden saniyeler mertebesine çıkar.

Etkileşimli oturumda. ollama run içerisinde /set parameter num_ctx 16384 komutunu yazın. Bu ayar sadece o oturum süresince geçerli kalır.

Modelfile içerisinde. Bu yöntem, değeri isimlendirilmiş bir modele sabitler; böylece istemci tarafında herhangi bir değişiklik yapılmasına gerek kalmadan her istemci bu değeri kullanır.

FROM llama3.1:8b
PARAMETER num_ctx 16384

ollama create llama3.1-16k -f ./Modelfile
ollama run llama3.1-16k

Sunucu üzerinde. OLLAMA_CONTEXT_LENGTH, kendi num_ctx parametresini içermeyen her istek için varsayılan değeri belirler. systemd kullanıyorsanız, birim dosyasını (unit file) düzenlemek yerine bir drop-in dosyası ekleyin.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_CONTEXT_LENGTH=16384"

sudo systemctl daemon-reload
sudo systemctl restart ollama
ollama ps

Öncelik sırası, özellikle başka birinin istemcisinde hata ayıklarken önem kazanır. num_ctx parametresini içeren bir istek, sunucu varsayılanını geçersiz kılar; bu nedenle kendi küçük değerini gönderen bir sohbet arayüzü veya bir aracı (agent), sizin systemd üzerinde yaptığınız değişikliği sessizce etkisiz hale getirebilir. Bir kodlama aracını Ollama sunucunuza yönlendirirken, sunucuyu suçlamadan önce istemcinin ne gönderdiğini kontrol edin.

Neden num_ctx değerini doğrudan modelin maksimum değerine ayarlayamazsınız

Attention mekanizması, her bir token'ın kendisinden önceki tüm token'ları incelemesini sağlar. Önceki token'lar için hesaplanan anahtar (key) ve değer (value) verileri, her yeni token için tekrar hesaplanmamaları amacıyla saklanır; bu depolama alanına KV cache (anahtar/değer önbelleği) denir. Bu alan, model yüklendiğinde tüm num_ctx için ayrılır; konuşma ilerledikçe büyümez. Bu nedenle, tek satırlık bir istemde bile geniş bir bağlam (context) ciddi miktarda bellek tüketir.

DigitalOcean'ın çıkarım maliyeti eğitimi, bu hesaplamayı tek bir satırda özetler:

kv_bytes_per_token = 2 * layers * kv_heads * head_dim * bytes_per_value

Buradaki 2 çarpanı, anahtar ve değerleri ayrı ayrı sayar. Diğer sayıları kendi modelinizin verilerinden okuyabilirsiniz.

curl -s http://localhost:11434/api/show -d '{"model":"llama3.1:8b"}' |
  jq '.model_info | {ctx: ."llama.context_length", layers: ."llama.block_count", heads: ."llama.attention.head_count", kv_heads: ."llama.attention.head_count_kv", embed: ."llama.embedding_length"}'

Llama 3.1 8B modeli 32 katman ve 8 anahtar/değer başlığı (head) bildirir. Başlık boyutu, embed değerinin heads değerine bölünmesiyle bulunur; yani burada 4096 / 32 = 128 eder. Bazı modeller bu değeri doğrudan llama.attention.key_length olarak yayınlar. Varsayılan önbellek f16 değerlerini tutar, bu yüzden bytes_per_value değeri 2'dir. 2 32 8 128 2 işlemi sonucunda 131.072 bayt elde edilir. Bu, bağlamdaki her bir token için 128 KiB önbellek demektir. Bunu bağlam uzunluğuyla çarptığınızda maliyet soyut bir kavram olmaktan çıkar.

[
  {
    "label": "4k",
    "kv_cache_gib": 0.5,
    "total_ram_gib": 5.1
  },
  {
    "label": "8k",
    "kv_cache_gib": 1,
    "total_ram_gib": 5.6
  },
  {
    "label": "16k",
    "kv_cache_gib": 2,
    "total_ram_gib": 6.6
  },
  {
    "label": "32k",
    "kv_cache_gib": 4,
    "total_ram_gib": 8.6
  },
  {
    "label": "64k",
    "kv_cache_gib": 8,
    "total_ram_gib": 12.6
  },
  {
    "label": "128k",
    "kv_cache_gib": 16,
    "total_ram_gib": 20.6
  }
]

6 satırı, yukarıdaki formülden elde edilen matematiksel sonuçlardır, ölçüm değildir. Toplam sütunu, Ollama kütüphanesinin Ağustos 2026'da llama3.1:8b için listelediği 4,9 GB'lık indirme boyutunu (4,6 GiB) içerir ancak hesaplama tamponlarını ve sunucu sürecinin kendisini dışarıda bırakır. Bu değerleri bir alt sınır olarak kabul edin.

Önemli olan yapıdır. 8k bağlamda önbellek maliyeti 1 GiB'dir; bu, model ağırlıklarının yanında ihmal edilebilir bir değerdir. Modelin tam 128k kapasitesinde ise maliyet 16 GiB'ye çıkar; bu da ağırlıkların üç katından fazladır ve toplamda 20.6 GiB civarında bir değer oluşturur. Dolayısıyla 4 GB RAM'e sahip bir VPS, bu modeli hiçbir kullanışlı bağlam uzunluğunda yükleyemez. 8 GB RAM'li bir VPS, 8k bağlam için uygundur. 16 GB RAM'li bir VPS ise sunucunun geri kalanı için yer bırakarak 32k bağlama ulaşabilir. Bu eşiklerin her biri model ağırlıklarıyla birlikte değişir; bu nedenle daha büyük bir modeli bu 8B modelle kıyaslıyorsanız, Qwen'in 27B etiketli modelinin sadece CPU kullanılan bir VPS üzerindeki durumu için yapılan hesaplamalar, 8 GB ile 64 GB RAM arasında bağlam için ne kadar az alan kaldığını göstermektedir.

KV önbelleği sığmadığında ne olur

Sadece CPU kullanan bir VPS üzerinde süreç basitçe büyür. Model yüklenirken ve uzun bir istek çalışırken süreci izleyin.

free -m
ps -eo rss,comm --sort=-rss | head -n 5

RSS (resident set size) değeri kilobayt cinsinden yazdırılır. Eğer free -m içindeki swap kullanımı artmaya başlarsa, bağlam (context) değerini düşürün. Swap üzerinde tutulan bir KV önbelleği, her yeni token tüm önbelleği okuduğu için üretim hızını token başına saniyeler mertebesinde yavaşlatır.

Eğer sunucunun belleği tamamen tükenirse, çekirdek en büyük süreci seçer ve sonlandırır.

sudo dmesg | grep -i "killed process"

Out of memory: Killed process 1234 (ollama) ifadesini içeren bir satır, talep ettiğiniz bağlamın sığmadığı anlamına gelir. Ollama genellikle bu noktaya gelmeden önce reddeder ve istek, talep edilen bellek miktarı ile boş bellek miktarını belirten bir hata mesajıyla başarısız olur.

GPU bulunan bir sunucuda hata daha sessiz gerçekleşir. Katmanlar sistem RAM'ine taşar, ollama ps CPU ve GPU dağılımını gösterir ve işleme hızı keskin bir şekilde düşer. Düşüşün ne kadar keskin olacağı donanımınıza bağlıdır; bu nedenle başka bir makineye ait verilere güvenmek yerine kendi sunucunuzda saniye başına düşen token sayısını ölçün ve her bağlam ayarı için bunu test edin.

Prefill süresi istemden daha hızlı artar

Prefill, ilk çıktı token'ı görünmeden önce girdiğiniz üzerinde yapılan işlemdir. Her istem token'ı kendisinden önceki tüm token'lara odaklandığından, toplam iş yükü girdi uzunluğunun karesiyle orantılı olarak artar. İstem uzunluğunu iki katına çıkarmak, ilk token için bekleme süresini iki kattan fazla artırır.

Yanıt ölçümü içerdiğinden, buna güvenmek zorunda değilsiniz.

jq -n --arg p "$LONG" '{model:"llama3.1:8b", prompt:$p, stream:false, options:{num_ctx:16384}}' |
  curl -s http://localhost:11434/api/generate -d @- |
  jq '{tokens: .prompt_eval_count, prefill_seconds: (.prompt_eval_duration/1000000000)}'

Bunu kısa bir istemle ve ardından uzun bir istemle çalıştırın, ardından her iki durum için de token sayısını saniyeye bölün. Yalnızca CPU kullanılan bir VPS üzerinde prefill, genellikle uzun bağlamlı bir isteğin en yavaş kısmıdır ve kısa bir istemden elde edilen saniyedeki token değeri bunu öngörmeyecektir.

Eşzamanlılık, bu durumun en çok hissedildiği alandır. Hizmet verilen her isteğin kendi önbelleğine ihtiyacı vardır, bu nedenle yukarıdaki grafikteki bellek sunucu başına değil istek başınadır ve tek bir uzun istek, kısa istekler arkasında kuyrukta beklerken sunucuyu meşgul edebilir. OLLAMA_NUM_PARALLEL değerini bilinçli bir şekilde ayarlayın ve her iki sayıyı da birlikte artırmadan önce kendi kendine barındırılan bir LLM'in kaç eşzamanlı kullanıcıya hizmet verebileceği konusunu okuyun.

Daha küçük bir önbellek ile bağlamı geri kazanın

Formüldeki bytes_per_value, kontrol edebileceğiniz bir ayardır. Ollama SSS belgesi OLLAMA_KV_CACHE_TYPE konusunu, 2 baytlık varsayılan f16 değeri, 1 baytlık q8_0 değeri ve bunun altındaki q4_0 değeri ile açıklar. q8_0 değerine geçmek önbelleği yarıya indirir; böylece 32k satırı 4 GiB yerine 2 GiB maliyet oluşturur. Aynı SSS belgesi, bazı derlemelerin nicelenmiş (quantised) bir önbelleğin etkili olması için ihtiyaç duyduğu OLLAMA_FLASH_ATTENTION=1 ayarını da açıklar.

[Service]
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KV_CACHE_TYPE=q8_0"

Varsaymak yerine doğrulayın: servisi yeniden başlatın, modeli daha öncekiyle aynı num_ctx değerinde yükleyin ve RSS değerini karşılaştırın. Destek, modele ve arka uca bağlıdır; bu nedenle hiçbir şeyi değiştirmeyen bir ayar, kullandığınız kombinasyonun desteklenmediği anlamına gelir. Belgeler bu seçenekleri, kaliteli bir sonuç garantisi vermeden listeler; bu yüzden güvenilir bir şekilde kullanmadan önce q4_0 ayarını kendi istemlerinizle test edin. Eğer buraya gelmenizin nedeni bu ince ayarlar ise, Ollama ve llama.cpp bunları farklı şekilde sunar.

num_ctx değerini belirleme yöntemi

1. Modelin maksimum bağlam (context) kapasitesini, katman sayısını ve anahtar/değer (key/value) başlık sayısını /api/show üzerinden okuyun.
2. Token başına düşen bayt miktarını formülle hesaplayın ve hedeflediğiniz bağlam değeriyle çarpın.
3. Ağırlık boyutunu ekleyin, boş RAM miktarıyla karşılaştırın ve sistemin geri kalanı için en az 1 GiB boş alan bırakın.
4. Değeri ayarlayın, modeli yükleyin ve ardından ollama ps ile prompt_eval_count kullanarak uygulanan değeri doğrulayın.
5. Gerçek iş yükünüzü çalıştırırken free -m üzerinden izleme yapın; eğer swap kullanımı başlarsa bağlam değerini yarıya indirin.

Çoğu iş, insanların atadığı bağlam değerinden daha azına ihtiyaç duyar. Uzun bir raporu özetlemek 16k içinde rahatlıkla sığar. Beş belge parçasını yapıştıran bir getirme (retrieval) arayüzü nadiren 8k değerini aşar. Tüm dosyaları okuyan bir kodlama ajanı, gerçekten 64k veya daha fazlasına ihtiyaç duyan durumdur; bu aynı zamanda makineyi bağlama göre boyutlandırmanız gereken senaryodur. Sunucu henüz yeniyse, çalışan bir Ollama kurulumu ile başlayın ve modeller sorunsuz yüklendikten sonra bağlam ayarlarını optimize edin.

FAQ

Ollama icindeki varsayilan baglam uzunlugu (context length) nedir?

Bu durum derlemeye ve donanima gore degisiklik gosterir, bu nedenle varsayimda bulunmak yerine kontrol edilmelidir. Ollama SSS dokumani 4096 token degerini belirtirken, Modelfile referansi num_ctx varsayilan degerini 2048 olarak gosterir; baglam uzunlugu sayfasi ise mevcut VRAM miktarina gore secilen bir varsayilan degerden bahseder: 24 GiB altinda 4k, 24 ile 48 GiB arasinda 32k ve uzerinde 256k. Yalnizca CPU kullanan bir VPS, dusuk degerle baslar. ollama ps, ilgili sutunu tasiyan derlemelerde uygulanan baglam uzunlugunu yazdirir; prompt_eval_count ise her derlemede API yanitinda bunu kanitlar.

Ollama neden uzun istemimin (prompt) basini yok sayiyor?

Cunku istem, baglam penceresinden daha uzundur; bu nedenle sunucu, model gormeden once onu kesmistir ve herhangi bir hata donmemistir. Ayni istemi daha buyuk bir num_ctx ile tekrar gonderin ve yanittaki prompt_eval_count degerinin arttigini gozlemleyin. Eger bu sayi degismiyorsa, sizinle sunucu arasinda bir katman num_ctx degerini kendisi ayarlamaktadir; bu durum sohbet arayuzlerinde ve ajan catilarinda (agent frameworks) yaygindir.

Daha buyuk bir num_ctx ne kadar ek RAM gerektirir?

Baglam uzunlugunu, token basina dusen onbellek maliyeti olan 2 * layers * kv_heads * head_dim * bytes_per_value ile carpin. Llama 3.1 8B f16 modeli icin bu deger token basina 128 KiB'dir; dolayisiyla 32k token, agirliklara ek olarak 4 GiB, tam 128k ise 16 GiB maliyet getirir. Onbellek, model yuklendiginde tahsis edilir; bu nedenle buyuk bir num_ctx, istemleriniz kisa kalsa bile bu bellek miktarini kullanir.

Daha buyuk bir baglam penceresi Ollama'yi yavaslatir mi?

Evet, iki sekilde yavaslatir. On hazirlik (prefill) islemi, istem uzunlugunun karesiyle orantili olarak artar; bu nedenle uzun bir girdi, ilk token'in gelisini uzunlugunun ima ettiginden daha fazla geciktirir. Daha buyuk onbellek ayrica bellek icin rekabet eder: GPU'lu bir sistemde katmanlari sistem RAM'ine iter, CPU'lu bir sistemde ise makineyi swap kullanimina zorlar. Hic doldurmadiginiz buyuk bir num_ctx, on hazirlik suresini etkilemese de bellek maliyetini yaratmaya devam eder.

Bir model icin num_ctx degerini kalici olarak ayarlayabilir miyim?

Evet. FROM llama3.1:8b ve PARAMETER num_ctx 16384 iceren bir Modelfile yazin ve ardindan ollama create llama3.1-16k -f ./Modelfile komutunu calistirin. llama3.1-16k isteyen her istemci, herhangi bir secenek gondermesine gerek kalmadan bu baglam degerini alir. Kendi num_ctx degerini tasiyan bir istek yine de onceliklidir; dolayisiyla bu islem bir tavan degeri degil, bir varsayilan deger belirler.