Bir LLM Aslında Nedir? İndirdiğiniz Dosyanın İçinde Ne Var?

Bir modeli indirdiniz, diskinizde 16 GB'lık bir dosya duruyor ve çalıştırınca size Türkçe cevap veriyor. Peki o dosyanın içinde ne var? Bu yazıda bir LLM'i parça parça açacağız: dosyanın anatomisi, "8B" neyi sayıyor, o sayılar nasıl oluştu ve siz bir soru sorduğunuzda tam olarak ne oluyor.

Bu yazıya "LLM kullanıyorum, hatta lokalde model çalıştırdım ama kaputun altında ne döndüğünü hiç bilmiyorum" diyerek geldiyseniz tam yerindesiniz. Sonunda bir model kartına bakıp Llama-3.1-8B-Instruct-Q4_K_M ya da 671B-A37B gibi bir ismin her parçasının ne anlattığını okuyabileceksiniz — ve daha önemlisi, model çalışırken hangi sayının nereye gittiğini kafanızda canlandırabileceksiniz.

Bir uyarıyla başlayalım, çünkü çoğu kafa karışıklığının kaynağı bu: model bir program değildir. İçinde "eğer kullanıcı selam derse merhaba de" diye bir satır yok. Dilbilgisi kuralları yok, sözlük yok, cevap veritabanı yok. İçinde yalnızca sayılar var — milyarlarca tane, hiçbirinin tek başına anlamı olmayan ondalık sayı. Yazının tamamı bu tuhaf gerçeğin açıklaması.

1. Dosyanın İçinde Ne Var?

Hugging Face'ten bir model indirdiğinizde karşınıza çıkan asıl dosyalar .safetensors uzantılıdır. Bu format, adı üstünde, PyTorch'un eski .bin (pickle) formatının güvenli alternatifi olarak çıktı: eski format dosyayı açarken içindeki kodu çalıştırabiliyordu, dolayısıyla indirdiğiniz bir model teorik olarak makinenizde kod koşturabilirdi. Safetensors bunu kökten keser, çünkü içinde çalıştırılacak hiçbir şey yoktur^[1][2].

Yapısı şaşırtıcı derecede sade. Dosyanın başında bir JSON başlık var: hangi tensörün adı ne, veri tipi ne, şekli ne ve dosyanın neresinden başlıyor. Başlığın ardından da o tensörlerin ham baytları arka arkaya dizilmiş durumda. Hepsi bu^[2][25].

Buradan çok önemli bir ayrım çıkıyor: model = mimari + ağırlıklar, ve bu ikisi ayrı yerlerde durur. Mimari — kaç katman var, katmanlar nasıl bağlanıyor, hangi sırayla ne çarpılıyor — transformers gibi bir kütüphanenin kodudur. İndirdiğiniz dosya ise o mimarinin içine dökülecek sayılardır. Aynı mimariye farklı ağırlıklar koyarsanız bambaşka bir model elde edersiniz; ağırlıkları koymazsanız elinizde saçmalayan boş bir iskelet kalır.

2. "8B" Neyi Sayıyor?

Model isimlerindeki 8B, 70B, 671B ifadeleri parametre sayısını söyler. Parametre, eğitim sırasında ayarlanan tek bir sayıdır — az önceki matrislerin içindeki tek bir hücre. 8B demek, ayarlanmış 8 milyar sayı demek.

Buradan dosya boyutuna geçmek basit bir çarpma: her parametrenin kaç bayt yer kapladığını bilmeniz yeter. Modern modeller genelde bf16 (16 bit, yani 2 bayt) olarak yayımlanır^[3]:

Bu tablo, "8 milyar parametreli modeli 8 GB'lık ekran kartımda çalıştırabilir miyim?" sorusunun cevabıdır: bf16 ile hayır, 4 bit ile evet^[4][5]. Quantization (nicemleme) denen işlem tam olarak budur — her sayıyı daha az bitle temsil etmek. Sezgiye aykırı gelen kısmı şu: 16 bitlik bir sayıyı 4 bite indirdiğinizde modelin cevap kalitesi çökmüyor, sadece hafifçe bozuluyor. Çünkü bu sayıların hiçbiri tek başına kritik değil; anlam milyarlarcasının ortak davranışında.

