AI Inference Nedir? LLM ve GPU Altyapı Rehberi

Kısaca AI Inference Nedir?

AI inference, eğitilmiş bir modelin yeni bir girdiyi işleyerek çıktı üretmesidir. Kullanıcı bir chatbot'a soru sorduğunda, bir banka işlemi fraud modeli tarafından skorlandığında veya bir kamera görüntüsü sınıflandırıldığında inference gerçekleşir.

Inference örnekleri:

• Bir LLM'in kullanıcı sorusuna yanıt üretmesi
• Bir görüntü modelinin nesne tanıması
• Fraud modelinin işlemi riskli veya güvenli olarak sınıflandırması
• Öneri motorunun kullanıcıya ürün önermesi
• Ses modelinin konuşmayı metne dönüştürmesi
• Embedding modelinin dokümanı vektöre dönüştürmesi
• Üretim hattındaki görüntü modelinin kalite problemi tespit etmesi

Modelin ürettiği çıktının türü değişse de altyapı açısından ortak soru aynıdır:

Model, beklenen kullanıcı hacmine hangi gecikme, kapasite ve maliyet seviyesinde hizmet verebilir?

AI Training ve Inference Arasındaki Fark Nedir?

Training modelin parametrelerini öğrenmesini, inference ise eğitilmiş modelin gerçek veriler üzerinde çıktı üretmesini sağlar. İki aşama aynı modeli kullanabilse de altyapı gereksinimleri önemli ölçüde farklılaşabilir.

Training'in yoğunluğu daha yüksek olabilir. Ancak inference sürekli çalıştığı için yüksek hacimli ve uzun ömürlü modellerde kümülatif inference maliyeti zaman içinde training maliyetini aşabilir.

Bu sonuç tüm yapay zeka projeleri için geçerli sabit bir kural değildir. Düşük kullanımlı bir modelde training en büyük maliyet olmaya devam edebilir. Bu nedenle maliyet analizi gerçek trafik ve model kullanım verisine göre yapılmalıdır.

AI Inference Altyapısı Neden Ayrı Planlanmalıdır?

Inference altyapısı kullanıcı trafiğine gerçek zamanlı hizmet verdiği için yalnızca hesaplama gücüne değil, latency, concurrency, availability, autoscaling ve birim maliyet optimizasyonuna göre tasarlanmalıdır.

Training sırasında bir GPU'nun birkaç saniye beklemesi toplam eğitim süresini sınırlı ölçüde etkileyebilir.

Production inference ortamında ise aynı gecikme doğrudan son kullanıcının bekleme süresine dönüşebilir.

Bir inference altyapısının aynı anda şu hedefleri dengelemesi gerekir:

• Düşük latency
• Yüksek throughput
• Yüksek GPU utilization
• Yeterli concurrency
• Yüksek availability
• Elastik ölçekleme
• Kontrollü birim maliyet

Bu hedefler zaman zaman birbiriyle çelişebilir.

Örneğin daha büyük batching throughput'u artırabilirken tek kullanıcı latency'sini yükseltebilir. Daha fazla warm GPU latency'yi azaltırken maliyeti artırabilir.

Inference mühendisliğinin temel problemi bu dengeleri doğru kurmaktır.

LLM Inference Nasıl Çalışır?

Bir LLM inference isteği genel olarak prompt'un token'lara dönüştürülmesi, model tarafından işlenmesi ve yeni token'ların adım adım üretilmesi süreçlerinden oluşur.

LLM serving tarafında iki aşamayı birbirinden ayırmak özellikle önemlidir.

Prefill Aşaması

Prefill sırasında model kullanıcının gönderdiği mevcut prompt ve context'i işler.

Uzun doküman, büyük RAG context'i veya uzun sohbet geçmişi bulunan isteklerde prefill önemli miktarda hesaplama tüketebilir.

Decode Aşaması

Decode sırasında model yanıtı token token üretir.

Her yeni token daha önce hesaplanan attention verilerini kullanır. Bu nedenle decode performansında yalnızca GPU hesaplama kapasitesi değil, GPU belleği ve memory bandwidth de kritik hale gelir.

Prefill ve decode'un farklı performans profilleri nedeniyle modern LLM serving platformlarında iki aşamanın scheduling ve kaynak planlaması ayrı şekilde optimize edilebilir.

LLM Inference'ta Hangi Performans Metrikleri Takip Edilmelidir?

LLM inference performansı yalnızca toplam yanıt süresiyle ölçülmemelidir. TTFT, token üretim hızı, throughput, concurrency ve tail latency birlikte takip edilmelidir.

TTFT - Time to First Token

Kullanıcının isteği göndermesi ile modelin ilk çıktı token'ını üretmesi arasında geçen süredir.

Chatbot ve copilots gibi etkileşimli servislerde kullanıcı algısı açısından kritik metriklerden biridir.

TPOT - Time Per Output Token

İlk token sonrasında her yeni token'ın ortalama üretilme süresini ifade eder.

Bazı platformlarda benzer metrik Inter-Token Latency - ITL olarak takip edilir.

End-to-End Latency

İsteğin sisteme girmesi ile yanıtın tamamen tamamlanması arasındaki toplam süredir.

Throughput

Sistemin belirli sürede işleyebildiği toplam istek veya token miktarıdır.

LLM servislerinde aşağıdaki ölçümler kullanılabilir:

• Request per second
• Input token per second
• Output token per second
• Total token per second

Concurrency

Aynı anda aktif olarak servis verilen inference isteği sayısıdır.

P95 ve P99 Latency

Ortalama latency tek başına yeterli değildir.

P99 latency, isteklerin yüzde 99'unun hangi süre içinde tamamlandığını gösterir ve production ortamındaki yavaş uç senaryoları görünür hale getirir.

