← Tüm hizmetler

Kendi Altyapınızda LLM Kurulumu

Dil modelleri, şirket kontrolündeki donanımda, özel bulut hesaplarında veya izole ağ ortamlarında devreye alınır ve işletilir.

Bir LLM'yi kendi altyapınızda çalıştırmak, model endpointini ve seçilen uygulama verilerini kurumunuzun kontrol ettiği ortamda tutar. Bu ortam şirket içindeki bir sunucu, özel bulut hesabı, ayrılmış sanal ağ veya bunların birleşimi olabilir.

Çalışma; model seçimini, donanım testlerini, inference (çıkarım) servisini, deployment (modeli devreye alma), uygulama entegrasyonunu, erişim kontrolünü, izlemeyi, güncellemeleri ve işletim dokümantasyonunu kapsar. Özel RAG ve AI agent sistemleri de onaylanan verileri herkese açık bir model API'sine göndermeden aynı deployment'ı kullanabilir.

LLM kurulumunuzu konuşalım

LLM'yi kendi altyapınızda çalıştırmak ne anlama gelir?

Model ağırlıkları ve inference yazılımı kurumunuzun kontrol ettiği ortamda çalışır. Uygulamalar genel bir yapay zeka servisi yerine özel model endpointine istek gönderir. Ağ, kimlik, depolama ve loglama politikaları şirket kontrolünde kalır.

Modelin özel ortamda çalışması, bütün uygulamanın kendiliğinden özel olduğu anlamına gelmez. Promptlar gateway (ağ geçidi), arama sistemi, loglar, analitik araçlar veya dış entegrasyonlardan geçebilir. Deployment sınırı, hassas girdileri veya model çıktılarını alan her bileşeni kapsamalıdır.

Kurulan sistem

  1. 01

    İş uygulaması

    İnsanların ve diğer yazılımların kullandığı chat arayüzü, belge akışı, RAG sistemi, AI agent, API veya arka plan süreci.

  2. 02

    Uygulama servisleri

    Kimlik doğrulama, prompt oluşturma, bilgi getirme, araç çalıştırma, çıktı doğrulama ve iş kuralları.

  3. 03

    Özel model endpointi

    İstekleri alan, kuyrukları yöneten, yanıtları streaming ile ileten ve istek sınırlarını uygulayan kararlı bir API.

  4. 04

    Inference motoru

    Seçilen modeli yükleyip çalıştıran vLLM, SGLang, llama.cpp veya TensorRT-LLM gibi yazılım.

  5. 05

    Modeller ve adaptörler

    Onaylı model ağırlıkları, tokenizer'lar, yapılandırma, isteğe bağlı quantized sürümler ve göreve özel adaptörler.

  6. 06

    Altyapı

    GPU veya CPU işlem kapasitesi, bellek, depolama, container'lar, ağ, secret yönetimi, izleme ve yedekleme yapılandırması.

Sistem nerede çalışabilir?

Doğru konum veri kurallarına, mevcut donanıma, kurum içi işletim kapasitesine ve talebin zaman içindeki değişimine bağlıdır.

Şirket içi

Konum
Şirket veri merkezi, sunucu odası veya iş istasyonu
Genellikle uygun olduğu durum
Sıkı ağ izolasyonu, mevcut GPU kapasitesi, sabit iş yükü veya dış bağlantının sınırlı olduğu tesisler
Dikkate alınması gerekenler
Kapasite planlama, donanım sürekliliği, güç, soğutma ve yenileme kurumun sorumluluğundadır

Özel bulut

Konum
Size ait bulut hesabı, VPC, özel subnet veya kurumunuza ayrılmış tenant
Genellikle uygun olduğu durum
Özel ağ içinde daha hızlı kaynak sağlama, yönetilen depolama, izleme ve ihtiyaca göre ayarlanabilen işlem kapasitesi
Dikkate alınması gerekenler
Bulut altyapısı dış bağımlılık olarak kalır ve boşta duran GPU kaynakları pahalı olabilir

Hibrit

