Yerel LLM Modellerinde Muhakeme Çabası Ayarları

Yerel bir LLM üzerinde muhakeme çabası neyi değiştirir

Muhakeme çabası (reasoning effort), bir modele yanıt vermeden önce ne kadar süre düşünmesi gerektiğini belirten bir ayardır. Bu ayar, yalnızca muhakeme bölümünün uzunluğunu değiştirir, başka hiçbir şeyi etkilemez. Diskteki ağırlıklar her seviyede aynıdır, kuantizasyon (quantisation) aynıdır ve yanıt aynı ileri beslemeli geçişten (forward pass) elde edilir. Değişen tek şey, modelin başlangıçta kendi çalışma alanına (scratchpad) kaç adet token harcadığıdır.

Bu ayrım, söz konusu tokenların nereye yerleştiği nedeniyle önemlidir. Barındırılan bir API üzerinde muhakeme tokenları faturaya yansır. Kendi VPS'inizde ise bu tokenların bedeli, kendi CPU veya GPU'nuzdaki üretim süresi ve bağlam penceresi (context window) içindeki alan olarak ödenir. En yüksek çaba seviyesine ayarlanmış bir model, yanıtın ilk kelimesi görünmeden önce çıktısının büyük bir kısmını muhakemeye harcayabilir; bu durum, kendi barındırdığınız donanımda iki saniyelik bir yanıt ile iki dakikalık bir yanıt arasındaki farkı oluşturur.

Seviyenin bulunduğu yer: ağırlıklar değil, sohbet şablonu

Düşünme yeteneğine sahip bir model, nihai cevabından önce genellikle <think> ve </think> etiketleri arasına sarılmış bir muhakeme bölümü üretmek üzere eğitilmiştir. Çaba seviyesi, modelin sohbet şablonunun isteme (prompt) yazdığı bir talimattır. Bu şablon, modelle birlikte gönderilen bir Jinja dosyasıdır. Şablon, reasoning_effort gibi bir değişkeni okur ve her değer için farklı bir sistem düzeyi satırı oluşturur; model, bu satıra yanıt olarak karalama defterini kısaltmak veya uzatmak üzere eğitilmiştir.

Buradan iki sonuç çıkar. Seviye isimleri çalışma zamanınıza değil modele aittir; bu nedenle bir modelin kartındaki isim, başka bir model için hiçbir anlam ifade etmeyebilir. Ayrıca, zincirdeki herhangi bir işlem modelin sohbet şablonunu genel bir şablonla değiştirirse, değişken hiçbir zaman işlenmez ve ayar sessizce etkisiz kalır.

2026-08-20 tarihinde kontrol edildiği üzere, Qwen3.8-27B model kartı üç çaba seviyesini belgelemektedir: low, medium ve xhigh; varsayılan değer ise xhigh'tür. high diye bir seçenek yoktur. Düşünme işlevinin kendisi, varsayılan olarak açık olan enable_thinking ile açılıp kapatılır; kart ayrıca, varsayılan olarak açık olan ve önceki konuşma geçmişindeki muhakemelerin korunmasını sağlayan preserve_thinking seçeneğini de belgelemektedir. gpt-oss bunun yerine low, medium ve high kullanır. Diğer birçok aile ise sadece bir boolean değeri kabul eder ve başka bir şey almaz. Çektiğiniz tam sürüm için model kartını okuyun, çünkü bu isimler bir standart değildir. 27B modelini bir VPS üzerinde çalıştırmak ilk adımdır. Bu sayfa, model cevap vermeye başladıktan sonra nelerin ayarlanacağı hakkındadır.

Neden yüksek işlem gücü gerektiren görevler VPS üzerinde daha maliyetlidir

Çıktı tokenları. Muhakeme tokenları, üretilen tokenlardır. Bunlar, donanımınızın desteklediği saniye başına token hızıyla aynı kod çözme döngüsünden geçerler. Bir görevin 200 tokenlık bir cevap ve 4.000 tokenlık bir muhakeme süreci ürettiğini varsayalım. Toplamda 4.200 token üretmiş olursunuz ancak kullanıcı bunların yalnızca 200 tanesini görür. Kod çözme hızınız, bellek bant genişliği ve seçtiğiniz kuantizasyon tarafından belirlenir; bu nedenle elinizdeki tek değişken token sayısıdır.

