Yerli LLM yeterli mi? BİLGE, KUMRU ve MAIN ile çoklu model stratejisi

"Yerli LLM yeterli mi?" sorusu nasıl kurulmalı

Yerli büyük dil modeli araştıran kamu kurumları genellikle tek bir soru sorar: Türkiye'de geliştirilen bir model kurumun işini görür mü? Bu sorunun tek kelimelik bir cevabı yoktur, çünkü kurumun "işi" tek bir görev değildir.

Bir kurumun gün içinde ürettiği yükün büyük bölümü kısa ve tekrar eden görevlerden oluşur: gelen dilekçenin konusuna göre etiketlenmesi, bir yazının özetlenmesi, formdan alan çıkarılması, arşiv içinde arama yapılması. Aynı kurumda, yüzlerce sayfalık bir mevzuat setini karşılaştırıp çok adımlı sonuç çıkarması istenen görevler de bulunur. Bu iki grup görev farklı model ölçekleri gerektirir.

Bu nedenle sorulacak soru "hangi model en iyi" değil, "hangi görev hangi modele düşer" sorusudur. Bu yazı Türkiye'de geliştirilen üç dil modeli girişimini yalnızca kamuya açık ve tarihli verilerle karşılaştırır, ardından kurumun çoğu zaman tek bir modele değil bir model portföyüne ihtiyaç duyduğunu gösterir.

• Kısa ve yüksek hacimli görevlerde belirleyici olan gecikme ve birim maliyettir.
• Uzun bağlam gerektiren görevlerde belirleyici olan bağlam penceresi ve akıl yürütme kapasitesidir.
• En yüksek gizlilik derecesindeki veride belirleyici olan ağ topolojisidir, model ölçeği değildir.
• Kurumlar bu üç ihtiyaca aynı anda sahip olduğu için tek modelli kurulum çoğu zaman bir tarafı karşılıksız bırakır.

Türkiye'de geliştirilen büyük dil modelleri: kamuya açık veriler

Türkiye'de geliştirilen büyük dil modelleri arasında kamuya açık teknik bilgisi bulunan üç girişim öne çıkıyor: TÜBİTAK BİLGEM tarafından geliştirilen BİLGE, VNGRS tarafından geliştirilen Kumru ve HAVELSAN tarafından geliştirilen MAIN platformu. Üçü birbirinden farklı erişim modelleriyle sunuluyor ve bu fark, bir kamu kurumunun bugün hangisini kullanabileceğini doğrudan belirliyor.

TÜBİTAK BİLGEM, 14 Haziran 2026 tarihli açıklamasında BİLGE'nin erişim durumunu şu cümleyle bildirdi: "Bilge henüz genel kullanıma açılmış bir hizmet değildir." Aynı açıklamada kurum, internet ortamında veya çeşitli platformlarda BİLGE adıyla sunulan ya da BİLGE ile ilişkilendirilen uygulamaların TÜBİTAK BİLGEM tarafından sağlanan resmî hizmetler olarak değerlendirilmemesi gerektiğini belirtti; erişim usullerine ilişkin bilgilerin yalnızca TÜBİTAK ve Sanayi ve Teknoloji Bakanlığı'nın resmî kanallarından paylaşılacağını ekledi. 30 Temmuz 2026'da BİLGE'nin geliştiricilerin kullanımına açılacağı duyuruldu, ancak bu duyuruda bir tarih verilmedi.

BİLGE'nin parametre ölçeği konusunda kamuya açık kaynaklar birbirinden farklı bilgiler içeriyor. 29 Haziran 2026 tarihli haberlerde BİLGE ailesinin 1 milyardan 122 milyara uzanan bir parametre skalası sunduğu, 1,9 ve 27 milyar parametreli modellerin bulunduğu, 122 milyar parametreli modelin ise geliştirilmekte olduğu aktarıldı. 30 Temmuz 2026 tarihli bir başka haberde ise 37 milyar parametre rakamı yer aldı. Bu yazı bu rakamlardan birini doğru kabul etmez; her ikisini de tarihiyle birlikte aktarır. BİLGE için doğrulanabilen performans verisi kültürel çeviri değerlendirmesindeki 50 üzerinden 44,44 puandır; aynı değerlendirmede kültürel çeviri kategorisinde yüzde 41'e kadar daha yüksek performans bildirildi (29 Haziran 2026). Model 1 trilyon kelimelik ham veriyle eğitildi.

