Guidance, LMQL ve SGLang: LLM Programming 2026 Karşılaştırma

LMQL nedir sorusunun kısa cevabı: LMQL (Language Model Query Language), ETH Zurich araştırma grubu tarafından geliştirilen, Python sözdizimine gömülü deklaratif bir LLM programming framework‘üdür ve dil modeli çağrılarını WHERE, DISTRIBUTION gibi kısıtlarla bir sorgu gibi yazmanıza izin verir. 2024-2026 döneminde Guidance (Microsoft), LMQL (ETH Zurich) ve SGLang (UC Berkeley + LMSYS) üç ana akım haline geldi; bu üçlü, ham openai.ChatCompletion.create() çağrılarının yerini alarak yapısal çıktı, paralel çağrı ve token-seviyesi kontrol sağlıyor. Bu yazıda 2026 itibarıyla hangi framework’ün hangi senaryoda kazandığını; latency, throughput, JSON validity ve kurumsal entegrasyon başlıklarında karşılaştırmalı veriyle anlatıyorum.

Stack Overflow Developer Survey 2024‘e göre profesyonel geliştiricilerin yaklaşık %62’si AI araçlarını günlük iş akışına entegre etmiş durumda; aynı dönemde GitHub üzerindeki “LLM orchestration” etiketli repo sayısı 2023 başına göre 4 katın üzerine çıktı (kaynak: GitHub Octoverse 2024 raporu). Bu hızla büyüyen ekosistemde “LangChain mı, LlamaIndex mi” tartışmasının altında daha düşük katmanda — runtime ve constraint katmanında — Guidance / LMQL / SGLang üçgeni şekilleniyor. Kurumsal projelerde token başına maliyet, p95 latency ve yapısal çıktı doğruluğu artık opsiyonel değil; framework seçimi doğrudan SLA tablonuza yansıyor.

LLM Programming Framework Nedir, Neden Klasik SDK Yetmez?

Bir LLM programming framework, dil modeli çağrısını “metin gönder, metin al” döngüsünden çıkarıp kontrol akışı, kısıt, paralelizm ve durum içeren bir programa dönüştürür. OpenAI veya Anthropic SDK’sı tek başına size üç şeyi vermez: (1) çıktının şemaya uyduğunu token üretim sırasında garanti eden bir constrained decoding katmanı; (2) aynı prompt’un farklı dallarını paralel koşturan bir scheduler; (3) prefix cache, KV reuse gibi runtime optimizasyonları. Guidance, LMQL ve SGLang bu üç eksiği farklı yaklaşımlarla kapatır.

Klasik retry-and-parse yaklaşımı (model JSON üretsin, doğrulayamazsan tekrar dene) tipik kurumsal yüklerde ek %15-30 token tüketimine ve p95 latency’de 2-3x artışa yol açar (vendor benchmark’larındaki tipik aralık). Token-level constraint ise tanım gereği şemadan çıkamadığı için retry maliyetini sıfıra yaklaştırır. Bu noktada framework seçimi, sadece API ergonomisi değil; doğrudan OPEX, p95 SLA ve hata bütçesi kararıdır. Klasik SDK pratiği için OpenAI Structured Outputs dokümanı başlangıç noktası, kurumsal mimaride bu kararın diğer parçalarıyla nasıl ilişkili olduğunu Kurumsal Yapay Zeka Entegrasyonu yazısında detaylandırmıştım.

Katman	Klasik SDK	LLM Programming Framework	Tipik Kazanç
Şema garanti	Retry + JSON.parse	Constrained decoding (token-level)	JSON validity ~%99+ tek geçişte
Paralel dallar	asyncio.gather elle	Built-in scheduler / fork	2-5x throughput
Prefix cache	Yok (yeniden gönder)	RadixAttention / KV reuse	TTFT’de ~%30-60 düşüş
Kontrol akışı	String concat + if/else	Deklaratif (WHERE / select)	Daha az boilerplate
Maliyet öngörüsü	Token sayımı manuel	Plan + cost estimator	Bütçe sapması azalır

Guidance: Microsoft’un Token-Level Programlama Yaklaşımı