KV Cache Nedir ve LLM Inference İçin Neden Önemlidir?

KV cache, transformer tabanlı modellerin önceki token'lar için hesapladığı attention key ve value verilerini bellekte tutarak her yeni token üretiminde aynı hesaplamaların tekrar yapılmasını önleyen bellek yapısıdır.

KV cache LLM inference'ı hızlandırır ancak önemli miktarda GPU belleği tüketebilir.

KV cache ihtiyacı şu faktörlerle büyüyebilir:

• Model büyüklüğü
• Context uzunluğu
• Aynı anda çalışan kullanıcı sayısı
• Üretilen token sayısı
• KV cache precision

Bu nedenle yalnızca model ağırlıklarının GPU belleğine sığıyor olması, production inference kapasitesinin yeterli olduğunu göstermez.

Model ağırlıkları, KV cache ve runtime overhead birlikte değerlendirilmelidir.

PagedAttention Nedir?

PagedAttention, KV cache belleğinin daha esnek bloklar halinde yönetilmesini sağlayarak LLM serving sırasında bellek parçalanmasını ve gereksiz rezervasyonu azaltmayı amaçlayan bir attention bellek yönetimi yaklaşımıdır.

Özellikle farklı context uzunluklarına sahip çok sayıda eş zamanlı istek çalışırken bellek verimliliği kritik hale gelir.

vLLM gibi modern LLM serving sistemleri PagedAttention ve benzeri bellek yönetimi yaklaşımlarını yüksek throughput için kullanır.

Batching Nedir?

Batching, birden fazla inference isteğinin GPU üzerinde birlikte işlenerek donanımın paralel hesaplama kapasitesinden daha verimli yararlanılmasıdır.

Tek bir request GPU'nun bütün hesaplama kapasitesini kullanamayabilir.

Birden fazla isteğin birlikte işlenmesi GPU utilization ve throughput'u artırabilir.

Static Batching

Belirli sayıda istek biriktirildikten sonra aynı batch içinde işlenir.

Yüksek throughput sağlayabilir ancak batch'in dolmasını beklemek latency ekleyebilir.

Dynamic Batching

İstekler kısa zaman pencereleri içinde dinamik olarak gruplanır.

Amaç latency ile GPU verimliliği arasında daha iyi denge kurmaktır.

Continuous Batching

Continuous batching özellikle autoregressive LLM serving için önemlidir.

Bir isteğin bütün yanıtının bitmesini beklemeden yeni isteklerin aktif batch'e dahil edilmesi ve tamamlanan isteklerin çıkarılması mümkün olur.

Bu yaklaşım değişken uzunluktaki LLM yanıtlarında GPU kaynaklarının daha verimli kullanılmasına yardımcı olabilir.

Prefix Caching ve Prompt Caching Nedir?

Prefix caching, birden fazla inference isteğinde tekrar kullanılan ortak prompt veya context bölümlerinin yeniden hesaplanmasını azaltmayı amaçlayan optimizasyon tekniğidir.

Örneğin bir kurumsal chatbot her istekte aynı uzun sistem prompt'unu veya aynı doküman grubunu kullanıyorsa bu ortak bölüm için hesaplanan verilerin yeniden kullanılabilmesi compute ihtiyacını azaltabilir.

Prefix caching özellikle şu senaryolarda değerli olabilir:

• Uzun system prompt kullanan chatbot'lar
• Aynı doküman üzerinde çok sayıda soru
• Ortak instruction kullanan agent sistemleri
• Uzun statik context kullanan uygulamalar

Bu mekanizma doğrudan yanıt cache'lemekten farklıdır.

Yanıt cache'i aynı veya benzer soruya daha önce üretilmiş çıktıyı döndürebilir. Prefix caching ise model hesaplamasının ortak başlangıç kısmını yeniden kullanır.

Speculative Decoding Nedir?

Speculative decoding, daha hızlı veya daha küçük bir modelin birden fazla olası token önermesi ve ana modelin bu token'ları doğrulaması üzerinden token üretimini hızlandırmayı amaçlayan inference optimizasyonudur.

Amaç her token için büyük modelin ayrı ayrı tam hesaplama yapma ihtiyacını azaltmaktır.

Gerçek performans kazanımı:

• Ana modelin boyutuna
• Draft model seçimine
• Prompt tipine
• Acceptance oranına
• Donanım ve serving framework'üne

göre değişebilir.

Bu nedenle speculative decoding teorik olarak hızlı görünse bile gerçek production trafik profiliyle benchmark edilmelidir.

Quantization Nedir?

Quantization, model ağırlıkları ve bazı durumlarda aktivasyon veya KV cache verilerinin daha düşük hassasiyetli sayı formatlarıyla temsil edilerek bellek ve hesaplama ihtiyacının azaltılmasıdır.

Örneğin model:

• FP32
• BF16
• FP16
• FP8
• INT8
• INT4

gibi farklı precision seviyelerinde çalıştırılabilir.

Daha düşük precision:

• Modelin bellek ihtiyacını azaltabilir.
• Daha küçük GPU'larda çalışmayı mümkün hale getirebilir.
• Throughput'u artırabilir.
• Birim inference maliyetini azaltabilir.

Ancak her model ve her quantization yöntemi aynı kalite sonucunu vermez.

Model kalitesi, latency, throughput ve bellek kullanımı production'a geçmeden önce birlikte benchmark edilmelidir.

Distillation Nedir?

Knowledge distillation, büyük bir öğretmen modelin yeteneklerinin daha küçük bir öğrenci modele aktarılması yaklaşımıdır.

Daha küçük model:

• Daha az GPU belleği kullanabilir.
• Daha düşük latency sağlayabilir.
• Daha yüksek concurrency destekleyebilir.
• Daha düşük inference maliyeti oluşturabilir.

