Kendi GPU'lar mı, bulut API mi: token başına maliyet hesaplama

Kendi GPU'larınızda token başına maliyet, sunucuların tam yüklü yıllık maliyetinin (donanımın 3 ila 5 yıla yayılan amortismanı, elektrik, alan, ağ altyapısı, yazılım, personel) gerçekten kullandığınız GPU-saate, ardından bir GPU-saatin gerçek trafiğinizde ürettiği token sayısına bölünmesiyle bulunur. Sabit ve öngörülebilir hacim GPU'ları yüzde 60 ila 90 kullanım oranında tutuyorsa kendi altyapınızı barındırmak kazanır; hacim düşük, dalgalı veya belirsizse bulut API'leri kazanır. Çoğu kurum sonunda hibrit bir yapıya ulaşır: şirket içinde barındırılan bir taban kapasite artı ani yüklenmeler ve sınır (frontier) modeller için API kapasitesi.

Kendi altyapını barındırmanın tam maliyet modeli

Çoğu maliyet karşılaştırması ilk adımda yanlış gider: GPU satın alma fiyatını bir API fiyat listesiyle kıyaslarlar. Doğru birim, sunucuları çalıştırmanın tam yüklü yıllık maliyetidir ve bunun yedi kalemi vardır.

1. Amortismana tabi tutulan sunucu yatırım maliyeti (capex). Sunucunun tam fiyatı (GPU'lar, CPU'lar, bellek, NVMe, NIC'ler), 3 ila 5 yıla doğrusal olarak yayılır. Üç yıl, yaygın BT amortisman uygulamasına uyar; beş yıl ise bir GPU neslinin çıkarım için ne kadar süre kullanışlı kaldığına karşılık gelir. Tek başına bu tercih, sonucu yüzde 40'a kadar değiştirebilir.
2. Elektrik ve soğutma. 8 GPU'lu bir H100 SXM sunucu tam yükte yaklaşık 10 kW çeker (GPU başına 700 W artı CPU'lar, bellek, fanlar ve NIC'ler). Ortalama çekişi tesisin PUE değeriyle (yaklaşık 1,2 ila 1,5) ve elektrik biriminizle çarpın.
3. Ortak veri merkezi (colocation) veya veri merkezi alanı. Rak alanı, soğutma ve uzaktan teknik destek, genellikle tahsis edilen güç kW'ı başına fiyatlandırılır. GPU rakları 10 ila 40 kW'lık kabinlere ihtiyaç duyar.
4. Ağ altyapısı. Çoklu düğüm kurulumları için rak üstü anahtarlar, InfiniBand veya 400 GbE, artı transit ve güvenlik duvarlarından düşen pay.
5. Yazılım ve lisanslar. vLLM, TensorRT-LLM ve NVIDIA NIM çalıştırması ücretsiz olabilir; ancak kurumsal Linux, izleme, gizli bilgi (secrets) yönetimi ve isteğe bağlı NVIDIA AI Enterprise desteği gerçek maliyet kalemleridir.
6. Operasyon personeli. Yama yönetimi, izleme, model güncellemeleri, yeniden kıyaslama ve nöbet: sunucu başına, filo büyüdükçe küçülen bir tam zamanlı personel (FTE) kesri.
7. Donanım desteği ve yedek parça. Genellikle yıllık capex'in birkaç yüzdesi kadardır.

Sekizinci faktör bir maliyet değil, bir bölendir: kullanım oranı. Satın aldığınız bir GPU, saniyede 2.000 token sunsun ya da gece 3'te boşta dursun aynı maliyete mal olur. Modeldeki en önemli tek sayı, satın alınan GPU-saatlerin gerçekten trafiğe hizmet eden payıdır.

Yıllık maliyetten GPU-saat ve milyon token başına maliyete

Yıllık maliyet bilindiğinde, dönüşüm iki bölme işlemidir: önce gerçekten kullanacağınız GPU-saate, ardından bir GPU-saatin iş yükünüzde ürettiği token sayısına.

cost_per_gpu_hour    = total_annual_cost / (gpu_count x 8,760 x utilization)
tokens_per_gpu_hour  = measured_tokens_per_sec_per_gpu x 3,600
cost_per_million_tok = cost_per_gpu_hour x 1,000,000 / tokens_per_gpu_hour

Verim (throughput) terimi bir pazarlama slaydından kopyalanmamalı, ölçülmelidir. Model boyutuna, kuantizasyona (FP8 veya INT4 ağırlıklar saniyedeki token sayısını FP16'ya kıyasla belirgin biçimde artırır), prompt ve tamamlama uzunluklarına, eşzamanlılığa ve kabul ettiğiniz gecikmeye bağlıdır. Aynı H100, bu tercihlere göre 5 ila 10 kat farklılık gösterebilir.

Savunulabilir bir ölçüm yöntemi:

1. Üretimde çalıştıracağınız modeli, kuantizasyonu ve sunum motorunu sabitleyin (sunum motoru karşılaştırmamıza bakın).
2. Gerçek trafiği örnekleyin: günün saatine göre girdi uzunlukları, çıktı uzunlukları ve saniyedeki istek sayısı. Sentetik 128 token'lık prompt'lar verimi olduğundan yüksek gösterir.
3. vLLM kıyaslama araçlarıyla artan eşzamanlılıkta yük testi yapın ve bu dağılımı yeniden oynatın.
4. p95 gecikmesinin hâlâ SLO'nuzu karşıladığı en yüksek eşzamanlılıkta toplam saniyedeki token sayısını kaydedin.
5. Testteki GPU sayısına bölün ve tepe noktaları ile model yeniden yüklemeleri için yüzde 15 ila 25 pay ekleyin.

Trafik prompt ağırlıklıysa prefill ve decode'u ayrı ayrı ölçün; çünkü girdi token'ları paralel işlenir ve çıktı token'larının tek tek üretilmesine kıyasla çok daha az maliyete mal olur. Verimi kendi trafik karışımınızda ölçün ve her satıcı kıyaslamasını bir üst sınır olarak değerlendirin.

Varsayımsal sayılarla örnek hesaplama

Aşağıdaki rakamlar açıklayıcı yer tutuculardır, fiyat teklifi değildir. Gerçek değerler bölgeye, satıcıya ve sözleşmeye göre değişir; bu nedenle güncel fiyatlandırmayı doğrulayın ve her satırı kendi rakamlarınızla değiştirin.

Sekiz GPU, yılda 70.080 GPU-saat sağlar. Yüzde 90 kullanım oranında tam yüklü maliyet GPU-saat başına yaklaşık $2,69'dur; yüzde 60'ta $4,04; yüzde 30'da $8,07'dir. Donanımla ilgili hiçbir şey değişmedi, yalnızca ne kadarının kullanıldığı değişti.

Şimdi ölçülmüş bir verimi uygulayalım. Aşağıdaki tablo, üç varsayımsal GPU başına verim düzeyi için üç kullanım oranında milyon token başına maliyeti (girdi ve çıktı karışık) gösteriyor.

Aynı donanımda en kötü ve en iyi hücre arasındaki fark 12 kattır. Kullanım oranı ve ölçülen verim, token başına maliyeti tek başlarına 3 kat veya daha fazla değiştirir; bu nedenle satın alma sonrası verilen mühendislik kararları, satın almanın kendisi kadar önemlidir.

Bulut API fiyatlandırmasıyla nasıl karşılaştırılır

API fiyatları milyon token başına verilir, ancak nadiren tek bir sayıdır; bu yüzden trafiğinizi yansıtan karma (blended) bir oran hesaplamanız gerekir. Öncelikle her satıcıyla güncel fiyatlandırmayı doğrulayın; 2026 itibarıyla liste fiyatları yılda birkaç kez değişiyor ve model katmanına göre farklılaşıyor.

En önemli üç fiyatlandırma boyutu:

• Girdi ve çıktı token'ları. Çoğu satıcıda çıktı token'ları girdiye göre kat kat daha yüksek fiyatlandırılır, çünkü decode maliyetli aşamadır. Özetleme (uzun girdi, kısa çıktı) ile kod üretimi (kısa girdi, uzun çıktı), aynı modelde karma fiyatta 3 kat farklılık gösterebilir.
• Toplu işlem indirimleri. Çoğu satıcı, birkaç saatlik bir tamamlanma penceresi karşılığında asenkron toplu iş yüklerine indirim uygular; bu genellikle standart oranın yaklaşık yarısı kadardır.
• Prompt önbellekleme. Tekrar eden ön ekler (sistem prompt'ları, RAG bağlamı, few-shot örnekleri) önbellekten girdi fiyatının bir kesri karşılığında sunulur, bazen bir yazma ücretiyle birlikte. Yüksek bir isabet oranı, ajan ve RAG iş yükleri için hesabı değiştirir.

Milyon token başına karma API fiyatı şudur:

p_blended = share_in x (hit_rate x p_cached + (1 - hit_rate) x p_in) + share_out x p_out

Burada share_in ve share_out, trafiğinizdeki girdi ve çıktı token'larının oranlarıdır; toplu işlem indirimini asenkron paya uygulayın. Sonucu, gerçekçi olarak beklediğiniz kullanım oranındaki kendi barındırma maliyetinizle karşılaştırın, yüzde 100'de değil.

Gerçekçi kullanım oranınızdaki kendi barındırma maliyetinizi milyon token başına, girdi-çıktı oranınızı, önbellek isabet oranınızı ve toplu işlem payınızı yansıtan karma bir API oranıyla karşılaştırın.

Başabaş mantığı ve her iki tarafın gizli maliyetleri

Kendi altyapını barındırmak sabit bir maliyet, API'ler ise değişken bir maliyet olduğundan başabaş noktası aylık bir token hacmidir: aylık sabit maliyetin karma API fiyatına bölünmesi. Örnek hesaplamada sunucu maliyeti ayda yaklaşık $14.100'dür. GPU başına saniyede 300 token'da sunucu kapasitesinin yaklaşık yüzde 75'ine karşılık gelen, varsayımsal milyon token başına $3'lük karma bir API oranına karşı başabaş noktası yaklaşık 4,7 milyar token/aydır. Varsayımsal $5'lik bir orana karşı bu, kapasitenin yaklaşık yüzde 45'i olan 2,8 milyar token'a düşer.

Bu nedenle sabit, yüksek ve öngörülebilir hacim kendi GPU'larınızı destekler, çünkü satın aldığınız kapasiteyi doldurabilirsiniz. Dalgalı, düşük veya belirsiz hacim ise API'leri destekler, çünkü boşta geçen saatler hiçbir şeye mal olmaz ve donanımı atıl bırakmadan model değiştirebilirsiniz. Ortalamada yüksek olup ortalamanın 5 katına varan tepe noktaları yapan hacim, hibrit tasarımlara yol açan zor durumdur.

Kendi altyapını barındırma tarafındaki gizli maliyetler:

• Tedarik süresi ve ilk üretim token'ından önce geçen mühendislik ayları.
• GPU arızaları ve firmware sorunları; yedek bir GPU ya da bir sonraki iş günü destek sözleşmesi isteğe bağlı değildir.
• Model değişimi: 2 kat bellek gerektiren yeni bir açık ağırlıklı model, öncekine göre boyutlandırılmış bir sunucuyu atıl bırakabilir (bkz. her model için kaç GPU gerektiği).
• Atıl güç: GPU'lar boştayken bile tepe gücün anlamlı bir kısmını çeker; bu yüzden düşük kullanım oranı elektrik faturasını orantılı biçimde düşürmez.

API tarafındaki gizli maliyetler:

• Prompt şişmesi: sistem prompt'ları, araç şemaları ve RAG parçaları her çağrıda yeniden gönderilir ve her seferinde girdi olarak faturalandırılır.
• Fiyat değişiklikleri ve model kullanımdan kaldırmaları, satıcının takvimine göre yeniden test yapmayı zorunlu kılar.
• Trafiğinizin tam tepe noktasında oran limitleri.
• Veri koruma: DPA'lar, veri yerleşimi (residency) garantileri ve denetim hakları hukuk ve uyumluluk ekiplerinin zamanını alır.

Başabaş noktası bir tarih değil, bir hacimdir: sabit kendi barındırma maliyetinin değişken API maliyetine eşit olduğu aylık token miktarını bulun, ardından bunu sürdürüp sürdüremeyeceğinizi dürüstçe sorun.

Genellikle kazanan strateji: hibrit yaklaşım

Maliyet modeli nadiren saf bir cevap verir ve 2026 itibarıyla en sağlam mimari her ikisini birden kullanır. Sabit taban için (kabaca saatlik yükün p50 ila p70'i) kendi barındırdığınız bir küme boyutlandırın, bunu yüksek kullanım oranında çalıştırın ve bunun üzerindeki her şeyi bir API'ye yönlendirin. vLLM, TensorRT-LLM ve NVIDIA NIM OpenAI uyumlu bir uç nokta sunduğundan, yönlendirme bir uygulama yeniden yazımı değil, bir ağ geçidi (gateway) yapılandırmasıdır.

Modeli dürüst tutan yönlendirme kuralları:

1. Önce veri hassasiyetine göre: düzenlemeye tabi veya gizli prompt'lar, maliyetten bağımsız olarak kendi GPU'larınızda kalır.
2. Modele göre: orta boy açık ağırlıklı bir model kendi GPU'larınızda büyük kısmı karşılar; API, bir sınır (frontier) model gerektiren küçük payı sunar.
3. Aciliyete göre: etkileşimli trafik kendi barındırılan taban kapasiteyi kullanır; asenkron işler, küme doluyken API'nin toplu işlem katmanına, dolu değilken gece kendi GPU'larınıza gider.
4. Kapasiteye göre: kuyruk derinliği bir eşiği aştığında API'ye taşırın ve maliyeti kaydedin ki bir sonraki boyutlandırma turunda veri olsun.

Faydalı bir ara adım, bulut GPU'larını saatlik veya yıllık olarak kiralamaktır: bu, tedarik süresini ortadan kaldırır ve capex taahhüdü öncesinde gerçek kullanım verisi üretir. Birçok ekip buradan başlar, ardından taban kapasiteyi bir şirket içi (on-premise) dağıtım planını izleyerek kendi donanımına taşır. Nanobase AI, trafik geçmişi altı aydan kısa olduğunda genellikle bu sırayı önerir.

Taban kapasiteyi sahiplenin, tepe noktalarını kiralayın ve yönlendirme kararını bir ağ geçidinde verin; böylece bölünme, uygulamalara dokunmadan değişebilsin.

Sık sorulan sorular

Şirket içi barındırılan LLM çıkarımı için gerçekçi bir GPU kullanım oranı nedir?

Yalnızca etkileşimli gündüz trafiğine hizmet eden kümeler, geceler ve hafta sonları atıl kaldığından tipik olarak yüzde 30 ila 50 kullanım oranında kalır. Mesai dışı saatlere toplu iş yükleri (belge işleme, değerlendirmeler, gömme/embedding) ekleyen ekipler yüzde 70 ila 90'a ulaşır. Ölçülmüş verileriniz yoksa yüzde 60 üzerinden planlayın; sürdürülen yüzde 85 üzeri mükemmeldir.

GPU sunucularını 3 yıl üzerinden mi, 5 yıl üzerinden mi amortismana tabi tutmalıyım?

Muhafazakâr senaryo için 3 yıl, iyimser senaryo için 5 yıl kullanın ve ikisini de gösterin. Üç yıl, yaygın BT amortisman takvimlerine ve yeni GPU nesillerinin çıkış hızına uyar. Beş yıl, bir H100'ün en yeni donanıma göre token başına daha yüksek maliyetle de olsa, yeni parçalar piyasaya çıktıktan sonra da çıkarımda iyi hizmet vermeye devam ettiğini yansıtır. Finans ekibiniz bir takvim zorunlu kılıyorsa onu kullanın.

Formül için saniyede token sayısını nasıl ölçerim?

Üretimde çalıştıracağınız tam modeli, kuantizasyonu ve sunum motorunu, gerçek prompt ve tamamlama uzunluğu dağılımınızı yeniden oynatarak yük testine tabi tutun. p95 gecikmesi SLO'nuzu aşana kadar eşzamanlılığı artırın ve bu noktanın hemen altındaki toplam saniyedeki token sayısını alın. GPU sayısına bölün. Her model veya motor yükseltmesinden sonra yeniden ölçün, çünkü verim çoğu ekibin beklediğinden daha fazla değişir.

Çıktı token'ları neden girdi token'larından daha pahalı?

Girdi token'ları, GPU hesaplamasını verimli kullanan tek bir paralel prefill geçişinde işlenir. Çıktı token'ları sıralı olarak, token başına bir ileri geçişle üretilir ve her geçiş hesaplama gücünden çok bellek bant genişliğiyle sınırlıdır. Daha yüksek bellek bant genişliğine sahip H200 ve B200'in decode verimini artırmasının nedeni budur. API satıcıları da aynı nedenle çıktıyı daha yüksek fiyatlandırır; bu yüzden girdi-çıktı oranınız karma maliyeti belirler.

Prompt önbellekleme, kendi altyapını barındırma kararını değiştirir mi?

Değiştirebilir. Girdi token'larının çoğu uzun sistem prompt'ları veya paylaşılan RAG bağlamı gibi tekrar eden ön ekler ise, API önbellekleme etkin girdi fiyatını ciddi biçimde düşürür; bu da karma API oranını azaltır ve başabaş hacmini yukarı çeker. Kendi barındırdığınız motorlar da ön ek (prefix) önbellekleme destekler ve bu, ölçülen veriminizi artırır. Her iki etkiyi de gerçek önbellek isabet oranınızla modelleyin.

Kendi altyapını barındırmak hangi aylık token hacminde kârlı hale gelir?

Donanım maliyetinize, kullanım oranınıza ve aksi halde ödeyeceğiniz API oranına bağlı olduğundan evrensel bir sayı yoktur. Yöntem sabittir: aylık tam yüklü sunucu maliyetinizi milyon token başına karma API fiyatına bölün. Bu makaledeki varsayımsal örnekte bu, 8 GPU'lu bir sunucu için ayda birkaç milyar token'dır. Bu hacmin altında, ve dalgalı trafik için, API'ler daha ucuzdur.

Nanobase AI nasıl yardımcı olabilir

Nanobase AI, sizinle birlikte maliyet modelini kurar ve ardından önerdiği altyapıyı teslim eder. Ölçülmüş trafiğinize göre H100, H200, B200 veya RTX PRO kümelerini boyutlandırır, aday modelleriniz üzerinde vLLM, TensorRT-LLM veya NVIDIA NIM ile verimi kıyaslar ve finans ekibinizin denetleyebileceği, güncel API fiyatlandırmasına karşı token başına maliyet karşılaştırması üretiriz. Cevap hibritse, Kubernetes GPU Operator, izleme ve fazla trafiği AWS, Azure veya Google Cloud'a yönlendiren OpenAI uyumlu bir ağ geçidiyle kendi barındırılan taban kapasiteyi devreye alırız.

Silikon Vadisi merkezli bir kurumsal yapay zeka mühendisliği şirketi ve NVIDIA Inception Programı üyesi olarak donanım boyutlandırma, sunum optimizasyonu ve entegrasyonu tek bir projede bir araya getiriyoruz. Çözümlerimizi keşfedin veya bir canlı demo ayırtın.

Projenizi konuşmaya hazır mısınız? Nanobase AI ile iletişime geçin veya hello@bumu.tech adresine e-posta gönderin.