Gemma 4 vs LFM2.5: Yerel Yapay Zekâ Testi

Testimizde gemma4:26b 220 gizli kod testinin ortalama %83,2’sini geçti; lfm2.5-24b-a2b %46,8’inde kaldı. Aynı iki model, 35 gizli kabul testli otonom proje görevinde %95’e karşı %49 aldı. Bu yazıdaki test rakamlarının tamamı, 19 Ekim 2026’da tek bir RTX 3090 ekran kartında yaptığımız toplam 73 model çalıştırmasından geliyor.

Farkın ana nedeni düşünme bütçesi. Düşünen bir akıl yürütme modeli cevap yazmadan önce uzun bir iç ses üretir; bu iç sesin token sınırı bitince model cevap veremez. lfm2.5 altı kod görevinden üçünde bu yüzden ya da çalışmayan dosya yüzünden hiç puan alamadı. gemma4 de bütçeyi üç denemede bitirdi, ama bunlar 18 denemenin yalnızca üçüydü.

lfm2.5’in gerçek avantajları da var. Daha az bellek kullanıyor, metni yaklaşık iki kat hızlı okuyor ve kısa, iyi tanımlı görevlerde yeterli: Roma rakamları görevinde 64 testin 64’ünü, üç denemede de geçti. Yazma hızında iki model neredeyse eşit çıktı. Ama bu avantajlar zor işte doğruluğa dönüşmedi.

Bu iki modeli aynı tüketici ekran kartında, modelin hiç görmediği otomatik testlerle C#, JavaScript, PHP ve ajan görevinde karşılaştıran yayımlanmış başka bir test bulamadık (araştırma: 22 Ekim 2026). Üretici tablolarına ve Türkçe kaynaklara da baktık; ayrıntısı “Sonuçlarımız üretici ve bağımsız testlerle örtüşüyor mu?” bölümünde.

Yerel model, kendi bilgisayarınızda veya sunucunuzda çalışan modeldir. Bulut asistanlarında yazdığınız metin üreticinin sunucusuna gider; yerel modelde veri makineden çıkmaz ve ücret yerine elektrik harcarsınız. Bu iki fark, müşteri belgeleri veya kaynak kod gibi hassas veriyle çalışan işletmeler için ilgi çekici.

Asıl soru başka: bir model kâğıt üstünde iyi görünse de gerçek işi yapıyor mu? Üreticilerin yayımladığı kıyaslamalar bize modelin soru-cevapta, matematikte veya genel bilgide ne kadar iyi olduğunu söylüyor. Bir BT yöneticisinin ya da yazılımcının sorusu ise daha somut: “Bu model benim bozuk modülümü bulur mu? Bir sipariş yazılımındaki hatayı kimse yardım etmeden düzeltir mi? 200 sayfalık arşivde doğru kişiyi bulur mu?”

Bu soruları sınamak için kendi testimizi kurduk. Testin özgünlüğü dört şeyden geliyor.

• Puanı hakem değil gizli testler veriyor: modelin hiç görmediği, yazdığı kodu otomatik çalıştıran testler.
• Görevlerden birine bilinçli bir kültür tuzağı koyduk (Türkçe bölgesel ayar, tr-TR).
• Modele tek başına çalışacağı bir ajan görevi, yani bir yazılım projesi verdik.
• 200 sayfalık bir arşiv üzerinde çok parçalı sorular sorduk.

Bulut asistanına veri yüklemenin kendi sınırları var; bunun için yapay zekâ ile veri analizi rehberimize bakabilirsiniz. Bu yazı ise yerel seçeneği ölçüyor: aynı donanımda, aynı ayarlarla, iki modelin karşılaştırması.

Testlerin tamamı tek bir masaüstü bilgisayarda çalıştı. Ekran kartı, 24 GB VRAM’e (ekran kartı belleği) sahip bir NVIDIA RTX 3090; modeller ayrı bir diskte duruyordu. Ekran kartında aynı anda yalnızca tek model çalıştı, böylece biri diğerinin belleğini veya hızını etkilemedi.

