Yerel LLM sunum katmanı: vLLM, SGLang, llama.cpp ve Ollama

Bir kurum çalıştıracağı modeli seçtiğinde elinde bir dosya olur: ağırlıklar, sözlük ve modelin beklediği istem biçimi. O dosyayı bir servise çeviren şey ayrı bir yazılımdır. Gelen istekleri sıraya alan, GPU belleğini paylaştıran, aynı anda kaç kullanıcının konuşabileceğini belirleyen ve dışarıya bir API yüzeyi açan katman budur.

Bu yazı dört adı — vLLM, SGLang, llama.cpp ve Ollama — özellik tablosuyla değil, dört ayrı eksendeki mimari yaklaşımlarıyla ayırır: planlama, bellek, yeniden kullanım ve paketleme. Aralarında bir hız sıralaması verilmez; aşağıdaki sayıların hepsi kendi kaynağının tarihiyle ve karşılaştırma tabanıyla anılır. Model dosyasının kendi tarafındaki hesaplar — niceleme seviyeleri, VRAM aritmetiği ve bağlam penceresi varsayılanları — “Yerel LLM seçerken Türkçe için nelere bakılır” yazısında ele alındı; burada tekrarlanmıyor.

Sunum katmanı ne yapar, model dosyası ne yapar

İki sorumluluk birbirinden ayrılır. Model dosyası ağırlıkları, sözlüğü ve istem biçimini taşır. Sunum katmanı planlamayı, bellek yönetimini, eşzamanlılığı ve API yüzeyini üstlenir. Ayrım kurulumda somut bir karşılık bulur: aynı model dosyası dört katmanın dördünde de çalışabilir, ama aynı donanımda kaç kullanıcıya aynı anda yanıt verileceğini model dosyası değil sunum katmanı belirler.

Ayrımın dışarıdan da böyle görüldüğüne dair bir işaret var. vLLM’in kendi tanıtım listesinde PagedAttention ile bellek yönetimi ayrı bir madde olarak duruyor; sürekli toplu işleme, parçalı ön doldurma ve önek cache ise tek maddede toplanmış.

Katmanın somut hâli çoğu zaman bir HTTP sunucusudur: llama.cpp’nin sunucu belgesi kendi aracını httplib ve nlohmann::json üzerine kurulu saf C/C++ bir HTTP sunucusu olarak tanımlar, sunduğu şey bir REST API kümesi ile bir web arayüzüdür. Tabanlar da kesişir — Ollama 15 Mayıs 2025’te çok kipli modeller için GGML tensor kütüphanesi üzerine kendi motorunu duyurdu ve o tarihe kadar model desteği için llama.cpp projesine dayandığını aynı yazıda belirtti.

Toplu işleme yaklaşımları: statik, dinamik ve sürekli

Sunum katmanının ilk kararı, aynı anda gelen istekleri nasıl grupladığıdır. Üç yaklaşım sırayla kurulabilir.

• Sabit kümeli toplu iş: istekler bir küme hâlinde toplanır, küme bir bütün olarak çalıştırılır ve kümedeki bütün istekler bitene kadar bir sonraki iş başlamaz. Bu adlandırma yalnızca açıklayıcıdır, bir kaynağın terimi değildir.
• Dinamik toplu işleme: toplu iş, sunucu tarafından çalışma anında oluşturulur. İstekler bir süre bekletilir, tercih edilen boyut oluştuğunda ya da bekleme süresi dolduğunda gönderilir.
• Sürekli toplu işleme: toplu işin içeriği her yinelemede yeniden belirlenir. Biten istek toplu işten çıkar, bekleyen istek yürüyen yineleme bittiğinde içeri girer.

Ortadaki yaklaşımın belgelenmiş hâli NVIDIA Triton’da bulunur (bkz. Triton Inference Server — Dynamic Batcher). Dinamik toplu işleme, ayrı istekleri sunucunun kendi karar verdiği anda tek toplu işte birleştirir ve durumsuz modeller için önerilir. Bekleme süresi max_queue_delay_microseconds ile sınırlanır: tercih edilen boyut süre içinde oluşursa toplu iş hemen, süre dolarsa oluşan boyutla gönderilir. Belgedeki örnek yapılandırmada değer 100 mikrosaniyedir.