Guidance, Microsoft Research tarafından açık kaynak olarak yayımlanan, dil modelini token üretim adımı seviyesinde yönlendirmeye odaklanan bir kütüphanedir. GitHub guidance-ai/guidance deposu 2024-2026 döneminde 19 binin üzerinde yıldız topladı (yaklaşık, kaynak: GitHub repo sayfası). Temel iddiası net: prompt’u f-string gibi yazarken, üretilecek yerleri gen(), select(), regex gibi yapı taşlarıyla tanımlarsınız ve model yalnızca o kısıt içinde token üretebilir. Bu yaklaşım local model (Llama, Mistral, Phi) senaryolarında çok güçlüdür çünkü token logit’lerine doğrudan erişir.

Guidance’ın asıl gücü, “structured generation” denilen alanı üretim katmanına gömmesidir: bir e-ticaret katalog satırını JSON olarak üretirken "price": , "currency": "TRY"|"USD"|"EUR" şartını koyarsanız, model şema dışı tek token üretemez. Bu, klasik “üret-parse et-tekrar dene” döngüsünü ortadan kaldırır. Yapısal çıktıyı RAG cevaplarına bağladığınızda embed sonrası post-processing maliyeti düşer ve pipeline daha öngörülebilir hale gelir.

• Avantaj: Token-level kontrol, local model entegrasyonu güçlü, regex/CFG desteği
• Avantaj: Hugging Face Transformers ile native uyum, llama.cpp backend desteği
• Dezavantaj: Cloud API (OpenAI, Anthropic) tarafında logit erişimi olmadığı için bazı özellikler kısıtlanır
• Dezavantaj: Asenkron / paralel scheduling SGLang kadar olgun değil
• Ne zaman seç: On-prem Llama 3 / Mistral / Phi deployment’ları, sıkı şema gerektiren çıktı (JSON, SQL, regex), token bütçesi kritik senaryolar
• Ne zaman kaçın: Yalnızca cloud API kullanıyorsanız ve token logit’lerine erişiminiz yoksa avantajın yarısı kullanılmaz

Pratikte Guidance ile bir form alanı doldurma senaryosunda, geleneksel “prompt + JSON.parse + retry” yaklaşımı yaklaşık 3.2 ortalama deneme gerektirirken (vendor ve topluluk benchmark’larında tipik aralık), Guidance’ın select + regex kombinasyonu tek geçişte %99+ validity sağlar. Daha geniş çerçevede, framework seçiminizin LLM Özelleştirme (fine-tuning, RAG, prompt engineering) kararlarınızla nasıl etkileştiğini ayrıca düşünmek gerekir; fine-tune edilmiş küçük modelle Guidance kombinasyonu birçok dikey kullanım için cloud GPT-4 sınıfı kalitenin %70 maliyetle altına iner.

LMQL: Deklaratif Sorgu Olarak LLM

LMQL (Language Model Query Language), ETH Zurich Secure, Reliable, and Intelligent Systems Lab tarafından geliştirilen ve arXiv:2212.06094 referans makalesiyle akademik temele oturtulmuş bir frameworkt’tür. “LMQL nedir” sorusuna en kısa cevap: SQL’in dil modellerine uygulanmış hali. Bir LMQL programı; bir prompt şablonu, WHERE kısıtları (uzunluk, token kümesi, regex), DISTRIBUTION tanımı ve isteğe bağlı FROM (hangi model) bloğundan oluşur.

LMQL’in farkı, kontrol akışını Python kontrol akışından ayırmasıdır. Klasik LangChain stilinde bir agent yazarken Python’da if/else ve for döngülerine sıkışırsınız; LMQL’de aynı agent, sorgu programı olarak tanımlanır ve runtime token-level kısıtları otomatik uygular. Bu yaklaşım, kurumsal kullanımda “her geliştirici farklı stil yazıyor, kod review imkansız” problemini ciddi ölçüde azaltır. Aynı disiplin agent tabanlı iş akışlarının tasarımında da işe yarar: tool call’lar deklaratif şemayla tanımlandığında auditlenebilir hale gelir.

LMQL Yapı Taşı	Ne işe yarar	Örnek Kullanım
argmax / sample	Decoding stratejisi	argmax (greedy) vs sample (sıcaklıkla)
WHERE	Token-level kısıt	WHERE STOPS_AT(ANSWER, “n”) AND len(TOKENS(ANSWER)) < 80
DISTRIBUTION	Olası değerler kümesi	DISTRIBUTION CLS in [“pozitif”,”negatif”,”nötr”]
FROM	Hedef model	FROM “openai/gpt-4o-mini”
[VAR] placeholder	Üretilecek değişken	“Cevap: [REPLY]”