Süreyi Ollama’nın zaman sayaçlarıyla, düşünme ve cevap yazma sürelerini akış sırasında ayrı ayrı ölçtük. Bellek ve gücü nvidia-smi ile aldık. Model yapı bilgilerini model dosyalarının kendi üst verisinden okuduk. Hiçbir testte işlemciye taşma olmadı; iki model de baştan sona ekran kartında çalıştı.

Bellek farkı pratik bir sonuç doğuruyor. lfm2.5 aynı kartta daha fazla boşluk bırakıyor; uzun bağlam veya ikinci bir iş için yer kalıyor. gemma4 uzun dokümanda 22,9 GB’a çıkıyor, yani 24 GB’lık kartta payı dar.

İki modelin ortak yanı, ikisinin de uzmanlar karışımı (MoE, Mixture of Experts) olması. Böyle bir model, her token için ağın tamamını değil yalnızca birkaç uzman alt ağını çalıştırır. Token, modelin metni işlediği birimdir; yaklaşık bir kelimenin dörtte üçü eder. Toplam parametre sayısı modelin boyutunu, aktif parametre sayısı her token’da gerçekten çalışan kısmı gösterir. İkisi de açık ağırlıklı model: ağırlıkları Hugging Face’te yayımlanmış ve kendi donanımınızda çalıştırılabiliyor.

LFM2.5-24B-A2B, Liquid AI’ın LFM ailesinden. Model kartına göre 24,0 milyar toplam, yaklaşık 2,45 milyar aktif parametresi var. 40 katmanın 30’u çift kapılı kısa konvolüsyon bloğu, 10’u dikkat bloğu (GQA); yani hibrit bir mimari. MoE bloğunda 64 uzmandan 4’ü çalışıyor. Bağlam penceresi, yani modelin tek seferde görebildiği metin miktarı, 131.072 token. Lisansı LFM Open License v1.0. En önemli davranış farkı: kart, bunun yalnızca düşünen (reasoning-only) bir model olduğunu söylüyor; her zaman önce düşünüyor.

Gemma 4 26B-A4B, Google’ın Gemma ailesinin 4. kuşağı. Kartına göre 25,2 milyar toplam, 3,8 milyar aktif parametresi var; Ollama sayfası “4 milyar aktif” diyor. 30 katman, 128 uzmandan 8’i artı 1 paylaşılan uzman çalışıyor. Dikkat katmanlarında 1024 token’lık kayan pencere ve global dikkat dönüşümlü; son katman global. Bağlam 256 bin token, Apache 2.0 lisanslı ve görüntü de anlıyor. Düşünme sistem isteminin başındaki <|think|> ile açılıp kapanıyor.

Yani gemma4 her token’da daha fazla parametre çalıştırıyor ve bellekte daha fazla yer tutuyor. lfm2.5 daha hafif. Ama token başına iş hafif olsa da toplam iş hafif olmadı: lfm2.5 bu testte görev başına çok daha fazla token harcadı.

Bir uyarı: testte kullandığımız lfm2.5-24b-a2b paketi, topluluk tarafından Ollama’ya yüklenmiş bir sürümdü. Ollama’nın resmi lfm2.5:24b paketi 15 GB, Q4_K_M ve Liquid AI yayıncısı altında; iki paketin aynı olup olmadığını karşılaştırmadık. Resmi paketin önerilen ayarları (sıcaklık 0,1, top_k 50) bizim ayarlarımızdan farklı; bunu “Yöntem notu ve sınırlar” bölümünde ayrıca ele alıyoruz.

Yapay zekâ çıktısını insan okuyarak puanlamak yavaş ve tutarsız. Biz her görev için gizli testler yazdık. Modele yalnızca görev metni ve arayüz verildi; testleri görmedi. Modelin yazdığı kod çıkarıldı, test projesine konuldu ve otomatik çalıştırıldı. Puan, geçen testlerin oranıdır.

Bu yöntemin iki sonucu var. Birincisi, “modelin cevabı güzel görünüyor” yetmez; kod derlenmiyorsa veya testi geçmiyorsa puan sıfırdır. İkincisi, iki model de aynı düzenekte, aynı koşullarda ölçüldü. İki modelde de şu ayarlar aynıydı.