Her iş yükünde en büyük modeli kullanmak yerine belirli göreve optimize edilmiş daha küçük bir model kullanmak çoğu zaman daha rasyonel olabilir.

Pruning Nedir?

Pruning, modelde sınırlı katkı sağladığı değerlendirilen ağırlık veya yapıların azaltılmasıyla modelin hesaplama ihtiyacını düşürmeyi amaçlayan optimizasyon yaklaşımıdır.

Pruning'in gerçek faydası kullanılan model mimarisine, sparsity yapısına ve inference donanımının bu sparsity modelini ne kadar iyi desteklediğine bağlıdır.

Doğru Inference GPU'su Nasıl Seçilir?

Inference için en pahalı veya en güçlü GPU otomatik olarak en iyi seçim değildir. Doğru GPU, modelin bellek ihtiyacı, latency hedefi, concurrency, throughput ve birim maliyet beklentisine göre seçilmelidir.

Değerlendirilmesi gereken başlıca kriterler:

• GPU belleği - VRAM
• Memory bandwidth
• Desteklenen precision formatları
• Tensor compute kapasitesi
• GPU başına güç tüketimi
• Sunucu başına GPU sayısı
• GPU'lar arası bağlantı
• Yazılım ve framework desteği
• Birim token veya request maliyeti

NVIDIA L40S gibi GPU'lar çeşitli inference senaryolarında kullanılabilirken H100, H200 veya daha yeni yüksek segment GPU'lar büyük modeller, yüksek concurrency ve yoğun LLM serving için farklı performans profilleri sunabilir.

Bununla birlikte küçük modeller veya daha düşük trafik gereksinimleri GPU gerektirmeyebilir.

CPU, farklı accelerator türleri veya daha küçük GPU'lar bazı inference iş yüklerinde daha ekonomik sonuç verebilir.

Inference İçin GPU Belleği Neden Bu Kadar Önemlidir?

LLM inference kapasitesi yalnızca GPU compute performansına değil, model ağırlıkları ve KV cache için kullanılabilir GPU belleğine de bağlıdır.

GPU belleği yetersiz olduğunda:

• Model tek GPU'ya sığmayabilir.
• Maksimum context uzunluğu sınırlanabilir.
• Concurrency düşebilir.
• Daha fazla GPU kullanılması gerekebilir.
• CPU offload gibi latency artırabilecek yöntemlere ihtiyaç duyulabilir.

Bu nedenle GPU seçiminde yalnızca FLOPS veya benchmark skorlarına bakmak yeterli değildir.

Bir Model Tek GPU'ya Sığmıyorsa Ne Yapılır?

Model tek bir GPU'nun belleğine sığmıyorsa model parallelism kullanılarak model birden fazla GPU veya düğüm üzerinde dağıtılabilir.

Tensor Parallelism

Aynı model katmanındaki hesaplamalar birden fazla GPU arasında bölüştürülür.

Pipeline Parallelism

Model katmanları farklı GPU veya düğümlere dağıtılır.

Expert Parallelism

Mixture-of-Experts - MoE modellerinde farklı expert katmanları farklı GPU'lar üzerinde konumlandırılabilir.

Dağıtık inference modelin çalışmasını mümkün hale getirebilir ancak GPU'lar arası ağ iletişimini daha önemli hale getirir.

Bu noktada yüksek bant genişlikli ve düşük gecikmeli veri merkezi ağı kritik hale gelir.

AI-ready veri merkezlerinde GPU cluster, güç, soğutma ve ağ gereksinimlerinin neden farklılaştığını AI-Ready Veri Merkezi Nedir? rehberimizde ele alıyoruz.

Inference Autoscaling Nasıl Çalışmalıdır?

Inference autoscaling, yalnızca CPU veya GPU kullanım yüzdesine göre değil, queue depth, aktif request sayısı, token hacmi, latency ve GPU memory kapasitesine göre tasarlanmalıdır.

Inference trafiği günün farklı saatlerinde ciddi biçimde değişebilir.

Ancak GPU instance açmak her zaman anlık değildir.

Yeni GPU kapasitesinin devreye alınması sırasında:

• Sunucu veya container başlatılabilir.
• Model ağırlıkları storage'dan yüklenebilir.
• GPU belleği allocate edilebilir.
• Model engine initialize edilebilir.
• Health check tamamlanabilir.

Bu sürece genel olarak cold start problemi denebilir.

Kritik production servislerinde yalnızca demand oluştuğunda yeni GPU açmak yeterli olmayabilir.

Bunun yerine:

• Minimum warm replica tutulabilir.
• Tahmine dayalı autoscaling kullanılabilir.
• Queue length bazlı scale-out tetiklenebilir.
• Latency SLO'larına göre ek kapasite devreye alınabilir.
• Kampanya veya yoğun saatler öncesi kapasite artırılabilir.

GPU Utilization Neden Tek Başına Yeterli Bir Metrik Değildir?

Yüksek GPU utilization her zaman verimli inference anlamına gelmez. Sistem GPU'yu yoğun kullanırken kullanıcı latency hedeflerini kaçırıyor veya gereksiz token üretiyor olabilir.

GPU utilization şu metriklerle birlikte izlenmelidir:

• TTFT
• TPOT veya ITL
• P95 ve P99 latency
• Request throughput
• Token throughput
• Queue depth
• GPU memory utilization
• KV cache utilization
• Error rate
• Cost per request

Inference Maliyeti Nasıl Hesaplanır?

Inference maliyeti yalnızca GPU saat ücretinden oluşmaz. Compute, enerji, depolama, ağ, yazılım, operasyon ve atıl kapasite birlikte değerlendirilmelidir.

Basitleştirilmiş toplam maliyet yaklaşımı:

Toplam inference maliyeti = Compute + enerji + depolama + ağ + lisans + operasyon + kapasite rezervi

