Rehber / Bölüm 1 · ücretsiz önizleme

1. LLM temelleri

LLM nedir ve nasıl çalışır: token, transformer ve parametreler, inference, KV cache ve prompt caching, context ve API, donanım ve performans, model seçimi, fine-tuning ve LoRA.

Bu sayfa rehberin 1. bölümünün ilk kısmıdır ve herkese açıktır. Diyagramları oynatabilirsiniz: adımları tek tek ilerletin ya da otomatik oynatın.

LLM (Large Language Model, büyük dil modeli), çok büyük miktarda metinle eğitilmiş, metni anlayıp üretebilen bir yapay sinir ağıdır. "Büyük" iki şeyi anlatır: eğitimde kullanılan metnin hacmini ve modelin milyarlarca parametresini. GPT, Claude, Gemini, Llama ve Qwen gibi model ailelerinin hepsi birer LLM'dir.

Bir LLM'in temelde yaptığı tek iş, kendisine verilen metne bakarak bir sonraki token'ı (kelime parçasını) tahmin etmektir. Soru cevaplama, özetleme, çeviri, kod yazma ya da bir tool'u çağırmaya karar verme gibi bütün yetenekler bu tek işlemin art arda tekrarlanmasından doğar. Sonraki bölümlerde anlatılan AI agent'lar da bu tahmin makinesinin etrafına kurulmuş yazılımlardır; bu yüzden agent'ı anlamanın ilk adımı LLM'i anlamaktır.

LLM ile model aynı şey mi? Hayır; LLM bir model türüdür. Model, makine öğrenmesinde veriden öğrenilmiş parametreleri olan ve bir girdiye karşılık çıktı üreten her sistemin genel adıdır. Bir fotoğraftaki nesneyi tanıyan, sesi yazıya çeviren ya da bir cümleyi sayı vektörüne çeviren sistemlerin hepsi modeldir. LLM ise bunların içinde dil üzerine eğitilmiş, metin üreten büyük transformer modelleridir. Her LLM bir modeldir, ama her model bir LLM değildir:

Bu rehberde "model" kelimesi, aksi söylenmedikçe LLM anlamında kullanılır. İlgili üç terim: model ailesi aynı ekibin farklı boy ve sürümlerdeki modelleridir (Gemma 4 ailesinin küçük ve büyük sürümleri gibi); SLM (small language model) 1–10 milyar parametrelik küçük LLM'lerdir; foundation model (temel model) çok geniş veriyle eğitilip birçok işe uyarlanabilen büyük modellerin üst adıdır ve LLM'ler bunun en yaygın örneğidir.

Bu bölüm LLM'i temelden uygulamaya doğru anlatır; her alt bölüm bir öncekinde tanımlanan terimleri kullanır:

1. 1.1 LLM nedir, neyden oluşur: genel çalışma mantığı ve neden kullanıldığı; model = mimari + weights + tokenizer + chat şablonu; token, tokenizer ve sampling; transformer, layer, attention ve MoE.
2. 1.2 Model nasıl çalışır: inference engine, prefill ve decode, KV cache, TTFT ve tokens/s, prefix caching ve prompt caching.
3. 1.3 Model seçimi: açık ve kapalı modeller, context boyları, yetenekler, model tipleri.
4. 1.4 Uygulama modelle nasıl konuşur: context ve context window, mesaj rolleri, API formatı ve chat şablonu, bir mesajın yolculuğu, oturum, memory ve RAG.
5. 1.5 Donanım ve performans: model nerede durur, bant genişliği, kuantizasyon, VRAM bütçesi, cihaz karşılaştırması, concurrency, KV cache yönetimi (PagedAttention), vLLM ayarları ve inference engine karşılaştırması.
6. 1.6 Model eğitimi ve özelleştirme: pre-training, fine-tuning, LoRA ve QLoRA, RAG ile farkı.