Konum
Hassas bileşenler özel ortamda, onaylı görevler başka bir ortamda çalışır
Genellikle uygun olduğu durum
Farklı veri sınıflarına, model ihtiyaçlarına veya geçici talep artışlarına sahip iş yükleri
Dikkate alınması gerekenler
Yönlendirme kuralları ve veri sınıflandırması açık ve test edilebilir olmalıdır

LLM'yi kendi altyapınızda çalıştırmanız gerekiyor mu?

Özel deployment daha fazla kontrol sağlar, ancak işletim sorumluluğu da getirir. Sağlayıcının veri koşulları ve kontrolleri gereksinimi karşılıyorsa hosted model API'si daha doğru mühendislik seçimi olabilir.

Kendi altyapınızda kurulum şu durumlarda değerlendirilmelidir

  • Promptlar, getirilen belgeler veya çıktılar kontrollü ağın dışına çıkamıyorsa
  • Uygulamanın internet bağlantısı olmadan çalışmaya devam etmesi gerekiyorsa
  • Model sürümleri ve güncellemeler kurum içi onay sürecinden geçecekse
  • Mevcut donanım sabit ve öngörülebilir iş yükünü karşılayabiliyorsa
  • Uygulamanın, onaylı hosted servislerde bulunmayan bir model veya adaptöre ihtiyacı varsa
  • İstek logları, saklama süresi ve silme işlemleri doğrudan işletim kontrolünde kalacaksa

Hosted model API'si şu durumlarda daha basit olabilir

  • Sağlayıcının veri işleme koşulları gereksinimi zaten karşılıyorsa
  • Talep düşük, düzensiz veya keskin biçimde değişiyorsa
  • Görev kabul edilebilir lisansla kurulamayacak bir modele bağlıysa
  • Ekip GPU altyapısı ve model serving yazılımını işletmek istemiyorsa
  • Yeni model özelliklerine hızlı erişim, altyapı kontrolünden daha önemliyse

Model nasıl seçilir?

Mevcut donanıma sığan en büyük model genellikle doğru varsayılan seçenek değildir. Seçim görev örnekleri ve ölçülebilir gereksinimlerle başlar; ardından modeller hedeflenen servis yapılandırmasında karşılaştırılır.

Bir modelin ağırlıklarının açık olması (open-weight), modelin sınırsız kullanılabileceği anlamına gelmez. Lisans, kabul edilebilir kullanım koşulları, yeniden dağıtım kuralları ve türetilmiş modellere ilişkin sınırlar hedeflenen ürüne ve kurumun kullanımına uygun olmalıdır.

Görev kalitesi
Doğruluk, uygulamanın gerçek dilleri, belgeleri, çıktı formatları ve hata vakaları üzerinde ölçülür.
Model davranışı
Talimat izleme, araç kullanımı, yapılandırılmış çıktı, bağlam uzunluğu ve multimodal girdi yalnızca görev gerektiriyorsa değerlendirilir.
Lisans
Ticari kullanım, dağıtım, değişiklik, kullanım sınırlamaları ve zorunlu bildirimler kurulumdan önce incelenir.
Donanım uyumu
Model ağırlıkları, çalışma zamanı ek yükü, KV cache, bağlam uzunluğu, eş zamanlı istekler ve quantization bellek kullanımını etkiler.
İşletim uyumu
Başlangıç süresi, desteklenen inference motorları, güncelleme yolu, izleme ve ekibin modeli sürdürebilmesi seçimin parçasıdır.

Donanım boyutlandırma ve kapasite planlama

Yalnızca parametre sayısı gerekli donanımı belirleyemez. Bellek kullanımı ve yanıt hızı; model formatına, hassasiyete, girdi ve çıktı uzunluğuna, eş zamanlı isteklere, inference motoruna ve GPU mimarisine bağlıdır. Güvenilir yöntem, aday yapılandırmaları temsili iş yüküyle test etmektir.

Bellek

Model ağırlıkları, çalışma alanı ve aktif isteklerin kullandığı KV cache için yeterli kapasite gerekir.

Yanıt süresi

İlk tokena kadar geçen süre ile üretim hızı ayrı ölçülür; kullanıcılar ikisini de hisseder.

