Smol Eğitim Rehberi:

Dünya Standartlarında LLM Geliştirmenin Sırları

Son model SLM eğitmenin ardındaki zorluklar, kararlar ve karmaşık gerçekler hakkındaki değerli bir Huggingface yazısının Türkçe çevirisidir.

Bu makale “The Smol Training Playbook: The Secrets to Building World-Class LLMs” yazısının Türkçe çevirisidir. Kaynağın aslında interaktif grafikler de bulunuyor, mutlaka bir göz atın ve beğeni bırakın.

1. Giriş

Günümüzde yüksek performanslı bir LLM eğitmek için gerçekten ne gerekiyor? Araştırmalara göre stratejik mimari seçimler, özenle seçilmiş veri kümeleri ve yeterli hesaplama gücünüz varsa sonuçlarınız parlak, ablasyon çalışmaları düzenli ve her karar açık ve mantıklıdır. Ancak bu raporlar sadece işe yarayanları gösterir. Ancak bu doğrulara erişinceye kadar yaşanan gece yarası dataloader hata ayıklamaları, loss’un zıplamalarını ve eğitimi sessizce sabote eden ince bir tensor parallelism hatasını göstermez. Gerçek dağınık daha yinelemeli ve son makaleye ulaşmayan detay kararlarla doludur.

SMOLLM3 11T token üzerinde eğitilmiş 3B çok dilli muhakeme modelini eğitim sürecimizde bize katılın. Daha öncesinde ölçeklenebilir veri kümelerini nasıl oluşturduğumuzu (FineWeb), sürecin her aşamasında en iyi değerlendirmelerin nasıl seçildiğini (The LLM Evaluation Guidebook) ile ele aldık. Şimdi tüm bunları bir araya getirerek güçlü bir yapay zeka modeli inşaa ediyoruz. Küçük ölçekli ablasyon çalışmalarının her zaman büyük ölçekte işe yaramadığını neden 1T token sonrasında bir eğitimi tekrar başlattığımızı, çok dilli mat ve kodlama hedeflerini dengelerken İngilizce performansını nasıl koruduğumuzu ve sonunda hibrit bir muhakeme modelini nasıl post-train ettiğimizi göreceksiniz.

Bu yazının temel alt parçaları:

• Eğitim pusulası (Training compass): Kendi modelinizi önceden eğitip eğitmemeniz gerektiğine dair üst düzey bir tartışmayı bu bölümde göreceksiniz. Melek yatırımcınızın tüm parasını yakmadan önce kendinize sormanız gereken temel soruları ve bu kararı sistematik biçimde nasıl ele alacağınızı birlikte inceliyoruz. Bu bölüm yüksek seviyededir; doğrudan teknik içeriğe geçmek isterseniz bunu atlayabilirsiniz.
• Ön-eğitim (Pretraining): Eğitim pusulasını takip eden bölümler, kendi pretraining hattınızı kurmak için sağlam bir tarif oluşturmanız adına bilmeniz gereken her şeyi kapsar: ablasyonları nasıl çalıştıracağınız, değerlendirmeleri nasıl seçeceğiniz, veri kaynaklarını nasıl karıştıracağınız, mimari seçimleri nasıl yapacağınız, hiperparametreleri nasıl ayarlayacağınız ve sonunda eğitim maratonuna nasıl dayanacağınız. Bu bölüm, sıfırdan ön-eğitim yapmayacak olsanız bile sürekli ön-eğitim (continued pretraining / mid-training) ile ilgileniyorsanız da geçerlidir.
• Son-eğitim (Post-training): Bu bölümde, önceden eğitilmiş modellerden maksimum verimi almak için gereken tüm teknikleri öğreneceksiniz. SFT, DPO ve GRPO ile başlayarak model birleştirme (model merging) gibi daha “karanlık sanatlar” ve simya benzeri yöntemlere kadar tüm post-training yelpazesini ele alıyoruz. Bu algoritmaları iyi çalışır hale getirmeye dair bilginin çoğu acı deneyimlerle öğrenilir; biz de umarız ki bazılarını sizin yerinize yaşamış oluruz.
• Altyapı (Infrastructure): Eğer pretraining bir kekse ve post-training onun üzerindeki krema ile kirazsa, altyapı da endüstriyel sınıf fırındır. O olmadan hiçbir şey olmaz; bozuksa da keyifli bir Pazar günü “pişirme” seansı bir yangın tehlikesine dönüşür. GPU kümelerini anlama, analiz etme ve hata ayıklama bilgisi internetin farklı kütüphanelerine, dokümantasyonlarına ve forumlarına dağılmıştır. Bu bölüm; GPU yerleşimi, CPU/GPU/düğüm/depolama arasındaki iletişim desenleri ve darboğazları nasıl tespit edip aşacağınızı kapsar.

2. Eğitim Pusulası: Neden → Ne → Nasıl

Makine öğrenmesi alanı optimizasyonla adeta takıntılı bir ilişki içindedir. Kayıp eğrilerine, model mimarilerine ve işlem verimliliğine odaklanırız; sonuçta makine öğrenmesi temelde bir modelin kayıp fonksiyonunu optimize etmekle ilgilidir. Ancak bu teknik ayrıntılara dalmadan önce çoğu zaman sorulmayan daha temel bir soru vardır: Bu modeli gerçekten eğitmeli miyiz?

Aşağıdaki ısı haritasında gösterildiği gibi, açık kaynak yapay zekâ ekosistemi neredeyse her gün dünya çapında modeller yayınlamaktadır: Qwen, Gemma, DeepSeek, Kimi, Minimax liste her ay daha da uzuyor.

Bunlar yalnızca araştırma prototipleri veya oyuncak örnekler değil: çok dilli anlama, kod üretimi ve akıl yürütme dahil olmak üzere şaşırtıcı derecede geniş kullanım alanlarını kapsayan üretim seviyesinde modellerdir. Çoğunun izin verici lisansları vardır ve bunları kullanmanıza yardımcı olmaya hazır aktif topluluklarla birlikte gelirler.

Bu da rahatsız edici bir noktayı gündeme getiriyor: Belki de kendi modelimizi eğitmeye gerek yok.

Bu, bir “LLM eğitme rehberi”ne garip bir başlangıç gibi görünebilir. Ancak başarısız olan birçok eğitim projesi kötü hiperparametreler ya da hatalı kod yüzünden değil; aslında ihtiyaç duyulmayan bir modeli eğitmeye karar verildiği için başarısız olmuştur. Bu yüzden eğitime başlamadan ve nasıl yapılacağına dalmadan önce iki soruyu yanıtlaman gerekir: Bu modeli neden eğitiyorsun? Hangi modeli eğitmelisin?

Bu sorulara net cevaplar olmadan, aylarca süren hesaplama gücünü ve mühendislik zamanını ya zaten dünyada var olan bir şeyi inşa ederek ya da daha kötüsü kimsenin ihtiyaç duymadığı bir şeyi üreterek boşa harcayabilirsin.

O hâlde “neden” sorusuyla başlayalım; çünkü amacını anlamadan, bundan sonra vereceğin hiçbir karar tutarlı olamaz.

Neden: Kimsenin Cevaplamak İstemediği Soru

Pratikte ne olduğunu açıkça söyleyelim. Birisi (şanslıysa) bir GPU kümesine erişim elde eder, belki bir araştırma hibesiyle, belki bir şirketin boş kapasitesi üzerinden, ve düşünce süreci kabaca şöyle ilerler: “100 H100’ümüz var, üç ay boyunca. Hadi bir model eğitelim!”

Model boyutu keyfi biçimde seçilir, veri kümesi eldeki ne varsa ondan derlenir. Eğitim başlar. Ve altı ay sonra, hem hesaplama bütçesi hem de ekip motivasyonu tüketilmiş halde, ortaya çıkan model aslında kimse tarafından kullanılmaz; çünkü en başta kimse “neden” sorusunu sormamıştır.

İşte bir model eğitmemeniz için bazı nedenler:

“Kendi modelimizi eğittik” söyleminin cazibesi güçlüdür, ancak çok fazla zaman ve kaynak yatırmadan önce şu soruyu sormak mantıklıdır: Bu modeli neden eğitmemiz gerekiyor?

Aşağıdaki akış şeması, büyük bir ön-eğitim projesine başlamadan önce izlenmesi gereken düşünme sürecini gösterir. Teknik açıdan bakıldığında, aslında ilk olarak yapmanız gereken şey; mevcut bir modeli sadece doğru şekilde prompt’layarak ya da ince ayar (fine-tuning) yaparak bu işi çözüp çözemeyeceğinizi bulmaktır.

Özelleştirilmiş ön-eğitimin (custom pretraining) anlamlı olabileceği temel olarak üç yaygın alan vardır: yeni araştırma yapmak istemeniz, üretim (production) kullanım senaryonuzun çok spesifik ihtiyaçları olması ya da açık model ekosistemindeki bir boşluğu doldurmak istemeniz. Her birine hızlıca bakalım.

Araştırma: Ne anlamak istiyorsunuz? LLM alanında yapılabilecek çok sayıda araştırma vardır. LLM araştırma projelerinin ortak noktası genellikle net tanımlanmış bir soruyla başlamanızdır:

• Bu yeni optimizör ile eğitimi 10B+ parametreli bir modele ölçekleyebilir miyiz? (“Muon is Scalable for LLM Training” çalışmasına bakınız.)
• Denetimli ince ayar (SFT) olmadan, yalnızca pekiştirmeli öğrenme (RL) ile akıl yürütme yetenekleri üretilebilir mi? (“DeepSeek-R1: Incentivizing Reasoning Capability in LLMs via Reinforcement Learning” çalışmasına bakınız.)
• Sadece sentetik ders kitabı verisiyle iyi küçük modeller eğitilebilir mi? (“Textbooks Are All You Need” çalışmasına bakınız.)
• Yalnızca açık lisanslı verilerle eğiterek rekabetçi performans elde edilebilir mi? (“The Common Pile v0.1: An 8TB Dataset of Public Domain and Openly Licensed Text” çalışmasına bakınız.)

Hipotezi mümkün olduğunca somut hale getirmek ve gerekli deney ölçeğini düşünmek, başarı şansını artırır.

Üretim (Production): Neden Mevcut Bir Modeli Kullanamazsınız?

Şirketlerin kullanım senaryoları için hazır (off-the-shelf) modelleri kullanamamasının üç ana nedeni vardır. Bunlardan ikisi teknik, diğeri ise yönetişim (governance) ile ilgilidir.

Kendi modelinizi eğitmenizin ilk nedeni alan özgüllüğü (domain specificity)’dir: Veriniz veya görevleriniz, mevcut modellerin iyi şekilde başa çıkamadığı son derece uzmanlaşmış bir kelime dağarcığı veya yapısal özellik içerdiğinde ortaya çıkar. Örneğin şunları eğitmek isteyebilirsiniz:

• Kendine özgü bir sözlük ve uzun-menzilli bağımlılıklar gerektiren bir DNA modeli
• Alan özel jargonuna ve mantığına derin hâkimiyet gerektiren bir hukuk veya finans modeli

Buna bağlı ikinci bir neden dağıtım kısıtlarıdır: Donanımınıza, gecikme gereksinimlerinize veya gizlilik ihtiyaçlarınıza özel bir model gerektiğinde ortaya çıkar. Örneğin, bir drone üzerinde çalışan bir LLM ya da FPGA gibi özel donanımlara sahip yerinde (on-prem) bir sistem buna örnektir.

Basit bir test şudur: Birkaç gün boyunca Qwen3, Gemma 3 veya güncel başka bir SOTA model üzerine geliştirme yapmayı deneyin. İstem mühendisliği, araç kullanımı veya eğitim sonrası (post-training) yöntemlerle performans hedeflerinize ulaşabiliyor musunuz? Eğer ulaşamıyorsanız, muhtemelen kendi modelinizi eğitme zamanı gelmiştir.

Hatta eğitim sonrası bütçeniz gereksinimlerinizi karşılamak için çok yüksek olsa bile, sıfırdan eğitim yapmaktan daha ucuz olabilir. Modelinizi 1T token ile ince ayarlamak (fine-tuning), sıfırdan 10T+ token ile eğitim yapmaktan daha ekonomiktir.

Bu noktada LLM eğiticileri bunu “post-training” yerine mucizevi şekilde “mid-training” olarak adlandırmaya başlar.

Kendi kurum içi dil modelinizi geliştirmenin üçüncü nedeni ise güvenlik ve yönetişimdir: Düzenlemeye tabi bir sektörde veya yüksek riskli bir uygulamada çalışıyorsanız, eğitim verisi, model davranışı ve güncelleme döngüleri üzerinde tam kontrol sahibi olmanız gerekir. Modele tam olarak neyin girdiğini bilmek ve bunu düzenleyicilere kanıtlayabilmek zorundasınız. Bazı durumlarda, kendi modelinizi geliştirmekten başka seçeneğiniz olmayabilir.

Bunlar kurum içi model eğitmenin temel nedenleridir, peki ya açık modeller yayınlayan şirketler veya kuruluşlar?

Stratejik Açık Kaynak: Doldurabileceğiniz Bir Boşluk Görüyor musunuz?

Deneyimli yapay zekâ laboratuvarlarının yeni açık modeller yayınlamasının en yaygın nedenlerinden biri, açık kaynak ekosisteminde belirli bir boşluk veya yeni bir yapay zekâ kullanım alanı tespit etmiş olmalarıdır.

Bu desen genellikle şu şekilde ortaya çıkar: Daha az keşfedilmiş bir alan fark edersiniz, örneğin, çok uzun bağlam (context) destekleyen güçlü cihaz içi (on-device) modellerin olmaması, çok dilli modellerin var olması ama düşük kaynaklı dillerde zayıf kalması ya da alanın Genie 3 gibi etkileşimli dünya modellerine doğru kayması, fakat bu alanda iyi bir açık ağırlıklı (open-weight) modelin bulunmaması gibi.

Daha iyi bir şey yapabileceğinize inanırsınız; belki daha iyi eğitim verisi derlemişsinizdir, daha iyi eğitim tarifleri (training recipes) geliştirmişsinizdir ya da başkalarının yapamadığı ölçekte aşırı eğitim (overtraining) yapacak hesaplama gücüne sahipsinizdir. Hedefiniz “en iyi model” gibi soyut bir şey değil, nettir: “cihaz içi kullanım için en iyi 3B model” ya da “1 milyon token bağlam penceresine sahip ilk küçük model” gibi.

Bu gerçek bir hedeftir ve başarılı olunduğunda değer üretir: Geliştiriciler modelinizi kullanır, başkaları için altyapı hâline gelir ya da teknik güvenilirlik kazandırır. Ancak başarı deneyim gerektirir. Gerçekten neyin mümkün olduğunu ve rekabetçi bir alanda nasıl güvenilir şekilde ilerleneceğini bilmeniz gerekir. Bunu somutlaştırmak için Hugging Face’te bu soruya nasıl yaklaştığımıza bakalım.

Hugging Face’in Yolculuğu

Peki Hugging Face neden açık modeller eğitiyor? Cevap basit: Açık kaynak ekosistemi için faydalı olan ve önemli boşlukları dolduran şeyler inşa ediyoruz.

Milyonlarca açık ağırlıklı model olmasına rağmen, tamamen açık modeller eğiten kuruluş sayısı oldukça azdır. Hugging Face’e ek olarak Ai2 ve Stanford’un Marin topluluğu bu alandaki örneklerdendir.

Bu çalışmalar; veri kümeleri, araçlar ve model eğitimini kapsar. Başlattığımız her LLM eğitimi projesi, bir boşluk fark edip anlamlı bir katkı sağlayabileceğimize inanmakla başladı.

İlk LLM projemizi GPT-3 (Brown ve ark., 2020) yayınlandıktan sonra başlattık. O dönemde açık bir alternatif geliştiren başka kimse yokmuş gibi görünüyordu ve bilginin yalnızca birkaç endüstri laboratuvarında kilitli kalmasından endişe ediyorduk. Bu nedenle GPT-3’ün açık bir versiyonunu eğitmek için BigScience atölyesini başlattık. Ortaya çıkan model BLOOM oldu. Bu model, 175B parametreli bir modeli eğitmek için eğitim yığını, tokenizer ve ön-eğitim korpusunu bir yıl boyunca oluşturan onlarca katkıcı tarafından geliştirildi.

BLOOM’un halefi 2022’de gelen StarCoder oldu (Li ve ark., 2023). OpenAI, GitHub Copilot için Codex’i geliştirmişti (Chen ve ark., 2021) ancak bu kapalı kaynaklıydı. Açık kaynak bir alternatif oluşturmak ekosistem için açık bir değer yaratacaktı. Bu nedenle ServiceNow ile BigCode çatısı altında The Stack veri kümesini oluşturduk ve Codex’i yeniden üretmek için StarCoder 15B’yi eğittik. StarCoder2 (Lozhkov ve ark., 2024), daha uzun eğitim yapabileceğimizi öğrenmemizden ve daha küçük modellerin daha uzun süre eğitildiğinde tek bir büyük modelden daha değerli olabileceğini fark etmemizden doğdu. O dönem açık kod modelleri için görülmemiş şekilde, çoklu trilyon token üzerinde 3B/7B/15B model ailesi eğittik.

SmolLM ailesi benzer bir örüntüyü takip etti. Güçlü küçük modellerin çok az olduğunu fark ettik ve güçlü bir ön-eğitim veri kümesi olan FineWeb-Edu’yu (Penedo ve ark., 2024) yeni oluşturmuştuk. SmolLM (135M/360M/1.7B) ilk versiyondu. SmolLM2 (Allal ve ark., 2025) daha iyi veri ve daha uzun eğitim üzerine odaklanarak birden fazla alanda SOTA performansa ulaştı. SmolLM3 ise 3B parametreye ölçeklenirken hibrit akıl yürütme, çok dillilik ve uzun bağlam gibi 2026’da topluluğun değer verdiği özellikleri ekledi.

Bu örüntü yalnızca ön-eğitimle sınırlı değil: Zephyr’i (Tunstall ve ark., 2023) Direct Preference Optimization (DPO)’nun ölçeklenebilirliğini göstermek için eğittik, Open-R1 ile DeepSeek-R1’in damıtma (distillation) hattını yeniden üretmeye çalıştık ve Olimpiyat Kodlama (IOI) seviyesinde SOTA performans gösteren OlympicCoder’ı yayınladık. Ayrıca farklı modalitelerde SmolVLM (Marafioti ve ark., 2025) ile görme, SmolVLA (Shukor ve ark., 2025) ile robotik alanlarını da keşfettik.

Eğer HF bilim projeleriyle ilgileniyorsanız, genel bir bakışı burada bulabilirsiniz: https://huggingface.co/science

Umarım bu bölüm, neden model eğitmek istediğinizi derinlemesine düşünmenin değerli olduğuna sizi ikna etmiştir. Bu kılavuzun geri kalanında, bu içsel sorgulamayı yaptığınızı ve modeli eğitmek için meşru bir nedeniniz olduğunu varsayacağız.

Ne: Hedefleri Kararlara Dönüştürmek

Artık neden eğitim yaptığınızı bildiğinize göre, neyi eğitmelisiniz? “Ne” derken model türünü (yoğun/dense, mixture of experts, hibrit, yeni bir şey), model boyutunu, mimari detaylarını ve veri karışımını kastediyoruz. “Neden”i netleştirdikten sonra “ne”yi türetebilirsiniz.

Örneğin:

• Cihaz üzerinde çalışan hızlı model → küçük ve verimli model
• Çok dilli model → büyük tokenizer kelime dağarcığı
• Çok uzun bağlam → hibrit mimari

Kullanım senaryosundan gelen bu kararların yanında, eğitimi daha stabil, daha örnek-verimli (sample efficient) veya daha hızlı hale getiren seçimler de vardır. Bu kararlar her zaman net değildir, ancak karar sürecini kabaca şu aşamalara bölebilirsiniz:

• Planlama: Deneylere başlamadan önce, kullanım senaryonuzu hangi bileşen kararlarına dönüştürmeniz gerektiğini haritalayın. Dağıtım (deployment) ortamınız model boyutu kısıtlarını belirler. Zaman çizelgeniz hangi mimari riskleri alabileceğinizi belirler. Hedef yetenekleriniz veri kümesi gereksinimlerini belirler. Bu aşama, “neden” kısmındaki her kısıtı “ne” kısmındaki somut teknik özelliklere bağlama aşamasıdır.
• Doğrulama: Bir başlangıç noktanız ve olası değişiklikler listeniz olduğunda, bunları sistematik olarak test edin. Test etmek pahalı olduğu için, yalnızca kullanım senaryonuz için gerçekten performans artırma potansiyeli olan veya eğitimi optimize eden değişikliklere odaklanın. Bu aşamada “Every Big Model Starts with a Small Ablation” bölümünde anlatılan ablation (çıkarım/deneysel sadeleştirme testleri) yaklaşımı devreye girer.

Sadece testleri nasıl çalıştıracağınızı değil, neyin test edilmeye değer olduğunu belirlemeyi öğrenin. Mükemmel ama alakasız ablasyonlar, hatalı ve dağınık ablasyonlar kadar hesaplama israfı yaratır.

Sonraki bölümlerde, modelinizi tanımlamak için sahip olduğunuz tüm seçenekleri ve bunları sistematik deneylerle nasıl daraltabileceğinizi öğreneceksiniz. Oraya geçmeden önce, kendi modellerimizi eğitirken ve harika LLM’ler geliştiren diğer ekipleri gözlemlerken edindiğimiz ekip ve proje kurulumuna dair bazı deneyimleri paylaşmak istiyoruz.

Süper Güç: Hız ve Veri

Elbette bir işi yapmanın birden çok yolu var, ancak başarılı büyük dil modeli (LLM) eğitim ekiplerini sürekli olarak öne çıkaran şeyin iterasyon hızı olduğunu gözlemledik. LLM eğitimi gerçekten “yaparak öğrenme” disiplinidir: Ne kadar sık eğitim yaparsanız, ekibiniz o kadar hızlı gelişir. Bu yüzden yılda bir model eğiten ekiplerle, üç ayda bir model eğiten ekipler arasında, ikinciler çok daha hızlı ilerler. Qwen ve DeepSeek ekipleri buna örnek olarak gösterilebilir. Artık sektörde tanınan bu ekipler, hızlı bir tempoyla sürekli yeni modeller yayınlama konusunda uzun bir geçmişe sahip.

İterasyon hızının yanı sıra, LLM eğitiminde en etkili unsur veri kürasyonudur. Modeli geliştirmek için mimari seçimlere odaklanma eğilimi doğaldır, ancak LLM eğitiminde gerçekten başarılı olan ekipler her şeyden çok yüksek kaliteli veriye takıntılı olanlardır.

İterasyon hızıyla bağlantılı bir diğer unsur ise ekip büyüklüğüdür. Temel ön-eğitim (pretraining) görevleri için, yeterli hesaplama gücüne sahip küçük bir ekip yeterlidir. Bugün Llama 3 benzeri bir modeli önceden eğitmek için muhtemelen yalnızca iki veya üç kişiye ihtiyaç duyarsınız. Ancak daha çeşitli eğitimlere ve alt görevlere (çok modlu sistemler, çok dilli modeller, eğitim sonrası süreçler vb.) yöneldikçe, her alanda uzmanlaşmak için ekibinize birkaç kişi daha eklemeniz gerekir.

Bu nedenle, küçük ama iyi donanımlı bir ekip kurun ve her iki-üç ayda bir yeni bir model geliştirin; kısa sürede en üst seviyeye tırmanırsınız. Bu kılavuzun geri kalanı, bu ekibin günlük teknik faaliyetlerine odaklanacaktır.

3. Her Büyük Model Küçük Bir Ablasyon ile Başlar

Bir LLM (Büyük Dil Modeli) eğitmeye başlamadan önce, modelin performansını ve eğitim verimliliğini şekillendirecek birçok karar vermemiz gerekir. Hangi mimari kullanım senaryomuza en iyi şekilde hizmet eder? Hangi optimizer ve öğrenme oranı (learning rate) planı kullanılmalı ve hangi veri kaynakları bir araya getirilmelidir?

Bu kararların nasıl verildiği sıkça sorulan bir sorudur. İnsanlar bazen bunun derin düşünme gerektirdiğini varsayar. Stratejik düşünme elbette önemlidir, ancak yalnızca akıl yürütme yeterli değildir. LLM’lerde her şey her zaman sezgisel değildir ve “işe yaraması gerekir” diye kurulan hipotezler pratikte her zaman karşılık bulmaz.

Örneğin, “en yüksek kaliteli veri” olarak görünen şeyleri kullanmak her zaman daha güçlü modeller üretmez. Örneğin arXiv’i ele alalım; burası insanlığın bilimsel bilgisinin geniş bir koleksiyonudur. Sezgisel olarak, bu kadar zengin STEM verisiyle eğitilen modellerin daha üstün olması gerekir, değil mi? Ancak pratikte durum böyle değildir; özellikle daha küçük modellerde bu durum performansı hatta düşürebilir (Shao ve ark., 2024). Neden? Çünkü arXiv makaleleri bilgi açısından zengin olsa da oldukça uzmanlaşmış ve dar bir akademik üslupla yazılmıştır; bu da modellerin en iyi öğrendiği daha çeşitli ve genel metinlerden oldukça farklıdır.

Peki, problemi uzun uzun düşünmek işe yaramıyorsa neyin işe yaradığını nasıl bilebiliriz? Çok sayıda deney yaparız. Makine öğrenmesi saf matematik değil, aslında büyük ölçüde deneysel bir bilimdir.

Birçok açıdan makine öğrenmesi, istatistiksel mekaniğin keşfinden önceki termodinamiğe benzer: Derin teorik açıklamalar hâlâ gelişmekte olsa da, oldukça iyi çalışan güvenilir ampirik yasalar ve tasarım ilkelerimiz vardır.

Bu deneyler birçok kritik kararımızı yönlendireceği için, onları doğru şekilde kurmak son derece önemlidir. Temel olarak istediğimiz iki ana özellik vardır:

• Hız: Mümkün olduğunca hızlı çalışmalı ki sık sık iterasyon yapabilelim. Ne kadar çok ablasyon çalıştırırsak, o kadar çok hipotez test edebiliriz.
• Güvenilirlik: Güçlü ayırt edici kapasite sunmalıdır. Ölçtüğümüz metrikler erken aşamada farklı kurulumları anlamlı şekilde ayırt edemiyorsa, ablasyonlarımız çok az bilgi verebilir (ve gürültülü ise, yanlış sinyalleri takip etme riskimiz vardır!). Daha fazla ayrıntı için FineWeb’i 1000+ dile ölçekleme üzerine blog yazısına bakabilirsiniz.

Ancak ablasyonları kurmadan önce, mimari türü ve model boyutu hakkında bazı temel kararlar vermemiz gerekir. Bu kararlar, pusulamız tarafından yönlendirilerek hangi eğitim çerçevesinin kullanılacağını, hesaplama bütçesinin nasıl dağıtılacağını ve hangi temel modelin başlangıç noktası olacağını etkiler.

SmolLM3 için, küçük ve cihaz üzerinde çalışacak modelleri hedeflediğimiz için 3B parametreli yoğun (dense) Llama tarzı bir mimari tercih ettik. Ancak “Model Mimarisi Tasarlama” bölümünde göreceğiniz gibi, kullanım durumunuza bağlı olarak mixture of experts (MoE) ya da hibrit bir model daha uygun olabilir ve farklı model boyutları farklı ödünleşimler (trade-off’lar) içerir. Bu seçimleri ilerleyen bölümlerde ayrıntılı olarak inceleyecek ve nasıl karar vereceğinizi göstereceğiz. Şimdilik en pratik ilk adımla başlayalım: bir temel model seçmek

Temel Belirlemek

Her başarılı model, kanıtlanmış bir temel üzerine inşa edilir ve bunu kendi ihtiyaçlarına göre değiştirir. Qwen ekibi ilk model ailesini eğitirken (Bai ve ark., 2023) LLaMA’nın mimarisinden başlamıştır. Meta, LLaMA 3’ü eğitirken LLaMA 2’yi temel almıştır. Kimi K2 ise DeepSeek-V3’ün MoE (Mixture of Experts) mimarisini başlangıç noktası olarak kullanmıştır. Bu durum yalnızca mimariler için değil, aynı zamanda eğitim hiperparametreleri ve eniyileme yöntemleri için de geçerlidir.

Neden böyle? İyi mimariler ve eğitim kurulumları tasarlamak, birçok organizasyonun yıllar süren iterasyonlarını gerektirir. Standart Transformer yapısı ve Adam gibi eniyileyiciler binlerce deney boyunca rafine edilmiştir. Hata modları keşfedilmiş, kararsızlıklar giderilmiş, uygulamaları eniyilenmiştir (optimize edilmiştir). Kanıtlanmış bir temelden başlamak, bu birikmiş bilginin tamamını devralmak demektir. Sıfırdan başlamak ise her problemi yeniden keşfetmek anlamına gelir.

İyi bir başlangıç noktası seçebilmek için bir mimari şu özellikleri karşılamalıdır:

• Kısıtlarınızla uyumlu olmalı: Hedef dağıtım ortamınıza ve kullanım senaryonuza uygun olmalı.
• Ölçekte kanıtlanmış olmalı: Benzer veya daha büyük ölçekte (trilyon-token seviyesinde) başarılı şekilde çalıştığı gösterilmiş olmalı.
• İyi dokümante edilmiş olmalı: Açık modellerde doğrulanmış ve işe yaradığı bilinen hiperparametre kümelerine sahip olmalı.
• İyi framework desteği olmalı: Hem eğitim hem de inference (çıkarım) için kullandığınız framework’ler tarafından desteklenmeli.

Aşağıda, 2025 itibarıyla (yazının yazıldığı dönemde, 2026 başı) farklı mimariler ve model boyutları için güçlü başlangıç temel seçeneklerinin eksik olmayan bir listesi yer almaktadır (2026 Mayıs’a göre güncellenmiştir):

Mimari (architecture) türünüzü belirleyin ve sahip olmasını istediğiniz parametre sayısına en yakın bir temel (baseline) seçin. Bunu çok fazla düşünerek karmaşıklaştırmayın; çünkü başladığınız mimari sabit ve değişmez değildir. Bir sonraki bölümde, bu temel yapıdan nasıl sizin için en uygun nihai mimariye ulaşabileceğinizi göreceksiniz.

Temelinizi Modifiye Etmek: Risksizleştirme Disiplini

Artık kullanım senaryonuza uyan ve çalışan bir temel (baseline) elde ettiniz. Burada durabilir, modeli eğitebilir ve (veri karışımınız iyiyse) büyük olasılıkla makul bir sonuç alabilirsiniz. Birçok başarılı proje tam olarak bunu yapar. Ancak temel modeller sizin özel kısıtlarınıza göre optimize edilmez; onları oluşturanların kullanım senaryoları ve dağıtım hedeflerine göre tasarlanırlar. Bu da, hedeflerinize daha iyi uyum sağlamak için yapılabilecek bazı değişikliklerin muhtemelen var olduğu anlamına gelir.

Fakat her mimari değişiklik risk taşır: Performansı artırabilir, ciddi şekilde düşürebilir ya da hiçbir etki yapmadan sadece deney maliyetini boşa harcayabilir.

Sizi doğru yolda tutan disiplin “risk azaltma (derisking)” yaklaşımıdır: Bir değişikliği, işe yaradığını test etmeden asla uygulamayın.

Ne zaman risksizleştirilmiş sayılır? Bir değişiklik, hedeflediğiniz yeteneklerde performansı artırdığı veya performansı kabul edilebilir sınırların ötesinde düşürmeden anlamlı bir fayda sağladığı (örneğin daha hızlı çıkarım, daha düşük bellek kullanımı veya daha yüksek stabilite) test edilerek gösterildiğinde riskleri azaltılmış (derisked) kabul edilir.

Zor olan kısım şudur: baseline ve eğitim kurulumunuzda değiştirebileceğiniz çok sayıda bileşen vardır; bunlar dikkat mekanizmaları, pozisyonel kodlama yöntemleri, aktivasyon fonksiyonları, eniyileyiciler, eğitim hiperparametreleri, normalizasyon şemaları, model mimarisi ve daha fazlası. Her biri potansiyel bir deneydir ve bu bileşenler çoğu zaman doğrusal olmayan şekillerde birbirini etkiler. Ne zamanınız ne de hesaplama kaynağınız her şeyi test etmeye ya da tüm etkileşimleri keşfetmeye yeter.

Bu yüzden işe, umut vadeden değişiklikleri mevcut temel’inize karşı test ederek başlayın. Bir şey işe yararsa onu yeni temel hattınıza dahil edin ve sonraki değişikliği onun üzerine test edin. Eğer hesaplama bütçeniz yeterliyse, değişiklikleri tek tek test edip “birini dışarıda bırakma” (leave-one-out) analizi de yapabilirsiniz. Ancak her hiperparametreyi kapsayan kapsamlı ızgara aramalarına veya her mimari varyantını denemeye kapılmayın.

ScaleRL makalesine (Khatri ve ark., 2025) bu metodolojinin pratikte nasıl uygulandığına dair iyi bir örnek olarak bakabilirsiniz.

Stratejik deney yapma Deney yapmayı bilmek yeterli değildir; hangi deneylerin yapılmaya değer olduğunu da bilmelisiniz. Bir değişikliği test etmeden önce şu iki soruyu sorun:

• Bu değişiklik benim özel kullanım senaryoma yardımcı olur mu?
• Bu değişiklik eğitim sürecimi eniyiler mi?

Eğer bir değişiklik bu iki hedeften hiçbirine net şekilde hizmet etmiyorsa, onu atlayın.

Artık stratejik planlama ile hangi fikirlerin umut vadettiğini nasıl seçeceğinizi biliyorsunuz. Şimdi sıra ampirik doğrulamaya geliyor. Sonraki bölümlerde bu değişiklikleri pratikte nasıl test edeceğinizi göstereceğiz: güvenilir deneyler nasıl kurulur, sonuçlar nasıl yorumlanır ve sık yapılan hatalardan nasıl kaçınılır. Ardından ilerleyen bölümlerde popüler mimari, veri, altyapı ve eğitim kararlarının nasıl test edildiğine dair somut örnekler göreceksiniz.

Bir Eğitim Yazılımı Çerçevesi Seçmek

Modelimizi eğitmek ve dolayısıyla tüm ablasyon çalışmalarımızı yürütmek için hangi yazılım çerçevesini kullanacağımıza karar vermemiz gereken ilk şey budur.

Ablasyonlar arasında ve nihai çalışmada eğitim yazılım çerçevesini değiştirmeyin. Bu, yalnızca soruna sebep olur.

Eğitim yazılım çerçevesi seçimi üç temel kriter arasında bir denge kurmayı gerektirir:

• Yazılım çerçevesi, hedef mimarimizi desteklemeli ya da onu kolayca genişletmemize olanak vermelidir.
• Stabil olmalı ve üretim hattına hazır olmalı; eğitim sırasında gizemli bir şekilde bozulma eğiliminde olmamalıdır.
• Yüksek veri aktarım hızı sağlamalıdır ki hızlı iterasyon yapabilelim ve hesaplama bütçemizi verimli kullanabilelim.

Pratikte bu gereksinimler birbirleriyle çelişebilir ve çeşitli ödünleşimler doğurabilir. Şimdi mevcut seçeneklere bakalım (2026 Mayıs ayı için güncellenmiştir):

Bu tablo, modern büyük dil modeli (LLM) eğitim ekosisteminde kullanılan başlıca framework’ler arasındaki temel ödünleşimleri özetler. İlk üç yazılım çerçevesi için satır sayısı karşılaştırmaları TorchTitan teknik raporuna (Liang et al., 2025) dayanmaktadır. Ancak 2026 itibarıyla önemli bir değişim vardır: bu sistemler artık birbirine rakip bağımsız araçlar olmaktan ziyade çoğu zaman birlikte kullanılan katmanlı bir eğitim stack’i (ör. FSDP2 + Megatron-Core + TorchTitan) haline gelmiştir.

Megatron-Core (eski Megatron-LM), NVIDIA tarafından geliştirilen ve uzun süredir büyük ölçekli model eğitimlerinde muharebede sınanmış olan ana dağıtık paralellik motorudur. Kimi gibi, frontier modellerin eğitiminde kullanılmıştır ve yüksek veri aktarımı sunar. 2025–2026 döneminde Megatron-LM büyük ölçüde Megatron-Core’a evrilmiştir. Tensor parallelism, pipeline parallelism ve expert parallelism (MoE) gibi bileşenleri modüler şekilde sunar. Güçlü performans sağlarken sistem karmaşıklığı yüksektir ve ileri seviye paralellik kombinasyonlarında debug ve geliştirme zordur.

DeepSpeed, ZeRO optimizasyonlarının öncüsü olarak BLOOM ve GLM gibi modellerin eğitiminde kritik rol oynamıştır. Güncel ekosistemde rolü değişmiştir: artık daha çok bellek optimizasyonu, CPU/NVMe offload ve inference runtime katmanı olarak kullanılır. ZeRO-1/2/3 hâlâ yaygın olsa da birçok modern PyTorch-native pipeline FSDP2’ye kaymıştır. Bu nedenle DeepSpeed, özellikle hibrit sistemler ve legacy uyumluluk gerektiren yapılarda güçlüdür ancak kod tabanı büyük ve karmaşıktır.

FSDP2 (PyTorch), PyTorch’un modern ölçekleme standardıdır ve Fully Sharded Data Parallel yaklaşımının yeni nesil implementasyonudur. Birçok sistemde ZeRO’nun yerini almaya başlamıştır. Model parametrelerini shard ederek GPU bellek kullanımını optimize eder ve PyTorch-native pipeline’larda daha sade bir alternatif sunar. Ancak Megatron-Core kadar kapsamlı tensor/pipeline/expert parallelism kontrolü sağlamaz; genelde diğer sistemlerle birlikte kullanılır.

TorchTitan, PyTorch ekosisteminin modern büyük ölçekli eğitim için geliştirdiği referans eğitim çerçevesidir. Megatron-Core ve FSDP2 ile entegre çalışarak uçtan uca eğitim tarifleri, kıyaslama ve dağıtık eğitim konfigürasyonları sağlar. En büyük avantajı modüler ve okunabilir yapısıdır, bu da hızlı deney yapmayı kolaylaştırır. Ancak hâlâ aktif geliştirme aşamasında olduğu için bazı uç durum senaryolarda Megatron-Core + DeepSpeed kadar muharebede sınanmış (battle-tested) değildir.

Nanotron, Hugging Face tarafından geliştirilen minimal bir öneğitim çerçevesidir. Amaç, dağıtık eğitim sürecini sade ve anlaşılır hale getirmektir. Küçük ve orta ölçekli modellerin eğitimi için idealdir ve SmolLM gibi araştırma projelerinde kullanılmıştır. Ancak üretim ölçeğinde Megatron-Core + FSDP2 kombinasyonu kadar kapsamlı değildir ve özellikle MoE gibi ileri özelliklerde gelişimi devam etmektedir.

MaxText, Google tarafından TPU ekosistemi için geliştirilmiş JAX tabanlı bir büyük ölçekli LLM eğitim çerçevesidir. TPU ağ yapısı (mesh) mimarisine özel olarak optimize edilmiştir ve özellikle Google’ın iç altyapısında ve TPU kümelerinde kullanılır. GPU tabanlı Megatron/FSDP ekosistemine alternatif olarak konumlanır. Ancak TPU bağımlılığı nedeniyle genel amaçlı kullanım alanı daha sınırlıdır ve öğrenme eğrisi yüksektir.

Colossal-AI, esnek dağıtık eğitim ve paralellik yöntemleri sunan alternatif bir framework’tür. Hibrit paralellik, memory optimization ve pipeline training gibi özellikler sağlar. Akademik ve niş üretim senaryolarında kullanılır ancak Megatron-Core veya PyTorch FSDP2 kadar standart hale gelmemiştir. Bu nedenle ekosistemde daha “alternatif” ve deneysel bir konumda yer alır.

Nanotron gibi sıfırdan framework geliştirme yaklaşımı, mimariyi tamamen kontrol etme ve sistemi derinlemesine anlama avantajı sağlar. Bu yaklaşım Ultra-Scale Playbook gibi pratiklerin oluşmasına katkı sağlamıştır. Ancak ciddi mühendislik maliyeti vardır: debug süreci zorlaşır, eksik özellikler zamanla eklenmelidir ve üretim stabilitesi başlangıçta düşüktür. Bu nedenle birçok ekip mevcut çerçeveleri fork ederek kendi ihtiyaçlarına göre genişletmeyi tercih eder. TorchTitan veya Megatron-Core tabanlı iç eğitim yığınları bu yaklaşımın yaygın örnekleridir.

Sonuç olarak framework seçimi artık tek bir aracın diğerine üstünlüğü şeklinde değerlendirilmemelidir. Daha doğru yaklaşım; hangi paralellik motorunun, hangi bellek yönetimi katmanının ve hangi orkestrasyon yapısının birlikte kullanılacağının sistem düzeyinde ele alınmasıdır. Seçim yapılırken ekip deneyimi, hedef model ölçeği, donanım altyapısı, geliştirme süresi ve hedeflenen özellikler belirleyici olur.

Birden fazla framework ihtiyaçları karşılıyorsa, gerçek donanım üzerinde throughput ve stabilite testleri yaparak karşılaştırma yapmak en doğru yöntemdir. Bu süreçte ayrıca hız testleri ve hızlı prototipleme denemelerinde, genellikle daha basit kod tabanına sahip çözümler daha hızlı sonuç verir ve pratikte avantaj sağlayabilir.

Ablasyon Kurulumu

Çerçeveyi seçtikten sonra artık ablasyon ile sadeleştirme ve analiz deneyleri düzeneğimizi tasarlamamız gerekiyor. Hızlıca yineleme yapabileceğimiz kadar hızlı, ancak sonuçların anlamlı sinyal üretecek ve nihai modele aktarılabilecek kadar büyük deneylere ihtiyacımız var.

Ablasyon çalışmalarının amacı, küçük ölçekte deneyler yürütmek ve sonuçları nihai üretimdeki çalışmaya güvenle genelleyebilmemizi sağlayacak çıktılar elde etmektir.

İki ana yaklaşım bulunmaktadır. Birincisi, hedef model boyutumuzu alıp daha az token ile eğitmek. SmolLM3 ablasyon çalışmalarında, son 11T token yerine tam 3B modeli 100B token üzerinde eğittik. İkincisi, eğer hedef modelimiz çok büyükse, ablasyon için daha küçük bir vekil model eğitebiliriz. Örneğin Kimi ekibi, 32B aktif parametreye sahip 1T parametreli K2 modelini geliştirirken, tüm ablasyonları tam boyutta yapmak aşırı maliyetli olacağından, bazı ablasyonları 0.5B aktif parametreli 3B MoE model üzerinde gerçekleştirdiler (Team et al., 2025).

Önemli bir soru, bu küçük ölçekli bulguların gerçekten aktarılıp aktarılmadığıdır. Deneyimlerimize göre, küçük ölçekte performansı düşüren bir şey varsa, bunu büyük ölçekte güvenle elersiniz. Ancak küçük ölçekte işe yarayan bir şey için, bu bulguların daha büyük ölçeklere genellenme olasılığının yüksek olduğunu söyleyebilmek adına yeterli miktarda token ile eğitim yaptığınızdan emin olmanız gerekir. Eğitim süresi ne kadar uzun ve ablasyon modelleri nihai modele ne kadar yakınsa, sonuçlar o kadar güvenilir olur.

Tüm ablasyonlar için temel bir vanilla Transformer kullanmaya karar verdik. Ana kurulumumuz, Llama 3.2 1B mimarisini takip eden 1B parametreli bir Transformer olup 45B token üzerinde eğitilmiştir. Bu eğitim, 8 H100 GPU’luk bir düğümde Nanotron yapılandırması kullanılarak yaklaşık bir buçuk gün sürer (GPU başına saniyede 42k token).

Model boyutu için Chinchilla-optimal değer yaklaşık 35B olsa da, daha stabil sinyal elde etmek için 45B token ile eğitiyoruz.

Temel 1B konfigürasyonumuz, tüm temel eğitim detaylarını yapılandırılmış bir YAML formatında içerir. Ana bölümleri aşağıda bulabilirsiniz:

## Veri kümeleri ve karıştırma ağırlıkları
data_stages:
- data:

    dataset:
      dataset_folder:
      - fineweb-edu
      - stack-edu-python
      - finemath-3plus

      dataset_weights:
      - 0.7
      - 0.2
      - 0.1

## Model mimarisi, Llama 3.2 1B konfigürasyonu
model:
  model_config:
    hidden_size: 2048
    num_hidden_layers: 16
    num_attention_heads: 32
    num_key_value_heads: 8  
    intermediate_size: 8192
    max_position_embeddings: 4096
    rope_theta: 50000.0
    tie_word_embeddings: true

## Eğitim hiperparametreleri, kosinüs zamanlayıcısı ile AdamW
optimizer:
  clip_grad: 1.0
  learning_rate_scheduler:
    learning_rate: 0.0005
    lr_decay_starting_step: 2000
    lr_decay_steps: 18000
    lr_decay_style: cosine
    lr_warmup_steps: 2000
    lr_warmup_style: linear
    min_decay_lr: 5.0e-05
  optimizer_factory:
    adam_beta1: 0.9
    adam_beta2: 0.95
    adam_eps: 1.0e-08
    name: adamW

## Paralellik, 1 düğüm
parallelism:
  dp: 8  # Veriler 8 GPU'da paralel olarak işleniyor.
  tp: 1  # 1 milyar ölçekte tensör veya ardışık işlem hattı paralelliğine gerek yok.
  pp: 1 

## Belirteçleştirici
tokenizer:
  tokenizer_max_length: 4096
  tokenizer_name_or_path: HuggingFaceTB/SmolLM3-3B

## 30B token için toplu işlem boyutu, dizi uzunluğu ve toplam eğitim süreleri
tokens:
  batch_accumulation_per_replica: 16
  micro_batch_size: 3 # GBS (küresel parti boyutu) = dp * batch_acc * MBS * dizgi = 1,5 milyon token
  sequence_length: 4096
  train_steps: 20000 # GBS * 20000 = 30B

...

Ablasyon çalışmalarımız için, neyi test ettiğimize bağlı olarak farklı bölümleri değiştirirken diğer her şeyi sabit tutacağız: mimari seçimler için model bölümü, eniyileyici ve eğitim hiperparametreleri için eniyileyici bölümü ve veri kürasyonu için data_stages bölümü.

Tek seferde sadece bir şeyi değiştirin.

Her ablasyonda yalnızca tek bir değişkeni değiştirin ve diğer her şeyi sabit tutun. Birden fazla şeyi aynı anda değiştirir ve performans artışı görürseniz, bunun hangi değişiklikten kaynaklandığını bilemezsiniz. Değişiklikleri ayrı ayrı test edin, ardından başarılı olanları birleştirip yeniden değerlendirin.

Ablasyonlar sırasında bazı mimari değişiklikler parametre sayısını önemli ölçüde değiştirebilir. Örneğin, bağlı (tied) gömmelerden bağımsız gömmelere (untied embeddings) geçmek gömme parametrelerimizi iki katına çıkarır; buna karşılık gruplu sorgu veya çok sorgulu dikkat kullanmak, çok başlı dikkat yerine dikkat parametrelerini önemli ölçüde azaltır (bunların hepsini birazdan detaylı olarak konuşacağız).

Adil karşılaştırmalar yapabilmek için parametre sayılarını takip etmemiz ve zaman zaman model boyutlarını yaklaşık aynı tutmak için diğer hiperparametreleri (örneğin gizli boyut veya katman sayısı) ayarlamamız gerekir. Aşağıda farklı konfigürasyonlar için parametre sayısını tahmin etmekte kullandığımız basit bir fonksiyon bulunmaktadır:

from transformers import LlamaConfig, LlamaForCausalLM

def count_parameters(
    tie_embeddings=True,
    num_key_value_heads=4,
    num_attention_heads=32,
    hidden_size=2048,
    num_hidden_layers=16,
    intermediate_size=8192,
    vocab_size=128256,
    sequence_length=4096,
):
    config = LlamaConfig(
        hidden_size=hidden_size,
        num_hidden_layers=num_hidden_layers,
        num_attention_heads=num_attention_heads,
        num_key_value_heads=num_key_value_heads,
        intermediate_size=intermediate_size,
        vocab_size=vocab_size,
        max_position_embeddings=sequence_length,
        tie_word_embeddings=tie_embeddings,
    )
    model = LlamaForCausalLM(config)  
    return f"{sum(p.numel() for p in model.parameters())/1e9:.2f}B"

Ayrıca, yoğun transformatörlerde, LLM’in parametre dağılımlarını görselleştirmek için etkileşimli bir araç da sunuyoruz. Bu, mimari kararlar alırken veya ablasyonlar için konfigürasyonlar oluştururken faydalı olabilir (sayfanın orijinaline gidip bu parametre hesaplayıcıyı kendi değerlerinizle deneyebilirsiniz):

Neyin İşe Yaradığını Anlamak: Değerlendirme

Ablasyonlarımızı çalıştırdıktan sonra neyin işe yaradığını, neyin yaramadığını nasıl anlarız?

Modelleri eğiten herkesin ilk içgüdüsü kayba (loss) bakmak olabilir ve evet, bu önemlidir. Kaybın düzgün bir şekilde, ani sıçramalar veya kararsızlık olmadan azaldığını görmek istersiniz. Birçok mimari seçimde kayıp, aşağı akış (downstream yani eğitilen modelin gerçek işlerde kullanıldığı görevlerde) performansla iyi korelasyon gösterir ve tek başına yeterli olabilir (Y. Chen ve ark., 2025). Ancak yalnızca kayıba (loss’a) bakmak her zaman güvenilir değildir. Veri ablasyon örneğini ele alırsak, Wikipedia üzerinde eğitimin web sayfalarına göre daha düşük kayıp verdiğini görürsünüz (çünkü bir sonraki token’ı tahmin etmek daha kolaydır), fakat bu daha yetenekli bir model elde edeceğiniz anlamına gelmez. Benzer şekilde, çalıştırmalar arasında belirteçleştirici değiştirirseniz kayıplar doğrudan karşılaştırılamaz çünkü metin farklı şekilde parçalanır. Bazı değişiklikler özellikle akıl yürütme ve matematik gibi belirli yetenekleri etkileyebilir, ancak bu etkiler ortalama kayıp içinde kaybolabilir. Son olarak, modeller öneğitim kaybına yakınsamış olsa bile aşağı akış görevlerde gelişmeye devam edebilir (Liu ve ark., 2022).

Tüm resmi görebilmek ve bu nüanslı etkileri anlayabilmek için daha ince taneli değerlendirmelere ihtiyaç duyarız. Doğal bir yaklaşım, bilgi, anlama, akıl yürütme ve bizim için önemli diğer alanları test eden aşağı akış değerlendirmeleri kullanmaktır.

Bu ablasyonlar için, erken sinyal veren ve gürültülü olmayan kıyaslamalara odaklanmak faydalıdır. FineTasks ve FineWeb2’de güvenilir değerlendirme görevleri dört temel ilkeye göre tanımlanır:

• Monotonluk: Kıyaslama skorları, modeller daha uzun süre eğitildikçe sürekli olarak artmalıdır.
• Düşük gürültü: Aynı kurulumla ancak farklı rastgele tohumlarla eğitilen modellerde kıyaslama skorları büyük dalgalanmalar göstermemelidir.
• Rastgele seviyenin üzerinde performans: Birçok yetenek ancak eğitim sürecinin ilerleyen aşamalarında ortaya çıkar; bu nedenle uzun süre rastgele seviyede kalan görevler kıyaslamalar için yararlı değildir. Örneğin MMLU’nun çoktan seçmeli formatı (ileride açıklayacağımız gibi) buna dahildir.
• Sıralama tutarlılığı: Bir yaklaşım erken aşamalarda diğerinden daha iyi performans gösteriyorsa, bu sıralama eğitim ilerledikçe de korunmalıdır.

Bir görevin kalitesi ayrıca görev formülasyonuna (soruları nasıl sorduğumuz) ve metrik seçimine (cevabı nasıl puanladığımıza) bağlıdır.

Üç yaygın görev formülasyonu vardır: çoktan seçmeli format (MultipleChoiceFormat), cloze formülasyonu (ClozeFormulation) ve serbest üretim (FreeGeneration). MCF, modellerin istemde açıkça sunulan ve A/B/C/D ile işaretlenmiş seçeneklerden birini seçmesini gerektirir (örneğin MMLU’da olduğu gibi). CF’de ise seçenekler istemde verilmez; bunun yerine farklı seçeneklerin olasılıklarını karşılaştırarak hangisinin daha olası olduğunu belirleriz. FG’de ise verilen bir istem için modelin açgözlü üretim çıktısının doğruluğuna bakarız. FG, modelin çok fazla örtük bilgiye sahip olmasını gerektirir ve bu nedenle tam bir eğitim çalışması öncesindeki kısa öneğitim ablasyonlarında genellikle fazla zor bir görevdir. Bu yüzden küçük ölçekli ablasyonlarda çoğunlukla çoktan seçmeli formülasyonlara odaklanırız (MCF veya CF).

Not: Son eğitim aşaması modellerinde FG temel değerlendirme formülasyonu haline gelir; çünkü modelin gerçekten faydalı yanıtlar üretebilip üretemediğini ölçeriz. Bu konuyu “Temel Modellerin Ötesi — Ardıl Eğitim” bölümünde ele alacağız.

Araştırmalar ayrıca modellerin eğitim başlarında MCF’de zorlandığını, bu nedenle erken sinyal için CF’nin daha iyi olduğunu göstermiştir (Du ve ark., 2025; Gu ve ark., 2025; J. Li ve ark., 2025). Bu yüzden küçük ablasyonlarda CF kullanırız ve ana eğitim çalışmasında MCF’yi ekleriz (çünkü eğitim ilerledikçe daha iyi sinyal verir). CF gibi olasılık temelli değerlendirmelerde modelin cevabını puanlamak için, doğru cevabın karakter sayısına göre normalize edilmiş log olasılığının en yüksek olduğu soruların yüzdesini hesaplarız. Bu normalizasyon, kısa cevaplara karşı bir yanlılığı önler.

MMLU MCF’nin rastgelelikten çıkıp anlamlı hale geldiği nokta model boyutuna ve eğitim verisine bağlıdır. 7B bir transformer için OLMES çalışması (Gu ve ark., 2025), modelin 500B token sonrasında rastgele olmayan performans göstermeye başladığını bulmuştur. 1.7B bir modelde ise SmolLM2’de (Allal ve ark., 2025) bunun 6T token sonrasında gerçekleştiğini gözlemledik. Du ve ark. (2025), bunun temelde pretraining loss’un belirli bir eşiğe ulaşmasıyla ilgili olduğunu savunur.

Ablasyon değerlendirme kümemiz, SIQA hariç FineWeb ablasyonlarındaki kıyaslamları içerir; SIQA’nın fazla gürültülü olduğunu tespit ettik. Ayrıca GSM8K ve HumanEval gibi matematik ve kod karşılaştırma ölçütlerini ve uzun bağlam ablasyonları için RULER benchmark’ını ekleriz. Bu görevlerin birleşimi; dünya bilgisi, akıl yürütme ve sağduyuyu farklı formatlarda test eder, aşağıdaki tabloda gösterildiği gibi. Değerlendirmeleri hızlandırmak için (bir miktar ek gürültü pahasına), her benchmark’tan yalnızca 1.000 soru üzerinde değerlendirme yaparız (GSM8K, HumanEval ve RULER hariç; bunları 3B SmolLM3 ablasyonlarıdna tam olarak kullanırız, ancak 1B deneylerde çıkarırız). Tüm çoktan seçmeli karşılaştırma ölçütleri için daha önce açıklandığı gibi CF kullanırız. Çok dilli ablasyonlar ve gerçek eğitimlerde ise çok dilliliği test etmek için daha fazla karşılaştırma ölçütleri ekleriz; bunları ileride detaylandıracağız. Bu değerlendirmeler LightEval kullanılarak çalıştırılır. Aşağıda her karşılaştırma ölçütlerinin temel özelliklerinin bir özeti yer almaktadır:

Bu değerlendirmelerin aslında neyi ölçtüğünü daha somut bir şekilde anlamak için her birinden birkaç örnek soruya bakalım:

Etkileşimli sürümdeki örneklere göz atarak her benchmark’taki soru türlerini inceleyebilirsiniz. MMLU ve ARC’nin çoktan seçmeli sorularla olgusal bilgiyi test ettiğine, GSM8K’nin matematik problemlerine sayısal cevaplar hesaplamayı gerektirdiğine ve HumanEval’in eksiksiz Python kodu üretmeyi istediğine dikkat edin. Bu çeşitlilik, ablasyonlarımız boyunca model yeteneklerinin farklı yönlerini test ettiğimizden emin olmamızı sağlar.

Ablasyonlar İçin Hangi Veri Karışımı Kullanılıyor?

Mimari ablasyonlar için, çok çeşitli görevlerde erken sinyal sağlayan sabit bir yüksek kaliteli veri kümesi karışımı üzerinde eğitim yapıyoruz. İngilizce için FineWeb-Edu, matematik için FineMath ve kod için Stack-Edu-Python kullanıyoruz. Mimariyle ilgili bulguların çok dilli veriler dahil olmak üzere diğer veri kümeleri ve alanlara da iyi genellenmesi beklendiğinden, veri karışımını basit tutabiliyoruz.

Veri ablasyonları için ise tam tersini yapıyoruz: Mimarinin kendisini sabit tutup farklı veri karışımlarını sistematik olarak değiştirerek çeşitli veri kaynaklarının model performansını nasıl etkilediğini anlamaya çalışıyoruz.

Bazen değerlendirme sonuçları arasındaki farklar oldukça küçük olabilir. Yeterli hesaplama gücünüz varsa, sonuçların ne kadar değiştiğini görmek için aynı ablasyonları farklı rastgele başlangıç tohumlarıyla (seed) yeniden çalıştırmak faydalı olabilir.

Sağlam bir ablasyon düzeninin gerçek değeri yalnızca iyi bir model geliştirmekten ibaret değildir. Ana eğitim sürecimiz sırasında işler ters gittiğinde (ve ne kadar hazırlıklı olursak olalım mutlaka bazı şeyler ters gider), aldığımız her karardan emin olmak ve hangi bileşenlerin yeterince test edilmediğini hızlıca belirleyebilmek isteriz. Bu hazırlık, hata ayıklama süresini azaltır ve gelecekteki zihinsel sağlığımızı korur.

Ablasyon Maliyetini Tahmin Etmek

Ablasyonlar son derece faydalıdır, ancak GPU zamanı gerektirir. Bu deneylerin maliyetini anlamakta fayda vardır. Aşağıdaki tablo, SmolLM3 ön eğitimi için tüm hesaplama maliyet dökümümüzü göstermektedir: ana eğitim çalışması (ara sıra yaşanan kesintiler dahil), eğitim öncesi ve sırasındaki ablasyonlar, ayrıca yeniden başlatmayı gerektiren beklenmedik bir ölçeklenme sorunu ve hata ayıklama için harcanan ek hesaplama maliyeti (bunları daha sonra ayrıntılı olarak açıklayacağız).

Sayılar önemli bir gerçeği ortaya koyuyor: Ablasyonlar ve hata ayıklama toplamda 161.280 GPU saati tüketti; bu da ana eğitim çalışmamızın maliyetinin (276.480 GPU saati) yarısından fazlası demek. SmolLM3’ün geliştirilmesi boyunca 100’den fazla ablasyon deneyi yürüttük: Ön eğitim ablasyonlarına 20 gün, orta eğitim aşaması ablasyonlarına 10 gün harcadık ve yukarıda bahsedilen beklenmedik eğitim sorunundan toparlanmak için 7 gün geçirdik.

Bu durum, ablasyon maliyetlerinin neden hesaplama bütçesine dahil edilmesi gerektiğini gösteriyor: Eğitim maliyeti + ablasyonlar + beklenmedik durumlar için bir tampon planlayın. Eğer SOTA (state-of-the-art) performans hedefliyorsanız, yeni mimari değişiklikleri uyguluyorsanız veya hâlihazırda kanıtlanmış bir tarifiniz yoksa, ablasyonlar küçük deneylerden ziyade önemli bir maliyet merkezi hâline gelir.

DeepSeek-V3 çıktığında dünya, bildirilen 5,6 milyon dolarlık eğitim maliyetine odaklandı. Birçok kişi bu rakamı toplam Ar-Ge maliyeti olarak yorumladı. Gerçekte ise bu rakam yalnızca nihai eğitim çalışmasını yansıtıyordu. Çok daha büyük ve genellikle görünmez olan gider, araştırmanın kendisidir: Nihai tarife ulaşmayı sağlayan ablasyonlar, başarısız çalıştırmalar ve hata ayıklama süreçleri. Modelin ölçeği ve yeniliği göz önüne alındığında, araştırma maliyetleri kesinlikle daha yüksekti.

Model mimarisini tasarlamaya geçmeden önce, deney yürüten herkesin uyması gereken bazı temel kuralları belirleyelim.

Çalışma Kuralları

Özet: Paranoyak olun.

Değerlendirme paketinizin doğruluğunu teyit edin. Herhangi bir modeli eğitmeden önce, değerlendirme paketinizin karşılaştıracağınız modellerin yayımlanmış sonuçlarını yeniden üretebildiğinden emin olun. Eğer kıyaslama ölçütlerinden bazıları üretici (generative) yapıdaysa (ör. GSM8k), ekstra dikkatli olun ve istemin doğru biçimlendirildiğini ve son işlem adımının doğru bilgiyi çıkardığını doğrulamak için birkaç örneği manuel olarak inceleyin. Çünkü değerlendirmeler vereceğiniz her kararı yönlendirecektir; bu adımı doğru yapmak projenin başarısı için kritik önemdedir.

Her değişikliği test edin, ne kadar küçük olursa olsun. “Sadece iki satır değiştiren” commit’i ya da masum görünen bir kütüphane güncellemesinin etkisini küçümsemeyin. Bu küçük değişiklikler, sonuçlarınızı kirletecek ince hatalara veya performans kaymalarına yol açabilir. Gerilemeleri önlemek için, sizin için önemli senaryoları kapsayan güçlü bir test paketine sahip bir kütüphaneye ihtiyacınız vardır.

Bazı durumlarda bir hata, kütüphaneyi en güncel sürüme yükselterek çözülebilir. Buna dair harika bir dedektifvari hata ayıklama örneği için Elana Simon’ın blog yazısına göz atabilirsiniz: [https://elanapearl.github.io/blog/2025/the-bug-that-taught-me-pytorch/]

Aynı anda yalnızca tek bir şeyi değiştirin. Deneyler arasında diğer her şeyi aynı tutun. Bazı değişiklikler birbirleriyle beklenmedik şekillerde etkileşime girebilir; bu yüzden önce her değişikliğin bireysel katkısını değerlendirin, ardından genel etkilerini görmek için bunları birlikte deneyin.

Yeterli miktarda token üzerinde eğitin ve yeterli değerlendirme yapın. Daha önce de belirttiğimiz gibi, değerlendirme paketinizin yeterli kapsama sahip olduğundan ve güvenilir sinyal elde etmek için yeterince uzun eğitim yaptığınızdan emin olmalısınız. Bu noktada kestirme yollara başvurmak, gürültülü sonuçlara ve kötü kararlara yol açacaktır.

Bu kuralları takip etmek aşırı temkinli hissettirebilir; ancak alternatif, günler önce yapılmış alakasız bir bağımlılık güncellemesinden kaynaklanan gizemli performans düşüşlerini günlerce ayıklamaktır. Altın kural şudur: İyi çalışan bir kurulumunuz olduğunda, hiçbir değişiklik testsiz bırakılmamalıdır!

4. Model Mimarisini Tasarlamak

Artık deneysel çerçevemizi oluşturduğumuza göre, modelimizi tanımlayacak büyük kararları verme zamanı geldi. Model boyutundan dikkat (attention) mekanizmalarına, tokenizer seçiminden diğer bileşenlere kadar yaptığımız her tercih; model eğitimi ve kullanımını etkileyecek kısıtlar ve fırsatlar yaratır.

Eğitim pusulasını hatırlayın: Herhangi bir teknik karar vermeden önce neden ve ne sorularında net olmamız gerekir. Bu modeli neden eğitiyoruz ve nasıl bir model olmasını istiyoruz?

Kulağa bariz geliyor olabilir, ancak daha önce açıkladığımız gibi burada bilinçli davranmak, kararlarımızı şekillendirir ve bizi sonsuz olası deneyler arasında kaybolmaktan korur. İngilizce için SOTA (state-of-the-art) bir model mi hedefliyoruz? Uzun bağlam (long context) öncelikli mi? Yoksa yeni bir mimariyi doğrulamaya mı çalışıyoruz? Eğitim döngüsü tüm bu durumlarda benzer görünebilir, ancak yapacağımız deneyler ve kabul edeceğimiz ödünleşimler (trade-offs) farklı olacaktır. Bu soruları erken yanıtlamak; çalışmaya başlamadan önce zamanımızı veri ve mimari çalışmaları arasında nasıl dengeleyeceğimize ve her alanda ne kadar yenilik yapacağımıza karar vermemize yardımcı olur.

Bu yüzden örnekle ilerleyelim ve SmolLM3’ün tasarımını yönlendiren hedefleri inceleyelim. Amacımız; cihaz üzerinde çalışan uygulamalar için güçlü, çok dilli performansı rekabetçi, matematik ve kodlama yetenekleri sağlam, ayrıca uzun bağlam yönetiminde dayanıklı bir model geliştirmekti. Daha önce de belirttiğimiz gibi bu hedef bizi 3 milyar parametreli yoğun (dense) bir modele yönlendirdi: güçlü yetenekler sunacak kadar büyük ama telefonlara rahatça sığacak kadar küçük. Uç cihazların (edge devices) bellek kısıtları ve proje takvimimiz (yaklaşık üç ay) nedeniyle MoE veya hibrit yerine yoğun transformer mimarisini tercih ettik.

SmolLM2’den İngilizce için daha küçük ölçekte (1.7 milyar parametre) çalışan bir tarifimiz vardı; ancak ölçeği büyütmek her şeyi yeniden doğrulamayı ve çok dillilik ile genişletilmiş bağlam uzunluğu gibi yeni zorluklarla uğraşmayı gerektirdi. Hedeflerin net olması yaklaşımımızı şekillendirdi. Örneğin SmolLM2’de ön eğitimin sonunda bağlam uzunluğunu artırmakta zorlanmıştık; bu yüzden SmolLM3 için baştan itibaren NoPE ve belge içi maskeleme (intra-document masking, ileride açıklanacak) gibi mimari seçimler yaparak bunu doğru gerçekleştirme şansımızı artırdık ve işe yaradı.

SmolLM2, cihaz üzerinde çalıştırılmak üzere tasarlanmış; 135 milyon, 360 milyon ve 1.7 milyar parametreli üç varyanta sahip önceki nesil küçük dil modellerimizdi. Bu modeller yalnızca İngilizce destekliyor ve 8k bağlam uzunluğuna sahipti.

Hedeflerimiz netleştiğinde, artık bunları hayata geçirecek teknik kararları almaya başlayabiliriz. Bu bölümde; mimari, veri ve hiperparametreler gibi temel kararlara yönelik sistematik yaklaşımımızı inceleyeceğiz. Bunu stratejik planlama aşaması gibi düşünün — bu temelleri doğru kurmak, gerçek eğitim maratonu sırasında sizi maliyetli hatalardan kurtaracaktır.

Mimari Seçimleri

Qwen3, Gemma 3 veya DeepSeek-V3 gibi güncel modellere baktığınızda, farklılıklarına rağmen hepsinin aynı temeli paylaştığını görürsünüz: 2017’de tanıtılan transformer mimarisi (Vaswani ve diğerleri, 2023). Temel yapısı yıllar içinde çok fazla değişmedi, ancak çekirdek bileşenlerinde çeşitli iyileştirmeler yapıldı. İster yoğun bir model, ister uzman karışımı (Mixture of Experts — MoE), ister hibrit bir mimari geliştiriyor olun, aynı yapı taşlarıyla çalışıyorsunuz.

Bu iyileştirmeler; daha iyi performans elde etmeye çalışan ve belirli sorunları çözmeye uğraşan ekiplerden ortaya çıktı: çıkarım (inference) sırasında bellek kısıtları, büyük ölçekli eğitimde kararsızlık ve daha uzun bağlamları işleme ihtiyacı gibi. Çok başlı dikkat (multi-head attention) yerine, grup sorgulu dikkat (Ainslie ve diğerleri, 2023) gibi hesaplama açısından daha verimli dikkat varyantlarına geçiş gibi bazı değişiklikler yaygın şekilde benimsendi. Farklı konumsal kodlama (positional encoding) şemaları gibi diğerleri ise hâlâ tartışılıyor. Sonunda, bugünün deneyleri yarının temel standartlarına dönüşecek.

Peki günümüzde LLM’ler gerçekte ne kullanıyor? Önde gelen modellerin hangi noktalarda ortaklaştığına bakalım. Ne yazık ki tüm modeller eğitim ayrıntılarını paylaşmıyor; ancak DeepSeek, OLMo, Kimi ve SmolLM gibi ailelerin sağladığı şeffaflık sayesinde mevcut tabloyu görebiliyoruz:

MLA, NoPE veya WSD gibi bu terimlerin bazılarını henüz anlamıyorsanız endişelenmeyin; bu bölümde her birini açıklayacağız. Şimdilik sadece çeşitliliğe dikkat edin: farklı dikkat mekanizmaları (MHA, GQA, MLA), konumsal kodlamalar (RoPE, NoPE, kısmi RoPE) ve öğrenme oranı zamanlamaları (cosine, multi-step, WSD) kullanılmaktadır.

Bu uzun mimari tercihleri listesine baktığımızda, nereden başlayacağımızı anlamak bile biraz göz korkutucu oluyor. Çoğu benzer durumda olduğu gibi, adım adım ilerleyecek ve gerekli tüm bilgiyi zaman içinde oluşturacağız. Öncelikle en basit temel mimariye (yoğun/dense bir model) odaklanacak ve her mimari yönü ayrıntılı olarak inceleyeceğiz. Daha sonra MoE ve hibrit modellere derinlemesine dalacak, bunları kullanmanın ne zaman iyi bir tercih olduğunu tartışacağız. Son olarak ise, çoğu zaman göz ardı edilen ve değeri yeterince bilinmeyen bir bileşen olan tokenizer’ı (belirteçleştiriciyi) inceleyeceğiz. Mevcut bir belirteçleştiriciyi mi kullanmalıyız yoksa kendi belirteçleştiricimizi mi eğitmeliyiz? Bir belirteçleştiricinin iyi olup olmadığını nasıl değerlendiririz?

Ablasyon kurulumu

Bu bölümün geri kalanında, mimari tercihlerin çoğunu bir önceki bölümde açıklanan kurulum üzerinden yapılan ablasyonlarla doğruluyoruz: FineWeb-Edu, FineMath ve Python-Edu karışımından alınan 45 milyar token üzerinde eğitilmiş 1B temel modelimiz (Llama 3.2 1B mimarisini takip ediyor). Her deney için, her değişikliğin etkisini değerlendirmek amacıyla hem eğitim kaybı (training loss) eğrilerini hem de aşağı akış (downstream) değerlendirme skorlarını gösteriyoruz. Tüm çalıştırmaların yapılandırmalarını HuggingFaceTB/training-guide-nanotron-configs [https://huggingface.co/datasets/HuggingFaceTB/training-guide-nanotron-configs/tree/main] içinde bulabilirsiniz.

Sebastian Raschka’nın “Big LLM Architecture Comparison” [https://magazine.sebastianraschka.com/p/the-big-llm-architecture-comparison] çalışması, 2025 yılındaki modern LLM mimarilerine dair iyi bir genel bakış sunuyor.

Her LLM’in çekirdeği olan dikkat (attention) mekanizmasıyla başlayacağız.

Dikkat (Attention)

Transformer mimarileri etrafındaki en aktif araştırma alanlarından biri dikkat (attention) mekanizmasıdır. Ön beslemeli (feedforward) katmanlar ön eğitim sırasında hesaplama yüküne hakim olsa da, çıkarım (inference) aşamasında dikkat mekanizması ana darboğaz haline gelir (özellikle uzun bağlamlarda). Çünkü bu mekanizma hesaplama maliyetini ve GPU bellek gereksinimlerini artırarak işlem verimini düşürür. Şimdi temel dikkat mekanizmalarına ve bunların kapasite ile hız arasında nasıl bir denge kurduğuna kısa bir göz atalım.

Dikkatim İçin Kaç Başlık (Head) Gerekli?

Çok başlıklı dikkat (Multi-Head Attention — MHA), orijinal transformer mimarisiyle tanıtılan standart dikkat mekanizmasıdır (Vaswani vd., 2023). Temel fikir şudur: Aynı bilgi getirme görevini bağımsız şekilde yapan N adet dikkat başlığı bulunur. Her başlık gizli durumu (hidden state) sorgulara (queries), anahtarlara (keys) ve değerlere (values) dönüştürür; ardından mevcut sorguyu kullanarak anahtarlar (K) üzerinden en alakalı token’ı bulur ve son olarak eşleşen token’larla ilişkili değeri (V) iletir.

Çıkarım sırasında geçmiş token’lar için KV değerlerini yeniden hesaplamamız gerekmez; bunları yeniden kullanabiliriz. Geçmiş KV değerleri için kullanılan belleğe KV önbelleği (KV cache) denir. Bağlam pencereleri büyüdükçe bu önbellek hızla çıkarım sürecinde darboğaz haline gelir ve GPU belleğinin büyük bir kısmını tüketebilir. Aşağıda, MHA kullanan ve 8.192 uzunluğunda dizilere sahip Llama 3 mimarisi için KV önbellek boyutunu hesaplayan basit bir örnek verilmiştir:

s_KV = 2 × n_bytes × seq × n_layers × n_heads × dim_heads

= 2 × 2 × 8192 × 32 × 32 × 128 = 4 GB (Llama 3 8B)

= 2 × 2 × 8192 × 80 × 64 × 128 = 20 GB (Llama 3 70B)

Not: Yukarıdaki heesap için hızlı bir hatırlatma için Jay Alamar’ın ünlü blog yazısına göz atabilirsiniz [https://jalammar.github.io/illustrated-transformer/] .

Buradaki baştaki 2 katsayısının nedeni hem key hem de value önbelleklerinin saklanmasıdır. Görüldüğü gibi önbellek boyutu dizi uzunluğu ile doğrusal şekilde artmaktadır; ancak bağlam pencereleri üstel biçimde büyüyerek artık milyonlarca token’a ulaşmıştır. Önbelleğin verimliliğini artırmak, çıkarım sırasında bağlam ölçeklendirmesini çok daha kolay hale getirecektir.

Burada doğal olarak şu soru ortaya çıkar: Gerçekten her başlık için yeni KV değerlerine ihtiyaç var mı? Muhtemelen hayır. Hem çoklu sorgu dikkat mekanizması (Multi-Query Attention — MQA) (Shazeer, 2019) hem de gruplandırılmış sorgu dikkat mekanizması (Grouped Query Attention — GQA) (Ainslie vd., 2023) bu sorunu ele alır.

En basit seçenek, KV değerlerini tüm başlıklar arasında paylaşmaktır. Böylece KV önbelleğinin boyutu n_heads kadar küçülür (Llama 3 70B için 64 kat azalma!). Bu yaklaşım MQA’nın temel fikridir ve StarCoder gibi bazı modellerde MHA’ya alternatif olarak kullanılmıştır. Ancak bu yöntem dikkat kapasitesinden biraz fazla ödün verebilir.

Başka bir seçenek ise KV değerlerini başlık grupları arasında paylaşmaktır. Örneğin dört başlık aynı KV değerlerini paylaşabilir. Bu yaklaşım GQA olarak adlandırılır ve MQA ile MHA arasında orta bir çözüm sunar.

Daha yakın zamanda DeepSeek-V2, çok başlıklı gizil dikkat (Multi-Head Latent Attention — MLA) mekanizmasını tanıttı (DeepSeek-AI vd., 2024). Bu yöntem (V3’te de kullanılmıştır) önbelleği sıkıştırmak için farklı bir strateji uygular: KV değerlerinin sayısını azaltmak yerine boyutlarını küçültür ve çalışma zamanında tekrar KV değerlerine dönüştürülebilen gizil (latent) bir değişken saklar.

Bu yaklaşımla DeepSeek, önbelleği GQA’daki 2.25 grup eşdeğerine kadar küçültmeyi başarmış ve aynı zamanda MHA’dan daha güçlü performans elde etmiştir. Bunun RoPE (Rotary Positional Embedding) ile çalışabilmesi için küçük ek bir gizil vektörle ufak bir düzenleme gerekir.

DeepSeek-V2’de ana gizil değişken için 4 × dim_head, RoPE kısmı için ise 1/2 × dim_head seçilmiştir. Böylece toplamda 4.5 × dim_head elde edilir. Bu yapı hem K hem de V için aynı anda kullanıldığı için baştaki 2 katsayısı ortadan kalkar.

RoPE (Rotary Position Embeddings), sorgu ve anahtar vektörlerini dizideki konumlarına göre döndürerek konumsal bilgiyi kodlayan bir yöntemdir. Günümüz büyük dil modellerinde (LLM) yaygın şekilde kullanılmaktadır. Bu bölümün ilerleyen kısımlarında konumsal kodlamaları incelerken RoPE’u daha detaylı ele alacağız.

Aşağıdaki görselde her dikkat mekanizmasının görsel açıklamasını görebilirsiniz:

Çok başlı dikkat mekanizması (MHA), gruplandırılmış sorgu dikkat mekanizması (GQA), çoklu sorgu dikkat mekanizması (MQA) ve çok başlı gizli dikkat mekanizmasının (MLA) basitleştirilmiş bir gösterimi. Anahtarları ve değerleri birlikte gizli bir vektöre sıkıştırarak, MLA çıkarım sırasında KV önbellek boyutunu önemli ölçüde azaltır.

Aşağıdaki tablo, bu bölümde ele alınan dikkat mekanizmalarını karşılaştırmaktadır. Basitlik açısından, her bir belirteç için kullanılan parametreleri karşılaştırıyoruz; toplam belleği hesaplamak isterseniz, parametre başına bayt sayısıyla (genellikle 2) ve dizi uzunluğuyla çarpmanız yeterlidir.

Şimdi bu attention (dikkat) mekanizmalarının gerçek deneylerde nasıl performans gösterdiğine bakalım!

Ablasyon: GQA, MHA’yı Geçiyor

Temel modelimiz 32 query head ve 8 KV head kullanıyor; bu da 32 / 8 = 4 oranına sahip bir GQA yapılandırmasına karşılık geliyor. Peki MHA kullansaydık ya da daha az KV head ve daha yüksek bir GQA oranı tercih etseydik performans nasıl değişirdi?

Bazı kütüphaneler buna GQA oranı diyor: Query groups = Query heads / KV heads

KV head sayısını değiştirmek, özellikle MHA durumunda, parametre sayısını etkiliyor. Tutarlılığı korumak için MHA çalıştırmasında katman sayısını ayarlıyoruz; aksi halde 100M+ parametre farkı oluşacaktı. Diğer yapılandırmalarda ise varsayılan 16 katmanı koruyoruz. MHA, MQA ve GQA için dört farklı kurulumu (oranlar: 2, 4, 8, 16) karşılaştıracağız. Nanotron yapılandırmalarını burada bulabilirsiniz: [https://huggingface.co/datasets/HuggingFaceTB/training-guide-nanotron-configs/tree/main/attention]

Ablasyon sonuçlarına baktığımızda, 16 gruplu (sırasıyla sadece 1 ve 2 KV başlık kullanan) MQA ve GQA’nın MHA’ya göre önemli ölçüde daha düşük performans gösterdiğini görüyoruz. Öte yandan, 2, 4 ve 8 gruplu GQA konfigürasyonları MHA performansıyla yaklaşık olarak eşleşiyor:

Sonuçlar, hem kayıp eğrileri hem de aşağı akış değerlendirmeleri boyunca tutarlı. Bunu özellikle HellaSwag, MMLU ve ARC gibi karşılaştırma ölçütlerinde açıkça görüyoruz; buna karşılık OpenBookQA ve WinoGrande gibi karşılaştırma ölçütlerinde biraz gürültü mevcut.

Bu ablasyon çalışmalarına dayanarak, GQA, MHA’ya güçlü bir alternatif. Performansı korurken çıkarım (inference) sırasında daha verimli çalışıyor. Bazı yeni modeller, KV önbelleğini daha da sıkıştırmak için MLA’yı benimsedi; ancak henüz yaygın olarak kullanılmıyor. Ablasyonlar sırasında Nanotron’da uygulanmamış olduğu için MLA üzerinde ablasyon yapmadık. SmolLM3 için 4 gruplu GQA kullandık.

Dikkat (attention) mimarisinin kendisinin ötesinde, eğitim sırasında kullandığımız dikkat örüntüsü de önem taşıyor. Hadi bir göz atalım.

Doküman Maskeleme

Eğitim dizileri boyunca dikkati nasıl uyguladığımız, hem hesaplama verimliliğini hem de model performansını etkiler. Bu bizi doküman maskelemesine ve daha genel olarak veri yükleyicide (dataloader) eğitim örneklerini nasıl yapılandırdığımız sorusuna getiriyor.

Ön eğitim sırasında sabit dizi uzunluklarıyla eğitim yapıyoruz, ancak dokümanlarımız değişken uzunluklara sahip. Bir araştırma makalesi 10 bin token içerebilirken, kısa bir kod parçası yalnızca birkaç yüz token olabilir. Peki değişken uzunluktaki dokümanları sabit uzunluktaki eğitim dizilerine nasıl sığdırıyoruz? Daha kısa dokümanları hedef uzunluğa ulaşacak şekilde dolgulamak (padding), anlamsız dolgu belirteçleri üzerinde hesaplama kaynağı harcamamıza neden olur. Bunun yerine paketleme (packing) kullanıyoruz: Dokümanları karıştırıp dizi sonu (EOS) token’larıyla birleştiriyor, ardından sonucu dizi boyutuna karşılık gelen sabit uzunluklu parçalara ayırıyoruz.

Başka bir seçenek de dokümanların başına dizi başlangıcı (BOS) token’ları eklemektir. Bu durumda, model/tokenizer yapılandırmalarında farklı bir bos_token_id bulunduğunu fark edersiniz.

Pratikte bu şu şekilde görünür:

Dosya 1: “Granola bar tarifi...” (400 token) <EOS>
Dosya 2: “def hello_world()...” (300 token) <EOS>
Dosya 3: “İklim değişikliğinin etkileri...” (1000 token) <EOS>
Dosya 4: “import numpy as np...” (3000 token) <EOS>
...

Birleştirme ve 4k uzunluklu dizilere bölme işleminden sonra:

Dizi 1: [Dosya 1] + [Dosya 2] + [Dosya 3] + [Dosya 4’ün bir kısmı]
Dizi 2: [Dosya 4’ün geri kalanı] + [Dosya 5] + [Dosya 6] + ...

Bir eğitim dizisi (training sequence), 4k bağlamımızı doldurmaya yetecek kadar uzun olduğu durumlarda tek bir tam dosya içerebilir; ancak çoğu dosya bundan daha kısadır, bu yüzden diziler genellikle birden fazla rastgele dosyanın birleştirilmesinden oluşur.

Standart nedensel maskeleme (causal masking) ile, belirteçler paketlenmiş dizide kendilerinden önce gelen tüm tokenlere dikkat edebilir (katılabilir/attend edebilir). Yukarıdaki örnekte, 4. dosyadaki Python betiğinde bulunan bir belirteç; granola bar tarifi, fonksiyon tanımı ve iklim değişikliği makalesine dikkat edebilir.

Tipik bir 4k ön-eğitim (pretraining) bağlamının neler içerdiğine bakalım. Hızlı bir analiz, Common Crawl ve GitHub veri kümelerindeki dosyaların önemli bir kısmının (yaklaşık %80–90) 2k token’dan daha kısa olduğunu ortaya koyuyor. Aşağıdaki grafik, bu kılavuz boyunca kullanılan daha yeni veri kümeleri için belirteç dağılımlarını incelemektedir:

Dokümanlar ve veri kümeleri.

FineWeb-Edu, DCLM, FineMath ve Python-Edu’daki belgelerin %80’inden fazlası 2 bin (2k) belirteçten daha kısadır. Bu, 2k veya 4k’lık bir eğitim sekansı ve standart nedensel (causal) maskeleme kullanıldığında, belirteçlerin büyük çoğunluğunun birlikte paketlenmiş alakasız belgelere dikkat hesaplamakla (attention) zaman harcayacağı anlamına gelir.

PDF’lerde daha uzun belgeler Web tabanlı veri kümelerinin çoğu kısa belgelerden oluşurken, PDF tabanlı veri kümeleri önemli ölçüde daha uzun içeriklere sahiptir. FinePDFs belgeleri ortalama olarak web metninden 2 kat daha uzundur ve bunların FineWeb-Edu ve DCLM belgeleriyle karıştırılması performansı artırır.

Hesaplama verimsizliği sorununa ek olarak, Zhao ve ark. (2024) bu yaklaşımın alakasız içeriklerden gelen gürültü ekleyerek performansı düşürebileceğini bulmuştur. Bunun yerine belge içi maskeleme (intra-document masking) kullanılmasını önermektedirler. Bu yöntemde dikkat (attention) maskesi, belirteçlerin yalnızca aynı belge içindeki önceki belirteçlere bakabileceği şekilde değiştirilir. Aşağıdaki görselleştirme bu farkı göstermektedir.

Zhu ve ark. (2025), SkyLadder’da belge içi maskelemenin benzer faydalarını bulmuşlardır, ancak farklı bir açıklama sunmaktadırlar: Daha kısa bağlam uzunluklarının eğitim için daha iyi sonuç verdiğini ve belge içi maskelemenin ortalama bağlam uzunluğunu etkili bir şekilde azalttığını tespit etmişlerdir.

Meta ayrıca Meta, Llama 3 modelini (Grattafiori ve diğerleri, 2024) belge içi maskeleme (intra-document masking) ile eğitti; kısa bağlamlı ön eğitim sırasında etkinin sınırlı olduğunu, ancak dikkat (attention) yükünün daha belirgin hâle geldiği uzun bağlam genişletmesinde önemli faydalar sağladığını buldular. Buna ek olarak, ProLong makalesi (Gao ve diğerleri, 2025), sürekli ön eğitim sırasında belge maskelemesi kullanarak Llama 3 8B’nin bağlam uzunluğunu genişletmenin hem uzun bağlam hem de kısa bağlam kıyaslama testlerinde fayda sağladığını gösterdi.

Biz de 1B temel modelimiz üzerinde bir ablasyon çalışması yürütmeye ve belge maskelemesinin kısa bağlam performansını etkileyip etkilemediğini test etmeye karar verdik. Yapılandırmayı burada bulabilirsiniz. Nanotron’da belge maskelemesini etkinleştirmek için tek yapmanız gereken _use_doc_masking bayrağını true olarak ayarlamaktır:

model_config:
  _attn_implementation: flash_attention_2
  _fused_rms_norm: true
  _fused_rotary_emb: true
- _use_doc_masking: false
+ _use_doc_masking: true

Sonuçlar, aşağıdaki grafiklerde gösterildiği gibi, standart nedensel maskeleme ile karşılaştırıldığında aynı kayıp eğrilerini ve sonraki değerlendirme puanlarını ortaya koymuştur.

Llama 3’te olduğu gibi, PIQA’daki küçük bir iyileşme dışında kısa bağlam görevleri üzerinde belirgin bir etki gözlemlemiyoruz. Ancak eğitim sürecini hızlandırmak için uzun dizilere ölçeklenirken belge maskeleme kritik hâle geliyor. Bu durum özellikle, 4k’dan 64k token’a ölçeklendirdiğimiz uzun bağlam genişletmemiz için önem taşıyor (“The Training Marathon” bölümünde ayrıntılı olarak anlatıldığı gibi). Bu nedenle, SmolLM3 için tüm eğitim süreci boyunca bunu benimsedik.

Bu bölümde dikkatin dizileri nasıl işlediğini ele aldık. Şimdi transformer’lardaki bir diğer büyük parametre bloğuna, yani gömmelere bakalım.

Gömme (embedding) Paylaşımı

Temel ablasyon modelimizin yapılandırmasına bakarsanız, standart bir transformer’dan farklı olan şeylerden birinin, tie_word_embeddings bayrağıyla etkinleştirilen gömme paylaşımı olduğunu görürsünüz.

LLM’lerde iki gömme bileşeni vardır: token’dan vektöre bir eşleme tablosu görevi gören girdi gömmeleri(vocab_size × hidden_dim boyutunda) ve gizli durumları kelime dağarcığı logits’lerine eşleyen son doğrusal katman olan çıkış gömmeleri (hidden_dim × vocab_size boyutunda). Bunların ayrı matrisler olduğu klasik durumda, toplamda 2 × vocab_size × hidden_dim gömme parametresi bulunur. Bu nedenle, özellikle kelime dağarcığı boyutu büyükse, küçük dil modellerinde gömmeler toplam parametre sayısının büyük bir kısmını oluşturabilir. Bu da gömme paylaşımını (girdi gömmelerini çıkışta yeniden kullanmayı) küçük modeller için doğal bir optimizasyon hâline getirir.

Daha büyük modeller genellikle bu tekniği kullanmaz, çünkü gömme vektörleri parametre bütçelerinin daha küçük bir bölümünü temsil eder. Örneğin, aşağıdaki pasta grafiğinde gösterildiği gibi, paylaşım olmadan toplam gömme vektörleri SmolLM3 3B’de parametrelerin yalnızca %8.5ini ve Llama 3.1 70B’de %3'ünü oluşturmaktadır.

Ablasyon — Paylaşımlı Gömme Katmanlarına Sahip Modeller, Daha Büyük Paylaşımsız Varyantlarla Eşleşiyor

Gömme katmanı paylaşımının ablasyon modelimiz üzerindeki etkisini değerlendirelim. Bu teknik üzerine 125M ölçeğinde gerçekleştirilen kapsamlı ablasyon çalışmalarıyla içgörü sağlayan MobileLLM’den yararlanacağız; söz konusu çalışmalar, paylaşımın parametre sayısını %11,8 azalttığını ve bunun yalnızca minimal bir doğruluk kaybına yol açtığını göstermişti.

Paylaşımsız gömme katmanları kullanıldığında parametre sayısı 1,2B’den 1,46B’ye çıktığı için, parametre sayısını yeniden 1,2B seviyesinde tutmak amacıyla katman sayısı azaltılmış, ancak yine paylaşımsız gömme katmanlarına sahip başka bir model eğiteceğiz. Sonrasında ise iki farklı 1,2B modeli karşılaştıracağız, bunlardan biri paylaşımlı gömme katmanları kullanan 16 katmanlı temel modelimiz ve diğeri paylaşımsız gömme katmanlarına sahip 12 katmanlı varyant. Ek bir referans noktası olarak ise, paylaşımsız gömme katmanlarına ve temel modelimizle aynı katman sayısına sahip 1,46B modeli de karşılaştırmaya dahil edeceğiz. Nanotron yapılandırmalarını burada bulabilirsiniz: [https://huggingface.co/datasets/HuggingFaceTB/training-guide-nanotron-configs/blob/main/baseline_config_1B.yaml]

Kayıp ve değerlendirme sonuçları, bağlı gömmelere (tied embeddings) sahip temel 1.2B modelimizin, %18 daha az parametreye sahip olmasına rağmen WinoGrande hariç tüm kıyaslamalarda 1.46B bağlı olmayan (untied) eşdeğeriyle karşılaştırılabilir performans elde ettiğini göstermektedir. Bağlı olmayan gömmelere ve azaltılmış katman sayısına (16 yerine 12) sahip 1.2B model ise her iki yapılandırmadan da daha düşük performans göstermiş, daha yüksek kayıp ve daha düşük aşağı akış değerlendirme skorları sergilemiştir. Bu durum, eşdeğer parametre bütçelerinde model derinliğini artırmanın, gömmelere ayırmaktan daha fazla fayda sağladığını göstermektedir.

Bu sonuçlara dayanarak, SmolLM3–3B modelimiz için bağlı gömmeleri koruduk.

Ancak embedding’ler tek başına bir dizideki token’ların sırasını yakalayamaz; bu bilgiyi sağlama görevi konumsal kodlamalara (positional encodings) aittir. Bir sonraki bölümde, standart RoPE’dan uzun bağlamlar için daha etkili modelleme sağlayan NoPE (No Positional Embedding) gibi daha yeni yaklaşımlara kadar konumsal kodlama stratejilerinin nasıl evrildiğine bakacağız.

Konumsal Kodlama ve Uzun Bağlam

Transformer’lar metni işlerken temel bir zorlukla karşılaşır: Paralel dikkat (attention) işlemleri aracılığıyla tüm dizileri aynı anda tükettikleri için doğal olarak kelime sırası hakkında hiçbir sezgileri yoktur. Bu, verimli eğitimi mümkün kılar ancak bir sorun yaratır. Açık bir konum bilgisi olmadan, modelin bakış açısından “Adam Muon’u yener” ile “Muon Adam’ı yener” ifadeleri benzer görünür.

Çözüm ise konumsal embedding’lerdir: Her token’a dizide benzersiz bir “adres” veren matematiksel kodlamalar. Ancak erken dönem BERT modellerindeki 512 token’lık bağlamlardan günümüzün milyonlarca token’lı modellerine doğru ilerledikçe, konumsal kodlama seçimi hem performans hem de hesaplama verimliliği açısından giderek daha kritik hâle gelmektedir.

Konumsal Kodlamanın Evrimi

İlk transformer modelleri basit mutlak konumsal embedding’ler kullandı; bunlar esasen her konumu (1, 2, 3…) bir vektöre eşleyen ve token embedding’lerine eklenen öğrenilmiş arama tablolarıydı (Vaswani ve ark., 2023). Bu yaklaşım kısa diziler için yeterince iyi çalışıyordu ancak önemli bir sınırlaması vardı: Modellerin maksimum girdi dizisi uzunluğu, eğitildikleri maksimum girdi uzunluğuyla sınırlıydı. Daha uzun dizilere kutudan çıktığı hâliyle genelleme yapma yetenekleri yoktu.

Bu nedenle alan, token’ların mutlak konumları yerine aralarındaki mesafeyi yakalayan göreli konumsal embedding’lere doğru evrildi. Bu sezgisel olarak da mantıklıdır: İki kelimenin 3 pozisyon aralıklı olması, onların (5,8) mi yoksa (105,108) mi konumlarında olduğundan daha önemlidir.

Konumsal kodlama hakkında daha derinlemesine bilgi için, bu blog temel konumlandırmadan döndürmeli kodlamaya kadar olan gelişimi adım adım açıklamaktadır.

Özellikle ALiBi (Attention with Linear Biases) (Press ve ark., 2022), dikkat skorlarını token mesafesine göre değiştirir. İki token birbirinden ne kadar uzaksa, dikkatleri de dikkat ağırlıklarına uygulanan basit doğrusal yanlılıklar aracılığıyla o kadar cezalandırılır. ALiBi’nin ayrıntılı bir uygulamasını labml.ai üzerinde bulabilirsiniz.

Ancak son dönem büyük dil modellerine hâkim olan teknik RoPE’tur (Su ve ark., 2023).

RoPE: Konumu Döndürme Olarak Temsil Etmek

RoPE’un temel içgörüsü, konum bilgisini yüksek boyutlu bir uzayda döndürme açıları olarak kodlamaktır. RoPE, konum vektörlerini token embedding’lerine eklemek yerine, sorgu (query) ve anahtar (key) vektörlerini mutlak konumlarına bağlı açılarla döndürür.

Sezgi şu şekildedir: Embedding’lerimizdeki her boyut çiftini bir çember üzerindeki koordinatlar olarak ele alır ve bunları şu unsurlarla belirlenen bir açı kadar döndürürüz:

• Token’ın dizideki konumu
• Üzerinde çalıştığımız boyut çifti (farklı çiftler farklı frekanslarda döner; bu frekanslar bir temel/referans frekansının üsleridir)

import torch

def apply_rope_simplified(x, pos, dim=64, base=10000):
    """
    Rotary Positional Embedding (RoPE)

    Idea:
    - Each token has a position index p (0, 1, 2, ...).
    - Each pair of vector dimensions has an index k (0 .. dim/2 - 1).
    - RoPE rotates every pair [x[2k], x[2k+1]] by an angle θ_{p,k}.


    Formula:
      θ_{p,k} = p * base^(-k / (dim/2))

    - Small k (early dimension pairs) → slow oscillations → capture long-range info.
    - Large k (later dimension pairs) → fast oscillations → capture fine detail.

    """
    rotated = []
    for i in range(0, dim, 2):
        k = i // 2  # index of this dimension pair

        # Frequency term: higher k → faster oscillation
        inv_freq = 1.0 / (base ** (k / (dim // 2)))
        theta = pos * inv_freq  # rotation angle for position p and pair k

        cos_t = torch.cos(torch.tensor(theta, dtype=x.dtype, device=x.device))
        sin_t = torch.sin(torch.tensor(theta, dtype=x.dtype, device=x.device))

        x1, x2 = x[i], x[i+1]

        # Apply 2D rotation
        rotated.extend([x1 * cos_t - x2 * sin_t,
                        x1 * sin_t + x2 * cos_t])

    return torch.stack(rotated)


## Q, K: [batch, heads, seq, d_head]
Q = torch.randn(1, 2, 4, 8)
K = torch.randn(1, 2, 4, 8)

## 👉 apply RoPE to Q and K *before* the dot product
Q_rope = torch.stack([apply_rope(Q[0,0,p], p) for p in range(Q.size(2))])
K_rope = torch.stack([apply_rope(K[0,0,p], p) for p in range(K.size(2))])

scores = (Q_rope @ K_rope.T) / math.sqrt(Q.size(-1))
attn_weights = torch.softmax(scores, dim=-1)

Bu kod karmaşık görünebilir, bu yüzden somut bir örnekle açıklayalım. “Hızlı kahverengi tilki” ifadesindeki “tilki” kelimesini ele alalım. Temel 1B modelimizde, her dikkat mekanizması 64 boyutlu bir sorgu/anahtar vektörüyle çalışır. RoPE bu vektörü 32 çifte ayırır: (x₁, x₂), (x₃, x₄), (x₅, x₆) ve benzeri. Çiftler üzerinde çalışıyoruz çünkü 2 boyutlu uzayda daireler etrafında dönüyoruz. Basitlik için, ilk çifte, (x₁, x₂)’ye odaklanalım. “Tilki” kelimesi ifademizde 3. pozisyonda yer alıyor, bu nedenle RoPE bu ilk boyut çiftini şu şekilde döndürecektir:

rotation_angle = position × θ₀ 
                = 3 × (1/10000^(0/32))
                = 3 × 1.0 
                = 3.0 radians 
                = 172° degrees

Temel frekansımız 10.000'dir, ancak ilk boyut çifti için (k=0) üssümüz 0'dır, bu nedenle temel frekans hesaplamayı etkilemez (0. kuvvete yükseltiriz). Aşağıdaki görselleştirme bunu göstermektedir.

Şimdi sihir gerçekleşiyor; iki belirteç dikkat yoluyla etkileşime giriyor. Döndürülmüş temsilleri arasındaki nokta çarpımı, dönüş açıları arasındaki faz farkı aracılığıyla göreceli mesafelerini doğrudan kodluyor (burada m ve n belirteç konumlarıdır):

dot_product(RoPE(x, m), RoPE(y, n)) = Σₖ [xₖ * yₖ * cos((m-n) * θₖ)]

Dikkat örüntüsü yalnızca (m−n)’ye bağlıdır; bu nedenle aralarında beş konum bulunan token’lar, dizideki mutlak konumlarından bağımsız olarak her zaman aynı açısal ilişkiye sahip olur. Böylece model, dizideki herhangi bir mutlak konumda çalışabilen ve daha uzun dizilere genellenebilen mesafe tabanlı örüntüler öğrenir.

RoPE Frekansını Yapılandırma

Pratikte, çoğu büyük dil modeli (LLM) ön eğitimi, RoPE için 10k veya 50k gibi temel frekanslar kullanılarak görece kısa bağlam uzunluklarıyla (2–4k token) başlar. Başlangıçtan itibaren çok uzun dizilerle eğitim yapmak, dikkat mekanizmasının dizi uzunluğuna göre karesel ölçeklenmesi ve uzun bağlamlı verilerin sınırlı bulunabilirliği (4k’dan büyük bağlam uzunluğuna sahip örnekler) nedeniyle hesaplama açısından pahalı olur; bunu daha önce belge maskelemesini incelerken görmüştük. Araştırmalar ayrıca bunun kısa bağlam performansına zarar verebileceğini de göstermektedir (Zhu vd., 2025). Modeller genellikle önce kelimeler arasındaki kısa menzilli korelasyonları öğrenmeye başlar; bu yüzden uzun diziler başlangıçta çok fazla fayda sağlamaz. Yaygın yaklaşım, ön eğitimin büyük kısmını daha kısa dizilerle yapmak, ardından sürekli ön eğitim uygulamak ya da son birkaç yüz milyar token’ı daha uzun dizilere ayırmaktır. Ancak dizi uzunlukları arttıkça, token konumlarıyla orantılı olan dönüş açıları da büyür; bu da uzak token’lar arasındaki dikkat skorlarının çok hızlı biçimde azalmasına neden olabilir (Rozière vd., 2024; Xiong vd., 2023):

θ = position x 1 / (base^(k/(dim/2)))

Çözüm, dizi uzunluğu arttıkça taban frekansını artırarak bu tür sönümlenmeyi önlemektir; bunun için ABF ve YaRN gibi yöntemler kullanılır.

RoPE ABF (Ayarlanmış Taban Frekanslı RoPE) (Xiong vd., 2023b), RoPE formülasyonundaki taban frekansını artırarak uzun bağlamlardaki dikkat (attention) sönümlenmesi problemini ele alır. Bu ayarlama, token konumları arasındaki dönüş açılarını yavaşlatır ve uzak token’ların dikkat skorlarının çok hızlı düşmesini engeller. ABF tek aşamada (doğrudan frekans artırımı) ya da çok aşamalı olarak (bağlam büyüdükçe kademeli artışlar) uygulanabilir. Yöntem uygulanması kolaydır ve gömülü vektörleri daha yüksek ayrıntı düzeyiyle dağıtarak modelin uzak konumları daha kolay ayırt etmesini sağlar.

Basit ve etkili olmasına rağmen, ABF’nin tüm boyutlar boyunca yaptığı tekdüze ölçekleme çok uzun bağlamlar için optimal olmayabilir. YaRN (Yet another RoPE extensioN) (Peng vd., 2023) ise daha gelişmiş bir yaklaşım benimser ve bir ramp ya da ölçekleme fonksiyonu kullanarak frekansları RoPE boyutları boyunca eşit olmayan biçimde enterpole eder. ABF’nin tekdüze ayarlamasının aksine, YaRN farklı frekans bileşenlerine farklı ölçekleme katsayıları uygular ve böylece genişletilmiş bağlam penceresini optimize eder. Ayrıca dinamik dikkat ölçekleme ve attention logits üzerinde sıcaklık ayarlaması gibi ek teknikler içerir; bunlar çok büyük bağlam boyutlarında performansın korunmasına yardımcı olur. YaRN, verimli “kısa eğit, uzun test et” stratejilerine olanak tanır; sağlam ekstrapolasyon için daha az token ve daha az ince ayar (fine-tuning) gerektirir. ABF’den daha karmaşık olsa da, YaRN genellikle çok uzun bağlamlarda daha iyi ampirik performans sunar; çünkü daha pürüzsüz ölçekleme sağlar ve felaket düzeyindeki dikkat kaybını azaltır. Ayrıca hiçbir ince ayar yapmadan yalnızca çıkarım (inference) aşamasında da kullanılabilir.

Bu frekans ayarlama yöntemleri dikkat skoru sönümlenmesi etkisini yavaşlatır ve uzak token’ların katkısını korur. Örneğin, Qwen3’ün eğitimi sırasında bağlam penceresi 4k’dan 32k’ya genişletilirken ABF kullanılarak frekans 10k’dan 1M’ye çıkarılmıştır (ekip daha sonra 131k’ya ulaşmak için YaRN uygulamış ve 4× ekstrapolasyon elde etmiştir). Optimal değerler konusunda güçlü bir fikir birliği olmadığını ve bağlam genişletme aşamasında farklı RoPE değerlerini deneyerek kendi kurulumunuz ve değerlendirme ölçütleriniz için en iyi sonucu veren ayarları bulmanın genellikle faydalı olduğunu unutmayın.

Bugün büyük modellerin çoğu RoPE kullanmaktadır: Llama, Qwen, Gemma ve daha niceleri. Bu teknik, farklı model boyutları ve mimarilerinde (yoğun/dense, MoE, hibrit) dayanıklılığını kanıtlamıştır.

Hibrit Konumsal Kodlama Yaklaşımları

Ancak modeller giderek daha büyük bağlamlara yöneldikçe (Meta AI, 2025; Yang vd., 2025), RoPE bile performans zorlukları yaşamaya başlıyor. Uzun bağlam genişletmelerinde RoPE frekansını artırmaya dayanan standart yaklaşımın, Needle in a Haystack (NIAH) (Kamradt, 2023) testinden daha zor uzun bağlam ölçütlerinde — örneğin RULER ve HELMET (Hsieh vd., 2024; Yen vd., 2025) — sınırlamaları olduğu görülmüştür. Bu sorunu hafifletmek için daha yeni teknikler geliştirilmiştir.

Bu bölüme başlarken transformer’ların token sırasını anlayabilmesi için konumsal bilgiye ihtiyaç duyduğunu söylemiştik; ancak son araştırmalar bu varsayımı sorgulamaya başladı. Ya açık konumsal kodlamalar aslında gerekli değilse?

NoPE (Kazemnejad vd., 2023), transformer’ları hiçbir açık konumsal kodlama olmadan eğitir ve modelin konumsal bilgiyi nedensel maskeleme (causal masking) ve dikkat örüntüleri aracılığıyla örtük biçimde öğrenmesine izin verir. Yazarlar, bu yaklaşımın ALiBi ve RoPE’a kıyasla daha iyi uzunluk genellemesi sergilediğini göstermektedir. Eğitim uzunluklarının ötesine ekstrapole edilmesi gereken açık bir konumsal kodlama olmadığından, NoPE doğal olarak daha uzun bağlamları işleyebilir. Ancak pratikte NoPE modelleri, kısa bağlamlı akıl yürütme ve bilgi görevlerinde RoPE modellerine göre daha zayıf performans gösterme eğilimindedir (B. Yang vd., 2025). Bu durum, açık konumsal kodlamaların ekstrapolasyonu sınırlayabilmesine rağmen, eğitim bağlam uzunluğu içindeki görevler için yararlı endüktif önyargılar sağladığını göstermektedir.

Bu ödünleşimler göz önüne alındığında, B. Yang vd. (2025), farklı konumsal kodlama stratejilerini birleştirmenin ilginç olabileceğini öne sürmektedir. Tanıttıkları hibrit yaklaşım olan RNoPE, model boyunca RoPE ve NoPE katmanlarını dönüşümlü olarak kullanır. RoPE katmanları açık konumsal bilgi sağlar ve yakınlık önyargısıyla (recency bias) yerel bağlamı işlerken, NoPE katmanları uzun mesafelerde bilgi erişimini iyileştirir. Bu teknik yakın zamanda Llama 4, Command A ve SmolLM3 modellerinde kullanılmıştır.

Not: RNoPE’a buradan sonra kolaylık olması açısından NoPE diyeceğiz.

Ablasyon — NoPE, Kısa Bağlamlı Belgelerde RoPE ile Eşleşiyor

Hibrit NoPE yaklaşımını test edelim. Bu teknikler arasındaki etkileşimi test etmek için, saf bir RoPE 1B ablasyon tabanını, her dördüncü katmanda konum kodlamasını kaldıran bir NoPE varyantı ve NoPE’u belge maskelemesiyle birleştiren üçüncü bir yapılandırmayla karşılaştıracağız. Temel sorumuz şu: Uzun bağlam yetenekleri kazanırken güçlü kısa bağlam performansını koruyabilir miyiz?

Kayıp ve değerlendirme sonuçları, üç yapılandırmanın tamamında benzer performans gösteriyor; bu da NoPE’un güçlü kısa bağlam yeteneklerini korurken aynı zamanda daha iyi uzun bağlam işleme için bir temel sağladığını gösteriyor. Bu sonuçlara dayanarak, SmolLM3 için NoPE + belge maskeleme kombinasyonunu benimsedik.

Bir diğer tamamlayıcı fikir ise RoPE’u model boyutunun yalnızca bir alt kümesine uygulamaktır. Tüm katmanları dönüşümlü olarak RoPE ve NoPE arasında değiştiren RNoPE’un aksine, kısmi RoPE bunları aynı katman içinde bir araya getirir. GLM-4.5 (5 Team ve diğerleri, 2025) ve MiniMax-01 (MiniMax ve diğerleri, 2025) gibi yakın dönem modeller bu stratejiyi benimsemiştir; ancak bu yaklaşım daha eski modellerde de, örneğin OpenAI tarafından geliştirilen GPT-J’de (Wang & Komatsuzaki, 2021) bulunuyordu. Ayrıca MLA kullanan her modelde de kısmi RoPE göreceksiniz; çünkü makul çıkarım maliyetleri için bu yaklaşım vazgeçilmezdir.

Neden “partial RoPE” MLA için önemli?

Çok başlı gizli dikkat (MLA: Multi-head Latent Attention), hesaplamayı hızlandırmak için her baş için ayrı anahtar saklamak yerine daha küçük bir “ortak gizli temsil” kullanır. Yani her token için büyük key’ler tutmak yerine:

• Her girdiden küçük bir vektör (cᵢ) üretilir.
• Her dikkat başı bu vektörü kullanarak skor hesaplar.
• Böylece hafıza ve hesaplama ciddi şekilde azalır.

Bu yaklaşımda normalde skor şöyle sadeleşir:

Query ve key dönüşümleri birleştirilerek tek bir matris (U) haline getirilir ve bu sayede işlem maliyeti düşer. RoPE, konum bilgisini eklemek için vektörlere döndürme (rotation) uygular; ancak bu döndürme token i ile token t arasındaki farka (t − i) bağlıdır ve bu nedenle her token çifti için değişkenlik gösterir. Bu durum, önceden birleştirilmiş tek bir dönüşüm matrisi (U) kullanmayı imkânsız hale getirir ve böylece MLA’nın sağladığı verimlilik avantajı bozulur.

Partial RoPE yaklaşımı ise embedding boyutunu ikiye ayırır. RoPE uygulanmayan büyük kısımda MLA normal şekilde çalışır ve dönüşümler önceden birleştirilebilir, bu da işlemi hızlı ve düşük maliyetli hale getirir. RoPE uygulanan küçük kısımda ise yalnızca döndürme işlemi yapılır ve böylece konum bilgisi korunur. Sonuç olarak RoPE tamamen kullanılırsa MLA’nın hız avantajı kaybolur, hiç kullanılmazsa konum bilgisi eksik kalır; partial RoPE kullanıldığında ise ikisi aynı anda sağlanır. Yani büyük kısmı hızlandırılırken küçük bir kısmı konum bilgisini korur ve bu sayede MLA hem verimli hem de konum-duyarlı kalır.

Uzun Bağlamlar için Dikkat Kapsamının Sınırlandırılması

Şimdiye kadar, uzun bağlamlarda konumsal bilgiyi nasıl ele alabileceğimizi inceledik: RoPE’un etkinleştirilmesi, devre dışı bırakılması (NoPE), bazı katmanlarda kısmen uygulanması (RNoPE) veya bazı gizli boyutlarda kısmi olarak kullanılması (partial RoPE), ya da frekansının ayarlanması (ABF, YaRN). Bu yaklaşımlar, modelin eğitim sırasında gördüğünden daha uzun dizileri işleyebilmesi için konum kodlamasını nasıl temsil ettiğini değiştirir. Ancak bunun tamamlayıcı bir stratejisi daha vardır: konumsal kodlamaları ayarlamak yerine, hangi token’ların birbirine dikkat (attention) verebileceğini sınırlayabiliriz.

Bunun neden önemli olduğunu görmek için, 8 token’lık dizilerle önceden eğitilmiş bir modeli düşünün. Çıkarım (inference) aşamasında 16 token işlemek istiyoruz (eğitim uzunluğundan daha fazla). 8–15 aralığındaki pozisyonlar, modelin konumsal kodlaması açısından dağılım dışıdır (out of distribution). RoPE ABF gibi teknikler bu sorunu konum frekanslarını ayarlayarak çözerken, dikkat kapsamı (attention scope) yöntemleri farklı bir yaklaşım benimser: token’ların birbirine hangi ölçüde dikkat edebileceğini stratejik olarak kısıtlar ve böylece dikkat örüntülerini tanıdık aralıklarda tutarken tüm diziyi işlemeye devam eder. Bu, hem hesaplama maliyetini hem de bellek gereksinimlerini azaltır.

Aşağıdaki diyagram, 8 token’lık bir ön eğitim penceresi ile 16 token’lık bir diziyi ele almak için kullanılan beş stratejiyi karşılaştırmaktadır.”

Parçalı dikkat (Chunked attention), diziyi sabit boyutlu parçalara (chunk’lara) böler; burada token’lar yalnızca kendi chunk’ları içinde dikkat (attention) kurabilir. Örneğimizde 16 token, iki adet 8’li chunk’a (0–7 ve 8–15) ayrılmıştır. Dikkat edin, 8 ile 15 arasındaki token’lar önceki chunk’a hiç geri bakamaz. Bu, chunk sınırlarında sıfırlanan izole dikkat pencereleri oluşturur. Llama 4 (Meta AI, 2025), RoPE katmanlarında 8.192 token’lık chunk’larla chunked attention kullanır (decoder katmanlarının dördü üzerinden üçünde), NoPE katmanları ise tam bağlam erişimini korur. Bu yaklaşım, katman başına KV cache boyutunu sınırlayarak bellek gereksinimlerini azaltır; ancak bir chunk içindeki token’ların önceki chunk’lara bakamaması bazı uzun bağlam görevlerinde performansı etkileyebilir.

Sliding Window Attention (SWA), Mistral 7B ile popülerleşen ve “en güncel token’lar en önemlidir” sezgisine dayanan farklı bir yaklaşımdır (Child et al., 2019; Jiang et al., 2023). Sert chunk sınırları yerine, her token yalnızca kendisinden önceki en son N token’a dikkat eder. Diyagramda gösterildiği gibi, her token geriye doğru en fazla 8 pozisyonu görebilir ve bu, dizi boyunca sürekli kayan bir pencere oluşturur. Örneğin token 15, 8–15 aralığındaki pozisyonlara bakabilirken; token 10, 3–10 aralığına dikkat eder. Bu pencere sürekli ileri kayarak, chunking’deki yapay sınırlar olmadan tüm dizi boyunca yerel bağlamı korur. Gemma 3 ise SWA’yı tam dikkat ile alternatif katmanlarda birleştirir; bu, hibrit pozisyonel kodlama yaklaşımlarının farklı stratejileri harmanlamasına benzer.

Çift Parça Dikkat (DCA: Dual Chunk Attention) (An et al., 2024), parçalı dikkatı genişleten ve parçalar arası bilgi akışını koruyan eğitim gerektirmeyen (training-free) bir yöntemdir. Örneğimizde chunk boyutu s = 4 kullanılır ve 16 token 4 chunk’a bölünür (diyagonal boyunca 4×4 kareler olarak görselleştirilebilir). DCA üç mekanizmayı birleştirir:

Parça içi dikkat (intra-chunk attention): Belirteçler kendi parçaları içinde normal şekilde (çapraz desende) dikkat kurar.

Chunk’lar arası dikkat (inter-chunk attention): Sorgular c − 1 = 7 konum indeksini kullanarak önceki chunk’lara bakar ve 7 ile sınırlandırılmış göreli pozisyonlar oluşturur.

Ardışık parça dikkat (Successive Chunk Attention): w = 3 yerel penceresi ile komşu parçalar arasındaki yerelliği korur.

Bu yapı, tüm göreli pozisyonları eğitim dağılımı içinde (0–7) tutarken parça sınırları arasında yumuşak geçişler sağlar. DCA, Qwen2.5 gibi modellerin çıkarım (inference) sırasında sürekli milyon-token eğitimine ihtiyaç duymadan ultra uzun bağlam pencerelerini (1 milyon tokene kadar) desteklemesini mümkün kılar.

Dikkat havuzları (Attention sinks)

Transformer modellerinde uzun bağlamlar kullanıldığında ilginç bir olgu ortaya çıkar: Model, dizinin başındaki belirteçlere anlamsal olarak önemli olmasalar bile alışılmadık derecede yüksek dikkat puanları atar. Bu başlangıç belirteçleri, dikkat dağılımı için bir dengeleme mekanizması gibi davranır ve dikkatin birikebildiği bir “havuz (sink)” görevi görür (Xiao ve ark., 2024).

Pratik çıkarım şudur: Sadece ilk birkaç belirtecin KV önbelleğini, son belirteçleri içeren kayan bir pencere ile birlikte tutmak, bağlam önbelliği boyutunu aştığında bile performansı büyük ölçüde korur. Bu basit değişiklik, modellerin ince ayar (fine-tuning) yapılmadan veya performans kaybı yaşamadan çok daha uzun dizileri işlemesini sağlar.

Modern uygulamalar dikkat havuzu kavramını farklı şekillerde kullanır. Orijinal araştırma, ön eğitim sırasında açık bir dikkat havuzu görevi görmesi için özel bir yer tutucu (placeholder) belirteci eklenmesini önerir. Daha yeni modellerde ise, örneğin gpt-oss gibi, dikkat havuzları girdi dizisine gerçek belirteç eklemek yerine, dikkat puanlarına eklenen öğrenilmiş her baş’a (head) bias logit’leri olarak uygulanır. Bu yaklaşım, belirteçleştirilmiş girdileri değiştirmeden aynı dengeleme etkisini sağlar.

İlginç bir şekilde, gpt-oss ayrıca dikkat katmanlarında önyargı (bias) birimleri de kullanır; bu, GPT-2’den bu yana nadiren görülen bir tasarım tercihidir. Bu önyargı birimleri genellikle standart dikkat işlemleri için gereksiz kabul edilir (Dehghani ve ark.’nın deneysel sonuçları test kaybı üzerinde minimal etki gösterir), ancak dikkat havuzlarını uygulamak gibi özel bir işlev görebilirler. Temel fikir şudur: İster özel belirteçler, ister öğrenilmiş önyargılar, ister her baş’a logit’ler olarak uygulansın, dikkat havuzları uzun bağlam senaryolarında dikkat dağılımı için istikrarlı bir “çapa” sağlar ve bağlam keyfi olarak uzasa bile modelin tüm dizi hakkında genel olarak faydalı bilgileri saklamasına imkân tanır.

Artık dikkatin temel bileşenlerini ele aldık: bellek ve hesaplama maliyetini dengeleyen farklı baş yapıları (MHA, GQA, MLA), belirteç sırasını modellerin anlamasına yardımcı olan konumsal kodlama stratejileri (RoPE, NoPE ve türevleri) ve uzun bağlamları daha yönetilebilir hale getiren dikkat kapsamı teknikleri (kayan pencere, parçalama ve dikkat havuzları). Ayrıca gömme katmanlarının nasıl yapılandırılması ve başlatılması gerektiğini de inceledik. Bu mimari seçimler, modelinizin dizileri nasıl işlediğini ve temsil ettiğini belirler.

Ancak doğru mimariye sahip olmak işin yalnızca yarısıdır. İyi tasarlanmış modeller bile, özellikle ölçek büyüdükçe, eğitim kararsızlığından muzdarip olabilir. Şimdi eğitim stabilitesini artırmaya yardımcı olan bazı tekniklere bakalım.

Stabiliteyi İyileştirme

Şimdi, LLM ön-eğitimindeki en büyük zorluklardan birine geçiyoruz: kararsızlıklar. Genellikle kayıp değerinde ani sıçramalar veya beklenmedik yükselişler şeklinde ortaya çıkan bu problemler, özellikle büyük ölçeklerde daha yaygın hale gelir.

“Training Marathon” bölümünde (kayan noktalı kesinlik, eniyileyiciler ve öğrenme oranı gibi konuları ele alarak) bu sıçramaların farklı türlerini ve nasıl ele alınacağını daha derinlemesine inceleyeceğiz. Ancak bazı mimari ve eğitim teknikleri de kararsızlığı azaltmaya yardımcı olabilir; bu yüzden bunlara kısa bir göz atalım. Son dönemdeki büyük ölçekli eğitim çalışmalarında (ör. OLMo 2 (OLMo et al., 2025) ve Qwen3 (A. Yang, Li, et al., 2025)) kullanılan ve stabiliteyi artıran bazı basit teknikleri inceleyeceğiz: Z-kayıp, gömmelerden ağırlık çürümesinin (weight decay) kaldırılması ve QK-norm.

Z-kaybı (Z-loss)

Z-kaybı (Chowdhery ve ark., 2022), modelin son çıktı logit’lerinin aşırı büyümesini engellemek için kayıp fonksiyonuna bir ceza terimi ekleyen bir düzenlileştirme (regularization) tekniğidir. Bu düzenlileştirme, logit’ler üzerinde softmax uygulanırken paydadaki toplamın (denominator) makul bir aralıkta kalmasını teşvik eder ve böylece eğitim sırasında sayısal kararlılığı korumaya yardımcı olur:

L_{z-loss}=λ⋅log⁡²(Z)

1B modelimiz üzerinde yapılan ablasyonun sonuçları, Z-kaybı eklemenin eğitim kaybını veya aşağı akış (sonraki çıktıların) performansını etkilemediğini göstermektedir. SmolLM3 için ise, eğitim başlarken Z-kaybı uygulamamız ek bir hesaplama yükü (training overhead) oluşturduğu ve o zamana kadar bunu eniyilemediğimiz için bu yöntemi kullanmamaya karar verdik.

Gömlemelerden Ağırlık Çürümesinin (Weight Decay) Kaldırılması

Ağırlık çürümesi (weight decay), genellikle bir düzenlileştirme tekniği olarak modelin tüm parametrelerine uygulanır; ancak OLMo ve ark. (2025), gömlemelerin bu işlemden hariç tutulmasının eğitim kararlılığını artırdığını bulmuştur. Bunun nedeni, ağırlık çürümesinin eğitim sırasında gömleme normlarının giderek küçülmesine yol açmasıdır. Bu durum, özellikle ilk katmanlarda daha büyük gradyanlara neden olabilir; çünkü katman normalizasyonunun Jacobian’ı, girdi normuna ters orantılıdır (Takase ve ark., 2025).

Bu yaklaşımı üç farklı yapılandırma eğiterek test ettik: standart ağırlık çürümesi kullanılan temel modelimiz, gömlemelerde ağırlık çürümesi uygulanmayan bir varyant ve son olarak tüm benimsenen değişikliklerin bir arada kullanıldığı üçüncü bir yapılandırma (gömlemelerde weight decay yok + NoPE + doküman maskeleme). Bu son yapılandırma, teknikler arasında olumsuz bir etkileşim olup olmadığını kontrol etmek için kullanıldı.

Kayıp (loss) eğrileri ve değerlendirme sonuçları üç yapılandırma arasında neredeyse aynıydı. Bu nedenle SmolLM3 eğitiminde bu üç değişikliğin tamamını benimsedik.

QK-norm

QK-norm (Dehghani ve ark., 2023), dikkat (attention) hesaplanmadan önce hem query (sorgu) hem de key (anahtar) vektörlerine katman normalizasyonu uygular. Bu teknik, attention logit’lerinin aşırı büyümesini önlemeye yardımcı olur ve kararlılığı artırmak için birçok modern modelde kullanılmıştır.

Ancak B. Yang ve ark. (2025), QK-norm’un uzun bağlam görevlerinde performansı düşürdüğünü bulmuştur. Analizleri, QK-norm’un ilgili token’lara (ipuçlarına / “needles”) daha düşük attention ağırlığı verdiğini ve ilgisiz bağlama daha yüksek attention ağırlığı verdiğini ortaya koymuştur. Bunun, normalizasyon işleminin query–key nokta çarpımındaki büyüklük (magnitude) bilgisini kaldırmasından kaynaklandığını ve bu nedenle attention logit’lerinin birbirine daha yakın büyüklükte hale geldiğini savunurlar.

Bu nedenle SmolLM3’te QK-norm kullanılmamıştır. (Ayrıca 3B parametreli küçük bir model olduğu için, QK-norm’un en çok fayda sağladığı büyük modellerde görülen eğitim kararsızlığı riski de daha düşüktür.)

Ek Hususlar

Şu ana kadar ele aldığımız bileşenlerin ötesinde, tamamlayıcılık açısından bahsedilmesi gereken birkaç mimari karar daha vardır.

Parametreleri başlatmak için modern modeller genellikle kırpılmış normal dağılım başlatma (ortalama=0, std=0.02 veya std=0.006) ya da μP (G. Yang & Hu, 2022) gibi bir başlatma şeması kullanır (örneğin Cohere’in Command A modeli (Cohere ve ark., 2025)). Bu da ablasyon çalışmaları için ayrı bir konu olabilir.

Aktivasyon fonksiyonları açısından ise SwiGLU, modern büyük dil modellerinde fiili standart haline gelmiştir (Gemma 2 hariç, GeGLU kullanır; NVIDIA ise ReLU² kullanır (Nvidia ve ark., 2024; NVIDIA ve ark., 2025)). Bu, ReLU veya GELU gibi eski seçeneklerin yerini almıştır.”

Daha geniş ölçekte, mimari düzen tercihleri de model davranışının şekillenmesinde rol oynar. Bir dil modelinin kapasitesini büyük ölçüde toplam parametre sayısı belirlese de, bu parametrelerin derinlik ve genişlik boyunca nasıl dağıtıldığı da önemlidir. Petty ve arkadaşları (2024), daha derin modellerin, aynı büyüklükteki daha geniş modellere kıyasla dil modelleme ve bileşimsel görevlerde daha iyi performans gösterdiğini; ancak bu avantajın belirli bir noktadan sonra doygunluğa ulaştığını göstermiştir. Bu “derin ve ince” stratejisi, MobileLLM deneylerinde (Z. Liu ve ark., 2024) bir milyardan az parametreye sahip LLM’ler için iyi sonuç verirken, daha geniş modeller daha yüksek paralellik sayesinde genellikle daha hızlı çıkarım (inference) sunar. Modern mimariler bu ödünleşimi farklı şekillerde yansıtmaktadır; bununla ilgili olarak Sebastian Raschka’nın LLM mimarileri karşılaştırmasına bakılabilir.

Şimdiye kadar, eğitim çalışmanız açısından optimize edilmeye değer yoğun (dense) Transformer mimarisinin en önemli yönlerini ele aldık. Ancak son dönemde, modelin tamamını ilgilendiren başka mimari müdahaleler de ortaya çıkmıştır; bunlar arasında MoE (Mixture of Experts) ve hibrit modeller bulunmaktadır. Şimdi, MoE’lerle başlayarak bunların neler sunduğuna bakalım.

Seyrekliğe Geçiş: MoE (Mixture of Experts)

Mixture of Experts (Uzman Karışımı) modellerinin temel fikri, her bir token tahmini için modelin tamamına ihtiyaç duymadığımızdır. Bu durum, beynimizin eldeki göreve bağlı olarak farklı bölgelerini etkinleştirmesine (örneğin görsel korteks veya motor korteks) benzetilebilir. Bir LLM açısından bakıldığında, programlama sözdizimini öğrenmiş olan bileşenlerin model bir çeviri görevi gerçekleştirirken kullanılmasına gerek olmayabilir. Eğer bunu etkili bir şekilde başarabilirsek, önemli miktarda hesaplama kaynağından tasarruf edebiliriz; çünkü çıkarım (inference) sırasında yalnızca modelin belirli bölümlerini çalıştırmamız yeterli olur.

Teknik açıdan bakıldığında, MoE’lerin amacı oldukça basittir: Her token için kullanılan (“aktif”) parametre sayısını artırmadan toplam parametre sayısını büyütmek. Biraz basitleştirmek gerekirse, toplam parametre sayısı modelin genel öğrenme kapasitesini etkilerken, aktif parametre sayısı eğitim maliyetini ve çıkarım hızını belirler. Bu nedenle günümüzde birçok öncü sistemin (örneğin DeepSeek-V3, Kimi K2 ve Gemini, Grok gibi kapalı kaynaklı modellerin) MoE mimarilerini kullandığını görüyoruz.

Aşağıdaki grafik, Ling 1.5 makalesinden (L. Team ve ark., 2025) alınmıştır ve MoE ile yoğun (dense) modellerin ölçeklenme yasalarını karşılaştırmaktadır.

MoE’lerle ilk kez karşılaşıyorsanız endişelenmeyin; çalışma mekanizması karmaşık değildir. Standart yoğun (dense) mimariyle başlayalım ve MoE’ye geçmek için hangi değişikliklerin gerektiğine bakalım (şekil: Sebastian Raschka):

MoE’lerde tek bir çok katmanlı algılayıcı (MLP) yerine birden fazla MLP (“uzman”/expert) kullanılır ve MLP’lerin önüne öğrenilebilir bir yönlendirici (router) eklenir. Her token için yönlendirici, çalıştırılacak uzmanların küçük bir alt kümesini seçer. Toplam parametreler ile aktif parametreler arasındaki ayrım da buradan kaynaklanır: Model çok sayıda uzmana sahiptir, ancak belirli bir token bunların yalnızca birkaçını kullanır.

Bir MoE katmanı tasarlarken birkaç temel soru ortaya çıkar:

• Uzman yapısı ve seyreklik (sparsity): Çok sayıda küçük uzman mı, yoksa daha az sayıda büyük uzman mı kullanılmalıdır? Her token için kaç uzman aktif olmalıdır ve toplamda kaç uzmana ihtiyaç vardır (yani seyreklik derecesi veya “top-k” değeri)? Bazı uzmanlar evrensel olup her zaman aktif olmalı mıdır?
• Kullanım ve uzmanlaşma: Yönlendirilen uzmanlar nasıl seçilmeli ve bunların etkin şekilde kullanılmaları (yani kapasitenin atıl kalmaması) nasıl sağlanmalıdır? Aynı zamanda uzmanların belirli alanlarda uzmanlaşmaları nasıl teşvik edilmelidir? Uygulamada bu, eğitim ve çıkarım verimliliği üzerinde önemli etkileri olan bir yük dengeleme (load balancing) problemidir.

Burada tek bir hedefe odaklanacağız: Sabit bir hesaplama bütçesi altında, kaybı (loss) en aza indirecek MoE yapılandırmasını nasıl seçebiliriz? Bu soru, saf sistem verimliliği (throughput/gecikme) meselesinden farklıdır; bu konuya daha sonra geri döneceğiz.

Bu bölümün büyük kısmı, Ant Group’un MoE ölçeklenme yasaları üzerine çalışmasına (Tian ve ark., 2025) dayanmaktadır. Bu çalışmada kullanılan Efficiency Leverage (EL) kavramını kullanacağız.

Basitçe ifade etmek gerekirse, EL; belirli bir MoE tasarımının ulaştığı kayıp değerine erişebilmek için yoğun (dense) bir modelin ne kadar hesaplama yapması gerektiğini ölçer. Ölçü birimi kayan nokta işlemleri (FLOPs) cinsindendir. Daha yüksek bir EL değeri, MoE yapılandırmasının yoğun eğitime kıyasla birim hesaplama başına daha fazla kayıp iyileşmesi sağladığı anlamına gelir.

MoE’nin seyreklik (sparsity) düzeyini verimlilik kaldıraç etkisini (Efficiency Leverage, EL) artıracak şekilde nasıl ayarlayabileceğimize daha yakından bakalım.

Seyreklik / Aktivasyon Oranı

Özet (TL;DR): Daha fazla seyreklik → Daha iyi FLOPs verimliliği → Çok yüksek seyreklikte azalan getiriler → En uygun nokta (sweet spot) sahip olduğunuz hesaplama bütçesine bağlıdır.

Bu bölümdeki amacımız, hangi MoE ayarının en iyi olduğunu belirlemektir. Asimptotik açıdan bakıldığında, iki uç durumun da ideal olmadığı kolayca görülebilir.

Bir tarafta, tüm uzmanların her zaman etkinleştirilmesi durumu vardır. Bu bizi yeniden yoğun (dense) mimariye götürür; burada tüm parametreler her zaman kullanılır.

Diğer tarafta ise aktif parametre sayısının çok düşük olduğu durum bulunur. En uç örnek olarak yalnızca tek bir parametrenin aktif olduğunu düşünün. Böyle bir yapının, dar bir alan için bile olsa, bir görevi başarıyla yerine getirmesi açıkça mümkün olmayacaktır.

Dolayısıyla bu iki uç nokta arasında bir denge bulmamız gerekir.

En uygun yapılandırmayı araştırmadan önce, iki önemli büyüklüğü tanımlamak faydalı olacaktır: aktivasyon oranı (activation ratio) ve bunun tersi olan seyreklik (sparsity).

aktivasyon oranı (activation ratio) = aktive edilen uzman sayısı / toplam uzman sayısı

seyreklik (sparsity) = toplam uzman sayısı / aktive edilen uzman sayısı = 1 / aktivasyon oranı

Hesaplama perspektifinden bakıldığında maliyet, yalnızca aktif parametreler tarafından belirlenir. Eğer etkinleştirilen uzmanların sayısını (ve boyutunu) sabit tutup toplam uzman sayısını artırırsanız, çıkarım/eğitim FLOPs bütçesi büyük ölçüde aynı kalır; ancak modele ek kapasite eklemiş olursunuz. Bu da, model yeterince uzun süre eğitildiği sürece genellikle daha iyi performans anlamına gelir.

Son dönemdeki MoE çalışmalarına bakıldığında bazı ilginç ampirik sonuçlar görülmektedir: Aktif uzman sayısı ve boyutu sabit tutulduğunda, toplam uzman sayısının artırılması (yani aktivasyon oranının düşmesi / seyrekliliğin artması) kaybı (loss) iyileştirir. Ancak bu iyileşme, seyreklik çok yüksek seviyelere ulaştığında azalan getiriler göstermeye başlar.

Aşağıdaki şekilleri düşünün:

• Kimi K2 grafiği (K. Team ve ark., 2025) her iki etkiyi de gösterir: Daha yüksek seyreklik performansı artırır, ancak seyreklik arttıkça kazanımlar giderek yavaşlar (taper off).
• Ant Group grafiği (Tian ve ark., 2025) aynı sonucu doğrular; ayrıca ek bir bulgu olarak, daha yüksek seyreklikli MoE’lerin ek hesaplama (compute) artırımlarından daha fazla fayda sağladığını gösterir.

Şekil 5: Seyreklik Ölçekleme Yasası. Seyrekliğin artması, model performansının iyileşmesine yol açar. Aktif uzman sayısını 8'e, paylaşılan uzman sayısını ise 1'e sabitledik ve toplam uzman sayısını değiştirerek farklı seyreklik seviyelerine sahip modeller elde ettik.

Şekil 5. Aktivasyon Oranı A’nın Kayıp ve Verimlilik Üzerindeki Etkisi. (a) Herhangi bir sabit hesaplama bütçesinde (her renkli çizgi), daha düşük aktivasyon oranları daha düşük kayıp sağlar. Turuncu yıldızlar en uygun (en düşük) kayıp noktasını işaretler. (b) Kayıp ve EL ölçekleme eğrileri, EL’nin hem daha yüksek hesaplama bütçeleri hem de daha düşük aktivasyon oranlarıyla arttığını göstermekte ve MoE avantajlarının ölçekte büyüdüğünü ortaya koymaktadır.

Aşağıdaki tabloda bazı MoE modellerinin seyreklik oranları listelenmiştir:

Model, toplam uzman sayıları, token başına aktive edilen uzman sayıları ve seyrekliği

Trendlerin gittiği yön açık: MoE modeller giderek daha seyrek hale geliyor. Bununla birlikte, optimum seyreklik hala donanıma ve uçtan uca verimliliğe bağlıdır. Örneğin, Step-3 en yüksek verimliliği hedefliyor ve belirli donanım ve bant genişliği kısıtlamalarına uyması için kasıtlı olarak seyrekliği en üst düzeye çıkarmıyor, gpt-oss-20b ise cihaz içi bellek kısıtlamaları nedeniyle düşük bir seyrekliğe sahip (pasif uzman hala bir miktar bellek kullanıyor).

Granülerlik

Seyreklik (sparsity) dışında, her bir uzmanın (expert) ne kadar büyük olması gerektiğine de karar vermemiz gerekir. Bu kavram, Ant Group tarafından tanıtılan granularity (granülerlik) metriği ile ifade edilir. Terimin neyi kastettiğini netleştirelim; çünkü farklı çalışmalarda terminoloji değişebiliyor ve bazıları biraz farklı formüller kullanıyor. Burada, referans aldığımız grafiklerle uyumlu olan tanımı kullanacağız:

G = a * d_model / d_expert with a = 2 or 4

Daha yüksek bir granularity değeri, sabit bir toplam parametre sayısı altında daha fazla sayıda ama daha küçük boyutlu uzman (expert) bulunduğu anlamına gelir. Bu metrik, uzman boyutu ( d_expert) ile model boyutu ( d_model) arasındaki bir oran olarak tanımlanır.

Yoğun (dense) modellerde yaygın bir kural olarak MLP ara katman boyutu genellikle şu şekilde seçilir:

d_intermediate=4*d_model. Eğer α=4 kabul edilirse (Krajewski ve ark., 2024’e göre), granülerlik sezgisel olarak şu şekilde yorumlanabilir: Yoğun MLP’nin genişliğini eşlemek için kaç tane uzmana ihtiyaç vardır.

Yani kabaca şu ilişkiyi düşünebiliriz:

4*dmodel=d_intermediate=G d_expert

Bu yorum yalnızca kaba bir sezgiseldir; modern MoE tasarımlarında toplam kapasite çoğu zaman tek bir yoğun MLP’den çok daha büyük olduğu için bu birebir eşleştirme pratikte tamamen geçerli olmaz. Ant Group ekibi ise α=2 değerini seçmiştir; bu sadece farklı bir normalizasyon tercihidir. Tutarlılık açısından biz de bu konvansiyonu kullanacağız.

Granularity değeri d_model ile ölçeklendiği için, model genişlikleri farklı olduğunda farklı modeller arasında karşılaştırma yapmak zorlaşabilir.

Yine de, aşağıda bazı güncel MoE sürümleri için farklı granularity değerlerini gösteren bir tablo bulunmaktadır:

Gelin, ayrıntı düzeyinin davranışı nasıl şekillendirdiğinden bahsedelim. Ant Group’un makalesinden:

(b) Değişen G değerleri üzerinden kayıp ve verimlilik kaldıraç ölçekleme eğrisi.

Granularity, EL’nin (Efficiency Leverage) ana sürücüsü gibi görünmez — özellikle 2’nin üzerindeki değerlerde fayda sağlar, ancak kaybı belirleyen baskın faktör değildir. Ayrıca burada da bir “sweet spot” vardır: granularity artırıldıkça belirli bir noktaya kadar kazançlar devam eder, ancak sonrasında iyileşmeler düzleşir (flatten). Bu nedenle granularity, son modellerde daha yüksek değerlere doğru net bir eğilim gösteren faydalı bir ayar düğmesidir; fakat tek başına optimize edilmesi gereken bir parametre değildir.

MoE’leri iyileştirmek için yaygın kullanılan bir diğer yaklaşım ise paylaşılan uzmanlar (shared experts) kavramıdır. Buna daha yakından bakalım.

Paylaşılan Uzmanlar (Shared Experts)

Paylaşılan uzmanlar yaklaşımında, her token her zaman aktif olan küçük bir uzman kümesine yönlendirilir. Bu paylaşılan uzmanlar, veride tekrar eden temel örüntüleri (basic, recurring patterns) öğrenir; böylece geri kalan uzmanlar daha agresif biçimde özelleşebilir (specialization).

Pratikte çok fazla paylaşılan uzmana ihtiyaç yoktur; model tasarımcıları genellikle bir, en fazla iki paylaşılan uzman seçer. Granularity arttıkça (örneğin Qwen3 tarzı bir yapıdan Qwen3-Next’e benzer yapılara geçildikçe), paylaşılan uzmanlar daha da faydalı hale gelme eğilimindedir.

Tian ve ark. (2025) grafiğine bakıldığında, genel etkisinin sınırlı olduğu görülür; yani EL üzerinde dramatik bir değişim yaratmaz. Basit bir sezgisel kural çoğu durumda yeterlidir: tek bir paylaşılan uzman kullanmak. Bu yaklaşım DeepSeek-V3, Kimi K2 ve Qwen3-Next gibi modellerle uyumludur ve gereksiz karmaşıklık eklemeden verimliliği maksimize etme eğilimindedir.

Yani, paylaşılan bir uzman (shared expert), bazı token’ların her zaman yönlendirildiği bir uzmandır. Peki diğer uzmanlar ne olacak? Her bir uzmana ne zaman yönlendirme yapacağımızı nasıl öğreniriz ve modelin yalnızca birkaç uzmanı kullanıp diğerlerini boşta bırakmadığından nasıl emin oluruz? Bir sonraki bölümde, tam olarak bu problemi ele alan yük dengeleme (load balancing) konusunu tartışacağız.

Yük Dengeleme

Yük dengeleme, Uzmanların Karışımı (Mixture of Experts, MoE) mimarisindeki kritik bileşendir. Eğer yanlış yapılandırılırsa, diğer tüm tasarım seçimlerini geçersiz kılabilir. Kötü yük dengesinin neden ciddi sorunlara yol açacağını görmek için, dört GPU’lu çok basit bir dağıtık eğitim kurulumunu düşünelim ve modelimizin dört uzmanını bu GPU’lara eşit şekilde dağıtalım. Eğer yönlendirme (routing) çöker ve tüm token’lar uzman 1’e gönderilirse, bu durumda GPU’larımızın yalnızca dörtte biri kullanılmış olur. Bu hem eğitim hem de çıkarım (inference) verimliliği açısından oldukça kötüdür. Ayrıca modelin etkin öğrenme kapasitesi de düşer, çünkü tüm uzmanlar aktif olarak kullanılmaz.

Bu sorunu çözmek için, yönlendiriciye (router) ek bir kayıp terimi (loss term) ekleyebiliriz. Burada standart yardımcı kayıp (auxiliary loss) tabanlı yük dengeleme yaklaşımını görebilirsiniz:

Bu basit formül yalnızca üç faktör kullanır: α katsayısı kaybın gücünü belirler, fᵢ trafik oranıdır (tokenların uzman i üzerinden geçen kısmı) ve Pᵢ olasılık kütlesidir; bu da basitçe uzman üzerinden geçen tokenların olasılıklarının toplamını ifade eder. İkisi de gereklidir: fᵢ gerçek dengeleme davranışına karşılık gelirken, Pᵢ yumuşak ve türevlenebilir olup gradyanın akmasına izin verir.

Mükemmel yük dengelemesi sağlarsak fᵢ = Pᵢ = 1 / Nᵣ elde ederiz. Ancak α’yı ayarlarken dikkatli olmalıyız: Eğer çok küçük olursa yönlendirmeyi yeterince teşvik edemeyiz; çok büyük olursa ise yönlendirme tekdüzeliği, temel dil modeli kaybından daha önemli hale gelir.

Kayıpsız yük dengeleme Açık bir kayıp terimi olmadan da dengeleme sağlamak mümkündür. DeepSeek-V3 (DeepSeek-AI ve diğerleri, 2025), yönlendirme softmax’ına giren benzerlik skorlarına eklenen basit bir bias terimi önermiştir. Bir yönlendirici (router) aşırı yüklendiğinde skor biraz düşürülür (γ kadar sabit bir faktörle), böylece seçilme olasılığı azalır; eğer uzman az kullanılıyorsa skor γ kadar artırılır. Bu basit uyarlanabilir kural yük dengelemesini sağlar.

Önemli bir detay, yönlendirme istatistiklerinin hangi ölçekte hesaplandığıdır: fᵢ ve Pᵢ yerel batch bazında mı (her işleyicinin mini-batch’i) yoksa global olarak mı (tüm worker’lar/cihazlar arasında toplanarak) hesaplanır? Qwen ekibinin analizi (Qiu ve diğerleri, 2025), her yerel batch’te yeterli token çeşitliliği olmadığında yerel hesaplamanın hem uzman özelleşmesini (routing sağlığı için iyi bir gösterge) hem de genel model performansını olumsuz etkileyebileceğini gösteriyor. Uzman özelleşmesi, belirli bir alan için bir veya daha fazla uzmanın diğerlerine göre daha sık etkinleştirilmesi olgusudur. Başka bir deyişle, yerel batch dar bir dağılıma sahipse routing istatistikleri gürültülü/yanlı hale gelir ve iyi bir dengeleme sağlamaz. Bu da mümkün olduğunca global istatistiklerin (veya en azından cihazlar arası toplulaştırmanın) kullanılması gerektiğini ima eder. Dikkat çekici şekilde, o makalenin yayımlandığı dönemde Megatron dahil birçok framework varsayılan olarak bu istatistikleri yerel hesaplıyordu.

Aşağıdaki grafik, Qwen makalesinden mikro-batch ve global batch toplulaştırmasının farkını ve bunun performans ile özelleşme üzerindeki etkisini göstermektedir:

Genel olarak, MoE etrafındaki mimari tercihleri kaldırarak (ablation) analiz etmek zordur çünkü birçok bileşen arasında karşılıklı bir etkileşim vardır. Örneğin, paylaşılan bir uzmanın ne kadar faydalı olduğu modelin ayrıntı düzeyine (granularity) bağlı olabilir. Gerçekten aradığınız içgörüleri elde etmek için iyi tasarlanmış bir deney seti oluşturmak adına zaman ayırmak önemlidir!

MoE’lerin temellerini ele aldık, ancak keşfedilecek daha çok şey var. İşte kapsamlı olmayan bir şekilde inceleyebileceğiniz bazı başlıklar:

• Sıfır-hesaplama (zero-computation) uzmanları, MoE katmanı yeniden ölçekleme ve eğitim izleme (LongCat-Flash makalesi)
• Ortogonal kayıp ile yük dengeleme (ERINE 4.5’te olduğu gibi)
• Eğitim boyunca yük dengeleme katsayısının zamanlamasını ayarlama
• MoE ile mimari/optimizasyon etkileşimleri, örneğin:
• Optimizatör sıralamalarının MoE için değişip değişmediği
• μP’nin MoE’ye nasıl uygulanacağı
• MoE için öğrenme oranının nasıl uyarlanacağı (çünkü uzmanlar her batch’te aynı sayıda token görmez)
• Başta kaç adet yoğun (dense) katman kullanılacağı

Meraklı okuyucuya, bu tavşan deliğinin daha derinlerine inmeyi bırakıyoruz; şimdi ise son büyük mimari seçeneğe geçiyoruz: hibrit modeller!

Ara bölüm: Hibrit Modeller

Yakın dönemdeki bir eğilim, standart yoğun (dense) veya MoE mimarisini durum uzayı modelleri (SSM’ler) veya lineer dikkat mekanizmaları ile genişletmektir (MiniMax ve diğerleri, 2025; Zuo ve diğerleri, 2025). Bu yeni model sınıfları, çok uzun bağlamları verimli şekilde işleme konusundaki transformerların temel zayıflıklarını çözmeyi hedefler. Bunlar, iki yaklaşım arasında bir orta yol sunar:

• RNN’ler, keyfi uzunluktaki bağlamları lineer ölçekle işleyebilir ancak bağlamsal bilgiyi tam kullanmakta zorlanabilir
• Transformer’lar ise uzun bağlamlarda çok pahalı hale gelir ancak bağlam içindeki örüntüleri çok iyi kullanabilir

SSM’lerin güçlü ve zayıf yönlerini anlamaya yönelik çalışmalar da yapılmıştır. Örneğin, Waleffe ve diğerleri (2024), Mamba modellerini (SSM türü) incelemiş ve birçok benchmarkta iyi performans gösterdiklerini ancak MMLU ve bazı diğer görevlerde zayıf kaldıklarını bulmuştur. Bunun, in-context learning (bağlam içi öğrenme) eksikliğinden kaynaklandığını öne sürerler. SSM’leri dense veya MoE bloklarıyla birleştirmek iki dünyanın en iyi yönlerini sağlar; bu yüzden “hibrit modeller” adı verilir.

Bu lineer dikkat mekanizmalarının temel fikri, hesaplamaları yeniden düzenleyerek attention maliyetini artık O(n² d) olmaktan çıkarmaktır; bu maliyet uzun bağlamlarda hesaplanamaz hale gelir. Bu nasıl çalışır? Öncelikle, çıkarım (inference) sırasında attention formülünü hatırlayalım. t tokenı için çıktının üretilmesi formülünü alalım. Softmax’ı kaldıralım. Yeniden sıralayalım. Çalışma durumunu kontrol edip basit bir güncellemeyle şöyle yazabiliriz:

Yeniden sıralama neden önemlidir? Soldaki ifade ∑(j≤t) (q_t^⊤ k_j) v_j şu anlama gelir: “Geçmişteki her j tokenı için q_t^⊤ k_j iç çarpımını (bir skaler) hesapla, bunu v_j’yi ölçeklemek için kullan ve ardından bu t adet vektörü topla.” Bu işlem, t adımında yaklaşık O(td) hesaplama maliyeti gerektirir. Sağdaki ifade ise bunu şu şekilde yeniden yazar: (∑(j≤t) v_j k_j^⊤) q_t . Burada, geçmişteki tüm (k_j, v_j) çiftlerini özetleyen tek bir durum matrisi tutulur: S_t = ∑(j≤t) v_j k_j^⊤ ∈ R^(d×d). Her yeni token geldiğinde bu matris, bir dış çarpım (outer product) v_t k_t^⊤ ile güncellenir ve bunun maliyeti O(d²)’dir. Ardından çıktı yalnızca tek bir matris-vektör çarpımıdır: S_t q_t. Bu da O(d²) maliyetlidir.

Dolayısıyla, soldaki yöntemle sıfırdan T token üretmenin maliyeti O(T²d) iken, S_t durumunu koruyup sağdaki formu kullanmanın maliyeti O(Td²) olur.

Sezgisel olarak:

• Sol taraf = “Her adımda çok sayıda küçük iç çarpım, ölçekleme ve toplama işlemi”.
• Sağ taraf = “Önceden özetlenmiş tek bir matrisin sorgu (query) ile çarpılması”.

Yani dizi uzunluğuna (sequence length) olan bağımlılık, boyuta (dimension) olan bağımlılıkla takas edilir.

Burada çıkarım (inference) ve yinelemeli (recurrent) form üzerine odaklanıyoruz, ancak bu yaklaşım eğitim sırasında da daha verimlidir. Eğitimde yapılan yeniden sıralama aşağıdaki denklem kadar basittir:

(QK^⊤)(n×n) V = Q (K^⊤V)(d×d)

Bu artık bir RNN-benzeri yapıya oldukça benzemektedir.

Sorunumuzu neredeyse çözdük. Pratikte softmax, önemli bir kararlılık (stabilizasyon) rolü oynar ve saf (naive) lineer attention, herhangi bir normalizasyon olmadan kararsız davranabilir. Bu sorunu çözmek için çeşitli pratik varyantlar önerilmiştir.

Lightning Attention

NormAttention fikri (Qin ve diğerleri, 2022) üzerine inşa edilen Lightning Attention, softmax normalizasyonunu dikkat (attention) büyüklüğünü kontrol eden ve kararlılığı artıran norm tabanlı bir ölçekleme ile değiştirme yaklaşımını temel alır. Lightning Attention’ın odak noktası ise uygulamayı hızlı ve verimli hale getirmek olup, bunu yaparken birkaç önemli mimari değişiklik de içerir. Her iki yöntemin formülleri aşağıdaki gibidir:

NormAttention: RMSNorm(Q(KᵀV))

Lightning Attention:

Adım 1: QKV projeksiyonu + SiLU

Q = SiLU(Q) K = SiLU(K) V = SiLU(V) G = σ(G)

Adım 2: Sönümleme (decay) faktörü ve önceki gösterimdeki S_t = KV_t durumu

KVt = λKV(t−1) + k_tᵀv_t

o_t = q_t KV_t

Adım 3: RMSNorm + geçit (gate)

Y = G ⊙ RMSNorm(O)

Deneysel sonuçlar, MiniMax ve diğerlerinin (2025) çalışmasına göre Lightning Attention kullanan hibrit modellerin çoğu görevde softmax attention ile eşdeğer performans gösterdiğini ortaya koymaktadır.

Buradaki ilginç nokta, NIAH gibi bilgi geri getirme (retrieval) görevlerinde tam softmax attention’dan çok daha iyi performans gösterebilmesidir. Bu durum, softmax katmanı ile lineer katman arasında bir tür sinerji olabileceğine işaret ediyor olabilir.

MiniMax M2

İlginç bir şekilde, yakın zamanda yayımlanan MiniMax-M2 hibrit veya lineer attention kullanmamaktadır. Ekibin ön eğitim (pretraining) liderine göre, Lightning Attention ile yapılan ilk MiniMax-M1 deneyleri küçük ölçeklerde ve o dönemde popüler olan benchmarklarda (MMLU, BBH, MATH) umut verici sonuçlar vermiş olsa da, daha büyük ölçeklerde “karmaşık ve çok adımlı muhakeme (multi-hop reasoning) görevlerinde belirgin eksiklikler” gözlemlediler.

Ekip ayrıca, pekiştirmeli öğrenme (RL) eğitimi sırasında yaşanan sayısal hassasiyet (numerical precision) problemlerini ve altyapı olgunluğunun yetersizliğini önemli engeller olarak gösteriyor. Sonuç olarak, büyük ölçekte yeni bir mimari tasarlamanın veri dağılımı, optimizatör seçimi ve benzeri birçok parametreye duyarlı olan çok değişkenli bir problem olduğunu; bu nedenle hem zor hem de yüksek hesaplama maliyetli olduğunu belirtiyorlar.

Bununla birlikte, “GPU hesaplama gücündeki büyüme yavaşlarken veri uzunluğu artmaya devam ettikçe, lineer ve seyrek (sparse) attention yöntemlerinin avantajları giderek daha belirgin hale gelecektir” görüşünü de dile getiriyorlar.

Bu durum, hem mimari ablasyon çalışmalarının ne kadar karmaşık olduğunu hem de araştırma dünyası ile üretim ortamındaki gerçeklik arasındaki farkı açıkça göstermektedir.

Şimdi diğer attention yöntemlerine göz atalım ve bunların birleşik (unified) bir çerçeve içinde nasıl anlaşılabileceğini inceleyelim.

Gelişmiş Lineer Attention

Yinelemeli (recurrent) modellerden alınabilecek faydalı bir ders, durumun (state) zaman zaman geçmiş bilgileri bırakabilmesine izin vermektir. Pratikte bu, önceki durum için bir geçit (gate) G_t tanımlamak anlamına gelir:

S_t = Gt ⊙ S(t−1) + v_t k_t^⊤

Son dönemde geliştirilen lineer attention mekanizmalarının neredeyse tamamı bu geçit bileşenini içerir. Aralarındaki temel fark, G_t’nin nasıl tanımlandığı ve uygulandığıdır.

Yang ve diğerlerinin (2024) çalışmasında, farklı geçit (gate) varyantları ve bunlara karşılık gelen mimariler listelenmektedir.

$G_t$’nin parametreleştirilmesinde farklılık gösteren, yakın tarihli modellerin kapılı doğrusal dikkat formülasyonları. Önyargı terimleri ihmal edilmiştir.

Önemli varyantlardan biri Mamba-2’dir (Dao & Gu, 2024); Nemotron-H (NVIDIA, Blakeman ve diğerleri, 2025), Falcon H1 (Zuo ve diğerleri, 2025) ve Granite-4.0-h (IBM Research, 2025) gibi çeşitli hibrit modellerde kullanılmaktadır. Ancak bu alan hâlâ gelişimin erken aşamalarındadır ve büyük ölçekli hibrit modellere geçerken dikkate alınması gereken önemli nüanslar bulunmaktadır.

Bu dikkat (attention) mekanizmaları umut verici görünse de, MiniMax’ın M2 ile elde ettiği deneyim, küçük ölçekte görülen avantajların her zaman büyük ölçekli üretim sistemlerine taşınamadığını göstermektedir. Bununla birlikte, hibrit modeller hızla gelişmeye devam ediyor ve ileri seviye (frontier) model eğitimi için güçlü bir seçenek olmayı sürdürüyor. Gated DeltaNet güncellemesini içeren Qwen3-Next (Qwen Team, 2025), uzun bağlamlarda çıkarım (inference) sırasında daha hızlı olduğunu, daha hızlı eğitildiğini ve standart kıyaslama testlerinde daha iyi performans gösterdiğini bildiriyor. Ayrıca büyük olasılıkla yeni Kimi Delta Attention mekanizmasını kullanacak olan Kimi’nin bir sonraki modelini de merakla bekliyoruz. Bunun yanında, uzun bağlam ölçeklenebilirliği sorununu yalnızca seçilmiş bloklar veya sorgular için dikkat hesaplayarak çözen Sparse Attention’dan da bahsetmek gerekir. Buna örnek olarak Native Sparse Attention (Yuan ve diğerleri, 2025), DeepSeek Sparse Attention (DeepSeek-AI, 2025) ve InfLLM v2 (M. Team ve diğerleri, 2025) gösterilebilir.

Artık mevcut mimari seçeneklerin neler olduğunu bildiğinize göre, bunlar arasından nasıl seçim yaparsınız? Tokenizer’lara geçmeden önce bu soruyu yanıtlayalım.

MoE mi, değil mi: Temel Mimari Seçimi

Bir yoğun (dense), MoE (Mixture of Experts) ya da hibrit model kullanıp kullanmama kararı genellikle birkaç temel faktöre bağlıdır: modeli nerede dağıtacağınız, ekibinizin uzmanlık düzeyi ve zaman çizelgeniz. Her seçeneğin avantaj ve dezavantajlarına kısaca bakalım ve bu seçimi yapmak için basit bir karar ağacı oluşturalım.

Yoğun transformer’lar, her parametrenin her token için aktif olduğu standart decoder-only transformer mimarisidir. Matematiksel detaylar için Harvard NLP blog yazısı “The Annotated Transformer”a ve sezgiyi geliştirmek için Jay Alammar’ın “The Illustrated Transformer” çalışmasına bakabilirsiniz.

Artıları: Yaygın desteklenir, iyi anlaşılmıştır, eğitim süreci stabildir, parametre başına iyi performans sunar.

Eksileri: Hesaplama maliyeti model boyutuyla doğrusal ölçeklenir; 70B’lik bir model, 3B’lik modele göre yaklaşık 23 kat daha pahalıdır.

Bu yaklaşım genellikle bellek kısıtlı kullanım senaryoları veya yeni LLM eğiticileri için varsayılan tercihtir.

Mixture of Experts (MoE) modelleri, transformer içindeki feedforward katmanlarını birden fazla “uzman” ile değiştirir. Bir yönlendirme (gating) ağı, her token’ı yalnızca birkaç uzmana yönlendirir. Sonuç olarak, çok daha düşük hesaplama maliyetiyle büyük bir ağ kapasitesi elde edilir. Örneğin Kimi K2, toplamda 1 trilyon parametreye sahipken token başına yalnızca 32B aktif parametre kullanır. Ancak tüm uzmanların bellekte yüklenmesi gerekir. Görsel bir rehber için Maarten Grootendorst’un blog yazısına bakabilirsiniz.

Artıları: Eğitim ve çıkarım (inference) açısından hesaplama başına daha iyi performans.

Eksileri: Yüksek bellek gereksinimi (tüm uzmanların yüklenmesi gerekir) ve yoğun modellere kıyasla daha karmaşık eğitim süreci. Framework desteği gelişiyor olsa da hâlâ daha olgun değil; dağıtık eğitimde uzman yerleştirme, yük dengeleme ve all-to-all iletişim gibi zorluklar bulunur.

Bellek kısıtlaması olmayan ve hesaplama başına maksimum performans isteyen durumlarda tercih edilir.

Hibrit modeller, transformer’ları Mamba gibi durum uzayı modelleri (state space models) ile birleştirir ve dikkat mekanizmalarının karesel ölçeklenmesine kıyasla bazı işlemlerde lineer karmaşıklık sunar. Bu konuda Sasha Rush’un blog yazısı ve Maarten Grootendorst’un Mamba ve SSM’lere dair görsel rehberi faydalı kaynaklardır.

Artıları: Potansiyel olarak daha iyi uzun bağlam (long context) işleme. Çok uzun diziler için daha verimli.

Eksileri: Yoğun ve MoE mimarilere göre daha az olgun, kanıtlanmış eğitim reçeteleri daha az. Framework desteği sınırlı.

Çok büyük bağlamlara ölçeklenmek ve standart transformer’ların çıkarım yükünü azaltmak istendiğinde kullanılır.

Ayrıca bazı ekipler metin için difüzyon modellerini de araştırmaya başlamıştır, ancak bu modeller (ve diğer deneysel alternatifler) şu an için oldukça erken aşamada olduğundan bu dokümanın kapsamı dışındadır.

Karar verirken önce modelin nerede dağıtılacağını belirleyin. Ardından ekibinizin uzmanlığını ve eğitim zaman çizelgesini değerlendirerek ne kadar keşif yapabileceğinize karar verin.

SmolLM3 için, cihaz üzerinde çalıştırmaya uygun güçlü ve küçük bir model geliştirmek istedik; yaklaşık üç aylık bir zaman çizelgemiz vardı ve geçmişte çoğunlukla yoğun (dense) modeller eğitmiştik. Bu durum, MoE (bellek kısıtlamaları) ve hibrit (keşif için kısa süre, 128 bin token’lık hedef bağlam uzunluğunu destekleyebilen yoğun modeller) mimarilerini elenmesine yol açtı; bu nedenle Llama tarzı yoğun bir model tercih ettik.

Model mimarisi konusunu geride bıraktığımıza göre, şimdi veri ile modelimiz arasında köprü görevi gören tokenizer’a odaklanalım.

Tokenizer

Tokenization şeması muhtemelen herhangi bir dil modelinin en az değer verilen bileşenlerinden biridir. Bunu, insan dili ile modelin içinde yaşadığı matematiksel dünya arasında bir çevirmen olarak düşünebilirsiniz. Mimari yenilikler genellikle ilgi odağını alsa da, tıpkı herhangi bir çevirmen gibi, çevirinin kalitesi çok önemlidir. Peki ihtiyaçlarımız için doğru tokenizer’ı nasıl inşa eder veya seçeriz?

Tokenizer Temelleri

Temelinde, bir tokenizer ham metni modelimizin işleyebileceği sayı dizilerine dönüştürür; bunu da akış halindeki metni token adı verilen ayrı işlenebilir birimlere bölerek yapar. Teknik detaylara girmeden önce, tokenizer tasarımımızı yönlendirecek bazı temel soruları yanıtlamalıyız:

• Hangi dilleri desteklemek istiyoruz? Çok dilli bir model geliştiriyorsak ancak tokenizer’ımız yalnızca İngilizce görmüşse, model İngilizce olmayan metinlerle karşılaştığında verimsiz olur; bu metinler gereksiz yere çok daha fazla token’a bölünür. Bu durum doğrudan performansı, eğitim maliyetini ve çıkarım hızını etkiler.
• Bizim için hangi alanlar önemlidir? Dillerin ötesinde, matematik ve kod gibi alanlar rakamların dikkatli bir şekilde temsil edilmesini gerektirir.
• Hedef veri karışımımız nedir? Eğer tokenizer’ımızı sıfırdan eğitmeyi planlıyorsak, ideal olarak onu nihai eğitim karışımımızı yansıtan bir örnek üzerinde eğitmeliyiz.

Bu soruları yanıtladıktan sonra, temel tasarım kararlarını inceleyebiliriz.

LLM Evaluation Guidebook’ımızın “Tokenization” bölümü, tokenizer’lara bir giriş sunar ve çeşitli faydalı kaynaklara bağlantılar içerir. Tokenization temellerine derinlemesine bir bakış için Andrej Karpathy’nin “Let’s Build the GPT Tokenizer” adlı çalışması uygulamalı mükemmel bir öğreticidir.

Kelime Dağarcığı Boyutu

Kelime dağarcığı (vocabulary), modelimizin tanıdığı tüm token’ları (kelimeler, alt-kelimeler veya semboller gibi en küçük metin birimleri) listeleyen temel bir sözlüktür.

Daha büyük kelime dağarcıkları genellikle metni daha verimli sıkıştırır; çünkü bir cümle başına daha az token üretiriz. Ancak bunun bir hesaplama maliyeti vardır: kelime dağarcığı boyutu doğrudan gömme (embedding) matrislerinin boyutunu etkiler. Eğer kelime dağarcığı büyüklüğü V ve gizli boyut h ise, giriş embedding’leri V × h parametre içerir ve çıkış katmanı da ayrıca V × h parametre içerir. Küçük modellerde bu, toplam parametrelerin önemli bir kısmını oluşturabilir (“Embedding Sharing” bölümünde gördüğümüz gibi), ancak modeller ölçeklendikçe bu oransal maliyet azalır.

En uygun nokta (sweet spot), hedef kapsama alanımıza ve model boyutuna bağlıdır. Sadece İngilizce modeller için yaklaşık 50k token genellikle yeterlidir; ancak çok dilli modeller, farklı yazı sistemlerini ve dilleri verimli şekilde işlemek için çoğunlukla 100k+ token’a ihtiyaç duyar. Llama 3 gibi güncel ve ileri seviye modeller, farklı dillerde token verimliliğini artırmak için 128k+ seviyesinde kelime dağarcığı benimsemiştir. Aynı ailedeki daha küçük modeller ise embedding paylaşımı (embedding sharing) kullanarak embedding parametrelerinin toplam içindeki oranını düşürürken daha büyük kelime dağarcığının avantajlarından yararlanır.

Dagan ve ark. (2024), kelime dağarcığı boyutunun sıkıştırma, çıkarım (inference) ve bellek üzerindeki etkisini analiz eder. Daha büyük kelime dağarcıklarından elde edilen sıkıştırma kazancının üstel olarak azaldığını gözlemlerler; bu da aslında optimal bir boyutun var olduğunu düşündürür. Çıkarım açısından, daha büyük kelime dağarcıkları daha avantajlı olabilir çünkü sıkıştırma sayesinde forward pass sırasında kazanılan maliyet, softmax’ta ek embedding token maliyetinden daha fazladır. Bellek açısından ise optimal boyut, dizi uzunluğu ve batch size’a bağlıdır: Uzun bağlamlar ve büyük batch’ler, daha az token üretildiği için KV cache tasarrufu nedeniyle daha büyük kelime dağarcıklarından fayda sağlar.

Verimi optimize etmek için kelime dağarcığı boyutunu 128’in katı olarak seçin (örneğin 50.000 yerine 50.304). Modern GPU’lar, boyutlar 2’nin daha yüksek kuvvetlerine bölünebildiğinde matris işlemlerini daha iyi gerçekleştirir; çünkü bu, bellek hizalamasını iyileştirir ve hizasız bellek erişimlerinden doğan ek yükü azaltır. Horace He bu konu hakkında faydalı bir blog yazısı kaleme almıştır.

Tokenizasyon Algoritması

Artık bir tokenizer’ı tanımlayan temel parametreleri gördüğümüze göre, pratik bir karar vermemiz gerekiyor: Mevcut bir tokenizer mı kullanmalıyız yoksa sıfırdan mı eğitmeliyiz? Cevap, kapsama (coverage) bağlıdır; yani mevcut tokenizer’ların hedef kelime dağarcığı boyutumuzla dillerimizi ve alanlarımızı ne kadar iyi kapsadığına.

Mevcut tokenizer’lar arasında byte-pair encoding (BPE) (Sennrich ve ark., 2016) hâlâ en yaygın tercihtir. WordPiece ve SentencePiece gibi başka algoritmalar da vardır, ancak daha az yaygın kullanılırlar. (Ayrıca doğrudan byte’lar veya karakterler üzerinde çalışan ve tokenization ihtiyacını tamamen ortadan kaldırma potansiyeli taşıyan tokenizer’sız yaklaşımlara yönelik artan bir araştırma ilgisi de vardır.)

Kapsama konusuna gelirsek, aşağıdaki şekli düşünün: GPT-2’nin yalnızca İngilizce için eğitilmiş BPE tokenizer’ı (Radford ve ark., 2019) ile Gemma 3’ün çok dilli SentencePiece tokenizer’ının (G. Team ve ark., 2025) aynı İngilizce ve Arapça cümleleri nasıl farklı şekilde segmentlere ayırdığını karşılaştırmaktadır.

Her iki tokenizer İngilizce üzerinde benzer performans gösteriyor gibi görünse de, Arapça için fark çarpıcı hale geliyor: GPT-2 metni yüzün üzerinde parçaya bölerken, Gemma 3 çok daha az token üretir; bunun nedeni çok dilli eğitim verisi ve daha büyük, daha kapsayıcı sözlüğüdür.

Ancak bir tokenizer’ın kalitesini değerlendirmek için yalnızca birkaç tokenizasyon örneğine bakıp “iyi” demek yeterli değildir; tıpkı mimari değişiklikleri sezgisel olarak yapıp ablasyon testleri çalıştırmadan karar veremeyeceğimiz gibi. Somut metriklere ihtiyaç duyarız.

Tokenizer Kalitesini Ölçmek

Bir tokenizer’ın ne kadar iyi performans gösterdiğini değerlendirmek için, FineWeb2’de (Penedo ve ark., 2025) kullanılan iki temel metriği kullanabiliriz:

Fertilite (Fertility), bir kelimeyi kodlamak için gereken ortalama token sayısını ölçer (kelime–token oranı). Daha düşük fertilite daha iyi sıkıştırma anlamına gelir ve bu da daha hızlı eğitim ve çıkarım (inference) sağlar.

Süregelen kelime oranı (Proportion of continued words), kelimelerin yüzde kaçının birden fazla parçaya bölündüğünü gösterir. Daha düşük değerler daha iyidir; çünkü daha az kelime parçalanır ve bu da daha verimli bir tokenizasyona işaret eder.

Fertilite metriği “kelime” kavramı etrafında tanımlanır çünkü uygun kelime tokenizasyon araçları (örneğin spaCy veya Stanza) mevcut olduğunda diller arası anlamlı karşılaştırmalar yapılmasını sağlar (Penedo ve ark., 2025). Tek bir dil için tokenizer karşılaştırması yaparken, kelimeler yerine karakter veya byte sayısını kullanarak karakter–token oranı veya byte–token oranı elde edebilirsiniz (Dagan ve ark., 2024). Ancak bu metriklerin diller arası karşılaştırmada bazı sınırlamaları vardır. Byte’lar, farklı yazı sistemlerindeki karakterlerin UTF-8’de farklı sayıda byte gerektirmesi nedeniyle yanıltıcı olabilir (örneğin Çince karakterler UTF-8’de 3 byte kullanırken Latin karakterler 1 veya 2 byte kullanır). Benzer şekilde karakter sayısı da diller arasındaki kelime uzunluğu farklarını hesaba katmaz. Örneğin Çince kelimeler genellikle Almanca bileşik kelimelere kıyasla çok daha kısadır.

Bu metrikleri şu şekilde uygulayabiliriz:

import numpy as np

def compute_tokenizer_metrics(tokenizer, word_tokenizer, text):
    """
    Computes fertility and proportion of continued words.

    Returns:
        tuple: (fertility, proportion_continued_words)
            - fertility: average tokens per word (lower is better)
            - proportion_continued_words: percentage of words split into 2+ tokens (lower is better)

    """
    words = word_tokenizer.word_tokenize(text)
    tokens = tokenizer.batch_encode_plus(words, add_special_tokens=False)
    tokens_per_word = np.array(list(map(len, tokens["input_ids"])))

    fertility = np.mean(tokens_per_word).item()
    proportion_continued_words = (tokens_per_word >= 2).sum() / len(tokens_per_word)

    return fertility, proportion_continued_words

Kod ve matematik gibi özel alanlar söz konusu olduğunda ise, fertiliteye ek olarak tokenizer’ın alan-özgü desenleri ne kadar iyi ele aldığına daha derinlemesine bakmamız gerekir. Modern tokenizer’ların çoğu sayıları basamak bazında böler; örneğin “123” şu şekilde parçalanır: [“1”, “2”, “3”] (Chowdhery ve ark., 2022; DeepSeek-AI ve ark., 2024). Sayıların bu şekilde bölünmesi ilk bakışta sezgisel olmayabilir, ancak aslında modellerin aritmetik örüntüleri daha etkili şekilde öğrenmesine yardımcı olur. Eğer “342792” tek ve bölünmez bir token olarak kodlanırsa, model bu tokenın diğer tüm sayı tokenlarıyla toplama, çıkarma veya çarpma işlemlerinde ne anlama geldiğini ezberlemek zorunda kalır. Oysa sayı parçalandığında model, basamak seviyesinde işlemlerin nasıl çalıştığını öğrenebilir. Bazı tokenizer’lar, örneğin Llama 3’ün tokenizer’ı (Grattafiori ve ark., 2024), 1 ile 999 arasındaki sayıları tekil tokenlar olarak kodlar ve geri kalan sayılar bu tokenların kombinasyonlarıyla oluşturulur.

Daha derin bir inceleme için, “From Digits to Decisions: How Tokenization Impacts Arithmetic in LLMs” adlı çalışma, farklı tokenization şemalarını matematik görevleri üzerinde karşılaştırır.

Tokenizer’ları Değerlendirme

Farklı diller arasında tokenizer’ları karşılaştırmak için, FineWeb2’nin tokenizer analizinde (Penedo ve ark., 2025) kullanılan kurulumu kullanacağız; değerlendirme korpusu olarak Wikipedia makaleleri alınır. Her dil için, hesaplamayı yönetilebilir tutarken anlamlı bir örneklem elde etmek amacıyla 100 makale örnekleyeceğiz.

Önce bağımlılıkları kurup hangi tokenizer’ları ve dilleri karşılaştırmak istediğimizi tanımlayalım:

pip install transformers datasets sentencepiece 'datatrove[multilingual]'
## we need datatrove to load word tokenizers

tokenizers = [
    ("Llama3", "meta-llama/Llama-3.2-1B"),
    ("Gemma3", "google/gemma-3-1b-pt"),
    ("Mistral (S)", "mistralai/Mistral-Small-24B-Instruct-2501"),
    ("Qwen3", "Qwen/Qwen3-4B")
]

languages = [
    ("English", "eng_Latn", "en"),
    ("Chinese", "cmn_Hani", "zh"),
    ("French", "fra_Latn", "fr"),
    ("Arabic", "arb_Arab", "ar"),
]

Şimdi Wikipedia örneklerimizi yükleyelim. Tüm veri kümelerini indirmekten kaçınmak için akış yöntemini kullanıyoruz:

from datasets import load_dataset

wikis = {}
for lang_name, lang_code, short_lang_code in languages:
 wiki_ds = load_dataset("wikimedia/wikipedia", f"20231101.{short_lang_code}", streaming=True, split="train")
 wiki_ds = wiki_ds.shuffle(seed=42, buffer_size=10_000)
 # Sample 100 articles per language
  ds_iter = iter(wiki_ds)
  wikis[lang_code] = "\n".join([next(ds_iter)["text"] for _ in range(100)])

Verilerimiz hazır olduğuna göre, artık her bir belirteçleyiciyi her bir dil üzerinde değerlendirebiliriz. Her kombinasyon için, DataTrove’dan uygun kelime belirteçleyicisini yüklüyor ve her iki ölçütü de hesaplıyoruz:

from transformers import AutoTokenizer
from datatrove.utils.word_tokenizers import load_word_tokenizer
import pandas as pd

results = []

for tokenizer_name, tokenizer_path in tokenizers:
    tokenizer = AutoTokenizer.from_pretrained(tokenizer_path, trust_remote_code=True)

    for lang_name, lang_code, short_lang_code in languages:
        word_tokenizer = load_word_tokenizer(lang_code)

        # Compute metrics on Wikipedia
        fertility, pcw = compute_tokenizer_metrics(tokenizer, word_tokenizer, wikis[lang_code])

        results.append({
            "tokenizer": tokenizer_name,
            "language": lang_name,
            "fertility": fertility,
            "pcw": pcw
        })

df = pd.DataFrame(results)
print(df)

tokenizer    language  fertility       pcw
0        Llama3     English   1.481715  0.322058
1        Llama3     Chinese   1.601615  0.425918
2        Llama3      French   1.728040  0.482036
3        Llama3     Spanish   1.721480  0.463431
4        Llama3  Portuguese   1.865398  0.491938
5        Llama3     Italian   1.811955  0.541326
6        Llama3      Arabic   2.349994  0.718284
7        Gemma3     English   1.412533  0.260423
8        Gemma3     Chinese   1.470705  0.330617
9        Gemma3      French   1.562824  0.399101
10       Gemma3     Spanish   1.586070  0.407092
11       Gemma3  Portuguese   1.905458  0.460791
12       Gemma3     Italian   1.696459  0.484186
13       Gemma3      Arabic   2.253702  0.700607
14  Mistral (S)     English   1.590875  0.367867
15  Mistral (S)     Chinese   1.782379  0.471219
16  Mistral (S)      French   1.686307  0.465154
17  Mistral (S)     Spanish   1.702656  0.456864
18  Mistral (S)  Portuguese   2.013821  0.496445
19  Mistral (S)     Italian   1.816314  0.534061
20  Mistral (S)      Arabic   2.148934  0.659853
21        Qwen3     English   1.543511  0.328073
22        Qwen3     Chinese   1.454369  0.307489
23        Qwen3      French   1.749418  0.477866
24        Qwen3     Spanish   1.757938  0.468954
25        Qwen3  Portuguese   2.064296  0.500651
26        Qwen3     Italian   1.883456  0.549402
27        Qwen3      Arabic   2.255253  0.660318

Sonuçlar, önceliklerinize bağlı olarak bazı kazananları ve dezavantajları ortaya koyuyor.

Gemma 3’ün tokenizer’ı, birden fazla dilde — özellikle İngilizce, Fransızca ve İspanyolca — düşük “fertility” (verimlilik/kelime başına token oranı) ve düşük kelime bölme (word-splitting) oranları elde eder. Bu durum, çok dilli eğitim verisi ve oldukça büyük sözlük boyutu (262 bin token, Llama 3’ün 128 bin token’ından yaklaşık 2 kat büyük) ile açıklanabilir. Qwen3’ün tokenizer’ı Çince’de üstün performans gösterirken, İngilizce, Fransızca ve İspanyolca’da Llama 3’ün gerisinde kalır. Mistral Small’un tokenizer’ı (Mistral AI, 2025) Arapça’da en iyi performansı gösterirken, İngilizce ve Çince’de diğerlerine kıyasla daha zayıf kalır.

Mevcut ve özel tokenizer’lar arasında seçim

Günümüzde güçlü tokenizer seçenekleri oldukça fazladır. Birçok yeni model, GPT-4’ün tokenizer’ı (OpenAI ve diğerleri, 2024) gibi bir yapıdan başlayıp bunu ek çok dilli token’larla genişletir. Llama 3’ün tokenizer’ı çok dilli metin ve kod üzerinde ortalama olarak iyi performans gösterirken, Qwen2.5 özellikle Çince ve bazı düşük kaynaklı dillerde öne çıkar. Peki mevcut seçenekleri mi kullanmalısınız yoksa kendi tokenizer’ınızı mı eğitmelisiniz? Aşağıda karar vermenize yardımcı olacak bazı yönergeler yer alıyor:

Mevcut tokenizer’ların ne zaman kullanılması gerekir: Eğer hedef kullanım alanınız yukarıda karşılaştırılan tokenizer’ların kapsadığı dil veya alanlarla uyumluysa, bunlar iyi test edilmiş ve güvenilir seçeneklerdir. SmolLM3 eğitimi için biz Llama 3’ün tokenizer’ını seçtik: Hedef dillerimiz (İngilizce, Fransızca, İspanyolca, Portekizce, Almanca ve İtalyanca) üzerinde rekabetçi tokenizasyon kalitesi sunuyor ve model boyutumuz küçük olduğu için makul bir sözlük boyutu sağlıyor. Daha büyük modellerde ise embedding’ler toplam parametrelerin daha küçük bir kısmını oluşturduğundan, Gemma3’ün verimlilik kazançları daha cazip hale gelir.

Kendi tokenizer’ınızı ne zaman eğitmelisiniz: Eğer düşük kaynaklı diller için çalışıyorsanız ya da benzersiz bir veri karışımına sahipseniz, iyi bir kapsama sağlamak için kendi tokenizer’ınızı eğitmeniz gerekebilir. Bu durumda tokenizer’ı, nihai eğitim karışımının nasıl olacağını düşündüğünüz veri kümesine yakın bir veri üzerinde eğitmek önemlidir. Bu durum biraz “tavuk-yumurta” problemine yol açar; çünkü doğru veri karışımını bulmak için tokenizer’a ihtiyaç duyarsınız, ancak nihai çalışmayı başlatmadan önce tokenizer’ı yeniden eğitip downstream performansı ve fertility değerlerinin iyi olup olmadığını doğrulayabilirsiniz.

Tokenizer seçiminiz teknik bir detay gibi görünebilir, ancak modelinizin performansının her yönüne etki eder. Doğru yapmak için zaman harcamaktan çekinmeyin.

SmolLM3

Mimari ortamı incelediğimize ve bazı ablasyon çalışmaları yürüttüğümüze göre, şimdi bunların SmolLM3 gibi bir modelde pratikte nasıl bir araya geldiğine bakalım.

SmolLM ailesinin amacı, küçük modellerle mümkün olanın sınırlarını zorlamaktır. SmolLM2, cihaz üzerinde verimli çalışacak şekilde tasarlanmış 135M, 360M ve 1.7B parametreli üç yetenekli model sundu. SmolLM3 için ise telefonlarda çalışabilecek kadar küçük kalırken performansı artırmak ve SmolLM2’nin zayıf yönleri olan çok dillilik, çok uzun bağlamları işleme ve güçlü muhakeme yetenekleri konularını geliştirmek istedik. Bu denge için en uygun nokta olarak 3B parametreyi seçtik.

Kanıtlanmış bir yaklaşımı ölçeklendirdiğimiz için doğal olarak yoğun (dense) transformer mimarilerine yöneldik. MoE henüz Nanotron’da uygulanmamıştı ve güçlü küçük yoğun modeller eğitme konusunda zaten gerekli uzmanlığa ve altyapıya sahiptik. Daha da önemlisi, uç cihazlara dağıtımda bellek kısıtlıyız; çok sayıda parametreye sahip bir MoE’de yalnızca birkaç uzman etkin olsa bile tüm uzmanları belleğe yüklemek gerekir. Bu da yoğun modelleri daha pratik bir seçenek hâline getirir.

Temel olarak SmolLM2 1.7B mimarisiyle başladık ve ardından Qwen2.5–3B düzenini kullanarak 100B token üzerinde bir 3B ablasyon modeli eğittik. Bu bize her değişikliği ayrı ayrı test edebileceğimiz sağlam bir başlangıç noktası sağladı. Her mimari değişikliğin ya İngilizce kıyaslama testlerinde kaybı (loss) ve aşağı akış performansını iyileştirmesi ya da kaliteyi düşürmeden çıkarım hızı gibi ölçülebilir faydalar sunması gerekiyordu.

Başarılı olan eğitim çalışmasını başlatmadan önce test ettiklerimiz şunlardı:

Tokenizer: Mimari değişikliklere geçmeden önce bir tokenizer seçmemiz gerekiyordu. Hedef dillerimizi ve alanlarımızı kapsayan iyi bir aday kümesi bulduk. Verimlilik (fertility) analizimize göre, Llama 3.2’nin tokenizer’ı altı hedef dilimizdeki performans açısından en iyi dengeyi sağlarken sözlük boyutunu 128k’de tuttu. Bu boyut, çok dilli verimlilik için yeterince büyük, ancak gömme (embedding) ağırlıkları nedeniyle 3B parametre sayısını gereksiz şekilde şişirmeyecek kadar da küçüktü.

Gruplandırılmış sorgu dikkati (Grouped Query Attention — GQA): Dört gruplu GQA’nın MHA ile aynı performansı verdiğine dair önceki bulgumuzu bu kez 3B ölçeğinde ve 100B token üzerinde yeniden doğruladık. KV önbelleği verimliliğindeki kazanımlar, özellikle belleğin kritik olduğu cihaz içi kullanım senaryolarında göz ardı edilemeyecek kadar büyüktü.

Uzun bağlam için NoPE: Hibrit bir konumsal kodlama düzeni uyguladık; her dördüncü katmanda NoPE, diğer katmanlarda ise RoPE kullandık. 3B ablasyonumuz önceki bulgularımızı doğruladı: NoPE, kısa bağlam performansından ödün vermeden uzun bağlam işleme yeteneğini geliştirdi.

Belge içi dikkat maskeleme (Intra-document attention masking): Çok uzun diziler üzerinde eğitim sırasında hız ve kararlılığı artırmak için belgeler arası dikkati engelledik. Yine, bunun aşağı akış performansı üzerinde bir etkisi olmadığını gördük.

Model düzeni optimizasyonu: Literatürdeki yakın dönem 3B modellerin düzenlerini karşılaştırdık; bazıları derinliği, bazıları ise genişliği önceliklendiriyordu. Eğitim düzenimizde derinlik ve genişliğin değiştiği Qwen2.5–3B (3.1B), Llama 3.2–3B (3.2B) ve Falcon3-H1–3B (3.1B) mimarilerini test ettik. Sonuçlar ilginçti: Qwen2.5–3B’nin aslında daha az parametreye sahip olmasına rağmen tüm düzenler neredeyse aynı kayıp ve aşağı akış performansına ulaştı. Ancak Qwen2.5–3B’nin daha derin mimarisi, ağ derinliğinin genelleme yeteneğine katkı sağladığını gösteren araştırmalarla (Petty ve ark., 2024) uyumluydu. Bu nedenle, eğitim ilerledikçe fayda sağlayacağını düşünerek daha derin düzeni tercih ettik.

Kararlılık iyileştirmeleri: SmolLM2’deki bağlı (tied) embedding’leri koruduk ancak OLMo 2’den esinlenen yeni bir yöntem ekledik: embedding’lerden weight decay’i kaldırdık. Ablasyonlarımız bunun performansa zarar vermediğini, buna karşılık embedding normlarını düşürdüğünü gösterdi; bu da eğitim sırasında sapmaları (divergence) önlemeye yardımcı olabilir.

Sistematik ablasyon yaklaşımının güzelliği, bu değişikliklerin her birinin doğrulandığını bilerek hepsini güvenle bir araya getirebilmemizdi.

Ablasyonlarda değişiklikleri birleştirmek

Pratikte değişiklikleri artımlı olarak test ederiz: Bir özellik doğrulandığında, sonraki özelliği test etmek için temel yapılandırmanın bir parçası hâline gelir. Test sırası önemlidir. Önce sahada kendini kanıtlamış özelliklerle başlayın (tied embeddings → GQA → belge maskeleme → NoPE → weight decay’in kaldırılması).

Çatışma Kuralları

Özetle: Seçimleriniz kullanım senaryonuza bağlıdır.

Dağıtım hedefinizin mimari kararları yönlendirmesine izin verin. Yeni mimari yenilikleri değerlendirirken modelinizin gerçekte nasıl ve nerede çalışacağını göz önünde bulundurun.

Yenilik ile pragmatizm arasında doğru dengeyi kurun. Büyük mimari ilerlemeleri görmezden gelmeyi göze alamayız; daha iyi alternatifler (örneğin GQA) varken MHA kullanmak teknik açıdan kötü bir tercih olurdu. En güncel araştırmaları takip edin ve ölçekte açık, doğrulanmış faydalar sunan teknikleri benimseyin. Ancak marjinal kazanımlar vaat eden her yeni makalenin peşinden gitme cazibesine karşı koyun (bunu yapacak kaynaklara sahip değilseniz veya amacınız mimari araştırma değilse).

Sistematik yaklaşım sezgisel yaklaşımdan üstündür. Kâğıt üzerinde ne kadar umut verici görünürse görünsün, her mimari değişikliği doğrulayın. Etkilerini anlamak için değişiklikleri birleştirmeden önce tek tek test edin.

Ölçek etkileri gerçektir; mümkün olduğunda hedef boyutta yeniden ablasyon yapın. Küçük ölçekli ablasyonlarınızın hedef model boyutunda tamamen geçerli olacağını varsaymayın. Hesaplama kaynağınız varsa bunları yeniden doğrulamaya çalışın.

Tokenizer verimliliğini kendi alanlarınız üzerinde doğrulayın. Hedef dilleriniz ve alanlarınızdaki verimlilik (fertility) metrikleri, en son modelin ne kullandığını takip etmekten daha önemlidir. Ciddi çok dilli çalışmalar için 50k’lık İngilizce odaklı bir tokenizer yeterli olmayacaktır; ancak çok fazla dili kapsamıyorsanız 256k’lık bir sözlüğe de ihtiyacınız yoktur.

Artık model mimarisi belirlendiğine göre, öğrenme sürecini yönlendirecek optimizer ve hiperparametreleri ele almanın zamanı geldi.

Optimizer ve Eğitim Hiperparametreleri

Parçalar yavaş yavaş yerine oturuyor. Ablasyonlarımızı gerçekleştirdik, mimaride karar kıldık ve bir tokenizer seçtik. Ancak eğitimi gerçekten başlatabilmek için hâlâ bazı kritik kararlar vermemiz gerekiyor: Hangi optimizer’ı kullanmalıyız? Öğrenme oranı (learning rate) ve batch boyutu ne olmalı? Eğitim boyunca öğrenme oranını nasıl planlamalıyız?

Buradaki cazip yaklaşım, literatürdeki güçlü bir modelden değerleri doğrudan almaktır. Sonuçta büyük laboratuvarlarda işe yaradıysa bizim için de işe yaramalıdır, değil mi? Ve birçok durumda, benzer bir mimari ve model boyutundan değerler alıyorsak bu yaklaşım gayet iyi sonuç verecektir.

Ancak bu değerleri kendi kurulumumuza göre ayarlamazsak performansın bir kısmını kaçırma riskiyle karşı karşıya kalırız. Literatürde bildirilen hiperparametreler belirli veri kümeleri ve kısıtlamalar için optimize edilmiştir; bazen bu kısıtlamalar performansla bile ilgili değildir. Belki öğrenme oranı geliştirme sürecinin başlarında seçilmiş ve bir daha gözden geçirilmemiştir. Model yazarları kapsamlı hiperparametre taramaları yapmış olsalar bile, bulunan optimum değerler onların mimari, veri ve eğitim rejimi kombinasyonları için geçerlidir; bizimkiler için değil. Literatürdeki değerler her zaman iyi bir başlangıç noktasıdır, ancak yakın çevrelerinde daha iyi değerler bulup bulamayacağımızı araştırmak akıllıca olacaktır.

Bu bölümde en güncel optimizer’ları inceleyeceğiz (ve eski ama güvenilir AdamW’nin (Kingma, 2014) hâlâ zamana karşı dayanıp dayanmadığını göreceğiz), standart kosinüs bozunmasının ötesine geçen öğrenme oranı planlamalarını ele alacağız ve model ile veri boyutuna bağlı olarak öğrenme oranı ve batch boyutunun nasıl ayarlanacağını inceleyeceğiz.

Önce optimizer savaşlarıyla başlayalım.

Optimizer’lar: AdamW ve Ötesi

Optimizer, tüm LLM eğitim sürecinin merkezinde yer alır. Geçmiş güncellemeler, mevcut ağırlıklar ve kayıptan türetilen gradyanlar temelinde her parametre için gerçek güncelleme adımının ne olacağını belirler. Aynı zamanda bellek ve hesaplama açısından oldukça maliyetlidir; bu nedenle ihtiyaç duyduğunuz GPU sayısını ve eğitiminizin hızını doğrudan etkileyebilir.

Bir optimizer’ın ne olduğundan ve ne işe yaradığından emin değilseniz, özellikle farklı optimizer’ları karşılaştıran Sebastian Ruder’ın Gradient Descent ve optimizer’lar hakkındaki blog yazısına göz atabilirsiniz.

LLM ön eğitimi için kullanılan optimizer’ların mevcut durumu aşağıdaki gibidir: Kimi K2 ve GLM 4.5 Muon optimizer kullanırken diğer her model AdamW kullanır.

Peki, herkes neden AdamW kullanıyor diye merak edebilirsiniz.

Bu rehberin bu kısmını yazan kişi (merhaba, Elie) bunun sebebinin “insanların tembel olması” olduğunu düşünüyor, ancak diğerleri daha gerçekçi bir şekilde AdamW’nin uzun süredir farklı ölçeklerde rakiplerinden daha iyi ya da en azından benzer şekilde çalıştığını söyleyebilir. Ayrıca, özellikle çok uzun eğitim süreçlerinde ne kadar iyi performans gösterdiğini test etmek zor (ve pahalı) olduğunda, böylesine temel bir bileşeni değiştirmek her zaman biraz ürkütücüdür.

Üstelik optimizer’ları adil bir şekilde karşılaştırmak göründüğünden daha zordur. Ölçek büyüdükçe dinamikler değişir ve bu değişimleri küçük ölçekli ablasyonlarla simüle etmek her zaman mümkün olmaz; bu nedenle hiperparametre ayarlaması oldukça karmaşıktır. Şöyle düşünebilirsiniz: “Sorun değil, AdamW’yi haftalarca ayarladım, karşılaştırma yapmak için aynı hiperparametreleri kullanırım!” Keşke bu doğru olsaydı. Ancak ne yazık ki her optimizer için uygun bir hiperparametre taraması yapmak gerekir (1 boyutlu mu, 2 boyutlu mu, 3 boyutlu mu?). Bu da optimizer araştırmalarını hem zor hem de maliyetli hâle getirir.

Çoğu zaman temel karşılaştırma modeli (baseline) yeterince iyi ayarlanmamıştır; bu nedenle yeni optimizer’lar zayıf AdamW ayarlarına karşı test edilir. Yakın tarihli bir çalışma (Wen ve ark., 2025), yalnızca bunun bile rapor edilen kazanımları ne kadar çarpıtabildiğini göstermektedir.

AdamW

Adam (Adaptive Momentum Estimation), birinci dereceden bir optimizasyon yöntemidir; yani yalnızca gradyanlara bakar. Geçmiş gradyanlardan elde edilen momentum bilgisini kullanarak her parametre için öğrenme oranını uyarlamalı şekilde ayarlar. W’yi (weight decay) ekliyoruz çünkü standart stokastik gradyan inişinde (SGD), L2 düzenlileştirmesi uygulamak için kayıp fonksiyonuna şu terimi ekleyebiliriz: λθ² (Burada θ ağırlıkları temsil eder.) Ancak Adam’da aynı işlemi yaparsak, uyarlamalı öğrenme oranı L2 düzenlileştirmesini de etkiler. Bunun sonucu olarak düzenlileştirme gücü gradyan büyüklüklerine bağlı hâle gelir ve etkisi zayıflar.

Bu ise istediğimiz bir davranış değildir. AdamW, weight decay’i ana optimizasyon döngüsünden ayrıştırılmış (decoupled) şekilde uygular ve böylece bu sorunu çözer.

İlginç olan şu ki, son birkaç yılda AdamW’nin hiperparametreleri neredeyse hiç değişmedi:

• β₁ = 0.9, β₂ = 0.95
• Gradyan normu kırpma (grad norm clipping) = 1.0
• Weight decay = 0.1 (Llama 3 405B bu değeri 0.01’e düşürüyor)

Aynı üçlü;

• Llama 1, 2 ve 3 modellerinde,
• DeepSeek-V1, V2 ve V3–671B modellerinde

hiç değiştirilmeden tekrar kullanılmıştır.

Peki Durk Kingma en başından beri haklı mıydı, yoksa bundan daha iyisini yapabilir miyiz?

Tek Satırda Muon

Adam, yalnızca gradyanları kullandığı için birinci dereceden bir yöntemdir. Muon ise bir parametre tensörünün matris görünümü üzerinde çalışan ikinci dereceden bir optimizatördür:

G_t = ∇_θ Lt(θ{t−1}) Bt = μ B{t−1} + G_t O_t = NewtonSchulz5(B_t) ≈ U V^T (eğer B_t = U Σ V^T ise, SVD) θt = θ{t−1} − η O_t G_t

Bu denklemlere baktığınızda şu soruyu sorabilirsiniz: “Bu neden ikinci dereceden bir yöntem? Ben yalnızca gradyanları görüyorum, daha yüksek dereceli terimler yok!”

Aslında ikinci dereceden optimizasyon, Newton-Schulz adımı içinde gerçekleşir; ancak burada ayrıntısına girmeyeceğiz. Muon’u derinlemesine açıklayan çok sayıda kaliteli kaynak var, biz burada yalnızca üç temel fikre odaklanacağız:

Muon hakkında daha fazla öğrenmek için Keller Jordan ve Jeremy Bernstein’ın blog yazılarını ve Jia-Bin Huang’ın video anlatımını öneriyoruz; başlangıç için oldukça iyi kaynaklardır.

Matris düzeyi geometri vs. parametre düzeyi güncellemeler: AdamW, her parametreyi ayrı ayrı ölçekler (diagonal ikinci moment yaklaşımı). Muon ise her ağırlık matrisini tek bir bütün olarak ele alır ve güncellemeyi G = U V^T yönünde yapar; bu, satır/sütun altuzay yapısını yakalar.

İzotropik adımlar ve ortogonalizasyon: G = U Σ V^T SVD ile büyüklük (Σ) ile yönleri (U ve V altuzayları) ayırır. G yerine U V^T koymak, tekil değerleri atar ve adımı ilgili altuzaylarda izotropik hâle getirir. İlk bakışta Σ’yı atmak bilgi kaybı gibi görünür; ancak bu, eksen hizalı yanlılığı azaltır ve çok küçük tekil değerler nedeniyle bastırılan yönlerin keşfini teşvik eder. Bunun modelde yalnızca kayıptan bakıldığında görünmeyen farklı yetenekler oluşturup oluşturmadığı hâlâ açık bir sorudur.

Daha büyük batch size toleransı: Pratikte Muon çoğu zaman daha yüksek batch size’ları tolere eder. Bunu batch size bölümünde daha ayrıntılı ele alacağız, ancak bu Muon’un benimsenmesinin önemli motivasyonlarından biri olabilir.

Uzun yıllar boyunca topluluk büyük ölçüde AdamW üzerinde birleşti ve frontier laboratuvarlarının optimizer tarifleri çoğunlukla gizli tutuldu (örneğin Qwen kendi ayarlarını paylaşmıyor). Ancak son dönemde Muon, bazı yüksek profilli sürümlerde (ör. Kimi K2 ve GLM-4.5) kullanılmaya başlandı. Gelecekte daha açık ve sağlam reçeteler görmeyi umuyoruz.

Optimizatör dünyası oldukça geniş bir hayvanat bahçesidir; araştırmacıların en yaratıcı olduğu iki şey: farklı momentum ve türev kombinasyonları yapmak ve bunlara isim bulmaktır: Shampoo, SOAP, PSGD, CASPR, DION, Sophia, Lion… hatta AdamW’nin bile NAdamW, StableAdamW gibi türevleri vardır.

Bu optimizatörlerin hepsine girmek başlı başına ayrı bir rehber olurdu; şimdilik bunu başka zamana bırakıyoruz. Bu arada Stanford’daki Marin ekibinin (Wen et al., 2025) farklı optimizer’ları karşılaştırarak hiperparametre ayarlamasının ne kadar kritik olduğunu gösterdiği harika çalışmayı öneriyoruz.

Neredeyse her optimizer seçimiyle birlikte gelen bir diğer soru ise şudur: Güncelleme ne kadar güçlü olmalı? Bunu belirleyen şey learning rate’tir ve genellikle optimizer denklemlerinde bir skaler olarak görünür. Basit gibi görünse de, bir sonraki bölümde göreceğiniz gibi bunun birçok farklı boyutu vardır.

Öğrenme Oranı

Öğrenme oranı (LR), ayarlamamız gereken en önemli hiperparametrelerden biridir. Her eğitim adımında, hesaplanan gradyanlara göre model ağırlıklarını ne kadar güncelleyeceğimizi kontrol eder. Öğrenme oranını çok düşük seçmek, eğitimi acı verici derecede yavaşlatır ve kötü bir yerel minimuma sıkışma riskini doğurur. Kayıp eğrileri neredeyse düz görünür ve anlamlı bir ilerleme kaydetmeden hesaplama bütçemizi tüketiriz. Öte yandan, öğrenme oranını çok yüksek ayarlamak, optimizer’ın optimal çözümleri sürekli aşan büyük adımlar atmasına neden olur ve model asla yakınsamaz (ya da düşünülemez bir şey olur: loss sapar ve “uzaya fırlar”).

Ancak en iyi öğrenme oranı sabit de değildir, çünkü eğitim sırasında öğrenme dinamikleri değişir. Başlangıçta, iyi çözümlerden uzaktayken yüksek öğrenme oranları işe yarar; fakat yakınsama aşamasında bu değerler istikrarsızlığa yol açar. İşte burada öğrenme oranı planlamaları devreye girer: Erken aşamadaki kaosu önlemek için sıfırdan ısınma (warmup), ardından iyi bir minimuma yerleşmek için kademeli azalma (decay). Warmup + kosinüs azalımı gibi desenler, yıllar boyunca sinir ağı eğitiminde doğrulanmıştır.

Warmup adımları

Modern LLM’lerin çoğu, model boyutundan ve eğitim süresinden bağımsız olarak sabit sayıda warmup adımı kullanır (örneğin 2.000 adım). Bu durum, “Mimari Seçimler” bölümünün başındaki tabloda da görülmektedir. Çok kısa eğitimler için toplam adımların %1–%5’i kadar warmup kullanmak yaygındır. Daha uzun eğitimlerde ise warmup adım sayısını artırmanın genellikle performansa önemli bir etkisi olmadığı gözlemlenmiştir.

Şimdi yaygın öğrenme oranı planlamalarına bakalım ve ardından tepe (peak) değerinin nasıl seçileceğini tartışalım.

Öğrenme Oranı Planlamaları: Kosinüs Azalımının Ötesi

Öğrenme oranının değiştirilmesinin yakınsamayı iyileştirdiği yıllardır bilinmektedir (Smith & Topin, 2018) ve uzun süre kosinüs azalımı (Loshchilov & Hutter, 2017) LLM eğitimi için standart yaklaşım olmuştur: Warmup’tan sonra tepe öğrenme oranına çıkılır ve ardından kosinüs eğrisiyle yumuşak şekilde düşürülür. Bu yöntem basit ve etkilidir. En büyük dezavantajı esneksizliktir; eğitim adım sayısını önceden bilmek gerekir, çünkü kosinüs eğrisinin uzunluğu toplam eğitim süresiyle eşleşmelidir. Bu durum birkaç senaryoda sorun yaratır: Model henüz plato yapmamışken daha fazla hesaplama kaynağı elde edip eğitimi uzatmak istediğinizde ya da ölçek yasaları çalışırken aynı modeli farklı token sayılarıyla eğitmeniz gerektiğinde. Kosinüs azalımı sizi her seferinde sıfırdan başlamaya zorlar.

İlginç bir şekilde bu esneksizlik, erken ölçekleme yasaları araştırmalarını da etkilemiştir (Kaplan ve ark., 2020); çünkü yazarlar farklı token sayılarıyla modelleri eğitirken sabit uzunlukta kosinüs planı kullanmış ve veri boyutunun etkisini olduğundan küçük tahmin etmişlerdir. Chinchilla çalışması (Hoffmann ve ark., 2022) bunu düzeltmiş ve plan uzunluğunu her modelin gerçek eğitim süresine uyarlamıştır.

Günümüzde birçok ekip, warmup sonrası hemen düşüşe geçmek zorunda olmayan planlar kullanmaktadır. Warmup–stable–decay (WSD) (Hu ve ark., 2024) ve multi-step (DeepSeek-AI, 2024) varyantları buna örnektir. Aşağıdaki gibi bir yaklaşımda öğrenme oranı, eğitim boyunca bir süre sabit yüksek seviyede tutulur, ardından ya son %10–20’lik token kısmında hızlı bir düşüş yapılır (WSD) ya da kademeli “basamaklı” düşüşler uygulanır. Örneğin DeepSeek LLM, eğitim süresinin %80 ve %90 noktalarında düşüşler içeren bir multi-step öğrenme oranı planı kullanır.

Bu planlar, kosinüs azalımına kıyasla pratik avantajlar sunar. Eğitimi yeniden başlatmadan ortada uzatabilir, eğitim ilerleyişini daha net görebilmek için erken aşamada decay uygulayabilir ve ölçek yasası deneylerini farklı token sayıları arasında tek bir ana eğitim koşusu içinde çalıştırabiliriz. Ayrıca çalışmalar, hem WSD hem de multi-step yöntemlerinin kosinüs azalımıyla benzer performans gösterdiğini (DeepSeek-AI, 2024; Hägele ve ark., 2024) ancak gerçek dünya eğitim senaryoları için daha pratik olduğunu göstermektedir.

Yakın zamanda GLM-4.5 (5 Team ve ark., 2025), WSD’nin genel benchmark’larda (SimpleQA, MMLU) kosinüs azalımından daha kötü performans gösterdiğini belirtmiştir, ancak bu iddiayı destekleyen sonuçlar paylaşılmamıştır.

Ama muhtemelen fark etmişsinizdir: Bu planlar, kosinüs azalımına kıyasla yeni hiperparametreler getirir. WSD’de decay fazı ne kadar sürmelidir? Multi-step varyantında her bir adım ne kadar uzun olmalıdır?

WSD için: Kosinüs performansına ulaşmak için gereken “cooldown” süresi, eğitim süresi uzadıkça azalır. Genel olarak toplam tokenların %10–%20’sinin decay fazına ayrılması önerilir (Hägele ve ark., 2024). Bir sonraki bölümde yapacağımız ablasyonlarda bu ayarın kosinüs ile uyumlu olduğunu doğrulayacağız.

Multi-step için: DeepSeek LLM’nin ablasyonları, temel 80/10/10 ayrımının (eğitimin %80’ine kadar sabit, %80–90 arası ilk düşüş, %90–100 arası ikinci düşüş) kosinüs ile eşdeğer performans verdiğini göstermiştir. Ancak bu oranların ayarlanmasıyla performansı aşmak da mümkündür (örneğin 70/15/15 veya 60/20/20 gibi bölümler kullanarak).

Öğrenme oranı planlamalarında daha da yaratıcı olunabilir. Şimdi DeepSeek modellerinin bazı diğer planlarına bakalım:

DeepSeek LLM, temel multi-step planını (80/10/10) kullanmıştır. DeepSeek V2 (DeepSeek-AI, Liu ve ark., 2024) oranları 60/30/10 şeklinde değiştirerek ilk decay adımına daha fazla zaman tanımıştır. DeepSeek V3 (DeepSeek-AI ve ark., 2025) ise en yaratıcı yaklaşımı benimsemiştir: sabit bir öğrenme oranını korumak ve ardından iki keskin adım uygulamak yerine, eğitim sürecinin %67’si ile %97’si arasında kosinüs tabanlı bir azalmaya geçiş yapmış, ardından son keskin adımdan önce kısa bir sabit faz eklemiştir.

DeepSeek schedule değişiklikleri DeepSeek-V2 ve V3 teknik raporlarında bu plan değişikliklerine dair ablasyonlar yer almamaktadır. Kendi kurulumunuz için önce basit WSD veya multi-step planlarıyla başlamak, ardından hiperparametreleri ablasyonlarla ayarlamak en güvenli yaklaşımdır.

Şimdi egzotik öğrenme oranı planlarını incelemeyi burada bırakalım ve pratikte neyin işe yaradığını görmek için GPU saatleri harcayalım!

Ablasyon — WSD, Kosinüs ile Eşleşiyor mu?

Bir ablasyon zamanı. WSD’nin gerçekten kosinüs performansına ulaşıp ulaşmadığını test edelim. Burada multi-step ablasyonlarını göstermeyeceğiz; ancak DeepSeek LLM’nin çalışmasına göz atmanızı öneririz, çünkü farklı faz bölünmeleriyle multi-step’in kosinüs ile eşleştiğini gösterir.

Kosinüs azalımı ile WSD’yi iki farklı decay penceresiyle karşılaştıracağız: %10 ve %20.

Deney sonuçları, üç yapılandırmanın da nihai performansının benzer olduğunu göstermektedir. Kayıp ve değerlendirme eğrilerine (özellikle HellaSwag) baktığımızda ilginç bir desen görürüz: Kosinüs, WSD’nin decay aşaması başlamadan önceki sabit fazda daha iyi loss ve değerlendirme skorları elde eder. Ancak WSD decay fazına geçtiğinde hem loss hem de aşağı akış metriklerinde neredeyse doğrusal bir iyileşme görülür ve bu sayede eğitim sonunda kosinüse yetişir.

Bu sonuç, WSD’nin %10–%20’lik decay penceresinin kosinüs ile aynı nihai performansı yakalamak için yeterli olduğunu, aynı zamanda eğitim sürecini ortada uzatma esnekliği sunduğunu doğrular. SmolLM3 için %10 decay içeren WSD tercih ettik.

Farklı scheduler’larla eğitilmiş modelleri ortada karşılaştırma Eğer kosinüs ve WSD checkpoint’lerini eğitim ortasında karşılaştırıyorsanız, adil bir kıyaslama için WSD checkpoint’ine bir decay uyguladığınızdan emin olun.

Artık popüler öğrenme oranı planlarına genel bir bakışımız var. Bir sonraki soru şu: Öğrenme oranı aslında ne olmalı?

Optimal Öğrenme Oranını Bulmak

Kendi scheduler’ımıza ve eğitim kurulumumuza uygun optimal öğrenme oranını bulmak için, mimari seçimlerde yaptığımız gibi kısa ablasyonlarla LR taramaları yapabiliriz. Ancak optimal learning rate eğitim süresine bağlıdır: Kısa bir ablasyonda en hızlı yakınsayan learning rate, uzun koşu için en iyi seçenek olmayabilir. Ve çok haftalık pahalı eğitimleri sırf farklı learning rate’leri denemek için tekrar tekrar çalıştırmak mümkün değildir.

Önce, çok yüksek veya çok düşük learning rate’leri hızlıca elememizi sağlayacak basit taramalara bakalım. Ardından hiperparametreler için scaling laws konusunu tartışacağız.

Ablasyon — LR Sweep’leri

Öğrenme oranlarının etkisini göstermek için 1B ablasyon modelimiz üzerinde 45B token ile bir tarama yapalım. Aynı modeli, aynı kurulumla dört farklı learning rate ile eğiteceğiz: 1e-4, 5e-4, 5e-3, 5e-2. Sonuçlar her iki uçtaki tehlikeleri net bir şekilde ortaya koymaktadır.

LR 5e-2 neredeyse anında diverge eder: Loss erken aşamada yükselir ve hiçbir zaman toparlanmaz, bu da modeli kullanılamaz hâle getirir. LR 1e-4 ise fazla temkinlidir; stabil şekilde eğitilse de diğer öğrenme oranlarına kıyasla çok daha yavaş yakınsar. Orta seviye seçenekler olan LR 5e-4 ve LR 5e-3 daha iyi yakınsama ve karşılaştırılabilir performans gösterir.

SmolLM3 için, AdamW kullanarak WSD planı ile 100B token üzerinde eğitilen 3B modellerde birkaç learning rate karşılaştırdık. 1e-4’ün hem loss hem de aşağı akış performansında 2e-4’e kıyasla belirgin şekilde daha yavaş yakınsadığını, 3e-4’ün ise 2e-4’e yalnızca küçük bir iyileşme sağladığını gördük. 3e-4’ün sağladığı marjinal kazanç, uzun eğitim koşularında artan instabilite riski ile birlikte geldiği için 2e-4’ü en iyi denge noktası olarak seçtik.

Bu tür taramalar, açıkça çok yüksek (divergence) veya çok düşük (yavaş yakınsama) learning rate’leri elememizi sağlar — ancak her model ölçeği için bunu yapmak hızla pahalı hâle gelir ve daha da önemlisi kısa eğitimlerde elde edilen sonuçlar tam ölçekli koşulara birebir taşınmayabilir. İşte burada scaling laws vazgeçilmez hâle gelir.

Scaling laws’a geçmeden önce, learning rate ile etkileşen diğer kritik hiperparametreyi tartışalım: batch size.

Batch Size

Batch size, model ağırlıkları güncellenmeden önce işlenen örnek sayısıdır. Eğitim verimliliğini ve nihai model performansını doğrudan etkiler. Batch size artırmak, donanım ve eğitim altyapınız iyi ölçekleniyorsa throughput’u (veri işleme hızını) artırır. Ancak belirli bir noktadan sonra büyük batch’ler veri verimliliğini düşürmeye başlar: aynı loss seviyesine ulaşmak için daha fazla toplam token gerekir. Bu kırılma noktası critical batch size olarak bilinir (McCandlish ve ark., 2018).

Throughput, eğitim sırasında saniyede işlenen token sayısıdır.

Batch size’ı ölçeklemenin iki yolu vardır:

1. Kritik sınırın altında ölçekleme: Batch size artırılır ve learning rate yeniden ayarlanırsa, daha küçük batch run’ı ile aynı token sayısında aynı loss’a ulaşılır; veri israfı olmaz.
2. Kritik sınırın üstünde ölçekleme: Daha büyük batch’ler veri verimliliğini düşürmeye başlar; aynı loss’a ulaşmak için daha fazla toplam token gerekir (yani daha fazla maliyet), ancak daha fazla GPU paralelliği sayesinde wall-clock süre azalabilir.

Batch size büyüdükçe her mini-batch gradyanı gerçek gradyanın daha iyi bir tahmini olur. Bu, daha büyük adımlar atmayı (yani learning rate’i artırmayı) mümkün kılar. Ama bunun nasıl ölçekleneceği kritik bir sorudur.

B örneklem üzerinde ortalama alırsak, batch gradyan, ortalama aynı kalır ancak kovaryans küçülür. SGD parameteresi bu şekilde güncellenir, ve bu güncellemenin varyansı şunlarla orantılıdır.

Bu nedenle batch size’ı k kat artırırsanız, update varyansını sabit tutmak için learning rate’i √k ölçeğinde artırmak gerekir.

Bcritical​→kBoptimal​⇒ηcritical​→√k​ηoptimal

Pratikte AdamW veya Muon gibi optimizer’lar için bu ölçekleme her zaman tam olarak geçerli değildir; β₁ / β₂ gibi parametrelerle etkileşimler farklı davranışlar üretebilir. Bu yüzden Merrill ve ark. (2025) tarafından önerilen pragmatik bir yöntem, kısa bir “branching” testidir: bir run’ı eski batch size’da bırakıp diğerini yeni batch size + ölçeklenmiş LR ile başlatmak ve loss eğrilerinin uyumunu kontrol etmek.

Critical batch size sabit değildir; eğitim ilerledikçe büyür. Başlarda gradyanlar daha gürültülüdür, bu yüzden kritik batch size küçüktür. Eğitim stabil hâle geldikçe daha büyük batch’ler verimli hâle gelir. Bu yüzden bazı büyük ölçekli eğitimlerde batch size warmup kullanılır. Örneğin DeepSeek-V3, ilk ~469B token boyunca 12.6M batch ile başlayıp daha sonra 62.9M batch’e çıkar.

Batch size warmup, learning rate warmup’a benzer şekilde çalışır: optimizasyonu verimli bölgede tutar.

Bazı sistemler (MiniMax-01 gibi) loss’u critical batch size için bir proxy olarak kullanır ve eğitim sonunda çok büyük batch size’lara çıkar (128M gibi). Bu durumda batch size değişimi, fiilen learning rate decay etkisi yaratır.

Batch Size ve Learning Rate Tuning

Pratikte yaklaşım şöyledir:

• Önce literatür veya scaling laws ile makul bir batch size ve learning rate seç
• Sonra batch size’ı artırarak throughput kazanımı olup olmadığına bak
• Learning rate’i mutlaka yeniden ayarla
• Eğer verimlilik artmıyorsa veya loss kötüleşiyorsa eski ayarlara dön

Bir sonraki adım scaling laws’tur.

Hiperparametreler için Scaling Laws

Optimal learning rate ve batch size yalnızca model mimarisi ve boyutuna değil, compute budget’a da bağlıdır. Compute budget, parametre sayısı ve token sayısına göre belirlenir.

C ≈ 6 × N × D

Burada:

• N: model parametre sayısı
• D: eğitim token sayısı
• C: toplam compute (FLOPs)

Bu formül, transformer eğitiminde yaklaşık 6 FLOPs / parametre / token gereksiniminden gelir.

Scaling laws sayesinde şu sorulara cevap verebiliriz:

• 1B’den 7B’ye çıkarken learning rate nasıl değişmeli?
• Veri iki katına çıkarsa learning rate ayarlanmalı mı?

DeepSeek LLM yaklaşımı şöyle çalışır:

• WSD gibi esnek bir schedule seç
• Farklı compute budget’larda modeller eğit (ör. 1e17–2e19 FLOPs)
• Her biri için LR ve batch size sweep yap
• En iyiye yakın noktaları seç (validation loss’un %0.25 içi gibi)
• (C, η) ve (C, B) noktalarını log-log grafikte fit et

Bu noktalar genelde power law davranışı gösterir ve log-log düzlemde yaklaşık düz çizgiler oluşturur.

Önemli sonuç: Geniş bir “iyi hiperparametre bölgesi” vardır. Yani tek bir mükemmel değer yoktur; sadece yeterince iyi bir bölge vardır.

Şekil 3 | Toplu işlem boyutu ve öğrenme oranının ölçeklendirme eğrileri. Gri daireler, genelleme hatası minimum değeri en fazla %0,25 aşan modelleri temsil eder. Noktalı çizgi, daha küçük modele uyan güç yasasını temsil eder. Mavi yıldızlar DeepSeek LLM 7B ve 67B’yi temsil eder.

Bu sonuçların arkasındaki temel sezgi, eğitim büyüdükçe ve uzadıkça daha kararlı güncellemeler (daha küçük öğrenme oranları) ve daha verimli gradyan tahmini (daha büyük batch boyutları) istediğimizdir.

Bu ölçekleme yasaları bize öğrenme oranı ve batch boyutu için başlangıç noktaları verir. Ancak hedef “gradyan başına optimal örnek sayısı” değil, “zaman ve GPU kısıtlarımız içinde ulaşılabilir daha düşük loss” elde etmek ve aynı zamanda her bir token’dan tam sinyali çıkarmaktır.

Pratikte, veri verimliliğine anlamlı bir zarar vermeden, kritik batch boyutuna kadar, ki bunu daha önce tartışmıştık, verimliliği ciddi şekilde artırmak için batch boyutunu öngörülen optimal batch boyutunun ötesine çıkarabilirsiniz.

SmolLM3

Peki SmolLM3 için ne kullandık? Ablasyonlar sırasında, 100B token üzerinde eğitilen 1B’lik bir modelde AdamW, AdEMAMix ve Muon’u karşılaştırdık. Muon, doğru şekilde ayarlandığında AdamW’yi geride bırakabildi ancak öğrenme oranına karşı hassastı ve diverjans (eğitimin bozulması) eğilimi gösteriyordu. AdEMAMix, Muon ile benzer loss değerlerine ulaştı ancak daha az hassastı. AdamW ise en stabil olan yöntemdi fakat ayarlanmış alternatiflere kıyasla daha yüksek bir nihai loss’a ulaştı.

Ancak 3B ölçeğine çıktığımızda Muon ve AdEMAMix ile daha sık diverjans yaşadık. Bu durum, ablasyonları bitirdikten sonra keşfettiğimiz bir paralellik hatasından kaynaklanmış olabilir (bkz. “The Training Marathon”), ancak bunu doğrulamadık. Sonuç olarak AdamW’yi (beta1: 0.9, beta2: 0.95), weight decay 0.1 ve gradient clipping 1 ile kullanmaya karar verdik. Nihayetinde oldukça standart (vanilla) bir kurulum.

Öğrenme oranı planı için WSD’yi seçtik. SmolLM2’de bunu başarıyla kullanmıştık ve toplam eğitim süresine göre esneklik sağlaması ile eğitim ortasında decay deneyleri yapabilme imkânı sayesinde en iyi kararlarımızdan biri olduğunu gördük. Öğrenme oranı taramaları yaptık ve 2e-4 değerinde karar kıldık. Global batch size için 2M ile 4M token arasında değerler denedik ancak loss veya downstream performans üzerinde anlamlı bir etki görmedik. Bu yüzden en iyi throughput’u veren 2.36M token değerini seçtik.

Çalışma Prensipleri

TL;DR: Keşif ile uygulama arasında denge kur. Bitmiş bir iş, mükemmel ama hiç başlamamış olandan iyidir.

“Ne” kısmını çok konuştuk (optimizer, learning rate, batch size), ama en az onun kadar önemli olan “nasıl”dır. Ne kadar deneme yapılması gerektiğine nasıl karar veririz? Zamanımızı nasıl yapılandırırız? Ne zaman keşfi bırakıp eğitime başlarız?

Zamanı keşif ve uygulama arasında doğru bölüştürmek gerekir. Yeni bir yöntemle küçük bir iyileştirmeyi haftalarca mükemmelleştirmeye çalışmak, aynı hesaplama bütçesini daha iyi veri kürasyonuna veya daha kapsamlı mimari ablasyonlara harcamaktan daha az değerlidir. Deneyimimize göre, mimari meraklılarını üzse de, en büyük performans kazanımları genellikle veri kürasyonundan gelir.

Şüphede kalındığında, maksimum performans yerine esneklik ve stabiliteyi seçin. Eğer iki yöntem benzer performans gösteriyorsa, daha esnek olanı veya implementasyonu daha olgun ve stabil olanı tercih edin. WSD gibi, eğitimi uzatmaya veya eğitim ortasında deney yapmaya izin veren bir öğrenme oranı planı, biraz daha iyi yakınsayan ama katı bir plandan daha değerlidir.

Ne zaman optimizasyonu bırakıp eğitime başlanacağını bilin. Her zaman ayarlanacak bir hiperparametre veya denenecek başka bir optimizer vardır. Keşif için bir son tarih belirleyin ve buna sadık kalın, gerçekten tamamladığınız model, asla başlamadığınız “mükemmel” modelden her zaman daha iyidir.”

Mükemmeliyetçilik, özellikle sınırlı işlem gücü ve zaman kısıtlamalarıyla çalıştığımızda, iyinin düşmanıdır.

Ölçekleme Yasaları: Kaç Parametre, Ne Kadar Veri?

Derin öğrenmenin ilk günlerinde, dil modelleri (ve onların eğitildiği hesaplama kümeleri) henüz “büyük” sayılmazken, eğitim süreçleri çoğu zaman ciddi bir hesaplama kısıtına tabi değildi. Bir model eğitirken genellikle donanımınıza sığan en büyük modeli ve batch boyutunu seçer, ardından model aşırı öğrenmeye (overfitting) başlayana veya veri bitene kadar eğitirdiniz. Ancak o erken dönemde bile ölçeğin faydalı olduğuna dair bir sezgi vardı, örneğin Hestness ve arkadaşları 2017’de daha büyük modelleri daha uzun süre eğitmenin öngörülebilir kazançlar sağladığını gösteren kapsamlı sonuçlar sunmuştu.

Büyük dil modelleri çağında ise her zaman hesaplama (compute) kısıtlıyız. Neden? Ölçeklenebilirliğe dair ilk fikirler, Kaplan ve arkadaşlarının “Scaling Laws for Neural Language Models” çalışmasıyla daha formal hale getirildi. Bu çalışmada, dil modeli performansının çok geniş ölçek aralıklarında oldukça öngörülebilir olduğu gösterildi. Bu durum, dil modellerinin boyutlarının ve eğitim sürelerinin hızla artmasına yol açtı; çünkü ölçeği artırmanın performansı ne kadar iyileştireceğini tahmin etmek mümkün hale gelmişti. Sonuç olarak, daha iyi dil modelleri geliştirme yarışı; daha büyük modelleri daha fazla veri üzerinde ve daha büyük hesaplama bütçeleriyle eğitme yarışına dönüştü ve alan hızla compute-kısıtlı hale geldi.

Compute kısıtı altında en önemli soru şudur: Daha büyük bir model mi eğitmeliyiz, yoksa daha fazla veri mi kullanmalıyız? Kaplan ve arkadaşlarının ölçekleme yasaları şaşırtıcı şekilde, önceki en iyi pratiklere kıyasla compute’un çok daha büyük bir kısmının model boyutuna ayrılmasının avantajlı olduğunu öne sürdü. Bu yaklaşım, örneğin 175B parametreli dev GPT-3 modelinin görece mütevazı bir token bütçesiyle (300B token) eğitilmesini motive etti. Ancak daha sonra Hoffman ve arkadaşları (2022), Kaplan’ın yönteminde metodolojik bir sorun tespit etti ve ölçekleme yasalarını yeniden türeterek compute’un daha büyük kısmının eğitim süresine (daha fazla token’a) ayrılması gerektiğini gösterdi. Bu yeni sonuçlar, örneğin 175B GPT-3’ün compute-optimal şekilde eğitilmesi durumunda 3.7T token görmesi gerektiğini öne sürüyordu. Hoffman ve arkadaşlarının bu revize edilmiş yasaları “Chinchilla yasaları” olarak anılmaya başladı; isim, bu çalışmayı motive eden Chinchilla modelinden geliyordu.

Bu gelişme alanı “daha büyük modeller yap” yaklaşımından “daha uzun ve daha iyi eğit” yaklaşımına kaydırdı. Ancak modern eğitim çalışmaları hâlâ Chinchilla yasalarını sıkı şekilde takip etmiyor, çünkü bu yasaların bir eksikliği var: Belirli bir compute bütçesi altında en iyi performansı verecek model boyutu ve eğitim süresini tahmin ediyorlar, fakat daha büyük modellerin eğitim sonrası kullanım maliyetini hesaba katmıyorlar. Başka bir deyişle, compute-optimal olmasa bile daha küçük bir modeli daha uzun eğitmek, inference maliyetlerini düşürecekse daha tercih edilebilir olabilir (Sardana et al., 2025; de Vries, 2023). Bu durum özellikle modelin çok yoğun kullanılacağı senaryolarda (örneğin açık kaynak olarak yayınlanmasında) geçerlidir. Son dönemde bu “overtraining” (ölçek yasalarının önerdiğinden daha uzun eğitme) yaklaşımı standart hale geldi ve SmolLM3’ü geliştirirken bizim de benimsediğimiz yöntem buydu.

Ölçekleme yasaları, belirli bir compute bütçesi altında model boyutu ve eğitim süresi için öneriler sunsa da, overtraining seçildiğinde bu kararları sizin vermeniz gerekir. SmolLM3 için önce 3B parametrelik bir hedef model boyutu seçtik. Qwen3–4B, Gemma 3 4B ve Llama 3.2 3B gibi benzer ölçekli modern modellere bakarak 3B’nin, akıl yürütme ve tool calling gibi yetenekler için yeterince güçlü, aynı zamanda hızlı inference ve verimli lokal kullanım için yeterince küçük olduğunu düşündük.

Eğitim süresini belirlemek için ise modern modellerin oldukça “overtrained” olduğunu not ettik — örneğin Qwen3 serisinin 36T token ile eğitildiği iddia ediliyor. Bu nedenle eğitim süresi çoğu zaman mevcut compute bütçesiyle belirleniyor. Biz yaklaşık bir ay boyunca 384 H100 GPU temin ettik ve bu da (~%30 model FLOPs utilization varsayımıyla) 11T tokenlık bir eğitim bütçesi sağladı.

Ölçekleme Yasalarının Değeri

Bu sapmalara rağmen ölçekleme yasaları pratikte hâlâ çok değerlidir. Deney tasarımı için bir temel sağlarlar, insanlar ablasyon çalışmalarında sinyal almak için Chinchilla-optimal kurulumları kullanır ve belirli bir model boyutunun hedef performansa ulaşıp ulaşamayacağını tahmin etmeye yardımcı olurlar. Harm de Vries’in “Go Smol or Go Home” yazısında belirttiği gibi, model boyutunu küçülterek kritik bir modele ulaşabilirsiniz: belirli bir loss seviyesine ulaşmak için gereken minimum kapasite; bunun altına düştüğünüzde getiriler hızla azalır.

Artık model mimarisi, eğitim kurulumu, model boyutu ve eğitim süresi netleştikten sonra iki kritik bileşeni hazırlamak gerekir: modeli eğitecek veri karışımı (data mixture) ve eğitimi güvenilir şekilde yürütecek altyapı. SmolLM3’te 3B parametrelik mimariyi sabitledikten sonra, çok dilli performans, matematik ve kod yeteneklerini güçlü şekilde destekleyecek bir veri karışımı oluşturmak ve 11T tokenlık eğitim sürecini kaldırabilecek sağlam bir altyapı kurmak gerekiyordu. Bu temel bileşenleri doğru kurmak kritik önemdedir, en iyi mimari seçimler bile kötü veri kürasyonu veya kararsız eğitim sistemlerini telafi edemez.

5. Veri Kürasyonunun Sanatı

Hayal edin, haftalarınızı mimarinizi mükemmelleştirmeye, hiperparametreleri ayarlamaya ve en sağlam eğitim altyapısını kurmaya harcadınız. Modeliniz güzel bir şekilde yakınsıyor (converge oluyor), sonra… tutarlı kod yazamıyor, temel matematikte zorlanıyor ve hatta cümlenin ortasında dil değiştiriyor. Ne ters gitti?

Cevap genellikle veride yatıyor. Biz mimari yeniliklere ve hiperparametre aramalarına takılıp kalırken, veri kürasyonu çoğu zaman modelimizin gerçekten kullanışlı bir araca mı dönüşeceğini yoksa sadece pahalı bir deneme mi olacağını belirliyor.

Model mimarisi modelin nasıl öğrendiğini tanımlıyorsa, veri de ne öğrendiğini tanımlar ve hiçbir hesaplama gücü ya da optimizasyon ayarı yanlış içerik üzerinde yapılan eğitimi telafi edemez. Bu, rastgele web kazıma verileri ile gerçekten modelin öğrenmesini istediğimiz becerileri öğreten özenle seçilmiş, yüksek kaliteli veri kümeleri arasındaki farktır. Ancak eğitim verisini doğru yapmak sadece iyi veri kümelerine sahip olmakla ilgili değildir. Asıl mesele doğru karışımı oluşturmaktır: çelişen hedefleri dengelemek (örneğin güçlü İngilizce vs. sağlam çokdillilik) ve performans hedeflerimize uygun veri oranlarını ayarlamak. Bu süreç evrensel bir “en iyi” karışımı bulmaktan çok, doğru soruları sormak ve bunlara cevap verecek somut planlar geliştirmekle ilgilidir:

Modelimizin hangi konularda iyi olmasını istiyoruz? Hangi veri kümeleri her alan için en uygun ve bunları nasıl karıştırmalıyız? Hedef eğitim ölçeğimiz için yeterli yüksek kaliteli veriye sahip miyiz?

Bu bölüm, bu sorularda size rehberlik edecek; ilkeli yöntemler, ablasyon deneyleri ve biraz da “simya” karışımıyla, veri yığınlarını harika bir eğitim karışımına dönüştürmeyi anlatacak.

İyi Bir Veri Karışımı Nedir ve Neden Bu Kadar Önemlidir?

Dil modellerinden çok şey bekliyoruz. Kod yazmamıza yardımcı olabilmeli, tavsiye verebilmeli, neredeyse her konuda soruları yanıtlayabilmeli, araçlar kullanarak görevleri tamamlayabilmeli ve daha fazlasını yapabilmeliler. Ancak web gibi bol miktarda ön-eğitim veri kaynağı, bu görevler için gereken bilgi ve yeteneklerin tamamını kapsamaz. Bu nedenle, son modeller matematik ve kodlama gibi belirli alanları hedefleyen daha özel ön-eğitim veri kümelerine de dayanır. Geçmişte veri kümeleri üzerinde kürasyon konusunda çok çalışma yaptık, ancak SmolLM3 için ağırlıklı olarak önceden var olan veri kümelerini kullandık. (Veri kürasyonu hakkında daha fazla bilgi için FineWeb ve FineWeb-Edu, FineWeb2, Stack-Edu ve FineMath raporlarımıza bakabilirsiniz.)

Veri Karışımlarının Sezgilere Aykırı Doğası

Eğer dil modeli eğitmeye yeni başladıysanız, iyi bir veri karışımı bulmak basit görünebilir: hedef yetenekleri belirleyin, her alan için yüksek kaliteli veri kümeleri toplayın ve bunları birleştirin. Ancak gerçek daha karmaşıktır, çünkü bazı alanlar eğitim bütçesi için birbirleriyle rekabet edebilir. Kodlama gibi belirli bir yeteneğe odaklanırken, görevle ilgili veriyi (örneğin kaynak kodu) daha fazla ağırlıklandırmak cazip olabilir. Ancak bir kaynağı fazla ağırlıklandırmak, diğer tüm kaynakların ağırlığını dolaylı olarak azaltır ve bu da modelin başka alanlardaki performansını zedeleyebilir. Bu nedenle farklı kaynakların birlikte eğitilmesi, downstream yetenekler arasında bir denge kurmayı gerektirir.

Buna ek olarak, tüm bu kaynaklar ve alanlar arasında genellikle modelin yeteneklerini artırmada özellikle faydalı olan bir “yüksek kaliteli” veri alt kümesi vardır. Peki neden düşük kaliteli veriyi tamamen atıp sadece en kaliteli verilerle eğitmiyoruz? Büyük bir eğitim bütçesine sahip bir modelde (örneğin SmolLM3’ün 11T token ölçeği), aşırı filtreleme yapmak verinin çok sık tekrar edilmesine yol açar. Önceki çalışmalar bu tür tekrarların zararlı olabileceğini göstermiştir (Muennighoff et al., 2025), bu yüzden ideal olarak hem yüksek hem düşük kaliteli veriyi kullanarak model performansını maksimize etmeliyiz.

Veriyi kaynaklar arasında dengelemek ve yeterince yüksek kaliteli veri sağlamak için, her kaynaktan gelen eğitim dokümanlarının göreli oranı karışımını dikkatle tasarlamamız gerekir. Bir dil modelinin belirli bir görev veya alandaki performansı, o görevle ilgili ne kadar veri gördüğüne güçlü biçimde bağlı olduğundan, karışım ağırlıklarını ayarlamak modelin yeteneklerini alanlar arasında dengelemenin doğrudan bir yoludur. Bu ödünleşimler modele bağlıdır ve tahmin edilmesi zordur, bu yüzden ablasyon çalışmaları kritik önemdedir.

Ayrıca karışım eğitim boyunca sabit kalmak zorunda değildir. Eğitim ilerledikçe karışımı ayarlayarak, buna çok aşamalı ya da müfredat (curriculum) eğitimi diyoruz, hem yüksek kaliteli hem de düşük kaliteli veriyi daha verimli kullanabiliriz.

Eğitim Müfredatlarının Evrimi

Büyük dil modeli eğitiminin ilk dönemlerinde standart yaklaşım, tüm eğitim boyunca tek bir sabit veri karışımı kullanmaktı. GPT-3 ve erken Llama sürümleri gibi modeller eğitim başından sonuna kadar statik bir karışımla eğitildi. Daha yakın zamanda ise alan, çok aşamalı bir yaklaşıma (Allal et al., 2025) kaydı; burada veri karışımı eğitim süreci boyunca değişir. Bunun temel motivasyonu, bir dil modelinin nihai davranışının eğitim sonunda gördüğü veriden güçlü şekilde etkilenmesidir (Y. Chen et al., 2025b). Bu içgörü pratik bir stratejiye dönüşür: eğitim başında daha bol kaynakları ağırlıklandırmak ve eğitim sonunda daha küçük ama yüksek kaliteli kaynakları karışıma eklemek.

Sık sorulan bir soru şudur: Karışımı ne zaman değiştireceğinize nasıl karar verirsiniz? Evrensel bir kural yoktur, ancak genelde şu prensipleri izleriz:

Performans odaklı müdahaleler: Önemli benchmark’larda değerlendirme metriklerini izleyin ve veri kümesi karışımını belirli yetenek darboğazlarını giderecek şekilde uyarlayın. Örneğin matematik performansı diğer yetenekler gelişirken duraklıyorsa, bu daha yüksek kaliteli matematik verisi eklemek için bir sinyaldir.

Yüksek kaliteli veriyi son aşamalar için saklama: Küçük ve yüksek kaliteli matematik ve kod veri kümeleri, annealing (tavlama) aşamasında (son aşama, öğrenme oranı düşerken) en etkili şekilde kullanılır.

Artık karışımların neden önemli olduğunu ve müfredatların nasıl çalıştığını ele aldığımıza göre, şimdi her ikisinin nasıl ayarlanacağını tartışalım.

Ablasyon Kurulumu: Veri Tariflerini Sistematik Olarak Test Etme

Veri karışımlarını test ederken kullandığımız yaklaşım, mimari ablasyonları nasıl yürüttüğümüze benzer; tek fark, bunları hedef model ölçeğinde yapmaya çalışmamızdır. Küçük ve büyük modellerin kapasite farkları vardır. Örneğin çok küçük bir model birçok dili desteklemekte zorlanabilirken, daha büyük bir model performansını başka alanlarda düşürmeden bunları daha kolay “özümseyebilir”. Bu nedenle ablasyonları aşırı küçük ölçekte yapmak, optimum karışım hakkında yanlış sonuçlara varma riskini taşır.

SmolLM3 için ana veri ablasyon çalışmalarını doğrudan 3B model üzerinde yürüttük ve 50B ile 100B token’lık daha kısa eğitimleri tercih ettik. Ayrıca farklı bir ablasyon türü daha kullandık: annealing (tavlama) deneyleri. Bu yaklaşımda modeli sıfırdan farklı karışımlarla eğitmek yerine, ana eğitim koşusundan ara bir checkpoint aldık (örneğin 7T token noktasında) ve eğitimi değiştirilmiş veri bileşimleriyle sürdürdük. SmolLM2, Llama 3 ve OLMo 2 gibi yakın tarihli çalışmalarda da kullanılan bu yöntem, çok aşamalı eğitim için veri karışımı değişikliklerini test etmeyi mümkün kılar.

Değerlendirme tarafında ise benchmark kümemizi genişlettik: standart İngilizce değerlendirmelerine ek olarak çokdilli görevleri de dahil ettik. Böylece farklı dil oranları arasındaki ödünleşimleri daha doğru şekilde ölçebildik.

Son çalışmalar, optimal veri oranlarını bulmak için otomatik yaklaşımlar önermiştir. Örneğin:

• DoReMi (Xie et al., 2023), doğrulama kaybını (validation loss) en aza indirmek için alan ağırlıklarını öğrenen küçük bir proxy model kullanır.
• RHO-LOSS (Mindermann et al., 2022), holdout loss’a göre bireysel eğitim noktalarını seçer; öğrenilebilir, görevle ilgili ve model tarafından henüz öğrenilmemiş örneklere öncelik verir.
• RegMix (Q. Liu et al., 2025), birden fazla değerlendirme hedefi ve veri alanı arasında denge kuran regularized regression ile optimal veri karışım oranlarını belirler.

Biz DoReMi ve RHO-LOSS’u önceki projelerde denedik, ancak genellikle veri kümesi boyutlarının doğal dağılımını kabaca yansıtan dağılımlara yakınsamaya eğilimli olduklarını gözlemledik, yani elinizde ne varsa ondan daha fazla kullanmayı önerir hale geliyorlar. Teorik olarak çekici olsalar da, bizim kurulumumuzda dikkatli manuel ablasyon çalışmalarını geçemediler. Güncel SOTA modeller hâlâ SmolLM3’te de benimsediğimiz yaklaşım olan sistematik ablasyon ve annealing deneyleriyle manuel karışım ayarlamasına dayanıyor.

SmolLM3: Veri Karışımını Kürate Etme

SmolLM3 için hedefimiz, hem İngilizce hem çok dilli içerikleri işleyebilen ve özellikle matematik ile kodlama alanlarında güçlü performans sergileyen bir model geliştirmekti. Bu içerik türleri çoğu LLM’de zaten yaygındır; ancak burada anlatılan yöntem, düşük kaynaklı bir dil veya finans ya da sağlık gibi belirli bir alan için model eğitirken de aynı şekilde uygulanabilir. Yöntem değişmez: iyi aday veri setlerini belirlemek, ablasyon çalışmaları yapmak ve tüm hedef alanları dengeleyen bir karışım tasarlamak.

Bu bölümde yüksek kaliteli veri kümelerinin nasıl oluşturulduğuna tekrar girmeyeceğiz, çünkü bunu önceki çalışmalarımızda zaten ayrıntılı şekilde ele aldık. Bunun yerine odak noktamız, bu veri kümelerini etkili bir ön-eğitim karışımına nasıl birleştirdiğimizdir.

Kanıtlanmış Temeller Üzerine İnşa Etmek

Ön-eğitim verisi söz konusu olduğunda iyi haber şu ki çoğu zaman sıfırdan başlamak zorunda değiliz. Açık kaynak topluluğu, yaygın alanların çoğu için zaten güçlü veri kümeleri oluşturmuş durumda. Bazen yeni veri üretmemiz gerekebiliyor, FineWeb, FineMath gibi “Fine” serilerinde yaptığımız gibi, ancak çoğu durumda asıl zorluk yeni veri icat etmek değil, mevcut kaynakları seçmek ve doğru şekilde birleştirmektir.

SmolLM3’te durumumuz da buydu. SmolLM2, 1.7B parametre ölçeğinde İngilizce web verisi için güçlü bir reçete oluşturmuş ve elimizdeki en iyi matematik ve kod veri kümelerini belirlemişti. Bizim hedefimiz bu başarıyı 3B parametre ölçeğine taşırken aynı zamanda güçlü çokdillilik, daha iyi matematik akıl yürütme ve daha güçlü kod üretimi gibi yeni yetenekler eklemekti.

Kod Verisi

Stage 1 için kullandığımız kod kaynakları, StarCoder2 ve The Stack v2 eğitim korpusundan çıkarıldı. Şunları dahil ettik:

• The Stack v2 (16 dil) temel veri kaynağımızdı ve StarCoder2Data olarak filtrelendi
• Gerçek dünya kod inceleme (code review) akıl yürütmesini temsil eden StarCoder2 GitHub pull request’leri
• Çalıştırılabilir, adım adım iş akışları sunan Jupyter ve Kaggle notebook’ları
• Kod etrafındaki bağlamı sağlayan tartışmaları içeren GitHub issue’ları ve Stack Exchange thread’leri

Aryabumi et al. (2024), kod verisinin dil modellerini yalnızca kodlama konusunda değil, aynı zamanda doğal dil akıl yürütme ve dünya bilgisi gibi alanlarda da geliştirdiğini ve eğitim karışımında %25 kod kullanılmasını önerdiğini gösteriyor. Bu nedenle ablasyon çalışmalarına karışımda %25 kod ile başladık.

Ancak bu ayarda HellaSwag, ARC-C ve MMLU gibi İngilizce karşılaştırma ölçütlerinde belirgin bir düşüş gözlemledik. Kod oranını %10’a düşürdüğümüzde ise İngilizce benchmark kümemizde %0 kod kullanılan duruma kıyasla anlamlı bir iyileşme görmedik. Buna rağmen, kod üretimi model için kritik bir yetenek olduğundan bu veriyi yine de karışıma dahil ettik.

Eğitim sürecinde yüksek kaliteli veri kullanımını en etkili hale getirmek için Stack-Edu (StarCoder2Data’nın eğitimsel olarak filtrelenmiş alt kümesi) verisini erken aşamada değil, daha sonraki aşamalara erteledik. Bu, yüksek kaliteli veriyi eğitim sonuna yakın kullanma ilkesine dayanıyordu.

Matematik Verisi

Matematik verisi için de benzer bir yaklaşım izledik. İlk aşamalarda daha büyük ve genel veri kümeleri olan FineMath3+ ve InfiWebMath3+ kullandık. Daha sonra FineMath4+ ve InfiWebMath4+ veri kümelerini daha fazla örnekleyerek (upsampling) ağırlıklarını artırdık ve ayrıca birkaç yeni yüksek kaliteli veri kümesi ekledik:

• MegaMath (Zhou et al., 2025)
• OpenMathInstruct (Toshniwal et al., 2024) ve OpenMathReasoning (Moshkov et al., 2025) gibi instruction ve reasoning veri kümeleri

Stage 1’de matematik verisini %3 oranında kullandık ve bunu FineMath3+ ile InfiWebMath3+ arasında eşit olarak böldük. Toplamda yalnızca 54B token kullanabildiğimiz ve Stage 1’in 8T–9T token ölçeğinde olduğu düşünüldüğünde, daha yüksek oranlar kullanmak veri üzerinde beşten fazla epoch anlamına gelecekti.

Yeni Aşamalar İçin Doğru Karışımı Bulmak

Stage 1 için en iyi karışımı sıfırdan yapılan ablasyonlarla belirlerken, sonraki aşamalar için (bizim durumda iki ek aşama) yeni veri kümelerini test etmek amacıyla annealing ablasyonu kullandık. Stage 1’in geç döneminden (yaklaşık 7T token) bir checkpoint alıp 50B token’lık annealing deneyleri yaptık.

Bu deneylerde kullanılan kurulum şöyleydi:

• %40 baseline mixture: Stage 1 boyunca kullanılan mevcut karışım
• %60 yeni dataset: değerlendirmek istediğimiz aday veri kümesi

Örneğin MegaMath’ın matematik performansını iyileştirip iyileştirmediğini test etmek için şu karışımı kullandık: %40 Stage 1 verisi (75/12/10/3 domain dağılımını koruyarak) + %60 MegaMath verisi.

Tüm üç aşamanın veri kompozisyon detaylarını bir sonraki bölümde bulacaksınız.

Veriyi dikkatlice kürate edip ablasyonlarla karışımı doğruladıktan sonra, artık gerçek eğitim sürecine başlamaya hazırdık. Bundan sonrası SmolLM3’ün bir ay süren eğitim yolculuğunun hikâyesi: hazırlıklar, beklenmeyen zorluklar ve süreç boyunca öğrenilen dersler.

6. Eğitim Maratonu

Buraya kadar gelmeyi başardığın için tebrikler, asıl eğlence şimdi başlıyor!

Bu noktada her şey yerli yerine oturmuş durumda: doğrulanmış bir mimari, finalize edilmiş bir veri karışımı ve ayarlanmış hiperparametreler. Geriye kalan tek şey altyapıyı kurmak ve “train” butonuna basmak.

SmolLM3 için 384 H100 GPU (48 düğüm) üzerinde yaklaşık bir ay boyunca eğitim yaptık ve 11 trilyon token işledik. Bu bölüm, uzun bir eğitim çalışması sırasında gerçekte neler olduğunu adım adım anlatıyor: ön kontroller (preflight checks), kaçınılmaz sürprizler ve sistemi nasıl stabil tuttuğumuz. Sağlam ablasyon (çıkarım/deney) pratiklerinin ve güvenilir altyapının neden kritik olduğunu ilk elden göreceksiniz. GPU donanımı, depolama sistemleri ve işlem verimini optimize etmeye dair teknik altyapı detaylarını son bölümde ele alıyoruz.

Ekibimiz bu süreçten birçok kez geçti: StarCoder ve StarCoder2’den SmolLM, SmolLM2 ve şimdi de SmolLM3’e kadar. Her bir eğitim çalışması farklıdır. Onlarca model eğitmiş olsan bile, her yeni koşu seni şaşırtmanın yeni bir yolunu bulur. Buradaki amacımız, bu sürprizlere hazır olman için başarı şansını kendi lehine nasıl artırabileceğini göstermektir.

Eğitim Başlamadan Önce Kontrol Listesi: Başlamadan Önce Neleri Doğrulamalı

“Train”e basmadan önce, her şeyin uçtan uca düzgün çalıştığından emin olmak için bir kontrol listesi uygularız. Bu şunları içerir:

Altyapı hazırlığı:

• Kümeniz “Slurm” rezervasyonlarını destekliyorsa, bunları kullan. SmolLM3 için tüm çalışma boyunca sabit 48 düğümlük bir rezervasyonumuz vardı. Bu, kuyruk gecikmelerinin olmaması, tutarlı işlem verimi ve düğüm sağlığını zaman içinde izleyebilme anlamına geliyordu.
• Başlatmadan önce GPU’ları stres testinden geçirin (GPU Fryer ve DCGM Diagnostics kullanıyoruz), throttling (hız düşmesi) veya performans düşüşünü yakalamak için. SmolLM3’te iki GPU’nun throttling yaptığını tespit ettik ve çalışmayı başlatmadan önce bunları değiştirdik.
• Depolama şişmesini önleyin. Sistemimiz her checkpoint’i S3’e yükler ve bir sonrakini kaydettikten hemen sonra yerel kopyayı siler; böylece hızlı yerel SSD’lerde hiçbir zaman birden fazla kopya tutmayız.

Değerlendirme kurulumu:

Değerlendirmeler aldatıcı derecede zaman alıcıdır. Bunları manuel çalıştırmak, sonuçları loglamak ve grafikler üretmek saatler sürebilir. Mümkünse tamamen otomatikleştirin ve eğitim başlamadan önce düzgün çalışıp logladığından emin olun. SmolLM3’te her kaydedilen checkpoint otomatik olarak kümede bir değerlendirme işini tetikler ve sonuçlar Wandb ve Trackio’ya loglanır.

Checkpoint ve otomatik devam sistemi:

Checkpoint’lerin doğru kaydedildiğini ve eğitim işinin manuel müdahale olmadan son checkpoint’ten devam edebildiğini doğrulayın. Slurm üzerinde başarısız bir işin otomatik yeniden başlatılması ve en son checkpoint’ten devam etmesi için, requeue seçeneğini kullanıyoruz.

Metrik loglama:

İlgili tüm metrikleri logladığınızdan emin olun: değerlendirme skorları, throughput (token/saniye), eğitim kaybı, gradient normu, düğüm sağlığı (GPU kullanım oranı, sıcaklık, bellek kullanımı) ve çalışmaya özel diğer debug metrikleri.

Eğitim konfigürasyonu kontrolü:

Eğitim config dosyanızı, başlatma scriptlerinizi ve Slurm submit komutlarınızı iki kez kontrol edin.

Altyapı derin incelemesi

GPU testleri, depolama karşılaştırma ölçütlerini, izleme kurulumu ve dayanıklı eğitim sistemleri kurma konusunda ayrıntılı rehber için Altyapı bölümüne bakın.

Ölçekleme Sürprizleri

SmolLM3 için kapsamlı ablasyon çalışmaları yaptıktan sonra, tam ölçekli çalışmaya hazırdık. 100B token üzerinde yaptığımız 3B model ablasyonları umut verici görünüyordu. SmolLM2’ye kıyasla yapılan mimari değişiklikler (“Mimari Seçimler”: GQA, NoPE, doküman masking, tokenizer bölümünde detaylandırılmıştır) ya performansı iyileştirdi ya da en azından korudu. Ayrıca İngilizce, çok dilli metin, kod ve matematik performansını dengeli şekilde optimize eden iyi bir veri karışımı bulmuştuk (“SmolLM3: Veri Karışımının Kürasyonu” bölümüne bakınız). 384 GPU (48 düğüm) üzerinde yaklaşık %30 model FLOPs kullanımı (MFU) hedefiyle yapılandırmamızı optimize ettik.

Eğitim başlamadan önce, throughput’u doğrulamak için 48 düğüm üzerinde bazı ablasyon testleri çalıştırdık. Bu testlerin daha fazla detayı Altyapı bölümünde bulunabilir.

Büyük çalışmaya hazırdık: 11T token. Tam o anda gerçeklik beklenmedik sürprizler çıkarmaya başladı.

Gizem #1: Kaybolan Throughput

Başlatmadan birkaç saat sonra throughput aniden düştü. Bu keskin bir düşüştü ve tekrar eden ani sıçramalarla devam ediyordu.

Neden throughput önemli?

Throughput, eğitim sırasında sistemimizin saniyede kaç token işleyebildiğini ölçer. Eğitim süresini doğrudan belirler — %50’lik bir throughput düşüşü, bir aylık çalışmayı iki aya çıkarabilir. Altyapı bölümünde, SmolLM3 çalışmasını başlatmadan önce throughput’u nasıl optimize ettiğimizi ayrıntılı olarak göstereceğiz.

Bu, herhangi bir ablasyon çalışmasında yaşanmamıştı; peki ne değişmişti? Üç şey vardı:

• Eğitim veri kümelerinin boyutu. Ablasyonlarda kullandığımız daha küçük alt kümeler yerine artık ~24 TB’lık tam eğitim veri kümesini kullanıyorduk; ancak veri kaynakları aynıydı.
• Eğitim adımı sayısı. 100B token’lık kısa ablasyon süresi yerine 11T token için gerçek adım sayısını çalıştırıyorduk.
• Olası donanım durumu. Ablasyon sırasında sorunsuz çalışan GPU’lar, uzun süreli yük altında arızalanabilir ya da ağ bağlantıları bozulabilirdi.

Bunların dışında her şey birebir aynıydı: düğüm sayısı, dataloader yapılandırması, model yerleşimi, paralellik kurulumu…

Sezgisel olarak ne veri kümesi boyutu ne de adım sayısı throughput düşüşüne neden olmamalıydı; bu yüzden doğal olarak önce donanım sorunlarından şüphelendik. Düğüm izleme metriklerini kontrol ettiğimizde, büyük throughput düşüşünün disk okuma gecikmesi (disk read latency) artışlarıyla korele olduğunu gördük. Bu da bizi doğrudan veri depolama katmanına götürdü.

Kümedeki depolama seçenekleri

Kümemizde eğitim verisi için üç farklı depolama katmanı var:

• FSx: Weka kullanan ağ tabanlı depolama. “Sıcak tutma (keep-hot)” önbellek modeliyle çalışır; sık kullanılan dosyaları yerelde tutar, kapasite doldukça “soğuk” dosyaları S3’e taşır.
• Scratch (Yerel NVMe RAID): Her düğümde bulunan hızlı yerel depolama (8 × 3.5 TB NVMe disk RAID). FSx’ten daha hızlıdır ancak sadece yerel düğüm tarafından erişilebilir.
• S3: Soğuk veri ve yedekler için uzak nesne depolama.

Detaylar Altyapı bölümünde bulunabilir.

SmolLM3’ün 24 TB’lık veri kümesi için başlangıçta veriyi FSx (Weka) üzerinde tuttuk. Ancak 24 TB eğitim verisine ek olarak diğer ekiplerin de kullandığı depolama yüküyle birlikte Weka sınırlarına yaklaşıyorduk. Sistem, eğitim sırasında veri shard’larını “evict” etmeye (yerinden atmaya) başladı; bu da onları yeniden çekmek zorunda kalmamıza neden oldu ve beklemelere yol açtı. Bu durum da büyük throughput düşüşünü açıklıyordu.

Çözüm #1: Veri depolamasını değiştirmek

Weka üzerinde veri klasörlerini tüm eğitim boyunca “hot” olarak sabitlemenin bir yolunu bulamayınca depolama yöntemini değiştirmeye karar verdik. Veriyi doğrudan S3’ten stream etmek yavaştı, bu yüzden veriyi her düğümün yerel scratch diskine taşımaya karar verdik.

Ancak bunun bir bedeli vardı: Bir düğüm ölür ve yerine yenisi gelirse, yeni GPU’larda veri bulunmuyordu. S3’ten 24 TB veriyi s5cmd ile indirmek 3 saat sürüyordu. Aynı datacenter içinde oldukları için S3 üzerinden gitmek yerine sağlıklı bir düğümden kopyalayarak fpsync ile bunu 1,5 saate indirdik. Bu yöntem daha hızlıydı çünkü tüm düğümler aynı veri merkezindeydi.

Yine de sorun vardı: Her node arızasında 1,5 saatlik kesinti ve yeni node’a veriyi manuel kopyalama zorunluluğu oldukça zahmetliydi. Sonunda bunu katlanılabilir hale getiren çözüm, Slurm rezervasyonunda önceden veri yüklenmiş yedek bir düğüm ayırmak oldu. Bir node düştüğünde, onu anında bu yedek node ile değiştiriyorduk; böylece kurtarma gecikmesi sıfıra indi. Yedek node boşta kaldığında ise eval veya geliştirme işlerini çalıştırarak boşa gitmesini engelliyorduk. Bu şekilde birinci gizemi çözdüğümüzü düşünüyoruz.

Gizem #2 : Kalıcı throughput düşüşleri

Veriyi scratch’a taşıdıktan sonra bile bireysel throughput düşüşleri devam ediyordu; ancak donanım izleme metriklerinde herhangi bir anormallik yoktu. Aşağıdaki grafik, depolama sorununu çözdükten sonra (turuncu) elde edilen throughput ile ablation’lar sırasında (mavi) elde edilen throughput’u karşılaştırıyordu. Gördüğümüz üzere düşüşler aslında daha da keskin hale gelmişti.

Hâlâ donanımdan şüphelendiğimiz için daha az sayıda düğüm üzerinde test yapmaya karar verdik. 384 GPU ile çalışırken herhangi bir bileşenin arızalanma ihtimali oldukça yüksektir. Ancak şaşırtıcı şekilde, hangi düğümü test edersek edelim aynı throughput düşüşlerini yalnızca tek bir düğüm üzerinde bile yeniden üretebildik. Bu durum donanım kaynaklı bir sorunu büyük ölçüde dışladı.

Ablation çalışmalarından bu yana değişen üç şeyi hatırlayın. Veri depolama sorununu veriyi yerel düğüm depolamasına taşıyarak zaten çözmüştük. Donanım ihtimali de artık elenmişti. Geriye yalnızca tek bir değişken kalıyordu: adım sayısı (step count).

Bunu test etmek için adım sayısını küçülttük (3 milyon adımdan 32 bine kadar geri çekerek). Sonuç ilginçti: throughput düşüşleri de küçülmeye başladı. Adım sayısı büyüdükçe düşüşler daha keskin ve daha sık hale geliyordu.

Başka bir deyişle, eğitimin toplam süresi için belirlenen daha büyük step count değerleri, throughput davranışını doğrudan etkiliyor gibi görünüyordu.

Aşağıda, diğer tüm ayarlar aynı kalacak şekilde kullandığımız tam yapılandırmalar yer alıyor:

## Short run (32k steps)
- "lr_decay_starting_step": 2560000
- "lr_decay_steps": 640000
- "train_steps": 3200000

## Long run (3.2M steps)
+ "lr_decay_starting_step": 26000
+ "lr_decay_steps": 6000
+ "train_steps": 32000

Sonuçlar, aşağıdaki şekilde gösterildiği gibi açıktı: Daha kısa çalıştırmalar küçük throughput düşüşleri üretirken, daha uzun step count değerleri daha keskin ve daha sık düşüşler üretiyordu. Dolayısıyla sorun donanım değil, bir yazılım darboğazıydı — ve büyük olasılıkla dataloader tarafındaydı; çünkü eğitim sürecindeki diğer bileşenlerin çoğu, step count’tan bağımsız olarak her batch’i aynı şekilde işler.

İşte o zaman Nanotron’un veri yükleyicisiyle (dataloader) aslında hiç büyük ölçekli ön eğitim (pretraining) yapmadığımızı fark ettik. SmolLM2, Nanotron etrafına yazılmış dahili bir sarmalayıcı (wrapper) üzerinden, Megatron-LM’den türetilmiş bir veri yükleyici (TokenizedBytes) kullanılarak ve istikrarlı bir veri aktarım hızıyla (throughput) eğitilmişti. SmolLM3 için ise Nanotron’un yerleşik veri yükleyicisine (nanosets) geçiş yapmıştık.

Uygulamasını derinlemesine incelediğimizde, her eğitim adımında büyümeye devam eden tek ve devasa bir indeks oluşturduğunu gördük. Eğitim adımları çok büyüdüğünde bu durum, paylaşımlı bellek kullanımının artmasına yol açıyor ve sonuç olarak veri aktarım hızında düşüşler meydana geliyordu.

Düzeltme #2: TokenizedBytes Veri Yükleyicisini Getirmek

Sorunun gerçekten veri yükleyicisinden kaynaklandığını doğrulamak için, aynı yapılandırmayı TokenizedBytes veri yükleyicisini kullanan dahili SmolLM2 altyapımız üzerinde çalıştırdık. Aynı veri kümeleriyle 48 düğüm (node) üzerinde hiçbir performans düşüşü yaşanmadı.

İleriye dönük en hızlı çözüm açıktı: Bu veri yükleyiciyi Nanotron’a kopyalamak.

Bunu yaptığımızda performans düşüşleri ortadan kalktı ve veri aktarım hızı yeniden hedef seviyesine ulaştı.

Yeniden eğitimi başlatmaya hazırdık… ta ki bir sonraki sürprizle karşılaşana kadar.

Gizem #3: Gürültülü Kayıp (Loss)

Yeni veri yükleyiciyle artık performans düşüşleri yaşamıyorduk, ancak kayıp (loss) eğrisi daha gürültülü görünüyordu.

nanosets, daha pürüzsüz bir kayıp eğrisi üretiyordu ve bu fark bize eski bir hata ayıklama savaşını hatırlattı: Birkaç yıl önce, ön eğitim kodumuzda bir karıştırma (shuffling) hatası bulmuştuk. Belgeler karıştırılıyor ancak bir grup (batch) içindeki diziler (sequence) karıştırılmıyordu. Bu da küçük kayıp sıçramalarına neden oluyordu.

Yeni veri yükleyicimizi kontrol ettiğimizde bunu doğruladık: Her belgedeki dizileri sıralı olarak okuyordu. Kısa dosyalar için bu sorun yaratmaz, ancak kod gibi alanlarda tek bir uzun ve düşük kaliteli dosya tüm bir batch’i doldurabilir ve kayıp sıçramalarına yol açabilir.

Düzeltme #3 — Dizi (Sequence) Düzeyinde Karıştırma

Önümüzde iki seçenek vardı:

1. Veri yükleyiciyi rastgele erişim (random access) yapacak şekilde değiştirmek (risk: daha yüksek bellek kullanımı).
2. Tokenize edilmiş dizileri çevrimdışı (offline) olarak önceden karıştırmak.

Eğitimi başlatma baskısı ve küme (cluster) rezervasyonumuzun devam ediyor olması nedeniyle, daha güvenli ve hızlı çözüm olarak ikinci seçeneği tercih ettik.

Tokenize edilmiş veriler zaten her düğümde bulunduğundan, yerel olarak yeniden karıştırma işlemi ucuzdu (yaklaşık 1 saat sürdü). Her dönem (epoch) için farklı rastgele tohumlar (seed) kullanarak karıştırılmış diziler ürettik; böylece dönemler arasında aynı karıştırma düzenlerinin tekrar edilmesini önledik.

Ne Zaman Yama Yapmalı, Ne Zaman Kalıcı Düzeltme Yapmalı?

Acil teslim tarihleriyle karşı karşıya kaldığınızda, bozuk uygulamanızı hata ayıklamaya çalışmak yerine kanıtlanmış bir çözümü veya hızlı bir geçici çözümü benimsemek daha hızlı olabilir. Daha önce, nanosets içindeki indeksleme uygulamasını düzeltmek yerine TokenizedBytes veri yükleyicisini sisteme entegre etmiştik. Burada da veri yükleyicide değişiklik yapmak yerine çevrimdışı ön karıştırmayı tercih ettik.

Ancak çok fazla kısa yol kullanmamaya dikkat edin; aksi takdirde bakımını yapmak ve optimize etmek zor olan, yamalarla dolu bir sisteme sahip olursunuz.

Yeniden Başlatma, İkinci Deneme

Bu noktada elimizde şunlar vardı:

• Kararlı veri aktarım hızı (scratch depolama + yedek düğüm stratejisi)
• Adım sayısına bağlı performans düşüşlerinin ortadan kaldırılması (TokenizedBytes veri yükleyicisi)
• Temiz, dizi (sequence) düzeyinde karıştırma (her epoch için çevrimdışı ön karıştırma)

Eğitimi yeniden başlattık.

Bu kez her şey yolunda gitti. Kayıp eğrisi düzgündü, veri aktarım hızı tutarlıydı ve sonunda yangın söndürmek yerine eğitime odaklanabildik.

Gizem #4: Tatmin Edici Olmayan Performans

İlk iki gün boyunca eğitim sorunsuz ilerledi. Günlüklerde (loglarda) herhangi bir probleme işaret eden hiçbir şey yoktu. Ancak yaklaşık 1 trilyon (1T) token seviyesine ulaşıldığında değerlendirme sonuçları beklenmedik bir durum ortaya çıkardı.

İzleme sürecimizin bir parçası olarak ara kontrol noktalarını (checkpoints) değerlendiriyor ve bunları geçmiş çalıştırmalarla karşılaştırıyoruz. Örneğin, benzer bir eğitim reçetesiyle eğitilmiş SmolLM2 (1.7B) modelinin ara kontrol noktalarına sahiptik; böylece her iki modelin de eğitimin aynı aşamalarında nasıl ilerlediğini takip edebiliyorduk.

Sonuçlar kafa karıştırıcıydı:

Daha fazla parametreye ve daha iyi bir veri karışımına sahip olmasına rağmen, 3B model aynı eğitim aşamasında 1.7B modelden daha kötü performans gösteriyordu.

Kayıp değeri düşmeye devam ediyor ve kıyaslama (benchmark) skorları iyileşiyordu, ancak iyileşme hızı beklentilerin belirgin şekilde altındaydı.

SmolLM2'ye kıyasla SmolLM3'te yapılan tüm mimari ve veri değişikliklerini kapsamlı şekilde test ettiğimiz için dikkatimizi eğitim altyapısına çevirdik. İki eğitim kurulumunda henüz test edilmemiş yalnızca birkaç fark kalmıştı.

Bunların en belirgini tensor parallelism (TP) idi:

• SmolLM2 tek bir GPU’ya sığabiliyor ve TP kullanılmadan eğitiliyordu.
• SmolLM3 ise belleğe sığabilmek için TP=2 gerektiriyordu.

Daha önce bunu test etmeyi düşünmemiştik; çünkü TP, 3B ablasyon deneylerinde kullanılmıştı ve sonuçlar mantıklı görünüyordu.

Düzeltme #4 : Son Düzeltme

TP hatası hipotezini test etmek için, SmolLM3 ile tamamen aynı kurulumda bir 1.7B model eğittik:

• Aynı mimari değişiklikler (document masking, NoPE)
• Aynı veri karışımı
• Aynı hiperparametreler

Bunu hem TP ile hem de TP olmadan gerçekleştirdik.

Fark hemen ortaya çıktı:

TP kullanılan sürüm sürekli olarak daha yüksek kayıp değerine ve daha düşük aşağı-akış (downstream) performansına sahipti.

Bu da sorunun TP ile ilişkili bir hata olduğunu doğruladı.

Daha sonra TP uygulamasını ayrıntılı olarak inceledik ve TP ile TP olmayan çalıştırmalardaki ağırlıkları karşılaştırdık.

Sorun ince ama önemliydi:

Tüm TP sıralarında (rank) aynı rastgele tohumları (random seeds) kullanıyorduk; oysa her sıranın farklı bir tohumla başlatılması gerekiyordu.

Bu durum, parçalar (shards) arasında korelasyonlu ağırlık başlangıçlarına (weight initialization) yol açıyordu ve yakınsamayı (convergence) olumsuz etkiliyordu.

Etkisi felaket düzeyinde değildi; model yine de eğitiliyor ve gelişiyordu. Ancak ortaya çıkan verimsizlik, büyük ölçekte gözlemlediğimiz performans farkını açıklamaya yetecek kadar büyüktü.

İşte hata düzeltmesi:

diff --git a/src/nanotron/trainer.py b/src/nanotron/trainer.py
index 1234567..abcdefg 100644
--- a/src/nanotron/trainer.py
+++ b/src/nanotron/trainer.py
@@ -185,7 +185,10 @@ class DistributedTrainer:
     ):
         # Set random states
-        set_random_seed(self.config.general.seed)
+        # Set different random seed for each TP rank to ensure diversity
+        tp_rank = dist.get_rank(self.parallel_context.tp_pg)
+        set_random_seed(self.config.general.seed + tp_rank)

+

TP rank’lerinin her birinin farklı bir seed kullanmasını sağlayacak şekilde seed’leri sabitledikten sonra, ablasyon deneylerini yeniden tekrarladık ve TP ile TP olmayan çalıştırmaların artık hem kayıp eğrileri hem de aşağı akış performansı açısından eşleştiğini doğruladık. Başka gizli sorunlar olmadığından emin olmak için ek sağduyu (sanity) kontrolleri gerçekleştirdik: 3B parametreli SmolLM2 tarzı (mimari ve veri açısından) bir çalıştırma ve ayrıca yine 3B parametreli ayrı bir SmolLM3 çalıştırması yaparak her ikisini SmolLM2’nin kontrol noktalarıyla karşılaştırdık. Sonuçlar artık beklentilerle uyumlu hale geldi: 1.7B SmolLM2, 3B SmolLM2 varyantından daha kötü performans gösterdi ve bu varyant da SmolLM3–3B tarafından geçildi.

Bu hata ayıklama süreci, daha önce vurguladığımız temel ilkelerden birini yeniden pekiştirdi: “Sağlam bir ablasyon kurulumunun gerçek değeri yalnızca iyi bir model inşa etmenin ötesine geçer. Ana eğitim çalışmamız sırasında işler ters gittiğinde (ve ne kadar hazırlıklı olursak olalım mutlaka gidecektir), verdiğimiz her karardan emin olmak ve hangi bileşenlerin yeterince test edilmediğini ve soruna neden olabileceğini hızlıca tespit edebilmek isteriz. Bu hazırlık, hata ayıklama süresini azaltır ve gelecekteki zihinsel sağlığımızı korur.”

Belirsiz bir eğitim hatasına bakıp sorunun nerede gizlendiğine dair hiçbir fikre sahip olmaktan daha kötü bir şey yoktur. Eğitim kurulumumuzdaki diğer tüm bileşenler doğrulanmış olduğu için, TP’yi tek makul neden olarak tespit edebildik ve performans farkını fark ettikten sonra hatayı tek bir gün içinde düzelttik.

Bununla birlikte, lansmandan bu yana ortaya çıkan beklenmedik sorunlar zincirinin sonuncusunu da çözmüş olduk. Üçüncüde olur: O noktadan sonra ayın geri kalanındaki eğitim süreci görece olaysız geçti — trilyonlarca token’ı bitmiş bir modele dönüştürmenin istikrarlı işi, zaman zaman node arızaları nedeniyle yapılan yeniden başlatmalarla bölündü.

Rotayı Sürdürmek

Önceki bölümün gösterdiği gibi, ablasyonlardan tam ölçekli pretraining’e geçiş sadece “tak ve çalıştır” bir süreç değildi. Beklenmedik zorluklar getirdi, ancak her birini başarıyla tespit edip çözdük. Bu bölüm, büyük ölçekli eğitim çalışmaları için gerekli izleme kurulumunu ve kritik hususları ele alıyor. Şu temel sorulara yanıt vereceğiz: Bir sorunla karşılaşıldığında eğitimi ne zaman yeniden başlatmalısınız? Run’ın çok ilerisine sarkmış problemleri nasıl ele alırsınız? Hangi metrikler gerçekten önemlidir? Eğitim boyunca sabit bir veri karışımı mı korumalısınız?

Eğitim İzleme: Kayıp Eğrilerinin Ötesi

TP (tensor parallelism) hatasını yakalamamızın nedeni kayıp eğrisi değildi; çünkü eğri gayet normal görünüyordu. Asıl belirleyici olan, downstream değerlendirmelerin beklenenin gerisinde kalmasıydı. Ayrıca SmolLM2’nin ara checkpoint’lerinden yapılan değerlendirmeler kritik bir rol oynadı; çünkü 3B modelin doğru yolda olmadığını erken bir aşamada fark etmemizi sağladılar. Dolayısıyla, büyük modeller eğitirken erken aşamada downstream değerlendirmeleri çalıştırmaya başlayın ve açık kaynak bir modelle karşılaştırma yapıyorsanız, yazarlarına ara checkpoint’leri sağlayıp sağlayamayacaklarını sorun. Bunlar çok değerli referans noktaları olabilir.

Altyapı tarafında en önemli metrik throughput’tur; yani saniyede işlenen token sayısı. SmolLM3 için run boyunca 13.500–14.000 token/s arasında stabil bir throughput bekliyorduk ve bu aralığın kalıcı olarak dışına çıkılması bir kırmızı bayraktı. Ancak throughput tek başına yeterli değildir: Donanım arızalarını öngörmek ve tespit etmek için sürekli donanım sağlığı izleme de gerekir. İzlediğimiz başlıca metrikler arasında GPU sıcaklıkları, bellek kullanımı ve hesaplama kullanım oranı vardı. Bunları Grafana panolarına kaydettik ve donanım anomalileri için gerçek zamanlı Slack uyarıları kurduk.

On-the-fly düzeltme vs. yeniden başlatma

1T token sonrasında run’ı yeniden başlattığımız göz önüne alındığında önemli bir soru ortaya çıkıyor: Bir şeyler ters gittiğinde her zaman yeniden başlatmak gerekir mi? Cevap, problemin ciddiyetine ve kök nedenine bağlıdır.

Bizim durumumuzda TP seeding hatası, işe yanlış noktadan başlamamız anlamına geliyordu; ağırlıklarımızın yarısı düzgün şekilde initialize edilmemişti. Model, SmolLM2’ye benzer performans gösteriyor ve benzer noktalarda plato yapıyordu; bu da muhtemelen iki kat maliyetle aynı performansı verecek bir modelle sonuçlanacağımızı gösteriyordu. Bu durumda yeniden başlatmak mantıklıydı. Ancak birçok sorun, compute israf etmemek için run sırasında düzeltilebilir. En yaygın problem, eğitim kaybında ani sıçramalardır (loss spike); bunlar küçük aksaklıklardan ciddi diverjans sinyallerine kadar farklı anlamlar taşıyabilir.

Stas Bekman’ın Machine Learning Engineering Open Book’ta güzel bir şekilde ifade ettiği gibi: “Eğitim kayıp grafikleri kalp atışı desenlerine benzer; iyi olanlar, kötü olanlar ve endişelenmeniz gerekenler vardır”.

Loss spike’ler iki kategoriye ayrılır:

Kurtarılabilir spike’ler: Bunlar ya hızlı şekilde (spike sonrasında hemen) ya da daha yavaş biçimde (önceki eğitim yörüngesine dönmek için birkaç adım gerektirerek) toparlanabilir. Genellikle eğitim bu durumlarda sürdürülebilir. Eğer toparlanma çok yavaşsa, sorunlu batch’leri atlamak için önceki bir checkpoint’e geri dönmeyi deneyebilirsiniz.

Kurtarılamayan spike’ler: Bu durumda model ya diverge olur ya da spike öncesine kıyasla daha kötü bir performansta plato yapar. Bunlar, sadece checkpoint’e geri dönmekten daha ciddi müdahaleler gerektirir.

Ölçek büyüdükçe eğitim instabilitelerinin arttığını tam olarak anlamasak da, konservatif bir mimari ve optimizer varsayımı altında bazı yaygın nedenleri biliyoruz:

Yüksek öğrenme oranı (learning rate): Bunlar eğitimin erken aşamalarında instabilite yaratır ve learning rate düşürülerek düzeltilebilir.

Kötü veri: Genellikle kurtarılabilir spike’lerin ana nedenidir, ancak toparlanma yavaş olabilir. Özellikle eğitim ilerledikçe, model düşük kaliteli verilerle karşılaştığında ortaya çıkabilir.

Veri–parametre durumu etkileşimleri: PaLM (Chowdhery ve ark., 2022), spike’ların çoğu zaman sadece “kötü veri”den değil, belirli veri batch’leri ile model parametre durumunun spesifik kombinasyonlarından kaynaklandığını gözlemledi. Aynı problemli batch’ler farklı bir checkpoint’ten geçirildiğinde spike’lar yeniden oluşmayabiliyordu.

Kötü başlangıç (initialization): OLMo 2 (OLMo ve ark., 2025) yakın zamanda scaled initialization yerine basit bir normal dağılım (ortalama=0, std=0.02) kullanmanın stabiliteyi artırdığını gösterdi.

Precision sorunları: Artık kimse FP16 ile eğitim yapmasa da, BLOOM bunu BF16’a kıyasla oldukça instabil buldu.

Ne yapabilirsiniz?

Spike’ler ortaya çıkmadan önce: stabiliteyi inşa etmek

Küçük modeller, konservatif learning rate’ler ve temiz veri ile genellikle spike üretmez; ancak büyük modeller için proaktif stabilite önlemleri gerekir. Ölçek büyüdükçe, instabiliteyi önlemeye yardımcı olan bir araç seti oluştu. Bunlar şunları içerir:

Veri filtreleme ve karıştırma (shuffling): Bu noktada verinin ne kadar kritik olduğuna tekrar tekrar dönüyoruz. Verinin temiz ve iyi karıştırılmış olması spike’leri önleyebilir. Örneğin OLMo 2, tekrar eden n-gram’leri (32+ kez tekrarlanan 1–13 token’lık diziler) içeren dokümanların çıkarılmasının spike sıklığını ciddi şekilde azalttığını buldu.

Eğitim modifikasyonları: Z-loss regularization, çıktı logit’lerinin aşırı büyümesini performansı etkilemeden sınırlar. Embedding’lerin weight decay’den çıkarılması da yardımcı olur.

Mimari değişiklikler: QK-norm (attention öncesi query ve key projeksiyonlarının normalize edilmesi) etkili bir yöntemdir. OLMo2 ve diğer ekipler bunun stabiliteyi artırdığını buldu ve ilginç şekilde Marin ekibi bunun run ortasında bile uygulanıp divergence sorunlarını düzeltebildiğini gösterdi.

Spike’ler yine de olduğunda: hasar kontrolü

Tüm bu önlemlere rağmen spike’ler yine de oluşabilir. Bunları düzeltmek için bazı seçenekler:

Sorunlu batch’leri atlamak: Spike öncesine geri dönüp problemli batch’leri atlamak en yaygın çözümdür. Falcon ekibi (Almazrouei ve ark., 2023) spike’leri çözmek için 1B token atlamış, PaLM ekibi (Chowdhery ve ark., 2022) ise spike civarındaki 200–500 batch’i atlamanın tekrar oluşumu engellediğini bulmuştur.

Gradient clipping’i sıkılaştırmak: Geçici olarak gradient norm eşiğini düşürmek.

Mimari düzeltmeler uygulamak: Yukarıda bahsedilen QK-norm gibi yöntemler etkili olabilir.

Şimdiye kadar ölçeklendirme sırasında karşılaştığımız zorlukları (throughput düşüşlerinden TP hatasına kadar), problemleri erken yakalamak için izleme pratiklerini ve loss spike’leri önleme/düzeltme stratejilerini ele aldık. Bu bölümü, multi-stage training’in model performansını nasıl artırabileceğini tartışarak bitireceğiz.

Orta eğitim (Mid-Training)

Modern LLM pretraining genellikle farklı veri karışımlarına sahip birden fazla aşamadan oluşur ve çoğu zaman context length’i uzatmak için final bir aşama ile tamamlanır. Örneğin Qwen3 (A. Yang, Li ve ark., 2025), üç aşamalı bir yaklaşım kullanır: 4k context ile 30T token’lık genel bir aşama, STEM ve coding ağırlıklı 5T yüksek kaliteli token içeren reasoning aşaması ve son olarak 32k context ile yüz milyarlarca token’lık uzun context aşaması. SmolLM3 de benzer bir felsefe izler; performans izlemeye bağlı olarak daha yüksek kaliteli veri setlerini ve context uzatmayı hem planlı hem de reaktif müdahalelerle devreye sokar.

Önceki bölümde açıkladığımız gibi, veri karışımının eğitim boyunca sabit kalması gerekmez. Multi-stage training, eğitim ilerledikçe veri seti oranlarını stratejik olarak değiştirmemize izin verir. Bazı müdahaleler en baştan planlanır: SmolLM3 için ikinci aşamada FineMath4+ ve Stack-Edu gibi daha yüksek kaliteli veri setlerini ekleyeceğimizi, final decay aşamasında ise küratörlü Q&A ve reasoning verilerini ekleyeceğimizi biliyorduk. Diğer müdahaleler ise eğitim sırasında performans takibine bağlı olarak reaktif şekilde yapılır. Örneğin SmolLM2’de matematik ve kod performansı hedeflerin gerisinde kaldığında, tamamen yeni veri setleri (FineMath ve Stack-Edu) oluşturup bunları eğitim ortasında eklemiştik. Bu esneklik — ister planlı bir müfredat ister ortaya çıkan eksiklere adaptasyon olsun — hesaplama bütçesinden maksimum değer çıkarmayı sağlar.

Stage 2 ve Stage 3 karışımları

Aşağıdaki grafik, üç eğitim aşamasını ve web/code/math oranlarının eğitim boyunca nasıl değiştiğini gösterir. SmolLM3 eğitim konfigürasyonları, her aşama için kesin veri ağırlıklarıyla birlikte SmolLM GitHub deposunda mevcuttur. Her aşamanın bileşiminin arkasındaki gerekçeler hakkında daha fazla ayrıntı için “The Art of Data Curation” bölümüne bakabilirsiniz.

Aşama 1 — Temel eğitim (8T token, 4k context)

Bu temel aşama, FineWeb-Edu, DCLM, FineWeb2, FineWeb2-HQ gibi web verilerinden oluşan çekirdek pretraining karışımımızı; The Stack v2 ve StarCoder2’den gelen kod verilerini; ayrıca FineMath3+ ve InfiWebMath3+’ten gelen matematik verilerini kullanır. Tüm eğitim 4k context uzunluğunda gerçekleştirilir.

Aşama 2 — Yüksek kaliteli veri enjeksiyonu (2T token, 4k context)

Bu aşamada, daha yüksek kaliteli filtrelenmiş veri kümelerini devreye alırız. Bunlar arasında kod için Stack-Edu, matematik için FineMath4+ ve InfiWebMath4+, ayrıca ileri matematiksel muhakeme için MegaMath yer alır (Qwen Q&A verisini, sentetik yeniden yazımları ve metin–kod iç içe bloklarını da ekleriz).

Aşama 3 — Öğrenme oranı düşüşü (LR decay) ile muhakeme ve Q&A verisi (1.1T token, 4k context)

Öğrenme oranı düşüşü (decay) aşamasında, daha yüksek kaliteli kod ve matematik veri kümelerini daha fazla örnekleyerek (upsampling) artırırız ve OpenMathReasoning, OpenCodeReasoning ve OpenMathInstruct gibi instruction ve reasoning verilerini ekleriz. Q&A örnekleri ise basitçe birleştirilir ve newline karakterleriyle ayrılır.

Uzun context genişletme: 4k → 128k token

Context uzunluğu, modelin aynı anda işleyebileceği metin miktarını belirler. Uzun doküman analizi, çok turlu tutarlı sohbetler ve tüm kod tabanlarının işlenmesi gibi görevler için kritik öneme sahiptir. SmolLM3 eğitime 4k token ile başladı, ancak gerçek dünya kullanım senaryoları için bunu 128k’ya ölçeklendirmemiz gerekiyordu.

Neden context’i eğitim ortasında genişletiyoruz?

Eğitimin başından itibaren uzun context ile çalışmak, attention mekanizmalarının sequence length ile karesel olarak ölçeklenmesi nedeniyle oldukça maliyetlidir. Ayrıca araştırmalar, eğitimin sonuna doğru veya sürekli pretraining sırasında birkaç düzine ila yüz milyar token ile context genişletmenin iyi uzun-context performansı için yeterli olduğunu göstermektedir (Gao ve ark., 2025).

Aşamalı ölçekleme: 4k → 32k → 64k

Doğrudan 128k’ya atlamadık. Bunun yerine modeli her seviyeye uyum sağlayacak şekilde kademeli olarak eğittik. İki uzun context aşaması çalıştırdık: önce 4k’dan 32k’ya, ardından 32k’dan 64k’ya geçtik (128k kapasitesi ise eğitim değil, inference-time extrapolation ile elde edilir).

Her aşama için yeni bir learning rate planı başlatmanın, ana decay fazının son 100B token’ı içinde context’i uzatmaktan daha iyi sonuç verdiğini gözlemledik. Her aşamada uzun context veri karışımı ve RoPE theta değeri için ablasyonlar yaptık ve RULER benchmark’ı üzerinde değerlendirme gerçekleştirdik.

Uzun context değerlendirmeleri (base model)

Uzun context ablasyonları sırasında HELMET benchmark’ının base modellerde oldukça gürültülü olduğunu gözlemledik (aynı eğitim farklı seed’lerle değişken sonuçlar veriyordu). Gao ve ark. (2025), varyansı azaltmak için supervised fine-tuning yapılmasını öneriyor. Biz bunun yerine RULER benchmark’ını kullandık ve bunun base model seviyesinde daha güvenilir sinyal verdiğini gördük.

Bu fazda, uzun context performansını artırmak için uzun web sayfaları ve kitaplar gibi dokümanların daha fazla örneklenmesi (upsampling) yaygın bir yaklaşımdır (Gao ve ark., 2025). Retrieval ve fill-in-the-middle görevleri için kitaplar, makaleler ve sentetik dokümanlar dahil olmak üzere çeşitli ablasyonlar yaptık; Qwen2.5–1M yaklaşımını (A. Yang, Yu ve ark., 2025) FineWeb-Edu ve Python-Edu ile takip ettik.

Şaşırtıcı şekilde, baseline karışıma kıyasla anlamlı bir iyileşme gözlemlemedik. Bu baseline zaten web ve kod verilerinden gelen doğal uzun dokümanları (~%10 token) içeriyordu ve NoPE kullanımı da buna katkı sağlamış olabilir.

RoPE ile ayarlanmış base frequency (ABF)

4k’dan 32k’ya genişletirken RoPE base frequency (theta) değerini 2M’e çıkardık. 32k’dan 64k’ya geçerken bunu 5M’e yükselttik. 10M gibi daha yüksek değerler RULER skorunu biraz artırsa da GSM8k gibi kısa context görevlerinde performansı düşürdüğü için 5M’de sabit kaldık.

Bu aşamada ayrıca math, code ve reasoning Q&A verilerini daha fazla örnekledik ve ChatML formatında birkaç yüz bin örnek ekledik.

4k → 32k genişlemesinde sliding window attention (4k, 8k ve 16k pencere boyutlarıyla) da denedik, ancak full attention’a kıyasla RULER performansı daha kötü çıktı.

YARN extrapolation: 128k’ya ulaşmak

SmolLM3’ün inference sırasında 128k context işleyebilmesini istedik, ancak doğrudan 128k sequence ile eğitim yapmak aşırı maliyetli olurdu. Bunun yerine YARN (Yet Another RoPE extensioN method) (B. Peng ve ark., 2023) kullanarak modelin eğitim uzunluğunun ötesine extrapolate etmesini sağladık.

Teorik olarak YARN, sequence length’i 4 katına kadar artırabilir. 64k checkpoint’in 128k performansı, 32k checkpoint’e göre daha iyi çıktı; bu da hedef inference uzunluğuna daha yakın eğitmenin faydasını doğruladı. Ancak 256k (4 × 64k) seviyesine çıkıldığında RULER performansı düştü, bu yüzden modeli 128k kullanımına kadar önermeyi uygun gördük.

Böylece SmolLM3’ün tüm pretraining sürecini; planlamadan ablasyonlara, ölçekleme kararlarından son eğitim koşusuna kadar tüm perde arkasını tamamlamış olduk.

Pretraining’i kapatırken

Planlama ve “training compass” yaklaşımından başlayarak neyi neden eğiteceğimizi belirlemeyi; mimari kararları doğrulayan sistematik ablasyonları; ve ölçek sırasında ortaya çıkan (throughput düşüşleri, dataloader tıkanmaları, 1T token’da restart gerektiren ince tensor parallelism bug’ı gibi) sorunlarla dolu gerçek eğitim sürecini ele aldık.

Bu süreçteki “parlatılmış raporların” arkasındaki gerçeklik netleşiyor: LLM eğitimi, mimari inovasyonlar ve veri kürasyonu kadar disiplinli deney yapma ve hızlı debug etme işidir. Planlama neyin test edileceğini belirler. Ablasyonlar kararları doğrular. Monitoring sorunları erken yakalar. Ve bir şeyler kaçınılmaz olarak bozulduğunda, sistematik risk azaltma nerede bakman gerektiğini gösterir.

SmolLM3 özelinde bu süreç, hedeflediğimizi verdi: 11T token üzerinde eğitilmiş, matematik, kod, çok dillilik ve uzun context görevlerinde rekabetçi, Qwen3 modelleri Pareto sınırında yer alan bir 3B model.

HellaSwag, ARC, WinoGrande, CommonsenseQA, MMLU-CF, MMLU Pro CF, PIQA, OpenBookQA, GSM8K, MATH, HumanEval+ ve MBPP+ üzerinde değerlendirilen temel modellerin kazanma oranı.

Temel model checkpoint’imizi kaydedip eğitim tamamlandığında, işi bitirdik demeye meyilli olabiliriz. Sonuçta, metinleri iyi tahmin eden, güçlü benchmark skorlarına ulaşan ve hedeflediğimiz yetenekleri sergileyen bir modelimiz var. Tamamdır, değil mi?

Pek sayılmaz. Çünkü bugün insanların istediği şey ham bir sonraki-token tahminleyiciden ziyade asistanlar ve kodlama ajanlarıdır. İşte bu noktada post-training devreye giriyor. Ve tıpkı pretraining’de olduğu gibi, gerçeklik düşündüğünüzden daha karmaşıktır.

7. Temel Modellerin Ötesinde: 2025’te Post-Training

Pre-training tamamlandıktan sonra, bir gün içinde SFT taban çizgisini elde etmiş olmalıyız. — Lewis Tunstall, iyimser bir LLM uzmanı

Kendi post-training maceranızı kendiniz seçin.

Ön-eğitim (pretraining), SmolLM3’ün ham yeteneklerini bize kazandırdı; ancak GPU’lar henüz soğumadan model kabiliyetlerinin bir sonraki sınırına geçiyoruz: post-training. Bu aşama; denetimli ince ayar (supervised fine-tuning), pekiştirmeli öğrenme (reinforcement learning), model birleştirme (model merging) ve daha fazlasını içerir, hepsi, “metin tahmin eden bir model” ile “insanların gerçekten kullanabileceği bir model” arasındaki boşluğu kapatmak için tasarlanmıştır. Ön-eğitim (pretraining) bilgiyi ağırlıklara kaba kuvvetle yerleştirmekle ilgiliyse, post-training bu ham kapasiteyi güvenilir ve yönlendirilebilir bir şeye dönüştürerek şekillendirmektir. Ve yine, cilalı post-training makaleleri gece yarısı yaşanan sürprizleri anlatmaz: GPU çöküşleri, hassas veri karışımları ya da önemsiz gibi görünen bir chat template kararının aşağı akış benchmark’larını nasıl etkileyebileceği gibi. Bu bölümde, SmolLM3’ü güçlü bir temel modelden son teknoloji bir hibrit akıl yürütme modeline dönüştürmek için post-training’in karmaşık dünyasında nasıl ilerlediğimizi göstereceğiz.

Hibrit akıl yürütme modeli nedir?

Hibrit akıl yürütme modeli iki farklı modda çalışır: biri kısa ve doğrudan yanıtlar için, diğeri ise adım adım uzun akıl yürütme için. Genellikle çalışma modu kullanıcı tarafından sistem mesajında belirlenir. Qwen3’ü takip ederek bunu hafif komutlarla açık hale getiriyoruz: “/think” genişletilmiş akıl yürütmeyi başlatır, “/no_think” ise kısa ve öz yanıtları zorunlu kılar. Böylece kullanıcı, modelin derinlik mi yoksa hız mı önceliklendireceğini kontrol eder.

Post-Training Pusulası: Neden → Ne → Nasıl

Tıpkı pretraining’de olduğu gibi, post-training de araştırma ve mühendislik döngülerinde boşa zaman kaybını önlemek için net bir pusuladan faydalanır. Bunu şöyle çerçeveleyebiliriz:

Neden post-train yapılır? Ön-eğitim pusulasında anlattığımız eğitim motivasyonlarının üçü post-training için de geçerlidir. Örneğin, mevcut bir modelde pekiştirmeli öğrenmenin yeni akıl yürütme yetenekleri kazandırıp kazandırmayacağını araştırıyor olabilirsiniz (araştırma), ya da büyük bir modeli gecikme (latency) nedeniyle daha küçük bir modele distile etmeniz gerekebilir (üretim), ya da belirli bir kullanım durumu için güçlü açık bir model eksikliği tespit etmiş olabilirsiniz (stratejik açık kaynak). Fark şu ki post-training, sıfırdan yetenek oluşturmak yerine mevcut yetenekler üzerine inşa eder. Ancak GPU’lara yönelmeden önce kendinize şunu sorun:

• Gerçekten post-training yapmanız gerekiyor mu? Bugün birçok açık-ağırlık model, geniş bir görev yelpazesinde kapalı modellere yaklaşan performans sunabiliyor. Bazıları kuantizasyon ve mütevazı hesaplama ile yerelde bile çalıştırılabiliyor. Eğer genel amaçlı bir asistan istiyorsanız, Hugging Face Hub’daki hazır bir model zaten ihtiyacınızı karşılıyor olabilir.
• Yüksek kaliteli, alan-özel veriye erişiminiz var mı? Post-training en çok, genel modellerin yetersiz kaldığı belirli bir görev veya alan hedefleniyorsa anlamlıdır. Doğru veriyle, modelinizi sizin kullanım senaryolarınızda daha doğru çıktılar üretecek şekilde ayarlayabilirsiniz.
• Başarıyı ölçebiliyor musunuz? Net değerlendirme kriterleri olmadan post-training’in gerçekten fayda sağlayıp sağlamadığını bilemezsiniz.
• Post-training neyi başarmalı? Bu, önceliklerinize bağlıdır.

Şunlardan hangisini istiyorsunuz:

• Nadiren konudan sapan, net bir yönerge takipçisi mi?
• İhtiyaca göre ton ve rol değiştirebilen çok yönlü bir asistan mı
• Matematik, kod veya ajan tabanlı problemleri çözebilen bir akıl yürütme motoru mu?
• Birden fazla dilde konuşabilen bir model mi?
• Bunlara nasıl ulaşılır?

İşte burada “tarifler” devreye girer. Şunları ele alacağız:

• Temel yetenekleri kazandırmak için denetimli ince ayar (SFT)
• İnsan veya yapay zeka tercihlerini doğrudan öğrenmek için tercih optimizasyonu (PO)
• Denetimli verinin ötesinde güvenilirliği ve akıl yürütmeyi geliştirmek için pekiştirmeli öğrenme (RL)
• Doğru dengeyi kurmak için veri kürasyonu (data curation)
• İlerlemeyi izlemek ve regresyonları erken yakalamak için değerlendirme (evaluation)

Bu pusula, post-training’in kaosunu kontrol altında tutar. “Neden” yön verir, “ne” öncelikleri belirler, “nasıl” ise hedefleri pratik bir eğitim döngüsüne dönüştürür.

Şimdi bu soruları SmolLM3 için nasıl yanıtladığımıza bakalım:

Neden?

Bizim SMOLLM3 eğitirkenki nedenimiz oldukça netti; çünkü piyasaya sürülmeden önce post-training gerektiren bir temel modelimiz vardı. Aynı zamanda Qwen3 gibi hibrit akıl yürütme modelleri giderek popülerleşiyordu, ancak bunları nasıl eğiteceğini anlatan açık tarifler çok azdı. SmolLM3 bize iki hedefi aynı anda gerçekleştirme fırsatı verdi: Gerçek dünya kullanımı için bir model hazırlamak ve Qwen3’ün 1.7B ve 4B modelleriyle birlikte Pareto sınırında yer alacak tamamen açık bir tarif sunmak.

Ne?

SmolLM3’ün güçlü yönlerine göre uyarlanmış bir hibrit akıl yürütme modeli eğitmeyi hedefledik; özellikle akıl yürütme kalitesinin İngilizce dışındaki dillerde de korunması gerekiyordu. Gerçek dünya kullanımında araç çağırma (tool calling) ve uzun bağlam (long context) iş akışları giderek daha önemli hale geldiği için, bunlar da post-training tarifimizin temel gereksinimleri oldu.

Nasıl?

Bunu bölümün geri kalanında öğreneceksiniz!

Tıpkı pretraining’de olduğu gibi post-training’de de temel noktalardan başlıyoruz: değerlendirmeler (evals) ve baseline’lar, çünkü her büyük model küçük bir ablasyonla başlar. Ancak ablasyon yapma şekli farklıdır. Pretraining’de “küçük” genellikle daha küçük model ve veri kümeleri anlamına gelir. Post-training’de ise “küçük”, daha küçük veri kümeleri ve daha basit algoritmalar anlamına gelir. Hedef model üzerinde doğrudan iterasyon yapacak kadar hızlı çalışabildiğimiz için neredeyse hiç farklı bir temel model kullanmayız.

Bu kuralın ana istisnası, Hugging Face Hub’dan hazır bir temel model kullanıldığında ortaya çıkar. Bu durumda temel model üzerinde ablasyon yapmak mantıklı olabilir; çünkü aynı boyutta olsalar bile 1T token ile eğitilmiş bir model ile 10T token ile eğitilmiş bir model arasında ciddi fark vardır.

Şimdi birçok model eğiticisinin bir projede çok geç kalana kadar kaçındığı konuya başlayalım: değerlendirmeler (evals).

Öncelik Her Şeyden Önce: Evals (Değerlendirmeler)

Post-training sürecindeki ilk adım, pretraining’de olduğu gibi, doğru eval (değerlendirme) kümesini belirlemektir. Günümüzde çoğu LLM asistan olarak kullanıldığı için, “zeka” gibi soyut ARC-AGI benzeri benchmark’ları (karşılaştırma ölçütlerini) kovalamak yerine “iyi çalışan” bir model hedeflemek daha doğru bir yaklaşım olarak görülüyor. Peki iyi bir asistan ne yapabilmeli? En azından şunları yapabilmelidir:

• Belirsiz yönergeleri işleyebilme,
• Adım adım plan yapabilmeli,
• Kod yazabilmeli,
• Gerekli olduğunda araç (tool) çağırabilmeli.

Bu davranışlar; muhakeme, uzun bağlam (long context) işleme ve matematik, kod ve araç kullanımı gibi becerilerin bir karışımını gerektirir. 3B parametre kadar küçük ya da daha küçük modeller bile asistan olarak iyi çalışabilir, ancak performans genellikle 1B’nin altına indikçe keskin biçimde düşer.

Küçük modellerin araç çağırma yeteneğini kullanarak sınırlı kapasitelerini telafi edip edemeyeceği ve böylece geçerli asistanlar haline gelip gelemeyeceği hâlâ ilginç ve açık bir sorudur. Bu yönde yakın zamanda yapılan çalışmalar için LiquidAI modellerine bakılabilir.

Hugging Face olarak, pretraining prensiplerini (monotonluk, düşük gürültü, rastgele olmayan sinyal, sıralama tutarlılığı) yansıtan katmanlı bir değerlendirme kümesi kullanıyoruz. Bu prensipleri ablasyon bölümünde detaylandırmıştık.

Eval’lerini güncel tut

Dikkate alınacak eval listesi, modeller geliştikçe sürekli değişmektedir. Burada tartışılanlar 2025 ortası odağımızı yansıtır. Post-training eval’lere kapsamlı bir bakış için LLM Evaluation Guidebook’a bakılabilir.

Post-trained bir modeli değerlendirmenin birçok yolu vardır:

Yetenek (capability) eval’leri

Bu sınıf eval’ler temel becerileri hedefler:

Bilgi (Knowledge): Şu anda bilimsel bilgi için ana eval olarak GPQA Diamond (Rein et al., 2024) kullanıyoruz. Bu karşılaştırma ölçütü, lisansüstü seviyede çoktan seçmeli sorulardan oluşur. Küçük modeller için doygunluğa ulaşmamıştır ve MMLU gibi testlere göre daha iyi sinyal verirken çok daha hızlı çalışır. Gerçeklik/faktüalite için bir diğer iyi test SimpleQA (Wei et al., 2024)’dir, ancak küçük modeller bilgi sınırlamaları nedeniyle burada genellikle zorlanır.

Matematik Matematiksel yeteneği ölçmek için çoğu model AIME’in en güncel versiyonu (şu anda 2025) ile değerlendirilir. MATH-500 (Lightman et al., 2023) küçük modeller için hâlâ faydalı bir “sağlamlık testi”dir, ancak akıl yürütme modelleri tarafından büyük ölçüde doygunluğa ulaşmıştır. Daha kapsamlı matematik değerlendirme kümeleri için MathArena önerilir.

Kod Kodlama yetkinliğini takip etmek için LiveCodeBench’in en güncel versiyonunu kullanıyoruz. Rekabetçi programlama problemlerine odaklansa da, LiveCodeBench üzerindeki gelişmelerin daha iyi kod modellerine dönüştüğünü gözlemledik (Python ile sınırlı olsa da). SWE-bench Verified daha sofistike bir ölçümdür, ancak küçük modeller için genellikle çok zor olduğu için çoğunlukla kullanılmaz.

Çok dillilik (Multilinguality): Maalesef modellerin çok dilli yeteneklerini test etmek için çok fazla seçenek yok. Global MMLU (Singh et al., 2025)’yi temel diller için kullanıyoruz ve MGSM (Shi et al., 2022)’yi çok dilli matematik testi olarak ekliyoruz.

Entegre görev değerlendirmeleri

Bu değerlendirmeler, shipping (ürünü dağıtma) aşamasındaki yeteneklere benzer becerileri test eder:

Uzun bağlam kullanımı: En yaygın test Needle in a Haystack (NIAH) (Kamradt, 2023)’tır. Burada rastgele bir bilgi (“needle”) uzun bir dokümanın (“haystack”) içine yerleştirilir ve model bunu bulmak zorundadır. Ancak bu benchmark uzun bağlam anlayışını ayırt etmekte yüzeysel kalır. Bu nedenle RULER (Hsieh et al., 2024) ve HELMET (Yen et al., 2025) gibi daha kapsamlı eval’ler geliştirilmiştir. Daha yakın zamanda OpenAI, MRCR ve GraphWalks benchmark’larını yayınlayarak bu alanı daha da zorlaştırmıştır.

Ayrıca uzun bağlam eval’lerinin sınırlamaları ve gerçekçi test tasarımı üzerine iyi bir blog yazısına bakılabilir.

Talimat takibi (Instruction following): IFEval (J. Zhou et al., 2023), talimat takip performansını ölçmek için en popüler eval’dir; “doğrulanabilir talimatlara” karşı otomatik puanlama kullanır. IFBench (Pyatkin et al., 2025), Ai2 tarafından geliştirilen ve daha çeşitli kısıtlar içeren bir genişletmedir. Çok turlu (multi-turn) talimat takibi için Multi-IF (He et al., 2024) veya MultiChallenge (Sirdeshmukh et al., 2025) önerilir.

Hizalama (Alignment): Modelin kullanıcı niyetiyle ne kadar uyumlu olduğunu ölçmek genellikle insan değerlendiricilerle veya LMArena gibi leaderboard’larla yapılır. Çünkü serbest üretim, stil ve genel faydalılık gibi özellikleri otomatik metriklerle ölçmek zordur. Ancak bu eval’ler pahalıdır; bu yüzden topluluk LLM’leri insan tercihlerine vekil olarak kullanır. Bu tür benchmark’lara AlpacaEval (Dubois et al., 2025), ArenaHard (T. Li et al., 2024) ve MixEval (Ni et al., 2024) dahildir. MixEval, LMArena Elo skorlarıyla en güçlü korelasyona sahiptir.

Tool calling (araç kullanımı): Berkeley Function Calling Leaderboard (BFCL), araç çağırma yeteneğini kapsamlı şekilde test eder, ancak genellikle hızlı şekilde doygunluğa ulaşır. TAU-Bench (Barres et al., 2025) ise modelin araç kullanarak müşteri hizmetleri senaryolarında problem çözme yeteneğini ölçer ve giderek popülerleşmiştir.

Aşırı öğrenmeyi (overfitting) önleme eval’leri

Modelin belirli bir beceriye overfit olup olmadığını test etmek için GSM8k (Cobbe et al., 2021) problemlerini bozarak türetilen GSMPlus (Q. Li et al., 2024) gibi dayanıklılık/uyarlanabilirlik eval’leri kullanılır.

İç (internal) eval’ler

Her ne kadar halka açık karşılaştırma ölçütleri model geliştirme sırasında sinyal sağlasa da, belirli yetenekleri hedeflemek için kendi iç değerlendirmelerinizi oluşturmanın veya iç uzmanların modelle etkileşime girmesini sağlamanın yerini tutmaz. Örneğin SmolLM3 için çok turlu akıl yürütme yeteneğini ölçmek amacıyla Multi-IF’in bir varyantını geliştirdik.

Bu durum özellikle bir YZ ürünü geliştiriyorsanız daha da önemlidir. Bu konuda Hamel Husain’in blog yazısı faydalı öneriler içerir.

“Vibe eval” ve Arena Testleri

Benzer şekilde, ara checkpoint’leri “vibe test” etmek (modelle doğrudan etkileşim kurmak), eval skorlarının yakalayamadığı ince davranış sorunlarını ortaya çıkarmak için çok önemlidir. Örneğin vibe test sırasında tüm sistem mesajlarının veri kümesinden yanlışlıkla silindiği bir bug keşfettik!

Bu yaklaşım LMArena gibi platformlarda insan tercihlerini ölçmek için ölçeklenebilir şekilde de yapılabilir. Ancak crowdsourced insan değerlendirmeleri kırılgandır (aşırı pohpohlama ve süslü dil gibi davranışları ödüllendirme eğilimindedir), bu yüzden düşük sinyalli bir geri bildirim olarak görülmelidir.

Eğitim verisini decontaminate etme (temizleme)

Public benchmark’lara aşırı güvenmenin bir riski, modellerin bu benchmark’lara overfit olmasıdır. Özellikle sentetik veri, hedef benchmark’lara benzeyen prompt ve cevaplar üretebildiğinde bu daha da artar. Bu nedenle eğitim verisini, model geliştirmede kullanacağınız eval’lerden “decontaminate” etmek kritik önemdedir. Bunu n-gram matching gibi yöntemlerle (Open-R1 benzeri script’lerle) yapabilirsiniz.

SmolLM3 için, hem talimat takip edebilen hem de matematik ve kod gibi alanlarda iyi akıl yürüten hibrit bir reasoning modeli hedefledik. Aynı zamanda temel modelin çok dillilik ve uzun bağlam yeteneklerini korumasını istedik.

Bu da bizi aşağıdaki değerlendirme kümesine götürdü:

Bu değerlendirmelerin aslında neyi ölçtüğünü somut olarak anlamak için birkaç örnek soruya bakalım.

Her benchmark’taki soru türlerini görmek için etkileşimli görüntüleyicideki örnekleri inceleyebilirsiniz. Alanların çeşitliliğinin, ablasyon çalışmalarımız boyunca model yeteneğinin farklı yönlerini test etmemizi nasıl sağladığına dikkat edin.

Çalıştığımız 3B model ölçeği için, eğitim sürecinin kendisinden daha hızlı çalışacak bu değerlendirmelerin, iyileştirmelerin gerçekten anlamlı olup olmadığını ve yalnızca örnekleme gürültüsünden kaynaklanmadığını anlamak için bize eyleme dönüştürülebilir sinyal ve güven sağlayacağını düşündük. Ayrıca, temel model performansında çok fazla gerileme olmadığından emin olmak için ön eğitim değerlendirmelerimizi de takip ettik (tam liste için ablasyon bölümüne bakın).

Değerlendirmelerinize öncelik verin

Yukarıdaki hikâye, bir ekip olarak bir araya gelip değerlendirme kümelerinde uzlaştığımızı ve eğitim başlamadan önce bunları hazır hale getirdiğimizi düşündürebilir. Gerçek ise çok daha dağınıktı: Sıkı bir teslim tarihi vardı ve model eğitimine, yukarıdaki değerlendirmelerin çoğu henüz uygulanmadan başlamıştık (örneğin RULER, model yayınından sadece birkaç gün önce hazır hale geldi). Geriye dönüp baktığımızda bunun bir hata olduğunu görüyoruz; ön eğitim ekibiyle hangi temel değerlendirmelerin eğitim sonrası aşamada da korunması gerektiğini konuşmalı ve bunları temel model eğitimi bitmeden çok daha önce uygulamayı önceliklendirmeliydik. Başka bir deyişle, her şeyden önce değerlendirmelerinize öncelik verin!

Etkileşim Kuralları (Rules of Engagement)

Bu bölümü, binlerce modeli değerlendirerek zor yoldan öğrendiğimiz birkaç dersle özetleyelim:

• Model geliştirme sırasında değerlendirmeleri hızlandırmak için küçük alt kümeler kullanın. Örneğin LiveCodeBench v4, v5 ile yüksek korelasyona sahiptir ancak yarı sürede çalışır. Alternatif olarak tinyBenchmarks (Polo ve ark., 2024) gibi, tam değerlendirmeyle güvenilir şekilde örtüşen en küçük soru alt kümesini bulmayı amaçlayan yöntemleri kullanabilirsiniz.
• Akıl yürütme (reasoning) modelleri için, chain-of-thought (düşünce zinciri) çıktısını puanlanan sonuçtan çıkarın. Bu, yanlış pozitifleri azaltır ve aynı zamanda “50 kelimenin altında bir şiir yaz” gibi kısıtları ihlal eden cevapları cezalandıran IFEval gibi benchmarkları doğrudan etkiler.
• Eğer bir değerlendirme LLM yargıçları kullanıyorsa, zaman içinde adil karşılaştırma yapabilmek için yargıcı ve sürümünü sabitleyin. Daha da iyisi, sağlayıcı yargıç modelini kaldırsa bile değerlendirmenin yeniden üretilebilir olması için açık ağırlıklı (open-weight) bir model kullanın.
• Temel modellerde veri kontaminasyonuna dikkat edin. Örneğin AIME 2025’ten önce yayınlanan çoğu modelin, AIME 2024’e kıyasla belirgin şekilde daha kötü performans göstermesi, burada bir “benchmaxxing” (benchmark optimizasyonu) olabileceğini gösteriyor.
• Mümkünse, ablasyonlarda kullanılan her şeyi test değil, validasyon olarak düşünün. Bu, Tulu 3 değerlendirme çerçevesine (Lambert ve ark., 2025) benzer şekilde, nihai model raporları için ayrı bir tutulmuş test seti bırakmak anlamına gelir.
• Kendi veriniz ve görevleriniz üzerinde küçük bir “vibe evals” kümesi mutlaka bulundurun; bu, kamuya açık karşılaştırma ölçütü kümelerine aşırı uyum sağlamayı (overfitting) yakalamaya yardımcı olur.
• Az sayıda problemi olan değerlendirmelerde (genellikle ~2.000’den az), k kez örnekleme yapın ve ortalama @k doğruluğunu raporlayın. Bu, geliştirme sırasında yanlış kararlara yol açabilecek gürültüyü azaltmak için önemlidir.
• Yeni bir değerlendirme implement ederken, yayınlanan birkaç modelin sonuçlarını (belirli bir hata payı içinde) yeniden üretebildiğinizden emin olun. Bunu yapamamak, ileride implementasyonu düzeltip birçok checkpoint’i yeniden değerlendirmek zorunda kalınca büyük zaman kaybına yol açabilir.
• Şüphede kaldığınızda her zaman değerlendirme verisine geri dönün ve modele tam olarak neyi prompt ettiğinizi inceleyin.

Değerlendirmeler elinizde olduğuna göre, artık bazı modelleri eğitme zamanı! Ancak bunu yapmadan önce bir post-eğitim (post-training) çerçevesi seçmemiz gerekiyor.

Meslek Araçları (Tools of the Trade)

Her bir post-training (eğitim sonrası) reçetesinin arkasında, büyük ölçekli deneyleri mümkün kılan bir araç kümesi (framework ve kütüphaneler) bulunur. Her framework, desteklediği algoritmalar, fine-tuning yöntemleri ve ölçeklenebilirlik özellikleri açısından kendi güçlü ve zayıf yönlerine sahiptir. Aşağıdaki tablo, denetimli ince ayardan (supervised fine-tuning) tercih optimizasyonuna (preference optimization) ve takviyeli öğrenmeye (reinforcement learning) kadar temel destek alanlarını özetlemektedir:

Burada, FullFT (Full Fine-Tuning), eğitim sırasında modelin tüm parametrelerinin güncellendiği tam ince ayarı ifade eder. LoRA (Low-Rank Adaptation) ise yalnızca küçük düşük-rank matrislerin güncellendiği, temel modelin dondurulduğu parametre-verimli bir yaklaşımdır. Multi-modal, metin dışındaki modalitelerde (örneğin görüntüler) eğitim desteğinin olup olmadığını belirtir. Distributed, modelin birden fazla GPU üzerinde eğitilip eğitilemediğini ifade eder.

Hugging Face’te biz TRL’i geliştirip sürdürüyoruz; bu nedenle bu bizim tercih ettiğimiz framework ve SmolLM3’ü post-train ederken kullandığımız araç da bu oldu.

Framework’leri çatallamak (forklamak)

Alan çok hızlı ilerlediği için, deneylerimizi TRL’in dahili bir fork’u üzerinde yürütmenin oldukça etkili olduğunu gördük. Bu sayede yeni özellikleri çok hızlı ekleyebiliyor ve daha sonra bunları ana kütüphaneye geri (upstream) katkı olarak gönderebiliyoruz. Eğer framework’ünüzün iç işleyişiyle çalışmaktan rahatsanız, benzer bir iş akışı hızlı iterasyon için güçlü bir yaklaşım olabilir.

Framework’leri Neden Kullanıyoruz?

Bazı araştırmacılar, training framework’leri kullanmayı eleştirip her şeyi her zaman sıfırdan yazmanız gerektiğini savunur. Bu yaklaşımın örtük iddiası, “gerçek” anlayışın ancak her RL algoritmasını yeniden implement ederek, her dağıtık eğitim primitifi elle yazarak ya da tek seferlik eval sistemi kurarak elde edilebileceğidir.

Ancak bu görüş modern araştırma ve üretim gerçekliğini göz ardı eder. Örneğin RL’e bakalım. PPO ve GRPO gibi algoritmaların doğru implementasyonu oldukça zordur (Huang ve ark., 2024) ve normalizasyon ya da Kullback–Leibler (KL) cezasındaki küçük hatalar bile günlerce boşa harcanan compute ve emek anlamına gelebilir.

Benzer şekilde, tek dosyalık bir implementasyon yazmak cazip olsa da, aynı script 1B’den 100B+ parametreli modellere ölçeklenebilir mi?

Framework’ler tam da bu yüzden vardır: temel bileşenler zaten iyi anlaşılmıştır ve bunları sürekli yeniden icat etmek zamanın kötü kullanımıdır. Bu, düşük seviyeli denemelerin değersiz olduğu anlamına gelmez. PPO’yu bir kez sıfırdan implement etmek mükemmel bir öğrenme egzersizidir. Framework kullanmadan basit bir transformer yazmak, attention’ın nasıl çalıştığını gerçekten anlamayı öğretir. Ancak çoğu durumda, en iyi yaklaşım sevdiğiniz bir framework’ü seçip onu kendi ihtiyacınıza göre uyarlamaktır.

Bu küçük serzenişi geride bıraktıktan sonra, eğitim koşularına genellikle nereden başladığımıza bakalım.

Neredeyse Her Post-Training Pipeline’ın SFT ile Başlamasının Sebebi

Günümüzde X’te (eski Twitter) biraz vakit geçirirseniz, reinforcement learning’in (RL) tek gerçek seçenek olduğunu düşünebilirsiniz. Her gün yeni kısaltmalar, algoritmik değişiklikler ve RL’in yeni yetenekler ortaya çıkarıp çıkaramayacağına dair hararetli tartışmalar (Chu ve ark., 2025; Yue ve ark., 2025) görürsünüz.

Bölümün ilerleyen kısımlarında göreceğimiz gibi RL gerçekten işe yarar, ancak ciddi pratik ödünleşimler (trade-off’lar) içerir.

RL elbette yeni bir şey değil. OpenAI ve diğer laboratuvarlar erken dönem modellerini hizalamak için insan geri bildiriminden öğrenme (RLHF) (Lambert ve ark., 2022) yöntemini yoğun şekilde kullandılar. Ancak RL tabanlı post-training’in açık kaynak ekosisteminde gerçekten yaygınlaşması DeepSeek-R1 (DeepSeek-AI, Guo ve ark., 2025) sürümüne kadar bekledi.

Ama değişmeyen bir şey var: Neredeyse tüm etkili post-training pipeline’lar hâlâ supervised fine-tuning (SFT) ile başlar. Bunun nedenleri oldukça basittir:

• Ucuzdur: SFT, RL’e kıyasla çok daha az hesaplama gücü gerektirir. Genellikle ciddi bir performans artışı elde etmek için “donanım yakmaya” gerek kalmaz ve RL’e kıyasla çok daha kısa sürede tamamlanır.
• Stabildir: Ödül tasarımı ve hiperparametrelere aşırı hassas olan RL’in aksine, SFT genellikle “sorunsuz çalışır”.
• Doğru başlangıç noktasıdır: İyi bir SFT checkpoint’i çoğu zaman hedeflenen kazanımların büyük kısmını sağlar ve DPO ya da RLHF gibi daha ileri yöntemleri çok daha etkili hale getirir.

Pratikte bu şu anlama gelir: SFT sadece “kolay olduğu için” ilk adım değildir; aynı zamanda performansı istikrarlı şekilde artıran ve daha karmaşık yöntemlerden önce en mantıklı basamaktır. Bu durum özellikle base model’larla çalışırken geçerlidir; çünkü birkaç istisna dışında bu modeller, gelişmiş post-training yöntemlerinden faydalanamayacak kadar hamdır.

DeepSeek-R1-Zero hakkında ne demeli?

En ileri seviyede, SFT ile başlama gerekçeleri her zaman geçerli değildir. Distill edilecek daha güçlü bir model yoktur ve insan anotasyonları uzun zincirli akıl yürütme (chain-of-thought reasoning) gibi karmaşık davranışlar için fazla gürültülüdür. Bu yüzden DeepSeek, SFT’yi atlayıp doğrudan RL ile R1-Zero’ya geçti; standart süpervizyonla öğretilemeyecek akıl yürütme davranışlarını keşfetmek için.

Eğer bu rejimde çalışıyorsanız, RL ile başlamak mantıklı olabilir. Ama büyük ihtimalle bu yazıyı okuyorsanız, orada değilsinizdir.

Peki SFT çoğu pipeline’ın başlangıcıysa, bir sonraki soru şudur: Neyi fine-tune etmelisiniz? Bu da doğru base model’i seçmekle başlar.

Base Model Seçimi

Post-training için bir base model seçerken birkaç pratik boyut öne çıkar:

• Model boyutu: Smol modeller zamanla ciddi şekilde gelişmiş olsa da, bugün hâlâ daha büyük modellerin daha iyi genelleme yaptığı ve çoğu zaman daha az örnekle daha iyi sonuç verdiği görülür. Eğitim sonrası nasıl kullanmayı veya deploy etmeyi planlıyorsanız, ona uygun bir model boyutu seçmelisiniz. Hugging Face Hub üzerinde model filtreleriyle modalite ve boyuta göre uygun modelleri kolayca bulabilirsiniz.

Mimari (MoE vs. dense): MoE modelleri (Mixture of Experts), her token için parametrelerin yalnızca bir alt kümesini etkinleştirir ve hesaplama başına daha yüksek kapasite sunar. Büyük ölçekli servis (serving) için oldukça iyidirler; ancak bizim deneyimimize göre fine-tune etmek daha zordur. Buna karşılık dense modeller daha basit eğitilir ve daha küçük ölçeklerde çoğu zaman MoE modellerden daha iyi performans gösterebilir.

Post-training geçmişi: Benchmark’lar faydalıdır, ancak daha da iyi bir sinyal, base model’in halihazırda güçlü post-trained modeller üretmiş ve toplulukta karşılık bulmuş olmasıdır. Bu, modelin eğitim sırasında “iyi öğrenip öğrenmediğine” dair bir proxy (dolaylı gösterge) sağlar.

Yeni modelleri anlamak için LocalLLaMa subreddit’i genel “hissiyatı” (vibes) anlamak açısından iyi bir yerdir. Artificial Analysis ve LMArena da yeni modeller için bağımsız değerlendirmeler sunar; ancak bu platformlar bazen model sağlayıcıları tarafından “benchmaxxing” (benchmark’a aşırı optimize etme) durumuna maruz kalabilir.

Deneyimlerimize göre Qwen, Mistral ve DeepSeek tabanlı modeller post-training için en elverişli modellerdir; özellikle Qwen açık ara favoridir, çünkü her model serisi geniş bir parametre aralığını kapsar (örneğin Qwen3 modelleri 0.6B’den 235B’ye kadar değişir!). Bu özellik, ölçeklemeyi çok daha kolay hale getirir.

Uygulama ihtiyaçlarınıza uygun bir base model seçtikten sonra, sonraki adım modelin temel yeteneklerini test etmek için basit ve hızlı bir SFT baseline oluşturmaktır.

Basit Baseline Eğitimi

SFT için iyi bir baseline; hızlı eğitilebilen, modelin temel yeteneklerine odaklanan ve belirli bir yetenek yetersiz kaldığında kolayca veri eklenerek genişletilebilen bir yapı olmalıdır. İlk baseline için hangi veri setlerinin seçileceği biraz deneyim ve kalite sezgisi (taste) gerektirir. Genel olarak, akademik benchmark’larda yüksek skor bildiren popüler public dataset’lere fazla ağırlık vermekten kaçınmak gerekir; bunun yerine OpenHermes gibi gerçekten güçlü modelleri eğitmekte kullanılmış veri setlerine odaklanmak daha doğrudur.

Örneğin SmolLM geliştirme sürecinde başlangıçta WebInstruct üzerinde SFT yaptık; bu kâğıt üzerinde oldukça iyi bir veri setiydi. Ancak “vibe test”lerimiz sırasında bunun fazla bilim odaklı olduğunu fark ettik — model, “Nasılsın?” gibi basit selamlara bile denklemle cevap veriyordu.

Eğitim verisindeki tuhaflıkları ortaya çıkarmada vibe testing’in ne kadar önemli olduğu bu bölümde tekrar eden bir tema — modelinizle sadece sohbet etmenin gücünü küçümsemeyin.

Bu durum bizi Everyday Conversations veri setini oluşturmaya yöneltti ve bu veri seti küçük modellerde temel sohbet yeteneklerini kazandırmada kritik bir rol oynadı.

SmolLM3 için ise hibrit bir reasoning modeli eğitmeyi hedefledik ve başlangıçta reasoning, instruction following ve steerability (yönlendirilebilirlik) için küçük bir veri seti karışımı seçtik. Aşağıdaki tablo her veri setinin istatistiklerini göstermektedir:

Hibrit akıl yürütme temelleri için veri karışımı

SmolLM3’ün geliştirilmesi boyunca öğrendiğimiz gibi, hibrit akıl yürütme modellerini eğitmek standart SFT’ye göre daha zordur; çünkü veri kümelerini sadece karıştırıp bir araya getiremezsiniz, veriyi farklı kipler arasında eşleştirmeniz (pair etmeniz) gerekir. Her örnek, modelin uzun akıl yürütmeye mi yoksa kısa ve öz bir yanıt vermeye mi geçmesi gerektiğini açıkça belirtmelidir ve ideal olarak, hangi durumda kip değiştirmesi gerektiğini öğreten paralel örnekler de bulunmalıdır. Bu tablodan çıkarılacak bir diğer önemli nokta ise veri karışımını örnek sayısına göre değil, token’lara göre dengelemeniz gerektiğidir: örneğin s1k-1.1 veri kümesi toplam örneklerin yaklaşık %1’ini oluştururken, uzun akıl yürütme yanıtları nedeniyle toplam token’ların yaklaşık %11’ini oluşturur.

Bu, ilgilendiğimiz beceriler açısından temel kapsama alanını sağladı, ancak aynı zamanda yeni bir zorluk da ortaya çıkardı: Her veri kümesinin, uzun düşünmeyi etkinleştirip etkinleştirmemesine bağlı olarak farklı biçimlendirilmesi gerekiyordu. Bu formatları birleştirmek için tutarlı bir sohbet şablonuna (chat template) ihtiyaç duyduk.

İyi Bir Chat Template Seçmek

Bir chat template seçerken veya tasarlarken tek bir “herkese uyan” çözüm yoktur. Pratikte, önceden sormaya değer birkaç soru olduğunu gördük:

• Kullanıcılar sistem rolünü özelleştirebilmeli mi? Kullanıcılar kendi sistem prompt’larını tanımlayabilmeliyse (örneğin “bir korsan gibi davran”), template bunu düzgün şekilde desteklemelidir.
• Modelin araçlara ihtiyacı var mı? Modelin API çağrısı yapması gerekiyorsa, template yapılandırılmış tool call ve yanıtlarını desteklemelidir.
• Bu bir akıl yürütme (reasoning) modeli mi? Akıl yürütme modelleri, modelin “düşüncelerini” nihai cevaptan ayırmak için <think> … </think> gibi şablonlar kullanır. Bazı modeller sohbet turları arasında bu akıl yürütme token’larını atar ve chat template bu mantığı yönetebilmelidir.
• Çıkarım (inference) motorlarıyla uyumlu mu olacak? vLLM ve SGLang gibi inference motorları, akıl yürütme ve araç kullanımı için özel parser’lara sahiptir. Bu parser’larla uyumluluk, özellikle tutarlı tool call’ların kritik olduğu karmaşık agent benchmark’larında, ileride birçok sorunu ortadan kaldırır.

Aşağıdaki tablo, bazı popüler chat template’leri ve bu temel kriterler açısından nasıl karşılaştırıldıklarını göstermektedir:

Çoğu durumda, ChatML veya Qwen’in sohbet şablonlarının başlamak için mükemmel bir nokta olduğunu gördük. SmolLM3 için hibrit akıl yürütme (reasoning) için bir şablona ihtiyaç duyduk ve Qwen3’ün, önem verdiğimiz boyutlar boyunca iyi bir denge kuran az sayıdaki seçenekten biri olduğunu fark ettik. Ancak tam olarak memnun olmadığımız bir tuhaflığı vardı: akıl yürütme içeriği, bir konuşmadaki yalnızca son tur hariç tüm turlar için atılıyor.

Aşağıdaki şekilde gösterildiği gibi, bu durum OpenAI’nin akıl yürütme modellerinin çalışma biçimine benzer:

Bu, çıkarım (inference) için mantıklı olsa da (bağlamın şişmesini önlemek için), eğitim açısından, modeli uygun şekilde koşullandırmak için tüm turlar boyunca akıl yürütme token’larını korumanın önemli olduğu sonucuna vardık.

Bu yüzden, aşağıdaki özelliklere sahip kendi sohbet şablonumuzu tasarlamaya karar verdik:

• Llama 3’teki ve tescilli modellerden jailbreak edilmiş olanlara benzer, yapılandırılmış bir sistem istemi. Ayrıca sistem istemini tamamen geçersiz kılma esnekliği de sunmak istedik.
• JSON araç çağrıları yapmak yerine rastgele Python kodu çalıştıran kod ajanları desteği.
• Sistem mesajı üzerinden akıl yürütme modunun açıkça kontrol edilmesi.

Sohbet şablonunun tasarımını yinelemek için Chat Template Playground’u kullandık. Hugging Face’teki meslektaşlarımız tarafından geliştirilen bu kullanışlı uygulama, mesajların nasıl render edildiğini önizlemeyi ve biçimlendirme hatalarını ayıklamayı kolaylaştırıyor. İşte nasıl göründüğü:

Bunu kendiniz de deneyebilirsiniz. Farklı örnekleri açılır menüden seçerek sohbet şablonunun çok turlu diyaloglarda, akıl yürütmede veya araç kullanımında nasıl çalıştığını görebilirsiniz. Hatta farklı davranışları etkinleştirmek için JSON girdisini manuel olarak bile değiştirebilirsiniz. Örneğin, enable_thinking: false verdiğinizde veya sistem mesajına /no_think eklediğinizde ne olduğunu görebilirsiniz.

Bazı ilk veri kümeleri ve bir sohbet şablonu üzerinde karar verdikten sonra, artık bazı başlangıç (baseline) modelleri eğitme zamanı!

Basit Başlangıç Modelleri

Optimizasyona ve performansı son noktaya kadar sıkıştırmaya geçmeden önce, bazı “basit başlangıç modelleri” (baby baselines) oluşturmamız gerekir. Bu baseline’lar henüz en iyi seviyeye ulaşmayı hedeflemez; amaç, sohbet şablonunun istediğimiz şekilde çalıştığını ve başlangıç hiperparametrelerinin stabil bir eğitim sağladığını doğrulamaktır. Ancak bu temel kurulduktan sonra hiperparametreleri ciddi şekilde ayarlamaya ve eğitim karışımlarını optimize etmeye başlarız.

SFT (Supervised Fine-Tuning) baseline’ları eğitirken dikkate alınması gereken başlıca noktalar şunlardır:

• Tam ince ayar mı (full fine-tuning) yoksa LoRA / QLoRA gibi parametre-verimli yöntemler mi kullanılacak? Thinking Machines’in harika blog yazısında açıklandığı gibi, LoRA belirli koşullarda (genellikle veri kümesi boyutuna bağlı olarak) FullFT ile benzer performans gösterebilir.
• Hangi tür paralelleştirme gerekli? Küçük modeller veya LoRA ile eğitilen modellerde genellikle veri paralelliği yeterlidir. Daha büyük modellerde ise model ağırlıklarını ve optimizer durumlarını bölmek için FSDP2 veya DeepSpeed ZeRO-3 gerekir. Uzun bağlamlı modellerde context parallelism gibi yöntemler kullanılır.
• FlashAttention ve Liger gibi kernel’ları kullanın. Donanımınız destekliyorsa bu yöntemler VRAM kullanımını ciddi şekilde azaltabilir. Bu kernel’ların birçoğu Hugging Face Hub üzerinde bulunur ve TRL’de tek bir parametreyle etkinleştirilebilir.
• Kayıp fonksiyonunu yalnızca assistant token’ları üzerinde hesaplayın. Daha sonra da tartışıldığı gibi bu, sohbet şablonunda assistant kısımlarını özel bir {% generation %} anahtarı ile sarmalayarak yapılabilir.
• Learning rate (öğrenme oranını) ayarlayın. Veri dışında, modelin “orta” mı yoksa “iyi” mi olacağını en çok belirleyen faktördür.
• Eğitim örneklerini paketleyin (packing) ve sequence length’i veri dağılımına göre ayarlayın. Bu, eğitimi ciddi şekilde hızlandırır. TRL bunu yapmak için kullanışlı bir uygulama sunar.

SmolLM3 için bu seçimlerin nasıl sonuç verdiğine bakalım. İlk baseline deneylerimizde basit bir kontrol yapmak istedik: Chat template gerçekten hibrit akıl yürütmeyi tetikliyor mu? Bunu test etmek için tablomuzdaki üç veri karışımını karşılaştırdık:

• Instruction (Yönerge): Akıl yürütme içermeyen örnekler üzerinde eğitim.
• Thinking (Düşünme): Akıl yürütme içeren örnekler üzerinde eğitim.
• Hybrid (Hibrit): Tüm örnekler üzerinde eğitim.

Her karışım için SmolLM3–3B-Base modeli üzerinde SFT eğitimi yaptık. FullFT kullandık, öğrenme oranı 1e-5, efektif batch size 128 ve 1 epoch olacak şekilde eğittik.

Çoğu model ve veri kümesi için bu hiperparametrelerin iyi bir başlangıç (baseline) oluşturduğunu gördük.

Veri kümeleri küçük olduğu için paketleme kullanmadık; dizi uzunluğu Instruction alt kümesi için 8.192 token, diğerleri için 32.768 token ile sınırladık. 8 H100 GPU’luk tek bir node üzerinde bu deneyler oldukça hızlıydı; alt kümeye bağlı olarak 30–90 dakika sürdü. Aşağıdaki grafikler, her alt kümenin ilgili akıl yürütme modundaki performansını karşılaştırmaktadır.

Bu sonuçlar bize hızla şunu gösterdi: hibrit modeller, bir tür “bölünmüş beyin” (split brain) davranışı sergiliyor; yani bir akıl yürütme modu için kullanılan veri karışımı, diğer mod üzerinde çok az etkiye sahip oluyor. Bunun kanıtı, çoğu değerlendirme testinde (eval) Instruct, Thinking ve Hybrid alt kümelerinin benzer puanlar almasıdır. İstisna olarak ise LiveCodeBench v4 ve IFEval öne çıkıyor; bu testlerde hibrit veriler, genel performansı artırıyor.

Temel Modellerinizi “Vibe-Test” Edin

Değerlendirme sonuçları (evals) genel olarak iyi görünse de, hibrit modeli farklı kişiliklerde davranmaya zorlamayı denediğimizde (örneğin, bir korsan gibi konuşmasını istediğimizde), sistem mesajına (system message) eklediğimiz talimatları sürekli olarak görmezden geldiğini fark ettik. Biraz araştırdıktan sonra, bunun nedeninin verileri biçimlendirme şeklimizden kaynaklandığını keşfettik:

Sohbet şablonumuzun tasarımında, sistem istemlerini saklamak için custom_instructions adlı bir argüman kullanıma sunduk. Örneğin, bir diyalogda bir persona’yı şu şekilde ayarlıyoruz:

from transformers import AutoTokenizer

tok = AutoTokenizer.from_pretrained("HuggingFaceTB/SmolLM3-3B")

messages = [
    {
        "content": "iPhone'umu kurmaya çalışıyorum, bana yardımcı olabilir misin?",
        "role": "user",
    },
    {
        "content": "Elbette. Bir vampir olsan bile teknoloji bazen biraz zorlayıcı olabilir. [TRUNCATED]",
        "role": "assistant",
    },
]
chat_template_kwargs = {
    "custom_instructions": "Sen vampir bir teknoloji uzmanısın.",
    "enable_thinking": False,
}
rendered_input = tok.apply_chat_template(
    messages, tokenize=False, **chat_template_kwargs
)
print(rendered_input)

## <|im_start|>system
### Meta Veriler

## Bilgi Kesim Tarihi: Haziran 2025
## Bugünün Tarihi: 28 Ekim 2025
## Akıl Yürütme Modu: /no_think

### Özel Talimatlar

## Sen vampir bir teknoloji uzmanısın.

## <|im_start|>user
## iPhone'umu kurmaya çalışıyorum, bana yardımcı olabilir misin?<|im_end|>

## <|im_start|>assistant
## <think>

## </think>
## Elbette. Bir vampir olsan bile teknoloji bazen biraz zorlayıcı olabilir. # [TRUNCATED]<|im_end|>

Sorun şu ki, veri örneklerimiz şöyle görünüyordu:

{
    "messages": [
        {
            "content": "iPhone'umu kurmaya çalışıyorum, bana yardımcı olabilir misin?",
            "role": "user",
        },
        {
            "content": "Elbette. Bir vampir olsan bile teknoloji bazen biraz zorlayıcı olabilir. [KESİLDİ]",
            "role": "assistant",
        },
    ],
    "chat_template_kwargs": {
        "custom_instructions": None,
        "enable_thinking": False,
        "python_tools": None,
        "xml_tools": None,
    },
}

İşleme kodumuzdaki bir hata, custom_instructions değerini None olarak ayarlamıştı; bu da sistem mesajını tüm eğitim örneklerinden etkili bir şekilde kaldırmıştı. Bu nedenle, bu eğitim örnekleri için güzel bir persona elde etmek yerine, SmolLM3'ün varsayılan sistem uyarı mesajıyla karşılaştık:

chat_template_kwargs = {
    "custom_instructions": None,
    "enable_thinking": False,
}
rendered_input = tok.apply_chat_template(
    messages, tokenize=False, **chat_template_kwargs
)
print(rendered_input)

## <|im_start|>system
#### Meta Veriler

## Bilgi Kesim Tarihi: Haziran 2025
## Bugünün Tarihi: 28 Ekim 2025
## Akıl Yürütme Modu: /no_think

#### Özel Talimatlar

## Sen, Hugging Face tarafından eğitilmiş, SmolLM adlı yardımcı bir yapay zekâ asistanısın.

## <|im_start|>user
## iPhone'umu kurmaya çalışıyorum, bana yardımcı olabilir misin?<|im_end|>

## <|im_start|>assistant
## <think>

## </think>
## Elbette. Bir vampir olsan bile teknoloji bazen biraz zorlayıcı olabilir. [KESİLDİ]<|im_end|>

Bu özellikle SystemChats alt kümesinde problemliydi; burada tüm persona’lar custom_instructions üzerinden tanımlanıyordu ve bu nedenle model, sohbet sırasında rastgele şekilde karakter değiştirme eğilimi gösteriyordu. Bu da bizi aşağıdaki kurala götürüyor:

Kural: Eval sonuçları iyi görünse bile modellerinizi her zaman “vibe-test” edin. Çoğu zaman eğitim verinizdeki ince hataları bu şekilde ortaya çıkarırsınız.

Bu hatayı düzeltmek eval’ler üzerinde hiçbir etki yaratmadı, ancak en sonunda chat template ve veri kümesi biçimlendirmesinin düzgün çalıştığından emin olduk.

Kurulumunuz stabil hale gelip veri işleme hattınız düzgün çalıştığında, bir sonraki adım belirli yetenekleri geliştirmeye odaklanmaktır.

Belirli Yetenekleri Hedefleme Open-R1’in geliştirilmesi sırasında, tamamen tek turlu (single-turn) akıl yürütme verisiyle bir temel model eğitmenin, çok turlu (multi-turn) akıl yürütmeye genelleme yapamadığını fark ettik. Bu şaşırtıcı değil; böyle örnekler olmadığında model, eğitim dağılımının dışında test ediliyor olur.

Bunu SmolLM3 için nicel olarak ölçmek amacıyla, Qwen3 ekibinden ilham aldık. Onlar, modelin akıl yürütme modları arasında tutarlı şekilde geçiş yapıp yapamadığını test etmek için rastgele /think veya /no_think etiketleri ekleyen ThinkFollow adlı dahili bir eval geliştirmişti. Bizim implementasyonumuzda Multi-IF promptlarını kullandık ve ardından modelin <think> ve </think> etiketleri arasında boş ya da dolu “think blokları” üretip üretmediğini kontrol ettik. Beklendiği gibi, hibrit baseline sonuçlarımız modelin ilk turun ötesinde akıl yürütme modunu etkinleştirmekte feci şekilde başarısız olduğunu gösterdi:

Bu sorunu gidermek için IFThink adında yeni bir veri kümesi oluşturduk. Multi-IF işlem hattına dayanarak, Tulu 3'ün talimat izleme alt kümesinden tek turlu talimatları kullandık ve bunları Qwen3–32B kullanarak çok turlu değişimlere genişleterek hem doğrulanabilir talimatlar hem de akıl yürütme izleri ürettik.

Çakışan talimatları filtrelemeyi düşündük, ancak ilk sonuçlar bu adımı atlamak için yeterince güçlüydü.

Yöntem aşağıda gösterilmiştir:

Bu verileri temel karışımımıza dahil etmek, önemli bir iyileşme sağladı:

IFThink ile çoklu tur akıl yürütme sorununu düzelttikten sonra, temel modelimiz sonunda amaçlandığı gibi davranmaya başladı; turlar boyunca tutarlı kaldı, talimatları takip etti ve sohbet şablonunu doğru şekilde kullandı. Bu temel oturduktan sonra, yeniden temel konulara döndük: eğitim kurulumunun kendisini ayarlamak.

Hangi hiperparametreler gerçekten önemlidir?

SFT’de (Supervised Fine-Tuning) aslında gerçekten önemli olan yalnızca birkaç hiperparametre vardır. Öğrenme oranı (learning rate), batch size ve packing, modelinizin ne kadar verimli eğitildiğini ve ne kadar iyi genelleme yaptığını neredeyse tamamen belirler. “Baby baseline” olarak kullandığımız ilk denemelerde, sadece veri kümesini ve chat template’i doğrulamak için makul varsayılan değerler seçmiştik. Artık kurulum stabil hale geldiğine göre, bu seçimleri yeniden ele alarak temel modelimiz üzerinde ne kadar etkileri olduğunu inceledik.

Kullanıcı turlarını maskeleme

Chat template için daha ince bir tasarım kararı, eğitim sırasında kullanıcı turlarının maskelenip maskelenmeyeceğidir. Çoğu sohbet tarzı veri kümesinde, her eğitim örneği kullanıcı ve asistan mesajlarının dönüşümlü dizisinden oluşur (araya yer yer araç çağrıları da girebilir). Eğer modeli tüm token’ları tahmin edecek şekilde eğitirsek, model aslında yüksek kaliteli asistan yanıtları üretmeye odaklanmak yerine kullanıcı sorgularını otomatik tamamlama davranışını öğrenir.

Aşağıdaki şekilde gösterildiği gibi, kullanıcı turlarını maskelemek bu durumu engeller; çünkü böylece modelin kaybı (loss) yalnızca asistan çıktıları üzerinde hesaplanır, kullanıcı mesajları üzerinde değil:

TRL’de, asistan belirteçlerinin maskesini döndürebilen sohbet şablonlarına maskeleme uygulanır. Pratikte bu, şablona aşağıdaki gibi bir {% generation %} anahtar kelimesi eklemeyi içerir:

{%- for message in messages -%}
  {%- if message.role == "user" -%}
    {{ "<|im_start|>" + message.role + "\n" + message.content + "<|im_end|>\n" }}
  {%- elif message.role == "assistant" -%}
{% generation %}
{{ "<|im_start|>assistant" + "\n" + message.content + "<|im_end|>\n" }}
{% endgeneration %}
  {%- endif %}
{%- endfor %}
{%- if add_generation_prompt %}
  {{ "<|im_start|>assistant\n" }}
{%- endif %}

Ardından, apply_chat_template() fonksiyonu return_assistant_tokens_mask=True parametresiyle kullanıldığında, sohbet şablonu diyalogun hangi bölümlerinin maskelenmesi gerektiğini belirtir. İşte asistan belirteçlerine 1 kimliği verilirken kullanıcı belirteçlerinin 0 kimliğiyle maskelendiğini gösteren basit bir örnek:

chat_template = '''
{%- for message in messages -%}
  {%- if message.role == "user" -%}
    {{ "<|im_start|>" + message.role + "\n" + message.content + "<|im_end|>\n" }}
  {%- elif message.role == "assistant" %}
    {% generation %}
    {{ "<|im_start|>assistant" + "\n" + message.content + "<|im_end|>\n" }}
    {% endgeneration %}
  {%- endif %}
{%- endfor %}
{%- if add_generation_prompt %}
  {{ "<|im_start|>assistant\n" }}
{%- endif %}
'''
rendered_input = tok.apply_chat_template(messages, chat_template=chat_template, return_assistant_tokens_mask=True, return_dict=True)
print(rendered_input)
## {'input_ids': [128011, 882, 198, 40, 2846, 4560, 311, 743, 709, 856, 12443, 11, 649, 499, 1520, 30, 128012, 198, 257, 128011, 78191, 198, 2173, 3388, 11, 1524, 439, 264, 51587, 11, 5557, 649, 387, 264, 2766, 315, 264, 8815, 7170, 510, 2434, 12921, 9182, 60, 128012, 271], 'attention_mask': [1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1], 'assistant_masks': [0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1, 1]}

Pratikte, maskeleme çoğu durumda sonraki değerlendirmeler üzerinde büyük bir etkiye sahip değildir ve yalnızca birkaç iyileştirme noktası sağlar. SmolLM3 ile, bunun en büyük etkisinin IFEval üzerinde olduğunu gördük; bunun nedeni muhtemelen modelin istemi tekrarlamaya daha az eğilimli olması ve çeşitli kısıtlamaları daha yakından takip etmesidir. Aşağıdaki şekiller, kullanıcı maskelemesinin her değerlendirme ve akıl yürütme modunu nasıl etkilediğini göstermektedir.

Paketlemek mi, Paketlememek mi?

Dizi paketleme (sequence packing), eğitim verimliliğinde büyük fark yaratan eğitim ayrıntılarından biridir. SFT’de (Supervised Fine-Tuning) çoğu veri kümesi değişken uzunlukta örnekler içerir; bu da her batch’in çok sayıda padding token içermesine neden olur ve bu hem hesaplama israfı yaratır hem de yakınsamayı yavaşlatır.

Paketleme, bunu çözmek için birden fazla diziyi, istenen maksimum token uzunluğuna ulaşılana kadar birleştirir. Bu birleştirme işlemini gerçekleştirmek için çeşitli yöntemler vardır; TRL ise “best-fit decreasing” (en iyi uyumlu azalan) stratejisini (Ding et al., 2024) benimser. Bu yöntemde, paketlenecek dizilerin sıralaması uzunluklarına göre belirlenir. Burada gösterildiği gibi, bu strateji batch sınırları boyunca dokümanların kırpılmasını en aza indirirken aynı zamanda padding token miktarını da azaltır:

Eğitim Sonrası ve Eğitim Öncesi Paketleme Karşılaştırması Eğitim öncesi aşamada bu aslında bir soru değil zorunluluktur. Trilyonlarca token üzerinde eğitim yaparken, önemli miktarda hesaplama gücünün dolguya harcanmasını önlemek için paketleme şarttır. Megatron-LM ve Nanotron gibi eğitim öncesi çerçeveler, paketlemeyi varsayılan olarak uygular. Eğitim sonrası aşama farklıdır. Çalışma süreleri daha kısa olduğu için, avantaj ve dezavantajlar değişir.

Paketlemenin eğitim için ne kadar verimli olduğunu anlamak için, temel veri kümemizin bir epoch’u boyunca paketleme ve paketleme yapılmaması arasındaki çalışma sürelerini karşılaştıralım:

Etkin toplu işlem boyutu 32'den sonra çalışma süresinin düzleşmesinin nedeni, bu boyutun gradyan birikimini devreye sokmadan elde edilebilecek en büyük boyut olmasıdır.

Parti büyüklüğüne bağlı olarak, paketlemenin verimliliği 3–5 kat artırdığını görüyoruz! Peki, her zaman paketleme kullanmalı mısınız? Bir ölçüde, cevap veri kümenizin ne kadar büyük olduğuna bağlıdır, çünkü paketleme, her adıma daha fazla belirteç sığdırarak her epoch başına optimizasyon adımlarının sayısını azaltır. Bunu, parti başına ortalama dolgusuz belirteç sayısını gösteren aşağıdaki şekilde görebilirsiniz:

Paketleme ile, parti başına token sayısı parti boyutuyla doğrusal olarak artar ve paketleme yapılmadan eğitime kıyasla, optimizasyon adımında 33 kata kadar daha fazla token içerebilir! Bununla birlikte, paketleme eğitim dinamiklerini biraz değiştirebilir: Genel olarak daha fazla veri işlerken, daha az gradyan güncellemesi yaparsınız, bu da nihai performansı etkileyebilir. Bu, özellikle her örneğin daha önemli olduğu küçük veri kümelerinde geçerlidir. Örneğin, aynı etkili parti boyutu olan 128'de paketleme ile paketleme yapılmaması durumunu karşılaştırırsak, IFEval gibi bazı değerlendirmelerin önemli bir performans kaybı yaşadığını görürüz:

Daha genel olarak, etkin toplu işlem boyutu 32'den büyük olduğunda, bu model ve veri kümesi için performansta ortalama bir düşüş olduğunu görüyoruz:

Pratikte, büyük ölçekli SFT (Supervised Fine-Tuning) çalışmalarında veri kümesi çok büyük olduğunda, paketleme (packing) neredeyse her zaman faydalıdır; çünkü sağladığı hesaplama tasarrufu, küçük ölçekli gradyan frekansı farklarını fazlasıyla telafi eder. Ancak küçük ölçekli veya daha heterojen veri kümelerinde, örneğin alan-özel ince ayar (domain-specific fine-tuning) ya da sınırlı sayıda insan tarafından küratörlüğü yapılmış instruction tuning veri kümelerinde, paketlemeyi kapatmak, örneklerin bütünlüğünü korumak ve her bir örneğin optimizasyona temiz şekilde katkı vermesini sağlamak açısından daha doğru olabilir.

Sonuç olarak en iyi strateji deneysel olandır: Paketlemeyi açık şekilde başlatmak, hem işlem hacmini (throughput) hem de downstream değerlendirme metriklerini izlemek ve hız kazanımlarının model kalitesine gerçekten yansıyıp yansımadığına göre ayarlama yapmak gerekir.

Öğrenme Oranının (Learning Rate) Ayarlanması

Şimdi en önemli hiperparametrelerden birine geliyoruz: öğrenme oranı (learning rate). Çok yüksek ayarlanırsa eğitim sapabilir (diverge), çok düşük olursa yakınsama (convergence) aşırı yavaş olur.

SFT’de optimal öğrenme oranı genellikle pretraining sırasında kullanılan değerden bir mertebe (veya daha fazla) daha küçüktür. Bunun nedeni, zaten zengin temsillere sahip bir modelden başlıyor olmamızdır; agresif güncellemeler “catastrophic forgetting” (felaket unutma) riskine yol açabilir.

Pretraining vs. post-training’de learning rate ayarı

Pretraining’den farklı olarak, post-training süreçleri yeterince kısa olduğu için tam kapsamlı learning rate taramaları (sweeps) yapmak mümkündür; oysa pretraining’de bu tür denemeler genellikle aşırı maliyetlidir.

Deneylerimizde “en iyi” learning rate’in model ailesine, model boyutuna ve packing kullanımına bağlı olarak değiştiğini gözlemledik. Yüksek learning rate’in gradient patlamasına yol açabilmesi nedeniyle, packing açıkken learning rate’i biraz düşürmek genellikle daha güvenlidir. Sonuçlarımız, 3e-6 veya 1e-5 gibi daha küçük LR değerlerinin daha yüksek değerlere kıyasla genel performansı daha iyi yaptığını göstermektedir.

Öğrenme oranı değerlerinin taranacağı bir aralık seçerken, [1e-6, 3e-6, 1e-5, 3e-5, 1e-4] gibi bir başlangıç ​​aralığı seçmenin faydalı olduğunu görüyoruz. Bu, iki büyüklük mertebesini kapsar ve ek ayarlamalar uygulanabilecek bir bölgeye odaklanmamızı sağlar.

Ortalama birkaç puanlık fark çok büyük görünmeyebilir, ancak bireysel benchmark’lara, örneğin AIME25’e bakıldığında, öğrenme oranı 1e-5’in üzerine çıktığında performansın ciddi şekilde düştüğü görülür.

Epoch sayısını ölçeklendirme

Ablasyon çalışmalarımızda genellikle hızlı iterasyon yapabilmek için tek epoch ile eğitim gerçekleştiriyoruz. İyi bir veri karışımı (data mixture) belirleyip öğrenme oranı gibi temel hiperparametreleri ayarladıktan sonra, bir sonraki adım final eğitim için epoch sayısını artırmaktır.

Örneğin, temel veri karışımımızı beş epoch boyunca eğittiğimizde, ortalama performansta birkaç yüzde puanlık ek bir kazanım elde etmek mümkündür:

Öğrenme oranı taramasında gördüğümüz gibi, ortalama performans bazı etkileri gizleyebiliyor; epoch sayısını ölçeklemenin bireysel değerlendirmeler üzerindeki etkisi oldukça belirgin. Örneğin LiveCodeBench v4’te genişletilmiş düşünme (extended thinking) ile, tek epoch’a kıyasla performans neredeyse iki katına çıkabiliyor.

SFT veri karışımı üzerinde iterasyon yaptıktan ve model makul bir performans seviyesine ulaştıktan sonra, bir sonraki adım genellikle daha ileri yöntemleri denemektir; örneğin tercih optimizasyonu (preference optimization) veya pekiştirmeli öğrenme (reinforcement learning). Ancak bunlara geçmeden önce, ek hesaplama bütçesinin temel modeli güçlendirmek için devam eden pretraining (continued pretraining) üzerinde harcanıp harcanmaması da değerlendirilmelidir.

Post-training’de optimizer kullanımı

Pretraining bölümünde de bahsettiğimiz gibi, önemli bir diğer bileşen optimizer’dır. Post-training için de varsayılan tercih hâlâ AdamW olmaya devam etmektedir. Açık bir soru ise, Muon gibi alternatif optimizer’larla pretrain edilmiş modellerin post-training aşamasında aynı optimizer ile mi eğitilmesi gerektiğidir. Kimi ekibi, Moonlight modeli için pretraining ve post-training’de aynı optimizer’ın kullanılmasının en iyi performansı verdiğini bulmuştur.

Reasoning’i güçlendirmek için continued pretraining

Continued pretraining, ya da daha “şık” bir ifadeyle mid-training, temel bir modeli alıp SFT’den önce büyük miktarda alan-özel token ile eğitmeye devam etmektir.

Mid-training, SFT’nin hedeflediği yetenekler ortak bir çekirdek beceriye dayanıyorsa özellikle faydalıdır; örneğin kodlama veya akıl yürütme (reasoning) gibi. Pratikte bu yaklaşım, modeli daha çok bu dağılıma kaydırarak SFT’nin hedeflediği yetenekleri daha iyi destekleyen bir başlangıç noktası oluşturur. Böylece SFT aşaması, temel becerileri sıfırdan öğretmek yerine daha çok hedef odaklı ince ayara odaklanabilir.

Mid-training yaklaşımı köklerini ULMFit’e (Howard & Ruder, 2018) dayandırır; bu çalışma, günümüz modern büyük dil modellerinde de yaygın olan üç aşamalı hattı, genel pretraining → mid-training → post-training, öncülük etmiştir. Örneğin FAIR’in Code World Model’i (team et al., 2025) gibi sistemlerde bu yaklaşım kullanılmaktadır.

Bu yaklaşım, Phi-4-Mini-Reasoning’in (Xu ve diğerleri, 2025) eğitiminde de kullanıldı, ancak bir farklılıkla: Yazarlar, web verileri üzerinde sürekli ön eğitim yapmak yerine, orta aşama eğitim veri kümesi için DeepSeek-R1'den damıtılmış akıl yürütme belirteçlerini kullandılar. Sonuçlar, çok aşamalı eğitim yoluyla tutarlı ve büyük kazanımlar göstererek oldukça etkileyiciydi:

Bu sonuçlar bizi benzer bir yaklaşımı denemeye yöneltti. Open-R1 kapsamında daha önce reasoning veri kümeleri oluşturma ve değerlendirme deneyimimize dayanarak üç ana aday üzerinde çalıştık:

• Mixture of Thoughts: Matematik, kodlama ve bilim alanlarında DeepSeek-R1’den damıtılmış 350 bin adet reasoning örneği.
• Llama-Nemotron-Post-Training-Dataset: NVIDIA’nın Llama 3 ve DeepSeek-R1 gibi çeşitli modellerden damıttığı büyük ölçekli veri kümesi. Biz bu veri kümesinifiltreleyerek DeepSeek-R1 çıktılarıyla sınırladık; bu da yaklaşık 3.64 milyon örneğe, yani 18.7 milyar tokene karşılık geldi.
• OpenThoughts3–1.2M: QwQ-32B’den damıtılmış 1.2 milyon örnek içeren ve toplamda 16.5 milyar token barındıran, en yüksek kaliteli reasoning veri kümelerinden biri.

Final SFT karışımına reasoning verisini de dahil etmeyi planladığımız için Mixture of Thoughts’u o aşama için sakladık; diğer veri kümelerini ise mid-training için kullandık. “SmolLM3” template’ini erken aşamada “belleğe kazımamak” için ChatML chat template’ini tercih ettik. Eğitim, 2e-5 öğrenme oranıyla beş epoch boyunca, sekiz node kullanılarak ve efektif batch size 128 olacak şekilde hızlandırılarak gerçekleştirildi.

Ne zaman mid-training yapılmalı?

Mid-training’i neden SFT’den sonra tartıştığımızı merak edebilirsiniz. Kronolojik olarak mid-training, base model üzerinde SFT’den önce gerçekleşir; ancak bunun faydalı olup olmayacağı çoğu zaman ancak ilk SFT deneyimlerinden sonra, performans açıkları görüldüğünde netleşir.

Pratikte genellikle iteratif bir döngü oluşur: SFT yapılır, zayıf noktalar belirlenir, hedefli mid-training uygulanır ve ardından tekrar SFT yapılır. Bu bölümü “SFT tek başına yeterli olmadığında ne yapılır?” şeklinde düşünebilirsiniz.

Eriyen GPU’ların gizemi

Bu deneyleri yürütmek cluster üzerinde beklenmedik bir zorluk ortaya çıkardı: Eski GPU’lar farklı noktalarda throttle’a giriyor, bu da donanım hatalarına ve eğitim run’larının zorunlu olarak yeniden başlatılmasına neden oluyordu. Yaşanan süreci hissettirmek için, aşağıda bir run’a ait log’lar yer alıyor; burada her renk değişimi bir restart’ı temsil ediyor:

Başlangıçta, hızlandırıcı yüksek verimlilik için optimize edildiğinden DeepSpeed’in suçlu olabileceğini düşündük. Bunu test etmek için veri paralelliğine geçtik, bu biraz yardımcı oldu, ancak daha sonra kayıp dramatik bir şekilde farklılaştı!

Gece yarısı kodunuzda hata bulmak sandığınızdan daha yaygındır. Geriye dönüp baktığımızda, bu ölçekte uzun süreli çalıştırmalar için, daha önce test edilmiş ve daha yüksek verimliliğe sahip olduğu için Nanotron’u kullanmak daha mantıklı olurdu.

Daha sonra fark ettiğimiz üzere, Hugging Face Accelerate’daki data parallelism ile ilgili bir bug, ağırlıkların ve gradient’lerin modelin yerel hassasiyetinde (bu durumda BF16) saklanmasına neden oluyordu. Bu durum, birikim (accumulation) ve optimizasyon sırasında sayısal kararsızlığa ve gradient doğruluğunun kaybına yol açtı.

Bunu önlemek için çoğu accelerator, “master weights” ve optimizer state’ler için FP32 kullanır ve yalnızca forward ve backward pass sırasında BF16’e cast eder.

Bu yüzden DeepSpeed’e geri döndük ve GPU’ların aşırı ısınması ve “bus’tan düşmesi” nedeniyle kaybedilen zamanı en aza indirmek için agresif checkpointing ekledik. Bu strateji başarılı oldu ve daha genel olarak da önerdiğimiz bir yaklaşım:

Kural

Pretraining bölümünde de vurguladığımız gibi, eğitim sırasında model checkpoint’lerini sık sık kaydetmek ve bunları uzak depolamaya (örneğin Hugging Face Hub) göndermek, yanlışlıkla üzerine yazma (overwrite) riskini önler. Ayrıca eğitim framework’ünüzün hata toleranslı olması ve otomatik yeniden başlatmayı desteklemesi de önemlidir. Bu iki strateji, özellikle mid-training gibi uzun süren işler için ciddi zaman kazandırır.

Birkaç gün boyunca run’ları “bebek bakıcısı gibi” takip ettikten sonra nihayet sonuçlarımızı elde ettik:

Genel olarak, NVIDIA’nın eğitim sonrası veri kümesinin OpenThoughts’tan daha iyi performans gösterdiğini, ancak kombinasyonun en iyi sonucu verdiğini gördük. Şimdi bu kontrol noktalarından birini alıp aynı temel veri karışımımızı uygulamanın etkisine bakalım:

Mid-trained bir reasoning modeli kullanmanın etkisi oldukça çarpıcıydı: extended thinking ile AIME25 ve LiveCodeBench v4 üzerinde performansı neredeyse üç katına çıkardık, GPQA-D ise tam 10 puanlık bir artış gördü. Daha da şaşırtıcı olan, reasoning çekirdeğinin kısmen /no_think moduna da taşınmasıydı; burada da reasoning benchmark’larında yaklaşık 4–6 puanlık iyileşmeler elde edildi.

Bu sonuçlar bize, reasoning modelleri için base model pretraining sırasında zaten yoğun reasoning verisi görmemişse, neredeyse her zaman bir miktar mid-training yapmanın anlamlı olduğunu açıkça gösterdi.

Ne zaman mid-training yapılmamalı?

Mid-training, modelin yeni bir çekirdek beceri öğrenmesi gerektiğinde oldukça etkilidir. Ancak base model zaten bu beceriyi büyük ölçüde kazanmışsa veya amaç stil üretimi ya da sohbet gibi daha yüzeysel yeteneklerse, faydası sınırlıdır. Bu durumlarda mid-training yerine compute’u başka yöntemlere, örneğin preference optimization veya reinforcement learning’e, ayırmak daha doğru olur.

Modeliniz SFT veri karışımı ve genel yetenekleri açısından yeterince olgunlaştığında, odak doğal olarak “yeni beceriler öğrenmekten” “mevcut becerileri rafine etmeye” kayar. Çoğu durumda en etkili sonraki adım preference optimization’dır.

SFT’den Preference Optimization’a: “Daha iyi”yi öğretmek

SFT’yi ölçeklemeye devam edebilirsiniz, ancak bir noktadan sonra getiriler azalır ve modelin örneğin hatalı kodunu düzeltememesi gibi problemler ortaya çıkar. Bunun nedeni SFT’nin bir tür imitation learning olmasıdır: model yalnızca eğitim verisinde gördüğü kalıpları taklit eder. Eğer veride “iyi düzeltme” örnekleri yoksa veya istenen davranış distillation ile zor yakalanıyorsa, model için “daha iyi nedir?” sorusunun net bir sinyali oluşmaz.

Sorun, veri kümesinde doğru çözüme giden ve gitmeyen trace’lerin karışık olması durumunda da devam eder. Model bu durumda, başlangıçta hata yapmanın normal olduğu gibi yanlış bir örüntüyü de öğrenebilir. Oysa istediğimiz şey, modelin en baştan doğru çözümü üretebilmesidir.

İşte burada tercih optimizasyonu (preference optimization) devreye girer. Sadece örnekleri kopyalamak yerine modele “A yanıtı B’den daha iyi” gibi karşılaştırmalı geri bildirim verilir. Bu tercih sinyali kaliteyi daha doğrudan öğretir ve SFT’nin sınırlarının ötesine geçmeyi mümkün kılar.

Ayrıca preference optimization genellikle SFT’ye kıyasla çok daha az veri gerektirir; çünkü model zaten önceki aşamalarda iyi bir başlangıç noktasına ulaşmış ve instruction-following yeteneği kazanmıştır.

Tercih Veri Kümeleri Nasıl Oluşturulur?

Tarihsel olarak preference dataset’leri, insan anotatörlere iki model yanıtı gösterilip hangisinin daha iyi olduğunun (bazen skala ile) seçtirilmesiyle oluşturulurdu. Bu yöntem hâlâ LLM sağlayıcıları tarafından kullanılıyor, ancak pahalı ve ölçeklenmesi zor.

Son dönemde LLM’lerin kaliteli çıktı üretebilmesiyle birlikte, bu süreç otomatikleştirilebilir hale geldi. Pratikte iki yaygın yaklaşım var:

Güçlü vs. Zayıf

Sabit bir x prompt kümesi alırız (genellikle kapsam ve zorluk açısından özenle seçilir). Daha zayıf veya temel bir modelden bir yanıt ve daha yüksek performanslı bir modelden başka bir yanıt üretiriz.

Daha güçlü modelin çıktısını seçilen yanıt y_c ve daha zayıf olanı reddedilen yanıt y_r olarak etiketleriz.

Bu, “güçlü vs. zayıf” karşılaştırmalarından oluşan bir veri seti üretir ({x, y_c, y_r}). Bu veri seti oluşturması oldukça basittir çünkü güçlü modelin çıktısının güvenilir biçimde daha iyi olduğunu varsayarız.

İşte Intel’den popüler bir örnek: GPT-3.5 ve GPT-4’ten gelen yanıtları içeren bir SFT veri setini alıp, GPT-4 yanıtlarını “seçilen”, GPT-3.5 yanıtlarını ise “reddedilen” olarak işaretleyerek bir tercih veri setine dönüştürmüşlerdir:

Puanlama ile Çevrimiçi Eğitim (On-Policy with Grading)

Aynı modeli (train edeceğiniz modelin kendisini) kullanarak her prompt için birden fazla aday yanıt üretin. Bu, “on-policy” bir veri kümesi oluşturur; çünkü modelin doğal olarak üreteceği çıktı dağılımını yansıtır.

Güçlü bir modeli referans almak yerine, bir harici değerlendirici (external grader) kullanılır: bu bir doğrulayıcı (verifier) ya da yanıtları bir veya birden fazla kalite ekseninde (örneğin faydalılık, gerçeklik doğruluğu gibi) puanlayan bir reward model olabilir.

Bu grader, üretilen aday yanıtlar arasında tercih etiketleri oluşturur ve böylece daha ince ayarlı ve esnek bir tercih veri kümesi elde edilir. Bu yöntem, model geliştikçe sürekli olarak yeni tercih verisi üretmeye imkân tanır; ancak kalitesi büyük ölçüde değerlendiricinin güvenilirliğine ve kalibrasyonuna bağlıdır.

Buna güzel bir örnek olarak SnorkelAI tarafından yapılan çalışma verilebilir. UltraFeedback adlı popüler bir tercih veri kümesinin istemlerini alıp bunları üç parçaya bölmüşler ve yukarıdaki yöntemi iteratif olarak uygulayarak modellerini kademeli şekilde iyileştirmişlerdir:

SmolLM3’ün geliştirilmesi sırasında, gerekçelendirme izleri (reasoning traces) içeren herhangi bir tercih verisi mevcut değildi. Bu yüzden “güçlü vs. zayıf” yaklaşımını kullanarak kendi verimizi üretmeye karar verdik. Ai2’nin Tulu 3 tercih karışımındaki istemleri kullanarak Qwen3–0.6B ve Qwen3–32B modellerinden /think modunda yanıtlar ürettik. Sonuç olarak, çok sayıda LLM tarafından üretilmiş 250 binden fazla tercih örneği içeren büyük ölçekli bir veri kümesi elde ettik. Bu veri kümesi, tercih optimizasyon algoritmaları kullanılarak SFT kontrol noktamızı (checkpoint) birden fazla eksende aynı anda iyileştirmeye hazır hale getirdi.

Hangi Algoritmayı Kullanmalısınız?

Doğrudan tercih optimizasyonu (Direct Preference Optimization, DPO) (Rafailov ve ark., 2024), açık kaynak dünyasında yaygın olarak benimsenen ilk tercih optimizasyon algoritmasıydı.

DPO makalesi 2023’ün ortalarında çıktığında, bunun RL yöntemleriyle aynı performansı verip veremeyeceği konusunda çevrimiçi ortamda hararetli tartışmalar vardı ve endüstriyel ölçekte etkinliğini gösteren herhangi bir uygulama reçetesi bulunmuyordu. Bunu ele almak için birkaç ay sonra Zephyr 7B’yi yayınladık; modeli tamamen sentetik veriler üzerinde eğittik ve DPO ile önemli performans artışları elde edilebileceğini gösterdik.

DPO’nun cazibesi; basit uygulanabilir olması, pratikte stabil çalışması ve orta miktarda tercih verisiyle bile etkili olabilmesinden geliyordu. Bu nedenle DPO, SFT modellerini geliştirmede, RL gibi daha karmaşık tekniklere geçmeden önce varsayılan yöntem haline geldi.

Ancak araştırmacılar kısa süre içinde DPO’nun geliştirilebileceği birçok yol olduğunu keşfettiler ve günümüzde keşfedilebilecek çok çeşitli alternatifler mevcut. En etkili bulduklarımızdan bazıları şunlardır:

Kahneman–Tversky optimizasyonu (KTO) (Ethayarajh ve ark., 2024): Tercih çiftlerine dayanmak yerine, insan karar verme teorisinden ilham alarak bir yanıtın “istenir” olup olmadığını modelleyen bir yaklaşımdır. Eşleştirilmiş tercih verisine (paired preference data) erişiminiz yoksa iyi bir seçenektir (ör. son kullanıcıdan 👍 veya 👎 gibi ham geri bildirimler).

Olasılık Oranı Tercih Optimizasyonu (ORPO: Odds ratio preference optimization) (Hong ve ark., 2024): Tercih optimizasyonunu doğrudan SFT sürecine entegre eder ve çapraz entropi kaybına (cross-entropy loss) odds ratio terimi ekler. Böylece referans modele veya ayrı bir SFT aşamasına ihtiyaç kalmaz ve yöntem daha hesaplama verimli hale gelir.

Çapaya (bir referansa) Bağlı Tercih Optimizasyonu (APO: Anchored preference optimization) (D’Oosterlinck ve ark., 2024): Seçilen ve reddedilen çıktılar arasındaki olasılıkların ne kadar değişmesi gerektiğini açıkça düzenleyen daha kontrollü bir amaç fonksiyonudur; yalnızca farkı optimize etmekle kalmaz. APO-zero ve APO-down olmak üzere iki varyantı vardır. Hangisinin kullanılacağı, modeliniz ile tercih verisi arasındaki ilişkiye bağlıdır; yani seçilen çıktılar modelin ürettiğinden daha iyi mi yoksa daha kötü mü olduğuna göre değişir.

Neyse ki, TRL’nin DPOTrainer’ı içinde sadece tek satırlık bir değişiklikle bu yöntemlerin çoğu arasında geçiş yapabiliyoruz. Bu yüzden başlangıç baz çizgimiz (baseline) için şu adımları izledik:

• Ai2’nin Tulu 3 Preference Personas IF veri setindeki prompt ve completion’ları kullanarak IFEval üzerinde talimat takip etme (instruction following) iyileşmelerini ölçmek (/no_think akıl yürütme modu ile).
• Aynı veri kümesindeki promptları yeniden kullanarak Qwen3–32B ve Qwen3–0.6B ile “güçlü vs. zayıf” tercih çiftleri üretmek. Bu sayede /think akıl yürütme modu için tercih verisi elde etmek.
• Bir epoch eğitim yapmak ve IFEval üzerindeki alan içi (in-domain) iyileşmeleri ile birlikte AIME25 gibi alan dışı (out-of-domain) değerlendirmelerdeki etkileri ölçmek; bunlar doğrudan talimat takip etme ile korelasyonlu.

Aşağıdaki şekilde gösterildiği gibi, her iki akıl yürütme modu için de alan içi iyileşmeler oldukça belirgindi: IFEval üzerinde APO-zero, SFT kontrol noktasına kıyasla %15–20 puanlık bir iyileşme sağladı.

APO-zero ayrıca dağıtım dışı (out-of-domain) görevlerde en iyi genel performansı gösterdiği için, kalan ablasyon deneylerimizde onu kullanmaya karar verdik.

Tercih optimizasyonu akıl yürütme için işe yarıyor Sonuçlarımızın gösterdiği gibi, tercih optimizasyonu modelleri sadece daha yardımcı veya daha hizalı hale getirmekle kalmaz; aynı zamanda daha iyi akıl yürütmeyi de öğretir. Eğer akıl yürütme modelinizi hızlıca geliştirmek istiyorsanız, “güçlü vs. zayıf” tercih çiftleri üretmeyi ve farklı kayıp fonksiyonlarını ablate etmeyi deneyin. Vanilla DPO’ya kıyasla önemli kazanımlar elde edebilirsiniz!

Tercih Optimizasyonunda Hangi Hiperparametreler En Önemlidir? Tercih optimizasyonu için, eğitim dinamiklerini etkileyen genellikle yalnızca üç hiperparametre vardır:

• Öğrenme oranı (learning rate), genellikle SFT’de kullanılan orandan 10–100× daha küçük olur.
• β parametresi, genellikle tercih çiftleri arasındaki marjın büyüklüğünü kontrol eder.
• Batch size (mini-batch boyutu).

Şimdi SmolLM3 için bunların nasıl sonuç verdiğine bakalım; smoltalk2’nin tamamı üzerinde eğittiğimiz SFT kontrol noktasından başlayacağız.

En İyi Performans İçin Küçük Öğrenme Oranları Kullanın

İlk yaptığımız ablasyon, öğrenme oranının model performansı üzerindeki etkisini incelemekti. SFT öğrenme oranına (2e-5) kıyasla yaklaşık 200× daha küçük (1e-7) ile yaklaşık 2× daha küçük (1e-5) arasındaki öğrenme oranlarının etkisini belirlemek için deneyler yaptık. Zephyr 7B gibi önceki projeler, tercih optimizasyon yöntemleri için en iyi öğrenme oranının SFT’de kullanılan orandan yaklaşık 10× daha küçük olduğunu göstermişti ve SmolLM3 için yaptığımız ablasyon çalışmaları da bu genel kuralı doğruladı.

Aşağıdaki şekilde gösterildiği gibi, yaklaşık 10× daha küçük öğrenme oranları SFT modelinin performansını her iki akıl yürütme modunda da iyileştirdi; ancak bu 10× sınırının ötesindeki tüm öğrenme oranları, genişletilmiş düşünme modunda daha kötü performansa yol açtı:

/no_think akıl yürütme modu için eğilim daha stabildir; en iyi öğrenme oranı 5e-6 olarak bulundu. Bu sonuç büyük ölçüde tek bir benchmark’tan (LiveCodeBench v4) kaynaklanıyordu, bu yüzden SmolLM3 çalışmalarımızda 1e-6 değerini tercih ettik.

Eğitim çalışmaları için önerimiz, öğrenme oranı taramalarını SFT öğrenme oranınızdan 5× ila 20× daha küçük bir aralıkta yapmanızdır. En iyi performansı büyük olasılıkla bu aralık içinde bulacaksınız!

β’yı Ayarlama

β parametresi için, referans modele ne kadar hizalanma olacağını keşfetmek amacıyla geniş bir değer aralığında (0.01’den 0.99’a kadar) deneyler yaptık. Hatırlatmak gerekirse, daha düşük değerler referans modele daha yakın kalmayı teşvik ederken, daha yüksek değerler modelin tercih verisine daha sıkı uyum sağlamasına izin verir. “Extended thinking” kullanılmadığında performans farklı β değerleri arasında genel olarak stabildi. β = 0.1 için model performansı her iki akıl yürütme modunda da en yüksekti ve SFT kontrol noktasına kıyasla iyileşme gösterdi. Daha düşük β değerleri model performansını düşürdü ve SFT kontrol noktasından daha kötü bir modelle sonuçlandı.

Bu sonuçlar, 0.1’den büyük değerlerin tercih optimizasyonu için daha uygun olduğunu ve modeli referans modele yakın tutmaktan ziyade tercih verisine hizalamanın daha faydalı olduğunu göstermektedir. Ancak, β değerlerini 0.01–0.5 aralığında keşfetmenizi öneririz. Daha yüksek değerler, SFT kontrol noktasından gelen ve grafikteki eval’larda yakalayamadığımız bazı yetenekleri silebilir.

Tercih Verisinin Ölçeklendirilmesi

Ayrıca veri kümesi boyutunun sonuçları nasıl etkilediğini belirlemek için 2k ile 340k tercih çifti arasında değişen değerler üzerinde deneyler yaptık. Bu aralık boyunca performans genel olarak stabil kaldı. Genişletilmiş düşünme (extended thinking) modunda, 100k’nin üzerindeki veri kümelerinde performans düşüşleri görüldü; ancak bu düşüş, farklı öğrenme oranlarında gördüğümüz kadar belirgin değildi. SmolLM3 eğitim çalışmasında kullandığımız veri seti 169k tercih çiftinden oluşuyordu, ancak sonuçlar daha küçük veri kümelerinin bile SFT kontrol noktasına kıyasla iyileştirme sağladığını gösterdi. Gelecek projeler için, yineleme aşamasında daha küçük veri kümeleriyle denemeler yapabileceğimizi biliyoruz; bu aşamada birden fazla fikri hızlıca test etmek ve en umut verici yapılandırmaları hızlıca belirlemek önemlidir.

Tümünü Bir Araya Getirmek

Tüm bu unsurları bir araya getirmek, nihai SmolLM3–3B modelini ortaya çıkardı: kendi boyutunda sınıfının en iyisi ve Qwen’in kendi hibrit akıl yürütme modelleriyle Pareto sınırında yer alıyor.

Muhakeme yapmayan talimat modelleri

Birkaç haftalık çalışma için fena değil!

Çalışma Kuralları (Rules of Engagement) Tercih optimizasyonu hakkında gelecekteki projeleriniz için faydalı olabilecek bulgularımızı özetlemek gerekirse:

• Kendi tercih verinizi oluşturmaktan çekinmeyin! Çıkarım (inference) maliyeti “ölçülemeyecek kadar ucuz” hale geldikçe, farklı inference sağlayıcılarından LLM tercihleri üretmek artık kolay ve maliyet-etkin.
• İlk baseline olarak DPO’yu seçin ve buradan iterasyon yapın. Veri türüne bağlı olarak ORPO, KTO veya APO gibi diğer algoritmaların DPO’ya kıyasla önemli kazanımlar sağlayabildiğini gördük.
• SFT’de kullanılan öğrenme oranından yaklaşık 10× daha küçük bir öğrenme oranı kullanın.
• β üzerinde tarama yapın; genellikle 0.01–0.5 aralığı uygundur.
• Çoğu tercih algoritması tek epoch sonrası overfit olduğu için, verinizi parçalara ayırıp iteratif şekilde eğitmek en iyi performansı verir.

Tercih optimizasyonu genellikle basitlik ve performans arasında iyi bir denge noktasıdır; ancak önemli bir sınırlamayı da beraberinde getirir: yalnızca toplayabildiğiniz offline tercih verisi kadar iyidir. Bir noktadan sonra statik veri kümeleri sinyal üretmeyi bırakır ve modelin prompt’larla ve çevreyle etkileşim kurduğu, çevrimiçi (online) yeni eğitim sinyalleri üreten yöntemlere ihtiyaç duyarsınız. İşte bu noktada tercih optimizasyonu, on-policy ve RL tabanlı yöntemlerin daha geniş ailesiyle kesişir.

On-Policy’ye Geçiş ve Denetimli Etiketlerin Ötesi Modelinizin matematik problemlerini sürekli çözmesini, çalıştırılabilir kod üretmesini veya çok adımlı planlama yapmasını istiyorsanız, çoğu zaman sadece “A, B’den iyidir” türü tercihlerden ziyade bir ödül sinyaline ihtiyaç duyarsınız.

Bu noktada RL anlamlı hale gelir. Tercihlerle modeli denetlemek yerine, modelin bir ortamla (örneğin matematik doğrulayıcı, kod çalıştırıcı veya gerçek kullanıcı geri bildirimi) etkileşime girmesine izin verir ve sonuçlardan doğrudan öğrenmesini sağlarsınız. RL özellikle şu durumlarda güçlüdür:

• Doğruluğun otomatik kontrol edilebildiği durumlar (unit testler, matematik ispatları, API çağrıları veya güçlü bir doğrulayıcı/ödül modeli varsa).
• Çok adımlı akıl yürütme veya planlama gerektiren görevler (yerel tercihler uzun vadeli başarıyı yakalayamaz)
• Tercih etiketlerinin ötesinde hedefler (örneğin kodun testleri geçmesi gibi)

LLM’lerde iki ana RL yaklaşımı vardır:

• İnsan geri bildiriminden pekiştirmeli öğrenme (RLHF): OpenAI’nin InstructGPT makalesi (Ouyang et al., 2022) ile popülerleşen bu yaklaşım, GPT-3.5 ve birçok modern LLM’in temelini oluşturur. İnsan değerlendiriciler model çıktıları arasında karşılaştırma yapar (“A, B’den daha iyi”) ve bu tercihlerden bir ödül modeli eğitilir. Daha sonra politika (policy), bu öğrenilen ödülü maksimize edecek şekilde RL ile ince ayarlanır. Ödül modeli insan tercihlerini yalnızca yaklaşık olarak öğrendiği için bazen “reward hacking” görülebilir. Örneğin model “the the the the” gibi dağılım dışı bir çıktı üretip yanlış şekilde yüksek ödül alabilir ve bu davranış RL döngüsüyle modele yerleşebilir.
• Doğrulanabilir ödüllerle pekiştirmeli öğrenme (RLVR): DeepSeek-R1 ile popülerleşen bu yaklaşımda, model çıktısını açıkça doğrulayabilen sistemler (örneğin kodun derlenip testleri geçip geçmediği veya matematik cevabının doğru olup olmadığı) kullanılır. Politika, bu doğrulanabilir geri bildirimle daha doğru çıktılar üretmek için eğitilir.

RLHF ve RLVR modelin neyi optimize ettiğini tanımlar; ancak bu optimizasyonun nasıl yapılacağı ayrı bir konudur. Pratikte RL eğitiminin verimliliği ve kararlılığı, algoritmanın on-policy mi yoksa off-policy mi olduğuna büyük ölçüde bağlıdır.

GRPO gibi yöntemler genellikle on-policy optimizasyon sınıfına girer; yani çıktıyı üreten model ile optimize edilen model aynıdır. Ancak burada bazı nüanslar vardır: üretim aşaması için birkaç batch örneklenebilir ve ardından k güncelleme yapılabilir; bu durumda ilk batch tamamen on-policy iken sonraki batch’ler hafif off-policy hale gelir.

Üretim modeli ile optimize edilen model arasındaki “policy lag”i telafi etmek için importance sampling ve clipping kullanılarak token olasılıkları yeniden ağırlıklandırılır ve güncellemelerin büyüklüğü sınırlandırılır.

Burada off-policy RL yöntemlerine girmeyeceğiz; ancak Q-learning gibi tamamen off-policy algoritmalar vardır ve bunlarda veri üreten politika ile optimize edilen politika tamamen farklı olabilir. LLM’lerde GRPO kullanıldığında üretim politikası genellikle optimizasyondaki modelden çok uzak değildir (genelde 16 adımdan az fark olur).

LLM’lerde autoregressive üretim yavaş olduğu için verl ve PipelineRL gibi framework’ler asenkron üretim ve “in-flight” ağırlık güncellemeleri ekleyerek eğitim verimini artırmıştır. Bu yöntemler daha karmaşık olsa da senkron eğitime kıyasla 4–5× daha hızlı olabilir. Bu hız kazanımı özellikle uzun kuyruk token dağılımına sahip reasoning modellerinde daha belirgindir.

SmolLM3 için zaman kısıtları ve offline tercih optimizasyonuyla zaten güçlü bir model elde ettiğimiz için RL’i tamamen atladık. Ancak yayın sonrası bu konuyu yeniden ele aldık ve sonraki bölümde öğrendiğimiz bazı dersleri paylaşacağız.

Hibrit Akıl Yürütme Modellerine RLVR Uygulamak Hibrit reasoning modelleri RLVR için ek karmaşıklık oluşturur çünkü üretim uzunluğu akıl yürütme moduna göre önemli ölçüde değişir. Örneğin aşağıdaki şekilde, SmolLM3’ün son APO kontrol noktasında AIME25 üzerindeki token uzunluğu dağılımlarını gösteriyoruz:

Gördüğünüz gibi, /no_think modu çözümleri ortalama (median) yaklaşık 2k token uzunluğunda üretirken, /think modu için ortalama uzunluk çok daha büyüktür (16k token) ve ağır kuyruklu (fat-tailed) bir dağılım gösterir. İdeal olarak, RLVR ile her iki modun genel performansını da artırmak, ancak kendi uzunluk dağılımlarını çok radikal şekilde değiştirmemek isteriz.

Bunu keşfetmek için, önce /no_think modunu optimize etmeye odaklandık; bunun için Big-Math veri kümesinden bir alt küme kullandık. Big-Math, doğrulanmış cevaplara sahip 250k’dan fazla matematik problemi içeren bir veri kümesidir.

Şaşırtıcı bir şekilde, GRPO’yu naif şekilde uygulamak bir tür reward hacking’e yol açtı: Model, uzun bir düşünce zinciri (chain of thought / CoT) üretmesi istenmediği halde, ödülü artırmak için kendi temel akıl yürütme yeteneklerini kullanarak bu ödülü “istismar etmeyi” öğrendi. Aşağıdaki şekilde gösterildiği gibi, yalnızca ödül artmakla kalmadı, aynı zamanda çıktıların uzunluğu da belirgin şekilde arttı:

SmolLM3’e RLVR’yi naif bir şekilde uygulamak, yüksek ödül ve daha iyi downstream performans elde edilmesini sağlasa da, tamamlanma (completion) uzunluklarının kontrolden çıkması gibi bir maliyet ortaya çıkardı.

Başka bir deyişle, GRPO ile RLVR, modelimizin /no_think modunu, /think moduna çok benzeyen bir hale dönüştürdü!

Model çıktıları incelendiğinde, artık uzun chain-of-thought (CoT) üretmeye başladığını ve hatta “Wait, …” gibi (Gandhi et al., 2025) çalışmalarda reasoning modelleriyle ilişkilendirilen bazı bilişsel davranışları sergilediğini gördük. Buna bir örnek aşağıda gösterilmiştir:

Ancak jogger ve tren aynı yönde hareket ettiği için, aralarındaki bağıl hız hızlarının farkıdır:

v
rel
 ​

=v
t
 ​

−v
j
 ​

=12.7778−2.7778=10m/s

Wait (bekle), hesaplamayı tekrar kontrol edeyim:

Wait (bekle), 46 km/saat → m/s dönüşümü:
46 × 1000 / 3600 = (46 × 10) / 36 = 460 / 36 ≈ 12.7778 m/s (doğru)

10 km/saat:
10 × 1000 / 3600 = 10000 / 3600 ≈ 2.7778 m/s (doğru)

Fark: 12.7778 − 2.7778 = 10 m/s (tam olarak doğru, çünkü 46 − 10 = 36 km/saat → 36 × (1000/3600) = 10 m/s)

Jogger trenin motorundan 340 metre öndedir. Tren jogger’ı geçtiğinde, trenin joggera göre kat etmesi gereken mesafe 340 metre artı trenin uzunluğu mudur? Wait, aslında problemi yeniden düşünmem gerekiyor.

Wait (bekle), aslında problem “tren jogger’ı 46 saniyede geçiyor” dediğinde genellikle trenin ön kısmının jogger’ı yakalayıp tamamen geçmesi (yani arka kısmının da geçmesi) arasındaki süreyi ifade eder. Bu durumda trenin uzunluğu, bağıl hız ile zamanın çarpımı olacaktır.

Ama önce başlangıç konumu: jogger, trenin motorunun 340 metre önünde. Yani tren, jogger’ın 340 metre gerisinde. Aynı yönde hareket ettiklerine göre tren arkadan geliyor. Jogger’ı geçmesi için trenin önce bu 340 metreyi kapatması, sonra da kendi uzunluğunu tamamen geçmesi gerekir.

Wait (bekle), yani problem şu: “A jogger running at 10 km/hr alongside a railway track is 340 m ahead of the engine of a train running at 46 km/hr in the same direction. The train takes 46 seconds to pass the jogger. How long is the train in meters?”

Hmm… o zaman jogger 340 m önde. Tren arkadan geliyor. Dolayısıyla trenin jogger’a ulaşması için önce 340 metreyi kapatması gerekiyor. Ardından da trenin tamamının jogger’ı geçmesi için kendi uzunluğu kadar daha yol alması gerekiyor.

Ödül Hilelemesini (Reward Hacking) Aşırı Uzunluk Cezaları ile Azaltma

Bu sorun, belirli bir uzunluğun üzerindeki tamamlamaları cezalandıran bir aşırı uzunluk cezası (overlong completion penalty) eklenerek hafifletilebilir. Bu ceza, iki parametre ile tanımlanır: maksimum tamamlanma uzunluğu, L_max​, ve yumuşak ceza önbelleği (soft punishment cache), L_cache​. Bu ceza, Yu ve ark. (2025) tarafından önerilen DAPO makalesindeki iyileştirmelerden biriydi ve aşağıdaki gibi bir ödül fonksiyonunun uygulanmasına karşılık gelir.

Bu cezayı kullanarak, modelin çıktı dağılımını doğrudan kontrol edebilir ve artan yanıt uzunluğu ile performans arasındaki dengeyi ölçebiliriz. Aşağıdaki şekilde, aşırı uzun yanıt cezasını 1,5k’dan 4k’ya 512 tokenlik adımlarla değiştirerek bir örnek gösterilmiştir:

Aşırı uzun bir ceza uygulamak ortalama ödülü azaltır.

Aşırı uzun bir ceza uygulamak, her bir dağıtımın süresini kısıtlar.

Yanıt süresi ve performans arasındaki denge, AIME25'teki iyileştirmeleri incelediğimizde daha net bir şekilde ortaya çıkıyor:

AIME25 üzerinde RLVR ile SmolLM3'ün aşağı yönlü performansı.

Şimdi, aşırı uzun süreli cezanın aşağı yönlü performansı nasıl etkilediğini açıkça görebiliyoruz; 2–4k aralığındaki cezalar, belirteç dağılımını kontrol altında tutarken önemli iyileştirmeler sağlıyor. Bir sonraki şekilde gösterildiği gibi, 400. adımdaki kontrol noktalarını alırsak, farklı ceza aralıklarında ilk politika ile son model arasındaki çıktı belirteç dağılımlarını karşılaştırabiliriz:

Hepsini Bir Araya Getirirsek

2,5–3k aralığında bir uzunluk cezası uygulamanın, performans ve yanıt uzunluğu arasında en iyi dengeyi sağladığını bulduk; aşağıdaki şekil, GRPO’nun AIME 2025'te APO gibi çevrimdışı yöntemlere göre performansı neredeyse iki katına çıkardığını göstermektedir:

Artık /no_think akıl yürütme modunda performansı nasıl artıracağımızı bildiğimize göre, RL eğitim hattındaki bir sonraki adım modelin her iki akıl yürütme modunda aynı anda ortak eğitilmesi olurdu. Ancak bunu oldukça zor bir problem olarak bulduk çünkü her mod kendi uzunluk cezasını (length penalty) gerektiriyor ve bu etkileşim şimdiye kadar istikrarsız eğitim üretmiş durumda. Bu durum, hibrit akıl yürütme modellerine RL uygulamaya çalışmanın temel zorluğunu ortaya koyuyor ve bunu Qwen gibi model geliştiricilerinin “instruct” ve “reasoning” varyantlarını ayrı ayrı yayınlama eğiliminde yeni bir trend olarak da görebiliyoruz.

Deneylerimiz, RLVR’nin akıl yürütme davranışını etkili biçimde yönlendirebildiğini gösteriyor; ancak yalnızca dikkatli ödül tasarımı (reward shaping) ve stabilite mekanizmaları ile. Bu karmaşıklık göz önüne alındığında, pek çok kişinin aklına şu soru geliyor: Pekiştirmeli öğrenme (RL) gerçekten tek uygulanabilir yol mu? Aslında son literatürde, on-policy optimizasyon için daha hafif yöntemler de önerildi; ancak bunlar açık kaynak topluluğu tarafından şaşırtıcı derecede az araştırılmış durumda. Şimdi bu yöntemlerden bazılarına göz atalım.

RL Tek Seçenek mi?

On-policy öğrenmeye yönelik diğer yaklaşımlar, model geliştikçe eğitim sinyalini sürekli yenileyen döngüler içinde tercih optimizasyonunu ve distilasyonu genişletir. Bunlar şunları içerir:

Online DPO: Sabit bir tercih veri kümesi üzerinde tek seferlik eğitim yapmak yerine, model sürekli olarak yeni yanıtlar üretir, yeni tercih etiketleri toplar (ödül modelleri veya LLM değerlendiricilerinden) ve kendini günceller. Bu yaklaşım optimizasyonu on-policy tutar ve eğitim verisi ile modelin güncel davranışı arasındaki sapmayı azaltır (Guo et al., 2024).

On-policy distillation: Tercihler yerine sinyal daha güçlü bir “öğretmen” modelden gelir. Öğrenci her eğitim adımında yanıtlar örnekler ve bu örnekler üzerinde öğrenci ile öğretmen logitleri arasındaki KL ayrışması (divergence) öğrenme sinyali olarak kullanılır. Bu sayede öğrenci, açık tercih etiketlerine veya doğrulayıcılara ihtiyaç duymadan öğretmenin yeteneklerini sürekli olarak özümseyebilir (Agarwal et al., 2024).

Bu yöntemler, statik tercih optimizasyonu ile tam RL arasındaki çizgiyi bulanıklaştırır: Modelin mevcut dağılımına uyum sağlamanın avantajlarını korurken, bir RL döngüsü tasarlamanın ve stabilize etmenin tüm karmaşıklığını ortadan kaldırırlar.

Hangi Yöntem Kullanılmalı?

“En iyi on-policy yöntem hangisi?” sorusuna dair sayısız araştırma makalesi olmasına rağmen, pratikte karar birkaç faktöre bağlıdır. Bunlar aşağıdaki tabloda gösterilmektedir:

Açık kaynak ekosisteminde, GRPO ve REINFORCE gibi takviyeli öğrenme yöntemleri en yaygın kullanılanlar olma eğilimindedir; ancak Qwen3 teknik raporu (A. Yang, Li, vd., 2025), 32B parametre altında modelleri eğitmek için politika tabanlı damıtma yönteminin kullanımını vurgulamıştır:

Küçük modellerle politika tabanlı damıtmanın ilginç bir özelliği, genellikle hesaplama maliyetinin çok daha düşük bir kısmıyla takviyeli öğrenme tabanlı yöntemlerden daha iyi performans göstermesidir. Bunun nedeni, her istem için birden fazla uygulama oluşturmak yerine, yalnızca bir uygulama örneklememiz ve bunun da öğretmen tarafından tek bir ileri/geri geçişte değerlendirilmesidir. Qwen3 teknik raporunun gösterdiği gibi, GRPO’ya göre kazanımlar önemli olabilir:

Son zamanlarda Thinking Machines, politika tabanlı damıtmanın, eğitilmiş bir modelin yeni bir alanda daha fazla eğitilmesi ve önceki performansının gerilemesi durumunda ortaya çıkan felaket niteliğindeki unutmayı hafifletmede de etkili olduğunu göstermiştir. Aşağıdaki tabloda, Qwen3–8b (IFEval) modelinin sohbet performansının dahili veriler üzerinde ince ayar yapıldığında ciddi şekilde düştüğünü, ancak bu davranışın ucuz damıtma ile geri kazanılabileceğini göstermektedirler:

Politika tabanlı damıtma yönteminden oldukça heyecan duyuyoruz, çünkü çok çeşitli yetenekli, açık ağırlıklı LLM’ler daha küçük, göreve özgü modellere damıtılabiliyor. Bununla birlikte, tüm politika tabanlı damıtma yöntemlerinin bir zayıf noktası, öğretmen ve öğrencinin aynı tokenleştiriciyi paylaşması gerektiğidir. Bunu ele almak için, herhangi bir öğretmenin herhangi bir öğrenciye damıtılmasını sağlayan Genel Politika Tabanlı Logit Damıtma (GOLD: General On-Policy Logit Distillation) adlı yeni bir yöntem geliştirdik. Bu konularla ilgileniyorsanız, teknik yazımızı incelemenizi öneririz.

Benzer şekilde, FAIR’deki araştırmacılar, DPO için tamamen politika dışı ve politika tabanlı olmanın etkisini karşılaştırdı ve çok daha az hesaplama kullanarak GRPO’nun performansına ulaşmanın mümkün olduğunu gösterdi (Lanchantin vd., 2025):

Makalelerinde gösterildiği gibi, çevrimiçi DPO matematiksel görevler için iyi çalışıyor ve hatta yarı-politik varyantı, politikadan birçok adım uzakta olmasına rağmen karşılaştırılabilir bir performans elde ediyor:

Genel olarak, hem RL’yi (pekiştirmeli öğrenmeyi) etkili şekilde ölçeklendirme (Khatri ve ark., 2025) hem de hesaplama verimliliği için diğer yöntemleri keşfetme konusunda hâlâ yapılacak çok şey olduğunu düşünüyoruz. Gerçekten heyecan verici zamanlar!

Post-Training’i Tamamlama

Eğer buraya kadar geldiyseniz, tebrikler: Post-training’de başarı için gerekli tüm temel bileşenlere artık sahipsiniz. Artık deneyler yapmaya ve SOTA sonuçlar elde etmek için farklı algoritmaları test etmeye hazırsınız.

Ancak muhtemelen fark etmişsinizdir ki, harika modelleri nasıl eğiteceğini bilmek hikâyenin sadece yarısı. Bu modelleri gerçekten hayata geçirmek için doğru altyapıya ihtiyacınız var. Bu bölümü, LLM eğitimindeki görünmeyen kahramana bakarak bitirelim.

8. Altyapı: Görünmeyen Kahraman

Artık model oluşturma ve eğitme hakkında bildiğimiz her şeyi biliyorsunuz; şimdi projenizi (ve bütçenizi) başarıya ya da başarısızlığa götürebilecek kritik ama genellikle göz ardı edilen bir bileşene bakalım: altyapı. İster framework’lere, ister mimariye, ister veri kürasyonuna odaklanın, altyapı temellerini anlamak eğitim darboğazlarını tespit etmeye, paralelleştirme stratejilerini optimize etmeye ve throughput (verim) sorunlarını debug etmeye yardımcı olur. (En azından, altyapı ekipleriyle iletişimi geliştirir!)

Model eğiten çoğu kişi mimari ve veriye çok önem verir, ancak çok azı altyapı ayrıntılarını gerçekten anlar. Altyapı uzmanlığı genellikle framework geliştiricilerinde ve küme (cluster) mühendislerinde bulunur ve geri kalanlar için “çözülmüş bir problem” gibi görülür: Birkaç GPU kirala, PyTorch kur, tamamdır. Biz SmolLM3’ü 384 H100 üzerinde yaklaşık bir ay boyunca eğittik ve toplamda 11 trilyon token işledik… ve bu hiç de sorunsuz bir süreç değildi! Bu süre boyunca düğüm arızaları, depolama sorunları ve eğitim yeniden başlatmalarıyla (”The Training Marathon” bölümünde anlatıldığı gibi) uğraştık. Bu tür problemlere karşı iyi acil durum planlarına ve stratejilere sahip olmanız gerekir ki eğitim süreci sorunsuz ve düşük bakım gerektiren şekilde ilerlesin.

Bu bölüm, bu bilgi boşluğunu kapatmayı amaçlıyor. Bunu, donanım katmanına odaklanan pratik bir rehber gibi düşünebilirsiniz; eğitim açısından önemli sorulara cevap verir.

İlk iki bölüm donanımın nasıl çalıştığına dair temelleri ele alır: Bir GPU aslında nelerden oluşur? Bellek hiyerarşisi nasıl çalışır? CPU ve GPU nasıl iletişim kurar? Ayrıca GPU satın alırken nelere dikkat edilmesi gerektiğini ve uzun eğitim koşularına başlamadan önce nasıl test edileceğini de ele alacağız. En önemlisi, her adımda bu sistemleri kendiniz nasıl ölçüp teşhis edebileceğinizi göstereceğiz. Sonraki bölümler daha uygulamalıdır: altyapınızı arızalara karşı nasıl dayanıklı hale getireceğinizi ve eğitim throughput’unu nasıl maksimuma çıkaracağınızı göreceksiniz.

Bu bölümün temel amacı darboğazları bulup gidermektir!

Bunu, belirli tasarım kararlarının neden önemli olduğunu anlamaya yönelik bir sezgi geliştirmek gibi düşünün. Modelinizin aktivasyonlarının farklı bant genişliği ve gecikme özelliklerine sahip çoklu cache seviyelerinden geçmesi gerektiğini anladığınızda, eğitim sürecinizi veri hareketini en aza indirecek şekilde yapılandırmayı düşünmeye başlarsınız. Düğümler arası iletişimin düğüm içi iletişimden kat kat daha yavaş olduğunu gördüğünüzde, paralelleştirme stratejilerinin neden bu kadar önemli olduğunu anlarsınız.

Şimdi bir GPU’nun içini açıp içinde ne olduğuna bakalım.

GPU’nun İçinde: Dahili Mimari

Bir GPU temelde, gecikmeden ziyade throughput (verim) için optimize edilmiş, son derece paralel bir işlemcidir. Az sayıda karmaşık komut akışını hızlı yürütmede başarılı CPU’ların aksine, GPU’lar binlerce basit işlemi aynı anda çalıştırarak performans elde eder.

GPU performansını anlamanın anahtarı, bunun sadece ham hesaplama gücü olmadığını fark etmektir; hesaplama ile veri hareketi arasındaki etkileşimdir. Bir GPU teorik olarak teraflop düzeyinde hesaplama gücüne sahip olabilir, ancak veriler hesaplama birimlerine yeterince hızlı ulaşamazsa bu potansiyel boşa gider. Bu yüzden hem bellek hiyerarşisini (veri nasıl hareket eder) hem de hesaplama işlem hatlarını (iş nasıl yapılır) anlamamız gerekir.

Basitçe söylemek gerekirse, en üst seviyede bir GPU iki temel görevi yapar:

• Veriyi taşımak ve depolamak (bellek sistemi)
• Veri üzerinde faydalı hesaplama yapmak (compute pipeline’ları)

Aşağıdaki alt bölümlerde bu denklemin iki tarafını da inceleyeceğiz: GPU’ların nasıl hesap yaptığını (FLOPs, Tensor Cores, hassasiyet) ve veriyi nasıl taşıdığını (yani bellek hiyerarşisini, High Bandwidth Memory [HBM]’den register’lara kadar).

Hesaplama Birimleri ve FLOPs

Özetle, GPU’lar performansı FLOPs (saniyedeki kayan nokta işlemleri) ile ölçer. H100 gibi modern GPU’lar düşük hassasiyette dramatik şekilde daha yüksek throughput sağlar: FP32’de 67 TFLOPs’a karşı BF16’da 990 TFLOPs. Ancak gerçek dünya performansı, bellek darboğazları nedeniyle teorik tepe değerin %70–77’sidir. SOTA eğitimde uçtan uca verimlilik %20–41 arasındadır; buna model FLOPs utilization (MFU) denir. Eğitim planlarken pazarlama rakamları değil, gerçekçi değerler kullanılmalıdır.

GPU hesaplama performansı saniyedeki kayan nokta işlemleri (FLOPs) ile ölçülür. Bir FLOP, a + b gibi tek bir aritmetik işlemdir ve modern GPU’lar saniyede trilyonlarca işlem yapabilir (TFLOPs).

GPU hesaplamasının temel yapı taşları Streaming Multiprocessors (SMs) adlı, bağımsız ve paralel çalışan işlem birimleridir. Her SM içinde iki tür çekirdek bulunur: standart kayan nokta işlemleri için CUDA Cores ve derin öğrenmede ana iş olan matris çarpımı için optimize edilmiş Tensor Cores.

Modern GPU’lar yüzlerce SM’i çip üzerinde organize eder. Örneğin, bizim kümede kullandığımız H100 SXM5 versiyonu 132 SM içerir. Her SM bağımsız çalışır ve warp adı verilen 32 iş parçacığından oluşan grupları eşzamanlı yürütür. Bunu yönetmek için SM’ler warp scheduler adı verilen bir bileşene dayanır: farklı warp’lar arasında iş yükünü dengeleyerek, bir warp beklemedeyken diğerine geçip gecikmeyi gizlerler. Bu tek talimat çoklu iplik (SIMT: single instruction, multiple threads) modeli sayesinde bir warp’taki tüm thread’ler aynı komutu farklı veriler üzerinde eşzamanlı olarak yürütür.

Çözgü iplikleri (warp’lar), Lindholm ve diğerlerinin (2008) belirttiği gibi, “ilk paralel iplik teknolojisi” olan dokumaya atıfta bulunularak adlandırılmıştır. Diğer GPU programlama modellerindeki çözgü ipliklerinin karşılığı, WebGPU’daki alt gruplar, DirectX’teki dalgalar ve Metal’deki simd gruplarıdır.

Tek bir GPU içinde birden fazla SM (kaynak: https://www.youtube.com/watch?v=ZQKMZIP3Fzg).

Yüzlerce SM’nin (Streaming Multiprocessor) her birinin aynı anda birden fazla warp çalıştırdığı düşünüldüğünde, tek bir GPU eşzamanlı olarak on binlerce iş parçacığını (thread) çalıştırabilir. GPU’ların, derin öğrenme iş yüklerinin büyük bölümünü oluşturan matris işlemlerinde bu kadar başarılı olmasını sağlayan şey de işte bu devasa paralelliktir.

FLOP’lardan söz ederken hassasiyet (precision) büyük önem taşır. Tensor Core’lar farklı hassasiyet seviyelerinde çalışabilir (FP64, FP32, FP16/BF16, FP8 ve FP4). Bu nedenle elde edilebilecek işlem hacmi (throughput), kullanılan veri türüne bağlı olarak büyük ölçüde değişir ve çoğu zaman katlarca farklılık gösterebilir. Daha düşük hassasiyetli biçimler, daha az veri aktarımı gerektirdikleri ve aynı silikon alanına daha fazla işlemi sığdırabildikleri için daha yüksek işlem hacmi sağlar. Geçmişte eğitim (training) sırasında kararsızlıklara yol açabildikleri için bunlardan kaçınılıyordu. Ancak günümüzde, çeşitli yeni teknikler sayesinde hem eğitim hem de çıkarım (inference) süreçleri giderek daha düşük hassasiyet seviyelerine, yani FP8 ve hatta FP4’e doğru yönlendirilmektedir.

FP8 karma hassasiyetli (mixed-precision) eğitim konusundaki deneyimlerimiz hakkında daha fazla bilgi edinmek isterseniz, **Ultra-Scale Playbook**’a göz atabilirsiniz.

Aşağıdaki tablo ise farklı NVIDIA GPU nesillerinde ve farklı hassasiyet seviyelerinde teorik en yüksek performansı (TFLOPs) göstermektedir:

Source: NVIDIA, SemiAnalysis

Daha düşük hassasiyet seviyelerinde işlem hacmindeki (throughput) bu çarpıcı artış yalnızca ham hızla ilgili değildir; aynı zamanda sayısal hesaplamaya bakış açımızdaki temel bir değişimi de yansıtır. FP8 ve FP4, modellerin birim watt başına ve birim zamanda daha fazla işlem gerçekleştirmesine olanak tanır. Bu nedenle, büyük ölçekli hem eğitim (training) hem de çıkarım (inference) süreçleri için vazgeçilmez hale gelmişlerdir. Örneğin, H100’ün FP8’de 3.960 TFLOPs performansa ulaşması, FP16/BF16’ye kıyasla 4 katlık bir iyileşme anlamına gelir. B200’ün FP4’te 10.000 TFLOPs değerine ulaşması ise bu ilerlemeyi daha da ileri taşımaktadır.

Ancak bu teorik en yüksek FLOPs değerlerinin, yalnızca ideal koşullar altında ulaşılabilecek azami hesaplama kapasitesini temsil ettiğini unutmamak gerekir. Bu koşullarda tüm hesaplama birimleri tamamen kullanılır ve ihtiyaç duydukları veriye anında erişebilirler. Gerçek uygulamalarda ise elde edilen performans, iş yükünüzün hesaplama birimlerini ne kadar sürekli veriyle besleyebildiğine ve işlemlerinizin mevcut donanıma ne kadar verimli şekilde eşlenebildiğine büyük ölçüde bağlıdır.

SmolLM3 modeli için eğitimi NVIDIA H100 80GB HBM3 GPU’lar üzerinde gerçekleştirmeyi planladığımızdan, öncelikle H100’ün teorik TFLOPs değerlerini gerçek dünya performansıyla karşılaştırmak istedik. Bunun için, SemiAnalysis GEMM kıyaslama (benchmark) aracını kullandık. Bu araç, Meta’nın Llama 70B eğitiminde kullanılan gerçek matris çarpımı (matrix multiplication) boyutları üzerinde işlem hacmini ölçmektedir.

Aşağıdaki tablo, Llama 70B eğitim iş yükündeki matris boyutlarına ve kullanılan hassasiyet seviyesine bağlı olarak H100 80GB GPU’larda elde edilen gerçek TFLOPs değerlerini göstermektedir:

Teorik Performansın Doğrulanması

Deneylerimiz, teorik tepe performans ile pratikte ulaşılabilen performans arasındaki farkı ortaya koydu. FP64 Tensor Core işlemleri için 49–56 TFLOPs elde ettik; bu da teorik tepe değer olan 67 TFLOPs’un %74–84’üne karşılık geliyor. TF32 (TensorFloat-32; PyTorch’un Tensor Core’larda FP32 tensörleri için varsayılan olarak kullandığı format) için ise 356–396 TFLOPs elde ettik ve bu da teorik tepe değerin (~495 TFLOPs, yoğun/dense işlem) %72–80’ine karşılık geliyor. Bu sonuçlar donanımın oldukça verimli kullanıldığını gösterse de, bu hassasiyet seviyeleri günümüz derin öğrenme eğitimlerinde nadiren tercih edilir: FP64 yüksek hesaplama maliyeti nedeniyle, TF32 ise BF16 ve FP8 gibi daha düşük hassasiyetlerin daha iyi performans sunması nedeniyle.

NVIDIA teknik özelliklerinde sıklıkla seyrek (sparse) performans değerleri verilir (TF32 için 989 TFLOPs). Bu değerler, 2:4 yapılandırılmış seyreklik (structured sparsity) desenlerinin kullanıldığını varsayar. Oysa bizim ölçtüğümüz yoğun (dense) işlemler, seyrek tepe performansın yaklaşık yarısına (~495 TFLOPs) ulaşabilir.

BF16 işlemlerinde ise farklı matris boyutlarında sürekli olarak 714–758 TFLOPs elde ettik; bu da H100’ün teorik 990 TFLOPs tepe performansının yaklaşık %72–77’sine karşılık geliyor. Pratikte bu, gerçek dünya iş yükleri için son derece yüksek bir donanım kullanım oranıdır.

Model FLOPs Kullanımı

Çekirdek (kernel) seviyesindeki kıyaslamalar ham TFLOPs değerlerini ölçerken, uçtan uca eğitim verimliliği Model FLOPs Utilization (MFU) ile ifade edilir. MFU, model tarafından gerçekleştirilen faydalı hesaplamaların teorik donanım tepe performansına oranıdır.

BF16 matmul kıyaslamalarımız, H100’ün teorik tepe performansının %72–77’sine ulaştığımızı gösterdi. Bu değer, kurulumumuzda çekirdek düzeyinde erişilebilecek üst sınırı temsil eder. Ancak uçtan uca eğitimde MFU bunun altında kalacaktır; çünkü matmul dışındaki işlemler, iletişim gecikmeleri ve diğer yardımcı hesaplamalar da toplam süreyi etkiler.

Eğitim sırasında güncel en yüksek MFU değerleri şöyledir: Meta, Llama 3 405B modelini eğitirken %38–41 MFU elde ederken, DeepSeek-V3 ise MoE mimarisine bağlı daha yoğun iletişim darboğazları nedeniyle GPU’larda yaklaşık %20–30 MFU’ya ulaşmıştır. SmolLM3 için ise daha sonra göreceğiniz gibi yaklaşık %30 MFU elde ettik. Bu farkın önemli bir kısmı, dağıtık eğitimde düğümler arası (internode) iletişim yükünden kaynaklanmaktadır. Çekirdek seviyesinde yaklaşık %77’lik üst sınır göz önüne alındığında, bu uçtan uca sonuçlar erişilebilir matmul performansına göre yaklaşık %50–55 verimliliğe karşılık gelir. Çıkarım (inference) iş yükleri ise daha yüksek MFU değerlerine (%70’in üzerinde, ham matmul performansına daha yakın) ulaşabilir; ancak üretim ortamlarından yayımlanmış sonuçlar sınırlıdır.

FP8 sonuçları ise daha karmaşıktır. Bunun için üç farklı matris çarpımı yöntemi/çekirdeği (kernel) üzerinde elde ettiğimiz sonuçlara bakalım.

Kernel, CUDA kodunun temel yürütme birimidir.

PyTorch’un torch._scaled_mm çekirdeğini e4m3 hassasiyetiyle kullandığımızda, matris boyutuna bağlı olarak 1.210–1.457 TFLOPs elde ettik; bu da teorik 3.960 TFLOPs tepe performansının yaklaşık %31–37’sine karşılık geliyor. Bunun nedeni nedir? FP8’de görülen bu daha düşük kullanım oranı aslında kötü performans anlamına gelmez. Hesaplama kapasitesi arttıkça işlemler giderek bellek bant genişliği tarafından sınırlandırılır (memory-bound). Tensor Core’lar FP8 verilerini, bellek sisteminin sağlayabileceğinden daha hızlı işleyebilir; dolayısıyla sınırlayıcı unsur hesaplama değil, bellek bant genişliğidir.

Transformer Engine’in TE.Linear çekirdeği, matris şekline bağlı olarak 547–1.121 TFLOPs elde ederken, torch._scaled_mm sürekli olarak daha yüksek aktarım hızı sağladı. Bu durum önemli bir gerçeği ortaya koyuyor: Kernel implementasyonu önemlidir ve aynı donanım yeteneklerini hedeflese bile kullanılan API seçimi performansı 2–3 kat etkileyebilir.

SmolLM3 eğitimi sırasında bu pratik ölçümler, gerçekçi aktarım hızı beklentileri belirlememize yardımcı oldu. Kendi eğitim çalışmalarınızı planlarken teorik tepe değerleri değil, pratikte ulaşılabilen değerleri esas almanız önemlidir.

Hesaplama Yeteneği

Doğru kernel API’sini seçmenin yanı sıra, bu kernel’ların doğru donanım nesli için derlenmiş olduğundan da emin olmak gerekir. Compute Capability (CC), NVIDIA’nın fiziksel GPU ayrıntılarını PTX komut kümesinden soyutlayan sürümleme sistemidir. GPU’nuzun hangi komutları ve özellikleri desteklediğini belirler.

Bunun önemi şudur: Belirli bir compute capability için derlenen kernel’lar eski donanımlarda çalışmayabilir ve kodunuz hedef GPU’nuzun CC sürümü için derlenmemişse önemli optimizasyonları kaçırabilirsiniz. Daha da kötüsü, bazı çerçeveler sessizce daha düşük performanslı kernel’ları seçebilir. Biz, PyTorch’un H100 GPU’larımız üzerinde Turing mimarisi için tasarlanmış sm_75 (compute capability 7.5) kernel’larını seçtiğini ve bunun gizemli yavaşlamalara yol açtığını gözlemledik. PyTorch topluluğunda da benzer şekilde, çerçevelerin çoğu zaman en uygun kernel yerine daha eski fakat daha uyumlu kernel’ları varsayılan olarak seçtiği belgelenmiştir. Görünüşte küçük olan bu ayrıntı, aynı donanımdan 720 TFLOPs yerine yalnızca 500 TFLOPs elde etmenize neden olabilir.

Önceden derlenmiş kütüphaneler veya özel kernel’lar kullanırken, bunların donanımınızın compute capability sürümü için derlendiğini mutlaka doğrulayın. Örneğin, sm90_xmma_gemm_..._cublas ifadesi, SM 9.0 (compute capability 9.0, H100’de kullanılan sürüm) için derlenmiş bir kernel’ı ifade eder.

GPU’nuzun compute capability değerini nvidia-smi --query-gpu=compute_cap komutuyla kontrol edebilir veya NVIDIA CUDA C Programming Guide içindeki Compute Capability bölümünde teknik özelliklerini inceleyebilirsiniz.

Gördüğümüz gibi, düşük hassasiyetlerde hesaplamalar çok hızlandığında GPU belleği bir darboğaz hâline gelebiliyor. Şimdi GPU belleğinin nasıl çalıştığına ve bu darboğazların neden oluştuğuna daha yakından bakalım.

GPU Bellek Hiyerarşisi: Register’lardan HBM’e

Özetle: GPU’lar belleği, hızlı ancak küçük kapasiteliden (register’lar ve shared memory) yavaş ancak büyük kapasiteliye (HBM ana belleği) doğru hiyerarşik olarak düzenler. Bu yapıyı anlamak kritik öneme sahiptir; çünkü modern yapay zekâ uygulamalarında darboğaz çoğu zaman hesaplama değil, verinin taşınmasıdır (memory-bound). Flash Attention gibi operator fusion teknikleri, ara sonuçları yavaş HBM’e yazmak yerine hızlı çip içi bellekte tutarak 2–4 kat hızlanma sağlayabilir. Kıyaslama sonuçları, H100’ün HBM3 belleğinin büyük veri aktarımlarında pratikte yaklaşık 3 TB/s bant genişliği sunduğunu ve bunun teorik özelliklerle uyumlu olduğunu göstermektedir.

Yüksek performanslı kernel’lar geliştirmek için GPU bellek hiyerarşisini anlamak büyük önem taşır. Hesaplama yapabilmek için GPU’ların sürekli olarak bellekten veri okuması ve belleğe veri yazması gerekir; bu nedenle bu veri transferlerinin hangi hızlarda gerçekleştiğini bilmek önemlidir.

Bellek işlemlerinin pratikte GPU içinde nasıl ilerlediğini görselleştirmek için önce NVIDIA Nsight Compute aracındaki Memory Chart’a bakalım. Bu profil oluşturma grafiği, seçtiğiniz herhangi bir kernel için verilerin farklı bellek birimleri arasında nasıl hareket ettiğini grafiksel olarak gösterir.

H100 üzerinde FP64 matris çarpımı sırasında GPU bellek hiyerarşisi üzerinden veri akışını gösteren bellek şeması.

Özetle, Memory Chart (Bellek Diyagramı) hem mantıksal birimleri (yeşil renkte) hem de fiziksel birimleri (mavi renkte) gösterir. Mantıksal birimler arasında Global, Local, Texture, Surface ve Shared bellekler bulunurken; fiziksel birimler arasında L1/TEX Cache, Shared Memory, L2 Cache ve Device Memory yer alır. Birimler arasındaki bağlantılar, bu birimler arasında gerçekleşen komut (Inst) veya istek (Req) sayılarını temsil eder. Bağlantıların renkleri ise ilgili yolun tepe kapasitesinin ne kadar kullanıldığını gösterir; kullanım oranı hiç kullanılmayan (%0) durumdan maksimum performansta çalışan (%100) duruma kadar değişir.

Herhangi bir kernel için bu Memory Chart diyagramını NVIDIA Nsight Compute kullanarak oluşturabilirsiniz.

## Profile a specific kernel with memory workload analysis
ncu --set full --kernel-name "your_kernel_name" --launch-skip 0 --launch-count 1 python your_script.py
## Once profiling is complete, open the results in the Nsight Compute GUI to view the Memory Chart

Bu grafik şu açılardan önemli içgörüler sağlar:

Darboğaz tespiti: Kırmızı/turuncu olarak görülen doygun bağlantılar, veri hareketinin hangi noktada kısıtlandığını gösterir. Bu bölgeler, performans sınırlayıcı “darboğaz”ların nerede oluştuğunu doğrudan ortaya koyar.

Önbellek verimliliği: L1/TEX ve L2 cache için hit rate (isabet oranları), çekirdeğin bellek hiyerarşisini ne kadar etkili kullandığını gösterir. Yüksek isabet oranı, daha az yavaş bellek erişimi anlamına gelir.

Bellek erişim desenleri: Mantıksal ve fiziksel birimler arasındaki veri akışı, kernel’in uzamsal (spatial) ve zamansal (temporal) lokaliteyi ne kadar iyi kullandığını ortaya koyar. İyi tasarlanmış erişim desenleri, gereksiz bellek trafiğini azaltır.

Port kullanımı: Bazen toplam bant genişliği tam kullanılmıyor gibi görünse bile, belirli bellek portları tamamen doygun olabilir. Bu durum, gizli bir performans sınırına işaret eder.

Bizim özel durumumuzda, FP64 matris çarpımı için kernel talimatlarının bellek hiyerarşisi boyunca nasıl aktığını görebilirsiniz: Global load komutları önce L1/TEX cache’e istek üretir; burada isabet olursa veri doğrudan alınır, isabet olmazsa L2’ye ek istek gider. L2’de de bulunamazsa en sonunda device memory (HBM) üzerinden veri çekilir. Birimler içindeki renkli kutular port kullanımını gösterir; bağlantılar tek tek düşük kullanımda görünse bile, paylaşılan veri portu tamamen doygun hale gelebilir.

Şimdi bu grafiği mümkün kılan temel bellek hiyerarşisine bakalım. Modern GPU’lar belleği hız, kapasite ve maliyet arasında bir denge kuracak şekilde katmanlı (hierarchical) olarak organize eder; bu tasarım fiziksel sınırlar ve devre mimarisi kısıtları tarafından belirlenir.

Bellek hiyerarşisini optimize etme

En iyi performans için hedef, yavaş bellek katmanlarına (HBM) giden trafiği azaltmak ve hızlı katmanların (shared memory, register’lar) kullanımını en üst düzeye çıkarmaktır.

H100 (SXM5) GPU’nun bellek hiyerarşisi (kaynak: Aleksa Gordić’in “Inside NVIDIA GPUs” kitabı).

Bu bellek hiyerarşisinin en altında HBM (High Bandwidth Memory) yer alır: GPU’nun ana belleği, aynı zamanda global memory veya device memory olarak da adlandırılır. H100, teorik olarak 3.35 TB/s bant genişliğine sahip HBM3 kullanır. HBM, bellek hiyerarşisinin en büyük fakat en yavaş katmanıdır.

Hiyerarşide yukarı doğru ilerledikçe, hesaplama birimlerine daha yakın oldukça daha hızlı fakat daha küçük bellek katmanlarıyla karşılaşırız:

L2 cache: GPU genelinde paylaşılan, SRAM tabanlı büyük bir önbellektir. Genellikle onlarca megabayt büyüklüğündedir. H100 üzerinde 50 MB kapasiteye ve yaklaşık 13 TB/s bant genişliğine sahiptir.

L1 cache ve shared memory (SMEM): Her Streaming Multiprocessor (SM), kendi L1 önbelleğine ve programcı tarafından yönetilen shared memory alanına sahiptir. Bu iki yapı aynı fiziksel SRAM alanını paylaşır. H100’de bu birleşik alan SM başına 256 KB’tır ve yaklaşık 31 TB/s bant genişliği sunar.

Register memory (RMEM): Hiyerarşinin en üstünde register’lar yer alır. Bunlar hesaplama birimlerinin hemen yanında bulunan en hızlı depolama alanıdır. Register’lar her thread’e özeldir ve SM başına yaklaşık 100 TB/s seviyesinde etkin bant genişliği sağlar.

Bu hiyerarşi, SRAM’in (cache ve register’larda kullanılan) hızlı ancak fiziksel olarak pahalı ve büyük ölçeklenmesi zor bir teknoloji olmasından; DRAM’in (HBM’de kullanılan) ise yoğun ve ucuz ancak daha yavaş olmasından kaynaklanır. Sonuç olarak, hızlı bellek küçük miktarlarda hesaplama birimlerine yakın konumlanırken, daha büyük ve daha yavaş bellek katmanları daha uzakta yer alır.

Neden Bu Önemli?

Bu hiyerarşiyi anlamak kernel optimizasyonu için kritik öneme sahiptir. Temel fikir şudur: memory-bound (bellek sınırlı) işlemlerde darboğaz hesaplama değil, veri taşımadır. Horace He’nin “Making Deep Learning Go Brrrr from First Principles” çalışmasında vurguladığı gibi, bellekten yükleme → iki kez çarpma → belleğe yazma işlemi ile bellekten yükleme → bir kez çarpma → belleğe yazma işlemi neredeyse aynı sürede gerçekleşir. Yani hesaplama maliyeti, bellek erişimine kıyasla “neredeyse ücretsizdir”.

Bu nedenle operator fusion çok güçlü bir tekniktir: Birden fazla işlemi tek bir kernel içinde birleştirerek ara sonuçları HBM’e yazmak yerine SRAM’de tutmak mümkündür. Böylece bellek trafiği ciddi şekilde azaltılır. Flash Attention bu prensibin en iyi örneklerinden biridir.

Flash Attention: Bellek Hiyerarşisi Optimizasyonuna Bir Örnek

Standart attention implementasyonları memory-bound’dur çünkü tam attention matrisini HBM’de materialize eder:

• Q @ K^T hesaplanır → N × N attention skorları HBM’e yazılır
• Softmax uygulanır → HBM’den okunur, hesaplanır, tekrar HBM’e yazılır
• V ile çarpım yapılır → attention skorları yeniden HBM’den okunur

Flash Attention, bu işlemleri fusion ederek ve intermediate sonuçları SRAM’de tutarak 2–4 kat hızlanma elde eder:

• Tam attention matrisi hesaplanmaz, bunun yerine SRAM’e sığan tile’lar halinde işlenir
• Ara attention skorları hiçbir zaman yavaş HBM’e yazılmaz
• Sadece final çıktı HBM’e geri yazılır

Sonuç olarak Flash Attention, HBM erişimini O(N²)’den O(N) seviyesine indirir ve bu sayede memory-bound bir işlemi GPU’nun compute kapasitesini daha verimli kullanan bir yapıya dönüştürür. Bu, kernel tasarımının özünü oluşturur: yavaş bellek erişimini minimize etmek, hızlı hesaplamayı maksimize etmek.

Örnek: HBM3 Bant Genişliğinin Pratikte Doğrulanması

Artık bellek hiyerarşisini anladığımıza göre, teoriyi pratikle doğrulayabiliriz. Bu noktada benchmark araçları kritik hale gelir.

NVBandwidth, NVIDIA’nın açık kaynaklı bir bant genişliği ölçüm aracıdır. GPU sistemlerinde veri transfer hızlarını ve gecikmeleri ölçmek için tasarlanmıştır. Host-to-device, device-to-host ve device-to-device transferlerini farklı kopyalama modelleriyle test eder. Ayrıca NVLink ve PCIe gibi çoklu GPU iletişimini analiz etmek için de kullanılır.

Araç, özellikle çoklu GPU sistemlerinde performans darboğazlarını tespit etmek ve interconnect verimliliğini doğrulamak için oldukça faydalıdır.

NVBandwidth’i NVIDIA’nın GitHub deposundan kurabilirsiniz. Araç, farklı cihazlar arasındaki veri transfer verimliliğini gösteren ayrıntılı bant genişliği matrisleri üretir ve bu sayede GPU iletişim altyapısını analiz etmek için ideal bir çözüm sunar.

H100’ün yerel bellek bant genişliğini ölçmek için device_local_copy testi kullanılabilir. Bu test, farklı mesaj boyutları üzerinden GPU içi buffer’lar arasında yapılan cuMemcpyAsync işlemlerinin bant genişliğini ölçer.

$ ./nvbandwidth -t device_local_copy -b 2048
memcpy local GPU(column) bandwidth (GB/s)
           0         1         2         3         4         5         6         7
 0   1519.07   1518.93   1519.07   1519.60   1519.13   1518.86   1519.13   1519.33

cuMemcpyAsync, iki bellek işaretçisi arasında veri kopyalama işlemini eşzamansız olarak gerçekleştiren ve aktarım türünü (ana bilgisayardan ana bilgisayara, ana bilgisayardan cihaza, cihazdan cihaza veya cihazdan ana bilgisayara) çıkarsayan bir CUDA sürücü API fonksiyonudur.

Ölçülen H100 yerel bellek bant genişliği

Sonuçlar bellek sistemlerinin önemli bir özelliğini ortaya koyuyor: Küçük mesaj boyutları (< 1 MB) için bant genişliğiyle sınırlı (bandwidth-bound) değil, gecikme (latency-bound) ile sınırlıyız. Bellek transferlerini başlatma maliyeti performansa baskın gelir ve bizi tepe bant genişliğine ulaşmaktan alıkoyar. Ancak büyük mesaj boyutları (≥ 1 MB) için hem okuma hem yazma işlemlerinde ~1.500 GB/s seviyesinde sürdürülebilir bant genişliğine ulaşırız.

HBM bant genişliği hem eş zamanlı okuma hem de yazma işlemlerini kapsadığından, bunları toplayarak toplam çift yönlü bant genişliğini 3 TB/s olarak elde ederiz (1.519 okuma + 1.519 yazma). Bu değer, H100’ün teorik 3,35 TB/s HBM3 spesifikasyonunu büyük ölçüde doğrular.

Roofline modeli

Bir kernel’in compute-bound (hesaplama sınırlı) mı yoksa memory-bound (bellek sınırlı) mı olduğunu anlamak, hangi optimizasyonların işe yarayacağını belirler. İki senaryo vardır:

1. Eğer memory-bound iseniz (zamanın çoğunu veri taşımaya harcıyorsanız), hesaplama throughput’unu artırmak yardımcı olmaz: operatör füzyonu gibi tekniklerle bellek trafiğini azaltmanız gerekir.
2. Eğer compute-bound iseniz (zamanın çoğunu FLOP işlemlerinde harcıyorsanız), bellek erişim desenlerini optimize etmek yardımcı olmaz: daha fazla hesaplama gücüne veya daha iyi algoritmalara ihtiyacınız vardır.

Roofline modeli, bu performans özelliklerini anlamak ve optimizasyon fırsatlarını belirlemek için görsel bir çerçeve sunar. Daha önce bahsettiğimiz Nsight Compute profil aracında bir roofline görünümü de mevcuttur. Kernel’imize uyguladığımızda elde ettiğimiz sonuç şöyledir:

Çekirdek performans sınırlarını gösteren çatı çizgisi grafiği (kaynak: NVIDIA Nsight Hesaplama Profili Oluşturma Kılavuzu).

Bu grafiği nasıl okuyacağımıza bakalım. İki ekseni vardır:

• Dikey eksen (Performans), elde edilen FLOP sayısını gösterir ve çok geniş bir değer aralığını kapsamak için logaritmik ölçek kullanır.
• Yatay eksen (Aritmetik Yoğunluk), iş miktarının bellek trafiğine oranını temsil eder ve FLOP/bayt cinsinden ölçülür. Bu eksen de yine logaritmik ölçek kullanır.

Roofline (çatı çizgisi) iki sınırdan oluşur:

• Bellek bant genişliği sınırı (eğimli çizgi), GPU’nun bellek aktarım hızına (HBM bant genişliği) bağlıdır. Bu çizgi üzerindeki performans, verinin ne kadar hızlı taşınabildiğiyle sınırlıdır.
• Tepe performans sınırı (yatay çizgi), GPU’nun maksimum hesaplama kapasitesiyle belirlenir. Bu çizgi üzerindeki performans, işlemlerin ne kadar hızlı yürütülebildiğiyle sınırlıdır.

Bu sınırların kesiştiği “ridge point”, bellek sınırlı (memory-bound) ve hesaplama sınırlı (compute-bound) rejimler arasındaki geçişi temsil eder.

Performansı, grafiğin iki bölgesine bakarak yorumlayabiliriz:

Bellek sınırlı bölgedeki kernel’ler (eğimli sınırın altında kalanlar) bellek bant genişliğiyle sınırlıdır. GPU veriyi bekler; hesaplama gücünü artırmak işe yaramaz. Optimizasyonlar, operator fusion (operatör birleştirme), daha iyi bellek erişim desenleri veya aritmetik yoğunluğu artırma gibi yöntemlerle bellek trafiğini azaltmaya odaklanmalıdır.

Hesaplama sınırlı bölgedeki kernel’ler (yatay sınırın altında kalanlar) hesaplama kapasitesiyle sınırlıdır. GPU yeterli veriye sahiptir ama yeterince hızlı işleyemez. Optimizasyonlar algoritmik iyileştirmelere veya Tensor Core gibi özel donanımların kullanımına odaklanmalıdır.

Elde edilen değer (grafikteki nokta), kernel’inin şu anda nerede durduğunu gösterir. Bu noktanın roofline sınırına uzaklığı, optimizasyon potansiyelini (headroom) temsil eder: Sınıra ne kadar yakınsa, performans o kadar optimaldir.

Örneğimizde kernel, bellek sınırlı bölgede yer alır; bu da bellek trafiğini optimize ederek hâlâ iyileştirme yapılabileceğini gösterir.

GPU iç yapısına daha derin bir bakış için (CUDA çekirdekleri, Tensor Core’lar, bellek hiyerarşileri ve düşük seviyeli optimizasyon teknikleri dahil) Ultra-Scale Playbook’a göz atabilirsiniz.

Artık GPU içinde neler olduğunu anladığımıza göre, biraz uzaklaşıp GPU’ların dış dünyayla nasıl iletişim kurduğuna bakalım.

GPU’nun dışı: GPU’lar dünyayla nasıl konuşur?

GPU’nun iç bellek hiyerarşisiyle nasıl hesaplama yaptığını gördük, ancak burada kritik bir gerçeği ele almamız gerekiyor: GPU tek başına çalışan bir sistem değildir. Herhangi bir hesaplama başlamadan önce verinin GPU belleğine yüklenmesi gerekir. CPU kernel’leri planlar ve işleri koordine eder. Dağıtık eğitimde ise GPU’lar sürekli olarak aktivasyonları, gradyanları ve model ağırlıklarını birbirleriyle paylaşır.

Bu nedenle dış iletişim altyapısı kritik öneme sahiptir. GPU’nun hesaplama birimleri ne kadar güçlü olursa olsun, veri CPU’dan, depolamadan veya diğer GPU’lardan yeterince hızlı gelmiyorsa pahalı donanım boşta kalır. Bu iletişim yollarını ve bant genişliği özelliklerini anlamak, darboğazları tespit etmek için gereklidir.

Bu bölümde GPU’yu dış dünyaya bağlayan dört kritik iletişim kanalına bakacağız:

• CPU–GPU (CPU’nun işleri nasıl planladığı ve GPU’ya veri aktardığı)
• GPU–GPU aynı makine içi (intranode) iletişim
• GPU–GPU farklı makine (internode) iletişim (ağ üzerinden)
• GPU–depolama (verinin depolamadan GPU belleğine akışı)

Bu bağlantıların her biri farklı bant genişliği ve gecikme özelliklerine sahiptir. Bunları anlamak, eğitim hattınızın nerede tıkandığını belirlemenize yardımcı olur. Bunu daha anlaşılır kılmak için en önemli bileşenleri ve iletişim bağlantılarını gösteren basitleştirilmiş bir diyagram oluşturduk:

AWS P5 örneğimizdeki temel bileşenlerin ve iletişim bağlantılarının basitleştirilmiş şeması.

Eğer bu ilk bakışta göz korkutucu geliyorsa endişelenmeyin. Bu bağlantıların her birine tek tek gireceğiz ve performans özelliklerini anlamak için gerçek bant genişliklerini ölçeceğiz.

CPU–GPU İletişimi

Özetle CPU, GPU işlerini PCIe bağlantıları üzerinden koordine eder. P5 instance’ımızda CPU–GPU veri transferleri PCIe Gen4 x8 ile yaklaşık 14.2 GB/s seviyesinde tıkanır. CPU–GPU gecikmesi yaklaşık 1.4 mikro saniye (μs) civarındadır ve bu da özellikle çok sayıda küçük kernel içeren iş yüklerinde kernel başlatma gecikmesi (overhead) oluşturur. CUDA Graphs, işlemleri toplu hale getirerek bu overhead’i azaltabilir. Çok soketli sistemlerde NUMA affinity kritik öneme sahiptir; işlemleri yanlış CPU soketinde çalıştırmak gecikmeyi ciddi şekilde artırır. Grace Hopper gibi modern mimariler ise PCIe sınırlarını kaldırarak NVLink-C2C (900 GB/s vs. 128 GB/s) ile çok daha yüksek bant genişliği sunar.

CPU, GPU hesaplamasının orkestratörüdür. Kernel başlatma, bellek tahsisi ve veri transferlerinin koordinasyonundan sorumludur. Ancak CPU’nun GPU ile ne kadar hızlı konuşabildiği, aralarındaki PCIe (Peripheral Component Interconnect Express) bağlantısına bağlıdır.

Bu bağlantıyı anlamak kritiktir çünkü şu alanları doğrudan etkiler:

• Kernel başlatma gecikmesi (CPU’nun GPU’ya işi ne kadar hızlı verebildiği)
• Veri transfer hızı (CPU ve GPU bellekleri arasında verinin ne kadar hızlı taşındığı)
• Senkronizasyon maliyeti (CPU–GPU koordinasyon noktalarının maliyeti)

Modern GPU sunucularında CPU–GPU bağlantısı zaman içinde ciddi şekilde evrim geçirmiştir. Daha eski sistemlerde doğrudan PCIe bağlantıları kullanılırken, günümüzün yüksek performanslı sistemleri (örneğin DGX H100) birden fazla GPU’yu verimli şekilde yönetmek için PCIe switch’li daha karmaşık topolojiler kullanır. En yeni GB200 mimarisi ise CPU ve GPU’yu aynı baskı devre üzerine yerleştirerek dış switch ihtiyacını tamamen ortadan kaldırır.

Şimdi P5 instance’ımızın fiziksel topolojisini lstopo ile inceleyelim ve bu kritik bağlantının gerçek performansını ölçerek olası darboğazları tespit edelim:

$ lstopo -v
...
HostBridge L#1 (buses=0000:[44-54])
    PCIBridge L#2 (busid=0000:44:00.0 id=1d0f:0200 class=0604(PCIBridge) link=15.75GB/s buses=0000:[45-54] PCISlot=64)
        PCIBridge L#3 (busid=0000:45:00.0 id=1d0f:0200 class=0604(PCIBridge) link=15.75GB/s buses=0000:[46-54] PCISlot=1-1)
            ...
            PCIBridge L#12 (busid=0000:46:01.4 id=1d0f:0200 class=0604(PCIBridge) link=63.02GB/s buses=0000:[53-53])
                PCI L#11 (busid=0000:53:00.0 id=10de:2330 class=0302(3D) link=63.02GB/s PCISlot=86-1)
                    Co-Processor(CUDA) L#8 (Backend=CUDA GPUVendor="NVIDIA Corporation" GPUModel="NVIDIA H100 80GB HBM3" CUDAGlobalMemorySize=83295872 CUDAL2CacheSize=51200 CUDAMultiProcessors=132 CUDACoresPerMP=128 CUDASharedMemorySizePerMP=48) "cuda0"
                    GPU(NVML) L#9 (Backend=NVML GPUVendor="NVIDIA Corporation" GPUModel="NVIDIA H100 80GB HBM3" NVIDIASerial=1654922006536 NVIDIAUUID=GPU-ba136838-6443-7991-9143-1bf4e48b2994) "nvml0"
            ...
...

lstopo çıktısından, sistemimizdeki iki önemli PCIe bant genişliği değerini görebiliriz:

• 15,75 GB/s: PCIe Gen4 x8 bağlantılarına karşılık gelir (CPU’dan PCIe anahtarlarına)
• 63,02 GB/s: PCIe Gen5 x16 bağlantılarına karşılık gelir (PCIe anahtarlarından GPU’lara)

Tüm topolojiyi daha iyi anlamak için, aşağıdaki komutu kullanarak görselleştirebiliriz:

Bu diyagram sistemimizin hiyerarşik yapısını gösteriyor. Şimdilik dikkat edilmesi gereken temel noktalar şunlar:

• İki adet Non-Uniform Memory Access (NUMA) düğümü içerir (her CPU soketi için bir bellek bölgesi).
• Her CPU soketi, PCIe Gen4 x8 bağlantılarıyla (15.75 GB/s) dört adet PCIe switch’e bağlanır.
• Her PCIe switch, PCIe Gen5 x16 bağlantılarıyla (63.02 GB/s) bir H100 GPU’ya bağlanır.

NVSwitch, EFA ağ kartları ve NVMe diskler gibi diğer bileşenleri ilerleyen bölümlerde inceleyeceğiz.

PCIe standardı nesiller arasında farklılık gösterir ve her yeni nesilde lane başına aktarım hızı yaklaşık iki katına çıkar. Aşağıdaki tablo bunu özetler. Dikkat edilmesi gereken nokta, transfer hızının GT/s (gigatransfers per second) cinsinden ölçülmesi, yani ham sinyal hızını ifade etmesidir; bant genişliği ise GB/s (gigabytes per second) cinsindendir ve kodlama ek yükü hesaba katılarak elde edilen gerçek kullanılabilir veri aktarım hızını temsil eder.

Teorik PCIe bant genişlikleri. Kaynak: https://en.wikipedia.org/wiki/PCI_Express.

CPU ile GPU arasındaki iletişim yolu.

Topoloji diyagramından ve PCIe bant genişliği tablosundan, CPU-GPU yolunun iki PCIe atlamasından geçtiğini görebiliriz: önce CPU’dan PCIe Gen4 x8 (15.754 GB/s) üzerinden PCIe anahtarına, ardından PCIe Gen5 x16 (63.015 GB/s) üzerinden PCIe anahtarından GPU’ya. Bu, CPU-GPU iletişimi için darboğazın ilk atlamada, 15.754 GB/s’de olduğunu gösterir. Bunu başka bir yardımcı program olan nvbandwidth ile doğrulayalım.

host_to_device_memcpy_ce komutu, GPU’nun kopyalama motorlarını kullanarak ana bilgisayar (CPU) belleğinden cihaz (GPU) belleğine cuMemcpyAsync’in bant genişliğini ölçer:

$ ./nvbandwidth -t host_to_device_memcpy_ce -b <message_size> -i 5

CPU-GPU arasında ölçülen bant genişliği

nvbandwidth’in host_to_device testi ile ölçülen CPU-GPU bant genişliği, büyük veri transferlerinde PCIe Gen4 x8'in ~14,2 GB/s’lik bir darboğaz oluşturduğunu göstermektedir.

Sonuçlar, küçük mesaj boyutları için gecikmenin sınırlı olduğunu, ancak büyük mesaj boyutları için ~14,2 GB/s’ye ulaştığımızı gösteriyor; bu da PCIe Gen4 x8 için teorik 15,754 GB/s bant genişliğinin yaklaşık %90'ına denk geliyor. Bu, CPU-GPU iletişiminde CPU-PCIe anahtar bağlantısının darboğazımız olduğunu doğruluyor.

Bant genişliğinin ötesinde, gecikme de CPU-GPU iletişimi için aynı derecede önemlidir, çünkü çekirdekleri ne kadar hızlı planlayabileceğimizi belirler. Bunu ölçmek için, ana bilgisayarda (CPU) bir tampon ayırarak ve GPU’dan işaretçi izleme çekirdeği kullanarak erişerek gidiş-dönüş gecikmesini ölçen host_device_latency_sm testini kullanıyoruz. Bu, CPU-GPU iletişiminin gerçek dünya gecikmesini simüle eder:

$ ./nvbandwidth -t host_device_latency_sm -i 5

CPU-to-GPU measured latency

nvbandwidth’in host_device_latency_sm testiyle (arabellek boyutunu değişken hale getirmek için uyarlanmış) ölçülen CPU-GPU gecikmesi, yaklaşık 1,4 mikrosaniyelik gidiş-dönüş gecikmesini göstermektedir.

Sonuçlar, gecikmenin yaklaşık 1.4 μs olduğunu gösteriyor. Bu da ML iş yüklerinde sıkça gözlemlediğimiz birkaç mikro saniyelik kernel başlatma overhead’ini açıklıyor. Çok sayıda küçük kernel başlatan iş yüklerinde bu gecikme bir darboğaz haline gelebilir; aksi durumda bu maliyet, yürütme örtüşmesi (overlapping execution) sayesinde gizlenir.

Küçük modeller veya küçük batch’lerle çalışırken inference tarafının GPU’yu kernel başlatma maliyeti nedeniyle daha sık sınıra vurduğunu görürüz. FlashFormer bunu, tüm bir katmanı birleştirerek (fusion) hız kazanımı elde ederek çözer (Nrusimha ve ark., 2025).

CUDA Graphs ile launch overhead azaltma

CUDA Graphs, bir dizi işlemi yakalayıp tek bir bütün olarak yeniden oynatarak bu overhead’i önemli ölçüde azaltabilir. Böylece her kernel başlatmada oluşan mikro saniyelik CPU–GPU round-trip gecikmesi ortadan kaldırılır. Bu özellikle çok sayıda küçük kernel veya sık CPU–GPU senkronizasyonu içeren iş yüklerinde büyük avantaj sağlar. Launch overhead’i anlamak ve optimize etmek için daha fazla bilgiye NVIDIA Teknik Blog’daki “Understanding the Visualization of Overhead and Latency in NVIDIA Nsight Systems” yazısına bakılabilir.

MoE modelleri ve CPU–GPU senkronizasyon overhead’i

Bazı mixture-of-experts (MoE) modellerinin implementasyonları, her iterasyonda CPU–GPU senkronizasyonu gerektirir; çünkü hangi expert’in çalıştırılacağı CPU tarafından planlanır. Bu durum kernel başlatma overhead’ini ciddi şekilde artırabilir, özellikle CPU–GPU bağlantısı yavaşsa throughput belirgin biçimde düşer.

Örneğin MakoGenerate’in DeepSeek MoE kernel optimizasyonunda, referans implementasyon ileri geçiş (forward pass) başına 1.043 kernel ve 67 CPU–GPU senkronizasyon noktası kullanıyordu. Routing mekanizması yeniden yapılandırıldığında bu sayı 533 kernel ve sadece 3 senkronizasyon noktasına düşürüldü; sonuç olarak %97 senkronizasyon azaltımı ve %44 uçtan uca gecikme düşüşü elde edildi.

Not: Her MoE implementasyonu CPU–GPU senkronizasyonu gerektirmez; modern yaklaşımlar routing’i tamamen GPU üzerinde tutabilir. Ancak gerektiren sistemlerde CPU–GPU iletişimi performans açısından kritik hale gelir.

Grace Hopper süperçipleri: CPU–GPU iletişimine farklı yaklaşım

NVIDIA’nın Grace Hopper süperçipleri, geleneksel x86 + Hopper sistemlerinden farklı bir CPU–GPU iletişim modeli kullanır. Başlıca iyileştirmeler:

• GPU–CPU oranı 1:1’dir (x86+Hopper sistemlerinde 4:1’e kıyasla), bu da GPU başına 3.5× daha yüksek CPU bellek bant genişliği sağlar
• PCIe Gen5 yerine NVLink-C2C kullanılır ve bu bağlantı 900 GB/s sağlar (128 GB/s’e kıyasla ~7× daha yüksek GPU–CPU bant genişliği)
• NVLink Switch System, PCIe Gen4 üzerinden bağlı InfiniBand NDR400 NIC’lere kıyasla GPU–GPU bağlantı bant genişliğinde 9× artış sağlar

Daha fazla detay için NVIDIA “Grace Hopper Superchip Architecture” teknik dokümanına (sayfa 11) bakılabilir.

NUMA Affinity: çok soketli sistemlerde kritik performans faktörü

AMD EPYC 7R13 gibi çok soketli sistemlerde (2 soket, 48 çekirdek), NUMA affinity GPU performansı için kritik öneme sahiptir. NUMA affinity, işlemleri hedef GPU ile aynı CPU soketindeki çekirdeklerde çalıştırmayı ifade eder.

Eğer GPU process’i, GPU’nun bağlı olduğu NUMA node yerine diğer node üzerinde çalışırsa, veri transferi CPU’lar arası bağlantı (AMD Infinity Fabric) üzerinden yapılır. Bu da hem gecikmeyi artırır hem de bant genişliği kaybına yol açar.

NUMA topolojisini ve node’lar arası mesafeleri incelemek, performans etkilerini daha iyi anlamayı sağlar:

$ numactl --hardware
node distances:
node   0   1 
  0:  10  32 
  1:  32  10

Aynı NUMA düğümü içindeki belleğe erişmek (distance 10), diğer NUMA düğümüne geçerek erişmeye (distance 32) göre çok daha hızlıdır. Bu 3.2×’lik gecikme farkı, process yanlış NUMA node’a pinlendiğinde GPU performansını ciddi şekilde etkileyebilir.

NUMA ile ilgili performans sorunlarını teşhis etme ve çözme adımları için bu bölümün ilerleyen kısımlarındaki “Troubleshooting Interconnect” kısmına bakabilirsiniz.

GPU–GPU Intranode İletişimi

Özet (TL;DR): Aynı node içindeki GPU’lar üç farklı şekilde haberleşebilir:

• CPU üzerinden (en yavaş yöntem, ~3 GB/s, PCIe ile sınırlı)
• GPUDirect RDMA üzerinden EFA NIC’leri ile (~38 GB/s)
• GPUDirect RDMA + NVLink üzerinden (~786 GB/s çift yönlü)

NVLink, CPU/PCIe yolunu tamamen bypass ederek 9–112× daha yüksek hız sağlar. NCCL, NVLink mevcutsa otomatik olarak onu tercih eder. NVLink SHARP (NVLS), collective işlemleri donanım seviyesinde hızlandırarak all-reduce performansını 1.3× artırıp ~480 GB/s seviyesine çıkarabilir. Ancak all-to-all işlemleri (~340 GB/s), NVLS hızlandırmasından faydalanmaz.

Dağıtık eğitimde GPU’lar her iterasyonda gradient, ağırlık ve aktivasyonlar gibi büyük veri bloklarını paylaşır. Bu veri transferi çoğu zaman gigabaytlar seviyesindedir. HBM’nin 3 TB/s civarındaki iç bant genişliğine kıyasla, yanlış iletişim yolu seçmek GPU performansını dramatik şekilde düşürebilir.

Bunun nedenini anlamak için aynı node içindeki GPU’ların nasıl iletişim kurduğuna bakalım (ve hangi ayarların kullanılıp kullanılmaması gerektiğine).

CPU üzerinden iletişim

Naif yaklaşım, host memory (SHM) kullanır: Veri GPU1’den PCIe switch üzerinden CPU’ya gider, host memory’ye yazılır, tekrar CPU’dan çıkar, PCIe switch üzerinden yeniden geçer ve GPU2’ye ulaşır.

Bu yöntem (önerilmez ama mümkün), NCCL’de şu şekilde zorlanabilir:

• NCCL_P2P_DISABLE=1
• FI_PROVIDER=tcp

Bu mod aktif olduğunda, NCCL_DEBUG=INFO ile doğrulama yapılabilir ve şu tür log mesajları görülebilir:

NCCL INFO Channel 00 : 1[1] -> 0[0] via SHM/direct/direct

GPU’lar arası iletişim yolu, CPU ve ana bellek üzerinden gerçekleşmekte olup, PCIe anahtarı ve CPU üzerinden gerçekleşen verimsiz gidiş-dönüş yolculuğunu göstermektedir.

Bu dolambaçlı yol birden fazla bellek kopyası içerir ve hem PCIe hem de CPU bellek bant genişliğini doyurur; bu da ciddi bir tıkanıklık oluşturur. Topolojimizde dört adet H100’ün aynı CPU bellek bus’larını paylaştığı düşünüldüğünde, birden fazla GPU aynı anda iletişim kurmaya çalıştığında bu tıkanıklık daha da problemli hale gelir; çünkü hepsi aynı sınırlı CPU bellek bant genişliği için rekabet eder.

Bu CPU aracılı yaklaşımda temel darboğazımız, CPU ile PCIe switch arasındaki yaklaşık PCIe Gen4 x8 (~16 GB/s) bağlantısıdır. Neyse ki GPU’ların CPU’yu devreye sokmadan iletişim kurmasının daha iyi bir yolu var: GPUDirect RDMA.

libfabric EFA üzerinden iletişim

GPUDirect RDMA (GDRDMA), NVIDIA GPU’ların doğrudan GPU belleğine erişmesine izin vererek GPU’lar arası doğrudan iletişimi mümkün kılan bir teknolojidir. Bu sayede veri CPU üzerinden geçmek zorunda kalmaz ve sistem belleği üzerinden buffer kopyaları ortadan kalkar. Sonuç olarak geleneksel CPU aracılı transferlere kıyasla 10×’e kadar daha yüksek performans elde edilebilir.

GPUDirect RDMA hem aynı node içindeki GPU’lar arasında hem de RDMA destekli ağ kartları (NIC’ler) üzerinden node’lar arası iletişimde kullanılabilir (bunu ileride daha detaylı göreceğiz).

Topolojimize geri dönersek, her PCIe switch’in 4 adet EFA (Elastic Fabric Adapter) NIC’i vardır; yani her GPU 4 adet EFA adaptörüne erişebilir. EFA, AWS’nin yüksek performanslı instance’lar için geliştirdiği özel ağ arabirimidir ve düşük gecikmeli, yüksek bant genişlikli instance’lar arası iletişim sağlar.

P5 instance’larında EFA, yüksek performanslı uygulamalar için tasarlanmış bir iletişim API’si olan libfabric arayüzünü sunar. Bu arayüz üzerinden GPUDirect RDMA gibi RDMA benzeri yeteneklere erişilir ve doğrudan GPU–GPU iletişimi sağlanabilir.

EFA, “Scalable Reliable Datagram (SRD)” adı verilen güvenilir bir Ethernet tabanlı taşıma protokolü kullanır. Bu protokol, çok sayıda yolun bulunduğu modern veri merkezi ağlarında yüksek verimlilik sağlamak üzere tasarlanmıştır. Ayrıntılar AWS HPC Blog’unda daha detaylı açıklanır.

Şimdi sistem topolojisinin ilgili kısmına ve EFA bağlantı detaylarına daha yakından bakalım:

$ lstopo -v
...
## We can see 4 such EFA devices per each PCIe switch
PCIBridge L#8 (busid=0000:46:01.0 id=1d0f:0200 class=0604(PCIBridge) link=15.75GB/s buses=0000:[4f-4f] PCIVendor="Amazon.com, Inc.")
PCI L#6 (busid=0000:4f:00.0 id=1d0f:efa1 class=0200(Ethernet) link=15.75GB/s PCISlot=82-1 PCIVendor="Amazon.com, Inc.")
    OpenFabrics L#4 (NodeGUID=cd77:f833:0000:1001 SysImageGUID=0000:0000:0000:0000 Port1State=4 Port1LID=0x0 Port1LMC=1 Port1GID0=fe80:0000:0000:0000:14b0:33ff:fef8:77cd) "rdmap79s0"
...

$ fi_info --verbose
        fi_link_attr:
            address: EFA-fe80::14b0:33ff:fef8:77cd
            mtu: 8760            # maximum packet size is 8760 bytes
            speed: 100000000000  # each EFA link provides 100 Gbps of bandwidth
            state: FI_LINK_UP
            network_type: Ethernet

Her EFA bağlantısı 100 Gbps (12.5 GB/s) bant genişliği sağlar. GPU başına 4 EFA NIC ve node başına 8 GPU olduğunu düşündüğümüzde, bu toplamda:

100 × 4 × 8 = 3,200 Gbps (400 GB/s)

node başına toplam bant genişliği anlamına gelir.

Detaylı olarak bu 3,200 Gbps kapasitesinin libfabric ve EFA kullanılarak nasıl tam verimli kullanılabileceğine dair inceleme için Lequn Chen’in şu blog serisine bakabilirsiniz: “Harnessing 3200 Gbps Network: A Journey with RDMA, EFA, and libfabric”.

GPUDirect RDMA’nın EFA üzerinden etkinleştirilmesi

GPUDirect RDMA’nın EFA üzerinden düzgün çalıştığından emin olmak için şu ortam değişkenleri ayarlanmalıdır:

• FI_PROVIDER=efa
• NCCL_P2P_DISABLE=1

Bu mod aktif edildiğinde, doğru çalışıp çalışmadığını doğrulamak için NCCL_DEBUG=INFO kullanılabilir ve şu tür log mesajları görülür:

NCCL INFO Channel 01/1 : 1[1] -> 0[0] [receive] via NET/Libfabric/0/GDRDMA/Shared

Libfabric EFA üzerinden GPU’dan GPU’ya iletişim yolu. Bunun, NVLink kullanmaya kıyasla düğüm içi iletişim için daha az verimli olduğunu unutmayın.

GPUDirect RDMA over EFA, CPU aracılı aktarımlara kıyasla önemli iyileştirmeler sağlarken (GPU başına dört EFA kartıyla yaklaşık 50 GB/s hıza ulaşarak), daha da iyisini yapabilir miyiz? İşte burada NVLink devreye giriyor.

NVLink**, NVIDIA’nın sunucular içinde hızlı çoklu GPU iletişimini sağlayan yüksek hızlı, doğrudan GPU’dan GPU’ya bağlantı teknolojisidir. Aşağıdaki tablo, nesiller boyunca NVLink bant genişliğini karşılaştırmaktadır (teorik özellikler gösterilmektedir). H100, her biri 50 GB/s çift yönlü hızda çalışan 18 bağlantı üzerinden GPU başına 900 GB/s çift yönlü bant genişliği sağlayan NVLink 4.0'ı kullanmaktadır.

DGX H100 mimarisinde dört adet üçüncü nesil NVSwitch, sekiz GPU’yu katmanlı bir topolojiyle birbirine bağlar. Bu yapıda her GPU, switch’ler üzerinden 5 + 4 + 4 + 5 bağlantı dağılımına sahip olacak şekilde bağlanır. Bu konfigürasyon, herhangi iki GPU arasında birden fazla doğrudan yol bulunmasını sağlar ve her GPU çifti arasında sabit yalnızca bir NVSwitch hop’u olacak şekilde iletişim kurulur. Sonuç olarak toplam 3.6 TB/s çift yönlü NVLink ağ bant genişliği elde edilir.

Varsayılan olarak NCCL, intranode GPU iletişimi için NVLink mevcutsa onu önceliklendirir; çünkü aynı makinedeki GPU’lar arasında en düşük gecikmeli ve en yüksek bant genişliğine sahip yol budur. NVLink’in kullanılmasını garanti etmek için, NVLink desteğini devre dışı bırakabilecek NCCL environment variable ayarlarından kaçınmak gerekir — yanlış bir flag ayarı istemeden NVLink kullanımını engelleyebilir.

NVLink, CPU veya sistem belleğini devreye sokmadan doğrudan GPU–GPU bellek erişimi sağlar. Eğer NVLink mevcut değilse NCCL sırasıyla GPUDirect P2P (PCIe üzerinden) veya daha düşük performanslı durumlarda SHM (shared memory) transport’a fallback yapar; özellikle inter-socket PCIe transferleri suboptimal olduğunda SHM tercih edilebilir.

NVLink’in gerçekten kullanıldığını doğrulamak için NCCL_DEBUG=INFO ayarlanır ve loglarda şu tür mesajlar görülür:

NCCL INFO Channel 00/1 : 0[0] -> 1[1] via P2P/CUMEM

CUMEM, eşler arası işlemlerin CUDA bellek tanıtıcılarını (cuMem API) kullandığını gösterir. Daha fazla bilgi için NCCL belgelerine bakın.

Aşağıdaki diyagram, NVLink kullanılırken verilerin izlediği doğrudan yolu göstermektedir.

NVLink üzerinden GPU’lar arası iletişim yolu.

NVLink 4.0'ın teorik bant genişliğinin 900 GB/s, EFA’nın ise yaklaşık 50 GB/s olduğunu göz önünde bulundurarak, düğüm içi iletişimde 18 katlık bir avantaj bekliyoruz. Bunu pratikte doğrulamak için, farklı iletişim yollarındaki gerçek bant genişliğini ölçmek amacıyla NCCL’nin SendRecv performans testini çalıştırdık:

$ FI_PROVIDER=XXX NCCL_P2P_DISABLE=X sendrecv_perf -b 8 -e 8G -f 2 -g 1 -c 1 -n 100

NCCL’nin SendRecv testi ile ölçülen GPU’dan GPU’ya bant genişliği (H100 GPU’lar, 1 Düğüm, 2 GPU)

Bu, NVLink’in ne kadar daha verimli olduğunu şüphe götürmez bir şekilde gösteriyor: EFA’nın 38,16 GB/s’sine (9 kat daha hızlı veya 18 kat çift yönlü) ve CPU temelinin 3,24 GB/s’sine (112,6 kat daha hızlı) kıyasla 364,93 GB/s’ye ulaşıyor. Bu ölçümler, NCCL’nin düğüm içi GPU iletişimi için NVLink’e neden öncelik verdiğini doğruluyor, ancak bir test daha için, her iki yönde eş zamanlı kopyalama kullanarak tüm GPU çiftleri arasındaki çift yönlü bant genişliğini ölçmek için nvbandwidth’i kullanalım:

$ ./nvbandwidth -t device_to_device_bidirectional_memcpy_write_ce -b <message_size> -i 5
memcpy CE GPU(row) <-> GPU(column) Total bandwidth (GB/s)
           0         1         2         3         4         5         6         7
 0       N/A    785.81    785.92    785.90    785.92    785.78    785.92    785.90
 1    785.83       N/A    785.87    785.83    785.98    785.90    786.05    785.94
 2    785.87    785.89       N/A    785.83    785.96    785.83    785.96    786.03
 3    785.89    785.85    785.90       N/A    785.96    785.89    785.90    785.96
 4    785.87    785.96    785.92    786.01       N/A    785.98    786.14    786.08
 5    785.81    785.92    785.85    785.89    785.89       N/A    786.10    786.03
 6    785.94    785.92    785.99    785.99    786.10    786.05       N/A    786.07
 7    785.94    786.07    785.99    786.01    786.05    786.05    786.14       N/A

SUM device_to_device_bidirectional_memcpy_write_ce_total 44013.06

Ölçülen 786 GB/s’lik çift yönlü bant genişliği, NVLink 4.0'ın teorik 900 GB/s spesifikasyonunun %85'ini temsil ediyor. GPU’dan GPU’ya iletişim için NVLink kullanımı, CPU darboğazını tamamen ortadan kaldırdı!

Peki bu, toplu iletişim modellerine nasıl yansıyor? NCCL Tests’in all_reduce_perf kıyaslama testiyle tek bir düğüm içindeki tüm azaltma performansını ölçelim:

$ ./all_reduce_perf -b 8 -e 16G -f 2 -g 1 -c 1 -n 100

NCCL’nin tüm azaltım performans testi (düğüm içi)

Not: Toplu iletişim kalıpları hakkında hızlı bir özet için Ultra-Scale Playbook’un Ek bölümüne bakın. Kapsamlı kıyaslama komut dosyaları ve yapılandırmaları için, harika dağıtılmış eğitim deposundaki mükemmel koleksiyona göz atın.

Ama durun bir dakika… 480 GB/s hıza ulaşıyoruz ki bu, NVLink 4.0 için teorik tek yönlü bant genişliği olan 450 GB/s’yi aşıyor. Bu nasıl bir sihir ve nasıl mümkün oluyor?

Belgelere biraz daha yakından baktığımızda, cevabın NVIDIA’nın donanım hızlandırmalı toplu işlemler teknolojisi olan NVLink SHARP’ta (NVLS) yattığı anlaşılıyor. Bu, H100 GPU’lu tek bir düğümde tüm azaltma işlemlerinde yaklaşık 1,3 kat hız artışı sağlıyor!

NVSwitch’lerin bu donanım hızlandırmalı toplu işlemleri nasıl mümkün kıldığına dair teknik ayrıntılar için NVSwitch mimarisi sunumuna bakın.

Peki başka alanlarda da yardımcı olabilirler mi? Tümden-tümüne performansı inceleyelim:

$ ./all_to_all_perf -b 8 -e 16G -f 2 -g 1 -c 1 -n 100

NCCL’nin tüm düğümler arası performans testi (düğüm içi)

All-to-all işlemler için 340 GB/s elde ediyoruz; bu, H100 sistemlerinde NVLink 4.0 ile bildirilen benzer benchmark sonuçlarıyla uyumlu. All-reduce işlemlerinin aksine, all-to-all desenleri NVLS donanım hızlandırmasından faydalanmaz. Bu da neden burada 340 GB/s görürken all-reduce tarafında 480 GB/s’e çıkabildiğimizi açıklıyor.

All-to-all iletişim, tüm GPU çiftleri arasında daha karmaşık point-to-point veri değişimi gerektirir. Bu nedenle NVSwitch’in collective hızlandırma özellikleri yerine büyük ölçüde NVLink’in ham bant genişliğine dayanır.

Özel NVLink iletişim desenleri için PyTorch’un SymmetricMemory API özelliğini takip etmek faydalıdır; bu API NVLink ve NVLS operasyonları üzerinde daha ince taneli kontrol sağlar.

Gelişmiş kernel optimizasyonu

Bazı optimize kernel tasarımları NVLink iletişimini compute’tan ayırarak farklı warp’lara dağıtır. Örneğin ThunderKittens, warp seviyesinde bir tasarım kullanır: belirli warp’lar NVLink transferlerini başlatır ve tamamlanmasını beklerken, diğer warp’lar compute işlemlerine devam eder.

Bu ince taneli SM compute + NVLink overlap yaklaşımı, çoğu GPU-ler arası iletişim gecikmesini gizleyebilir. Implementasyon detayları için ThunderKittens’in multi-GPU kernel blog yazısına bakılabilir.

NVLink tek bir node içinde olağanüstü bant genişliği sunmasına rağmen, frontier model eğitimleri genellikle birden fazla node’a ölçeklenmeyi gerektirir.

Bu da yeni bir potansiyel darboğazı ortaya çıkarır: node’lar arası (internode) ağ bağlantısı, ki bu NVLink’e kıyasla çok daha düşük bant genişliğinde çalışır.

GPU–GPU İnternode İletişimi

Özet (TL;DR): Multi-node GPU iletişimi InfiniBand (400 Gbps) veya RoCE (100 Gbps) gibi yüksek hızlı ağlarla yapılır. All-reduce işlemleri iyi ölçeklenir (320–350 GB/s, node’lar arasında stabil), bu da büyük eğitim cluster’larını mümkün kılar. All-to-all ise daha hızlı bozulur çünkü algoritmik olarak daha karmaşıktır: gecikme intranode ~13 μs iken internode tarafında 55 μs+ seviyesine çıkar.

MoE iş yüklerinde sık all-to-all gerektiği için, CPU tarafından orkestre edilen transferler yerine NVSHMEM gibi GPU-initiated (GPU tarafından başlatılan) iletişim modelleri çok daha iyi performans sağlar.

Model ölçeği tek node’u aştıkça, eğitim birden fazla node’a dağıtılır ve bunlar yüksek hızlı ağlarla birbirine bağlanır. Benchmarklara geçmeden önce, multi-node GPU cluster’larında karşılaşacağın üç temel ağ teknolojisine bakalım:

• Ethernet: 1 Gbps’ten 100+ Gbps’e evrilmiş ve hâlâ birçok veri merkezinde yaygın
• RoCE (RDMA over Converged Ethernet): Ethernet üzerine RDMA ekleyerek TCP yerine ECN tabanlı congestion control kullanır
• InfiniBand: NVIDIA’nın endüstri standardı switch fabric’i; 400 Gbps’e kadar bant genişliği, sub-microsecond latency ve GPUDirect RDMA ile CPU’yu bypass eden doğrudan GPU–GPU iletişimi sağlar

Li ve ark. (2022) daha detaylı açıklamalar sunar, ancak özetle:

AWS P5 örneklerinde, Elastic Fabric Adapter (EFA) ağ arayüzü (NIC) görevi görür. Daha önce gördüğümüz gibi, her GPU, PCIe Gen5 x16 bağlantıları aracılığıyla dört adet 100 Gbps EFA NIC’ye bağlanır.

Libfabric EFA üzerinden düğümler arası GPU’lar arası iletişim yolu.

Burada gösterildiği gibi, GPU’lar ve ağ kartları aynı PCIe anahtarına bağlandığında, GPUDirect RDMA, iletişimlerinin yalnızca bu anahtar üzerinden gerçekleşmesini sağlar. Bu kurulum, PCIe Gen5 x16 bant genişliğinin tam olarak kullanılmasını sağlar ve diğer PCIe anahtarlarını veya CPU bellek veri yolunu dahil etmeyi önler.

Teorik olarak, düğüm başına 8 PCIe anahtarı × anahtar başına 4 EFA NIC × EFA NIC başına 100 Gbps, 3.200 Gbps (400 GB/s)** bant genişliği verir; bu da AWS’nin P5 özelliklerinde bulduğumuz bant genişliğidir. Peki bu pratikte de geçerli mi? Daha önce yaptığımız aynı kıyaslamaları farklı düğümlerde çalıştırarak bunu öğrenelim!

Bant Genişliği Analizi

AWS P5 örneklerimizdeki farklı düğüm sayıları üzerinde toplu işlemlerin bant genişliği ölçeklendirilmesi, aws-samples/awsome-distributed-training’deki öneriler kullanılarak gerçekleştirilmiştir.

Noktadan noktaya gönderme/alma işlemleri, 2–4 düğüm için yaklaşık 42–43 GB/s performans sağlarken, bu değer 5+ düğümde yaklaşık 21 GB/s seviyesine düşmektedir. Bu performans düşüşü, NCCL’nin 4 düğümün üzerine ölçeklendiğinde her eş (peer) için noktadan noktaya kanal sayısını otomatik olarak 2’den 1’e düşürmesinden kaynaklanır. Bu durum, kullanılabilir bant genişliği kullanımını fiilen yarıya indirir. Oysa teorik maksimum değer ~50 GB/s civarındadır (4 EFA NIC × her biri 12.5 GB/s).

Bu testte 5+ düğümde tam verimi geri kazanmayı, NCCL_NCHANNELS_PER_NET_PEER=2 ayarını kullanarak başardık. Ancak bu bayrak dikkatli kullanılmalıdır; çünkü all-to-all performansını düşürebilir (detaylar için GitHub issue #1272’ye bakınız).

All-reduce işlemi tek bir düğüm içinde mükemmel performans gösterir ve 480 GB/s bus bant genişliğine ulaşır. 2 düğüme ölçeklendiğinde bant genişliği neredeyse aynı kalır (479 GB/s). Bunun ardından 3–16 düğüm arasında yaklaşık 320–350 GB/s seviyesinde stabilize olur. Bu desen önemli bir özelliği ortaya koyar: Düğümler arası sınır geçildiğinde NVLink’ten node’lar arası ağ fabric’ine geçiş nedeniyle başlangıçta bir düşüş yaşanır, ancak sonrasında düğüm sayısı arttıkça bant genişliği neredeyse sabit şekilde ölçeklenir.

Düğümler arası all-reduce ölçeklenmesi

İki düğümden sonra görülen bu neredeyse sabit ölçeklenme davranışı, büyük ölçekli eğitim açısından oldukça olumludur. 3–16 düğüm arasında 320–350 GB/s seviyesinin görece stabil kalması, all-reduce işlemlerine dayanan paralellik stratejilerinin (örneğin veri paralelliği) GPU başına bant genişliği ciddi şekilde düşmeden yüzlerce, hatta binlerce GPU’ya ölçeklenebileceğini gösterir.

Bu logaritmik ölçeklenme karakteristiği, her bir 8 GPU’nun ayrı bir switch rail’e bağlandığı ve bisection bandwidth’i maksimize eden 8-rail optimize fat-tree mimarilerine sahip iyi tasarlanmış çok katmanlı ağ topolojilerinde tipiktir. Güncel frontier eğitim kümeleri rutin olarak 100.000+ GPU seviyesinde çalışır ve bu tür büyük ölçekli dağıtımların mümkün olmasını sağlayan şey bu stabil ölçeklenme davranışıdır.

Node içi NVLink ve node’lar arası ağ gibi farklı bant genişliği katmanlarıyla çalışırken, tüm mevcut bant genişliğini verimli kullanmak için paralellik stratejinizi bu katmanlara göre uyarlamanız önerilir. Heterojen ağ topolojilerinde paralelliği optimize etmeye yönelik detaylı rehber için Ultra-Scale Playbook’a bakınız.

All-to-all işlemi ise çok daha zorlayıcı bir ölçeklenme problemi sergiler: Tek düğümde 344 GB/s ile başlarken, iki düğümde 81 GB/s’ye düşer ve daha büyük kümelerde yaklaşık 45–58 GB/s seviyesine kadar gerilemeye devam eder. Bu daha keskin düşüş, all-to-all deseninin yoğun ağ gereksinimlerini yansıtır; çünkü her GPU, her diğer GPU ile iletişim kurmak zorundadır ve bu durum all-reduce’a kıyasla çok daha fazla ağ tıkanıklığı oluşturur.

Gecikme analizi

AWS P5 örneklerimizdeki farklı düğüm sayıları arasında toplu işlemlerin gecikme ölçeklendirmesi, aws-samples/awsome-distributed-training adresindeki öneriler kullanılarak gerçekleştirilmiştir.

Gecikme ölçümleri, düğümler arası sınırları aşmanın temel maliyetini ortaya koymaktadır. Gönderme/alma (send/receive) işlemleri, tüm çok düğümlü yapılandırmalarda 40–53 μs arasında görece stabil gecikme değerleri korur. Bu durum, noktadan noktaya iletişim gecikmesinin esas olarak küme boyutundan ziyade temel ağ gidiş-dönüş süresi (round-trip time) tarafından belirlendiğini gösterir. Ancak gözlenen bazı değişimler, ağ topolojisi ve yönlendirme (routing) etkilerinin hâlâ rol oynadığını düşündürmektedir.

All-reduce işlemleri tek bir düğüm içinde minimum 12,9 μs gecikme gösterir; ancak bu değer 2 düğümde 55,5 μs’ye sıçrar ve küme boyutu arttıkça neredeyse doğrusal şekilde yükselmeye devam ederek 16 düğümde 235 μs’ye ulaşır. Bu artış, hem iletişim mesafesinin büyümesini hem de daha fazla düğümle birlikte reduction ağacının (reduction tree) giderek daha karmaşık hale gelmesini yansıtır.

All-to-all işlemleri benzer bir eğilim gösterir: tek düğümde 7,6 μs ile başlar, 2 düğümde 60 μs’ye çıkar ve 16 düğümde 621 μs’ye kadar yükselir. All-to-all gecikmesindeki süper-doğrusal artış, daha fazla düğüm sürece dahil oldukça ağ tıkanıklığının ve koordinasyon yükünün birleşerek büyüdüğünü göstermektedir.

GPU iletişimini optimize etmek için NVSHMEM

MoE (Mixture of Experts) mimarilerinin yükselişiyle birlikte, uzman yönlendirme (expert routing) için sık all-to-all iletişimi gereksinimi artmıştır. Bu da optimize GPU iletişim kütüphanelerini kritik hale getirmiştir.

NVSHMEM, birden fazla GPU’nun belleğini bölümlenmiş global adres uzayı (PGAS) içinde birleştiren yüksek performanslı bir iletişim kütüphanesi olarak giderek daha fazla kullanılmaktadır. CPU tarafından orkestre edilen veri transferlerine dayanan geleneksel MPI tabanlı yaklaşımların aksine, NVSHMEM CPU–GPU senkronizasyon yükünü ortadan kaldıran asenkron ve GPU tarafından başlatılan işlemleri mümkün kılar.

NVSHMEM, GPU iletişiminde birkaç önemli avantaj sunar: GPUDirect Async gibi teknolojiler sayesinde GPU’lar, düğümler arası iletişim başlatırken CPU’yu tamamen atlayabilir ve küçük mesajlarda (<1 KiB) 9,5 kata kadar daha yüksek verim elde edebilir. Bu özellik, yoğun kolektif iletişim desenleri gerektiren işlemler için özellikle faydalıdır.

Kütüphane şu anda Mellanox adaptörleri (CX-4 veya sonrası), Slingshot-11 (libfabric CXI) ve Amazon EFA (libfabric EFA) desteğine sahiptir. İnce taneli iletişim gerektiren ve güçlü ölçeklenme hedefleyen uygulamalarda, NVSHMEM’in düşük ek yüklü tek taraflı (one-sided) iletişim ilkeleri, geleneksel CPU proxy yöntemlerine kıyasla performansı önemli ölçüde artırabilir.

Daha fazla bilgi için NVSHMEM dokümantasyonuna ve GPUDirect Async üzerine NVIDIA blog yazısına bakılabilir.

Bant genişliği ölçümleri beklenen seviyelerin altında kaldığında, performansı sınırlayan birkaç farklı faktör olabilir. Optimum interconnect kullanımına ulaşmak için bu olası darboğazların anlaşılması kritik önemdedir.

İnterconnect sorun giderme (Troubleshooting Interconnect)

Beklenenden düşük bant genişliği gözlemlendiğinde, aşağıdaki alanlar sistematik olarak kontrol edilmelidir:

Kütüphane sürümleri

Güncel olmayan NCCL, EFA veya CUDA kütüphaneleri önemli performans optimizasyonlarından veya hata düzeltmelerinden yoksun olabilir. Her zaman tüm iletişim kütüphanelerinin uyumlu ve güncel sürümlerinin kullanıldığından emin olunmalıdır. Örneğin AWS, donanımlarıyla optimize edilmiş kütüphane sürümleri içeren Deep Learning AMI’lerini düzenli olarak güncellemektedir. Kritik deneyler için bu sürümlerin loglanması da önerilir.

CPU affinity yapılandırması

Yanlış CPU affinity ayarları, gereksiz NUMA bölgeleri arası trafiğe yol açarak NCCL performansını ciddi şekilde düşürebilir. Her GPU, bellek erişim gecikmesini azaltmak için aynı NUMA düğümündeki CPU’lara bağlanmalıdır. GitHub issue #1017, NCCL_IGNORE_CPU_AFFINITY=1 ve --cpu-bind none kullanımının container gecikmesini pratikte nasıl azalttığını göstermektedir. Daha fazla bilgi Enterprise Support Portal’da bulunabilir.

Ağ topolojisi ve yerleşim

Ağ topolojinizi anlamak performans sorunlarını teşhis etmek için kritiktir. Cloud placement group’lar yardımcı olsa da, instance’ların mutlaka minimum ağ atlaması (hop) ile yerleştiğini garanti etmez. Modern datacenter fat-tree topolojilerinde farklı üst seviye switch’lere bağlı instance’lar daha fazla ağ hop’u nedeniyle daha yüksek gecikme ve potansiyel olarak daha düşük bant genişliği yaşayabilir.

AWS EC2 kullanıcıları için Instance Topology API, ağ düğüm yerleşimi hakkında önemli görünürlük sağlar. Ağın alt katmanında aynı node’u paylaşan instance’lar (doğrudan bağlı olanlar) fiziksel olarak en yakın olanlardır ve en düşük gecikmeli iletişimi sağlarlar.

İletişim kuran düğümler arasındaki ağ atlama (network hop) sayısını en aza indirmek, doğrudan daha iyi ara bağlantı (interconnect) performansına dönüşür. Küçük ölçekli deneyler ve ablation çalışmaları için, örneklerinizin aynı ağ anahtarı (network switch) üzerinde birlikte konumlandırıldığından emin olmak, hem gecikme (latency) hem de bant genişliği kullanımı açısından ölçülebilir bir fark yaratabilir.

Doğru Ortam Değişkenleri

Ağ adaptörünüz için eksik veya yanlış yapılandırılmış ortam değişkenleri, bant genişliği kullanımını ciddi şekilde sınırlayabilir. NCCL gibi iletişim kütüphaneleri, adaptif yönlendirme, GPU tarafından başlatılan transferler ve doğru tampon (buffer) boyutlandırması gibi optimum performans özelliklerini etkinleştirmek için belirli yapılandırma bayraklarına (flags) ihtiyaç duyar.

Örneğin AWS EFA kullanırken, instance türünüz için önerilen NCCL ve EFA ortam değişkenlerini ayarladığınızdan emin olun. AWS EFA cheatsheet, farklı senaryolar için en uygun bayrak yapılandırmaları konusunda kapsamlı rehberlik sağlar.

Konteyner-Özel Dikkat Noktaları

Konteynerler (Docker/Enroot) kullanıldığında, NCCL performansını optimize etmek için birkaç kritik yapılandırma adımı vardır:

• Paylaşımlı ve kilitlenmiş bellek (shared & pinned memory): Docker konteynerleri varsayılan olarak sınırlı paylaşımlı ve kilitli bellek kaynakları kullanır. Başlatma hatalarını önlemek için konteynerleri --shm-size=1g --ulimit memlock=-1 ile başlatın.
• NUMA desteği: Docker varsayılan olarak NUMA desteğini devre dışı bırakır; bu durum cuMem host tahsislerinin doğru çalışmasını engelleyebilir. Docker’ı --cap-add SYS_NICE ile başlatarak NUMA desteğini etkinleştirin.
• PCI topolojisi keşfi: NCCL’nin GPU ve ağ kartlarının PCI topolojisini doğru şekilde keşfedebilmesi için /sys dosya sisteminin doğru şekilde mount edildiğinden emin olun. /sys üzerinde sanal bir PCI topolojisi olması, alt-optimal performansa yol açabilir.

GPU–CPU ve GPU–GPU iletişimindeki darboğazları nasıl debug edeceğinizi artık bildiğinize göre, genelde daha az dikkat edilen bir konuya bakalım: depolama katmanıyla iletişim!

GPU–Depolama İletişimi

Kısaca: GPU–depolama I/O işlemleri, veri yükleme ve checkpoint alma süreçleri üzerinden eğitimi etkiler. GPUDirect Storage (GDS), CPU’yu bypass ederek GPU–depolama arasında doğrudan veri transferi sağlar ve daha iyi performans sunar. Küme içinde GDS etkin olmasa bile, yerel NVMe RAID (RAID 0’da 8 × 3.5 TB disk) 26.59 GiB/s ve 337k IOPS sağlar (ağ depolamasından 6.3× daha hızlı), bu da checkpoint işlemleri için idealdir.

GPU’lar ve depolama sistemleri arasındaki bağlantı çoğu zaman göz ardı edilir, ancak eğitim verimliliğini ciddi şekilde etkileyebilir. Eğitim sırasında GPU’ların sürekli olarak depolamadan veri okuması ve düzenli olarak model durumlarını depolamaya yazması (checkpointing) gerekir. Büyük ölçekli modern eğitimlerde bu I/O işlemleri, uygun şekilde optimize edilmezse darboğaz haline gelebilir.

Depolama Topolojisini Anlamak

GPU’lar ve depolama cihazları arasındaki fiziksel bağlantılar, GPU ara bağlantılarına benzer hiyerarşik bir yapı izler. Depolama cihazları PCIe köprüleri üzerinden bağlanır ve bu topolojiyi anlamak performans karakteristiklerini ve olası darboğazları açıklamaya yardımcı olur.

lstopo ile sistem topolojisine bakıldığında NVMe disklerin sisteme nasıl bağlandığını görebiliriz. P5 instance’ımızda her GPU başına bir NVMe SSD bulunmaktadır.

PCIBridge L#13 (busid=0000:46:01.5 id=1d0f:0200 class=0604(PCIBridge) link=15.75GB/s buses=0000:[54-54] PCIVendor="Amazon.com, Inc.")
PCI L#11 (busid=0000:54:00.0 id=1d0f:cd01 class=0108(NVMExp) link=15.75GB/s PCISlot=87-1 PCIVendor="Amazon.com, Inc." PCIDevice="NVMe SSD Controller")
    Block(Disk) L#9 (Size=3710937500 SectorSize=512 LinuxDeviceID=259:2 Model="Amazon EC2 NVMe Instance Storage" Revision=0 SerialNumber=AWS110C9F44F9A530351) "nvme1n1"

Akla gelen doğal bir soru, GPU’ların CPU’yu işin içine katmadan doğrudan NVMe sürücülerine erişip erişemeyeceğidir. Cevap evet, GPUDirect Storage (GDS) aracılığıyla.

NVIDIA’nın GPUDirect teknoloji ailesinin bir parçası olan GPUDirect Storage, depolama (yerel NVMe veya uzak NVMe-oF) ve GPU belleği arasında doğrudan bir veri yolu sağlar. Depolama denetleyicisinin yakınındaki doğrudan bellek erişimi (DMA) motorunun verileri doğrudan GPU belleğine veya GPU belleğinden dışarı taşımasına izin vererek, CPU sıçrama tamponları aracılığıyla gereksiz bellek kopyalamalarını ortadan kaldırır. Bu, CPU yükünü azaltır, gecikmeyi düşürür ve büyük çok modlu veri kümeleri üzerinde eğitim gibi veri yoğun iş yükleri için G/Ç performansını önemli ölçüde iyileştirir.

Sisteminizde GPUDirect Storage’ın doğru şekilde yapılandırılıp yapılandırılmadığını doğrulamak için, GDS yapılandırma dosyasını kontrol edebilir ve sağlanan tanılama araçlarını kullanabilirsiniz:

$ /usr/local/cuda/gds/tools/gdscheck.py -p
 =====================
 DRIVER CONFIGURATION:
 =====================
 NVMe               : Supported   
 NVMeOF             : Unsupported
 SCSI               : Unsupported
 ScaleFlux CSD      : Unsupported
 NVMesh             : Unsupported
 DDN EXAScaler      : Unsupported
 IBM Spectrum Scale : Unsupported
 NFS                : Unsupported
 BeeGFS             : Unsupported
 WekaFS             : Unsupported
 Userspace RDMA     : Unsupported
 --Mellanox PeerDirect : Enabled
 --rdma library        : Not Loaded (libcufile_rdma.so)
 --rdma devices        : Not configured
 --rdma_device_status  : Up: 0 Down: 0
 =====================

NVMe: Supported satırı, GDS’nin şu anda NVMe sürücüler için çalışacak şekilde yapılandırıldığını, Unsupported bayrağı ise diğer depolama türleri için yapılandırılmadığını gösterir. GDS, depolama türünüz için doğru şekilde yapılandırılmamışsa, /etc/cufile.json adresindeki yapılandırma dosyasını değiştirme talimatları için NVIDIA GPUDirect Depolama Kıyaslama ve Yapılandırma Kılavuzu’na bakın.

Blok Depolama Aygıtları

Sisteminizde bulunan depolama aygıtlarını anlamak için lsblk komutunu kullanabilirsiniz:

$ lsblk --fs -M
    NAME        FSTYPE            LABEL                   UUID                                 FSAVAIL FSUSE% MOUNTPOINT
...
    nvme0n1
    └─nvme0n1p1 ext4              cloudimg-rootfs         24ec7991-cb5c-4fab-99e5-52c45690ba30  189.7G    35% /
┌┈▶ nvme1n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme2n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme3n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme8n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme5n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme4n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
├┈▶ nvme6n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
└┬▶ nvme7n1     linux_raid_member ip-26-0-164-236:MY_RAID d0795631-71f0-37e5-133b-e748befec126
 └┈┈md0         xfs                                       dddb6849-e5b5-4828-9034-96da65da27f0   27.5T     1% /scratch

Çıktı, sistemdeki blok aygıt hiyerarşisini göstermektedir. Burada dikkat edilmesi gereken önemli noktalar şunlardır:

nvme0n1p1, / ​​dizinine monte edilmiş ve 291 GB’lık tam kapasitesinin %35'ini kullanan kök Amazon EBS dosya sistemidir. Sekiz NVMe sürücüsü (nvme1n1'den nvme8n1'e kadar), MY_RAID adlı bir RAID dizisi olarak yapılandırılmıştır. RAID dizisi /dev/md0 olarak gösterilir, XFS ile biçimlendirilmiştir ve 28 TB kullanılabilir alanla (8 × 3,5 TB) /scratch dizinine monte edilmiştir.

Oklar (┈▶), birden fazla NVMe aygıtının aynı RAID dizisinin üyeleri olduğunu ve daha sonra tek bir md0 aygıtında birleştiğini gösterir.

Amazon Elastic Block Store (EBS), Amazon EC2 örnekleriyle kullanılmak üzere tasarlanmış yüksek performanslı, ölçeklenebilir bir blok depolama hizmetidir.

Ağ Depolama

Yerel NVMe depolama alanına ek olarak, sistem ağa bağlı depolama sistemlerine de erişebilir:

$ df -h
Filesystem                                         Size  Used Avail Use% Mounted on
/dev/root                                          291G  101G  190G  35% /
weka-hopper.hpc.internal.huggingface.tech/default  393T  263T  131T  67% /fsx
10.53.83.155@tcp:/fg7ntbev                         4.5T  2.9T  1.7T  63% /admin
/dev/md0                                            28T  206G   28T   1% /scratch

Bu çıktı şunları gösteriyor:

/dev/root (291 GB Amazon EBS), %35 kapasiteyle kök dosya sistemidir.

/fsx (393 TB WekaFS) %67 dolu ve 131 TB kullanılabilir alan mevcut.

/admin (4,5 TB FSx Lustre) %63 dolu ve 1,7 TB kullanılabilir alan mevcut.

/dev/md0 (28 TB yerel NVMe RAID), yalnızca %1 dolu ve /scratch’te 28 TB kullanılabilir alan mevcut. Bu, 8 x 3,5 TB NVMe örnek depolama SSD’lerinden oluşan RAID dizimizdir.

Bizim durumumuzda /fsx aslında Amazon FSx değil, WekaFS’dir. FSx’ten WekaFS’ye geçiş yaparken kolaylık sağlamak için aynı bağlama noktası adını koruduk.

Yerel NVMe RAID dizisi (/scratch), en hızlı G/Ç performansını sağlarken, ağ dosya sistemleri paylaşılan veri depolama için daha büyük kapasite sunar.

Depolama Teknolojisi Özeti RAID (Bağımsız Disklerin Yedekli Dizisi): Veri şeritlendirme, eşlik veya aynalama yoluyla performansı ve/veya güvenilirliği artırmak için birden fazla sürücüyü birleştirir.

NVMe (Kalıcı Olmayan Bellek Express): Doğrudan PCIe’ye bağlanan, SATA/SAS’tan daha yüksek verim ve daha düşük gecikme sağlayan SSD’ler için yüksek performanslı bir depolama protokolüdür.

WekaFS: Yapay zeka/makine öğrenimi iş yükleri için tasarlanmış, düşük gecikmeli erişim ve birden fazla düğümde yüksek verim sağlayan yüksek performanslı paralel bir dosya sistemidir.

FSx Lustre: Paralel erişimi sağlamak için meta verileri ve veri hizmetlerini farklı sunucular arasında ayıran, yüksek performanslı hesaplama için tasarlanmış paralel bir dosya sistemidir. Büyük dosyalar için etkili olsa da, birçok küçük dosya içeren meta veri yoğun yapay zeka/makine öğrenimi iş yüklerinde zorlanabilir.

Depolama Bant Genişliği Karşılaştırması

Her depolama sisteminin performans özelliklerini anlamak için, GPUDirect Storage kullanarak okuma/yazma hızlarını karşılaştırabiliriz. İşte çeşitli konfigürasyonları test eden kapsamlı bir parametrik kıyaslama komut dosyası:

gdsio -f /<disk_path>/gds_test.dat -d 0 -w <n_threads> -s 10G -i <io_size> -x 1 -I 1 -T 10

Bu kıyaslama, depolama sistemi performansını verimlilik, gecikme ve IOPS açısından değerlendirir; ayrıca şunları da değerlendirir:

Ölçeklenebilirlik: Performansın farklı iş parçacığı sayıları ve G/Ç boyutlarıyla nasıl değiştiği. Bu, farklı iş yükü modelleri için en uygun yapılandırmaları ortaya koyar:

• Küçük G/Ç boyutları (64k ila 256k) genellikle IOPS’yi en üst düzeye çıkarır ancak bant genişliğini doyurmayabilir.
• Büyük G/Ç boyutları (2M ila 8M) genellikle verimliliği en üst düzeye çıkarır ancak IOPS’yi azaltır.
• İş parçacığı sayısı her ikisini de etkiler: Daha fazla iş parçacığı, donanım sınırlarına kadar toplam IOPS ve verimliliği artırabilir. Aktarım yöntemi verimliliği: GPU_DIRECT, CPU_GPU ve CPUONLY karşılaştırması, CPU belleğini atlamanın faydasını gösterir:
• GPU_DIRECT, verileri doğrudan GPU belleğine aktarmak için RDMA kullanır ve CPU’yu tamamen atlar (en düşük gecikme, en yüksek verimlilik, küçük işlemler için en iyi IOPS).
• CPU_GPU, verilerin önce CPU belleğine gittiği ve ardından GPU’ya kopyalandığı geleneksel yoldur (CPU ek yükü ve bellek bant genişliği çekişmesi ekler, etkili IOPS’yi azaltır).
• CPUONLY, GPU katılımı olmadan temel CPU-sadece G/Ç’dir.

IOPS IOPS, gdsio çıktısından ops / total_time olarak hesaplanan, saniyede tamamlanan bireysel G/Ç işlemlerinin sayısıdır. IOPS özellikle şunlar için önemlidir:

Küçük G/Ç boyutlarına sahip rastgele erişim modelleri Birçok küçük dosya veya dağınık veri erişimi içeren iş yükleri İşlem başına gecikmenin ham bant genişliğinden daha önemli olduğu veritabanı benzeri işlemler

Daha yüksek IOPS, eşzamanlı, ince taneli veri erişimini daha iyi yönetme yeteneğini gösterir.

Değişken iş parçacığı sayıları ve G/Ç boyutlarında depolama sistemi performansını karşılaştıran kıyaslama sonuçları. Isı haritaları, her depolama katmanı için en uygun yapılandırmaları ortaya koyan verimlilik (GiB/s) ve IOPS modellerini görselleştirir. Not: GPUDirect Storage (GDS) şu anda bu küme yapılandırmasında desteklenmemektedir.

Benchmarklar, dört depolama sistemimiz arasında dramatik performans farklarını ortaya koyuyor:

• /scratch (yerel NVMe RAID), 26.59 GiB/s bant genişliği ve 337k IOPS ile açık ara lider konumda; FSx’e kıyasla 6.3× daha yüksek throughput ve 6.6× daha iyi IOPS sunuyor. 8 × 3.5 TB NVMe diskten oluşan bu yerel RAID dizisi en düşük gecikmeyi (tepe IOPS’ta 190 μs) sağlıyor ve thread sayısına karşı olağanüstü ölçekleniyor; throughput için 64 thread ve 1M I/O boyutlarında en yüksek performansa ulaşıyor.
• /fsx (WekaFS), 4.21 GiB/s ve 51k IOPS ile güçlü bir ağ depolama performansı sunuyor ve makul performans gerektiren paylaşımlı veri için en iyi seçenek oluyor. FSx en iyi throughput değerine (4.21 GiB/s) CPUONLY transferiyle ulaşırken, en iyi IOPS değeri (51k) GPU_DIRECT transferiyle elde ediliyor.
• /admin (FSx Lustre) ve /root (EBS) yaklaşık 1.1 GiB/s throughput ile benzer ve mütevazı performanslar gösteriyor, ancak IOPS kapasitesi açısından önemli ölçüde farklılaşıyor. /admin, GPU_DIRECT transferi ile en yüksek throughput değerine (1.13 GiB/s) ulaşıyor ve CPU_GPU transferi ile 17k IOPS’a kadar çıkıyor (bu, /root’a göre 24× daha iyi), bu da onu çok sayıda küçük işlem içeren iş yükleri için daha uygun hale getiriyor. /root’un düşük IOPS performansı (730), bunun yalnızca büyük ve sıralı işlemler için uygun olduğunu doğruluyor.

Not: GPUDirect Storage şu anda küremizde etkin değil; bu nedenle NVMe depolama için GPU_DIRECT sonuçları (/scratch ve /root), CPUONLY transferlerine kıyasla daha düşük performans gösteriyor. GDS doğru şekilde yapılandırılsaydı, özellikle yüksek performanslı NVMe dizilerinde GPU’dan depolamaya doğrudan transferlerde GPU_DIRECT’in belirgin avantajlar sağlaması beklenirdi.

Tüm depolama türlerinde maksimum throughput 1M I/O boyutlarında, maksimum IOPS ise test edilen en küçük boyutta (64k) elde ediliyor. Bu klasik ödünleşim, iş yüküne bağlı olarak ham bant genişliği (büyük I/O) ile işlem eşzamanlılığı (küçük I/O) arasında seçim yapmayı gerektirir. Büyük checkpoint dosyalarıyla ML eğitimi için /scratch üzerinde 1–8M aralığı en uygun performansı sağlar.

Özet

Bu noktada, depolama hiyerarşisini ve eğitim altyapınızda farklı bileşenlerin nasıl etkileştiğini kapsamlı şekilde anlamış olmalısınız. Ancak asıl kritik çıkarım şudur: Darboğazları tespit etmek, teorik bilgiyi pratik optimizasyondan ayıran şeydir.

Bu bölümde, yığının her seviyesinde gerçek bant genişliklerini ölçtük: tek bir GPU içindeki HBM3’ün 3 TB/s’i, node içi GPU’lar arası NVLink’in 786 GB/s’i, CPU–GPU transferleri için PCIe Gen4 x8’in 14.2 GB/s’i, node’lar arası iletişim için 42 GB/s ağ kapasitesi ve 26.59 GiB/s (yerel NVMe) ile 1.1 GiB/s (paylaşımlı dosya sistemleri) arasında değişen depolama sistemleri. Bu ölçümler, eğitim hattınızın nerede yavaşlayacağını ortaya koyar ve yüksek MFU elde etmek için kritiktir.

Ancak ham bant genişliği sayıları tek başına tüm resmi vermez. Modern eğitim sistemleri hesaplamayı iletişimle örtüştürebilir, böylece iletişim maliyetlerini hesaplamanın arkasında gizleyebilir. Bu paralelleştirme, interconnect yavaş olsa bile darboğazı azaltmaya yardımcı olur. Compute ve communication’ı örtüştürerek throughput’u en üst düzeye çıkarmaya yönelik ayrıntılı stratejiler için Ultra-Scale Playbook’a bakın.

Aşağıdaki diyagram, tüm benchmark ölçümlerimizi tek bir görünümde özetleyerek GPU’dan uzaklaştıkça bant genişliğinin nasıl dramatik biçimde azaldığını gösterir.

Donanım ve yazılım kurulumumuzdaki darboğazları nasıl tespit edeceğimizi artık bildiğimize göre, bir adım daha ileri gidip aylar boyunca stabil şekilde çalışabilecek dayanıklı (resilient) bir sistemin nasıl kurulacağını inceleyelim.

Dayanıklı Eğitim Sistemleri Kurmak

Hızlı donanım, LLM eğitimi için iyi ve stabil bir altyapının yalnızca temel gereksinimidir. Bir eğitim sürecinde amatör seviyeden profesyonel seviyeye geçmek için yalnızca ham hızın ötesine bakmanız ve tüm eğitim deneyimini daha sorunsuz hale getiren, kesinti süresini en aza indiren daha az “gösterişli” ama kritik altyapı bileşenlerine odaklanmanız gerekir.

Bu bölümde odağımızı donanım ve yazılım optimizasyonundan üretim hazırlığına kaydırıyoruz: kaçınılmaz hatalara dayanabilecek kadar sağlam, sürekli müdahale gerektirmeyecek kadar otomatik ve bir şeyler ters gittiğinde uyum sağlayabilecek kadar esnek sistemler kurmak.

Node Sağlığı İzleme ve Değiştirme

Eğitim için yeterli sayıda hızlı GPU’ya sahip olmak önemlidir, ancak LLM eğitimleri bir veya iki gün yerine haftalarca ya da aylarca sürdüğü için GPU sağlığını zaman içinde izlemek kritik hale gelir. İlk benchmark testlerini geçen GPU’lar bile uzun eğitim süreçleri sırasında termal kısıtlama (thermal throttling), bellek hataları veya performans düşüşü göstermeye başlayabilir. Bu bölümde bu problemi nasıl ele aldığımızı ve kullandığımız araçları paylaşacağız.

SmolLM3’ü başlatmadan önce kapsamlı GPU tanılama testleri çalıştırdık. GPU’ları termal kısıtlama, bellek hataları ve performans anormalliklerine karşı stres testine sokan GPU Fryer adlı dahili bir araç kullandık. Ayrıca NVIDIA’nın DCGM Diagnostics aracını da çalıştırdık. Bu araç, GPU donanımını doğrulamak, performansı izlemek ve hesaplama, PCIe bağlantısı, bellek bütünlüğü ve termal kararlılık gibi alanları kapsayan derin tanılama testleri üzerinden arıza veya güç anormalliklerinin kök nedenlerini tespit etmek için yaygın olarak kullanılan bir araçtır. Bu başlangıç testleri, eğitim sırasında sorun çıkarabilecek iki problemli GPU’yu ortaya çıkardı.

Aşağıdaki tablo, DCGM Diagnostics ile nelerin test edilebileceğini göstermektedir:

Kaynak: NVIDIA DCGM Tanılama dokümantasyonu

İşte sonuçlarımıza bir örnek:

$ dcgmi diag -r 2 -v -d VERB
Successfully ran diagnostic for group.
+---------------------------+------------------------------------------------+
| Diagnostic | Result |
+===========================+================================================+
| -----  Metadata  ----------+------------------------------------------------ |
| DCGM Version | 3.3.1 |
| Driver Version Detected | 575.57.08 |
| GPU Device IDs Detected | 2330,2330,2330,2330,2330,2330,2330,2330 |
| -----  Deployment  --------+------------------------------------------------ |
| Denylist | Pass |
| NVML Library | Pass |
| CUDA Main Library | Pass |
| Permissions and OS Blocks | Pass |
| Persistence Mode | Pass |
| Environment Variables | Pass |
| Page Retirement/Row Remap | Pass |
| Graphics Processes | Pass |
| Inforom | Pass |

+-----  Integration  -------+------------------------------------------------+
| PCIe | Pass - All |
| Info | GPU 0 GPU to Host bandwidth:  14.26 GB/s, GPU |
| 0 Host to GPU bandwidth:  8.66 GB/s, GPU 0 b |
| idirectional bandwidth: 10.91 GB/s, GPU 0 GPU |
| to Host latency:  2.085 us, GPU 0 Host to GP |
| U latency:  2.484 us, GPU 0 bidirectional lat |
| ency:  3.813 us |

...
+-----  Hardware  ----------+------------------------------------------------+
| GPU Memory | Pass - All |
| Info | GPU 0 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 1 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 2 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 3 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 4 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 5 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 6 Allocated 83892938283 bytes (98.4%) |
| Info | GPU 7 Allocated 83892938283 bytes (98.4%) |

+-----  Stress  ------------+------------------------------------------------+

SmolLM3’ün Eğitimi Maratonu” bölümünde açıklandığı gibi, SmolLM3 bir Slurm ile yönetilen küme üzerinde eğitildiği için tüm çalışma boyunca 48 node’luk sabit bir rezervasyon ayırttık. Bu kurulum, zaman içinde aynı node’ların sağlık ve performansını takip etmemizi sağladı. Eğitim sırasında tüm node’lar genelinde GPU sıcaklıkları, bellek kullanımı, hesaplama (compute) kullanım oranı ve throughput dalgalanmaları gibi temel metrikleri sürekli izledik. Tüm GPU’lardan DCGM metriklerini toplamak için Prometheus kullandık ve bunları gerçek zamanlı izleme için Grafana dashboard’larında görselleştirdik. AWS altyapısı üzerinde GPU izleme için Amazon Web Services üzerinde AWS kullanan Prometheus ve Grafana kurulumuna dair detaylı yönergeler için awsome-distributed-training reposundaki örnek kurulum rehberine bakabilirsiniz. Bir Slack botu, herhangi bir node şüpheli davranış sergilediğinde bizi uyararak tüm eğitim sürecini çökertmeden önce arızalı donanımı proaktif olarak değiştirmemize olanak sağladı.

Bu çok katmanlı yaklaşım sayesinde, ortaya çıkan herhangi bir donanım sorunu yönetilebilir kesintilere dönüşüyordu.

Termal Gerçeklik Kontrolü: GPU’lar Neden Yavaşlar

Pazarlama teknik özellikleri mükemmel soğutma koşullarını varsayar, ancak gerçek dünya daha karmaşıktır. GPU’lar aşırı ısındıklarında saat hızlarını otomatik olarak düşürerek teorik maksimum performansın altına inerler; bu durum iyi tasarlanmış sistemlerde bile görülebilir.

Termal kısıtlamayı (throttling) tespit etmek için DCGM Diagnostics tarafından sağlanan DCGM_FI_DEV_CLOCK_THROTTLE_REASONS metriğini izledik. Bu metrik sıfırdan farklı değerler gösterdiğinde, GPU’lar aşırı ısınma nedeniyle saat hızlarını otomatik olarak düşürüyor demektir. Aşağıdaki dashboard, bu throttling olaylarının pratikte nasıl göründüğünü göstermektedir:

Bu Grafana kontrol paneli, GPU kümemizdeki termal kısıtlama olaylarını göstermektedir. Alt paneldeki çubuklar, GPU’ların aşırı ısınma nedeniyle saat hızlarını otomatik olarak düşürdüğü zamanları göstermektedir.

Termal kısıtlama yalnızca etkilenen GPU’ya zarar vermekle kalmaz; dağıtılmış eğitim kurulumunuzun tamamına yayılır. Testlerimiz sırasında, tek bir kısıtlama düğümünün toplu iletişim performansını nasıl önemli ölçüde etkileyebileceğini gözlemledik:

Stres testlerimiz sırasında tüm düğümlerde bant genişliğindeki azalmayı gözlemledik. 14 düğümden sonraki keskin düşüş (350 GB/s’den 100 GB/s’ye), tek bir termal olarak kısıtlanmış GPU’dan kaynaklandı ve bu da yavaş bir düğümün tüm dağıtılmış eğitim hattını nasıl darboğaza sokabileceğini gösterdi.

Bu grafik, 1 node’dan 16 node’a ölçeklenirken all-reduce bant genişliğinin nasıl bozulduğunu gösteriyor. Özellikle 14 node’dan sonra keskin bir düşüşe dikkat edin: bant genişliği 350 GB/s seviyesinden 100 GB/s seviyesine iniyor, oysa beklenti 300 GB/s’in üzerinde kalmasıydı. Bu bir ağ problemi değildi: termal kısıtlamaya giren tek bir node, darboğaz haline gelerek gradient senkronizasyonu sırasında tüm diğer node’ları bekletiyordu. Dağıtık eğitimde hız, en yavaş node kadar olur.

Temel ders: Uzun eğitim koşularına başlamadan önce, daha önce bahsedilen araçlarla donanımı stres testine tabi tutarak termal ve güç limitlerini ortaya çıkarın. DCGM telemetrisi ile sıcaklıkları sürekli izleyin ve gerçek dünya termal sınırlarını hesaba katın. Ayrıca GPU clock hızlarının maksimum performans modunda olduğundan emin olmak iyi bir pratiktir. GPU’ların neden güç kısıtları nedeniyle teorik performanslarını sürdüremediğine dair daha derin bir analiz için Horace He’nin güç throttling konusundaki mükemmel incelemesine bakabilirsiniz.

Checkpoint Yönetimi

Checkpoint’ler, uzun eğitim süreçlerimizde güvenlik ağımızdır. Bunları üç pratik nedenle düzenli olarak kaydederiz: hatalardan kurtulmak, eğitim ilerlemesini değerlendirmelerle takip etmek ve ara modelleri araştırma topluluğuyla paylaşmak. En önemli kısım kurtarma (recovery) kısmıdır. Eğer bir eğitim süreci başarısız olursa, en son checkpoint’ten yeniden başlatmak isteriz; böylece yalnızca kayıt aralığı kadar veri kaybederiz (örneğin 4 saatte bir kaydediyorsak en fazla 4 saat).

Kalınan yerden devam etme sürecini otomatikleştirin Resume sürecinizi otomatikleştirmelisiniz. Slurm üzerinde örneğin SBATCH --requeue kullanarak işin en son checkpoint’ten otomatik olarak yeniden başlamasını sağlayabilirsiniz. Böylece bir hatayı birinin fark edip manuel müdahale etmesini bekleyerek zaman kaybetmezsiniz.

Uygularken dikkat edilmesi gereken iki önemli nokta vardır:

• Checkpoint kaydetme işlemi eğitim throughput’unu etkilemeyecek şekilde arka planda yapılmalıdır.
• Depolama kullanımını izleyin. 24 günlük bir eğitimde her 4 saatte bir checkpoint almak yaklaşık 144 checkpoint anlamına gelir. Büyük modeller ve optimizer state’leri düşünüldüğünde bu ciddi bir alan kaplar. Bizim yaklaşımımızda yalnızca en son checkpoint yerelde tutulur, geri kalanlar depolama alanını şişirmemek için Amazon Web Services üzerindeki Amazon S3’e aktarılır.

Geçmişten Acı Bir Ders

İlk büyük ölçekli çalışmamızda (StarCoder), eğitim birkaç restart boyunca sorunsuz ilerledi. Ancak son gün, checkpoint klasörünün tamamının eski throughput testlerinden kalma bir rm -rf $CHECKPOINT_PATH komutu tarafından silindiğini fark ettik. Bu yıkıcı komut yalnızca Slurm job’u gerçekten tamamlandığında çalışıyordu ve önceki restart’larda tetiklenmemişti.

Neyse ki bir gün önceki checkpoint elimizdeydi, bu da yalnızca bir günlük yeniden eğitim maliyeti doğurdu. Çıkarım netti: production script’lerinde asla yıkıcı komutlar bırakmayın ve checkpoint backup işlemlerini manuel müdahaleye güvenmeden, kaydetmenin hemen ardından otomatik hale getirin.

Nanotron eğitimlerimizde checkpoint’leri her 2 saatte bir yerelde kaydediyoruz, hemen ardından Amazon S3’e yüklüyoruz ve yedek doğrulandıktan sonra yerel kopyayı siliyoruz. Resume sırasında eğer en güncel checkpoint yerelde yoksa S3’ten çekiyoruz. Bu yaklaşım hem depolama tasarrufu sağlar hem de hızlı kurtarma imkânı sunar.

Otomatik Değerlendirmeler (Automated Evaluations)

Değerlendirmeleri manuel çalıştırmak hızla darboğaz haline gelir. İlk bakışta basit görünür ama tekrar tekrar yapılınca ciddi zaman kaybettirir. Benchmark çalıştırmak, sonuçları takip etmek ve grafiklemek toplamda büyük bir operasyon yükü oluşturur. Çözüm: her şeyi baştan otomatikleştirmek.

SmolLM3 için değerlendirmeleri LightEval ile Nanotron checkpoint’leri üzerinde çalıştırdık. Her kaydedilen checkpoint, cluster üzerinde otomatik bir evaluation job tetikliyordu. Sonuçlar doğrudan Weights & Biases veya Trackio üzerine gönderildi; böylece sadece dashboard’u açıp eğrilerin nasıl ilerlediğini izledik. Bu yaklaşım ciddi zaman tasarrufu sağladı ve eval takibini tutarlı hale getirdi.

Eğer training setup’ınızda yalnızca bir şeyi otomatikleştirecekseniz, bu değerlendirmeler olsun.

Son olarak, throughput’u maksimize etmek için training layout’unu nasıl optimize edebileceğimize bakalım.

Training Throughput Optimizasyonu

Son altyapı konumuz, training layout’unu yani modelin mevcut GPU’lar arasında nasıl dağıtıldığını optimize etmektir. Bu da bizi temel bir soruya getiriyor…

Kaç GPU’ya İhtiyacımız Var?

Tüm bu spesifikasyon ve benchmark konuşmalarından sonra hâlâ çözmeniz gereken pratik bir soru var: Gerçekte kaç GPU kiralamalı veya satın almalısınız?

Doğru GPU sayısını belirlemek; eğitim süresi, maliyet ve ölçekleme verimliliği arasında denge kurmayı gerektirir. Kullandığımız çerçeve şöyleydi:

Temel boyutlandırma formülü:

GPU sayısı = (GPU başına verim × Hedef eğitim süresi ) / Toplam gerekli FLOP sayısı

​Bu formül problemi üç ana bileşene ayırır:

1. Toplam FLOP ihtiyacı: Modeli eğitmek için gereken hesaplama miktarı (model boyutu, eğitim token’ları ve mimariye bağlıdır)
2. GPU başına throughput: Her GPU’nun saniyede gerçekleştirebildiği FLOP (teorik tepe değer değil!)
3. Hedef eğitim süresi: Eğitimin ne kadar sürede tamamlanmasını istediğiniz

Temel fikir: Teorik tepe performansa değil, gerçekçi verime (MFU) bakmalısınız. MFU, pratikte ulaşılan teorik performans yüzdesidir.

SmolLM3 için:

Model boyutu: 3B parametre Eğitim token’ları: 11T token Hedef süre: ~4 hafta Beklenen MFU: %30

Toplam FLOP hesabı (transformer yaklaşımı: token başına 6N FLOP):

FLOP_total = 6 × N × tokens

FLOP_total = 6 × (3 × 10⁹) × (11 × 10¹²)

FLOP_total = 1.98 × 10²³ FLOP

Efektif GPU throughput:

Throughput_effective = 720 × 10¹² × 0.30

Throughput_effective = 216 × 10¹² FLOP/s

GPU sayısı:

GPU_count = FLOP_total / (Throughput_effective × time)

GPU_count = 1.98 × 10²³ / (216 × 10¹² × 4 × 604,800)

GPU_count ≈ 379 GPU

Sonuç: ~375–400 H100 GPU ihtiyacı

384 GPU seçimi, hem hesaplamaya hem de sistemdeki olası arızalara karşı küçük bir güvenlik payına uygundur.

Amdahl Yasası (kısa form):

Max_speedup = 1 / (S + P / N)

S = seri (paralelleşmeyen) kısım P = paralel kısım N = işlemci sayısı

Dağıtılmış LLM eğitiminde GPU ölçeklendirmesi: Amdahl yasası uygulamada

Bizimki gibi küçük bir modelde, eğer iletişim her eğitim adımının %10’unu alıyorsa, kaç GPU eklerseniz ekleyin en fazla 10× hızlanma elde edebilirsiniz. Daha kötüsü, GPU sayısı arttıkça iletişim oranı genellikle artar, çünkü:

Daha fazla GPU = daha fazla all-reduce katılımcısı = daha uzun senkronizasyon süresi Ağ gecikmesi/bant genişliği bir darboğaz haline gelir Küçük modeller hesaplamanın arkasına iletişimi gizleyemez

SmolLM3 için weak scaling prensiplerini kullandık: global batch size’ımız GPU sayısıyla birlikte ölçeklendi ve küresel olarak GPU başına yaklaşık 8k token seviyesinde tutuldu. Bu, iletişim/hesaplama oranını makul seviyede tutarken throughput’u maksimize etti.

Optimal Paralellik Konfigürasyonunu Bulmak

GPU’ları temin ettikten sonraki bir sonraki zorluk, onları gerçekten verimli şekilde eğitecek biçimde yapılandırmaktır. Bu noktada paralellik stratejisi kritik hale gelir.

Ultra-Scale Playbook yaklaşımını izleyerek optimal eğitim konfigürasyonlarını buluruz. Bu playbook problemi üç ardışık adıma böler: önce modelin belleğe sığıp sığmadığını kontrol et, sonra hedef batch size’a ulaş, ve en sonunda maksimum throughput için optimize et. Bunu SmolLM3’e nasıl uyguladığımıza bakalım.

Farklı paralellik stratejilerinin (data parallelism, tensor parallelism, pipeline parallelism, ZeRO vb.) detaylı açıklamaları için sizi bir kez daha Ultra-Scale Playbook’a bakmaya davet ediyoruz Bernie meme burada devreye girer.

Adım 1: Bir Eğitim Adımını Belleğe Sığdırmak

İlk soru basit: SmolLM3 3B modelimiz tek bir H100’ün 80 GB belleğine sığıyor mu? Bunu cevaplamak için Nanotron’un predict_memory aracını kullandık. Bu araç model parametreleri, optimizer state’leri, gradient’ler ve activation’lar için bellek kullanımını tahmin eder.

Nanotron’un predict_memory aracından elde edilen bellek zaman çizelgesi, SmolLM3 3B’nin 74 GB’ta zirve yaptığını ve H100'ün 80 GB sınırına yaklaştığını gösteriyor.

Sonuçlar, 80 GB sınırına oldukça yaklaştığımızı gösterdi. Bu da GPU başına bellek kullanımını azaltacak bir tür paralelliğe ihtiyacımız olduğu anlamına geliyordu; ister tensor parallelism (model katmanlarını GPU’lar arasında bölmek), ister pipeline parallelism (model derinliğini GPU’lar arasında bölmek), ister ZeRO optimizer sharding (optimizer state’lerini dağıtmak) olsun. Bu stratejilerden en az biri olmadan modeli verimli şekilde, hatta belki de hiç eğitemezdik.

Adım 2: Hedef Global Batch Size’a Ulaşmak

Modelin bir şekilde bellek içine sığabileceğini anladıktan sonra, yaklaşık 2 milyon token olan hedef global batch size (GBS) değerine nasıl ulaşacağımızı belirlememiz gerekiyordu. Bu kısıt bize ilk denklemi verir:

GBS = DP × MBS × GRAD_ACC × SEQLEN ≈ 2M token

GBS = DP × MBS × GRAD_ACC × SEQLEN ≈ 2M token

Burada:

• DP (data parallelism): veri paralel kopya sayısı
• MBS (micro-batch size): her GPU’nun mikro-batch başına işlediği token sayısı
• GRAD_ACC (gradient accumulation): optimizer adımı öncesi forward/backward sayısı
• SEQLEN (sequence length): her örnek başına token sayısı (ilk pretraining aşamasında 4,096)

Ayrıca 384 H100’lük donanım kısıtımız var: DP × TP × PP = 384 = 2⁷ × 3

Burada:

• TP (tensor parallelism): katman içi ağırlık matrislerini GPU’lara bölme sayısı
• PP (pipeline parallelism): model katmanlarını pipeline aşamalarına bölme sayısı

Bu iki denklem arama uzayımızı tanımladı.

Adım 3: Eğitim Throughput’unu Optimize Etmek

Kısıtlarımız belirlendikten sonra, eğitim throughput’unu maksimize eden paralellik konfigürasyonunu bulmamız gerekiyordu. Arama uzayı hem donanım topolojisi hem de model mimarisi tarafından belirlenir.

Donanımımız iki farklı interconnect yapısına sahipti: önceki bölümde gördüğümüz gibi NVLink (node içi iletişim için 900 GB/s) ve EFA (node’lar arası iletişim için ~50 GB/s). Bu yapı doğal olarak en az iki paralellik türünün birlikte kullanılmasını gerektirir. Bant genişlikleri arasındaki büyük fark, hangi paralellik stratejisinin daha iyi çalışacağını güçlü şekilde etkiler.

Model tarafında SmolLM3 mimarisi de seçeneklerimizi sınırlıyordu. Mixture-of-Experts kullanmadığımız için expert parallelism gerekmiyordu. Benzer şekilde, ilk aşamada 4,096 token sequence length ile eğittiğimiz için context parallelism’e de ihtiyaç yoktu. Böylece üç ana paralellik boyutu kaldı: data parallelism (DP), tensor parallelism (TP) ve pipeline parallelism (PP).

Adım 2’den gelen kısıtlarla birlikte şu parametreleri taramamız gerekti:

• DP (ZeRO varyantları ile: ZeRO-0, ZeRO-1, ZeRO-3): 1–384 arası değerler (2 ve/veya 3’ün katlarıyla sınırlı)
• TP (1, 2, 3, 4, 6, 8): NVLink bant genişliğini tam kullanmak için tek node içinde tutulur
• PP (1..48): model derinliğini GPU’lar arasında bölmek için
• MBS (2, 3, 4, 5): bellek tasarrufuna göre batch büyütme
• Activation checkpointing (none, selective, full): bellek için ek compute trade-off’u
• Kernel optimizasyonları: CUDA Graphs ve optimize kernel’ler

Bu kombinasyon sayısı fazla görünse de pratik yaklaşım, önce her boyutu bağımsız benchmarklamak ve throughput’u ciddi düşüren seçenekleri elemekti. Önemli içgörü şu: tüm paralellik stratejileri eşit değildir. Bazıları getirdiğinden fazla iletişim yükü oluşturur.

Bizim durumda pipeline parallelism zayıf performans gösterdi. Çünkü PP, node’lar arasında sık pipeline bubble senkronizasyonu gerektirir ve 3B gibi görece küçük bir modelde bu iletişim maliyeti kazancı yok etti. Ayrıca pipeline bubble’ı tamamen ortadan kaldıracak gelişmiş schedule’lara erişimimiz yoktu, bu da PP’yi daha da verimsiz yaptı. Benzer şekilde ZeRO-0 üzeri seviyeler de all-gather ve reduce-scatter operasyonları nedeniyle throughput’u iyileştirmek yerine düşürdü. Bu erken testler arama uzayını ciddi şekilde daralttı ve bizi data parallelism + sınırlı tensor parallelism kombinasyonuna yönlendirdi.

Her konfigürasyonu değerlendirmek için beş iterasyonluk benchmark çalıştırdık ve metrik olarak GPU başına token/s değerini ölçtük. Weights & Biases ve Trackio kullanarak sonuçları logladık ve karşılaştırmayı kolaylaştırdık.

Nanotron üzerinde yapılan sistematik benchmark’lar sonucunda DP = 192 seçildi. Bu, node’lar arası EFA bant genişliğini data-parallel gradient senkronizasyonu için kullanır. Yani 192 bağımsız model kopyası farklı batch’ler üzerinde çalışır. Tensor parallelism için TP = 2 seçildi; böylece tensor-parallel iletişim tek node içinde kalır ve NVLink’in yüksek bant genişliği tam kullanılır. Bu, her katmanın ağırlık matrislerini iki GPU’ya böler ve forward/backward sırasında hızlı iletişim gerektirir.

Micro-batch size (MBS = 3), bellek kullanımı ile compute verimliliği arasında bir denge sağlar. Daha büyük batch’ler Tensor Core kullanımını artırabilirdi ancak bellek sınırına zaten yakındık. Son olarak ZeRO-0 seçildi; yani optimizer state sharding kullanılmadı. ZeRO-1 veya ZeRO-3 bellek kullanımını düşürebilirdi ancak 384 GPU arasında optimizer state iletişimi throughput’u ciddi şekilde düşürürdü.

Bu kararların birçoğu o dönemde kullandığımız framework’lerin durumuna bağlıydı. Örneğin Nanotron henüz ZeRO-3 desteklemiyordu ve pipeline parallelism için çok optimize schedule’lar yoktu. Framework geliştikçe bu trade-off’lar değişebilir.

Bu konfigürasyon, yaklaşık 2 milyon token’lık hedef global batch size’ı sağladı (192 × 3 × 1 × 4096 ≈ 2.3M) ve 384 H100 cluster üzerinde maksimum throughput elde etti. Tam training konfigürasyonu stage1_8T.yaml dosyasında yer alıyor.

Böylece altyapı bölümünün sonuna gelmiş olduk. Şimdi bir adım geri çekilip daha büyük resme bakalım: neyi kapsadık, ne öğrendik ve bunların hepsi nereye gidiyor.

9. Sonuç

Bu yolculuğa basit bir soruyla başladık: 2025’te yüksek performanslı bir LLM (Büyük Dil Modeli) eğitmek için gerçekten ne gerekir? Ön eğitimden sonradan eğitime kadar tüm süreci adım adım inceledikten sonra, size yalnızca teknikleri değil, onları işe yarar hale getiren metodolojiyi de gösterdik.

Büyük ölçekte ön eğitim.

Eğitim Pusulası (Training Compass) çerçevesiyle işe gerçekten başlamaya değip değmeyeceğine nasıl karar vereceğimizi inceledik; ardından hedefleri somut mimari kararlara nasıl çevireceğimizi gösterdik. Güvenilir ablation süreçlerinin nasıl kurulacağını, değişikliklerin tek tek nasıl test edileceğini ve birkaç milyar token’lık deneylerden trilyonlarca token’a kadar nasıl ölçeklenebileceğini gördünüz. Büyük ölçekte ortaya çıkabilecek altyapı zorluklarını (veri yükleyici darboğazları, throughput çöküşleri, gizli hatalar) belgeledik ve bunların erken fark edilip hızlıca giderilmesini sağlayan izleme ile sistematik risk azaltma yöntemlerini paylaştık.

Sonradan eğitim (post-training) uygulamada.

Bir temel modelden üretim seviyesinde bir asistana geçmenin kendi sistematik yaklaşımını gerektirdiğini gösterdik: herhangi bir eğitime başlamadan önce değerlendirme (eval) süreçlerini kurmak, SFT (denetimli ince ayar) veri karışımlarında yinelemeli olarak çalışmak, tercih optimizasyonunu uygulamak ve isteğe bağlı olarak RL (pekiştirmeli öğrenme) ile daha da ileri gitmek. Metriklerin gözden kaçırdığı hataları “vibe testing” ile nasıl yakalayabileceğinizi, sohbet şablonlarının (chat templates) komut takibini sessizce nasıl bozabileceğini ve veri karışımı dengesinin sonradan eğitimde de ön eğitim kadar önemli olduğunu gördünüz.

Her iki aşama boyunca da aynı temel içgörülere tekrar tekrar döndük: Her şeyi deneylerle doğrulayın, her seferinde yalnızca bir şeyi değiştirin, ölçek büyüdükçe yeni türden hataların ortaya çıkmasını bekleyin ve kararları yeni çıkan her makaleyi kovalamak yerine kullanım amacınızın yönlendirmesine izin verin.

Bu süreci izleyerek SmolLM3’ü eğittik: uzun bağlam desteğine sahip, çok dilli, güçlü bir 3 milyarlık akıl yürütme modeli. Bu süreçte neyin işe yaradığını, neyin bozulduğunu ve işler ters gittiğinde nasıl hata ayıklayacağımızı öğrendik. Başarıları da, hataları da elimizden geldiğince belgeledik.

Sırada ne var? Bu yazı modern LLM eğitiminin temellerini kapsıyor, ancak bu alan hızla gelişiyor. Daha derine inmenin birkaç yolu:

• Kendi deneylerinizi yapın. Ablation’lar hakkında okumak faydalıdır; ancak kendi deneylerinizi yapmak gerçekten neyin önemli olduğunu öğretir. Küçük bir model seçin, değerlendirmeleri kurun ve denemelere başlayın.
• Kaynak kodu okuyun. Nanotron, TRL ve benzeri eğitim çerçeveleri açık kaynaklıdır. Uygulamalarını anlamak, makalelerde geçiştirilen ayrıntıları ortaya çıkarır.
• Güncel çalışmaları takip edin. En yeni model makaleleri, alanın nereye yöneldiğini gösterir. Kaynakça bölümünde, etkili makalelerden ve kaynaklardan oluşan özenle seçilmiş listemizi bulabilirsiniz.

Atıflar

Aşağıda, LLM eğitim yolculuğumuzda bize yol gösteren makalelerin, kitapların ve blog yazılarının derlenmiş bir listesi bulunmaktadır.

LLM Mimarisi

• Dense models: Llama 3, OLMo 2, MobileLLM
• MoEs: DeepSeek-V2, DeepSeek-V3, Scaling Laws of Efficient MoEs
• Hybrid models: MiniMax-01, Mamba2

Eniyileyiciler ve Eğitim Parametreleri

• Muon is Scalable for LLM Training, Fantastic Pretraining Optimizers
• Large Batch Training, DeepSeek LLM

Veri Küratörlüğü

• Web: FineWeb & FineWeb-Edu, FineWeb2, DCLM
• Code: The Stack v2, To Code or Not to Code
• Math: DeepSeekMath, FineMath, MegaMath
• Data mixtures: SmolLM2, Does Your Data Spark Joy?

Ölçekleme Yasaları

• Kaplan, Chinchilla, Scaling Data-Constrained Language Models

Ardıl-Eğitim

• InstructGPT: OpenAI’s foundational paper to turn base models into helpful assistants. The precursor to ChatGPT and a key step on humanity’s path up the Kardashev scale.
• Llama 2 & 3: Extremely detailed tech reports from Meta on the training behind their Llama models (may they rest in peace). They each contain many insights into human data collection, both for human preferences and for model evaluation.
• Secrets of RLHF in LLMs, Part I & II: These papers contain lots of goodies on the nuts and bolts of RLHF, specifically on how to train strong reward models.
• Direct Preference Optimization: The breakthrough paper from 2023 that convinced everyone to stop doing RL with LLMs.
• DeepSeek-R1: The breakthrough paper from 2025 that convinced everyone to start doing RL with LLMs.
• Understanding R1-Zero-Like Training (Dr. GRPO): One of the most important papers on understanding the baked-in biases with GRPO and how to fix them.
• DAPO: Bytedance shares many implementation details to unlock stable R1-Zero-like training for the community.
• ScaleRL: A massive flex from Meta to derive scaling laws for RL. Burns over 400k GPU hours to establish a training recipe that scales reliably over many orders of compute.
• LoRA Without Regret: A beautifully written blog post which finds that RL with low-rank LoRA can match full fine-tuning (a most surprising result).
• Command A: A remarkably detailed tech report from Cohere on various strategies to post-train LLMs effectively.

Altyapı

• Ultra-Scale Playbook
• Jax scaling book
• Modal GPU Glossary

Eğitim Çerçeveleri

• Megatron-LM
• DeepSpeed
• TorchTitan
• Nanotron
• NanoChat
• TRL

Değerlendirme

• LLM Evaluation Guidebook
• OLMES
• FineTasks
• Lessons from the Trenches

Kaynak

Ben Allal, L., Tunstall, L., Tazi, N., Bakouch, E., Beeching, E., Patiño, C. M., Fourrier, C., Frere, T., Lozhkov, A., Raffel, C., von Werra, L., & Wolf, T. (2025, October 30). The Smol Training Playbook: The Secrets to Building World-Class LLMs. Retrieved from https://huggingface.co/spaces/HuggingFaceTB/smol-training-playbook#introduction