VNGRS tarafından geliştirilen Kumru, 10 Ekim 2025'te duyuruldu. Kumru-7B, 7,4 milyar parametreli ve tamamen Türkçe için sıfırdan ön eğitimden geçirilmiş bir model olarak tanımlanıyor; ön eğitimde 500 GB temizlenmiş ve yinelenmesi kaldırılmış Türkçe metin ve 300 milyar token kullanıldı. Modelin bağlam penceresi 8.192 token ve 16 GB VRAM'e sahip GPU'larda çalışabildiği bildiriliyor. Kumru'nun Türkçeye özel tokenizer'ı için Kumru-2B model kartında şu ölçüm yer alıyor: diğer açık kaynaklı modeller, daha büyük sözlük boyutlarına rağmen Kumru'ya kıyasla yüzde 38 ile yüzde 98 arasında daha fazla token harcıyor. Erişim açısından iki model ayrışıyor: Kumru-2B Hugging Face üzerinde Apache 2.0 lisansıyla yayımlanmış durumda, Kumru-7B ise kurum içi dağıtım için sunuluyor ve Hugging Face deposu 13 Ağustos 2026 tarihli kontrolde kimlik doğrulama istedi.

HAVELSAN tarafından geliştirilen MAIN, bir dil modeli değil kurumsal yapay zekâ platformu olarak konumlanıyor. Platformun adı "Multifunctional Artificial Intelligence Network" ifadesinin baş harflerinden geliyor. HAVELSAN mühendislerinin bir yıllık araştırma geliştirme çalışması sonucunda açık kaynaktan oluşturulan 9 milyar parametreli bir modeli bulunuyor; platform bu modelin yanı sıra farklı ölçeklerdeki modelleri bir arada orkestre ederek görevin gerektirdiği kapasiteyi devreye alan bir mimariyle çalışıyor. 4 Aralık 2025 tarihli MAIN V2.0 duyurusunda mimari "güvenli, modüler ve kapalı ağlarda çalışabilen mimarisiyle" ifadesiyle tanımlandı; çekirdek modülün özellikleri arasında rol bazlı erişim, tamamen kapalı ağda çalışma ve güvenlik önlemleri sayıldı. MAIN V2.0 modülleri arasında dil, konuşma, analitik, ajan, insan kaynakları, kod asistanı ve taktik modülleri yer alıyor; dil modülü 200'ü aşkın dilde metin anlama, çeviri ve özetleme yeteneği bildiriyor. MAIN, IDC Future Enterprise Awards 2025 kapsamında "Best in AI-Ready Platform" kategorisinde birincilik aldı.

Bu üç girişimin yanında TÜBİTAK'ın yapay zekâ modellerinin geliştirilmesi ve ölçeklendirilmesi için hizmete aldığı ARF yüksek başarımlı hesaplama kümesi bulunuyor. ARF-ACC sistemi 18 Kasım 2025'te açıklanan TOP500 listesinde 145. sıraya yerleşti; aynı sistem Haziran 2025 listesinde 266. sıradaydı. Sisteme 2025 yılında 192 adet NVIDIA H200 GPU eklendi. Bu yazı hangi modelin hangi altyapıda eğitildiğine dair bir iddia içermez; ARF verisi yalnızca ülkedeki eğitim kapasitesinin ölçeğini göstermek için aktarılmıştır.

Görev tipine göre model ölçeği ve Türkçeye özel modelin katkısı