• Sıcaklık 0,3 (modelin cevaplardaki rastgelelik ayarı)
• Düşünme modu açık
• Kod ve proje görevleri 3 kez, uzun doküman görevi 2 kez çalıştırıldı
• Ekran kartında aynı anda yalnızca tek model
• Görevler İngilizce verildi; iki modele de aynı metin
• Düşünme için token bütçesi var; bütçe bitince model cevap veremez

Bütçe sınırı kod ve proje görevlerinde 24.576 token, uzun doküman görevinde 32 bin token’dı. Bu sınırlar sonuçları doğrudan etkiliyor; bütçeyi bitiren model, ne kadar iyi bilirse bilsin sıfır alıyor.

Birinci rauntta altı görev, üç dil ve toplam 220 gizli test vardı. Her görevi her model üç kez denedi, yani her modelde 18 deneme. gemma4 altı görevin dördünde tüm gizli testleri geçti; lfm2.5 üç görevde hiç puan alamadı.

İki dilde zorluk farklı yerlerden geldi: C# görevleri uzun ve kurallı bir tasarım, PHP önbelleği ise dilin kendi sınırlarını bilmeyi istiyordu. Sonuçlar görev görev şöyle dağıldı.

Görevleri dil dil anlatalım.

C#: hesap makinesi ve veri deposu

Hesap makinesinde modelden, metin olarak verilen bir matematik ifadesini hazır değerlendirici kullanmadan çözmesini istedik. DataTable.Compute, Roslyn ve harici kütüphane yasaktı. Dört işlem, üs (^), parantez ve tekli eksi/artı destekleniyordu. Kurallar küçük ama sinsi: ^ sağdan birleşir, tekli eksi ^’den zayıftır.

2^3^2  = 512
-2^2   = -4
2^-1   = 0.5

39 testin 24’ü doğru sonuç, 13’ü FormatException (boş metin, 2+, *3, (), 2 3, 1.2.3, eksik parantez, 3**2, 2+a, 2,5+1), 2’si DivideByZeroException bekliyordu. Tuzak şuydu: testler Türkçe kültür ayarında (tr-TR) çalışıyor; sayıyı kültüre bağlı okuyan kod “3.5”i 35 sanıyor. gemma4 üç denemenin birinde bütçeyi bitirdi, ikisinde 38/39 ve 39/39 aldı; lfm2.5 üç denemede de bütçeyi bitirdi.

Veri deposu görevi, bellekte çalışan ve iç içe işlem (BEGIN/ROLLBACK/COMMIT) destekleyen bir anahtar-değer deposuydu; Get, Set, Delete ve Count işlemleri O(1) olmalıydı. 24 testin biri performans testiydi: 200 bin anahtar ve 1.000 iç içe işlemle toplam 3 saniyenin altı. gemma4 üç denemede de 24/24 aldı; lfm2.5 üç denemede de bütçeyi bitirdi.

JavaScript: iş havuzu ve hata avı

İş havuzu görevi, aynı anda en fazla N işi çalıştıran bir havuz ve artan beklemeli yeniden deneme mantığıydı; harici paket yasaktı. Yeniden deneme testi 40 ms ardından 80 ms bekleme süresini ölçüyordu. gemma4 üç denemede 25/25 aldı; lfm2.5 23/25, 25/25 ve 25/25.

Hata avında yorum satırlarında ne yapması gerektiği yazan bir modülde 12 gizli hata vardı; modele kaç hata olduğunu söylemedik: parseQuery 4, deepEqual 4, debounce 3, chunk 1, groupBy hatasız. Dokunulmamış modül 42 testin 22’sini zaten geçiyordu. gemma4 üç denemede de 42/42 aldı; lfm2.5 üç denemede de 35/42’de takıldı.

PHP: Roma rakamları ve süreli önbellek