Üçüncü yaklaşımın birincil kaynağı Orca’dır (USENIX OSDI ’22, s. 521-538). Makale önce tespiti koyar: o güne kadarki sistemler yürütmeyi istek granülerliğinde planlar ve motor, toplu işteki bütün istekler bitene kadar sabit bir istek kümesi tutar. Sonucu iki yönlüdür — erken biten istek istemciye dönemez, sonradan gelen istek sıradaki toplu iş tamamen bitene kadar bekler. Orca’nın çözümü planlamayı yineleme granülerliğine indirmektir: planlayıcı çalıştırılacak istekleri seçer, motoru tek bir yineleme için çağırır, sonuçları alır. Her yinelemede geri dönüş olduğu için biten istek anında döner, yeni istek yürüyen yineleme bittiğinde sıraya girebilir. Bugün sürekli toplu işleme denen yaklaşımın kaynağı budur.

Makale ikinci bir teknik daha tanımlar: seçmeli toplu işleme. İki isteğin bir sonraki yinelemesi her zaman aynı toplu işte birleşemez — ikisi de başlangıç aşamasındayken girdi token sayıları farklıysa, ikisi de artım aşamasındayken farklı indekste token işliyorsa ya da biri başlangıç diğeri artım aşamasındaysa dikkat tensörlerinin şekilleri örtüşmez. Bu yüzden toplu işleme bütün işlemlere değil, seçilenlere uygulanır. Orca aynı yanıt süresi seviyesinde GPT-3 175B üzerinde NVIDIA FasterTransformer’a göre 36,9 kat verim bildirir; 2022 tarihli bir ölçüm ve o günün karşılaştırma tabanıdır.

Terimler her belgede aynı ayrılmıyor. llama.cpp’nin sunucu belgesi --cont-batching bayrağını “continuous batching (a.k.a dynamic batching)” diye tanımlar ve varsayılanı açıktır. Yukarıdaki kavramsal ayrım vLLM ile SGLang terminolojisine aittir; belgeye bakarken bayrağın adı olduğu gibi okunmalıdır.

PagedAttention: KV cache’i sayfalara bölmek

Planlama granülerliği yineleme düzeyine indiğinde belirleyici olan bellek yönetimidir. Sebep KV cache’in davranışıdır: her istek için büyüktür ve üretim ilerledikçe büyüyüp küçülür. PagedAttention makalesi bunu doğrudan söyler — bu davranış toplu iş boyutunu belirler (bkz. Efficient Memory Management for Large Language Model Serving with PagedAttention, arXiv:2309.06180, SOSP ’23).

Makalenin ölçtüğü pay şu: önceden ayrılan sürekli bellek bloğunun yalnızca %20,4 ile %38,2 arasındaki bölümü gerçek token durumlarını tutar; aynı ölçümde vLLM için bu pay %96,3’tür. Kalan alan gelecekteki tokenlar için önceden ayrılmış yuvalara, azami dizi uzunluğuna göre fazladan ayırmadan doğan blok içi alana ve bellek ayırıcısından gelen dağınık alana gider.

Çözüm işletim sistemlerinden geliyor. PagedAttention bir isteğin KV cache’ini, her biri sabit sayıda tokenin anahtar ve değer vektörlerini tutan bloklara böler ve blokların fiziksel bellekte yan yana olmasını gerektirmez. Makalenin analojisi bu bölümün taşıyıcı cümlesidir: "one can think of blocks as pages, tokens as bytes, and requests as processes".