Gerçek bir sunucuda (aiserver) Ollama ayarlarının kontrolü ve bir isteğin canlı izlenmesi dokümanın sonundaki Ek A'dadır.

1.1LLM nedir, neyden oluşur

LLM nasıl çalışır: genel bakış

Bir LLM'e metin verdiğinizde içeride dört adımlık bir döngü çalışır:

1. Metin sayılara çevrilir. Tokenizer metni token'lara böler ve her token'ı sözlükteki numarasına (token ID) çevirir. Model kelimeleri değil, bu sayıları görür.
2. Model olasılık hesaplar. Sayılar modelin katmanlarından (layer) sırayla geçer. Son katmanın çıktısı, sözlükteki her token için "sıradaki token bu olabilir" olasılığıdır.
3. Bir token seçilir. Bu olasılıklardan biri seçilir (sampling). "Türkiye'nin başkenti" metninden sonra en yüksek olasılık büyük ihtimalle "·Ankara" token'ına çıkar.
4. Seçilen token metne eklenir ve döngü başa döner. Model yeni metne bakıp bir sonraki token'ı tahmin eder. Cevap bu şekilde token token üretilir ve model "bitti" anlamına gelen özel bir token ürettiğinde durur. Sohbet arayüzlerinde cevabın kelime kelime akmasının (streaming) nedeni budur.

Neden kullanıyoruz? Model eğitim sırasında çok büyük miktarda metinden dilin yapısını, kavramlar arasındaki ilişkileri ve talimatlara uymayı öğrenir. Bu sayede kural yazmadan, doğal dille iş yaptırabiliriz: serbest metni anlamak, bir log ya da e-postayı yapılandırılmış veriye çevirmek, özetlemek, kod yazmak ve bir isteği karşılamak için hangi tool'un çağrılacağına karar vermek.

Sınırları da aynı mekanizmadan gelir. Model doğruyu değil, en olası devamı üretir. Bilgisi eğitim verisinin tarihiyle sınırlıdır, emin olmadığı yerde akla yatkın ama yanlış cevap üretebilir (hallucination) ve aynı soruya her seferinde birebir aynı cevabı vermeyebilir. Bu yüzden güncel veri tool'larla verilir, kesinlik gerektiren hesaplar ve kritik kararlar deterministik koda bırakılır. Bu bölümün geri kalanı, bu döngünün her adımını ayrıntılı açar.

Model nelerden oluşur

Model = mimari (architecture) + ağırlıklar (weights) + tokenizer + chat şablonu (chat template)

Diskteki bir model, örneğin Ollama'nın indirdiği tek bir GGUF dosyası, bu dört parçayı birlikte taşır. Şekilde parçaların nerede durduğu ve bir istekte hangi sırayla kullanıldığı görülüyor; sağdaki KV cache ve sampling modelin değil, onu çalıştıran engine'in parçasıdır.

Parçaların ayrıntısı:

Transformer ile model aynı şey değildir. Transformer mimaridir; Qwen/Llama gibi bir model ise bu mimari + eğitim sırasında öğrenilmiş weights (ağırlıklar) bütünüdür. Weights milyarlarca sayısal parametredir; "70B" yaklaşık 70 milyar parametreyi ifade eder. Inference sırasında weights değişmez, yalnızca hesaplamada kullanılır.

Parametre nedir, neden model büyüklüğü parametreyle ölçülür? Modelin her layer'ı, girdiyi çarpan ve toplayan büyük sayı tablolarından (matrislerden) oluşur. Bu tablolardaki her bir sayıya parametre denir; "ağırlık" (weight) ile aynı şeydir. Parametre adı matematikten gelir: tıpkı y = a·x + b doğrusundaki a ve b gibi, hesabın sonucunu belirleyen ama girdi olmayan, ayarlanabilir değerlerdir. Eğitim, bu milyarlarca değerin modelin tahminleri doğru çıkacak şekilde azar azar ayarlanmasıdır; eğitim bitince değerler sabitlenir ve modelin bütün "bilgisi" bu sayılarda saklanır.