Kamu kurumlarının yapay zekâ yükü tek tip değildir ve model seçimi görev sınıfı bazında yapıldığında hem sonuç hem maliyet öngörülebilir hale gelir. Aşağıdaki tablo, görev tipini model ölçeğiyle eşleştirir ve Türkçeye özel eğitilmiş bir modelin o görevde ölçülebilir bir katkısı olup olmadığını gösterir.

Türkçeye özel eğitimin en somut katkısı tokenizasyon verimliliğinde ortaya çıkar. Türkçe sondan eklemeli bir dil olduğu için genel amaçlı tokenizer'lar aynı metni daha fazla parçaya böler; bu da aynı belgenin daha fazla token tüketmesi anlamına gelir. Token sayısı hem maliyeti hem bağlam penceresine sığan metin miktarını doğrudan etkiler. Buna karşılık uzun bağlam, çok adımlı akıl yürütme, kod üretimi ve çok dilli görevlerde belirleyici olan etken dil uyarlaması değil model ölçeği ve eğitim verisinin kapsamıdır.

Kurumun elindeki görev listesi bu iki grup arasında dağıldığı için tek bir modelle kurulan mimari, ya yüksek hacimli basit görevlerde gereğinden fazla kaynak harcar ya da ağır görevlerde bağlam penceresine takılır.

Kapalı devre kurulumun sağladığı, gateway'in sağlayamayacağı avantaj

Kapalı devre kendi altyapısını kuran bir kamu kurumu, LLMTR'nin sunamayacağı bir avantaja sahip olur: internetten tamamen kopuk çalışabilme. Bu, LLMTR'nin bir eksiği değil, mimari bir gerçektir. LLMTR bir API gateway'dir ve gateway'e erişim ağ bağlantısı gerektirir. En yüksek gizlilik derecesindeki veri sınıfları için doğru cevap, kurumun kendi donanımında çalışan ve dış ağa hiç çıkmayan bir kurulumdur.

Bu ihtiyaca cevap veren seçenekler kamuya açık verilerle bellidir. HAVELSAN MAIN'in 4 Aralık 2025 tarihli duyurusunda çekirdek modül özellikleri arasında "tamamen kapalı ağda çalışma" sayılıyor ve platform mimarisi "güvenli, modüler ve kapalı ağlarda çalışabilen mimarisiyle" ifadesiyle tanımlanıyor. Kumru-2B, Apache 2.0 lisansıyla Hugging Face üzerinde yayımlandığı için kurum kendi sunucusuna indirip dış bağlantı olmadan çalıştırabilir; Kumru-7B'nin 16 GB VRAM'li GPU'larda çalışabildiği bildiriliyor ve bu, kapalı devre kurulum için donanım eşiğini düşüren bir veridir.

Kapalı devre kurulumun kurumun üstlendiği maliyetleri de bellidir ve satın alma birimi bunları baştan hesaba katmalıdır: GPU donanımının tedariki ve amortismanı, model güncellemelerinin elle taşınması, ölçeklendirme sırasında kapasite planlaması, model çeşitliliğinin kurumun kendi kurduğu modellerle sınırlı kalması. Bu maliyetler kapalı devre kurulumu yanlış yapmaz; yalnızca hangi veri sınıfı için katlanılmaya değer olduğu sorusunu gündeme getirir.

Uygulamada kurumların çoğu tek bir cevaba değil bir veri sınıflandırmasına ihtiyaç duyar: en yüksek gizlilik derecesindeki veri kapalı devrede kalır, kalan görev hacmi ise dış bağlantıya izin verilen bir katmanda işlenir. Bu iki katmanın birlikte yönetilmesi, yazının bundan sonraki bölümünün konusudur.