İş hacmi

Eş zamanlı kullanıcı sayısı, kuyruktaki istekler, prompt uzunluğu ve üretilen token sayısı sistemin sürekli taşıması gereken yükü belirler.

Kullanılabilirlik

Yedeklilik, bakım aralıkları, yeniden başlatma süresi ve kabul edilebilir kurtarma süresi tek sunucunun yeterli olup olmadığını belirler.

Büyüme

Beklenen kullanıcı sayısı, belge hacmi, AI agent sistemlerinin iş yükü ve yeni uygulamalar ilk sürümün ötesindeki kapasiteyi etkiler.

Boyutlandırma testi şunları raporlamalıdır

  • • Her aday model ve quantization için kalite sonuçları
  • • Boşta ve yük altında GPU ile sistem belleği kullanımı
  • • İlk tokena kadar geçen süre ve saniyede üretilen token sayısı
  • • Beklenen eş zamanlı istek sayısında iş hacmi ve kuyrukta bekleme süresi
  • • Hata oranı, timeout davranışı ve kurtarma süresi
  • • Normal ve yoğun talepte tahmini altyapı maliyeti

Model servisi ve uygulama entegrasyonu

Kullanılabilir bir deployment, modelin çevresinde kararlı bir servise ihtiyaç duyar. Servis katmanı; uygulamaların nasıl bağlanacağını, isteklerin donanımı nasıl paylaşacağını ve model ya da sunuculardan biri hata verdiğinde ne olacağını kontrol eder.

Inference API

Dokümante edilmiş endpoint; streaming, yapılandırılmış çıktı, araç çağrıları, istek sınırları ve uygulamanın ihtiyaç duyduğu yanıt formatını destekler.

Quantization

Daha düşük hassasiyetli ağırlıklar bellek kullanımını azaltabilir; hız, donanım uyumu veya çıktı kalitesini değiştirebilir. Her aday hedef görevde test edilir.

Batching ve cache

Continuous batching, prefix caching ve KV cache ayarları iş hacmini artırabilir; ne kadar katkı sağladıkları isteklerin yapısına ve trafiğe bağlıdır.

Paralel çalışma

Model GPU'lar arasında bölünebilir veya daha fazla isteğe yanıt vermek için çoğaltılabilir. Birden fazla sunucudan oluşan tasarımlar, ağ bant genişliğine ve gecikmesine de bağlıdır.

Yönlendirme

Gateway görevleri farklı yerel modellere gönderebilir, kullanılamayan kopyayı atlayabilir veya onaylı istekleri dış modele yönlendirebilir.

Uygulama bağlantıları

Özel RAG ve AI agent sistemleri, kurum içi API'ler, masaüstü uygulamaları ve mevcut ürünler kimliği doğrulanan arayüzlerle bağlanır.

Güvenlik ve veri yönetimi

Model endpointini özel ortamda tutmak bir dış veri yolunu kaldırır. Uygulama açıklarını, prompt injection riskini, gereğinden fazla yetkiyi, güvensiz çıktı kullanımını veya ele geçirilmiş model ve container bağımlılıklarını ortadan kaldırmaz.

Güvenlik kontrolleri kaynak belgeleri, vektör depolarını, promptları, model çıktılarını, araçları, logları, yedekleri ve yönetim arayüzlerini içeren bütün istek yolunu izlemelidir.

Ağ sınırı
Özel subnet'ler, firewall kuralları, giriş kontrolleri, servisler arası politikalar ve isteğe bağlı çevrimdışı çalışma, endpoint'e hangi sistemlerin erişebileceğini belirler.
Kimlik ve yetki
Kullanıcılar ve servisler inference öncesinde kimlik doğrulamasından geçer. RAG veya AI agent sistemleri veri getirip araç kullandığında uygulama yetkileri geçerli kalır.
Şifreleme ve secret yönetimi
Bağlantılar aktarım sırasında şifrelenir. Token'lar, sertifikalar, registry erişim bilgileri ve depolama anahtarları onaylı secret yönetim sisteminde tutulur.
Loglar ve saklama
Prompt ve çıktı logları veri politikasına göre kapatılır, maskelenir veya saklanır. İşletim metrikleri tam içeriği kopyalamadan toplanabilir.
Model tedarik zinciri
Model dosyaları, container'lar, paketler ve sürümler onaylı kaynaklardan gelir; kullanılan sürümler sabitlenir, taranır ve yayından önce kayda alınır.
Çıktı kontrolleri
Uygulamalar yapılandırılmış çıktıyı doğrular; modelin ürettiği kod, sorgu veya komutları ayrı kontrol ve yetki olmadan çalıştırmaz.