Roma rakamları görevinde yalnızca standart yazım geçerliydi (IIII, IC, VX hatalıdır) ve 1–3999 aralığı destekleniyordu. 64 testin 28’i bilinen değerler, biri 1’den 3999’a gidiş-dönüş, 29’u reddedilmesi gereken girdilerdi. İki model de üç denemede 64/64 aldı. lfm2.5’in hafif ve hızlı yapısı, böyle kısa ve iyi tanımlı görevde yetiyor.

Süreli LRU önbellek, dolunca en uzun süredir kullanılmayanı atan ve süre aşımı (TTL) olan bir önbellekti; zaman dışarıdan enjekte edilen bir saatle yönetiliyordu. 26 test vardı. gemma4 iki denemede bütçeyi bitirdi, birinde 26/26 aldı. lfm2.5 üç denemede de dosyayı çalıştıramadı.

Grafiğin gösterdiği şey: lfm2.5’in ortancası iki C# görevinde bütçenin tavanına dayandı; gemma4’ün ortancası yalnızca PHP önbellek görevinde tavana ulaştı. Roma rakamlarında ise gemma4 biraz daha fazla token harcadı; bu tek görevde lfm2.5 daha tasarruflu.

Üç başarısızlık hikâyesi

Sayıların ardındaki davranış, çoğu zaman rakamlardan daha öğretici.

PHP hatasının kalıbı kabaca şöyle; PHP iç içe sınıf tanımını desteklemediği için dosya yüklenmeden çöküyor.

class LruCache
{
    private class Node   // PHP'de sınıf içinde sınıf tanımlanamaz
    {
        // ...
    }
}

Bütçeyi iki katına çıkarınca ne oldu?

lfm2.5’in sorunu yalnız süre mi, yoksa kod kalitesi mi? Bunu ayırmak için iki C# görevini 49 bin token’lık bütçeyle, yani iki katıyla yeniden denedik. lfm2.5 bu kez cevap yazdı, ama 4 denemenin 2’sinde kod derlenmedi; diğer ikisi 35/39 ve 8/24 aldı. gemma4 veri deposunda yine iki denemede 24/24 aldı. Sonuç: lfm2.5’in sorunu yalnızca süre değil, kod kalitesi de.

İkinci rauntta modeli yapay zekâ ajanı olarak çalıştırdık. Ajan, tek bir cevap yazmakla yetinmeyip araç kullanarak adım adım iş yapan modeldir. Görev, gerçekçi bir sipariş yönetim yazılımıydı: 7 kaynak dosya ve 8 bin token’lık bir şartname.

Dört hata raporu kullanıcı şikâyeti biçimindeydi: “kupon fazla indirim yapıyor”, “başarısız siparişten sonra stok kayboluyor”, “kupon bir gün erken bitiyor”, “indirim satırlara garip dağılıyor”. Bunların üstüne sıfırdan bir özellik eklenecekti: yuvarlama kuralları, stok iadesi ve rapor değişiklikleriyle kısmi iade. Model beş aracı kullanabiliyordu: dosyaları listele, oku, yaz, testleri çalıştır ve “bitti” de. 60 adım sınırı vardı ve soru soracak kimse yoktu.

Puanı 35 gizli kabul testi verdi. Dokunulmamış proje bunların 11’ini zaten geçiyordu; yani kimse hiçbir şey yapmasa 11/35 elde edilirdi.

lfm2.5’in üçüncü denemesindeki 10/35, dokunulmamış projenin 11/35’inin de altında. Yani modelin müdahalesi, o denemede çalışan bir kısmı bozdu.

Hangi sorunun ne kadar çözüldüğüne de baktık: 3 denemede ilgili gizli testlerin geçilme oranı.

En büyük uçurum yeni özellikte. Hata düzeltmek, var olan kodu okuyup küçük bir değişiklik yapmayı gerektirir. Kısmi iade ise şartnameyi okuyup birkaç dosyayı tutarlı biçimde değiştirmeyi, yuvarlama ve stok kurallarını birlikte düşünmeyi gerektirir. lfm2.5 en çok bu işte zorlandı.

