Geçen hafta ofiste, 2025 Mart’ının o klasik “bir bakalım bu model ne kadar hızlı” moduna girdim (buna dikkat edin). Elimde birkaç cloud AI modeli vardı. Önümde kahve. Ve biraz fazla beklenti, açıkçası. Hani şu “parametre sayısı büyükse iş çözülür” refleksi vardır ya — ben de tam oradaydım, o psikolojide. Sonra sonuçlar ekrana düştü ve tablo beni gerçekten ters köşe yaptı; beklediğimin tam tersi çıktı.
İşin aslı şu: yapay zekâ tarafında artık sadece “hangi model daha akıllı” diye bakmak yetmiyor. Hız var, tutarlılık var, JSON düzgünlüğü var, araç çağırma becerisi var — bunların hepsi aynı sepette duruyor. Sepetin sapı kırılgan olunca, en pahalı modeli seçmek bazen sadece daha uzun beklemek anlamına geliyor. Bu kadar.
Asıl mesele: Büyük model her zaman iyi model değil
Bunu yazarken 2024 sonbaharında bir kurumsal projede yaşadığım sahne aklıma geldi. İstanbul’da bir finans ekibi için ajan akışı kuruyorduk; ekip “en güçlü modeli koyalım bitsin” diyordu, kağıt üstünde mantıklıydı. Pratikte ise her istek 20 saniyeyi aşıyor, kullanıcı ekran başında ufak ufak sinirleniyordu. Sinirleniyordu da haklıydı. O gün anladım: LLM seçimi biraz araba seçmeye benziyor — motor gücü önemli. Şehir içinde sürekli trafikteyseniz başka şeyler de devreye giriyor işte.
Bu benchmark’ın en çarpıcı yani tam burada ortaya çıkıyor. 397B sınıfındaki dev modelin bazı görevlerde bekleneni verememesi bir skandal değil aslında; daha çok “model boyu = kalite” ezberinin çatlaması bu. Çünkü gerçek dünyada yalnızca cevap doğru mu diye bakmıyoruz — cevabın kaç saniyede geldiği, formatın bozulup bozulmadığı, araç zincirine uygun olup olmadığı da kritik, hepsini birlikte düşünmek gerekiyor (en azından benim deneyimim böyle)
Kurumsal kullanımda hız çoğu zaman lüks değil ihtiyaç oluyor. Müşteri destek ajanı düşünün: 22 saniye bekleyen kullanıcıyla 1.6 saniyede dönen kullanıcı arasındaki fark muazzam. Birinde sohbet akıyor, diğerinde ekran donmuş gibi hissediliyor… ve kullanıcı bunu unutmuyor.
Büyük model bazen gerçekten iyi iş çıkarıyor ama hız düşerse bütün deneyim çökmeye başlıyor. Hele bir de ajan tabanlı yapılarda “iyi ama ağır” modeller çoğu zaman pahalı bir konfor haline geliyor.
Benchmark neye baktı, biz neden önemsemeliyiz?
Bu testte üç basit ama çok öğretici görev var: temel matematik, kısa kod üretimi ve mantık sorusu. Dışarıdan bakınca kolay görünüyor — hani lise matematiği gibi duruyor (ki bu çoğu kişinin gözünden kaçıyor). Ama tam da bu yüzden güzel bir ölçüm sunuyor, çünkü modellerin gereksiz süslemeler yapmadan direkt cevap vermesi bekleniyor. Süsleme yok, palavra yok, sadece iş.
İlginç olan şu ki, Ben kendi tarafımda benzer testleri ilk kez 2023’te Kadıköy’de küçük bir SaaS ekibiyle yapmıştım. Amaç LLM’in uzun roman yazması değildi; tek satırlık JSON döndürmesi gerekiyordu, o kadar. Şaşırtıcı biçimde en parlak görünen model değil, en disiplinli model kazandı o gün (buna dikkat edin). Burada da aynı hikâye var gibi duruyor — nasıl desem, tarih tekerrür ediyor işte.
Ve işler burada ilginçleşiyor.
Garip gelecek ama, Aşağıdaki küçük özet tabloya bakınca resim netleşiyor: Daha fazla bilgi için AI ile Katalog Kaosunu Düzenli Veriye Çevirmek: Perde Arkası yazımıza bakabilirsiniz. Bu konuyla ilgili SpaceX Heyecanı Bitget’te: IPO Öncesi Yeni Yol yazımıza da göz atmanızı tavsiye ederim.
| Model | Ortalama Süre | Kısa Not |
|---|---|---|
| nemotron-3-super:cloud | 1.63s | En hızlı ve tutarlı |
| qwen3-coder-next:cloud | 2.14s | Kod ve tool calling tarafında güçlü |
| gemma3:27b-cloud | 2.95s | Dengeli ve pratik |
| qwen3.5:397b-cloud | 22.39s | Büyük ama ağır kaldı |
Neyse uzatmayalım; bu tablodaki asıl mesaj şu: benchmark sadece hız yarışı değil, davranış testi de yapıyor gibi düşünün. Kim daha çabuk su kaynatıyor değil — kim tencereyi taşırmadan işi bitiriyor, onu ölçüyor yani.
Araç çağırma, JSON ve kod üretimi neden bu kadar önemli?
Ajan kurarken format bozulursa oyun biter
Açık konuşayım: ajan sistemlerinde düz metin cevabı çoğu zaman yetmiyor. Yetmiyor, nokta. Bir modele görev veriyorsunuz; o size yarım yamalak bir açıklama dönduruyor ama uygulama tarafı saf JSON bekliyor… İşte orada her şey dağılıyor, bütün pipeline çöküyor.
Editör masasında bunu ilk kez Ankara’daki bir fintech demosunda gördüm — tarih olarak da net söyleyeyim, 12 Şubat 2025’ti. Model harika konuşuyordu, gayet akıcıydı,. Tek bir eksik virgül yüzünden pipeline takıldı kaldı (evet, bazen bütün sistem minicik bir karaktere yeniliyor; şaşırtıcı ama gerçek). Bu yüzden tool calling başarısı benim gözümde sadece teknik özellik değil, doğrudan ürün güvenilirliği meselesi.
Kod üretimi ise ayrı dert
Vallahi, Hmm, nereden başlasam… Kod yazdırırken sadece “çalıştı mı?” demek yetmez. Type hint var mı? Docstring düzgün mü? Kenar durumları düşünülmüş mü? Mesela basit görünen tek satırlık filtreleme işlemleri bile bazı modellerde gereksiz karmaşaya dönüşebiliyor — bir bakıyorsunuz otuz satır gelmiş, kafanız karışıyor. Bu konuyla ilgili Butterfly CSS: 2026’da Dikkat Çeken Hafif Bir Seçenek yazımıza da göz atmanızı tavsiye ederim.
Bence dikkat çekici nokta şu: qwen3-coder-next hızlı olmasına rağmen her zaman tutarlı değilken, nemotron-3-super daha dengeli davranmış görünüyor testlerde. Biri sprint koşucusu gibi çıkıyor ortaya… diğeri maratoncu gibi stabil kalıyor. İkisi de lazım bazen, ama hangisi lazım olduğunu bilmek gerekiyor. Daha fazla bilgi için PDF Dünyasında Bir Nefes: Ücretsiz ve Limitsiz Araçlar yazımıza bakabilirsiniz.
Peki hangi senaryoda hangi model mantıklı?
Araya gireyim: Küçük bir startup için öncelik genelde hız ve maliyet oluyor. Günde binlerce çağrı atıyorsanız ekstra on saniye bile fatura tarafında can sıkabiliyor — hem kullanıcı deneyimini bozuyor hem de altyapıyı şişiriyor, ikisi birden. Bu konuyla ilgili Amazon Luna’nın sadeleşmesi: Oyunların bir kısmı sessizce gidiyor yazımıza da göz atmanızı tavsiye ederim.
İşin garibi, Enterprise tarafta resim biraz değişiyor tabii, ama büyük ölçüde tersine de dönmüyor. İşler büyüyünce gözünüzü kapatıp “en büyük modeli alalım” demek riskli çünkü operasyonel yük artıyor, hata ayıklamak zorlaşıyor — özellikle agent workflow varsa bu çok belirgin hissediliyor. Burada disiplinli çıktı üreten modeller öne çıkıyor, ister istemez.
- Küçük startup: Hızlı yanıt veren, JSON’u düzgün döndüren model tercih edin. (bence en önemlisi)
- Ekip içi otomasyon: Tool calling başarısı yüksek modelleri öne alın.
- Kod asistanı: Kod kalitesi ile hızı birlikte ölçün.
- Müşteri yüzlü ürün: Bekleme süresi kısa olan modeli seçin; aksi halde kullanıcı kaçar gider. (bence en önemlisi)
- Dahili analiz: Daha ağır modeller bazen kabul edilebilir çünkü gecikme tolere edilir.
Bana göre çıkan dersler neler?
Nisan başında kendi test ortamımda benzer bir karşılaştırma yaptığımda aynı sürprizi yaşadım. Salonda otururken sonuçlar ekrana düştü ve ben resmen “durun bir dakika…” dedim içimden. Büyük görünen şey her zaman baskın gelmiyor; aksine bazen daha küçük ama iyi optimize edilmiş model işi götürüyor, hem de güzelce götürüyor. İyi haber şu: artık seçim yapmak eskisi kadar sezgisel değil, veriyle yapabiliyoruz. Kötü haber mi? Seçim alanı genişlediği için kafa karışıklığı da arttı. Valla durumu özetlemek gerekirse bu.
Evet, doğru duydunuz.
Bazıları bunu hayal kırıklığı olarak okuyabilir. Haklılar da olabilir — kendi adıma konuşayım — çünkü yıllardır “daha büyük = daha iyi” anlatısına alıştık. Ama bulut AI tarafında optimize etmeun etkisi sandığımızdan fazla çıktı — speed matters dedikleri şey tam olarak bu işte. Mesela de de tool-heavy agent mimarilerinde gecikme doğrudan paraya dönüşüyor, kimi zaman dakika bazında bile hissediliyor. Asıl ders bence şu:
{
"last_model": "nemotron-3-super:cloud",
"why": [
"1x hızlı",
"doğru cevap oranı yüksek",
"ajan akışına daha uygun"
]
}Şu ufak detaya bakın: pratik noktalar
Lafı gevelemeden söyleyeyim: benchmark sonuçlarını körlemesine prod’a taşımayın. Taşımayın, ciddiyim. Kendi veriniz farklı olabilir — prompt yapınız değişir, kullanıcı kitleniz değişir, latency beklentiniz değişir, hatta saate göre bile performans oynayabilir bazen. Yani bağlam önemli, her zaman.
Bunun yerine üç aşamalı yaklaşım iş görüyor:
- Kendi kullanım senaryonuzu yazın; soru tiplerini listeleyin. (bu kritik)
- Aynı prompt’u birkaç modele gönderip süre + doğruluk ölçün.
- Sadece ortalama süreye değil hata türlerine de bakın (JSON bozuk mu? Mantık hatası var mı?). — ciddi fark yaratıyor
Pardon — bir düzeltme yapayım — ortalama süre tek başına hiçbir şeyi anlatmıyor olabilir, çünkü kimi model ilk denemede uçuyor sonra tökezliyor, kimi ise hep makul gidiyor. O yüzden dağılıma bakmak lazım. Yani p90/p95 değerleri sizi kurtarır, özellikle production ortamında. Bu kadar basit aslında, ama atlanan da bu oluyor çoğunlukla.
Sıkça Sorulan Sorular
Büyük parametre sayısı neden her zaman avantaj sağlamıyor?
Büyük modeller çoğu zaman güçlüdür ama hızları düşebilir. Çıktı tutarlılığı beklenenden kötü olabilir.Ajan tabanlı sistemlerde gecikme arttıkça kullanıcı deneyimi bozulur.Bu yüzden yalnızca boyuta bakmak yeterli değildir.
Araç çağırma neden kritik?
Araç çağırma başarılı olmazsa LLM’in cevabı uygulamanız tarafından kullanılamaz.JSON’un düzgün gelmesi özellikle otomasyon zincirlerinde hayati önem taşır.Basit görünür. Pratikte en çok sorun çıkaran yerlerden biridir.
Küçük ekipler hangi metriğe öncelik vermeli?
Küçük ekipler önce hız ve maliyet odaklı başlamalıdır.Daha sonra doğruluk ve format uyumu eklenmelidir.Eğer ürün müşteri yüzlü ise gecikme neredeyse doğrudan gelir kaybıdır.
Neden aynı görevde farklı modeller farklı sonuç veriyor?
Şöyle söyleyeyim, Pozlama farkları yok burada tabii; mesele eğitim verisi mimari optimizasyon ve servis katmanındaki gecikmeler.Modelin “zeka seviyesi” kadar nasıl paketlendiği de sonucu etkiler.O yüzden benchmark okumayı öğrenmek gerekir.
Sana önerdiğim okuma listesi ve resmi kaynaklar aşağıda duruyor…
Kaynaklar ve İleri Okuma]
?
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