Kayıt yapısı buna göre kurulur. Blok tablosunun her kaydı bir fiziksel blok numarasıyla o blokta dolu olan yuva sayısını tutar; bir isteğin cache’i soldan sağa dolan mantıksal bloklar dizisidir ve yeni fiziksel blok yalnızca öncekilerin tamamı dolduğunda ayrılır. Her fiziksel blok bir referans sayacı taşır ve blok granülerliğinde kopyalama-yazma uygulanır: paralel örneklemede iki çıktı aynı istemi paylaştığında istem durumu tek kopya tutulur, bir yazma geldiğinde yeni blok ayrılıp içerik kopyalanır.

Paylaşımın karşılığı ölçülmüştür: ışın aramada blok paylaşımı %55’e varan bellek tasarrufu sağlar ve paralel örneklemede istem bölümünün toplam KV cache belleğinin %12’sini oluşturduğu bir deney kaydedilmiştir. Makale aynı yanıt süresi seviyesinde FasterTransformer ve Orca’ya kıyasla 2-4 kat verim bildirir — 2023 tarihli, o günün tabanlarına karşı bir ölçüm.

RadixAttention ve önek cache: paylaşılan bağlamı yeniden kullanmak

Üçüncü granülerlik değişimi yeniden kullanım tarafındadır. PagedAttention bir isteğin içindeki paylaşımı ucuzlattı; SGLang istekler arasındaki paylaşımı hedefler (bkz. SGLang: Efficient Execution of Structured Language Model Programs, arXiv:2312.07104). SGLang tek başına bir model çalıştırıcı değil, bir ön yüz dili ile bir çalışma zamanının ortak tasarımıdır.

RadixAttention’ın ayırt edici yanı yalın: üretim bittikten sonra cache’i atmaz, radix ağacında tutar. Radix ağacı önek ağacının alan bakımından verimli bir biçimidir ve kenarları tek eleman yerine değişken uzunlukta eleman dizileriyle etiketlenebilir. Ağaç, token dizileri ile karşılık gelen KV cache tensörleri arasındaki eşlemeyi yönetir; hem istemlerin hem üretimlerin cache’i tutulur.

Bu bir alternatif değil, bir katman. Makale RadixAttention’ın sürekli toplu işleme, sayfalanmış dikkat ve tensör paralelliğiyle uyumlu olduğunu ve her sayfanın boyutunun bir tokene eşit olduğunu açıkça yazar; cache isabeti olmadığında getirdiği bellek ve zaman ek yükü ihmal edilebilir düzeydedir.

Yer açma ilkesi LRU’dur ve yapraktan başlar: en uzun süredir kullanılmayan yaprak önce çıkarılır, ortak atalar kendileri yaprak hâline gelene kadar yeniden kullanılabilir kalır. Çalışan toplu işin kullandığı düğümler, referans sayaçları sıfırlanana kadar yerinde kalır. Sabit boyutlu bir cache havuzu önceden ayrılmaz; cachelenmiş tokenlar ile çalışan istekler aynı bellek havuzunu paylaşır.

Planlama da cache farkındalıdır. İsabet oranı, cachelenmiş istem token sayısının istem token sayısına oranıdır ve istekler eşleşen önek uzunluğuna göre sıralanır. Makalenin Teorem 3.1’i, cache boyutu azami istek uzunluğundan küçük olmadığında en-uzun-ortak-önek-önce sıralamasının radix ağacının derinlik öncelikli dolaşımına denk geldiğini ve optimum isabet oranını verdiğini söyler.

Karşılığını bulduğu yerler somuttur: az örnekli istemler, ortak soru öneki taşıyan kıyaslamalar, ajan şablonu ile önceki çağrılar, çok turlu sohbet geçmişi ve RAG hattındaki ortak bağlam. Bu kıyaslamalarda isabet oranı %50 ile %99 arasında değişir ve cache farkındalı planlama ortalamada optimum isabet oranının %96’sına yaklaşır. Chatbot Arena’da bir ay süren bir dağıtımda LLaVA-Next-34B için %52,4, Vicuna-33B için %74,1 isabet gözlenmiş, Vicuna-33B’de ilk token süresi ortalama 1,7 kat azalmıştır — 2024 tarihli, iş yüküne özgü bir gözlem.