Kurulumdan sonra sistemi kim işletecek?

İşletim modeli üretim öncesinde kararlaştırılır. Sistem kurum içi platform ekibine hazırlanabilir, TensorBundle belirlenmiş bakım kapsamını üstlenebilir veya sorumluluk bileşenlere göre bölünebilir.

Alan İlk deployment Sürekli işletim
Modeller Seçilen sürümün değerlendirilmesi, onaylanması, paketlenmesi ve kaydedilmesi Güncellemelerin incelenmesi, testlerin tekrarlanması, sürüm geçişinin veya geri dönüşün yönetilmesi
Model servisi Inference motorunun, API'nin, sınırların, ölçeklemenin ve sağlık kontrollerinin yapılandırılması Kapasitenin, yanıt süresinin, hataların, kuyrukların ve servis kullanılabilirliğinin izlenmesi
Altyapı İşlem kaynaklarının, depolamanın, container'ların, ağın ve secret yönetiminin hazırlanması Yamaların uygulanması, kapasitenin yönetilmesi, donanımın yenilenmesi ve kurtarma sürecinin test edilmesi
Uygulama Kullanıcıların, RAG ve AI agent sistemlerinin veya ürünlerin özel endpoint'e bağlanması Entegrasyonların, yetkilerin, test vakalarının ve iş kurallarına uygun davranışın sürdürülmesi

Teslimat kapsamında neler bulunur?

Teslimat, kararlaştırılan ortam ve iş yükünde aynı şekilde yeniden kurulabilen bir deployment'tır. Sistemi çalıştırmak, test etmek, güncellemek ve bir arıza sonrasında kurtarmak için gereken bilgileri içerir.

  1. 01 Model karşılaştırması ve donanım benchmark sonuçları
  2. 02 Dokümante edilmiş model ve lisans seçimi
  3. 03 Sürümleri sabitlenmiş container imajları veya yükleme paketleri
  4. 04 Inference endpointi, kimlik doğrulama, istek sınırları ve sağlık kontrolleri
  5. 05 Ağ, depolama, secret ve loglama yapılandırması
  6. 06 Kapsama dahil uygulama, RAG veya AI agent entegrasyonları
  7. 07 Yük testleri, kalite değerlendirmeleri ve kabul sonuçları
  8. 08 İzleme panelleri, alarmlar, yedekleme, geri dönüş ve kurtarma prosedürleri
  9. 09 Sorumlu ekip için kurulum ve işletim dokümantasyonu

LLM kurulumu hakkında sorular

LLM'nin ofisimizdeki sunucularda mı çalışması gerekir?

Hayır. Kendi altyapınız; şirket içi donanım, özel veri merkezi, size ait bulut hesabı veya VPC ya da kurum politikalarınızla yönetilen, size ayrılmış bir ortam anlamına gelebilir. Gerekli sınırı veri ve ağ kuralları belirler.

Sistem internet bağlantısı olmadan çalışabilir mi?

Model dosyaları, container'lar, paketler, kimlik doğrulama bağımlılıkları ve gerekli veri kaynakları ortam içinde bulunuyorsa evet. Güncellemeler için kontrollü bir içe aktarma süreci gerekir. Bağlantı kesikken dış araçlar ve hosted model servisleri kullanılamaz.

Mevcut altyapımızı kullanabilir miyiz?