Birim maliyet ise kullanım senaryosuna göre aşağıdaki şekilde ölçülebilir:

• İstek başına maliyet
• 1.000 inference başına maliyet
• 1 milyon input token başına maliyet
• 1 milyon output token başına maliyet
• Kullanıcı başına aylık AI maliyeti
• Endpoint başına aylık maliyet
• Model başına aylık maliyet

LLM servislerinde input ve output token profillerinin ayrı ölçülmesi özellikle önemlidir.

Uzun context'li kısa cevap ile kısa prompt'lu uzun cevap aynı altyapı maliyet davranışını göstermez.

Inference Maliyetini Ne Belirler?

Başlıca maliyet sürücüleri:

• Model boyutu
• Precision seviyesi
• Prompt uzunluğu
• Output token uzunluğu
• Context window
• Concurrent kullanıcı sayısı
• Batching verimliliği
• KV cache kapasitesi
• GPU tipi
• GPU sayısı
• GPU utilization
• Autoscaling modeli
• Coğrafi deployment sayısı
• High availability kapasitesi

Inference Maliyetini Nasıl Düşürebilirsiniz?

1. Her İş İçin En Büyük Modeli Kullanmayın

Daha büyük model her zaman daha yüksek iş değeri anlamına gelmez.

Basit sınıflandırma, özetleme veya routing görevleri için küçük modeller yeterli olabilir.

2. Quantization Kullanın

Model kalitesi kabul edilebilir düzeyde korunabiliyorsa düşük precision modeli daha az GPU belleği ve compute ile çalıştırabilir.

3. Continuous Batching Kullanın

Kullanıcı isteklerini daha etkin schedule ederek aynı GPU üzerinde daha fazla eş zamanlı request işlenebilir.

4. Prefix Caching Kullanın

Uzun ve tekrar eden prompt bölümlerinin yeniden hesaplanması azaltılabilir.

5. Gereksiz Context'i Azaltın

RAG sisteminde modele alakalı olmayan çok sayıda doküman göndermek hem kaliteyi hem maliyeti olumsuz etkileyebilir.

Retrieval sonucu yalnızca gerçekten gerekli context'in modele gönderilmesi hedeflenmelidir.

6. Output Token Limitlerini Yönetin

Modelin gereksiz uzun cevaplar üretmesi latency ve compute maliyetini artırabilir.

7. Akıllı Model Routing Kullanın

Basit istekler küçük ve ekonomik modele, daha zor istekler daha güçlü modele yönlendirilebilir.

8. Autoscaling'i Optimize Edin

Sürekli fazla GPU açık tutmak maliyeti artırırken kapasiteyi fazla azaltmak latency ve availability sorununa yol açabilir.

9. Donanım ve Modeli Birlikte Benchmark Edin

GPU seçimi teorik benchmark yerine gerçek prompt ve concurrency dağılımı kullanılarak test edilmelidir.

10. Maliyeti Model ve Endpoint Bazında İzleyin

Toplam GPU faturası tek başına yeterli değildir.

Hangi modelin ve hangi API endpoint'inin ne kadar maliyet oluşturduğu görünür hale getirilmelidir.

Değişken altyapı maliyetlerinin yönetim çerçevesi için Cloud FinOps Nedir? içeriği tamamlayıcıdır.

Model Routing Nedir?

Model routing, her isteği aynı modele göndermek yerine isteğin karmaşıklığına, latency hedeflerine, maliyet limitine veya veri hassasiyetine göre uygun modele yönlendirme yaklaşımıdır.

Örnek:

• Basit FAQ sorusu - küçük model
• Standart özetleme - orta ölçekli model
• Karmaşık reasoning - güçlü model
• Hassas veri - private inference ortamındaki model

Bu yaklaşım bir AI uygulamasının bütün isteklerinde en pahalı modeli çalıştırmasını önleyebilir.

Inference İçin GPU Paylaşımı ve Multi-Tenancy Nasıl Kullanılır?

Düşük trafikli modeller için bir GPU'yu yalnızca tek modele ayırmak önemli miktarda atıl kapasite oluşturabilir. GPU paylaşımı birden fazla workload'un aynı donanımı kontrollü biçimde kullanmasını sağlar.

Kullanılabilecek modeller:

• Aynı serving engine üzerinde birden fazla model
• GPU partitioning
• Container tabanlı kaynak izolasyonu
• Time slicing
• Multi-tenant inference platformu

Ancak multi-tenancy tasarlanırken performans izolasyonu ve güvenlik birlikte değerlendirilmelidir.

Gerçek Zamanlı ve Batch Inference Arasındaki Fark Nedir?

Real-time inference kullanıcı veya sistem isteğine anında yanıt vermeyi, batch inference ise çok sayıda girdinin belirli zaman aralıklarında toplu olarak işlenmesini hedefler.

Gerçek zamanlı gereksinimi olmayan bir workload'u online API olarak çalıştırmak gereksiz altyapı maliyeti yaratabilir.

Merkezi Inference mı, Edge Inference mı?

Inference'ın merkezi veri merkezinde, bulutta veya edge üzerinde çalıştırılması latency, model boyutu, veri hassasiyeti, bağlantı ve operasyon gereksinimlerine göre belirlenmelidir.

Merkezi Inference

Model güçlü bir veri merkezi veya cloud altyapısında çalışır.

Avantajları:

• Yüksek GPU kapasitesi
• Merkezi yönetim
• Daha kolay model güncelleme
• Büyük modelleri çalıştırabilme
• Kaynak paylaşımı

Edge Inference

Model veri kaynağına veya kullanıcıya yakın bir cihaz, sunucu veya edge lokasyonda çalışır.

Avantajları:

• Daha düşük ağ round trip süresi
• Bağlantı kesintisinde yerel çalışma imkanı
• Ham veriyi yerelde tutabilme
• Gerçek zamanlı karar verebilme

Dezavantajı ise edge cihazın compute, bellek, enerji ve operasyon kapasitesinin sınırlı olabilmesidir.

Edge inference özellikle küçük ve optimize edilmiş modellerde güçlü bir seçenek olabilir.

Edge mimarisinin genel çerçevesi için Edge Computing Nedir? içeriğini inceleyebilirsiniz.

Inference Altyapısında Ağ Neden Önemlidir?

Inference yalnızca GPU problemi değildir. Kullanıcı ile model endpoint'i arasındaki ağ latency'si ve dağıtık GPU sistemlerinde düğümler arasındaki iletişim performansı toplam yanıt süresini doğrudan etkileyebilir.

Ağ iki ayrı katmanda değerlendirilmelidir:

Kullanıcı - Inference Endpoint Bağlantısı

Gerçek zamanlı uygulamalarda kullanıcıya olan ağ mesafesi TTFT ve toplam latency'yi etkiler.

GPU - GPU Bağlantısı

Model birden fazla GPU veya node üzerinde çalışıyorsa tensor parallelism ve diğer distributed inference yöntemleri yüksek hızlı GPU iletişimine ihtiyaç duyabilir.

Bu nedenle:

• Yüksek bant genişlikli Ethernet
• InfiniBand
• RoCE
• GPU interconnect teknolojileri
• Carrier-neutral dış bağlantı

workload'a göre değerlendirilebilir.

Inference ve Direct Cloud Access Arasındaki İlişki Nedir?

Hybrid inference mimarisinde model veya veri farklı bulut ve veri merkezi ortamlarına dağıtılıyorsa bağlantı kalitesi toplam latency ve veri transfer performansının parçası haline gelir.

Örneğin:

• Model private cloud'da çalışabilir.
• Vector database public cloud'da bulunabilir.
• Kurumsal veri on-premise olabilir.
• Inference servisi farklı cloud region'larında ölçeklenebilir.

Bu mimaride her inference isteği birden fazla network segmentinden geçebilir.

Kritik cloud bağlantılarında public internet yerine daha kontrollü bağlantı modellerinin kullanımını Direct Cloud Access Nedir? rehberimizde ele alıyoruz.

RAG Sistemlerinde Inference Altyapısı Nasıl Değişir?

RAG - Retrieval-Augmented Generation mimarisinde kullanıcı isteğinin latency'si yalnızca LLM tarafından değil, retrieval, embedding, vector database ve context oluşturma adımları tarafından da belirlenir.

Tipik bir RAG request path:

1. Kullanıcı sorgusu alınır.
2. Gerekirse embedding oluşturulur.
3. Vector database sorgulanır.
4. İlgili dokümanlar seçilir.
5. Prompt ve context oluşturulur.
6. LLM inference gerçekleştirilir.
7. Yanıt kullanıcıya stream edilir.

Bu nedenle yalnızca LLM GPU latency'sini optimize etmek toplam uygulama latency'sini tek başına çözmez.

RAG performansı uçtan uca ölçülmelidir.

Inference Altyapısında High Availability Nasıl Sağlanır?

Production AI servisi kritik iş süreçlerine bağlıysa GPU veya model serving node arızasının kullanıcı hizmetini tamamen durdurmaması gerekir.

High availability tasarımında:

• Birden fazla inference replica
• Health check
• Load balancing
• Automatic failover
• Minimum warm capacity
• Alternatif model fallback
• Multi-zone veya multi-site deployment

değerlendirilebilir.

Ancak yüksek availability ek GPU kapasitesi gerektirdiği için maliyet ve dayanıklılık arasında denge kurulmalıdır.

Inference Endpoint Güvenliği Nasıl Sağlanmalıdır?

Inference endpoint'i bir API olduğu için klasik uygulama ve API güvenlik kontrollerinin tamamı AI servisleri için de geçerlidir.

Temel kontroller:

• Authentication
• Authorization
• Rate limiting
• API gateway
• TLS
• Network segmentation
• Audit logging
• Secrets management
• DDoS koruması

Ayrıca prompt, model output ve kullanıcı context'i kişisel veya ticari olarak hassas veri içerebilir.

Log politikası buna göre tasarlanmalıdır.

Inference, KVKK ve Veri Egemenliği Açısından Nasıl Değerlendirilmelidir?

Kişisel verinin inference sırasında hangi ülkede işlendiği, hangi model platformuna gönderildiği, loglarda ne kadar süre tutulduğu ve kimlerin erişebildiği veri koruma değerlendirmesinin parçasıdır.

Kurumsal inference mimarisinde şu sorular sorulmalıdır:

• Prompt hangi ülkede işleniyor?
• Inference verisi storage'a yazılıyor mu?
• Prompt ve output loglanıyor mu?
• Loglar ne kadar süre tutuluyor?
• Model sağlayıcısı veriyi eğitim için kullanıyor mu?
• Alt işleyenler kimler?
• Yedeklerde prompt verisi bulunuyor mu?
• Veri lokasyonu seçilebiliyor mu?

Veri lokasyonu ve yargı alanı perspektifi için Veri Egemenliği Nedir? rehberi tamamlayıcıdır.

Production Inference İçin Hangi Serving Framework'leri Kullanılır?

Model serving framework'ü GPU kullanım verimliliğini, batching davranışını, memory management'i ve desteklenen optimizasyonları doğrudan etkileyebilir.

LLM inference tarafında kullanılan platformlara örnek olarak:

• vLLM
• NVIDIA TensorRT-LLM
• NVIDIA Triton Inference Server
• Hugging Face serving çözümleri
• Kubernetes üzerinde özelleştirilmiş model serving platformları

verilebilir.

Platform seçiminde yalnızca ham benchmark değil:

• Model desteği
• Quantization desteği
• Continuous batching
• Prefix caching
• Speculative decoding
• Observability
• Autoscaling entegrasyonu
• Multi-GPU desteği
• API uyumluluğu

birlikte değerlendirilmelidir.

Inference Benchmark Nasıl Yapılmalıdır?

Inference benchmark, yalnızca modelin saniyede ürettiği maksimum token sayısını ölçmemelidir. Gerçek production trafiğini temsil eden concurrency, prompt uzunluğu ve output dağılımları kullanılmalıdır.

Benchmark testinde farklı:

• Prompt uzunlukları
• Output uzunlukları
• Concurrency seviyeleri
• Batch boyutları
• Quantization türleri
• GPU modelleri

test edilmelidir.

Ölçülmesi gereken sonuçlar:

• TTFT
• TPOT
• P50 latency
• P95 latency
• P99 latency
• Token throughput
• Maximum stable concurrency
• GPU utilization
• GPU memory utilization
• Birim maliyet

Inference Altyapısı İçin Hangi KPI'lar Takip Edilmelidir?

• TTFT: İlk token'a kadar geçen süre
• TPOT / ITL: Ardışık output token'ları arasındaki üretim süresi
• P95 latency: İsteklerin yüzde 95'inin tamamlandığı süre
• P99 latency: Tail latency göstergesi
• Request throughput: Saniyede tamamlanan request sayısı
• Token throughput: Saniyede işlenen token miktarı
• Concurrency: Eş zamanlı aktif kullanıcı veya request sayısı
• GPU utilization: GPU kullanım oranı
• GPU memory utilization: VRAM kullanım oranı
• KV cache utilization: KV cache kapasitesinin kullanım oranı
• Queue depth: Bekleyen inference request sayısı
• Error rate: Başarısız inference isteklerinin oranı
• Availability: Model endpoint erişilebilirlik oranı
• Cost per request: Başarılı request başına toplam maliyet
• Cost per 1M tokens: LLM workload'unda bir milyon token başına altyapı maliyeti

Inference Altyapısı Kurarken Sorulması Gereken Sorular

Trafik

• Günlük request hacmi nedir?
• Peak traffic ne kadar?
• Concurrency hedefi nedir?
• Trafik ne kadar bursty?

Latency

• TTFT hedefi nedir?
• P95 ve P99 latency hedefleri belirlendi mi?
• Streaming response gerekli mi?

Model

• Model kaç parametre?
• Hangi precision kullanılıyor?
• Quantization mümkün mü?
• Model tek GPU'ya sığıyor mu?
• Context window ne kadar?

Kapasite

• GPU başına kaç concurrent request destekleniyor?
• KV cache kapasitesi ne kadar?
• Minimum warm replica sayısı nedir?

Maliyet

• Cost per request ölçülüyor mu?
• Cost per token ölçülüyor mu?
• Atıl GPU kapasitesi ne kadar?
• Model bazında maliyet ayrıştırılabiliyor mu?

Veri

• Prompt hangi ülkede işleniyor?
• Prompt ve output loglanıyor mu?
• KVKK veya sektörel lokasyon gereksinimi var mı?

Dayanıklılık

• GPU node arızasında ne oluyor?
• Failover modeli var mı?
• Fallback model kullanılabilir mi?

Kurumsal AI Inference Yol Haritası Nasıl Oluşturulur?

Adım 1: Kullanım Senaryosunu Tanımlayın

Chatbot, fraud detection, görüntü işleme veya batch processing gibi workload tipi belirlenmelidir.

Adım 2: SLO'ları Belirleyin

TTFT, latency, throughput ve availability hedefleri tanımlanmalıdır.

Adım 3: Gerçek Trafik Profilini Tahmin Edin

Ortalama değil peak concurrency ve token hacmi esas alınmalıdır.

Adım 4: Modeli Optimize Edin

Quantization, distillation, context reduction ve prompt optimizasyonu değerlendirilmelidir.

Adım 5: Serving Platformunu Seçin

vLLM, TensorRT-LLM veya farklı model serving teknolojileri workload ile benchmark edilmelidir.

Adım 6: GPU ve Altyapıyı Boyutlandırın

Model ağırlıkları, KV cache, concurrency ve high availability birlikte hesaplanmalıdır.

Adım 7: Autoscaling Tasarlayın

Queue, latency ve token hacmine dayalı scaling modeli kurulmalıdır.

Adım 8: Güvenliği ve Veri Lokasyonunu Tasarlayın

API security, network isolation ve kişisel veri akışları değerlendirilmelidir.

Adım 9: Benchmark Yapın

Gerçek production workload'unu temsil eden yük testleri uygulanmalıdır.

Adım 10: FinOps ve Observability Kurun

Model bazında performans ve maliyet sürekli izlenmelidir.

Inference Projelerinde Sık Yapılan Hatalar

1. Training GPU'sunu Otomatik Olarak Inference İçin Kullanmak

Training için doğru olan GPU, production inference'ın latency ve maliyet profili için en iyi seçenek olmayabilir.

2. Yalnızca Ortalama Latency Ölçmek

Ortalama değer iyi görünürken P99 latency kullanıcı deneyimini bozabilir.

3. Model Belleğini Hesaplayıp KV Cache'i Unutmak

Uzun context ve yüksek concurrency GPU belleğinin önemli bölümünü KV cache'e ayırabilir.

4. Her İstek İçin En Büyük Modeli Çalıştırmak

Basit görevler küçük modellerle daha ekonomik şekilde çözülebilir.

5. Context'i Kontrolsüz Büyütmek

Daha fazla context her zaman daha iyi yanıt anlamına gelmez ve prefill maliyetini yükseltir.

6. Cold Start'ı Hesaba Katmamak