Bu yüzden model büyüklüğü parametre sayısıyla ifade edilir: "8B" yaklaşık 8 milyar, "26B" yaklaşık 26 milyar, "70B" yaklaşık 70 milyar parametre demektir (B = billion, milyar). Parametre sayısı iki şeyi belirler:

• Kapasite: Daha çok parametre genelde daha çok bilgi ve daha iyi muhakeme demektir; ama aynı boydaki iki modelden daha iyi eğitilmiş olanı öne geçebilir.
• Bellek ve hız: Her parametre bellekte yer kaplar ve her token üretilirken okunur. Gereken bellek ≈ parametre sayısı × parametre başına byte: 16-bit (FP16) her parametre için 2 byte tutar, yani 26B model ≈ 52 GB; 4-bit kuantizasyonda (Q4) parametre başına yaklaşık yarım byte, pratikte Gemma 4 26B için ≈ 17 GB. MoE modellerde toplam ve aktif parametre ayrıdır; aşağıda ve 1.5'te.

Token, tokenizer ve sampling

Token ve bağlam penceresi. Tokenizer metni kelime parçalarına (token) böler; Türkçede bir kelime genelde 2–4 token'dır. Bağlam penceresi (context window) modelin tek seferde görebildiği toplam token sayısıdır: system prompt, konuşma geçmişi, tool tanımları, tool sonuçları ve cevap hepsi aynı pencereyi paylaşır. Modele çok fazla tool tanımı vermek bu yüzden hem pahalıdır hem de doğru tool'un seçilme ihtimalini düşürür.

Örnek: bir cümle token'a nasıl dönüşür? Aşağıdaki bölünmeler GPT-4o'nun tokenizer'ıyla (o200k_base) gerçekten çıkarılmıştır. Her kutu bir token'dır; · kelimenin başındaki boşluğu gösterir, çünkü boşluk da token'ın parçasıdır. Model metni değil, alttaki sayıları (token ID) görür.

Üç şey görülür. (1) Token kelime değildir: sık geçen kelimeler tek token, seyrek olanlar parçalara bölünür. (2) Türkçe eklemeli bir dil olduğu için aynı anlam İngilizceden daha fazla token tutar; tek bir Türkçe kelime 7 token olabilir. Bu da context'in daha çabuk dolması ve API'de daha yüksek maliyet demektir. (3) Bölünme modele özeldir: Gemma, Llama veya Claude aynı cümleyi farklı parçalara ve farklı ID'lere böler, bu yüzden token sayıları modeller arasında birebir karşılaştırılamaz.

Tokenizer ile Transformer aynı şey değildir. Tokenizer metni modelin işleyebileceği token ID'lerine çevirir. Transformer ise bu token'ları işleyen sinir ağı mimarisidir; attention ve diğer katmanları kullanarak bir sonraki token için olasılıklar üretir. Bu olasılıklardan tek bir token seçilmesine sampling denir; temperature tam bu adımda devreye girer.

Sampling. temperature düşükse model daha deterministik, yüksekse daha çeşitli cevap verir. Operasyon agent'larında düşük tutulur ama sıfır bile tam tekrar edilebilirlik garantisi vermez; bu yüzden kritik kararlar deterministik koda bırakılır.

Soru: Temperature 0 yaparsak model hep aynı şeyi yapmaz mı?

Cevap: çoğu zaman evet, ama GPU paralelliği ve batch etkileri nedeniyle garanti değil; güvenlik bu varsayıma dayanmamalı.

Transformer'ın içi: layer, attention, FFN ve MoE

Router benzetmesi. Her token, 30 router'lık bir hattan sırayla geçen bir pakettir. Her router'ın kendi konfigürasyonu vardır; bu, o layer'ın weights'idir. Paket her router'da okunur ve biraz değiştirilir; 30. router'dan çıkan pakete bakılarak bir sonraki token seçilir. (MoE'deki "router" ayrı bir kavramdır: layer içinde hangi expert'lerin çalışacağını seçen küçük ağ.)