Dikkat: Model dosyası belleğe sığdı diye iş bitmiyor. Modelin yanında bir de KV cache için yer ayırmanız gerekiyor — 7. bölümde göreceğiz, uzun context'te bu, modelin kendisi kadar yer kaplayabiliyor.

3. Peki O Sayılar Modelin Neresinde Duruyor?

Cevaba geçmeden önce modelin bir hattı olduğunu görelim, çünkü bundan sonra sık kullanacağım "giriş" ve "çıkış" kelimeleri bu hattın iki ucunu anlatıyor.

Bir LLM tek yönlü bir boru hattı gibi çalışır. Girişte metin yoktur — tokenizer cümlenizi parçalara ayırır ve her parçaya sözlükteki sıra numarasını verir; modele giren şey bu numaralardır. İlk iş, her numaranın karşılığındaki vektörü bir tablodan bulup çıkarmaktır. Sonra bu vektörler 32 katmanın içinden sırayla geçer; her katman onları biraz daha bağlamla zenginleştirir ama boyutlarını hiç değiştirmez — girişte 4096 sayı, 32 katman sonra yine 4096 sayı. Çıkışta ise son vektör tekrar sözlük boyutuna açılır: 128.256 aday token'ın her biri için bir skor. Modelin ürettiği ham çıktı budur — bir kelime değil, 128.256 sayı.

Şimdi parametreleri bu hattın üzerine yerleştirebiliriz.

İki uçtaki tablolar. Her ikisi de 128.256 × 4096 şeklinde, yani ~525'er milyon parametre. Llama 3 8B'de bunlar ayrı ayrı öğrenilir — yapılandırma dosyasında tie_word_embeddings: false yazar^[3][6]. Bazı küçük modellerde ise tek bir tablo iki uçta paylaşılır ve model bir hamlede yarım milyar parametre tasarruf eder.

