
2020’lerin başında derin öğrenme topluluğunun paylaştığı temel varsayım şuydu: modeli büyüt, veriyi artır, hesaplama bütçesini genişlet. GPT-2’den GPT-4’e uzanan yolda parametre sayısı binlerce kat arttı ve kıyaslama skorları buna paralel yükseldi. Bu yaklaşım bir süre işe yaradı; ama trilyon parametreli modellerin hem eğitilmesi hem çalıştırılması için gereken altyapı, kaynakları yalnızca birkaç kuruluşun erişebildiği seviyelere taşıdı.
2024 sonunda OpenAI’nin o1 modelini piyasaya sürmesi bu denklemi farklı bir açıdan sorgulatmaya başladı. o1, GPT-4 Turbo’dan daha küçük bir temele dayanmasına karşın matematik olimpiyatı problemlerinde ve bilimsel akıl yürütme kıyaslamalarında çok daha yüksek skorlar elde etti. Fark model büyüklüğünde değildi; modelin yanıt üretirken harcadığı hesaplama miktarındaydı. Bu mekanizmanın adı test-time compute, Türkçesiyle çıkarım zamanı ölçeklendirme.
Test-Time Compute Nedir?
Bir yapay zeka modelinin yaşam döngüsü iki ayrı aşamadan oluşur: eğitim (training) ve çıkarım (inference). Eğitim aşamasında model, milyarlarca veri örneğini görerek ağırlıklarını günceller; bu süreç haftalarca, hatta aylarca sürebilir ve büyük GPU kümeleri gerektirir. Çıkarım aşamasında ise model “donmuş” ağırlıklarla sorulara yanıt üretir.
Geleneksel train-time scaling yaklaşımı şunu söyler: eğitim sırasında ne kadar çok hesaplama harcarsanız, o kadar iyi bir model elde edersiniz. Çıkarım sırasındaki hesaplama bütçesi sabit tutulur. Test-time compute bu denklemi kısmen tersine çevirir: ağırlıklar sabittir, ancak yanıt üretirken harcanan hesaplama miktarı değişkendir.
Matematiksel sezgiyi şöyle kurmak mümkün: sabit bir model verildiğinde, doğru cevabı verme olasılığı o soruya harcanan hesaplama bütçesiyle artar. Bunu P(doğru | hesaplama bütçesi) eğrisi olarak düşünebilirsiniz. N farklı yanıt üretin ve en iyisini seçin ya da yanıt üretim sürecine daha fazla adım koyun; her iki yolda da bu eğri yukarı kayar.
Bu fikrin teorik zemini yeni değil; ama o1’in 2024’te piyasaya çıkmasıyla birlikte verimli uygulamalarının mümkün olduğu pratikte kanıtlandı ve her büyük laboratuvar benzer mekanizmaları benimsemeye başladı.
Nasıl Çalışır: Temel Teknikler
Test-time compute’u hayata geçiren birkaç farklı yöntem ailesi var. Bu yöntemler birbirini dışlamaz; üretimdeki sistemler genellikle bunları katmanlı biçimde kullanır.
Best-of-N Örnekleme
En anlaşılır yöntem budur: modeli aynı soruya N kez yanıt üretecek şekilde çalıştırın, ardından elde ettiğiniz N yanıttan en iyisini seçin. “En iyi” nasıl belirlenir? Küçük bir doğrulama modeli (verifier) her yanıtı değerlendirir ve en yüksek puanlıyı döndürür.
Bir matematik problemini düşünün: 10 farklı çözüm yolu deneyin, yalnızca adım adım doğrulanabilir olanı döndürün. Hata oranı düşer. Bu yöntemin zayıf noktası maliyettir: N=10 demek, 10 kat daha fazla token ve süre demektir.
Işın Arama ve Ağaç Arama
Best-of-N tamamen paralel çalışır: tüm N yol bağımsız olarak tamamlanır. Işın araması daha ekonomik bir alternatif sunar: her adımda birkaç “aday yol” paralel yürütülür, düşük puanlı olanlar erken elenir ve yalnızca umut vadeden yollar devam eder.
Ağaç arama, Tree of Thoughts modelini temel alır. Yanıt üretimi bir ağaç yapısı olarak modellenir; her düğüm kısmi bir düşünce adımını temsil eder. Verifier her düğümü puanlar, umut vadeden dallar genişletilir, düşük puanlılar budanır. Bu yaklaşım çok adımlı ispat ve planlama görevlerinde özellikle etkilidir.
Zincirleme Akıl Yürütme (Sequential CoT)
OpenAI o1 ve o3’ün temel mekanizması budur. Model, son yanıtı üretmeden önce bir dizi “düşünce adımı” üretir. Bu adımlar kullanıcıya gösterilmeyebilir (gizli CoT / thinking blokları), ancak token bütçesi bunlara harcanır.
Chain-of-Thought prompting, bu tekniğin kullanıcı tarafından tetiklenen versiyonuydu: “adım adım düşün” talimatı verirdiniz. Test-time compute ise bu süreci otomatik ve bütçeli hâle getirir: modele belirli bir soruya kaç token kadar düşünce harcaması gerektiği söylenebilir ya da model bunu kendisi belirler.
Öz-Revizyon ve Eleştiri Döngüsü
Model yanıtını ürettikten sonra aynı model ya da ayrı bir “eleştirmen” model bu yanıtı değerlendirir. Zayıf nokta ya da hata bulunursa model yanıtı gözden geçirir. Bu döngü birkaç kez tekrarlanabilir.
Kod üretiminde bu teknik özellikle güçlüdür: önce bir çözüm yaz, kendi test senaryolarınla kontrol et, hatayı bul ve düzelt. Dışarıdan etiket almak gerekmez.
Doğrulayıcılar ve Ödül Modelleri
Yukarıdaki tüm tekniklerin merkezinde tek bir soru yatar: “Bu ara adım ya da bu yanıt doğru mu?” Bu soruyu yanıtlayan bileşenler verifier ve reward model olarak adlandırılır.
İki ana tür mevcuttur. Outcome Reward Model (ORM) yalnızca nihai yanıtı değerlendirir; “bu cevap doğru mu?” sorusuna yanıt arar. Eğitimi görece kolaydır çünkü yalnızca son çıktıya etiket gerekmektedir. Ama ara adımları görmezden geldiğinden, yanlış muhakemeyle ulaşılan doğru sonuçları ödüllendirebilir.
Process Reward Model (PRM) ise her ara adımı ayrı ayrı değerlendirir. “Bu düşünce adımı mantıklı ve geçerli mi?” sorusunu sorar. Adım bazlı akıl yürütme için tasarlanmış bu yaklaşım, hatalı adımın tam olarak nerede başladığını yakalayabilir.
Üretim sistemleri genellikle her iki modeli birlikte kullanır: PRM arama sırasında adımları filtreler, ORM nihai yanıt seçiminde devreye girer.
Hangi Modeller Kullanıyor?
Test-time compute artık yüksek performanslı akıl yürütme modellerinin standart bir özelliğidir.
OpenAI o1 ve o3: Bu tekniğin piyasadaki en dikkat çekici kanıtlarından biri oldular. o1 matematik olimpiyatı problemlerinde GPT-4’ü belirgin biçimde geride bıraktı; o3 ise ARC-AGI kıyaslamasında insan seviyesine yakın bir performans gösterdi. Her ikisi de gizli CoT kullanır: yanıt üretilmeden önce yüzlerce ya da binlerce token’lık bir “düşünce” süreci yürütülür ve kullanıcıya yalnızca son çıktı sunulur.
DeepSeek R1: Açık kaynaklı bu model, test-time compute’u RLVR (Reinforcement Learning via Verifiable Rewards) yaklaşımıyla birleştirir. Model kendi ürettiği doğru çözümlerden pekiştirmeli öğrenmeyle güçlenir. Akıl yürüten modellerin karşılaştırması için bu konuya ayrılmış yazıya bakabilirsiniz.
Gemini 2.0 Flash Thinking: Google’ın bu modeli “thinking” modunu doğrudan kullanıcıya açıyor; yanıt üretirken harcanan hesaplama miktarı ayarlanabilir.
Claude 3.7 Sonnet (Extended Thinking): Anthropic’in extended thinking özelliği de aynı prensibi uygular: model daha uzun düşünce zincirleri oluşturmak için ek token bütçesi kullanır ve bu bütçe isteğe göre artırılabilir.
Trade-off’lar: Güç, Hız ve Maliyet
Test-time compute performansı artırır; bedelini de token ve gecikme olarak ödersiniz.
Yanıt süresi tarafında, Best-of-N veya beam search kullanıyorsanız yanıt süresi N katına çıkabilir. Gerçek zamanlı bir sohbet botunda kullanıcı bu gecikmeyi fark eder. Arka planda çalışan bir kod doğrulama sistemi ya da uzun vadeli bir planlama aracı için bu gecikme kabul edilebilir.
Maliyet tarafında, thinking modları standart modlara kıyasla 5-10 kat daha fazla token tüketir ve bu doğrudan faturaya yansır.
Ne zaman kullanmalı? Sorun ne kadar karmaşık ve doğrulanabilirse kazanım o kadar belirgin olur. Basit bir bilgi sorusu için gizli CoT gereksizdir ve büyük olasılıkla zaten aktif olmaz. Çok adımlı matematiksel ispat, uzun kod tabanında hata ayıklama ya da agentic planlama görevlerinde fark açılır.
Compute-optimal denge kavramı burada kritiktir: belirli bir hesaplama bütçesinin ötesinde her ek token’ın marjinal faydası azalır, maliyet ise doğrusal olarak artmaya devam eder. Bu eşiği tahmin etmek uygulamalı sistemlerde aktif bir araştırma konusudur.
Eğitim Zamanıyla İlişki: Kapalı Bir Döngü
Test-time compute ile train-time scaling birbirinden bağımsız değildir; ikisi arasında bir geri besleme döngüsü kurulabilir.
Süreç şöyle ilerler: model test sırasında birden fazla çözüm yolu dener. Bu yollardan bazıları doğru sonuca ulaşır. Başarılı yollar yeni fine-tuning verisi olarak kullanılabilir. Model bir sonraki eğitim döngüsünde bu veriyle güçlenir ve bir sonraki test-time compute oturumunda daha kaliteli başlangıç noktalarına sahip olur.
Bu fikrin öncülü STaR (Self-Taught Reasoner) algoritmasıdır: model kendi çözümlerinden öğrenir, doğru olanları eğitim setine ekler, yanlış olanları atar. Böylece dışarıdan insan etiketi almak gerekmeden kendi kendine gelişir.
DeepSeek R1’in RLVR yaklaşımı benzer bir döngü kurar; fark şudur: RLHF bileşeninin yerini doğrulanabilir ödüller (matematik sonuçları, kod test çıktıları) alır. İnsan değerlendirmesi gerektirmeyen bu ödüller, döngünün çok daha hızlı ve ölçeklenebilir çalışmasını mümkün kılar.
Sınırlamalar ve Açık Sorunlar
Test-time compute güçlü bir yaklaşımdır; ancak sınırlarını görmezden gelmek yanıltıcı olur.
Halüsinasyon hâlâ mümkün: Verifier’lar mükemmel değildir. Hatalı adımları doğru olarak puanlayan bir PRM, modeli yanlış bir yolda derinleştirilebilir. Daha fazla hesaplama harcamak, daha fazla güven garantisi vermez; tersine, yanlış bir arama ağacında derinleşmek yanlış sonuca olan bağlılığı artırabilir.
Token bütçesi ve maliyet baskısı: Özellikle uzun bağlamlı LLM kullanım senaryolarında test-time compute’un maliyeti katlanır. Milyonlarca token içeren bir bağlamı, milyonlarca token’lık düşünce zinciriyle işlemek şu an pratik değildir.
Görev türü bağımlılığı: Bu teknik, doğrulaması kolay görevlerde işe yarar: matematik, kod üretimi, mantık bulmacaları. Yaratıcı yazarlık ya da açık uçlu tartışma sorularında “doğru cevap” belirsizdir ve güvenilir bir verifier eğitmek zorlaşır.
Retrieval ile hibrit yaklaşımlar: Akademik çevrelerde en aktif tartışmalardan biri, test-time compute ile RAG sistemlerinin nasıl bütünleştirileceği üzerine. Model hem dış bir bilgi kaynağından veri çekecek hem de bu veriyi çok adımlı akıl yürütmeyle işleyecek; iki katman da hesaplama talep ettiğinden dengeleme sorunu ortaya çıkmaktadır.
Ölçeklemenin Yeni Boyutu
Scaling law tartışmaları uzun süre tek bir eksen üzerinde yürütüldü: model büyüklüğü. Test-time compute bu tartışmaya ikinci bir eksen ekledi: çıkarım sırasındaki hesaplama derinliği.
Bu ikinci eksenin en önemli pratik sonucu, aynı ağırlık setine sahip bir modelin farklı hesaplama bütçeleriyle farklı performans düzeylerinde çalıştırılabilmesidir. Hız gerektiren görevler için kısa düşünce zinciri, doğruluk gerektiren görevler için derin arama kullanılabilir. Tek model, duruma göre ayarlanabilir yetenek sunar.
Bu esnekliği hayata geçiren bir teknik “budget forcing” (bütçe zorlama) olarak adlandırılır: modele yanıt üretmeden önce harcayabileceği maksimum düşünce token sayısı söylenir. Bütçe düşük tutulursa model hızlı ve yüzeysel akıl yürütür; bütçe artırılırsa model geri adım atıp alternatif yolları da keşfeder. OpenAI API’sinde max_completion_tokens ve Anthropic’in extended thinking parametresindeki budget_tokens bu mekanizmanın kullanıcıya açılan arayüzleridir.
Laboratuvarlar şu an iki ayrı cephede ilerleniyor: verifier modellerini ucuzlatmak ve retrieval ile hibrit mimariler kurmak. PRM eğitim maliyeti düştükçe test-time compute daha geniş görev türlerine yayılabilir; RAG ile birleştiğinde ise güncel dış bilgiyi derin çok adımlı akıl yürütmeyle aynı sistemde toplayabiliriz. Ağırlıkları güncellemeden önce daha uzun düşünmek her geçen ay biraz daha erişilebilir hâle geliyor.