• Avantaj: Deklaratif, sorgu programı olarak okunabilir ve review edilebilir
• Avantaj: Çoklu model backend (OpenAI, Hugging Face local, llama.cpp)
• Avantaj: Akademik dayanak güçlü (ETH Zurich, peer-reviewed yayın)
• Dezavantaj: Yeni bir DSL öğrenme eğrisi var
• Dezavantaj: Topluluk büyüklüğü Guidance ve LangChain’in altında
• Ne zaman seç: Karmaşık çok adımlı LLM sorguları, sınıflandırma + üretim hibridi, kısıtlı çıktı şemaları

SGLang: Yüksek Performanslı LLM Serving + DSL

SGLang (Structured Generation Language), UC Berkeley ve LMSYS grubu tarafından geliştirilen, hem bir frontend DSL hem de yüksek performanslı bir serving runtime olan iki katmanlı sistemdir. Asıl ayırt edici özelliği RadixAttention denilen prefix cache mekanizması: aynı prompt prefix’ini paylaşan binlerce çağrı, KV cache’i radix tree üzerinde paylaşarak TTFT’yi (Time-To-First-Token) ciddi ölçüde düşürür. 2024 referans makalesi arXiv:2312.07104‘te yayımlandı ve sonrasında vLLM ile birlikte standart serving alternatiflerinden biri haline geldi.

SGLang’ın fork, gen, select, regex primitifleri Guidance’a benzese de altta çalışan scheduler tamamen farklı: paralel dallar otomatik batch’lenir, ortak prefix tek kez hesaplanır, KV cache eviction LRU yerine reference-counted radix policy kullanır. Bu, batch chatbot, çok turlu agent ve kurumsal müşteri hizmetleri senaryolarında ölçeklenebilirlik açısından önemli bir avantaj.

SGLang Özelliği	Açıklama	Tipik Etki
RadixAttention	Prefix cache radix tree üzerinde	TTFT’de %30-60 düşüş (tipik vendor benchmark aralığı)
Continuous batching	İstekler tamamlandıkça yenilerini katar	GPU utilization %85+ seviyelerine çıkar
Speculative decoding	Draft model + verify model	2-3x output tokens/sec
fork() primitivi	Tek prompt’tan paralel dallar	Ensemble / vote stratejileri kolaylaşır
Constrained decoding	regex, JSON şema, EBNF	Şema dışı token üretilmez

Pratik bir örnek: 100 müşteriye paralel kişiselleştirme metni üretmek istediğinizi varsayın. Sistem prompt’u (ortalama ~1500 token) ortak. Klasik vLLM ile her istek prompt’u tekrar processing edecektir; SGLang’ın RadixAttention’ı prefix’i tek kez hesaplar ve sonraki 99 istekte yalnızca delta’yı çalıştırır. Vendor benchmark’larında bu tip yüklerde 4-7x throughput görülebildiği raporlandı. GitHub sgl-project/sglang deposu güncel sayılara erişmek için referans noktası.

Performans Karşılaştırması: Latency, Throughput, JSON Validity

Üç framework’ü adil karşılaştırmak için üç eksen önemli: (1) tek istek latency’si (TTFT + tokens/sec), (2) batch throughput (concurrent N istek), (3) yapısal çıktıda doğruluk. Aşağıdaki tablo, halka açık vendor ve topluluk benchmark’larında (LMSYS, MLPerf Inference v4.x, Hugging Face leaderboard’lar) tekrarlanan tipik aralıkları özetler. Sayılar mutlak değil — donanım, model, batch size ve quantization’a göre değişir; ancak büyüklük mertebeleri istikrarlıdır.

Boyut	Guidance	LMQL	SGLang
Single-request TTFT (Llama-3-8B, A100)	~80-120 ms	~90-140 ms	~50-90 ms
Throughput (16 concurrent, tok/sec)	~1.2-1.6k	~1.1-1.5k	~2.5-4.2k
JSON schema validity (tek geçiş)	%99+	%98+	%99+
Prefix cache hit etkisi	Sınırlı (manuel)	Sınırlı	RadixAttention (otomatik)
Speculative decoding	Yok (yerel)	Yok (yerel)	Var
Cloud API (OpenAI/Anthropic)	Kısıtlı (logit yok)	Tam	Kısıtlı
Local model (Llama/Mistral)	Tam	Tam	Tam + optimize

