Yöntem

İlkeler

• Kim yapıyor. Test yapısını ve yöntemi ben kurdum. Testleri ajanım koşuyor, puanlayıcının ceza verdiği her cevabı tek tek okuyup hatalarını düzeltiyor. Hiçbir sayfa ben okuyup onaylamadan yayımlanmıyor.
• Bir seferde tek değişken. Ekran kartlarını karşılaştırırken model dosyası ve motor sürümü birebir aynıdır (hash’ler doğrulanır). Modelleri karşılaştırırken prompt’lar, örnekleme ayarları, araçlar ve beklenen cevaplar birebir aynıdır.
• Sırayla, karışık değil. Büyük modeller VRAM’e birlikte sığmaz; karışık koşmak her soruda onlarca gigabaytı yeniden yüklemek, yani çıkarım yerine disk hızını ölçmek olurdu.
• Tekrar. Kalite testleri her prompt’u modelin önerdiği sıcaklıkta (genelde 1) 2–3 kez koşar. Sıcaklık 1’de tek bir koşu sonucu tersine çevirebilir — bunu yaşadım.
• Kontrol edilen puanlama. Otomatik puanlayıcılar hızlıdır ve öngörülebilir biçimde yanılır. Bu sitedeki her puan gerçek cevaplarla karşılaştırıldı; düzeltmeler test sayfasında yazıyor.
• Düzeltmeler görünür kalır. Yayımlanmış bir rakam yanlış çıktığında (örneğin tek bir soğuk istek Ollama’nın hızını %40 düşük gösterdiğinde) sayfa bunu sessizce değiştirmek yerine açıkça yazar.
• Sıralama tablolarından çok gerçek iş. Bu model boyutunda herkese açık benchmark’lar çabuk doyuyor; en belirleyici testim homelab’imin gerçekten dayandığı bir iş.

Hız

Ölçü	Nedir	Nasıl
Üretim (decode)	ilk token’dan sonra saniyede üretilen token	motorun kendi sayaçları (Ollama’da eval_count/eval_duration, diğerlerinde sunucu zamanlamaları); asla duvar saati ÷ token değil
Prefill / prompt okuma	ilk çıktı token’ından önce saniyede işlenen prompt token’ı	aynı sayaçlar, uzunluğu bilinen sabit prompt’larla (1K, 7,5K, 8K, 20K, 31K, 168K token’a kadar)
Cevap başına saniye	kullanıcının uçtan uca beklediği süre	istemci tarafında ölçülür

Üretim çoğunlukla bellek bant genişliğine, prefill ise hesaba bağlıdır; kuantizasyonun ve ekran kartı seçiminin ikisini farklı etkilemesinin nedeni bu. Spekülatif çözmede üretim hızı içeriğe çok bağlıdır (kod, düz metinden çok daha fazla taslak token kabul eder); bu yüzden önemli olduğu yerde prompt başına rakam veriyorum.

Thinkbench

Günlük kullanıma benzeyen beş prompt: iki kod görevi (bir Python fonksiyonu, bir bash yedek betiği), bir Türkçe bilgi sorusu, bir Türkçe yaratıcı yazı görevi ve kısa bir mantık bulmacası. Her biri düşünme açık, modelin örnekleme ayarlarıyla (sıcaklık 1, top_p 0,95, top_k 20, min_p 0) 3 kez koşar; sınır 4.096 token. Toplam token, düşünme token’ı, cevap başına saniye ve saniyede token kaydedilir.

Bir modelin sıradan isteklerde ne kadar konuştuğunu ve düşündüğünü ölçer — doğruluğu değil.

Hardbench

Doğrulanmış tam sayı cevaplı on AIME tipi problem, her biri 2 kez, 32.768 token sınırı. Cevaplar betikle kontrol edilir. Kontrolden çıkan düşünmeyi (sınıra dayanan koşular) ve kaba doğruluk farklarını yakalar. Bu model boyutunda neredeyse doymuş durumda — çoğu model 20’de 19–20 yapıyor — bu yüzden iyi modelleri nadiren ayırır.

CVE değerlendirmesi

Model seçimlerinin çoğunu belirleyen test. Homelab’imde bir modeli güvenlik işinde gerçekte nasıl kullandığımı yeniden üretir.

Kurulum. Türkçe sorulan 15 soru, her biri 3 kez, araç kullanımı açık olarak calivi (açık kaynak bir sohbet arayüzü) üzerinden cevaplanır. Araçlar NVD, FIRST EPSS, CISA KEV, OSV ve paket kayıtlarını sorgulayan bir CVE triyaj MCP sunucusundan ve web aramasından gelir. Her model aynı sistem prompt’unu alır: kullanıcının dilinde cevap ver, CVE kimliklerini, sürümleri ve puanları yalnız araç çıktısından al, hiçbir aracın döndürmediği bir CVE kimliğini asla yazma, sonunda makinece okunur sabit bir özet bloğu ver.

Soru türleri.

• Yükseltme önerisi (8 soru, 24 cevap): “X’in Y sürümünü kullanıyoruz, neye yükseltelim?” — Log4j, Spring4Shell, Jackson, Django, Express, lodash, jinja2 ve diğerleri. Doğru cevap, sorulan CVE’yi kapatan ilk sürüm değil, bilinen açığı olmayan en yeni sürümdür.
• Triyaj: bilinen bir CVE (ör. Log4Shell, MOVEit, xz, OpenSSL) — önem, istismar durumu, düzeltildiği sürümler.
• KEV durumu (6 kontrol) ve son KEV eklemeleri (zaman pencereli bir liste).
• Önceliklendirme: bir CVE kümesini gerçek riske göre sırala.
• Var olmayan bir CVE: model ayrıntı uydurmak yerine böyle bir kaydın olmadığını söylemeli.

Doğru cevaplar. Beklenen cevaplar aynı herkese açık kaynaklardan bağımsız olarak üretilir ve her koşudan önce dondurulur (zamana bağlı sorular her koşunun kendi UTC başlangıcına göre puanlanır). Aynı sayfada karşılaştırılan modeller aynı doğru-cevap setini paylaşır.

Neler puanlanır. Önerilen sürümün en yeni temiz sürüm olması; düzeltme sürümlerinin doğru / yanlış / belirtilmemiş olması; KEV durumu; önceliklendirme; var olmayan CVE’nin ele alınışı. Her soru 0–1 arası puan alır, genel puan ortalamadır. Yanında kaydedilen ama puana girmeyenler: uydurma CVE kimlikleri (NVD’de hiç yok), hafızadan yazılan CVE’ler (gerçek, ama hiçbir araç sonucunda yok — dayanak hatası), yanlış dilde cevaplar, araç hataları, araç çağrısı sayısı ve cevap başına saniye.

Cevap kontrolü. Puanlayıcının ceza verdiği her cevap okunur. Puanlayıcı hataları düzeltilip test sayfasında listelenir; gerçek hatalar korunur ve anlatılır.

Güç

Priz gücü, bütün sunucuya takılı bir priz tipi wattmetreden aralık olarak okunur. Ekran kartının gücü, saat hızları ve sıcaklığı nvidia-smi ya da rocm-smi/sysfs’ten gelir. Token başına enerji = priz gücü ÷ üretim hızı.

Neyi yayımlıyorum, neyi yayımlamıyorum

Her sayfada tarih, donanım, motor ve sürümü, model dosyaları (kaynaklarıyla) ve ayarlar yazar. Altyapımın iç makine adları, adresleri ve ham logları yayımlanmaz; donanım bunların yerine konfigürasyonuyla anılır.