Aynı işlevi bugün vLLM de sunuyor; fark yapıdadır. vLLM’de blok kimliği karma tabanlıdır: blok karması üst bloğun karma değerinden, o bloktaki tokenlardan ve bloğu benzersiz kılan ek değerlerden oluşur, yalnızca tam bloklar cachelenir ve çok kiracılı ortamlarda cacheleri ayırmak için bir cache tuzu da bu karmaya girer. Varsayılan karma algoritması v0.11’den beri sha256’dır ve önek cache varsayılan olarak açıktır. SGLang tarafında aynı işlev radix ağacı ve LRU yaprak çıkarma ile kurulur. İki katmanın mimari yaklaşım farkını en somut gösteren yer burasıdır: işlev aynı, veri yapısı ayrı.

GGUF ve tek ikili dosya: paketleme ve işletme modeli

Dördüncü eksen planlama ve bellekten ayrılır: paketleme. GGUF, GGML ve GGML tabanlı çalıştırıcılarla çıkarım için model saklama biçimidir. Tasarım hedefleri belgede sırayla yazılıdır: tek dosyayla dağıtım — dosyalar kolayca dağıtılıp yüklenebilir ve dış dosya gerektirmez; genişletilebilirlik — yeni özellikler uyumu koruyarak eklenebilir; mmap uyumu; kullanım kolaylığı; ve tam bilgi — modeli yüklemek için gereken her şey dosyanın içindedir.

Son madde soyut değil. Genel meta veri anahtarları general.architecture, general.quantization_version, general.file_type ve general.alignment olarak tanımlıdır. Tokenizer’ın tamamı da dosyadadır: sözlük, birleştirme kuralları, token türleri, özel token kimlikleri ve gerekirse Hugging Face tokenizer.json dosyasının tamamını gömebilen bir alan. En dikkat çekici anahtar tokenizer.chat_template — modelin beklediği girdi biçimini tanımlayan bir Jinja şablonu, ağırlıklarla aynı dosyanın içinde.

Biçim GGML, GGMF ve GGJT’nin ardılıdır. Belgedeki tarihçeye göre öncüllerinin konumsal parametre düzeni yeni hiperparametreleri uyumu koruyarak alamıyordu; anahtar-değer yapısı bunu karşılar.

Kurum içi kurulumda iki ayrı “tek dosya” birbirine karışmamalı. Birincisi modelin tek GGUF dosyasıdır. İkincisi çalıştırıcının kendisidir: llama.cpp’nin ilk özellik maddesi bağımlılıksız saf C/C++ gerçeklemedir ve HTTP sunucusu bile tek başlık dosyası kütüphanelerle kuruludur. Dağıtım birimi bir konteyner yığını değil, indirilebilir bir ikili dosyadır. Paketleme hattının tamamı da aynı ağaçtadır: convert_hf_to_gguf.py, quantize, gguf-split, imatrix ve server.

Ollama’nın paketleme birimi Modelfile’dır ve belgede bir modeli oluşturup paylaşmanın taslağı olarak tanımlanır. Yönergeleri FROM, PARAMETER, TEMPLATE, SYSTEM, ADAPTER, LICENSE ve MESSAGE’dır; FROM üç kaynağı kabul eder — mevcut bir model adı, bir Safetensors dizini ya da bir GGUF dosya yolu. Niceleme oluşturma adımına bağlanır: belgede ollama create --quantize q4_K_M biçimi örneklenir. Dağıtım davranışı tanıdıktır: model kullanıcı adının ad alanına kopyalanır, ollama push ile paylaşılır, karşı taraf ollama run ile çalıştırır. Niceleme seviyesinin kalite ve bellek tarafındaki karşılığı için yayındaki Türkçe model seçimi yazısına bakılabilir; burada konu paketlemenin kendisidir.

Ekosistemin toplandığı yer: TGI deposunun arşive alınması

Bu dört adın neden bir arada anıldığına dair en taze işaret, kapanan bir projeden geliyor. Hugging Face’in Text Generation Inference deposu 21 Mart 2026’da arşive alındı; tarih depo sayfasındaki şeritte yazılı. README bir bakım modu bildirimi taşıyor.