Gerçek zamanlı süre. Kullanıcı, cevabın ilk tokenı için bekler; çünkü bu noktadan önceki her şey boş bir ekran veya dönen bir yükleme simgesidir. Muhakeme süreci önce yayınlandığı için bekleme süresi, kabaca muhakeme token sayısının kod çözme hızınıza bölünmesi ve buna istem işleme süresinin eklenmesiyle hesaplanır. Muhakeme uzunluğunu iki katına çıkarmak, bekleme süresini de iki katına çıkarır.

Bağlam. Muhakeme tokenları, diğer tüm tokenlar gibi bağlam penceresini işgal eder. preserve_thinking açık olduğunda, ilk adımdaki çalışma alanı beşinci adımda hala istemin içindedir; bu nedenle pencere her iki uçtan dolarken istem işleme süreci her adımda yavaşlar. num_ctx değerini bunu kapsayacak şekilde artırmak, KV önbellek belleği tüketir; GPU bulunmayan bir VPS üzerinde bu, elinizde boşta olmayabilecek sistem RAM'i anlamına gelir.

Düzeyin ne zaman yükseltileceği ve ne zaman düşük bırakılacağı

Yanlış bir ara adımın sonucu bozacağı işlerde düzeyi yükseltin: çok adımlı aritmetik ve birim dönüştürme, birden fazla dosya üzerinde düzenleme planlama, derlenmesi gereken kodlar ve bir cevabın aynı anda birkaç koşulu sağlaması gereken kısıtlı problemler. Bu durumlarda karalama defteri gerçek bir iş yapar ve daha uzun bir karalama defteri, modelin aksi takdirde yapacağı bir hatayı yakalamanın ucuz bir yoludur.

Cevap zaten girdinin içindeyse ve iş sadece onu taşımaksa düzeyi düşük bırakın. Çıkarma, sınıflandırma, etiketleme, çeviri, yeniden yazma, özetleme ve biçimlendirme işlemlerinin tümü bu kapsama girer. Akıl yürütme bölümü çoğunlukla görevi yeniden ifade eder ve modele, doğru olan ilk içgüdüsünden vazgeçmesi için alan tanır.

Etkileşimli her türlü işlem için de düzeyi düşük bırakın. Bir sohbet kutusunda veya düzenleyicide döngünün içindesinizdir; bu nedenle, düzeltebileceğiniz hızlı bir cevap, beklemek zorunda olduğunuz yavaş bir cevaptan daha iyidir. Bir kodlama aracını yerel bir modele yönlendirmenin arkasındaki gerçek ödünleşim budur: bir aracı birçok küçük çağrı yapar ve akıl yürütme maliyeti bunların her birinden tahsil edilir.

llama.cpp içinde seviye nasıl ayarlanır

llama.cpp değişkeni doğrudan şablona yazar; bu da seviyenin ulaştığından emin olabileceğiniz çalışma zamanını oluşturur. -m parametresini elinizdeki GGUF dosyasına yönlendirin.

llama-server -m ./qwen3.8-27b-Q4_K_M.gguf \
  --jinja \
  --reasoning-effort medium \
  --reasoning-format deepseek \
  -c 32768 \
  --host 127.0.0.1 --port 8080

--jinja, modelin kendi sohbet şablonunu kullanır ve güncel sürümlerde varsayılan olarak etkindir. --reasoning-effort parametresi default, minimal, low, medium, high, xhigh veya max değerlerini kabul eder; burada default, şablonun kendi varsayılan değerinin korunacağı anlamına gelir. Bu liste modelin değil, llama.cpp'nin sözlüğüdür; bu nedenle yalnızca kartın listelediği bir ismi geçirin: şablonun tanımlamadığı bir seviye, istek anında şablon hatasına neden olabilir. --reasoning-format deepseek, muhakeme sürecini message.content içinden çıkarıp message.reasoning_content içine taşır; bu ayrımı bir sonraki bölümde ölçülebilir kılan da budur.

Düşünme sürecini kısaltmak yerine tamamen kapatmak için şablon değişkenini kendiniz ayarlayın:

llama-server -m ./qwen3.8-27b-Q4_K_M.gguf --jinja \
  --chat-template-kwargs '{"enable_thinking": false}'

