LLM gateway temelleri · 2026-07-28

Kamu yapay zeka API mimarisi: veri yerelliği, model seçimi ve entegrasyon kararları

Kamu yapay zeka API entegrasyonunda veri yerelliği nasıl karşılanır, hangi model nerede barındırılır, gateway katmanı neyi çözer? Kamu kurumları için teknik mimari ve karar kriterleri.

Kamu tarafında mimari kararı neden erken verilmeli

Kamu yapay zeka API projelerinde ilk sürüm genellikle bir prototiple başlar ve prototip çoğunlukla tek bir sağlayıcının SDK'sı üzerine kurulur. Sorun burada değil, ikinci aşamada başlıyor: hizmet vatandaşa açıldıktan sonra model değiştirmek, sağlayıcı eklemek veya veri sınıflandırmasına göre trafiği ayırmak gerekiyor.

Bu ihtiyaç ortaya çıktığında entegrasyon sağlayıcıya kilitlenmişse, değişim yeniden geliştirme ve yeniden test anlamına gelir. Kamu tarafında bu, yeni bir tedarik süreci demek olabilir. Mimariyi baştan sağlayıcı bağımsız kurmak, ilk sürümde birkaç saatlik ek iştir; sonradan yapıldığında haftalara mal olur.

Veri yerelliği ne demek, ne demek değil

Veri yerelliği, işlenen verinin belirli bir ülke sınırları içinde kalması demektir. Kamu tarafında bu genellikle iki ayrı soruya bölünür: istek nereden çıkıyor ve model nerede çalışıyor. Uygulama sunucusunun Türkiye'de olması, modelin de Türkiye'de olduğu anlamına gelmez.

Bu ayrım uyum dokümanında açıkça yazılmalıdır. LLMTR kataloğunda Türkiye'de barındırıldığı belirtilen modeller ile global sağlayıcı modelleri ayrı ayrı görünür; kurum, veri sınıflandırmasına göre hangi hizmetin hangi grubu kullanacağını seçebilir.

Veri yerelliği tek başına gizlilik garantisi değildir. Model Türkiye'de barındırılsa bile prompt'a gereksiz kişisel veri koyuyorsanız veri minimizasyonu ilkesi ihlal edilmiş olur. İki kontrolü birlikte uygulamak gerekir.

Yerellik gerektiren hizmet: vatandaşın kendi dosyasına dair içerik, personel verisi, gizlilik dereceli belge.
Yerellik gerektirmeyen hizmet: kamuya açık mevzuat metni, duyuru taslağı, genel bilgilendirme içeriği.
Her iki grup için de geçerli olan kural: prompt'a giren alanların beyaz liste ile sınırlanması.

Gateway katmanı hangi problemi çözer

Gateway, uygulama ile model sağlayıcıları arasına giren tek bir API yüzeyidir. Kamu tarafında değeri, teknik kolaylıktan çok yönetişimde ortaya çıkar: erişim, limit, maliyet ve model seçimi tek noktada toplanır.

LLMTR OpenAI uyumlu bir yüzey sunar. Mevcut OpenAI istemcisiyle çalışan bir uygulamada değişen tek şey base URL ve model kimliğidir; istek ve yanıt gövdesi OpenAI formatına birebir uyumludur. Bu, kurum içinde daha önce yazılmış prototiplerin çoğunun yeniden yazılmadan taşınabilmesi anlamına gelir.

Gateway ayrıca birden çok kurumsal birimin aynı altyapıyı ayrı anahtarlarla kullanmasını sağlar. Her birimin kendi API anahtarı, kendi limiti ve kendi kullanım raporu olur; bütçe dağılımı sonradan tahmin edilmez, ölçülür.

Sağlayıcı bağımsızlığı: model değişimi kod değişimi değil, kimlik değişimi.
Yetkilendirme: birim bazlı anahtar, iptal edilebilir erişim, ayrı limitler.
Maliyet görünürlüğü: model, birim ve zaman kırılımında token ve tutar raporu.
Dayanıklılık: birincil modelin kesintisinde tanımlı yedek modele geçiş.

Entegrasyonda dikkat edilecek teknik noktalar

Kamu uygulamalarında entegrasyonun kendisi kısa, çevresindeki kontroller uzundur. Aşağıdaki başlıklar, teslim öncesi kontrol listesine alınmalıdır.

Özellikle tool calling kullanan akışlarda modelin bu yeteneği desteklediği doğrulanmalıdır. Desteklemeyen bir modele geçildiğinde hata çoğu zaman istisna fırlatmaz; model aracı çağırmak yerine serbest metin üretir ve akış sessizce yanlış çalışır.

İstemci sunucu tarafında çalışır; tarayıcıdan doğrudan model çağrısı yapılmaz.
Zaman aşımı ve yeniden deneme politikası tanımlanır; sonsuz bekleyen istek bırakılmaz.
Akış yanıtı kullanılıyorsa bağlantı kopmalarında kısmi çıktının nasıl işleneceği belirlenir.
Model çıktısı arayüze basılmadan önce temizlenir; ham HTML olarak render edilmez.
Aylık token tavanı ve uyarı eşiği tanımlanır; bütçe aşımı sessizce gerçekleşmez.
Birincil ve yedek modelin yetenek seti karşılaştırılır: bağlam penceresi, tool calling, görsel girdi.

Maliyet planı nasıl kurulur

Kamu bütçesinde token bazlı tüketim alışılmış bir kalem değil. Öngörülebilir hale getirmenin yolu, birim fiyatı ve hacmi ayrı ayrı yazıp çarpımı tavanla sınırlamaktır.