Asıl önemli olan aynı bildirimin ikinci cümlesidir. Metin, optimize çıkarım motorlarının transformers model mimarilerine dayanması yönündeki hareketi TGI’nin başlattığını, bu yaklaşımın alt akıştaki çıkarım motorlarınca benimsendiğini söylüyor ve okuyucuyu doğrudan adlarıyla vLLM, SGLang ile llama.cpp ve MLX gibi karşılıklı uyumlu yerel motorlara yönlendiriyor. Bu yazının dört katmanından üçü, kapanan projenin kendi metninde adlandırılmış oluyor.

Zaman çizgisi kısa: son etiketli sürüm v3.3.7, 19 Aralık 2025; arşivleme yaklaşık üç ay sonra. Deponun özellik listesi de o tarihte neyin standart sayıldığını gösteriyor — çoklu GPU için tensör paralelliği, toplam verim için gelen isteklerin sürekli toplu işlenmesi, OpenAI sohbet tamamlama API’siyle uyumlu Messages API, ve Flash Attention ile Paged Attention kullanan optimize edilmiş çıkarım kodu.

OpenAI uyumlu API yüzeyi ve seçimin taşınabilirliği

Dört katmanın ortak bir yüzeyi var ve bu sonradan eklenmiş bir uyumluluk katmanı değil. PagedAttention makalesinin uygulama bölümü vLLM’i FastAPI ön yüzü ile GPU tabanlı bir çıkarım motorundan oluşan uçtan uca bir sistem olarak tanımlar ve ön yüzün OpenAI API arayüzünü genişleterek örnekleme parametrelerini istek başına özelleştirdiğini yazar.

Bugün dördüne de aynı kapıdan giriliyor. vLLM ile llama.cpp tarafında /v1/completions, /v1/chat/completions, /v1/embeddings ve /v1/responses belgelenmiş durumda; llama.cpp ayrıca Anthropic Messages API uyumlu bir yüzey sunuyor ve tek satırlık başlangıç mümkün — llama serve -hf ile model doğrudan Hugging Face deposundan servis ediliyor. Ollama kapsamı kendi ifadesiyle veriyor: OpenAI API’sinin bir bölümüyle uyumluluk. SGLang tarafında chat/completions ve completions belgelenmiş.

Taşınabilirliğin sınırı da burada görünür: yüzey taşınır, ayar taşınmaz. Yapılandırılmış çıktı bunun en net örneğidir. vLLM beş kısıt türü sunar — seçenek, düzenli ifade, JSON şeması, bağlamdan bağımsız dilbilgisi ve yapısal etiket — ve dört ayrı arka uçla çalışır. SGLang JSON şeması, düzenli ifade ve EBNF kısıtlarını XGrammar varsayılanıyla sunar. llama.cpp tarafında şema kısıtlı JSON yanıt biçimi vardır. Aynı istek gövdesi taşınır, kısıt tanımı ile varsayılan arka uç taşınmaz.

Bu yüzey modele erişimi standartlaştırır; modelin kurumsal sistemlere erişimini standartlaştıran katman ise ayrıdır ve “MCP sunucusu nedir, ne değildir?” yazısında ele alındı.

Kurum içi kurulumda hangi katman hangi senaryoya oturur

Katmanları işletme duruşuyla ayıran en somut çift sayı Ollama’nın belgesinde duruyor. OLLAMA_NUM_PARALLEL model başına eşzamanlı istek sayısıdır ve varsayılanı 1’dir; OLLAMA_MAX_LOADED_MODELS aynı anda yüklenebilecek model sayısıdır ve varsayılanı GPU başına 3’tür. Kuyruk sınırı OLLAMA_MAX_QUEUE ile 512’dir. Bu varsayılanlar bir duruş tarif eder: az eşzamanlılık, çok model.