--reasoning-budget farklı bir mekanizmadır. Muhakeme bölümünü token bazında sınırlar; 0 bu süreci hemen sonlandırırken, -1 herhangi bir kısıtlama getirmez; bu, modele daha kısa bir plan yapmasını söylemekten farklıdır. Her iki bayrak da sunucu genelinde geçerlidir. llama-server, reasoning_effort parametresini istek bazlı bir alan olarak kabul etmez; bu nedenle aynı anda iki farklı çaba seviyesi sunmak, iki farklı port üzerinde iki ayrı süreç çalıştırmak anlamına gelir.

vLLM, aynı değişkeni OpenAI uyumlu gövde içerisinde istek bazlı olarak sunar:

{"model": "Qwen/Qwen3.8-27B",
 "messages": [{"role": "user", "content": "Summarise this changelog in two lines."}],
 "chat_template_kwargs": {"reasoning_effort": "medium"}}

Ollama üzerinde seviye ayarı nasıl yapılır

Ollama, /api/chat ve /api/generate üzerinde kendi think alanına sahiptir. Bu alan true, false veya low, medium, high ve max değerlerinden birini kabul eder; burada max, modelin sunduğu en yüksek seviyeyi talep eder. Düşünme (thinking) özelliği, destekleyen modellerde varsayılan olarak etkindir.

ollama run qwen3.8:27b --think=low "Draft a one line commit message for a README typo fix"

{"model": "qwen3.8:27b",
 "messages": [{"role": "user", "content": "Which HTTP status code means the request body was too large?"}],
 "think": "low",
 "stream": false}

Muhakeme süreci message.thinking içinde, yanıt ise message.content içinde döner ve sizin için halihazırda ayrıştırılmıştır. Etkileşimli bir ollama run oturumu içerisinde, /set think ve /set nothink komutları yeniden başlatmaya gerek kalmadan bu özelliği açıp kapatır.

Şimdi uyumsuzluğa dikkat edin. Ollama'nın sözlüğü low, medium, high ve max değerlerinden oluşur. Qwen3.8 şablonu ise low, medium ve xhigh değerlerini tanımlar. Birinin diğeriyle eşleştirilmesi gerekir ve bir Ollama modeli, orijinal depodaki Jinja dosyası yerine kendi etiketi içine paketlenmiş bir şablon taşır; bu nedenle seviyenizin modele ulaşıp ulaşmadığı, o paketlenmiş şablona bağlıdır. Çalıştığını varsaymayın. Bunu ölçmek yaklaşık bir dakika sürer.

Seviyenin gerçekten uygulanıp uygulanmadığını ölçme

Aynı istemi temperature değerini 0 yaparak birden fazla seviyede gönderin ve ardından token sayılarını karşılaştırın. Burada jq, tırnak işaretlerini manuel olarak kaçış karakteriyle belirtmenize gerek kalmaması için gövdeyi oluşturur.

for level in low medium max; do
  body=$(jq -n --arg lvl "$level" '{
    model: "qwen3.8:27b",
    messages: [{role: "user", content: "A pump fills a 4500 litre tank in 25 minutes. A second pump is 40 percent slower. How long do both together take? Answer in minutes."}],
    think: $lvl,
    stream: false,
    options: {temperature: 0, num_ctx: 8192}
  }')
  echo "== $level"
  curl -s http://localhost:11434/api/chat -d "$body" | jq '{
    thinking_chars: (.message.thinking // "" | length),
    answer_chars: (.message.content | length),
    eval_count: .eval_count,
    seconds: (.total_duration / 1e9),
    tok_per_sec: (.eval_count / (.eval_duration / 1e9))
  }'
done

eval_count, muhakeme dahil üretilen her token'dır; dolayısıyla iki seviye arasındaki fark neredeyse tamamen muhakemeden kaynaklanır. thinking_chars size ayrımı doğrudan verir. İki durumun gerçekleşmesi gerekir: sayılar seviyeler arasında değişmeli ve cevap daha düşük seviyede doğru kalmalıdır. Eğer eval_count üç çalıştırma boyunca gürültü seviyesinde kalıyorsa, seviye göz ardı ediliyor demektir; bu durumda çözüm, farklı bir seviye adı kullanmak yerine bunu ileten bir çalışma zamanı (runtime) kullanmaktır.

Toplam süre hikayenin yalnızca yarısıdır; bu nedenle akışı başlatıp ilk boş olmayan content parçasında durarak ilk cevap token'ına kadar geçen süreyi ölçün. Bu işlem için jq ve bc gereklidir.