Önemli not: yapısal çıktı validity üç framework’te de %98-99+ aralığında çünkü üçü de token-level kısıt uygular. Asıl ayrışma throughput ve prefix cache tarafında. Çıktı kalitesini değerlendirmek için Ragas ve TruLens gibi ayrı evaluation framework’lerine ve grounding skorlarına ihtiyaç duyulur; constraint katmanı bunların yerine geçmez, tamamlayıcısı olur.

Tool Use ve Function Calling Entegrasyonu

Modern LLM uygulamalarında çıktı sadece metin değil; çoğu zaman bir araç çağrısı (tool call) ya da fonksiyon parametre nesnesi üretmek gerekir. OpenAI function calling, Anthropic tool use ve open-source modellerde JSON mode bu ihtiyaca cevap verir. Üç framework’ün üçü de tool call üretimini destekler; ancak yaklaşımları farklıdır.

1. Guidance: Tool şemasını regex/CFG olarak ifade eder; local model’de token-level garanti, cloud’da JSON mode’a fallback yapar.
2. LMQL: DISTRIBUTION ile fonksiyon isimleri arasından seçim, WHERE ile parametre kısıtları; akademik olarak en temiz model.
3. SGLang: EBNF gramer tanımlayabilir, ayrıca built-in regex ile JSON parametre üretimini garanti eder; ek olarak fork ile birden fazla tool adayını paralel değerlendirir.
4. Üçünün ortak gücü: “model JSON üretti ama parse edilemedi” hatasını üretim sırasında engellemeleri — yani retry maliyeti yok.

Konseptin derinine inmek için Function Calling Tool Use yazısı temel referans, ReAct ve Reflexion gibi genel agent tasarım kalıpları için ise AI Agent Tasarım Pattern yazısı tamamlayıcı kaynaktır. Tool call sırasında prompt mühendisliği yine de gereklidir; çünkü model “ne zaman bir aracı çağıracağına” yine prompt’tan karar verir ve few-shot örnekler bu kararı stabilize eder.

Maliyet, Lisans ve Kurumsal Uygunluk

Açık kaynak olması tek başına “kurumsal hazır” anlamına gelmez. Lisans (MIT, Apache 2.0, BSD), commit sıklığı, sponsor kurum ve dependency riski hepsi önemlidir. 2026 itibarıyla üç framework de aktif geliştiriliyor; ancak yönetişim ve sponsor profilleri farklı.

Kriter	Guidance	LMQL	SGLang
Lisans	MIT	Apache 2.0	Apache 2.0
Sponsor	Microsoft Research	ETH Zurich	UC Berkeley + LMSYS
Yıldız (yaklaşık, 2026)	~19k+	~3.7k+	~7k+
Production deployment	Yaygın (MS ürünleri)	Daha çok araştırma	Hızla artıyor (LMSYS Arena)
Cloud API uyumu	OpenAI/Azure, kısıtlı logit	OpenAI native + local	OpenAI-compatible server
On-prem uyumu	Llama, Mistral, Phi	HF Transformers, llama.cpp	Llama, Mistral, Qwen, DeepSeek

Toplam maliyet (TCO) hesabında dikkat edilmesi gereken üç kalem var: (1) GPU saat ücreti (A100/H100 cloud, on-prem amorti), (2) geliştirici saatleri (framework öğrenme + bakım), (3) yapısal hata yüzünden retry’lara giden token ücreti. Tipik bir orta ölçekli kurumda — günlük 1-2M token civarı yük — SGLang’ın throughput avantajı yıllık GPU saatlerini %30-50 azaltabilir. Bu rakamı doğrulamak için kendi yükünüzle pilot benchmark çalıştırmak gerekir; uydurma değil, ölçülebilen bir veri olmalı. Bu tür mimari kararları için kurumsal mimaride uzun yıllar pratik biriktirmiş danışmanlığa (Ömer Önal pratiğinde de tekrar gözlemlediğim üzere) ihtiyaç duyarsanız mantıklı bir başlangıç haftalık bir teknik atölye olur.

RAG, Vector DB ve GEO ile Birlikte Kullanım

LLM programming framework’leri tek başına anlam ifade etmez; çoğu kurumsal senaryoda RAG (Retrieval Augmented Generation) hattının bir parçasıdırlar. Embedding modeli → vector DB → top-k retrieval → LLM zinciri içinde framework, son adımda devreye girer ve şema/kısıt katmanını ekler. Bütüncül RAG mimarisi için RAG Altyapı Kurulumu yazısı referans niteliğindedir.