vLLM ile SGLang’in varsayılanları tersini tarif eder: tek model, yüksek eşzamanlılık. vLLM’in planlama ilkesi ilk gelen ilk çıkar biçimindedir; bir dizinin blokları birlikte erişildiği için yer açma bütünsel uygulanır ve geri getirme CPU belleğine takas ya da yeniden hesaplama ile yapılır. Çoklu GPU tarafında Megatron-LM tarzı tensör paralelliği desteklenir; her model parçası aynı girdi token kümesini işlediği için merkezî planlayıcı içinde tek bir KV cache yöneticisi ve tek bir mantıksal-fiziksel blok eşlemesi tutulur.

SGLang kendi tanımında tek GPU’dan büyük dağıtık kümelere kadar ölçeklenen bir sunum çerçevesidir. Sunucu argümanlarındaki varsayılanlar duruşu doğrular: radix cache açık, yer açma ilkesi lru, sayfa boyutu 1, tensör paralellik boyutu 1.

llama.cpp’nin duruşu en az kurulumdur: BLAS’tan CUDA’ya, Metal’den Vulkan’a uzanan arka uç listesi ve toplam VRAM kapasitesinden büyük modelleri kısmen hızlandıran CPU+GPU melez çalıştırma. Ollama tarafında işletmenin bilmesi gereken bir ayrıntı var: model dizinleri belgelenmiş konumlardadır ve OLLAMA_MODELS ortam değişkeniyle taşınır. Veri yerelliği yazılı bir koşulsa bu yol da kurulum belgesine girer.

Paylaşılan bir kurulumda hangi bağlamın kime açık olduğu sorusunun mimari karşılığı “RAG mimarisinde erişim kontrolü: kim neyi görebilir?” yazısında ayrıntılandırıldı.

Sürüm temposu hızlı. 8 Ağustos 2026 itibarıyla vLLM’in etiketli sürümü v0.26.0 (27 Temmuz 2026), SGLang’inki v0.5.17 (8 Ağustos 2026). Bu yazıdaki bayrak adları ve varsayılanlar aynı tarihe aittir; kurulumdan önce kendi sürümünüzün belgesiyle karşılaştırın.

Kaynaklar

• Orca: A Distributed Serving System for Transformer-Based Generative Models — USENIX OSDI ’22, s. 521-538 (yineleme granülerliğinde planlama, seçmeli toplu işleme, 36,9 kat ölçümü)
• Efficient Memory Management for Large Language Model Serving with PagedAttention — arXiv:2309.06180, SOSP ’23 (blok tablosu, referans sayacı ve kopyalama-yazma, token durumu payı)
• SGLang: Efficient Execution of Structured Language Model Programs — arXiv:2312.07104 (RadixAttention, LRU ile yer açma, cache farkındalı planlama, Teorem 3.1)
• NVIDIA Triton Inference Server Dokümantasyonu — Dynamic Batcher (dinamik toplu işleme, max_queue_delay_microseconds)
• vLLM — GitHub deposu, README.md ve vllm/config/cache.py (özellik listesi, önek cache varsayılanı)
• vLLM Dokümantasyonu — Automatic Prefix Caching, Structured Outputs, OpenAI-Compatible Server, Parallelism and Scaling
• SGLang — GitHub deposu ve Dokümantasyonu, Server Arguments (radix cache varsayılanı, lru, sayfa boyutu 1)
• Text Generation Inference — GitHub deposu (21 Mart 2026’da arşive alındı; son sürüm v3.3.7, 19 Aralık 2025)
• GGUF Specification — ggml-org/ggml, docs/gguf.md (tasarım hedefleri, genel meta veri, tokenizer.chat_template)
• llama.cpp — GitHub deposu ve tools/server/README.md (bağımlılıksız gerçekleme, arka uç listesi, OpenAI uyumlu uçlar)
• Ollama Belgeleri — Modelfile Reference, Import a model, OpenAI compatibility ve FAQ (yönergeler, eşzamanlılık varsayılanları, model dizinleri)
• Ollama’s new engine for multimodal models — Ollama Blog, 15 Mayıs 2025
• GitHub Releases — vllm-project/vllm v0.26.0 ve sgl-project/sglang v0.5.17