start=$(date +%s.%N)
curl -sN http://localhost:11434/api/chat -d '{
  "model": "qwen3.8:27b",
  "messages": [{"role": "user", "content": "Explain what a reverse proxy does, in three sentences."}],
  "think": "low",
  "stream": true
}' |
while IFS= read -r line; do
  if [ -n "$(printf '%s' "$line" | jq -r '.message.content // ""')" ]; then
    echo "first answer token after $(echo "$(date +%s.%N) - $start" | bc)s"
    break
  fi
done

İşlemi low ve tekrar max seviyelerinde çalıştırın. Aradaki fark, satın aldığınız bekleme süresidir. llama.cpp üzerinde aynı sayılar yanıtın içinde geri döner, bu sayede shell aritmetiğine gerek kalmaz:

curl -s http://localhost:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model": "local", "temperature": 0,
       "messages": [{"role": "user", "content": "A pump fills a 4500 litre tank in 25 minutes. A second pump is 40 percent slower. How long do both together take?"}]}' | jq '{
  reasoning_chars: (.choices[0].message.reasoning_content // "" | length),
  answer_chars: (.choices[0].message.content | length),
  predicted_n: .timings.predicted_n,
  tok_per_sec: .timings.predicted_per_second
}'

Bunu kendi sunucunuzda gerçekleştirin. Yayınlanmış bir efor karşılaması size ait olmayan donanımlar üzerinde ölçülmüştür; token sayısını saniyeye dönüştüren terim, sizin decode hızınızdır. Kendi sunucunuzda saniye başına token ölçümü size bu terimi sağlar: muhakeme token'larının decode hızınıza bölümü, yeni eklediğiniz bekleme süresidir.

Hatalar ve çözüm yolları

Cevap kesiliyor veya content boşken thinking dolu görünüyor. Üretim sınırı, akıl yürütme süreci tarafından tüketilmiş durumdadır. Ollama'nın num_predict parametresi, akıl yürütme dahil olmak üzere toplam üretim miktarını sınırlar. Akıl yürütme süreci öncelikli olduğundan, yüksek çaba seviyesinde 512 tokenlık bir sınır, cevap henüz başlamadan yanıtın sonlanmasına neden olabilir. Ollama bu durumda "done_reason": "length" hatası döndürür. Sınırı yükseltin veya çaba seviyesini düşürün. num_predict token sayısını nasıl hesaplar başlıklı bölüm, bu etkileşimi ayrıntılı olarak açıklar.

Seviye değişikliği hiçbir şeyi değiştirmiyor. Token sayıları her seviyede aynı kalıyor. Çalışma zamanı (runtime) değişkeni iletmiyor olabilir veya şablon bu değişkeni okumuyordur. Orijinal depodaki şablon yerine, çalışma zamanınızın fiilen kullandığı şablonu kontrol edin. --jinja ve --chat-template-kwargs kullanan llama.cpp, değişkeni manuel olarak yazdığı için iyi bir kontrol noktasıdır: Eğer seviye ayarı orada çalışıyor ancak başka hiçbir yerde çalışmıyorsa, model düzgündür ve diğer çalışma zamanı değişkeni göz ardı ediyordur.

Bir seviye ismi reddediliyor. İstek anında alınan bir şablon hatası veya sağlıklı bir sunucuda ilk mesajda alınan bir hata, genellikle şablonda tanımlanmamış bir seviye gönderdiğiniz anlamına gelir; örneğin, kartında yalnızca low, medium ve xhigh değerleri bulunan bir modele high göndermek gibi.

Çok turlu sohbetler her turda yavaşlıyor. Eski akıl yürütme verileri geçmişte tutuluyor. Model destekliyorsa preserve_thinking değerini false olarak ayarlayın veya geri gönderdiğiniz mesajlardan thinking alanını temizleyin. Aksi takdirde, cevaplar aynı uzunlukta kalsa bile her turda istem işleme süresi artacaktır.

Basit olduğunu düşündüğünüz bir görevde düşük çaba seviyesinde kalite düşüyor. Bazı ayıklama işlemleri aslında ayıklama değildir. Eğer girdi bir birim dönüşümü veya belirli bir kuralın sırayla uygulanmasını gerektiriyorsa, bu kısa çıktılı bir akıl yürütme görevidir. Bu tür çağrılar için tüm sunucunun ayarını değiştirmek yerine, sadece ilgili çağrı için seviyeyi yükseltin.

Aynı anda iki seviyeyi çalıştırma

llama.cpp, seviyeyi başlangıçta sabitler. Bu nedenle hem bir düzenleyiciye hem de gece çalışan bir toplu işe hizmet veren bir sunucu, her biri kendi --reasoning-effort değerine sahip iki ayrı port üzerinde iki süreç gerektirir. İki süreç, işleri zaman içinde ayırmadığınız sürece ağırlıkların bellekte iki kopyasının tutulması anlamına gelir. Tek bir VPS üzerinde daha ekonomik olan yöntem, genellikle kullanıcının beklediği işlemler için düşük eforlu bir sunucu çalıştırmak ve kimsenin izlemediği işler için zamanlanmış, daha yüksek eforlu bir çalıştırma yapmaktır. Birden fazla kullanıcı aynı yerel modeli paylaştığında ne olur konusu burada da geçerlidir: muhakeme token'ları kod çözme işidir; bu nedenle eforu artırmak, efektif eşzamanlılığınızı, token sayısını artırdığınız oranda düşürür.

FAQ

Varsayılan olarak hangi mantıksal yürütme (reasoning) seviyesini kullanmalıyım?

Modelin sunduğu en düşük seviyeden başlayın ve yalnızca başarısız olduğunu gözlemlediğiniz görevler için seviyeyi yükseltin. Birçok düşünme modeli yüksek bir varsayılan değerle gelir; Qwen3.8-27B ise Ağustos 2026 itibarıyla en üst seviyesi olan xhigh değerini varsayılan olarak kullanır. Bu varsayılan değer, kıyaslama (benchmark) tablolarında iyi görünmesi için seçilmiştir; ancak kıyaslama tabloları süre bazlı bir maliyet çıkarmaz. Kendi donanımınızda ise zaman maliyetine katlanırsınız; bu nedenle yüksek seviyeyi her istekte miras alınan bir ayar yerine, görev bazlı tercih edilen bir seçenek haline getirin.

Mantıksal yürütme (reasoning) token'ları bağlam penceresinden (context window) düşülür mü?

Evet. Bunlar çıktıdaki sıradan token'lardır ve diğer her şeyle birlikte bağlam penceresinde yer alırlar. Bir sonraki aşamada orada kalıp kalmayacakları, çalışma zamanına (runtime) ve modele bağlıdır. Qwen3.8'in kartı, varsayılan olarak açık olan preserve_thinking özelliğini belgeler; bu özellik önceki mantıksal yürütme süreçlerini geçmişte tutar, dolayısıyla uzun bir konuşma ürettiği her karalama defterini (scratchpad) beraberinde taşır. Bunu false olarak ayarlayın veya yeniden oynattığınız mesajlardan thinking alanını çıkarın; böylece istem işleme süreci büyümemeye başlar.

Düşünme seviyesini değiştirmek neden token sayılarımda bir fark yaratmıyor?

Ayar, sohbet şablonuna ulaşmıyor. Seviye bir şablon değişkenidir; bu nedenle yalnızca çalışma zamanı bunu iletir ve paketlenmiş şablon bunu okursa çalışır. Bazı çalışma zamanları, orijinal depodaki Jinja dosyası yerine modelle birlikte kendi şablonlarını sunar ve bu durumda değişken, herhangi bir hata mesajı üretilmeksizin devre dışı bırakılır. Bunu doğrulamak için, temperature değerini 0 yaparak aynı istemi en düşük ve en yüksek seviyede gönderin ve eval_count değerlerini karşılaştırın. Eğer sayılar hata payı içinde eşleşiyorsa, seviye ayarı göz ardı ediliyor demektir.

Daha düşük mantıksal yürütme seviyesi modeli daha az doğru kılar mı?

Bu göreve bağlıdır ve varsayımda bulunmak yerine ölçüm yapmak daha sağlıklıdır. Yanıtın veri çıkarma veya yeniden yazma gibi işlemlerde olduğu gibi girdide zaten mevcut olduğu durumlarda, daha kısa bir karalama defteri genellikle hiçbir şeyi değiştirmez. Çok adımlı aritmetik veya derlenmesi gereken kod gibi, nihai adımdan önce ara bir adımın doğru olması gereken durumlarda ise daha kısa bir karalama defteri ile doğruluk oranı düşer. Gerçek iş yükünüzden yirmi istemlik bir set oluşturun, bunları temperature değeri 0 olacak şekilde iki farklı seviyede çalıştırın ve yanlış yanıtları sayın. Bu sayı iş yükünüze özeldir ve hiçbir yayınlanmış tablo size bunu veremez.