lfm2.5 yazma hızında gemma4’e denk olduğu için süre farkı hız farkından değil, çok daha fazla adım atmasından geliyor. İki modelin çalışma biçimi şöyle ayrıştı.

Bu, düşünme bütçesi hikâyesinin ajan görevindeki karşılığı: lfm2.5 bağlamı şişirdi, aynı dosyaları yeniden yazdı ve adım bütçesini tüketti. Bunun nedenini sınamadık; gözlemimiz yalnızca bu sırayla yaşandığı.

Üçüncü rauntta uzun metin hafızasını sınadık. Hayali bir lojistik şirketinin bir yıllık arşivini hazırladık: personel listesi, birbirini geçersiz kılan duyurular (tayinler, yönetici değişiklikleri, harcırah zamları, işten ayrılışlar), yüzlerce masraf kaydı ve dikkat dağıtan alakasız toplantı notları.

İki boyutun her birinde 10 soru sorduk; her soru birkaç parçayı birleştirmeyi gerektiriyordu. Örnekler: “Nisan’daki zamdan sonra İzmir harcırah limitini aşan masraflar hangileri?”, “Bu çalışanın genel müdüre kadar yönetici zinciri nedir?”, “Şubat’ta iptal edilen kodun yerine geçen güncel kod hangisi?” Düşünme bütçesini bu rauntta 32 bin token yaptık.

İki model de aynı tuzağa düştü: yüzlerce satırlık masraf defterini akıllarından satır satır saymaya kalktılar ve bütçe bitti. gemma4 30 bin token’lık arşivde bütçeyi bir kez yetiştirdi ve 10 sorunun 9’unu doğru cevapladı: yönetici zinciri, tarihe göre değişen limit, çeyreklik toplam ve iptal edilen kod doğru geldi. Ama aynı arşivde ilk denemede cevapsız kaldı. 200 sayfalık arşivde gemma4 iki denemede de cevap yazamadı.

Düşünmeyi kapatınca ne oluyor? Bunu gemma4’te “doğrudan cevap ver” ayarıyla denedik. lfm2.5’in düşünmesi bu ayarla kapanmıyor.

gemma4 doğrudan cevapta 14–47 saniyede 10 sorudan 4 puan aldı. Basit bilgi bulmada hızlı ve isabetli, hesap gerektiren sorularda zayıf. lfm2.5 cevap verdiğinde neredeyse yalnızca “güncel kod” sorusunu bildi. Pratik sonuç: uzun bir arşivden toplam veya zincir gerektiren soru soracaksanız, modele satır saydırmak yerine bu işi koda veya arama aracına devretmek gerekir.

Hız iki ayrı sayıdır. Okuma hızı (prompt işleme), modelin verdiğiniz metni ne kadar hızlı içeri aldığını; yazma hızı (üretim), cevabı ne kadar hızlı yazdığını gösterir. Uzun dokümanlarda okuma hızı belirleyicidir.

Bu, lfm2.5’in gerçek ve ölçülmüş avantajı: aynı uzun metni yaklaşık yarı sürede içeri alıyor. Ama cevap yazma hızında fark yok.

İki model de kısa görevlerde saniyede 200’ün üzerinde token yazdığı için süre farkı hızdan değil, harcanan token sayısından geliyor. Zamanın nereye gittiğine kod testlerinde ayrıca baktık.

Kod testlerinde süre ağırlıklı olarak düşünmeye harcanıyor: lfm2.5’te %93,5, gemma4’te %88,9. Bu yüzden saniyedeki token sayısı tek başına model hızını anlatmıyor. Önemli olan, modelin kaç token’da bitirdiği.

Ekran kartı çalışırken iki modelde de yaklaşık 365 W çekti. Yani lfm2.5’in token başına daha az parametre çalıştırması, bu donanımda elektrik tasarrufuna dönüşmedi; proje görevini yaklaşık dört kat uzun sürede bitirdiği için harcadığı enerji de muhtemelen daha yüksekti (enerjiyi ayrıca ölçmedik).