• Kapalı devre kurulum, dış ağa hiç çıkmaması gereken veri sınıfları için doğru mimaridir ve bunu bir gateway sağlayamaz.
• Kapalı devre kurulumun karşılığında kurum donanım, güncelleme ve kapasite planlaması yükünü üstlenir.
• Kurumun tüm görev hacmi aynı gizlilik derecesinde değildir; sınıflandırma yapılmadan alınan "hepsi kapalı devre" kararı düşük dereceli görevlere de aynı maliyeti yükler.
• İki katmanlı kurulumda belirleyici olan, hangi verinin hangi katmanda işleneceğinin yazılı olarak tanımlanmasıdır.

Çoklu model stratejisinin uygulama katmanı: tek yüzey, görev başına farklı model

Çoklu model stratejisi, bir kurumun farklı görevleri farklı modellere yönlendirmesi ve bunu tek bir entegrasyon yüzeyinden yapmasıdır. Stratejinin uygulama maliyeti, her model için ayrı SDK, ayrı kimlik doğrulama ve ayrı faturalandırma kurulmasından doğar; bu maliyet ortadan kalktığında görev başına model seçimi bir yapılandırma kararına iner.

LLMTR bu noktada OpenAI uyumlu tek bir /v1 yüzeyi sunar. Uygulama kodunda base_url ve API anahtarı bir kez ayarlanır, ardından görev başına yalnızca model kimliği değişir. Türkiye'de barındırılan modeller ile global sağlayıcı modelleri aynı katalogdan aynı şemayla çağrılır, bu nedenle bir görevin hangi modele düştüğü kod değişikliği değil parametre değişikliğidir.

Aşağıdaki örnek, yüksek hacimli ve kısa bir görev ile uzun bağlam gerektiren bir görevin aynı kod üzerinde iki farklı modele yönlendirilmesini gösterir. Her iki çağrı da aynı anahtarla yapılır ve tek bir kullanım raporunda görünür.

• Model kimliği bir yapılandırma değeri olarak tutulduğunda görev-model eşleşmesi kod dağıtımı olmadan değiştirilebilir.
• Aynı test setinin iki model üzerinde çalıştırılması, kurumun kendi verisiyle karşılaştırma yapmasını sağlar.
• Bir görev sınıfı için küçük model yeterli sonuç veriyorsa, o görevi büyük modelde çalıştırmak maliyeti karşılıksız artırır.
• Kurum içi arama ve gömme görevleri ayrı bir model kimliğiyle yürütülür ve ayrı ölçülür.

Aynı kod üzerinde yalnızca model kimliğini değiştirerek Türkiye'de barındırılan model ile global model arasında geçiş (OpenAI Python SDK)

import os
from openai import OpenAI

# Tek istemci, tek yüzey: base_url ve anahtar bir kez ayarlanır.
client = OpenAI(
    api_key=os.environ["LLMTR_API_KEY"],  # yer tutucu: kendi anahtarınızı verin
    base_url="https://llmtr.com/v1",
)

# Görev başına model seçimi: kod aynı kalır, yalnızca model kimliği değişir.
TR_HOSTED = "llmtr/qwen3-5-4b"           # Türkiye'de barındırılan küçük model
GENIS_MODEL = "anthropic/claude-opus-5"  # uzun bağlam ve çok adımlı analiz


def sor(model: str, sistem: str, icerik: str) -> str:
    yanit = client.chat.completions.create(
        model=model,
        messages=[
            {"role": "system", "content": sistem},
            {"role": "user", "content": icerik},
        ],
        max_tokens=1024,
    )
    return yanit.choices[0].message.content


dilekce_metni = open("dilekce.txt", encoding="utf-8").read()
mevzuat_metni = open("mevzuat.txt", encoding="utf-8").read()

# Yüksek hacimli, kısa görev: Türkiye'de barındırılan model
etiket = sor(
    TR_HOSTED,
    "Gelen dilekçenin konusunu tek kelimeyle etiketle.",
    dilekce_metni,
)

# Uzun mevzuat karşılaştırması: geniş bağlamlı model
analiz = sor(
    GENIS_MODEL,
    "İki yönetmelik metnini karşılaştır, farkları madde madde yaz.",
    mevzuat_metni,
)

print(etiket)
print(analiz)