Çoğu durumda evet. Mevcut sunucular model uyumu, kullanılabilir bellek, depolama, ağ kapasitesi ve güncel iş yükü açısından incelenir. Sonuç, mevcut donanımda hangi model ve yapılandırmaların çalışabileceğini, yükseltme veya farklı bir model gerekip gerekmediğini gösterir.

Özel modelin yeterince iyi olduğunu nasıl anlarız?

Aday modeller hedeflenen uygulamadan alınan örneklerle test edilir. Karşılaştırma yanıt kalitesini, dili, gerekli formatları, hızı ve önemli hata vakalarını kapsar. Genel benchmark sonuçları bu göreve özel testin yerini tutamaz.

Özel LLM kurulumunun maliyeti nedir?

Maliyet mevcut donanıma, seçilen modele, beklenen kullanıma, kullanılabilirlik gereksinimlerine ve sistemi kimin işleteceğine bağlıdır. Tahmin ilk uygulama, altyapı ve sürekli işletim maliyetlerini ayrı göstermelidir.

Kurum içinde yapay zeka veya altyapı ekibi gerekir mi?

Her zaman gerekmez, ancak yayından sonra erişim, operasyonel sorunlar, güncellemeler ve kapasite için bir sorumlu bulunmalıdır. Sorumluluk kurum içi platform ekibinde kalabilir, kararlaştırılan bakım hizmetine dahil edilebilir veya ekipler arasında bölünebilir.

Model daha sonra değiştirilebilir mi?

Evet. Bunun için uygulamanın tek bir modelin ayrıntılarına değil, kararlı bir özel endpointe bağlanması gerekir. Yeni model yine lisans incelemesi, görev değerlendirmesi, performans testi ve kontrollü yayın sürecinden geçer.

Promptlarımız veya belgelerimiz modeli eğitmek için kullanılır mı?

Ayrı bir eğitim veya veri toplama süreci kurulmadıkça, kendi altyapınızda çalışan inference servisi gelen istekleri eğitim için kullanmaz. Loglar, geri bildirim depoları, analitik ve yedekleme sistemleri için yine de açık saklama ve erişim kuralları gerekir.

Birden fazla uygulama aynı kurulumu kullanabilir mi?

Evet. Gateway her uygulamanın kimliğini doğrulayabilir, ayrı sınırlar uygulayabilir, kullanımı kaydedebilir ve istekleri uygun modele yönlendirebilir. Kapasite planı uygulamaların toplam trafiğini ve farklı prompt boyutlarını hesaba katmalıdır.

Küçük bir kurulumla başlayıp daha sonra büyütebilir miyiz?

Evet. Sınırlı ilk sürüm tek model ve tek uygulamaya hizmet verebilir. Gerçek kullanım ve performans görüldükten sonra kullanıcı, uygulama, model kopyası veya donanım eklenebilir.

Kurulum hem özel hem dış modelleri kullanabilir mi?

Evet. Hibrit yönlendirme katmanı hassas görevleri özel modellerde tutabilir ve açıkça onaylanmış istekleri dış servislere gönderebilir. Yönlendirme, hangi bilginin ortamdan çıkabileceğini kullanıcıların hatırlamasına değil, sistemin uyguladığı veri kurallarına dayanmalıdır.

Yayından sonra hangi desteğe ihtiyaç vardır?

Sistem izleme, güvenlik ve bağımlılık güncellemeleri, kapasite kontrolleri, model değerlendirmesi, yedek testleri ve olay yönetimi gerektirir. Sorumluluklar ve bakım kapsamı üretim öncesinde kararlaştırılır.

LLM kurulumu ne kadar sürer?

Hazır donanımda tek model kurulumu; satın alma, özel ağ, yüksek kullanılabilirlik, uygulama entegrasyonu ve güvenlik incelemesi içeren üretim servisinden daha kısa sürer. Yararlı bir tahmin için iş yükü, aday ortam, veri sınırı, kullanılabilirlik hedefi ve kabul testleri gerekir.

Teknik kaynaklar

Bu sayfadaki kurulum bilgileri; model servisi, ölçekleme, quantization, izleme ve LLM uygulama güvenliği hakkındaki güncel birincil dokümantasyona dayanır.