gemma4:26b açık farkla kazandı. Kod yazmada, tek başına proje yürütmede ve uzun metinde daha doğru, daha tutarlı ve daha az israflı çalıştı. lfm2.5’in hafifliği ve okuma hızı gerçek avantaj, ama zor işte kaliteye dönüşmedi.

• gemma4:26b ne için:

  Günlük kodlamada C# ve JavaScript’te neredeyse kusursuz çalıştı. Tek başına görevde araçları disiplinli kullandı, işi bitirip teslim etti; üç denemenin üçünde de tamamladı. Çok zor görevlerde düşünme bütçesini 32–48 bin token’a çıkarmak işe yarıyor.

• lfm2.5-24b-a2b ne için:

  Hafif ve basit işlerde daha az bellek kullanıyor ve metni daha hızlı okuyor. Kısa ve iyi tanımlı görevlerde, Roma rakamları gibi, yeterli. Zor kod ve tek başına çalışma gerektiren işlerde bu testte güvenilir olmadı.

Bu testten çıkan genel ders şu: “düşünen” modellerde hız, saniyedeki token sayısından ibaret değil. Asıl mesele, modelin ne zaman düşünmeyi bırakıp cevaba geçeceğini bilmesi. Bu konuda gemma4 bizim testimizde çok daha olgun davrandı: daha az token harcayıp daha yüksek puan aldı ve bitirmesi gerektiğinde bitirdi.

Aşırı düşünme literatürde de bilinen bir sorun. Düşünme bloğunu token sınırında kapatıp cevabı zorlayan “budget forcing” yaklaşımı akademik çalışmalarda öneriliyor. Daha fazla düşünmenin her zaman daha iyi sonuç vermediğini, doğruluğun token sayısıyla düzgün artmadığını gösteren makaleler de var. “Bütçe bitince hiç cevap verememe” durumunu doğrudan inceleyen bir makale ise bulamadık; lfm2.5 her zaman düşündüğü için bu riskin yapısal olduğunu düşünüyoruz, ama bu bir yorum, kanıtlanmış bir sonuç değil.

Kısmen. Kodlamada Google’ın yayımladığı sonuçlarla tutarlıyız; ajan ve araç kullanımında ise Liquid’in kendi tablosunun tersi bir sonuç aldık. Aşağıdaki tablo, kaynaklarda bulduklarımızla bizim ölçtüğümüzü yan yana koyuyor.

Bu tabloda iki nokta öne çıkıyor. Birincisi, Liquid’in kendi tablosunda LFM2.5, SWE-Bench Verified’da ve araç/ajan ölçütlerinde Gemma’nın önünde görünüyor; bizim ajan sonucumuz bunun tersi. İkincisi, o tablo bağımsız değil: Liquid hem kendi modelini hem rakibini kendi altyapısında çalıştırmış. Gemma’nın GPQA değeri bile Google’ın yayımladığı 82,3’ün altında; protokol farkı olabilir, ama doğrulayamadık.

Farkın nedenini bilmiyoruz. Olası açıklamalar şunlar; hepsi hipotez, hiçbirini sınamadık.

• Harness farkı: Liquid’in SWE-Bench koşusu OpenCode adlı bir ajan altyapısı kullanıyor; bizim 5 araçlı kendi düzeneğimizden farklı. Araç sunumu ve istem biçimi modelin başarısını değiştirebilir.
• Örnekleme ayarı: Liquid’in önerdiği sıcaklık 0,1, Google’ın Gemma için önerdiği 1,0; biz iki modelde de 0,3 kullandık. Bu ayar iki modelden birini diğerinden daha çok etkilemiş olabilir.
• Paket farkı: Biz topluluk tarafından yüklenmiş bir lfm2.5 paketi kullandık; resmi paketle karşılaştırmadık.
• Görev türü: SWE-Bench gerçek açık kaynak projelerindeki hataları çözer; bizim görevlerimiz yeni yazılmış, modelin eğitim verisinde bulunma ihtimali düşük gizli testlerdi.