LLMTR bu ihtiyaca nasıl karşılık veriyor

LLMTR, yerli dil modellerinin alternatifi değil, çoklu model stratejisinin uygulama katmanıdır. Kurumun ihtiyacı olan şey çoğu zaman "bir model seçmek" değil, birden fazla modeli aynı anda, aynı kimlik doğrulama ve aynı raporlama düzeni altında kullanabilmektir. LLMTR bu katmanı OpenAI uyumlu tek bir /v1 yüzeyiyle sağlar.

Türkiye'de barındırılan sekiz model katalogda doğrudan çağrılabilir durumdadır: llmtr/gemma-4, llmtr/qwen3-6-35b, llmtr/medgemma-4b, llmtr/trendyol-7b, llmtr/magibu-11b-v8, llmtr/embeddinggemma-300m, llmtr/qwen3-5-4b ve llmtr/ornith-1-35b. Bu modellerin yanında OpenAI, Anthropic, Google, xAI, Qwen ve Mistral gibi global sağlayıcıların modelleri aynı katalogdan ve aynı şemayla çağrılır. Kurum, düşük gizlilik derecesindeki yüksek hacimli görevleri Türkiye'de barındırılan küçük bir modele, uzun bağlam gerektiren görevleri geniş bağlamlı bir modele yönlendirebilir ve ikisini tek kullanım raporunda görebilir.

Kurumsal kullanım açısından üç nokta öne çıkıyor. Birincisi, her birim ayrı API anahtarı alabilir; her anahtarın kendi rate limit'i, kendi tavanı ve kendi kullanım raporu olur, böylece bütçe birim bazında takip edilir. İkincisi, kullanıcı promptları ve model yanıt gövdeleri kullanım ve faturalama veritabanına yazılmaz; müşteri API anahtarları düz metin olarak değil SHA-256 hash olarak saklanır ve sağlayıcı API anahtarları yalnızca environment variable'da tutulur. Üçüncüsü, fiyatlandırma yapısı nettir: kredi yüklemede yüzde 8 platform marjı uygulanır, model fiyatlarına marj eklenmez.

Bu yazının dördüncü bölümünde belirtilen sınır burada da geçerlidir: internetten tamamen kopuk çalışması gereken veri sınıfları için LLMTR doğru katman değildir, o veri kurumun kendi kapalı devre kurulumunda kalmalıdır. LLMTR'nin karşılık verdiği ihtiyaç, kalan görev hacminin tek bir entegrasyonla ve model çeşitliliğinden ödün vermeden yürütülmesidir. BİLGE gibi henüz genel kullanıma açılmamış bir modelin ileride erişime açılması durumunda da kurumun kurduğu görev-model eşleşmesi yapısı korunur; değişen tek şey ilgili görev sınıfına atanan model kimliği olur.

Kurumların satın alma dilinde bu, "yapay zekâ yazılımı kiralama" veya "yapay zekâ hizmet alımı" başlığı altında değerlendirilir; teknik ekibin dilinde ise API tabanlı token kullanımıdır. İki tanım aynı kurulumu anlatır.

Kaynaklar

Bu yazıdaki sayısal veriler, tarihler ve alıntılar aşağıdaki kamuya açık kaynaklardan doğrulanmıştır. Son kontrol: 13 Ağustos 2026. Doğrulanamayan hiçbir parametre, tarih veya performans iddiası yazıya alınmamıştır; kaynakların çeliştiği noktalarda çelişki olduğu gibi aktarılmıştır.

Bu içerik bilgilendirme amaçlıdır, hukuki görüş niteliği taşımaz. Nihai değerlendirme kurumun uyum ve hukuk birimlerinin kararıdır.