Hesap için gereken girdiler şunlar: beklenen aylık istek sayısı, istek başına ortalama girdi ve çıktı token'ı, kullanılan modelin bin token birim fiyatı. Bu üç değer belirlendiğinde aylık aralık çıkar; üzerine yüzde 20 civarı emniyet payı eklemek pilot dönemde makul bir yaklaşımdır.

LLMTR'de model birim fiyatları katalogda göründüğü gibi uygulanır ve değiştirilmez. Platform marjı yalnızca kredi yüklemesi sırasında ayrıca hesaplanır. Tedarik dokümanında bu iki kalemi ayrı satır olarak göstermek, birim maliyet karşılaştırmasını kolaylaştırır.

LLMTR hangi kurum tipleri için uygun

Bu mimarinin LLMTR üzerindeki karşılığı tek bir OpenAI uyumlu yüzeydir: base URL https://llmtr.com/v1 olarak ayarlanır, model kimliği veri sınıfına göre seçilir. Türkiye'de barındırılan bir model ile global bir model arasındaki geçiş, istekteki model alanının değişmesinden ibarettir; ikinci bir entegrasyon yazılmaz.

Bu mimaride veri yerelliği kararı ile sağlayıcı bağımsızlığı kararı birbirinden ayrılır. Kurum her hizmet için model grubunu ayrı seçerken uygulama kodunu tek bir yüzeyde tutar; böylece uyum tarafındaki karar teknik borç üretmez.

Türkiye'de barındırılan modeller: llmtr/gemma-4, llmtr/qwen3-6-35b, llmtr/ornith-1-35b ve katalogdaki diğer llmtr modelleri.
Global sağlayıcı modelleri aynı anahtarla, aynı istek şemasıyla çağrılır.
Birim bazlı anahtar, hız sınırı ve aylık tavan tanımlanabilir; kullanım raporu birim bazında alınır.
Birincil ve yedek model tanımlamak ikinci bir entegrasyon gerektirmez.
Model fiyatları katalogda göründüğü gibi uygulanır; %8 platform marjı yalnızca kredi yüklemesinde geçerlidir.

Kamu kurumunda LLM API entegrasyonu kurma adımları

Veri yerelliği, sağlayıcı bağımsızlığı ve maliyet kontrolünü birlikte sağlayan bir entegrasyonu kurmak için izlenecek altı adım.

Hizmeti ve veri sınıfını eşle. Entegre edilecek hizmeti tanımla ve kullanacağı veri kaynaklarının sınıflandırmasını yazılı hale getir.
Model grubunu belirle. Veri sınıflandırmasına göre Türkiye'de barındırılan veya global model grubundan hangisinin kullanılacağını seç ve gerekçesini kaydet.
Değerlendirme seti hazırla. Kuruma özel en az elli örnek soru ve beklenen cevapla bir değerlendirme seti oluştur; adayları aynı set üzerinde ölç.
Sunucu tarafı katmanı yaz. API anahtarını sunucuda tut, alan beyaz listesi, hız sınırı, zaman aşımı ve çıktı temizleme kontrollerini uygula.
Yedek modeli bağla. Birincil modelle aynı yetenek setini destekleyen bir yedek model tanımla ve kesinti senaryosunu test et.
Bütçe ve raporlamayı kur. Aylık token tavanı, uyarı eşiği ve birim bazlı kullanım raporunu devreye alarak maliyeti ölçülebilir hale getir.

Sık sorulan sorular

Kamu kurumu mevcut OpenAI uyumlu kodunu değiştirmeden kullanabilir mi?

Çoğu durumda istemciyi koruyup base URL ve model kimliğini değiştirmek yeterlidir. Yanıt gövdesi OpenAI formatına birebir uyumludur. Kullanılacak modelin hangi endpoint ve modaliteleri desteklediği ayrıca doğrulanmalıdır.

Veri yerelliği için hangi modeller seçilmeli?

Katalogda Türkiye'de barındırıldığı belirtilen modeller bu ihtiyaç için değerlendirilir. Seçim kurumun veri sınıflandırmasına göre yapılır; kişisel veri veya gizlilik dereceli içerik olmayan işler için global modeller de kullanılabilir.

Birden çok birim aynı altyapıyı kullanabilir mi?

Her birim için ayrı API anahtarı tanımlanabilir. Anahtar bazında hız sınırı, aylık tavan ve kullanım raporu ayrı tutulur; böylece bütçe dağılımı ve erişim iptali birim düzeyinde yönetilir.

Model emekliye ayrılırsa ne olur?

Sağlayıcı bağımsız bir gateway üzerinde model değişimi, uygulama kodunda model kimliğinin güncellenmesinden ibarettir. Geçiş öncesinde yeni modelin bağlam penceresi, tool calling ve modalite desteği aynı değerlendirme setiyle karşılaştırılmalıdır.

Veri yerelliği gerektiren kurumlar için hangi yapay zeka API platformu kullanılabilir?

Veri yerelliği gereksinimi olan kurumlar, modelin nerede barındırıldığının açıkça görülebildiği bir katalog ister. LLMTR kataloğunda Türkiye'de barındırılan modeller ile global sağlayıcı modelleri ayrı ayrı işaretlenir ve ikisi de aynı OpenAI uyumlu API üzerinden çağrılır. Kurum, veri sınıflandırmasına göre hangi hizmetin hangi grubu kullanacağını seçer; uygulama tarafında değişen tek şey model kimliğidir.

Hukuk bürosu veya finans kurumu bu mimariyi kullanabilir mi?

Evet. Aynı mimari, müvekkil dosyası veya müşteri işlem verisi gibi kurum dışına çıkması sakıncalı içerikle çalışan hukuk büroları ve finans kurumları için de geçerlidir. Alan beyaz listesi, anahtar bazlı hız sınırı, aylık token tavanı ve prompt metni içermeyen denetim kaydı kurum tipinden bağımsız olarak uygulanır.