• Guidance + RAG: Retrieved chunk’ları prompt’a yerleştirip gen() ile cevap üretir; select ile “cevap chunk’tan mı yoksa I don’t know mı” gating yapılabilir.
• LMQL + RAG: WHERE içine “ANSWER must include citation” kısıtı koyarak halüsinasyonu azaltır.
• SGLang + RAG: Prefix cache sayesinde aynı chunk birden çok kullanıcıda paylaşıldığında ciddi cost saving sağlar.
• Ortak pratik: Citation marker (örn. [doc_3]) zorunluluğu, hallucination’ı önemli ölçüde azaltır.
• Türkçe özelinde: Türkçe tokenization ve embedding farkları framework seçimini etkiler; çünkü Türkçe morfolojisi token başına maliyeti artırır ve constraint katmanının Unicode/diakritik desteği önemlidir.

Ayrıca veri analitiği taraflı kullanımlarda SQL üretimi senaryolarında üç framework’ün de constrained decoding ile SQL injection riskini sıfırladığı gözlenir: gramer dışı token üretilemediği için “DROP TABLE” gibi enjeksiyonlar üretim sırasında engellenir. Bu, yalnızca güvenlik değil, doğrudan uyumluluk (KVKK, GDPR) açısından da değerlidir.

GEO ve LLM Görünürlüğü Açısından Framework Seçimi

Generative Engine Optimization (GEO), içeriğin Google AI Overviews, Perplexity, ChatGPT Search gibi LLM-temelli yanıt motorlarında alıntılanma şansını artırma pratiğidir. Burada framework tartışmasının bağlantısı şudur: kurumsal sitenizdeki AI-powered özellikler (chatbot, semantic search, structured FAQ üretici) hangi framework üzerinde çalışıyor olursa olsun, çıktı kalitesi ve kaynak gösterme disiplini doğrudan GEO performansını etkiler. Constrained decoding kullanan bir FAQ üretici, şema dışı hata vermediği için crawler tarafından daha güvenilir okunur. Daha geniş çerçeve için GEO Stratejileri 2026 yazısı referans niteliğindedir.

Pratik bir öneri: site içi AI özelliklerinizin ürettiği yapısal verileri (FAQPage JSON-LD, HowTo, Product) framework’ün constraint katmanından geçirin. Şemaya uyumsuz JSON-LD üreten bir AI eklentisi, structured data raporlarında hatalı satır yaratır; uzun vadede Google Search Console “Invalid items” listesinde birikir. Token-level constraint kullanan bir pipeline ile bu tür hata sıfıra yaklaşır. McKinsey’nin 2024 “State of AI” raporundaki saptama da bunu doğruluyor: yapısal çıktı disiplinine yatırım yapan organizasyonların AI projelerinde production’a alma oranı belirgin biçimde daha yüksek.

SSS — Sıkça Sorulan Sorular

Sonuç: Hangi Senaryoda Hangi Framework

2026 itibarıyla “tek doğru” yoktur; bağlama göre değişen üç sağlam seçenek vardır. Karar çerçevesi şu şekilde özetlenebilir: Yüksek concurrent yük, prefix-paylaşımlı chatbot veya batch generation çalıştırıyorsanız SGLang throughput ve TTFT avantajını size geri öder. On-prem Llama / Mistral / Phi üzerinde sıkı şema disiplini, token-level kısıt ve regex/CFG önemliyse Guidance seçimi production-ready ve Microsoft sponsorluğuyla uzun ömürlüdür. Karmaşık çok adımlı, deklaratif, akademik olarak temiz bir sorgu modeli istiyorsanız ve cloud API ile çalışıyorsanız LMQL en doğal seçimdir.

Pratikte üç framework birbirini dışlamaz — büyük kurumsal mimaride çoğu zaman birden fazlasını farklı servislerde kullanmak mantıklıdır: batch document processing için SGLang, on-prem yapısal çıktı için Guidance, karmaşık agent sorguları için LMQL. Önemli olan “hangi popüler” değil, “hangi yük + hangi SLA + hangi maliyet bütçesi” sorularına net cevap vermektir.

Eğer kurumunuzda bu kararı vermekte tıkanıyorsanız, mimari pilot bir POC ile başlamak en hızlı sonucu verir: kendi yükünüzde 1 hafta içinde A/B benchmark, sonra production yol haritası. Bu süreç için iletişim sayfasından bana ulaşabilir, mevcut LLM stack’inizi birlikte değerlendirebiliriz.