• TÜBİTAK'ın BİLGE erişim durumu açıklaması, 14 Haziran 2026 — gazeteoksijen.com
• BİLGE model ailesi, parametre skalası ve kültürel çeviri değerlendirmesi, 29 Haziran 2026 — dunya.com
• BİLGE'nin geliştiricilerin kullanımına açılacağına dair duyuru ve 37 milyar parametre bilgisi, 30 Temmuz 2026 — alomaliye.com
• Kumru duyurusu, parametre sayısı ve eğitim verisi ölçüleri, 10 Ekim 2025 — webrazzi.com
• Kumru-2B model kartı, Apache 2.0 lisansı ve tokenizer verimliliği ölçümü — huggingface.co
• HAVELSAN MAIN V2.0 modül yapısı ve kapalı ağ mimarisi duyurusu, 4 Aralık 2025 — havelsan.com
• MAIN V2.0 tanıtımı ve IDC Future Enterprise Awards 2025 sonucu, 23 Kasım 2025 — aa.com.tr
• ARF-ACC sisteminin 18 Kasım 2025 tarihli TOP500 listesindeki sıralaması — tubitak.gov.tr
• LLMTR model kataloğu ve Türkiye'de barındırılan modeller — llmtr.com

Kamu kurumunda görev-model eşleşmesi çıkarma

Bir kamu kurumunun kendi görev envanterini gizlilik derecesi ve model ölçeğiyle eşleştirerek çoklu model kurulumuna geçmesi için izlenecek adımlar.

1. Görev envanteri çıkarın. Kurumun yapay zekâ ile yürütmeyi planladığı görevleri tek tek listeleyin ve her görev için aylık tahmini hacmi, ortalama girdi uzunluğunu ve beklenen yanıt süresini yazın. Bu üç veri olmadan model ölçeği kararı verilemez.
2. Görevleri gizlilik derecesine göre ayırın. Her görevi işlediği verinin gizlilik derecesine göre sınıflandırın ve dış ağa hiç çıkmaması gereken görevleri ayrı bir listeye alın. Bu liste kapalı devre kurulumun kapsamını, kalan liste ise gateway katmanının kapsamını belirler.
3. Her görev sınıfı için aday model belirleyin. Kısa ve yüksek hacimli görevler için 1-8 milyar parametreli Türkçeye özel veya Türkiye'de barındırılan modelleri, uzun bağlam ve çok adımlı analiz gerektiren görevler için geniş bağlam pencereli büyük ölçekli modelleri aday listesine alın. Her aday için erişim biçimini ve lisansını da yazın.
4. Kurumun kendi verisiyle karşılaştırma yapın. Her görev sınıfı için kurumun gerçek belgelerinden oluşan sabit bir test seti hazırlayın ve aday modelleri aynı test setiyle çalıştırın. Yalnızca doğruluk değil, girdi token sayısı, yanıt süresi ve birim maliyet de kaydedilmelidir.
5. Birim bazlı anahtar ve tavan tanımlayın. Gateway katmanında çalışacak görevler için her birime ayrı API anahtarı çıkarın ve her anahtara kendi rate limit'ini ve harcama tavanını tanımlayın. Böylece kullanım raporu birim bazında okunur ve bütçe aşımı tek birimle sınırlı kalır.
6. Eşleşmeyi ölçüp düzenli olarak güncelleyin. Kullanım raporunu görev sınıfı bazında aylık inceleyin ve bir görevin daha küçük bir modelde yeterli sonuç verdiğini gördüğünüzde model kimliğini güncelleyin. Model kimliği yapılandırma değeri olarak tutulduğunda bu değişiklik kod dağıtımı gerektirmez.

Sık sorulan sorular

Yerli büyük dil modelleri kamu kurumunun ihtiyacını karşılar mı?

Cevap görev tipine bağlıdır. Dilekçe sınıflandırma, özetleme ve alan çıkarma gibi kısa ve yüksek hacimli görevlerde 1-8 milyar parametreli Türkçeye özel modeller yeterli sonuç üretir ve daha az işlem gücü tüketir. Yüzlerce sayfalık mevzuat setinde çok adımlı analiz, kod üretimi veya çok dilli içerik gibi görevlerde belirleyici etken bağlam penceresi ve model ölçeğidir. Kurumların çoğu her iki görev grubuna aynı anda sahip olduğu için tek modelli kurulum genellikle bir tarafı karşılıksız bırakır.

