Küçük Dil Modelleri (SLM) ve Fine-Tuning: 2026'da Maliyet-Etkin Özelleştirmenin Yolu (LoRA, QLoRA, Distillation)

TL;DR — 2026'da kurumsal yapay zekânın en gerçekçi maliyet kaldıracı, her şeyi dev bir API modeline yıkmak değil; dar ve tekrar eden işler için Küçük Dil Modelleri (SLM) seçip bunları fine-tuning ile özelleştirmektir. LoRA ve QLoRA gibi PEFT teknikleri, haftalar sürüp binlerce dolara mal olabilecek bir eğitimi tek bir GPU'da saatlere indirebiliyor; distilasyon ise küçük modelin büyük modelin davranışını öğrenmesini sağlıyor. Doğru senaryoda kurumlar yapay zekâ maliyetlerini önemli ölçüde (raporlanan örneklerde ~%75'e varan oranlarda) düşürebiliyor. Bu yazıda "ne zaman SLM + fine-tuning, ne zaman RAG, ne zaman ikisi birden" sorusunu; veri hazırlığını; LoRA/QLoRA ile tam fine-tuning farkını; değerlendirme ve felaket unutmayı (catastrophic forgetting); vLLM ve kuantizasyonla servis etmeyi; ve Türkçe'ye özgü incelikleri sahadan gözlemlerimle anlatıyorum.

Son iki yılda sahada en çok duyduğum cümle şu: "Hocam pilot çalıştı, demo herkesi büyüledi, ama faturayı görünce proje rafa kalktı." Bu cümlenin arkasında neredeyse her zaman aynı hata yatıyor: basit, dar, tekrar eden bir işi, dünyanın en büyük genel amaçlı modeline, üstelik token başına ödeyerek yaptırmak. Bir e-postayı sınıflandırmak, bir faturadan kalem çıkarmak, bir destek talebini doğru departmana yönlendirmek, sabit formatta özet üretmek... Bunların hiçbiri "evrenin sırlarını çözecek" bir zekâ gerektirmiyor. Ama biz çoğu zaman bu işleri, sanki her seferinde bir doktora tezi yazdırıyormuşuz gibi en pahalı modele havale ediyoruz.

İşte tam bu noktada Küçük Dil Modelleri devreye giriyor. Kabaca birkaç milyon parametreden ~7 milyar parametreye kadar uzanan, sınırlı donanımda verimli çalışacak şekilde tasarlanmış nöral dil modellerine SLM diyoruz. Bunlar cihaz üstünde (on-device), uçta (edge) ve maliyete duyarlı kurumsal senaryolarda koşabilecek kadar hafifler. 2026 itibarıyla bu alan artık "oyuncak modeller" alanı değil; ciddi mühendislikle damıtılmış, dar işlerde devasa modellere kafa tutabilen bir ekosistem.

Ben bu yazıyı, danışmanlık ve eğitim verdiğim kurumlarda gördüğüm gerçek kararlarla yazıyorum. Amacım size moda kelimeler satmak değil; "hangi işi hangi modele, neden ve nasıl" verdireceğinizin pratik bir çerçevesini sunmak.

SLM'i tek bir cümleyle tanımlayayım: sınırlı hesap kaynağında verimli çalışacak şekilde tasarlanmış, görece küçük parametre sayısına sahip dil modeli. "Görece küçük" derken, bugünün yüz milyarlarca parametreli devleriyle kıyaslandığında birkaç milyon ile ~7 milyar arasındaki bandı kastediyorum. Bu band o kadar geniş ki içine hem telefonda koşan minik modeller hem de tek bir kurumsal GPU'da rahatça fine-tune edebileceğiniz orta boy modeller giriyor.

2026'da kurumsal sahada en sık karşılaştığım SLM aileleri şunlar:

• Microsoft Phi-4 (14B) ve Phi-4-mini (3.8B): Küçük ölçekte şaşırtıcı derecede güçlü muhakeme sunuyorlar. Bunun sırrı, özenle hazırlanmış sentetik veri ve distilasyon. Yani model, boyutundan beklenenden çok daha "akıllı" davranıyor çünkü öğrendiği veri kalitesi yüksek.
• Google Gemma 3: Daha büyük Gemini ailesinden damıtılmış (distilled), 4B ve üzeri boyutlarda çok-kipli (multimodal) yetenekler sunan bir aile. Metnin ötesine geçmesi gereken senaryolarda dikkat çekici.
• Mistral Ministral 3B: Uç (edge) senaryoları için optimize edilmiş, küçük ama tok bir model. Cihaz üstü ve düşük gecikme isteyen yerlerde aklımda ilk gelenlerden.
• Meta Llama 3.2 1B / 3B: Çok hafif, açık ağırlıklı, geniş ekosistem desteği olan modeller. Hızlı prototip ve on-device için pratik.
• Alibaba Qwen3 ailesi: Güçlü çok-dillilik (multilingual) ile öne çıkıyor; özellikle Türkçe dahil İngilizce dışı dillerde sınadığınızda hoş sürprizler verebiliyor.

Buradaki kritik gözlem şu: bu modellerin küçük olması "zayıf" demek değil. Phi-4 ailesinin gösterdiği gibi, kaliteli veri + distilasyon ile küçük bir model, dar bir görevde çok daha büyük bir modele rakip olabiliyor. 2026'nın oyununu kazandıran şey ham parametre sayısı değil; doğru veriyle doğru göreve doğru modeli oturtmak.

Bir SLM'i "kutudan çıktığı gibi" kullandığınızda, genel bir asistan gibi davranır. Ama kurumların ihtiyacı genellikle genel değil, çok spesifiktir: sizin terminolojinizle konuşan, sizin formatınızda çıktı veren, sizin iş kurallarınıza uyan bir model. İşte fine-tuning tam da bunu yapar: modelin davranışını, biçimini ve alan diline (domain style) hâkimiyetini sizin verinizle yeniden şekillendirir.

Burada 2026'nın en güzel haberi şu: artık fine-tuning yapmak için bir araştırma laboratuvarı olmanıza gerek yok.

LoRA: Düşük rütbeli adaptasyon

LoRA (Low-Rank Adaptation), modelin tüm ağırlıklarını güncellemek yerine yalnızca küçük bir alt küme parametreyi günceller. Bunun sonucu dramatik: gereken hesabı kabaca bir büyüklük mertebesi (yaklaşık 10 kat) azaltabilir. Pratikte ne demek bu? Büyük bir LLM için haftalar sürecek, binlerce dolara mal olabilecek bir eğitim, bir SLM için tek bir GPU'da saatler içinde bitebilir. Ben bunu sahada defalarca gördüm: sabah veriyi hazırlayıp öğlene doğru ilk LoRA adaptörünü çalıştırmak, akşama doğru ölçümleri konuşmak artık sıradan bir gün.

QLoRA: Daha küçük GPU'ya sığdırmak

QLoRA, LoRA'nın üzerine kuantizasyon ekler. Yani modeli daha düşük bitlik bir gösterimle tutarak belleği ciddi şekilde küçültür ve böylece daha mütevazı bir GPU'ya sığdırmanızı sağlar. Bütçesi sınırlı, ama yine de kendi modelini eğitmek isteyen ekipler için QLoRA adeta bir demokratikleşme aracı. Tek bir tüketici sınıfı veya orta seviye GPU üzerinde, daha önce sadece büyük bütçeli ekiplerin yapabildiği işi yapabiliyorsunuz.

Distilasyon: Büyükten küçüğe bilgi aktarımı

Bilgi distilasyonu (knowledge distillation), küçük bir modelin daha büyük bir modelden öğrenmesini sağlar. Büyük model "öğretmen", küçük model "öğrenci" olur; öğrenci, öğretmenin davranışını taklit ederek çok daha düşük hesap maliyetiyle ona yakın bir performansa ulaşabilir. Phi-4 ve Gemma 3 gibi modellerin gücünün ardında tam da bu yaklaşım var. Kurumsal tarafta ben bunu şöyle kullanmayı seviyorum: büyük bir modeli kullanarak yüksek kaliteli örnek çıktılar ürettiriyorum, sonra bu örneklerle küçük modeli eğitiyorum. Sonuçta üretimde küçük, ucuz ve hızlı bir model koşuyor; ama davranışı büyük modelden miras alıyor.

Bu sorunun cevabı, projenin kaderini belirler. Sahadaki deneyimime göre SLM + fine-tuning şu durumlarda büyük API modelini açık ara geçer:

1. Dar ve tekrar eden işlerde. Görev ne kadar dar ve tekrarlıysa, küçük model o kadar parlıyor. Sınıflandırma, etiketleme, sabit formatta çıkarım, yönlendirme, şablon doldurma... Bu tür işlerde devasa bir modelin "genel zekâsı" israftır. Küçük modeli o tek işe odaklayıp keskinleştirdiğinizde, hem daha doğru hem daha tutarlı sonuç alırsınız.

2. Gecikme (latency) kritik olduğunda. Küçük model demek, daha hızlı yanıt demek. Bir çağrı merkezinde gerçek zamanlı öneri, bir editörde anlık otomatik tamamlama, bir üretim hattında milisaniyelerin önemli olduğu bir karar... Buralarda büyük bir API'nin gidiş-dönüş gecikmesi tek başına projeyi öldürebilir.

3. Ölçekte maliyet patladığında. Günde birkaç yüz çağrı yapıyorsanız API maliyeti sorun olmaz. Ama günde milyonlarca çağrı yapıyorsanız, token başı ücret çarpan etkisiyle astronomik hale gelir. İşte burada kendi SLM'inizi kendi donanımınızda koşturmak devreye girer. Raporlanan örneklerde, doğru dar görevler için SLM'e geçen kurumların yapay zekâ maliyetlerini önemli ölçüde, hatta ~%75'e varan oranlarda düşürdüğü gözlemleniyor. Bunu mutlak bir garanti değil, gerçekçi bir potansiyel olarak okumanızı öneririm; sonuç sizin iş yükünüze ve mühendislik disiplininize bağlı.

4. On-prem, KVKK ve veri ikametgâhı (data residency) gerektiğinde. Türkiye'de çalışıyorsanız bu madde çoğu zaman pazarlık konusu bile değildir. Hassas müşteri verisi, sağlık kaydı, finansal bilgi... Bunların kurum dışına, hele yurt dışındaki bir API'ye çıkması KVKK açısından ciddi risk taşır. Kendi sunucunuzda koşan bir SLM, veriyi hiç dışarı çıkarmadan iş görür. Bu, birçok kurumsal projede SLM tercihinin tek başına yeterli gerekçesidir.

5. Çevrimdışı (offline) ve uçta (edge) çalışmak gerektiğinde. İnternet bağlantısının olmadığı veya güvenilmez olduğu sahalarda, fabrikalarda, sahadaki cihazlarda büyük API modelini kullanamazsınız. Cihaz üstünde koşan küçük bir model ise bağlantıdan bağımsız çalışır.

Tersi de doğru: eğer işiniz geniş, açık uçlu, sürekli yeni ve derin muhakeme gerektiren bir işse; düşük hacimliyse; ve veri mahremiyeti bir engel değilse, büyük bir API modeli hâlâ en pratik seçim olabilir. Mesele "küçük her zaman iyidir" değil; mesele işi doğru tanımlayıp doğru aracı seçmektir.

Sahada en sık yapılan kavram karışıklığı bu. İnsanlar "modelin bizim verimizi bilmesini istiyoruz" deyince hemen fine-tuning'e koşuyor. Oysa çoğu zaman ihtiyaçları olan şey RAG'dir. İkisini ayıran çizgiyi net çizeyim:

• Fine-tuning, davranış / biçim / alan dili içindir. Modelin nasıl konuşacağını, hangi formatta çıktı vereceğini, sizin terminolojinizi ve üslubunuzu içselleştirmesini, belirli bir görevde nasıl davranacağını öğretirsiniz. Yani fine-tuning modelin "nasıl" davrandığını değiştirir.
• RAG (Retrieval-Augmented Generation), bilgi / güncellik içindir. Modele, çıkarım anında dış bir kaynaktan (vektör veritabanı, doküman deposu) ilgili bilgiyi getirip bağlama eklersiniz. Böylece model, eğitildiği andan sonra değişen veya hiç görmediği güncel bilgiye erişir. Yani RAG modelin "neyi bildiğini" besler.

Pratik kural olarak şunu söylüyorum: Bilgi değişiyorsa RAG, davranış sabitse fine-tuning. Ürün kataloğunuz her hafta değişiyorsa onu fine-tune etmek delilik olur; her değişiklikte yeniden eğitmeniz gerekir. Onun yerine RAG ile katalogu canlı çekersiniz. Ama modelin her zaman sizin marka tonunuzla, sizin JSON şemanızla, sizin sınıflandırma etiketlerinizle yanıt vermesini istiyorsanız, bu davranıştır ve fine-tuning ister.

Ve çoğu olgun kurumsal sistemde cevap "ikisi birden" çıkar: davranışı ve formatı fine-tuning ile sabitlersiniz, güncel bilgiyi RAG ile beslersiniz. Örneğin fine-tune edilmiş küçük bir model her zaman temiz, şemaya uygun bir yanıt üretir; RAG ise o yanıtın içine doğru ve güncel olguları yerleştirir. Bu ikili, hem ucuz hem doğru hem güncel bir sistem kurmanın en sağlam yoludur.

Açık konuşayım: fine-tuning projelerinin başarısının %80'i veri kalitesinde saklı. Model mimarisi, hiperparametreler, GPU seçimi... Bunların hepsi önemli, ama hiçbiri kötü veriyi kurtaramaz. "Çöp girer, çöp çıkar" kuralı yapay zekâda acımasızca işler.

Sahada veri hazırlığı için takip ettiğim ilkeler şunlar:

• Az ama temiz, çoktan iyidir. Birkaç bin gerçekten temiz, doğru etiketlenmiş, tutarlı formatlı örnek; on binlerce gürültülü örnekten daha iyi sonuç verir. Özellikle LoRA gibi PEFT yöntemlerinde, küçük ama yüksek kaliteli bir veri seti şaşırtıcı derecede güçlüdür.
• Format tutarlılığı kutsaldır. Eğer modelin belirli bir formatta (örneğin geçerli JSON) çıktı vermesini istiyorsanız, eğitim verinizdeki her örnek tam olarak o formatta olmalı. Tek bir bozuk örnek bile modele "bazen şöyle de olabilir" mesajı verir.
• Çeşitlilik ama dağılım sadakati. Veriniz, modelin üretimde karşılaşacağı durumların gerçek dağılımını yansıtmalı. Sadece kolay örnekleri toplarsanız, model zor kenar durumlarında çuvallar.
• Etiket mutabakatı. Birden fazla kişi etiketliyorsa, etiketleme kılavuzunuz net olmalı ve etiketçiler arası tutarlılığı ölçmelisiniz. Tutarsız etiketler modeli "gürültü öğrenmeye" iter.
• Sentetik veriyi akıllıca kullanın. Phi-4'ün gösterdiği gibi, kaliteli sentetik veri çok güçlü olabilir. Büyük bir modelle örnek üretip, sonra bunları insan eliyle gözden geçirerek temizlemek, veri kıtlığını aşmanın pratik bir yolu. Ama körü körüne güvenmeyin; sentetik veride de hata, yanlılık ve tekrar olur.

Bir de sızıntı (leakage) konusu var: değerlendirme setinizdeki örnekler kesinlikle eğitim setine karışmamalı. Aksi halde modeliniz "harika" görünür ama bu sahte bir başarıdır; gerçekte ezberlediği örnekleri size geri okur.

Bu kararı netleştirelim, çünkü bütçe ve sonuç doğrudan buna bağlı.

Tam fine-tuning (full fine-tuning), modelin tüm parametrelerini günceller. Maksimum esneklik sunar, ama bedeli yüksektir: çok daha fazla GPU belleği, çok daha uzun süre, çok daha yüksek maliyet ve felaket unutma riskinde artış. Bir SLM'de bile, eğer elinizde geniş ve çeşitli bir veri seti yoksa, tam fine-tuning çoğu zaman gereksiz bir lükstür.

PEFT (Parameter-Efficient Fine-Tuning), yani LoRA ve QLoRA, parametrelerin yalnızca küçük bir kısmını günceller. Avantajları:

• Çok daha az hesap ve bellek (LoRA ile yaklaşık bir büyüklük mertebesi tasarruf).
• Tek GPU'da, saatler içinde biten eğitimler.
• Birden fazla görev için ayrı ayrı küçük adaptörler tutup, ana modeli paylaşabilme. Yani tek bir temel SLM üzerine onlarca hafif adaptör takıp çıkarabilirsiniz.
• Daha düşük felaket unutma riski, çünkü temel ağırlıkların çoğuna dokunulmaz.

Pratik tavsiyem net: Çoğu kurumsal SLM fine-tuning'ine LoRA veya QLoRA ile başlayın. Gerçekten yetmediğini ölçümlerle kanıtladığınız ender durumlarda tam fine-tuning'i düşünün. Vakaların büyük çoğunluğunda PEFT, hem daha ucuz hem yeterince güçlüdür. QLoRA'yı ise donanımınız sınırlıysa veya modeli mümkün olan en küçük GPU'ya sığdırmak istiyorsanız tercih edin.

Fine-tuning'in en sinsi tuzağı şudur: modeli yeni görevde harika hale getirirken, eskiden iyi yaptığı şeyleri unutmasına yol açabilirsiniz. Buna felaket unutma (catastrophic forgetting) deniyor. Model, dar görevinize aşırı uyum sağlarken genel yeteneklerini kaybeder; sonra üretimde beklenmedik bir girdiyle karşılaşınca tuhaf davranır.

Bundan kaçınmanın pratik yolları:

• PEFT kullanın. LoRA/QLoRA temel ağırlıkların çoğunu dondurduğu için felaket unutmaya karşı doğal bir koruma sağlar.
• Aşırı eğitmeyin. Çok fazla epoch, modeli eğitim verisine ezberletir. Erken durdurma (early stopping) ve doğrulama setini izlemek şart.
• Karışık veri kullanın. Sadece yeni göreve değil, modelin korumasını istediğiniz genel yeteneklere dair bir miktar örneği de eğitime serpiştirin.
• Gerçekçi değerlendirin. İki ayrı set tutun: biri yeni görevdeki başarıyı, diğeri eski genel yeteneklerin korunup korunmadığını ölçsün. Sadece hedef metriğe bakıp "harika oldu" demek tehlikeli.

Değerlendirme konusunda en çok vurguladığım şey: otomatik metriğe körü körüne güvenmeyin. Dar bir görevde doğruluk, F1, tam eşleşme gibi metrikler işe yarar; ama üretken çıktılarda mutlaka insan gözüyle bir örneklem inceleyin. Ayrıca üretim trafiğini örnekleyip düzenli olarak gözden geçirin; model zamanla, veri dağılımı kaydıkça (data drift) sapabilir.

Modeli eğitmek işin yarısı; onu üretimde verimli koşturmak diğer yarısı. Burada iki kavram öne çıkıyor.

vLLM gibi yüksek verimli servis motorları, aynı donanımdan çok daha fazla iş çıkarmanızı sağlar. Akıllı bellek yönetimi ve toplu işlem (batching) ile, eşzamanlı çok sayıda isteği düşük gecikmeyle karşılayabilirsiniz. Kendi SLM'inizi kendi sunucunuzda koşturuyorsanız, böyle bir motor üretim ekonomisini doğrudan etkiler.

Kuantizasyon, model ağırlıklarını daha düşük bitlik gösterimle tutarak belleği ve hesabı azaltır. Eğitimde QLoRA ile tanıştığınız kuantizasyonu, serviste de kullanırsınız: 8-bit ya da 4-bit kuantize edilmiş bir SLM, çok daha küçük bir GPU'da, çok daha hızlı koşar; üstelik dar görevlerde doğruluk kaybı çoğu zaman ihmal edilebilir düzeydedir. Tabii bunu da körlemesine değil, ölçerek yapmak gerekir: kuantizasyon sonrası modeli kendi değerlendirme setinizle yeniden sınayın.

Bir de toparlayıcı bir gözlem: SLM + kuantizasyon + vLLM üçlüsü, "kendi modelini kendi sunucunda koştur" hayalini bugün son derece gerçekçi kılıyor. Beş yıl önce bu, ciddi bir altyapı yatırımı gerektirirdi; bugün orta ölçekli bir kurum bile bunu makul bir bütçeyle kurabiliyor.

Bir kurumla oturduğumda kafamdaki akış kabaca şöyle işliyor. Önce işi tanımlıyoruz: dar mı geniş mi, hacim ne, gecikme ne kadar kritik, veri nereye çıkabilir, bilgi ne sıklıkla değişiyor. Sonra bu yanıtlara göre yol ayrımına geliyoruz.

Aşağıdaki tablo, sahada kullandığım kaba karar rehberinin özetidir:

Senaryo / İhtiyaç	Önerilen yaklaşım	Neden
Dar, tekrarlı görev (sınıflandırma, çıkarım, yönlendirme)	SLM + LoRA fine-tuning	Ucuz, hızlı, keskin; büyük modelin genel zekâsına gerek yok
Sürekli değişen / güncel bilgi gerekiyor	RAG (gerekirse fine-tune edilmiş SLM ile)	Bilgi tazeliği eğitimle değil getirimle çözülür
Sabit marka tonu, format, şema şart	Fine-tuning	Davranış ve biçim eğitimle içselleştirilir
Hem davranış hem güncel bilgi	Fine-tuning + RAG birlikte	İkisinin güçlü yanlarını birleştirir
KVKK / on-prem / veri yurt içinde kalmalı	Kendi sunucuda SLM	Veri hiç dışarı çıkmaz
Çevrimdışı / uç cihaz / düşük gecikme	Küçük SLM (1B-3B), kuantize	Bağlantısız ve hızlı çalışır
Sınırlı GPU bütçesi, yine de fine-tune	QLoRA	Kuantizasyonla küçük GPU'ya sığar
Geniş, açık uçlu, düşük hacimli, mahremiyet sorunu yok	Büyük API modeli	Bu senaryoda büyük modelin esnekliği pratiktir
Büyük modelin davranışını ucuza taşımak	Distilasyon ile SLM eğitimi	Öğrenci model öğretmene yaklaşır, maliyet düşer

Bu tabloyu bir reçete değil, bir başlangıç pusulası olarak görün. Gerçek hayatta senaryolar iç içe geçer; önemli olan soruları doğru sırayla sormak.

Türkçe çalışan bir ekip için birkaç noktanın altını özellikle çizmek isterim, çünkü bunlar İngilizce kaynaklarda nadiren konuşulur.

Çok-dilli modelleri test edin, varsaymayın. Qwen3 gibi güçlü çok-dilli aileler Türkçe'de hoş sürprizler verebilir, ama her küçük model Türkçe'de aynı performansı göstermez. Bir modelin İngilizce'de parlaması, Türkçe'de de parlayacağı anlamına gelmez. Bu yüzden model seçimini kendi Türkçe değerlendirme setinizle yapın; pazarlama tablolarına değil, kendi ölçümünüze güvenin.

Türkçe'nin sondan eklemeli (agglutinative) yapısı tokenizasyonu zorlar. Türkçe'de tek bir kök, onlarca ek alarak uzun kelimelere dönüşebilir. Bu, bazı modellerde token verimsizliğine ve dolayısıyla hem maliyet hem bağlam penceresi açısından dezavantaja yol açar. Model seçerken Türkçe metinde token başına ne kadar verimli olduğuna bakmak gerçek bir fark yaratır.

Türkçe fine-tuning verisi bulmak zor, o yüzden üretmek gerekir. İngilizce için bol veri varken, sizin dar göreviniz için Türkçe veri çoğu zaman yoktur. Burada distilasyon ve sentetik veri yaklaşımı kurtarıcı olur: büyük, Türkçe'yi iyi bilen bir modelle örnek ürettirip, insan eliyle temizleyerek kendi küçük modelinizi eğitirsiniz. Pratikte en çok işime yarayan yöntem bu oldu.

KVKK ve veri ikametgâhı Türkçe projelerde çoğu zaman belirleyici. Yukarıda da değindim ama tekrar vurgulayayım: Türkiye'deki birçok kurumda hassas verinin yurt dışı bir API'ye gitmesi en baştan masadan kalkar. Bu da çoğu zaman tartışmayı doğrudan "kendi sunucumuzda koşan, fine-tune edilmiş bir SLM" noktasına taşır. Yani burada SLM, sadece maliyet değil, uyum (compliance) gerekçesiyle de kazanır.

Eğer bu yazıyı okuyup "tamam, ikna oldum, peki ben yarın ne yapayım" diyorsanız, sahada işe yaradığını gördüğüm sıralamayı paylaşayım.

Önce bir tek, dar ve acı veren işi seçin. Tüm kurumu dönüştürmeye çalışmayın; günde binlerce kez tekrarlanan, sıkıcı, kurallı bir işi bulun. Faturadan kalem çıkarma, destek talebi yönlendirme, sözleşme maddesi sınıflandırma gibi. Bu iş ne kadar darsa, ilk başarınız o kadar net olur.

Sonra veriyi toplayın ve temizleyin. Birkaç bin gerçekten temiz örnek hedefleyin. Format tutarlılığına takıntılı olun. Gerekirse büyük bir modelle sentetik örnek üretip insan eliyle gözden geçirin. Bir kısmını kenara, değerlendirme için ayırın ve sakın eğitime karıştırmayın.

Ardından uygun bir SLM seçip QLoRA ile başlayın. Türkçe işiniz için birkaç aday modeli kendi setinizle kıyaslayın. Tek bir GPU'da, QLoRA ile ilk adaptörünüzü eğitin. Bu adımın bir günde bitebildiğini gördüğünüzde, işin ne kadar erişilebilir olduğunu fark edeceksiniz.

Sonra dürüstçe değerlendirin. Hedef görevdeki başarıyı ve genel yeteneğin korunup korunmadığını ayrı ayrı ölçün. İnsan gözüyle örneklem inceleyin. Felaket unutma belirtisi varsa veriyi ve epoch sayısını gözden geçirin.

En sonunda kuantize edip vLLM ile servis edin, ve bilgi tazeliği gerekiyorsa üstüne RAG ekleyin. Üretime aldıktan sonra da trafiği örnekleyip izlemeyi bırakmayın; veri dağılımı kaydıkça modelinizi tazelemeniz gerekebilir.

Bu yolu izleyen kurumların ortak gözlemi şu oluyor: ilk projede edinilen kas hafızası, ikinci ve üçüncü projeyi katlanarak hızlandırıyor. Çünkü artık temel SLM'iniz, veri hattınız ve servis altyapınız hazır; her yeni dar görev için yalnızca yeni bir hafif adaptör eğitmeniz yetiyor. İşte 2026'da maliyet-etkin yapay zekânın gerçek sırrı bu: dev modele her şeyi yıkmak değil, doğru işi doğru küçük modele, doğru yöntemle öğretmek.

Bu yolda ilerlerken kafalarda dolaşan birkaç yaygın yanlış inanışı da düzeltmekte fayda var, çünkü bunlar projeleri daha başlamadan yanlış yöne sürüklüyor.

"Küçük model demek zayıf model demek." Hayır. Dar bir görevde, iyi veriyle fine-tune edilmiş 3B'lik bir model, o görevde devasa bir genel modeli rahatlıkla geçebilir. Çünkü siz o modeli tek bir işe odakladınız; o ise binlerce işi aynı anda idare etmeye çalışıyor. Uzmanlık her zaman genelciliği yener.

"Fine-tuning bir kere yapılır, biter." Gerçekte fine-tuning yaşayan bir süreçtir. Veri dağılımı kayar, iş kuralları değişir, yeni kenar durumlar ortaya çıkar. Olgun ekipler modeli düzenli aralıklarla, üretimden gelen yeni ve temizlenmiş örneklerle tazeler. PEFT'in güzelliği tam da burada: yeniden eğitim ucuz ve hızlı olduğu için bu tazeleme bir yük değil, rutin bir bakım haline gelir.

"Önce büyük modelle başlayalım, sonra küçültürüz." Bu çoğu zaman ters teper. Büyük modelle kurulan bir mimari, küçük modele geçerken baştan tasarlanmayı gerektirir; istem (prompt) stratejiniz, beklentileriniz, hata toleransınız değişir. Ben dar ve net işlerde doğrudan küçük modelle başlamayı, gerçekten gerekirse büyütmeyi öneriyorum. Aşağıdan yukarı büyümek, yukarıdan aşağı küçülmekten genellikle daha sağlıklı.

"Fine-tuning, RAG'ın yerine geçer." Defalarca vurguladım ama bir kez daha: bunlar rakip değil, tamamlayıcıdır. Biri davranışı, diğeri bilgiyi çözer. Birini diğerinin yerine koymaya çalışmak, çoğu başarısız projenin kök nedenidir.

Son olarak, "kendi modelimi koşturmak gerçekten ucuz mu" sorusunu dürüstçe ele alalım, çünkü bu hesap her zaman tek yönlü değildir. API modelinde maliyet token başınadır ve doğrudan kullanımla ölçeklenir; altyapı derdiniz olmaz ama hacim arttıkça fatura doğrusal şişer. Kendi SLM'inizi koşturduğunuzda ise önden bir mühendislik ve donanım maliyeti vardır; ama bu maliyet sabittir ve hacim arttıkça çağrı başına maliyetiniz hızla düşer.

Bu yüzden gözlemlediğim raporlanan ~%75'e varan tasarruflar, genellikle yüksek hacimli, dar görevlerde ortaya çıkıyor. Düşük hacimde kendi altyapınızı kurmak ekonomik olmayabilir; orada API daha mantıklıdır. Ama günde milyonlarca çağrıya çıkan, sabit ve dar bir iş yükünüz varsa, kırılma noktasını geçip kendi SLM'inize geçmek hem maliyet hem mahremiyet açısından net kazanç sağlar. Önemli olan bu kırılma noktasını duygusal değil, sayısal olarak hesaplamaktır: beklenen aylık çağrı hacmini, donanım ve bakım maliyetini, ve mühendislik eforunu aynı tabloya koyup karşılaştırın.

Benim sahadaki tavsiyem hep aynı: önce küçük bir pilotla kırılma noktanızı ölçün, sonra ölçeğe göre karar verin. Sayılar konuştuğunda, doğru aracın hangisi olduğu çoğu zaman kendiliğinden ortaya çıkar.