Model yükleme süresi ani scale-out sırasında kullanıcı latency'sini etkileyebilir.

7. GPU Utilization'ı Tek Başarı Metriği Kabul Etmek

Kullanıcı SLO'ları ve birim maliyet birlikte izlenmelidir.

8. Gerçek Trafikle Benchmark Yapmamak

Batch 1 veya sentetik kısa prompt benchmark'ı production performansını temsil etmeyebilir.

9. Ağ Latency'sini İhmal Etmek

Kullanıcıya uzak deployment veya zayıf hybrid bağlantı TTFT'yi artırabilir.

10. Maliyet Sahipliği Oluşturmamak

Model ve endpoint maliyeti görünür değilse optimizasyon fırsatları tespit edilemez.

AI Inference İçin On-Premise, Colocation, Private Cloud veya GPUaaS Nasıl Seçilir?

Doğru deployment modeli kullanım süresi, kapasite dalgalanması, veri hassasiyeti, yatırım modeli ve operasyon ihtiyacına göre belirlenmelidir.

AI-ready veri merkezi yaklaşımında colocation, private cloud ve GPU erişim modellerinin nasıl birlikte değerlendirildiğini AI-Ready Veri Merkezi Nedir? içeriğimizde detaylandırıyoruz.

Ixpanse'in Sunucu Barındırma altyapısı carrier-neutral bağlantı seçenekleri ve yüksek yoğunluklu altyapı ihtiyaçları için kurumsal colocation modeli sunar.

Daha kontrollü ve izole kaynak ihtiyacı bulunan iş yüklerinde Özel Bulut modeli değerlendirilebilir.

Ixpanse ile AI Inference Altyapısı

Ixpanse, yapay zeka inference altyapısını yalnızca GPU seçimi olarak değil; compute, veri merkezi, güç, soğutma, bağlantı, private cloud ve operasyon katmanlarının birlikte çalıştığı bir mimari problem olarak ele alır.

Production inference ortamlarında değerlendirilebilecek Ixpanse altyapı katmanları:

• AI-ready veri merkezi altyapısı
• GPU sunucular için yüksek yoğunluklu colocation
• Private cloud altyapısı
• Carrier-neutral bağlantı seçenekleri
• Ankara IX üzerinden bağlantı mimarileri
• Hybrid cloud bağlantısı
• Yönetilen altyapı operasyonu
• Veri koruma ve iş sürekliliği katmanları

Ixpanse'in carrier-neutral Sunucu Barındırma altyapısı, GPU ve AI sunucularının profesyonel veri merkezi ortamında konumlandırılmasını destekler.

Ankara IX ve bağlantı hizmetleri, inference endpoint'leri ile cloud, veri kaynakları ve kullanıcı ağları arasındaki bağlantı mimarisinin daha kontrollü tasarlanmasına yardımcı olabilir.

Yönetilen Hizmetler katmanı ise altyapının performans, availability ve kapasite açısından sürekli izlenmesine destek olur.

Bir modeli PoC aşamasından production inference ortamına taşırken GPU kapasitesi, colocation, private cloud, network ve maliyet mimarisini birlikte değerlendirmek için Ixpanse uzman ekibiyle iletişime geçebilirsiniz.

Sonuç

Yapay zeka projesinin production başarısı yalnızca modelin ne kadar iyi eğitildiğiyle değil, gerçek kullanıcı trafiğine ne kadar hızlı, güvenilir ve ekonomik hizmet verdiğiyle belirlenir.

• Training ve inference farklı altyapı problemleridir.
• Inference sürekli operasyonel maliyet oluşturur.
• Yüksek trafikli sistemlerde inference maliyeti zaman içinde training maliyetini aşabilir, ancak bu her proje için otomatik bir sonuç değildir.
• LLM inference performansında TTFT, TPOT, throughput ve P99 latency birlikte takip edilmelidir.
• GPU belleği yalnızca model ağırlıkları için değil, KV cache için de planlanmalıdır.
• Continuous batching ve iyi scheduling GPU utilization'ı artırabilir.
• Quantization model başına bellek ve compute ihtiyacını azaltabilir.
• Prefix caching tekrar eden context'lerde gereksiz hesaplamayı azaltabilir.
• Her istek için en büyük modeli kullanmak maliyet açısından verimsiz olabilir.
• Autoscaling tasarımında GPU cold start ve model yükleme süresi dikkate alınmalıdır.
• Merkezi ve edge inference kararı workload bazında verilmelidir.
• Inference altyapısı compute kadar network ve veri lokasyonuna da bağlıdır.
• En önemli maliyet metriği toplam GPU faturası değil, üretilen iş değeri başına inference maliyetidir.

Production AI altyapısı tasarlanırken sorulması gereken temel soru:

Modelimiz çalışıyor mu?

değil,

Modelimiz gerçek trafik altında hedeflediğimiz latency, availability ve maliyet seviyesinde sürdürülebilir biçimde çalışabiliyor mu?

olmalıdır.

AI Inference Hakkında Sıkça Sorulan Sorular

AI inference nedir?

AI inference, önceden eğitilmiş bir yapay zeka modelinin yeni girdileri işleyerek tahmin, sınıflandırma, skor veya içerik üretmesi sürecidir.

Inference ile training arasındaki fark nedir?

Training modelin parametrelerini öğrenmesini sağlar. Inference ise eğitilmiş modelin gerçek kullanıcı veya sistem girdileri üzerinde çıktı üretmesidir.

LLM inference nedir?

LLM inference, eğitilmiş büyük dil modelinin kullanıcı prompt'unu işleyerek bir sonraki token'ları tahmin etmesi ve metin yanıtı oluşturması sürecidir.

Inference için mutlaka GPU gerekir mi?