Bağımsız ölçümlerde de eksik var. Artificial Analysis’te Gemma 4 26B için sayfa var, LFM2.5 için bulamadık. Atomic Chat’in RTX 5090’da LFM2.5’in terminal görevlerini kazandığını söyleyen bir paylaşımı da var, ama sayfayı açamadık ve yöntemini bilmiyoruz; bu yüzden değerlendirmeye almadık. RTX 3090’da yayımlanmış bir token/sn ölçümü de bulamadık: hesap makinesi siteleri tahmin veriyor ve bizim ölçtüğümüz yazma hızının çok altında değerler gösteriyor; bunları ölçüm saymadık.

Bu sınırlar sonucun yönünü değiştirmiyor ama büyüklüğünü okurken dikkat etmeyi gerektiriyor. Kendi işinizde sıralama farklı çıkabilir; bu yüzden bir sonraki bölümde işletmeler için ne yapılması gerektiğini ayrı yazıyoruz.

Yerel yapay zekâ kurarken model seçimi, ekran kartı seçimi kadar önemli. Aynı donanımda iki model arasında kod testlerinde %83,2’ye karşı %46,8 gibi bir fark çıktı. Bu farkı donanım değil, modelin düşünme davranışı belirledi. Üretici tablolarındaki sıralama, kendi işinizdeki sıralamayla örtüşmeyebilir; bizim testimizde ajan görevinde örtüşmedi.

Kendi işiniz için üç şey öneriyoruz. Birincisi, modeli kendi görevleriniz ve kendi gizli testlerinizle sınayın; genel kıyaslamalara tek başına güvenmeyin. İkincisi, düşünme bütçesini ve modelin bütçeyi bitirdiğinde ne yaptığını ölçün; boş cevap, doğru bir “bilmiyorum”dan daha pahalıdır. Üçüncüsü, model davranışını dar bir pilotta izleyin: aynı görevi birkaç kez çalıştırıp dalgalanmaya bakın.

• s01Model, görevlerimizin kaçında düşünme bütçesini bitiriyor?
• s02Cevap yazdığında kod derleniyor ve testleri geçiyor mu?
• s03Aynı görevi birkaç kez çalıştırdığımızda sonuç ne kadar değişiyor?
• s04Donanımımızda bellek payı uzun metin ve ikinci bir iş için yetiyor mu?

Verinizin kurum dışına çıkmasını istemiyorsanız, yerel yapay zekâ kurulumu modelin, belge erişiminin ve yetkilerin birlikte planlanmasını gerektirir. Hangi işlerde yapay zekânın değer katacağını belirlemek için yapay zekâ danışmanlığı kullanım alanlarının ve uygun model ve araçların belirlenmesini kapsar. Modelin işini bir yazılıma bağlayacaksanız, özel yazılım geliştirme tarafında da sınama ve entegrasyon planı gerekir.

Bu yazıdaki rakamlar bizim testimize aittir. Başka bir iş, başka bir donanım veya Türkçe talimatlarla sonuç değişebilir; kendi işinizde ölçmeden kararı vermeyin.

1. [1]LFM2.5-24B-A2B model kartı — Hugging Face (Liquid AI)huggingface.co↗
2. [2]LFM2.5-24B-A2B duyurusu — Liquid AIliquid.ai↗
3. [3]lfm2.5:24b — Ollamaollama.com↗
4. [4]Gemma 4 model kartı — Google AIai.google.dev↗
5. [5]gemma-4-26B-A4B-it — Hugging Face (Google)huggingface.co↗
6. [6]gemma4 — Ollamaollama.com↗
7. [7]Artificial Analysis — Gemma 4 26B A4Bartificialanalysis.ai↗
8. [8]s1: Simple test-time scaling (budget forcing) — arXiv 2501.19393arxiv.org↗
9. [9]Reasoning Models Can Be Effective Without Thinking — arXiv 2504.09858arxiv.org↗
10. [10]When More Thinking Hurts: Overthinking in LLM Test-Time Compute Scaling — arXiv 2604.10739alphaxiv.org↗
11. [11]Does Thinking More always Help? — arXiv 2506.04210arxiv.org↗
12. [12]Thinking Past the Answer — arXiv 2606.02835arxiv.org↗