Kabaca ilk layer'lar kelime ve dilbilgisi, ortadakiler anlam, sondakiler "sıradaki token ne olmalı" düzeyinde çalışır; bu keskin bir ayrım değil, bir eğilimdir.

Attention: Q, K ve V. Attention mekanizması, mevcut token işlenirken geçmişteki hangi token'ların önemli olduğunu hesaplar. Basit zihinsel model:

• Q (Query): Şu anda ne arıyorum?
• K (Key): Geçmişteki hangi bilgiler bununla ilgili?
• V (Value): İlgili bulduğum yerden hangi bilgiyi almalıyım?

K ve V metin değildir; her Transformer katmanında oluşan sayısal tensor'lardır.

Dense ve MoE (Mixture of Experts). Her layer'ın ikinci yarısı olan FFN, dense modellerde tek bir büyük ağtır ve her token bu ağın tamamından geçer. MoE modellerde FFN çok sayıda küçük "expert"e bölünür; layer içindeki küçük bir yönlendirici (router) her token için bunlardan birkaçını seçer. Gemma 4 26B'de 128 expert'ten 8'i (artı bir ortak expert) çalışır: toplam ~25,8B parametrenin token başına yalnızca ~3,8B'i kullanılır. Sonuç: MoE'de toplam parametre belleği, aktif parametre hızı belirler (bkz. 1.5).

Bölüm boyunca geçen terimler modelin neresinde?

1.2Model nasıl çalışır: inference zinciri, KV cache ve prompt caching

Bu kavramları tek bir zincirde görmek karışıklığı azaltır. Yerel bir NVIDIA GPU örneğinde tipik akış şöyledir:

Inference engine nedir? Modeli gerçekten CPU/GPU üzerinde çalıştıran yazılım katmanıdır. llama.cpp bunun doğrudan örneğidir. Ollama ve LM Studio ise inference motorunu model indirme/yönetme, API sunma ve servis etme özellikleriyle paketleyen daha üst seviye platformlardır. Ollama başlangıçta tamamen llama.cpp'ye dayanıyordu; Mayıs 2025'ten beri yeni model mimarilerini (Gemma 3, Llama 4, Qwen 2.5 VL gibi, özellikle multimodal olanları) kendi GGML tabanlı motoruyla çalıştırıyor. Hangi motorun kullanıldığı model ailesine göre değişir. Sunucu tarafında yüksek eşzamanlılık için vLLM, SGLang veya TensorRT-LLM gibi motorlar tercih edilir.

CUDA nedir? NVIDIA GPU'lara genel amaçlı hesap yaptıran yazılım platformudur. Inference motoru ağır matris hesaplarını CUDA (ve cuBLAS gibi kütüphaneleri) üzerinden GPU'ya verir. CUDA bir depolama alanı değildir; weights ve KV cache'in VRAM'e yerleştirilmesi ve GPU üzerinde hesap yapılması için kullanılan hesaplama/programlama katmanıdır. AMD'de karşılığı ROCm, Apple'da Metal'dir.

Prefill, decode ve KV cache

Prefill ve decode. API isteğindeki system prompt + tool tanımları + geçmiş + güncel mesaj önce tokenize edilir. Bu input token'larının Transformer katmanlarından geçirilmesine prefill denir. İlk çıktı token'ından sonra yeni token'ların sırayla üretilmesi decode aşamasıdır.

Bir istek sırasında olanlar (örnek: "V_NDFC_FABRIC_1 switchlerini listele"):