Hayır. Küçük modeller, düşük trafik veya optimize edilmiş modeller CPU ya da farklı accelerator türleri üzerinde yeterli performans gösterebilir. GPU ihtiyacı model boyutu ve latency hedeflerine göre belirlenmelidir.

Training GPU'su inference için kullanılabilir mi?

Evet, ancak ekonomik olarak en iyi seçenek olmayabilir. Inference donanımı latency, throughput, GPU belleği, concurrency ve birim maliyete göre ayrıca değerlendirilmelidir.

Inference maliyeti training maliyetini aşar mı?

Yüksek kullanımlı ve uzun ömürlü production modellerinde aşabilir. Ancak bu her proje için geçerli değildir. Trafik, model boyutu, token hacmi ve altyapı modeli sonucu belirler.

TTFT nedir?

TTFT - Time to First Token, kullanıcının isteği göndermesi ile LLM'in ilk çıktı token'ını üretmesi arasında geçen süredir.

TPOT nedir?

TPOT - Time Per Output Token, ilk token sonrasında her yeni output token'ın üretilme süresini ifade eden inference metriğidir.

KV cache nedir?

KV cache, transformer modelinin önceki token'lar için hesapladığı attention key ve value verilerini saklayarak aynı hesaplamaların her token için tekrarlanmasını azaltan bellek yapısıdır.

Continuous batching nedir?

Continuous batching, LLM serving sırasında yeni isteklerin aktif batch'e eklenmesi ve tamamlanan isteklerin çıkarılmasıyla GPU kullanımının daha verimli hale getirilmesini amaçlayan scheduling yöntemidir.

Quantization nedir?

Quantization, model ağırlıkları veya diğer hesaplama verilerinin daha düşük hassasiyetli sayı formatlarıyla temsil edilerek bellek ve compute ihtiyacının azaltılmasıdır.

Quantization model kalitesini düşürür mü?

Düşürebilir, ancak etkinin büyüklüğü model ve quantization yöntemine bağlıdır. Bu nedenle kalite ve performans gerçek kullanım verisiyle test edilmelidir.

Prefix caching nedir?

Prefix caching, birden fazla inference isteğinde tekrar kullanılan ortak prompt veya context bölümlerinin hesaplama sonuçlarının yeniden kullanılmasını sağlayan optimizasyon yöntemidir.

Speculative decoding nedir?

Speculative decoding, daha hızlı bir modelin token önerileri üretmesi ve ana modelin bunları doğrulaması üzerinden LLM token üretimini hızlandırmayı amaçlayan yöntemdir.

Inference autoscaling nedir?

Inference autoscaling, kullanıcı talebi ve performans metriklerine göre model serving kapasitesinin otomatik olarak artırılması veya azaltılmasıdır.

GPU autoscaling neden zor olabilir?

GPU kapasitesinin açılması, container başlatılması ve model ağırlıklarının GPU belleğine yüklenmesi zaman alabilir. Bu nedenle production sistemlerinde cold start dikkate alınmalıdır.

Edge inference nedir?

Edge inference, model çıkarımının merkezi cloud veya veri merkezi yerine kullanıcıya veya veri kaynağına yakın bir cihaz veya edge altyapısında gerçekleştirilmesidir.

Edge inference her zaman daha hızlı mıdır?

Hayır. Ağ round trip süresini azaltabilir ancak edge donanımının compute kapasitesi merkezi GPU sisteminden daha düşük olabilir. Sonuç workload'a göre değişir.

Inference maliyeti nasıl ölçülmelidir?

GPU veya CPU maliyetine ek olarak enerji, storage, network, yazılım ve operasyon giderleri dahil edilmeli; sonuç request veya token başına birim maliyet olarak takip edilmelidir.

LLM inference için en önemli KPI'lar nelerdir?

TTFT, TPOT veya ITL, P95 ve P99 latency, token throughput, concurrency, GPU utilization, GPU memory, KV cache kullanımı, error rate ve cost per token temel KPI'lardır.

vLLM nedir?

vLLM, LLM modellerinin yüksek throughput ile servis edilmesine yönelik PagedAttention, continuous batching, prefix caching, quantization ve distributed inference gibi optimizasyonlar sunan açık kaynaklı model serving teknolojisidir.

TensorRT-LLM nedir?

TensorRT-LLM, NVIDIA GPU'larda büyük dil modellerinin inference performansını optimize etmek için kullanılan NVIDIA model serving ve inference optimizasyon teknolojisidir.

Inference için colocation mantıklı mıdır?

Sürekli ve öngörülebilir yüksek GPU kullanımı bulunan şirketlerde AI-ready colocation, GPU donanımı üzerinde daha fazla kontrol ve daha öngörülebilir altyapı maliyeti sağlayabilir.

GPUaaS hangi inference senaryolarında uygundur?

PoC, dönemsel ihtiyaç, değişken trafik veya hızlı kapasite gerektiren projelerde GPU kapasitesine hizmet modeliyle erişim esneklik sağlayabilir.

Ixpanse AI inference altyapısını nasıl destekler?

Ixpanse, AI-ready veri merkezi, yüksek yoğunluklu colocation, private cloud, carrier-neutral bağlantı, Ankara IX ve yönetilen hizmet katmanlarıyla production AI altyapısının compute, network ve operasyon gereksinimlerini destekler.

İlgili İçerikler

• HPC ve Yapay Zeka Projeleri İçin Altyapı Gereksinimleri
• AI-Ready Veri Merkezi Nedir?
• Edge Computing Nedir?
• Cloud FinOps Nedir?
• Direct Cloud Access Nedir?
• Sunucu Barındırma
• Özel Bulut
• Ankara IX
• Yönetilen Hizmetler

Teknik Kaynaklar

• vLLM Documentation 
• NVIDIA TensorRT-LLM Documentation 
• NVIDIA TensorRT Performance Optimization