BİLGE şu anda kullanıma açık mı?

TÜBİTAK BİLGEM 14 Haziran 2026 tarihli açıklamasında "Bilge henüz genel kullanıma açılmış bir hizmet değildir" ifadesini kullandı ve internette BİLGE adıyla sunulan uygulamaların kurumun resmî hizmetleri sayılmaması gerektiğini belirtti. 30 Temmuz 2026'da modelin geliştiricilerin kullanımına açılacağı duyuruldu, ancak bu duyuruda bir tarih verilmedi. Erişim usullerine ilişkin bilgilerin yalnızca TÜBİTAK ve Sanayi ve Teknoloji Bakanlığı'nın resmî kanallarından paylaşılacağı bildirildi.

BİLGE kaç parametreli?

Kamuya açık kaynaklar bu konuda farklı bilgiler içeriyor. 29 Haziran 2026 tarihli haberlerde BİLGE ailesinin 1 milyardan 122 milyara uzanan bir parametre skalası sunduğu, 1,9 ve 27 milyar parametreli modellerin bulunduğu, 122 milyar parametreli modelin geliştirilmekte olduğu aktarıldı. 30 Temmuz 2026 tarihli bir haberde ise 37 milyar parametre rakamı yer aldı. Bu kaynaklar arasındaki fark kamuya açık bilgiyle giderilemediği için tek bir rakam doğru kabul edilmemelidir.

Kumru'yu kamu kurumu kendi sunucusunda çalıştırabilir mi?

Kumru-2B, Hugging Face üzerinde Apache 2.0 lisansıyla yayımlanmıştır ve kurum kendi sunucusuna indirip çalıştırabilir. Kumru-7B kurum içi dağıtım için sunuluyor ve Hugging Face deposu 13 Ağustos 2026 tarihli kontrolde kimlik doğrulama istedi; bu model için sağlayıcıyla ticari temas gerekiyor. Kumru-7B'nin 16 GB VRAM'e sahip GPU'larda çalışabildiği bildirilmiştir.

Kapalı devre kurulum mu, API gateway mi tercih edilmeli?

Bu iki seçenek birbirinin alternatifi değil, farklı veri sınıflarının cevabıdır. İnternetten tamamen kopuk çalışması gereken en yüksek gizlilik derecesindeki veri için kurumun kendi kapalı devre kurulumu doğru mimaridir ve bunu bir API gateway sağlayamaz. Kurumun kalan görev hacmi için gateway katmanı, donanım tedariki ve model güncelleme yükü olmadan çok sayıda modele erişim sağlar. Kurum önce veri sınıflandırması yapmalı, sonra her sınıf için katman seçmelidir.

Türkçeye özel tokenizer maliyeti gerçekten etkiler mi?

Evet, çünkü faturalandırma token sayısı üzerinden yapılır ve bağlam penceresine sığan metin miktarı da token cinsinden ölçülür. Türkçe sondan eklemeli bir dil olduğu için genel amaçlı tokenizer'lar aynı metni daha fazla parçaya böler. Kumru-2B model kartındaki ölçüme göre diğer açık kaynaklı modeller, daha büyük sözlük boyutlarına rağmen Kumru'ya kıyasla yüzde 38 ile yüzde 98 arasında daha fazla token harcıyor. Bu fark yüksek hacimli Türkçe metin işleyen kurumlarda birim maliyete doğrudan yansır.

İlgili yazılar

• Kurum içi yapay zeka asistanı nasıl kurulur? Kamu kurumları için mimari kararlar
• Kamu kurumu ChatGPT ve OpenAI API kullanabilir mi? KVKK yurt dışı aktarım çerçevesi

• Model kataloğu
• Fiyatlandırma
• Chat Completions dokümantasyonu
• Python SDK