1. Prefill. Context'teki tüm token'lar (system prompt, tool tanımları, geçmiş, yeni mesaj) birlikte 30 layer'dan geçer. Her layer, her token için kendi K ve V değerini üretir ve KV cache'e yazar: token başına 30 çift. Son layer'ın çıktısından ilk cevap token'ı seçilir (ör. "Fabric"). Buraya kadar geçen süre TTFT'dir.
2. Decode, 1. adım. Yalnızca "Fabric" token'ı 30 layer'dan geçer. Her layer'da prompt'un cache'teki K ve V değerlerine bakar, kendi K ve V'sini cache'e ekler. Sıradaki token seçilir.
3. Decode, sonraki adımlar. Her seferinde yalnızca en son token layer'lardan geçer; cache her adımda bir token büyür. Model tur sonu token'ını üretince üretim durur.

KV cache neden var? Model cevabı token token üretir ve her yeni token, her layer'da önceki bütün token'lara bakmak zorundadır. Cache olmasaydı her yeni token için önceki bütün token'lar 30 layer'dan yeniden geçirilecekti; 500 token'lık bir cevapta prompt 500 kez yeniden hesaplanacaktı. Cache bu tekrarı bir okuma işlemine çevirir: hesaplanan şey saklanır, sonraki adımlarda yalnızca okunur.

Sık yanlış anlama: KV cache "aynı token tekrar gelirse yeniden hesaplanmasın" diye tutulmaz. Metinde "switch" kelimesi ikinci kez geçerse bu yeni bir token'dır; konumu ve çevresi farklı olduğu için K ve V değerleri de farklıdır. Cache'in istekler arasında yeniden kullanılması (prefix caching, aşağıda) yalnızca context'in başından itibaren birebir aynı bir dizi için geçerlidir.

KV cache ne kadar yer kaplar? Kaba formül:

\text{KV bayt} = 2 \times L \times H_{kv} \times d_{head} \times b \times T

Burada 2 = K ve V, L = katman sayısı, H_kv = KV head sayısı, d_head = head boyutu, b = değer başına byte (FP16 için 2), T = token sayısı. Sliding window kullanmayan klasik bir model örneği: 48 katman, 8 KV head, 128 head boyutu, FP16 ile token başına yaklaşık 0,19 MB; 32K token için ~6 GB, 128K token için ~24 GB. "128K context neden bu kadar VRAM yiyor?" sorusunun cevabı budur; Gemma 4'ün bunu nasıl küçülttüğü aşağıda. Azaltan teknikler: GQA (grouped-query attention; birden fazla query head aynı K/V'yi paylaşır, H_kv küçülür), sliding window attention (bazı katmanlar yalnız son N token'a bakar) ve KV cache kuantizasyonu (ör. 8-bit ile yarıya iner).

Gemma 4 26B'de cache'in şekli. 30 layer'ın 25'i yalnızca son 1.024 token'a bakar (sliding window): bu layer'ların cache'i context uzasa da sabit kalır (FP16'da istek başına ~0,2 GB). Kalan 5 layer tüm context'e bakar ve cache'leri context'le birlikte büyür: token başına ~20 KB. Yani 32K token'lık bir istek ~0,2 + 0,66 ≈ ~0,9 GB KV cache tutar. Engine sliding window'u desteklemiyorsa (tüm layer'lar için tam cache tutarsa) aynı istek ~7 GB'a çıkar: aynı model, aynı GPU, engine'e göre 8 kat fark. Q, K ve V'nin anlamı için bkz. 1.1.

İki aşamanın darboğazı farklıdır. Prefill tüm input token'larını paralel işler ve hesaplama gücüyle sınırlıdır (compute-bound). Decode her adımda tek token üretir ama her token için tüm weights'i ve KV cache'i bellekten okur; bellek bant genişliğiyle sınırlıdır (memory-bandwidth-bound). Pratik sonuç: uzun prompt ve çok sayıda tool tanımı TTFT'yi uzatır; kuantizasyon ise okunacak byte'ı azalttığı için en çok tokens/s'yi iyileştirir.