Tekrar eden katmanlar. İşin bel kemiği. Llama 3 8B'de 32 tane özdeş yapıda katman var ve her birinin içinde iki alt bölüm bulunuyor: attention bölümü (token'ların birbirine bakmasını sağlayan W_Q, W_K, W_V, W_O matrisleri)^[23] ve feed-forward bölümü (her token'ı tek tek işleyen, çok daha geniş üç matris).

Bir dakika — "katmanın içinde iki alt bölüm" da ne demek?

Burada durup bir terim kazasını çözelim, çünkü "katman" kelimesi iki farklı şeyin adı ve ikisi karıştırılınca bu bölümün tamamı anlaşılmaz oluyor.

Sinir ağı denince akla gelen klasik şemayı düşünün: yan yana nöron sütunları, aralarında oklar. O şemada katman = bir nöron sütunudur; bir matris çarpımı, bir aktivasyon, bitti. Transformer'da ise katman = bir bloktur, yani o klasik şemadaki birkaç katmanın paketlenmiş hali. İngilizce kaynaklarda buna transformer block ya da decoder layer deniyor — ama "layer" kelimesi ikisi için de kullanıldığından karışıklık kaçınılmaz oluyor.

Farkın asıl kaynağı şu: klasik şemada ağdan geçen şey tek bir vektördür. Transformer'da geçen şey bir vektör dizisidir — cümlede kaç token varsa o kadar vektör, alt alta. Klasik şemada bunun karşılığı yoktur, ve bu fark her şeyi değiştirir: artık iki ayrı yönde karıştırma yapmanız gerekir.

Alt bölüm 1 — attention. Token'ların birbirine baktığı yer. "oturdu"nun vektörüne "kedi"nin vektöründen bilgi taşır. Klasik şemada böyle bir hareket olamaz; orada tek vektör vardır, kiminle konuşacak?

Alt bölüm 2 — feed-forward. Her token'ın tek başına işlendiği yer; diğer token'lara hiç bakmaz. 4096 sayıyı alır, 14336'ya açar, tekrar 4096'ya indirir. Ve işin güzel tarafı şu: bu, tam da yukarıda tarif ettiğim klasik şemanın kendisidir. Yani o resim yanlış değil — bir transformer katmanının yarısının içinde ne olduğunu gösteriyor.

Bu bölümleme benim uydurduğum bir kolaylık da değil; kodda birebir böyle duruyor. Bir katman nesnesinin içinde tam olarak iki alt modül var^[6]:

model.layers[0]          # "katman 0" — bir blok
├── self_attn            # W_Q, W_K, W_V, W_O
└── mlp                  # gate, up, down  (klasik şemadaki ağ)

model.layers[1]
├── self_attn
└── mlp
...  32 kez

Son bir not: her iki alt bölümün de çıktısı, girdisinin üzerine eklenir. Buna residual connection (artık bağlantı) deniyor^[23]. Yani attention da feed-forward da vektörü baştan yazmaz, ona bir düzeltme ekler. Bir önceki şemada "boyut hep 4096 kalır" diyebilmemizin sebebi tam olarak budur — ve 32 katmanın üst üste binebilmesinin de.

Peki bu bölgeler parametre bütçesini nasıl paylaşıyor? Llama 3 8B'nin yapılandırma değerlerinden hesaplayalım — sonuç çoğu kişiyi şaşırtıyor:

Buradaki asimetriyi akılda tutmakta fayda var: bir modeli küçültmeye ya da hızlandırmaya çalışırken sadece attention'a bakmak yetmez, ağırlığın çoğu başka yerde^[7][8]. Attention'ın içeride tam olarak ne yaptığı ise başlı başına bir konu — yazının sonunda oraya yönlendireceğim.

4. Token: Modelin Alfabesi

Model harflerle de kelimelerle de çalışmaz; token denen ara birimlerle çalışır. Token bazen bütün bir kelime, bazen bir kelimenin parçası, bazen tek bir noktalama işaretidir. Sebebi pratik: harf bazlı çalışmak dizileri gereksiz uzatır, kelime bazlı çalışmak ise sözlükte olmayan her kelimede sistemi kilitler. Token ikisinin arasındaki tatlı nokta.

Llama 3'ün kelime dağarcığı 128.000 token içeriyor ve Meta bu tokenizer'ın Llama 2'ye kıyasla aynı metni %15'e kadar daha az tokenla ifade ettiğini söylüyor^[9]. Bu detay önemli, çünkü token sayısı doğrudan paranız ve context'iniz demek.

Ve burada Türkçe konuşanları ilgilendiren bir mesele var

Bu tokenizer'lar ezici çoğunlukla İngilizce metinle eğitiliyor. Sonuç şu: İngilizce bir kelime çoğunlukla tek token'a sığarken, eklerle uzayan diller kelime başına çok daha fazla token harcıyor. On temel modelin tokenizer'ını 24 Avrupa dilinde ölçen bir çalışma bu farkı net gösteriyor: İngilizce kelime başına ~1,2 token'da kalırken, Fince ve Macarca gibi eklemeli (agglutinative) diller 2,7–3,0 bandına çıkıyor^[10].

Çalışmada Türkçe yok — ama Türkçe de tam olarak o gruba, eklemeli diller ailesine ait. Türkçe için yapılan ayrı ölçümler de yaygın tokenizer'larda kelime başına 1,8–2,9 token aralığını raporluyor^[11][12].

Bunun günlük hayattaki karşılığı net: API'den token başına ödeme yapıyorsanız aynı metin için İngilizceye göre yaklaşık iki katı ödüyorsunuz, ve 128K'lık bir context penceresi Türkçe metinde İngilizcedeki kadar uzağa gitmiyor.

5. Bu Sayılar Nasıl Oluştu? — Pre-training

Şimdi asıl soruya geldik: milyarlarca sayının değerini kim belirledi? Cevap kimse — daha doğrusu, hiçbir insan tek tek belirlemedi. Süreç şöyle işliyor.

Başlangıçta bütün matrisler rastgele sayılarla dolu. Model bu hâliyle tam bir zırva üretiyor. Sonra tek ve çok basit bir alıştırma başlıyor: devasa bir metin yığınından bir parça al, son kelimeyi kapat, modele "sıradaki token ne?" diye sor.

Model bir tahmin üretir. Tahmin yanlıştır. Yanlışlığın büyüklüğü bir sayıya çevrilir (buna loss, yani kayıp denir). Ardından backpropagation devreye girer: bu hata sinyalini ağın içinden geriye taşır ve her parametre için "sen bu hataya ne kadar sebep oldun, hangi yöne kıpırdasan hata azalırdı?" sorusunu cevaplar. Her parametre o yönde çok küçük bir adım atar. Sonra bir sonraki metin parçası gelir, döngü yeniden başlar.

Bu döngünün büyüsü, milyarlarca kez tekrarlanmasında. Llama 3, herkese açık kaynaklardan toplanmış 15 trilyondan fazla token üzerinde eğitildi^[9][24]. Etiketli veri gerekmedi; doğru cevap zaten metnin kendisinde duruyordu.

Şekildeki son kutu ilginç bir hikâye anlatıyor. 2022'de yayımlanan Chinchilla çalışması, belli bir eğitim bütçesi için en verimli dağılımın parametre başına yaklaşık 20 token olduğunu göstermişti^[13][14]. Llama 3 8B'de bu oran 1.870 — yani "en verimli" noktanın neredeyse yüz katı veri.

Bu bir hata değil, bilinçli bir tercih. Chinchilla eğitim maliyetini optimize ediyor. Ama bir model bir kez eğitilip milyonlarca kez çalıştırılıyor; dolayısıyla asıl fatura eğitimden değil, inference'tan geliyor. Küçük bir modeli "gereğinden fazla" eğitmek, sonsuza kadar daha ucuz çalışan bir model demek. Son yılların küçük ama şaşırtıcı derecede iyi modellerinin sırrı büyük ölçüde bu.

6. Base Model Sohbet Etmez — Post-training

Pre-training biter, elinizde bir base model vardır. Ve base model sandığınız şey değildir: sohbet etmez, talimat dinlemez. Yaptığı tek şey metni devam ettirmektir, çünkü öğrendiği tek beceri bu.

Base model'a "Türkiye'nin başkenti neresidir?" diye sorarsanız cevap vermek yerine soruyu çoğaltabilir — internette bu cümle genelde bir sınav sorusu listesinin içinde geçtiği için:

Base model'ı asistana çeviren aşamaya post-training deniyor ve iki ana adımdan oluşuyor. Birincisi SFT (supervised fine-tuning): insanlar tarafından yazılmış "şöyle sorulunca böyle cevap verilir" örnekleriyle modeli eğitmek^[15]. İkincisi tercih optimizasyonu: aynı soruya üretilen iki cevaptan hangisinin daha iyi olduğu insanlara sorulur, model iyi bulunana yaklaşacak şekilde ayarlanır. Llama 3'te bu aşamada SFT, rejection sampling, PPO ve DPO birlikte kullanıldı^[9][16].

Pratik sonuç: Bir instruct model'i kendi kodunuzdan çağırırken chat template'ini doğru uygulamak zorundasınız — mesajları hangi özel token'larla sarmaladığınız modelin eğitimde gördüğü kalıpla eşleşmezse kalite belirgin biçimde düşer. Bu, lokalde model çalıştıran ekiplerin en sık düştüğü tuzaklardan biri.

7. Siz Soru Sorduğunuzda Ne Oluyor?

Eğitim bitti, dosya diskinizde. Şimdi bir soru soruyorsunuz. Model ne yapıyor?

Sürpriz olabilir ama model cevabı bir bütün olarak düşünmüyor. Her seferinde tek bir token üretiyor, ürettiğini girdinin sonuna ekliyor ve baştan başlıyor. Buna autoregressive (özbağlanımlı) üretim deniyor. Ekranda akan cevap, saniyede onlarca kez tekrarlanan bu döngünün görüntüsü.

Her adımda modelin çıkışında kelime dağarcığının tamamı için — Llama 3'te 128.256 aday için — bir olasılık dağılımı oluşuyor. Sonraki token bu dağılımdan seçiliyor ve nasıl seçildiğini siz ayarlıyorsunuz^[17][18]:

"Aynı soruya neden her seferinde farklı cevap alıyorum?" sorusunun cevabı burada. Model değişmiyor — dağılımdan yapılan seçim rastgele. temperature=0 derseniz seçim rastgele olmaktan çıkar ve büyük ölçüde aynı cevabı alırsınız.

KV cache: aynı işi iki kez yapmamak

Döngünün maliyetli bir yanı var. Her yeni token'da modelin, o ana kadarki bütün metni yeniden işlemesi gerekir. 500 token'lık bir cevabın 500. adımında, ilk 499 token için aynı hesapları 499. kez yapmak akıl kârı değil.

Çözüm KV cache: modelin her token için hesapladığı ara değerler (key ve value tensörleri) bellekte tutulur, sonraki adımlarda yeniden hesaplanmaz^[19]. Llama 3'te bu cache'in görece küçük kalmasının sebebi de GQA: birden fazla query head aynı key/value çiftini paylaşıyor^[22]. Bu yüzden üretim iki faza ayrılır — prompt'un tamamının bir kerede işlendiği prefill ve token token ilerleyen decode.

Bedeli bellek. Llama 3 8B'de token başına 128 KB KV cache tutulur. Zararsız görünüyor, ta ki çarpana kadar:

8. Model Kartını Okumak

Artık bir model ismindeki her parçayı çözebilirsiniz. Örnek üzerinden gidelim:

Son satır ayrı bir paragrafı hak ediyor, çünkü 2026'nın en yaygın mimari deseni bu. Mixture of Experts (MoE) modellerde feed-forward bölümü tek bir blok değil, onlarca "uzman"a bölünmüş durumda ve her token için yalnızca birkaçı devreye giriyor^[20]. DeepSeek-V3 bunun bilinen örneği: toplam 671 milyar parametre, token başına aktif 37 milyar^[21].

Buradaki takas çok net ve pratikte can yakıcı: hız aktif parametreye, bellek ihtiyacı toplam parametreye bağlıdır. Yani 37 milyarlık bir modelin hızını alırsınız ama 671 milyarlık bir modeli belleğe sığdırmak zorundasınızdır. "Ucuz çalışıyor" demek "ucuz kurulur" demek değil.

Toparlayalım

Baştaki soruya dönelim: indirdiğiniz dosyanın içinde ne var? Cevap artık tek cümleye sığıyor — bir metin yığınında sonraki token'ı tahmin etmeye çalışırken milimetrik olarak ayarlanmış milyarlarca sayı.

O sayılar embedding tablosunda, tekrar eden 32 katmanda ve çıkış katmanında duruyor. Çoğunluğu feed-forward bölümünde. Siz soru sorunca model bunları kullanarak 128 bin aday arasında bir olasılık dağılımı üretiyor, oradan bir token seçiliyor, döngü baştan başlıyor. Aradaki hesabı tekrarlamamak için KV cache tutuluyor; onun da bedeli bellek.

Peki en kritik parça? Bir katmanın içindeki attention bölümü — yani token'ların birbirine bakıp bağlam kurduğu yer. Bu yazıda ona kasten girmedim, çünkü tek başına bir yazıyı hak ediyor. "kedi mindere oturdu" cümlesinde "oturdu"nun neden "kedi"ye uzandığını, W_Q, W_K ve W_V matrislerinin o çarpımlarda tam olarak ne yaptığını gerçek rakamlarla görmek isterseniz sıradaki durak Self-Attention: Bir Kelime Diğerlerine Nasıl Bakar? yazısı.

Ama önce şunu yapın: bir model indirin, config.json'ını açın ve bu yazıdaki hesapları kendi modelinizle tekrarlayın. Kaç katman var, embedding boyutu kaç, parametrelerin ne kadarı feed-forward'da? On dakikalık bir alıştırma ve bu yazının tamamını okumaktan daha çok şey öğretiyor. Daha da derine inmek isterseniz Sebastian Raschka'nın sıfırdan LLM inşa eden kitabı^[26] bu yazının doğal devamı. Kolay gelsin!

Kaynaklar