TTFT ile tokens/s farklı metriklerdir. TTFT, API isteğinin gönderilmesinden ilk çıktı token'ının alınmasına kadar geçen toplam süredir; kuyruk/ağ, prefill ve ilk token üretimi buna dahildir. tokens/s ise ilk token sonrasındaki üretim hızıdır. Düşük TTFT'li ama düşük tokens/s'li bir model hemen yazmaya başlayıp ekranda yavaş ilerleyebilir. stream: true ile uygulama token'ları üretildikçe kullanıcıya iletir.

Prompt caching ile KV cache ilişkisi. Her KV cache kullanımı prompt caching değildir. KV cache tek bir generation sırasında decode'u hızlandırmak için zaten kullanılır. Prompt/prefix caching ise bir önceki istekte hesaplanmış uygun bir prefix'in ara durumunun sonraki istekte yeniden kullanılmasıdır.

Serving katmanı aynı prefix için daha önce hesaplanmış durumu yeniden kullanabiliyorsa prefill hesabı azalır. Bu TTFT'yi ve sağlayıcının gerçek GPU maliyetini düşürür; API sağlayıcılarının cached input'u daha ucuz fiyatlamasının nedeni budur.

Prefix caching ve prompt caching: aynı mekanizmanın iki adı. Prefix caching engine tarafındaki terimdir: vLLM'de Automatic Prefix Caching, SGLang'de RadixAttention, Ollama ve llama.cpp'de slot içindeki prefix'in yeniden kullanımı. Prompt caching ise API sağlayıcılarının ürün ve fiyat adıdır: Anthropic'te cache_control ile işaretlenir, OpenAI'da belirli bir uzunluğun üstündeki prompt'larda otomatik çalışır. İkisinde de yapılan iş aynıdır: başı birebir aynı olan token dizisinin KV cache'ini yeniden hesaplamadan kullanmak. Fark yalnızca kimin yönettiğindedir: kendi sunucumuzda bu bir engine ayarıdır, API'de ise faturadaki "cached input tokens" satırıdır.

Yerel GPU'da prefix cache. Ollama da önceki isteğin KV cache'ini, yeni istek aynı prefix'le başlıyorsa örtülü olarak yeniden kullanır. Pratikte üç şartı vardır: (1) model GPU'da yüklü kalmalıdır; varsayılan olarak 5 dakika boşta kalan model bellekten atılır ve cache silinir (keep_alive ile uzatılır); (2) prefix byte byte aynı olmalıdır; system prompt'un başındaki bir zaman damgası tüm cache'i boşa çıkarır; (3) num_ctx istekler arasında değişmemelidir. Paralel isteklerde her slot'un kendi cache'i olduğundan isabet oranı düşebilir. vLLM'de ise cache bir slot'a değil block'lara bağlıdır: aynı prefix'i taşıyan block'lar hash ile bulunur ve farklı istekler, hatta farklı kullanıcılar arasında paylaşılır (Automatic Prefix Caching, varsayılan açık; ayrıntısı 1.5'te).

Önemli ayrım: prompt caching context window'u küçültmez. 9K token cached + 1K token yeni ise modelin mantıksal context'i hâlâ 10K token'dır. İstemci prompt'u yine tamamen gönderir; kazanç sağlayıcı tarafındaki tekrar GPU hesabının azalmasındadır, ağ yükünün kaybolmasında değil.

Tool calling'de neden daha değerlidir? Bir agent aynı tur içinde LLM → tool → LLM → tool → LLM şeklinde birkaç model çağrısı yapar. Her çağrıda system prompt, tool tanımları ve önceki adımlar prefix olarak tekrar eder; prefix caching bu tekrarlanan bölümün prefill maliyetini azaltır.

Soru: KV cache modelin içinde mi?

Cevap: model weights'in parçası değildir. Inference motorunun yönettiği geçici çalışma durumudur; GPU inference'ta çoğunlukla VRAM'de tutulur. Model kapanınca weights dosyada kalır, KV cache silinir.